- From: Travis Snoozy (Volt) <a-travis@microsoft.com>
- Date: Wed, 20 Dec 2006 13:56:08 -0800
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Henrik Nordstrom said: > ons 2006-12-20 klockan 13:38 +0100 skrev Julian Reschke: > > > What makes me nervous is that we have a MUST requirement to use > > rfc1123-dates, but then the grammar allows something else. I understand > > the intent, I'm just skeptical about how it's done. > > Not sure if it's possible to corretly express the requirement of > HTTP-date using BNF grammar.. I.e. how to express elements which must be > understood in parsing using the grammar, but which must not be used when > composing using the the grammar. Well, it could be handled in a fashion similar to other backwards-compatibility notes by relegating this information to the appendix (section 19). Not that I particularly like that idea, but that is how other things are handled. (veering from the topic at hand) I think that the *really* bad part about the 3.3.1 BNF, though (now that I look further down) is the usage of 2DIGIT. There is no bound on those digits, so it really doesn't represent proper date/time formats anyway. "Jun 99", "61:99:84", and other such nonsense is valid according to the grammar. How is an implementation supposed to deal with that? > The main definition of HTTP-date where also the background information > on why things are as they are is in 3.3.1. > > Maybe we shoud split the HTTP-date BNF for the older dates in two steps > to stress this within the BNF as well? I.e. something like the > following: > > HTTP-date = rfc1123-date | obsolete-date > obsolete-date = rfc850-date | asctime-date This might be helpful if you were just scanning the BNF (or it could jog your memory if you saw obsolete-date somewhere), but I think that it doesn't quite deal with the "should we use rfc1123-date instead of HTTP-date in references?" question. -- Travis
Received on Wednesday, 20 December 2006 21:56:22 UTC