* 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/