index.html 59.2 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>XML-binary Optimized Packaging</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
<h1><a name="title" id="title"></a>XML-binary Optimized Packaging</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Recommendation 25 January 2005</h2><dl><dt>This version:</dt><dd>
      <a href="http://www.w3.org/TR/2005/REC-xop10-20050125/">http://www.w3.org/TR/2005/REC-xop10-20050125/</a>
    </dd><dt>Latest version:</dt><dd>
      <a href="http://www.w3.org/TR/xop10/">
	http://www.w3.org/TR/xop10/</a>
    </dd><dt>Previous version:</dt><dd>
      <a href="http://www.w3.org/TR/2004/PR-xop10-20041116/">
	http://www.w3.org/TR/2004/PR-xop10-20041116/</a>
    </dd><dt>Editors:</dt><dd>Martin Gudgin, Microsoft</dd><dd>Noah Mendelsohn, IBM</dd><dd>Mark Nottingham, BEA</dd><dd>Hervé Ruellan, Canon</dd></dl><p>Please refer to the <a href="http://www.w3.org/2005/01/xop10-errata"><strong>errata</strong></a> for this document, which may
      include normative corrections.</p><p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xop10"><strong>translations</strong></a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr /><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
	This document defines the XML-binary Optimized Packaging (XOP)
	convention, a means of more efficiently serializing XML Infosets that
	have certain types of content.
      </p></div><div>
<h2><a name="status" id="status"></a>Status of this Document</h2><p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p><p>
  This document is a Recommendation of the W3C. It has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p><p>
  This document has been produced by the
  <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a> (WG)
  as part of the W3C
  <a href="http://www.w3.org/2002/ws/Activity"> Web Services Activity</a>. The English version of this specification is the only normative version. However, for translations of this document, see <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xop10">http://www.w3.org/2003/03/Translations/byTechnology?technology=xop10</a>.
</p><p>
Please report errors in this document to <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">archive</a>). The errata list for this edition is available at <a href="http://www.w3.org/2005/01/xop10-errata">http://www.w3.org/2005/01/xop10-errata</a></p><p>
This document is based upon the <a href="http://www.w3.org/TR/2004/PR-xop10-20041116/">XML-binary Optimized Packaging Proposed Recommendation</a> of 16 November 2004.
Feedback received during that review resulted in no changes. Evidence of interoperation between
 at least two implementations of this specification are documented in the <a href="http://www.w3.org/2000/xp/Group/4/08/implementation.html">Implementation Summary</a>.
Changes between these two versions are described in a <a href="diff-xop.html">diff document</a>.
</p><p>
This document has been produced under the
<a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended
by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>.
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
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">W3C Patent Policy</a>.
Patent disclosures relevant to this specification may be found on the Working Group's
<a href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent disclosure page</a>.
</p><p>A list of current W3C Recommendations and other technical documents can be found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
    1.1 <a href="#terminology">Terminology</a><br />
    1.2 <a href="#example">Example</a><br />
    1.3 <a href="#notational_conventions">Notational Conventions</a><br />
2 <a href="#xop_infosets">XOP Infoset Constructs</a><br />
    2.1 <a href="#xop_include">xop:Include element information item</a><br />
    2.2 <a href="#xop_href">href attribute information item</a><br />
3 <a href="#xop_processing_model">XOP Processing Model</a><br />
    3.1 <a href="#creating_xop_packages">Creating XOP Packages</a><br />
    3.2 <a href="#interpreting_xop_packages">Interpreting XOP Packages</a><br />
4 <a href="#xop_packages">XOP Packages</a><br />
    4.1 <a href="#mime_xop_packages">MIME Multipart/Related XOP Packages</a><br />
5 <a href="#identifying_xop_documents">Identifying XOP Documents</a><br />
    5.1 <a href="#id2270207">Registration</a><br />
6 <a href="#security_considerations">Security Considerations</a><br />
    6.1 <a href="#package_integrity">XOP Package Integrity</a><br />
    6.2 <a href="#package_confidentiality">XOP Package Confidentiality</a><br />
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#relation_other_specifications">Relationship to other specifications</a><br />
    A.1 <a href="#dependencies">Dependencies</a><br />
    A.2 <a href="#payload">Payload</a><br />
    A.3 <a href="#extension">Extension</a><br />
    A.4 <a href="#requirements">Requirements</a><br />
B <a href="#references">References</a><br />
    B.1 <a href="#normative_references">Normative References</a><br />
    B.2 <a href="#informative_references">Informative References</a><br />
C <a href="#acks">Acknowledgements</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2><p>
	This specification defines the XML-binary Optimized Packaging (XOP)
	convention, a means of more efficiently serializing XML Infosets (see
	<a href="#">[XMLInfoSet]</a>) that have certain types of content.
      </p><p>
	A XOP package is created by placing a serialization of the XML Infoset
	inside of an extensible packaging format (such a MIME
	Multipart/Related, see <a href="#RFC2387">[RFC 2387]</a>). Then, selected
	portions of its content that are base64-encoded binary data are extracted and
	re-encoded (i.e., the data is decoded from base64) and placed into the
	package. The locations of those selected portions are marked in the XML
	with a special element that links to the packaged data using URIs.
      </p><p>
	In a number of important XOP applications, binary data need never be
	encoded in base64 form. If the data to be included is already available
	as a binary octet stream, then either an application or other software
	acting on its behalf can directly copy that data into a XOP package, at
	the same time preparing suitable linking elements for use in the root
	part; when parsing a XOP package, the binary data can be made available
	directly to applications, or, if appropriate, the base64 binary
	character representation can be computed from the binary data.
      </p><p>
	However, at the conceptual level, this binary data can be thought of as
	being base64-encoded in the XML Document. As this conceptual form might
	be needed during some processing of the XML Document (e.g., for signing
	the XML document), it is necessary to have a one to one correspondence
	between XML Infosets and XOP Packages. Therefore, the conceptual
	representation of such binary data is as if it were base64-encoded,
	using the canonical lexical form of XML Schema <code>base64Binary</code>
	datatype (see <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary">3.2.16
	  base64Binary</a>). In the reverse direction, XOP is capable of
	optimizing only base64-encoded Infoset data that is in the canonical
	lexical form.
      </p><p>
	Only element content can be optimized; attributes,
	non-base64-compatible character data, and data not in the canonical
	representation of the <code>base64Binary</code> datatype cannot be
	successfully optimized by XOP.
      </p><p>
	The remainder of this specification is organized in the following
	fashion:
      </p><ul><li><p>
	    Section 2 describes the XOP Infoset, which preserves the
	    non-optimized content and structure of the original XML Infoset.
	  </p></li><li><p>
	    Section 3 specifies the XOP processing model.
	  </p></li><li><p>
	    Section 4 of this specification describes the form of the XOP
	    Package.
	  </p></li><li><p>
	    Section 5 describes how XOP Documents are identified.
	  </p></li><li><p>
	    Section 6 explores the security considerations of using the XOP
	    convention.
	  </p></li></ul><div class="div2">
