Re: [EAI] UTF-8 in Message-IDs

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

--On Wednesday, August 17, 2011 15:36 -0700 Chris Newman
<[e-mail]> wrote:

>...
>   The Message-ID SHOULD include at least one UTF-8 character.
> 
> By including a UTF-8 character, any gateway to a non-EAI
> system will have to replace the Message-ID with a new one,
> thus correctly indicating that the resulting downgraded
> message is a subsequent revision. Systems wishing to identify
> the original EAI message id for a damaged downgraded message
> can look at the Downgraded-Message-ID header.

Chris, while I agree with your analysis of "subsequent
revision", I don't get from their to your conclusion for two
reasons:

(1) Other than in the POP/IMAP downgrade path, there is no such
thing as a Downgraded-Message-ID header.   One can imagine a
number of scenarios that would involve a need to send a message
back out in ASCII-only form that do not involve that header or
any downgrading we are going to specify.  Note especially that
the user generating a reply may have sufficient out of band
information available to supply deliverable addresses for some
or all of the author, sender and recipients of the message as
appropriate.

(2) Per one of my examples of some days ago, if we allow UTF-8
in Message-IDs at all, it is quite possible to have a message
that requires UTF8SMTPbis extension handling but that contains
no non-ASCII data in either header fields or addresses other
than that UTF-8 Message-ID.  Indeed, one interpretation of the
statement you suggest above virtually guarantees a lot of
messages of that type (probably it can be rewritten to reduce
the number, but that doesn't change things much).  Now we have
an interesting problem: the message is reply-able (and, more
important, forward-able without creating a message/global body
part) and new recipients with all-ASCII addresses can be added.
Certainly in the forwarding case, there is no "subsequent
revision".   It can be handled strictly as a legacy message
except for that pesky Message-ID.  And, again, except for
replacing or otherwise dealing with the Message-ID, there is no
need to downgrade anything.

As I've said before, I don't think those scenarios (including
Frank's) are adequate to make a case for a protocol restriction
to ASCII.  I think they are sufficient to justify a
recommendation that systems sending mail into environments they
consider fragile should confine themselves to ASCII message
ID's.  Requiring non-ASCII characters in Message-IDs would not
only defeat that recommendation, it would run counter to the
core of the "if we tell them ASCII-only, they will ignore us"
observation that Ned, I, and others have been making.  

To review that observation (at least my version), MUAs have ways
to construct Message-IDs, usually by cramming some local
information and a domain name together.  For all sorts of
reasons, they are likely to continue doing whatever they are
doing, using a domain name with U-labels in it if they consider
such a domain name primary.  If we ask them to do anything else,
it is going to create a requirement for extra code and extra
work -- whether that be converting the domain name to use
U-labels or to artificially add a non-ASCII character because
some other header field contains at least one non-ASCII
character.  We can provide them very little motivation for doing
that other than the WG's exploration of transition cases and
edge cases.  Experience indicates that extra work, especially
extra work that creates additional code paths, with no even
slightly compelling motivation, translates into an unimplemented
requirement.

(personal opinion only)
    john