Re: draft-ietf-ohto-ccpp-exchange-00

At 03:03 PM 4/25/00 -0400, Hidetaka Ohto wrote:
>Dear all:
>
>I wrote draft-IETF-ohto-ccpp-exchange-00.txt(attached to this mail)
>as a starting point of the discussion for CC/PP protocol.

[...]

>Please review it.

I've taken a first pass through this.  At this time, I don't plan to offer 
a detailed review, because I think that there will be many details that are 
resolved as the CC/PP format definition is firmed up.  But there are some 
general points I would like to raise:



>Abstract
>
>    [...]  The ability of RDF to
>    reference profile information via URIs assists in minimizing the
>    number of network transactions required to adapt content to a
>    device, ...

I think it's important to be clear about the difference between number of 
transactions and volume of data transfered.  The use of URIs as indirect 
references, if anything, will tend to *increase* the number of network 
transactions, while reducing the volume of data to be transferred.  I 
understand the latter to be the primary goal, with cacheing assumed to 
restrain the number of additional transactions incurred by this approach.


>1. Introduction
>
>    The CC/PP framework is a mechanism for describing the capabilities
>    and preferences associated with users and user agents accessing the
>    World Wide Web.  Information about user agents includes the hardware
>    platform, system software,  applications and user preferences
>    (P3P[6]). The user agent capabilities and preferences can be thought
>    of as metadata,or properties and descriptions of the user agent's
>    hardware and software. The CC/PP descriptions are intended to
>    provide information necessary to adapt the content and the content
>    delivery mechanisms to best fit the capabilities and preferences of
>    the user and its agents.
>
>    The major disadvantage of this format is that it is verbose. Some
>    networks are very slow and this would be a moderately expensive way
>    to handle metadata. There are several optimizations possible to help
>    deal with network performance issues. One strategy is to use a
>    compressed form of XML (e.g. WBXML[14]), and a complementary
>    strategy is to use references(URIs).

[...]

As this is a document about CCPPEX protocol rather than CC/PP, I think he 
introduction dwells too much on describing aspects of CC/PP, and details 
that should be addressed in the CC/PP design.  For the purposes of an 
introduction to the protocol I think it's useful to say:

- the CCPP format is based on RDF

- a CC/PP expression contains references to separately stored profile 
information and local differences from that expression.  Thus, a server (or 
proxy) is expected to be able to retrieve separately stored expressions 
from a CC/PP repository.

- the protocol is expected to be able to transfer profile information in 
formats other than CCPP/RDF [is this really a requirement?]

- The basic structure of the protocol is:
-- a client sends a resource request to a server, together with an 
(optional) CC/PP expression.
-- proxies which on the path from client to server may indicate variations 
from the client-specified profile, so the CC/PP expression received by the 
server is not necessarily an exact copy of that supplied by the 
client.  Proxy variations may indicate additional capabilities (e.g. 
additional formats supported by a transcoding proxy) or constrained 
capabilities (incoming data formats that may be disallowed by 
organizational policy).
-- a server uses the CC/PP profile information provided to make decisions 
about the selection or adaptation of content for this request, and sends 
back an appropriate response, together with information about the CC/PP 
profile information that was used and its effect on the response.


>2. Basic requirements for CC/PP exchange protocol
>
>    The basic requirements for the CC/PP exchange protocol are listed
>    below.
>
>    1.  The transmissions of the CC/PP descriptions should be
>        HTTP/1.1-compatible.
>
>    2.  The CC/PP exchange protocol should support an indirect
>        addressing scheme based on RFC2396[7] for referencing profile
>        information.
>
>    3.  Components used to construct CC/PP descriptions, such as vendor
>        default descriptions, should be independently cacheable.
>
>    4.  The CC/PP exchange protocol should provide a lightweight
>        exchange mechanism that permits the client to avoid resending
>        the elements of the CC/PP descriptions that have not changed
>        since the last time the information was transmitted.

Requirements 2 and 3 seem to be more to do with properties of the CC/PP 
format than the CCPPEX protocol.



Finally, concerning the proposed use of "Profile-diff" headers.  To me, 
this is mixing data formats with the protocol specification.  The idea of 
expressing differences from some common feature set is, I think, a format 
issue, and the CC/PP format is being designed to address this.  As such, I 
don't think it should be necessary to distinguish between "profile" and 
"profile-diff".

However, I do concede that there may be advantages to presenting the 
profile in several parts, so that (for example) new parts included by 
proxies can reference other parts provided by the client.  But I don't see 
a need to distinguish between 'Profile:' and 'Profile-diff-x:'.  Also, I 
think the method described for cross-referencing duplicates the use of URIs 
in RDF, and is therefore redundant.

What is needed, I think, is a way to indicate which RDF resource 
corresponds to the client described, as opposed to other RDF resources that 
constitute elements of the description.  Exactly how this is achieved will 
depend on the final CC/PP design -- it could be done *within* CC/PP, or it 
could be done by some identification supplied separately from the RDF 
expressions.

Here is one possible example approach:

    Profile-URI: <client-profile-URI>
    Profile-RDF: <RDF-expression>
    Profile-RDF: <RDF-expression>
     :
    Profile-RDF: <RDF-expression>

where each of the <RDF-expressions> defines part of an RDF graph that 
constitutes the CC/PP desription received by the server.  The RDF resource 
corresponding to the profile would be distinguished by an RDF expression 
something like:

     :
    <rdf:Description ID=(client-profile-URI) >     // or 
'about=(client-profile-URI)'
       <component> ... </component>
       <component> ... </component>
        :
       (etc.)
        :
    </rdf:Description>
     :

Cross-links between the various profile sub-expressions can be handled 
within the RDF (if necessary, using invented digest-based URIs).

--

#g

------------
Graham Klyne
(GK@ACM.ORG)

Received on Wednesday, 10 May 2000 12:13:37 UTC