Re: HTTP/1.2 topics and beyond

"Roy T. Fielding" writes:

| The HTTP specification defines HTTP (not DNS, bind, TCP/IP, etc.).
| The only times that the draft discusses things outside HTTP is when they
| are part of the design rationale of the protocol or security considerations.
| Some of those descriptions are more verbose than they would need to be
| if there was a separate implementation guide to reference, but they
| would still be referenced from the spec.  Other things, like the discussion
| of handling broken connections, could be moved to an impementation guide
| without affecting the definition of HTTP.  However, it is important to
| note that they are only part of the HTTP specification if they appear
| inside the specification or some other RFC that updates the specification
| (the set of standards-track documents associated with the protocol).

Definitely!  My concern is twofold - firstly the specification has 
become nearly three times larger than HTTP 1.0 (which had problems, 
admittedly), whilst only adding (IMHO) a small amount of extra 
functionality.  Secondly, the number of MUSTs and SHOULDs (another 
"entry cost") has gotten quite alarming -

  % grep MUST draft-ietf-http-v11-spec-06.txt | wc -l
       258

  % grep SHOULD draft-ietf-http-v11-spec-06.txt | wc -l
       189

I'd argue that some of these do not, strictly speaking, belong in the 
specification but have accumulated there over time because of the lack 
of anywhere else that was particularly appropriate for them.  These are 
the MUSTs and SHOULDs which are really guidelines for implementors 
rather than basic requirements of the protocol.  It would be nice to 
hive these off into a separate document, but this may turn out to be 
unrealistic given the timescales involved...  have to wait and see.

One meta-comment: given that HTTP 1.1 requires so much from its 
implementors, some sort of quick reference might be in order?  e.g. 
listing the status of the various headers in clients' requests and 
servers' responses (MUST? SHOULD?  MAY?) would be a good start.  To 
save on the page count, this could perhaps be worked into the table of 
contents?

Since I haven't received any other private comments on that list of 
candidate sections, apart from a note along similar lines to Roy's from 
Jeff Mogul, here's what I'm fixing on doing next...

(1) Create a new document consisting (for now) of just those sections I 
referred to in my earlier message

(2) Mark sections/paragraphs/... which I believe ought to belong in the 
specification

(3) Post a URL for this document (it'll be too long to post the whole 
thing) to the list and invite comments

Barring accidents I'd expect to have a first draft ready in about a 
week's time.  If in the course of (2) I decide that the specification 
and implementation details are too tightly intertwined for me to 
separate out, I'll post a "bail out" note to the list!

How does that sound ?

Martin

Received on Monday, 29 July 1996 23:55:06 UTC