But in the bigger picture, every time you use a U-label or a UTF-8 local-part,
you make it more difficult to deal with the case when you hit a point where the
SMTPUTF8 extension isn't available.
We have two downgrading options defined, but neither of them is terribly
attractive.
What this argues for is to eliminate as much use of the extension as you
possibly can. And if that means using A-labels, or even dropping the use of
"for" clauses - which are optional anyhow - so be it.
If I've read this thread correct, the main argument for the original
SHOULD was convenient display to (end) users. While that's a laudable
goal, it's quite different from a typical protocol mandate to achieve
interoperability.
Further, it appears that implementers have chosen to widely ignore the
SHOULD, in favor of A-labels. Again, this does not hurt
interoperability, but makes reading by /some/ humans more challenging,
though not impossible. Even further, it appears that A-labels work well
for some other readers.
My impression is that the SHOULD represented idealism over simple
pragmatism.
The basic work was to extend an existing service to support a wider
range of characters. With some consistency, that kind of task fares
much better with an overlay solution. (Think MIME.) A-labels are an
overlay. U-labels are not.
If the operational industry has voted with its code and clearly prefers
A-labels, than the SHOULD is an especially counter-productive choice,
since it creates debate about the specification where, really, it has no
benefit. I suspect MAY is the better choice. It gives permission and
even implicit encouragement, but eliminates the standards tension caused
by not using U-labels.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp