index.html 49.8 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>SOAP Message Transmission Optimization Mechanism</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
<h1><a name="title" id="title"></a>SOAP Message Transmission Optimization Mechanism</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Recommendation 25 January 2005</h2><dl><dt>This version:</dt><dd>
      <a href="http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/</a>
    </dd><dt>Latest version:</dt><dd>
      <a href="http://www.w3.org/TR/soap12-mtom/">
	http://www.w3.org/TR/soap12-mtom/</a>
    </dd><dt>Previous version:</dt><dd>
      <a href="http://www.w3.org/TR/2004/PR-soap12-mtom-20041116/">
	http://www.w3.org/TR/2004/PR-soap12-mtom-20041116/</a>
    </dd><dt>Editors:</dt><dd>Martin Gudgin, Microsoft</dd><dd>Noah Mendelsohn, IBM</dd><dd>Mark Nottingham, BEA</dd><dd>Hervé Ruellan, Canon</dd></dl><p>Please refer to the <a href="http://www.w3.org/2005/01/soap12-mtom-errata"><strong>errata</strong></a> for this document, which may
      include normative corrections.</p><p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=soap12-mtom"><strong>translations</strong></a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr /><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
	This document describes an abstract feature and a concrete
	implementation of it for optimizing the transmission and/or wire format
	of SOAP messages. The concrete implementation relies on the <a href="#XOP">[XML-binary Optimized Packaging]</a> format for carrying SOAP messages.
      </p></div><div>
<h2><a name="status" id="status"></a>Status of this Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p><p>
  This document is a Recommendation of the W3C. It has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p><p>
  This document has been produced by the
  <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a> (WG)
  as part of the W3C
  <a href="http://www.w3.org/2002/ws/Activity"> Web Services Activity</a>. The English version of this specification is the only normative version. However, for translations of this document, see <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=soap12-mtom">http://www.w3.org/2003/03/Translations/byTechnology?technology=soap12-mtom</a>.
</p><p>
Please report errors in this document to <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">archive</a>). The errata list for this edition is available at <a href="http://www.w3.org/2005/01/soap12-mtom-errata">http://www.w3.org/2005/01/soap12-mtom-errata</a></p><p>
This document is based upon the <a href="http://www.w3.org/TR/2004/PR-soap12-mtom-20041116/">SOAP Message Transmission Optimization Mechanism Proposed Recommendation</a> of 16 November 2004.
Feedback received during that review resulted in no changes. Evidence of interoperation between
 at least two implementations of this specification are documented in the <a href="http://www.w3.org/2000/xp/Group/4/08/implementation.html">Implementation Summary</a>.
Changes between these two versions are described in a <a href="diff-mtom.html">diff document</a>.
</p><p>
This document has been produced under the
<a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended
by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>.
An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s)
 with respect to this specification should disclose the information in accordance with section 6 of the
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">W3C Patent Policy</a>.
Patent disclosures relevant to this specification may be found on the Working Group's
<a href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent disclosure page</a>.
</p><p>A list of current W3C Recommendations and other technical documents can be found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
    1.1 <a href="#notations">Notational Conventions</a><br />
    1.2 <a href="#relations">Relation to other specifications</a><br />
2 <a href="#feature">Abstract SOAP Transmission Optimization Feature</a><br />
    2.1 <a href="#aof-introduction">Introduction</a><br />
    2.2 <a href="#aof-name">Abstract SOAP Transmission Optimization Feature Name</a><br />
    2.3 <a href="#aof-processing">Abstract SOAP Transmission Optimization Feature Processing</a><br />
        2.3.1 <a href="#aof-sending">Sending a message</a><br />
        2.3.2 <a href="#aof-receiving">Receiving a message</a><br />
        2.3.3 <a href="#aof-intermediaries">Intermediaries</a><br />
        2.3.4 <a href="#aof-intermed">Binding Optimizations at Intermediaries</a><br />
3 <a href="#xop-serialization">An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</a><br />
    3.1 <a href="#im-introduction">Introduction</a><br />
    3.2 <a href="#mime-serialization">Serialization of a SOAP message</a><br />
    3.3 <a href="#mime-deserialization">Deserialization of a SOAP message</a><br />
4 <a href="#HTTP-implementation">HTTP SOAP Transmission Optimization Feature</a><br />
    4.1 <a href="#httpof-introduction">Introduction</a><br />
    4.2 <a href="#httpof-name">HTTP SOAP Transmission Optimization Feature Name</a><br />
    4.3 <a href="#httpof-implementation">Implementation</a><br />
        4.3.1 <a href="#httpof-sending">Sending a SOAP message</a><br />
            4.3.1.1 <a href="#httpof-sending-init">Init</a><br />
        4.3.2 <a href="#httpof-receiving">Receiving a SOAP message</a><br />
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#references">References</a><br />
B <a href="#acks">Acknowledgements</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2><p>
	The first part of this document (<a href="#feature"><b>2 Abstract SOAP Transmission Optimization Feature</b></a>) describes an
	abstract feature for optimizing the transmission and/or wire format of
	a SOAP message (<a href="#W3C.soap-part1">[SOAP Version 1.2 Part 1: Messaging Framework]</a>) by selectively encoding
	portions of the message, while still presenting an XML Infoset to the
	SOAP application.
      </p><p>
	Use of the Abstract SOAP 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 pass-through of optimized data contained
	within headers or bodies relayed by an intermediary  (see <a href="#aof-intermed"><b>2.3.4 Binding Optimizations at Intermediaries</b></a>).  Additional specifications might also be
	written to provide for other optimized multi-hop capabilities, perhaps
	building on the mechanisms provided herein.
      </p><p>
	The second part (<a href="#xop-serialization"><b>3 An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</b></a>) describes an
	Optimized MIME Multipart/Related Serialization of SOAP Messages
	implementing the Abstract SOAP Transmission Optimization Feature in a
	binding independent way. This implementation relies on the <a href="#XOP">[XML-binary Optimized Packaging]</a> format.
      </p><p>
	The third part (<a href="#HTTP-implementation"><b>4 HTTP SOAP Transmission Optimization Feature</b></a>) uses this
	Optimized MIME Multipart/Related Serialization of SOAP Messages for
	describing an implementation of the Abstract Transmission Optimization
	Feature for the SOAP 1.2 HTTP binding (see <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">7. SOAP HTTP
	  Binding</a>).
      </p><div class="div2">
