Subject: i51 HTTP-date vs. rfc1123-date, was: NEW ISSUE: date formats in BNF and spec text, was: RFC 2616 Errata: Misc. Typos

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jun 2007 14:47:00 +0200

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

I had an action item for this one: 
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action22>.

So far I have only changed the ABNF as suggested 
(<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.issue.i51-http-date-vs-rfc1123-date>), 
now it says:

        HTTP-date    = rfc1123-date ; for use by HTTP clients
                     | obsolete-date ; only allowed for recipients
        obsolete-date = rfc850-date | asctime-date

Question:

In Prague we also talked about adding an "explanatory note to BNF 
section" -- was that meant to be a generic statement that the BNF 
includes some productions that producers should not use? Any concrete 
suggestions for text?

Feedback appreciated (please also verify the BNF comments I added).

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 19 Jun 2007 17:00:10 +0200

> includes some productions that producers should not use? Any concrete 

I don't remember the exact context, but it's already there in the text.
Just aligning it to refer to the correct BNF terms should do.

> Feedback appreciated (please also verify the BNF comments I added).

Instead of clients/recipients I think it's better to divide in parsers /
producers..

the reference to client is not right. rfc1123-date is the only form
allowed to be used when constructing HTTP messages, this applies equal
to both clients and servers.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jun 2007 17:23:53 +0200

> Just aligning it to refer to the correct BNF terms should do.

Pointer, please?

> to both clients and servers.

Right, sorry. New version:

        HTTP-date    = rfc1123-date ; for use in message producers
                     | obsolete-date ; only allowed in message parsing
        obsolete-date = rfc850-date | asctime-date

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 19 Jun 2007 22:22:24 +0200

> > Just aligning it to refer to the correct BNF terms should do.

3.3.1, second paragraph last sentence. Not sure changes here improve the
situation however as it's the background to the BNF construct.

14.18, first paragraph last sentence. Changing this to refer to the BNF
instead of RFC1123 would make a lot sense as it's not really the RFC1123
date allowed (restricted to GMT)..

just look for the RFC 1123 references relating to dates..

>         obsolete-date = rfc850-date | asctime-date

Looks better.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jun 2007 22:30:44 +0200

> situation however as it's the background to the BNF construct.

Ah. I was looking about a generic statement, not just about dates (does 
this principle apply to other parts of the BNF anyway?). Thanks for 
clarifying.

Will look at the other stuff tomorrow.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 19 Jun 2007 22:48:15 +0200

tis 2007-06-19 klockan 22:30 +0200 skrev Julian Reschke:

> this principle apply to other parts of the BNF anyway?).

Not sure there is many other examples in the current BNF. There probably
is some minor ones, but I can't remember one..

But I'm also of the opinion that a cleanup similar to RFC2822 would do
HTTP a great deal good, and might even be within our intended scope if
done carefully. But that discussion is best left until we reach the ABNF
goal, allowing some automated tests of the BNF scope.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 Jun 2007 13:38:13 +0200

> just look for the RFC 1123 references relating to dates..

We already made that change, right 
(<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.section.14.18>)? 

    The Date general-header field represents the date and time at which
    the message was originated, having the same semantics as orig-date in
    [RFC2822].  The field value is an HTTP-date, as described in
    Section 3.3.1; it MUST be sent in rfc1123-date format.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 20 Jun 2007 17:06:10 +0200

> (<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.section.14.18>)? 

Right.

Regards
Henrik