Analysis of properties for MTOM

I took an action item on yesterday's call to set down some of my ideas
relating to properties at MTOM senders and receivers.  These are not yet
coordinated with Gudge's proposal at [1], so this should be taken neither
as an endorsement or rejection of any particular suggestions therein.

Working Draft Status Quo
------------------------

Our MTOM working draft introduces one property [2]:

   Name:
   http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates


   Description:
      A list containing zero or more (pointers to) element information
      items within the SOAP envelope candidate for being transmitted in an
      optimized way. The manner in which such identification is represented
      in the node is at the discretion of the implementation.

   Accompanying note:

      Note: Among the possible choices for identifying element information
      items in the
      http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
 are XPaths relative to the Envelope element information item, or pointers
      to the internal implementation of the elements in question. Indeed
      the list may be implicit in the content of the envelope itself. For
      example, any information item with contents that happen to be the
      canonical form of some base64 binary value can be implicitly included
      in the list if desired.

There is also an ednote about the need to eventually decide whether types
other than base 64 can also be handled.

Regarding receivers, the current Working Draft says [3]:

   When receiving a SOAP message using an implementation of the Abstract
   Transmission Optimization Feature, a SOAP node binding MUST enable the
   Abstract Transmission Optimization Feature. In addition, the SOAP node
   binding SHOULD/MAY set the value of the
   http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
 property to reflect the SOAP message parts whose transmission was
   optimized in the incoming message.

   Ednote (HR): We should decide on a SHOULD or on a MAY. In addition, the
   http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
 property is not very meaningful on the receiver side. We may create
   another property for reflecting element information items whose
   transmission was effectively optimized (an efficient implementation will
   provide this property to allow efficient retrieval of the optimized
   element information items).

The rules relating to transmission are [4]:

   When sending a SOAP message with the Abstract Transmission Optimization
   Feature enabled, a SOAP node using a binding implementing the Abstract
   Transmission Optimization Feature SHOULD optimize the transmission of
   all the SOAP message element information items listed in the value of
   the
   http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
 property.

   In addition, the SOAP node binding MAY optimize the transmission of
   other SOAP message element information items not listed in the value of
   the
   http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
 property. In particular, if the
   http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates
 property is not defined or if it has an empty value, the SOAP node binding
   MAY optimize the transmission of any SOAP message element information
   item.

I thing the current chapter 2 is incoherent in its treatment of the type
issue.  I note that I fulfilled an action item on July 29 to provide
proposed text cleaning that up and indicating that, for now, we're base64
only.  My proposal is at [5], and generated a response from Gudge at [6],
in which he raises a number of concerns.   I don't think I see any
disposition of all this in the f2f minutes, though I'm surprised we didn't
decide to do something.  In particular, my note proposed a revised property
description:

Revised description for base64 only:

   A list containing zero or more (pointers to) element information items
   within the SOAP envelope.  These are identified as candidates for
   optimized transmission.  All [children] of such candidate elements MUST
   be [character information items];  the string represented by the
   children of each candidate element, taken in sequence, MUST represent a
   legal canonical lexical form for the XML Schema base64Binary datatype,
   as described in [XML Schema Part 2]. The manner in which element
   identifications are represented in the node is at the discretion of the
   implementation.

Suggestions
-----------

In fulfillment of my action item, here is a brief analysis and some
suggestions regarding the above.

* As stated on the phone, I think the only thing we want to require that a
binding know is how the infoset was represented on the wire.

* I think that the property at the sender should be viewed as (a) a warrant
that the data is in a form suitable for optimization, in this case base
64-compatible lexical form and (b) a hint that software outside the binding
believes that the content referenced may be a good bet for optimization.

* Noting that the exact wire formats or serializations to be used is
nowhere discussed in Chapter 2, I think it is incoherent to require that
identified items be optimized, since we don't state in any
binding-independent manner how you would distinguish an optimized from an
unoptimized form.  For example, the lexical character form of a small
base64 value is likely to be more compact than the multi-part related form.
I thus think we should have no normative definition in Chapter 2 of what it
is to "optimize".  We merely assume that certain bindings will be written
to do certain optimizations, and note that some such bindings will be aided
by identification of nodes known to be in base64binary form.  I think my
proposed text in [5] does about this, and I suggest that we adopt it
(modifying as necessary to account for Gudge's concerns raised in [6]).

*  The bullet above argues against the ElementsRequiringOptimization and
ElementsThatMustNotBeOptimized as recently proposed by Gudge in [1].  I
don't think its decidable at this level of the spec what it means to
optimize something, and I think we should never at this level require or
forbid a binding from doing anything, except insofar as SOAP itself sets
requirements.

* I cannot offhand think of any other binding-independent properties to
propose at the sender.

* I think we want MTOM-through-current-SOAP-HTTP-binding to be a degenerate
case of MTOM, in which nothing is in fact optimized.  Stated another way:
that MTOM requires no transmission of information other than that already
required by SOAP and any non-MTOM features in use.  SOAP already mandates
that the receiver be capable of reconstructing the Infoset, which strongly
suggests that the receiver must know what is optimized, but we need not and
should not restate that.  SOAP covers it.

* Taking together the observation that there is no binding-independent
definition of what it means to optimize, and that we cannot in general
require additional information outside the envelope, I conclude that we
should mandate no receiver properties at all in Chapter 2.  I think we
could say:  "This specification mandates no binding-independent properties
at the receiver.  Binding specifications that implement [MTOM] MAY provide
for receiver-side properties that describe some or all of the optimizations
applied to the transmission.

* With respect to the binding-specific properties above, and taking note of
yesterday's vote on intermediary behavior which accepted [7], I propose
that the intermediary rule would be:  "As noted above, binding-specific
receiver properties describing the optimization of inbound messages MAY be
provided by certain bindings.  If the receiving node is an intermediary,
then such properties MAY be used by an outbound binding to facilitate the
optimization of relayed content.  The means, if any, by which such
cooperation is achieved are in general specific to the implementations of
the binding(s) involved:  this specification mandates no such cooperation,
and provides no fixed means for achieving such cooperation.

* We may wish to define in Chapter 4 a receiver property that is specific
to the HTTP binding, and that indicates which data was in fact optimized.


In short, clean up the existing outbound property to say that it warrants
base64 binary form.  No binding-independent receiver properties.  Maybe a
Chapter 4 receiver property specific to the HTTP binding.

Hope this is a good start on the discussion.

Noah


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0004.html
[2] http://www.w3.org/TR/soap12-mtom/#aof-properties
[3] http://www.w3.org/TR/soap12-mtom/#aof-receiving
[4] http://www.w3.org/TR/soap12-mtom/#aof-sending
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0067.html
[6] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0069.html
[7] http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Thursday, 4 September 2003 12:54:38 UTC