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

Graham,
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
possible.

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

Received on Friday, 12 May 2000 14:31:02 UTC