editoral issues raised by Ross Patterson

To get into the mailing list archives....

Will be editorial issue "PATTERSON"...
			- Jim
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
jg@w3.org, jg@pa.dec.com

Forwarded message 1

  • From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
  • Date: Tue, 30 Dec 97 13:01:50 EST
  • Subject: HTTP editorial issues (21Nov97)
  • To: jg@w3.org
  • Cc: masinter@parc.xerox.com
  • Message-Id: <199712301846.AA04216@reston.vmd.sterling.com>
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.)

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

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

   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.

   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.

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

   7) (12.2) The first paragraph contains an unresolved reference for
      "... field-name Alternates, as described in appendix ...".

   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.

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

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

  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.

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

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

  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

  15) (14.48) The production for <t-codings> doesn't allow "identity", but
      rule 3 seems to allow "identity;q=0".

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

  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.

  18) (19.8.1) There are two odd line breaks in the phase "part of a

  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

Received on Wednesday, 14 January 1998 12:42:54 UTC