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

From: Hidetaka Ohto (
Date: Fri, May 12 2000

  • Next message: Swetina Joerg: "[www-ccpp-protocol] <none>"

    Message-ID: <000201bfbc40$9cebef60$>
    From: "Hidetaka Ohto" <>
    To: "Graham Klyne" <>
    Cc: <>
    Date: Fri, 12 May 2000 14:16:33 -0400
    Subject: Re: draft-ietf-ohto-ccpp-exchange-00
    Thank you for your comments on the draft.
    > I think it's important to be clear about the difference between number of 
    > transactions and volume of data transferred.  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 caching assumed to 
    > restrain the number of additional transactions incurred by this approach.
    Yes. I will try to make clear of it in the draft.
    > 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".
    > Here is one possible example approach:
    >     Profile-URI: <client-profile-URI>
    >     Profile-RDF: <RDF-expression>
    >     Profile-RDF: <RDF-expression>
    >      :
    >     Profile-RDF: <RDF-expression>
    In your possible example, you still distinguished the
    list of URIs(Profile-URI) from the list of RDF expressions(Profile-RDF).
    One of the main functions of "Profile" and "Profile-Diff" in the draft 
    is the same as those of Profile-URI and Profile-RDF.
    Basically I am not sure the difference between them.
    My take on your opinion is that CC/PP descriptions should describe their
    relationship (such as overriding/combining rules) by themselves as much as
    Currently, I admit that CCPPEX has complementary functions which 
    may be solved in "Format" area, such as the precedence rules among 
    Profile-diff headers etc.
    At the time I made the CCPPEX draft, CCPP itself does not have 
    precedence rules explicitly, therefore CCPPEX needed to have the function.
    I agree there will be many details that are resolved as the CC/PP format 
    definition is firmed up.
    -- Taka