<h3><a name="terminology" id="terminology"></a>1.1 Terminology</h3><p>
	  This specification uses terminology from the XML Infoset (see <a href="#">[XMLInfoSet]</a>) when discussing XML content and structure. This
	  is only a convention for clear specification of XOP behavior.
	</p><p>
	  The following terms are used in this specification:
	</p><ul><li><b>Original XML Infoset</b> - An XML Infoset to be optimized.
	  </li><li><b>Optimized Content</b> - Content which has been removed from
	    the XML Infoset.
	  </li><li><b>XOP Infoset</b> - The Original Infoset with
	    any Optimized Content removed and replaced by
	    <code>xop:Include</code><em> element information items</em>.
	  </li><li><b>XOP Document</b> - A serialization of the XOP Infoset using
	    any W3C recommendation-level version of XML.
	  </li><li><b>XOP Package</b> - A package containing the XOP
	    Document and any Optimized Content. As a whole, the XOP Package
	    is an alternate serialization of the Original Infoset.
	  </li><li><b>Reconstituted XML Infoset</b> - An XML Infoset that has been
	    constructed from the parts of a XOP Package.
	  </li></ul><img src="XOP-architecture.png" alt="Architecture of the XOP framework" /></div><div class="div2">
<h3><a name="example" id="example"></a>1.2 Example</h3><p>
	  <a href="#xml_infoset_soap_sample">Example</a> 1 shows an XML Infoset prior to XOP
	  processing. <a href="#xop_package_soap_sample">Example</a> 2 shows the same
	  Infoset, serialized using the XOP format in a MIME Multipart/Related
	  package. The base64-encoded content of the <code>m:photo</code> and
	  <code>m:sig</code> elements have been replaced by a
	  <code>xop:Include</code> element, while
	  the binary octets have been serialized in separate MIME parts. Note
	  that those examples use <a href="#xmlmime">[Assigning Media Types to Binary Data in XML]</a> to identify the
	  media type of the content of the <code>m:photo</code> and
	  <code>m:sig</code> 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.
	</p><div class="exampleOuter">
<div class="exampleHeader"><a name="xml_infoset_soap_sample" id="xml_infoset_soap_sample"></a>Example: XML Infoset prior to XOP processing (Example 1, SOAP)</div><div class="exampleInner"><pre>&lt;soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'&gt;
  &lt;soap:Body&gt;
    &lt;m:data xmlns:m='http://example.org/stuff'&gt;
      &lt;m:photo
  xmlmime:contentType='image/png'&gt;/aWKKapGGyQ=&lt;/m:photo&gt;
      &lt;m:sig
  xmlmime:contentType='application/pkcs7-signature'&gt;Faa7vROi2VQ=&lt;/m:sig&gt;
    &lt;/m:data&gt;
  &lt;/soap:Body&gt;
&lt;/soap:Envelope&gt;</pre></div></div><div class="exampleOuter">
<div class="exampleHeader"><a name="xop_package_soap_sample" id="xop_package_soap_sample"></a>Example: XML Infoset serialized as a XOP package (Example 2, SOAP)</div><div class="exampleInner"><pre>MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="&lt;mymessage.xml@example.org&gt;";
    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: &lt;mymessage.xml@example.org&gt;

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

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: &lt;http://example.org/me.png&gt;

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: &lt;http://example.org/my.hsh&gt;

// binary octets for signature

--MIME_boundary--</pre></div></div><p>
	  <a href="#xml_infoset_xml_sample">Example</a> 3 shows an XML Infoset prior to XOP
	  processing. <a href="#xop_package_svg_sample">Example</a> 4 shows the same
	  Infoset, serialized using the XOP format in a MIME Multipart/Related
	  package. The base64-encoded content of the <code>m:photo</code> and
	  <code>m:sig</code> elements have been replaced by a
	  <code>xop:Include</code> 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.
	</p><div class="exampleOuter">
<div class="exampleHeader"><a name="xml_infoset_xml_sample" id="xml_infoset_xml_sample"></a>Example: XML Infoset prior to XOP processing (Example 3, non-SOAP)</div><div class="exampleInner"><pre>&lt;m:data xmlns:m='http://example.org/stuff'&gt;
  &lt;m:photo&gt;/aWKKapGGyQ=&lt;/m:photo&gt;
  &lt;m:sig&gt;Faa7vROi2VQ=&lt;/m:sig&gt;
&lt;/m:data&gt;</pre></div></div><div class="exampleOuter">
<div class="exampleHeader"><a name="xop_package_svg_sample" id="xop_package_svg_sample"></a>Example: XML Infoset serialized as a XOP package (Example 4, non-SOAP)</div><div class="exampleInner"><pre>MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="&lt;mymessage.xml@example.org&gt;";
    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: &lt;mymessage.xml@example.org&gt;

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

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: &lt;http://example.org/me.png&gt;

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: &lt;http://example.org/my.hsh&gt;

// binary octets for signature

