Re: Fwd:HTTP server driven content negotiation

At 04:37 PM 3/24/99 -0500, Hidetaka Ohto wrote:
>
>Hi, Michael:
>
>Thank you for your e-mail.
>It is very helpful for me to understand the requirements.
>
>Please let me try to itemize the basic model and requirements.
>
>1. In the general case, the content negotiation mechanisms
>    must not assume backchannels.
>2. The content must be tagged, and the receiver must know its
>    capabilites and be able to match them in some simple manner.
>3. 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.
>4. The profiles will necessarily be fairly simple, and content will
>     necessarily be tagged as belonging to multiple profiles.
>5.  It is almost required that inappropriate content be discarded as
>     soon as possible, and before it reaches HTML parsers or object
>     cache.
>
>Then,  I would like to try to analyze the each requirement.
>1. Another protocol besides HTTP might be considered. Because
>    HTTP is based on request/response model(required 2way transport).
>    It does not mean that CC/PP could not be used so that CC/PP is
>    independent from protocol.

Some notes:

a. Arbitrary file transfer is done with the ISO DSMCC data carousel or a
functionally similar technique.

b. Content may be grouped and packaged into a single "file".

c. Each piece of content is tagged with Content Type, etc with either an
HTTP Reply header syntax, or using a proprietary set of MPEG descriptors
for the same purpose.

>2. It is a basic system requirement and would be fulfilled no matter what
>    profile format is introduced.
>
>3.  I guess that profile information cache on the client side is one of
>     the solutions.
>    One of the scenarios is as follows:
>   a)  Server broadcasts profile information with a name tag
>        (it should be a URI).

This will still need to be repeatedly broadcast in a carousel since you
never know when the client will tune, and every channel is potentially a
network.  And, it should be a small number of them.  But fundamentally this
should be OK.

>   b)  User agent caches the profile information.
>   c)  Server broadcasts a content with the name tag.

This tag is bound to the content at the transfer protocol layer?  Assuming
we use an HTTP Reply encoding, then what would you recommend the HTTP Reply
field syntax be?

>   d)  User agent look up the profile information using name tag and
>        decides whether the content is used.
>
>    If the list of  (name tag, profile information) pair is preinstalled
>    in the STB, the process a), b) could be omitted.
>    It is very simple and bandwidth saving way, but we could not change
>    profile info dynamically. If the bandwidth requirement is critical, we
>    could choose this way.
>    (I believe this solution was already suggested by Philipp)

This is fine, but then the URI syntax must be well-defined and some
namespace management done to avoid collisions, such as:

	ccpp://philips.com/make/model/profile

Is there a standard defined manner to do the above in CC/PP?

>    Furthermore, CC/PP can describe default capability info and modified
>    capability info.Therefore if the default profile information list is
>     preinstalled, a server broadcast only the changes of the default
>profile
>     information when the update happens.
>
>4. I think we can add multiple name tags to one content in the same manner
>    as described above.

This would be important.  The tag needs to be a URI list.

>5. It requires  the separation of profile information and content.
>    In that case, the profile information should be conveyed within
>    protocol headers, not be embedded in the contents.
>
>IMHO, to fulfilling the requirements,  we should consider not only profile
>format(ex. CC/PP) but also the one way protocol which conveys
>the profile information within the headers.
>
------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

Received on Wednesday, 24 March 1999 18:07:38 UTC