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:09:01 +0200 (CEST)
To: Eugene Kuznetsov <eugene@datapower.com>
cc: <mark.baker@sympatico.ca>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0107251401180.5375-100000@mail.idoox.com>
 I don't think that intermediaries necessarily need a SOAP
identifier in the message.
 If the SOAP intermediary is an explicit one - i.e. the message
is being sent _to_ this intermediary (with further routing
information available from any source), then it's just like what
you mean in end-to-end.
 If on the other hand the SOAP intermediary is a "transparent"
one (as in transparent HTTP proxy), it might use some kind of
indication that an HTTP message is a SOAP message. Here my
favourite is the standardized SOAP-specific content type.
 I don't think that non-SOAP intermediaries need to know it's
SOAP that they carry, but anyway the content-type should suffice
here as well.

                            Jacek Kopecky


On Tue, 24 Jul 2001, Eugene Kuznetsov wrote:

 > > As for your (**): you don't _need_ anything to identify that what
 > > you're transmitting is SOAP because the thing behind the request
 > > URI should know that.
 > I disagree -- unless there is a well-standardized Content-Type
 > that is SOAP-specific (IOW, "app/soap+xml", not "text/xml"), the
 > various intermediaries, security devices and so on will have a
 > difficult time figuring out if "/site/foo/bar.cgi" is SOAP or
 > a web page request.
 > What you are saying makes perfect sense when it goes from end-to-
 > end, but the picture gets more difficult as one starts adding
 > various SOAP and non-SOAP intermediaries along the way.
 > As for dispatching on the basis of the content, that's important
 > as well -- it's just that there are multiple levels, all the way
 > from TCP ports to HTTP protocol to SOAP envelopes to SOAP payloads.
 > Different parts of the network have different needs and capabilities
 > along that entire protocol stack.
 > \\ Eugene Kuznetsov
 > \\ eugene@datapower.com
 > \\ DataPower Technology, Inc.
Received on Wednesday, 25 July 2001 08:09:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC