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

[Martin W Sachs <mwsachs@us.ibm.com>]

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