[Top] [All Lists]

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

2021-06-05 02:21:38

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

On 6/4/2021 3:21 PM, John C Klensin wrote:
Would the EAI WG have made
different decisions in some cases had there been full
understanding of what we know now, including what and how
people would choose to implement?

No doubt you are right.  We didn't have much experience yet,
with operational enhancement efforts such as ESMTP, RFC2822,
MIME, DNSSec, DKIM, or much else.

Otherwise, please explain how additional discussions of the
wording of the specs -- perhaps as distinguished from sharing
implementation experience and perspectives -- are helpful.

The current concern I saw is with field experience
demonstrating that SHOULD is out of sync, with the obvious
suggestion that it be changed.

You appear to be asking how it would be helpful to have the
specification reflect extensive field experience.  But maybe

No.  I am asking a much more pragmatic question or pair of
questions: (i) whether making a change in this area (see below)
is worth, at this particular point, opening up RFC 6531 and/or
6532 (and reviewing whether other documents in the SMTPUTF8
collection to see if they need similar adjustments) would be
worth the trouble and (ii) whether there is the energy to do
that and to do it well.

I think it is particularly important to ask the second question
because the apparently  underwhelming speed at which EMAILCORE
is converging on 5321bis and 5322bis does not support the
hypothesis that there is a lot of energy to do work like this
and because there are i18n issues associated with what the right
solutions might be and there appears to be even less energy in
the IETF for that kind of work.

And, finally, while I am personally convinced, at least at this
moment, that changes to the relevant text would be appropriate
if we had the collective time and energy, it is much less clear
to me that swapping MAY for SHOULD is the correct change to
make.  If, in the long term and when SMTPUTF8 is ubiquitous,
U-labels were really the better answer for this case, then the
test ought to explain why that is the right target even while
explaining why A-labels may be appropriate during the transition
period (however long that lasts).  Simply saying "everyone who
has spoken up about implementations is using A-labels" is
actually not a sufficient reason to change the spec.  And I
again note that the people who were represented in the WG with
the strongest perceived need for non-ASCII email addresses do
not appear to be represented on this list.  Making a decision
without them having the ability to be consulted would seem to me
to be profoundly unfair and unreasonable.


changing, e.g., SHOULD to MAY (if that were to be the right

ietf-smtp mailing list

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