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

Oh, I see.  Yes, I agree it is a good idea to clarify that it is always evident from the message when it is using MTOM serialization even when there is no blob of data getting "optimized"

I propose that we accept Frederick's proposal with my minor editorial nit below (s/might have only one/can have a single):

If a client sends an optimized (MTOM) message, this will be indicated by characteristics associated by using such an optimized message, including a wire format that is a Multipart/Related message, and a content-type header of "application/xop+xml" for the outer package. In this case, the response message will also be optimized, also having a Multipart/Related message and content-type header of "application/xop+xml".  Note that when optimized messages are used, the Multipart/Related message can have a single part containing the primary SOAP envelope.

Daniel Roth

-----Original Message-----
From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
Sent: Monday, December 04, 2006 5:50 AM
To: Daniel Roth
Cc: Frederick Hirsch; public-ws-policy@w3.org
Subject: Re: ACTION 155: Draft proposed clarifications in 2.6 on use of the mtom assertion as an optional assertion

Dan

You are right. Here is an updated revision to the proposal:

"If a client sends an optimized (MTOM) message, this will be
indicated by characteristics associated by using such an optimized
message, including a wire format that is a Multipart/Related message,
and a content-type header of "application/xop+xml" for the outer
package. In this case, the response message will also be optimized,
also having a Multipart/Related message and content-type header of
"application/xop+xml" . Note
that when optimized messages are used, the Multipart/Related message
might have only one part, containing the primary SOAP envelope."

The point is that you will see this multipart format even when not
needed when using MTOM and I believe it would be useful to clarify.

regards, Frederick

Frederick Hirsch
Nokia


On Nov 30, 2006, at 6:17 PM, ext Daniel Roth wrote:

> From what I see in the MTOM spec, just because the message is using
> a Multipart format does not mean the message is using Optimized
> MIME Multipart/Related serialization.  There are other requirements
> as well, which are out lined here: http://www.w3.org/TR/soap12-mtom/
> #xop-serialization.
>
> Daniel Roth
>
> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> Sent: Thursday, November 30, 2006 10:01 AM
> To: Daniel Roth
> Cc: Frederick Hirsch; public-ws-policy@w3.org
> Subject: Re: ACTION 155: Draft proposed clarifications in 2.6 on
> use of the mtom assertion as an optional assertion
>
> Yes, but I wanted to make clear that even if there were only the
> primary SOAP envelope that the Multipart format would appear on the
> wire, making it obvious that the optimized message is being used.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Nov 30, 2006, at 12:28 PM, ext Daniel Roth wrote:
>
>> Hi Frederick,
>>
>> I'm fine with adding more clarity.  I think you want to clarify
>> what an "optimized message" is.  Rather than dive into the details
>> of Optimized MIME Multipart/Related serialization, how about we
>> reuse the terminology from the MTOM and MTOMPolicy specs?  Like this:
>>
>> "If a client sends an optimized message, one which uses Optimized
>> MIME Multipart/Related serialization, then the response message
>> will also be optimized, also using Optimized MIME Multipart/Related
>> serialization."
>>
>> Readers can then refer to the MTOM spec to discover the details of
>> the wire format.
>>
>> Daniel Roth
>>
>> -----Original Message-----
>> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
>> request@w3.org] On Behalf Of Frederick Hirsch
>> Sent: Wednesday, November 29, 2006 1:12 PM
>> To: public-ws-policy@w3.org
>> Cc: Frederick Hirsch
>> Subject: Re: ACTION 155: Draft proposed clarifications in 2.6 on
>> use of the mtom assertion as an optional assertion
>>
>>
>> I suggest a minor revision to this proposal, with the intent of
>> additional clarity:
>>
>> Original Proposal:
>>
>>> 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.
>>
>> Suggested revision to Proposal:
>>
>> Change the next to last sentence from:
>>
>> "If a client sends an optimized message the response will be
>> optimized."
>>
>> to
>>
>> "If a client sends an optimized message, one which will have a wire
>> format that is a Multipart/Related message, then the response message
>> will also be optimized, also having a Multipart/Related message. Note
>> that messages may be Multipart/Related having only one part, this
>> first root part containing the primary SOAP envelope."
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>>
>>
>

Received on Monday, 4 December 2006 17:38:33 UTC