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) :-( .
And it might have been simpler just to add "'", "*" and "%" to tspecials,
for the removal of all confusion.
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.
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"?
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5