Re: HTTP server driven content negotiation

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

Message-Id: <>
Date: Fri, 19 Mar 1999 06:40:12 -0800
To: Philipp Hoschka <>
From: "Michael A. Dolan" <>
Subject: Re: HTTP server driven content negotiation 


I've reviewed the CC/PP document, and it is sure not obvious how to do this.

Are you saying the content would contain a (CC/PP) URI, perhaps something
of the form:


The device of course cannot locate and retrieve such a URI, so its meaning
must either be infered from the URI itself, or the device descriptions

In my application, this does not seem all that useful to do since there are
only a few discrete configurations which must be agreed to in advance and
the clients all know what they themselves are.

Also, this scheme requires a parse of the content to figure out if it
should be parsed and rendered.  I was looking for a higher level mechanism
in the transport, such as an HTTP (reply) field so the decision can be made

So, I'm still very skeptical that CC/PP is a good fit.  Am I missing
something here?

My problem is pretty simple and CC/PP is definitely overkill even if it
could work.  But, I'm certainly open to solving the problem in a more
general and standard manner.

Can you elaborate on your proposal some?


At 02:20 PM 3/19/99 +0100, Philipp Hoschka wrote:
>On 07/03/1999, "Michael A. Dolan" <>  wrote:
>>When making content-based system profiles, it would be handy to tag
>>broadcast content.
>>As best as I can tell, CC/PP and the IETF conneg work is not suitable since
>>it requires the client to first describe its profile (which cannot
>>generally be done in TV).
>I think both of these are basically methods to write device descriptions.
>They do not define protocols, and thus do not require that the client
>describes its profile.
>I would thus propose to tag the content with the description of the
>device it is intended for. Looking at it from that angle, both CC/PP
>and conneg seem applicable to this particular problem. 
>Note that at least in the case of CC/PP, the device description 
>can be replaced by a URI pointing to a location where the description 
>is stored. The intent is to avoid sending around lengthy device
>descriptions. In many cases, this URI can be considered as an identifier
>only, i.e. there's no need to actually downlad the description - the
>description is "hard-wired" into the receiving device.
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122