In each case, you can use double
quotes to encapsulate virtually anything that doesn't include double
quotes, and you can use the \22 hex code notation for embedded double
quotes.
OK, maybe there isn't really a problem, but I am a little bit
concerned about the description in the draft. Since the stuff about
quoting with <"> is already in RFC822, maybe we can just include a
pointer to RFC822, so that implementors will know what to watch out
for. Blindly applying the Quoted-Printable conversion *can* lead to
problems, e.g.:
From: foo(_at_)blurfl(_dot_)co(_dot_)jp (Foo B&)r)
Note the &), which is a legal Quoted-Printable encoding.
All I'm asking for is a clear RFC, to avoid pitfalls.
The problem with the "Header-type" solution is that you might have
multiple header fields in this boat, using different character sets, and
how do you associate the right "Header-type" with the right other header
field?
Well, one obvious way to solve this problem is to use ISO 2022, which
can cover most of the characters in the world.
But perhaps a more acceptable way would be to use something like the
Encoded-Variable method. How about a slight simplification? E.g.:
From: Keld J|rn Simonsen <keld(_at_)dkuug(_dot_)dk>
Header-Encoding: From / J|rn = ISO-646-60
I included the "From" so that the software doesn't blindly apply
conversions everywhere in the header. Also, it should be possible to
have one or more pairs after the header name:
header "/" word "=" content-type *["," word "=" content-type ]
Note that the encoding is always Quoted-Printable (or a slightly
restricted form of Quoted-Printable).
Even better would be if someone has an
example that really does use an 8-bit value.
Keld's middle name in Latin-1 would be J\F8rn.
Erik