W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Fwd: draft-ietf-http-v11-spec-rev-04 comments

From: Jim Gettys <jg@pa.dec.com>
Date: Wed, 12 Aug 1998 14:21:02 -0700
Message-Id: <9808122121.AA19428@pachyderm.pa.dec.com>
To: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/331

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:


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.


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.


 * 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"

 * 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.


 * 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

 * 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.


 * 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 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:23 UTC