Roy T. Fielding said:
> On Dec 20, 2006, at 2:29 PM, Henrik Nordstrom wrote:
> > Should HTTP-date be reduced into just rfc1123-date and replaced by it,
> > and the compatibility with the obsolete date formats moved to section
> > 19.4, or should we try to clarify HTTP-date further.
>
> No, there is no need for any changes in that section (aside from
> updating the BNF to the ABNF standard).
>
> The BNF is for parsing the superset of what is allowed in a message,
> not for defining all of the specifics of each message generation.
> All IETF specs that use BNF specify it to be lenient in what is
> received,
> while the text requirements add limitations to be conservative in
> what is sent.
All right, so wholesale replacement of HTTP-date is out of the question. That's fine, but that still leaves the question of whether we should be using HTTP-date for *new* constructs (see attached message for my prior comment on this). The Date header doesn't work for this, but if we take If-Unmodified-Since as our example (which exists only in HTTP/1.1) why should its BNF contain any reference to HTTP-date (and the old date formats)?
-- Travis
Forwarded message 1
2006-12-18 16:12 -0800, Henrik Nordstrom said:
> > 3. Section 14.18, page 124:
> >
> > The field value is an HTTP-date, as described in section 3.3.1; it MUST
> be sent in <ins>the </ins>RFC 1123 [8]<del>-</del><ins> </ins>date format.
>
> The section has already been rewritten to read
> "MUST be sent in rfc1123-date format."
> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-
> latest.html#rfc.section.14.18
>
> but perhaps you are right that there should still be a "the" infront..
>
> in such case it also also applies to 14.21 which uses the exact same
> language.
On closer inspection, shouldn't the BNF for that section (14.18) be "rfc1123-date" and not "HTTP-date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is allowed (conflicting with the definition of HTTP-date)*? Likewise, shouldn't we just use the rfc1123-date moniker throughout the document whenever explicitly referring to only dates in RFC 1123 format?
-- Travis
* Perhaps to answer my own question: it could be that the BNF is intending to represent the loosest set of values the field could take, i.e., that an implementation MUST be able to parse a message containing such a construct, even if generating such a message would be in violation of the specification. Then that leaves the question of whether or not Date exists in HTTP/1.0, and if not, if there's any compelling reason to use HTTP-date over rfc1123-date.