[ebxml-cppa-negot] vanilla SOAP binding

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

This is to correct an error below. syncReplyMode is not just for reliable messaging. It can be used separately from reliable messaging. We previously said that for negotiation, we would want to specify synchronous replies since that avoids the need to supply an endpoint address for responses. We need to specify the value of syncReplyMode based on the needs of the negotiation protocol, TBD.

*************************************************************************************
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
*************************************************************************************
----- Forwarded by Martin W Sachs/Watson/IBM on 07/30/2002 06:11 PM -----

Martin W Sachs 07/30/2002 04:38 PM

To: ebxml-cppa-negot@lists.oasis-open.org cc: From: Martin W Sachs/Watson/IBM@IBMUS Subject: vanilla SOAP binding

I reviewed the contents of the MessagingCharacteristics attributes and DocExchange elements in the CPPA and MSG spec with regard to the bootstrap problem in the NCPA. My conclusion is that we can be specify them to be set to define a minimum-subset of MSH function that is probably not much more than "vanilla SOAP" and in any case, leaves nothing to negotiate about use of ebXML messaging. I propose that we define these elements and attributes accordingly and not try to introduce a pure SOAP binding at this time.

Analysis:

ebXMLSenderBinding and ebXMLReceiverBinding: Following are the elements and their functions:

ReliableMessaging: If present, reliable messaging is to be used.
PersistDuration: Used only for reliable messaging.
xxxNonRepudiation: Used only for message security.
xxxDigitalEnvelope: Used only for message security
NamespaceSupported: Used with MSG options, extensions, and body parts

MessagingCharacteristics: All of its attributes relate to Reliable Messaging.

syncReplyMode: reliable messaging
ackRequested: reliable messaging
ackSignatureRequested: reliable messaging
duplicateElimination: Used mostly for reliable messaging. If there is any other use, it is optional.
actor: reliable messaging (supports ackRequested)

Conclusions:

It appears that all of the child elements of ebXMLSenderBinding and ebXMLReceiverBinding can be properly omitted. The effect of omission is that neither reliable messaging nor message security will be used. It is probably not necessary to say anything more in the CPPA spec about the effect of omitting all of them.

All of the attributes of MessagingCharacteristics relate to reliable messaging. If all the child elements are omitted under ebXMLxxxBinding, the MessagingCharacteristics attributes are probably ignored. However to be sure, we can specify in the NCPA that syncReplyMode="none",
ackRequested, ackSignatureRequested, and duplicateElimination = "never". The CPPA spec states that the value of the actor attribute is ignored if ackRequested="never", so either of the enumerated values will work.

At least for version 1, the NCPA can omit reliable messaging and message security. NameSpaceSupported is only needed if we need to specify body parts for negotiation messages. Therefore, it should be sufficient for elimination of the messaging bootstrap problem to omit all of the child elements of ebXMLxxxBinding and set all the MessagingCharacteristics attribute values to those listed above. NOTE: The default values of the attributes of MessagingCharacteristics are not appropriate.

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
*************************************************************************************
----- Forwarded by Martin W Sachs/Watson/IBM on 07/30/2002 04:07 PM -----

Martin W Sachs 07/24/2002 09:59 AM

To: ebxml-cppa@lists.oasis-open.org, ebxml-cppa-negot@lists.oasis-open.org cc: From: Martin W Sachs/Watson/IBM@IBMUS Subject: vanilla SOAP binding

We have discussed providing a "vanilla" SOAP binding in the CPA for use in negotiation CPAs. This helps to eliminate the need for negotiating the negotiation CPA before negotiating the CPA that is under construction.

At first sight, providing a vanilla SOAP binding is an addition to the CPPA specification. That probably has to be a post-V2 item since adding that binding is a change that is probably more extensive than we want to make while the specification is under OASIS review and ballot. There are other possibilities:

1. Add an extensibility element to the DocExchange element, which would permit introducing the SOAP binding an an extension. We could probably insert the extensibility element while doing the final edits after the public review period.

2. Perhaps we can create a "negotiation profile" that specifies the minimal set of document-exchange that is in the negotiation CPA and that everone doing negotiation is expected to be able to support. All child elements of DocExchange, ebXMLSenderBinding, and ebXMLReceiverBinding have cardinalties that include zero, which permits eliminating most ebXML messaging function in the negotiation CPA without changing the CPPA specification. Similarly, we could look at the rest of the CPA definition to see what we can specify as the minimal set of function for the negotiation CPA.

There is one slight problem with (2): While the schema permits a CPA to contain no child elements under ebXMLSenderBinding and ebXMLReceiverBinding, I don't believe that we specify how messaging works if none of those child elements are present. A natural definition is that if none of them are present, messages are exchanged with only the basic Messaging Service function, which has to be pretty close to vanilla SOAP. Could we discuss this with the MSG team to see if it makes sense to add such a statement to the CPPA speciication?

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
*************************************************************************************