RE: soap:header extensibility with mU primer example

My understanding (sorry, pun unintentional, but I'm going to leave it there!) is that "mustUnderstand" is insurance for the client - if the client sends a header flagged "mustUnderstand", then the server must fault if it does not understand that header - this way the client is protected against a back-level server doing the wrong thing with a message that it understands incompletely.
 
Suppose we had a money transfer web service, and the client sends in a request to transfer $10 000 (or whatever sum you regard as significant) and adds a header which says "transfer to be completed only when the sender has confirmed receipt of the goods" (we postulate a web service that has been modified to allow the receiver to confirm that the transfer is "pending"). If the service does not understand the header, then things will go astray.
 
How's that?
 
Tony

	-----Original Message----- 
	From: www-ws-desc-request@w3.org on behalf of Jonathan Marsh 
	Sent: Fri 15-Jul-05 0:31 
	To: David Orchard; www-ws-desc@w3.org 
	Cc: 
	Subject: RE: soap:header extensibility with mU primer example
	
	

	I think my position is better stated as “a client never needs to put a mustUnderstand on a header block that is described in WSDL and therefore we don’t need built-in support for this in WSDL”.  If other specs specify the setting of mustUnderstand, that is fine though it seems redundant in the presence of a WSDL.

	 

	It also bothers me that setting mustUnderstand is supposed to be a client decision, yet we’re overriding that responsibility by giving the server the ultimate word.  I don’t have a compelling example of harm that could be caused, but neither to do you seem to have a compelling example or simple guidance for when this facility might be needed.

	 

	If we decide to keep mU, I don’t think adding your example to the Primer will actually be terribly helpful, so my second choice (behind remoing mU) would be the status quo.

	 

	
  _____  


	From: David Orchard [mailto:dorchard@bea.com] 
	Sent: Wednesday, July 13, 2005 11:14 AM
	To: Jonathan Marsh; www-ws-desc@w3.org
	Subject: RE: soap:header extensibility with mU primer example

	 

	How is this any different than taking an endpoint that doesn't support ws-security, then adding a ws-policy attachment that says ws-security must be used (and ws-security says set the mu="true")?  

	 

	One way of looking at your position is that you think that a client should never put a mustUnderstand on a header block that is described in WSDL but it's allowed to do it on anything that might be described in any other spec that is referenced by Policy or f&p. 

	 

	I think it strange to allow only Policy/feature authors the ability to say something that WSDL 2.0 straight up can describe.

	 

	Dave

	 

	
  _____  


	From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
	Sent: Wednesday, July 13, 2005 11:00 AM
	To: David Orchard; www-ws-desc@w3.org
	Subject: RE: soap:header extensibility with mU primer example

	 

	Sorry Dave, but we don’t find this motivation very compelling.  This seems like the clumsiest way imaginable to introduce an incompatible version.  We have a variety of other mechanisms that could be employed, including introducing a new name for the new operation, introducing a new endpoint, or adding an app-level version identifier into the message body with appropriate failure semantics.  If this is the best motivation you can come up with, we would rather see the mU capability removed.

	 

	Speaking for Microsoft not as chair,

	Jonathan

	 

	
  _____  


	From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of David Orchard
	Sent: Tuesday, July 12, 2005 3:48 PM
	To: www-ws-desc@w3.org
	Subject: soap:header extensibility with mU primer example

	 

	A proposed section for the Primer if people accept the example and motivation.

	 

	Additional 5.2.5.4.  Additional mandatory elements in header.

	 

	A primary motivation for soap:mustUnderstand is to enable a client to ensure that a service understands a soap header block that the client sends.  Imagine that the reservation interface is controlled by a 3rd party such as a travel consortium.  The travel consortia decides to make the NumberOfGuests a soap header block rather than part of the body, perhaps on the initial version or a subsequent version.  There are a variety of reasons for this.  The extension could be handled in a well factored design at the service by a specialized piece of software.   A 3rd party specifying the header blocks is why Web Service specifications will often require that the mustUnderstand flag is set to true. 

	 

	The binding using mustUnderstand is:

	 

	<operation ref="tns:opCheckAvailability">

	       <input>

	         <wsoap:header wsoap:mustUnderstand="true" element="tns:NumberOfGuests"/>

	       </input>

	    </operation>

	 

	Any client that uses the new interface will set the soap:mustUnderstand attribute in the message.  If the service receiving the messages does not understand the extension, it will fault.

	 

	Cheers,

	Dave