RE: Variant-ID proposal

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?

>    - 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 -- 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?)

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

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

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

Why not post the suggestions to the the list, after you and Jeff agree?

Paul

Received on Thursday, 25 April 1996 20:11:34 UTC