Re: Fwd:HTTP server driven content negotiation

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.

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

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.

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).
   b)  User agent caches the profile information.
   c)  Server broadcasts a content with the name tag.
   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)

    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.

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.

Best Regards,
-- Taka

Received on Wednesday, 24 March 1999 16:30:41 UTC