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

From: Graham Klyne (GK@dial.pipex.com)
Date: Wed, May 10 2000

  • Next message: Hidetaka Ohto: "Re: draft-ietf-ohto-ccpp-exchange-00"

    Message-Id: <4.3.1.2.20000510143027.00ce4200@pop.dial.pipex.com>
    Date: Wed, 10 May 2000 16:04:16 +0100
    To: "Hidetaka Ohto" <ohto@w3.org>, Johan Hjelm <hjelm@w3.org>
    From: Graham Klyne <GK@dial.pipex.com>
    Cc: <www-ccpp-protocol@w3.org>
    Subject: 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)