<h3><a name="notations" id="notations"></a>1.1 Notational Conventions</h3><p>
	  The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	  document are to be interpreted as described in RFC 2119 <a href="#RFC2119">[RFC 2119]</a>.
	</p><p>
	  This specification uses a number of namespace prefixes throughout;
	  they are listed in <b>[<a href="#tabnsprefixes">Prefixes and Namespaces used in this specification.</a>]</b>.  Note that the
	  choice of any namespace prefix is arbitrary and not semantically
	  significant (see XML Infoset <a href="#">[XMLInfoSet]</a>).
	</p><table border="1"><caption id="tabnsprefixes">Prefixes and Namespaces used in this specification.</caption><tbody><tr><th rowspan="2">Prefix</th><th>Namespace</th></tr><tr><th>Notes</th></tr><tr><td rowspan="2">env</td><td>"http://www.w3.org/2003/05/soap-envelope"</td></tr><tr><td>
		A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1: Structures Second Edition]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> document for the
		"http://www.w3.org/2003/05/soap-envelope"
		namespace can be found at <a href="http://www.w3.org/2003/05/soap-envelope">http://www.w3.org/2003/05/soap-envelope</a>.
	      </td></tr><tr><td rowspan="2">xop</td><td>"http://www.w3.org/2004/08/xop/include"</td></tr><tr><td>
		A non-normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1: Structures Second Edition]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> document for the
		"http://www.w3.org/2004/08/xop/include"
		namespace can be found at <a href="http://www.w3.org/2004/08/xop/include">http://www.w3.org/2004/08/xop/include</a>.
	      </td></tr><tr><td rowspan="2">rep</td><td>"http://www.w3.org/2004/08/representation"</td></tr><tr><td>
		A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1: Structures Second Edition]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> document for the
		"http://www.w3.org/2004/08/representation"
		namespace can be found at <a href="">TBD</a>.
	      </td></tr><tr><td rowspan="2">xs</td><td>"http://www.w3.org/2001/XMLSchema"</td></tr><tr><td>
		The namespace of XML Schema data types (see <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a>).
	      </td></tr></tbody></table></div><div class="div2">
<h3><a name="relations" id="relations"></a>1.2 Relation to other specifications</h3><p>
	  The <a href="#HTTP-implementation"><b>4 HTTP SOAP Transmission Optimization Feature</b></a> (which is an implementation
	  of the <a href="#feature"><b>2 Abstract SOAP Transmission Optimization Feature</b></a> for the SOAP 1.2 HTTP binding) is
	  intended to enhance the SOAP HTTP binding described in <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">7.  SOAP HTTP
	    Binding</a> or an updated version of it.
	</p><p>
	  This document along with <a href="#XOP">[XML-binary Optimized Packaging]</a>
	  and <a href="#">[SOAP Representation Header]</a> has been produced in conjunction
	  with the development of requirements
	  embodied in the <a href="#">[W3C.soap-attachment-req]</a> document.
	</p></div></div><div class="div1">
<h2><a name="feature" id="feature"></a>2 Abstract SOAP Transmission Optimization Feature</h2><div class="div2">
<h3><a name="aof-introduction" id="aof-introduction"></a>2.1 Introduction</h3><p>
	  The Abstract SOAP Transmission Optimization Feature enables SOAP bindings
	  to optimize the transmission and/or wire format of a SOAP message by
	  selectively encoding portions of the message, whilst still presenting
	  an XML Infoset to the SOAP application. Optimization is available
	  only for element content that is in a canonical lexical
	  representation of the <code>xs:base64Binary</code> data type (see
	  <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary">3.2.16
	    base64Binary</a>).
	</p><p>
	  Note: because there is a one-to-one correspondence between such
	  canonical forms and values in the value space of
	  <code>xs:base64Binary</code>, MTOM implementations typically optimize
	  by transmitting a compact representation of the value in place of the
	  less compact character sequence. At the receiver, the character form
	  can be reconstructed if necessary.
	</p><p>
	  Consistent with the requirement that a SOAP binding transmit the
	  Envelope Infoset intact, implementations of this feature MUST NOT
	  substitute canonical for non-canonical representations, or make other
	  changes to optimized element content.
	</p></div><div class="div2">
<h3><a name="aof-name" id="aof-name"></a>2.2 Abstract SOAP Transmission Optimization Feature Name</h3><p>
	  This Abstract SOAP Transmission Optimization Feature is identified by the
	  URI:
	</p><ul><li><p>
	      "http://www.w3.org/2004/08/soap/features/abstract-optimization".
	    </p></li></ul></div><div class="div2">
