Re: rfc2231 implementations?

> Does anybody have insight why RFC2047 explicitly prohibits encoding parameter values and quoted strings? 

There are two reasons.  The first is that there were objections from
the ietf-822 working group (when this was originally proposed) to
having encoded-words within a string, on the grounds that part of the
purpose of the quotes in a quoted-string were to protect the contents
from interpretation.  It was argued that encoded-words were another
kind of quoting mechanism but that they shouldn't invalidate the
original kind.

The second reason is that encoded-words were intended as human-readable
text rather than machine-readable text.    This allowed encoded-words
to avoid solving certain problems, like canonicalization and
comparison, that turned out to be significant technical hurdles to
the development of encoding schemes for machine-readable tokens
such as IDNs and internationalized email addresses (the hurdles for the
latter have not yet been satisfactorily overcome).

The filename parameter of a content-disposition field is somewhat of a
gray area because it's only a suggestion - for security and other
reasons (e.g. character set differences, restrictions on file
names imposed by the receiving system) no receiving system should
automatically use the filename parameter as a destination filename.
So for the specific case of a content-disposition filename parameter it
might be reasonable for an MUA to interpret a parameter value that
looks like an encoded-word, as if it were decoded according to RFC
2047, just as the MUA might need to transform the filename in other
ways to avoid scribbling in arbitrary directories and/or conform to
local file naming conventions.  But that's a matter of how the MUA
interprets one specific kind of parameter rather than a license to use
encoded-words in arbitrary MIME parameters.

Keith