This is very much the wrong time to bring this up, but has the
idea of permitting comma-separated lists as MIME parameter values
ever received serious attention? The change would simply be to
replace
parameter := attribute "=" value
attribute := token ; case-insensitive
value := token / quoted-string
with
parameter := attribute "=" value
attribute := token ; case-insensitive
value := token-list / quoted-string
token-list := token *("," token)
or, more simply
parameter := attribute "=" value
attribute := token ; case-insensitive
value := 1#token / quoted-string
, borrowing another bit of RFC-822 extended BNF. (It might also
be reasonable to permit multiple, comma-separated quoted-strings;
I'm not sure.)
A number of examples have already come up which could use this
flexibility:
The suggested language= parameter for text content-types
Additional encoding/compression parameters
The (now obsolete) extensions= parameter in the March
text/enriched draft
Though none of these examples is compelling (and in fact each of
them is probably contentious), and although a single quoted-
string can obviously be used to specify arbitrary lists (as in
fact recommended for extensions= by the March text/enriched
draft), they seem to me to combine to suggest that other
parameters are likely to want list values in the future, and that
it would be preferable for the base MIME specification to permit
lists, rather than forcing a later extension to modify or extend the
base, or requiring the quoted-string circumlocution.
An extension like this is obviously backwards-compatible, in that
a line like
Content-type: text/plain, x-something=one,two
is invalid under the current grammar. I am, however, certainly
aware of the reluctance to make any significant changes at this
late date.
Steve Summit
scs(_at_)adam(_dot_)mit(_dot_)edu