[Top] [All Lists]

Re: Objection to Last Call - draft-ietf-eai-utf8headers-09.txt

2008-03-19 01:07:38
Charles Lindsey wrote:

fixing the problem I shall describe would have repercussions in
     draft-ietf-eai-smtpext-11.txt [EAI-SMTP-extension] and in
     draft-ietf-eai-dsn-06.txt [EAI-dsn]
(especially the latter), it should be construed as a formal
objection to those as well.

[procedural nit]
IMO it is slightly beside the point to dispute the right to start
a "Last Call".  If it doesn't get out of hand ADs can "Last Call"
whatever and whenever they like.  Figuring out what the community
wants before stating what the consensus is is the purpose of this
exercise, a good reason for objections could be when the alleged
consensus is dubious.  

Of course the EAI drafts to varying degrees depend on each other,
but I'm confident that UTF8SMTP (the SMTP extension) makes sense,
therefore I posted a draft with a normative UTF8SMTP reference
yesterday, <>.

From my POV the DSN draft is also in excellent shape.  I'd like
it better to reference BCP 137, because the DSN draft ended up
with using an in theory problematic "unicode escape", but that's
perfectionism, at best an editorial nit.

my concern is that a new MIME subtype message/global is
defined, and that this new message subtype is in breach
of RFC2045, which currently has the status of Draft Standard.

I strongly support to introduce message/global, an EAI message
is *NOT* an ordinary US-ASCII message/rfc822, an EAI message
uses UTF-8 "as is" in its header.  Simplified message/global
vs. message/rfc822 is like IRI vs. URI, or IDNAbis vs. LDH, and
it is very important to have these differences clear.

Taking the message/global idea as given the details of its
definition are indeed fascinating.  I had a long chat with Ned
(the co-author of RFC 2045) some days ago on the SMTP list in
a thread about "I18N considerations" for the email-arch draft,
mostly we discussed message/global and the history of MIME,
see <>

Highly recommended for reading, I dare not summarize it here.

I have no problem with defining extensions to RFC 2822 and
even to RFC204[56] (e.g. to permit UTF-8 in places where
those current documents do not allow it).

I'd prefer to stay away from MIME, for the job at hand (EAI)
it is unnecessary to "embrace and extend" MIME version 1.0.
There are "only" two places in the EAI drafts where MIME is

1 - The use of a "nested" CTE B64 if all else fails to send
    DSNs to an EAI sender with a 7bit bit hop on the route.
2 - The use of UTF-8 in MIME version 1.0 part headers, this
    can require to parse the MIME structure of a message to
    figure out if it's a message/global or a message/rfc822,
    instead of only looking at the message header.

I'm concerned about (2), different from your concerns.  And I
considered (1) as negligible, maybe a 2045 erratum.  Nobody -
now also including Ned - liked my erratum idea, admittedly it
was formalistic, it would be "editorial", not "technical".

[...skipping your problem description...]

I might well agree that that restriction is unfortunate and
misguided, and even that it ought to be changed. But RFC2045
is a Draft Standard, and it is entirely outside the remit of
the EAI WG to attempt to change what is in a Draft Standard.

Oddly you don't have this problem with (1), and I don't have
it with (2).  For both issues I think they could be fixed in
MIME, and I don't insist on an erratum or 2045bis for (2), or
on a MIME versin 1.1 for (1).  And for you issue (= my 2) it
might be precisely the purpose of an "IETF experiment" to see
if it works out in practice.

I could say the same about (1), but I'd hate it if (1) turns
out to be critical and kills the EAI effort, because (1) is
not really necessary to experiment with "Email Address I18N".

Arguably (2) is also not really necessary, but Ned told me
that application/message ideas to solve this problem are old
and never made it, and without something in the direction of
application/message (2) is necessary.  Somehow those DSNs to
an EAI sender with 7bit hops on the return path must make it.

This should be a rare situation, what does an old 7bit relay
do on the return path to an UTF8SMTP sender, and accepting it
as given oddity all UTF8SMTP senders can be expected to know
how to "unpack" a B64 message/global part in a DSN.

Of course the security considerations need to be very clear.
B64 message/global is not designed for forward paths, it is
no ersatz-downgrading, it is a loophole for rare cases where
the alternative would be to drop DSNs.

Furthermore, if the interpretation of RFC2046 Section 5.2.4
suggested in [EAI-utf8header] is correct, it follows that
RFC2046 is inconsistent with RFC2045. Inconsistency between
two Draft Standards is a serious matter, but one which is
to be resolved by the IESG rather than by an individual WG
such as EAI.

For my purposes I "resolved" it in a discussion about I18N in
email-arch.  I didn't know that apparently technical details
in MIME were actually results of "political" decisions at the
time when 204[56] were published (1996, twelve years ago).


IETF mailing list