Subject: [i47] inconsistency in date format explanation

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 2 Nov 2007 19:19:03 -0700

The proposed resolution to this issue (in draft 03) is incorrect
because RFC1036 doesn't define the date format in question.
This was an error introduced in the 2616 editing cycle.  It should
be fixed by removing reference to 1036, as described below:

===================================================================
--- p1-messaging.xml	(revision 591531)
+++ p1-messaging.xml	(working copy)
@@ -1037,14 +1037,14 @@
</t>
<figure><artwork type="example">
     Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
-   Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
+   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
     Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
</artwork></figure>
<t>
     The first format is preferred as an Internet standard and  
represents
     a fixed-length subset of that defined by RFC 1123 <xref  
target="RFC1123"/> (an update to
-   RFC 822 <xref target="RFC822"/>). The second format is in common  
use, but is based on the
-   obsolete RFC 850 <xref target="RFC1036"/> date format and lacks a  
four-digit year.
+   RFC 822 <xref target="RFC822"/>). The other formats are described  
here only for
+   compatibility with obsolete implementations.
     HTTP/1.1 clients and servers that parse the date value &MUST;  
accept
     all three formats (for compatibility with HTTP/1.0), though they  
&MUST;
     only generate the RFC 1123 format for representing HTTP-date values
@@ -3152,17 +3156,6 @@
<seriesInfo name="RFC" value="1808"/>
</reference>
-<reference anchor="RFC1036">
-<front>
-<title abbrev="Standard for USENET Messages">Standard for  
interchange of USENET messages</title>
-<author initials="M." surname="Horton" fullname="M. Horton">
-<organization>AT&amp;amp;T Bell Laboratories</organization></author>
-<author initials="R." surname="Adams" fullname="R. Adams">
-<organization>Center for Seismic Studies</organization></author>
-<date month="December" year="1987"/></front>
-<seriesInfo name="RFC" value="1036"/>
-</reference>
-
<reference anchor="RFC977">
<front>
<title abbrev="Network News Transfer Protocol">Network News Transfer  
Protocol</title>
================

....Roy

On Nov 29, 2006, at 4:50 PM, Mark Nottingham wrote:

>
> Added: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i47
>
> On 2006/11/20, at 6:46 AM, Julian Reschke wrote:
>
>>
>> Hi.
>>
>> In Section 3.3.1, RFC2616 says (<http://tools.ietf.org/html/ 
>> rfc2616#section-3.3.1>):
>>
>> "The second format is in common use, but is based on the obsolete  
>> RFC 850 [12] date format and lacks a four-digit year."
>>
>> However, [12] refers to RFC1036, which obsoletes RFC850.
>>
>> Proposal: change to:
>>
>> "The second format is in common use, but is based on the obsolete  
>> RFC1036 date format [12] and lacks a four-digit year."
>>
>> Best regards, Julian
>
> --
> Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Nov 2007 11:25:35 +0100

Roy T. Fielding wrote:
> ...

Good catch, thanks. Updated 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.issue.i47-inconsistency-in-date-format-explanation> 
accordingly.

Now this is a good example that external references are more useful when 
they point to a specific section; in this case this would have made 
easier to detect the problem.

By that reasoning, shouldn't we possibly say:

   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete format defined in [RFC850], 
Section 2.1.4

instead of

   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format

?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 4 Nov 2007 18:41:31 -0800

On Nov 3, 2007, at 3:25 AM, Julian Reschke wrote:
> Good catch, thanks. Updated <http://www.w3.org/Protocols/HTTP/1.1/ 
> rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.issue.i47- 
> inconsistency-in-date-format-explanation> accordingly.
>
> Now this is a good example that external references are more useful  
> when they point to a specific section; in this case this would have  
> made easier to detect the problem.
>
>   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete format defined in  
> [RFC850], Section 2.1.4
>
> instead of
>

That's how we arrived at the current bug -- the RFC editor saw the
reference to RFC 850 and determined that we cannot refer to an
obsoleted RFC, thus requiring the reference update to 1036.  If we
just include the number in the comment (without a Reference) then
we should be fine.

....Roy

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 5 Nov 2007 16:21:34 +0100

Roy T. Fielding wrote:

> the RFC editor saw the reference to RFC 850 and determined that
> we cannot refer to an obsoleted RFC

Informative references to an obsoleted RFC should be okay, if the
status "obsolete" is obvious.  

For an approved RFC in the editor queue referencing RFC 850 compare
<http://tools.ietf.org/html/draft-ietf-usefor-usefor-12#section-7.2>.

IANA got the idea and registered Date-Received specified in RFC 850
as obsolete header field: 
<http://www.iana.org/assignments/message-headers/perm-headers.html>

 Frank