<h3><a name="aof-processing" id="aof-processing"></a>2.3 Abstract SOAP Transmission Optimization Feature Processing</h3><div class="div3">
<h4><a name="aof-sending" id="aof-sending"></a>2.3.1 Sending a message</h4><p>
	    When sending a SOAP Message, if the Abstract Transmission
	    Optimization Feature is used in combination with the SOAP
	    Request-Response Message Exchange Pattern (<a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#singlereqrespmep">6.2
	      SOAP Request-Response Message Exchange Pattern</a>) or the
	    SOAP Response Message Exchange Pattern (<a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapresmep">6.3 SOAP
	      Response Message Exchange Pattern</a>), the
	    <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>
	    property is the Infoset of the SOAP Message to be sent. Similar
	    rules should be applied for other MEPs, as appropriate.
	  </p><p>
	    The purpose of the Abstract SOAP Transmission Optimization Feature is to
	    optimize the transmission of base64 encoded data. To be optimized,
	    the characters comprising the [children] of an <em>element
	      information item</em> MUST be in the canonical form of
	    <code>xs:base64Binary</code> (see  <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a>
	    <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary">3.2.16
	      base64Binary</a>) and MUST NOT contain any whitespace
	    characters, preceding, inline with or following the non-whitespace
	    content.
	  </p><p>
	    Note: the means of identifying <em>element information
	      items</em> that contain base64 encoded data in
	    canonical lexical form are implementation-dependent. Some
	    implementations can identify such <em>element information
	      items</em> by construction (e.g., because a certain API may
	    create only canonical forms); others may check the characters prior
	    to sending, others may rely on information in the description such
		as the presence and/or value of the <code>xmlmime:expectedMediaType</code>
		schema annotation (see <a href="#xmlmime">[Assigning Media Types to Binary Data in XML]</a>), if a schema is available.
		Because of the need to exactly preserve the characters
	    in the transmitted Infoset, non-canonical representations MUST NOT
	    be optimized by implementations of this feature.
	  </p></div><div class="div3">
<h4><a name="aof-receiving" id="aof-receiving"></a>2.3.2 Receiving a message</h4><p>
	    When receiving a SOAP message optimized using an implementation of
	    the Abstract SOAP Transmission Optimization Feature, a SOAP node SHOULD
	    generate a fault if it does not support the implementation used or the
	    Abstract SOAP Transmission Optimization Feature.
	  </p><p>
	    Upon reception of an optimized SOAP message, the receiving node
	    MUST reconstruct an Envelope Infoset from the optimized SOAP
	    message. Then, the receiving node MUST perform SOAP processing on
	    the reconstructed Infoset (see <a href="#W3C.soap-part1">[SOAP Version 1.2 Part 1: Messaging Framework]</a>
	    <a href="http://www.w3.org/TR/soap12-part1/#msgexchngmdl">2.
	      SOAP Processing Model</a>). In all cases, the received
	    Infoset MUST be exactly the same as that transmitted by the sender.
	  </p><p>
	    Implementations are free to reconstruct only those portions
	    actually needed for processing, or to present information from the
	    message in a form convenient for efficient processing. For example,
	    a value sent in an optimized form (e.g., binary) MAY be made
	    available in that form as well as in the base64 encoded character
	    form.
	  </p><p>
	    When this feature is used in combination with the SOAP
	    Request-Response Message Exchange Pattern (<a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#singlereqrespmep">6.2
	      SOAP Request-Response Message Exchange Pattern</a>) or the
	    SOAP Response Message Exchange Pattern (<a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapresmep">6.3 SOAP
	      Response Message Exchange Pattern</a>), the Infoset
	    contained in the
	    <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code>
	    property is the Infoset of the reconstructed SOAP Envelope. Similar
	    rules should be applied for other MEPs, as appropriate.
	  </p></div><div class="div3">
<h4><a name="aof-intermediaries" id="aof-intermediaries"></a>2.3.3 Intermediaries</h4><p>
	    Use of the Abstract SOAP 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. The section <a href="#aof-intermed"><b>2.3.4 Binding Optimizations at Intermediaries</b></a> details the
	    means by which certain optimizations can be performed by bindings
	    at intermediaries.
	  </p><p>
	    However a SOAP intermediary implementing the Abstract Transmission
	    Optimization Feature MUST still follow the rules related to the
	    usage of an implementation of the Abstract Transmission
	    Optimization Feature when receiving the message (see <a href="#aof-receiving"><b>2.3.2 Receiving a message</b></a>) and those  related to the usage of an
	    implementation of the Abstract SOAP Transmission Optimization Feature
	    when sending the message (see <a href="#aof-sending"><b>2.3.1 Sending a message</b></a>). In
	    particular, it MUST follow the rules for relaying SOAP messages (see
	    <a href="#W3C.soap-part1">[SOAP Version 1.2 Part 1: Messaging Framework]</a> <a href="http://www.w3.org/TR/soap12-part1/#relaysoapmsg">2.7
	      Relaying SOAP Messages</a>).
	  </p></div><div class="div3">
<h4><a name="aof-intermed" id="aof-intermed"></a>2.3.4 Binding Optimizations at Intermediaries</h4><p>
	    As described in <a href="#W3C.soap-part1">[SOAP Version 1.2 Part 1: Messaging Framework]</a> <a href="http://www.w3.org/TR/soap12-part1/#relaysoapmsg">2.7
	      Relaying SOAP Messages</a>, a SOAP intermediary may be
	    called upon 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.
	  </p><p>
	    The Abstract SOAP 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.
	  </p><p>
	    Note: a consequence of this architecture 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 non-optimized forms in all cases.  Other bindings may be
	    capable of optimization, but may or may not choose to optimize 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.
	  </p></div></div></div><div class="div1">
