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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: End-to-end RM


What I said on the call was that the TR&P team decided, after careful
and lengthy deliberations that ebxml RM was point-to-point, not end-to-end.
I did not say that end-to-end is not needed. This is the distinction
I am drawing. The T2 charter is not to add new functionality, but to
address any errata in the specification. Since the specification does
not address an end-to-end reliable protocol, any consideration would
be for a subsequent version of the specification (T3 or version 2.0).

Of course, I will also (re)state that the specification DOES provide for
the sender to learn of a failure in the delivery of a message to its
ultimate recipient by means of a DeliveryFailure message sent by
a node that cannot deliver a message at some point along the message
path. See section 10.4 of the 1.0 specification.

Marty Sachs has raised the issue [1] that this section, because it says
SHOULD instead of SHALL may represent a flaw in the protocol. At first,
I thought that the term SHOULD was all that could be stated in the
specification. After further thought (I was originally opposed) I think 
that this suggested change may indeed be necessary, but we'll have to
also address the aspect that the sending application may not have a 
direct means of dealing with a delivery failure. e.g. we cannot
specify what an originating MSH is REQUIRED to do with a DeliveryFailure
error message other than possibly to log the error as a minimum

IMO, an MSH, unless it is embued with an intellegence of its own,
cannot be directly responsible for addressing a delivery failure
along a message path for a message for which it has already received
an acknowledgment. It should only be responsible for notifying
the sending party (the application or its administrator, etc.)
of the details of the delivery failure.

I don't ever recall in any context that we ever said that RM can be achieved
over unreliable links. Possibly you mean unreliable transports, such as
HTTP, which is what the RM protocol has been designed to address.

I believe that if a sending party/application says that a message is
to be delivered with a deliverySemantics of OnceAndOnlyOnce that this
quality of service MUST be supported (whether by the ebXML RM protocol
or by "transport" specific means, such as in the case of MQSeries) 
by all MSH nodes in a message path. Maybe the spec doesn't say that 
explicitly, in which case we should address this to make it crystal 
clear in the errata. Something along the lines of:

	An MSH receiving a message with a deliverySemantics="OnceAndOnlyOnce"
	that does not support that level of QOS MUST send
	an Error message to the To Party with an errorCode of NotSupported 
	and a Severity of Error.

Yes, this would mean that this particular message path would be permanently
blocked until such time as the offending node is either removed from the
message path or it is enabled with the RM capability. I don't see this as a 
problem that we need to solve, nor do I ever recall it as being a requirement.
Possibly you are referring to the requirement that RM be achievable over
unreliable transports such as HTTP and SMTP. That is a very different requirement
than that RM be achievable through intermediary MSH nodes that don't support
that level of QOS.



[1] http://lists.oasis-open.org/archives/ebxml-msg/200107/msg00026.html

David Fischer wrote:
> Chris,
> I think we have established on the list the need for end-to-end RM.  However, on
> the call, you asserted the reverse.
> Many times we have made the statement in the various F2F meetings that "reliable
> messaging can be achieved over unreliable links."  Yet on the call you said that
> if RM is requested by DeliverySemantics=1&o1, then if a link cannot do RM it
> must return an error?  This could actually be a permanently block any RM flagged
> message!  These two ideas are not compatible.  The only way to provide RM over
> unreliable links is to "close the loop" with an end-to-end Ack.
> I must continue to maintain that an end-to-end MSH level Ack is required.  This
> is already in the spec and it is called DeliveryReceipt.  The only change I am
> asking for is that DeliveryReceipt be appropriately added to section 10.
> Regards,
> David Fischer
> Drummond Group.

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

Powered by eList eXpress LLC