W3C

SOAP Message Transmission Optimization Mechanism

W3C Working Draft 8 June 2004

This version:
http://www.w3.org/TR/2004/WD-soap12-mtom-20040608/
Latest version:
http://www.w3.org/TR/soap12-mtom/
Previous version:
http://www.w3.org/TR/2004/WD-soap12-mtom-20040209/
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 W3C Last Call 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 .

Comments on this document are welcome. Send them before 29 June 2004 to xmlp-comments@w3.org mailing list (public archive). Note that all outstanding issues against this document are documented in the Working Group Last Call Issues List. If the feedback on this document is positive, the WG plans to submit it for consideration as a W3C Candidate Recommendation.

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. 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.

Editorial note: HR 
The current XML Schema references points to the Proposed Edited Recommendation for the Second Edition of XML Schema. Those references will be updated when this Second Edition becomes a Recommendation.

Table of Contents

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 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/Related 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 The application/soap_xop+xml Media Type
    A.1 Introduction
    A.2 Registration
B References


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.

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/Related Serialization of SOAP Messages) describes an Optimized MIME Multipart/Related 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/Related 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).

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 [Prefixes and Namespaces used in this specification.]. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see XML Infoset [XML InfoSet]).

Prefixes and Namespaces used in this specification.
PrefixNamespace
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.
xop"http://www.w3.org/2003/12/xop/include"
A non-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/3/06/Attachments/include.xsd.
rep"http://www.w3.org/2004/02/representation"
A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the "http://www.w3.org/2004/02/representation" namespace can be found at TBD.
xs"http://www.w3.org/2001/XMLSchema"
The namespace of XML Schema data types (see [XML Schema Part 2]).

1.2 Relation to other specifications

The 4 HTTP Transmission Optimization Feature (which is an implementation of the 2 Abstract Transmission Optimization Feature for the SOAP 1.2 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] and the specification described herein fulfills those requirements.

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

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.3 Abstract Transmission Optimization Feature Processing

2.3.1 Sending a message

When sending a SOAP Message, if the Abstract Transmission Optimization 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 of the SOAP Message to be sent. Similar rules should be applied for other MEPs, as appropriate.

One purpose of the Abstract Transmission Optimization Feature is to optimize the transmission of base64 encoded data. To be optimized, the characters comprising the [children] of an element information item MUST be in the canonical form of xs:base64Binary (see [XML Schema Part 2] 3.2.16 base64Binary) and MUST not contain any whitespace characters, preceding, inline with or following the non-whitespace content.

Note: the means of identifying element information items that contain base64 encoded data in canonical lexical form are implementation-dependent. Some implementations can identify such element information items by construction (e.g., because a certain API may create only canonical forms); others may check the characters prior to sending. 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 optimized 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.

