- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 20 Oct 97 15:42:41 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Dave Kristol writes:
I have one quibble. There are some lines that have double negatives
and that are, therefore, hard to interpret. Three examples:
If no-transform, don't add
Content-Encoding, Content-Length,
Content-Range, Content-Type 13.5.2 na MN na 2
Don't use 200 with partial resp. 13.8 na MN MN 1
GET/HEAD: no side effects 13.9 SN na na
I recommend always stating the requirement in the positive sense. So
these lines would read:
If no-transform, add
Content-Encoding, Content-Length,
Content-Range, Content-Type 13.5.2 na MN na 2
Use 200 with partial resp. 13.8 na MN MN 1
GET/HEAD: has side effects 13.9 SN na na
This way the SN/MN negations are clearer, I think.
I thought about this, and decided that it was probably safer to
have the textual description state the rule, rather than have it
state what we don't want people to do (with the "MUST NOT" in the
columns to the right negating the apparent meaning of the left
side).
I mean, if one took your version, and just read it without paying
much attention to the "MN"s to the side, one might naively believe
that it allows/requires adding "Content-Type" when no-transform
is present.
Bottom line: this summary isn't going to be 100% intelligible on
its own to a naive reader, no matter what we do. It's only usable
with a copy of the spec present, open, and *read* by the user.
-Jeff
P.S.: Anyone who wants to actually contribute a significant
portion of the summary would probably have more influence over
the design (hint, hint).
Received on Monday, 20 October 1997 15:50:41 UTC