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

[Alessandro Vesely <[e-mail]>]

On Wed 01/Apr/2020 20:14:49 +0200 Ned Freed wrote:
> 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.


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