W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Features: required implementation and use (was Re: Describing which blobs are to be optimized.)

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


    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

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.



  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:41 UTC