SOAP Message Transmission Optimization Mechanism

W3C Working Draft 21 July 2003

This version:

http://www.w3.org/TR/2003/WD-soap12-mtom-20030721

Latest version:

http://www.w3.org/TR/soap12-mtom

Editors:

Noah Mendelsohn, IBM

Mark Nottingham, BEA

Hervé Ruellan, Canon

Abstract

This document describes an abstract feature and a concrete implementation of it for optimizing the transmission and/or wire format of SOAP messages.

Status of this Document

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.

This copy has edits proposed by Noah Mendelsohn. These include:

· Proposed resolution of action item relating to issue 432, specifically to indicate that our feature property must point to base64binary items, not just anything to be optimized. This does not deal with all aspects of 432, just the one I was given as an action item at the Sophia face to face meeting.

· A few other editorial changes that I propose to make in my role as an editor (I had prepared these in my working copy before I was assigned the action item on 432.) If anyone has objections to any of these non-432 edits, let me know and I’ll skip them…they have no official status.

Insertions are highlighted in blue like this, deletions are in red with strikethrough.

Noah

This is the first W3C Working Draft of the SOAP Message Transmission Optimization Mechanism document. It has been produced by the XML Protocol Working Group (WG), which is part of the Web Services Activity.

Discussion of this document takes place on the public xml-dist-app@w3.org mailing list (public archive) under the email communication rules in the XML Protocol Working Group Charter .

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

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 W3C technical reports can be found at http://www.w3.org/TR/.

Short Table of Contents

1. Introduction
2. Abstract Transmission Optimization Feature
3. Inclusion Mechanism
4. HTTP Transmission Optimization Feature
A. References
B. Change Log (Non-Normative)

1. Introduction
    1.1 Notational Conventions
    1.2 Relation to other specifications
2. Abstract Transmission Optimization Feature
    2.1 Introduction
    2.2 Abstract Transmission Optimization Feature Name
    2.3 Abstract Transmission Optimization Feature Properties
    2.4 Abstract Transmission Optimization Feature Processing
        2.4.1 Sending a message
        2.4.2 Receiving a message
        2.4.3 Transmitting a message
3. Inclusion Mechanism
    3.1 Introduction
    3.2 Inclusion element
        3.2.1 Include element
        3.2.2 href attribute
    3.3 MIME Multipart/Related Serialization
        3.3.1 Introduction
        3.3.2 Serialization of a SOAP message
        3.3.3 Deserializing a SOAP message
4. HTTP Transmission Optimization Feature
    4.1 Introduction
    4.2 HTTP Transmission Optimization Feature Name
    4.3 Implementation
        4.3.1 Sending a SOAP message
        4.3.2 Receiving a SOAP message

Appendices

A. References
B. Change Log (Non-Normative)

1. Introduction

The first part of this document (2. Abstract Transmission Optimization Feature) 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.

This Abstract Transmission Optimization Feature is intended to be implemented by SOAP protocol bindings, however nothing precludes implementation as a SOAP module.

The ~~usage of the~~ Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path, providing no normative convention for optimization of SOAP transmission through intermediaries. Additional specifications could in principle be written to provide for optimized multi-hop transmission based on the facilities provided herein, or in other ways that build on this specification (e.g. by providing for transparent passthrough of optimized messages).

The second part (3. Inclusion Mechanism) describes an Inclusion Mechanism implementing part of the Abstract Transmission Optimization Feature in a binding-independant way. The third part (4. HTTP Transmission Optimization Feature) describes a protocol binding based on the SOAP HTTP binding, but extended to use the Abstract Transmission Optimization feature ~~uses this Inclusion Mechanism for implementing the Abstract Transmission Optimization Feature for an HTTP binding.~~

This document ~~represents~~ describes a transmission optimization mechanism which was inspired by a similar mechanism in the PASWA document (see [PASWA]). The XML Protocols WG Workgroup plans to ~~work~~ consider later on the other parts of ~~that~~ the PASWA 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.

1.1 Notational Conventions

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 [RFC 2119].

