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

From: Ned Freed <[email-masked]>
Date: Mon, 31 May 2021 17:54:32 -0700 (PDT)

> >> But, and this is crucial, the human reading the trace
> >> information is rarely either the sender or the ultimate
> >> recipient of the message, who are generally presented with a
> >> subset of the headers fields ("To", "Cc", "Date", "Subject"
> >> ...).  Examination of trace headers is far more likely to a
> >> task for a mail system administrator.  They're used in abuse
> >> reports and the like, and a uniform representation is more
> >> important than familiarity to the community of readers of
> >> some given language.
> >
> > And what the admin usually wants to do is either a comparison
> > or check the domain with the DNS in some way. So an A-label
> > can be more convenient.
> >
> > And in the unlikely event an admin needs to translate the
> > A-label to a U-label, there are an abundance of tools that I
> > can use to do it.

> I may live in a different world, or at least with different
> users, than the two of you, but I quite often see users pointed
> to trace fields in order to make estimates of the validity of a
> message.

If we're talking about end users... Between the lack of user interest in
security, lack of expertise, and client authors making it increasingly difficult
to even access trace fields, it's been a very long time since I've done this.

Even if we're talking about our customers, there's really no interest in
performing these sorts of estimates any more.

To the extent Received: fields are relevant to our customers, it's to track down
the cause of some sort of problem, usually but not always some kind of delivery
delay. I find A-label better suited to this usage than U-labels.

