W3C

SOAP Message Transmission Optimization Mechanism

W3C Working Draft 09 February 2004

This version:
http://www.w3.org/TR/2004/WD-soap12-mtom-20040209/
Latest version:
http://www.w3.org/TR/soap12-mtom/
Previous versions:
http://www.w3.org/TR/2003/WD-soap12-mtom-20030721/
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. The concrete implementation relies on the [XOP] format for carrying 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. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the second W3C Working Draft of the SOAP Message Transmission Optimization Mechanism specification. It has been produced by the XML Protocol Working Group (WG), which is a 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 .

Comments on this document are welcome. Send them to xmlp-comments@w3.org mailing list (public archive). Note that all resolved and outstanding issues against this document are documented in the Working Group's Issues List.

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

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.


Short Table of Contents

1. Introduction
2. Abstract Transmission Optimization Feature
3. An Optimized MIME Multipart Serialization of SOAP Messages
4. HTTP Transmission Optimization Feature
A. References
B. Change Log (Non-Normative)


Table of Contents

1. Introduction
    1.1 Notational Conventions
    1.2 Relation to other specifications
        1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0 Data Model
        1.2.2 Relationship to the SOAP Processing model
2. Abstract Transmission Optimization Feature
    2.1 Introduction
    2.2 Abstract Transmission Optimization Feature Name
    2.3 Abstract Transmission Optimization Feature Processing
        2.3.1 Sending a message
        2.3.2 Receiving a message
        2.3.3 Intermediaries
        2.3.4 Binding Optimizations at Intermediaries
3. An Optimized MIME Multipart Serialization of SOAP Messages
    3.1 Introduction
    3.2 Serialization of a SOAP message
    3.3 Deserialization of 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.1.1 Init
        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 ([SOAP Part 1]) by selectively encoding portions of the message, while still presenting an XML Infoset to the SOAP application.

Unlike SOAP itself, which is defined in terms of XML Infosets [XML InfoSet], this feature models message envelopes using the XQuery 1.0 and XPath 2.0 Data Model [XML Query Data Model], 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 Data Model: the changes needed to this specification should be straightforward, and the optimizations provided herein should be easy to generalize for such use.

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 pass-through of optimized data contained within headers or bodies relayed by an intermediary (see 2.3.4 Binding Optimizations at Intermediaries). Additional specifications might also be written to provide for other optimized multi-hop capabilities, perhaps building on the mechanisms provided herein.

The second part (3. An Optimized MIME Multipart Serialization of SOAP Messages) describes an Optimized MIME Multipart Serialization of SOAP Messages implementing the Abstract Transmission Optimization Feature in a binding independent way. This implementation relies on the [XOP] format.

The third part (4. HTTP Transmission Optimization Feature) uses this Optimized MIME Multipart Serialization of SOAP Messages for describing an implementation of the Abstract Transmission Optimization Feature for the SOAP 1.2 HTTP binding (see [SOAP Part 2] 7. SOAP HTTP Binding).

Editorial note: HR 
Request for comments: this document uses the [XML Query Data Model]. Readers are invited to comment our use of this Data Model.
Editorial note: HR 
Request for comments: currently all level of MTOM (2. Abstract Transmission Optimization Feature, 3. An Optimized MIME Multipart Serialization of SOAP Messages and 4. HTTP Transmission Optimization Feature) and XOP support only the optimization of Element Nodes with base64-encoded content in canonical form. Does it make sense?

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
dm Not bound to any namespace.
Consistent with [XML Query Data Model], this prefix is used to qualify accessor names in the XQuery 1.0 and XPath 2.0 Data Model.
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.
xop "http://www.w3.org/2003/12/xop/include"
A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the "http://www.w3.org/2003/12/xop/include" namespace can be found at http://www.w3.org/2000/xp/Group/4/01/MTOM-WD/include.xsd.
xdt "http://www.w3.org/2003/05/xpath-datatypes"
The namespace of the XPath data types (see [XML Query Data Model], New Datatypes).
xs "http://www.w3.org/2001/XMLSchema"
The namespace of XML Schema data types (see [XML Schema Part 2]).
Editorial note: HR 
Change xop schema location.

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 been widely deployed.