<h2><a name="xop-serialization" id="xop-serialization"></a>3 An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</h2><div class="div2">
<h3><a name="im-introduction" id="im-introduction"></a>3.1 Introduction</h3><p>
	  The Optimized MIME Multipart/Related Serialization expands upon the
	  Abstract SOAP Transmission Optimization Feature by describing parts of an
	  implementation of this feature using the <a href="#XOP">[XML-binary Optimized Packaging]</a> format
	  as its basis. This specification does not describe a full
	  implementation but is intended to provide support for building a full
	  implementation of the Abstract SOAP Transmission Optimization Feature. In
	  particular, this specification does not specify the use of any
	  transport for the SOAP message. A full implementation based on this
	  specification is described in <a href="#httpof-name"><b>4.2 HTTP SOAP Transmission Optimization Feature Name</b></a>.
       	</p><p>
	  The Optimized MIME Multipart/Related Serialization provides the basis
	  for an implementation of the Abstract Transmission Optimization
	  Feature by describing how to serialize a SOAP envelope in an
	  optimized way, using the <a href="#XOP">[XML-binary Optimized Packaging]</a> format and a MIME
	  Multipart/Related packaging (<a href="#RFC2387">[RFC 2387]</a>).
	</p><p>
	  More specifically, the SOAP envelope Infoset is transmitted as a MIME
	  Multipart/Related XOP Package (see <a href="#XOP">[XML-binary Optimized Packaging]</a>, <a href="">4.1
	    MIME Multipart/Related XOP Packages</a>). Any W3C
	  recommendation-level version of XML is allowed for storing the XOP
	  Infoset created from the SOAP envelope Infoset into the MIME
	  Multipart/Related XOP Package, however, note that the SOAP envelope
	  Infoset MUST be serializable as XML 1.0.
	</p></div><div class="div2">
<h3><a name="mime-serialization" id="mime-serialization"></a>3.2 Serialization of a SOAP message</h3><p>
	  When sending a SOAP message using the MIME Multipart/Related
	  Serialization, the SOAP envelope Infoset is serialized as specified
	  in <a href="#XOP">[XML-binary Optimized Packaging]</a> <a href="http://www.w3.org/TR/2005/REC-xop10-20050125/#creating_xop_packages">3.1
	    Creating XOP packages</a>.  Specifically:
	</p><ul><li>The content-type of the outer package MUST be multipart/related.</li><li>The type parameter of the content-type header of the outer package MUST have a value of "application/xop+xml" (see <a href="#XOP">[XML-binary Optimized Packaging]</a>, <a href="">4.1
	    MIME Multipart/Related XOP Packages</a>). </li><li>The startinfo parameter of the content-type header of the outer package MUST specify
                a content-type for the root part of "application/soap+xml".</li><li>The content-type of the root part MUST be
                application/xop+xml (see <a href="#XOP">[XML-binary Optimized Packaging]</a>, <a href="">4.1
	    MIME Multipart/Related XOP Packages</a>). </li><li>The type parameter of the content-type header of the root part MUST specify a
                content-type of "application/soap+xml".</li></ul><p>The result is a MIME
	  Multipart/Related XOP package (see <a href="#XOP">[XML-binary Optimized Packaging]</a>): one body
	  part, the root, containing an XML representation of the modified SOAP
	  envelope, with an additional part used to contain the binary
	  representation of each element that was optimized.
	</p></div><div class="div2">
<h3><a name="mime-deserialization" id="mime-deserialization"></a>3.3 Deserialization of a SOAP message</h3><p>
	  When receiving a SOAP message using this Optimized MIME
	  Multipart/Related Serialization, the SOAP Envelope Infoset is
	  reconstructed from the MIME Multipart/Related XOP Package by
	  performing the processing specified in <a href="#XOP">[XML-binary Optimized Packaging]</a> <a href="http://www.w3.org/TR/2005/REC-xop10-20050125/#interpreting_xop_packages">3.2
	    Interpreting XOP packages</a>.
	</p><p>
	  Note: conventions or error reporting mechanisms to be used in
	  processing packages that incorrectly purport to be XOP Packages
	  containing a SOAP Envelope are beyond the scope of this
	  specification.
	</p></div></div><div class="div1">
<h2><a name="HTTP-implementation" id="HTTP-implementation"></a>4 HTTP SOAP Transmission Optimization Feature</h2><div class="div2">
<h3><a name="httpof-introduction" id="httpof-introduction"></a>4.1 Introduction</h3><p>
	  The HTTP SOAP Transmission Optimization Feature is a binding-level feature
	  implementing the Abstract SOAP Transmission Optimization Feature in an
	  HTTP binding. The basis of this HTTP SOAP Transmission Optimization
	  Feature is the Optimized MIME Multipart/Related Serialization
	  described in <a href="#xop-serialization"><b>3 An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</b></a>.
	</p><p>
	  This HTTP SOAP Transmission Optimization Feature builds upon the current
	  HTTP binding (see <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">7. SOAP HTTP
	    Binding</a>), enhancing it with the support of the Abstract
	  SOAP Transmission Optimization Feature.  In all aspects not described in
	  this section, the rules of the HTTP binding are not modified.
	</p></div><div class="div2">
