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

Thanks Daniel, I am fine with your edit.

regards, Frederick

Frederick Hirsch
Nokia


On Dec 4, 2006, at 12:38 PM, ext Daniel Roth wrote:

> 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 18:42:41 UTC