Charles Lindsey wrote:
However, on reading the syntax in RFC 2231, I now find a few further
oddities.
1. Broken backwards compatibility
Under RFC 2046, I could write
x-foo'bar = baz
But that is not allowed now.
OTOH, I can still write
charset = x-foo'bar
but not
charset* = ''x-foo'bar
Of course you can't; the asterisk means encoding is used, so that has to be:
charset* = ''x-foo%27bar
That is clearly specified in section 4.1 note (5).
But I thought the IETF "didn't do" backwards incompatibility (Cue howls of
protest from Bruce Lilley) :-( .
If you intend to use my name, please at least extend me the common courtesy
of not misspelling it. Perhaps, you meant somebody else....
You might also save yourself some public humiliation by reading and thinking
about the topic; clearly an *extended* parameter (that is what the asterisk
indicates) is an extension. Charles, based on this and a similar
postting to the
usefor list, you clearly do not undersand backward compatibility -- the
first
part (the line after OTOH) is precisely an example of working backwards
compatibility.
Regarding the change to the MIME definition of a regular parameter attribute
name, please note:
1. 2231 is a MIME extension RFC which updates 2045's (another MIME RFC)
definition. I.e. the auhors knew what they were doing -- quite a
different
situation from an attempt to produce an incompatible redefinition
of something
defined in an RFC managed by another area.
2. 2231 was the result of discussions with MIME users; the
compatibility issues
were well understood.
3. attribute-char is shared by the parameter attribute and the extended
value. At
first glance it might appear that there's no reason to exclude '
and/or % from
an attribute name, but bear in mind the fact that an attribute name
may appear
in a different parameter's value.
2. IANA registered charsets
Under RFC 2046, it was allowed to register "foo'bar" as a charset (it was
just required to be a token). Presumably, this is not allowed now, but
where is it actually written down what may be registered as a charset?
AFAICS, that IANA registry was created by RFC 2046.
See RFC 2278. A single quote is still valid in a charset name, and it
is possible
to uambiguously parse an extended parameter containing a charset name
with one
or more single quotes. So it's not an issue (except, of course, insofar
as implementors
need to take care to parse correctly).