RE: Reliable Messaging Spec v0-078

[Rik Drummond <rvd2@worldnet.att.net>]

Ajay. thanks for the nice comments on the draft everyone has been working
their butts off...

we decide to make this transport independent. i have been thinking about it
work directly over tcp/ip, as we are now doing with smtp and http... what do
you think of that? and are there any concerns?

best regards, rik

-----Original Message-----
From: Ajay K Sanghi [mailto:sanghi@giasdl01.vsnl.net.in]
Sent: Monday, September 25, 2000 6:46 AM
To: Jim Hughes; ebxml-transport@lists.ebxml.org
Subject: RE: Reliable Messaging Spec v0-078



Hi Jim,

Since this is my first communication with the ebXML group, I take this
opportunity to congratulate ebXML team for excellent work being done. In a
very recent Bill Gates talk in New Delhi, I asked him the question of
Microsoft's position w.r.t ebXML, particularly in relation with Biztalk. I
don't hink he has heard of ebXML, unless he was unable to understand my
Indian accent ;-) All he said was that Interoperabilty is more important
(agreed) and that XML will facilitate that (he was speaking on Microsoft's
.NET strategy).

I am reading Sep 22, 2000 spec for ebXML TRP Reliable Messaging. I feel that
Sequence Numbering is NOT required for achieveing Reliablity at ebXML MSH
layer. We must leverage reliablilty provided by the protocol themselves.

Assumption for Reliable Messaging should only be that it should use a
(reliable) connection oriented protocol (CONS like X.25, TCP - they are
reliable, meaning "ordering" is guaranteed). However, this reliablity does
not "guarantee" that the ebXML MSH has received the message, for which a
"delivery confirmation" element/attribute may be added instead of sequence
number. Whenever delivery confirmation element/attribute is set to YES, the
receiving MSH will respond with ebXML message (just the ebXML header,
confirming receipt). Note (Key Point) - on account of this message (delivery
confirmation request message) riding on top of CONS, a response to this
message would necessarily mean that all previously sent messages has been
received. Infact, if the recieving MSH is sending back some data, this
delivery confirmation response can be piggybacked. There is absolutely no
need for persisting packets as suggested in the specs. This delivery
request/response can be thought of as a ebXML-MSH-ping.

Suggestion for Timeout/Retry is ok provided MSH-timeout is of greater
interval than what it is at the tranport level (tranport-retries*timeout),
otherwise it will cause grieve. If retires are to be done by MSH, then
sequence numbering "may" be required for checking duplicates (not for the
purpose of delivery confirmation), since for the sending transport layer,
it's fresh data. In first phase of ebXML specs, I'll be tempted to drop this
idea too - the logic being that if it can't be delivered even with
transport's retries and timeout, then there is a good chance it won't be
delivered with ebXML-MSH-retries as well. Sending application should simply
abort and send the message at some other time.

I am in favor of ebXML-MSH, but it should only be used to enable certain
services (as glue) that CONS transport is supporting or to build something
on top of what reliable transports support, if absolutely required. For
example Q-ualified data (used for out of band signalling in X.25) can be
used for signalling End of File for file transfers. Alternate to Q-data way
of sending End of File would be to first send the size of file. The Delivery
confirmation (D-bit) logic in X.25 protocols should be looked into. Also, of
interest may be some other attributes like fast-select (sender sends
connection request along with small data and the receiver sends back data
along with call termination - verifone (I think) used to use this for credit
card verification)

However, if the goal is to provide Relibility over Unrealible connectionless
protocols (CLNS - like UDP) then use of sequence numbering is ok. I suggest
that X.25 protocol is looked at to see the problems assoicated with sequence
numbering, especailly in case MSH is queuing data and not sending it to the
application (see how RNR is used). My suggestion is that ebXML should not
address reliability over unreliable protocols.

Just a suggestion.

Thank you and regards,

Ajay

Ajay K Sanghi
Managing Director

ABO Software Private Limited
B102 Gulmohar Park, New Delhi 110049
Tel: +91 11 6512816, 6512822 Fax: 6518873
Website: http://www.abosoftware.com
email: ajay@abosoftware.com

> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Sunday, September 24, 2000 4:30 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: Reliable Messaging Spec v0-078
>
>
> Attached are Word and PDF copies of the latest version of the Reliable
> Messaging Spec, for discussion on Wednesday in the F2F. Shimamura-san has
> added much more detail on reliability issues, and of course the
> earlier use
> of Message Groups is now deleted for simplicity. Since there were many
> changes, I deliberately did not mark changes in this document,
> but you can
> easily see them by using Word's compare utility against the
> previous version.
>
> [Ralph, could you have some copies of the document available on Tuesday,
> for those that might not have access to a printer before
> travelling to Dallas?]
>
> Jim
>