Re: End-to-end RM

[Martin W Sachs <mwsachs@us.ibm.com>]

A few comments below.

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



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 08/14/2001
11:19:33 AM

Sent by:  Chris.Ferris@Sun.COM


To:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
cc:
Subject:  Re: End-to-end RM



David,

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

MWS:  I agree.  The specification can say the delivery-failure notification
SHALL be delivered without prescribing how.

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.

MWS:  The MSH which is responsible for notifying the From Party
of delivery failure is the From
Party's MSH.  The evidence of delivery failure is exhausting the permitted
number of retries without receiving an acknowledgment.  So, there is no
issue about a delivery failure along a message path for which it has
already
received an acknowledgment.  IF the acknowledgment came, the message was
delivered to the destination persistent store.  Of course, I have the
end to end protocol in mind when I say this. A protcol which permits and
intermediary to acknowlege the message and further, permits the message
to be lost farther down the path is not reliable messaging.

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.

MWS:  This is back into the discussion of end to end vs. hop by hop.  As
long as the RM protocol is end to end, it doesn't matter whiat quality of
service is supported in between.  Of course a lousy link in the middle will
cause more RM retries but it won't violate the committments that RM makes
to
the endpoint parties.

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.

Cheers,

Chris

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

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org