RE: Reliable Messaging Spec v0-078

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

your suggestions are well taken. stay with us on this. we are just dialoging
now. i don't care how we do it i just want to be able to compare this at the
same protocol level as smtp, http, etc.... this is a very important issue.

I want to be able to make statements like " ebxml transport is the
completely comparable at protocol technical level to smtp or http, is more
efficient, has basic RM and embedded security. It is lower cost to implement
and operate that http/webserves and is easier to support. it is a better
protocol for small, medium and large business ec than the others"

do you see where i am going? I need a solution, you definitely have the
background to work with gordon, and dale moberg on a solution..... please
keep it up. we need to be transport protocol independent if we can on
this.... so what is the best trade off?

keep up the good! work... rik

-----Original Message-----
From: Ajay K Sanghi [mailto:sanghi@giasdl01.vsnl.net.in]
Sent: Thursday, September 28, 2000 11:16 PM
To: Rik Drummond; gvh@progress.com
Cc: ebxml-transport@lists.ebxml.org
Subject: RE: Reliable Messaging Spec v0-078




> 	- running ebxml on top of another protocol just adds one
> more layer to the
> stack and is not deemed elegant in some "experts" eyes.... which
> means it is
> not a "real one"
>

But putting all the protocol-stack related functionality in ebXML-RM may be
unwiser in my opinion. In my very first communication to Jim, I suggested
making RM very lite (just a glue) and to drop the idea of resync and
recovery. But the moment resync and recovery is a "requirement", then it's
better it get's developed as a separate layer, for which I suggest looking
at BX.25. If BX.25 is working over X.25 and Bell labs (piscataway branch) is
still using it, then I won't be surprised if they have already made it work
over TCP as well. They may even fund it's development, who knows. May be the
term "BX.25" should be replaced by something like RESCOV (resync and
recovery) protocol.

Regards,

Ajay

> just some thoughts... rik
>
>
> -----Original Message-----
> From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
> Sent: Thursday, September 28, 2000 7:27 AM
> To: Ajay K Sanghi
> Cc: Rik Drummond; ebxml-transport@lists.ebxml.org
> Subject: Re: Reliable Messaging Spec v0-078
>
>
> While creating a new protocol specifically for ebXML sounds interesting,
> the business questions to ask are:
>
> - What benefits would it have over RM-over-HTTP? RM-over-SOAP? Reliable
> W3C XP (should such a thing come to pass)? I'm assuming
> performance--could this be quantified? What else?
>
> - Why do this specifically for ebXML?
>
> - What do we believe the adoption would be?
>
> - How would it position ebXML?
>
> -gvh-
>
> Ajay K Sanghi wrote:
> > >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?
> >
> > I assume, you mean making ebXML as first class application (or
> application
> > protocol) over TCP/IP, just like SMTP, HTTP and issues/concerns
> associated
> > with the same.
> >
> > Yes, I would like to see ebXML sit directly on top of TCP/IP (at later
> > date), with SMTP as an excellent starter.
> >
> > I noticed Martin using the term "logical channel" in response
> to Sanjay's
> > email, which is a key point. In my earlier mail, I suggested
> going through
> > BX.25 specs ("B" stands for Bell Labs), which are very comprehensively
> > done - used by AT&T for their NEMOS and 800 DCS project (that was 1992).
> > Basically, one LAPB link can contain multiple X.25 virtual circuits
> (logical
> > channels) and each virtual circuit is dedicated to one BX.25 session (I
> > think - it has been a while I worked on it). Over and above all the
> > reliability that X.25 provides, BX.25 was mainly used for
> session recovery
> > (if lost virtual circuit) and resynchronisation (continue from the point
> > where it let off). Key thing leveraged from X.25 was "flow control"
> besides
> > "reliability". ebXML should also leverage flow control and
> reliablity from
> > TCP.
> >
> > Following is just loud thinking-
> > Assumption: well known port for ebXML is defined (say 1000).
> > Context: <sender ip, reciever ip, sender port number, receiver port
> number>
> > forms unique combination to connect to an instance of application
> > Scenario:
> > One ebXML receiver (server) is listening on port 1000
> > One sender sending 2 ebXML messages concurrently,
> > case 1: on 2 different sender port numbers
> > case 2: on 1 (same) sender port number but the 2 ebXML messages are
> > multiplexed
> >
> > case 1 does not have the problem associated with flow control. i.e. one
> > ebXML  session blocking the other
> >
> > case 2 would involve building flow control in the ebXML RM layer so that
> the
> > other ebXML message is not blocked - defining flow control
> would increase
> > complexity, besides invloving negotiation at application
> protocl layer for
> > the window size, etc.
> >
> > more cases can also be introduced like the receiver re-connecting on a
> > different port for each ebXML message once the ebXML listener
> identifies a
> > ebXML message request...
> >
> > Issues:-
> > 1. should ebXML RM support auto resyncronisation and recovery after the
> > session has been timed-out.
> > 2. if yes, how to identify the resynchronisation point. resync should be
> > supported for "best effort" cases also, once the decision is yes (may be
> as
> > optional feature).
> > 3. sequence number is ok for resync purpose but then a "session-id"
> (logical
> > channel) should also get added. who allocates the session-id? sender or
> > receiver? since it's going to be common to both. Also, some more resync
> > protocol messages have to be added.
> > 4. Who initiates the recovery and resync process (sender or receiver or
> > combination of both)? for example,sender recovers but receiver resyncs.
> Note
> > recovering has to do with only identification of the lost session, while
> > resync has to identify the point within the session from where data
> transfer
> > is to begin.
> > 5. should ebXML RM assume window size of 1, or should a window
> be defined.
> I
> > think, window complexity should not be added.
> > 6. does session establishment involve any negotiation for QoS. Can
> receiver
> > deny "at most once" effort to downgrade the session to "best effort".
> > 7. Delivery confirmation can be achieved even without sequence numbering
> but
> > for resynchronisation, sequence numbering  (or some identification) with
> > every packet is required
> > 8. I find timing-out at RM level quite dicy, without the knowledge of
> timers
> > at lower level as mentioned in my earlier email. I think
> retrying to send
> > the data at RM level should be replaced by re-establishing for
> resync and
> > recovery in case that is to be supported.
> > 9. arhcitecturally, it seems there would be one ebXML listener and each
> call
> > reqquest would be handled by a different thread
> >
> > these are some of the points that i can immediately think of...
> >
> > Thanks and regards,
> >
> > Ajay
> >
> > > -----Original Message-----
> > > From: Rik Drummond [mailto:rvd2@worldnet.att.net]
> > > Sent: Wednesday, September 27, 2000 9:53 AM
> > > To: Ajay K Sanghi; ebxml-transport@lists.ebxml.org
> > > Subject: RE: Reliable Messaging Spec v0-078
> > >
> > >
> > > 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
> > > >
> > >
> > >
>
>