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
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.
著作権（C）インターネット協会（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ペイロード（サブ文書）上でデジタル署名が必要な場合があります。この要件は、独占XML正則化によって満たされます。
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フラグメント]は排他的正規化のさらなるアプリケーションによって変更されていないであろう。 3. 2つのノードセットは[XML、XML-NS]でこの仕様で有意でないと考え変換を除いて同一であるか否かを判定することができます。
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.
http://www.w3.org/TR/xml-exc-c14n：このRFCに対応したWorld Wide Web Consortium（W3C）の勧告です。エラッタは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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード] 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
XPath 1.0の勧告[XPathの用語ノードセットを定義し、様々なタイプ（要素、属性、名前空間、テキスト、コメント、処理命令、および根）のノードの集合として入力XML文書を表現するためのデータ・モデルを指定します。ノードは、に含まれる又は発現の評価に基づいて、ノード集合から除外されます。本明細書および[XML-C14N]内に、ノードセットであります
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).
各ノード（この意味では、それが正式な数学的な集合として使用されている）標準形式でレンダリングされるべきか否かを直接示すために使用されます。セットから除外されたノードは、その親ノードがノードセットに含まれている場合であっても、生成される標準形式でレンダリングされていません。しかし、省略ノードが依然として（例えば、子孫の名前空間コンテキストに影響を及ぼすことによって）その子孫のレンダリングに影響を与えるかもしれません。
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]で定義されるように、要素ノード又はルートノードのいずれかであり、正確に一つの親を有しています。頂点ノードは、ドキュメントのサブセットには要素ノードの祖先を持たない文書サブセット内の要素ノードです。孤立ノードは、その親要素ノード文書サブセットにない要素ノードです。頂点ノードではない孤立ノードの出力親文書のサブセットである孤立ノードの最も近い祖先要素です。頂点ノードには、出力親を持ちません。非孤児ノードの出力親は、ノードの親です。出力祖先は、文書のサブセット内の任意の祖先要素ノードです。
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の下三世代と文書ツリーを与えられ、大文字はノードを表し、ドキュメントのサブセット（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:
- + - B '-c - + - D `-E - + - -G' fは次の特性が適用されます。
* 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または親Eと文書部分集合内の属性ノードは、Pは、名前空間接頭辞である修飾名を持っている場合、文書のサブセット内の要素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]によって記載された方法で処理される名前空間接頭辞を示しますInclusiveNamespaces PrefixListパラメータを受信します。
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.
空間は、文書のサブセットの孤立ノードにインポートされていない、とInclusiveNamespaces PrefixListにない*名前空間ノードは、それらが、可視および場合である開始タグで表され：langのとxml：* XMLなど、XML名前空間の属性彼らは、そのタグの出力祖先から有効ではありません。
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正則化法は、与えられたXML文書部分集合の排他的正則形式を生成し、この仕様で定義されたアルゴリズムです。用語排他的XML正則化は、XML文書のサブセットに排他的XML正則化法を適用するプロセスを指します。
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正則化のアプリケーションは、Canonicalの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正則化は、CanonicalのXML [XML-C14N]の制限に加えて二つの追加の制限があります。
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:
ラング、XML：空間、およびXML：1.正規化されるXMLは、XMLなどのXML名前空間属性の効果に依存し得る塩基は、祖先ノードに現れます。エンベロープ文書のサブセットにこのような属性の非輸入に起因する問題を回避するために、どちらかの彼らは、明示的に効果が必要か、その効果ノードの祖先であるされている正規化されたXML文書のサブセットのノードに与えられなければなりません必要とされているか、彼らは常に、XML文書のサブセットが解釈されているすべてのコンテキストでは同等の値で宣言する必要があります。正規化されたXMLを使用する2.アプリケーションがバインドされている名前空間接頭辞が目に見えて利用されていないXML名前空間宣言の効果に依存してもよいです。例は、値が評価したがって、式で参照名前空間接頭辞に依存するXPath式となる属性であろう。または、属性値は、いくつかのアプリケーションでのQName [XML-NS]と考えられるかもしれないが、それは、XPathにのみ文字列値です。
<number xsi:type="xsd:decimal">10.09</number>.
<数XSI：タイプ= "XSD 10進"> 10.09 </数>。
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.
関係する名前空間接頭辞の使用が表示されるようにXMLを修正しなければならないO、または名前空間の宣言が表示されなければならなくて、XMLを解釈されているすべてのコンテキストで同じ値に束縛されること、またはそのような名前空間の接頭辞はMUST O O InclusiveNamespaces PrefixListに表示されます。
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>
<N1：elem1のxmlns：N1 = "のhttp：//b.example">コンテンツ</ 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>
<N0：PDUのxmlns：N0 = "のhttp：//a.example"> <N1：elem1のxmlns：N1 = "のhttp：//b.example">コンテンツ</ 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:
最初の文書は、上記の標準形式です。しかし、その文書が第二の場合のように包まれていると仮定します。その頂点ノードとしてelem1を持つサブ文書は、XPath式のようなこの第二ケースから抽出することができます。
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]
（。// | // @ * | //名前空間:: *）[祖先-または自己:: 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>
<N1：elem1のxmlns：N0 = "のhttp：//a.example" のxmlns：N1 = "のhttp：//b.example">コンテンツ</ 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名前空間は正規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>
<N0：地元のxmlns：N0 = "FOO：バー" のxmlns：N3 = "ftp://example.org"> <N1：のElem2のxmlns：N1 = "http://example.net" XML：LANG = "EN "> <N3：スタッフのxmlns：N3 =" ftp://example.org "/> </ N1：のElem2> </ N0：ローカル>
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">
<N2：PDUののxmlns：N1 = "http://example.com" のxmlns：N2 = "のhttp：//foo.example" XML：LANG = "FR" のxml：スペース= "維持">
<n1:elem2 xmlns:n1="http://example.net" xml:lang="en"> <n3:stuff xmlns:n3="ftp://example.org"/> </n1:elem2> </n2:pdu>
<N1：のElem2のxmlns：N1 = "http://example.net" XML：LANG = "EN"> <N3：スタッフの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]
（。// | // @ * | //名前空間:: *）[祖先-または自己:: 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>
<N1：のElem2のxmlns：N0 = "FOO：バー" のxmlns：N1 = "http://example.net" のxmlns：N3 = "ftp://example.org" XML：LANG = "EN"> <N3：もの> </ N3：もの> </ 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の両方片における同じオクテットシーケンスによって表されるものの、上記、第二ケースからの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>
<N1：のElem2のxmlns：N1 = "http://example.net" のxmlns：N2 = "のhttp：//foo.example" XML：LANG = "EN" のxml：スペース= "維持"> <N3：スタッフのxmlns ：N3 = "ftp://example.org"> </ N3：もの> </ 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名前空間宣言が存在すると、正規化形式の頂点にその宣言を上昇していました。第二の例では、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正則化を使用して、上記のXPath式によって抽出さのElem2の物理的形態です。
<n1:elem2 xmlns:n1="http://example.net" xml:lang="en"> <n3:stuff xmlns:n3="ftp://example.org"></n3:stuff> </n1:elem2>
<N1：のElem2のxmlns：N1 = "http://example.net" XML：LANG = "EN"> <N3：スタッフのxmlns：N3 = "ftp://example.org"> </ N3：もの> < / 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正則化のためのデータモデル、処理、入力パラメータ、出力データは、以下の例外を除き、カノニカル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].)
ラングとxml：スペースドキュメントのサブセットに適用される1カノニカルXMLは、XMLなどのXML名前空間の属性、各孤立要素ノードの祖先ノードの検索を必要とします。これらは、同じ属性の宣言は（それが文書のサブセットに含まれているか否か）要素の属性軸に既にある場合を除き、要素ノードにコピーされます。この検索やコピーを独占XMLの正規化の方法から省略されています。 2.排他的XML正則化法は、名前空間接頭辞および/またはデフォルトの名前空間の存在を示すトークンのリストを含む追加、nullの可能性が、パラメーターInclusiveNamespaces PrefixListを受信することができます。 CanonicalのXML [XML-C14N]で提供されるこのリストに表示されるすべての名前空間ノードが処理されます。それは目に見えて、その親要素によって利用される1親要素がノード集合であり、2：3。InclusiveNamespaces PrefixListに表示されていないプレフィックスを持つ名前空間ノードNは、条件のすべてが満たされた場合にレンダリングされます、および3接頭辞はまだ出力先祖によってレンダリングされていない、または視覚名前空間の接頭辞を利用する親要素の最も近い出力先祖が同じ名前空間接頭辞と値とノードセットに名前空間ノードを持ちませんN. 4.デフォルトの名前空間を表すトークンは次のようにのxmlns =をレンダリングするためのルールは、「」に変更され、InclusiveNamespaces PrefixListに存在しない場合。ノードセット、出力のxmlnsである要素Eの名前空間軸を=「」canonicalizingとき場合にのみ条件がすべて満たされている場合：1. Eは目に見えてデフォルトの名前空間を利用して（つまり、それが名前空間接頭辞を持ちません） 、および2.それは目に見えて、デフォルトの名前空間は、ノードセットのデフォルトの名前空間ノードを持つ利用Eの最も近い出力先祖をノードセットには、デフォルトの名前空間ノードを持っていない、と3。それは名前空間ノードとしてXPathデータモデルで表現されていないため（「」のxmlns =ため、このステップは必要であるが、名前空間ノードが存在しないとして、ドキュメントサブセット[XML-C14N]でデフォルトの名前空間宣言のセクション4.7伝播を参照します。）
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正則化方法を実現するため（非規範的）方法である - それは、十分に形成されたサブセットを前提と要素がノードセットにある場合、したがってその名前空間軸の全てであること。要素がサブセットにない場合は、どちらもその名前空間軸ではありません。
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の操作：名前空間が行われていない出力頂点要素ノードに属性。）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.それは目に見えて直接の親要素やその属性の1が利用する、またはInclusiveNamespaces PrefixList中に存在する、と2をその接頭辞と値がありませんns_renderedに表示されます。 1.デフォルトの名前空間が目に見えて直接の親要素ノードによって利用される、またはデフォルトのプレフィックスのトークンがInclusiveNamespaces PrefixListに存在し、2要素はありません：条件のすべてが満たされた場合だけ3.「」=のxmlnsをレンダリングデフォルトの名前空間の値を宣言したノード集合に名前空間ノードを持っている、と3デフォルトの名前空間接頭辞はns_rendered辞書に存在していません。 4.既存のエントリを置き換え、ns_rendered辞書に（=「」のxmlnsを含む）すべてのレンダリングされた名前空間ノードを挿入します。プッシュ状態スタックと再帰に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デジタル署名[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
ｈっｔｐ：／／ｗっｗ。ｗ３。おｒｇ／２００１／１０／ｘｍｌーえｘｃーｃ１４ん＃うぃｔｈこっめんｔｓ
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] 1と同様にXMLコメントの直列化を含めて「#WithComments」パラメータを使用することができます。このアルゴリズムはまた、PrefixList属性を持つ空のInclusiveNamespaces要素のオプションの明示的なパラメータを取ります。この属性の値は、名前空間接頭辞の空白区切りのリストであり、そして#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>
<DS：変換アルゴリズム= "http://www.w3.org/2001/10/xml-exc-c14n#"> <EC：InclusiveNamespaces PrefixList = "DSIG石けん#DEFAULT" のxmlns：ECは= "のhttp：// www.w3.org/2001/10/xml-exc-c14n＃ "/> </ DS：変換>
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スキーマ]で表される）スキーマ定義：
<?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 ''> ]>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOCTYPEスキーマPUBLIC！ " - // W3C // DTD XMLスキーマ200102 // EN"「http://www.w3.org/2001/XMLSchema .DTD」[<！ATTLISTスキーマの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">
<スキーマの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#」バージョン= "0.1" のelementFormDefault = "資格">
<element name="InclusiveNamespaces" type="ec:InclusiveNamespaces"/> <complexType name="InclusiveNamespaces"> <attribute name="PrefixList" type="NMTOKENS"/> </complexType> </schema>
<要素名= "InclusiveNamespaces" タイプ= "EC：InclusiveNamespaces" /> <complexTypeの名= "InclusiveNamespaces"> <属性名= "PrefixList" タイプ= "NMTOKENS" /> </ complexTypeの> </スキーマ>
DTD: <!ELEMENT InclusiveNamespaces EMPTY > <!ATTLIST InclusiveNamespaces PrefixList NMTOKENS #REQUIRED >
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.
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.
例えば、<フー/>要素は、<バズ用のxmlns = "http://example.org <バー/> <フー/> </バー>のソース・インスタンスにログインした後に除去し、ターゲット・インスタンスに配置された場合/バー "/> <Fooの/> </バズ>、署名がまだ有効である必要がありますが、<Fooの/>はhttp://example.org/bar名前空間に属するものとして解釈されている場合ではありません。これは、ノードがどのように処理されるかに依存。
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を指定しなければならない（すなわち、ソース、断片、およびターゲット） （：LANG、XML：スペース、とxml：ベース例えば、XML）またはデフォルトの名前空間宣言（例えば、のxmlns =「」）とXMLの属性について、ノードセット処理（すなわち、取り外し、交換、および挿入）を定義。
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フラグメント]として、それは、その結果を作成することがますます困難になることを警告するために提供される「とは、そのアプリケーションのコンテキストにおいて有意義かつ明白です。」
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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（Second Editionを）。 T.ブレイ、E. MALER、J.パオリ、及びC. M. Sperberg-マックイーン。 http://www.w3.org/TR/2000/REC-xml-20001006の利用可能なW3C勧告、2000年10月
[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]ボイヤー、J.、 "標準的なXML"、RFC 3076、2001年3月もhttp://www.w3.org/TR/2001/REC-xml-c14n-20010315で利用可能なW3C勧告
[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スキーマ] XMLスキーマパート1：構造D.ブナ、M.マロニー、N.メンデルゾーン、およびH.トンプソン。 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/の利用可能なW3C勧告、2001年5月
[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. DeRose。 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]バーナーズ=リー、T.、フィールディング、R.、および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. Orchad。 http://www.w3.org/TR/2002/CR-xinclude-20020221/の利用可能なW3C勧告候補、2002年2月
[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]イーストレイク、D.、Reagle、J.とD.ソロ、 "XML-署名構文と処理"、RFC 3275、2002年3月利用可能でhttp://www.w3.org/TR/2002/ REC-XMLDSIG-コア-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. Reagle。 http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/の利用可能なW3C勧告候補、2002年3月
[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フラグメント] XMLフラグメントインターチェンジ。 P.グロッソ、およびD. Veillard。 http://www.w3.org/TR/2001/CR-xml-fragment-20010212の利用可能なW3C勧告候補、2001年2月
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
Authors' Addresses
著者のアドレス
John Boyer PureEdge Solutions Inc. 4396 West Saanich Rd. Victoria, BC, Canada V8Z 3E9
ジョン・ボワイエPureEdgeソリューションズ株式会社4396西Saanich Rdを。ビクトリア、BC、カナダV8Z 3E9
Phone: +1-888-517-2675 EMail: jboyer@PureEdge.com
電話：+ 1-888-517-2675 Eメール：jboyer@PureEdge.com
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ155ビーバー通りミルフォード、MA 01757 USA
Phone: +1-508-634-2066 (h) +1-508-786-7554 (w) EMail: Donald.Eastlake@motorola.com
電話番号：+ 1-508-634-2066（H）+ 1-508-786-7554（W）メール：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
ジョセフM. Reagleジュニア、コンピュータサイエンスNE43-350のための技術研究所のW3Cマサチューセッツ工科大学、545テクノロジースクエアケンブリッジ、MA 02139
Phone: +1-617-258-7621 EMail: reagle@mit.edu
電話：+ 1-617-258-7621 Eメール：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.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。