Subject: RFC 2616 Errata: Misc. Typos

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Mon, 18 Dec 2006 11:41:58 -0800

I've collected several typos; instead of sending out one mail for each, I've decided to just lump them all together in one message. Enjoy!

1. Section 7.1, page 42:

Some of this metainformation is <ins>"</ins>OPTIONAL<ins>"</ins>; some might be <ins>"</ins>REQUIRED<ins>"</ins> by portions of this specification.

2. Section 13.13, page 99:

Even though sometimes such resources ought not <del>to</del><ins>be</ins> cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.

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.

4. Section 14.23, page 129:

A client MUST include a Host header field in all HTTP/1.1 request messages<del> </del>.

5. Section 14.32, page 137:

Note: because the meaning of "Pragma: no-cache<ins>"</ins> as a response<del> </del><ins>-</ins>header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response<ins>.</ins>

6. Section 15.6, page 155:

HTTP/1.1<del>.</del> does not provide a method for a server to direct clients to discard these cached credentials.

-- Travis

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Mon, 18 Dec 2006 14:46:26 -0800

Oops, I missed one...

> I've collected several typos; instead of sending out one mail for each,
> I've decided to just lump them all together in one message. Enjoy!

> Some of this metainformation is <ins>"</ins>OPTIONAL<ins>"</ins>; some
> might be <ins>"</ins>REQUIRED<ins>"</ins> by portions of this
> specification.

> Even though sometimes such resources ought not <del>to</del><ins>be</ins> > cached, or ought to expire quickly, user interface considerations may
> force service authors to resort to other means of preventing caching (e.g.
> "once-only" URLs) in order not to suffer the effects of improperly
> functioning history mechanisms.

> 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.

> Note: because the meaning of "Pragma: no-cache<ins>"</ins> as a
> response<del> </del><ins>-</ins>header field is not actually specified, it
> does not provide a reliable replacement for "Cache-Control: no-cache" in a
> response<ins>.</ins>

> HTTP/1.1<del>.</del> does not provide a method for a server to direct
> clients to discard these cached credentials.

7. Section 2.1, page 15:

At least one delimiter (LWS and/or<del>

<del><ins> </ins>separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 19 Dec 2006 01:11:51 +0100

> 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.

Regards
Henrik

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Mon, 18 Dec 2006 16:31:07 -0800

2006-12-18 16:12 -0800, Henrik Nordstrom said:

> > 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.
>

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.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Dec 2006 09:35:31 +0100

> Some of this metainformation is <ins>"</ins>OPTIONAL<ins>"</ins>; some might be <ins>"</ins>REQUIRED<ins>"</ins> by portions of this specification.

I agree that BCP14 keywords shouldn't appear here. But maybe a better 
fix would be to lowercase both?

> Even though sometimes such resources ought not <del>to</del><ins>be</ins> cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of pre…

OK.

> 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.

(see separate mail)

> A client MUST include a Host header field in all HTTP/1.1 request messages<del> </del>.

OK.

> Note: because the meaning of "Pragma: no-cache<ins>"</ins> as a response<del> </del><ins>-</ins>header field is not actually specified, it does not provide a reliable replacement for "Cache-Control…

Possibly. There are other instances of that. Should we make them all 
consistent?

> HTTP/1.1<del>.</del> does not provide a method for a server to direct clients to discard these cached credentials.

Yes.

Thanks for the good feedback!

I will fix the trivial ones right away.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Dec 2006 09:38:08 +0100

Travis Snoozy (Volt) schrieb:
> ...
> ...

I'm not sure what's the issue here. Do you want to get rid of the CRLF 
before "separators"?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Dec 2006 09:42:56 +0100

>> but perhaps you are right that there should still be a "the" infront..

I'll let the native English speakers vote on that one :-)

> 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 de…

I have thought about that myself, but didn't have time to bring it up yet.

Best regards, Julian

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 19 Dec 2006 09:21:33 -0800

2006-12-19 00:38 -0800 Julian Reschke said:
> > <del><ins> </ins>separators) MUST exist between any two tokens (for the
> > definition of "token" below), since they would otherwise be interpreted
> > as a single token.
> > ...
>

Yes, the extra CRLF is the only issue here; it's easy to spot on paper, but a little awkward to reproduce :).

Thanks,

-- Travis

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 19 Dec 2006 09:51:57 -0800

> fix would be to lowercase both?

