Re: Issue 133, and permitting no body

 Mark,
 I'm only maybe starting to get far glimpses of what the
non-tunnelists may mean by their non-tunneling approach, so I
meant a "SOAP Application use case", not "other possible
bindings' equivalent use cases".
 I think that from non-tunnelists' POV the binding usecases could 
be sufficient, and if the group shares this POV, it will discuss 
your proposal. I'll just stay skeptic about this approach 
intermixing the layers for a while.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 30 Jan 2002, Mark Baker wrote:

 > >  Mark,
 > >  I'm not sure what you mean by "web architecture", because I 
 > > thought we have yet to see that. 8-)
 > 
 > Heh.  Well, linked off our home page is this;
 > 
 > http://www.w3.org/DesignIssues/Architecture
 > 
 > which includes some discussion about why GET is so special to web
 > architecture.
 > 
 > >  Anyway, from SOAP-centric point of view, a transport binding 
 > > specifies means of getting SOAP messages from one node to 
 > > another.
 > >  I think that your proposal (of making the Body optional) should 
 > > come from a use case independent of any particular protocol 
 > > binding, not from some unusual but possible use of GET method in 
 > > HTTP.
 > >  Do you have any use case for Body-less messages that is 
 > > independent of HTTP?
 > 
 > Sure.  How about FTP RETR, IMAP LIST, NNTP ARTICLE, or any other
 > idempotent retrieval method from any application protocol?  A SOAP
 > binding to any of these protocols may necessitate the need to do
 > such a thing, unless you only want to tunnel.
 > 
 > I don't know about the practical implications of including a body with
 > all of those protocols, but it's possible that some don't disallow
 > bodies like HTTP.
 > 
 > Anyhow, I brought this up because I thought it could help address issue
 > 133.
 > 
 > MB
 >

Received on Wednesday, 30 January 2002 16:22:57 UTC