Subject: Re: RFC 2616, partitioned

From: Robert Sayre <[email-masked]>
Date: Fri, 19 Oct 2007 19:09:40 +0000

> a) Is a partitioned specification desirable?
> b) If so, is this the right partitioning?

Overall, I feel the partitioned documents are much clearer than the 
monolithic documents we've reviewed, and I suspect new implementors will 
find them more approachable.

The only downside I see to this partitioning is that the header 
definitions are split up. I found that listing in 2616 pretty 
convenient, but I suppose documents like the header registry are a 
better reference these days.

- Rob

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 21 Oct 2007 14:26:55 -0700

> better reference these days.

Yep, that is part of why I wanted to separate the message parsing
requirements from the semantics -- there is no point in trying to
present the lists as if they are complete.  This way, the requirements
on parsing can be stated once in general and only specifically
mention the known exceptions (e.g., cookie headers have to remain
as separate fields for historical reasons, ...).

Part of the readability fixes needed for this revision is to
integrate the IANA considerations and pointer to the registries
that were defined post-2616.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Oct 2007 12:30:32 +1000

> that were defined post-2616.

It's also a good opportunity to update the registries to point to the  
document itself, rather than the registration document (which is less  
than useful, especially if people are going to start relying on  
that). Ah, good; that's already <http://www.w3.org/Protocols/HTTP/1.1/ 
rfc2616bis/issues/#i40>.

--
Mark Nottingham       [email-masked]

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 22 Oct 2007 11:19:36 +0100

> better reference these days.

I think it's fine if the header _definitions_ are split among their
appropriate documents, but an index of all of them together, referring
to their definitions in other documents, would be a handy reference.

Another very handy reference would be a quick list of "to claim
HTTP/1.1 compliance, a client/server/proxy implementation MUST (very
brief): ...", and in that list refer to the individual documents.

I've seen too many little servers reporting themselves as HTTP/1.1
which don't even try to implement half of the MUSTs in RFC2616.

Another, IMHO, would be "As of 2007, some of the widespread
implementation bugs and workarounds needed for practical internet
interoperability are..."  It's outside the scope of HTTP's definition,
but it would be pretty handy to _somwehere_ consolidate the knowledge
that different implementors have gathered.

-- Jamie