Regarding non-US-ASCII characters (punt):
Current [RFC 1521] grammar restricts parameter values (and
hence Content-Disposition filenames) to US-ASCII. We
recognize the great desirability of allowing arbitrary
character sets in filenames, but it is beyond the scope of
this document to define the necessary mechanisms. We expect
that the basic [RFC 1521] `value' specification will someday
be amended to allow use of non-US-ASCII characters, at which
time the same mechanism should be used in the Content-
Disposition filename parameter.
Hmmm. If 'value' is redefined for all of MIME, won't it break
existing MIME implementations and thus have a negative impact on the
installed base? It's one thing to define a new way of representing
arbitrary {octet,character}-strings in new parameters, something else
to make it retroactively apply to old ones.
It all depends on how it is done. If the new syntax for value is simply a new
way of interpreting already-legal material I see no real problems with it.
Sure, some things won't be able to interpret the new value strings, but for the
most part I figure that new parameter uses will require new software
capabilities anyway.
This is one of the reasons why I support the use of encoded words within
quoted strings -- they are presently legal.
No matter what scheme you choose it pretty much has to work like encoded words
do inside of quoted string. You can play games with the introductory characters
and the delimiter characters but that's about all. Any scheme put forward has
to allow for long parameter values, which means there has to be a way of
putting padding spaces in so header field wrapping won't mess things up, which
in turn requires that quotes around the whole thing have to be allowed.
Mind you, I'd *really* like to have MIME be consistent in the way it
treats parameters, but I would be surprised if we could justify a
retroactive change. (am I the only one who thinks this is shaky?)
I see nothing shaky about it.
(I suppose the RFC that redefines 'value' could include a caution to
not use the new syntax for awhile, at least not except for non-ASCII
strings.)
The new syntax only makes sense for value strings that can use character set
information. Hence this doesn't apply to existing uses of value. In fact the
only case I can think of is the name parameter for the message/external-body
local-file access method, and this is obviously a case where only those systems
that have file systems which support multiple naming schemes will need to do
anything. (The meaning of different character sets is not defined in the case
of FTP accesses.)
As such, I see such a caution as being irrelevant. What does need to be in
there is a specification that this can ONLY be used for parameters where
character set information is meaningful. In other words, use with any
particular parameter is absolutely forbidden unless the definition of that
parameter specifically permits it.
Ned