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

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

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"
<[e-mail]> 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
> 
> On Wed, 1 Apr 2020, John C Klensin wrote:
> 
>> 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
>> <[e-mail]> wrote:
>> 
>>> 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 <[e-mail]>
>>> 
>>> 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__axJW5I6OenE
>>> uw D48nwptzU
>>> 
>>> 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
>> 
>> 
>> 
> 
> Regards,
> John Levine, [e-mail], Primary Perpetrator of "The
> Internet for Dummies",
> Please consider the environment before reading this e-mail.
> https://jl.ly