W3C home > Mailing lists > Public > xmlp-comments@w3.org > June 2001

Response to SOAPAction Proposals

From: Hall, Randy E <randy.e.hall@intel.com>
Date: Mon, 18 Jun 2001 14:41:32 -0700
Message-ID: <13FCCC1F3509D411B1C700A0C969DEBB036DF21D@fmsmsx91.fm.intel.com>
To: "'Xmlp-comments@w3.org'" <Xmlp-comments@w3.org>
	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]:
			Required header defined by SOAP. Must be
"urn:schemas-upnp-org:control-1-0#QueryStateVariable". If used in a request
			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

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,
*	SOAPAction is optional
*	Clear wording describing correct usage of SOAPAction as processing
*	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.

	Randy E Hall
	Intel Corporation
	480.554.3792 - Office
	602.300.8646 - Mobile

<http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0032.html> >
	[2] UPnP Device Architecture Specification:
Received on Monday, 18 June 2001 19:02:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:58 UTC