RE: NEW ISSUE: date formats in BNF and spec text, was: RFC 2616 Errata: Misc. Typos

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