ietf
[Top] [All Lists]

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

2008-03-24 05:44:23
On Wed, 19 Mar 2008 09:32:42 +0100
    Frank Ellerman <nobody at xyzzy.claranet.de> said:

Apologies, I confused (1) and (2):
  
 [...]
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.

Unfortunately, the threading on the ietf(_at_)ietf(_dot_)org archive had got all
screwed up, and you were not replying to the message you thought you were
replying to.  Indeed the message you were replying to is listed in the
archive as [no subject] and has no headers. So I have recovered it and
quoted it in full below so that I may answer it. I have copied the
References header from your last message, so this should now get threaded
somewhere in the right place, but since none of the MUAs available to me
allow manual tinkering with References (and, worse, the ietf archives
don't show Message-ID headers at all), I am constructing this message by
hand and will have to send it using sendmail -t :-( .

Anyway, here goes.

Sometime on Mar 19th, (archived as [no subject])
    Frank Ellerman <nobody at xyzzy.claranet.de> said:

Charles Lindsey wrote:

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.

I might not have had any problem with message/global if it had only been
intended to be seen inside the "global sandbox". But, unfortunately it is
expected to be passed around _outside_ that sandbox, on the presently
deployed network and, in spite of some wishful thinking on the EAI WG,
that just will not work (as I showed).

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 <http://thread.gmane.org/gmane.ietf.smtp/6678/focus=6697>

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

I have read that thread, and it is clear that Ned would take a very dim
view of disobeying that "EXPRESSLY FORBIDDEN", especially any attempt to
do so on the existing network. It may, with hindsight, have been the wrong
decision, but it is there and that is what lots of agents have
implemented. Moreover, as I showed at the start of this thread, even RFC
2046 does not permit what EAI is trying to do (yes, there is a sentence
about treating unknown stuff as application/octet-stream, but the very
next sentence following that makes it clear that does not extend to using
Q-P or Base64 as a CTE).

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

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.

Folks should note this is where Frank confused (1) and (2). I have
annotated his remarks with what he meant to say, inside [..].

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[2]), and I don't have
it with (2[1]).  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[2]).  And for you issue (= my 2[1]) it
might be precisely the purpose of an "IETF experiment" to see
if it works out in practice.

It doesn't need any experiment. It is already known that 3 widely used
MTAs will not cope with it, and I am only aware of one (not so widely
used) that will. As I said above, no problem if (1) happens inside the
global sandbox, but it is explicitly intended to work outside it.

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

But EAI is trying to do far more than fix "Email Address I18N".

Arguably (2[1]) 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[1]) is necessary.  Somehow those DSNs to
an EAI sender with 7bit hops on the return path must make it.

There are two ways to fix (1). Either an application/message, or else
insist the message/global is downgraded before letting it loose on the
current network (in which case you might as well continue to call it (an
extended) message/rfc822.

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.

It may well be rare, but the IETF places great store on not breaking
existing implementations, however ancient. You and I might agree that is
an unnecessary straightjacket, but there it is :-( .

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.

But that is NOT what the utf8headers draft says.

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_)7)
the
time when 204[56] were published (1996, twelve years ago).

No, you didn't resolve it. What I think we really need is for Ned to join
this discussion and to read my objection. I believe he will uphold my
position but, if not, then I might be prepared to shut up. Cc to Ned.

Frank



-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, 
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf