Re: garbled text in MTOM Serialization Policy Assertion

Christopher B Ferris wrote:
> 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

Just to be clear, the following text was pasted accidentally and you are 
going to remove it entirely with no other changes?

"ensure that a response message is serialized as application/xop+xml a 
client can send an application/xop+xml request message."

Your change would address my concern appropriately. Thanks for 
considering my comment.

Fabian


> 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 14:16:56 UTC