[要約] RFC 3741は、XML文書の独自の正規化方法を定義しています。その目的は、XMLデータの一意性と整合性を確保することです。
Network Working Group J. Boyer
Request for Comments: 3741 PureEdge Solutions
Category: Informational D. Eastlake 3rd
Motorola
J. Reagle
W3C
March 2004
Exclusive XML Canonicalization, Version 1.0
排他的なXML Canonicalization、バージョン1.0
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization.
Canonical XMLは、「XML：」名前空間のすべての名前空間宣言と属性を含む、サブドキュメントの祖先のコンテキストを含む、サブドキュメントに適用される場合、XMLの標準シリアル化を指定します。ただし、一部のアプリケーションには、実用的な範囲で、標準化された亜ドキュメントから祖先のコンテキストを除外する方法が必要です。たとえば、XMLメッセージのXMLペイロード（Subdocument）を介したデジタル署名が必要になる場合があります。これは、その亜ドキュメントが元のメッセージから削除されたり、別のコンテキストに挿入されたときに壊れない場合があります。この要件は、排他的なXML Canonicalizationによって満たされます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Applications . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Limitations. . . . . . . . . . . . . . . . . . . . . . . 5
2. The Need for Exclusive XML Canonicalization. . . . . . . . . . 5
2.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 6
2.2. General Problems with re-Enveloping. . . . . . . . . . . 7
3. Specification of Exclusive XML Canonicalization. . . . . . . . 8
3.1. Constrained Implementation (non-normative) . . . . . . . 9
4. Use in XML Security. . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
5.1. Target Context . . . . . . . . . . . . . . . . . . . . . 12
5.2. 'Esoteric' Node-sets . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
7. Acknowledgements (Informative) . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
The XML Recommendation [XML] specifies the syntax of a class of objects called XML documents. The Namespaces in XML Recommendation [XML-NS] specifies additional syntax and semantics for XML documents. It is normal for XML documents and subdocuments which are equivalent for the purposes of many applications to differ in their physical representation. For example, they may differ in their entity structure, attribute ordering, and character encoding. The goal of this specification is to establish a method for serializing the XPath node-set representation of an XML document or subset such that:
XML推奨[XML]は、XMLドキュメントと呼ばれるオブジェクトのクラスの構文を指定します。XML推奨[XML-NS]の名前空間は、XMLドキュメントの追加の構文とセマンティクスを指定します。XMLドキュメントとサブドキュメントでは、多くのアプリケーションが物理的表現が異なることを目的としています。たとえば、エンティティ構造、属性の順序、およびキャラクターエンコーディングが異なる場合があります。この仕様の目標は、XMLドキュメントまたはサブセットのXPathノードセット表現をシリアル化する方法を確立することです。
1. The node-set is minimally affected by any XML context which has been omitted. 2. The canonicalization of a node-set representing well-balanced XML [XML-Fragment] will be unaltered by further applications of exclusive canonicalization. 3. It can be determined whether two node-sets are identical except for transformations considered insignificant by this specification under [XML, XML-NS].
1. ノードセットは、省略されているXMLコンテキストの影響を最小限に抑えられます。2.バランスの取れたXML [XML-fragment]を表すノードセットの標準化は、排他的な標準化のさらなる応用によって変更されません。3. [xml、xml-ns]の下でのこの仕様では重要でないと見なされる変換を除いて、2つのノードセットが同一かどうかを判断できます。
An understanding of the Canonical XML Recommendation [XML-C14N] is required.
標準的なXML推奨[XML-C14N]の理解が必要です。
The World Wide Web Consortium Recommendation corresponding to this RFC is at: http://www.w3.org/TR/xml-exc-c14n. Errata are located at http://www.w3.org/2002/07/xml-exc-c14n-errata.
このRFCに対応するWorld Wide Webコンソーシアムの推奨は、http：//www.w3.org/tr/xml-exc-c14nにあります。Errataはhttp://www.w3.org/2002/07/xml-exc-c14n-errataにあります。
The key words "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 [Keywords].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
The XPath 1.0 Recommendation [XPath] defines the term node-set and specifies a data model for representing an input XML document as a set of nodes of various types (element, attribute, namespace, text, comment, processing instruction, and root). The nodes are included in or excluded from a node-set based on the evaluation of an expression. Within this specification and [XML-C14N], a node-set is used to directly indicate whether or not each node should be rendered in the canonical form (in this sense, it is used as a formal mathematical set). A node that is excluded from the set is not rendered in the canonical form being generated, even if its parent node is included in the node-set. However, an omitted node may still impact the rendering of its descendants (e.g., by affecting the namespace context of the descendants).
XPath 1.0推奨[XPath]は、ノードセットという用語を定義し、入力XMLドキュメントをさまざまなタイプのノードのセット（要素、属性、名前空間、テキスト、コメント、処理命令、およびルート）として表すためのデータモデルを指定します。ノードは、式の評価に基づいてノードセットに含まれるか、除外されます。この仕様と[XML-C14N]内で、ノードセットを使用して、各ノードを正規形式でレンダリングする必要があるかどうかを直接示します（この意味では、正式な数学セットとして使用されます）。セットから除外されたノードは、親ノードがノードセットに含まれていても、生成される標準形式でレンダリングされません。ただし、省略されたノードは、子孫のレンダリングに依然として影響する可能性があります（例えば、子孫の名前空間コンテキストに影響を与えることにより）。
A document subset is a portion of an XML document indicated by an XPath node-set that may not include all of the nodes in the document. As defined in [XPath] every node (e.g., element, attribute, and namespace), has exactly one parent, which is either an element node or the root node. An apex node is an element node in a document subset having no element node ancestor in the document subset. An orphan node is an element node whose parent element node is not in the document subset. The output parent of an orphan node that is not an apex node is the nearest ancestor element of the orphan node that is in the document subset; an apex node has no output parent. The output parent of a non-orphan node is the parent of the node. An output ancestor is any ancestor element node in the document subset.
ドキュメントサブセットは、ドキュメントにすべてのノードを含めないXPathノードセットで示されるXMLドキュメントの一部です。[XPath]で定義されているように、すべてのノード（例：要素、属性、名前空間）には、正確に1つの親があり、これは要素ノードまたはルートノードのいずれかです。頂点ノードは、ドキュメントサブセットに要素ノードの祖先がないドキュメントサブセットの要素ノードです。Orphanノードは、親要素ノードがドキュメントサブセットにない要素ノードです。Apexノードではない孤児ノードの出力親は、ドキュメントサブセットにある孤児ノードの最も近い先祖要素です。頂点ノードには出力の親がいません。非オーファンノードの出力親は、ノードの親です。出力の祖先は、ドキュメントサブセットの任意の祖先要素ノードです。
For example given a document tree with three generations under the root node A and where capitalization denotes the node is in the document subset (A,E,G).
たとえば、ルートノードAの下に3世代のドキュメントツリーが与えられ、キャピタ化がノードがドキュメントサブセット（a、e、g）にあることを示すドキュメントツリーが与えられます。
Pictorial Representation:
絵の表現：
[diagram of nodes, http://www.w3.org/TR/xml-exc-c14n/exc-c14n.png]
[ノードの図、http://www.w3.org/tr/xml-exc-c14n/exc-c14n.png]
Textual Representation:
テキスト表現：
A-+-b `-c-+-d `-E-+-f `-G The following characteristics apply:
a- -b `-c- -d` -e- -f` -g次の特性が適用されます。
* A is an apex node, output parent of E, and output ancestor of (E,G); * E is an orphan node and the output parent of G.
* aは頂点ノード、eの出力親、および（e、g）の出力祖先です。* eは孤児ノードであり、gの出力親です。
An element E in a document subset visibly utilizes a namespace declaration, i.e., a namespace prefix P and bound value V, if E or an attribute node in the document subset with parent E has a qualified name in which P is the namespace prefix. A similar definition applies for an element E in a document subset that visibly utilizes the default namespace declaration, which occurs if E has no namespace prefix.
ドキュメントサブセットの要素Eは、名前空間宣言、つまり名前空間プレフィックスPとバウンド値Vを目に見えて使用します。同様の定義は、デフォルトの名前空間宣言を目に見えて利用するドキュメントサブセットの要素Eに適用されます。これは、eが名前空間プレフィックスがない場合に発生します。
The namespace axis of an element contains nodes for all non-default namespace declarations made within the element as well as non-default namespace declarations inherited from ancestors of the element. The namespace axis also contains a node representing the default namespace if it is not the empty string, whether the default namespace was declared within the element or by an ancestor of the element. Any subset of the nodes in a namespace axis can be included in a document subset.
要素の名前空間軸には、要素内で作成されたすべての非デフォルトネームスペース宣言のノードと、要素の祖先から継承された非デフォルトネームスペース宣言が含まれます。名前空間軸には、デフォルトの名前空間が要素内で宣言された場合でも要素の祖先によって宣言された場合でも、空の文字列ではない場合、デフォルトの名前空間を表すノードも含まれます。名前空間軸のノードのサブセットは、ドキュメントサブセットに含めることができます。
The method of canonicalization described in this specification receives an InclusiveNamespaces PrefixList parameter, which lists namespace prefixes that are handled in the manner described by the Canonical XML Recommendation [XML-C14N].
この仕様で説明されている標準化の方法は、包括的なXML推奨[XML-C14N]で説明されている方法で処理される名前空間プレフィックスをリストする包含型のスペースプレフィックスリストパラメーターを受信します。
The exclusive canonical form of a document subset is a physical representation of the XPath node-set, as an octet sequence, produced by the method described in this specification. It is as defined in the Canonical XML Recommendation [XML-C14N] except for the changes summarized as follows:
ドキュメントサブセットの排他的な標準形式は、この仕様で説明されている方法によって生成されるオクテットシーケンスとしてのXpathノードセットの物理的表現です。次のように要約された変更を除き、標準XML推奨[XML-C14N]で定義されています。
* attributes in the XML namespace, such as xml:lang and xml:space are not imported into orphan nodes of the document subset, and
* namespace nodes that are not on the InclusiveNamespaces PrefixList are expressed only in start tags where they are visible and if they are not in effect from an output ancestor of that tag.
* XMLなどのXMLネームスペースの属性：LangおよびXML：スペースはドキュメントサブセットの孤児ノードにインポートされません。
* inclusivenmesspacesプレフィックスリストにない名前空間ノードは、表示されているスタートタグでのみ表現され、そのタグの出力祖先から有効でない場合。
The term exclusive canonical XML refers to XML that is in exclusive canonical form. The exclusive XML canonicalization method is the algorithm defined by this specification that generates the exclusive canonical form of a given XML document subset. The term exclusive XML canonicalization refers to the process of applying the exclusive XML canonicalization method to an XML document subset.
排他的な標準XMLという用語は、排他的な標準形式のXMLを指します。排他的なXML Canonicalizationメソッドは、特定のXMLドキュメントサブセットの排他的な標準形式を生成するこの仕様で定義されたアルゴリズムです。排他的なXML Canonicalizationという用語は、XMLドキュメントサブセットに排他的なXML Canonicalizationメソッドを適用するプロセスを指します。
The applications of Exclusive XML Canonicalization are very similar to those for Canonical XML [XML-C14N]. However, exclusive canonicalization, or equivalent means of excluding most XML context, is necessary for signature applications where the XML context of signed XML will change. This sort of change is typical of many protocol applications.
排他的なXML Canonicalizationのアプリケーションは、標準XML [XML-C14N]のアプリケーションと非常に似ています。ただし、署名されたXMLのXMLコンテキストが変更される署名アプリケーションには、ほとんどのXMLコンテキストを除外する排他的な標準化または同等の手段が必要です。この種の変更は、多くのプロトコルアプリケーションの典型です。
Note that in the case of the SignedInfo element of [XML-DSig], the specification of an appropriate canonicalization method is the only technique available to protect the signature from insignificant changes in physical form and changes in XML context.
[xml-dsig]のsignedInfo要素の場合、適切な標準化法の仕様は、物理的形態の取るに足らない変化とXMLコンテキストの変化から署名を保護するための唯一の手法であることに注意してください。
Exclusive XML Canonicalization has the limitations of Canonical XML [XML-C14N] plus two additional limitations as follows:
排他的なXML標準化には、標準XML [XML-C14N]と2つの追加の制限の制限があります。
1. The XML being canonicalized may depend on the effect of XML namespace attributes, such as xml:lang, xml:space, and xml:base appearing in ancestor nodes. To avoid problems due to the non-importation of such attributes into an enveloped document subset, either they MUST be explicitly given in a node of the XML document subset being canonicalized where their effect is needed or which is an ancestor of the node where their effect is needed or they MUST always be declared with an equivalent value in every context in which the XML document subset will be interpreted. 2. Applications that use the XML being canonicalized may depend on the effect of XML namespace declarations where the namespace prefix being bound is not visibly utilized. An example would be an attribute whose value is an XPath expression and whose evaluation therefore depends upon namespace prefixes referenced in the expression. Or, an attribute value might be considered a QName [XML-NS] by some applications, but it is only a string-value to XPath:
1. 正規化されているXMLは、XML：Lang、XML：Space、およびXMLなどのXML名空間属性の効果に依存する可能性があります。そのような属性が包括的なドキュメントサブセットへの非輸入による問題を回避するには、それらの効果が必要な場合に正規化されているXMLドキュメントサブセットのノードで明示的に指定する必要があります。必要な場合、またはXMLドキュメントサブセットが解釈されるすべてのコンテキストで、常に同等の値で宣言される必要があります。2. XMLを使用するアプリケーションは、標準化されているXMLが、バインドされている名前空間プレフィックスが目に見えて使用されていないXMLネームスペース宣言の効果に依存する場合があります。例は、値がXPath式であり、その評価は式で参照されている名前空間のプレフィックスに依存する属性です。または、属性値は一部のアプリケーションによってqName [xml-ns]と見なされる場合がありますが、それはxpathの文字列値にすぎません。
<number xsi:type="xsd:decimal">10.09</number>.
<番号xsi：type = "xsd：decimal"> 10.09 </number>。
To avoid problems with such namespace declarations,
そのような名前空間宣言の問題を回避するために、
o the XML MUST be modified so that use of the namespace prefix involved is visible, or o the namespace declarations MUST appear and be bound to the same values in every context in which the XML will be interpreted, or o the prefixes for such namespaces MUST appear in the InclusiveNamespaces PrefixList.
o 関係する名前空間プレフィックスの使用が表示されるようにXMLを変更する必要があります。または、oネームスペース宣言が表示され、XMLが解釈されるすべてのコンテキストで同じ値にバインドされている必要があります。inclusivenamespacesプレフィックスリスト。
In some cases, particularly for signed XML in protocol applications, there is a need to canonicalize a subdocument in such a way that it is substantially independent of its XML context. This is because, in protocol applications, it is common to envelope XML in various layers of message or transport elements, to strip off such enveloping, and to construct new protocol messages, parts of which were extracted from different messages previously received. If the pieces of XML in question are signed, they need to be canonicalized in a way such that these operations do not break the signature but the signature still provides as much security as can be practically obtained.
場合によっては、特にプロトコルアプリケーションで署名されたXMLの場合、XMLコンテキストから実質的に独立しているように、サブドキュメントを正規化する必要があります。これは、プロトコルアプリケーションでは、メッセージまたはトランスポート要素のさまざまなレイヤーにXMLを封筒に入れ、そのような包みを取り除き、その一部が以前に受信した異なるメッセージから抽出された新しいプロトコルメッセージを作成することが一般的であるためです。問題のXMLの断片が署名されている場合、これらの操作が署名を破らないように標準化する必要がありますが、署名は実際に得られる限り多くのセキュリティを提供します。
As a simple example of the type of problem that changes in XML context can cause for signatures, consider the following document:
XMLコンテキストで変化する問題のタイプの簡単な例として、署名を引き起こす可能性があります。次のドキュメントを検討してください。
<n1:elem1 xmlns:n1="http://b.example">
content
</n1:elem1>
this is then enveloped in another document:
これは、別のドキュメントに包まれています。
<n0:pdu xmlns:n0="http://a.example">
<n1:elem1 xmlns:n1="http://b.example">
content
</n1:elem1>
</n0:pdu>
The first document above is in canonical form. But assume that document is enveloped as in the second case. The subdocument with elem1 as its apex node can be extracted from this second case with an XPath expression such as:
上記の最初のドキュメントは標準的な形式です。ただし、2番目のケースのようにドキュメントが包まれていると仮定します。ApexノードとしてのELEM1を使用した亜文書は、次のようなXPath式でこの2番目のケースから抽出できます。
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]
The result of applying Canonical XML to the resulting XPath node-set is the following (except for line wrapping to fit this document):
結果のXPATHノードセットに標準XMLを適用した結果は、次のとおりです（このドキュメントに適合するラインラッピングを除く）：
<n1:elem1 xmlns:n0="http://a.example"
xmlns:n1="http://b.example">
content
</n1:elem1>
Note that the n0 namespace has been included by Canonical XML because it includes namespace context. This change which would break a signature over elem1 based on the first version.
N0ネームスペースは、名前空間コンテキストが含まれているため、Canonical XMLに含まれていることに注意してください。最初のバージョンに基づいてELEM1を介して署名を破るこの変更。
As a more complete example of the changes in canonical form that can occur when the enveloping context of a document subset is changed, consider the following document:
ドキュメントサブセットの包囲コンテキストが変更されたときに発生する可能性のある標準形式の変更のより完全な例として、次のドキュメントを検討してください。
<n0:local xmlns:n0="foo:bar"
xmlns:n3="ftp://example.org">
<n1:elem2 xmlns:n1="http://example.net"
xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"/>
</n1:elem2>
</n0:local>
And the following which has been produced by changing the enveloping of elem2:
ELEM2の包みを変更することによって生成された以下：
<n2:pdu xmlns:n1="http://example.com"
xmlns:n2="http://foo.example"
xml:lang="fr"
xml:space="retain">
<n1:elem2 xmlns:n1="http://example.net"
xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"/>
</n1:elem2>
</n2:pdu>
Assume an XPath node-set produced from each case by applying the following XPath expression:
次のXPath式を適用して、各ケースから生成されたXPathノードセットを想定してください。
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem2]
Applying Canonical XML to the node-set produced from the first document yields the following serialization (except for line wrapping to fit in this document):
最初のドキュメントから生成されたノードセットに正規のXMLを適用すると、次のシリアル化が得られます（このドキュメントに適合するラインラッピングを除く）：
<n1:elem2 xmlns:n0="foo:bar"
xmlns:n1="http://example.net"
xmlns:n3="ftp://example.org"
xml:lang="en">
<n3:stuff></n3:stuff>
</n1:elem2>
However, although elem2 is represented by the same octet sequence in both pieces of external XML above, the Canonical XML version of elem2 from the second case would be (except for line wrapping so it will fit into this document) as follows:
ただし、ELEM2は上記の外部XMLの両方のピースで同じオクテットシーケンスで表されますが、2番目のケースからのELEM2の標準XMLバージョンは（このドキュメントに適合するためにラインラッピングを除く）です。
<n1:elem2 xmlns:n1="http://example.net"
xmlns:n2="http://foo.example"
xml:lang="en"
xml:space="retain">
<n3:stuff xmlns:n3="ftp://example.org"></n3:stuff>
</n1:elem2>
Note that the change in context has resulted in lots of changes in the subdocument as serialized by the inclusive Canonical XML [XML-C14N]. In the first example, n0 had been included from the context and the presence of an identical n3 namespace declaration in the context had elevated that declaration to the apex of the canonicalized form. In the second example, n0 has gone away but n2 has appeared, n3 is no longer elevated, and an xml:space declaration has appeared, due to changes in context. But not all context changes have effect. In the second example, the presence at ancestor nodes of an xml:lang and n1 prefix namespace declaration have no effect because of existing declarations at the elem2 node.
コンテキストの変化により、包括的な標準XML [XML-C14N]によってシリアル化されたように、サブドキュメントの多くの変化が発生したことに注意してください。最初の例では、N0はコンテキストから含まれていましたが、コンテキストでの同一のN3ネームスペース宣言の存在は、その宣言が標準化された形式の頂点に上昇しました。2番目の例では、N0はなくなりましたが、N2が表示され、N3はもはや上昇していません。XML：コンテキストの変化により、宇宙宣言が表示されます。しかし、すべてのコンテキストの変更が効果があるわけではありません。2番目の例では、XML：LangおよびN1プレフィックス名空間宣言の祖先ノードでの存在は、ELEM2ノードでの既存の宣言のために効果がありません。
On the other hand, using Exclusive XML Canonicalization as specified herein, the physical form of elem2 as extracted by the XPath expression above is (except for line wrapping so it will fit into this document) as follows:
一方、本明細書に指定されている排他的なXML Canonicalizationを使用して、上記のXPath式で抽出されたELEM2の物理的形式は（このドキュメントに適合するようにラインラッピングを除く）です。
<n1:elem2 xmlns:n1="http://example.net"
xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"></n3:stuff>
</n1:elem2>
in both cases.
両方の場合において。
The data model, processing, input parameters, and output data for Exclusive XML Canonicalization are the same as for Canonical XML [XML-C14N] with the following exceptions:
排他的なXML Canonicalizationのデータモデル、処理、入力パラメーター、および出力データは、次の例外を除き、標準XML [XML-C14N]の場合と同じです。
1. Canonical XML applied to a document subset requires the search of the ancestor nodes of each orphan element node for attributes in the XML namespace, such as xml:lang and xml:space. These are copied into the element node except if a declaration of the same attribute is already in the attribute axis of the element (whether or not it is included in the document subset). This search and copying are omitted from the Exclusive XML Canonicalization method. 2. The Exclusive XML Canonicalization method may receive an additional, possibly null, parameter InclusiveNamespaces PrefixList containing a list of namespace prefixes and/or a token indicating the presence of the default namespace. All namespace nodes appearing on this list are handled as provided in Canonical XML [XML-C14N]. 3. A namespace node N with a prefix that does not appear in the InclusiveNamespaces PrefixList is rendered if all of the conditions are met: 1. Its parent element is in the node-set, and 2. it is visibly utilized by its parent element, and 3. the prefix has not yet been rendered by any output ancestor, or the nearest output ancestor of its parent element that visibly utilizes the namespace prefix does not have a namespace node in the node-set with the same namespace prefix and value as N. 4. If the token representing the default namespace is not present in InclusiveNamespaces PrefixList, then the rules for rendering xmlns="" are changed as follows. When canonicalizing the namespace axis of an element E that is in the node-set, output xmlns="" if and only if all of the conditions are met: 1. E visibly utilizes the default namespace (i.e., it has no namespace prefix), and 2. it has no default namespace node in the node-set, and 3. the nearest output ancestor of E that visibly utilizes the default namespace has a default namespace node in the node-set. (This step for xmlns="" is necessary because it is not represented in the XPath data model as a namespace node, but as the absence of a namespace node; see Section 4.7 Propagation of Default Namespace Declaration in Document Subsets [XML-C14N].)
1. ドキュメントサブセットに適用された標準XMLには、XML：LangおよびXML：Spaceなど、XMLネームスペースの属性の各孤児要素ノードの祖先ノードの検索が必要です。これらは、同じ属性の宣言が要素の属性軸に既にある場合を除き、要素ノードにコピーされます（ドキュメントサブセットに含まれているかどうかにかかわらず）。この検索とコピーは、排他的なXML Canonicalization Methodから省略されています。2.排他的なXML CanOnicalizationメソッドは、デフォルトの名前空間の存在を示す名前空間プレフィックスおよび/またはトークンのリストを含む、追加の、おそらくnullのパラメーター包括的なプレフィックスリストを受け取る場合があります。このリストに表示されるすべての名前空間ノードは、標準XML [XML-C14N]で提供されているように処理されます。3. inclusivenmesspacesプレフィックスリストに表示されないプレフィックスを備えた名前空間ノードnは、すべての条件が満たされている場合にレンダリングされます。1。その親要素はノードセットに、2。、および3.プレフィックスは、出力の祖先、または名前空間プレフィックスを目に見えて利用する親要素の最も近い出力の祖先によってまだレンダリングされていません。N. 4.デフォルトの名前空間を表すトークンが包括的なMamesSpacesプレフィックスリストに存在しない場合、xmlns = ""をレンダリングするためのルールは次のように変更されます。ノードセットにある要素Eの名前空間軸を正規化する場合、すべての条件が満たされている場合にのみ出力xmlns = ""、および2.ノードセットにデフォルトの名前空間ノードはありません。3。デフォルトの名前空間を目に見えて利用するEの最も近い出力祖先は、ノードセットにデフォルトの名前空間ノードを持っています。（XMLNS = ""のこのステップは、XPathデータモデルで名前空間ノードとして表されていないが、名前空間ノードの存在として表されるため、必要です。セクション4.7ドキュメントサブセットのデフォルトの名前空間宣言の伝播[XML-C14N]を参照してください。。）
The following is a (non-normative) method for implementing the Exclusive XML Canonicalization method for many straightforward cases -- it assumes a well-formed subset and that if an element is in the node-set, so is all of its namespace axis; if the element is not in the subset, neither is its namespace axis.
以下は、多くの簡単なケースに対して排他的なXML Canonicalizationメソッドを実装するための（非規範的な）方法です。これは、適切に形成されたサブセットを想定し、要素がノードセットにある場合、すべての名前空間軸もそうであることを想定しています。要素がサブセットにない場合、その名前空間軸でもありません。
1. Recursively process the entire tree (from which the XPath node-set was selected) in document order starting with the root. (The operation of copying ancestor xml: namespace attributes into output apex element nodes is not done.) 2. If the node is not in the XPath subset, continue to process its children element nodes recursively.
1. ルートから始まるドキュメントの順序で、ツリー全体（Xpathノードセットが選択された）全体を再帰的に処理します。（祖先XMLをコピーする操作：名前空間属性は出力Apex要素ノードには行われていません。）2。ノードがXpathサブセットにない場合は、子供の要素ノードを再帰的に処理し続けます。
3. If the element node is in the XPath subset then output the node in accordance with Canonical XML except for namespace nodes which are rendered as follows:
3. 要素ノードがXpathサブセットにある場合、次のようにレンダリングされる名前空間ノードを除き、カノニカルXMLに従ってノードを出力します。
1. ns_rendered is a copy of a dictionary, off the top of the state stack, of prefixes and their values which have already been rendered by an output ancestor of the namespace node's parent element. 2. Render each namespace node if and only if all of the conditions are met: 1. it is visibly utilized by the immediate parent element or one of its attributes, or is present in InclusiveNamespaces PrefixList, and 2. its prefix and value do not appear in ns_rendered. 3. Render xmlns="" if and only if all of the conditions are met: 1. The default namespace is visibly utilized by the immediate parent element node, or the default prefix token is present in InclusiveNamespaces PrefixList, and 2. the element does not have a namespace node in the node-set declaring a value for the default namespace, and 3. the default namespace prefix is present in the dictionary ns_rendered. 4. Insert all the rendered namespace nodes (including xmlns="") into the ns_rendered dictionary, replacing any existing entries. Push ns_rendered onto the state stack and recurse. 5. After the recursion returns, pop the state stack.
1. NS_RENDEREDは、州スタックの上部にある辞書のコピー、プレフィックスのコピー、および名前空間ノードの親要素の出力祖先によってすでにレンダリングされているそれらの値です。2.すべての条件が満たされている場合にのみ、各名前空間ノードをレンダリングします。1。即時の親要素またはその属性のいずれかによって目に見えて利用されているか、包括的なSpacesプレフィックスリストに存在します。ns_renderedに表示されます。3.すべての条件が満たされている場合にのみxmlns = ""をrenderします。1。デフォルトの名前空間は、即時の親要素ノードによって目に見えて利用されます。デフォルトの名前空間の値を宣言するノードセットに名前空間ノードがありません。3。デフォルトの名前空間プレフィックスは、辞書ns_renderedに存在します。4.レンダリングされたすべての名前空間ノード（xmlns = ""を含む）をns_rendered辞書に挿入し、既存のエントリを交換します。NS_RENDEREDをステートスタックに押し込み、再発します。5.再帰が戻った後、状態スタックをポップします。
Exclusive Canonicalization may be used as a Transform or CanonicalizationMethod algorithm in XML Digital Signature [XML-DSig] and XML Encryption [XML-Enc].
排他的な標準化は、XML Digital Signature [XML-DSIG]およびXML暗号化[XML-ENC]の変換またはCanOnicalizationMethodアルゴリズムとして使用できます。
Identifier: http://www.w3.org/2001/10/xml-exc-c14n#
識別子：http：//www.w3.org/2001/10/xml-exc-c14n#
http://www.w3.org/2001/10/xml-exc-c14n#WithComments
http://www.w3.org/2001/10/xml-exc-c14n#WithComments
Just as with [XML-C14N] one may use the "#WithComments" parameter to include the serialization of XML comments. This algorithm also takes an optional explicit parameter of an empty InclusiveNamespaces element with a PrefixList attribute. The value of this attribute is a white space delimited list of namespace prefixes, and where #default indicates the default namespace, to be handled as per [XML-C14N]. The list is in NMTOKENS format (a white space separated list). For example:
[XML-C14N]と同様に、「#WithComments」パラメーターを使用してXMLコメントのシリアル化を含めることができます。このアルゴリズムは、プレフィックスリスト属性を備えた空の包括的Mamesスペース要素のオプションの明示的なパラメーターも使用します。この属性の値は、名前空間プレフィックスのホワイトスペース区切りリストであり、#defaultは[XML-C14N]に従って処理されるデフォルトの名前空間を示します。リストはnmtokens形式（ホワイトスペース分離リスト）です。例えば：
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="dsig soap #default"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
indicates the exclusive canonicalization transform, but that namespaces with prefix "dsig" or "soap" and default namespaces should be processed according to [XML-C14N].
排他的な標準化変換を示しますが、その名前空間はプレフィックス「DSIG」または「石鹸」とデフォルトの名前空間を備えた[XML-C14N]に従って処理する必要があります。
Schema Definition (expressed in [XML-schema]):
スキーマ定義（[xml-schema]で表現）：
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema
PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
"http://www.w3.org/2001/XMLSchema.dtd"
[
<!ATTLIST schema xmlns:ec CDATA
#FIXED 'http://www.w3.org/2001/10/xml-exc-c14n#'>
<!ENTITY ec 'http://www.w3.org/2001/10/xml-exc-c14n#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
targetNamespace="http://www.w3.org/2001/10/xml-exc-c14n#"
version="0.1" elementFormDefault="qualified">
<element name="InclusiveNamespaces"
type="ec:InclusiveNamespaces"/>
<complexType name="InclusiveNamespaces">
<attribute name="PrefixList" type="NMTOKENS"/>
</complexType>
</schema>
DTD:
<!ELEMENT InclusiveNamespaces EMPTY >
<!ATTLIST InclusiveNamespaces
PrefixList NMTOKENS #REQUIRED >
This specification is used to serialize an XPath node-set under certain assumptions given in [XML-C14N] and this specification. Three such examples include:
この仕様は、[XML-C14N]およびこの仕様で与えられた特定の仮定の下でXPathノードセットをシリアル化するために使用されます。そのような3つの例は次のとおりです。
1. implementations of [XML-C14N] and this specification do not render an XML declaration; 2. implementations of this specification only render attributes from the "XML" namespace (e.g., xml:lang, xml:space, and xml:base) when they are in the subset being serialized; 3. implementations of this specification do not consider the appearance of a namespace prefix within an attribute value to be visibly utilized.
1. [XML-C14N]の実装とこの仕様では、XML宣言はレンダリングされません。2.この仕様の実装は、「XML」名前空間（例：XML：Lang、XML：Space、およびXML：Base）からの属性のみをレンダリングします。3.この仕様の実装は、属性値内の名前空間プレフィックスの外観を目に見えるように利用することを考慮しないでください。
While such choices are consistent with other XML specifications and satisfy the Working Group's application requirements it is important that an XML application carefully construct its transforms such that the result is meaningful and unambiguous in its application context. In addition to this section, the Limitations of this specification, the Resolutions of [XML-C14N], and the Security Considerations of [XML-DSig] should be carefully attended to.
このような選択肢は他のXML仕様と一致しており、ワーキンググループのアプリケーション要件を満たしていますが、XMLアプリケーションがその変換を慎重に構築して、結果がアプリケーションのコンテキストで意味があり、明確になることが重要です。このセクションに加えて、この仕様の制限、[XML-C14N]の解像度、および[XML-DSIG]のセキュリティ上の考慮事項に注意深く対応する必要があります。
The requirement of this specification is to satisfy applications that "require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument." Given a fragment being removed from its source instance, this specification satisfies this requirement by excluding from the fragment any context from its ancestors that is not utilized. Consequently, a signature [XML-DSig] over that fragment will remain valid in its source context, removed from the source context, and even in a new target context. However, this specification does not insulate the fragment against confused interpretation in a target context.
この仕様の要件は、「実用的な範囲で、標準化された亜博物館から祖先のコンテキストを除外する方法を必要とする」アプリケーションを満たすことです。ソースインスタンスから断片が削除されていることを考えると、この仕様は、使用されていない先祖からのコンテキストからフラグメントから除外することにより、この要件を満たします。その結果、そのフラグメント上の署名[xml-dsig]は、ソースコンテキストで、ソースコンテキストから削除され、さらには新しいターゲットコンテキストでも削除されます。ただし、この仕様では、ターゲットコンテキストでの混乱した解釈に対するフラグメントを隔離しません。
For example, if the <Foo/> element is signed in its source instance of <Bar/><Foo/></Bar> and then removed and placed in the target instance <Baz xmlns="http://example.org/bar"/><Foo/></Baz>, the signature should still be valid, but won't be if <Foo/> is interpreted as belonging to the http://example.org/bar namespace: this is dependent on how nodes are processed.
たとえば、<foo/>要素が<bar/> <foo/> </bar>のソースインスタンスに署名され、削除されてターゲットインスタンスに配置された場合<baz xmlns = "http://example.org/bar "/>> <foo/> </baz>、署名はまだ有効である必要がありますが、<foo/>がhttp://example.org/bar namespaceに属していると解釈されている場合はそうではありません。ノードの処理方法に依存します。
This specification does not define mechanisms of removing, inserting, and "fixing up" a node-set. (For an example of this sort of specification, see the processing required of Creating the Result Infoset (section 4.5) when an [XInclude] is performed.) Instead, applications must carefully specify the XML (i.e., source, fragment, and target) or define the node-set processing (i.e., removal, replacement, and insertion) with respect to default namespace declarations (e.g., xmlns="") and XML attributes (e.g., xml:lang, xml:space, and xml:base).
この仕様は、ノードセットを削除、挿入、および「固定」するメカニズムを定義しません。（この種の仕様の例については、[xinclude]が実行されたときに結果インフォセット（セクション4.5）の作成に必要な処理を参照してください。）代わりに、アプリケーションはXML（すなわち、ソース、フラグメント、およびターゲット）を慎重に指定する必要があります。または、デフォルトの名前空間宣言（例：XMLNS = ""）およびXML属性（XML：Lang、XML：Space、およびXML：Base）に関して、ノードセット処理（すなわち、削除、交換、および挿入）を定義します。。
Consider an application that might use this specification or [XML-C14N] to serialize a single attribute node. An implementation of either specification will not emit a namespace declaration for that single attribute node. Consequently, a "carefully constructed" transform should create a node-set containing the attribute and the relevant namespace declaration for serialization.
この仕様または[XML-C14N]を使用して、単一の属性ノードをシリアル化する可能性のあるアプリケーションを検討してください。いずれかの仕様の実装では、その単一属性ノードの名前空間宣言は発生しません。その結果、「慎重に構築された」変換は、属性と関連する名前空間宣言を含むノードセットを作成する必要があります。
This example is provided to caution that as one moves beyond well-formed [XML] and then well-balanced XML [XML-Fragment], it becomes increasingly difficult to create a result that "is meaningful and unambiguous in its application context."
この例は、整形された[XML]を超えて移動し、バランスの取れたXML [XML-Fragment]を超えて、「アプリケーションのコンテキストで意味があり、明確である」という結果を作成することがますます困難になることを注意してください。
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[XML] Extensible Markup Language (XML) 1.0 (Second Edition). T. Bray, E. Maler, J. Paoli, and C. M. Sperberg-McQueen. W3C Recommendation, October 2000. Available at http://www.w3.org/TR/2000/REC-xml-20001006
[XML]拡張可能なマークアップ言語（XML）1.0（第2版）。T.ブレイ、E。マラー、J。パオリ、およびC. M.スパルバーグ-mcqueen。W3C推奨、2000年10月。http：//www.w3.org/tr/2000/rec-xml-20001006で入手可能
[XML-C14N] Boyer, J., "Canonical XML", RFC 3076, March 2001. Also a W3C Recommendation available at http://www.w3.org/TR/2001/REC-xml-c14n-20010315
[XML-C14N] Boyer、J。、 "Canonical XML"、RFC 3076、2001年3月。W3Cの推奨もhttp://www.w3.org/tr/2001/REC-XML-C14N-20010315で入手できます。
[XML-NS] Namespaces in XML. T. Bray, D. Hollander, and A. Layman. W3C Recommendation, January 1999. Available at http://www.w3.org/TR/1999/REC-xml-names-19990114/
[XML-NS] XMLの名前空間。T.ブレイ、D。ホランダー、A。レイマン。W3C推奨、1999年1月。http：//www.w3.org/tr/1999/rec-xml-names-19990114/で入手可能
[XML-schema] XML Schema Part 1: Structures D. Beech, M. Maloney, N. Mendelsohn, and H. Thompson. W3C Recommendation, May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[XML-Schema] XMLスキーマパート1：構造D.ビーチ、M。マロニー、N。メンデルソーン、およびH.トンプソン。W3C推奨、2001年5月。http：//www.w3.org/tr/2001/rec-xmlschema-20010502/で入手可能
[XPath] XML Path Language (XPath) Version 1.0. J. Clark and S. DeRose. W3C Recommendation, November 1999. Available at http://www.w3.org/TR/1999/REC-xpath-19991116
[XPath] XMLパス言語（XPath）バージョン1.0。J.クラークとS.デロース。W3C推奨、1999年11月。http：//www.w3.org/tr/1999/rec-xpath-19991116で入手可能
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、RFC 2396、1998年8月。
[XInclude] XML Inclusions (XInclude) Version 1.0. J. Marsh, and D. Orchad. W3C Candidate Recommendation, February 2002. Available at http://www.w3.org/TR/2002/CR-xinclude-20020221/
[Xinclude] XMLインクルージョン（XINCLUDE）バージョン1.0。J.マーシュ、およびD.オーチャッド。W3C候補の推奨、2002年2月。http：//www.w3.org/tr/2002/cr-xinclude-2002021/で入手可能
[XML-DSig] Eastlake, D., Reagle, J. and D. Solo, "XML-Signature Syntax and Processing", RFC 3275, March 2002. Available at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
[XML-dsig] Eastlake、D.、Reagle、J。and D. Solo、「XML-Signature Syntax and Processing」、RFC 3275、2002年3月。http：//www.w3.org/tr/2002/で入手可能rec-xmldsig-core-20020212/
[XML-Enc] XML Encryption Syntax and Processing. D. Eastlake, and J. Reagle. W3C Candidate Recommendation, March 2002. Available at http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/
[XML-ENC] XML暗号化構文と処理。D.イーストレイク、J。レーグル。W3C候補者の推奨、2002年3月。http：//www.w3.org/tr/2002/cr-xmlenc-core-20020304/で入手可能
[XML-Fragment] XML Fragment Interchange. P. Grosso, and D. Veillard. W3C Candidate Recommendation, February 2001. Available at http://www.w3.org/TR/2001/CR-xml-fragment-20010212
[xml-fragment] xmlフラグメントインターチェンジ。P.グロッソ、およびD.ベイラード。W3C候補の推奨、2001年2月。http：//www.w3.org/tr/2001/cr-xml-fragment-20010212で入手可能
The following people provided valuable feedback that improved the quality of this specification:
次の人々は、この仕様の品質を改善する貴重なフィードバックを提供しました。
* Merlin Hughes, Baltimore * Thomas Maslen, DSTC * Paul Denning, MITRE * Christian Geuer-Pollmann, University Siegen * Bob Atkinson, Microsoft
* マーリン・ヒューズ、ボルチモア *トーマス・マスレン、DSTC *ポール・デニング、マイター *クリスチャン・ジューア・ポルマン、ユニバーシティ・シーゲン *ボブ・アトキンソン、マイクロソフト
Authors' Addresses
著者のアドレス
John Boyer PureEdge Solutions Inc. 4396 West Saanich Rd. Victoria, BC, Canada V8Z 3E9
John Boyer Pureedge Solutions Inc. 4396 West Saanich Rd。カナダ、紀元前、ビクトリアv8z 3e9
Phone: +1-888-517-2675
EMail: jboyer@PureEdge.com
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-634-2066 (h)
+1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Joseph M. Reagle Jr., W3C Massachusetts Institute of Technology Laboratory for Computer Science NE43-350, 545 Technology Square Cambridge, MA 02139
Joseph M. Reagle Jr.、W3C Massachusetts Institute of Technology Laboratory for Computer Science NE43-350、545 Technology Square Cambridge、MA 02139
Phone: +1-617-258-7621
EMail: reagle@mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。