Network Working Group J. Boyer
Request for Comments: 3741 PureEdge Solutions
Category: Informational D. Eastlake 3rd
Motorola
J. Reagle
W3C
March 2004
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规范化，版本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.
规范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
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
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.可以确定两个节点集是否相同，但本规范在[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.
与本RFC相对应的万维网联盟建议位于：http://www.w3.org/TR/xml-exc-c14n. 勘误表位于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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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节点集可能不包括文档中的所有节点。正如[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]
[diagram of nodes,
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
文档子集中的元素E可视地利用名称空间声明，即名称空间前缀P和绑定值V，前提是E或文档子集中具有父元素E的属性节点具有限定名称，其中P是名称空间前缀。类似的定义
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没有命名空间前缀，则会出现默认命名空间声明。
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].
本规范中描述的规范化方法接收InclusiveNamespaces PrefixList参数，该参数列出了按照规范化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:space）不会导入到文档子集的孤立节点中，并且不在InclusiveNamespaces PrefixList上的*命名空间节点仅在开始标记中表示，在开始标记中它们是可见的，并且如果它们不是该标记的输出祖先有效的话。
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规范化的应用程序与规范化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]的限制以及以下两个附加限制：
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名称空间属性的效果，如祖先节点中出现的XML:lang、XML:space和XML:base。为了避免由于未将此类属性导入到封装文档子集而导致的问题，它们必须在规范化的XML文档子集的某个节点中显式给出，其中需要它们的效果，或者是需要它们的效果的节点的祖先，或者必须在解释XML文档子集的每个上下文中始终使用等效值声明它们。2.使用被规范化的XML的应用程序可能取决于XML命名空间声明的效果，其中绑定的命名空间前缀未被明显使用。例如，属性的值是XPath表达式，因此其计算取决于表达式中引用的名称空间前缀。或者，某些应用程序可能会将属性值视为QName[XML-NS]，但它只是XPath的字符串值：
<number xsi:type="xsd:decimal">10.09</number>.
<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的每个上下文中的相同值，或者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
在某些情况下，特别是对于协议中的签名XML应用程序，需要规范化子文档，使其基本上独立于XML上下文。这是因为，在协议应用程序中，在消息或传输元素的不同层中封装XML是很常见的，可以去掉这种封装，然后
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片段是经过签名的，则需要对其进行规范化，以使这些操作不会破坏签名，但签名仍能提供实际获得的尽可能多的安全性。
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">
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>
<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:
上面的第一个文档是标准格式的。但是假设文档像第二种情况一样被封装。可以使用XPath表达式从第二种情况中提取以elem1作为其顶点节点的子文档，例如：
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]
(//. | //@* | //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):
将规范XML应用于生成的XPath节点集的结果如下（为适应此文档而换行除外）：
<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">
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.
请注意，规范XML包含n0命名空间，因为它包含命名空间上下文。此更改将破坏基于第一个版本的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: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">
<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>
<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]
(//. | //@* | //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>
<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中都由相同的八位字节序列表示，但第二种情况下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: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命名空间声明将该声明提升到规范化形式的顶点。在第二个示例中，n0消失了，但n2出现了，n3不再提升，并且由于上下文中的更改，出现了一个xml:space声明。但并不是所有的上下文变化都有效果。在第二个示例中，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: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规范化的数据模型、处理、输入参数和输出数据与规范化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
1. 应用于文档子集的规范化XML需要在每个孤立元素节点的祖先节点中搜索XML命名空间中的属性，例如XML:lang和XML:space。除非相同属性的声明已经在元素的属性轴中（无论是否包含在
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规范化方法中省略了此搜索和复制。2.独占XML规范化方法可能会收到一个额外的、可能为空的参数InclusiveNamespaces PrefixList，该参数包含一个名称空间前缀列表和/或一个表示存在默认名称空间的标记。此列表中出现的所有命名空间节点都按照规范XML[XML-C14N]中的规定进行处理。3.如果满足以下所有条件，则呈现前缀未出现在InclusiveNamespaces PrefixList中的命名空间节点N：1。其父元素位于节点集中，2。它明显地被其父元素利用，以及3。前缀尚未由任何输出祖先呈现，或者其父元素的最近输出祖先（明显使用名称空间前缀）在节点集中没有与N.4相同名称空间前缀和值的名称空间节点。如果表示默认命名空间的标记不在InclusiveNamespaces PrefixList中，则呈现xmlns=”“的规则将更改如下。规范化节点集中元素E的命名空间轴时，如果且仅当满足所有条件时输出xmlns=“”：1。E明显地利用了默认名称空间（即，它没有名称空间前缀），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规范化方法——它假设一个格式良好的子集，并且如果一个元素在节点集中，那么它的所有名称空间轴也是如此；如果元素不在子集中，则其名称空间轴也不在其中。
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:namespace属性复制到输出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。直接父元素或其属性之一可以明显地使用它，或者出现在InclusiveNamespaces PrefixList和2中。其前缀和值不会出现在ns_渲染中。3.Render xmlns=“”当且仅当满足所有条件时：1。直接父元素节点可以明显地使用默认名称空间，或者默认前缀标记出现在InclusiveNamespaces PrefixList和2中。元素在节点集中没有声明默认名称空间值的名称空间节点，3。默认名称空间前缀出现在字典ns_中。4.将所有呈现的命名空间节点（包括xmlns=“”）插入ns_呈现字典，替换任何现有条目。将ns_渲染推到状态堆栈上并递归。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]中的转换或规范化方法算法。
Identifier:
http://www.w3.org/2001/10/xml-exc-c14n#
Identifier:
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注释的序列化。此算法还接受带有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: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].
指示独占规范化转换，但应根据[XML-C14N]处理前缀为“dsig”或“soap”的命名空间和默认命名空间。
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" 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">
<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>
<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 >
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节点集。其中三个例子包括：
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.
本规范的要求是满足“需要一种方法，在实际范围内，将祖先上下文从规范化子文档中排除”的应用程序，本规范通过从片段中排除其祖先中未使用的任何上下文来满足这一要求。因此，该片段上的签名[XMLDSIG]将在其源上下文中保持有效，从源上下文中删除，甚至在新的目标上下文中也保持有效。然而，该规范并没有将片段与目标上下文中的混乱解释隔离开来。
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 名称空间：这取决于节点的处理方式。
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,
本规范不定义删除、插入和“修复”节点集的机制。（有关此类规范的示例，请参阅执行[XInclude]时创建结果信息集所需的处理（第4.5节）。相反，应用程序必须仔细指定XML（即源、片段、，
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).
和目标）或定义关于默认名称空间声明（如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片段]，创建“在其应用程序上下文中有意义且明确”的结果变得越来越困难
[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] 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-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, March 2001.
Also a W3C Recommendation available at
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] 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-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 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/
[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 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
[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.和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 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/
[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, March 2002.
Available at 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 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-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 Fragment Interchange. P. Grosso, and D.
Veillard. W3C Candidate Recommendation, February
2001. Available at 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号V8Z 3E9
Phone: +1-888-517-2675
EMail: jboyer@PureEdge.com
Phone: +1-888-517-2675
EMail: jboyer@PureEdge.com
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake 3rd Motorola美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-634-2066 (h)
+1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
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麻省理工学院计算机科学实验室NE43-350，马萨诸塞州剑桥技术广场545号，邮编02139
Phone: +1-617-258-7621
EMail: reagle@mit.edu
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.
版权所有（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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。