[Moderator Action] Comments on the CC/PP: Structure and Vocabularies draft

       This document does a nice job of a) providing a vocabulary for
representing user/application/platform profiles
       b) allowing this information to be specified incrementally, or on
a per session basis, thus optimizing bandwidth. c) skating
       around (for the time being) the issue of vocabulary heterogeneity
by adopting RDF.

       It is also appropriate for this work to include transcoding proxy
capability descriptions, as they are part of the service
       chain between client and content server. Different people are
defining this box in different ways ( even within the IETF there is
       Middlebox, Webi, OPES and ICAP), you need to make some statement
about what kind of box architecture  you will be
       compatible with. Related points:

          ·         It is not always the case that you want the proxy
capability to be advertised to the origin server. What if the
             CC/PP client wants to provision a proxy to remove
advertisements, but does not want to inform the content
             provider of his intent.

          ·         Let's say that these proxies aren't free and start
billing you for services. I don't think you want to trust the content
             provider to optimize the proxy provisioning for minimum
cost. (S)he is going to focus on how to make their job
             easier, i.e serve you the content as easily as possible.
This may be incompatible with cost minimization.

          ·         The proxy proposals in the IETF, notably OPES (Open
Pluggable Edge Services), are beginning to define their own
             profile vocabulary. Some coordination in that space is
needed.

       The self-imposed restriction to transcoding proxies seems
arbitrary. It would seem that you want caching proxies or
       NAT related proxies to also forward their profiles to the content
server ...

Received on Wednesday, 4 April 2001 22:14:43 UTC