- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Mon, 15 Jul 2002 11:29:16 +0100
- To: "'Mark Baker'" <distobj@acm.org>, Jacek Kopecky <jacek@systinet.com>
- Cc: Marc Hadley <marc.hadley@Sun.COM>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi Mark, > Hi Jacek, <snip/> > Well, as it stands right now, the Web method is exposed as a property. > So you're suggesting replacing it with a "safe" property and removing > any mention of the method? This is my understanding of Stuart and > Marc's positions. I have *NOT* proposed the removal or renaming of the Web Method feature. I have *NOT* proposed that it be made optional for the HTTP binding to *support* the Web Method feature. What I have proposed in [1] is that *if* the user (ie a piece software bound to the binding) does not recognise or use the Web Method feature when initiating a message exchange, that the HTTP method used be default to POST in the case of the Request-Response MEP or GET on the case of the SOAP-Response MEP. This is entirely in-line with the narrative in section 6.4.3 [3]. <quote> Applications SHOULD use GET as the value of webmeth:Method in conjunction with the 6.3 SOAP Response Message Exchange Pattern to support information retrievals which are safe, and for which no parameters other than a URI are required; I.e. when performing retrievals which are idempotent, known to be free of side effects, for which no SOAP request headers are required, and for which security considerations do not conflict with the possibility that cached results would be used. Except in unusual circumstances, other operations SHOULD be performed using POST in conjunction with the 6.2 Request-Response Message Exchange Pattern. Other methods SHOULD not in general be used. For example, use of PUT would suggest storing the SOAP envelope Infoset as the created resource, as opposed to processing in the manner required by the SOAP processing model. </quote> As the HTTP binding is currently drafted, the behaviour of the binding is at-best undefined if the Web Method feature is not used (ie the webmeth:Method property is not set or not present in the initiating message exchange context). IMO it is legitimate for the webmeth:Method property to be absent or unset because we *do not* require that the user of a binding understands and uses ALL the features that a given binding provides... only those that it choose to use. > In addition to my strong objection, I'd note that this would be a > substantial change to what we agreed to go to Last Call with, so would > presumably set us back to Working Draft status. I do not believe that the change that I have proposed in [1] is as substantial as you suggest. It is primarily about the way we use the framework we have developed to describe behaviour. I have already agreed with Noah [2] that the change I have requested makes no practical difference to real implementations. > > * All of the properties are abstractions anyway. None of this requires a > > typical user to bother or not bother with anything. > > I certainly agree on the implementation pragmatics here. It does however make a (positive IMO) difference aligning with the intent of the framework that we created - such that binding clients can make use of bindings that support/provide features that they understand, without having to know and use binding provided features that they do not. > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@acm.org > http://www.markbaker.ca http://www.idokorro.com Regards Stuart [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0000.html [2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0036.html [3] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#webmethodstatemachine
Received on Monday, 15 July 2002 06:40:54 UTC