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


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



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


Powered by eList eXpress LLC