Re: Variant-ID proposal

Paul Leach:
>
>This in general sounds good to me.
>
>>----------
>>From:  koen@win.tue.nl[SMTP:koen@win.tue.nl]
>>Sent:  Tuesday, April 23, 1996 1:10 PM
>>Subject:       Re: Variant-ID proposal
>

>
>        [ omission...]
>
>>- To summarize, I propose the following:
>>    - variant-IDs are quoted-strings
>>    - all responses from varying resources, whether they use
>>      Vary or Alternates, SHOULD include variant-ids
>
>Why not say that if there's a Vary:, there MUST be a variant-id?

The main part of the discussion was about whether there should be a
variant-id if there is no Vary but only Alternates.  

I do not like a MUST for inclusion of a variant-id.  Variant-ids make
caches more efficient, but if you do not include them, this will not
prevent caches from being correct.

>>    - if a response from a varying resource does not include a
>>      variant-id, the resource author may not assume that caching
>>      services will be provided for the response.
>
>Don't fully uderstand this. If there's no Vary: header, and no
>variant-id, then the cache will think its not a varying resource, and
>will cache it as if it wasn't. If there is a Vary and no variant-id, I
>don't know what it means

The presence of a vary header implies that it is a varying resource.
The presence of a variant-id means only that the origin server
included one.

> -- I'd be inclined to disallow servers from
>sending it, and/or say that caches should not cache such responses. (Is
>that what you meant?)

Whay I mean is that if Vary is included but no variant-id is included,
the resource author can expect the cache to work correctly, but cannot
expect it to work efficiently.

>>    - When using If-Invalid in requests on on varying resources, only
>>      the Cval: header values of cached responses with variant-IDs can
>>      be included
>>    - Cache replacement (throwing old entity instances out of cache
>>      memory because fresher ones that replace them are received)
>>      happens using variant-ids, there is no talk about
>>      Content-Location headers
>
>Does this mean that we delete Content-Location header from 1.1?

I don't think so, it has some other uses.  Side issue: I don't like
most of the current Location header text: it is over-specific about
negotiation without there being any need for this.

>>    - Plain 1.1 proxies are never allowed to add variant-IDs to cached
>>      responses which do not have them, but caches operating under a
>>      future content negotiation specification are allowed to
>>      construct the same variant-ID the origin server uses when
>>      constructing a 200 response out of separately cached components
>>      on behalf of the origin server.
>
>Why say anything at all about this in the 1.1 spec?

We don't need to say anything about this in the spec.  The above is
only important in the context of the discussions we have been having.

[...]
>>Now, if you agree to the changes outlined above, and if Jeff agrees
 [Note: the `you' above is Roy]
>>too, I would feel safe in drafting the required edits in private
>>e-mail with Jeff and in asking Jim Gettys to perform the edits.
>
>Why not post the suggestions to the the list, after you and Jeff
>agree?

We would of course also post them to the list.

>Paul

Koen.

Received on Thursday, 25 April 1996 23:35:44 UTC