--MIME_boundary--</pre></div></div></div><div class="div2">
<h3><a name="notational_conventions" id="notational_conventions"></a>1.3 Notational Conventions</h3><p>
	  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 <a href="#RFC2119">[RFC 2119]</a>.
	</p><p>
	  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.
	</p><a name="tabnsprefixes" id="tabnsprefixes"></a><table border="1"><caption>Prefixes and Namespaces used in this
	    specification.</caption><tbody><tr><th rowspan="2">Prefix</th><th>Namespace</th></tr><tr><th>Notes</th></tr><tr><td rowspan="2">xop</td><td>"http://www.w3.org/2004/08/xop/include"</td></tr><tr><td>
		A non-normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1: Structures Second Edition]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> document for the
		"http://www.w3.org/2004/08/xop/include"
		namespace can be found at <a href="http://www.w3.org/2004/08/xop/include">http://www.w3.org/2004/08/xop/include</a>. Note that XML Schema
&gt; currently provides only for validation of XML 1.0 Infosets;  accordingly,
&gt; the schema may not be usable
&gt; with XOP Infosets corresponding to later versions of XML.
	      </td></tr><tr><td rowspan="2">xmlmime</td><td>"http://www.w3.org/2004/11/xmlmime"</td></tr><tr><td>
		The namespace for the content type attribute.
	      </td></tr><tr><td rowspan="2">soap</td><td>"http://www.w3.org/2003/05/soap-envelope"</td></tr><tr><td>
			The SOAP 1.2 namespace<a href="#">[SOAP12]</a>.
	      </td></tr><tr><td rowspan="2">xs</td><td>"http://www.w3.org/2001/XMLSchema"</td></tr><tr><td>
		The namespace of XML Schema data types <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a>.
	      </td></tr></tbody></table></div></div><table border="1" summary="Editorial note: HR"><tr><td align="left" valign="top" width="50%"><b>Editorial note: HR</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">Note that the "http://www.w3.org/2004/11/xmlmime"
	URI is not final and will be changed to track the evolution of the
	<a href="http://www.w3.org/TR/xml-media-types">"Assigning Media Types to Binary Data in XML"</a> document.
      </td></tr></table><div class="div1">
<h2><a name="xop_infosets" id="xop_infosets"></a>2 XOP Infoset Constructs</h2><p>
	XOP operates by extracting the Optimized Content from the Original
	Infoset to create the XOP Infoset. In particular, the <em>character
	  information item</em> children of <em>element information
	  items</em> to be optimized are removed and replaced with an
	<em>element information item</em> named <code>xop:Include</code>.
	The <code>xop:Include</code> <em> element information item</em>
	contains an <em> attribute information item</em> with a link to
	the part of the XOP Package that carries a binary representation of the
	data removed from the original <em> element information item</em>.
	Details of the construction and processing of XOP serializations are
	provided in <a href="#xop_processing_model"><b>3 XOP Processing Model</b></a>.
      </p><p>
	The Infoset used as input to XOP processing MUST NOT contain any
	<em>element information item</em> with a [namespace name]
	property of "http://www.w3.org/2004/08/xop/include"
	and a [local name] property of <code>Include</code>.  Infosets
	containing such <em> element information items</em> cannot be
	serialized using XOP. This is because during infoset reconstruction
	a processor is unable to differentiate between
	<code>xop:Include</code> <em> element information items</em> inserted during XOP package
	construction and those that were part of the original infoset.
      </p><p>
	The following subsections provide formal definitions for allowable content in the
	<em>element information item</em> and <em>attribute information
	  items</em> used to construct a XOP serialization; content not explicitly specified
	  is disallowed. A non-normative XML Schema for <a href="#XML">[Extensible Markup Language (XML) 1.0 (Third Edition)]</a> serializations of those
	<em>element information item</em> and <em> attribute
	  information items</em> can be found at <a href="http://www.w3.org/2004/08/xop/include">http://www.w3.org/2004/08/xop/include</a>.
      </p><div class="div2">
<h3><a name="xop_include" id="xop_include"></a>2.1 <code>xop:Include</code> element information item</h3><p>
	  The <code>xop:Include</code> <em> element information item</em>
	  has:
	</p><ul><li>
	    A [local name] of <code>Include</code>.
	  </li><li>
	    A [namespace name] of
	    "http://www.w3.org/2004/08/xop/include".
	  </li><li>
	    One or more <em>attribute information items</em>
	    amongst its [attributes] property as follows:

	    <ul><li>
			A mandatory <code>href</code><em> attribute information
			item</em> (see <a href="#xop_href"><b>2.2 href attribute information item</b></a>).
		  </li><li>
			Zero or more additional namespace qualified <em>attribute information
		  items</em>. Any such <em>attribute information items</em> MUST NOT have a [namespace name] of
		"http://www.w3.org/2004/08/xop/include", MUST NOT change
		the semantics of processing the <code>xop:Include</code><em> element information item</em> and MUST be ignored if
		not recognized.
	      </li></ul></li><li>
	    Zero or more namespace qualified <em>element
	      information items</em> in its [children] property. Any such
	    <em>element information items</em> MUST NOT have a [namespace name]
	    of "http://www.w3.org/2004/08/xop/include", MUST
	    NOT change the semantics of processing the <code>xop:Include</code><em> element information item</em> and MUST be ignored if not recognized.
	  </li></ul></div><div class="div2">
<h3><a name="xop_href" id="xop_href"></a>2.2 <code>href</code> attribute information item</h3><p>
	  The <code>href</code> <em> attribute information item</em> has:
	</p><ul><li>
	    A [local name] of <code>href</code>.
	  </li><li>
	    An empty [namespace name].
	  </li><li>
	    A [normalized value] which is a representation of a URI (see
	    <a href="#RFC2396">[RFC 2396]</a> as amended by <a href="#RFC2732">[RFC 2732]</a>)
	    referencing the part of the package containing the data logically
	    included by the [owner element] (i.e., the <code>xop:Include</code><em> element information item</em>). The [normalized value] MUST be a
		valid URI per the cid: URI scheme (see <a href="#RFC2392">[RFC 2392]</a>). In addition,
		the [normalized value] MUST be a valid lexical form of the XML Schema <code>xs:anyURI</code>
	    datatype (see <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI">3.2.17
	      anyURI</a>).
	  </li><li>
	    An [owner element] which is the <code>xop:Include</code><em> element information item</em> containing the
	    <em> attribute information item</em>.
	  </li></ul></div></div><div class="div1">
