[ebxml-cppa] SyncReplyMode is a misnomer?

[Arvola Chan <arvola@tibco.com>]

During this morning's ebxml-msg conference call, we discussed issues related
to the synchronous reply model, and how the MSG and CPP/A specs need to be
harmonized.

A number of participants opined that the syncReplyMode attribute is really
describing the bundling of business signals with business response into the
same ebXML message and has nothing to do with the transport characteristics
(whether a synchronous channel is used). If so, the values signalsOnly,
signalsAndResponse, and ResponseOnly ought to apply to the SMTP binding as
well. If this is the case, then syncReplyMode is a minomer, and the CPP/A
team ought to come up with a different name to convey the fact that this
parameter applies to both synchronous and asynchronous delivery channels.

I pointed out that the CPP/A team is probably assuming that a synchronous
delivery channel (with an HTTP-like binding) is used when syncReplyMode is
not set to "None", because we have been talking about the need to know the
signing certificates for both the initiator and the responder for a delivery
channel when syncReplyMode is other than "None". However, if that's the
interpretation for syncReplyMode, then should there also be a way to
describe in the CPA that an SMTP transport is to be used, and yet signals
and response are to be packaged together?

In general, I have been advocating that a syncReplyMode of
signalsAndResponse and responseOnly should be interpreted as overriding some
BPSS parameters related to the use of business signals and non repudiation
of receipt. In either case, (a syncReplyMode of signalsAndResponse or
responseOnly), the initiator would not be returning a business level receipt
acknowledgment signal for the response (which otherwise would have to come
back on a separate channel because the responder is expected to close the
connection once the response is returned). If we do allow for the CPA  to
override the business process specification, then we may also want to ask if
such overriding is meaningful, regardless of the synchronous/asynchronous
characteristics of the delivery channel.

Regards,
-Arvola