W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2006

Some MTOM precisions

From: Youenn Fablet <youenn.fablet@crf.canon.fr>
Date: Mon, 16 Oct 2006 10:12:58 +0200
To: www-ws-desc@w3.org
Cc: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Message-id: <45333F0A.5080306@crf.canon.fr>

Following on last telcon's discussions, here are some potential 
enhancements to the proposal, related to engagement requiredness and 
These precisions may be suited for a primer or something like that.
For input messages and input faults
        - required means that MTOM must be supported and should be 
engaged by the client.
                Typically, when there is no binary data in a message, 
MTOM is not needed.
        - optional means that MTOM may be engaged by the client and is 
supported by the service
For output messages and output faults
        - required means that MTOM must be supported by the client
                Engagement is based on the message content-type as per 
the MTOM specification.
        - optional means that MTOM is supported and may be engaged by 
the service.
                Engagement must only be done when the service knows that 
the client supports MTOM.
                This knowledge may come from different sources: MTOM use 
in the input message, policy exchanges, content negociation (HTTP Accept 
header for instance)...
                By default, MTOM is not engaged.

There were also some discussions whether to use @wsdl:required to mark 
optionality/requiredness of the extension.
While I do not recall the exact reasons for not reusing it, I would note 
that the WS-Addr UsingAddressing extension use @wsdl:required with the 
exact same intention.

Finally, I know that SWA can be described by WSDL1.1, but I do not think 
it can be described by WSDL2.0.
The same extension element could be used for both MTOM and SWA, the 
switch being based on the soap version in use.
In such a case, we should define a specific uri for the extension 
element and not directly reuse the MTOM URI.

I hope this helps.
Received on Monday, 16 October 2006 08:13:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:01 UTC