- From: Jim Gettys <jg@pa.dec.com>
- Date: Mon, 29 Mar 1999 07:45:56 -0800
- 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 08:08:37 UTC