I used quotes because there are other portions of the spec that quote these words when referring to the BCP14 meaning (as opposed to applying the BCP14 meaning). See the section 14.9.3 (top of page 113), and section 4.4 (page 33).

<snip>

> > response<del> </del><ins>-</ins>header field is not actually specified,
> > it does not provide a reliable replacement for "Cache-Control: no-cache"
> > in a response<ins>.</ins>
>

I assume "that" is referring to the "response header" versus "response-header" change. Unless these two versions have different meanings, I'd say the usage should probably be consistent throughout the entire document. I didn't notice (or if I did, I didn't annotate) any other spots where this happened, so if I omitted other occurrences, that's just an oversight on my part.

<snip>

Thanks,

-- Travis

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Dec 2006 19:14:18 +0100

> I used quotes because there are other portions of the spec that quote these words when referring to the BCP14 meaning (as opposed to applying the BCP14 meaning). See the section 14.9.3 (top of page…

ACK. Will check.

> I assume "that" is referring to the "response header" versus "response-header" change. Unless these two versions have different meanings, I'd say the usage should probably be consistent throughout…

IMHO there's a difference between those two. If we say "response 
header", we're talking about a header on a response. When we say 
"response-header", it's about the things described in 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-02.html#rfc.section.6.2>.

More opinions needed :-)

Best regards, Julian

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 19 Dec 2006 10:27:21 -0800

<snip>

> > I assume "that" is referring to the "response header" versus "response-
> > header" change. Unless these two versions have different meanings, I'd
> > say the usage should probably be consistent throughout the entire
> > document.

<snip>

> 02.html#rfc.section.6.2>.

In that case, I'd say "Response header" and "response-header" respectively.
(Capital "R" Response, referring to
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-
02.html#response>.)

> More opinions needed :-)

The more the merrier.

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 20 Dec 2006 09:30:36 +0100

tis 2006-12-19 klockan 09:42 +0100 skrev Julian Reschke:

> > 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?
> 

It's an HTTP-date.

HTTP-date is a wierd beast in that it's an asymmetric specification,
where parsing and composing differs. The BNF specifies many formats
everyone must understand, but the notes clarify that only rfc1123-date
may be sent.

Because of this each use of HTTP-date stresses this, in a best effort to
ensure no implementer mistakenly thinks that it's valid to send any of
the HTTP-date variants that must be accepted.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 Dec 2006 13:38:45 +0100

> the HTTP-date variants that must be accepted.

Understood.

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.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 20 Dec 2006 22:35:06 +0100

> 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.

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

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 Dec 2006 22:45:44 +0100

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

That sounds like a good improvement.

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Wed, 20 Dec 2006 13:56:08 -0800

> 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?

>       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

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 20 Dec 2006 23:29:17 +0100

ons 2006-12-20 klockan 13:56 -0800 skrev Travis Snoozy (Volt):

> 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.

Which in effect is the question

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.

For as long as the compatibility is in HTTP-date references must be to
HTTP-date as this defines the parser. If we move the compatibility to
19.3 and/or 19.6 then HTTP-date is no longer needed and replacing it by
rfc1123-date is sufficient.

But I dislike this as it makes it less obvious what formats the parsers
must support as we then have the situation that it's insufficient for
lexical parsing to follow the BNF and you must also read the notes to
define the lexical parser..

At least to me the current wording regarding HTTP-date is pretty clear
as it is. But then I am the kind of guy which actually considers
stressing this aspect of HTTP-date in each reference to be redundant and
not at all needed as it's already an MUST in 3.3.1, long before the
first reference or even the BNF definition of HTTP-date..

Regards
Henrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 20 Dec 2006 15:55:46 -0800

> 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.

....Roy

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Wed, 20 Dec 2006 16:16:36 -0800

> while the text requirements add limitations to be conservative in

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

Subject: RE: RFC 2616 Errata: Misc. Typos
From: "Travis Snoozy (Volt)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 18 Dec 2006 16:31:07 -0800
List-Id: <ietf-http-wg.w3.org>

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 21 Dec 2006 02:00:22 +0100

ons 2006-12-20 klockan 16:16 -0800 skrev Travis Snoozy (Volt):

> 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)?

I see your point, but why make the life for implementers more
complicated/confused by specifying different parsing rules for different
date related directives within the same specification? And in the
specific example especially so considering the very close relationship
with If-Modified-Since.

It's as likely (relative to the number of implementations) there will be
If-Umodified-Since implementations sending "bad" date formats as for the
older headers..

Regards
Henrik