This specification uses terminology from the XML Infoset (see ) when discussing XML content and structure. This is only a convention for clear specification of XOP behavior.

The following terms are used in this specification:

1 shows an XML Infoset prior to XOP processing. 2 shows the same Infoset, serialized using the XOP format in a MIME Multipart/Related package. The base64-encoded content of the m:photo and m:sig elements have been replaced by a xop:Include element, while the binary octets have been serialized in separate MIME parts. Note that those examples use to identify the media type of the content of the m:photo and m:sig elements. Note also that the sample base64 data is smaller than would be typical and the binary octets are not shown; in practice, the optimized form is likely to be much smaller than the original.

3 shows an XML Infoset prior to XOP processing. 4 shows the same Infoset, serialized using the XOP format in a MIME Multipart/Related package. The base64-encoded content of the m:photo and m:sig elements have been replaced by a xop:Include element, while the binary octets have been serialized in separate MIME parts. Note also that the sample base64 data is smaller than would be typical and the binary octets are not shown; in practice, the optimized form is likely to be much smaller than the original.

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 .

This specification uses a number of namespace prefixes throughout; they are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

The xop:Include element information item has:

The href attribute information item has:

To create a XOP Package from an Original XML Infoset:

Additional parts MAY be added to the package to satisfy application specific requirements. Other content-specific metadata MAY be reflected in the packaging metadata as appropriate.

If content cannot be successfully encoded into the XOP package, implementations SHOULD behave as if that portion of the Original XML Infoset was not nominated for optimization.

This section specifies the means by which the Original XML Infoset can be reconstructed from a XOP Package that has been prepared according to the rules of .

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

To create a Reconstituted XML Infoset from a XOP Package:

This section describes how MIME Multipart/Related packaging (as specified in ) is used with XOP.

The root MIME part is the root part of the XOP package, MUST be a serialization of the XOP Infoset using any W3C recommendation-level version of XML (e.g., , ), and MUST be identified with a media type of "application/xop+xml" (as defined below). The "start-info" parameter of the package's media type MUST contain the content type associated with the content's XML serialization. (i.e. it will contain the same value as the "type" parameter of the root part).

Except for purposes of determining the root MIME part, as specified by , ordering of MIME parts MUST NOT be considered significant to XOP processing or to the construction of the XOP Infoset.

Part metadata is reflected in MIME header fields. Specifically, the URI used in the value of an href attribute information item on a xop:Include element information item contains a URI that uses the 'cid:' scheme (see ), so the corresponding MIME part MUST have a Content-ID header field (see with a corresponding field-value.

Furthermore, if a xmime:contentType attribute information item is found (as described in ), it SHOULD be reflected in the field value of the MIME Content-Type header.

The integrity of Infosets optimized using XOP may need to be ensured. As XOP packages can be transformed to recover such Infosets (see ), existing XML Digital Signature techniques can be used to protect them. Note, however, that a signature over the Infoset does not necessarily protect against modifications of other aspects of the XOP packaging; for example, an Infoset signature check might not protect against re-ordering of non-root parts.

In the future a transform algorithm for use with XML Signature could provide a more efficient processing model where the raw octets are digested directly.

The confidentiality of XOP Packages may need to be ensured. As such packages can be transformed to an XML Information Set, existing XML Encryption (see ) techniques can be used to protect such packages. Any part of a package can be encrypted, whether it includes base64 characters or not. The resulting CipherData element information item can then be optimized because the content of such an element information item is base64 characters.

In the future a transform algorithm for use with XML Encryption could provide a more efficient processing model where the raw octets are encrypted directly.