--On Tuesday, May 25, 2021 14:29 -0400 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
It appears that John C Klensin <john-ietf(_at_)jck(_dot_)com> said:
It would certainly be appropriate to either revise the spec
or, better from my point of view, create a short applicability
statement that explains the reasoning behind the SHOULD and
the circumstances under which it would be sensible to ignore
it. ...
The thing that sometimes gets lost in "let's make the spec
conform to what implementations are doing" discussions in this
area is that there is an assumption behind the whole
collection of SMTPUTF8 specs, namely that the world really
wanted non-ASCII addressing and header field values. ...
This may seem like splitting hairs but there is a difference
between header fields that users see and fields that they
don't. Message-IDs are still generally ASCII in EAI messages,
and I don't see any benefit from making the domain names in
trace headers U-labels rather than A-labels.
I'm not getting any pushback on Return-Path which really does
need to be UTF-8 is it's an EAI address. I think the few MTAs
that put a FOR clause in the Received header put EAI addresses
there, too.
I recognize the distinction while also realizing that, as you
know, things often leak. My recollection (if Jiankang is
following this, his memory is probably better than mine) is that
the WG explicitly discussed the issue and concluded that
U-labels were a better idea than A-labels.
One way or the other, let me split a different hair. As I read
RFC 6531, all the penultimate paragraph of Section 3.7.3 says is
that the "server SHOULD use the U-label form". It does not
discuss circumstances under which it is reasonable for an
implementation to do otherwise. If the implementations you are
talking about have rational reasons for doing otherwise, then
they are still conforming, even if not exhibiting preferred
behavior. Does that mean the spec should be revised? I don't
think so unless (1) we feel a need to be explicit about when it
is ok to do something different than the SHOULD specifies, (2)
we gave decided it is not the preferred behavior after all, or
(3) we have concluded that the assumption that substantially all
MTAs will migrate to SMTPUTF8 support is incorrect.
So, barring the third option above and given that U-labels and
A-labels are reversibly convertible without information loss, I
just do not see a big deal
here, certainly not one that would justify reopening the
document(s).
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp