W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

RE: Protocol Bindings

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 12 Jul 2001 12:13:00 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192545@0-mail-1.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT