To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: Re: RFC 1342 bugs & suggested fixes
Date: Fri, 26 Feb 93 17:45:57 +0900
The encoded word has the encoding as one of its 3 required parts.
If you want to use the encoded word to explicitly identify a 7
bit character set, say iso-2022-jp, with the current specification
you would be required to specify one of "b"inary or "q"oted
printable when neither is necessary.
Yes, but iso-2022-jp *does* need to be encoded in either "B" or "Q"
since (a) it uses ESCAPE (0x1b), and (b) it often uses bytes that
are "dangerous" in headers (i.e. "<", "(", <">, ",", etc). In fact,
some of the Japanese even want to mandate "B" for iso-2022-jp since
it's so safe and since it takes a fair amount of trouble to figure
out *which* byte values would need to be encoded if the "Q" encoding
was used.
I repeat: The motivation for the "7" encoding is to *allow* for
charsets *like* MU, which are already safe in headers as is.
I've thought about this some more, and I now don't think the "7"
encoding would be very useful.
Any text encoded with the "7" encoding would still have to obey the
general rules for encoded-words: no SPACE or CTRL characters, no "?",
and no SPECIALs when used where an "atom" might be expected. Any text
of significant length will probably have a SPACE, and will then
require "Q" encoding rather than "7" encoding. Furthermore, the only
differences between a "Q"-encoded encoded-word and a "7"-encoded
encoded-word would be (a) the way 0x3d ("=" character in ASCII) is
encoded, and (b) the optional encoding of 0x20 (SPACE character in
ASCII) as "_".
For text that doesn't contain many '='s, the "7" is so similar to the
"Q" encoding that it doesn't seem worth the effort to define both.
I realize the MU uses '=' frequently. Can you change MU to use
something else? I would even venture that it's better if MU doesn't
look so much like quoted-printable: if they look too much alike, some
implementor is likely to confuse one for the other.
Keith