Re: Last gasp terminology issue

Roy T. Fielding:
>
>Jeff said:
>> So I'll make one last attempt to suggest that the term "variant"
>> is the wrong one.  I'd still support Koen's suggestion of "entity
>> source" as the best compromise (given the extremely misleading but
>> historically accepted misuse of the term "entity").  Among other
>> things, it fits nicely as a directly replacement for the text
>> of the definition of "variant".  I.e., this
>> 
>>     variant
>>       Each representation of that resource that corresponds to a different
>>       sequence of entities that could be returned for a requested resource
>>       is termed a variant.
>> 
>> would become
>> 
>>     entity source
>>       Each representation of that resource that corresponds to a different
>>       sequence of entities that could be returned for a requested resource
>>       is termed an entity source.

I find the 04 draft variant definition fatally confusing, and while
changing it to `entity source' at least makes my problems with the IMS
section disappear, it does not take away the problem that I can't
parse the above text.

>
>Ummm, while that is better than variant, the definition is still bogus.
>I was going to correct that in 04a (I did in 03), but Jim suggested I
>wait until we had a clean draft to look at.  A better one is
>
>      entity source
>        The most specific resource corresponding to a representation.
>        This may be separate from the requested resource.

I think this is circular: you would need to talk about plain
vs. generic resources, and some plain resources not having an URI, to
get this right.  Read
http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q2/0394.html to see
what I mean.

>
>but I still think that the term just isn't needed.

I believe we indeed don't need the term.  However, most of the
rewrites you give below do not really improve the situation for me.

Reasoning from first principles, it would be logically possible to
eliminate the term `variant' by unfolding each use of it `variant' to
a longer piece of text and then simplifying.  Something like

  if the variant has been changed since...

would become

  if the representation that will be returned for this request
  has changed since...
  
I'm too tired to try this on the whole spec right now, though.

[...]

>  Let's look at its
>occurrences within the draft.  Oooh, it looks like some of these are
>now seriously wrong.
>
>Draft 04 says:
>=============================
>> 14.24 If-Modified-Since
>>  
>> The If-Modified-Since request-header field is used with the GET method
>> to make it conditional: if the requested variant has not been modified
>> since the time specified in this field, an entity will not be returned  ...
>
>The above is a protocol error.  IMS applies to the resource as a whole,
>not to any single variant.

I do not agree that this is a protocol error.  I always assumed that
the Last-Modified header applied to the variant, not to the whole
resource.

It is very time-consuming, if not plainly infeasible, for a server to
compute a collective last-modified value for all variants of a
negotiated resource, especially if these variants are not all stored
on the same origin server.  

If 
  a) the dates in IMS and If-unmodified-since are for the whole resource 
and
  b) servers MUST implement If-unmodified-since

then HTTP/1.1 is FATALLY broken, because it will not allow easy
implementation of content negotiated resources.

I would agree to your proposed change if servers were allowed not to
implement IUS for a resource if they never return Last-Modified dates
in responses for the resource.

[....]

>We (Henrik and I) spent a long time getting people to understand and
>accept that definition of the semantics of last-modified, and that
>work must not be thrown out at the last minute.

I am not aware of ever having been educated by about the fact that
that last-modified applied to the negotiable resource and all of its
variants as a whole.  I always assumed it applied to the individual
variants.

> ...Roy T. Fielding

Koen.

Received on Tuesday, 4 June 1996 13:40:28 UTC