W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2003

Re: Initial formulation of intermediary semantics for MTOM

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Tue, 02 Sep 2003 08:50:19 -0400
To: noah_mendelsohn@us.ibm.com
Cc: xml-dist-app@w3.org
Message-id: <0201E3FD-DD44-11D7-8142-0003937568DC@sun.com>

I'm generally in favor of the direction of the suggested changes. I'd 
like to see these made in conjunction with clarifying the relationship 
of MTOM to the current HTTP binding[1]. I think its possible that some 
of the things explicitly stated here would naturally fall out from such 
an effort, in particular the hop-by-hop nature.

Regards,
Marc.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0032.html

On Friday, Aug 29, 2003, at 18:14 US/Eastern, 
noah_mendelsohn@us.ibm.com wrote:

>
>
>
>
>
> I took an action item af the France f2f to formulate a proposal for
> intermediary handling of MTOM.  This note is in fulfillment of that 
> action.
> What I've written here is the rough outline of a direction.  The 
> proposal
> is as follows.  All section numbers are with respect to the MTOM WD at 
> [1]:
>
> <current fromSection="Introduction">
> The usage of the Abstract Transmission Optimization Feature is a 
> hop-by-hop
> contract between a SOAP node and the next SOAP node in the SOAP message
> path, providing no normative convention for optimization of SOAP
> transmission through intermediaries.
> </current>
> <proposed forSection="Introduction">
> The usage of the Abstract Transmission Optimization Feature is a 
> hop-by-hop
> contract between a SOAP node and the next SOAP node in the SOAP message
> path, providing no mandatory convention for optimization of SOAP
> transmission through intermediaries.   The feature does provide 
> optional
> means by which binding implementations MAY choose to facilitate the
> efficient passthrough of optimized data contained within headers or 
> bodies
> relayed by an intermediary.
> </proposed>
>
> <current fromSection="2.4.3 Transmitting a Message">
> The usage of the Abstract Transmission Optimization Feature is a 
> hop-by-hop
> contract between a SOAP node and the next SOAP node in the SOAP message
> path. Therefore, no specific rules exist for a SOAP intermediary
> implementing the Abstract Transmission Optimization Feature.
> </current>
> <proposed  forSection="2.4.3 Transmitting a Message">
> The usage of the Abstract Transmission Optimization Feature is a 
> hop-by-hop
> contract between a SOAP node and the next SOAP node in the SOAP message
> path. Therefore, no changes or restrictions to the SOAP processing 
> model
> are introduced by this feature at an intermediary.  Section 2.4.4 
> details
> the means by which certain optimizations can be performed by bindings 
> at
> intermediaries.
> </proposed>
>
> <proposed newSection="2.4.4 Binding Optimizations at Intermediaries">
> As described in SOAP Part 1 Section 2.7 Relaying SOAP Messages, a SOAP
> intermediary may be called upon to to relay intact certain headers, or 
> to
> reinsert headers identical to those received and removed for 
> processing.
> Furthermore, many intermediaries will relay unmodified the contents of 
> the
> SOAP body.   In all these cases, portions of the relayed message have
> content identical to corresponding portions of the inbound message.
>
> The Abstract Transmission Optimization Feature does not require any
> particular correspondence between the optimization of the inbound 
> message
> and the outbound message, even when optimized portions of the inbound
> message are relayed intact, or reinserted in identical form in the 
> envelope
> Infoset.  Nonetheless, the implementations of the receiving binding 
> and the
> binding used to transmit the relayed message MAY cooperate to provide
> efficient relay.  For example, if the inbound and outbound binding use 
> the
> same representation for optimized binary, the implementations MAY 
> cooperate
> to pass the optimized form directly from the inbound to the outbound
> binding.  The choice of whether to implement such cooperation, and if 
> so
> the means used, is at the discretion of the binding specification(s) 
> and/or
> the implementation of the bindings.
>
> Note:  a consequence of these rules is that there are no invariant 
> rules
> for the degree to which optimizations are preserved as a message passes
> through intermediaries.  Certain outbound bindings may be incapable of 
> any
> optimization, and will therefore transmit unoptimized forms in all 
> cases.
> Other bindings may be capable of optimization, but may or may not 
> choose to
> or succeed in optimizing the same portions (if any) that were 
> optimized in
> the inbound message.  Other bindings, perhaps under the direction of 
> logic
> provided in SOAP modules or perhaps as consequence of conventions 
> embodied
> in the bindings, may optimize portions of the message that were not
> optimized inbound, or which were optimized using different techniques.
> </proposed>
>
> [1] http://www.w3.org/TR/soap12-mtom/
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Tuesday, 2 September 2003 08:57:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT