RE: Reliable Messaging Spec v0-078

[Ajay K Sanghi <sanghi@giasdl01.VSNL.NET.IN>]

Hi Jim,

It's unfortunate that an effort as majestic as ebXML is Unsponsored.

>Thus, a
> current ebXML
> tenet is to provide some level of "reliability" over *all* transports.

To me it seems that ebXML goal is to be able to sit directly on top of Frame
Relay as well, for which a "comprehensive" sequencing mechanism would be
required. Not only the receiver but also sender may have to persist
ebXML-packets, until acknowledged. Because Frame Relay will simply drop (eat
away) packets without informing the higher layer, for various reasons and
leave it for application to recover from it.

If not already looked into, it may be worth the effort to look into-

1. CCP (common communication protocol) developed by AT&T. It is a
communication API (AT&T also has C++ version of it) used by AT&T developers
to program in a transport independent manner.

2. BX.25, which provides ideas for resynchronisation and recovery of lost
virtual circuits.

I wish the initial ebXML goal was to assume TCP/IP (which can sit on top of
Frame Relay as well) and keep it simple, more so because, "Internet" is the
target medium. Also, based on versioning of the ebXML header, new things
(header elements, functionality etc) can always be added at a later date.

Thank you and regards,

Ajay

> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Monday, September 25, 2000 9:26 PM
> To: ebxml-transport@lists.ebxml.org
> Subject: RE: Reliable Messaging Spec v0-078
>
>
> Ajay -
>
> One of the basic assumptions for RM is no knowledge of the particular
> transport, particularly QoS characteristics such as reliability,
> timeouts,
> etc. If we assume some kind of "reliable" protocol, as you suggest, and
> then add (maybe) some additional "reliability" for ebXML
> purposes, then we
> get into a lot of issues... For simplicity, at this first level, we don't
> make assumptions but I suspect that in a later phase this work
> might be done.
>
> Regarding the point in your last paragraph, the UN-sponsored
> ebXML project
> is focusing on a solution that would support business in all parts of the
> world, even where unreliable transports are not available (or, at least,
> where networks might have unreliable links in them). Thus, a
> current ebXML
> tenet is to provide some level of "reliability" over *all* transports.
>
> Regards,
>
> Jim Hughes
> Fujitsu
>
> At 05:15 PM 9/25/2000 +0530, Ajay K Sanghi wrote:
>
> >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
> > >
>
>