<h2><a name="xop_processing_model" id="xop_processing_model"></a>3 XOP Processing Model</h2><p>
	This section describes the processing model for creating XOP Packages
	and interpreting XOP Packages.  Unless otherwise stated, the result of
	such processing MUST be semantically equivalent to performing the
	specified steps separately, and in the order given.
      </p><div class="div2">
<h3><a name="creating_xop_packages" id="creating_xop_packages"></a>3.1 Creating XOP Packages</h3><p>
	  To create a XOP Package from an Original XML Infoset:
	</p><ol class="enumar"><li>
	    Ensure that the Original XML Infoset contains no <em>element
	      information item</em> with a [namespace name] of
	    "http://www.w3.org/2004/08/xop/include" and a [local
	    name] of <code>Include</code>. As discussed in <a href="#xop_infosets"><b>2 XOP Infoset Constructs</b></a>, XML Infosets with such <em> element
	      information items</em> cannot be represented using XOP.
	  </li><li>
	    Create an empty package.
	  </li><li>
	    Identify within the Original XML Infoset the <em>element
	      information items</em> to be optimized. To be optimized, the
	    characters comprising the [children] of the <em>element
	      information item</em> MUST be in the canonical form of
	    <code>xs:base64Binary</code> (see <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary">3.2.16
	  base64Binary</a>) and MUST NOT contain any whitespace
	    characters, preceding, inline with or following the non-whitespace
	    content.
	  </li><li>
	    Create a XOP Infoset which is a copy of the Original XML Infoset,
	    but with the [children] of each <em>element
	      information item</em>
	    identified in the previous step replaced by a
	    <code>xop:Include</code><em> element
	      information item</em> (see <a href="#xop_include"><b>2.1 xop:Include element information item</b></a>) constructed as follows:

	    <ol class="enumla"><li>
		Transform the replaced characters into binary data by
		processing them as base64-encoded data.
	      </li><li>
		Serialize the binary data into a new part of the package, with
		appropriate metadata corresponding to the [normalized value] of
		the <code>href</code><em> attribute information item</em> of
		the <code>xop:Include</code><em> element information
		  item</em> (see <a href="#xop_href"><b>2.2 href attribute information item</b></a>).
	      </li><li>
		If the <em>element information item</em> being optimized
		(i.e., the [parent] of the newly inserted
		<code>xop:Include</code><em> element information item</em>)
		has a <code>xmlmime:contentType</code><em> attribute
		  information item</em>, its value SHOULD be reflected
		appropriately in the metadata for the part.
	      </li></ol></li><li>
	    Serialize the resulting XOP Infoset into the package using any W3C
	    recommendation-level version of XML (e.g., <a href="#XML">[Extensible Markup Language (XML) 1.0 (Third Edition)]</a>,
	    <a href="#XML1.1">[Extensible Markup Language (XML) 1.1]</a>) 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 <a href="#identifying_xop_documents"><b>5 Identifying XOP Documents</b></a>.
	  </li></ol><p>
	  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.
	</p><p>
	  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.
	</p></div><div class="div2">
<h3><a name="interpreting_xop_packages" id="interpreting_xop_packages"></a>3.2 Interpreting XOP Packages</h3><p>
	  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 <a href="#creating_xop_packages"><b>3.1 Creating XOP Packages</b></a>.
	</p><p>
	  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.
	</p><p>
	  To create a Reconstituted XML Infoset from a XOP Package:
	</p><ol class="enumar"><li>
	    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 <a href="#XML">[Extensible Markup Language (XML) 1.0 (Third Edition)]</a>.
	  </li><li>
	    Using that XML Infoset, for each <em>element information
	      item</em>, E,  which has, as the sole member of its [children] property, a <code>xop:Include</code><em> element information item</em> (as defined in <a href="#xop_include"><b>2.1 xop:Include element information item</b></a>):

	    <ol class="enumla"><li>
		Locate the part of the package corresponding to the URI in the
		<code>href</code><em> attribute information item</em> of
		the <code>xop:Include</code><em> element information item</em> (i.e., corresponding to the URI
		encoded in the <em> attribute information item</em>'s
		[normalized value]).
	      </li><li>
		Replace the <code>xop:Include</code><em> element information item</em> that appears in the
		[children] property of E with <em> character information items</em> representing
		the canonical base64 encoding of the entity body of the
		identified package part (i.e., effectively replace the
		<code>xop:Include</code><em> element information item</em>
		with the data reconstructed from the
		package part).
	      </li></ol></li></ol></div></div><div class="div1">
<h2><a name="xop_packages" id="xop_packages"></a>4 XOP Packages</h2><p>
	XOP is capable of using a variety of underlying packaging mechanisms.
	Such packaging mechanisms MUST be able to represent, with full fidelity
	all the parts created according to <a href="#xop_processing_model"><b>3 XOP Processing Model</b></a> (see <a href="#creating_xop_packages"><b>3.1 Creating XOP Packages</b></a>), and MUST be used in a manner that provides a
	  means of designating a distinguished root (main, primary etc.) part.
      </p><p>
	The subsection below specifies normatively how a particular packaging
	mechanism, MIME Multipart/Related, is used, but does not preclude the
	use of other packaging mechanisms with the XOP convention.
      </p><div class="div2">
