More small edits to draft 04a

>1.3 Terminology
>
>semantically transparent
>   The use of a semantically transparent  cache would not affect either
>  the clients or the servers in any way except to improve performance.
>  When a client makes a request via a semantically transparent cache,
>  it would receive exactly the same entity-headers and entity-body it
>  would have received if it had made the same request to the origin
>  server, at the same time.

is seriously ugly.  A rewrite would be

 semantically transparent cache
   A cache that does not affect the semantics of a request and the resulting
   response.  A response is considered to be unaffected by the cache when
   the client receives a response equivalent to what it would have received
   if it had made the request directly to the origin server.

====================
There are extra spaces in the following lines (sorry about no context,
but it is probably easier to just do a Find in the Word version):

0242: 19.4 Differences Between  HTTP Bodies and RFC 1521 Internet Message
0507:   The use of a semantically transparent  cache would not affect either
0515:  is used to find out whether a cache entry is an equivalent  copy of
0931:and SHOULD be able to handle URIs of unbounded length if they  provide
0991:Characters other than  those in the "reserved" and the "unsafe" sets
1014:850  date format and lacks a four-digit year. HTTP/1.1 clients and
1123:or can be applied to an  entity. Content codings are primarily used to
1157:This document  defines a registration process which uses the Internet
1230:footer, which is  terminated by an empty line.  The purpose of the
1247:HTTP uses Internet Media Types  in the Content-Type (section 14.18) and
1290:an entity-body transferred via HTTP messages  MUST be represented in the
1504:message format of RFC 822  for transferring entities (the payload of the
1507:with nothing preceding the  CRLF) indicating the end of the header
1545:SHOULD  follow "common form" when generating HTTP constructs, since
1838:a transformed Request-URI  in forwarded requests.
2335:     transmitting the request.  If  the client sees an error status, it
2527:then the cache MUST treat the  cache entry as stale.
2943:cache MUST update the  entry  to reflect any new field values given in
3151:some servers using  fixed-length buffers for reading or manipulating the
3328:separated by a single colon (":") character, within a base64  encoded
3747:relax the cache's approximation of  semantic transparency.
4049:When a cache has a stale entry  that it would like to use as a response
4113:Entity Tags are described in section 3.11. The headers used with  entity
4256:change whenever the associated entity  changes in a semantically
4902:Character set values are described in section 3.4. Each charset  may be
4931:which is acceptable according to the Accept-Encoding  header, then the
5655:entity at the time of the request.  Future requests  MAY use the
5989:described in section 3.2.2).  The Host field value MUST represent  the
6049:c)If the variant  has not been modified since a valid If-Modified-Since
6335:(section 14.31) to limit the number  of proxies or gateways that can
6852:the recipient proxy or gateway, analogous to the User-Agent and  Server
7196:omit the sending of  Accept-Language headers by default, and to ask the
7205:if it detects, by looking for any Vary response-header fields  generated
7679:19.4 Differences Between  HTTP Bodies and RFC 1521 Internet Message
7714:requires that content with a  type of "text" represent line breaks as
7843:where allocation of many IP addresses to a single  host has created
8109:ignores Connection. Persistent connections are  the default for HTTP/1.1
8163:make supporting previous versions easy.  It is  worth noting that at the
8183:And  we would expect HTTP/1.1 clients to:

====================
Missing a space from:

1824:3.2.1.The origin server MUST decode the Request-URI in order to properly
6168:See section 3.11for rules on how to determine if two entity tags match.

====================
In the acknowledgments:

7314:       Paul J. Leach                      Frangois Yergeau

Should be Francois in 7bit text (a &ccedilla in the eventual HTML version).

====================
Last sentence of Section 1.4 (right above Section 2):

>closed for a variety of reasons.  See section 8.1.

should be

 closed for a variety of reasons (see section 8.1).

The same comment elsewhere that "See ..." is used as a sentence:

934:handle.  See section 10.4.15.
3791:revalidate" Cache-Control directive.  See section 14.9.

and in 3.2.2:

