W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1999

FINAL: minor editorial issues in draft-ietf-http-v11-spec-rev-06.txt

From: Jim Gettys <jg@pa.dec.com>
Date: Mon, 29 Mar 1999 07:45:56 -0800
Message-Id: <9903291545.AA21598@pachyderm.pa.dec.com>
To: RFC Editor <rfc-ed@ISI.EDU>
Cc: http-wg@hplb.hpl.hp.com, moore@cs.utk.edu, masinter@parc.xerox.com
I've finally gotten to put the edits for the rfc editor together in
one file (this one), in order, in the format the RFC editor likes.

They are relative to the draft: draft-ietf-http-v11-spec-rev-06.txt.  No
one seems to have reported any others for a while, so lets put this puppy
to bed, and get the RFC issued.

Keith: this is it, as far as I'm concerned.  It is your judgement as to
whether you want to have the IESG look these over.

HTTP working group: Unless very serious, forever hold your peace (or at 
least until we prepare the full standard draft).  You should have spoken 
up by now (several times).  Please check for any final editing mistakes 
I may have made. After the RFC editor has done their job on a plaintext 
version, I'll produce a postscript version we'll also distill to PDF; 
I'm still looking for a reasonable way to get to clean HTML and XML.

				Your editor,
				- Jim Gettys
References:
http://www.ics.uci.edu/pub/ietf/http/hypermail/1999q1/0055.html
http://www.ics.uci.edu/pub/ietf/http/hypermail/1999q1/0058.html
http://www.ics.uci.edu/pub/ietf/http/hypermail/1999q1/0062.html

=======================
Section 3.2.2 change:

OLD:
    http_URL = "http:" "//" host [ ":" port ] [ abs_path ]

NEW:
    http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
                                                         ^^^^^^^^^^^^^

This is another artifact of the removal of the URI syntax in
deference to RFC 2396.
===========================

section 3.2.3 URI comparison

OLD:
   Characters other than those in the "reserved" and "unsafe" sets (see
   section 3.2) are equivalent to their ""%" HEX HEX" encoding.

NEW:
   Characters other than those in the "reserved" and "unsafe" sets (see
   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
   ^^^^^^^^^^^^^

Change 'section 3.2' to 'RFC 2396 [42]'. The definition of URI syntax
had been removed so the reference was wrong.
==========================
Section 3.6.1 "Chunked Transfer Coding"
OLD:
   trailer        = *entity-header

NEW:
   trailer        = *(entity-header CRLF)
                     ^             ^^^^^^
Note that these are all the same error, and it's been in the spec
since the very first draft (November 28, 1994).  *sigh*
================
4.1 Message Types:
OLD:
        generic-message = start-line
                          *message-header

NEW
        generic-message = start-line
                          *(message-header CRLF)
                           ^              ^^^^^^

Note that these are all the same error, and it's been in the spec
since the very first draft (November 28, 1994).  *sigh*
================
4.2 Message Headers:
OLD:
       message-header = field-name ":" [ field-value ] CRLF
                                                      ^^^^^

NEW:
       message-header = field-name ":" [ field-value ]

Note that these are all the same error, and it's been in the spec
since the very first draft (November 28, 1994).  *sigh*
================
5 Request
OLD
        Request       = Request-Line              ; Section 5.1
                        *( general-header         ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header )        ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3
NEW
        Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                          | request-header        ; Section 5.3
                          | entity-header ) CRLF) ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3

Note that these are all the same error, and it's been in the spec
since the very first draft (November 28, 1994).  *sigh*
================
6 Response
OLD
       Response      = Status-Line               ; Section 6.1
                       *( general-header         ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header )        ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2
NEW
       Response      = Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                         | response-header       ; Section 6.2
                         | entity-header ) CRLF) ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2

Note that these are all the same error, and it's been in the spec
since the very first draft (November 28, 1994).  *sigh*
==========================
Section: 8.1.4 Practical Considerations, last paragraph:

OLD:
   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD NOT maintain more than connections with any

NEW:
   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD NOT maintain more than 2 connections with any
                                                    ^

Missing "2" connections.  Very important! 
=======================
Section 8.2.3, first sentence:

OLD:
   The purpose of the 100 (Continue) status (see section 10.1.1) is to
   allow an client that is sending a request message with a request body

NEW:
   The purpose of the 100 (Continue) status (see section 10.1.1) is to
   allow a client that is sending a request message with a request body
         ^^
change "an client" to "a client"

======================
Section 8.2.4
OLD:
   connection close before receiving any status from the server, the
   client SHOULD retry the request, subject to the restrictions in
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   section 8.2.3. If the client does retry this request,
^^^^^^^^^^^^^^^^

NEW:
   connection close before receiving any status from the server, the
   client SHOULD retry the request. If the client does retry this request,


Delete the phrase
  ", subject to the restrictions in section 8.2.3"
since section 8.2.3 was deleted.

========================
Section 12.2:

OLD:
   With agent-driven negotiation, selection of the best representation
   for a response is performed by the user agent after receiving an
   initial response from the origin server. Selection is based on a list
   of the available representations of the response included within the
   header fields (this specification reserves the header name
   Alternates) or entity-body of the initial response, with each
   representation identified by its own URI. Selection from among the
   representations may be performed automatically (if the user agent is
   capable of doing so) or manually by the user selecting from a
   generated (possibly hypertext) menu.

NEW:
   With agent-driven negotiation, selection of the best representation
   for a response is performed by the user agent after receiving an
   initial response from the origin server. Selection is based on a list
   of the available representations of the response included within the
   header fields or entity-body of the initial response, with each
   representation identified by its own URI. Selection from among the
   representations may be performed automatically (if the user agent is
   capable of doing so) or manually by the user selecting from a
   generated (possibly hypertext) menu.



delete the phrase "(this specification reserves the header name
Alternates)"
since the reservation was in RFC 2068 but has since been removed.
======================
section 13.5.1:
OLD:
      . Proxy-Authorization

      . Transfer-Encoding

      . Upgrade

NEW:
      . Proxy-Authorization

      . TE
      ^^^^

      . Trailers
      ^^^^^^^^^^

      . Transfer-Encoding

      . Upgrade


Add 'TE' and 'Trailer' to the list of Hop-by-Hop headers.
======================
section 14.9 Cache Control:

OLD:
         | "max-age" "=" delta-seconds            ; Section 14.9.4

NEW:
         | "max-age" "=" delta-seconds            ; Section 14.9.3
                                                                 ^


change the reference to 'Section 14.9.4' to 'Section 14.9.3'

======================
Add at the end of section 14.32:

        Note: because the meaning of "Pragma: no-cache" as a
        response header field is not actually specified, it does not
        provide a reliable replacement for "Cache-control: no-cache"
        in a response.

======================
Section 14.11:

OLD:

   If the content-coding of an entity is not "identity", then
   the response MUST including a Content-Encoding
NEW:
   If the content-coding of an entity is not "identity", then
   the response MUST include a Content-Encoding
                           ^

change 'including' to 'include'.

======================
21 Index:

OLD:
  URI. See RFC 2068                     wkday, 21
New:
  URI. See RFC 2396                     wkday, 21
  ^^^^^^^^^^^^^^^^^

Update reference to URI draft standard syntx document
======================
Received on Monday, 29 March 1999 16:47:41 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:30 EDT