More small edits to draft 04a

Section 5.1.1, para after BNF:

>The list of methods acceptable by a plain resource can be specified in
>an Allow header field (section 14.7). The return code of the response
>always notifies the client whether a method is currently allowed on a
>resource, as which methods are allowed can change dynamically. ...

should be

 The list of methods allowed by a resource can be specified in 
>an Allow header field (section 14.7). The return code of the response
>always notifies the client whether a method is currently allowed on a
 resource, since the set of allowed methods can change dynamically. ...

Next paragraph:

>The methods GET and HEAD MUST be supported by all general-purpose
>servers. Servers which provide Last-Modified dates for resources MUST
>also support the conditional GET method. ...

needs to be more specific, a la

>The methods GET and HEAD MUST be supported by all general-purpose
 servers. Servers that provide Last-Modified dates for resources MUST
 also support the If-Modified-Since header field. Servers that provide
 entity tags for resources MUST also support the If-None-Match header
 field. These requirements allow cache update mechanisms to make
 efficient use of network bandwidth. ...

Either that, or just delete the second sentence in the original.

====================
Section 7, first paragraph is missing a comma
"consists of entity-header fields and an entity-body although some"
                                                    ^here
====================
Section 7.2, BNF

       Entity-Body    = *OCTET

should be

       entity-body    = *OCTET

====================
Section 7.2.1, first sentence

"body is determined via the header fields Content-Type, Content-Encoding."

should be

"body is determined via the header fields Content-Type and Content-Encoding."

and in the next real paragraph is missing a comma

"to the data, usually for the purpose of data compression that are a"
                                                         ^here
====================
Section 8 (all of it) should not be using the term "Negotiate" at all.
Persistence isn't negotiated -- it is either "signaled" or "ended",
depending upon the context.

====================
Section 8.1.2.1, last paragraph

>See section 4.4 on methods that can be used to indicate message length.
>Sending the Content-Length is the preferred technique. Chunked encoding
>SHOULD be used when the size of the entity-body is not known before
>beginning to transmit the entity-body. Finally, if neither Content-
>Length or chunked encoding are possible then the connection SHOULD be
>closed.  Note that the last method does not work if the entity-body is
>part of a request.

is redundant and should be deleted.  It can be replaced by

 In order to remain persistent, all messages on the connection must
 have a self-defined message length (i.e., one not defined by closure
 of the connection), as described in section 4.4.

====================
Section 8.1.2.2, first paragraph

>Clients and servers which support persistent connections MAY "pipeline"
>their requests and responses. When pipelining, a client will send
>multiple requests without waiting for the responses. The server MUST
>then send all of the responses in the same order that the requests were
>made.

needs to be rephrased as

 A client that supports persistent connections MAY "pipeline" its
 requests (i.e., send multiple requests without waiting for each
 response).  A server MUST send its responses to those requests 
 in the same order that the requests were received.

and the last paragraph in 8.1.2.2

>Clients and servers that support persistent connections MUST correctly
>support receiving messages via all message length determining techniques
>(see section 4.4).

is both redundant and unnecessary (the same is true for all clients
and servers that don't support persistent connections).

====================
>8.1.4 Interaction with Security Protocols
>It is expected that persistent connections will operate with both SHTTP
>[31] and SSL [32].
 
serves no useful purpose and should be deleted (along with references
[31] and [32]).

====================
Section 9.2.1 begins with "The writers of client software should",
which is just a verbose way of saying "Implementers should", and 
the latter is more accurate considering that the paragraph refers
to both client and server behavior.

====================
Section 9.3, last paragraph has

>by a change in Content-Length, Content-MD5, ETag or Content-Version),

which should be

 by a change in Content-Length, Content-MD5, ETag or Last-Modified),

====================
Sections 10.3.2-5 (status 301, 302, and 303), second paragraph in each

>If the new URI is a location, its URL MUST be given by the Location

needs to be changed to

 If the new URI is a location, its URL SHOULD be given by the Location

since there are times when the server desires to send a redirect
but does not want to allow the client to perform it automatically.

====================
Section 10.3.4, first paragraph, middle sentence:

"The new resource is not an reference for the original Request-URI."

should be

"The new URI is not a substitute reference for the originally requested
resource."

====================
Section 10.3.5, first paragraph

>respond with this status code. The response MUST NOT contain an message-
>body. Header fields contained in the response SHOULD only include
>information that is relevant to cache managers or that may have changed
>independently of the entity's Last-Modified date. Examples of relevant
>header fields include: Date, Server, Content-Length, Content-MD5,
>Content-Version, Cache-Control, ETag and Expires.

should be

 respond with this status code. The response MUST NOT contain a message-
 body. Header fields contained in the response SHOULD only include
 information that is relevant to cache managers or that may have changed
 independently of the entity's modification. Examples of relevant
 header fields include: Date, Server, Content-Length, Content-MD5,
 Cache-Control, ETag, Expires, Last-Modified, and Vary.

====================
10.4.10, first paragraph.   The "MAY" should be replaced by "might".

====================
Section 13 currently begins with