> And that brings me close to the reasoning I think the
> WG used more generally: that it was better to stick to "native
> character" forms (in this case, U-labels), especially when there
> was a possibility of a full mailbox name with a UTF-8 local part
> and a domain part containing IDN labels.   That is obviously not
> the case for clauses of "Received:" fields other than "for",
> but, if the WG extrapolated from that principle to this
> particular case (and I don't remember how much detailed
> attention the particular case got.  The other argument for
> U-labels is that, precisely as Ned points out, if an admin needs
> to translate an A-label, there are many tools and admins are
> likely to know where to find them.  By contrast, if a user is
> presented with an A-label, the reaction is at least as likely to
> be "WT<rude word>" as "I have a tool handy that does that".

But in the bigger picture, every time you use a U-label or a UTF-8 local-part,
you make it more difficult to deal with the case when you hit a point where the
SMTPUTF8 extension isn't available.

We have two downgrading options defined, but neither of them is terribly
attractive.

What this argues for is to eliminate as much use of the extension as you
possibly can. And if that means using A-labels, or even dropping the use of
"for" clauses - which are optional anyhow - so be it.

> A different piece of the same story is that, if I had much more
> confidence that authors of MUAs and other mail access tools
> would think carefully about these subtle issues and get them
> right, I'd say that, given the dual relationship between
> A-labels and U-labels, it makes no difference which of the two
> are used on the wire -- it is all a presentation issue.  On the
> other hand, my experience of the last decade or so has given me
> no such confidence.

AFAIK MUAs haven't gotten into the business of trace field analysis. In fact
even the automated tools for this I've seen do little more than prettprint
header content. So I don't think this is particularly relevant.

> ...

> On the other hand, and here comes the question: There are
> proposals floating around that would define new header fields
> that would reflect, include, or depend on, different sorts of
> forward-pointing and reverse-pointing addresses.  Should we be
> taking the position that none of those should move forward
> unless they explicitly address what should be done when those
> fields are not traditional ASCII ones?

Very good point. EAI is a standards-track format/protocol. An unavoidable
consequence of this is that proposal that involves a new header field needs to
say how it interacts with EAI, even if it's only to say it doesn't interact at
all.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 1 Jun 2021 19:32:22 +0200

> delay. I find A-label better suited to this usage than U-labels.

Nowadays, Received: fields are often intermixed with Authentication-Results:, especially near the top of the header.  The latter provides U-Labels, AFAICS.  That way, both kinds of labels are available.  Here's a couple of examples:

By Courier-MTA:

By Google:

Authentication-Results: mx.google.com;
        dkim=pass header.i=@foà.it header.s=gamma header.b=BHORghd0;
        spf=pass (google.com: domain of [email-masked] designates 62.94.243.226 as permitted sender) smtp.mailfrom=[email-masked];
        dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=xn--fo-kia.it

Still, Section 3.7.3 of RFC 6531 doesn't seem to say that A-R's are trace fields...

>> On the other hand, and here comes the question: There are proposals
>> floating around that would define new header fields that would
>> reflect, include, or depend on, different sorts of forward-pointing
>> and reverse-pointing addresses.  Should we be taking the position
>> that none of those should move forward unless they explicitly
>> address what should be done when those fields are not traditional
>> ASCII ones?> 

If not specified, it looks like Section 3.6 of RFC 6532 supplies a default:

    encoded-words SHOULD NOT be used when generating header fields for
    messages employing this extension.  Agents MAY, when incorporating
    material from another message, convert encoded-word use to direct use
    of UTF-8.

Best
Ale
--

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Jun 2021 14:59:16 -0400

Ned,

I think we are mostly in agreement, especially about the current
crop of MUA clients not being very helpful in these areas and
the users not caring about security, having a very low level of
knowledge, and not seeing either as a problem.  A few comments
below (text on which I have nothing to add elided)

--On Monday, May 31, 2021 17:54 -0700 Ned Freed
<[email-masked]> wrote:

>...
> To the extent Received: fields are relevant to our customers,
> it's to track down the cause of some sort of problem, usually
> but not always some kind of delivery delay. I find A-label
> better suited to this usage than U-labels.

In case I've given any other impression, so do I.  But, like
you, I know what an A-label is, how to convert it back if
necessary, and so on.  The WG made the assumption that users
without that knowledge would be looking at that stuff.  If
today's reality, as we all seem to believe and have experienced,
is that the knowledge level and inclination to dig into these
issues of the typical user has, if anything, gone down
significantly since that assumption was made, then using
U-labels is optimizing for the very few users (percentage-wise)
who are inclined and able to dig into headers _and_ who don't
find dealing with A-labels convenient and don't know what to do
with them.

So, while I am profoundly sympathetic to a position I heard Doug
Englebart describe by an analogy to letting people drive cars
without any sort of training, it seems clear that war is over
and we lost... and, as one of many consequences, that the EAI
Wg's optimization decisions were probably wrong.

>> character" forms (in this case, U-labels), especially when
>> there was a possibility of a full mailbox name with a UTF-8
>> local part and a domain part containing IDN labels.   That is
>> obviously not the case for clauses of "Received:" fields
>> other than "for", but, if the WG extrapolated from that
>> principle to this particular case (and I don't remember how
>> much detailed attention the particular case got.  The other
>> argument for U-labels is that, precisely as Ned points out,
>> if an admin needs to translate an A-label, there are many
>> tools and admins are likely to know where to find them.  By
>> contrast, if a user is presented with an A-label, the
>> reaction is at least as likely to be "WT<rude word>" as "I
>> have a tool handy that does that".
> 
> But in the bigger picture, every time you use a U-label or a
> UTF-8 local-part, you make it more difficult to deal with the
> case when you hit a point where the SMTPUTF8 extension isn't
> available.

And that turns back into a comment I made earlier -- that the WG
made a number of decisions that ultimately assumed that SMTPUTF8
would deploy rapidly, perhaps even as rapidly as 8BITMIME did.
Obviously, at least to me, had the in-transit downgrading that
the EAI WG first tried to define been workable, we'd be having
fewer, or at least different, problems at this stage.  We might
have even been able to avoid the SMTP extension and done a
Punycode-like extension for messages in transit and hence their
MTA-supplied header fields.  But we concluded that we couldn't,
and so, as far as the protocol is concerned, hitting a point in
transit where the SMTPUTF8 extension is not available means
rejecting the message with all of the problems that implies.

> We have two downgrading options defined, but neither of them
> is terribly attractive.

And both are post-delivery options, more concerned with MUAs or
POP or IMAP servers accessing the message store.

> What this argues for is to eliminate as much use of the
> extension as you possibly can. And if that means using
> A-labels, or even dropping the use of "for" clauses - which
> are optional anyhow - so be it.

In the context of the comments above, no disagreement.  That
gets us back to the original question of whether it is worth
opening the SMTPUTF8 spec family of documents to review and
change those specifications and, if so, whether there is energy
to do so.  If the answer is "no" --and that is not only my
preference but what I think I am hearing -- then I'm not sure
how useful continuing this thread actually is.

> Very good point. EAI is a standards-track format/protocol. An
> unavoidable consequence of this is that proposal that involves
> a new header field needs to say how it interacts with EAI,
> even if it's only to say it doesn't interact at all.

Agreed.  I hope those of us who write and review documents, the
IESG, and the ISE are paying attention.

   best,
    john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Jun 2021 10:12:41 -0700

> "for" clauses - which are optional anyhow - so be it.

If I've read this thread correct, the main argument for the original 
SHOULD was convenient display to (end) users.  While that's a laudable 
goal, it's quite different from a typical protocol mandate to achieve 
interoperability.

Further, it appears that implementers have chosen to widely ignore the 
SHOULD, in favor of A-labels.  Again, this does not hurt 
interoperability, but makes reading by /some/ humans more challenging, 
though not impossible.  Even further, it appears that A-labels work well 
for some other readers.

My impression is that the SHOULD represented idealism over simple 
pragmatism.

The basic work was to extend an existing service to support a wider 
range of characters.  With some consistency, that kind of task fares 
much better with an overlay solution.  (Think MIME.)  A-labels are an 
overlay.  U-labels are not.

If the operational industry has voted with its code and clearly prefers 
A-labels, than the SHOULD is an especially counter-productive choice, 
since it creates debate about the specification where, really, it has no 
benefit.  I suspect MAY is the better choice.  It gives permission and 
even implicit encouragement, but eliminates the standards tension caused 
by not using U-labels.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Sam Varshavchik <[email-masked]>
Date: Fri, 04 Jun 2021 18:06:20 -0400

Dave Crocker writes:

> If the operational industry has voted with its code and clearly prefers A- 
> labels, than the SHOULD is an especially counter-productive choice, since it  
> creates debate about the specification where, really, it has no benefit.  I  
> suspect MAY is the better choice.  It gives permission and even implicit  
> encouragement, but eliminates the standards tension caused by not using U- 
> labels.

The current preference is for A-labels. But after SMTPUTF8 becomes  
customary: at some point it will make sense to interpret SHOULD using its  
original meaning, here.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Jun 2021 15:14:43 -0700

On 6/4/2021 3:06 PM, Sam Varshavchik wrote:
> customary: at some point it will make sense to interpret SHOULD using 
> its original meaning, here.

One of the consistent demonstrates of Internet Scale is that transition 
times are /really/ long.

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jun 2021 18:21:58 -0400

Dave (and others),

There are old sayings, at least when and where I was growing up,
about hindsight being almost perfect and far easier and more
accurate that looking ahead.  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?  I'd like to think so for some cases,
but there is no way that any of can be sure now.  Were these
issues and options, including what forms should appear in
"Received:" fields, considered by the WG?  As Jiankang has
indicated, yes.    Were they considered carefully enough, and
the tradeoffs analyzed adequately, given what we knew then?
Well, it seemed so at the time.

I can tell you a few things that I remember very clearly:

(1) The active participants in the WG included significantly
more people whose interest and expertise was in i18n matters
despite some knowledge of Internet email than people with a
really strong background in Internet email and some background
in the i18n issues.  That made me, as WG co-chair,
uncomfortable.  I assume it made my co-chair Joseph and our
predecessors Harald and Xiaodong uncomfortable too but don't
ever remember discussing it with them.  Could we do anything
about it?  No.  I have often wished that, when a WG was
proposed, we could explicitly identify the expertise and balance
of perspectives needed, write it into the charter, decline to
start the WG is those conditions could not be met and shut it
down immediately if they were never met.  Profoundly unrealistic
and I'd probably also like a pony, but an idea that, if we are
going to talk about informed consensus, has some theoretical
appeal.  

(2) No one in the WG and no one during IETF Last Call raised the
question of whether the choice of U-labels in "Received:" fields
was appropriate.  If what became RFC 6531 were under active
consideration today and that issue were raised with the
conclusions or arguments you and others are reaching now, I
think that appropriate WG response (and certainly the response
from the co-chairs) would have been "even though we would have
preferred it earlier, good catch and that was probably not
discussed sufficient".   But it is not in that state.  Instead,
it is a Proposed Standard published more than eleven years ago
and the issue is coming up only now.  Isn't hindsight great?

(3) By contrast, the idea of using an overlay or special
encoding as you suggest was extensively discussed in the WG
(long before I became co-chair).  That discussion was, for
better or worse, dominated by questions of what to do about the
local part in mailbox names.  While it was obvious how to encode
IDN labels using something like Base64 and later, once the
problems with that were understood, Punycode encoding, it was
critical to that idea that RFC 1034 specified a very restrictive
syntax while allowing almost any octet string of reasonable
length as a label and that we could scan a significant portion
of the DNS to find out what was actually being used.  For
mailbox local parts, we had the related problems of (i) email
addresses being used to convey all sorts of strange information
including system commands and instruction sequences, hashes as
part of addresses, and a wide variety of indicators about what
was going on and (ii) the combination of extremely permissive
syntax rules (dating, you will recall, to before RFCs 822 and
821).   The WG concluded that the only possibilities were to
make a semi-arbitrary choice of encoding indicators and accept
the notion that any existing addresses that were broken in the
process were just causalities of progress and to give up on
encoding.  It also concluded, for reasons entirely consistent
with ones you have made in the past even more forcefully than I
have, that the "some breakage is ok" option was unacceptable.
I don't think we would change that even in hindsight.  

The conclusion was then to specify U-labels in addresses and
even isolated domain names with the one exception of the initial
"220" greeting and the EHLO command, neither of which could use
non-ASCII forms because the extension had not been negotiated
yet.  Should that have been parsed out more carefully on a
case-by-case basis?  Maybe.  Isn't hindsight fun?  And isn't
second-guessing even more so?

(4) One of the consequences of the composition and focus of the
EAI WG is that many of those who actively participated,
including some document authors and probably past co-chairs, are
not represented on this list.   Whatever else we do, I think it
would be unfair and improper for us to make decisions without
reaching out to those people and giving them an opportunity to
be involved.  In particular, it is possible that their view of
some of the tradeoffs might be different from that of most of
the people on this (more email-oriented) list.

Finally, let me say again, more strongly, that discussions here,
perhaps especially those that involve second-guessing or
applying hindsight to decisions made more than a decade ago, are
not getting us anywhere.  Suggestions about whether a sentence
written before 2005 should have said "SHOULD" or "MAY" appear to
be even less useful.  If someone wants to propose a WG to reopen
old questions and revise the SMTPFUT8 specs, by all means go for
it but please try to be sure that the perspectives that were
represented in the EAI WG are represented again.  Or, if someone
wants to propose taking some or all of the SMTPUTF8 specs to
Internet Standard, please do the needed reports and get that
process started: we could certainly reduce a SHOULD to a MAY
and/or add supplemental text as part of that process.

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

best,
    john

--On Friday, June 4, 2021 10:12 -0700 Dave Crocker
<[email-masked]> wrote:

> If I've read this thread correct, the main argument for the
> original SHOULD was convenient display to (end) users.  While
> that's a laudable goal, it's quite different from a typical
> protocol mandate to achieve interoperability.
> 
> Further, it appears that implementers have chosen to widely
> ignore the SHOULD, in favor of A-labels.  Again, this does not
> hurt interoperability, but makes reading by /some/ humans more
> challenging, though not impossible.  Even further, it appears
> that A-labels work well for some other readers.
> 
> My impression is that the SHOULD represented idealism over
> simple pragmatism.
> 
> The basic work was to extend an existing service to support a
> wider range of characters.  With some consistency, that kind
> of task fares much better with an overlay solution.  (Think
> MIME.)  A-labels are an overlay.  U-labels are not.
> 
> If the operational industry has voted with its code and
> clearly prefers A-labels, than the SHOULD is an especially
> counter-productive choice, since it creates debate about the
> specification where, really, it has no benefit.  I suspect MAY
> is the better choice.  It gives permission and even implicit
> encouragement, but eliminates the standards tension caused by
> not using U-labels.
> 
> d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jun 2021 18:45:13 -0400

--On Friday, June 4, 2021 15:14 -0700 Dave Crocker
<[email-masked]> wrote:

>> The current preference is for A-labels. But after SMTPUTF8
>> becomes  customary: at some point it will make sense to
>> interpret SHOULD using  its original meaning, here.
> 
> One of the consistent demonstrates of Internet Scale is that
> transition times are /really/ long.

But that was another very explicit decision of the WG: to focus
on when, as Sam puts it, SMTPUTF8 becomes customary and then try
to accelerate the rate of adoption.  That was, in particular,
rather than trying to invent horrible kludges that we would then
want to transition away from, facing exactly the problem you
identify, a problem that normally gets even worse when those
kludges that "everyone" has adopted mostly work.  

If one views the desire to get a fast transition from a really
extreme direction (and I'm trying to summarize some of the
perspective of WG participants, not advocate for it), then "what
happens when a message gets partway across the Internet and then
hits a system that does not support the extension?" is very
nearly a feature, as in "let the users complain until the
relevant system is upgraded" and/or "encourage destination
system that do not support the extension to avoid advertising MX
intermediaries until the whole chain is upgraded".  

And, again, if we conclude that expectation was either
unrealistic or just a bad idea, well hindsight is great, isn't
it?

One other decision we didn't make is worth remembering.  That
decision would have been to keep mailbox names in ASCII (using
U-labels in the domain part if needed but following 2891/5321
and 2892/5322 strictly wrt the local part).  No changes to trace
fields, no complications with header-signing protocols, etc.
Instead, we would just put more emphasis on name phrases in
header fields, using encoded words if needed, and _maybe_
creating a small SMTP extension to allow carrying those phrases
into the envelope as parameters to MAIL and RCPT.  That was,
perhaps for good reason, completely unacceptable to those who
thought they needed non-ASCII local parts and probably
unacceptable to everyone in the relevant countries who like
using email addresses as identifiers.  But, if we wanted to
concentrate on easy and smooth extensibility and ignore those
use needs, a good exercise in second-guessing the WG's decision
might yield that sort of result.  And, btw, while we were at it,
we could decide to second-guess all of those email address as
personal identifier ideas.  :-(

best,
  john

with reference to my prior note

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Jun 2021 16:14:43 -0700

On 6/4/2021 3:21 PM, John C Klensin wrote:
> Would the EAI WG have made
> 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.

> 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 not?

d/

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Jun 2021 03:21:04 -0400

--On Friday, June 4, 2021 16:14 -0700 Dave Crocker
<[email-masked]> wrote:

>> 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.
> 
> 
> The current concern I saw is with field experience
> demonstrating that SHOULD is out of sync, with the obvious
> suggestion that it be changed.
> 

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.

   john

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 5 Jun 2021 09:21:08 -0700

> worth the trouble and (ii) whether there is the energy to do

Oh?  On re-reading your previous two postings, I'm still not finding 
those questions.

At any rate, it appears that you are suggesting expanding the proposed, 
very simple, very narrow, very pragmatic and entirely experience-based 
proposal into a larger and more generic activity.

While the latter might be worth considering, there is nothing about the 
current issue that requires coupling it to the larger task.

> the IETF for that kind of work.

Seems like a good reason for a) decoupling the larger task from the 
immediate, narrower one, and b) deferring the larger task until more 
immediate concerns are addressed.

> period (however long that lasts). 

Your 'if' is problematic.  You are invoking a desirable but indefinite 
-- and, based on history, a discouraging -- future state as a reason to 
refrain from making a simple, practical change, responding to 
established reality.

  Simply saying "everyone who
> actually not a sufficient reason to change the spec.

Oh? Really?  Why is that?

>  And I
> not appear to be represented on this list. 

The IETF has established practice of making decisions based on those who 
show up.  It's not as if this is a hidden activity.

d/

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2021 12:55:55 -0400

>worth the trouble and (ii) whether there is the energy to do

At this point, tne answer is clearly no.  I was asking as part of
the EAI testing I'm doing for the UASG, to figure out how hard I
should try to persuade people to fix their code to pass that particular
test.  (Not very, since they all say no anyway.)

FWIW, Gmail and Hotmail/Live/Office365 which I believe are the 
largest EAI-enabled mail systems in the world, also have A labels.
Of course, when I looked at a test message I sent to my Hotmail
account, I found this gem, so A-labels are hardly their biggest issue.
Check out those "with" and "via" clauses:

I have found pretty good support for exhanging mail with EAI addresses.  Those
two hosted mail systems do so and most open source MTAs have adequate EAI support,
Postfic, Exim, Courier, and now even sendmail (in beta, but it works.)

What I have not found is a lot of support for hosting their own EAI
addresses. You can do it in the open source stuff, but nobody does.
It's fairly painful to do so for a variety of reasons. On most systems
foo@<A-label> and foo@<U-label> are not mapped together so you have to
make two addresses for everyone, and MUA support is spotty at best.
Ned has described some of the reasons that even though Oracle's MTA
has code to support local EAI addresses, nobody uses it.

I have found almost no support at all for EAI in POP and IMAP. The
only open source is Courier IMAP, and the commercial ones with EAI
extensions I've tried are really buggy, to the point of repeatedly
requiring that I patch the python IMAP library to keep it from
crashing during the tests. IMAP already has overcomplex but usable
support for multiple character sets in folder names and search terms,
and I have found that more often than not non-EAI IMAP servers such as
Dovecot work adequately with EAI mail sort of by accident because they
don't try to enforce 7-bit ASCII in their 8-bit data.

So anyway, I expect that EAI and ASCII mail will coexist for a long time even
though there is no downgrade path to smooth the way.  The A-labels are just
a symptom of that.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Jun 2021 14:14:28 -0400

--On Saturday, June 5, 2021 09:21 -0700 Dave Crocker
<[email-masked]> wrote:

> At any rate, it appears that you are suggesting expanding the
> proposed, very simple, very narrow, very pragmatic and
> entirely experience-based proposal into a larger and more
> generic activity.
> 
> While the latter might be worth considering, there is nothing
> about the current issue that requires coupling it to the
> larger task.

Except that 

(1) Your "very simple, very narrow, very pragmatic, and entirely
experience-based proposal" may also be very wrong.  I don't
personally think it is, but I believe that deciding to make that
change by, e.g., the discussions on this list in the last few
days, would be inappropriate because it gives little or no voice
to those who have the strongest interest in in a fully
internationalized email system.    And no matter how often you
insist that your proposal is a very simple and pragmatic change
--presumably with no side effects--  will alter that exclusion
and the possibility those people identifying long-term side
effects we have not identified.

(2) At the risk of being even more pragmatic about your "very
pragmatic" proposal, I know of no way to make an authoritative
change in a standards track RFC -- whether one word or a few
paragraphs -- without generating an I-D, having it discussed in
the community, going through IETF Last Call, and publishing a
new RFC.    That is not a lightweight process even if the change
is "very simple and very narrow".  It seems to me that asking
the question of whether, given limited resources and energy and
other priorities, it is worth doing... and reaching a tentative
"no" conclusion.  John Levine's recent note suggests to me that
this issue is not a big problem and that, if we are inclined to
put more energy into the SMTPUTF8 collection, those resources
are better spent elsewhere.

    john

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Jun 2021 18:56:58 +0200

On Sat 05/Jun/2021 20:14:28 +0200 John C Klensin wrote:
> new RFC.

How about an erratum?

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Jun 2021 10:00:19 -0700

>> the community, going through IETF Last Call, and publishing a

Unfortunately, the administrative rule on RFC errata is that they are 
limited to corrections where what is written does not match what was 
intended.  That is, documentation errors, rather than -- such as here -- 
revised goals.

But, yeah.  The way to address a modest change is with a modest effort.

d/

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Jun 2021 13:22:24 -0400

--On Sunday, June 6, 2021 10:00 -0700 Dave Crocker
<[email-masked]> wrote:

>>> pragmatic" proposal, I know of no way to make an
>>> authoritative change in a standards track RFC -- whether one
>>> word or a few paragraphs -- without generating an I-D,
>>> having it discussed in the community, going through IETF
>>> Last Call, and publishing a new RFC.
>> 
>> How about an erratum?
> 
> Unfortunately, the administrative rule on RFC errata is that
> they are limited to corrections where what is written does not
> match what was intended.  That is, documentation errors,
> rather than -- such as here -- revised goals.

Agreed.  In addition to Dave's point and going beyond
"administrative rule", the problem is that there is not even a
pretense that errata represent IETF consensus.   So, even if the
WG messed up and the goals need revision, errata don't work
except in one very narrow way.   That would be to submit this as
an erratum and then try to get the powers-that-be to identify it
as "hold for document update" rather than rejecting it outright.
That would provide a very clear signpost that any future
revision of the SMTPUTF8 specifications should (SHOULD?) either
consider the issue or be prepared to explain why not.

> But, yeah.  The way to address a modest change is with a

And I await a description --other than the errata signpost idea
mentioned above-- as to how to make a change in this area with a
modest effort, presumably one about which IETF consensus can be
asserted but that does not require an I-D, notification of (and
discussion including) as many of those who participated in the
EAI effort as were still interested, IETF Last Call, etc.

A different way of saying the same thing is that, if this change
is not important enough to establish IETF consensus about making
it, it is not a "modest change" but a change that is not worth
the trouble at this point.

    john

---

From: "John Levine" <[email-masked]>
Date: 6 Jun 2021 14:56:55 -0400

>EAI effort as were still interested, IETF Last Call, etc.

One of the things on my long list as sort-of-RFC-editor is a way to do
incremental updates to RFCs, likely with version numbers, so we only have
to reapprove the sections that have changed.

I still don't think it's worth opening up RFC 6531 unless we have a lot more to change.

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sun, 06 Jun 2021 15:43:19 -0400

> > the community, going through IETF Last Call, and publishing a

This smells more like a BCP.  But I'm not sure one thing like that qualifies for
a BCP by itself, and I'm not seeing the energy needed for a wider-reaching BCP.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Jun 2021 02:44:29 -0400

> I still don't think it's worth opening up RFC 6531 unless we have a

I can continue to ignore the suggested use of U-labels in trace headers
without a document revision, and without any consequente
interoperability downsides.  So there's not much impetus for change
there.

If we're really looking for surgery patient, that'd be RFC6532, in which
message/global is a major design blunder.  It blatantly breaks a key
feature of the design of MIME, in which for good reason composite parts
did not get non-identity transfer encodings.

It is perhaps still not too late (given low adoption) to fix the
blunder, by deprecating message/global.  Bounces of EAI messages can
either optimistically include UTF-8 characters in the headers of nested
messages, or conservatively bounce just a "text/rfc822-headers" portion,
which being non-composite can be transfer-encoded:

    https://datatracker.ietf.org/doc/html/rfc3462#section-2

bouncing just the headers is a good idea anyway, since it reduces
the odds of the bounces getting lost in transit for being overly
large, or triggering false positives in filters, ...

-- 
    Viktor.