Comments on the CC/PP: Structure and Vocabularies draft

I sent this earlier, without signing up to the  mail reflector.
Apologies if you receive this twice.

     This proposal 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) full-blown solutions to 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. However, 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. On a related note:

         ·         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
unnecessary. It would seem that you want caching proxies or
      NAT related proxies to also forward their profiles to the origin
server.