Re: Fwd: I-D ACTION:draft-hoffman-utf8headers-00.txt

John C Klensin <[email protected]> wrote:

> While this idea is an interesting one in principle, the
> particular proposal you make would break a very large fraction
> of the RFC822/2822 parsers in the world, which assume 
>    Header = *C ":"
> where "C" is an instance of a permitted character.

Either I don't understand your objection, or I didn't make my proposal
clear enough.

The previous UTF-8-headers proposals have been redefining the syntax
of existing fields (like From:, Subject:, etc.) to allow UTF-8.  I am
suggesting creating a new field, 8: (which may appear multiple times),
and allowing UTF-8 only inside 8:, and leaving existing field syntax
unchanged.  Existing software, which does not recognize 8:, will not try
to interpret it (unrecognized fields are ignored).  New software that
recognizes 8: will know that the first thing inside the contents of an
8: field is a sub-field-name, with the same semantics as a top-level
field name, but with slightly different syntax beyond that (UTF-8 is
allowed).

The intention of this proposal is to make breakage less likely than it
would be if UTF-8 were used directly inside today's standard fields
(From:, To:, etc.).

We can't expect existing parsers to understand non-ASCII fields, so
the best we can do is try to hide the non-ASCII fields from them.  An
SMTP extension keyword is one line of defense, but Charles Lindsey was
concerned that it wouldn't be enough.  This new 8: field would serve as
a second line of defense and as a convenient flag.

AMC