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

Charles,

To comment on one point, my assumption has been that, if we
decide that the transaction encapsulation is useful and
appropriate, we would just go to the effort to either move RFC
2442 to Proposed along with it, or would obsolete or update 2442
and incorporate its key features into a revision of this draft.
There are interoperable implementations of 2442. My
retrospective guess as to why it was made Experimental (I don't
remember) is that the community wasn't convinced it was
necessary and a good idea.  If we need it for this purpose, the
question of necessity and desirability are immediately answered.

The other difficulty with using either 8BitMIME and an 8bit
C-T-E or news encoding is the issue that Keith has raised
repeatedly in other contexts: all sorts of trash gets inserted
into headers, especially trace files, by all sorts of actors.
While the type of brute-force, "take whatever is there and
encapsulate it" approach of this draft won't solve that problem,
it runs a much lower risk of making things worse than assuming
that some stray 8bit characters are really UTF-8.

    john


--On Friday, March 05, 2004 14:24 +0000 Charles Lindsey
<[email protected]> wrote:

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