<h3><a name="mime_xop_packages" id="mime_xop_packages"></a>4.1 MIME Multipart/Related XOP Packages</h3><p>
	  This section describes how MIME Multipart/Related packaging (as
	  specified in <a href="#RFC2387">[RFC 2387]</a>) is used with XOP.
	</p><p>
	  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., <a href="#XML">[Extensible Markup Language (XML) 1.0 (Third Edition)]</a>, <a href="#XML1.1">[Extensible Markup Language (XML) 1.1]</a>), 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).
	</p><p>
	  Except for purposes of determining the root MIME part, as specified
	  by <a href="#RFC2387">[RFC 2387]</a>, ordering of MIME parts MUST NOT be
	  considered significant to XOP processing or to the construction of
	  the XOP Infoset.
	</p><p>
	  Part metadata is reflected in MIME header fields. Specifically,
	  the URI used in the value of an <code>href</code> <em> attribute
	  information item</em> on a <code>xop:Include</code> <em> element
	  information item</em> contains a URI that uses the 'cid:' scheme
	  (see <a href="#RFC2392">[RFC 2392]</a>), so the corresponding MIME
	  part MUST have a Content-ID header field (see <a href="#RFC2387">[RFC 2387]</a>
	  with a corresponding field-value.
	</p><p>
	  Furthermore, if a <code>xmlmime:contentType</code> <em> attribute
	    information item</em> is found (as described in <a href="#xop_processing_model"><b>3 XOP Processing Model</b></a>), it SHOULD be reflected in the field value
		of the MIME Content-Type header.
	</p></div></div><div class="div1">
<h2><a name="identifying_xop_documents" id="identifying_xop_documents"></a>5 Identifying XOP Documents</h2><p>XOP Documents, when used in MIME-like systems, are identified with
	  the "application/xop+xml" media type, with the required "type" parameter conveying
	  the original XML serialisation's associated content type. Note that when the type
	  parameter contains reserved characters, it needs to be appropriately quoted and escaped.</p><p>For example, a XOP package using MIME multipart/related packaging to serialize a
	  SOAP 1.2 message <a href="#W3C.soap-part1">[SOAP Version 1.2 Part 1: Messaging Framework]</a> with an action parameter of "http://www.example.net/foo"
	  would label the package itself with the "multipart/related"
	  media type, and the root part with the "application/xop+xml" media type along with a type parameter
	  containing "application/soap+xml;action=\"http://www.example.net/foo\"".
	  </p><div class="div2">
<h3><a name="id2270207" id="id2270207"></a>5.1 Registration</h3><dl><dt class="label">MIME media type name:</dt><dd><p>application</p></dd><dt class="label">MIME subtype name:</dt><dd><p>xop+xml</p></dd><dt class="label">Required parameters:</dt><dd><dl><dt class="label">type</dt><dd><p>This parameter conveys the content type associated with the XML serialization of the XOP infoset, including parameters as appropriate.</p></dd></dl></dd><dt class="label">Optional parameters:</dt><dd><dl><dt class="label">charset</dt><dd><p>This parameter has identical semantics to the charset parameter
				  of the "application/xml" media type as specified in
				  RFC 3023 <a href="#">[RFC3023]</a>.</p></dd></dl></dd><dt class="label">Encoding considerations:</dt><dd><p>Identical to those of "application/xml"
			as described in RFC 3023 <a href="#">[RFC3023]</a>,
			section 3.2.</p></dd><dt class="label">Security considerations:</dt><dd><p>In addition to application-specific considerations, XOP has the same
			security considerations described in RFC3023 <a href="#">[RFC3023]</a>,
			section 10.</p></dd><dt class="label">Interoperability considerations:</dt><dd><p>There are no known interoperability issues.</p></dd><dt class="label">Published specification:</dt><dd><p>This document</p></dd><dt class="label">Applications which use this media type:</dt><dd><p>No known applications currently use this media type.</p></dd><dt class="label">Additional information:</dt><dd><dl><dt class="label">File extension:</dt><dd><p>XOP</p></dd><dt class="label">Fragment identifiers:</dt><dd><p>Identical to that of "application/xml" as described in
				  RFC 3023 <a href="#">[RFC3023]</a>,
				  section 5.</p></dd><dt class="label">Base URI:</dt><dd><p>As specified in RFC 3023 <a href="#">[RFC3023]</a>, section 6.</p></dd><dt class="label">Macintosh File Type code:</dt><dd><p>TEXT</p></dd></dl></dd><dt class="label">Person and email address to contact for further information:</dt><dd><p>Mark Nottingham &lt;mnot@pobox.com&gt;</p></dd><dt class="label">Intended usage:</dt><dd><p>COMMON</p></dd><dt class="label">Author/Change controller:</dt><dd><p>The XOP specification is a work product of the World Wide Web Consortium's <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a>. The W3C has change control over this specification.</p></dd></dl></div></div><div class="div1">
<h2><a name="security_considerations" id="security_considerations"></a>6 Security Considerations</h2><div class="div2">
<h3><a name="package_integrity" id="package_integrity"></a>6.1 XOP Package Integrity</h3><p>
	  The integrity of Infosets optimized using XOP may need to be ensured.
	  As XOP packages can be transformed to recover such Infosets (see
	  <a href="#interpreting_xop_packages"><b>3.2 Interpreting XOP Packages</b></a>), 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.
	</p><p>
	  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.
	</p></div><div class="div2">
<h3><a name="package_confidentiality" id="package_confidentiality"></a>6.2 XOP Package Confidentiality</h3><p>
	  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 <a href="#XMLEnc">[XML Encryption Syntax and Processing]</a>) 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
	  <code>CipherData</code> <em> element information item</em> can then
	  be optimized because the content of such an <em> element information
	    item</em> is base64 characters.
	</p><p>
	  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.
	</p></div></div></div><div class="back"><div class="div1">
<h2><a name="relation_other_specifications" id="relation_other_specifications"></a>A Relationship to other specifications</h2><p>
	This appendix summarizes the XOP dependencies upon underlying
	specifications, the nature of appropriate payloads for XOP and the
	means of extending XOP.
      </p><div class="div2">
