Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP bi nding preamble.

Sure, but that isn't the point; the point is that SOAP 1.2 doesn't
offer a way to make idempotent requests in a way that is compatible
with the Web architecture. The WG's HTTP binding is, at best,
incomplete, *if* "compatibility with the Web architecture" is
considered a requirement. 

Such a requirement isn't stated in the Requirements document or the
Charter. An argument could be made that it's self-evident, since the
WG is a) in the W3C and b) is chartered to define an HTTP binding.



On Tue, Feb 19, 2002 at 06:49:54PM -0000, Martin Gudgin wrote:
> Seems to me that nothing in our spec precludes someone from
> defining a GET based binding. I don't think our HTTP binding is
> such a beast. I don't see the GET binding as being in the 'minimum
> required to declare victory' space.
> 
> Gudge
> 
> ----- Original Message -----
> From: "Mark Nottingham" <mnot@mnot.net>
> To: "Martin Gudgin" <marting@develop.com>
> Cc: "Paul Prescod" <paulp@ActiveState.com>; "Williams, Stuart"
> <skw@hplb.hpl.hp.com>; <xml-dist-app@w3.org>
> Sent: Tuesday, February 19, 2002 5:42 PM
> Subject: Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP
> bi nding preamble.
> 
> 
> >
> > Hi Gudge,
> >
> > On Tue, Feb 19, 2002 at 12:22:35PM -0000, Martin Gudgin wrote:
> > >
> > > It is unclear ( to me at least ) how such a call would differ from
> > > a standard HTTP GET. What would make it SOAP? Just the fact that
> > > the HTTP response would contain an Envelope element? Or the fact
> > > that the Content-Type header of that response would be
> > > application/xml+soap? Or both?
> >
> > Speaking only for myself (there seem to be a number of positions on
> > this issue!), this (both) is what I'd like to see.
> >
> > Why bother? Because if it's not specified, it won't be widely
> > implemented. The 'profiles' (not my term) of SOAP use that get
> > defined early are important. It gives you compatibility with the Web
> > architecture, low-level caching, etc. and is easy to do.
> >
> >
> > > Also, given that the Envelope will *NOT* be used to serialize the
> > > request is it really SOAP, given that the Envelope is a core part
> > > of the spec? Given that the envelope is hierarchical ( it is an
> > > Infoset, after all ) I'm not sure I can see a reasonable way to
> > > encode it into the query string ( although I can see how you might
> > > encode very simple requests into the URI ).
> >
> > I'm not too concerned with 'what is SOAP/is it SOAP' arguments,
> > because SOAP is a pretty slippery concept (is it a messaging
> > framework? an RPC protocol? A substrate of HTTP? a layer? ... ).
> >
> >
> > > Also, it would seem *VERY* problematic to try and use SOAP Headers
> > > in such an example, where are we supposed to put those in a GET? I
> > > understand that idempotent HTTP requests should use GET. But it
> > > seems that some of the things I might want to include in an
> > > idempotent SOAP request might include SOAP headers. Are you
> > > suggesting we define a way to encode SOAP headers as HTTP headers?
> >
> > I'd say no; in the request, they can use features of the underlying
> > protocol, but there is no slot for an envelope (or maybe just
> > headers; see below). Yes, this is a constraint on the use of the
> > binding, but it's useful, and I don't think it breaks SOAP to define
> > it.
> >
> >
> > > Or maybe the query string should just be ?xml='<soap:Envelope....'
> > > in which case perhaps all these problems go away... Is that what
> > > you think we should do?
> >
> > No! There should be an effort to specify how to express section
> > 5-encoded data into a query string; it may even attempt to defined a
> > framework for expressing SOAP headers as HTTP headers (although I'm
> > a bit doubtful about this one).
> >
> > You end up with something with following properties:
> >   - uses GET
> >   - request only allows bodies with section 5 encoding
> >     (which are serialised in the query string)
> >   - all HTTP protocol features are available
> >   - no SOAP headers are possible in the request (but see above)
> >   - response is a normal HTTP/SOAP response
> >
> > I don't know if this is a new binding or a binding feature of the
> > HTTP binding; perhaps it's a feature, since it limits the
> > functionality of the envelope.
> >
> > (I'd put my hand up to do a proposal for this, but I can't prioritise
> > it right now; if there's support for the idea, though, I'll see what
> > I can do.)
> >
> > Cheers,
> >
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 19 February 2002 15:05:26 UTC