Re: Variant-ID proposal

[Note for the reader: a discussion of a simplification to the current
draft spec follows.]

Roy T. Fielding:
>
>> Proxies will have to generate variant-IDs like
>> "http://other.org/xx.gif" using a cached Alternates header sometimes,
>> this is why I do not want variant-ids to be tokens.  If they were
>> tokens, we would need horrible string-to-token conversion rules in the
>> content negotiation spec.
>
>Proxies must not generate variant-IDs -- there is no way that would
>work in a system where the client is not always required to use the
>same set of caches.

I think we are are still some misunderstandings between us.  I never
proposed that proxies under plain 1.1 would be allowed to invent
variant-IDs from scratch.  The construction of variant-ids by proxies
would be only allowed according to rules in the future content
negotiation specification, and of course all proxies would be obliged
to generate the same variant-ID that the origin server would generate.

Here is what I am saying:

- We currently have two mechanisms for use with If-Invalid and varying
  resources in the spec:

  mechanism 1:

      3.15 Validator Sets
      Validator sets are used for doing conditional retrievals on varying
      resources; see section 13.8.4.

            validator-set = 1#validator-set-item
            validator-set-item = opaque-validator

      13.8.4 Use of Selecting Opaque Validators

      If the origin server prefers not to provide variant-IDs, it MAY at its
      option use the _selecting opaque validator_ mechanism. A selecting
      opaque validator is an opaque validator whose value is unique across all
      variants of a resource.

      If the origin server cannot generate opaque validators that are
      guaranteed to be unique across all variants of a varying resource, it
      MUST NOT send any opaque validators for that resource.


 mechanism 2:

      3.16 Variant Sets
      Validator sets are used for doing conditional retrievals on varying
      resources; see section 13.8.3.

            variant-set = 1#variant-set-item
            variant-set-item = opaque-validator ";" variant-id


- Associated with these are two separate cases for the If-Invalid
  header and two separate rules for cache replacement.
  
- If I understood you correctly in the past, you have expressed
  concerns that this is unnecessarily complex, and that we should just
  require there to be a variant-id if If-Invalid is to be used.

- In the past, I have not been happy with a requirement to include
  variant-IDs if If-Invalid is to be used. I feared we could paint
  ourselves into a corner, content-negotiation wise, with this
  requirement, because this means that caches constructing pre-emptive
  responses on behalf of the origin server must sometimes do this by
  taking an earlier reactive response and adding a variant-ID.

- Now, after having thought some more about this, I feel reasonably
  safe with the requirement that there always must be a variant-id if
  If-Invalid is to be used, as long as the variant-id is a
  quoted-string, not a token.

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

- If we do it this way, we can delete the sections 
      3.15 Validator Sets
      13.8.4 Use of Selecting Opaque Validators
  and simplify the sections
      10.48 If-Invalid
      10.49 If-Valid
      13.12 SLUSHY: Cache Keys
      13.20 Cache Replacement for Varying Resources

  One could even convincingly argue that *not* doing this would make the
  protocol too complex.

  On the down side, if we do this, implementations of transparent
  content negotiation (defined by a future spec) will become slightly
  more complex, and slightly more bytes will be sent over the wire.

Now, if you agree to the changes outlined above, and if Jeff agrees
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.

>  I suppose it makes just as much sense to have
>quoted-strings to variant-ids as it does for change-indicators.

Yes.

>
>The entire caching section will need to be rewritten to use
>EID and entity-id terminology.

I consider this to be orthogonal to the variant-ID issue above.

>......Roy

Koen.

Received on Tuesday, 23 April 1996 21:05:33 UTC