RE: T is for Transfer

> From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]
[snip]
> +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.  
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes, HTTP, and the TCP below HTTP, and the IP below TCP,
and the physical network infrastructure below IP, all
provide features that some SOAP nodes would like to use.
And the SOAP nodes can indeed use them without violating
the stack/layering model.  It can be done by borrowing
from Unix's ioctl(2) model.  (Ioctl's counterpart in
networking is getsockopt(3N) and setsockopt(3N), both.)
As a Unix user application can make setsockopt() to
configure socket, TCP, or IP options across layers,
e.g. setsockopt(...,SO_OOBINLINE,...), a SOAP application
should also be able to do so similarly, provided there's
an ioctl-like feature in SOAP.  So far, such feature is
not intrinsic to SOAP.  So one would have to improvise with
SOAP extensions.  (I've been doing that in my research into
SOAP Extensions for Web Services Delivery Networks (SEWSD).)  

The idea is to keep SOAP as clean as possible, no pun intended,
by providing a single interface to reach and touch the gunk
in underlying layers.

BTW, I never wanted to get sucked into SOAP threads.
Aren't you folks supposed to wrap up SOAP 1.2 by April?
The above SOAP-ioctl thing was intended for SOAP 1.3 only.

Joe Hui
Exodus, a Cable & Wireless service
==================================================

> 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 20:58:48 UTC