RE: [ebxml-msg] Can an MSH send a sync ack and then an async resp onse?

[Dale Moberg <dmoberg@cyclonecommerce.com>]

David, David, and Cliff,

Arvola stated (see below):

"Cliff:
The syncReplyMode value of "mshSignalsOnly" was agreed by the  team*
during
the conference call of 10/22/2001.  See
http://lists.oasis-open.org/archives/ebxml-msg/200110/msg00174.html."

* the team being referred to here is the Messaging TC.

The CPPA team followed the Messaging group's lead and is adding this
value to the CPA. The presence of this value documents a behavior
of packaging/transport that Messaging has said was to be allowed
(as reported to them by Arvola.) (Incidentally, Ralph B.
noted that allowing the option was desirable.)

To in any way construe the situation as:

"that changes to the CPP/A spec were
implicity changing the behavior of the MSH spec"

is without foundation, historically baseless, and needlessly
contentious.  

If CPPA does allow software to be
configured to make use of options that
are not "in" the Messaging spec, (like digital
enveloping using application/pkcs7-mime), software
that is strictly ebXML and nothing else can
1. omit non-ebXML capabilities from its CPPs
and 2. throw an error when an attempt is made
to load a CPA involving those capabilities.
Preventing the CPPA TC from being able to express
such features might be regarded
by that group as interfering with their independence.

If we in Messaging do plan to change
the packaging/transport options allowed in the ebMS
specification, the CPPA team would certainly 
appreciate and benefit from being informed. 
Otherwise, they will probably retain the 
values/options that the Messaging TC has previously 
identified, and which have been reported to them by Arvola.

CPPA does not at present have 
all of David Fischer's options:

None
SignalsOnly
ResponseOnly
SignalsAndResponse 
mshSignalsOnly
mshSignalsAndSignals
mshSignalsAndResponse
mshSignalsAndSignalsAndResponse

Are all these modes ones Messaging  really wants 
to support? As a Messaging group member,
I would like to have an opportunity to discuss whether
some of these modes are really useful. 

Also, a number of minor editorial changes and 
clarifications are still trickling in. Though
I voted for approval, I did not imagine that
this vote precluded making useful changes as 
they are noted. Could we have some clarification
on when the changes will be made? 


Dale Moberg


Marti

I was responding to the comment made originally made by Cliff Collins at
[1]
and confirmed by David Fischer at [2] that changes to the CPP/A spec
were
implicity changing the behavior of the MSH spec.

I have gone on record many times before that this tight coupling between
the
specs is wrong and should have been avoided but accept that it is too
late
to do anything about it for this version. However if there is a tight
coupling between the two specs we should make it explicit and update the
introduction to reflect this in the way that David Fischer suggests at
[3].

Finally Marty, please remember that I an NOT anti-CPA I just want the
relationship between the CPA and the MSH specs to be "right" with less
coupling than currently exists.

No doubt there will be debate around this when we plan what goes into
the
next version.

David
================
[1] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00154.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00158.html
[3] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00161.html


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Sunday, January 20, 2002 1:15 PM
To: David Fischer
Cc: Burdett, David; Arvola Chan; Cliff Collins; Cherian Sanjay;
ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Can an MSH send a sync ack and then an async
resp onse?



David,

I cannot imagine what changes could be made to the CPP-CPA specification
that could possibly affect the words that you are quoting.

What do you have in mind?

Regards,
Marty

[ tail truncated in the interest of bandwidth conversation]