- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 29 Jul 1996 11:15:23 +0200 (MET DST)
- To: Martin Hamilton <martin@mrrl.lut.ac.uk>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Martin Hamilton:
> 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.
I don't think that many MUST and SHOULDs are really guidelines for
implementors, so moving them into a separate document would not gain
you that much. All in all, I don't think that the 1.1 spec can be
made much smaller by creating an implementation guide. It can be made
more accessible, but not much smaller. The 1.1 spec is a bit like a
monolithic OS kernel: there are so many interdependencies in the text
that you can't easily remove parts without breaking the whole.
My take on the MUSTs and SHOULDs in 1.1 is that most of them are of
the form `if you do this, only then MUST/SHOULD you ...'. I estimate
that about half of the MUSTs and SHOULDs in 1.1 only apply to the
authors of proxy caches, not to user agent and origin server authors.
>One meta-comment: given that HTTP 1.1 requires so much from its
>implementors, some sort of quick reference might be in order?
Yes, I think a quick reference is definitely in order. What we need
is a table that could serve as a reading guide: the table should give
information like `if you are a user agent author, do not bother to
read/understand section X.Y'.
At this point, I think that implementors wanting to upgrade their
software to 1.1 need a guide to deconstructing the HTTP/1.1 spec much
more than they need a guide to constructing HTTP/1.1 implementations.
> e.g.
>listing the status of the various headers in clients' requests and
>servers' responses (MUST? SHOULD? MAY?) would be a good start.
Yes. I've been thinking about tables like the ones below. I filled
these tables from memory, so re-use with caution. `MUST IF' means
`MUST if particular conditions apply.'
Request header generation handling generation handling
by user by origin by caching by caching
(GET requests) agent server proxy proxy
---------------|-----------|----------|-----------|----------|
Accept MAY MAY - -
Accept-Charset MAY MAY - -
Accept-Encoding MAY MAY - MAY
Accept-Language MAY MAY - -
Authorization MAY MAY - -
Cache-Control MAY MUST MAY MUST
Connection MAY - MAY MUST?
>From MUST IF - - -
Host MUST MAY MUST -
If-Modified-Since MAY MAY MAY MAY
If-Match MAY MAY MAY MAY
If-None-Match MAY MAY MAY MAY
If-Range MAY MAY MAY MAY
If-Unmodified-Since MAY MAY MAY MAY
Max-Forwards - - - -
Pragma MAY - MAY MUST?
Proxy-Authorization MAY - MAY MAY
..etc..
Response header handling generation handling generation
by user by origin by caching by caching
(GET responses) agent server proxy proxy
---------------|-----------|----------|-----------|----------|
Accept-Ranges MAY MAY MAY MAY
Age MAY - MUST MUST
Allow MAY MAY - -
Cache-Control MAY MAY MUST -
..etc..
Vary MAY MUST IF MUST -
..etc..
>Martin
Koen.
Received on Monday, 29 July 1996 23:57:21 UTC