This section describes the status of this document at the time of its publication. Other documents may supersede this document.

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

Table 1 shows a representation of a SOAP envelope XML
Infoset prior to XOP processing. Table 2 shows the same Infoset, serialized
using the application/xop+xml format in a MIME Multipart/Related package. These
examples correspond to those in [XOP, 1.2 Examples],
adjusted to illustrate SOAP 1.1 envelopes.

Lines (01-02) in Table indicate the message is encoded as
SOAP 1.1. Lines (07) and (09) are elements with base64encoded binary data.
For purposes of this example, both of these blocks of data will be optimized.

Lines (17) and (24) in Table show the media type “text/xml”
as required by SOAP 1.1. Lines (28-43) illustrate SOAP 1.1 envelope. Other
parts of this package are identical to those one would find in a XOP package
for a SOAP 1.2 envelope.

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

Use of MTOM/XOP with SOAP 1.1 is straightforward. There are
differences between SOAP 1.1 and SOAP 1.2 particularly with respect to
definitions of SOAP 1.2 Features, SOAP 1.2 Modules, SOAP 1.2 Message Exchange
Patterns, SOAP 1.2 Property Conventions for Message Exchange Patterns, SOAP 1.2
HTTP binding description and intermediaries. Those parts of MTOM specification
that are specific to SOAP 1.2-only constructs are not applicable to SOAP 1.1
and thus not applicable to this specification. For example, in [MTOM]
2
Abstract SOAP Transmission Optimization Feature and [MTOM]
4
HTTP SOAP Transmission Optimization Feature the feature definition and its
effects on SOAP MEP and SOAP MEP properties are not applicable to this
specification.

SOAP 1.1 is defined in terms of XML elements, and MTOM
describes SOAP 1.2 constructs in terms of information items. There is a clear
correspondence between the two, as described in the [XML
Information Set].

All constraints described in [MTOM] and
[XOP] MUST be followed, except as noted above or changed as
specified below.

When sending a SOAP 1.1 message using the MIME
Multipart/Related Serialization, the SOAP envelope Infoset is serialized into
XML 1.0 as specified in [XOP] 3.1
Creating XOP packages. Specifically:

The content-type of the outer package MUST be multipart/related.

The type parameter of the content-type header of the outer
package MUST have a value of application/xop+xml
(see [XOP], 4.1 MIME
Multipart/Related XOP Packages).

The start-info parameter of the content-type header of the
outer package MUST specify a content-type for the root part of text/xml.

The content-type of the root part MUST be application/xop+xml (see [XOP], 4.1 MIME Multipart/Related XOP Packages).

The type parameter of the content-type header of the root
part MUST specify a content-type of text/xml.

The result is a MIME Multipart/Related XOP package (see [XOP]): one body part, the root, containing an XML 1.0
representation of the modified SOAP 1.1 envelope, with an additional part used
to contain the binary representation of each element that was optimized.

Implementations supporting the HTTP SOAP Transmission
Optimization binding for SOAP 1.1 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 1.1 envelope containing
such an element information item is to be sent, the binding MUST do one
of the following:

Fall back to use the text/xml
media type or any other suitable media type, i.e., send the SOAP envelope
without using the HTTP SOAP Transmission Optimization Feature.

4. 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/xop+xml media type, it is strongly
advised 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.

It is assumed that such mechanisms that protect SOAP
messages at the infoset level will seamlessly adapt to provide protection for
messages conforming to this document. It is strongly recommended that the
messages be secured using those mechanisms. In order to properly secure
messages, the body and all relevant headers need to be included in the
signature. It should be noted that for messages traveling through
intermediaries, it is possible that some or all of the message information
headers may have multiple signatures when the message arrives at the ultimate
receiver. It is strongly recommended that the initial sender include a
signature to prevent any spoofing by intermediaries.