"The World Wide Web is a distributed system, and its performance can be
 improved by the use of caches. These caches are typically placed at
 proxies and in the clients themselves."

which should be replaced with

 HTTP is typically used for distributed information systems, where
 performance can be improved by the use of response caches.

Note that the original second sentence is wrong -- caches can be placed
anywhere except tunnels, as has already been explained in section 1.

====================
Section 13.4.1

 Accept-Ranges should be added to the list of hop-by-hop headers.

====================
Section 14.5 (Accept-Ranges)

The following paragraphs are absolutely wrong and must be deleted:

>The Accept-Ranges MUST NOT be added to a response by a proxy (i.e., it
>may only be added by the origin server), MUST NOT be forwarded by a
>proxy that does not support the Range header, and MUST NOT be returned
>to a client whose HTTP version is less than HTTP/1.1.
> 
>  Note: this rule allows a client to be reasonably sure that a
>  subsequent Range request on the entity will not accidentally
>  transfer the entire entity.  However, the subsequent Range request
>  may follow a different request chain, and so there is a small
>  chance that the entire entity will be returned in a response.

and the paragraph below it should begin with "Servers ..." instead
of "Origin servers ...".

The reason is because the Range header field is interpreted by the
next inbound server that has the entity cached -- not necessarily
the origin server -- and thus 14.5 is SEVERELY BROKEN in draft 04a.

====================
Section 14.19 (Date), the third real paragraph says

"However, since the date--as it is believed by the origin--is
 important for evaluating cached responses, origin servers MUST always
 include a Date header."

which should be

 However, since the date--as it is believed by the origin--is
 important for evaluating cached responses, origin servers MUST
 include a Date header field in all responses.

and the second paragraph below it

>Although origin servers MUST send a Date field in every response, if a
>cache receives a response without a Date field, it SHOULD attach one
>with the cache's best estimate of the time at which the response was
>originally sent.

is redundant and should be deleted.

====================
Sections 14.33 and 14.34 (Proxy-Auth...) still do not have the changes
that I mentioned before having to do with proxies forwarding Proxy-AA
fields which they did not request (and don't consume).

In section 14.33, replace

>Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
>only to the current connection and MUST NOT be passed on to downstream
>clients.

with

 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
 only to the current connection and SHOULD NOT be passed on to downstream
 clients.  However, an intermediate proxy may need to obtain its own
 credentials by requesting them from the downstream client, which in
 some circumstances will appear as if the proxy is forwarding the 
 Proxy-Authenticate header field.

In section 14.34, replace

>Unlike Authorization, the Proxy-Authorization applies only to the
>current connection and MUST NOT be passed on to upstream servers. If a
>request is authenticated and a realm specified, the same credentials
>SHOULD be valid for all other requests within this realm.

 Unlike Authorization, the Proxy-Authorization header field applies only
 to the next outbound proxy that demanded authentication using the 
 Proxy-Authenticate field. When multiple proxies are used in a chain,
 the Proxy-Authorization header field is consumed by the first outbound
 proxy that was expecting to receive credentials. A proxy MAY relay the
 credentials from the client request to the next proxy if that is the
 mechanism by which the proxies cooperatively authenticate a given
 request.

====================
Section 19.2 uses the wrong terminology

>19.2 MIME multipart/byteranges Content-type
>When an HTTP message includes the content of multiple ranges (for
>example, a response to a request for multiple non-overlapping ranges),
>these are transmitted as a multipart MIME message.  The multipart MIME
>content-type used for this purpose is defined in this specification to
>be "multipart/byteranges".
> 
>The MIME multipart/byteranges content-type includes two or more parts,
>each with its own Content-Type and Content-Range fields.  The parts are
>separated using a MIME boundary parameter.

should be

 19.2 Internet Media Type multipart/byteranges

 When an HTTP message includes the content of multiple ranges (for
 example, a response to a request for multiple non-overlapping ranges),
 these are transmitted as a multipart MIME message.  The multipart media
 type defined for this purpose is called "multipart/byteranges".
 
 The multipart/byteranges media type includes two or more body-parts,
 each with its own Content-Type and Content-Range fields.

AND then concluding with the registration template (where is it???).
It should look very similar to the one provided for "message/http".

====================
Section 19.4 is mistitled

"Differences Between  HTTP Bodies and RFC 1521 Internet Message Bodies"

when it should be

 Differences between HTTP Entities and RFC 1521 Entities

====================
Section 19.6 would be simpler if the mid-section titles for

>19.6.1 Additional Request Methods
>19.6.2 Additional Header Field Definitions

and the lower-level subsections moved up a level.  Also,

>19.6.2.6 Compatibility with HTTP/1.0 Persistent Connections

and its subsection should be moved to the section on

>19.7 Compatibility with Previous Versions

and really should be rewritten as well ... *sigh*

Finally, section 19.6.1.4 is not necessary and can be deleted.

====================
That's it for the small edits.  Note, however, that I still don't
think that the sections on Caching and Cache-Control have received
adequate review.  More on that in its own message.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Monday, 3 June 1996 10:09:27 UTC