<h3><a name="dependencies" id="dependencies"></a>A.1 Dependencies</h3><p>
	  The XOP convention builds upon a number of underlying specifications.
	  They are:
	</p><ul><li><p>
	      XML (e.g., <a href="#XML">[Extensible Markup Language (XML) 1.0 (Third Edition)]</a>, <a href="#XML1.1">[Extensible Markup Language (XML) 1.1]</a>) - The XOP
	      Document is encoded using any W3C recommendation-level version of
	      XML (see <a href="#creating_xop_packages"><b>3.1 Creating XOP Packages</b></a>). 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.
	    </p></li><li><p>
	      Namespaces in XML (e.g., <a href="#XMLNS">[Namespaces in XML]</a>, <a href="#XMLNS1.1">[Namespaces in XML 1.1]</a>) - 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.
	    </p></li><li><p>
	      Uniform Resource Identifiers (see <a href="#RFC2396">[RFC 2396]</a>) - The
	      XOP Document uses URIs to locate parts in the XOP Package (see
	      <a href="#xop_href"><b>2.2 href attribute information item</b></a>. 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.
	    </p></li><li><p>
	      Packaging Mechanism - XOP requires the use of a packaging
	      mechanism that satisfies the requirements in <a href="#xop_packages"><b>4 XOP Packages</b></a>. 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.
	    </p><p>
	      The relationship of one such mechanism to XOP, The MIME
	      Multipart/Related Content-type, is specified in <a href="#mime_xop_packages"><b>4.1 MIME Multipart/Related XOP Packages</b></a>.
	    </p></li></ul></div><div class="div2">
<h3><a name="payload" id="payload"></a>A.2 Payload</h3><p>
	  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 an
	  <em>element information item</em> with a [local name] of of
	  <code>Include</code> 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
	  Schema <code>base64Binary</code> datatype (see <a href="#XMLSchemaP2">[XML Schema Part 2: Datatypes Second Edition]</a> <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary">3.2.16
	    base64Binary</a>).
	</p></div><div class="div2">
<h3><a name="extension" id="extension"></a>A.3 Extension</h3><p>
	  XOP Documents allow extensions to the <code>xop:Include</code> 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 new
	  <code>Include</code> <em> element information item</em> in another
	  namespace).
	</p><p>
	  The extensibility of the specifications underlying XOP is not
	  constrained by their use in XOP.
	</p></div><div class="div2">
<h3><a name="requirements" id="requirements"></a>A.4 Requirements</h3><p>
	  This document along with <a href="#MTOM">[SOAP Message Transmission Optimization Mechanism]</a>
	  and <a href="#">[SOAP Representation Header]</a> has been produced in conjunction
	  with the development of requirements
	  embodied in the <a href="#ucr">[SOAP Optimized Serialization Use Cases and Requirements]</a> document.
	</p></div></div><div class="div1">
<h2><a name="references" id="references"></a>B References</h2><div class="div2">
<h3><a name="normative_references" id="normative_references"></a>B.1 Normative References</h3><dl><dt class="label"><a name="XML" id="XML"></a>Extensible Markup Language (XML) 1.0 (Third Edition)</dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xml-20040204"><cite>Extensible Markup
	Language (XML) 1.0 (Third Edition)</cite></a>, Jean Paoli, Eve Maler,
	Tim Bray, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 04 February 2004.
	This version is http://www.w3.org/TR/2004/REC-xml-20040204.
	The <a href="http://www.w3.org/TR/REC-xml">latest version</a> is
	available at http://www.w3.org/TR/REC-xml.</dd><dt class="label"><a name="XML1.1" id="XML1.1"></a>Extensible Markup Language (XML) 1.1</dt><dd>
        <a href="http://www.w3.org/TR/2004/REC-xml11-20040204/"><cite>Extensible Markup
	Language (XML) 1.1</cite></a>, John Cowan, C. M. Sperberg-McQueen,
	François Yergeau, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 04 February 2004.
	This version is http://www.w3.org/TR/2004/REC-xml11-20040204/.
	The <a href="http://www.w3.org/TR/xml11/">latest version</a> is
	available at http://www.w3.org/TR/xml11/.</dd><dt class="label"><a name="MTOM" id="MTOM"></a>SOAP Message Transmission Optimization Mechanism</dt><dd>
        <a href="http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/"><cite>SOAP Message
	Transmission Optimization Mechanism</cite></a>, 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/.
	The <a href="http://www.w3.org/TR/soap12-mtom/">latest version</a> is
	available at http://www.w3.org/TR/soap12-mtom/.</dd><dt class="label"><a name="rep" id="rep"></a>Resource Representation SOAP Header Block</dt><dd>
	 <a href="http://www.w3.org/TR/2005/REC-soap12-rep-20050125/"><cite>Resource
	 Representation SOAP Header Block</cite></a>, 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/.
	 The <a href="http://www.w3.org/TR/soap12-rep/">latest version</a> is
	 available at http://www.w3.org/TR/soap12-rep/.</dd><dt class="label"><a name="ucr" id="ucr"></a>SOAP Optimized Serialization Use Cases and Requirements</dt><dd>
	<a href="http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/"><cite>SOAP Optimized
	Serialization Use Cases and Requirements</cite></a>, 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/.
	The <a href="http://www.w3.org/TR/soap12-os-ucr/">latest version</a>
	is available at http://www.w3.org/TR/soap12-os-ucr/.</dd><dt class="label"><a name="XMLNS" id="XMLNS"></a>Namespaces in XML</dt><dd>
	<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114"><cite>Namespaces in
	XML</cite></a>, 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.
	The <a href="http://www.w3.org/TR/REC-xml-names">latest version</a> is
	available at http://www.w3.org/TR/REC-xml-names.</dd><dt class="label"><a name="XMLNS1.1" id="XMLNS1.1"></a>Namespaces in XML 1.1</dt><dd>
        <a href="http://www.w3.org/TR/2004/REC-xml-names11-20040204"><cite>Namespaces in
	XML 1.1</cite></a>, 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.
	The <a href="http://www.w3.org/TR/xml-names11/">latest version</a> is
	available at http://www.w3.org/TR/xml-names11/.</dd><dt class="label"><a name="XMLInfoset" id="XMLInfoset"></a>XML Information Set (Second Edition)</dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"><cite>XML Information Set
	(Second Edition)</cite></a>, 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.
	The <a href="http://www.w3.org/TR/xml-infoset">latest version</a> is
	available at http://www.w3.org/TR/xml-infoset.</dd><dt class="label"><a name="XMLSchemaP1" id="XMLSchemaP1"></a>XML Schema Part 1: Structures Second Edition</dt><dd>
        <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1:
	Structures Second Edition</cite></a>, 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/.
	The <a href="http://www.w3.org/TR/xmlschema-1/">latest version</a> is
	available at http://www.w3.org/TR/xmlschema-1/.</dd><dt class="label"><a name="XMLSchemaP2" id="XMLSchemaP2"></a>XML Schema Part 2: Datatypes Second Edition</dt><dd>
	<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2:
	Datatypes Second Edition</cite></a>, 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/.
	The <a href="http://www.w3.org/TR/xmlschema-2/">latest version</a> is
	available at http://www.w3.org/TR/xmlschema-2/.</dd><dt class="label"><a name="xmlmime" id="xmlmime"></a>Assigning Media Types to Binary Data in XML</dt><dd>
	<a href="http://www.w3.org/TR/2004/WD-xml-media-types-20041102"><cite>Assigning Media
	Types to Binary Data in XML</cite></a>,
	Ü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.
	The <a href="http://www.w3.org/TR/xml-media-types">latest version</a>
	is available at http://www.w3.org/TR/xml-media-types.</dd><dt class="label"><a name="RFC2119" id="RFC2119"></a>RFC 2119</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for
	use in RFCs to Indicate Requirement Levels</cite></a>, S. Bradner,
	Editor.
	IETF, March 1997.
	This RFC is available at http://www.ietf.org/rfc/rfc2119.txt.</dd><dt class="label"><a name="RFC2387" id="RFC2387"></a>RFC 2387</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2387.txt"><cite>The MIME
	Multipart/Related Content-type</cite></a>, E. Levinson,
	Editor.
	IETF, August 1998.
	This RFC is available at http://www.ietf.org/rfc/rfc2387.txt.</dd><dt class="label"><a name="RFC2557" id="RFC2557"></a>RFC 2557</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2557.txt"><cite>MIME
	Encapsulation of Aggregate Documents, such as HTML (MHTML)</cite></a>,
	J. Palme, A. Hopmann and N. Shelness, Editors.
	IETF, March 1999.
	This RFC is available at http://www.ietf.org/rfc/rfc2557.txt.</dd><dt class="label"><a name="RFC2392" id="RFC2392"></a>RFC 2392</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2392.txt"><cite>Content-ID and
	Message-ID Uniform Resource Locators</cite></a>,
	E. Levinson, Editor.
	IETF, August 1998.
	This RFC is available at http://www.ietf.org/rfc/rfc2392.txt.</dd><dt class="label"><a name="RFC2396" id="RFC2396"></a>RFC 2396</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource
	Identifiers (URI): Generic Syntax</cite></a>, T. Berners-Lee,
	R. Fielding and L. Masinter, Editors.
	IETF, August 1998.
	This RFC is available at http://www.ietf.org/rfc/rfc2396.txt.</dd><dt class="label"><a name="RFC2732" id="RFC2732"></a>RFC 2732</dt><dd>
	<a href="http://www.ietf.org/rfc/rfc2732.txt"><cite>Format for
	Literal IPv6 Addresses in URL's</cite></a>,
	R. Hinden, B. Carpenter and L. Masinter, Editors.
	IETF, December 1999.
	This RFC is available at http://www.ietf.org/rfc/rfc2732.txt.</dd></dl></div><div class="div2">