This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see XML Infoset [XML InfoSet]).

Table 1: Prefixes and Namespaces used in this specification.
Prefix	Namespace	Notes
env	"http://www.w3.org/2003/05/soap-envelope"	A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the "http://www.w3.org/2003/05/soap-envelope" namespace can be found at http://www.w3.org/2003/05/soap-envelope.
xbinc	"http://www.w3.org/2003/06/soap/features/binary-inclusion"	The namespace of the 3. Inclusion Mechanism.

1.2 Relation to other specifications

This specification has currently no well-defined relation with the [SOAP 1.2 Attachment Feature] specification. However, it may be expected that this specification will supersede the [SOAP 1.2 Attachment Feature] specification once this specification has reached a stable state.

Even if this specification does not target specificaly attachments to a SOAP message, it is expected that it will fulfill all attachment feature requirements described in [SOAP 1.2 Attachment Feature].

The implementation of the abstract feature as a binding feature for an HTTP binding is intended to enhance the SOAP HTTP binding described in [SOAP Part 2] SOAP HTTP Binding or an updated version of it.

This specification provides specifically for the optimized transmission of elements with content known to be in the form of a canonical lexical representation of the base64binary datatype, as described in

This document has been produced in conjunction with the development of requirements, embodied in the requirements document [SOAP Attachment Requirements]. 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.

2. Abstract Transmission Optimization Feature

2.1 Introduction

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.

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.

2.2 Abstract Transmission Optimization Feature Name

This Abstract Transmission Optimization Feature is identified by the URI:

· "http://www.w3.org/2003/06/soap/features/abstract-optimization".

2.3 Abstract Transmission Optimization Feature Properties

The Abstract Transmission Optimization Feature defines the set of properties described in Table 2.

Table 2: Property definitions for the Abstract Transmission Optimization Feature
Property Name	Property Description
`http://www.w3.org/2003/06/soap/features/abstract-optimization/Base64BinaryOptimizationCandidates`	A list containing zero or more (pointers to) element information items within the SOAP envelope. These are identified as candidates for ~~being transmitted in an optimized way~~optimized transmission. All [children] of such candidate elements MUST be [character information items]; the string represented by the children of each candidate element, taken in sequence, MUST represent a legal canonical lexical form for the XML Schema base64Binary datatype, as described in [XML Schema Part 2]. The manner in ~~which such~~element identifications is are represented in the node is at the discretion of the implementation.

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

Editorial note: HR
Does "enabling" an Abstract Feature make sense for a SOAP node? If this is not the case, another property should be created for reflecting the fact that the Abstract Transmission Optimization Feature is enabled or not.

Editorial note: HR per Noah's remark
Do we allow the optimization of only base64 binary content or do we allow to generalize the `http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates` as a list of (type, node) pairs? This would allow for binary transmission of integers, floats, and so on. The decision to limit the property to base64 binary items is tentative, pending analysis of the

2.4 Abstract Transmission Optimization Feature Processing

2.4.1 Sending a message

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 http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property.

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

The XML Schema Recommendation provides for datatypes such as base64Binary a lexical character form corresponding to each abstract value. For each value, there is exactly one canonical lexical form. One means of optimization for listed elements is thus to transmit a compact representation of the value as opposed to the character form of the element. The lexical forms can in all cases be reconstrcuted unambiguously from representations of the values.

In addition, the SOAP node binding MAY optimize the transmission of other SOAP message element information items not listed in the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/ Base64BinaryOptimizationCandidates OptimizationCandidates property. In particular, if the http://www.w3.org/2003/06/soap/features/abstract-optimization/ Base64BinaryOptimizationCandidates OptimizationCandidates property is not defined or if it has an empty value, the SOAP node binding MAY optimize the transmission of any SOAP message element information item, however the means of optimization for such additional items are beyond the scope of this specification (for example, the binding may discover that an element not listed has, in some particular message instance, to have content which corresponds to the canonical form of some base64Binary value (perhaps because the element is indeed of that type, or perhaps coincidentally…in either case optimization may in principle be applied, but such optimization of unlisted values is beyond the normative scope of this specification.) .

