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

+1

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

public-ws-policy-request@w3.org wrote on 12/04/2006 12:38:13 PM:

> 
> 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
> >>
> >>
> >>
> >
> 
>