Comments on draft-klensin-email-i18n-message-00.txt

Time this got commented on. The topic was essentially how to encapsulate a
message with UTF-8 in its headers so that it could be tunneled through
present transport channels and be reconstituted at the far end.

Jon proposes two encapsulations:

J1. Message Encapsulation

I would like to divide this into two cases:

J1a. Using message/rfc822

Suppose message/rfc822 is extended in the obvious way to allow headers in
the message to be in UTF-8 (and also, if the message is a part of a
multipart, the body part headers, such as Content-Type/Disposition, too).

That is still not good enough because the rules for
Content-Transfer-Encoding only allow for the body-part of the
message/rfc822 to be encoded (in QP or Base64). So those UTF-8 headers
would still be at the mercy of the transport medium.

But help is at hand, assuming that the transport supports 8BITMIME.
Officially speaking, 8BITMIME is not obliged to support 8bit characters
except in the body part of that message/rfc822 (because that is the only
place where you are allowed to say C-T-E: 8bit). But in practice, because
transports never look inside the body of messages, any transport
supporting 8BITMIME would certainly convey those headers correctly
(because it would actually require extra work on the part of the
implementor to make it not work). So it is a pretty safe bet.

J1b. Using application/news-transmission

This type is already registered with IANA and, although desgined for News,
it should work perfectly well for Email. Essentially, it just bundles the
whole message/article up into a bunch of bytes (headers and all) and sends
it as the body of the message with whatever CTE you choose.

Note however, that neither of those methods gives any help for UTF-8 in
the envelope (and specifically in the RCPT TO).


J2. Mail Transaction Encapsulation

This encapsulates a complete ESMTP transaction, including both envelope
and bodies, and sends it as an application/batch-SMTP, as described in RFC
2442. I would regard this as a better solution than J1[ab], because it
deals with the envelope, and the details given in RFC 2442 seem just fine.

The only snag is that RFC 2442 is an Informational RFC, and hence could
not be referenced in a Standards-Track document (though it might be OK in
an Experimental RFC). That problem does not look insurmountable.

-- 
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: [email protected]      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