Re: Should we update an RFC if people refuse to implement parts of it ?

> 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