ietf-smtp
[Top] [All Lists]

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

2021-06-04 17:45:50


--On Friday, June 4, 2021 15:14 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

On 6/4/2021 3:06 PM, Sam Varshavchik wrote:
The current preference is for A-labels. But after SMTPUTF8
becomes  customary: at some point it will make sense to
interpret SHOULD using  its original meaning, here.

One of the consistent demonstrates of Internet Scale is that
transition times are /really/ long.

But that was another very explicit decision of the WG: to focus
on when, as Sam puts it, SMTPUTF8 becomes customary and then try
to accelerate the rate of adoption.  That was, in particular,
rather than trying to invent horrible kludges that we would then
want to transition away from, facing exactly the problem you
identify, a problem that normally gets even worse when those
kludges that "everyone" has adopted mostly work.  

If one views the desire to get a fast transition from a really
extreme direction (and I'm trying to summarize some of the
perspective of WG participants, not advocate for it), then "what
happens when a message gets partway across the Internet and then
hits a system that does not support the extension?" is very
nearly a feature, as in "let the users complain until the
relevant system is upgraded" and/or "encourage destination
system that do not support the extension to avoid advertising MX
intermediaries until the whole chain is upgraded".  

And, again, if we conclude that expectation was either
unrealistic or just a bad idea, well hindsight is great, isn't
it?

One other decision we didn't make is worth remembering.  That
decision would have been to keep mailbox names in ASCII (using
U-labels in the domain part if needed but following 2891/5321
and 2892/5322 strictly wrt the local part).  No changes to trace
fields, no complications with header-signing protocols, etc.
Instead, we would just put more emphasis on name phrases in
header fields, using encoded words if needed, and _maybe_
creating a small SMTP extension to allow carrying those phrases
into the envelope as parameters to MAIL and RCPT.  That was,
perhaps for good reason, completely unacceptable to those who
thought they needed non-ASCII local parts and probably
unacceptable to everyone in the relevant countries who like
using email addresses as identifiers.  But, if we wanted to
concentrate on easy and smooth extensibility and ignore those
use needs, a good exercise in second-guessing the WG's decision
might yield that sort of result.  And, btw, while we were at it,
we could decide to second-guess all of those email address as
personal identifier ideas.  :-(

best,
  john


with reference to my prior note

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>