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

From: Mark Nottingham <[email-masked]>
Date: Mon, 1 Jan 2007 12:07:02 +1100

Added as i51;
   http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/index.html#i51

On 2006/12/19, at 7:42 PM, Julian Reschke wrote:

>
> Travis Snoozy (Volt) schrieb:
>> 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..
>
> I'll let the native English speakers vote on that one :-)
>
>>> 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?
>
> I have thought about that myself, but didn't have time to bring it  
> up yet.
>
>> -- 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.
>
> Best regards, Julian
>
>
>

--
Mark Nottingham     http://www.mnot.net/