Editorial note: HR
Do we allow the optimization of the `Envelope` , `Header` , `Body` element information items, or of a full Header Block?

Editorial note: HR
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).

2.4.2 Receiving a message

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.

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node binding MUST be capable of reconstructing the original SOAP message infoset. However, 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 the Infoset.

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

Editorial note: HR

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

2.4.3 Transmitting a message

The usage of the Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path. Therefore, no specific rules exist for a SOAP intermediary ~~implementing~~ relaying a message using the Abstract Transmission Optimization Feature.

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 2.4.2 Receiving a message) and those related to the usage of an implementation of the Abstract Transmission Optimization Feature when sending the message (see 2.4.1 Sending a message). In addition, it MUST follow the rules for relaying SOAP messages (see [SOAP Part 1] Relaying SOAP Messages).

3. Inclusion Mechanism

3.1 Introduction

The Inclusion Mechanism expands upon the Abstract Transmission Optimization Feature by describing parts of an implementation of this feature. Use of this inclusion mechanism is optional; protocol binding specifications MAY implement the Abstract Transmission Optimization Feature using this Inclusion mechanism, or MAY implement the feature using other means. This specification does not describe a full protocol binding implementation but ~~is intended to provide support for building a full implementation of the Abstract Transmission Optimization Feature~~rather provides a building block useable in the creation of such binding specifications. ~~In particular, this specification does not specify the use of any transport for the SOAP message.~~ A ~~full~~ particular binding ~~implementation~~ ~~based on this specification~~that does use the inclusion mechanism is describe in 4. HTTP Transmission Optimization Feature.

The Inclusion Mechanism is divided into two parts, the first one describing an xbinc:Include element information item for including external data of any type in an XML Infoset or document.

The second part describes a serialization of a SOAP message optimized for transmission. This serialization uses the xbinc:Include element information item and a MIME Multipart/Related ([RFC 2387]) packaging for encapsulating the SOAP message.

3.2 Inclusion element

3.2.1 Include element

The xbinc:Include element information item is used for logically including generic data into an XML infoset. The full XML infoset can be build by replacing the xbinc:Include element information item by the base64 encoded value of the data referred to in the href attribute information item.

The xbinc:Include element information item has:

· A [local name] of Include .

· A [namespace name] of "http://www.w3.org/2003/06/soap/features/binary-inclusion".

· Zero element information item in its [children] property.

· One or more attribute information items in its [attributes] property. Among these MUST be the following:

o href attribute information item (see 3.2.2 href attribute).

3.2.2 href attribute

The href attribute information item is used to refer to the external data logically included by the xbinc:Include element information item containing it.

The href attribute information item has the following XML infoset properties:

· A [local name] of href .

· A [namespace name] which has no value.

· A [specified] property with a value of "true".

The type of the href attribute information item is xs:anyURI. The value of the href attribute information item is a URI that refers to the data logically included by the xbinc:Include element information item containing it.

3.3 MIME Multipart/Related Serialization

3.3.1 Introduction

The MIME Multipart/Related serialization provides part of an implementation of the Abstract Transmission Optimization Feature by describing how to serialize a SOAP infoset in an optimized way inside a MIME Multipart/Related packaging. This serialization uses the 3.2 Inclusion element element for linking the main SOAP message with element information items serialized in a compact form.

3.3.2 Serialization of a SOAP message

For transmitting a SOAP message for which the Abstract Transmission Optimization Feature is enabled, the MIME Multipart/Related serialization helps optimizing the transmission of the message by allowing to transmit in a compact form parts of the SOAP message. The SOAP message is serialized into a MIME Multipart/Related ([RFC 2387]) packaging: one body part, the root, containing an XML representation of the SOAP envelope, modified to use xbinc:include elements in place of each optimized data item, while other body parts contain the optimized parts ~~of the SOAP message transmitted in a compact form~~ for reference by the xbinc:includes.