<h3><a name="httpof-name" id="httpof-name"></a>4.2 HTTP SOAP Transmission Optimization Feature Name</h3><p>
	  This HTTP SOAP Transmission Optimization Feature is identified by the URI:
	</p><ul><li><p>
	      "http://www.w3.org/2004/08/soap/features/http-optimization".
	    </p></li></ul></div><div class="div2">
<h3><a name="httpof-implementation" id="httpof-implementation"></a>4.3 Implementation</h3><p>
	  The HTTP SOAP Transmission Optimization Feature uses the Optimized MIME
	  Multipart/Related Serialization (see <a href="#xop-serialization"><b>3 An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</b></a>) for implementing the Abstract
	  SOAP Transmission Optimization Feature. On the sending side, this feature
	  serializes the SOAP message as described in <a href="#mime-serialization"><b>3.2 Serialization of a SOAP message</b></a> and puts the MIME headers of the resulting MIME
	  Multipart/Related XOP Package in as HTTP headers and the rest of the package into the HTTP body. On the receiving side,
	  this feature extracts the MIME headers from the HTTP headers and the rest of the MIME Multipart/Related XOP Package from the
	  HTTP body and deserializes as described in <a href="#mime-deserialization"><b>3.3 Deserialization of a SOAP message</b></a>.
	</p><div class="div3">
<h4><a name="httpof-sending" id="httpof-sending"></a>4.3.1 Sending a SOAP message</h4><p>
	    When sending a SOAP message, the HTTP SOAP Transmission Optimization
	    Feature changes the behavior of <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a>
	    <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">7.
	      SOAP HTTP Binding</a>. This section describes the
	    perturbations to <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#http-reqsoapnode">7.5.1
	      Behavior of Requesting SOAP Node</a> that result from use
	    of the HTTP SOAP Transmission Optimization Feature. Only those aspects
	    described below differ from the existing operation of the HTTP
	    binding, all other aspects of its operation remaining unchanged.
	  </p><div class="div4">
<h5><a name="httpof-sending-init" id="httpof-sending-init"></a>4.3.1.1 Init</h5><p>
	      In the "Init" state, a HTTP request is formulated and
	      transmission of the request is initiated. When using the HTTP
	      SOAP Transmission Optimization Feature, the formulation of the request
	      differs from <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#http-reqbindreqstate">7.5.1.1 Init</a>
	      as shown in <b>[<a href="#tabreqstateinitfields">HTTP Request Fields</a>]</b>.
	    </p><table border="1"><caption id="tabreqstateinitfields">HTTP Request Fields</caption><tbody><tr><th>Field</th><th>Value</th></tr><tr><td>Content-Type header field</td><td>multipart/related</td></tr><tr><td>HTTP entity body</td><td>SOAP message serialized as described in <a href="#xop-serialization"><b>3 An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</b></a></td></tr></tbody></table><p>
	      The XOP package is constructed as described in <a href="#xop-serialization"><b>3 An Optimized MIME Multipart/Related Serialization of SOAP
	Messages</b></a> with the following
	      restriction:
	    </p><ul><li><p>
		  The XOP Infoset MUST be serialized as
		  <code>application/xop+xml</code> in the root part of the
		  package per Section 5 of <a href="#XOP">[XML-binary Optimized Packaging]</a>.
		</p></li><li><p>
		  Each optimized <em>Node</em> MUST generate exactly one
		  extracted binary part in the resulting package, i.e.,
		  extracted binary parts MUST NOT be referenced by more than
		  one <code>xop:Include</code> in the SOAP message part.
		</p></li><li><p>
		  Each MIME part that is refered to by <code>xop:Include</code>
		  MUST have a Content-Transfer-Encoding header field.
		</p></li></ul><p>
	      Note: this does not preclude the MIME Multipart/Related package
	      from including additional parts not referenced by a
	      <code>xop:Include</code> element. Such additional parts are not part of
	      the SOAP message Infoset and are not included in the SOAP
	      processing model.
	    </p><p>
	      Implementations of this binding MUST enforce the restriction that
	      XOP is not to be used with Infosets that contain <em>element
		information items</em> of name <code>xop:Include</code> (see
	      <a href="#XOP">[XML-binary Optimized Packaging]</a> <a href="http://www.w3.org/TR/2005/REC-xop10-20050125/#xop_infosets">3.
		XOP Infosets Constructs</a>). In any case where a SOAP
	      envelope containing such an <em> element information item</em>
	      is to be sent, the binding MUST do one of the following:
	    </p><ul><li>
		Fall back to use the <code>application/soap+xml</code> media type
		or any other suitable media type, i.e., send the SOAP envelope
		without using the HTTP SOAP Transmission Optimization Feature.
	      </li><li>
		Generate a binding-dependent SOAP fault.
	      </li></ul><p>
	      Note that such SOAP envelopes could in principle arise either
	      from data created locally at the sending node or in data relayed
	      at an intermediary. Bindings are responsible for checking all
	      such input as necessary to ensure that the rule just stated is
	      enforced.
	    </p></div></div><div class="div3">
