Subject: NEW ISSUE: editorial bug in 13.5.1

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Dec 2006 16:44:17 +0100

Hi,

I was looking at RFC2616, Section 13.5.1 which currently ends with 
(<http://tools.ietf.org/html/rfc2616#section-13.5.1>):

    Other hop-by-hop headers MUST be listed in a Connection header,
    (section 14.10) to be introduced into HTTP/1.1 (or later).

Sorry?

My first idea was that the comma was just in the wrong place, making it

    Other hop-by-hop headers MUST be listed in a Connection header
    (section 14.10), to be introduced into HTTP/1.1 (or later).

But of course that still doesn't make any sense.

So I looked at RFC2068, Section 13.5.1 
(<http://tools.ietf.org/html/rfc2068#section-13.5.1>) and that one says:

    Hop-by-hop headers introduced in future versions of HTTP MUST be
    listed in a Connection header, as described in section 14.10.

Now that makes sense, and it seems that RFC2616 was broken when somebody 
tried to rewrite that sentence.

Proposal: just say...:

    Other hop-by-hop headers MUST be listed in a Connection header
    (Section 14.10).

Best regards, Julian

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 12 Dec 2006 13:20:22 -0800

Sorry?

    

    
    
<rant>
This is when it would be nice to have access to the Internet-Draft
versions that expired along the way, rather than having them consigned
to IETF's Orwellian memory hole.  
</rant>

Fortunately, these are available on the Web (although some of the
versions out there seem to have been truncated accidentally).  The
change crept in between draft-ietf-http-v11-spec-rev-05.txt and
draft-ietf-http-v11-spec-rev-06.txt (which, I believe, was the
last version before the RFC).

    Proposal: just say...:

I suspect what the re-writer (probably not me!) meant was something
like:

        Other hop-by-hop headers, if they are introduced either
	in HTTP/1.1 or later versions of HTTP/1.x, MUST be listed
	in a Connection header (Section 14.10).

(It's not clear that the HTTP/1.1 spec can impose this kind of rule on
HTTP/N.M where N > 1.)

-Jeff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Dec 2006 11:44:23 +0100

Jeffrey Mogul schrieb:
 > ...

Such as at 
<http://tools.ietf.org/wg/http/draft-ietf-http-v11-spec-rev/>? (Thanks 
thanks thanks to the IETF tool team for the good work!).

> (It's not clear that the HTTP/1.1 spec can impose this kind of rule on

I would think that in general the spec talks about HTTP/1.1, and if it 
wants to talk about future versions, it has to specifically do so.

So the original problem seems to be that the spec defines the complete 
set of hop-by-hop headers, and then talks about not defined above. Maybe 
the text needs to be expanded to something like:

	Future revisions of the HTTP/1.1 specification and later
	versions of HTTP MAY introduce new hop-by-hop headers. Those
	headers MUST be listed in a Connection header (Section 14.10)
	for backwards compatibility with this specification.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 14 Dec 2006 01:08:57 +0100

> (It's not clear that the HTTP/1.1 spec can impose this kind of rule on

Imho it can not as a major version bump basically allows anything to
change including the meaning of Connect. But for 1.M where M > 1 it
should..

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 14 Dec 2006 01:17:41 +0100

> 	for backwards compatibility with this specification.

Think I prefer Jeffs simple and concise definition. We also have RFC2145
(even if informal) which do guide future specification authors how to
read this..

On a side note personally I think it was a mistake to define hop-by-hop
headers which does not need to be mentioned in Connect as every special
case allows for broken implementations but it's a bit late to do
anything about that now.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Dec 2006 13:41:14 +0100

> (even if informal) which do guide future specification authors how to

Ack.

See proposed fix in 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.issue.13.5.1-connection_misleading>.

Best regards, Julian