Re: Variant-ID proposal

Jeffrey Mogul:
>

[Note: I should be sleeping by now, so don't count on this reply making
too much sense.]

[...]
>First, Koen started this thread with the following statement:
>
>    I have argued before that the requirement 
>    
>      Varying resources (even those that are transparently negotiated) MUST
>      send responses which include variant-IDs.
>    
>    which is present in both Jeff's If-Valid/If-Invalid/Cval text and Roy's
>    competing If-EID/Unless-EID/EID text must be dropped, because
>    this requirement means unnecessary trouble for transparent content
>    negotiation.
>
>I cannot find this "requirement" in my drafts, and cannot recall having
>made it.

In your description if the If-Invalid header, you say:

|      If-Invalid = "If-Invalid" ":" if-invalid-rhs
|
|      if-invalid-rhs = opaque-validator | variant-set
|
|      variant-set = 1#variant-set-item
|
|      variant-set-item = opaque-validator ";" variant-id
|
|   The correct form (opaque-validator or variant-set) depends on whether
|   or not the request is being made to a multi-entity resource which
                                                                ^^^^^
|   uses the variant-id mechanism.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So you require there to be a variant-id in order for the If-Invalid
mechanism to be used for refreshing cached variants or alternates.
Since we want such refreshing to be possible, it follows that you
require transparently negotiated resources, which use Alternates, not
Vary, to include variant-ids.  But I don't want that, I want to have

       variant-set-item = opaque-validator [ ";" variant-id ]

and allow refreshing just on the basis of the opaque validator.  For
this to work, the opaque validators would have to be unique across the
alternates, but this is easy for a server to implement that.

[....]
>In other words, the point at which the selection is done (origin
>server, proxy, or client) must have full information about the
>available choices.
>
>My belief is that Koen intends this information to be conveyed
>by the Alternates header.  I'm basing this belief on the
>draft-holtman-http-negotiation-00.txt document; I'm not sure
>if any of his more recent messages have changed this.

Your belief is still correct.

[...]
>However, Koen might like this compromise: we allow (but do not require)
>the origin server to embed variant-identification information
>in the opaque validator itself.  (We do NOT allow the cache
>to look at this embedded information!)  Such a validator is
>marked with the suffix "/S" (for "Selecting").

This compromise mechanism you describe is what I have wanted all along.
I do not even require the /S, we can leave it to the server to ensure
that all opaque validators ever used in in a preemptive response using
Alternates are indeed selecting.

As I indicated above, in order for this compromise to work, it is
necessary that multiple such selecting validators can be present in an
If-Invalid header.

>-Jeff

Koen.

Received on Wednesday, 17 April 1996 00:33:39 UTC