<h4><a name="httpof-receiving" id="httpof-receiving"></a>4.3.2 Receiving a SOAP message</h4><p>
	    When receiving a SOAP message, an implementation of the SOAP HTTP
	    Binding (see <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a>) will determine whether
	    the HTTP SOAP Transmission Optimization Feature is used by checking the
	    presence of the <code>application/xop+xml</code> media type (see
	    <a href="#XOP">[XML-binary Optimized Packaging]</a> Section 5.1). If the media type of the HTTP message is "multipart/related"
	    and the media type of the root part of the MIME Multipart/Related
	    package is <code>application/xop+xml</code>, and the start-info parameter
		indicates a content type of "application/soap+xml" then the received
	    SOAP message was transmitted using the HTTP SOAP Transmission
	    Optimization Feature and MUST be processed accordingly.
	  </p><p>
	    The HTTP SOAP Transmission Optimization Feature changes the behavior of
	    <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">7.  SOAP
	      HTTP Binding</a> for the reception of a SOAP message. The
	    perturbations to <a href="#W3C.soap-part2">[SOAP Version 1.2 Part 2: Adjuncts]</a> <a href="http://www.w3.org/TR/soap12-part2/#http-bindrespnode">7.5.2
	      Behavior of Responding SOAP Node</a> that result from use
	    of the HTTP SOAP Transmission Optimization Feature are as follows:
	  </p><ul><li><p>
	    When making an abstraction of the request message available in
	    <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code>, the
	    HTTP Binding MUST reconstruct the SOAP Envelope Infoset as
	    described in <a href="#mime-deserialization"><b>3.3 Deserialization of a SOAP message</b></a>.
	  </p></li></ul><p>
		All other aspects of the operation of the HTTP binding remain unchanged.
	  </p></div></div></div></div><div class="back"><div class="div1">
