Update to MTOM specification
"Herve Ruellan" <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
Dear all, Here is a revised draft of the MTOM specification. This draft is a first try at removing from the MTOM specification the description of the MIME packaging and referring to the MIFFY specification [1]. This draft is still in a rought state and will need to be improved as the MIFFY specification evolves. The draft uses colored diffs for better showing the modifications, however in some places large amount of texts were removed and only the section title remains. Best regards, Hervé. [1]
OptimizationMechanism-25-11-03.html
(text/html, 53 KB)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><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; }
dt.label { display: run-in; }
li, p { margin-top: 0.3em;
margin-bottom: 0.3em; }
p.diff-chg,
li.diff-chg,
h1.diff-chg,
h2.diff-chg,
h3.diff-chg,
h4.diff-chg,
h5.diff-chg,
h6.diff-chg,
td.diff-chg,
tr.diff-chg { background-color: orange; }
p.diff-del,
li.diff-del,
h1.diff-del,
h2.diff-del,
h3.diff-del,
h4.diff-del,
h5.diff-del,
h6.diff-del,
td.diff-del,
tr.diff-del { background-color: red; text-decoration: line-through;}
p.diff-add,
p.diff-add,
h1.diff-add,
h2.diff-add,
h3.diff-add,
h4.diff-add,
h5.diff-add,
h6.diff-add,
td.diff-add,
tr.diff-add { background-color: lime; }
table { empty-cells: show; }
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 type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/base.css"></head><body>
<div class="head">
<h1>SOAP Message Transmission Optimization Mechanism</h1>
<h2>Editors Copy $Date: 2003/10/08 15:56:23 $ 21 July 2003</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2003/WD-soap12-mtom-20030721">http://www.w3.org/TR/2003/WD-soap12-mtom-20030721</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>Editors:</dt>
<dd>Noah Mendelsohn, IBM</dd>
<dd>Mark Nottingham, BEA</dd>
<dd>Hervé Ruellan, Canon</dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©2003 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>(<a href="http://www.lcs.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">viability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr><div>
<h2><a name="abstract">Abstract</a></h2>
<p class="diff-del">
This document describes an abstract feature and a concrete
implementation of it for optimizing the transmission and/or wire format
of SOAP messages.
</p>
<p class="diff-add">
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 MIFFY
format (ref?) for carrying SOAP messages.
</p>
</div><div>
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p>
<p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. The latest status of this document series is maintained
at the W3C.</em></p>
<p class="diff-chg">This is an editor's copy of the SOAP Message Transmission Optimization Mechanism document. It has been produced by the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a> (WG), which is part of the <a href="http://www.w3.org/2002/ws/Activity"> Web Services Activity</a>.</p>
<p>Discussion of this document takes place on the public <a href="mailto:[email protected]">[email protected]</a> mailing list <a href="http://lists.w3.org/Archives/Public/xml-dist-app/">(public archive)</a> under the email communication rules in the <a href="http://www.w3.org/2000/09/XML-Protocol-Charter"> XML Protocol Working Group Charter </a>.</p>
<p>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>This is a public W3C Working Draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all <a href="http://www.w3.org/TR/">W3C technical reports</a> can be found at http://www.w3.org/TR/.</p>
</div>
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#feature">Abstract Transmission Optimization Feature</a><br>3. <a href="#inclusion-mechanism">Inclusion Mechanism</a><br>4. <a href="#HTTP-implementation">HTTP Transmission Optimization Feature</a><br>A. <a href="#MappingInfosets">Mapping between Infosets and Data Models</a><br>B. <a href="#references">References</a><br>C. <a href="#changelog">Change Log</a> (Non-Normative)<br></p></div><hr><div class="toc">
<h2><a name="contents">Table of Contents</a></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> 1.2.1 <a href="#DMRelation">Use of the Infoset and the XQuery 1.0 and XPath 2.0
Data Model</a><br> 1.2.2 <a href="#SOAPRelation">Relationship to the SOAP Processing model</a><br>2. <a href="#feature">Abstract Transmission Optimization Feature</a><br> 2.1 <a href="#aof-introduction">Introduction</a><br> 2.2 <a href="#aof-name">Abstract Transmission Optimization Feature Name</a><br> 2.3 <a href="#aof-properties">Abstract Transmission Optimization Feature Properties</a><br> 2.4 <a href="#aof-processing">Abstract Transmission Optimization Feature Processing</a><br> 2.4.1 <a href="#aof-sending">Sending a message</a><br> 2.4.2 <a href="#aof-receiving">Receiving a message</a><br> 2.4.3 <a href="#aof-intermediaries">Intermediaries</a><br> 2.4.4 <a href="#aof-intermed">Binding Optimizations at Intermediaries</a><br>3. <a href="#inclusion-mechanism">Inclusion Mechanism</a><br>4. <a href="#HTTP-implementation">HTTP Transmission Optimization Feature</a><br> 4.1 <a href="#httpof-introduction">Introduction</a><br> 4.2 <a href="#httpof-name">HTTP 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.2 <a href="#httpof-receiving">Receiving a SOAP message</a><br></p>
<h3><a id="appendix" name="appendix">Appendices</a></h3><p class="toc">A. <a href="#MappingInfosets">Mapping between Infosets and Data Models</a><br> A.1 <a href="#SenderDMMapping">Infoset Mapping at Sending Nodes</a><br> A.2 <a href="#ReceiverDMMapping">Infoset Mapping at Receiving Nodes</a><br>B. <a href="#references">References</a><br>C. <a href="#changelog">Change Log</a> (Non-Normative)<br></p></div><hr><div class="body">
<div class="div1">
<h2><a name="introduction"></a>1. Introduction</h2>
<p>
The first part of this document (<a href="#feature"><b>2. Abstract Transmission Optimization Feature</b></a>) describes an
abstract feature for optimizing the transmission and/or wire format of
a SOAP message by selectively re-encoding portions of the message,
while still presenting an XML Infoset to the SOAP application.
</p>
<p>
This Abstract Transmission Optimization Feature is intended to be
implemented by SOAP bindings, however nothing precludes
implementation as a SOAP module.
</p>
<p class="diff-del">
Unlike SOAP itself, which is defined in terms of XML Infosets <a href="#">[XMLInfoset]</a>, this feature models message envelopes using the
XQuery 1.0 and XPath 2.0 Data Model <a href="#DM">[XML Query Data Model]</a>, which is a
typed superset of the Infoset. This feature uses type information only
for optimization purposes; it does not provide for reconstruction of
type information at receivers, except as necessary to support
optimization. Nonetheless, use of the data model in this specification
facilitates optimized transmission of query results through SOAP, and
should provide a useful foundation if, for example, digital signature
canonicalizations were to be developed for data model instances. Use
of the data model here should also facilitate the work of those who may
wish to develop features to provide for optimized transmission of the
full typed model: the changes needed to this specification should be
straightforward, and the optimizations provided herein should be easy
to generalize for such use.
</p>
<p>
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 (see <a href="#aof-intermed"><b>2.4.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 class="diff-del">
The second part (<a href="#inclusion-mechanism"><b>3. Inclusion Mechanism</b></a>) describes an Inclusion Mechanism
implementing part of the Abstract Transmission Optimization Feature in
a binding-independant way. The third part (<a href="#HTTP-implementation"><b>4. HTTP Transmission Optimization Feature</b></a>) uses this Inclusion Mechanism for
implementing the Abstract Transmission Optimization Feature for an HTTP
binding.
</p>
<p class="diff-add">
The second part (<a href="#HTTP-implementation"><b>4. HTTP Transmission Optimization Feature</b></a>) describes an
implementation of the Abstract Transmission Optimization Feature for an
HTTP binding using the MIFFY format (ref?).
</p>
<p>
This document represents a transmission optimization mechanism which
was inspired by a similar mechanism in the PASWA document (see <a href="#PASWA">[PASWA]</a>). The WG plans to work later on the other parts of that
document (assigning media types to binary data in XML infosets and
including representations of Web resources in SOAP messages) and to
publish other drafts which will include such mechanisms.
</p>
<div class="div2">
<h3><a name="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 <a href="#tabnsprefixes"><b>Table 1</b></a>. Note that the
choice of any namespace prefix is arbitrary and not semantically
significant (see XML Infoset <a href="#XMLInfoSet">[XML InfoSet]</a>).
</p>
<table border="1" id="tabnsprefixes">
<caption>Table 1: Prefixes and Namespaces used in this specification.</caption>
<tbody>
<tr>
<th rowspan="1" colspan="1">Prefix</th>
<th rowspan="1" colspan="1">Namespace</th>
<th rowspan="1" colspan="1">Notes</th>
</tr>
<tr>
<td rowspan="1" colspan="1">dm</td>
<td rowspan="1" colspan="1">"???"</td>
<td rowspan="1" colspan="1">Consistent with <a href="#DM">[XML Query Data Model]</a>, this prefix is used to
qualify accessor names in the XQuery 1.0 and XPath 2.0 Data
Model. Apparently, no URI has been reserved to correspond to
this prefix.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">env</td>
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-envelope"</td>
<td rowspan="1" colspan="1">A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2]</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="1" colspan="1">xbinc</td>
<td rowspan="1" colspan="1">"http://www.w3.org/2003/06/soap/features/binary-inclusion"</td>
<td rowspan="1" colspan="1">The namespace of the <a href="#inclusion-mechanism"><b>3. Inclusion Mechanism</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">xdt</td>
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/xpath-datatypes"</td>
<td rowspan="1" colspan="1">The namespace of the XPath data types.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">xs</td>
<td rowspan="1" colspan="1">"http://www.w3.org/2001/XMLSchema"</td>
<td rowspan="1" colspan="1">The namespace of XML Schema data types <a href="#XMLSchemaP2">[XML Schema Part 2]</a>.</td>
</tr>
</tbody>
</table>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
Check which namespaces are still used in the specification.
</td></tr></table>
<table border="1" summary="Editorial note: NRM"><tr><td width="50%" valign="top" align="left"><b>Editorial note: NRM</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
Need biblio reference for XPath Data Types.
</td></tr></table>
</div>
<div class="div2">
<h3><a name="relations"></a>1.2 Relation to other specifications</h3>
<p>
This specification has currently no well-defined relation with the
<a href="#W3C.soap-attachment">[SOAP 1.2 Attachment Feature]</a> specification. However, it may be
expected that this specification will supersede the <a href="#W3C.soap-attachment">[SOAP 1.2 Attachment Feature]</a> specification once this specification
has reached a
stable state.
</p>
<p class="diff-chg">
Even if this specification does not target specifically attachments to
a SOAP message, it is expected that it will fulfill all attachment
feature requirements described in <a href="#W3C.soap-attachment-req">[SOAP Attachment Requirements]</a>.
</p>
<p>
The implementation of the abstract feature as a binding feature for
an HTTP binding is intended to enhance the SOAP HTTP binding
described in <a href="#W3C.soap-part2">[SOAP Part 2]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">SOAP HTTP
Binding</a> or an updated version of it.
</p>
<p class="diff-del">
See <a href="#DMRelation"><b>1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0
Data Model</b></a> for a discussion of the XML Infoset
(<a href="#XMLInfoSet">[XML InfoSet]</a>), and the XQuery 1.0 and XPath 2.0 Data
Model (<a href="#DM">[XML Query Data Model]</a>), and their use by this specification.
</p>
<p>
This document has been produced in conjunction with the development
of requirements, embodied in the requirements document <a href="#W3C.soap-attachment-req">[SOAP Attachment Requirements]</a>. The requirements document is a
work in progress. No reconciliation of this document and the
requirements document has been done for this publication. It is
expected that this document and the requirements document will
iteratively evolve over time.
</p>
<div class="div3">
<h4 class="diff-del"><a name="DMRelation"></a>1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0
Data Model</h4>
</div>
<div class="div3">
<h4><a name="SOAPRelation"></a>1.2.2 Relationship to the SOAP Processing model</h4>
<p>
This feature makes no changes to the SOAP processing model.
Although type information is used to optimize transmission of SOAP
envelopes, that type information in no way affects the processing
of messages once received. As described in <a href="#MappingInfosets"><b>A. Mapping between Infosets and Data Models</b></a>, there is in all cases an untyped Infoset
corresponding to each transmitted and received envelope data model.
The data models transmitted MUST in all cases correspond to legal
SOAP envelope Infosets, and SOAP processing MUST be performed on
received Infosets in the manner prescribed by the SOAP
Recommendation.
</p>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
This section should probably be conserved, however it will need
to be revisited and moved to another location.
</td></tr></table>
</div>
</div>
</div>
<div class="div1">
<h2><a name="feature"></a>2. Abstract Transmission Optimization Feature</h2>
<div class="div2">
<h3><a name="aof-introduction"></a>2.1 Introduction</h3>
<p>
The Abstract Transmission Optimization Feature enables SOAP bindings
to optimize the transmission and/or wire format of a SOAP message by
selectively re-encoding portions of the message, whilst still
presenting an XML Infoset to the SOAP application.
</p>
<p class="diff-del">
The Abstract Transmission Optimization Feature also enables SOAP
applications to provide hints about what part of a SOAP message could
be re-encoded in an efficient way. However, it is up to the
implementation to decide if and how it will optimize the transmission
of a given SOAP message.
</p>
</div>
<div class="div2">
<h3><a name="aof-name"></a>2.2 Abstract Transmission Optimization Feature Name</h3>
<p>
This Abstract Transmission Optimization Feature is identified by the
URI:
</p>
<ul>
<li>
<p>
"http://www.w3.org/2003/06/soap/features/abstract-optimization".
</p>
</li>
</ul>
</div>
<div class="div2">
<h3 class="diff-del"><a name="aof-properties"></a>2.3 Abstract Transmission Optimization Feature Properties</h3>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
As the ATOF has no longer any property, this section has been
deleted.
</td></tr></table>
</div>
<div class="div2">
<h3><a name="aof-processing"></a>2.4 Abstract Transmission Optimization Feature Processing</h3>
<div class="div3">
<h4><a name="aof-sending"></a>2.4.1 Sending a message</h4>
<p class="diff-del">
To send a SOAP message using the Abstract Transmission Optimization
Feature, an application MUST enable the Abstract Transmission
Optimization Feature.
In addition it SHOULD define the value of the
<code>http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates</code>
property.
</p>
<p class="diff-add">
When sending a SOAP message, the SOAP processor implementing the
Abstract Transmission Optimization Feature MUST check whether this
Feature is enabled or not. The Abstract Transmission Optimization
Feature can be enabled by the application using the SOAP processor,
by the configuration of the SOAP processor or by any other means.
</p>
<p class="diff-add">
If the Abstract Transmission Optimization Feature is enabled, the
SOAP processor SHOULD use any available implementation of the
Feature for sending the SOAP message. Note that the implementations
of the Feature available can depend on other constraints set for
the sending the SOAP message.
</p>
<p class="diff-add">
If the Abstract Transmission Optimization Feature is not enabled,
the SOAP processor MUST not use any implementation of the Feature
for sending the SOAP message.
</p>
<p class="diff-del">
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 <em>element
nodes</em> listed in the value of the
<code>http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates</code>
property.
The means of optimization is at the discretion of the binding.
The fact that optimization candidates are known to be
of dm:type=xs:base64binary and in canonical form
implies that transmission of the dm:typed-value is sufficient
to enable reconstruction of the required dm:string-value at the receiving node.
Bindings MAY use such means of optimization if desired.
</p>
<p class="diff-del">
In addition, the SOAP node binding MAY optimize the transmission of
other SOAP message <em>element nodes</em> not
listed in the value of the
<code>http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates</code>
property. In particular, if the
<code>http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates</code>
property is not defined or if it has an empty value, the SOAP node
binding MAY optimize the transmission of any SOAP message
<em>element node(s)</em> which have a dm:type of xs:base64binary and which are known to be in canonical form.
</p>
<table border="1" class="diff-del" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2" class="diff-del">
Do we allow the optimization of the <code>Envelope</code> ,
<code>Header</code> , <code>Body</code>
<em>element information items</em>, or of a full Header
Block?
</td></tr></table>
<table border="1" class="diff-del" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2" class="diff-del">
If the binding used does not implement the Abstract Transmission
Optimization Feature there are several options which can be
followed: fault; send the message ignoring the request for using
the Abstract Optimization Feature; send the message including the
request for using the Abstract Transmission Optimization Feature
(allows an intermediary implementing it to use its
implementation).
</td></tr></table>
</div>
<div class="div3">
<h4><a name="aof-receiving"></a>2.4.2 Receiving a message</h4>
<p>
When receiving a SOAP message using an implementation of the
Abstract Transmission Optimization Feature, a SOAP node MUST fault
if it does not support the implementation used or the Abstract
Transmission Optimization Feature.
</p>
<p class="diff-del">
When receiving a SOAP message using an implementation of the
Abstract Transmission Optimization Feature, a SOAP node binding
MUST reconstruct the transmitted data model,
with the following exceptions:
<ul diff="del">
<li diff="del">
The dm:type of any or all received data model nodes may be set as indeterminate, using the mechanisms of <a href="http://www.w3.org/TR/xpath-datamodel/#dm-type">dm:type</a>.
</li>
<li diff="del">For any such nodes, the dm:typed-value must be adjusted accordingly,
E.g. to return the same characters as dm:string-value for elements and attributes of simple type (see <a href="http://www.w3.org/TR/xpath-datamodel/#dm-typed-value">dm:typed-value</a>).
</li>
<li diff="del">
</li>
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
character form mandated by dm:string-value.
</ul>
</p>
<p class="diff-del">
The receiving node MUST reconstruct from the data model an Envelope
Infoset, as described in <a href="#ReceiverDMMapping"><b>A.2 Infoset Mapping at Receiving Nodes</b></a>; the
receiving node MUST then perform SOAP processing on the
reconstructed Infoset.
</p>
<p class="diff-add">
A SOAP node receiving a SOAP message using an implementation of the
Abstract Transmission Optimization Feature MUST reconstruct the
Envelope Infoset as specified by the implementation of the Feature.
The receiving node MUST then perform SOAP processing on the
reconstructed Infoset.
</p>
<p class="diff-del">
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
<code>http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates</code> property to reflect the SOAP
message parts whose transmission was optimized in the incoming
message.
</p>
<p class="diff-add">
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.
</p>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
We should decide on a SHOULD or on a MAY. In addition, the
<code>http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates</code>
property is not very meaningful on the receiver side. We may
create another property for reflecting <em>element information
items</em> whose transmission was effectively optimized (an
efficient implementation will provide this property to allow
efficient retrieval of the optimized <em>element information
items</em>).
</td></tr></table>
</div>
<div class="div3">
<h4><a name="aof-intermediaries"></a>2.4.3 Intermediaries</h4>
<p>
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. <a href="#aof-intermed"><b>2.4.4 Binding Optimizations at Intermediaries</b></a> details
the means by which
certain optimizations can be performed by bindings at
intermediaries. Note that <a href="http://www.w3.org/TR/xpath-datamodel/#dm-type">dm:type</a> is used only as a means of facilitating hop-by-hop optimization: it does not in general affect processing at a SOAP receiver, and values of dm:type are not in general preserved when relaying through an intermediary.
</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.4.2 Receiving a message</b></a>) and those related to the usage of an
implementation of the Abstract Transmission Optimization Feature
when sending the message (see <a href="#aof-sending"><b>2.4.1 Sending a message</b></a>). In
addition, it MUST follow the rules for relaying SOAP messages (see
<a href="#W3C.soap-part1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/soap12-part1/#relaysoapmsg">Relaying
SOAP Messages</a>).
</p>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
This section need to be revisited.
</td></tr></table>
</div>
<div class="div3">
<h4><a name="aof-intermed"></a>2.4.4 Binding Optimizations at Intermediaries</h4>
<p>
As described in <a href="#W3C.soap-part1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/soap12-part1/#relaysoapmsg">Relaying
SOAP Messages</a>, 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.
</p>
<p>
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.
In support of such cooperation, the inbound
binding MAY make available to the outbound
binding the received values of some or all
<a href="http://www.w3.org/TR/xpath-datamodel/#dm-type">dm:type</a> accessors.
</p>
<p>
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.
</p>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
This section need to be revisited.
</td></tr></table>
</div>
</div>
</div>
<div class="div1">
<h2 class="diff-del"><a name="inclusion-mechanism"></a>3. Inclusion Mechanism</h2>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
This whole section is removed as it has been replaced by the MIFFY
specification (ref?).
</td></tr></table>
</div>
<div class="div1">
<h2><a name="HTTP-implementation"></a>4. HTTP Transmission Optimization Feature</h2>
<div class="div2">
<h3><a name="httpof-introduction"></a>4.1 Introduction</h3>
<p class="diff-del">
The HTTP Transmission Optimization Feature is a binding-level feature
implementing the Abstract Transmission Optimization Feature in an
HTTP binding. This HTTP Transmission Optimization Feature uses the
<a href="#inclusion-mechanism"><b>3. Inclusion Mechanism</b></a> as the basis of its
implementation.
</p>
<p class="diff-add">
The HTTP Transmission Optimization Feature is a binding-level feature
implementing the Abstract Transmission Optimization Feature in an
HTTP binding. This HTTP Transmission Optimization Feature uses the
MIFFY format (ref?) as the basis of its implementation.
</p>
<p>
This HTTP Transmission Optimization Feature builds upon the current
HTTP binding (see <a href="#W3C.soap-part2">[SOAP Part 2]</a> <a href="http://www.w3.org/TR/soap12-part2/#soapinhttp">SOAP HTTP
Binding</a>), enhancing it with the support of the Abstract
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"></a>4.2 HTTP Transmission Optimization Feature Name</h3>
<p>
This HTTP Transmission Optimization Feature is identified by the URI:
</p>
<ul>
<li>
<p>
"http://www.w3.org/2003/06/soap/features/http-optimization".
</p>
</li>
</ul>
</div>
<div class="div2">
<h3><a name="httpof-implementation"></a>4.3 Implementation</h3>
<p class="diff-del">
The HTTP Transmission Optimization Feature uses the <a href="#inclusion-mechanism"><b>3. Inclusion Mechanism</b></a> for implementing the Abstract
Transmission Optimization Feature. It serializes the SOAP message
using the <b><a href="#">???</a></b> and puts the resulting
MIME Multipart/Related packaging in the HTTP body.
</p>
<p class="diff-add">
The HTTP Transmission Optimization Feature uses the MIFFY format
(ref?) for implementing the Abstract Transmission Optimization
Feature. The SOAP message is encapsulated in a MIME Multipart/Related
package following the rules of the MIFFY format and this MIME
Multipart/Related package is put into the HTTP body.
</p>
<div class="div3">
<h4><a name="httpof-sending"></a>4.3.1 Sending a SOAP message</h4>
<p class="diff-del">
When sending a SOAP message for which the Abstract Transmission
Optimization Feature is enabled, the HTTP Transmission Optimization
Feature optimizes the transmission of the message by serializing it
using the <b><a href="#">???</a></b>. Unless otherwise
stated, serializing a SOAP message infoset into the HTTP body MUST
be semantically equivalent to performing the following steps
separately, and in the order given.
</p>
<p class="diff-add">
When sending a SOAP message for which the Abstract Transmission
Optimization Feature is enabled, the HTTP Transmission Optimization
Feature optimizes the transmission of the message by serializing it
using the MIFFY format (ref?). Unless otherwise
stated, serializing a SOAP message infoset into the HTTP body MUST
be semantically equivalent to performing the following steps
separately, and in the order given.
</p>
<ol>
<li>
<p class="diff-chg">
Serialize the SOAP Message into a MIME Multipart/Related
packaging as described in the MIFFY format (ref?).
</p>
</li>
<li>
<p>
Serialize the MIME Multipart/Related packaging into the HTTP
body.
</p>
</li>
</ol>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
Should specify what to do for the content type.
</td></tr></table>
</div>
<div class="div3">
<h4><a name="httpof-receiving"></a>4.3.2 Receiving a SOAP message</h4>
<p>
When receiving a SOAP message using the HTTP Transmission
Optimization Feature, the HTTP binding MUST, at least logically,
provide access to the reconstructed SOAP message infoset.
</p>
<p>
The reconstruction of the SOAP message infoset from the data
contained in the HTTP Body MUST be semantically equivalent to
performing the following steps separately, and in the order given.
</p>
<ul>
<li>
<p>
Extract the MIME Multipart/Related packaging from the HTTP body.
</p>
</li>
<li>
<p class="diff-del">
Deserialize the SOAP message from the MIME Multipart/Related packaging as described in <b><a href="#">???</a></b>.
</p>
<p class="diff-add">
Deserialize the SOAP message from the MIME Multipart/Related packaging according to the rules of the MIFFY format (ref?).
</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="back">
<div class="div1">
<h2><a name="MappingInfosets"></a>A. Mapping between Infosets and Data Models</h2>
<table border="1" summary="Editorial note: HR"><tr><td width="50%" valign="top" align="left"><b>Editorial note: HR</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
This section should be revisited as XQDM appears only in the MIFFY
format.
</td></tr></table>
<p>
The SOAP Recommendation models message envelopes
as XML Infosets; this feature uses the XQuery 1.0 and
XPath 2.0 Data Model to augment the information available
in such Infosets with typing information, which is used
as the basis for optimization. This Appendix sets
out in detail the correspondence between SOAP Infosets
and SOAP data models, for purposes of implementation
of this feature.
</p>
<div class="div2">
<h3><a name="SenderDMMapping"></a>A.1 Infoset Mapping at Sending Nodes</h3>
<p>
The <a href="#DM">[XML Query Data Model]</a> provides a normative mapping from
the Post Schema Validation Infoset to a data model.
Except as specified here, that mapping is used to construct
data models from SOAP envelope infosets at a sending node.
The differences are as follows:
<ul>
<li>Neither SOAP nor this feature requires schema validation of messages
by sender or receiver. The means by which dm:type and dm:typed-value
are determined are at the discretion of the sending SOAP node,
except that the dm:typed-value must be consistent with
the dm:string-value for the assigned dm:type.
</li>
<li>
In the case where no type information is available, perhaps
because no schema validation was performed or because
no type was assigned by such validation, the conventions
described at
<a href="http://www.w3.org/TR/xpath-datamodel/#dm-type">dm:type</a>.
MUST be used to indicate that the type is indeterminate.
</li>
</ul>
<table border="1" summary="Editorial note: NRM"><tr><td width="50%" valign="top" align="left"><b>Editorial note: NRM</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">Should xdt:untypedAtomic be used for leaf nodes
with only text content? Seems preferable to me, but
for some reason the dm is looser.</td></tr></table>
</p>
</div>
<div class="div2">
<h3><a name="ReceiverDMMapping"></a>A.2 Infoset Mapping at Receiving Nodes</h3>
<p>
The <a href="#DM">[XML Query Data Model]</a> provides a normative mapping from
a Data Model to an Infoset.
That mapping is used to construct the SOAP envelope Infoset
at the receiver.
Note that this mapping makes use only of dm:string and
text node dm:children: in no case is the dm:type or
dm:typed-value used to construct the Infoset.
Thus, this mapping enforces the goal of this feature,
which is to use type information as a means of optimization,
but not to affect the semantics of SOAP processing.
</p>
</div>
</div>
<div class="div1">
<h2><a name="references"></a>B. References</h2>
<dl>
<dt class="label"><a name="W3C.soap-part1"></a>[SOAP Part 1] </dt><dd>W3C Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See <a href="http://www.w3.org/TR/soap12-part1/">http://www.w3.org/TR/soap12-part1/</a>.)</dd>
<dt class="label"><a name="W3C.soap-part2"></a>[SOAP Part 2] </dt><dd>W3C Recommendation "SOAP Version 1.2 Part 2: Adjuncts", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See <a href="http://www.w3.org/TR/soap12-part2/">http://www.w3.org/TR/soap12-part2/</a>.)</dd>
<dt class="label"><a name="W3C.soap-attachment"></a>[SOAP 1.2 Attachment Feature] </dt><dd>W3C Working Draft "SOAP 1.2 Attachment Feature", H. F. Nielsen, H. Ruellan, September 2002. (See <a href="http://www.w3.org/TR/soap12-af/">http://www.w3.org/TR/soap12-af/</a>.)</dd>
<dt class="label"><a name="W3C.soap-attachment-req"></a>[SOAP Attachment Requirements] </dt><dd>W3C Editors' copy "SOAP Attachment Feature Requirements", M. A. Jones, May 2003. (See <a href="http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html">http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html</a>.)</dd>
<dt class="label"><a name="XML"></a>[XML 1.0] </dt><dd>W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See <a href="http://www.w3.org/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>.)</dd>
<dt class="label"><a name="XMLNS"></a>[Namespaces in XML] </dt><dd>W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See <a href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a>.)</dd>
<dt class="label"><a name="XMLInfoSet"></a>[XML InfoSet] </dt><dd>W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See <a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024/">http://www.w3.org/TR/2001/REC-xml-infoset-20011024/</a>.)</dd>
<dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Part 1] </dt><dd>W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See <a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a>.)</dd>
<dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Part 2] </dt><dd>W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a>.)</dd>
<dt class="label"><a name="SchemaPart2Errata"></a>[XML Schema Part 2 Errata] </dt><dd>W3C Internal Working Draft 7 March 2003 Id: datatypes-with-errata.xml,v 1.5 2003/03/07 19:54:00 (See <a href="http://www.w3.org/XML/Group/2002/09/xmlschema-2/datatypes-with-errata.html">http://www.w3.org/XML/Group/2002/09/xmlschema-2/datatypes-with-errata.html</a>.)</dd>
<dt class="label"><a name="RFC2119"></a>[RFC 2119] </dt><dd>IETF "RFC 2119: Keywords for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.)</dd>
<dt class="label"><a name="RFC2387"></a>[RFC 2387] </dt><dd>IETF "The MIME Multipart/Related Content-type", E. Levinson, August 1998. (See <a href="http://www.ietf.org/rfc/rfc2387.txt">http://www.ietf.org/rfc/rfc2387.txt</a>.)</dd>
<dt class="label"><a name="PASWA"></a>[PASWA] </dt><dd>"Proposed Infoset Addendum to SOAP Messages with Attachments", April 2003. (See <a href="http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html">http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html</a>.)</dd>
<dt class="label"><a name="DM"></a>[XML Query Data Model] </dt><dd>"XQuery 1.0 and XPath 2.0 Data Model", April 2003. (See <a href="http://www.w3.org/TR/xpath-datamodel/">http://www.w3.org/TR/xpath-datamodel/</a>.)</dd>
</dl>
</div>
<div class="div1">
<h2><a name="changelog"></a>C. Change Log (Non-Normative)</h2>
<table border="1">
<caption>Table 2: Changes since first draft.</caption>
<thead>
<tr>
<th rowspan="1" colspan="1">Who</th>
<th rowspan="1" colspan="1">When</th>
<th rowspan="1" colspan="1">What</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20031124</td>
<td rowspan="1" colspan="1">Modify the specification to refer to the MIFFY format.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">NRM</td>
<td rowspan="1" colspan="1">20031008</td>
<td rowspan="1" colspan="1">Major change to convert to XQuery data model
formulation. Re-integrated text on optimization
through intermediaries, adding a few DM-related
sentences to the sections on intermediaries
and binding optimizations through intermediaries.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">NRM</td>
<td rowspan="1" colspan="1">20030917</td>
<td rowspan="1" colspan="1">Integrated new text on optimization
through intermediaries, which should close
issue 431.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030703</td>
<td rowspan="1" colspan="1">Changed <a href="#introduction"><b>1. Introduction</b></a> paragraph 2 to include Noah's text on hop-by-hop contract.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030703</td>
<td rowspan="1" colspan="1">Changed <b><a href="#">???</a></b> bullet 4 as per Gudge suggestion (ie "the content" of each eii). Changed bullet 3 in the same way.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030703</td>
<td rowspan="1" colspan="1">Added Introductory text from Jacek relating document to PASWA and telling about future inclusion of PASWA related stuff.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030701</td>
<td rowspan="1" colspan="1">Added relation with requirements document.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030630</td>
<td rowspan="1" colspan="1">Added an URI table as in other specs, and a Notational Convention section.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030630</td>
<td rowspan="1" colspan="1">Named properties with URIs.</td>
</tr> <tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030630</td>
<td rowspan="1" colspan="1">Put all eii and aii names in monospace.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030630</td>
<td rowspan="1" colspan="1">Corrected specific typos found by Tony Graham.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Split up HTTP implementation into an <a href="#inclusion-mechanism"><b>3. Inclusion Mechanism</b></a> and an <a href="#HTTP-implementation"><b>4. HTTP Transmission Optimization Feature</b></a> using this <a href="#inclusion-mechanism"><b>3. Inclusion Mechanism</b></a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Added a link to other specification section (<a href="#relations"><b>1.2 Relation to other specifications</b></a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Added a references section (<a href="#references"><b>B. References</b></a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Changed main title from "Optimization Mechanism" to "SOAP Message
Transmission Optimization Mechanism".</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Changed abstract feature name from "Abstract Optimization
Feature" to "Abstract Transmission Optimization Feature".</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Changed/removed all occurences of "Working Draft".</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030620</td>
<td rowspan="1" colspan="1">Removed all colored-diff marks.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Changed document's name from "Inclusion Mechanism" to "Optimization Mechanism", and changed abstract feature name and HTTP feature name.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Corrected typos and other editorial errors.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Added a publication date.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Added an abstract.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Improved general introduction (<a href="#introduction"><b>1. Introduction</b></a>).
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Changed the presentation of the processing rules in <a href="#aof-sending"><b>2.4.1 Sending a message</b></a>, <a href="#aof-receiving"><b>2.4.2 Receiving a message</b></a>.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Shortened aof-transmitting.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Improved HTTP implementation introduction (<a href="#httpof-introduction"><b>4.1 Introduction</b></a>).
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Added a description of the <code>Include</code> <em>element
information item</em> and of the <code>href</code>
<em>attribute information item</em>.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Changed the presentation for sending a SOAP message through the
HTTP binding.
</td>
</tr>
<tr>
<td rowspan="1" colspan="1">HR</td>
<td rowspan="1" colspan="1">20030618</td>
<td rowspan="1" colspan="1">
Improved the presentation for receiving a SOAP message through the
HTTP binding.
</td>
</tr>
</tbody>
</table>
</div>
</div>
</body></html>