Unless otherwise stated, serializing a SOAP message infoset with the MIME Multipart/Related serialization MUST be semantically equivalent to performing the following steps separately, and in the order given.

1. Create a MIME Multipart/Related packaging.

2. Create a list of the element information items whose transmission is to be optimized. This list SHOULD contain all the element information items of the SOAP message pointed to in the http://www.w3.org/2003/06/soap/features/abstract-optimization/ Base64BinaryOptimizationCandidates OptimizationCandidates property. This list MAY contain other element information items of the SOAP message.

3. Add a serialization of the content of ~~each~~ zero or more element information items in from the list in a body part of the MIME Multipart/Related packaging. The serialization should consist of the binary representation of the value corresponding to the lexical form represented by the sequence of character information item children of the listed element.

Editorial note: HR
How do we set the Content-type?
Editorial note: NRM
What sort of fault or error occurs if one or more of the lexical forms is not a canonical binary?

4. Modify the SOAP message infoset by replacing the content of each element information item ~~in the list by an~~processed in step 3 with an xbinc:Include element information item referring to the body part of the MIME Multipart/Related packaging containing its serialization.

5. Serialize the resulting SOAP message infoset, using XML 1.0, in the root object of the MIME Multipart/Related packaging.

Editorial note: HR
Do we allow only an XML 1.0 serialization?

3.3.3 Deserializing a SOAP message

As described in section 2.4.2, a SOAP receiver ~~When receiving a SOAP message using the MIME Multipart/Related serialization, deserializing~~ MUST~~, at least logically,~~ provide access to the reconstructed SOAP message infoset.

The reconstruction of the SOAP message infoset from the data contained in the MIME Multipart/Related packaging MUST be semantically equivalent to performing the following steps separately, and in the order given.

· Extract the SOAP message from the root object of the MIME Multipart/Related packaging and deserialize it to an infoset representation.

· Extract and construct a deserialization of e each other body part of the MIME Multipart/Related packaging. The deserialization must reconstruct the character sequence that was originally encoded (if the binary encoded suggested above is used, then the character sequence will be the canonical form correpsonding to the binary data carried in the part.)

· Find every xbinc:Include element information item in the SOAP message infoset.

For each xbinc:Include element information item, find the body part of the MIME Multipart/Related packaging which is referred to by the href attribute information item of the xbinc:Include element information item. ~~Replace the~~ xbinc:Include ~~element information item~~ ~~by the base64-encoded value of the referred to body part.~~ Replace the xbinc:Include element with the deserialization of the corresponding part.

When reconstructing a SOAP message infoset, the implementation:

· SHOULD generate an "env:Sender" SOAP fault with a subcode of xbinc:MissingHRef if an xbinc:Include element information item does not contain a href attribute information item.

· SHOULD generate an "env:Sender" SOAP fault with a subcode of xbinc:NotFoundHRef if no body part of the MIME Multipart/Related packaging matches the href attribute information item of an xbinc:Include element information item.

As described in section 2.4.2, implementations MAY limit infoset reconstuction to those information items actually required for processing by a particular node.

4. HTTP Transmission Optimization Feature

4.1 Introduction

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 3. Inclusion Mechanism as the basis of its implementation.

This HTTP Transmission Optimization Feature builds upon the ~~current~~ SOAP 1.2 HTTP binding (see [SOAP Part 2] SOAP HTTP Binding), 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.~~ All behavior of the SOAP 1.2 HTTP binding is retained, except as specifically indicated below.

4.2 HTTP Transmission Optimization Feature Name

This HTTP Transmission Optimization Feature is identified by the URI:

· "http://www.w3.org/2003/06/soap/features/http-optimization".

4.3 Implementation

The HTTP Transmission Optimization Feature uses the 3. Inclusion Mechanism for implementing the Abstract Transmission Optimization Feature. It serializes the SOAP message using the 3.3.2 Serialization of a SOAP message and puts the resulting MIME Multipart/Related packaging in the HTTP body.

4.3.1 Sending a SOAP message

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 3.3.2 Serialization of a SOAP message. 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.

