Re: No consensus on draft findings on Unsafe Methods (whenToUseGet-7)

Mark Nottingham wrote:

> The main issue is that it can't be called a binding - because it doesn't 
> in fact provide an abstract, transparent messaging substrate for SOAP; 
> instead it severely limits it, by imposing:
> 
>  * RPC only
>  * request-response MEP only
>  * Section 5 encoding only (and references would need to be addressed)
>  * no Headers (except for those that can be abstracted out as HTTP features)
>  * no support for SOAP envelope versioning, etc.

So what's your point?  I've been explicit that this only works for the
subset of SOAP transactions for which a GET method semantic makes
sense, and is not trying to support all or even very much of the
functionality of SOAP.

> I've mused in the past that it might be itself considered a feature (or 
> whatever the current term is) of the HTTP binding; "if you fit the 
> profile of all of the above restraints, and your request is 
> safe/idempotent, you can use the GET feature."

Yep.

> 
> XMLPWG didn't show much interest [2] in this approach, and that isn't 
> surprising; it doesn't fit cleanly into SOAP, and the use cases, 
> although evident now (because so many people see SOAP as just 
> RPC-using-XML-over-HTTP), are pretty uninteresting in the face of where 
> most vendors want to take SOAP. I've already spoken about the dubious 
> value of HTTP caching to SOAP, so the only remaining tangible benefit is 
> linking/bookmarking.

It's precisely the job of the TAG to worry about web architecture,
especially when it appears that other WGs are blowing it off.  The
response to issue 133 is not exactly comforting.

> Because of this, I agree that it's not a good idea to mandate that 
> XMLPWG "fix" this problem (unless a hitherto non-evident desire to do so 
> is displayed). If it will get us past this, I'll be happy to help put 
> together a NOTE which defines a HTTP binding feature that accomplishes 
> this

Sounds good to me. -Tim

Received on Monday, 22 April 2002 00:36:42 UTC