W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: T is for Transfer

From: Mountain, Highland M <highland.m.mountain@intel.com>
Date: Thu, 28 Mar 2002 16:43:20 -0800
Message-ID: <ED492E16A0B8D311AC490090276D20841709C0A1@FMSMSX31>
To: "'Eugene Kuznetsov'" <eugene@datapower.com>, Joseph Hui<jhui@digisle.net>, Mark Baker <distobj@acm.org>, Appleton Pete M <PMAppleton@bemis.com>
Cc: "Mountain, Highland M" <highland.m.mountain@intel.com>, xml-dist-app@w3.org
+1 to Eugene

All,

Given the reality of the industry, we need to find the best resolution to
both sides of the transport/transfer argument. SOAP envelopes will be "sent"
via HTTP, BUT we also need to preserve SOAP's protocol neutrality.  I like
Joe's PDU view of the SOAP envelope sitting on top of HTTP(see snip below),
but HTTP does provide features we should not ignore.  Concerns addressed by
Scott Cantor (and others) should be addressed by separate HTTP Bindings.


SOAP 1.2 and the Protocol Binding Framework do not get in the way of these 2
views. What does is the lack of process for developing and publishing
Normative Bindings that the whole industry can reference in a consistent
manner.  Earlier today, Glen Daniels proposed a SOAP module specification
template activity.  While there is a Protocol Binding Framework in the spec,
which is somewhat analogous to Glen's Module Spec Template idea, the process
for publishing Normative Binding Specifications and/or Module Specifications
appears to be lacking.  Until the process of publishing a Normative Protocol
Binding is ironed out and well understood, developers may be driven to use
the Default HTTP POST binding even if another HTTP method is more
appropriate for their application.

Thoughts?

Highland



Joe Hue wrote:
> It's bad engineering to transfer data of identical PDU
> type -- in this case, SOAP is the PDU type -- in separate
> protocols, let alone seperate protocol layers.  (SOAP sits
> above HTTP.)  



Scott Cantor wrote:
.....you're using GET, POST, PUT, DELETE, etc. and following
all the usual, expected rules that HTTP specifies, which allows a whole
lot of interesting things to happen in the world automatically. 

-----Original Message-----
From: Eugene Kuznetsov [mailto:eugene@datapower.com]
Sent: Thursday, March 28, 2002 4:58 PM
To: Joseph Hui; Mark Baker; Appleton Pete M
Cc: highland.m.mountain@intel.com; xml-dist-app@w3.org
Subject: RE: T is for Transfer


> HTTP is not a transport protocol by design; but it doesn't stop people
> from seeing it as one creatively, often for its "port-80 firewall
> friendliness." 

Exactly. One may hold any one of several views on the morality of this
reality, but it's a reality nonetheless.

\\ Eugene Kuznetsov
\\ eugene@datapower.com
\\ DataPower Technology, Inc.
 
Received on Thursday, 28 March 2002 19:44:01 GMT

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