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: 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.



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,
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
> we can't check compliance.

I agree with both statements above. In fact, I believe Martin is right in
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

My point, as an implementor, was rather  whether the spec can  rightfully
about such a contract today: Without a specified  notification API, I feel
uncomfortable having to interpret an unprecise, yet normative,
requirement - and more
importantly, having to assume the other party does interpret it the same

That is why I am much in favor of APIs between application/administration

and MSH: this would not leave out too much to interpretation, when it comes
communication - and contracts -  between "application" and MSH.
(Note that such API(s) do not have to cover all interactions MSH / App, but
those that
are standardized, or under CPA)


> 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
> delivered, the MSH or process SHOULD send a delivery failure notification
> 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
> reason. If this occurs, then the From party that is the ultimate
> for the error message SHOULD be informed of the problem by other means.
> 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,
> example, there was a communications failure that meant the message could
> 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