Re: garbled text in MTOM Serialization Policy Assertion

Christopher B Ferris <[email protected]> Wed, 17 Oct 2007 09:51:35 -0400
Newsgroups gmane.text.xml.distributed
Message-ID <OF3AD15F47.22B93062-ON85257377.004B2E74-85257377.004BFFB1@us.ibm.com>
This is a multipart message in MIME format.
--=_alternative 004B658A85257377_=
Content-Type: text/plain; charset="US-ASCII"

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: [email protected]
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

[email protected] 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 [email protected]
> Finland
--=_alternative 004B658A85257377_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Fabian,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the detailed review and feedback.</font>
<br>
<br><font size=2 face="sans-serif">The WG has agreed to address your concern
by applying the original issue resolution [1]</font>
<br><font size=2 face="sans-serif">correctly (there was a cut-n-paste error).
We hope that this addresses your concern.</font>
<br>
<br><font size=2 face="sans-serif">[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4506</font>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br>
<br><font size=2 face="sans-serif">Christopher Ferris<br>
STSM, Software Group Standards Strategy<br>
email: [email protected]<br>
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris<br>
phone: +1 508 234 2986</font>
<br>
<br><tt><font size=2>[email protected] wrote on 10/09/2007 08:48:44
AM:<br>
<br>
&gt; Hi,<br>
&gt; <br>
&gt; I am commenting in lieu of Monica Martin and Pete Wenzel. They had
<br>
&gt; reviewed the LC edition [1] of the MTOM Serialization Policy <br>
&gt; Assertion 1.1 document. The same issue is present in the latest <br>
&gt; editor's working draft [2].<br>
&gt; <br>
&gt; The text in paragraph 3.2 is garbled. Here is how it looks like now:<br>
</font></tt>
<br><tt><font size=2>&gt; /wsoma:MTOM/@wsp:Optional=&quot;true&quot;</font></tt>
<br><tt><font size=2>&gt; Per Web Services Policy [WS-Policy], this is
compact notation for <br>
&gt; two policy alternatives, one with and one without the assertion. <br>
&gt; This indicates that the behavior indicated by the assertion is <br>
&gt; optional, specifically that non-MTOM-encoded exchanges are also <br>
&gt; supported by the endpoint.</font></tt>
<br><tt><font size=2>&gt; When an endpoint reflects a compact policy expression
with the MTOM <br>
&gt; assertion marked with wsp:Optional='true', it may be difficult to
<br>
&gt; know which alternative has been engaged. In such cases, if a request<br>
&gt; message is received that is an application/soap+xml message, then
<br>
&gt; the receiving endpoint SHOULD respond (if at all) with an application/soap+xml<br>
&gt; response message unless there is some other indicator that specifies<br>
&gt; that the response is to be sent using MTOM encoding.</font></tt>
<br><tt><font size=2>&gt; ensure that a response message is serialized
as application/xop+xml <br>
&gt; a client can send an application/xop+xml request message.</font></tt>
<br><tt><font size=2>&gt; For example, when using SOAP/HTTP binding, the
Accept HTTP header value of <br>
&gt; multipart/related; type=application/xop+xml in the request message
<br>
&gt; indicates that the response may be sent using MTOM encoding.</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; We assume that it was intended to say instead:<br>
</font></tt>
<br><tt><font size=2>&gt; /wsoma:MTOM/@wsp:Optional=&quot;true&quot;</font></tt>
<br><tt><font size=2>&gt; Per Web Services Policy [WS-Policy], this is
compact notation for <br>
&gt; two policy alternatives, one with and one without the assertion. <br>
&gt; This indicates that the behavior indicated by the assertion is <br>
&gt; optional, specifically that non-MTOM-encoded exchanges are also <br>
&gt; supported by the endpoint.</font></tt>
<br><tt><font size=2>&gt; When an endpoint reflects a compact policy expression
with the MTOM <br>
&gt; assertion marked with wsp:Optional='true', it may be difficult to
<br>
&gt; know which alternative has been engaged. In such cases, if a request<br>
&gt; message is received that is an application/soap+xml message, then
<br>
&gt; the receiving endpoint SHOULD respond (if at all) with an application/soap+xml<br>
&gt; response message unless there is some other indicator that specifies<br>
&gt; that the response is to be sent using MTOM encoding.</font></tt>
<br><tt><font size=2>&gt; For example, when using SOAP/HTTP binding, the
Accept HTTP header value of <br>
&gt; multipart/related; type=application/xop+xml in the request message
<br>
&gt; indicates that the response may be sent using MTOM encoding. </font></tt>
<br><tt><font size=2>&gt; In the absence of such an indicator, a client
can ensure that a <br>
&gt; response message is serialized as application/xop+xml by sending an
<br>
&gt; application/xop+xml request message.</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Best regards,<br>
&gt; <br>
&gt; Fabian Ritzmann<br>
&gt; <br>
&gt; <br>
&gt; [1] http://www.w3.org/2000/xp/Group/2/06/LC/mtompolicy.html<br>
&gt; [2] http://www.w3.org/TR/2007/WD-soap12-mtom-policy-20070918/<br>
</font></tt>
<br><tt><font size=2>&gt; -- <br>
&gt; Fabian Ritzmann<br>
&gt; Sun Microsystems, Inc.<br>
&gt; Stella Business Park &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Phone
+358-9-525 562 96<br>
&gt; Lars Sonckin kaari 12 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Fax
&nbsp; +358-9-525 562 52<br>
&gt; 02600 Espoo &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;Email [email protected]<br>
&gt; Finland</font></tt>
--=_alternative 004B658A85257377_=--