Re: HTTP server driven content negotiation

Philipp-

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:

	ccpp://application_name/profile=1

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

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

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?

Thanks,
	Mike

At 02:20 PM 3/19/99 +0100, Philipp Hoschka wrote:
>
>On 07/03/1999, "Michael A. Dolan" <miked@tbt.com>  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

Received on Friday, 19 March 1999 10:09:46 UTC