Although not specifically implementing an "attachment" abstraction, this specification is intended to fulfill all attachment feature requirements described in [SOAP 1.2 Attachment Feature].

Editorial note: HR 
Those two paragraphs should be changed/removed when relation with the SOAP 1.2 Attachment Feature is made clear.

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] 7. SOAP HTTP Binding or an updated version of it.

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.

Editorial note: Noah 
We should check requirements and revise this paragraph in going to last call.

1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0 Data Model

The SOAP Recommendation ([SOAP Part 1] and [SOAP Part 2]) provides for processing of SOAP "envelopes", which are modeled as XML Information Sets ([XML InfoSet]). Such Infosets capture the tree structure, the names of the elements, the character content of elements and attributes, and so on. The Infoset does not model schema data types, such as integer, and thus provides no association between character strings and values. Schema validation is not in general required for processing of SOAP messages.

The purpose of the feature described in this document is to optimize the transmission of SOAP envelopes by relying on type information that may be available to the sender. This feature does not specify any particular means by which such type information is to be determined: schema validation is one possibility, but senders MAY determine or establish types using other means. Type information need be provided only for Element Nodes that are to be optimized.

Unlike the Infoset, the XQuery 1.0 and XPath 2.0 Data Model ([XML Query Data Model], hereinafter referred to as the "Data Model") provides a model that carries type and value space information for each element and attribute. Accordingly, the feature described in this document and its implementations are expressed in terms of that Data Model. A precondition for use of this feature is therefore availability of a Data Model for the message to be transmitted. Details of the correspondence between SOAP Infosets and Data Models are provided in [XOP] A. Mapping between Infosets and Data Models. The Data Model introduces properties and accessors such as dm:string-value , dm:type and dm:typed-value , which are used in this specification.

Editorial note: HR 
Note: the [XML Query Data Model] uses the terms "accessor" and "property" for closely related concepts. For example the documentation of the dm:type accessor for the Element Node says "Returns the value of the type property". In this WD, we use both the accessor and property terminology. We expect to work with the XML Query Working Group to converge on the appropriate use of Data Model terminology in future releases of this specification.

The SOAP envelope does not in general convey schema type information, and the purpose of this feature is to optimize but not otherwise change the SOAP processing model. Accordingly, as described in 2.3.2 Receiving a message, the feature described in this document and its implementations does not require that the type property or the return value of the dm:typed-value accessor be reconstructed at a receiving node. This feature thus implements a "lossy" model, in which type information available to the sender may be used for purposes of optimization, but need not in general be provided to the receiver (except insofar as necessary in the binding to implement the optimization). The envelope Data Models at sender and receiver are therefore identical in overall structure, dm:string-value accessor return value, and children property value, but not necessarily with respect to type property value and dm:typed-value accessor return value.

1.2.2 Relationship to the SOAP Processing model

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 2.3.1 Sending a message and 2.3.2 Receiving a message, there is in all cases an untyped XML 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 as described in 2.3.2 Receiving a message, SOAP processing is performed on received Infosets in the manner prescribed by the SOAP Recommendation.

2. Abstract Transmission Optimization Feature

Editorial note: HR 
Request for comments: readers are invited to send feedback about this 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 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 xs:base64Binary data type (see [XML Schema Part 2] 3.2.16 base64Binary and Errata in XML Schema, E2-54).

Note: because there is a one-to-one correspondence between such canonical forms and values in the value space of xs:base64Binary , 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.

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.

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 Processing

2.3.1 Sending a message

To send a SOAP message using the Abstract Transmission Optimization Feature, a SOAP application MUST generate a Data Model corresponding to the SOAP Envelope Insoset in the manner specified in [XOP] A.1 XOP Infoset to Data Model Mapping.

