Re: HTTP 1.1 document terminology.

A few quibbles ...

> ...  IfValid, and IfInvalid become IfMatch and IfNoMatch, and so
> forth.

That should be "If-Match" and "Unless-Match", for consistency with
other (past and future) conditions.

> request
> -------
> An HTTP request message (as defined in section 9).

  An HTTP request message, as defined in section 9.

> response
> --------
> An HTTP response message (as defined in section 10).

  An HTTP response message, as defined in section 10.

> resource
> --------
> A network data object or service that can be identified by a URI
> (section 7.2). A "resource" is a concept (a little like a
> Platonic ideal).  When represented electronically, a resource may be
> of the kind which corresponds to only one possible bit stream
> representation.  An example is the text version of an Internet
> RFC. That never changes. It will always has the same checksum.

Bad example -- RFCs do change (obsoleted, updated, etc. in header).
In any case, this places too much focus on bit streams (which do not
have anything to do with a resource aside from being one representation
resulting from a GET.  Keep in mind that a resource is essentially the
same as an "Object" in OO design methodology, and thus is more than just
the data representation even when that is static.

I prefer the original, since the additional wording just confuses things.

  resource
  --------
  A network data object or service that can be identified by a URI
  (section 7.2).

> generic resource
> ----------------

> On the other hand, a resource may be generic in that as a concept it
> is well specified but not so specifically specified that it can only
> be represented by a single bit stream.  In this case, other URIs may
> exist which identify a resource more specifically. These other URIs
> identify resources too, and there is a relationship of genericity
> between the generic and the relatively specific resource.  As an

I would prefer a more concise (and less circular) definition:

  A resource that provides a generic interface to one or more other
  resources.  In this case, other URIs may exist which identify the
  resource(s) more specifically.  As an
> example, successively specific resources might be
> 
> 1. The Bible
> 2. The Bible, King James Version
> 3. The Bible, KJV, in English
> 4. A particular ASCII rendering of the KJV Bible in English
> 
> Each resource may have a URI.  The authority which allocates the URI
> is the authority which determines to what it refers: Therefore, that
> authority determines to what extent that resource is generic or
> specific.  When we discuss electronic resources, an interesting fact
> is that a small number of dimensions of genericity emerge.
> 
> Time
> A resource may vary with time. For example, "The Wall Street Journal"
> varies with time. Each issue is a time-specific resource, which does
> not change with time. Most home pages on the Web change with time, in
> a less periodic way.

NOTE: Allowing time to be a dimension of genericity will mean that almost
all resources will be generic, including those that are non-negotiable
at a particular instant in time.  Is this useful?

> Language
> When a document is translated, it is useful to be able to refer to it
> either in the generic, or to a particular specific translation.
> 
> Representation
> A given resource may have many ways in which it can be represented on
> the wire, using different Content-Types (section 18.19).  As an
> example, an image may be represented in PNG or GIF format.
> 
> specific resource
> -----------------
> A resource that is not a generic resource.
> 
> variant
> -------
> An specific resource that is a member of at least one generic
> resource.  Sometimes called a resource variant.  Note that the set of
> variants of a generic resource may change over time as well.

  A specific resource that is a member of at least one generic
> resource.  Sometimes called a resource variant.  Note that the set of
  variants of a generic resource may change over time.

> entity
> ------
> The set of information transferred as the payload of a request or
> response.  An entity consists of metainformation in the form of
> Entity-Header fields and content in the form of an Entity-Body, as
> described in section 11 
  described in section 11.
  
> resource entity
> ---------------
> A particular representation, rendition,
> encoding, or presentation of a resource at a particular point in time.
> Resources not supporting content negotiation are bound to a single
> entity.  Generic resources supporting content negotiation are bound to
> a set of one or more entities, whose membership may vary over time.
> 
> content negotiation
> -------------------
> The mechanism for selecting the appropriate variant of a generic
> resource when applying a request, is described in section 15.
                                    as
> ...
> 
> cache
> -----
> A program's local store of response messages and the subsystem that
> controls its message storage, retrieval, and deletion. A cache stores
> cachable responses in order to reduce the response time and network
> bandwidth consumption on future, equivalent requests. Any client or
> server MAY include a cache, though a cache cannot be used by a server
> while it is acting as a tunnel.

  cachable
  --------
  A response is cachable if a cache is allowed to store a copy of the
  response message for use in answering subsequent requests. The rules for
  determining the cachability of HTTP responses are defined in Section XX.
  Even if a resource is cachable, there may be additional constraints on
  when and if a cache can use the cached copy for a particular request.

>...
> validator
> ---------
> A tag or a Last-Modified date and time used to validate whether a cache 
> entry is "fresh" or "stale."

  An entity tag or Last-Modified value when used to validate whether a cache 
  entry is "fresh" or "stale."


 ...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, 29 April 1996 16:05:23 UTC