Re: HTTP 1.1 document terminology.

By the reactions I got (and when I reread my message) it is pretty
clear my cold (or the drugs I took for it) did not improve my last
message on terminology.  It did have the effect of clarifying where a
number of people do have slightly different ideas for the same term.
In particular, different people seem to have different concepts of 
what a variant is.

In any case, this is the terminology I plan to go with in the next draft.
Some of the definitions probably need tweaking; I suspect people
will be happier with what is below than the previous definitions.

Right now, I'm more concerned with getting each term used where it should
be than quibbiling over the exact definition.  

Koen suggested "plain resource" rather than "specific resource".  I
accepted this suggestion, as it got us out of various regarding the use
of specific elsewhere in the document, and it has the right connotation.

Jeff suggested "resourcelet" as a place-holder for what Roy called
"resource entity".  While not happy with resource entity, I ended up
even less happy with resourcelet.  So I'm going with resource entity
(which I am less unhappy with), and unless someone magically generates
a better name instantaneously (I'm tired of going back and forth on
this one, so it would have to be pretty good).

So the explicit renames are:
	1) I'm changing the name of the CVal header to ETag.  
	2) I changed the name of the If-Valid header to If-Match.  
	3) I call If-Invalid If-NoMatch.  
	4) Roy would prefer If-NoMatch to be called Unless-Match.  
		But we don't have any other Unless'es at the moment, 
		so I currently believe If-NoMatch to be better.
	5) I also renamed Range-If to If-Range, for the hobgoblin 
		of consistency.


I'm now trying to plow my way through the rest of the editing.
				- Jim




Terminology 

This specification uses a number of terms to refer to the roles played
by participants in, and objects of, the HTTP communication.

connection

A transport layer virtual circuit established between two application
programs for the purpose of communication.

message

The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in section 8 and
transmitted via the connection.

request

An HTTP request message as defined in section 9.

response

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).  When represented electronically, a resource may be
either a plain resource, which corresponds to only one possible
representation, or a generic resource.

generic resource

A resource that is a set of closely related representations of the
same document, form, applet, etc. A generic resource is always
identified by a URI. The individual representations may each be
identified by a unique URI, or by the combination of the generic
resource's URI and a variant-ID, or by the combination of the generic
resource's URI and some "content-negotiation" mechanism.  In this
case, other URIs may exist which identify a resource more
specifically.

plain resource

A resource that is not a generic resource.  A plain resource is always
identified by a URI.

entity

The set of information transferred as the payload of a request or
response, representing a resource entity.  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.

resource entity

A specific representation, rendition, encoding, or presentation of a
network data object or service, either a plain resource or a specific
member of a generic resource.  A resource entity might be identified
by a URI, or by the combination of a URI and a variant-ID, or by the
combination of a URI and some other mechanism.

variant

A resource entity 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.

content negotiation

The mechanism for selecting the appropriate variant of a generic
resource when servicing a request, as described in section 15.

entity tag

An opaque string associated with an entity and used to distinguish it
from other instances of the same resource entity.  A "strong entity
tag" is one that may be shared by two entities of a resource entity
only if they are equivalent by octet equality.  A "weak entity tag" is
one that may be shared by two entities of a resource entity if they
are semantically equivalent.  A given entity tag value may be used for
entities identified by two different URIs, or by the same URI and two
different variant-IDs, without implying anything about the equivalence
of these entities.

client

An application program that establishes connections for the purpose of
sending requests.

user agent

The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.

server

An application program that accepts connections in order to service
requests by sending back responses. Any given program MAY be capable
of being both a client and a server; our use of these terms refers
only to the role being performed by the program for a particular
connection, rather than to the program's capabilities in
general. Likewise, any server MAY act as an origin server, proxy,
gateway, or tunnel, switching behavior based on the nature of each
request.

origin server

The server on which a given resource resides or is to be created.

proxy

An intermediary program which acts as both a server and a client for
the purpose of making requests on behalf of other clients. Requests
are serviced internally or by passing them on, with possible
translation, on to other servers. A proxy MUST interpret and, if
necessary, rewrite a request message before forwarding it. Proxies are
often used as client-side portals through network firewalls and as
helper applications for handling requests via protocols not
implemented by the user agent.

gateway

A server which acts as an intermediary for some other server. Unlike a
proxy, a gateway receives requests as if it were the origin server for
the requested resource; the requesting client may not be aware that it
is communicating with a gateway. Gateways are often used as
server-side portals through network firewalls and as protocol
translators for access to resources stored on non-HTTP systems.

tunnel

An intermediary program which is acting as a blind relay between two
connections. Once active, a tunnel is not considered a party to the
HTTP communication, though the tunnel may have been initiated by an
HTTP request. The tunnel ceases to exist when both ends of the relayed
connections are closed. Tunnels are used when a portal is necessary
and the intermediary cannot, or should not, interpret the relayed
communication.

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 16.  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.

firsthand

A response is firsthand if it comes directly and without unnecessary
delay from the origin server, perhaps via one or more proxies.  A
response is also firsthand if its validity has just been checked
directly with the origin server.  explicit expiration time The time at
which the origin server intends that an entity should no longer be
returned by a cache without further validation.  heuristic expiration
time An expiration time assigned by a cache when no explicit
expiration time is available.

age

The age of a response is the time since it was generated by, or
successfully validated with, the origin server.

freshness lifetime

The length of time between the generation of a response and its
expiration time.

fresh

A response is fresh if its age has not yet reached its freshness lifetime.

stale

A response is stale if its age has passed its freshness lifetime. A
cache may use a fresh response without validating it, but "normally"
may not use a stale response without first validating it.  ("Normally"
means "unless configured to provide better performance at the expense
of transparency.")  Therefore, what expires is the cache's authority
to use a cached response, without validation, in its reply to a
subsequent request.

semantically transparent 

Ideally, an HTTP/1.1 cache would be "semantically transparent." That
is, use of the 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 receives 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.

validator

An entity tag, or a Last-Modified time, which is used to find out
whether a cache entry is a semantically transparent copy of a resource
entity.  A cache entry is semantically transparent if its validator
exactly matches the validator that the server would provide for
current instance of that resource entity.

Received on Tuesday, 30 April 1996 06:39:27 UTC