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

Re: A tale of two bindings

From: Jacek Kopecky <jacek@idoox.com>
Date: Wed, 25 Jul 2001 14:00:59 +0200 (CEST)
To: <mark.baker@sympatico.ca>
cc: Rich Salz <rsalz@zolera.com>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0107251153080.5375-100000@mail.idoox.com>
Mark, please see my replies inside.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Tue, 24 Jul 2001, Mark Baker wrote:

 > > The list of differences is completely ridiculous.  I can write
 > > tunnelling-oriented SOAP right now, and the only difference between what
 > > I use and your "application semantic" binding is whether faults come
 > > back using 500 or 200.
 >
 > And the use of port 80, at a minimum.  There could very well have
 > been other major differences, as my tunnel-binding wasn't completely
 > specified as you may have noticed.
 >
 > A binding is not a trivial piece of design work.  I'm quite sure one can
 > be quickly thrown together, but when done without a set of requirements,
 > could potentially do major damage.

You are certainly right here. All my email is based on my
informal understanding of what the requirements are:
1) addressing nodes
2) transmitting the infoset from one node to another

You can add more, see below.

 > > > (**) A tunnel binding only requires a single bit of SOAP-identifying
 > > > information on an inbound message in order to unambigously identify
 > > > to a receiving implementation that a tunnel needs to be established.
 > >
 > > Not at all.  It could be completely up to the local server
 > > configuration.  I could write all my web services as CGI scripts and
 > > nobody would know.
 >
 > You mean that the use of a tunnel could be hidden from intermediaries?

 Intermediaries can be explicit or hidden, SOAP and transport.
 Explicit or hidden transport intermediaries are for example the
HTTP the proxy servers (explicit or transparent), firewalls. HTTP
proxies needn't know it's SOAP, as long as the caching etc.
headers are set properly; firewalls on the other hand might want
to know, see below.
 Explicit SOAP intermediaries are addressed explicitly and
directed the payload at, so they only need the payload, not any
HTTP stuff.
 Hidden SOAP intermediaries, something like a transparent SOAP
proxy, might need to identify that "it's SOAP being transported
here". Do you have a use-case for these?

 > Ouch, I'm sure firewall admins would just love the W3C for that one.

 I guess you mean a hidden transport intermediary (according to
my split-up above). Yes, you might want to filter out incoming
SOAP requests. Then the MIME type or SOAPAction header could be
used. See below.

 > While we can't stop anybody from tunneling, we should certainly aim
 > to provide a binding that makes it cheap and easy for tunneling to
 > be detected.  To not do so would be to commit a major security
 > faux pas.

I think the easiest solution (and one that is also portable to
other MIME-based protocol bindings) would be the special MIME
type like the one that's been proposed a lot:
application/soap+xml
Received on Wednesday, 25 July 2001 08:01:28 GMT

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