- 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>
Following on last telcon's discussions, here are some potential
enhancements to the proposal, related to engagement requiredness and
optionality.
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.
Regards,
Youenn
Received on Monday, 16 October 2006 08:13:38 UTC