- From: Hall, Randy E <randy.e.hall@intel.com>
- Date: Mon, 18 Jun 2001 14:41:32 -0700
- To: "'Xmlp-comments@w3.org'" <Xmlp-comments@w3.org>
- Message-ID: <13FCCC1F3509D411B1C700A0C969DEBB036DF21D@fmsmsx91.fm.intel.com>
In response to 2 proposals to deprecate SOAPAction [1], Proposal A comes closer to meeting our needs. Here are the issues Intel has with deprecating SOAPAction: 1 We believe SOAPAction is a useful feature of transport-specific bindings that could be used to carry out-of-band data useful to a SOAP processor. Protocol binding requirements, however, have not been defined making a decision to remove this functionality premature. We would like to see this issue readdressed in protocol binding discussions. Removing SOAPAction breaks UPnP forcing rework of both implementations and the device architecture standard. From the UPnP Device Architecture Specification [2]: SOAPACTION Required header defined by SOAP. Must be "urn:schemas-upnp-org:control-1-0#QueryStateVariable". If used in a request with method M-POST, header name must be qualified with HTTP name space defined in MAN header. Single URI. 2 The proposals as worded make neither assumptions nor guarantees of equivalent functionality in the final specification. Again, we believe that a cleanly-defined header that provides processing hints is a valuable feature. 3 Both ebXML and RosettaNet are adopting SOAP for message exchange. These are positive events for SOAP and the XML Protocol WG that will help increase adoption. Removing SOAPAction hinders progress of both organizations. Intentionally breaking features with little perceived value may lead to doubt about whether SOAP is a safe implementation route -- ultimately adoption slows at best, stops altogether at worst. As stated earlier, we would like to see this issue readdressed as part of protocol bindings discussions. Proposed requirements for SOAPAction replacement/enhancement, possibly in a protocol binding, include * SOAPAction is optional * Clear wording describing correct usage of SOAPAction as processing hint * Physical placement of SOAPAction must not require cracking the message to obtain "SOAPAction" value To summarize, we don't believe SOAPAction should be removed or deprecated at this point due to backwards compatibility issues, lack of crisp requirements for protocol bindings and impact and timing on other standards organizations. Regards, Randy E Hall Intel Corporation 480.554.3792 - Office 602.300.8646 - Mobile randy.e.hall@intel.com [1] <http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0032.html <http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0032.html> > [2] UPnP Device Architecture Specification: http://www.upnp.org/download/UPnPDA10_20000613.htm <http://www.upnp.org/download/UPnPDA10_20000613.htm>
Received on Monday, 18 June 2001 19:02:04 UTC