[Top] [All Lists]

Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?

2021-06-04 12:13:12

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

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.


Dave Crocker
Brandenburg InternetWorking

ietf-smtp mailing list