[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: reliable messaging
Nonetheless, without the SHALL, reliable messaging is not meeting its committment to the application level. There is clearly no point in continuing to circle around this one on the list server. David needs to call out the SHALL/SHOULD issue for delivery failure notification in his issues list. The team needs to discuss in Palo Alto and come up with a consensus. If the Team agrees on SHOULD, there should be a strongly worded (non-normative) caveat on this one. 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 ************************************************************************************* jacques durand <jacques@savvion.com> on 08/27/2001 02:58:06 PM To: "Burdett, David" <david.burdett@commerceone.com> cc: Martin W Sachs/Watson/IBM@IBMUS, "'christopher ferris'" <chris.ferris@east.sun.com>, ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org Subject: Re: reliable messaging David & Martin: "Burdett, David" wrote: > Marty/Jacques > > I think I agree with both of you. > 1. We need to make much stronger statements about the From Party MSH > notifying the From Party Application that a message was not delivered. > 2. We can't make it a "SHALL" or "MUST" as we have not specified the API and > we can't check compliance. > I agree with both statements above. In fact, I believe Martin is right in saying that the RM contract does not make much sense if only between MSH end points. I also believe it should be between the "From" and "To" parties. (or more precisely, between From, To and the "carrier" (MSH infrastructure)). My point, as an implementor, was rather whether the spec can rightfully standardize about such a contract today: Without a specified notification API, I feel uncomfortable having to interpret an unprecise, yet normative, "notification" requirement - and more importantly, having to assume the other party does interpret it the same way too... That is why I am much in favor of APIs between application/administration layers and MSH: this would not leave out too much to interpretation, when it comes to communication - and contracts - between "application" and MSH. (Note that such API(s) do not have to cover all interactions MSH / App, but only those that are standardized, or under CPA) Jacques > > So let's try and agree some words. How about the following for the > replacement first and last paragraphs in section 10.4 ... > > Current first para (lines 1874-6) ... > >>If a message sent with deliverySemantics set to OnceAndOnlyOnce cannot be > delivered, the MSH or process SHOULD send a delivery failure notification to > the From Party. The delivery failure notification message contains: ...<< > > Revised first para ... > >>A MSH that is not the From Party MSH might receive a message sent with > deliverySemantics set to OnceAndOnlyOnce that it determines cannot be > delivered to the To Party application or other process that is the final > destination of the message. In this case, the MSH MUST send a delivery > failure notification to the From Party that contains: ...<< > > We should also add to the bulleted list ... > >>. a deliverySemantics attribute set to OnceAndOnlyOnce<< > ... as the message should be sent reliably. > > Current last para (lines 1886-9) ... > >>It is possible that an error message with an Error element with an > ErrorCode set to DeliveryFailure cannot be delivered successfully for some > reason. If this occurs, then the From party that is the ultimate destination > for the error message SHOULD be informed of the problem by other means. How > this is done is outside the scope of this specification.<< > > Revised last para, its now two and has sub headings ... > >>10.4.1 From Party MSH Behavior > The From Party MSH that sent a message with deliverySemantics set to > OnceAndOnlyOnce might determine that the message could not delivered. In > this case it is strongly RECOMMENDED that the From Party MSH notify the > application or other process that requested the message be sent of the > delivery failure. This should indicate whether the failure was certain, for > example, there was a communications failure that meant the message could not > be sent, or probable, for example, although the message was sent, no > acknowledgement or delivery receipt was received. > > 1 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC