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

[John C Klensin <[e-mail]>]

--On Tuesday, May 25, 2021 14:29 -0400 John Levine
<[e-mail]> wrote:

> It appears that John C Klensin  <[e-mail]> 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