[Top] [All Lists]

Re: [ietf-smtp] How wrong is this EAI implementation

2020-06-23 18:17:18

--On Tuesday, June 23, 2020 15:09 +0200 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:

On Sunday 21 June 2020 16:53:42 CEST, John Levine wrote:
I don't think that 5321 requires that bob(_at_)example(_dot_)com and
bob(_at_)EXAMPLE(_dot_)COM be treated the same, either.

Beyond some point, you can't force people to be reasonable.

Agree entirely. And this is why I think the EAI specs are too
subtle on this point.

I do have an opinion about what that point is, and what the
documents ought to say. But my real issue is that it's
possible to review source code against every MUST and SHOULD
in 653x and miss that there's something to consider.

In my capacity as the former co-chair of the former WG a few
observations while speaking only for myself:

* Like so many other i18n efforts in the IETF in recent years,
the WG had mostly run out of energy by the time it got those
documents out.  I don't know if there would be energy and the
needed focus to start (and ultimately finish) clarifying
documents but other events of the last year or two leave me very

* There were several important contributors to EAI WG-produced
specs who remain on the ima(_at_)ietf(_dot_)org list (although even some of
them have move on to other work professionally) but who are not
on this one.   Absent a move by the relevant ADs (presumably
after discussion on both lists) to consolidate them, if one
wants to have a serious discussion about SMTPUTF8 ("EAI")
issues, those issues should probably be addressed there (instead
or in addition).

* Just as I think that the "core" RFC 5321/5322 specs and
possibly some closely-related work are overdue for an
applicability statement that discusses what is common,
reasonable, and/or likely to work well in practice independent
of what is formally permitted, a similar document would almost
certainly be useful about assorted i18n extensions to email.
I'd think that, not only should 6530-6533 and 6855-6858 be
addressed (including whatever experience we have had that would
suggest that one or both of 6857 and 6858 should be revised or
deprecated), but that such an effort would want to make clear
statements about the relevance of PRECIS to email address
local-parts and to discuss and make recommendations about when
to use non-ASCII addresses and relevant headers and when to
stick to RFC 2231-style encoded words.  If anyone thinks it is
the right time to do the work and produce that document, and
that the IETF would have the energy and will to process it in a
timely way, I look forward to an I-D with great anticipation.

And, fwiw, I certainly agree that one could do a code review
against normative statements and miss that there are issues to


ietf-smtp mailing list