garbled text in MTOM Serialization Policy Assertion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

garbled text in MTOM Serialization Policy Assertion

Fabian Ritzmann-3
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 [hidden email]
Finland
Reply | Threaded
Open this post in threaded view
|

Re: garbled text in MTOM Serialization Policy Assertion

Christopher B Ferris

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


[hidden email] 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 [hidden email]
> Finland
Reply | Threaded
Open this post in threaded view
|

Re: garbled text in MTOM Serialization Policy Assertion

Fabian Ritzmann-3

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


> [hidden email] 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 [hidden email]
> > Finland