- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Thu, 12 Jul 2001 12:13:00 +0100
- To: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>
- Cc: xml-dist-app@w3.org
> I actually don't think it matters whether our spec is packaged in one or > two documents. What to me is the important thing is the scope of the > binding. > > I absolutely agree with the scope of the BEEP binding in that it talks > exactly about how BEEP core is mapped to TCP and how BEEP core may take > advantage of TCP features with an eye for performance. The wording I was referring to as a *very* short section in the BEEP Core Spec (RFC3080) not the BEEP/TCP mapping (RFC3081). If you like, it's the plug in the core spec which describes what BEEP expects of a mapping to some transport service. > Note that BEEP defines much more than SOAP core does (everything that relates to > channels etc) so it is to be anticipated that their binding is much > bigger. Yep... they provide a richer abstraction than unsequenced, unreliable, uncorrelated one-way messaging. > As an example, you can find a SOAP-RP/DIME binding to TCP at > > http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html#N0700 > > Henrik Indeed I have looked at and read the SOAP-RP/DIME binding to TCP. It is consistent with unsequenced, unreliable, uncorrelated one-way messaging. It could have leveraged ordering and reliablity from the TCP channel, but does not: the requirement to reuse a TCP connection is a (maybe strong) SHOULD, not a MUST and multiple TCP connections are allowed between SOAP-RP peers; when closing a SOAP-RP TCP connection the SOAP-RP spec states "If a TCP connection is closed and there are outstanding messages that were to be sent on the implicit reverse path, then these messages SHOULD be discarded." which admits some albeit rare message loss possibilities. > >Do you think we should be doing something similar? > > > >Jean-Jacques. > > > >"Williams, Stuart" wrote: > > > >> I was recently referred to section 2.5 of the Beep Core spec. It's an > >> enviably concise and compact definition of what BEEP expects of a > >> mapping to a particular transport service. Stuart
Received on Thursday, 12 July 2001 07:13:10 UTC