Sent to incorrect lists, so resending.

I am sending this to the wsawg and dist-app lists in addition to the TAG list. This issue was actively debated on the April 15th TAG call.

1. I believe the wording on TAG issue whenToUseGet-7 is somewhat flawed. I could live with any of : a. safe methods (GET/HEAD) should be used for safe operations in browser-centric applications b. safe methods (GET/HEAD) *may* be used for safe operations or c. safe methods (GET/HEAD) should be used for safe operations in web applications that are information oriented.

My concern is that the web services world is almost universally built upon the use of HTTP POST when used with HTTP for document exchange, and this finding may imply that exclusive use of the SOAP HTTP Binding (particularly POST) is a violation of the web, and may need correction. Certainly when I brought this up in the TAG call, various people were wanting to change web services to do the "right" thing in their mind.

My belief is that the web has been based upon a shared information space, primarily through use of GET/POST methods. However, as we move towards more machine to machine oriented communications, with arbitrary payloads of XML, and it's focus on update/service oriented architectures, the need for a public contract for safe actions is dramatically reduced. Indeed the browser-centric web arbitrarily chooses GET or POST for various reasons that are unrelated to safeness, but more because of browser characteristics and server implementation decisions. There are many cases of safe POSTs and unsafe GETs.

My personal position on the centrality of HTTP GET/POST to the web is detailed in [1]. There have been many people that have posted on the www-tag list on the centrality of HTTP GET, the issue of strong-typing, relationship of SOAP to HTTP, and other closely related facets, such as Don Box [2], Noah Mendelsohn [3], Henrik Nielsen [4], and others.

For these reasons, and others including the lack of consensus on this issue, it is inappropriate to create issue resolution wording that could result in suggestions that safe web services must use a new HTTP GET binding, that the XMLP/WSDL/Web Services Architecture Groups should change probably significant sections of their wording, to delay publication of SOAP 1.2 (in order to do more work on a GET binding), or other charter/wording/schedule changes.

I have strived for a middle ground, that of suggesting that GET usage is for a particular application of the web - as opposed to a definitive characteristic of the web - but mine and others arguments appear to have been unpursuasive. So...

2. I repeatedly suggested on the TAG call the creation of a liaison between the TAG and some subset of the Web Services Activity be struck to deal with the issue of Web Services interactions being typically POST based. The TAG did not decide for or against this proposal during it's call. This was also raised by HenrikN during the last WSAWG call. I would like the WSACG to take up the issue of requesting the setting up a WSA/TAG liaison during it's next meeting. The first task would be resolving the issue of HTTP POST vs GET for web services use cases. I might even be so bold as to suggest looking at web services use cases that involve a priori knowledge of "safe" interactions. I think that the ws activity members probably have an opinion on the issue of whether HTTP GET SHOULD be used for safe methods, considering the current SOAP 1.2 HTTP binding. Further, some members of the TAG seemed quite interested in changing the web services architecture instead of trying to documenting and achieve consensus on this issue. I refused a request to, in my words, "lead the charge in getting the WSA to do the SOAP and WSDL changes to do the right thing". This is a classic liason activity, where we need to strive for consensus between different views. I would be glad to participate and help in such a liason.

3. I encourage interested parties in the other groups to respond to this issue. This is one of the first TAG findings, and has potential significant ramifications to the web services architecture. Formal - as suggested in item #2 - and personal discussions - this item - should help foster education and consensus that have so far been illusive. I've specifically sent this note to dist-app as a call to arms on this issue.

4. A personal note. I find it disappointing that we are debating this issue. I would rather being doing what I consider more productive forward-looking work, such as web service security use-cases/requirements/charter or closing SOAP 1.2 issues, than debating a technical decision that has shipped in many thousands of units and does not have any consensus in the real world. But there are such extremes of opinion and desires for "correcting behaviour" rather than documenting consensus that I and others will be forced to spend time on this issue.

Cheers, Dave

[1] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0259.html [2] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0177.html [3] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0082.html [4] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0201.html