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

> Sender: bennettp@bt-sys.bt.co.uk
> From: Paul Bennett <p.bennett@bt-sys.bt.co.uk>
> Date: Wed, 12 Aug 1998 08:03:03 +0100
> To: jg@w3.org
> Subject: draft-ietf-http-v11-spec-rev-04 comments
> -----
> 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.
> 

Sure will.  It will have a lot fewer mistakes courtesy of your read.

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

There were some problems generating the plaintext; it is correct in the
postscript.  I'll make sure the next draft's text is cleaner.

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

Fixed.

>  * Section 5.1.2 "Request-URI", p33, second para talks about
>    replacing 'a null abs_path with "*"' - surely it's replaced
>    with a "/".
> 
I think the spec is right as is.


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

>  * 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.".
> 
fixed
>  * 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 ...".
> 
fixed
>  * Section 14.31 "Max-Forwards" refers to section 14.31 for the
>    TRACE method; this should be section 9.8.
> 
fixed
>  * 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.
> 
fixed; the MIME documents were massively reorgized before they
went to draft standard, and I didn't catch all the reorganization
>  * Section 13.5.1 "End-to-end and Hop-by-hop Headers" refers to the
>    Keep-Alive field, which doesn't exist any more.
> 
Yes, it exists, but not in this spec (and it has not be fully "standardized");
I fixed the reference.

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

I've sent this to Roy Fielding and Dave Kristol to look at...  I don't
breath BNF the way they do.

>  * 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.
> 
I've sent this to Roy Fielding and Dave Kristol to look at...  I don't
breath BNF the way they do.

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

No, and we're not sure that the spec should do so.  Not clear what
current implementations actually do, either.

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

Interesting question; but it had to be defined carefully in 300 Multiple
Choices to allow a future content negotiation standard, and I'm not sure
it needs to be so well defined here.

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

No, it can be any URI, per the URI spec.  This is necessary to allow
gatewaying into other URI schemes.

> 
> Typos
> 
>  * Section 3.6 "Transfer Codings", third paragraph: "section
>    14.4114.41" clearly should read "section 14.41".
> 
fixed
>  * 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!).
> 
fixed
>  * Section 10.1 "Informational 1xx": "There are no required headers
>    for this class of status codes."  Should be "code" singular, I
>    think.
> 
fixed
>  * 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 ...".
> 
fixed
>  * 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 ...".
> 
fixed
>  * 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 ...".
> 
fixed
>  * 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".
> 
fixed
>  * Section 13.5.4 "Combining Byte Ranges", last paragraph: "If either
>    requirement is not meant ..." should be "not met", presumbaly.
> 
fixed
>  * Section 13.13 "History Lists", fourth paragraph: "This is not be
>    construed to prohibit" - should be "This is not construed ..."
> 
fixed
>  * Section 14.8 "Authorization", last sentence of first para on p91:
>    "(assuming that the authentication schemed ..." should be
>    "scheme" (spurious 'd').
> 
fixed
>  * Section 14.21 "Expires", last paragraph "... an response ..."
>    should be "... a response ..."
> 
fixed
>  * 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 :-)
> 
fixed
>  * Section 14.35.2 "Range Retrieval Requests", second para on p118:
>    "intermediate caches ought tosupport" - space missing between "to"
>    and "support".
> 
fixed
>  * Section 14.45 "Via", first para: spurious whitespace at start
>    of fifth line.
> 
text problems; shouldn't be in future versions.
>  * 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
>    ...".
> 
fixed
>  * Section 19.6.3 "Changes from RFC 2068", p146, third from last
>    paragraph: extra right bracket: "A new error code (416))".
> 
fixed
> 
> 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
> 
fixed
>  * 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".
> 
Left as is.  various blood was sweated on this in the first place,
and I expect/hope it is correct as is.
>  * 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.
> 
> 
added comment

"The User-Agent header field (section 14.43) can sometimes be used to 
determine that a specific client has a particular security hole which 
might be exploited. Unfortunately, this same information is often used 
for other valuable purposes for which HTTP currently has no better 
mechanism. " 

> Cross-references
> 
>  * Throughout: I'd like to see more cross-referencing.  Particularly,
>    against most occurrances of method names, field names, status and
>    warning codes.
> 
I'm out of energy on this topic.  I added some.

>  * 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".
> 
Made minor clarifications here.  Your suggestion doesn't work,
as it gets cumbersome.  I added "MUST level", "SHOULD level" requirements
instead to clarify this.

>  * 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.
> 
done.
>  * Section 3.3.1 "Full Date": needs forward-reference to section
>    19.3 (concerning the "year 2000 problem").
> 
done.
>  * 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.
> 
done
>  * Section 13.6 "Caching Negotiated Responses", first sentence refers
>    to section 12; 12.1 would be more accurate.
> 
done.
>  * Section 14.4 "Accapt-Language" should refer to section 3.10.
> 
done.
>  * Section 14.5 "Accept-Range" should refer to section 3.12.
> 
done.
>  * Section 14.15 "Content-Encoding", second para on p100 refers to
>    14.15 itself!
> 
Couldn't find this one.
>  * Section 14.15 "Content-Range" should refer to section 3.12.
> 
done.
>  * Section 14.21 "Expires", third paragraph refers to section 3.3;
>    3.3.1 would be more accurate.
> 
done.
>  * Section 14.24 "If-Match" should refer so section 3.11.
> 
done.
> 
> 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.
> 
done
>  * Section 5.3, "Request Header Fields": more alphabetical BNF:
>    "If-Match" should appear before "If-Modified-Since".
>
done.
>  * 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".
> 
No.  you gotta be very careful here.  These are not interchangable.
>  * Section 10.4.15 "414 Requestr URI Too Long": spurious extra
>    space before the full-stop at the end of the first sentence.
> 
fixed.
> * Section 13.1.4 "Explicit User Agent Warnings": spurious extra
>    full-stop at the end of the first paragraph.
> 
fixed
>  * 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).
> 
fixed
> 
> Things you know about, but I'll mention anyway
> 
>  * Throughout: The [jg] footnotes
> 
Word artifact; I'll see the plaintext is clean the next time.
>  * 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
> 
Flagged by [ref]
>  * Section 14.16 "Content-Range", second para on p104, "See appendix
>    Error! Reference source not found".
> 
fixed.
>  * Section 19.1 "Internet Media Type message/http and
>    application/http": screwy line-wrapping in the Encoding
>    considerations section of application/http.
> 
fixed.
>  * 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.
> 
fixed.
>  * 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 :-(
> 

The Word and Postscript versions should be fine in this area; I'll try 
 to make sure the text index is clean in the next version. But Word has 
 driven me to distraction with a bug I keep running into that causes it 
 to crash.

Received on Thursday, 3 September 1998 14:36:14 UTC