<h3><a name="informative_references" id="informative_references"></a>B.2 Informative References</h3><dl><dt class="label"><a name="C14N" id="C14N"></a>Canonical XML Version 1.0</dt><dd>
	<a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"><cite>Canonical XML Version 1.0</cite></a>, John Boyer, Editor.
	World Wide Web Consortium, 15 March 2001.
        This version is http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
        The <a href="http://www.w3.org/TR/xml-c14n">latest version</a> is
	available at http://www.w3.org/TR/xml-c14n.</dd><dt class="label"><a name="EXCC14N" id="EXCC14N"></a>Exclusive XML Canonicalization Version 1.0</dt><dd>
        <a href="http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/"><cite>Exclusive XML Canonicalization Version 1.0</cite></a>,
	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/.
	The <a href="http://www.w3.org/TR/xml-exc-c14n">latest version</a> is
	available at http://www.w3.org/TR/xml-exc-c14n.</dd><dt class="label"><a name="XMLEnc" id="XMLEnc"></a>XML Encryption Syntax and Processing</dt><dd>
	<a href="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/"><cite>XML Encryption Syntax and Processing</cite></a>,
	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/.
        The <a href="http://www.w3.org/TR/xmlenc-core/">latest version</a> is
	available at http://www.w3.org/TR/xmlenc-core/.</dd><dt class="label"><a name="W3C.soap-part1" id="W3C.soap-part1"></a>SOAP Version 1.2 Part 1: Messaging Framework</dt><dd>
     	<a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/"><cite>SOAP
	Version 1.2 Part 1: Messaging Framework</cite></a>, Marc Hadley,
	Noah Mendelsohn, Jean-Jacques Moreau, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 24 June 2003.
	This version is http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
	The <a href="http://www.w3.org/TR/soap12-part1/">latest version</a> is
	available at http://www.w3.org/TR/soap12-part1/.</dd><dt class="label"><a name="W3C.soap-part2" id="W3C.soap-part2"></a>SOAP Version 1.2 Part 2: Adjuncts</dt><dd>
	<a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/"><cite>SOAP
	Version 1.2 Part 2: Adjuncts</cite></a>, Henrik Frystyk Nielsen,
	Noah Mendelsohn, Jean-Jacques Moreau, <em>et. al.</em>, Editors.
	World Wide Web Consortium, 24 June 2003.
	This version is http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.
	The <a href="http://www.w3.org/TR/soap12-part2/">latest version</a> is
	available at http://www.w3.org/TR/soap12-part2/.</dd></dl></div></div><div class="div1">
<h2><a name="acks" id="acks"></a>C Acknowledgements (Non-Normative)</h2><p>This specification is the work of the W3C XML Protocol Working Group.</p><p>Participants in the Working Group are (at the time of writing, and by
      alphabetical order): David Fallside (IBM),
