In <01KRLYIRSE3W00AE20(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com writes:
On Thursday 23 January 2003 11:58, Charles Lindsey wrote:
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.
Sure, I agree that is all quite reasonable. I was just pointing out that
the IETF postion on compatibilty was not as rigid as some here were
seeming to imply.
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.
And, again, if some breech of compatibility is proposed, looking at real
observed existing usage (as opposed to a theoretical possibility which
some obscure site might _just_ be using, but noone has ever seen, like my
"x-foo'bar = baz" example) is the proper procedure.
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.
Thanks for the pointer to RFC 2978. I see that '%' is also allowed, but
not '*'. So writing a foolproof parser for extended-initial-value would be
tricky (you have to scan from R to L until you have identified the two
rightmost "'"s), but I doubt implementors will bother to go so far.
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?
Sounds like a sensible thing to fix next time that document comes up for
revision.
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.
Yes, I was merely checking that, where a protocol changed, it was in order
to make consequential changes to IMAP, or other documents affected.
--
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