index.html 28.7 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Known Issues with Canonical XML 1.0 (C14N/1.0)</title><style type="text/css">
code           { font-family: monospace; }

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

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }


div.assertion { border: 4px double gray; padding: 0.5em; margin-bottom: 0.2em; }
blockquote { background-color: #eeeeee; }
spectext { background-color: #eeeeee; }
.message { background-color: #d5dee3; }


pre { margin-left: 4em}

p.diff-chg,
li.diff-chg,
h1.diff-chg,
h2.diff-chg,
h3.diff-chg,
h4.diff-chg,
h5.diff-chg,
h6.diff-chg,
td.diff-chg,
tr.diff-chg     { background-color: #E47833; }
p.diff-del,
li.diff-del,
h1.diff-del,
h2.diff-del,
h3.diff-del,
h4.diff-del,
h5.diff-del,
h6.diff-del,
td.diff-del,
tr.diff-del     { background-color: red; text-decoration: line-through;}
p.diff-add,
p.diff-add,
h1.diff-add,
h2.diff-add,
h3.diff-add,
h4.diff-add,
h5.diff-add,
h6.diff-add,
td.diff-add,
tr.diff-add    { background-color: lime; }
table          { empty-cells: show; }


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}
div.table,
div.figure	 {margin-top: 2em;
		  margin-bottom: 2em;
		  text-align: center; }
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"></head><body>

  <div class="head"><p><a href="http://www.w3.org/"><img height="48" width="72" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
<h1>Known Issues with Canonical XML 1.0 (C14N/1.0)</h1>
<h2>W3C Working Group Note 20 December 2006</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/">http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/C14N-issues/">http://www.w3.org/TR/C14N-issues/</a></dd><dt>Previous versions:</dt><dd><a href="http://www.w3.org/TR/2006/WD-C14N-issues-20060915/">http://www.w3.org/TR/2006/WD-C14N-issues-20060915/</a></dd><dt>Editors:</dt>
      <dd>José Kahan, <a href="http://www.w3.org/">W3C</a></dd>
      <dd>Konrad Lanz, <a href="http://www.a-sit.at/">A-SIT</a></dd>
    </dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©2006 <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">Abstract</a></h2>


<p>This technical note addresses some of the issues related to
inheritance of the XML attributes <code>xml:base</code> and <code>xml:id</code> and the W3C
Recommendation for Canonical XML Version 1.0 [<a href="#C14N10">C14N10</a>] (<a href="http://www.w3.org/2001/03/C14N-errata">Errata</a>). Shortcomings of C14N/1.0
are noted out and the use of a new C14N/1.1 recommendation
with the XML Digital Signature 1.0 Recommendation  [<a href="#XMLDSIG">XMLDSIG</a>]  is discussed.


</p>

</div><div>
<h2><a name="status">Status of this Document</a></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/" shape="rect">W3C technical
reports index</a> at http://www.w3.org/TR/.</em></p>

<p>This is the <a href="http://www.w3.org/2005/10/Process-20051014/tr.html#q75">W3C
Working Group Note</a> of "Known Issues with Canonical XML 1.0
(C14N/1.0)", produced by the <a href="http://www.w3.org/XML/Core/" shape="rect">XML Core Working Group</a>, as part of the <a href="http://www.w3.org/XML/Activity">XML Activity</a>. A
companion note, "XML Digital Signatures in the 2006 XML Environment"
[<a href="#XMLDSIG2006" shape="rect">XMLDSIG2006</a>], describes in
further detail how a revised canonicalization algorithm (C14N/1.1 or
other) may be used with the current XML-SIG/1.0 Specification.</p>


<p>Please send comments related to this document to <a href="mailto:www-xml-canonicalization-comments@w3.org" shape="rect">www-xml-canonicalization-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/" shape="rect">public archive</a>).</p>

<p>Publication as a Working Group Note does not imply endorsement by
the W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than work in
progress.</p>

<p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2002/08/xmlcore-IPR-statements">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>

</div>


<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#S1">Overview</a><br>2. <a href="#S2">Interaction with XML Base</a><br>3. <a href="#S3">Interaction with XML Id</a><br>4. <a href="#S4">Implicit use of Canonical XML 1.0 by XML Signature</a><br>5. <a href="#S5">Further considerations for C14N/1.1</a><br>6. <a href="#Ref">References</a><br>7. <a href="#Ack">Acknowledgments</a><br></p></div><hr><div class="toc">
<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#S1">Overview</a><br>2. <a href="#S2">Interaction with XML Base</a><br>    2.1 <a href="#S21">Inheriting xml:base values</a><br>    2.2 <a href="#S22">Special values of xml:base</a><br>3. <a href="#S3">Interaction with XML Id</a><br>4. <a href="#S4">Implicit use of Canonical XML 1.0 by XML Signature</a><br>5. <a href="#S5">Further considerations for C14N/1.1</a><br>    5.1 <a href="#S5_1">xml:base and URI reference simplification</a><br>    5.2 <a href="#S5_2">An XML infoset strategy for canonicalizing XML base</a><br>6. <a href="#Ref">References</a><br>7. <a href="#Ack">Acknowledgments</a><br></p>
<h3><a name="appendix" id="appendix">Appendix</a></h3><p class="toc"></p></div><hr><div class="body">

<div class="div1">

<h2><a name="S1"></a>1. Overview</h2>
	<p>Section 2.4 of the Canonical XML 1.0 [<a href="http://www.w3.org/TR/xml-c14n#DocSubsets">C14N10</a>]
	Specification defines special treatment for attributes in the
	<code>XML</code> namespace when a representation of a document subset
	is generated. The processing specified assumes that attributes in the
	XML namespace are inherited by copying them from the nearest ancestor.
	The inheritance rule given is appropriate for the processing of the <code>xml:space</code> and
	<code>xml:lang</code> attributes, but not for <code>xml:base</code>, which
	needs a special inheritance mechanism, or for <code>xml:id</code>, which
	should not be inherited at all.  [<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0004.html">XML-BASE-Problem</a>].</p>


	<p>Related problems exist in the Decryption Transform for XML
	Signature [<a href="#XMLENCDEC">XMLENCDEC</a>] W3C
	Recommendation, which applies a modified C14N/1.0 algorithm and
	adds additional rules concerning the copying of attributes in
	the <code>xml</code> namespace.  These rules are based on the
	same assumptions as their counterparts in C14N/1.0.</p>


</div>

<div class="div1">

<h2><a name="S2"></a>2. Interaction with XML Base</h2>

  <p>The XML Base Recommendation [<a href="#XMLBASE">XMLBASE</a>] defines
  the base URI of an element as the value of the element's
  <code>xml:base</code> attribute, the base URI of the element's
  parent element within the document or external entity, or the base
  URI of the document entity or external entity containing the
  element. In particular, the meaning of relative URI references in
  an <code>xml:base</code> attribute can depend on the chain of
  <code>xml:base</code> attributes along an element's ancestor axis.</p>

  <p>The canonicalization of <code>xml:base</code> requires a more
  specific algorithm than just copying or inheriting the values of
  preceding <code>xml:base</code> attributes. The following cases must
  be taken into account:</p>

  <ul>
		<li>
			<p><code>xml:base</code> values may consist of
			only a fragment identifier (this is a no-op)</p>
		</li>
		<li>
			<p><code>xml:base</code> values may be empty
			(this is a no-op)</p>
		</li>
		<li>
			<p><code>xml:base</code> values may be absolute or relative URI references</p>
		</li>
	</ul>

<div class="div2">

<h3><a name="S21"></a>2.1 Inheriting xml:base values</h3>

<p>Depending on the input node set to canonical xml, one can either
canonicalize a whole document or a subset of the document's nodes.
For example, in [<a href="#XMLDSIG">XMLDSIG</a>], one can use either
XPointer to dereference only parts of a document or XPath Filter and
XPath Filter 2.0 transforms to refer to a given fragment of the
document that one wants to sign.</p>

<p>Consider the following XML document (document 1):</p>

<div class="figure" id="document1">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
&lt;a xml:lang="en"&gt;
  &lt;b xml:base="http://www.example.org/pathseg1/" xml:lang="de"&gt;
	&lt;c&gt;
	&lt;/c&gt;
  &lt;/b&gt;
&lt;/a&gt;
	 </pre>
	</blockquote>
<p>Figure 1: Sample XML document 1</p>
</div>

<p>We now canonicalize document 1 with the input nodeset of c14n being
the element <code>&lt;c&gt;</code>. The element nodes along
<code>&lt;c&gt;</code>'s ancestor axis are examined for the first
occurence of any <code>xml</code> namespace axis, and these are then
merged into the attribute list of <code>&lt;c&gt;</code>.</p>

<div class="figure" id="document1-canonicalized">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
	&lt;c xml:base="http://www.example.org/pathseg1/" xml:lang="de"&gt;
	&lt;/c&gt;
	 </pre>
	</blockquote>
<p>Figure 2: Canonical form of sample XML document 1</p>
</div>

<p>The <code>xml:base</code> attribute on the <code>&lt;c/&gt;</code>
element in the canonicalized node-set indeed contains the base URI of
the <code>&lt;c/&gt;</code> element as present in document 1.</p>

<p>Up to now, there have been no problems with the simple duplication
of <code>xml:base</code> for maintaining the inheritance. However,
this is not always possible. Let's now consider the following XML
document (document 2):</p>

<div class="figure" id="document2">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
&lt;a xml:base="http://www.example.org/pathseg1/" xml:lang="en"&gt;
  &lt;b xml:base="../pathsegA/" xml:lang="de" &gt;
	&lt;c&gt;
	&lt;/c&gt;
  &lt;/b&gt;
&lt;/a&gt;
	 </pre>
	</blockquote>
<p>Figure 3: Sample XML document 2</p>
</div>


<p>We now canonicalize document 2, the input nodeset of c14n being the element &lt;c&gt;</p>

<div class="figure" id="document2-canonicalized">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
	&lt;c xml:base="../pathsegA/" xml:lang="de"&gt;
	&lt;/c&gt;
	 </pre>
	</blockquote>
<p>Figure 4: Canonical form of sample XML document 2</p>
</div>

<p>
In the case of <code>xml:lang</code>, copying the parent's
attributes allowed to retain the context. In the case of
<code>xml:base</code>, we have lost the context of how to resolve the
relative URI reference. Thus, for a given node-set, the application of the C14N/1.0
inheritance rule can lead to <code>xml:base</code>
attributes which specify a base URI that is different from the one
in the original document context.
</p>

</div>

<div class="div2">

<h3><a name="S22"></a>2.2 Special values of xml:base</h3>

<p>C14N/1.0 also has issues in that it doesn't know how to process
<code>xml:base</code> attributes that have no value or have values
that are a same-document (section 4.2 [<a href="#RFC2396">RFC
2396</a>]) reference.  As indicated by <a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Jun/0021">
Roy Fielding and Richard Tobin</a> these should be treated as do
nothing or no operation (noop) in <code>xml:base</code>.</p>

<p>Consider the following document located at (<code>file:///tmp/doc.xml</code>):</p>

<div class="figure" id="document3">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
&lt;a xml:base="http://www.example.org/pathseg1/"&gt;
  &lt;b xml:base="file.ext" xml:lang="de"&gt;
	&lt;c xml:base="" &gt;
	  &lt;d xml:base="" href="file.ext#some-id1"&gt;
	  &lt;/d&gt;
	  &lt;e xml:base="#some-fragment" href="file.ext#some-id2"&gt;
	  &lt;/e&gt;
	&lt;/c&gt;
  &lt;/b&gt;
&lt;/a&gt;
	 </pre>
	</blockquote>
<p>Figure 5: Sample XML document 3</p>
</div>

<p>We now canonicalize document 3 with the input nodeset of C14N/1.0 being
the element <code>&lt;c&gt;</code> and all its descendants:</p>

<div class="figure" id="document3-canonicalized">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
	&lt;c xml:base=""&gt;
	  &lt;d xml:base="" href="#some-id1"&gt;
	  &lt;/d&gt;
	  &lt;e xml:base="#some-fragment" href="#some-id2"&gt;
	  &lt;/e&gt;
	&lt;/c&gt;
	 </pre>
	</blockquote>
<p>Figure 6: Incorrect canonical form of sample XML document 3</p>
</div>

<p>As there already exists an <code>xml:base=""</code> attribute in
<code>&lt;c&gt;</code>, C14N/1.0 rules won't let <code>
&lt;c&gt;</code> inherit
<code>xml:base="http://www.example.org/pathseg1/file.ext"</code>.</p>

<p>Let's now consider the case that the node that has
<code>xml:base=""</code> is in the input-nodeset and that
<code>xml:base=""</code> is considered as a no operation (noop).
According to the C14N/1.0 rules, we would need to copy the ancestor's
value that is not in the input-nodeset. However, this would not
suffice.</p>

<p>The inheritance rules of the XML Base Recommendation [<a href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/#resolution">XMLBASE,
section 4</a>] allows for succesive use of relative references. Also,
such sucessive relative references may not be in the input node set
and hence not rendered.  So an inheritance rule for
<code>xml:base</code> would have to combine <code>xml:base=""</code>
with its omitted ancestors <code>xml:base</code> values. However this
is not stated.</p>

<p>A correct canonicalization of element &lt;c&gt; and all its
descendants that preserves the base URI from the original context
would be as follows:</p>

<div class="figure" id="document3-canonicalized-correctly">
	<blockquote>
	  <pre style="text-align: left">
&lt;?xml version="1.0"?&gt;
	&lt;c xml:base="http://www.example.org/pathseg1/file.ext" &gt;
	  &lt;d href="file.ext#some-id1"&gt;
	  &lt;/d&gt;
	  &lt;e href="file.ext#some-id2"&gt;
	  &lt;/e&gt;
	&lt;/c&gt;
	 </pre>
	</blockquote>
	<p>Figure 7: Correct canonical form of sample XML document 3</p>
</div>

</div>

</div>

<div class="div1">

<h2><a name="S3"></a>3. Interaction with XML Id</h2>

<p>The <code>xml:id</code> [<a href="#XMLID">XMLID</a>] attribute is part of the
XML information Set [<a href="#XMLINFOSET">XMLINFOSET</a>]. It allows
to associate any XML element with a unique identifier. Therefore, the
value of a given <code>xml:id</code> attribute is unique within an XML
document. The <code>xml:id</code> Recommendation was issued after
Canonical XML 1.0 had become a Recommendation.</p>

<p>The recommended C14N/1.0 processing behavior that requires
inheritance of attributes by copying them from the nearest ancestor
can produce badly-formed documents with respect to the <code>xml:id</code>
recommendation. Consider the following fragment of an XML
document:</p>

<blockquote>
  <pre>
	&lt;a xml:id="id_a"&gt;
	   &lt;b /&gt;
	   &lt;c /&gt;
       	&lt;/a&gt;
 </pre>
</blockquote>

<p>If we select the children of node <code>&lt;a&gt;</code> and apply the C14N/1.0
processing rules, both node <code>&lt;b&gt;</code> and
<code>&lt;c&gt;</code> would obtain a copy of <code>&lt;a&gt;</code>'s
<code>xml:id</code> attribute. This produces a badly-formed XML
document as two <code>xml:id</code> attributes have the same
value:</p>

<blockquote>
  <pre>
	   &lt;b xml:id="id_a" /&gt;
	   &lt;c xml:id="id_a" /&gt;
 </pre>
</blockquote>


<p>Note that even if only element inherited the <code>xml:id</code>
attribute, the result would still be wrong - the <code>xml:id</code>
attribute value would be assigned to the wrong element. For example,
let's now select node <code>&lt;b&gt;</code>. The C14N/1.0 processing would
assign node <code>&lt;a&gt;</code>'s <code>xml:id</code> attribute value
to node <code>&lt;b&gt;</code>:</p>

<blockquote>
  <pre>
	   &lt;b xml:id="id_a" /&gt;
 </pre>
</blockquote>

<p>Therefore, C14N/1.0 cannot be applied to documents containing
<code>xml:id</code> attributes. Inheritance of any <code>xml:id</code>
attributes would produce a wrong or a badly-formed document.</p>

</div>

<div class="div1">

<h2><a name="S4"></a>4. Implicit use of Canonical XML 1.0 by XML Signature</h2>

<p>XML Signature [<a href="#XMLDSIG">XMLDSIG</a>] identifies the
canonicalization method by an URI inside
<code>&lt;ds:CanonicalizationMethod&gt;</code> on a
<code>&lt;ds:SignedInfo&gt;</code> level. More importantly, the same
is needed on the data object or <code>&lt;ds:Manifest&gt;</code> level
by using a <code>&lt;ds:Transform&gt;</code> inside a
<code>&lt;ds:Reference&gt;</code>.  In the latter case, if no such
<code>&lt;ds:Transform&gt;</code> is given on the data object level,
and if a node-set is subject to a transformation that requires an
octet stream or is to be hashed using the message digest, the <a href="http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel">XML
Signature Reference Processing Model</a> uses Canonical XML C14N/1.0
implicitly to convert a node-set into an octet stream.</p>

<p>
If applications require processing according to a particular version
of Canonical XML, then they should explicitly give the appropriate
algorithm URI. Specifically, the following cases must be taken into
account:
</p>

  <ul>
		<li>
			<p>insert an explicit
			<code>&lt;ds:Transform&gt;</code>
			invoking a new version of Canonical XML before each
			<code>&lt;ds:Transform&gt;</code> that
			requires an octet stream as input, but is
			applied to a node-set</p>
		</li>
		<li>
			<p>if the previous transform
			outputs a note-set, append a <code>&lt;ds:Transform&gt;</code>
			invoking a new version of Canonical XML as the last
			<code>&lt;ds:Transform&gt;</code> before the
			digest input.</p>
		</li>
		<li>
			<p>use this URI inside <code>&lt;ds:CanonicalizationMethod&gt;</code></p>
		</li>
	</ul>

<p>
Such an approach, however, will increase the size and the complexity of
XML digital signatures.  Future versions of XML Signature [<a href="#XMLDSIG">XMLDSIG</a>] should consider the use of
<code>&lt;ds:CanonicalizationMethod&gt;</code> to specify a default
node-set to octet stream conversion method for the <a href="http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel">XML
Signature Reference Processing Model</a>.</p>

<p>One should also note that a lot of care will have to be taken on
future signature creation as all transforms (including the digest)
that require an octet stream as input but are applied to a node-set
will need to have such a revised version of Canonical XML as
<code>&lt;ds:Transform&gt;</code> before it is input.</p>

<p>For further information, please refer to the companion note, "XML
Digital Signatures in the 2006 XML Environment [<a href="#XMLDSIG2006">XMLDSIG2006</a>], which describes with more
detail how a revised canonicalization algorithm (C14N/1.1 or other)
may be used with the current XML-SIG/1.0 Specification.</p>

</div>


<div class="div1">

<h2><a name="S5"></a>5. Further considerations for C14N/1.1</h2>

<div class="div2">

<h3><a name="S5_1"></a>5.1 xml:base and URI reference simplification</h3>

<p>Inheritance rules will also have to be able to deal with relative
references having "./" and "../" segments apearing in the values for
<code>xml:base</code>.
</p>

<p>According to the rules laid down in the XML Base Recommendation [<a href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/#resolution">XMLBASE,
Section 4</a>], relative references are resolved against the
<code>xml:base</code> attribute of the element or element's
ancestor. This implies that relative references are absolutized and
normalized as specified in [<a href="#RFC2396">RFC 2396, Section
5.2</a>].</p>

<p>This operation can only be performed from the outermost to the
innermost relative reference.  Thus, there is no value in keeping dot
and dot-dot-segments when fixing up relative reference values of
<code>xml:base</code> when defining an inheritance rule for
canonicalizing <code>xml:base</code> attributes.</p>

<p>Some special considerations are needed. When normalizing a relative
URI reference, it is crucial to keep the leading "../" segments of
relative-path references. Otherwise, path-segments of ancestors'
<code>xml:base</code> URIs may not be removed appropriately.  Another
issue is that one could create erroneous output that looks similar to
that of a network-path reference when normalizing an absolute-path reference.
For instance, an incorrect
normalization of
<code>"seg/.././/pseudo-networkpath/seg/file.ext"</code>
would be <code>//pseudo-netpath/seg/file.ext</code>.</p>
<p>Note: [<a href="#RFC3986">RFC 3986, Section 4.2</a>] defines the terms
relative-path, network-path and absolute-path reference as used in
this document.
</p>

<p>The removal of dot-segments cause more logically equivalent
documents to produce the same canonicalized output. Furthermore, XML
Signatures [<a href="#XMLDSIG">XMLDSIG</a>] will benefit from such
normalization as the likelyhood of false negatives on signature
validation decreases.
</p>

</div>

<div class="div2">

<h3><a name="S5_2"></a>5.2 An XML infoset strategy for canonicalizing XML base</h3>

<p>
As stated earlier in this note, the rules for the inheritance of
<code>xml:base</code> require many considerations.  Another more
straight-forward approach would be to use a strategy based on the XML
infoset [<a href="#C14N-INFOSET">C14N-INFOSET</a>], namely:
</p>

<ul>
 <li>Use the name <code>EII</code> for an element information item to be
  canonicalized, and <code>EIIC</code> for the element information item
  corresponding to <code>EII</code> in the result of parsing the canonical
  serialization of the node-set containing <code>EII</code>.</li>

 <li>Synthesize an xml:base attribute for <code>EII</code> iff the
  <code>EIIC</code>'s [base URI] would otherwise be different from
  <code>EII</code>'s [base URI].</li>

</ul>

<p>This has the advantage that not only does it correctly produce</p>

<blockquote>
<pre>
&lt;a xml:base="http://example.org"&gt;
       &lt;c xml:base="test/" /&gt;
&lt;/a&gt;
</pre>
</blockquote>

<p>from</p>

<blockquote>
  <pre>
&lt;a xml:base="http://example.org"&gt;
   &lt;b xml:base="test/ "&gt;
       &lt;c/&gt;
   &lt;/b&gt;
&lt;/a&gt;
</pre>
</blockquote>

when <code>&lt;b&gt;...&lt;/b</code>&gt; is filtered out, but it will also correctly produce

<blockquote>
<pre>
&lt;a xml:base="http://example.org"&gt;
       &lt;c xml:base="http://example.org/test/test/" /&gt;
&lt;/a&gt;
</pre>
</blockquote>

<p>from</p>

<blockquote>
 <pre>
&lt;a xml:base="http://example.org"&gt;
   &lt;b xml:base="test/"&gt;
       &lt;c xml:base="test/" /&gt;
   &lt;/b&gt;
&lt;/a&gt;
</pre>
</blockquote>


<p>when <code>&lt;b&gt;...&lt;/b&gt;</code> is filtered out.</p>

<p>But we can't say it that way, because C14N as written does not use
the infoset. Cannonical XML is currently defined on the XPath data
model.</p>

</div>

</div>

<div class="div1">

<h2><a name="Ref"></a>6. References</h2>

<dl>

<dt class="label"><a name="C14N10"></a>[C14N10] </dt><dd>
<a href="http://www.w3.org/TR/xml-c14n"><cite>Canonical XML
Version 1.0</cite></a>, J. Boyer. W3C Recommendation, 15 March 2001,
<a href="http://www.w3.org/TR/xml-c14n">http://www.w3.org/TR/xml-c14n</a>
(<a href="http://www.w3.org/2001/03/C14N-errata">Errata</a>).
</dd>

<dt class="label"><a name="C14N-INFOSET"></a>[C14N-INFOSET] </dt><dd>
<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0005.html"><cite>
An infoset-based  strategy for canonicalizing xml:base</cite></a>, H. S. Thompson. XML-CORE Public Mailing list, 6 March 2006,
<a href="http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0005.html">http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Mar/0005.html</a>
</dd>


<dt class="label"><a name="RFC2396"></a>[RFC2396] </dt><dd>
<a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource Identifiers
(URI): Generic Syntax</cite></a>, T. Berners-Lee MIT/LCS,  R. Fielding U.C. Irvine,
L. Masinter Xerox Corporation, August 1998
<a href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a>.
</dd>

<dt class="label"><a name="RFC3986"></a>[RFC3986] </dt><dd>
<a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource Identifiers
(URI): Generic Syntax</cite></a>, T. Berners-Lee W3C/MIT,  R. Fielding Day Software,
L. Masinter Adobe Systems, January 2005
<a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.
</dd>

<dt class="label"><a name="XMLBASE"></a>[XMLBASE] </dt><dd>
<a href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/"><cite>XML Base
</cite></a>, J. Marsh. W3C Recommendation, 27 June 2001,
<a href="http://www.w3.org/TR/xmlbase/">http://www.w3.org/TR/xmlbase/</a>.
</dd>

<dt class="label"><a name="XMLDSIG2006"></a>[XMLDSIG2006] </dt><dd>
<a href="http://www.w3.org/TR/2006/NOTE-DSIG-usage-20061220/"><cite>Using XML Digital Signatures in the 2006 XML Environment</cite></a>, T. Roessler.
W3C Working Group Note, 20 Dec 2006,
<a href="http://www.w3.org/TR/2006/NOTE-DSIG-usage-20061220/">
http://www.w3.org/TR/2006/NOTE-DSIG-usage-20061220/</a>.
</dd>

<dt class="label"><a name="XMLENCDEC"></a>[XMLENCDEC] </dt><dd>
<a href="http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210"><cite>Decryption Transform for XML Signature</cite></a>, M. Hughes, T. Imamura, H. Maruyama. W3C Recommendation, 10 December 2002,
<a href="http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210">
http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210</a>.
</dd>

<dt class="label"><a name="XMLID"></a>[XMLID] </dt><dd>
<a href="http://www.w3.org/TR/xml-id/"><cite>xml:id Version 1.0
</cite></a>, J. Marsh, D. Veillard, N. Walsh. W3C Recommendation,9 September 2005,
<a href="http://www.w3.org/TR/xml-id/">http://www.w3.org/TR/xml-id/</a>.
</dd>

<dt class="label"><a name="XMLINFOSET"></a>[XMLINFOSET] </dt><dd>
<a href="http://www.w3.org/TR/xml-infoset/"><cite>XML Information Set (Second Edition)
</cite></a>, J. Cowan and R. Tobin, editors W3C Recommendation, 4 February 2004,
<a href="http://www.w3.org/TR/xml-infoset/">http://www.w3.org/TR/xml-infoset/</a>.
</dd>

<dt class="label"><a name="XMLDSIG"></a>[XMLDSIG] </dt><dd><a href="http://www.w3.org/TR/xmldsig-core/"><cite>XML-Signature Syntax and
Processing</cite></a>, D. Eastlake, J. R., D. Solo, M. Bartel,
J. Boyer , B. Fox , E. Simon. W3C Recommendation, 12 February
2002, <a href="http://www.w3.org/TR/xmldsig-core/">http://www.w3.org/TR/xmldsig-core/</a>.
</dd>

</dl>
</div>

<div class="div1">

<h2><a name="Ack"></a>7. Acknowledgments</h2>

<p>This note is based on based on input from John Boyer, Roy Fielding, Larry Masinter,
    Thomas Roessler, the members of the XML Core Working Group, and the members of the xml-dsig mailing list.
</p>
</div>

</div>

<div class="back">

</div>
</body></html>