>avoided whenever possible.  (See RFC 1900[24].)  If the abs_path is not

should be 

 avoided whenever possible (see RFC 1900 [24]). If the abs_path is not


====================
3.2.3 URI Comparison has become discombobulated.  The first paragraph

>The canonical form for "http" URLs is obtained by converting any UPALPHA
>characters in host to their LOALPHA equivalent (hostnames are case-
>insensitive), eliding the [ ":" port ] if the port is 80, and replacing
>an empty abs_path with "/".

should be deleted.

The first bulleted item:

  .  A port that is empty or not given is equivalent to port 80.

should be

  o  A port that is empty or not given is equivalent to the
     default port for that URI;

The first three bullets should end in ";" and the last end with a period.

The sentence immediately after the bullets:

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

should be

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

====================
There are still a few places in the BNF where entity-header and
general-header are capitalized (they should be lowercase):

Section 3.6 (chunked):
1227:       footer         = *Entity-Header

Section 4.5:
1678:       General-Header = Cache-Control            ; Section 14.9

Section 7.1:
2081:       Entity-Header  = Allow                    ; Section 14.7

====================
Section 3.10, first paragraph, last sentence has an excess comma
"within the Accept-Language, and Content-Language fields."

====================
Section 3.11 is a bit off:

>Entity tags are used for comparing two or more entities from the same
>requested resource, and are transmitted using the ETag header field (see
>section 14.20. Entity tags consist of a quoted strings, whose internal
>structure is opaque to clients, possibly prefixed by a weakness
>indicator.

is both incorrect and missing the usual references. A better version:

 Entity tags are used for comparing two or more entities from the same
 requested resource. HTTP/1.1 uses entity tags in the Etag (section 14.20),
 If-Match (section 14.25), If-None-Match (section 14.26), and If-Range
 (section 14.27) header fields. An entity tag consists of an opaque quoted
 string, possibly prefixed by a weakness indicator.

The note following the BNF description:

>  Note that the weak tag is considered part of a weak entity tag; it
>  MUST NOT be removed by any cache or client.

is bogus and should be deleted (the weak indicator is IN the entity tag,
and thus cannot be separated by definition).  Lower down,

>A "weak entity tag," indicated by the "W/" prefix, may be shared by two
>entities of a resource only if they are equivalent and could be

is ambiguous -- it should be

 A "weak entity tag," indicated by the "W/" prefix, may be shared by two
 entities of a resource only if the entities are equivalent and could be

====================
The initial part of Section 3.12 is unnecessary:

>3.12 Range Protocol Parameters
>This section defines certain HTTP protocol parameters used in range
>requests and related responses.
> 
>3.12.1 Range Units
>An entity may be broken down into subranges according to various ...

should just be

 3.12 Range Units

 HTTP/1.1 allows a client to request that only part (a range of) the
 response entity be included within the response. 
 An entity may be broken down into subranges according to various ...

Actually, this section lacks the motivating text and header field
references that is present for the other protocol parameters.

====================
Section 4.1 should include a reference [9] after the mention of RFC 822
in the third paragraph.

Also, the last note of that section:

  Note: certain buggy HTTP/1.0 implementations and/or scripts
  generated extra CRLF's before/after a request.  To restate what is

should be

  Note: Certain buggy HTTP/1.0 client implementations generate an
  extra CRLF after a POST request.  To restate what is

since that is the only case known to exist.

====================
Section 4.2, last paragraph, must have been incorrectly changed after
I left the meeting in Palo Alto, because the last sentence

>     The order of multiple header fields with the same field-name
>MUST be preserved by proxies.

is wrong.  It should be

      The order in which header fields with the same field-name
are received is therefore significant to the interpretation of the
combined field value, and thus a proxy MUST NOT change the order of
these field values when a message is forwarded.

====================
More extra spaces:

4.3 Message Body
 The message-body (if any) of an HTTP message is used to carry the  ...

4.4 Message Length
 When a message-body is included with a message, the length of that body

====================
Time to send these out -- more later.


 ...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 07:06:59 UTC