Re: Should we update an RFC if people refuse to implement parts of it ?

Victor, John, and probably others,

(explicitly adding Jiankang and the ART ADs in case they not
been following this list closely.)

In addition to believing the text is probably right as it now
appears, I should be explicit about why I'm pushing back on
doing anything about this other that reassuming implementers who
use A-labels that no one is likely to call the Protocol Police.  

The other reasons, and the more important ones, are completely
pragmatic.  First, given the heavy dependencies of the SMTPUTF8
documents on RFCs 5321 and 5322 and that the latter are being
revised, I think it would not be helpful to revises the SMTPUTF8
documents until after we have finished with the revisions of the
base documents.  As I assume others have noticed, those
revisions are not proceeding quickly... and, wherever the fault
lies, is it not with Pete or myself. Second, even if there is
sufficient energy to do serious work on email (and the rate of
progress in EMAILCORE could be interpreted as evidence to the
contrary), there is ample evidence (painful to me personally)
that there is little or none of the combined knowledge,
expertise, and energy to do serious i18n work.  Revision of
these specs requires knowledge and interest in both (and, for
this particular case, specific knowledge and experience with
some of the subtle tradeoffs in IDNA2008).  And finally, unless
I have misread the signals from the ADs, we are not likely to
see many (if any at all) no-WG, AD-sponsored standards track
documents about which there is any controversy.  In the case,
the controversies are already clear from this fairly short
thread.  So, unless someone is really to propose a WG and make a
serious suggestion about where the energy is going to come from
--especially when EMAILCORE is still going on-- well...

I would add to this disclaimer that my hope and expectation when
the EAI WG wound down was that fully conforming implementations
would deploy rapidly and extensively enough that, by the time we
got around to revising 5321 and 5322, we could just fold most of
those specs in, maybe talking about "minimal" and "recommended"
(i.e., fully internationalized) implementations.  Silly me.

best,
   john



--On Tuesday, May 25, 2021 15:32 -0400 Viktor Dukhovni
<[email protected]> wrote:

> On Mon, May 24, 2021 at 07:05:53PM -0400, John R. Levine wrote:
> 
>> I've been doing some EAI tests.  RFC 6531 section 3.7.3 says
>> that domain  names in trace headers SHOULD all be U-labels.
>> In practice, everyone uses  A-labels for reasons that are not
>> absurd.  The FROM clause has the name  from the EHLO command
>> which has to be sent as A-labels, and it's quite  plausible
>> to have a message where the message itself is entirely ASCII, 
>> sent to a UTF-8 address, which then could be forwarded to an
>> ASCII address  except that it has those U-labels in the trace
>> header which would have to  be downgraded.  I've talked to a
>> couple of MTA maintainers who have told  me forget it, that's
>> silly, not doing that.
> 
> Disclaimer: I'm one of the MTA maintainers who found the RFC
> advice in question to be unworthy of implementation.
> 
>> In a situation like this, would it make sense in a future
>> update to the  RFC to adjust the advice to the reality?
> 
> Without daring to generalise to broader questions of
> whether/when the spec or the implementations have the final
> say, on the particulars of this specific case I think it is
> easy to conclude that it best to amend the specification.
> 
>     * The specification in question prescribes the format of
> some fields       of trace headers that most users will not
> see.
> 
>     * The specifications causes the format used in the trace
> header to       differ from the actual data exchanged on the
> wire.  These are the       client-to-server EHLO name and the
> server-to-client greeting name,       also repeated in the
> first line of the EHLO response.
> 
>       Because both are exchanged prior to negotiation of
> SMTPUTF8, they       always in A-label form.
> 
>     * The trace headers should match data recorded in system
> logs and       are mostly for the benefit of the postmaster.
> There's more value       in making them readable to any/all
> the postmasters along the       delivery path, than to those
> versed in the native tongue of the       message sender and
> ultimate recipients.
> 
>     * It is possible that the message headers are all ASCII,
> and the       only presence of UTF8 is in the envelope, which
> may get rewritted       or narrowed in transit.  By the time
> the message is delivered to       some mailboxes, the only
> non-ASCII content that might remain could       be the trace
> headers in question (if they follow the RFC).
> 
>       Given that not all IMAP clients, MUAs, ... support EAI,
> the       conservative thing to do (a la Postel) is to not
> needlessly       inject UTF8 content into the message headers.
> 
> Therefore, I find the specific RFC text to be misguided, and
> not only inessential to interoperability/utility, but actually
> working against both.  I am therefore inclined to ignore this
> part of the RFC with prejudice.  If there's an opportunity to
> revise (remove) the text, that'd be great.