Subject: [EAI] [Technical Errata Reported] RFC6532 (6036)

From: RFC Errata System <[email-masked]>
Date: Wed, 1 Apr 2020 01:37:56 -0700 (PDT)

The following errata report has been submitted for RFC6532,
"Internationalized Email Headers".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6036

--------------------------------------
Type: Technical
Reported by: Alessandro Vesely <[email-masked]>

Section: GLOBAL

Original Text
-------------
A section 3.2bis, "Syntax Extensions to RFC 2045", is missing.

Corrected Text
--------------
In particular, Section 5.1 of RFC 2045, "Syntax of the Content-Type Header Field", deserves an extension:

    token /= UTF8-non-ascii

similar to the extensions given to various text types given in Section 3.2.

Notes
-----
Various header fields are defined in terms of the grammar defined in RFC 2045.  In particular, the missing extension of token was reported for Authentication-Results:
https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenEuwD48nwptzU

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6532 (draft-ietf-eai-rfc5335bis-13)
--------------------------------------
Title               : Internationalized Email Headers
Publication Date    : February 2012
Author(s)           : A. Yang, S. Steele, N. Freed
Category            : PROPOSED STANDARD
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2020 12:34:50 -0400

This erratum is wrong.  The MIME definition of "token" is fine.

In RFC 8601 we misused "token" in the Authenticated-Results header for
what really is a domain name.  That's what needs to be fixed, and we're
discussing what the least bad fix is.

R's,
John

In article <[email-masked]> you write:
>Various header fields are defined in terms of the grammar defined in RFC 2045.  In particular, the missing extension of
>token was reported for Authentication-Results:

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Apr 2020 13:04:47 -0400

My vague recollection is that this was an explicit decision by
the WG.   Essentially, just as the WG concluded that header
field names should remain restricted to ASCII, the conclusion
was that Content-type fields were protocol parameters, not
information for the user, and that there was no need (and
potentially some cost and risks) to allow non-ASCII characters
or free text more generally.  One could revisit that question,
but I believe that the appropriate way to do it would be to
generate an Internet draft that explained the issues and
tradeoffs and proposed a change -- not just to RFC 6532 but to
the IANA registries related to Content-type parameter values.

In any event not something that is possible as a erratum because
the change would change the technical requirements for an
SMTPUTF8 implementation.

best,
  john

--On Wednesday, April 1, 2020 01:37 -0700 RFC Errata System
<[email-masked]> wrote:

> In particular, Section 5.1 of RFC 2045, "Syntax of the
> Content-Type Header Field", deserves an extension:
> 
>     token /= UTF8-non-ascii
> 
> Various header fields are defined in terms of the grammar
> defined in RFC 2045.  In particular, the missing extension of
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be
> verified or rejected. When a decision is reached, the
> verifying party   can log in to change the status and edit the
> report, if necessary. 
>

---

From: "John R. Levine" <[email-masked]>
Date: 1 Apr 2020 13:24:49 -0400

I would suggest rejecting this erratum.  The motivation is that "token" is 
imported into RFC 8601 where we have found some unfortunate results, but 
the solution is to fix 8601, which we're working on.

R's,
John

>> "Internationalized Email Headers".

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Apr 2020 12:37:01 -0500

Please note that none of the ART ADs on this thread (and errata report) are current.

> On Apr 1, 2020, at 12:24 PM, John R. Levine <[email-masked]> wrote:
> 
> I would suggest rejecting this erratum.  The motivation is that "token" is imported into RFC 8601 where we have found some unfortunate results, but the solution is to fix 8601, which we're working on.
> 
> R's,
> John
>

---

From: [email-masked]
Date: Wed, 01 Apr 2020 11:11:52 -0700 (PDT)

Agreed. This should be rejected.

				Ned

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: [email-masked]
Date: Wed, 01 Apr 2020 11:14:49 -0700 (PDT)

Your recollection is correct and so is your point about this being
a fundamental change to SMTPUTF8. There was a strong consensus that
parameter names didn't need to be internationalized.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Apr 2020 14:28:05 -0400

John and I are in agreement that this should be rejected (in
case it wasn't clear, I favor rejecting it too).  Since neither
8601 nor its predecessors (7601, 7410, 7001, 5451, and 6577)
update 6532 or the base MIME Content-type definition), I would
assume that any change along these lines to 6532 would require
an explicit update to (or replacement of) that document and
Standards Action on that change.  That is true whether the
motivation for the change comes out of the Authentication Status
work (and Authentication-Results header field) helped motivate
the request or not and whether the definitions associated with
the field are stable yet.  

I'm pushing back on John's justification/explanation only
because this proposed change to 6532 should not come back as an
erratum (updated or new) after 8601 is replaced or otherwise
fixed.  Let's reject it because it proposes the type of change
to 6532 that is improper for an erratum.  If the author of the
erratum believes that the suggested change to 6532 is needed,
let's see the Internet-Draft and appropriate explanation,
ideally coordinated with whatever fixes are being made to 8601.
I welcome any additional explanation as to why this should be
rejected that relevant present or past ADs or the IESG would
like to add, preferably including John's, but strongly prefer
that the core reason for the rejection be about 6532 itself.

best,
  john

--On Wednesday, April 1, 2020 13:24 -0400 "John R. Levine"
<[email-masked]> wrote:

> I would suggest rejecting this erratum.  The motivation is
> that "token" is imported into RFC 8601 where we have found
> some unfortunate results, but the solution is to fix 8601,
> which we're working on.
> 
> R's,
> John
> 
>> In any event not something that is possible as a erratum
>> because the change would change the technical requirements
>> for an SMTPUTF8 implementation.
>> 
>> best,
>>  john
>> 
>> 
>>> https://mailarchive.ietf.org/arch/msg/dmarc/g1U__axJW5I6OenE
>>> uw D48nwptzU
>>> 
>>> Instructions:
>>> -------------
>>> verifying party   can log in to change the status and edit
>>> the report, if necessary.
>>>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 2 Apr 2020 10:51:31 +0200

> parameter names didn't need to be internationalized.

I didn't realize that that would change the requirements for SMTPUTF8, since
actual Content-Type header fields need a registration or some kind of agreement
among the parties using X-whatever tokens.

RFC 5322's word term is defined quite alike, as word = atom / quoted-string.
However, atom is defined in terms of atext, which is extended by RFC 6532.  I
hope you will excuse me for not having realized that an internationalized
Content-Type: would have changed SMTPUTF8 requirements, given that non-ASCII
Received: fields are already possible.

Anyway, I don't know how many specs imported "value" from RFC2045.  For RFC
8601, the most backward compatible fix is perhaps to import token instead of
value, extend token by /= UTF8-non-ascii, and then define value using the
extended token:

value := token / quoted-string

Oh well...  if this erratum is rejected, the one needed for RFC 8601 will most
likely be more complicated  than this.  So I think the attempt has been worth
trying.  Thank you everyone for your time.

Best
Ale
--

---

From: "John R. Levine" <[email-masked]>
Date: 2 Apr 2020 10:41:09 -0400

> Anyway, I don't know how many specs imported "value" from RFC2045.

The ones I know immediately are a lot of MIME updates and RFC 5536 about 
the netnews article format.  This is not a spec to change casually.

Regards,