When this feature is used in combination with the SOAP Request-Response Message Exchange Pattern ([SOAP Part 2] 6.2 SOAP Request-Response Message Exchange Pattern) or the SOAP Response Message Exchange Pattern ([SOAP Part 2] 6.3 SOAP Response Message Exchange Pattern), the http://www.w3.org/2003/05/soap/mep/OutboundMessage property is the Infoset derived from the Original Data Model as described in [XOP] A.2 XOP Data Model to Infoset Mapping. Similar rules should be applied for other MEPs, as appropriate.

Editorial note: HR 
Is the reference to XOP correct? Should we change it to a direct DM reference (and which)?

Implementations of this feature are likely to optimize a set of Element Nodes of the SOAP message and may use the value of the type property to determine how to optimize the Element Nodes.

One purpose of the Abstract Transmission Optimization Feature is to optimize the transmission of base64 encoded data. To be optimized, an Element Node whose content consists of base64 encoded data MUST have a type property value of xs:base64Binary and the return value for its dm:string-value accessor MUST be a canonical lexical form of that type (see [XML Schema Part 2] 3.2.16 base64Binary and Errata in XML Schema, E2-54).

Editorial note: HR 
Need to change this reference to XML Schema second edition, 3.2.16 when available.

Note: the means of identifying Nodes in canonical lexical form are implementation-dependent. Some implementations can identify such Nodes by construction (e.g., because a certain API may create only canonical forms); others may check the characters prior to sending; yet others may observe a convention of setting the type property to xs:base64Binary in MTOM Data Models only when the data is known to be canonical. Because of the need to exactly preserve the characters in the transmitted Infoset, non-canonical representations MUST NOT be optimized.

2.3.2 Receiving a message

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node SHOULD 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 reconstruct the transmitted Data Model, with the following rules:

The receiving node MUST reconstruct from the Data Model an Envelope Infoset, as described in [XOP] A.2 XOP Data Model to Infoset Mapping; the receiving node MUST then perform SOAP processing on the reconstructed Infoset (see [SOAP Part 1] 2. SOAP Processing Model). In all cases, the received Infoset MUST be exactly the same as that transmitted by the sender. Receivers MUST NOT, for example, convert non-canonical lexical representations to canonical.

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 .

When this feature is used in combination with the SOAP Request-Response Message Exchange Pattern ([SOAP Part 2] 6.2 SOAP Request-Response Message Exchange Pattern) or the SOAP Response Message Exchange Pattern ([SOAP Part 2] 6.3 SOAP Response Message Exchange Pattern), the Infoset contained in the http://www.w3.org/2003/05/soap/mep/InboundMessage property is derived from the Data Model as described in [XOP] A.2 XOP Data Model to Infoset Mapping. Similar rules should be applied for other MEPs, as appropriate.

Note: applications may perform schema validation or other processing that might create Data Models with more specific type information than that provided herein, but this feature does not provide for the reconstruction of type information based on type property values provided by the sender.

2.3.3 Intermediaries

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. The section 2.3.4 Binding Optimizations at Intermediaries details the means by which certain optimizations can be performed by bindings at intermediaries. Note that the type property 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 the type property are not in general preserved when relaying through an intermediary.

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.3.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.3.1 Sending a message). In addition, it MUST follow the rules for relaying SOAP messages (see [SOAP Part 1] 2.7 Relaying SOAP Messages).

2.3.4 Binding Optimizations at Intermediaries

As described in [SOAP Part 1] 2.7 Relaying SOAP Messages, 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.

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 type properties.

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 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.

3. An Optimized MIME Multipart Serialization of SOAP Messages

3.1 Introduction

The Optimized MIME Multipart Serialization expands upon the Abstract Transmission Optimization Feature by describing parts of an implementation of this feature using the [XOP] 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 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 4.2 HTTP Transmission Optimization Feature Name.

The Optimized MIME Multipart 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 [XOP] format and a MIME Multipart/Related packaging ([RFC 2387]). Specifically, it is assumed that a Data Model has been prepared for the SOAP envelope as described in 2.3.1 Sending a message. For use with this serialization, the type property MUST be set to xs:base64Binary only for those Element Nodes known to be in the canonical lexical form for that type. The type property for all other Element Nodes MUST be set to xdt:untypedAny .

3.2 Serialization of a SOAP message