Tony Graham (Sun Microsystems),
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
Marc Hadley (Sun Microsystems),
Gerd Hoelzing (SAP AG),
John Ibbotson (IBM),
Anish Karmarkar (Oracle),
Suresh Kodichath (IONA Technologies),
Yves Lafon (W3C),
Michael Mahan (Nokia),
Noah Mendelsohn (IBM, formerly of Lotus Development),
Jeff Mischkinsky (Oracle),
Jean-Jacques Moreau (Canon),
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
David Orchard (BEA Systems, formerly of Jamcracker),
Herve Ruellan (Canon),
Jeff Schlimmer (Microsoft Corporation),
Pete Wenzel (SeeBeyond),
Volker Wiechers (SAP AG).
</p><p>Previous participants were: Yasser alSafadi (Philips Research),
Bill Anderson (Xerox),
Vidur Apparao (Netscape),
Camilo Arbelaez (webMethods),
Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems),
Philippe Bedu (EDF (Electricite De France)),
Olivier Boudeville (EDF (Electricite De France)),
Carine Bournez (W3C),
Don Box (Microsoft Corporation, formerly of DevelopMentor),
Tom Breuel (Xerox),
Dick Brooks (Group 8760),
Winston Bumpus (Novell, Inc.),
David Burdett (Commerce One),
Charles Campbell (Informix Software),
Alex Ceponkus (Bowstreet),
Michael Champion (Software AG),
David Chappell (Sonic Software),
Miles Chaston (Epicentric),
David Clay (Oracle),
David Cleary (Progress Software),
Dave Cleary (webMethods),
Ugo Corda (Xerox),
Paul Cotton (Microsoft Corporation),
Fransisco Cubera (IBM),
Jim d'Augustine (Excelon Corporation),
Ron Daniel (Interwoven),
Glen Daniels (Macromedia),
Doug Davis (IBM),
Ray Denenberg (Library of Congress),
Paul Denning (MITRE Corporation),
Frank DeRose (TIBCO Software, Inc.),
Mike Dierken (DataChannel),
Andrew Eisenberg (Progress Software),
Brian Eisenberg (DataChannel),
Colleen Evans (Sonic Software),
John Evdemon (XMLSolutions),
David Ezell (Hewlett Packard),
James Falek (TIBCO Software, Inc.),
Eric Fedok (Active Data Exchange),
Chris Ferris (Sun Microsystems),
Daniela Florescu (Propel),
Dan Frantz (BEA Systems),
Michael Freeman (Engenia Software),
Dietmar Gaertner (Software AG),
Scott Golubock (Epicentric),
Mike Greenberg (IONA Technologies),
Rich Greenfield (Library of Congress),
Hugo Haas (W3C),
Mark Hale (Interwoven),
Randy Hall (Intel),
Bjoern Heckel (Epicentric),
Frederick Hirsch (Zolera Systems),
Erin Hoffmann (Tradia Inc.),
Steve Hole (MessagingDirect Ltd.),
Mary Holstege (Calico Commerce),
Jim Hughes (Fujitsu Limited),
Oisin Hurley (IONA Technologies),
Yin-Leng Husband (Hewlett Packard, formerly of Compaq),
Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.),
Scott Isaacson (Novell, Inc.),
Kazunori Iwasa (Fujitsu Limited),
Murali Janakiraman (Rogue Wave),
Mario Jeckle (DaimlerChrysler Research and Technology),
Eric Jenkins (Engenia Software),
Mark Jones (AT&amp;T),
Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software),
Richard Koo (Vitria Technology Inc.),
Jacek Kopecky (Systinet),
Alan Kropp (Epicentric),
Julian Kumar (Epicentric),
Peter Lecuyer (Progress Software),
Tony Lee (Vitria Technology Inc.),
Michah Lerner (AT&amp;T),
Bob Lojek (Intalio Inc.),
Henry Lowe (OMG),
Brad Lund (Intel),
Matthew MacKenzie (XMLGlobal Technologies),
Murray Maloney (Commerce One),
Richard Martin (Active Data Exchange),
Alex Milowski (Lexica),
Kevin Mitchell (XMLSolutions),
Nilo Mitra (Ericsson),
Ed Mooney (Sun Microsystems),
Dean Moses (Epicentric),
Highland Mary Mountain (Intel),
Don Mullen (TIBCO Software, Inc.),
Rekha Nagarajan (Calico Commerce),
Raj Nair (Cisco Systems),
Masahiko Narita (Fujitsu Limited),
Mark Needleman (Data Research Associates),
Art Nevarez (Novell, Inc.),
Eric Newcomer (IONA Technologies),
Henrik Nielsen (Microsoft Corporation),
Conleth O'Connell (Vignette),
Kevin Perkins (Compaq),
Jags Ramnaryan (BEA Systems),
Andreas Riegg (DaimlerChrysler Research and Technology),
Vilhelm Rosenqvist (NCR),
Marwan Sabbouh (MITRE Corporation),
Waqar Sadiq (Vitria Technology Inc.),
Rich Salz (Zolera Systems),
Krishna Sankar (Cisco Systems),
George Scott (Tradia Inc.),
Shane Sesta (Active Data Exchange),
Lew Shannon (NCR),
John-Paul Sicotte (MessagingDirect Ltd.),
Miroslav Simek (Systinet),
Simeon Simeonov (Macromedia),
Aaron Skonnard (DevelopMentor),
Nick Smilonich (Unisys),
Seumas Soltysik (IONA Technologies),
Soumitro Tagore (Informix Software),
James Tauber (Bowstreet),
Anne Thomas Manes (Sun Microsystems),
Lynne Thompson (Unisys),
Patrick Thompson (Rogue Wave),
Jim Trezzo (Oracle),
Asir Vedamuthu (webMethods),
Randy Waldrop (WebMethods),
Fred Waskiewicz (OMG),
David Webber (XMLGlobal Technologies),
Ray Whitmer (Netscape),
Stuart Williams (Hewlett Packard),
Yan Xu (DataChannel),
Amr Yassin (Philips Research),
Susan Yee (Active Data Exchange),
Jin Yu (MartSoft Corp.).
</p><p>The people who have contributed to discussions on
<a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>
are also gratefully acknowledged.</p></div></div></body></html>