Re: HTTP binding options

Oh yeah I guess I am being inconsistent. Yes, I'm quite ok
with doing (3) - I'd say we must do (3).

Sanjiva.

----- Original Message ----- 
From: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: <www-ws-desc@w3.org>; "David Orchard" <dorchard@bea.com>
Sent: Thursday, November 13, 2003 8:44 PM
Subject: Re: HTTP binding options


> So does this mean you are now advocating option 3 (option 2 only 
> supports HTTP POST, as far as I can see)?
> 
> Jean-Jacques.
> 
> Sanjiva Weerawarana wrote:
> 
> > I'd say we support HTTP GET for idempotent operations just fine- 
> > if you read what Mark said, the idea of the URI being dependent
> > on the message contents is not a required part of Web architecture.
> > 
> > Even the SOAP Response MEP doesn't go as far as (5) - that has
> > a no-input requirement. So we're really in virgin territory by
> > going that far and its at a pretty high price (lots of restrictions
> > on the input (follow RPC style + simple types only), weirdness of
> > whether the input is really the input and a pretty complex language
> > to boot).
> > 
> > Sanjiva.
> > 
> > ----- Original Message ----- 
> > From: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
> > To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
> > Cc: <www-ws-desc@w3.org>; "David Orchard" <dorchard@bea.com>
> > Sent: Thursday, November 13, 2003 7:34 PM
> > Subject: Re: HTTP binding options
> > 
> > 
> > 
> >>After having read the entire thread, I'm still inclined to go for (at 
> >>least) option 3).
> >>
> >>It would be interesting to know if the TAG is likely to raise an issue 
> >>if we don't support HTTP GET (for idempotent operations), like it did 
> >>for SOAP 1.2.
> >>
> >>David, any (wild) guess?
> >>
> >>JJ.
> >>
> >>Sanjiva Weerawarana wrote:
> >>
> >>
> >>>The "HTTP binding table" at the post-meeting lunch came up
> >>>with the following possible options for the HTTP binding:
> >>>
> >>>option 1:
> >>>    drop HTTP binding completely
> >>>
> >>>option 2:
> >>>    define a POST binding only with the natural binding possible:
> >>>    input becomes POST body and output must be POST response
> >>>
> >>>option 3:
> >>>    define option 2 +
> >>>    define GET binding for operations with MEP=in-out and with no
> >>>    input body (i.e., GET goes to http:address URL) and the output
> >>>    must be the GET response
> >>>
> >>>option 4:
> >>>    define option 3 + 
> >>>    define GET binding for operations with MEP=in-out and @style=rpc
> >>>    ala the WSDL 1.1 binding, but with rules to move all parameters 
> >>>    into query parameters. (That is, no URL rewriting ala WSDL 1.1.)
> >>>
> >>>option 5:
> >>>    define option 4 +
> >>>    add URL replacement to allow different parts to go in the URL
> >>>    itself vs. as query params
> >>>
> >>>There was pretty strong sentiment against doing (5). (4) has the
> >>>negative that the value of operation/@style is bleeding into the
> >>>binding - which would be unfortunate. (3) is interesting and can
> >>>be generalized a bit for other MEPs if needed. An interesting twist
> >>>on (3) could be to allow appending a relative URL to the adresss
> >>>on a per-operation  basis. That's not without price (inconsistent
> >>>use of xml:base for relative URLs for one).
> >>>
> >>>My current preference is that we do option (2).
> >>>
> >>>Sanjiva.
> >>>
> > 
> >

Received on Thursday, 13 November 2003 09:56:08 UTC