Thank you for your reply, and yes, I am concerned about filename parameter of a
content-disposition header and wish RFC2047 made an exception for this
parameter, like what you describe below. There are some backwards compatibility
issues which force me to continue using RFC2047 for a filename. As I mentioned
previously in this mail thread, next version of Exchange Server will decode
RFC2231, but more likely than not will keep producing filename parameter
encoded with RFC2047 (even though we have code in place to encode RFC2231).
--
Yuri Inglikov
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Friday, August 11, 2006 4:24 AM
To: Yuri Inglikov
Cc: ietf-822(_at_)imc(_dot_)org; arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no
Subject: 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