- From: Hugo Haas <hugo@w3.org>
- Date: Tue, 8 Jun 2004 12:15:55 +0200
- To: Glen Daniels <gdaniels@sonicsoftware.com>
- Cc: Marc Hadley <Marc.Hadley@Sun.COM>, Jonathan Marsh <jmarsh@microsoft.com>, www-ws-desc@w3.org, xml-dist-app@w3.org
- Message-ID: <20040608101555.GB26031@w3.org>
* Glen Daniels <gdaniels@sonicsoftware.com> [2004-06-07 11:49-0400] [..] > Second, we could add something like a "mustUnderstand" attribute to > feature/module declarations, which indicates that anyone using the WSDL > must understand the given extension, but that the usage of that > extension is still optional unless "required='true'" is specified. > Required extensions would remain as they are - where both usage and > understanding are mandated. This would allow specifying features which > may or may not be used, but whose use affects the syntax/semantics of > the exchange enough that failure to understand them would completely > screw things up in the event they were used. It raises interesting questions when considering MTOM. When the HTTP Transmission Optimization Feature is in use, the media type of the entity received changes from application/soap+xml to mime/multipart-related, which means that an agent not supporting the feature is going to be seriously confused, and return a 415 according to the SOAP HTTP binding[1] if it's the provider agent, or probably just discard the message it's the requester agent. That means that if MTOM is used, MTOM has to be understood by the message receiver to process the message. There is no such thing as a mustUnderstand=false for MTOM, which could be the case for other features too. That means that there are two cases to avoid runtime failures in such a scenario: - the mustUnderstand attribute you are proposing would always need to be set to true for MTOM. - if the use of MTOM was not required and the requester agent didn't want to provider agent to use it as it doesn't support it, it would need to indicate it at runtime, e.g. with Don't Use MTOM (DU-MTOM) SOAP feature which could appear with an HTTP/1.1 Accept header or a SOAP header. It would be described as follows, for an input-output MEP: output: MTOM required=false mustUnderstand=true or: output: MTOM required=false mustUnderstand=false input: DU-MTOM required=true Avoiding runtime errors for MTOM without mustUnderstand will mean either requiring the HTTP Transmission Optimization Feature or not using it. We are basically approaching the domain of constraints and capabilities. Note that this required/mustUnderstand issue also applies to the SOAP module component in our SOAP 1.2 binding, as a SOAP module may provide features or headers that always need to be understood. Regards, Hugo 1. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-reqbindwaitstate -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Tuesday, 8 June 2004 06:15:56 UTC