Re: HTTP 1.1 document terminology.

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

"plain" is not an antonym of "generic" -- I still prefer my definitions
of group-resource and individual resource over anything else proposed.

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

If-NoMatch is not the same meaning as "Unless-Match", and we want the
meaning of the latter.  Please change it, or at least to
"If-Not-One-Of-These-Etags" (a.k.a. "Unless-Etag") or something which
is logically equivalent to its purpose.

> 	5) I also renamed Range-If to If-Range, for the hobgoblin 
> 		of consistency.

I think we should just delete Range-If -- the usage is not compelling
enough to add the complexity.

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

These two are wrong.  The correct definitions are

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

  resource entity
      A particular representation, rendition, encoding, or presentation
      of an [individual|plain] resource that could be enclosed in a 200
      response to a GET request on that resource.  Likewise, the
      Entity-Header fields of a resource entity could be enclosed in a
      200 response to a HEAD request, parts of the Entity-Body of a
      resource entity could be enclosed in a 206 response to a partial
      GET request, and a new resource entity could be enclosed in a
      PUT request.  An [individual|plain] resource MUST be bound to a
      single resource entity at any instant in time.

The specificity of this definition is necessary and cannot be removed
without making it ambiguous as to which entity is being referenced.
A "resource entity" is an entity, not a resource.

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

Likewise, the above is incorrect

  entity tag
     A string associated with an entity and used to distinguish it
     from other entities of the requested resource.  A "strong entity tag"
     is one that may be shared by two entities of a resource only if they
     are equivalent by octet equality.  A "weak entity tag" is
     one that may be shared by two or more entities of a resource if they
     are semantically equivalent.  A given entity tag value may be used for
     entities obtained by requests on different URIs without implying
     anything about the equivalence of these entities.

[assuming the variant-id is still part of the entity tag, which it must
be if we are going to allow variant-ids at all].


 ...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 Tuesday, 30 April 1996 21:42:20 UTC