<h2><a name="references" id="references"></a>A References</h2><dl><dt class="label"><a name="W3C.soap-part1" id="W3C.soap-part1"></a>SOAP Version 1.2 Part 1: Messaging Framework</dt><dd>
     	<a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/"><cite>SOAP
	Version 1.2 Part 1: Messaging Framework</cite></a>, Marc Hadley,
	Noah Mendelsohn, Jean-Jacques Moreau, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 24 June 2003.
	This version is http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
	The <a href="http://www.w3.org/TR/soap12-part1/">latest version</a> is
	available at http://www.w3.org/TR/soap12-part1/.</dd><dt class="label"><a name="W3C.soap-part2" id="W3C.soap-part2"></a>SOAP Version 1.2 Part 2: Adjuncts</dt><dd>
	<a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/"><cite>SOAP
	Version 1.2 Part 2: Adjuncts</cite></a>, Henrik Frystyk Nielsen,
	Noah Mendelsohn, Jean-Jacques Moreau, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 24 June 2003.
	This version is http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.
	The <a href="http://www.w3.org/TR/soap12-part2/">latest version</a> is
	available at http://www.w3.org/TR/soap12-part2/.</dd><dt class="label"><a name="XOP" id="XOP"></a>XML-binary Optimized Packaging</dt><dd>
        <a href="http://www.w3.org/TR/2005/REC-xop10-20050125/"><cite>XML-binary Optimized
	Packaging</cite></a>, Mark Nottingham, Noah Mendelsohn, Martin Gudgin,
	and Hervé Ruellan, Editors.
	World Wide Web Consortium,
	25 January 2005.
	This version is http://www.w3.org/TR/2005/REC-xop10-20050125/.
	The <a href="http://www.w3.org/TR/xop10/">latest version</a> is
	available at http://www.w3.org/TR/xop10/.</dd><dt class="label"><a name="W3C.soap-attachment" id="W3C.soap-attachment"></a>SOAP 1.2 Attachment Feature</dt><dd>
        <a href="http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/"><cite>SOAP 1.2 Attachment
	Feature</cite></a>, Hervé Ruellan and Henrik Frystyk Nielsen,
	Editors. World Wide Web Consortium, 08 June 2004.
	This version is http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/.
	The <a href="http://www.w3.org/TR/soap12-af/">latest version</a> is
	available at http://www.w3.org/TR/soap12-af/.</dd><dt class="label"><a name="ucr" id="ucr"></a>SOAP Optimized Serialization Use Cases and Requirements</dt><dd>
	<a href="http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/"><cite>SOAP Optimized
	Serialization Use Cases and Requirements</cite></a>, Tony Graham,
	Mark Jones, and Anish Karmarkar, Editors.
	World Wide Web Consortium, 08 June 2004.
	This version is http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/.
	The <a href="http://www.w3.org/TR/soap12-os-ucr/">latest version</a>
	is available at http://www.w3.org/TR/soap12-os-ucr/.</dd><dt class="label"><a name="rep" id="rep"></a>Resource Representation SOAP Header Block</dt><dd>
	 <a href="http://www.w3.org/TR/2005/REC-soap12-rep-20050125/"><cite>Resource
	 Representation SOAP Header Block</cite></a>, Martin Gudgin,
	 Yves Lafon, and Anish Karmarkar, Editors.
	 World Wide Web Consortium,
	 25 January 2005.
	 This version is http://www.w3.org/TR/2005/REC-soap12-rep-20050125/.
	 The <a href="http://www.w3.org/TR/soap12-rep/">latest version</a> is
	 available at http://www.w3.org/TR/soap12-rep/.</dd><dt class="label"><a name="xmlmime" id="xmlmime"></a>Assigning Media Types to Binary Data in XML</dt><dd>
	<a href="http://www.w3.org/TR/2004/WD-xml-media-types-20041102"><cite>Assigning Media
	Types to Binary Data in XML</cite></a>,
	Ümit Yalçınalp and Anish Karmarkar, Editors.
	World Wide Web Consortium, 02 November 2004.
	This version is http://www.w3.org/TR/2004/WD-xml-media-types-20041102.
	The <a href="http://www.w3.org/TR/xml-media-types">latest version</a>
	is available at http://www.w3.org/TR/xml-media-types.</dd><dt class="label"><a name="XML" id="XML"></a>Extensible Markup Language (XML) 1.0 (Third Edition)</dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xml-20040204"><cite>Extensible Markup
	Language (XML) 1.0 (Third Edition)</cite></a>, Jean Paoli, Eve Maler,
	Tim Bray, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 04 February 2004.
	This version is http://www.w3.org/TR/2004/REC-xml-20040204.
	The <a href="http://www.w3.org/TR/REC-xml">latest version</a> is
	available at http://www.w3.org/TR/REC-xml.</dd><dt class="label"><a name="XMLNS" id="XMLNS"></a>Namespaces in XML</dt><dd>
	<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114"><cite>Namespaces in
	XML</cite></a>, Andrew Layman, Dave Hollander, and Tim Bray, Editors.
	World Wide Web Consortium, 14 January 1999.
	This version is http://www.w3.org/TR/1999/REC-xml-names-19990114.
	The <a href="http://www.w3.org/TR/REC-xml-names">latest version</a> is
	available at http://www.w3.org/TR/REC-xml-names.</dd><dt class="label"><a name="XMLInfoset" id="XMLInfoset"></a>XML Information Set (Second Edition)</dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"><cite>XML Information Set
	(Second Edition)</cite></a>, Richard Tobin and John Cowan, Editors.
	World Wide Web Consortium, 04 Feb 2004.
	This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204.
	The <a href="http://www.w3.org/TR/xml-infoset">latest version</a> is
	available at http://www.w3.org/TR/xml-infoset.</dd><dt class="label"><a name="XMLSchemaP1" id="XMLSchemaP1"></a>XML Schema Part 1: Structures Second Edition</dt><dd>
        <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1:
	Structures Second Edition</cite></a>, David Beech, Murray Maloney, Henry S. Thompson,
	and Noah Mendelsohn, Editors.
	World Wide Web Consortium, 28 October 2004.
	This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
	The <a href="http://www.w3.org/TR/xmlschema-1/">latest version</a> is
	available at http://www.w3.org/TR/xmlschema-1/.</dd><dt class="label"><a name="XMLSchemaP2" id="XMLSchemaP2"></a>XML Schema Part 2: Datatypes Second Edition</dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2:
	Datatypes Second Edition</cite></a>, Ashok Malhotra and Paul V. Biron, Editors.
	World Wide Web Consortium, 28 October 2004.
	This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.
	The <a href="http://www.w3.org/TR/xmlschema-2/">latest version</a> is
	available at http://www.w3.org/TR/xmlschema-2/.</dd><dt class="label"><a name="RFC2119" id="RFC2119"></a>RFC 2119</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for
	use in RFCs to Indicate Requirement Levels</cite></a>, S. Bradner,
	Editor.
	IETF, March 1997.
	This RFC is available at http://www.ietf.org/rfc/rfc2119.txt.</dd><dt class="label"><a name="RFC2387" id="RFC2387"></a>RFC 2387</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2387.txt"><cite>The MIME
	Multipart/Related Content-type</cite></a>, E. Levinson,
	Editor.
	IETF, August 1998.
	This RFC is available at http://www.ietf.org/rfc/rfc2387.txt.</dd><dt class="label"><a name="RFC2396" id="RFC2396"></a>RFC 2396</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource
	Identifiers (URI): Generic Syntax</cite></a>, T. Berners-Lee,
	R. Fielding and L. Masinter, Editors.
	IETF, August 1998.
	This RFC is available at http://www.ietf.org/rfc/rfc2396.txt.</dd><dt class="label"><a name="RFC3023" id="RFC3023"></a>RFC 3023</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc3023.txt"><cite>XML
	Media Types</cite></a>, M. Murata, S. St.Laurent
	and D. Kohn, Editors.
	IETF, January 2001.
	This RFC is available at http://www.ietf.org/rfc/rfc3023.txt.</dd><dt class="label"><a name="PASWA" id="PASWA"></a>PASWA</dt><dd>
	<a href="http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html"><cite>Proposed Infoset Addendum to SOAP Messages with Attachments</cite></a>,

	AT&amp;T, BEA Systems, Canon, Microsoft Corporation, SAP AG
	and Tibco Software, April 2003.
	This document is available at
	http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.</dd></dl></div><div class="div1">
<h2><a name="acks" id="acks"></a>B Acknowledgements (Non-Normative)</h2><p>This specification is the work of the W3C XML Protocol Working Group.</p><p>Participants in the Working Group are (at the time of writing, and by
      alphabetical order): David Fallside (IBM),
