headers
Charles Lindsey | 5 Mar 2004 15:24
Picon
Picon

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.
(Continue reading)

Permalink | Reply |
headers
ned.freed | 6 Mar 2004 00:27

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


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

You have this exactly backwards. References to informational RFCs are allowed
in standards track RFCs, modulo certain restrictions that have yet to be
formalized. (There is a draft out on this out there somewhere, I believe.) If
the informational status of a document is seen to be a problem, it is likely
that it can be changed with minimal effort.

Normative references to experimental protocols, however, are generally not
allowed. And moving an experimental document to the standards track is,
generally speaking, a more difficult proposition, as whatever issue that led it
to be classified as experimental has to be dealt with. And given what it has
historically taken to force a specification to experimental this can be a very
nontrivial proposition. (This has changed in more recent times - the
IESG has begun to use experimental status more than it used to.) 

				Ned
Permalink | Reply |
headers
John C Klensin | 5 Mar 2004 19:04

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
<chl <at> clerew.man.ac.uk> wrote:

> 
> Time this got commented on. The topic was essentially how to
(Continue reading)

Permalink | Reply |
headers
Charles Lindsey | 8 Mar 2004 12:18
Picon
Picon

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


In <41948119.1078491897 <at> [10.0.2.122]> John C Klensin <john-ietf <at> jck.com> writes:

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

Sure, the problem is easily fixed if we decide to follow the RFD 2442 route.

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

I don't see that using RFC 2442 as opposed to other methods of
encapsulation makes any difference here.

Suppose a message passes through servers A, B, C, D and E, where each is
determined to add, at the least, its own Received header. Suppose A and B
are upgraded to support UTF8-HEADERS, but C is not.

By the time B comes to deal with it, it will have acquired
    Received: by A
    Received: by B
(Continue reading)

Permalink | Reply |
headers
ned.freed | 5 Mar 2004 23:51

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


> 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

RFC 2442 is informational, not experimental. (I note in passing that one of the
author's names is misspelled in the RFC Index; I'll send in  a note about that
right away.)

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

Informational status was chosen because that was the status deemed appropriate
for media type specifications at that point in  time. The reason don't recall 
any concerns that this wasn't a good idea is simple: There weren't any.
I clearly recall the meeting where I presented this specification,  and
I also recall that there were no objections or concerns raised. (The
reason I remember this so clearly is that I was quite surprised to encounter
so little resistance to the idea.)

Things have changed, and now the belief is that these sorts of registrations
belong on the standards track. But it goes without saying that such changes
in belief don't retroactivaly change the status of existing documents.
(Continue reading)

Permalink | Reply |

Gmane