ACTION 155: Draft proposed clarifications in 2.6 on use of the mtom assertion as an optional assertion

This email completes action 155 [1].

This action is to provide clarification in response to issue 3952, which states that when the MTOM assertion is marked optional it is ambiguous as to how the provider will respond to a non-MTOM message [2].

The WS-MTOMPolicy assertion requires the use of MTOM serialization on the request and on the response (see section 3.2 in the WS-MTOMPolicy spec) [3].

Marking the MTOM policy assertion as optional creates two alternatives: one with the assertion and one without.  Section 3.2 in the WS-Policy Framework states that the alternative without the MTOM assertion does not use MTOM serialization (i.e. the behavior "will not be applied") [4].

The use of MTOM serialization in a message can always be detected by inspecting the message (see section 3.2 in the MTOM spec) [5].  This allows the provider to know which alternative is applicable.

So, marking the MTOM assertion as optional does not result in an ambiguous policy.  If a requester sends an MTOM message it will get an MTOM message.  If a requester sends a plain text message it will get a plain text message.

However, some readers might assume that the MTOM assertion behaves different than what is actually specified in the WS-MTOMPolicy spec.  For example, some might expect that the assertion would have MAY semantics (i.e. the provider could respond to a non-MTOM message with an MTOM message).  Such a hypothetical assertion could result in ambiguous policies when used with wsp:Optional.  The primer should be clear about what the semantics of the MTOM assertion actually are and what the behavior should be when the MTOM assertion is marked optional.

I propose the following Primer text addition to section 2.6 [6] to clase issue 3952:

The mtom:OptimizedMimeSerialization element is a policy assertion. (The prefix mtom is used here to denote the Optimized MIME Serialization Policy namespace.) This assertion identifies the use of MIME Multipart/Related serialization as required for request and response messages. Policy-aware clients can recognize this policy assertion and engage Optimized MIME Serialization for these messages.   The semantics of this assertion are reflected in messages: they use an optimized wire format (MIME Multipart/Related serialization).
...
In the example below, the Optimized MIME Serialization policy assertion is marked optional. This policy expression allows the use of optimization and requires the use of addressing and one of transport- or message-level security.  If a client sends an optimized message the response will be optimized.  If a client sends a plain text message, the response will be plain text.

[1] http://www.w3.org/2005/06/tracker/wspolicy/actions/155
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3952
[3] http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/optimizedmimeserialization-policy.pdf
[4] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8#rPolicy_Alternative
[5] http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/#mime-serialization
[6] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%20charset=utf-8#optional-policy-assertion