XML-binary Optimized Packaging

1.1 Terminology

This specification uses terminology from the XML Infoset (see [XMLInfoSet]) 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:

• Original XML Infoset - An XML Infoset to be optimized.
• Optimized Content - Content which has been removed from the XML Infoset.
• XOP Infoset - The Original Infoset with any Optimized Content removed and replaced by xop:Include element information items.
• XOP Document - A serialization of the XOP Infoset using any W3C recommendation-level version of XML.
• XOP Package - A package containing the XOP Document and any Optimized Content. As a whole, the XOP Package is an alternate serialization of the Original Infoset.
• Reconstituted XML Infoset - An XML Infoset that has been constructed from the parts of a XOP Package.

1.2 Example

Example 1 shows an XML Infoset prior to XOP processing. Example 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 [Assigning Media Types to Binary Data in XML] 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.

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope' 
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo 
  xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
      <m:sig 
  xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<[email protected]>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <[email protected]>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo 
  xmlmime:contentType='image/png'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig 
  xmlmime:contentType='application/pkcs7-signature'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/my.hsh'/></m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--

Example 3 shows an XML Infoset prior to XOP processing. Example 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.

<m:data xmlns:m='http://example.org/stuff'>
  <m:photo>/aWKKapGGyQ=</m:photo>
  <m:sig>Faa7vROi2VQ=</m:sig>
</m:data>

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<[email protected]>";
    start-info="text/xml"
Content-Description: An XML document with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <[email protected]>

<m:data xmlns:m='http://example.org/stuff'>
  <m:photo><xop:Include 
  xmlns:xop='http://www.w3.org/2004/08/xop/include' 
  href='cid:http://example.org/me.png'/></m:photo>
  <m:sig><xop:Include 
  xmlns:xop='http://www.w3.org/2004/08/xop/include' 
  href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--

1.3 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 below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

2.1 xop:Include element information item

The xop:Include element information item has:

• A [local name] of Include.
• A [namespace name] of "http://www.w3.org/2004/08/xop/include".
• One or more attribute information items amongst its [attributes] property as follows:
  • A mandatory href attribute information item (see 2.2 href attribute information item).
  • Zero or more additional namespace qualified attribute information items. Any such attribute information items MUST NOT have a [namespace name] of "http://www.w3.org/2004/08/xop/include", MUST NOT change the semantics of processing the xop:Include element information item and MUST be ignored if not recognized.
• Zero or more namespace qualified element information items in its [children] property. Any such element information items MUST NOT have a [namespace name] of "http://www.w3.org/2004/08/xop/include", MUST NOT change the semantics of processing the xop:Include element information item and MUST be ignored if not recognized.

2.2 href attribute information item

The href attribute information item has:

• A [local name] of href.
• An empty [namespace name].
• A [normalized value] which is a representation of a URI (see [RFC 2396] as amended by [RFC 2732]) referencing the part of the package containing the data logically included by the [owner element] (i.e., the xop:Include element information item). The [normalized value] MUST be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the [normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
• An [owner element] which is the xop:Include element information item containing the attribute information item.

3.1 Creating XOP Packages

To create a XOP Package from an Original XML Infoset:

1. Ensure that the Original XML Infoset contains no element information item with a [namespace name] of "http://www.w3.org/2004/08/xop/include" and a [local name] of Include. As discussed in 2 XOP Infoset Constructs, XML Infosets with such element information items cannot be represented using XOP.
2. Create an empty package.
3. Identify within the Original XML Infoset the element information items to be optimized. To be optimized, the characters comprising the [children] of the element information item MUST be in the canonical form of xs:base64Binary (see [XML Schema Part 2: Datatypes Second Edition]3.2.16 base64Binary) and MUST NOT contain any whitespace characters, preceding, inline with or following the non-whitespace content.
4. Create a XOP Infoset which is a copy of the Original XML Infoset, but with the [children] of each element information item identified in the previous step replaced by a xop:Include element information item (see 2.1 xop:Include element information item) constructed as follows:
   1. Transform the replaced characters into binary data by processing them as base64-encoded data.
   2. Serialize the binary data into a new part of the package, with appropriate metadata corresponding to the [normalized value] of the href attribute information item of the xop:Include element information item (see 2.2 href attribute information item).
   3. If the element information item being optimized (i.e., the [parent] of the newly inserted xop:Include element information item) has a xmlmime:contentType attribute information item, its value SHOULD be reflected appropriately in the metadata for the part.
5. Serialize the resulting XOP Infoset into the package using any W3C recommendation-level version of XML (e.g., [Extensible Markup Language (XML) 1.0 (Third Edition)], [Extensible Markup Language (XML) 1.1]) and identify it as the root part according to the packaging mechanism's convention, labeling it with the application/xop+xml media type, as described in 5 Identifying XOP Documents.

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.

3.2 Interpreting XOP Packages

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 3.1 Creating XOP Packages.

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:

1. Construct an XML Infoset by parsing the root part of the package as an XML document. The document MUST be parsed according to the level of the XML Recommendation identified by the XML declaration of that document. If no XML declaration is present, then the document MUST be parsed per [Extensible Markup Language (XML) 1.0 (Third Edition)].
2. Using that XML Infoset, for each element information item, E, which has, as the sole member of its [children] property, a xop:Include element information item (as defined in 2.1 xop:Include element information item):
   1. Locate the part of the package corresponding to the URI in the href attribute information item of the xop:Include element information item (i.e., corresponding to the URI encoded in the attribute information item's [normalized value]).
   2. Replace the xop:Include element information item that appears in the [children] property of E with character information items representing the canonical base64 encoding of the entity body of the identified package part (i.e., effectively replace the xop:Include element information item with the data reconstructed from the package part).

4.1 MIME Multipart/Related XOP Packages

This section describes how MIME Multipart/Related packaging (as specified in [RFC 2387]) 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., [Extensible Markup Language (XML) 1.0 (Third Edition)], [Extensible Markup Language (XML) 1.1]), 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 [RFC 2387], 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 [RFC 2392]), so the corresponding MIME part MUST have a Content-ID header field (see [RFC 2387] with a corresponding field-value.

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

5.1 Registration

MIME media type name:

application

MIME subtype name:

xop+xml

Required parameters:

type

This parameter conveys the content type associated with the XML serialization of the XOP infoset, including parameters as appropriate.

Optional parameters:

charset

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

Encoding considerations:

Identical to those of "application/xml" as described in RFC 3023 [RFC3023], section 3.2.

Security considerations:

In addition to application-specific considerations, XOP has the same security considerations described in RFC3023 [RFC3023], section 10.

Interoperability considerations:

There are no known interoperability issues.

Published specification:

This document

Applications which use this media type:

No known applications currently use this media type.

Additional information:

File extension:

XOP

Fragment identifiers:

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

Base URI:

As specified in RFC 3023 [RFC3023], section 6.

Macintosh File Type code:

TEXT

Person and email address to contact for further information:

Mark Nottingham <[email protected]>

Intended usage:

COMMON

Author/Change controller:

The XOP specification is a work product of the World Wide Web Consortium's XML Protocol Working Group. The W3C has change control over this specification.

6.1 XOP Package Integrity

The integrity of Infosets optimized using XOP may need to be ensured. As XOP packages can be transformed to recover such Infosets (see 3.2 Interpreting XOP Packages), 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.

6.2 XOP Package Confidentiality

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 [XML Encryption Syntax and Processing]) 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.