Tony Graham (Sun Microsystems),
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
Marc Hadley (Sun Microsystems),
Gerd Hoelzing (SAP AG),
John Ibbotson (IBM),
Anish Karmarkar (Oracle),
Suresh Kodichath (IONA Technologies),
Yves Lafon (W3C),
Michael Mahan (Nokia),
Noah Mendelsohn (IBM, formerly of Lotus Development),
Jeff Mischkinsky (Oracle),
Jean-Jacques Moreau (Canon),
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
David Orchard (BEA Systems, formerly of Jamcracker),
Herve Ruellan (Canon),
Jeff Schlimmer (Microsoft Corporation),
Pete Wenzel (SeeBeyond),
Volker Wiechers (SAP AG).
</p><p>Previous participants were: Yasser alSafadi (Philips Research),
Bill Anderson (Xerox),
Vidur Apparao (Netscape),
Camilo Arbelaez (webMethods),
Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems),
Philippe Bedu (EDF (Electricite De France)),
Olivier Boudeville (EDF (Electricite De France)),
Carine Bournez (W3C),
Don Box (Microsoft Corporation, formerly of DevelopMentor),
Tom Breuel (Xerox),
Dick Brooks (Group 8760),
Winston Bumpus (Novell, Inc.),
David Burdett (Commerce One),
Charles Campbell (Informix Software),
Alex Ceponkus (Bowstreet),
Michael Champion (Software AG),
David Chappell (Sonic Software),
Miles Chaston (Epicentric),
David Clay (Oracle),
David Cleary (Progress Software),
Dave Cleary (webMethods),
Ugo Corda (Xerox),
Paul Cotton (Microsoft Corporation),
Fransisco Cubera (IBM),
Jim d'Augustine (Excelon Corporation),
Ron Daniel (Interwoven),
Glen Daniels (Macromedia),
Doug Davis (IBM),
Ray Denenberg (Library of Congress),
Paul Denning (MITRE Corporation),
Frank DeRose (TIBCO Software, Inc.),
Mike Dierken (DataChannel),
Andrew Eisenberg (Progress Software),
Brian Eisenberg (DataChannel),
Colleen Evans (Sonic Software),
John Evdemon (XMLSolutions),
David Ezell (Hewlett Packard),
James Falek (TIBCO Software, Inc.),
Eric Fedok (Active Data Exchange),
Chris Ferris (Sun Microsystems),
Daniela Florescu (Propel),
Dan Frantz (BEA Systems),
Michael Freeman (Engenia Software),
Dietmar Gaertner (Software AG),
Scott Golubock (Epicentric),
Mike Greenberg (IONA Technologies),
Rich Greenfield (Library of Congress),
Hugo Haas (W3C),
Mark Hale (Interwoven),
Randy Hall (Intel),
Bjoern Heckel (Epicentric),
Frederick Hirsch (Zolera Systems),
Erin Hoffmann (Tradia Inc.),
Steve Hole (MessagingDirect Ltd.),
Mary Holstege (Calico Commerce),
Jim Hughes (Fujitsu Limited),
Oisin Hurley (IONA Technologies),
Yin-Leng Husband (Hewlett Packard, formerly of Compaq),
Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.),
Scott Isaacson (Novell, Inc.),
Kazunori Iwasa (Fujitsu Limited),
Murali Janakiraman (Rogue Wave),
Mario Jeckle (DaimlerChrysler Research and Technology),
Eric Jenkins (Engenia Software),
Mark Jones (AT&amp;T),
Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software),
Richard Koo (Vitria Technology Inc.),
Jacek Kopecky (Systinet),
Alan Kropp (Epicentric),
Julian Kumar (Epicentric),
Peter Lecuyer (Progress Software),
Tony Lee (Vitria Technology Inc.),
Michah Lerner (AT&amp;T),
Bob Lojek (Intalio Inc.),
Henry Lowe (OMG),
Brad Lund (Intel),
Matthew MacKenzie (XMLGlobal Technologies),
Murray Maloney (Commerce One),
Richard Martin (Active Data Exchange),
Alex Milowski (Lexica),
Kevin Mitchell (XMLSolutions),
Nilo Mitra (Ericsson),
Ed Mooney (Sun Microsystems),
Dean Moses (Epicentric),
Highland Mary Mountain (Intel),
Don Mullen (TIBCO Software, Inc.),
Rekha Nagarajan (Calico Commerce),
Raj Nair (Cisco Systems),
Masahiko Narita (Fujitsu Limited),
Mark Needleman (Data Research Associates),
Art Nevarez (Novell, Inc.),
Eric Newcomer (IONA Technologies),
Henrik Nielsen (Microsoft Corporation),
Conleth O'Connell (Vignette),
Kevin Perkins (Compaq),
Jags Ramnaryan (BEA Systems),
Andreas Riegg (DaimlerChrysler Research and Technology),
Vilhelm Rosenqvist (NCR),
Marwan Sabbouh (MITRE Corporation),
Waqar Sadiq (Vitria Technology Inc.),
Rich Salz (Zolera Systems),
Krishna Sankar (Cisco Systems),
George Scott (Tradia Inc.),
Shane Sesta (Active Data Exchange),
Lew Shannon (NCR),
John-Paul Sicotte (MessagingDirect Ltd.),
Miroslav Simek (Systinet),
Simeon Simeonov (Macromedia),
Aaron Skonnard (DevelopMentor),
Nick Smilonich (Unisys),
Seumas Soltysik (IONA Technologies),
Soumitro Tagore (Informix Software),
James Tauber (Bowstreet),
Anne Thomas Manes (Sun Microsystems),
Lynne Thompson (Unisys),
Patrick Thompson (Rogue Wave),
Jim Trezzo (Oracle),
Asir Vedamuthu (webMethods),
Randy Waldrop (WebMethods),
Fred Waskiewicz (OMG),
David Webber (XMLGlobal Technologies),
Ray Whitmer (Netscape),
Stuart Williams (Hewlett Packard),
Yan Xu (DataChannel),
Amr Yassin (Philips Research),
Susan Yee (Active Data Exchange),
Jin Yu (MartSoft Corp.).
</p><p>The people who have contributed to discussions on
<a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>
are also gratefully acknowledged.</p></div></div></body></html>