Subject: comments on revised role and service binding
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. 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. 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. 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. 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? 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. 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. I suggest that some of the points raised by Dale also call for additional explanation in the spec. 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. 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
Powered by
eList eXpress LLC