W3C home > Mailing lists > Public > public-ws-policy@w3.org > November 2006

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

From: Daniel Roth <Daniel.Roth@microsoft.com>
Date: Thu, 30 Nov 2006 15:17:38 -0800
To: Frederick Hirsch <frederick.hirsch@nokia.com>
CC: "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <E2903CF1E4B5B144B559237FDFB291CE46A5F483@NA-EXMSG-C117.redmond.corp.microsoft.com>

>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 Thursday, 30 November 2006 23:17:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:43 GMT