ebxml-cppa message

Subject: Re: RosettaNet Retry Parameter not Expressible in BPSS or CPP/A
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Arvola Chan <arvola@tibco.com>
Date: Thu, 23 Aug 2001 17:09:12 -0400

Arvola,

Do you view the retries as being initiated by the Message Service or by the
application?  If they are initiated by the Message Service, then I agree
that DocExchange is the place for the specification.  If they are initiated
by the application, then the specification really belongs in the BPSS.

If the retries are initiated by the Message Service, then a single Retries
element should be satisfactory.  It could be deleted from the
ReliableMessaging element and added as a child of DocExchange.  Presumably
RetryInterval would accompany Retries.

Do these retries require a specifiable timeout value?

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



Arvola Chan <arvola@tibco.com> on 08/23/2001 04:38:43 PM

To:   ebxml-cppa@lists.oasis-open.org
cc:
Subject:  RosettaNet Retry Parameter not Expressible in BPSS or CPP/A



Existing RosettaNet PIPs do not require exactly once delivery semantics.
Asynchronous PIPs have a Retry parameter that governs how many additional
retries a sender will send a message, if it has not received a Receipt
Acknowledgement signal from the other party.

Currently, BPSS does not allow for the specification of a retry count. At
the CPP/A level, the only available retry parameter is associated with
reliable messaging. It is not clear if RosettaNet should always use
reliable
messaging for all PIPs.

Ideally, the DocExchange element should carry an alternate Retry element
that is not tied to reliable messaging. Otherwise, it will be great fi
extension mechanisms whereby namespace qualified extension
elements/attributes can be added. This is an approach that is used both in
SOAP and in the Message Service to provide extensibility.

-Arvola






----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>