- From: Richard P. King <rpk@watson.ibm.com>
- Date: Wed, 18 Jul 2001 10:18:44 -0400
- To: www-ws@w3.org
Mark (Baker, that is), The following is just a copy of the remarks I made on the www.ibm.com/developerworks/webservices/library/ws-phtt discussion forum: Perhaps a paragraph that disappeared during the editing of our specification should be restored: "An alternative approach would have been to use the framework for extending HTTP commands to expose HTTPR-specific fields. This would have exposed the protocol detail to web servers, proxies and firewalls in the web, possibly requiring special versions of this software to be deployed to handle HTTPR. To avoid this exposure, and because it is anticipated that HTTPR will be a minority web protocol, this approach was not taken." To respond more specifically to your comments, let me add that HTTPR is using HTTP's POST strictly as just that, to deliver a payload to a server, because that was the surest way to get the HTTPR request all the way from the client to the server through any possible, pre-existing proxy without interference. The same applies, I believe even more strongly, to burying get-responder-info inside the payload instead of overloading the meaning of HTTP's GET, since get-responder-info does more than request information; it also establishes an HTTPR session, which may persist for some time. At the heart of it is, perhaps, a conflict between the stateless nature of HTTP and stateful nature of reliable message transfer. Rather than shoehorn into HTTP ways of expressing and exchanging state information and thereby make HTTP a stateful protocol, it seemed preferable to use HTTP as the transport mechanism for expression of reliable messaging at a higher level. HTTP certainly stands for Hypertext Transfer Protocol, and the contents of POST payloads and their responses under HTTPR are certainly not HTML. Still, when looked at dispassionately, there is nothing in HTTP that precludes transmission of any other kind of data, including, we like to think, HTTPR. Richard.
Received on Wednesday, 18 July 2001 10:19:21 UTC