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

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

  • Next message: Markus Buchhorn: "Re: SDPng"

    Message-Id: <4.3.1.2.20000525090146.00c12f00@pop.dial.pipex.com>
    Date: Thu, 25 May 2000 09:05:33 +0100
    To: "Hidetaka Ohto" <ohto@w3.org>
    From: Graham Klyne <GK@dial.pipex.com>
    Cc: <www-ccpp-protocol@w3.org>
    Subject: Re: draft-ietf-ohto-ccpp-exchange-00
    
    At 02:16 PM 5/12/00 -0400, Hidetaka Ohto wrote:
    > > 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.
    
    The sole purpose of Profile-URI in my proposal is to distinguish the "entry 
    point" into the RDF graph:  i.e. the resource that is the root of the graph 
    describing the properties supplied.  As such, it would specify a *single* 
    URI, not a list.
    
    >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.
    
    Yes, that's my opinion.
    
    >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.
    
    I understand ... my comments were made in light of an assumption that CC/PP 
    would deal with these issues.  (And the fact that I believe that it should 
    not be the protocol's responsibility to contain structural information 
    about the capability profile.)
    
    #g
    
    
    ------------
    Graham Klyne
    (GK@ACM.ORG)