Re: Fwd:HTTP server driven content negotiation

From: Michael A. Dolan (
Date: Fri, Mar 19 1999

Message-Id: <>
Date: Fri, 19 Mar 1999 09:20:53 -0800
To: Henrik Frystyk Nielsen <>, Johan Hjelm <>, Philipp Hoschka <>,
From: "Michael A. Dolan" <>
Subject: Re: Fwd:HTTP server driven content negotiation


Think of the TV broadcast stream as one giant shared cache.  It's
distributed with a push stream, and every client has a small cache it has
to manage.

How can different capability receivers pick out the data from this big
cache push stream that is appropriate for them based on some small,
(predetermined by both ends) profile levels?

The client cannot ask for anything.  It can only decide to cache something
(or not).

If Vary is not appropriate, do you have any other suggestions?

I can of course invent a reply field, such as:

	XProfile: application/level

or something.  But I wanted to be sure I had exhausted any standard
mechanisms before inventing my own.


At 07:53 PM 3/18/99 -0500, Henrik Frystyk Nielsen wrote:
>At 05:32 09/03/1999 -0800, Michael A. Dolan wrote:
>>There is a client cache.  Managing the cache is exactly what this would be
>>good for.   So....does this make sense?  Am I using Vary correctly?  Are
>>there more examples of its use?
>Sorry for the delay - my point is that if it is a end-user cache then vary
>doesn't do much unless that end-user changes preferences a lot in which
>case it often can be solved in more direct ways, for example if the cache
>and the app exists in the same address space.
>Vary really only makes sense if you have a shared cache that can serve
>multiple different clients with different setup. In this case the cache has
>to know under what conditions it can serve an already cached response -
>this is what the Vary header field tells it.
>Henrik Frystyk Nielsen,
>World Wide Web Consortium
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122