However, I would like to know why 2047 is thought to be a "poor mechanism"
for this purpose (i.e. why was it not standardized that way - it seems to
work in a wide variety of situations).
partially because 2047 imposes strict limitations on the lengths of
encoded-words, doesn't allow them to appear in quoted strings, and
contains characters which aren't legal in MIME parameters.
But WHY doesn't it allow them to appear in quoted strings? What harm
ensures?
it was an explicit decision of the working group. I think the idea
was that the whole intent of a quoting mechanism is to convey things
intact from end-to-end, so quoted strings should not be subject
to additional interpretation. 2047 is in effect an additional quoting
mechanism, to be used instead of "..." rather than in conjunction with it.
and of course 2047 simply was not designed for use with parameters -
so the WG didn't consider that use case.
I just tried a test message to
To: "J\xFCrgen D. Schmidt" <...>
and my mailer (dtmail) sent it as
To: "=?ISO-8859-1?Q?J=FCrgen_D._Schmidt?=" <...>
which is, of course, wrong even though most mailers would have done the
same. The "correct" way to do it is, apparently
To: =?ISO-8859-1?Q?J=FCrgen?= "D. Schmidt" <...>
And the limitation on length doesn't really matter because there is
provision for sticking split pieces together again.
right but it makes assumptions about how MTAs and other mail
handling software wraps message header fields (based on existing
practice in the early 1990s), which doesn't hold for headers within
message bodies.
partially because there are a few things out there that unilaterally
translate all 2047 encodings in a message from one charset to another,
or that decode all 2047 encodings - and 2047 was explicitly designed to
permit the former.
And you are saying that RFC2231 does not allow that, and that was a good
enough reason why RFC2231 encoded differently than RFC2047?
this is part of why we decided to encode parameters differently - we
decided that 2047 did not work well enough to be used as a general-purpose
parameter-encoding mechanism. (we weren't looking at just the problem
of encoding filenames, we were looking at the problem of encoding
parameters)
Keith