1. Serialize the SOAP Message into a MIME Multipart/Related packaging as described in 3.3.2 Serialization of a SOAP message.

2. Serialize the MIME Multipart/Related packaging into the HTTP body.

3. Content type?

4.3.2 Receiving a SOAP message

How do we recognize new and old form…does the new binding only understand multipart related? Is there a new media type?

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.

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.

· Extract the MIME Multipart/Related packaging from the HTTP body.

· Deserialize the SOAP message from the MIME Multipart/Related packaging as described in 3.3.3 Deserializing a SOAP message.

A. References

[SOAP Part 1]

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 http://www.w3.org/TR/soap12-part1/.)

[SOAP Part 2]

W3C Recommendation "SOAP Version 1.2 Part 2: Adjuncts", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See http://www.w3.org/TR/soap12-part2/.)

[SOAP 1.2 Attachment Feature]

W3C Working Draft "SOAP 1.2 Attachment Feature", H. F. Nielsen, H. Ruellan, September 2002. (See http://www.w3.org/TR/soap12-af/.)

[SOAP Attachment Requirements]

W3C Editors' copy "SOAP Attachment Feature Requirements", M. A. Jones, May 2003. (See http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html.)

[XML 1.0]

W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.)

[Namespaces in XML]

W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

[XML InfoSet]

W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)

[XML Schema Part 1]

W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)

[XML Schema Part 2]

W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)

[RFC 2119]

IETF "RFC 2119: Keywords for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)

[RFC 2387]

IETF "The MIME Multipart/Related Content-type", E. Levinson, August 1998. (See http://www.ietf.org/rfc/rfc2387.txt.)

[PASWA]

"Proposed Infoset Addendum to SOAP Messages with Attachments", April 2003. (See http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.)

B. Change Log (Non-Normative)

Table 3: Changes since first draft.
Who	When	What
HR	20030703	Changed 1. Introduction paragraph 2 to include Noah's text on hop-by-hop contract.
HR	20030703	Changed 3.3.2 Serialization of a SOAP message bullet 4 as per Gudge suggestion (ie "the content" of each eii). Changed bullet 3 in the same way.
HR	20030703	Added Introductory text from Jacek relating document to PASWA and telling about future inclusion of PASWA related stuff.
HR	20030701	Added relation with requirements document.
HR	20030630	Added an URI table as in other specs, and a Notational Convention section.
HR	20030630	Named properties with URIs.
HR	20030630	Put all eii and aii names in monospace.
HR	20030630	Corrected specific typos found by Tony Graham.
HR	20030620	Split up HTTP implementation into an 3. Inclusion Mechanism and an 4. HTTP Transmission Optimization Feature using this 3. Inclusion Mechanism
HR	20030620	Added a link to other specification section (1.2 Relation to other specifications).
HR	20030620	Added a references section (A. References).
HR	20030620	Changed main title from "Optimization Mechanism" to "SOAP Message Transmission Optimization Mechanism".
HR	20030620	Changed abstract feature name from "Abstract Optimization Feature" to "Abstract Transmission Optimization Feature".
HR	20030620	Changed/removed all occurences of "Working Draft".
HR	20030620	Removed all colored-diff marks.
HR	20030618	Changed document's name from "Inclusion Mechanism" to "Optimization Mechanism", and changed abstract feature name and HTTP feature name.
HR	20030618	Corrected typos and other editorial errors.
HR	20030618	Added a publication date.
HR	20030618	Added an abstract.
HR	20030618	Improved general introduction (1. Introduction).
HR	20030618	Changed the presentation of the processing rules in 2.4.1 Sending a message, 2.4.2 Receiving a message.
HR	20030618	Shortened 2.4.3 Transmitting a message.
HR	20030618	Improved HTTP implementation introduction (4.1 Introduction).
HR	20030618	Added a description of the `Include` element information item and of the `href` attribute information item.
HR	20030618	Changed the presentation for sending a SOAP message through the HTTP binding.
HR	20030618	Improved the presentation for receiving a SOAP message through the HTTP binding.