RE: Issue 133, and permitting no body

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: 05 February 2002 00:13
> To: Williams, Stuart
> Cc: 'Mark Baker'; xml-dist-app@w3.org
> Subject: Re: Issue 133, and permitting no body

<snip/>

> > I think that this is not the case with SOAP intermediaries. It is
> > not even clear that a SOAP client knows what resource it is
> > actually referencing... only that, in general, it is referencing
> > the next intermediary along a path. The resource that it actually
> > references (the ultimate recipient, the default actor...) is
> > essentially anonymous.
> 
> So there are two issues here; making SOAPs use of HTTP RESTful, and
> makeing SOAP itself RESTful. You seem to be concerned with the latter
> here. I'd be happy with the former ;)

Actually, I'm trying to form a picture in my mind that doesn't wriggle
around :-)

Kind of gets us back to top-down/bottom-up (again) :-(

I was just seeing in Mark(B)'s description of bodyless SOAP message in a GET
request the notion that *HTTP* intermediaries could treat the SOAP headers
contained therein a bit like more finely targetted HTTP headers. However, at
least as I see it, the HTTP intermediaries really have to be SOAP
intermediaries too. So... if you were wanting to reference
http://example.org/foo/bar/ what request URI would you use in your HTTP GET
request, and to what would the HTTP client initially connect?

<env:Envelope>
  <env:Header>
    <ex:reverseProxyControl 
     env:actor="http://revProxy.example.org/exampleReverseProxy" 
     env:MustUnderstand='1'>

     <!- some proxy control incantations -->

    </ex:reverseProxyControl>
  </env:Header>
</env:Envelope>

Maybe you'll see why the picture feels like its wriggling around abit. Where
I think it probably takes you is a RESTful SOAP (ie. the latter).

 
> I think I'd view SOAP intermediaries as resources that perform an
> operation to an encapsulated message. That message's semantics happen
> to tell it to access another resource, and so forth. There are
> implied semantics for the processing of the response, which include
> interpretation of the response itself. 

So... to some extent that then raise the intermediary above SOAP rather than
intrinsic to SOAP... I'd be fine with that and it would make the whole
multi-hop  MEP thing a WHOLE LOT simpler. Ie. you would seem the 'contract'
as being between the initial sender and the initial recipient, and then a
contact between that recipient and the next recipient and so-forth... but
the contract (at the SOAP level) is then hop-by-hop and not end-2-end.
End-2-End semantics move up to the domain of the entities using SOAP (SOAP
applications?).

> > Nice to chat with you again... can't tempt you back into the WG :-)
> 
> Alas, it's out of my hands.
> 
> 
> Cheers,
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/

Regards

Stuart

Received on Tuesday, 5 February 2002 10:31:25 UTC