Paul Bennet has done a complete, nit-picking, read of draft 04... My thanks to him for the read. Having recently become convinced that there will (almost certainly) be a draft 05, I'm forwarding this list to the mailing list so it will get archived. - Jim
attached mail follows:
Jim,
I've just completed reviewing the '-04' revision of the HTTP/1.1
spec, and have some comments for you.
Most of these comments are simple editorial matters. There are a
few genuine errors I noticed; I've listed things in decreasing order
of severity (I'd understand if you never get to the end of this
list, but I'd rather you dealt with the first couple).
The spec's looking in good shape; I bet you'll be pleased to see it
reach Draft Standard.
Paul.
Out and out mistakes
* Page 2, last sentence: "See section 18 for the full copyright
notice." - that should be section *20*. (I believe Henrik has
already notified you of this one.)
* Section 2.1 "Augmented BNF", p15, last sentence of first
paragraph ("implied *LWS" rule): '(for the definition of
"token" above)' - you mean, *below* (the def's in section 2.2).
* Section 5.1.2 "Request-URI", p33, second para talks about
replacing 'a null abs_path with "*"' - surely it's replaced
with a "/".
* Section 8.1.3 "Proxy Servers", first paragraph: "... as specified
in section 14.2.1." - no such section exists; maybe you mean
section 14.10?
* Section 13.2.4 "Expiration Calculations", end of second paragraph:
"(see section 14.10." - missing right bracket, and the section
number's wrong - should be 14.9.3.
* Section 13.5.2 "Non-modifiable Headers", page 79, last sentence
on page refers to "Warning 114 (Transformation Applied)". That
should be "214", according to section 14.46, page 126. This
sentence also includes repetition: "..., if not already present,
... if one does not already appear in the message.".
* Section 14.24 "If-None-Match", third para on p112, last sentence:
"... then the server MUST not return a 304 ..."; the "not" should
be capitalised: "... the server MUST NOT return a 304 ...".
* Section 14.31 "Max-Forwards" refers to section 14.31 for the
TRACE method; this should be section 9.8.
* Section 19.4.2 "Conversion to Canonical Form" refers to "Appendix
G of RFC 2045" - such an appendix doesn't exist! The closest I
can find is section 6.6... or maybe you mean something else.
* Section 13.5.1 "End-to-end and Hop-by-hop Headers" refers to the
Keep-Alive field, which doesn't exist any more.
Clarifications
* Section 2.2 "Basic Rules", "TEXT" rule: "<any OCTET except CTLs,
but including LWS>". This excludes the optional "CRLF" of "LWS"
by virtue of those two octets being CTLs, but it took a second
reading to see this; perhaps "<any OCTET except CTLs, but
including HT and SP>" would be clearer.
* Section 2.2 "Basic Rules", "Note:" in "quoted-pair" description:
I *think* I get what the example's on about: it's the
significance of an HT and/or SP before "a" and "quoted-string",
right? But the indentation of the example doesn't make this
clear; perhaps indent those two lines more than the first of
the example, or add more description to the text.
* Sections 9.3 "GET", 9.4 "HEAD" and 9.7 "DELETE" don't explicitly
rule out the presence of an entity-body, as section 9.8 "TRACE"
does.
* Section 10.2.2 "201 Created" says nothing about the format of the
response entity. (section 10.3.1 "300 Multiple Choices" in a
similar position is explicitly non-committal.
* Section 10.3.6 "305 Use Proxy": "The Location field gives the URI
of the proxy." But nowhere can I find a specification for this
URI form; presumably it's an HTTP URI without an abs_path part.
Typos
* Section 3.6 "Transfer Codings", third paragraph: "section
14.4114.41" clearly should read "section 14.41".
* Section 3.7.2 "Multipart Types", third paragraph is a repetition
of the penultimate sentence of the second paragraph (but maybe you
intended the repetition to emphasise the point!).
* Section 10.1 "Informational 1xx": "There are no required headers
for this class of status codes." Should be "code" singular, I
think.
* Section 10.2.7 "206 Partial Content", first bullet point: "If a
Content-Length header field is present in the response MUST match
..." words missing! Probably want "... in the response, its value
MUST match ...".
* Section 13.2.4 "Expiration Calculations", page 72, second para:
weird additional whitespace in first line of this paragraph.
Also, the last sentence includes repetition: "If the value is
greater than 24 hours, ... whose age is more than 24 hours ...".
* Section 13.3.3 "Weak and Strong Validators", first two sentences
should be a single one (the first one doesn't make sense alone;
perhaps replace "... different entities. One normally ..." with
"... different entities, one normally ...".
* Section 13.5.3 "Combining Headers", second paragraph starts "In
the status code is 304" - that should be "If the status code ...".
The last sentence of this paragraph also repeats "see 13.5.4".
* Section 13.5.4 "Combining Byte Ranges", last paragraph: "If either
requirement is not meant ..." should be "not met", presumbaly.
* Section 13.13 "History Lists", fourth paragraph: "This is not be
construed to prohibit" - should be "This is not construed ..."
* Section 14.8 "Authorization", last sentence of first para on p91:
"(assuming that the authentication schemed ..." should be
"scheme" (spurious 'd').
* Section 14.21 "Expires", last paragraph "... an response ..."
should be "... a response ..."
* Section 14.25 "If-None-Match", end of first sentence: "... used
with a method to make the method conditional." should be "... used
with a method to make it conditional.". This brings the wording
in line with that of the other If-* headers, as well as saving
bytes :-)
* Section 14.35.2 "Range Retrieval Requests", second para on p118:
"intermediate caches ought tosupport" - space missing between "to"
and "support".
* Section 14.45 "Via", first para: spurious whitespace at start
of fifth line.
* Section 14.46 "Warning", first sentence: "transformation of a
message whichmight" - missing space. Also spurious extra space
at the start of the fourth para on p125: " Warning headers can
...".
* Section 19.6.3 "Changes from RFC 2068", p146, third from last
paragraph: extra right bracket: "A new error code (416))".
Things you've probably debated to death
* Throughout: "inbound" vs. "upstream" - these terms seem to refer
to the same concept, but are not defined or used consistently.
"inbound": 13.11, 14.31, 14.35.2, 19.6.2
"outbound": 13.2.3, 14.34
"upstream": 10.5.3, 10.5.5, 14.45, 19.6.3,
"downstram": 14.33
* Section 3.6.1 "Chunked Transfter Coding", "chunk-data"
production: "chunk-size(OCTET)" at a casual glance *might* imply
"1*HEX OCTET", when presumably you mean "n*n OCTET ; where n is
the value of chunk-size".
* Section 15.1.2 "Transfer of Sensitive Information": given recent
well-publicised security holes in specific user agents, perhaps
"User-agent" should be added to the list of sensitive fields.
Cross-references
* Throughout: I'd like to see more cross-referencing. Particularly,
against most occurrances of method names, field names, status and
warning codes.
* Section 1.2 "Requirements": the key words "SHALL", "REQUIRED",
"MAY" and "OPTIONAL" are mentioned, but requirements for
(un)conditionally compliant implementations with respect to
these words are not laid down. Suggest: replace "the MUST
requirements" with "the MUST, REQUIRED and SHALL requirements".
* Section 3.2.2 "http URL", second paragraph: "... and the
Request-URI ..." a forward reference to section 5.1.2 (for
Request-URI) would be helpful.
* Section 3.3.1 "Full Date": needs forward-reference to section
19.3 (concerning the "year 2000 problem").
* Section 8.2.1 "Persistent Connections and Flow Control":
reference to section 3.6 ("chunked encoding") should more
accurately be a reference to section 3.6.1.
* Section 13.6 "Caching Negotiated Responses", first sentence refers
to section 12; 12.1 would be more accurate.
* Section 14.4 "Accapt-Language" should refer to section 3.10.
* Section 14.5 "Accept-Range" should refer to section 3.12.
* Section 14.15 "Content-Encoding", second para on p100 refers to
14.15 itself!
* Section 14.15 "Content-Range" should refer to section 3.12.
* Section 14.21 "Expires", third paragraph refers to section 3.3;
3.3.1 would be more accurate.
* Section 14.24 "If-Match" should refer so section 3.11.
Really petty stuff
* Section 4.5 "General Header Fields": the BNF is *almost* in
alphabetical order (shift "Trailer" up two places and you're
there). Also: comment part of "Warning" isn't quite aligned
with the other comments.
* Section 5.3, "Request Header Fields": more alphabetical BNF:
"If-Match" should appear before "If-Modified-Since".
* Section 10.2.5 "204 No Content" and section 10.2.6 "205 Reset
Content", last sentence of each, differ in their terminology:
204 says "The 204 response MUST NOT include a message-body";
205 says "The response MUST NOT include an entity".
* Section 10.4.15 "414 Request URI Too Long": spurious extra
space before the full-stop at the end of the first sentence.
* Section 13.1.4 "Explicit User Agent Warnings": spurious extra
full-stop at the end of the first paragraph.
* Section 19.6.3 "Changes from RFC 2068", top of p146: spurious
extra space at start of first line: " Content-Base was
deleted ...". Also, spurious extra whitespace at the start
of points six and sever (page 147).
Things you know about, but I'll mention anyway
* Throughout: The [jg] footnotes
* Throughout: "HTTP Authentication: Basic and Digest Access
Authentication"; presumably you're waiting for an RFC number
(but you might also flag these as [43]). This appears at least
in these sections: 10.4.2, 10.4.8, 11, 14.8, 14.33, 14.34, 14.47
* Section 14.16 "Content-Range", second para on p104, "See appendix
Error! Reference source not found".
* Section 19.1 "Internet Media Type message/http and
application/http": screwy line-wrapping in the Encoding
considerations section of application/http.
* Section 19.6 "Compatibility with Previous Versions", last
sentence: "Error! Reference source not found" - presumably this
should instead refer to RFC2068 since Keep-Alive has now gone.
* Section 21 "Index": the index is broken - at least, a good
percentage of the referenced pages are irrelevant, which is
a real shame because the index looks great and is *vital* in
a document this size :-(
_____________________________________________________________
Notice: This contribution is the personal view of the author
and does not necessarily reflect the technical nor commercial
direction of British Telecommunications plc.
_____________________________________________________________
Received on Wednesday, 12 August 1998 14:22:34 EDT
This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:20 EDT