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 byxop: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 them:photo andm:sig elements have been replaced by axop: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 them:photo andm: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.0Content-Type: Multipart/Related;boundary=MIME_boundary;    type="application/xop+xml";    start="<mymessage.xml@example.org>";    startinfo="application/soap+xml; action=\"ProcessData\""Content-Description: A SOAP message with my pic and sig in it--MIME_boundaryContent-Type: application/xop+xml;     charset=UTF-8;     type="application/soap+xml; action=\"ProcessData\""Content-Transfer-Encoding: 8bitContent-ID: <mymessage.xml@example.org><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_boundaryContent-Type: image/pngContent-Transfer-Encoding: binaryContent-ID: <http://example.org/me.png>// binary octets for png--MIME_boundaryContent-Type: application/pkcs7-signatureContent-Transfer-Encoding: binaryContent-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 them:photo andm:sig elements have been replaced by axop: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.0Content-Type: Multipart/Related;boundary=MIME_boundary;    type="application/xop+xml";    start="<mymessage.xml@example.org>";    start-info="text/xml"Content-Description: An XML document with my pic and sig in it--MIME_boundaryContent-Type: application/xop+xml;     charset=UTF-8;     type="text/xml"Content-Transfer-Encoding: 8bitContent-ID: <mymessage.xml@example.org><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_boundaryContent-Type: image/pngContent-Transfer-Encoding: binaryContent-ID: <http://example.org/me.png>// binary octets for png--MIME_boundaryContent-Type: application/pkcs7-signatureContent-Transfer-Encoding: binaryContent-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.1xop:Include element information item

Thexop:Include element information item has:

• A [local name] ofInclude.
• A [namespace name] of "http://www.w3.org/2004/08/xop/include".
• One or moreattribute information items amongst its [attributes] property as follows:
  • A mandatoryhref attribute informationitem (see2.2 href attribute information item).
  • Zero or more additional namespace qualifiedattribute information items. Any suchattribute information items MUST NOT have a [namespace name] of "http://www.w3.org/2004/08/xop/include", MUST NOT changethe semantics of processing thexop:Include element information item and MUST be ignored ifnot recognized.
• Zero or more namespace qualifiedelement information items in its [children] property. Any suchelement information items MUST NOT have a [namespace name] of "http://www.w3.org/2004/08/xop/include", MUST NOT change the semantics of processing thexop:Include element information item and MUST be ignored if not recognized.

2.2href attribute information item

Thehref attribute information item has:

• A [local name] ofhref.
• 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., thexop: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 Schemaxs:anyURI datatype (see[XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
• An [owner element] which is thexop: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 noelement information item with a [namespace name] of "http://www.w3.org/2004/08/xop/include" and a [local name] ofInclude. As discussed in2 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 theelement information items to be optimized. To be optimized, the characters comprising the [children] of theelement information item MUST be in the canonical form ofxs: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 eachelement information item identified in the previous step replaced by axop:Include element information item (see2.1 xop:Include element information item) constructed as follows:
   1. Transform the replaced characters into binary data byprocessing them as base64-encoded data.
   2. Serialize the binary data into a new part of the package, withappropriate metadata corresponding to the [normalized value] ofthehref attribute information item ofthexop:Include element information item (see2.2 href attribute information item).
   3. If theelement information item being optimized(i.e., the [parent] of the newly insertedxop:Include element information item)has axmlmime:contentType attribute information item, its value SHOULD be reflectedappropriately 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 in5 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 of3.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 eachelement information item, E, which has, as the sole member of its [children] property, axop:Include element information item (as defined in2.1 xop:Include element information item):
   1. Locate the part of the package corresponding to the URI in thehref attribute information item of thexop:Include element information item (i.e., corresponding to the URIencoded in the attribute information item's[normalized value]).
   2. Replace thexop:Include element information item that appears in the [children] property of E with character information items representingthe canonical base64 encoding of the entity body of theidentified package part (i.e., effectively replace thexop:Include element information itemwith the data reconstructed from thepackage 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 anhref attribute information item on axop: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 axmlmime:contentType attribute information item is found (as described in3 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 <mnot@pobox.com>

Intended usage:

COMMON

Author/Change controller:

The XOP specification is a work product of the World Wide Web Consortium'sXML 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 (see3.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 resultingCipherData 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.

A.1 Dependencies

The XOP convention builds upon a number of underlying specifications. They are:

• XML (e.g.,[Extensible Markup Language (XML) 1.0 (Third Edition)],[Extensible Markup Language (XML) 1.1]) - The XOP Document is encoded using any W3C recommendation-level version of XML (see3.1 Creating XOP Packages). Formats that use XOP MUST identify which versions of XML are permissible for encoding the XOP Infoset. XOP does not constrain the use of any mechanisms defined by XML, including those explicitly allowing extensions, nor does it constrain the use of underlying specifications.

• Namespaces in XML (e.g.,[Namespaces in XML],[Namespaces in XML 1.1]) - The XOP Document uses any W3C recommendation-level version of Namespaces in XML compatible with the version(s) of XML used. Formats that use XOP MUST identify which versions of Namespaces in XML are permissible for encoding the XOP Infoset. XOP does not constrain the use of any mechanisms defined by Namespaces in XML, including those explicitly allowing extensions, nor does it constrain the use of underlying specifications.

• Uniform Resource Identifiers (see[RFC 2396]) - The XOP Document uses URIs to locate parts in the XOP Package (see2.2 href attribute information item. XOP does not constrain the use of any mechanisms defined by URIs, including those explicitly allowing extensions, nor does it constrain the use of underlying specifications.

• Packaging Mechanism - XOP requires the use of a packaging mechanism that satisfies the requirements in4 XOP Packages. One such mechanism MUST be in use, but XOP does not require a specific mechanism. Formats using XOP MUST identify at least one such mechanism permissible for creating the XOP Package, and MUST specify how each allowed mechanism is to be used for building the XOP Package.

  The relationship of one such mechanism to XOP, The MIME Multipart/Related Content-type, is specified in4.1 MIME Multipart/Related XOP Packages.

A.2 Payload

The payload of a XOP Package is an XML Infoset. XOP constrains the range of admissible characters in the payload to those contained in the "Char" production of a W3C recommendation-level version of XML. Additionally, the Original XML Infoset cannot contain anelement information item with a [local name] of ofInclude and a [namespace name] of "http://www.w3.org/2004/08/xop/include". Finally, portions of the payload which are nominated for optimization in XOP MUST be base64-encoded data in the canonical lexical form of XML Schemabase64Binary datatype (see[XML Schema Part 2: Datatypes Second Edition]3.2.16 base64Binary).

A.3 Extension

XOP Documents allow extensions to thexop:Include element when they do not change its semantics. Changes to the semantics MUST be identified by a new namespace URI (i.e., they MUST define a newInclude element information item in another namespace).

The extensibility of the specifications underlying XOP is not constrained by their use in XOP.

A.4 Requirements

This document along with[SOAP Message Transmission Optimization Mechanism] and[SOAP Representation Header] has been produced in conjunction with the development of requirements embodied in the[SOAP Optimized Serialization Use Cases and Requirements] document.

B.1 Normative References

Extensible Markup Language (XML) 1.0 (Third Edition)

Extensible MarkupLanguage (XML) 1.0 (Third Edition), Jean Paoli, Eve Maler,Tim Bray,et. al., Editors. World Wide Web Consortium, 04 February 2004. This version is http://www.w3.org/TR/2004/REC-xml-20040204. Thelatest version isavailable at http://www.w3.org/TR/REC-xml.

Extensible Markup Language (XML) 1.1

Extensible Markup Language (XML) 1.1, John Cowan, C. M. Sperberg-McQueen, François Yergeau,et. al., Editors. World Wide Web Consortium, 04 February 2004. This version is http://www.w3.org/TR/2004/REC-xml11-20040204/. Thelatest version is available at http://www.w3.org/TR/xml11/.

SOAP Message Transmission Optimization Mechanism

SOAP Message Transmission Optimization Mechanism, Hervé Ruellan,Noah Mendelsohn, Martin Gudgin, and Mark Nottingham, Editors. World Wide Web Consortium, 25 January 2005. This version is http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/.Thelatest version isavailable at http://www.w3.org/TR/soap12-mtom/.

Resource Representation SOAP Header Block

Resource Representation SOAP Header Block, Martin Gudgin, Yves Lafon, and Anish Karmarkar, Editors. World Wide Web Consortium, 25 January 2005. This version is http://www.w3.org/TR/2005/REC-soap12-rep-20050125/. Thelatest version is available at http://www.w3.org/TR/soap12-rep/.

SOAP Optimized Serialization Use Cases and Requirements

SOAP Optimized Serialization Use Cases and Requirements, Tony Graham, Mark Jones, and Anish Karmarkar, Editors. World Wide Web Consortium, 08 June 2004. This version is http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/. Thelatest versionis available at http://www.w3.org/TR/soap12-os-ucr/.

Namespaces in XML

Namespaces inXML, Andrew Layman, Dave Hollander, and Tim Bray, Editors. World Wide Web Consortium, 14 January 1999. This version is http://www.w3.org/TR/1999/REC-xml-names-19990114. Thelatest version isavailable at http://www.w3.org/TR/REC-xml-names.

Namespaces in XML 1.1

Namespaces inXML 1.1, Richard Tobin, Andrew Layman, Tim Bray, and Dave Hollander, Editors. World Wide Web Consortium, 04 Febuary 2004. This version is http://www.w3.org/TR/2004/REC-xml-names11-20040204. Thelatest version is available at http://www.w3.org/TR/xml-names11/.

XML Information Set (Second Edition)

XML Information Set (Second Edition), Richard Tobin and John Cowan, Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204. Thelatest version isavailable at http://www.w3.org/TR/xml-infoset.

XML Schema Part 1: Structures Second Edition

XML Schema Part 1: Structures Second Edition, David Beech, Murray Maloney, Henry S. Thompson,and Noah Mendelsohn, Editors. World Wide Web Consortium, 28 October 2004. This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. Thelatest version isavailable at http://www.w3.org/TR/xmlschema-1/.

XML Schema Part 2: Datatypes Second Edition

XML Schema Part 2:Datatypes Second Edition, Ashok Malhotra and Paul V. Biron, Editors. World Wide Web Consortium, 28 October 2004. This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Thelatest version isavailable at http://www.w3.org/TR/xmlschema-2/.

Assigning Media Types to Binary Data in XML

Assigning MediaTypes to Binary Data in XML, Ümit Yalçınalp and Anish Karmarkar, Editors. World Wide Web Consortium, 02 November 2004. This version is http://www.w3.org/TR/2004/WD-xml-media-types-20041102.Thelatest version is available at http://www.w3.org/TR/xml-media-types.

RFC 2119

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Editor.IETF, March 1997. This RFC is available at http://www.ietf.org/rfc/rfc2119.txt.

RFC 2387

The MIME Multipart/Related Content-type, E. Levinson, Editor.IETF, August 1998. This RFC is available at http://www.ietf.org/rfc/rfc2387.txt.

RFC 2557

MIME Encapsulation of Aggregate Documents, such as HTML (MHTML),J. Palme, A. Hopmann and N. Shelness, Editors.IETF, March 1999. This RFC is available at http://www.ietf.org/rfc/rfc2557.txt.

RFC 2392

Content-ID and Message-ID Uniform Resource Locators, E. Levinson, Editor.IETF, August 1998. This RFC is available at http://www.ietf.org/rfc/rfc2392.txt.

RFC 2396

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, Editors.IETF, August 1998. This RFC is available at http://www.ietf.org/rfc/rfc2396.txt.

RFC 2732

Format for Literal IPv6 Addresses in URL's, R. Hinden, B. Carpenter and L. Masinter, Editors.IETF, December 1999. This RFC is available at http://www.ietf.org/rfc/rfc2732.txt.

B.2 Informative References

Canonical XML Version 1.0

Canonical XML Version 1.0, John Boyer, Editor. World Wide Web Consortium, 15 March 2001. This version is http://www.w3.org/TR/2001/REC-xml-c14n-20010315. Thelatest version is available at http://www.w3.org/TR/xml-c14n.

Exclusive XML Canonicalization Version 1.0

Exclusive XML Canonicalization Version 1.0, Joseph Reagle, Donald E. Eastlake 3rd, and John Boyer, Editors. World Wide Web Consortium, 18 July 2002. This version is http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/. Thelatest version isavailable at http://www.w3.org/TR/xml-exc-c14n.

XML Encryption Syntax and Processing

XML Encryption Syntax and Processing, Joseph Reagle and Donald Eastlake, Editors. World Wide Web Consortium, 10 December 2002. This version is http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/. Thelatest version is available at http://www.w3.org/TR/xmlenc-core/.

SOAP Version 1.2 Part 1: Messaging Framework

SOAP Version 1.2 Part 1: Messaging Framework, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau,et. al., Editors. World Wide Web Consortium, 24 June 2003. This version is http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. Thelatest version isavailable at http://www.w3.org/TR/soap12-part1/.

SOAP Version 1.2 Part 2: Adjuncts

SOAPVersion 1.2 Part 2: Adjuncts, Henrik Frystyk Nielsen, Noah Mendelsohn, Jean-Jacques Moreau,et. al., Editors. World Wide Web Consortium, 24 June 2003. This version is http://www.w3.org/TR/2003/REC-soap12-part2-20030624/. Thelatest version isavailable at http://www.w3.org/TR/soap12-part2/.