W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2007

Re: garbled text in MTOM Serialization Policy Assertion

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Wed, 17 Oct 2007 09:51:35 -0400
To: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Cc: xml-dist-app@w3.org
Message-ID: <OF3AD15F47.22B93062-ON85257377.004B2E74-85257377.004BFFB1@us.ibm.com>
Fabian,

Thanks for the detailed review and feedback.

The WG has agreed to address your concern by applying the original issue 
resolution [1]
correctly (there was a cut-n-paste error). We hope that this addresses 
your concern.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4506

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

xml-dist-app-request@w3.org wrote on 10/09/2007 08:48:44 AM:

> Hi,
> 
> I am commenting in lieu of Monica Martin and Pete Wenzel. They had 
> reviewed the LC edition [1] of the MTOM Serialization Policy 
> Assertion 1.1 document. The same issue is present in the latest 
> editor's working draft [2].
> 
> The text in paragraph 3.2 is garbled. Here is how it looks like now:

> /wsoma:MTOM/@wsp:Optional="true"
> Per Web Services Policy [WS-Policy], this is compact notation for 
> two policy alternatives, one with and one without the assertion. 
> This indicates that the behavior indicated by the assertion is 
> optional, specifically that non-MTOM-encoded exchanges are also 
> supported by the endpoint.
> When an endpoint reflects a compact policy expression with the MTOM 
> assertion marked with wsp:Optional='true', it may be difficult to 
> know which alternative has been engaged. In such cases, if a request
> message is received that is an application/soap+xml message, then 
> the receiving endpoint SHOULD respond (if at all) with an 
application/soap+xml
> response message unless there is some other indicator that specifies
> that the response is to be sent using MTOM encoding.
> ensure that a response message is serialized as application/xop+xml 
> a client can send an application/xop+xml request message.
> For example, when using SOAP/HTTP binding, the Accept HTTP header value 
of 
> multipart/related; type=application/xop+xml in the request message 
> indicates that the response may be sent using MTOM encoding.
> 
> We assume that it was intended to say instead:

> /wsoma:MTOM/@wsp:Optional="true"
> Per Web Services Policy [WS-Policy], this is compact notation for 
> two policy alternatives, one with and one without the assertion. 
> This indicates that the behavior indicated by the assertion is 
> optional, specifically that non-MTOM-encoded exchanges are also 
> supported by the endpoint.
> When an endpoint reflects a compact policy expression with the MTOM 
> assertion marked with wsp:Optional='true', it may be difficult to 
> know which alternative has been engaged. In such cases, if a request
> message is received that is an application/soap+xml message, then 
> the receiving endpoint SHOULD respond (if at all) with an 
application/soap+xml
> response message unless there is some other indicator that specifies
> that the response is to be sent using MTOM encoding.
> For example, when using SOAP/HTTP binding, the Accept HTTP header value 
of 
> multipart/related; type=application/xop+xml in the request message 
> indicates that the response may be sent using MTOM encoding. 
> In the absence of such an indicator, a client can ensure that a 
> response message is serialized as application/xop+xml by sending an 
> application/xop+xml request message.
> 
> Best regards,
> 
> Fabian Ritzmann
> 
> 
> [1] http://www.w3.org/2000/xp/Group/2/06/LC/mtompolicy.html
> [2] http://www.w3.org/TR/2007/WD-soap12-mtom-policy-20070918/

> -- 
> Fabian Ritzmann
> Sun Microsystems, Inc.
> Stella Business Park             Phone +358-9-525 562 96
> Lars Sonckin kaari 12            Fax   +358-9-525 562 52
> 02600 Espoo                      Email Fabian.Ritzmann@Sun.COM
> Finland
Received on Wednesday, 17 October 2007 13:52:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:24 GMT