RE: service binding - tech comment v0.2 CPP/CPA

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

I agree with Marty that this is clearer
and has a number of enhancements! Thanks Chris.

I interpreted the default and override to
each be acceptable capabilities that
could be matched, even though they might be
differently ranked. So Marty's question
about whether an override could be
used in a proposed CPA did not occur
to me. Nevertheless, it seems worth
clarifying how the preference system
works. I guess that if you had capabilities
that you did not really want to encourage
being used, you would not advertize them
at all in the CPP. (I don't say anything
about Fortran or Cobol in my resume...)

Dale Moberg

> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, January 23, 2001 10:48 AM
> To: christopher ferris
> Cc: ebxml-tp@lists.ebxml.org
> Subject: Re: service binding - tech comment v0.2 CPP/CPA
> 
> 
> 
> Chris,
> 
> This service binding proposal looks great.  However I do have 
> some comments
> and questions.
> 
> Regarding preference among alternative service bindings:
> 
>    It should state that preference among alternatives is a negotiation
>    matter.  (This mostly relates to matching send properties 
> to receive
>    properties that we still have to add but we should add the 
> point about
>    the negotiation matter now.)
> 
>    We probably need to say what happens if a delivery channel 
> with override
>    specified is not compatible with the other partner. One 
> possibility is
>    that this is an incompatibility that must be negotiated.
> 
>    In order for Override to be meaningful, the delivery channels with
>    Override specified have to appear in the CPA if they are 
> compatible with
>    both parties.  Therefore in fact, preference also 
> determines selection
>    of delivery channel when the collaboration protocol is 
> being performed.
> 
>    It needs to state (if true) that where more than one 
> delivery channel is
>    allowed the highest preference (the default) delivery 
> channel will be
>    used unless an override is specified for a particular message. (I
>    suggest avoiding the question of what selects the delivery 
> channel.)
> 
>      One could extend this to permit dynamic selection of 
> delivery channel
>      in order of preference (again avoiding what does the 
> selection).  This
>      would be a non-normative note.
> 
> This proposal appears to limit each role to one certificate for all
> delivery-channel security functions on all delivery channels.  Is this
> sufficient?  tpaML  allows a different certificate for each security
> function used in either transport or doc exchange (transport 
> encryption,
> transport authentication, nonrepudiation, digital envelope) in each
> delivery channel. However, when I look at the transport and 
> doc exchange
> security functions I do see a certificate reference in each.  So the
> question is, what is the function of the certificate 
> reference in <Role> vs
> the certificate references in the individual security definitions?
> 
> Default delivery channel:  Somewhere the text needs to state that the
> default delivery channel is the one specified by the 
> highest-preference
> service binding for this role and collaboration protocol. I think this
> statement belongs in the text for channelID attribute.
> 
> Override element:  It should state what is done Override is 
> specified in
> the only service binding specified for this role and collaboration
> protocol.  "Ignore" is a possibility but this could be 
> considered an error
> that should be corrected.  The error could be detected by a CPP-aware
> authoring tool and by a CPA composition tool.
> 
> Message attribute:  I suggest stating that the value of the message
> attribute is defined in the collaboration protocol element 
> identified by
> the collaborationId attribute.
> 
> "Alternate" should be "alternative" since there can be more than two.
> 
> Regards,
> Marty
> 
> **************************************************************
> ***********************
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> **************************************************************
> ***********************
> 
> 
> 
> christopher ferris <chris.ferris@east.sun.com> on 01/22/2001 
> 01:14:14 PM
> 
> To:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>
> cc:
> Subject:  service binding - tech comment v0.2 CPP/CPA
> 
> 
> 
> All,
> 
> One of the issues that has been discussed both on and
> off list is the purpose and function of the ServiceBinding
> element.
> 
> There has been some confusion and also some concern that
> the current draft of the CPP will make it difficult
> at best for automated CPP+CPP->CPA mapping.
> 
> One of the concerns was that in the current design, it is difficult
> to determine if all of the messages for a given collaboration
> protocol are actually "bound" to a DeliveryChannel.
> 
> Another concern raised is how to map alternate delivery channels
> to a given collaboration protocol, etc.
> 
> I would therefore like to propose the attached revision to the
> Role element that I think will make things a little clearer
> than they are in v0.2 as well as to provide a little better
> closure on ensuring that all messages are "bound" to
> a delivery channel.
> 
> This proposal also involves removing the ServiceBinding child
> element from the DeliveryChannel, as this function is now covered
> with the attached proposed change to the Role and ServiceBinding
> elements.
> 
> Comments are encouraged.
> 
> Cheers,
> 
> Chris
> 
> 
> 
> 
> 
>