Re: editoral issues raised by Ross Patterson

>  From: "Ross Patterson" <Ross_Patterson@ns.reston.vmd.sterling.com>
>  Date: Tue, 30 Dec 97 13:01:50 EST
>  To: jg@w3.org
>  Cc: masinter@parc.xerox.com
>  Subject: HTTP editorial issues (21Nov97)
>  
>  I just finished a cover-to-cover reread of draft-ieft-http-v11-spec-rev-01,
>  the 21 November 1997 HTTP 1.1 draft.  I don't know how many of these you've
>  heard about, but I thought I'd pass them along.
>  
>     1) (TOC) Lots of section-numbering errors ("1.1.2" following "8.1.1", etc.)
>  

Microsoft Word often loses its cookies in section numbering; I didn't
catch that its cookies were lost when I generated the postscript in the
last draft (may have to do with what time of night I generated it).  I give
Word at best a B- as a word processing tool...

I'll try to make sure the next draft doesn't have the problem.

>     2) (4.1) The note reads "... client implementations generate an extra
>        CRLF's after ...".  That's either "an extra CRLF" or "some extra CRLF's".
>  

"extra CRLF's" seems to be right.

>     3) (8.1.3) The third paragraph contains an unresolved reference for
>        "information about the Keep-Alive header ...".
> 

I deleted the KeepAlive section from this document, and forgot the change
the reference to the section to RFC 2068 instead.  We don't need to
keep things not part of the standard that we may need to reference
once we have them in an RFC somewhere (in this case, 2068).
Thanks....
 
>     4) (8.1.4) The third paragraph reads "For example, a client MAY have
>        started to send ...".  I think you mean "may", not "MAY", as this isn't
>        a requirement statement.
>  

Yup. You are right...

>     5) (8.1.4) The fourth paragram ends with "However, this automatic retry
>        SHOULD NOT be repeated if the second request fails."  I think you mean
>        the second retry of the sequence of requests, not the second request of
>        the sequence.
>  

I modified the last sentence to say:
"The automatic retry SHOULD NOT be repeated if the second sequence of requests
fails."

>     6) (11.1) There is a dangling "Scheme" at the end of the sentence.
>  

Deleted.

>     7) (12.2) The first paragraph contains an unresolved reference for
>        "... field-name Alternates, as described in appendix ...".
>  
Deleted the dangling reference, as it isn't needed...

>     8) (13.2.3) The third paragraph claims that "... HTTP/1.1 requires
>        origin servers to send a Date header with every response ...", but that
>        contradicts (14.19) where there are rules for when a server doesn't
>        have to supply a Date header.
>  

Covered in a different message to come.

>     9) (13.2.3) The fourth paragraph contains the repeated phrase "HTTP/1.1
>        uses the Age response header to".

Yup.  Fixed.

>  
>    10) (13.2.6) The second paragraph reiterates the claim that "... the HTTP/1.1
>        specification requires the transmission of Date headers on every
>        response".

Covered in a different message to come.

>  
>    11) (13.5.1) There is an extra bullet in the list of hop-by-hop headers, and
>        again in the list of headers that a non-caching proxy MUST NOT modify.
>  

Should be fixed now.

>    12) (13.6) The fifth paragraph reads "A Vary header field-value of "*"
>        always fail to match ...".  It should read "... always fails to ...".
>  

Fixed.

>    13) (14.15) There is an extra period at the end of the first sentence.
> 

Fixed.

>    14) (14.32) The second paragraph ends "Clients SHOULD include both header
>        fields when a no-cache request is sent to a server not known to be
>        HTTP/1.1 compliant."  The fourth paragraph beings "HTTP/1.1 clients
>        SHOULD NOT send the Pragma request-header."  This seems to be a
>        contradiction.
>  

Covered in a separate message to come.

>    15) (14.48) The production for <t-codings> doesn't allow "identity", but
>        rule 3 seems to allow "identity;q=0".
> 
Here's Henrik's clarification:
it is not that "identity" isn't allowed - the problem
is that chunked is special - due to backwards compatibility concerns.

In general, all transfer-codings can have parameters associated with them
(both in Transfer-Encoding and TE header fields) and they can be assigned a
q-value when they are listed in the TE header.

However, chunked is special in that it can't have any parameters and it
can't have a qvalue when listed in the TE header field. This is why chunked
is treated specially in the BNF for both Transfer-Encoding and TE. All
other transfer-codings, including "identity" are included in the
transfer-extension contruct.

The current wording is therefore correct - but it merits a note like
this in the TE section:

        Note: Because of backwards compatibility considerations
        with RFC 2068, the "chunked" transfer-coding can not be used
        with parameter or accept-params.
 
>    16) (15.1) This section looks like it no longer belongs in the document,
>        since there is no actual discussion of Basic authentication in the
>        HTTP/1.1 spec.  It is also duplicated in the authentication draft
>        (draft-ietf-http-authentication-00, 21 November 1997, section 4.1).
>  

Yup.  You are right.  I like deleting material :-).

>    17) (19.3) The fourth paragraph states "... no label is preferred over the
>        labels US-ASCII or ISO-8859-1."  That can either be read as "There is
>        no label that we prefer more than US-ASCII and ISO-8859-1" or "We
>        prefer an unlabeled character set over the US-ASCII and ISO-8859-1
>        labels."  I'm confused enough that I can't even guess which was meant.


I've clarified this to:
"The character set of an entity-body should be labeled as the lowest common 
denominator of the character codes used within that body, with the exception 
that not labeling the entity is preferred over labeling the entity with 
the labels US-ASCII or ISO-8859-1. See section 3.7.1."

>  
>    18) (19.8.1) There are two odd line breaks in the phase "part of a
>        quoted-string".
>  

Yes, that is exactly the point.  But indenting the lines may make it clearer,
so I've indented it...

>    19) (19.8.3) This section begs for either a citation of the old
>        specification or a description of it.
>  
>  Many thanks to you and the rest of the editting group - this is a mammoth
>  work and of great importance to a lot of us.
>  
>  Ross Patterson
>  Sterling Software, Inc.
>  VM Software Division

--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com