OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: new CPPA-MSG interlock issues


The following new issues derive from the MSG meeting today, Oct. 4. The
specifics of the following items are subject to change as the MSG team
refines version 1.1 and some could change as early as tomorrow.  It will be
important to capture these points in our issues data base now in order to
be sure that we track them until the resolutions are certain.

1. This corresponds to MSG spec. issue #1: More details are needed in the
CPPA specification regarding SSL 3.0. The need to state the encryption
algorithm was specifically called out.  Other details may also have to be
specified.  The basic idea is that the CPA needs to state the minimal
acceptable parameter set as input to the SSL dynamic negotiation.  Any
information about SSL that apply to whatever transport protocol it is used
with belong in an SSL subsection directly under "Transport Security" rather
than under "Specifics for HTTP." This probably includes the SSL version,
which is currently under "Specifics for HTTP".

2. The MSG team has tentatively agreed to changes in the way the reliable
messaging semantics are defined.  This will require corresponding
changes/additions in the reliable messaging specifications in the CPP and
CPA.  In brief, the MSG team has agreed to permit all possible combinations
(yes/no) of the following:  deliverySemantics, ackRequested, and
deliveryReceiptRequested.  In addition, deliverySemantics now means only
duplicate-checking.  The effect is that the delivery semantics may now be
onceAndOnlyOnce, atMostOnce, atLeastOnce, or bestEffort, depending on which
of the 8 combinations is selected. Which combination is actually used is
subject to agreement by the two parties and therefore has to be expressed
in the CPA.

3. There may also be a need to specify whether reliable-messaging retries
are based on Acknowledgment or DeliveryReceipt.  This will depend on which
code point is selected under (2).  DeliveryReceipt will  come from the From
party; the Acknowledgment will come from the other end of the first hop.
The MSG team's thinking is that Acknowledgment is only a progress report,
not an assurance of delivery, while the delivery receipt is an assurance of
delivery.


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC