In <200301231352(_dot_)55817(_at_)sendmail(_dot_)mutz(_dot_)com> Marc Mutz
<mutz(_at_)kde(_dot_)org> writes:
On Thursday 23 January 2003 11:58, Charles Lindsey wrote:
()token*0()=3D()token()
ditto =3D()"quoted-string"()
ditto =3D()ascii'en_US'foo%20bar()
All extended-*-{name,value}s? productions are designed to be recognized
as "token" by pre-2231 parsers. Following that thought through will
give you quite naturally the idea of where CFWS can occur.
OK, thanks to all concerned. I can now see how to write a syntax with CFWS
in the right places.
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
But I thought the IETF "didn't do" backwards incompatibility (Cue howls of
protest from Bruce Lilley) :-( .
You're engaging in sophistry again. First of all, the one exception the IETF
makes to the backwards compatibility rule is that of additional restrictions
and feature elimination: It is common for capabilities to be removed, syntactic
flexibility to be eliminated, unused options deprecated, and even for features
to be excised. (This last is typically only done in the case of a burgeoning
security problem of some sort.) So, to the extent RFC 2231 made some previous
legal syntax illegal, this is a very different thing from making previously
illegal syntax legal. Indeed, the entire RFC 2821/2822 exercise would not have
been possible had it been necessary to preserve backwards compatibility with
every prior jot and tittle.
Furthermore, in this particular case, the authors checked and made sure no
existing registered media type parameters were affected by the change. Indeed,
if memory serves, the original syntax we picked (I no longer recall what it
was) fell foul of some obsure existing usage, and we abandoned it for that
reason.
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.
First of all, the restricitions on charset names are such that it is never
necessary to use RFC 2231 facilities to write them. Nor is charset* a
registered media type parameter. So this is an entirely academic exercise.
RFC 2978 section 2.3 is where charset name syntax is specified. Currently
single quotes are allowed. And AFAIK no existing charset name uses a single
quote. So there is no existing usage of a charset name which when coupled
with the nonexistant charset* parameter would cause things to break.
Now, it would be possible to remove this from the allowed syntax (which is
already more restrictive than that of media type parameters, and has in fact
been made increasingly restrictive over time). But doing so really isn't
necessary, so why bother?
3. IMAP
I see that RFC 2231 makes a minor change to IMAP ("SHOULD decode parameter
value continuations"). To be very pedantic, shouldn't RFC 2231 have been
described as "Updates RFC 2060"?
Sure, whatever.
Ned