When sending a SOAP message using the MIME Multipart Serialization, the SOAP message Data Model is serialized as specified in [XOP] 4.1 Creating XOP packages. The result is a MIME Multipart/Related ([RFC 2387]) package: 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, i.e., those whose type property is xs:base64Binary .

3.3 Deserialization of a SOAP message

When receiving a SOAP message using this Optimized MIME Multipart Serialization, the SOAP Envelope Data Model is reconstructed from the XOP MIME Multipart/Related package by performing the processing specified in [XOP] 4.2 Interpreting XOP packages. From the Data Model, a SOAP Envelope Infoset is reconstructed as described in 2.3.2 Receiving a message.

Editorial note: HR 
I think we should add somewhere what to do if the reconstruction of the Data Model or of the Infoset fails. Probably we should fault.

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. The basis of this HTTP Transmission Optimization Feature is the Optimized MIME Multipart Serialization described in 3. An Optimized MIME Multipart Serialization of SOAP Messages.

This HTTP Transmission Optimization Feature builds upon the current HTTP binding (see [SOAP Part 2] 7. 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.

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 Optimized MIME Multipart Serialization (see 3. An Optimized MIME Multipart Serialization of SOAP Messages) for implementing the Abstract Transmission Optimization Feature. On the sending side, this feature serializes the SOAP message as described in 3.2 Serialization of a SOAP message and puts the resulting MIME Multipart/Related package in the HTTP body. On the receiving side, this feature extracts the MIME Multipart/Related package from the HTTP body and deserializes as described in 3.3 Deserialization of a SOAP message.

4.3.1 Sending a SOAP message

When sending a SOAP message, the HTTP Transmission Optimization Feature changes the behavior of [SOAP Part 2] 7. SOAP HTTP Binding. This section describes the perturbations to [SOAP Part 2] 7.5.1 Behavior of Requesting SOAP Node that result from use of the HTTP 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.

4.3.1.1 Init

In the "Init" state, a HTTP request is formulated and transmission of the request is initiated. When using the HTTP Transmission Optimization Feature, the formulation of the request differs from [SOAP Part 2] 7.5.1.1 as shown in Table 2.

Table 2: HTTP Request Fields
Field Value
Content-Type header field mime/multipart-related
HTTP entity body SOAP message serialized as described in 3.2 Serialization of a SOAP message

The XOP package is constructed as described in 3. An Optimized MIME Multipart Serialization of SOAP Messages with the following restriction:

  • Each optimized Node MUST generate exactly one extracted binary part in the resulting package, i.e., extracted binary parts MUST NOT be referenced with more than one xop:Include in the SOAP message part.

Note: this does not preclude the MIME Multipart/Related package from including additional parts not referenced with a xop:Include . Such additional parts are not part of the SOAP message Infoset and are not included in the SOAP processing model.

Implementations of this binding MUST enforce the restriction that XOP is not to be used with Data Models that contain Element Nodes of name xop:Include (see [XOP] 3. XOP Data Models Constructs). In any case where a SOAP envelope containing such a Node is to be sent, the binding MUST do one of the following:

  • Fall back to use the application/soap+xml media type or any other suitable media type, i.e., send the SOAP envelope without using the HTTP Transmission Optimization Feature.
  • Generate a binding-dependent SOAP fault.

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.

4.3.2 Receiving a SOAP message

When receiving a SOAP message, the HTTP Transmission Optimization Feature changes the behavior of [SOAP Part 2] 7. SOAP HTTP Binding. This section describes the perturbations to [SOAP Part 2] 7.5.2 Behavior of Responding SOAP Node that result from use of the HTTP 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.

When making an abstraction of the request message available in http://www.w3.org/2003/05/soap/mep/InboundMessage , the HTTP Binding MUST reconstruct the SOAP Envelope Infoset as described in 3.3 Deserialization of a SOAP message.

Editorial note: HR 
There is an open issue about how to recognize a message serialized using XOP.

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/2003/REC-soap12-part1-20030624/.)
[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/2003/REC-soap12-part2-20030624/.)
[XOP]
W3C Working Draft "XML-binary Optimized Packaging", N. Mendelsohn, M. Nottingham, H. Ruellan, February 2004. (See http://www.w3.org/TR/2004/WD-xop10-20040209/.)
[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/2002/WD-soap12-af-20020924/.)
[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/.)
[XML Schema Part 2 Errata]
W3C Internal Working Draft 7 March 2003 Id: datatypes-with-errata.xml,v 1.5 2003/03/07 19:54:00 (See http://www.w3.org/XML/Group/2002/09/xmlschema-2/datatypes-with-errata.html.)
[XML Query Data Model]
"XQuery 1.0 and XPath 2.0 Data Model", Mary Fernández, Ashok Malhotra, Jonathan Marsh, Marton Nagy, Norman Walsh, November 2003. (See http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/.)
[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 20040129 Changed link to XOP from editor's copy to WD.
HR 20040129 Changed include.xsd location.
HR 20040129 Added text in 4.3.1.1 about xop:Include elements present in the Data Model to optimize.
HR 20040129 Added ednote in 1.2.1.
HR 20040129 Remove Ednotes in 2.3, 2.3.3 and 3.1.
HR 20040127 Added request for comments on xmlp-comments@w3c.org.
HR 20040126 Misc editorial changes.
HR 20040126 Corrected usage of Data Model terms.
HR 20040122 Typos, links and other details corrected.
HR 20040122 Added ednote for comments on Abstract Feature.
HR 20040122 Added Noah's comments (http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Jan/0040.html).
HR 20040122 Added text from Jacek action (http://lists.w3.org/Archives/Public/xml-dist-app/2004Jan/0019.html).
HR 20040121 Changed MIFFY to XOP. Added a reference to XOP specification.
HR 20040109 Added request for comments on use of the XQuery DM.
HR 20040109 Included MarcH's proposal (http://lists.w3.org/Archives/Public/xml-dist-app/2003Dec/0014.html) for 4.3.1 into MTOM spec. Extended this approach for 4.3.2
HR 20040108 Reformatted Table 1.
HR 20040108 Added reference to miffy:Include dm:type schema from MTOM doc.
HR 20031215 Changed "re-encoding" to "encoding" in 2.1 (WG decision) and 1 (for coherency.
HR 20031210 Added ednote about how to recognize a MIFFY message in section 4.3.2.
HR 20031210 Changed back in section 4 (HTTP Transmission Optimization Feature) all references to Miffy to references to section 3.
HR 20031210 Recreated section 3 from content of old section 3.3. Updated old content refer to MIFFY.
HR 20031209 Started rewriting section 2.3 (was section 2.4) Abstract Transmission Optimization Feature Processing.
HR 20031209 Completely removed ex-section 2.3 Abstract Transmission Optimization Feature Properties according to f2f resolution.
HR 20031209 Removed color changes from section 2.1 according to f2f resolution.
HR 20031209 Removed ednote in Section 1.2.2 according to f2f resolution.
HR 20031209 Reinserted Section 1.2.1 according to f2f resolution. Done some editorial work in this section. Added ednote to check validity of last paragraph.
HR 20031209 Updated Section 1.2 according to f2f resolution: added ednotes for reminding some checking was needed.
HR 20031209 Reinserted description of the Inclusion Mechanism in Section 1. Updated description of the HTTP Transmission Optimization Feature in Section 1.
HR 20031209 Updated Section 1 according to f2f resolution: dropped second paragraph, reinserted third paragraph.
HR 20031124 Modified the specification to refer to the MIFFY format.
NRM 20031008 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.
NRM 20030917 Integrated new text on optimization through intermediaries, which should close issue 431.
HR 20030703 Changed 1. Introduction paragraph 2 to include Noah's text on hop-by-hop contract.
HR 20030703 Changed 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. An Optimized MIME Multipart Serialization of SOAP Messages and an 4. HTTP Transmission Optimization Feature using this 3. An Optimized MIME Multipart Serialization of SOAP Messages
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 occurrences 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.3.1 Sending a message, 2.3.2 Receiving a message.
HR 20030618 Shortened aof-transmitting.
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.