Re: comments on revised role and service binding

[christopher ferris <chris.ferris@east.sun.com>]

Marty,

Please see below.

Cheers,

Chris

Martin W Sachs wrote:
> 
> Chris,
> 
> Here are some things that are still open on role and service bindings,
> mostly in the form of suggestions for additional text in the spec.  Some
> may belong in the CPA composition appendix when it is written but
> meanwhile, my taste is to put them in the spec in the appropriate places so
> we can then forget about them.
> 
> We could use some explanation (perhaps a non-normative note) about how the
> service binding preferences are applied.  Based on our discussion at
> today's call, they are applied in two ways:
> 
>    1.  In chosing the highest-preference delivery channels that are
>    compatible between the two parties.  This relates to the as yet
>    undefined send properties but I think that this note could be written
>    now, basically using the words the first sentence.
> 
>    2.  An implementation may provide the capability of dynamically
>    assigning delivery channels on a message basis during performance of the
>    collaboration protocol.  The highest-preference available delivery
>    channel would be chosen based on present conditions.

Agreed.

> 
> A brief non-normative note covering the case where an override delivery
> channel in a CPP is not compatible with the other party when the CPP is
> composed.  Probably just a caveat that this situation can occur is
> sufficient.  It can be resolved either by negotiating or by reverting to a
> compatible default channel.

Agreed.

> 
> A non-normative note saying that when a CPA is composed, only compatible
> service bindings are retained and the default channel for each party is the
> highest preference channel that is compatible with the other party.

Agreed.

> 
> Some explanatory text on the certificates in the role tag and delivery
> channel.  The basic points are that the certificate referred to by the role
> tag relates to the authorizing role and signing the payload while the
> certificates in the delivery channel relate to message exchanges.

Agreed.

> 
> On a related matter, we need to understand the function of nonrepudiation
> in the delivery channel vs the certificate in the role tag. Does
> nonrepudiation in the delivery channel relate to signing of header or does
> it also relate to signing payload?

I for one believe that it is only useful when signing both header
and payload together. Of course, there has also been discussion
that the only meaningful NR signature is that where the "applications"
signs the payload (or header and payload) and the ack. This needs
more scrutiny and discussion with teh ta-security folk. 

> 
> The word "default" appear in a couple of places. The word needs to be
> related to "highest preference delivery channel" somewhere, probably in the
> second paragraph under "Role Element", which is where the word is used the
> first time.

Agreed, sort-of. In the context of a ServiceBinding, the channelId
is the default, to be used in ALL cases *except* where there is
an Override specified for a given message. This is not the same as
highest preference. The ServiceBinding that appears first in a list
is the highest preference, not a "default".

In any event, I agree that we need to be sure that the text is
clear on this matter.

> 
> It needs to say that the value of the message attribute is defined in the
> collaboration protocol document pointed to by the collaboration protocol
> element identified by the collaborationId attribute.

Yes. I think that it needs to be explicit as to where this value
has its source in the BPM.

> 
> I suggest that some of the points raised by Dale also call for additional
> explanation in the spec.

Most likely;-)

> 
> I'm keeping this on the list of things to do for now.  It's probably best
> if you provide the text for these at your convenience.  It could be an
> email with an indcation of where each piece of text goes.

Sounds like a plan;-)

> 
> 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/23/2001 09:45:55 PM
> 
> To:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>
> cc:
> Subject:  Re: next conference call - reminder
> 
> I'd like to submit this revised version of my Role proposal for
> consideration in tomorrow's call. I have attempted to clear up
> some of the confusion regarding the semantic meaning of the Override
> element by tweaking its description a bit.
> 
> I've also updated the list of sources for the Role name to
> align it with the BPM based on some discussions I had with Karsten
> today.
> 
> This version has change tracking enabled from the previous version
> I sent out so that the changes are easily identified.
> 
> Cheers,
> 
> Chris
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