Upon reception of an optimized SOAP message, the receiving node MUST reconstruct an Envelope Infoset from the optimized SOAP message. Then, the receiving node MUST perform SOAP processing on the reconstructed Infoset (see [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 base64 encoded character form.

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 the Infoset of the reconstructed SOAP Envelope. Similar rules should be applied for other MEPs, as appropriate.

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.

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.

Note: a consequence of this architecture is that there are no invariant rules for the degree to which optimizations are preserved as a message passes through intermediaries. Certain outbound bindings may be incapable of any optimization, and will therefore transmit non-optimized forms in all cases. Other bindings may be capable of optimization, but may or may not choose to optimize the same portions (if any) that were optimized in the inbound message. Other bindings, perhaps under the direction of logic provided in SOAP modules or perhaps as consequence of conventions embodied in the bindings, may optimize portions of the message that were not optimized inbound, or which were optimized using different techniques.

3 An Optimized MIME Multipart/Related Serialization of SOAP Messages

3.1 Introduction

The Optimized MIME Multipart/Related 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/Related Serialization provides the basis for an implementation of the Abstract Transmission Optimization Feature by describing how to serialize a SOAP envelope in an optimized way, using the [XOP] format and a MIME Multipart/Related packaging ([RFC 2387]).

More specifically, the SOAP envelope Infoset is transmitted as a MIME Multipart/Related XOP Package (see [XOP], 4.1 MIME Multipart/Related XOP Packages). Any W3C recommendation-level version of XML is allowed for storing the XOP Infoset created from the SOAP envelope Infoset into the MIME Multipart/Related XOP Package, however, note that the SOAP envelope Infoset MUST be serializable as XML 1.0.

3.2 Serialization of a SOAP message

When sending a SOAP message using the MIME Multipart/Related Serialization, the SOAP envelope Infoset is serialized as specified in [XOP] 3.1 Creating XOP packages. The result is a MIME Multipart/Related XOP package (see [XOP]): 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.

3.3 Deserialization of a SOAP message

When receiving a SOAP message using this Optimized MIME Multipart/Related Serialization, the SOAP Envelope Infoset is reconstructed from the MIME Multipart/Related XOP Package by performing the processing specified in [XOP] 3.2 Interpreting XOP packages.

Note: conventions or error reporting mechanisms to be used in processing packages that incorrectly purport to be XOP Packages containing a SOAP Envelope are beyond the scope of this specification.

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/Related Serialization described in 3 An Optimized MIME Multipart/Related 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.3 Implementation

The HTTP Transmission Optimization Feature uses the Optimized MIME Multipart/Related Serialization (see 3 An Optimized MIME Multipart/Related 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 XOP Package in the HTTP body. On the receiving side, this feature extracts the MIME Multipart/Related XOP Package from the HTTP body and deserializes as described in 3.3 Deserialization of a SOAP message.

When using the HTTP Transmission Optimization Feature to transmit a SOAP Envelope Infoset, the XOP Infoset built from the SOAP Envelope Infoset MUST be serialized as application/soap_xop+xml in the root part of the MIME Multipart/Related XOP Package.

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 [HTTP Request Fields].

HTTP Request Fields
FieldValue
Content-Type header fieldmime/multipart-related
HTTP entity bodySOAP 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/Related Serialization of SOAP Messages with the following restriction:

  • The XOP Infoset MUST be serialized as application/soap_xop+xml in the root part of the package.

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

  • Each MIME part that is refered to by xop:Include MUST have a Content-Tranfer-Encoding header field.

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 Infosets that contain element information items of name xop:Include (see [XOP] 3. XOP Infosets Constructs). In any case where a SOAP envelope containing such an element information item 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.
Editorial note: HR 

Request for comments:

The binding framework of the SOAP recommendation provides that "the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP message Infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol." (see [SOAP Part 1] 4.2 Binding Framework). Although illegal as input to XOP encoding, elements named xop:Include are legal in SOAP Infosets, and may indeed be useful in certain circumstances (perhaps in sending an error report on or otherwise quoting a fragment of a XOP Infoset). During preparation of this MTOM specification some commentators noted that the second option provided above (i.e., to generate an error) sets the potentially unfortunate precedent of allowing particular bindings to decline to send otherwise legal SOAP messages. Accordingly, the option to generate a binding-dependent fault is included in this draft provisionally, and the XML Protocols Workgroup solicits feedback on the advisability of retaining this option in the final Recommendation.

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, an implementation of the SOAP HTTP Binding (see [SOAP Part 2]) will determine whether the HTTP Transmission Optimization Feature is used by checking the presence of the application/soap_xop+xml media type (see ???). If the media type of the HTTP message is "multipart/related" and the media type of the root part of the MIME Multipart/Related package is application/soap_xop+xml, then the received SOAP message was transmitted using the HTTP Transmission Optimization Feature and MUST be processed accordingly.

The HTTP Transmission Optimization Feature changes the behavior of [SOAP Part 2] 7. SOAP HTTP Binding for the reception of a SOAP message. The remaining of 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.

A The application/soap_xop+xml Media Type

A.1 Introduction

SOAP version 1.2 ([SOAP Part 1] and [SOAP Part 2]) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols.

The XML-binary Optimized Packaging Mechanism [XOP] is an alternate serialization of the XML Infoset, intended to make processing and representation of certain types of content (specifically, that which is base64-encoded) more efficient. Such serializations, when free-standing, are called XOP Packages; the portion of the XOP Package that represents the structure and non-optimized content of the Infoset are called XOP Documents, and are serialized as XML.

This appendix defines the media type application/soap_xop+xml which can be used to identify SOAP 1.2 message envelopes that have been serialized as XOP Documents using XML 1.0 ([XML 1.0]).

The application/soap_xop+xml media type explicitly identifies the XOP Document portion of a SOAP 1.2 message envelope, serialized as XML 1.0. In other words, it identifies the serialized XML after the extraction of any content into the XOP Package; it does not identify the package itself.

XOP Documents not serialized as XML 1.0 or representing message envelopes with a different SOAP namespace version MUST NOT use it.

A.2 Registration

  • MIME media type name:

    application.

  • MIME subtype name:

    soap_xop+xml

  • Required parameters:

    none

  • Optional parameters:

    • "charset":

      This parameter has identical semantics to the charset parameter of the application/xml media type as specified in RFC 3023 [RFC 3023].

    • "action":

      This optional parameter can be used to specify the URI that identifies the intent of the message. In SOAP 1.2, it serves a similar purpose as the SOAPAction HTTP header field did in SOAP 1.1. Namely, its value identifies the intent of the message.

      The value of the action parameter is an absolute URI-reference as defined by RFC 2396 [RFC 2396]. SOAP places no restrictions on the specificity of the URI or that it is resolvable. Although the purpose of the action parameter is to indicate the intent of the SOAP message there is no mechanism for automatically computing the value based on the SOAP envelope. In other words, the value has to be determined out of band.

      It is recommended that the same value be used to identify sets of message types that are logically connected in some manner, for example part of the same "service". It is strongly RECOMMENDED that the URI be globally unique and stable over time.

      The presence and content of the action parameter MAY be used by servers such as firewalls to appropriately filter SOAP messages and it may be used by servers to facilitate dispatching of SOAP messages to internal message handlers etc. It SHOULD NOT be used as an insecure form of access authorization. Use of the action parameter is OPTIONAL. SOAP Receivers MAY use it as a hint to optimize processing, but SHOULD NOT require its presence in order to operate.

  • Encoding considerations:

    Identical to those of application/xml as described in RFC 3023 [RFC 3023], section 3.2, as applied to the SOAP envelope Infoset.

  • Security considerations:

    Because SOAP can carry application defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the SOAP message based on the semantics of the MIME wrapper alone. Therefore, whenever using the application/soap_xop+xml media type, it is strongly RECOMMENDED that the security implications of the context within which the SOAP message is used is fully understood. The security implications are likely to involve both the specific SOAP binding to an underlying protocol as well as the application-defined semantics of the data carried in the SOAP message (though one must be careful when doing this, as discussed in SOAP 1.2 Part 1 [SOAP Part 1], 7.3.1 Binding to Application-Specific Protocols.

    Also, see SOAP 1.2 Part 1 [SOAP Part 1], 7. Security Considerations.

    In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in RFC 3023 [RFC 3023], section 10.

  • Interoperability considerations:

    There are no known interoperability issues.

  • Published specification:

    SOAP 1.2 Part 1 [SOAP Part 1], SOAP 1.2 Part 2, [SOAP Part 2], and XOP [XOP].

  • Applications which use this media type:

    No known applications currently use this media type.

  • Additional information:

    • File extension:

      SOAP messages are not required or expected to be stored as files.

    • Fragment identifiers:

      Identical to that of application/xml as described in RFC 3023 [RFC 3023], section 5.

    • Base URI:

      As specified in RFC 3023 [RFC 3023], section 6. Also see SOAP 1.2 Part 1 [SOAP Part 1], 6. Use of URIs in SOAP.

    • Macintosh File Type code:

      TEXT

  • Person and email address to contact for further information:

    Mark Nottingham <mnot@pobox.com>

  • Intended usage:

    COMMON

  • Author/Change controller:

    The SOAP 1.2 specification set is a work product of the World Wide Web Consortium's XML Protocol Working Group. The W3C has change control over these specifications.

B 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/.)
XOP
W3C Working Draft "XML-binary Optimized Packaging", N. Mendelsohn, M. Nottingham, H. Ruellan, June 2004. (See http://www.w3.org/TR/2004/WD-xop10-20040608/.)
SOAP 1.2 Attachment Feature
W3C Working Group Note "SOAP 1.2 Attachment Feature", H. F. Nielsen, H. Ruellan, June 2004. (See http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/.)
SOAP Attachment Requirements
W3C Working Draft "SOAP Attachment Feature Requirements", M. A. Jones, Tony Graham, Anish Karmarkar, June 2004. (See http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/.)
SOAP Representation Header
W3C Working Draft "SOAP Resource Representation Header", A. Karmarkar, M. Gudgin, Y. Lafon, June 2004. (See http://www.w3.org/TR/2004/WD-soap12-rep-20040608/.)
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 Proposed Edited Recommendation "XML Schema Part 1: Structures Second Edition", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 18 March 2004. (See http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/.)
XML Schema Part 2
W3C Proposed Edited Recommendation "XML Schema Part 2: Datatypes Second Edition", Paul V. Biron, Ashok Malhotra, 18 March 2004. (See http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/.)
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.)
RFC 2396
Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)
RFC 3023
IETF "XML Media Types", M. Murata, S. St. Laurent, D. Kohn, January 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)
PASWA
"Proposed Infoset Addendum to SOAP Messages with Attachments", April 2003. (See http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.)