Subject: Re: service binding - tech comment v0.2 CPP/CPA
Marty,
Thanks for the review. Some comments/responses below.
Cheers,
Chris
Martin W Sachs wrote:
>
> 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.)
While the choice of alteratives that is selected for use in a CPA
derived from a CPP is certainly a negotiation matter for the parties,
what I think is important is that from the perspective of the Party
that creates the CPP, that the order of the ServiceBinding
elements designates that Party's preference as to how it would prefer
to receive messages (e.g. because it is the most secure, reliable,
or whatever)
>
> 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.
I would think that this would be covered in a non-normative note or
appendix that discusses the negotiation process as you have suggested
in a previous email.
>
> 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.
Correct.
>
> 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?
My thinking was that a certificate could be identified for the Role
for purposes of authentication when the Party sends messages "from"
that Role. The way I see this used would be that the CPP negotiation
would use the Role certificate and plug it into the TransportSecurity
or NonRepudiation CertificateRef when it composes the CPA. Does this
make sense?
>
> 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.
The way that I had intended the "default" nature of the ServiceBinding's
delivery channel would be that for any message OTHER than those that
are identified in an Override child element of the ServiceBinding element
would be sent using the "default" delivery channel.
Those messages that are identified by an Override would be REQUIRED
to be sent via the designated delivery channel in the context of
the ServiceBinding, regardless of the delivery channel identified as the
default for that ServiceBinding.
>
> 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.
I think that you are misunderstanding what is meant by Override. Maybe
a different element name is required to convey the intent of this element
as I conceived it. What Override is intended to convey is that for the
identified message, the delivery channel represented by the channelId
attribute of the Override element is used instead of the delivery
channel that is designated as the "default" for the ServiceBinding.
>
> Message attribute: I suggest stating that the value of the message
> attribute is defined in the collaboration protocol element identified by
> the collaborationId attribute.
Agreed.
>
> "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
--
Christopher Ferris
_/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced Development
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
begin:vcard n:Ferris;Christopher tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XML Technology Development adr:;;One Network Drive;Burlington;Ma;01824-0903;USA version:2.1 email;internet:chris.ferris@east.Sun.COM title:Sr. Staff Engineer x-mozilla-cpt:;0 fn:Christopher Ferris end:vcard
Powered by
eList eXpress LLC