Re: Fwd:HTTP server driven content negotiation

At 01:25 PM 3/24/99 -0500, Hidetaka Ohto wrote:
>
>Dear Michael:
>
>I am Hidetaka Ohto.
>Now I am involved in the CC/PP work in the
>Mobile Interest Group in W3C.
>
>I am making a specification called CC/PP exchange
>protocol based on HTTP extension framework.
>
>http://www.w3.org/TR/NOTE-CCPPexchange (W3C Note)
>http://www.w3.org/Mobile/Group/IG/NOTE-CCPPexchange (latest draft)
>
>The protocol is designed for enhanced content
>negotiation, while considering how to minimize
>transmissions of capability descriptions.
>( CC/PP description itself is independent from
>the transport, as Philipp said. )

I have reviewed this work, and in this context am having trouble
understanding how to use it in a broadcast environment.  Thank you for your
interest and help.

>Now I am very interested in the content negotiation
>for the TV, and  I would like to know basic requirements
>for the content negotiation from the point of view of TV.
>
>First of all, I would like to make sure your model.
>IMHO, I guess the basic model is as follows:
>1. There is no way to send client profile information from a user agent
>     to servers so that the system is unidirectional.

In the general case, this is correct.  While some TV's will be
Internet-capable, whatever mechanism is developed for this must assume no
backchannel.  Also, a clarification: "unidirectional" means to some that
only the link is one way, and there may be other unidirectional links, thus
completing the channel.  The topology is that there is only one
unidirectional link.

>2. Servers broadcast contents with profile information which describe the
>     required capabilities of receivers(user agents).
>
>3. The user agent looks up the profile information and decides whether
>    the content should be used(cached, rendered etc) or not.

The above is one solution which I think is reasonable.  The content must be
tagged, and the receiver must know its capabilites and be able to match
them in some simple manner.

>I beleive you mentioned that CC/PP(or IETF conneg syntax) is over spec for
>fulfilling the demands of TV content negotiation. So I would like to know
>your requirements of the profile information from the point of view of TV.

Due to bandwidth considerations, there is a STRONG desire to not deliver
very many profiles of the same content. In fact, ideally, the profiles are
layered and nothing is duplicated.  This is a bit unrealistic, but a goal.

In contrast, to strictly mimic a traditional client-server (HTTP) system
one would have to tag and broadcast all possible profiles the server was
capable of delivering (remember the client can't ask for anything).  This
shotgun approach is simply not acceptable from a bandwidth and receiver
performance point of view.  So, the profiles will necessarily be fairly
simple, and content will necessarily be tagged as belonging to multiple
profiles.

I am conerned about any design where the receiver has to parse the content
to retrieve the profile information.  In a system that has limited cache
size and CPU power, it is almost required that inappropriate content be
discarded as soon as possible, and before it reaches HTML parsers or object
cache.

Please note that I am not a student of CC/PP, and have only read the public
material.  Before we assume anything more about it, can you provide an
example of its use in the above scenario?  Perhaps it will work just fine.
It would certainly be my preference to use it if at all possible.

Thanks,
	Mike

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

Received on Wednesday, 24 March 1999 14:09:59 UTC