Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 6920 Trinity College Dublin
Category: Standards Track D. Kutscher
ISSN: 2070-1721 NEC
C. Dannewitz
University of Paderborn
B. Ohlman
A. Keranen
Ericsson
P. Hallam-Baker
Comodo Group Inc.
April 2013
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 6920 Trinity College Dublin
Category: Standards Track D. Kutscher
ISSN: 2070-1721 NEC
C. Dannewitz
University of Paderborn
B. Ohlman
A. Keranen
Ericsson
P. Hallam-Baker
Comodo Group Inc.
April 2013
Naming Things with Hashes
用散列命名事物
Abstract
摘要
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.
本文档定义了一组使用散列函数的输出识别对象（本例中为数字对象）的方法。它为此指定了一个新的URI方案，一种将这些URL映射到HTTP URL的方法，以及这些名称的二进制和人类可说出的格式。各种格式旨在支持（但不要求）指向被引用对象的强链接，以便被引用对象可以与对其的引用进行相同程度的身份验证。这项工作的目的是使URL中哈希输出的当前使用标准化，并支持新的以信息为中心的应用程序和协议中哈希输出的其他使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6920.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6920.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Hashes Are What Count . . . . . . . . . . . . . . . . . . . . 4
3. Named Information (ni) URI Format . . . . . . . . . . . . . . 6
3.1. Content Type Query String Attribute . . . . . . . . . . . 8
4. .well-known URI . . . . . . . . . . . . . . . . . . . . . . . 9
5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10
6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Human-Speakable (nih) URI Format . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Hello World! . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Public Key Examples . . . . . . . . . . . . . . . . . . . 13
8.3. nih Usage Example . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Assignment of ni URI Scheme . . . . . . . . . . . . . . . 15
9.2. Assignment of nih URI Scheme . . . . . . . . . . . . . . . 15
9.3. Assignment of .well-known 'ni' URI . . . . . . . . . . . . 16
9.4. Creation of Named Information Hash Algorithm Registry . . 16
9.5. Creation of Named Information Parameter Registry . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Hashes Are What Count . . . . . . . . . . . . . . . . . . . . 4
3. Named Information (ni) URI Format . . . . . . . . . . . . . . 6
3.1. Content Type Query String Attribute . . . . . . . . . . . 8
4. .well-known URI . . . . . . . . . . . . . . . . . . . . . . . 9
5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10
6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Human-Speakable (nih) URI Format . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Hello World! . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Public Key Examples . . . . . . . . . . . . . . . . . . . 13
8.3. nih Usage Example . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Assignment of ni URI Scheme . . . . . . . . . . . . . . . 15
9.2. Assignment of nih URI Scheme . . . . . . . . . . . . . . . 15
9.3. Assignment of .well-known 'ni' URI . . . . . . . . . . . . 16
9.4. Creation of Named Information Hash Algorithm Registry . . 16
9.5. Creation of Named Information Parameter Registry . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Identifiers -- names or locators -- are used in various protocols to identify resources. In many scenarios, those identifiers contain values that are obtained from hash functions. Different deployments have chosen different ways to include the hash function outputs in their identifiers, resulting in interoperability problems.
标识符——名称或定位器——在各种协议中用于标识资源。在许多情况下，这些标识符包含从哈希函数获得的值。不同的部署选择了不同的方式将哈希函数输出包含在其标识符中，从而导致互操作性问题。
This document defines the "Named Information" identifier, which provides a set of standard ways to use hash function outputs in names. We begin with a few example uses for various ways to include hash function output in a name, with the specifics defined later in this document. Figure 1 shows an example of the Named Information (ni) URI scheme that this document defines.
本文档定义了“命名信息”标识符，该标识符提供了一组在名称中使用哈希函数输出的标准方法。我们从几个示例开始，使用各种方法将哈希函数输出包含在一个名称中，具体细节将在本文档后面定义。图1显示了本文档定义的命名信息（ni）URI方案的示例。
ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
Figure 1: Example ni URI
图1：示例NIURI
Hash function outputs can be used to ensure uniqueness in terms of mapping URIs [RFC3986] to a specific resource or to make URIs hard to guess for security reasons. Since there is no standard way to interpret those strings today, in general only the creator of the URI knows how to use the hash function output. Other protocols, such as application-layer protocols for accessing "smart objects" in constrained environments, also require more compact (e.g., binary) forms of such identifiers. In yet other situations, people may have to speak such values, e.g., in a voice call (see Section 8.3), in order to confirm the presence or absence of a resource.
哈希函数输出可用于确保将URI[RFC3986]映射到特定资源方面的唯一性，或出于安全原因使URI难以猜测。由于目前没有解释这些字符串的标准方法，通常只有URI的创建者知道如何使用哈希函数输出。其他协议，例如用于在受限环境中访问“智能对象”的应用层协议，也需要更紧凑（例如二进制）形式的此类标识符。在其他情况下，人们可能必须说出这些值，例如在语音通话中（参见第8.3节），以确认是否存在资源。
As another example, protocols for accessing in-network storage servers need a way to identify stored resources uniquely and in a location-independent way so that replicas on different servers can be accessed by the same name. Also, such applications may require verification that a resource representation that has been obtained actually corresponds to the name that was used to request the resource, i.e., verifying the binding between the data and the name, which is here termed "name-data integrity".
作为另一个示例，用于访问网络存储服务器的协议需要一种方法来唯一地标识存储的资源，并且以独立于位置的方式进行标识，以便可以使用相同的名称访问不同服务器上的副本。此外，此类应用可能需要验证已获得的资源表示实际上对应于用于请求资源的名称，即，验证数据和名称之间的绑定，在这里称为“名称数据完整性”。
Similarly, in the context of information-centric networking [NETINF-ARCHITECTURE] [CCN] and elsewhere, there is value in being able to compare a presented resource against the URI that was used to access that resource. If a cryptographically strong comparison function can be used, then this allows for many forms of in-network storage, without requiring as much trust in the infrastructure used to present the resource. The outputs of hash functions can be used in this manner, if they are presented in a standard way.
类似地，在以信息为中心的网络[NETINF-ARCHITECTURE][CCN]和其他环境中，能够将呈现的资源与用于访问该资源的URI进行比较是有价值的。如果可以使用加密功能强大的比较功能，那么就可以使用多种形式的网络内存储，而不需要对用于表示资源的基础设施有太多的信任。哈希函数的输出可以以这种方式使用，如果它们以标准方式呈现的话。
Additional applications might include creating references from web pages delivered over HTTP/TLS; DNS resource records signed using DNSSEC or data values embedded in certificates, Certificate Revocation Lists (CRLs), or other signed data objects.
其他应用程序可能包括从通过HTTP/TLS交付的网页创建引用；使用DNSSEC或嵌入在证书、证书吊销列表（CRL）或其他签名数据对象中的数据值签名的DNS资源记录。
The Named Identifier can be represented in a number of ways: using the ni URI scheme that we specifically define for the name (which is very similar to the "magnet link" that is informally defined in other protocols [Magnet]), or using other mechanisms also defined herein. However it is represented, the Named Identifier *names* a resource, and the mechanism used to dereference the name and to *locate* the named resource needs to be known by the entity that dereferences it.
命名标识符可以用多种方式表示：使用我们专门为名称定义的ni-URI方案（与其他协议[magnet]中非正式定义的“magnet-link”非常类似），或者使用本文中也定义的其他机制。无论如何表示，取消引用的实体都需要知道命名标识符*命名*资源，以及用于取消引用名称和*定位*命名资源的机制。
Media content-type, alternative locations for retrieval, and other additional information about a resource named using this scheme can be provided using a query string. "The Named Information (ni) URI Scheme: Optional Features" [DECPARAMS] describes specific values that can be used in such query strings for these various purposes and other extensions to this basic format specification.
可以使用查询字符串提供媒体内容类型、用于检索的替代位置以及有关使用此方案命名的资源的其他附加信息。“命名信息（ni）URI方案：可选功能”[DECPARAMS]描述了可在此类查询字符串中用于这些不同目的的特定值，以及此基本格式规范的其他扩展。
In addition, we define a ".well-known" URL equivalent, a way to include a hash as a segment of an HTTP URL, a binary format for use in protocols that require more compact names, and a human-speakable text form that could be used, e.g., for reading out (parts of) the name over a voice connection.
此外，我们还定义了“.well-known”URL等价物，一种将哈希作为HTTP URL段的方式，一种用于需要更紧凑名称的协议的二进制格式，以及一种可用于通过语音连接读取（部分）名称的人类可说出文本形式。
Not all uses of these names require use of the full hash output -- truncated hashes can be safely used in some environments. For this reason, we define a new IANA registry for hash functions to be used with this specification so as not to mix strong and weak (truncated) hash algorithms in other protocol registries.
并非所有这些名称的使用都需要使用完整的散列输出——在某些环境中可以安全地使用截断的散列。出于这个原因，我们为哈希函数定义了一个新的IANA注册表，以便与本规范一起使用，从而避免在其他协议注册表中混合强和弱（截断）哈希算法。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Syntax definitions in this memo are specified according to ABNF [RFC5234].
本备忘录中的语法定义根据ABNF[RFC5234]规定。
This section contains basic considerations related to how we use hash function outputs that are common to all formats.
本节包含与如何使用所有格式通用的哈希函数输出相关的基本注意事项。
When comparing two names of the form defined here, an implementation MUST only consider the digest algorithm and the digest value, i.e., it MUST NOT consider other fields defined below (such as an authority field from a URI or any parameters). Implementations MUST consider
当比较这里定义的表单的两个名称时，实现必须只考虑摘要算法和摘要值，即，它不必考虑下面定义的其他字段（例如来自URI的权限字段或任何参数）。实现必须考虑
two hashes identical, regardless of encoding, if the decoded hashes are based on the same algorithm and have the same length and the same binary value. In that case, the two names can be treated as referring to the same thing.
如果解码的哈希基于相同的算法，并且具有相同的长度和相同的二进制值，则两个哈希相同，无论编码如何。在这种情况下，这两个名字可以被视为是指同一件事。
The sha-256 algorithm as specified in [SHA-256] is mandatory to implement; that is, implementations MUST be able to generate/send and to accept/process names based on a sha-256 hash. However, implementations MAY support additional hash algorithms and MAY use those for specific names, for example, in a constrained environment where sha-256 is non-optimal or where truncated names are needed to fit into corresponding protocols (when a higher collision probability can be tolerated).
必须实现[sha-256]中规定的sha-256算法；也就是说，实现必须能够基于sha-256哈希生成/发送和接受/处理名称。然而，实现可以支持额外的散列算法，并且可以将这些算法用于特定的名称，例如，在sha-256不是最优的受限环境中，或者在需要截断名称以适应相应协议的情况下（当可以容忍更高的冲突概率时）。
Truncated hashes MAY be supported. When a hash value is truncated, the name MUST indicate this. Therefore, we use different hash algorithm strings in these cases, such as sha-256-32 for a 32-bit truncation of a sha-256 output. A 32-bit truncated hash is essentially useless for security in almost all cases but might be useful for naming. With current best practices [RFC3766], very few, if any, applications making use of names with less than 100-bit hashes will have useful security properties.
可能支持截断哈希。当哈希值被截断时，名称必须指明这一点。因此，在这些情况下，我们使用不同的哈希算法字符串，例如sha-256-32对sha-256输出进行32位截断。在几乎所有情况下，32位截断散列对安全性基本上都是无用的，但可能对命名有用。在当前的最佳实践[RFC3766]中，使用小于100位哈希的名称的应用程序很少（如果有的话）具有有用的安全属性。
When a hash value is truncated to N bits, the leftmost N bits (that is, the most significant N bits in network byte order) from the binary representation of the hash value MUST be used as the truncated value. An example of a 128-bit hash output truncated to 32 bits is shown in Figure 2.
当哈希值被截断为N位时，必须将哈希值二进制表示形式中最左边的N位（即网络字节顺序中最重要的N位）用作截断值。图2中显示了被截断为32位的128位散列输出的示例。
128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 32-bit truncated hash: 0x26535790
128位哈希：0x265357902fe1b7e2a04b897c6025d7a2 32位截断哈希：0x26535790
Figure 2: Example of Truncated Hash
图2：截断散列的示例
When the input to the hash algorithm is a public key value, as may be used by various security protocols, the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure (Section 4.1 of [RFC5280]). This input has been chosen primarily for compatibility with the DANE TSLA protocol [RFC6698] but also includes any relevant public key parameters in the hash input, which is sometimes necessary for security reasons. This does not force use of X.509 or full compliance with [RFC5280] since formatting any public key as a SubjectPublicKeyInfo is relatively straightforward and well supported by libraries.
当散列算法的输入为公钥值时（可由各种安全协议使用），应在X.509 SubjectPublicKeyInfo结构（RFC5280）中的公钥上计算散列（第4.1节）。选择此输入主要是为了与DANE TSLA协议[RFC6698]兼容，但也包括哈希输入中的任何相关公钥参数，这有时出于安全原因是必要的。这并不强制使用X.509或完全符合[RFC5280]，因为将任何公钥格式化为SubjectPublicKeyInfo相对简单，并且受到库的良好支持。
Any of the formats defined below can be used to represent the resulting name for a public key.
下面定义的任何格式都可用于表示公钥的结果名称。
Other than in the aforementioned special case where public keys are used, we do not specify the hash function input here. Other specifications are expected to define this.
除了上面提到的使用公钥的特殊情况外，我们不在这里指定哈希函数输入。预计其他规范将对此进行定义。
A Named Information (ni) URI consists of the following nine components:
命名信息（ni）URI由以下九个组件组成：
Scheme Name: The scheme name is 'ni'.
方案名称：方案名称为“ni”。
Colon and Slashes: The literal "://"
Colon and Slashes: The literal "://"
Authority: The optional authority component may assist applications in accessing the object named by an ni URI. There is no default value for the authority field. (See Section 3.2.2 of [RFC3986] for details.) While ni names with and without an authority differ syntactically from ni names with different authorities, all three refer to the same object if and only if the digest algorithm, length, and value are the same.
权限：可选的权限组件可以帮助应用程序访问由NIURI命名的对象。“权限”字段没有默认值。（详情请参见[RFC3986]第3.2.2节。）尽管具有和不具有权限的ni名称在语法上与具有不同权限的ni名称不同，但只有当且仅当摘要算法、长度和值相同时，这三个名称才引用同一对象。
One slash: The literal "/"
一个斜杠：文字“/”
Digest Algorithm: The name of the digest algorithm, as specified in the IANA registry defined in Section 9.4 below.
摘要算法：在下文第9.4节定义的IANA注册表中指定的摘要算法名称。
Separator: The literal ";"
分隔符：文本“
Digest Value: The digest value MUST be encoded using the base64url [RFC4648] encoding, with no "=" padding characters.
摘要值：必须使用base64url[RFC4648]编码对摘要值进行编码，不带“=”填充字符。
Query Parameter separator '?': The query parameter separator acts as a separator between the digest value and the query parameters (if specified). For compatibility with Internationalized Resource Identifiers (IRIs), non-ASCII characters in the query part MUST be encoded as UTF-8, and the resulting octets MUST be percent-encoded (see [RFC3986], Section 2.1).
查询参数分隔符“？”：查询参数分隔符用作摘要值和查询参数（如果指定）之间的分隔符。为了与国际化资源标识符（IRI）兼容，查询部分中的非ASCII字符必须编码为UTF-8，产生的八位字节必须进行百分比编码（请参见[RFC3986]，第2.1节）。
Query Parameters: A "tag=value" list of optional query parameters as are used with HTTP URLs [RFC2616] with a separator character '&' between each. For example, "foo=bar&baz=bat".
查询参数：可选查询参数的“tag=value”列表，与HTTP URL[RFC2616]一起使用，每个URL之间有一个分隔符“&”。例如，“foo=bar&baz=bat”。
It is OPTIONAL for implementations to check the integrity of the URI/ resource mapping when sending, receiving, or processing ni URIs.
对于实现来说，在发送、接收或处理ni URI时检查URI/资源映射的完整性是可选的。
Escaping of characters follows the rules in RFC 3986. This means that percent-encoding is used to distinguish between reserved and unreserved functions of the same character in the same URI component.
字符转义遵循RFC 3986中的规则。这意味着百分比编码用于区分同一URI组件中相同字符的保留函数和非保留函数。
As an example, an ampersand ('&') is used in the query part to separate attribute-value pairs; therefore, an ampersand in a value has to be escaped as '%26'. Note that the set of reserved characters differs for each component. As an example, a slash ('/') does not have any reserved function in a query part and therefore does not have to be escaped. However, it can still appear escaped as '%2f' or '%2F', and implementations have to be able to understand such escaped forms. Also note that any characters outside those allowed in the respective URI component have to be escaped.
例如，在查询部分中使用符号（“&”）来分隔属性值对；因此，必须将值中的与符号转义为“%26”。请注意，每个组件的保留字符集都不同。例如，斜杠（“/”）在查询部分中没有任何保留函数，因此不必转义。但是，它仍然可以显示为转义为“%2f”或“%2f”，并且实现必须能够理解此类转义形式。还要注意，必须转义各个URI组件中允许的字符之外的任何字符。
The Named Information URI adapts the URI definition from the URI Generic Syntax [RFC3986]. We start with the base URI production:
命名信息URI根据URI通用语法[RFC3986]调整URI定义。我们从基本URI产品开始：
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
; from RFC 3986
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
; from RFC 3986
Figure 3: URI Syntax
图3:URI语法
Then, we adapt that for the Named Information URI:
然后，我们对命名信息URI进行调整：
NI-URI = ni-scheme ":" ni-hier-part [ "?" query ]
; adapted from "URI" in RFC 3986
; query is from RFC 3986, Section 3.4
ni-scheme = "ni"
ni-hier-part = "//" [ authority ] "/" alg-val
; authority is from RFC 3986, Section 3.2
alg-val = alg ";" val
; adapted from "hier-part" in RFC 3986
alg = 1*unreserved
val = 1*unreserved
; unreserved is from RFC 3986, Section 2.3
NI-URI = ni-scheme ":" ni-hier-part [ "?" query ]
; adapted from "URI" in RFC 3986
; query is from RFC 3986, Section 3.4
ni-scheme = "ni"
ni-hier-part = "//" [ authority ] "/" alg-val
; authority is from RFC 3986, Section 3.2
alg-val = alg ";" val
; adapted from "hier-part" in RFC 3986
alg = 1*unreserved
val = 1*unreserved
; unreserved is from RFC 3986, Section 2.3
Figure 4: ni Name Syntax
图4:ni名称语法
The "val" field MUST contain the output of base64url encoding (with no "=" padding characters), the result of applying the hash function ("alg") to its defined input, which defaults to the object bytes that are expected to be returned when the URI is dereferenced.
“val”字段必须包含base64url编码的输出（不带“=”填充字符），这是将哈希函数（“alg”）应用于其定义的输入的结果，默认为在解除URI引用时预期返回的对象字节。
Relative ni URIs can occur. In such cases, the algorithm in Section 5 of [RFC3986] applies. As an example, in Figure 5, the absolute URI for "this third document" is "ni://example.com/sha-256-128;...".
可能出现相对ni URI。在这种情况下，[RFC3986]第5节中的算法适用。例如，在图5中，“第三个文档”的绝对URI是“ni://example.com/sha-256-128；…”。
<html>
<head>
<title>ni: relative URI test</title>
<base href="ni://example.com">
</head>
<html>
<head>
<title>ni: relative URI test</title>
<base href="ni://example.com">
</head>
<body>
<p>Please check <a href="sha-256;f4OxZX...">this document</a>.
and <a href="sha-256;UyaQV...">this other document</a>.
and <a href="sha-256-128;...">this third document</a>.
</p>
</body>
</html>
<body>
<p>Please check <a href="sha-256;f4OxZX...">this document</a>.
and <a href="sha-256;UyaQV...">this other document</a>.
and <a href="sha-256-128;...">this third document</a>.
</p>
</body>
</html>
Figure 5: Example HTML with Relative ni URI
图5：具有相对NIURI的HTML示例
The authority field in an ni URI is not quite the same as that from an HTTP URL, even though the same values (e.g., DNS names) may be usefully used in both. For an ni URI, the authority does not control nearly as much of the structure of the "right-hand side" of the URI. With ni URIs we also define standard query string attributes and, of course, have a strictly defined way to include the hash value.
NIURI中的authority字段与HTTP URL中的authority字段并不完全相同，即使在这两种URL中使用相同的值（例如DNS名称）也是有用的。对于NIURI，权威机构几乎无法控制URI“右侧”的大部分结构。使用NIURI，我们还定义了标准的查询字符串属性，当然，我们有一种严格定义的方法来包含哈希值。
Internationalisation of strings within ni names is handled exactly as for http URIs -- see [RFC2616], Section 3.2.3.
ni名称中字符串的国际化处理与http URI完全相同——请参见[RFC2616]第3.2.3节。
The semantics of a digest being used to establish a secure reference from an authenticated source to an external source may be a function of associated metadata such as the Content Type. The Content Type "ct" parameter specifies the MIME Content Type of the associated data as defined in [RFC6838]. See Section 9.5 for the associated IANA registry for ni parameter names as shown in Figure 6. Implementations of this specification MUST support parsing the "ct=" query string attribute name.
用于建立从认证源到外部源的安全引用的摘要的语义可以是相关元数据（例如内容类型）的函数。内容类型“ct”参数指定[RFC6838]中定义的关联数据的MIME内容类型。有关ni参数名称的相关IANA注册表，请参见第9.5节，如图6所示。此规范的实现必须支持解析“ct=”查询字符串属性名称。
ni:///sha-256-32;f4OxZQ?ct=text/plain
ni:///sha-256-32;f4OxZQ?ct=text/plain
Figure 6: Example ni URI with Content Type
图6：具有内容类型的NIURI示例
Protocols making use of ni URIs will need to specify how to verify name-data integrity for the MIME Content Types that they need to process and will need to take into account possible Content-Transfer-Encodings and other aspects of MIME encoding.
使用ni URI的协议需要指定如何验证需要处理的MIME内容类型的名称数据完整性，并且需要考虑可能的内容传输编码和MIME编码的其他方面。
Implementations of this specification SHOULD support name-data integrity validation for at least the application/octet-stream Content Type, with no explicit Content-Transfer-Encoding (which is equivalent to binary). Additional Content Types and Content-Transfer-Encodings can of course also be supported, but are OPTIONAL. Note that the hash is calculated after the Content-Transfer-Encoding is removed so it is applied to the raw data.
此规范的实现应至少支持应用程序/八位字节流内容类型的名称数据完整性验证，而不支持显式内容传输编码（相当于二进制）。当然，还可以支持其他内容类型和内容传输编码，但这是可选的。请注意，哈希是在删除内容传输编码后计算的，因此它将应用于原始数据。
If a) the user agent is sensitive to the Content Type and b) the ni name used has a "ct=" query string attribute and c) the object is retrieved (from a server) using a protocol that specifies a Content Type, then, if the two Content Types match, all is well. If, in this situation, the Content Types do not match, then the client SHOULD handle that situation as a potential security error. Content Type matching rules are defined in [RFC2045], Section 5.1.
如果a）用户代理对内容类型敏感，b）使用的ni名称具有“ct=”query string属性，c）使用指定内容类型的协议（从服务器）检索对象，则如果两种内容类型匹配，则一切正常。如果在这种情况下，内容类型不匹配，那么客户端应该将这种情况作为潜在的安全错误处理。[RFC2045]第5.1节定义了内容类型匹配规则。
We define a mapping between URIs following the ni URI scheme and HTTP [RFC2616] or HTTPS [RFC2818] URLs that makes use of the .well-known URI [RFC5785] by defining an "ni" suffix (see Section 9).
我们通过定义“ni”后缀（参见第9节），定义遵循ni-URI方案的URI与HTTP[RFC2616]或HTTPS[RFC2818]url之间的映射，这些url利用了众所周知的URI[RFC5785]。
The HTTP(S) mapping MAY be used in any context where clients with support for ni URIs are not available.
HTTP（S）映射可以在任何不支持ni URI的客户端可用的上下文中使用。
Since the .well-known name-space is not intended for general information retrieval, if an application dereferences a .well-known/ni URL via HTTP(S), then it will often receive a 3xx HTTP redirection response. A server responding to a request for a .well-known/ni URL will often therefore return a 3xx response, and a client sending such a request MUST be able to handle that, as should any fully compliant HTTP [RFC2616] client.
由于.well-known名称空间不用于一般信息检索，如果应用程序通过HTTP取消引用.well-known/ni URL，则它通常会收到3xx HTTP重定向响应。因此，响应.well-known/ni URL请求的服务器通常会返回3xx响应，发送此类请求的客户端必须能够处理该响应，任何完全兼容的HTTP[RFC2616]客户端也必须能够处理该响应。
For an ni name of the form "ni://n-authority/alg;val?query-string" the corresponding HTTP(S) URL produced by this mapping is "http://h-authority/.well-known/ni/alg/val?query-string", where "h-authority" is derived as follows: If the ni name has a specified authority (i.e., the n-authority is non-empty), then the h-authority MUST have the same value. If the ni name has no authority specified (i.e., the n-authority string is empty), a h-authority value MAY be derived from the application context. For example, if the mapping is being done in the context of a web page, then the origin [RFC6454] for that web site can be used. Of course, in general there are no guarantees that the object named by the ni URI will be available via the corresponding HTTP(S) URL. But in the case that any data is returned, the retriever can determine whether or not it is content that matches the ni URI.
对于形式为“ni://n-authority/alg；val？查询字符串”的ni名称，此映射生成的相应HTTP（S）URL为http://h-authority/.well-known/ni/alg/val?query-字符串”，其中“h-权限”派生如下：如果ni名称具有指定权限（即，n-权限为非空），那么h-authority必须具有相同的值。如果ni名称没有指定权限（即n-authority字符串为空），则可以从应用程序上下文派生h-authority值。例如，如果映射是在网页的上下文中完成的，则可以使用该网站的源[RFC6454]。当然，通常不能保证NIURI命名的对象通过相应的HTTP（S）URL可用。但在返回任何数据的情况下，检索器可以确定是否是与NIURI匹配的内容。
If an application is presented with an HTTP(S) URL with "/.well-known/ni/" as the start of its pathname component, then the reverse mapping to an ni URI either including or excluding the authority might produce an ni URI that is meaningful. However, there is no guarantee that this will be the case.
如果应用程序显示的HTTP（S）URL以“/.well-known/ni/”作为其路径名组件的开始，则反向映射到包含或排除授权的ni URI可能会生成有意义的ni URI。然而，无法保证情况会如此。
When mapping from an ni URI to a .well-known URL, an implementation will have to decide between choosing an "http" or "https" URL. If the object referenced does in fact match the hash in the URL, then there is arguably no need for additional data integrity, if the ni URI or .well-known URL was received "securely." However, TLS also provides confidentiality, so there can still be reasons to use the "https" URL scheme even in this case. Additionally, web server policy such as [RFC6797] may dictate that data only be available over "https". In general, however, whether to use "http" or "https" is something that needs to be decided by the application.
当从NIURI映射到一个众所周知的URL时，实现必须在选择“http”或“https”URL之间做出决定。如果引用的对象确实与URL中的哈希匹配，那么如果ni URI或.well-known URL是“安全地”接收的，则可以说不需要额外的数据完整性。但是，TLS也提供了机密性，因此即使在这种情况下，仍然有理由使用“https”URL方案。此外，web服务器策略（如[RFC6797]）可能规定数据只能通过“https”访问。但是，一般来说，是使用“http”还是“https”需要由应用程序决定。
Some applications may benefit from using hashes in existing HTTP URLs or other URLs. To do this, one simply uses the "alg-val" production from the ni name scheme ABNF, which may be included, for example, in the pathname, query string, or even fragment components of HTTP URLs [RFC2616]. In such cases, there is nothing present in the URL that ensures that a client can depend on compliance with this specification, so clients MUST NOT assume that any URL with a pathname component that matches the "alg-val" production was in fact produced as a result of this specification. That URL might or might not be related to this specification, only the context will tell.
某些应用程序可能会受益于在现有HTTP URL或其他URL中使用哈希。要做到这一点，只需使用ni名称方案ABNF中的“alg val”生成，例如，它可以包含在HTTP URL的路径名、查询字符串甚至片段组件[RFC2616]中。在这种情况下，URL中没有任何内容可以确保客户机依赖于此规范的遵从性，因此客户机不得假设任何带有路径名组件且与“alg val”产品匹配的URL实际上是由于此规范而生成的。该URL可能与此规范相关，也可能与此规范无关，只有上下文才能说明这一点。
If a more space-efficient version of the name is needed, the following binary format can be used. The binary format name consists of two fields: a header and the hash value. The header field defines how the identifier has been created, and the hash value contains a (possibly truncated) result of a one-way hash over whatever is being identified by the hash value. The binary format of a name is shown in Figure 7.
如果需要更节省空间的名称版本，可以使用以下二进制格式。二进制格式名称由两个字段组成：头和散列值。header字段定义了标识符的创建方式，哈希值包含单向哈希的结果（可能被截断），该结果覆盖了由哈希值标识的任何内容。名称的二进制格式如图7所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Suite ID | Hash Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Suite ID | Hash Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... |
+-+-+-+-+-+-+-+-+
Figure 7: Binary Name Format
图7：二进制名称格式
The Res field is a reserved 2-bit field for future use and MUST be set to zero for this specification and ignored on receipt.
Res字段是一个保留的2位字段，供将来使用，必须为此规范设置为零，并在收到时忽略。
The hash algorithm and truncation length are specified by the Suite ID. For maintaining efficient encoding for the binary format, only a few hash algorithms and truncation lengths are supported. See Section 9.4 for details.
哈希算法和截断长度由套件ID指定。为了保持二进制格式的有效编码，只支持少数哈希算法和截断长度。详见第9.4节。
A hash value that is truncated to 120 bits will result in the overall name being a 128-bit value, which may be useful for protocols that can easily use 128-bit identifiers.
被截断为120位的散列值将导致总名称为128位值，这对于可以轻松使用128位标识符的协议可能很有用。
Sometimes a resource may need to be referred to via a name in a format that is easy for humans to read out and less likely to be ambiguous when heard. This is intended to be usable, for example, over the phone in order to confirm the (current or future) presence or absence of a resource. This "confirmation" use-case described further in Section 8.3 is the main current use-case for Named Information for Humans (nih) URIs. ("nih" also means "Not Invented Here", which is clearly false, and therefore worth including [RFC5513]. :-)
有时，可能需要通过名称引用资源，其格式便于人们读出，并且在听到时不太可能模棱两可。这是为了可用，例如，通过电话确认（当前或未来）资源的存在或不存在。第8.3节中进一步描述的“确认”用例是人类命名信息（nih）URI的主要当前用例。（“nih”也意味着“不是在这里发明的”，这显然是错误的，因此值得包括[RFC5513]：-）
The ni URI format is not well-suited for this, as, for example, base64url uses both uppercase and lowercase, which can easily cause confusion. For this particular purpose ("speaking" the value of a hash output), the more verbose but less ambiguous (when spoken) nih URI scheme is defined.
ni URI格式并不适合这种情况，例如，base64url同时使用大写和小写，这很容易造成混淆。出于这个特殊目的（“说出”散列输出的值），定义了更详细但不太含糊（说出时）的nih URI方案。
The justification for nih being a URI scheme is that it can help a user agent for the speaker to better display the value or help a machine to better speak or recognise the value when spoken. We do not include the query string since there is no way to ensure that its value might be spoken unambiguously and similarly for the authority, where, e.g., some internationalised forms of domain name might not be
nih作为URI方案的理由是，它可以帮助说话人的用户代理更好地显示值，或者帮助机器更好地说话，或者在说话时识别值。我们不包括查询字符串，因为无法确保其值可以明确无误地表达，类似地，对于管理局来说，例如，某些国际化形式的域名可能不存在
easy to speak and comprehend easily. This leaves the hash value as the only part of the ni URI that we feel can be usefully included. But since speakers or listeners (or speech recognition) may err, we also include a checkdigit to catch common errors and allow for the inclusion of "-" separators to make nih URIs easier to read out.
容易说，容易理解。这使得散列值成为我们认为可以有效地包含的NIURI的唯一部分。但由于说话人或听话人（或语音识别）可能会出错，我们还包括一个校验位来捕获常见错误，并允许包含“-”分隔符，以使nih URI更易于读取。
Fields in nih URIs are separated by a semicolon (;) character. The first field is a hash algorithm string, as in the ni URI format. The hash value is represented using lowercase ASCII hex characters; for example, an octet with the decimal value 58 (0x3A) is encoded as '3a'. This is the same as base16 encoding as defined in RFC 4648 [RFC4648] except using lowercase letters. Separators ("-" characters) MAY be interspersed in the hash value in any way to make those easier to read, typically grouping four or six characters with a separator between.
nih URI中的字段由分号（；）字符分隔。第一个字段是哈希算法字符串，如NIURI格式。哈希值使用小写ASCII十六进制字符表示；例如，十进制值为58（0x3A）的八位字节被编码为“3a”。这与RFC 4648[RFC4648]中定义的base16编码相同，只是使用小写字母。分隔符（“-”字符）可以以任何方式散布在散列值中，以使这些分隔符更易于读取，通常使用分隔符将四个或六个字符分组。
The hash value MAY be followed by a semicolon ';' then a checkdigit. The checkdigit MUST be calculated using Luhn's mod N algorithm (with N=16) as defined in [ISOIEC7812] (see also [Luhn]). The input to the calculation is the ASCII hex-encoded hash value (i.e., "sepval" in the ABNF production below) but with all "-" separator characters first stripped out. This maps the ASCII hex so that '0'=0, ...'9'=9, 'a'=10, ...'f'=15. None of the other fields, nor any "-" separators, are input when calculating the checkdigit.
哈希值后面可以跟一个分号“；”然后是一个校验位。必须使用[ISOIEC7812]中定义的Luhn mod N算法（N=16）计算校验位（另见[Luhn]）。计算的输入是ASCII十六进制编码的哈希值（即下面ABNF产品中的“sepval”），但首先去掉所有“-”分隔符。这将映射ASCII十六进制，以便“0”=0，'9'=9，'a'=10，'f'=15。计算校验位时，不输入任何其他字段或任何“-”分隔符。
humanname = "nih:" alg-sepval [ ";" checkdigit ]
alg-sepval = alg ";" sepval
sepval = 1*(ahlc / "-")
ahlc = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; DIGIT is defined in RFC 5234 and is 0-9
checkdigit = ahlc
humanname = "nih:" alg-sepval [ ";" checkdigit ]
alg-sepval = alg ";" sepval
sepval = 1*(ahlc / "-")
ahlc = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; DIGIT is defined in RFC 5234 and is 0-9
checkdigit = ahlc
Figure 8: Human-Speakable Syntax
图8：人类可说出的语法
For algorithms that have a Suite ID reserved (see Figure 11), the alg field MAY contain the ID value as an ASCII-encoded decimal number instead of the hash name string (for example, "3" instead of "sha-256-120"). Implementations MUST be able to match the decimal ID values for the algorithms and hash lengths that they support, even if they do not support the binary format.
对于保留套件ID的算法（参见图11），alg字段可能包含ID值，作为ASCII编码的十进制数，而不是哈希名称字符串（例如，“3”而不是“sha-256-120”）。实现必须能够匹配它们支持的算法和哈希长度的十进制ID值，即使它们不支持二进制格式。
There is no such thing as a relative nih URI.
没有相对nih URI这样的东西。
The following ni URI is generated from the text "Hello World!" (12 characters without the quotes), using the sha-256 algorithm shown with and without an authority field:
以下ni URI是使用sha-256算法从文本“Hello World！”（12个字符，不带引号）生成的，该算法显示有权限字段和没有权限字段：
ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
The following HTTP URL represents a mapping from the previous ni name based on the algorithm outlined above.
以下HTTP URL表示基于上述算法的前一个ni名称的映射。
http://example.com/.well-known/ni/sha-256/
f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
http://example.com/.well-known/ni/sha-256/
f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
Given the DER-encoded SubjectPublicKeyInfo in Figure 9, we derive the names shown in Figure 10 for this value.
给定图9中DER编码的SubjectPublicKeyInfo，我们推导出图10中显示的该值的名称。
0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0000020 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 0000040 00 a2 5f 83 da 9b d9 f1 7a 3a 36 67 ba fd 5a 94 0000060 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3 0000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 bd 7b 0000120 9d db e4 0a d7 10 cd f9 53 20 ee 0d d7 56 6e 5b 0000140 7a ae 2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6 0000160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76 0000200 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b 0000220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b 0000240 57 10 b7 a3 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83 0000260 14 f4 6b 58 e2 de f2 ff c9 77 07 e3 f3 4c 97 cf 0000300 1a 28 9e 38 a1 b3 93 41 75 a1 a4 76 3f 4d 78 d7 0000320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b 0000340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90 0000360 9c bc ee b0 a2 b1 dc da 6d a0 0f f6 ad 1e 2c 12 0000400 a2 a7 66 60 3e 36 d4 91 41 c2 f2 e7 69 39 2c 9d 0000420 d2 df b5 a3 44 95 48 7c 87 64 89 dd bf 05 01 ee 0000440 dd 02 03 01 00 01
0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 00000 20 01 05 00 03 82 01 0f 00 80 82 01 00000 40 00 a2 5f 83 da 9b d9 f1 7a 36 67 ba fd 5a 94 00000 60 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3 00000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 7b 0000120 9d db e4 0a d7 10 cd 53 20 ee 0d d7 56 E 5b 140 00007A ae2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6 0000160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76 000020 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b 0000220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b 0000240 57 10 b7 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83 0000260 14 f4 6b 58 e2 de f2 ff c9 77 e3 f3 4c 97 cf 300 000028 9e 38 a1 b393 41 75 a1 a4 76 3f 4d 78 d7 0000320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b 0000340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90 0000360 9c bc ee b0 a2 b1 dc da 6d a0 0f 6 ad 1e 12 0000400 a2 a7 66 60 3e 36 d4 91 c2 f2 e7 39 2c 9d 0000420 d2 df b5 44 95 48 7c 87 89 dd bf 05 ee 0000440 dd 02 01 01 01
0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7 0000020 53 87 7e b6 2f f4 4d 5a 19 00 25 30 ed 97 ff e4
0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7 00000 20 53 87 7e b6 2f f4 4d 5a 19 00 25 ed 97 ff e4
Figure 9: A SubjectPublicKeyInfo Used in Examples and Its sha-256 Hash
图9：示例中使用的SubjectPublicKeyInfo及其sha-256哈希
+-------------------------------------------------------------------+
| URI: |
| ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| .well-known URL (split over 2 lines): |
| http://example.com/.well-known/ni/sha256/ |
| UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| URL Segment: |
| sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| Binary name (ASCII hex encoded) with 120-bit truncated hash value |
| which is Suite ID 0x03: |
| 0353 2690 57e1 2fe2 b74b a07c 8925 60a2 |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 120 bits|
| in length) with checkdigit: |
| nih:sha-256-120;5326-9057-e12f-e2b7-4ba0-7c89-2560-a2;f |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 32 bits |
| in length) with checkdigit and no "-" separators: |
| nih:sha-256-32;53269057;b |
+-------------------------------------------------------------------+
| Human-speakable form using decimal presentation of the |
| algorithm ID (sha-256-120) with checkdigit: |
| nih:3;532690-57e12f-e2b74b-a07c89-2560a2;f |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| URI: |
| ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| .well-known URL (split over 2 lines): |
| http://example.com/.well-known/ni/sha256/ |
| UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| URL Segment: |
| sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| Binary name (ASCII hex encoded) with 120-bit truncated hash value |
| which is Suite ID 0x03: |
| 0353 2690 57e1 2fe2 b74b a07c 8925 60a2 |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 120 bits|
| in length) with checkdigit: |
| nih:sha-256-120;5326-9057-e12f-e2b7-4ba0-7c89-2560-a2;f |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 32 bits |
| in length) with checkdigit and no "-" separators: |
| nih:sha-256-32;53269057;b |
+-------------------------------------------------------------------+
| Human-speakable form using decimal presentation of the |
| algorithm ID (sha-256-120) with checkdigit: |
| nih:3;532690-57e12f-e2b74b-a07c89-2560a2;f |
+-------------------------------------------------------------------+
Figure 10: Example Names
图10：示例名称
Alice has set up a server node with an RSA key pair. She uses an ni URI as the name for the public key that corresponds to the private key on that box. Alice's node might identify itself using that ni URI in some protocol.
Alice使用RSA密钥对设置了一个服务器节点。她使用NIURI作为与该框上的私钥对应的公钥的名称。Alice的节点可能会在某些协议中使用该NIURI来标识自己。
Bob would like to believe that it's really Alice's node when his node interacts with the network and asks his friend Alice to tell him what public key she uses. Alice hits the "tell someone the name of the public key" button on her admin user interface and that displays the nih URI and says "tell this to your buddy". She phones Bob and reads the nih URI to him.
当他的节点与网络交互时，Bob希望相信它确实是Alice的节点，并让他的朋友Alice告诉他她使用的公钥。Alice在她的管理员用户界面上点击“告诉某人公钥的名称”按钮，显示nih URI并说“告诉你的好友”。她打电话给鲍勃，给他读《国家卫生研究院URI》。
Bob types that in to his "manage known nodes" admin application (or lets that application listen to part of the call), which can regenerate the ni URI and store that or some equivalent. Then when Bob's node interacts with Alice's node, it can more safely accept a signature or encrypt data to Alice's node.
Bob将其输入到他的“管理已知节点”管理应用程序（或让该应用程序侦听部分调用），该应用程序可以重新生成ni URI并存储该URI或其他等效内容。然后，当Bob的节点与Alice的节点交互时，它可以更安全地接受签名或将数据加密到Alice的节点。
The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following assignment has been made.
注册URI方案的程序在RFC 4395[RFC4395]中规定。已完成以下任务。
URI scheme name: ni
URI方案名称：ni
Status: Permanent
地位：永久
URI scheme syntax: See Section 3.
URI方案语法：参见第3节。
URI scheme semantics: See Section 3.
URI方案语义：参见第3节。
Encoding considerations: See Section 3.
编码注意事项：参见第3节。
Applications/protocols that use this URI scheme name:
使用此URI方案名称的应用程序/协议：
General applicability.
一般适用性。
Interoperability considerations: Defined here.
互操作性注意事项：此处定义。
Security considerations: See Section 10.
安全注意事项：见第10节。
Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie
联系人：斯蒂芬·法雷尔，斯蒂芬。farrell@cs.tcd.ie
Author/Change controller: IETF
作者/变更控制员：IETF
References: As specified in this document
参考文献：如本文件所述
The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following assignment has been made.
注册URI方案的程序在RFC 4395[RFC4395]中规定。已完成以下任务。
URI scheme name: nih
URI方案名称：nih
Status: Permanent
地位：永久
URI scheme syntax: See Section 7.
URI方案语法：参见第7节。
URI scheme semantics: See Section 7.
URI方案语义：参见第7节。
Encoding considerations: See Section 7.
编码注意事项：参见第7节。
Applications/protocols that use this URI scheme name:
使用此URI方案名称的应用程序/协议：
General applicability.
一般适用性。
Interoperability considerations: Defined here.
互操作性注意事项：此处定义。
Security considerations: See Section 10.
安全注意事项：见第10节。
Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie
联系人：斯蒂芬·法雷尔，斯蒂芬。farrell@cs.tcd.ie
Author/Change controller: IETF
作者/变更控制员：IETF
References: As specified in this document
参考文献：如本文件所述
The procedures for registration of a Well-Known URI entry are specified in RFC 5785 [RFC5785]. The following assignment has been made.
RFC 5785[RFC5785]中规定了注册已知URI条目的程序。已完成以下任务。
URI suffix: ni
URI后缀：ni
Change controller: IETF
更改控制器：IETF
Specification document(s): This document
规范文件：本文件
Related information: None
相关信息：无
IANA has created a new registry for hash algorithms as used in the name formats specified here; it is called the "Named Information Hash Algorithm Registry". Future assignments are to be made through Expert Review [RFC5226]. This registry has five fields: the suite ID, the hash algorithm name string, the truncation length, the underlying algorithm reference, and a status field that indicates if the algorithm is current or deprecated and should no longer be used. The status field can have the value "current" or "deprecated". Other values are reserved for possible future definition.
IANA已经为散列算法创建了一个新的注册表，该算法在这里指定的名称格式中使用；它被称为“命名信息哈希算法注册表”。未来的任务将通过专家评审[RFC5226]完成。此注册表有五个字段：套件ID、哈希算法名称字符串、截断长度、基础算法引用，以及一个状态字段，该字段指示算法是当前算法还是已弃用且不应再使用。状态字段的值可以是“当前”或“已弃用”。其他值保留为将来可能的定义。
If the status is "current", then that does not necessarily mean that the algorithm is "good" for any particular purpose, since the cryptographic strength requirements will be set by other applications or protocols.
如果状态为“当前”，则这并不一定意味着算法对于任何特定目的都是“良好的”，因为密码强度要求将由其他应用程序或协议设置。
A request to mark an entry as "deprecated" can be done by sending a mail to the Designated Expert. Before approving the request, the community MUST be consulted via a "call for comments" of at least two weeks by sending a mail to the IETF discussion list.
将条目标记为“已弃用”的请求可以通过向指定专家发送邮件来完成。在批准请求之前，必须通过向IETF讨论列表发送邮件，通过至少两周的“征求意见”咨询社区。
Initial values are specified below. The Designated Expert SHOULD generally approve additions that reference hash algorithms that are widely used in other IETF protocols. In addition, the Designated Expert SHOULD NOT accept additions where the underlying hash function (with no truncation) is considered weak for collisions. Part of the reasoning behind this last point is that inclusion of code for weak hash functions, e.g., the MD5 algorithm, can trigger costly false positives if code is audited for inclusion of obsolete ciphers. See [RFC6149], [RFC6150], and [RFC6151] for examples of some hash functions that are considered obsolete in this sense.
初始值如下所示。指定专家通常应批准引用其他IETF协议中广泛使用的哈希算法的添加。此外，如果基础哈希函数（没有截断）被认为对冲突很弱，则指定的专家不应接受添加。最后一点背后的部分原因是，如果对包含过时密码的代码进行审计，则包含弱哈希函数的代码（例如MD5算法）可能会触发代价高昂的误报。请参阅[RFC6149]、[RFC6150]和[RFC6151]以了解在这种意义上被视为过时的一些哈希函数的示例。
The suite ID field ("ID") can be empty or can have values between 0 and 63, inclusive. Because there are only 64 possible values, this field is OPTIONAL (leaving it empty if omitted). Where the binary format is not expected to be used for a given hash algorithm, this field SHOULD be omitted. If an entry is registered without a suite ID, the Designated Expert MAY allow for later allocation of a suite ID, if that appears warranted. The Designated Expert MAY consult the community via a "call for comments" by sending a mail to the IETF discussion list before allocating a suite ID.
套件ID字段（“ID”）可以为空，也可以具有介于0和63之间的值（包括0和63）。因为只有64个可能的值，所以此字段是可选的（如果省略，则为空）。如果给定哈希算法不使用二进制格式，则应省略此字段。如果登记的条目没有套件ID，指定的专家可以允许以后分配套件ID（如果有担保的话）。在分配套件ID之前，指定专家可通过向IETF讨论列表发送邮件，通过“征求意见”咨询社区。
ID Hash Name String Value Length Reference Status 0 Reserved 1 sha-256 256 bits [SHA-256] current 2 sha-256-128 128 bits [SHA-256] current 3 sha-256-120 120 bits [SHA-256] current 4 sha-256-96 96 bits [SHA-256] current 5 sha-256-64 64 bits [SHA-256] current 6 sha-256-32 32 bits [SHA-256] current 32 Reserved
ID哈希名称字符串值长度参考状态0保留1 sha-256 256位[sha-256]当前2 sha-256-128位[sha-256]当前3 sha-256-120位[sha-256]当前4 sha-256-96位[sha-256]当前5 sha-256-64位[sha-256]当前6 sha-256-32位[sha-256]当前32保留
Figure 11: Suite Identifiers
图11：套件标识符
The Suite ID value 32 is reserved for compatibility with IPv6 addresses from the Special Purpose Address Registry [RFC4773], such as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843].
套件ID值32保留用于与特殊用途地址注册表[RFC4773]中的IPv6地址兼容，例如覆盖可路由加密哈希标识符（RAYTS）[RFC4843]。
The referenced hash algorithm matching the Suite ID, truncated to the length indicated, according to the description given in Section 2, is used for generating the hash. The Designated Expert is responsible for ensuring that the document referenced for the hash algorithm meets the "specification required" rule.
根据第2节中给出的描述，匹配套件ID的引用哈希算法（截断为指定长度）用于生成哈希。指定专家负责确保哈希算法引用的文档符合“要求规范”规则。
IANA has created a new registry entitled "Named Information URI Parameter Definitions".
IANA创建了一个名为“命名信息URI参数定义”的新注册表。
The policy for future assignments to the registry is Expert Review, and as for the ni Hash Algorithm Registry above, the Designated Expert is responsible for ensuring that the document referenced for the parameter definition meets the "specification required" rule.
今后分配给注册表的政策是专家审查，对于上述ni哈希算法注册表，指定专家负责确保参数定义引用的文件符合“所需规范”规则。
The fields in this registry are the parameter name, a description, and a reference. The parameter name MUST be such that it is suitable for use as a query string parameter name in an ni URI. (See Section 3.)
此注册表中的字段包括参数名称、说明和引用。参数名称必须适合用作ni URI中的查询字符串参数名称。（见第3节。）
The initial contents of the registry are:
登记册的初始内容包括：
Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [RFC6920]
Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [RFC6920]
No secret information is required to generate or verify a name of the form described here. Therefore, a name like this can only provide evidence for the integrity of the referenced object, and the proof of integrity provided is only as good as the proof of integrity for the name from which we started. In other words, the hash value can provide a name-data integrity binding between the name and the bytes returned when the name is dereferenced using some protocol.
生成或验证此处所述表单的名称不需要任何机密信息。因此，这样的名称只能为引用对象的完整性提供证据，并且提供的完整性证明与我们开始使用的名称的完整性证明一样好。换句话说，哈希值可以在名称和使用某种协议取消引用名称时返回的字节之间提供名称数据完整性绑定。
Disclosure of a name value does not necessarily entail disclosure of the referenced object but may enable an attacker to determine the contents of the referenced object by reference to a search engine or other data repository or, for a highly formatted object with little variation, by simply guessing the value and checking if the digest value matches. So, the fact that these names contain hashes does not protect the confidentiality of the object that was input to the hash.
名称值的泄露不一定意味着引用对象的泄露，但可能使攻击者能够通过引用搜索引擎或其他数据存储库来确定引用对象的内容，或者，对于高度格式化且变化不大的对象，只需猜测值并检查摘要值是否匹配。因此，这些名称包含哈希的事实并不保护输入到哈希的对象的机密性。
The integrity of the referenced content would be compromised if a weak hash function were used. SHA-256 is currently our preferred hash algorithm; this is why we've added only SHA-256-based suites to the initial IANA registry.
如果使用弱哈希函数，则引用内容的完整性将受到损害。SHA-256是目前我们首选的哈希算法；这就是为什么我们只在初始IANA注册表中添加了基于SHA-256的套件。
If a truncated hash value is used, certain security properties will be affected. In general, a hash algorithm is designed to produce sufficient bits to prevent a 'birthday attack' collision occurring. Ensuring that the difficulty of discovering two pieces of content
如果使用截断的哈希值，某些安全属性将受到影响。一般来说，哈希算法旨在产生足够的位，以防止发生“生日攻击”冲突。确保发现两条内容的难度
that result in the same digest with a work factor O(2^x) by brute force requires a digest length of 2x. Many security applications only require protection against a second pre-image attack, which only requires a digest length of x to achieve the same work factor. Basically, the shorter the hash value used, the less security benefit you can possibly get.
通过蛮力产生功因子为O（2^x）的相同摘要需要2x的摘要长度。许多安全应用程序只需要针对第二次预映像攻击进行保护，而第二次预映像攻击只需要x的摘要长度即可实现相同的工作系数。基本上，使用的哈希值越短，您可能获得的安全性好处就越少。
An important thing to keep in mind is not to make the mistake of thinking two names are the same when they aren't. For example, a name with a 32-bit truncated sha-256 hash is not the same as a name with the full 256 bits of hash output, even if the hash value for one is a prefix of that for the other.
要记住的一件重要事情是，不要错误地认为两个名字是相同的，而实际上它们是不同的。例如，具有32位截断sha-256散列的名称与具有完整256位散列输出的名称不同，即使其中一个的散列值是另一个的前缀。
The reason for this is that if an application treats these as the same name, then that might open up a number of attacks. For example, if I publish an object with the full hash, then I probably (in general) don't want some other application to treat a name with just the first 32 bits of that as referring to the same thing, since the 32-bit name will have lots of colliding objects. If ni or nih URIs become widely used, there will be many cases where names will occur more than once in application protocols, and it'll be unpredictable which instance of the name would be used for name-data integrity checking, thus leading to threats. For this reason, we require that the algorithm, length, and value all match before we consider two names to be the same.
原因是，如果应用程序将这些名称视为相同的名称，则可能会引发许多攻击。例如，如果我发布了一个具有完整散列的对象，那么我可能（通常）不希望其他应用程序将仅具有前32位的名称视为引用同一事物，因为32位名称将有许多冲突对象。如果ni或nih URI被广泛使用，在许多情况下，名称将在应用程序协议中出现不止一次，并且不可预测名称的哪个实例将用于名称数据完整性检查，从而导致威胁。由于这个原因，我们要求算法，长度和值都匹配之前，我们认为两个名称是相同的。
The fact that an ni URI includes a domain name in the authority field by itself implies nothing about the relationship between the owner of the domain name and any content referenced by that URI. While a name-data integrity service can be provided using ni URIs, that does not in any sense validate the authority part of the name. For example, there is nothing to stop anyone from creating an ni URI containing a hash of someone else's content. Application developers MUST NOT assume any relationship between the registrant of the domain name that is part of an ni URI and some matching content just because the ni URI matches that content.
ni-URI本身在authority字段中包含域名这一事实并不意味着域名所有者与该URI引用的任何内容之间的关系。虽然可以使用ni URI提供名称数据完整性服务，但这在任何意义上都不会验证名称的授权部分。例如，没有什么可以阻止任何人创建包含其他人内容哈希的NIURI。应用程序开发人员不得仅因为ni URI与某个匹配内容匹配，就假定作为ni URI一部分的域名注册人与该内容之间存在任何关系。
If name-data integrity is successfully validated, and the hash is strong and long enough, then the "web origin" [RFC6454] for the bytes of the named object is really going to be the place from which you get the ni name and not the place from which you get the bytes of the object. This appears to offer a potential benefit if using ni names for scripts included from a HTML page accessed via server-authenticated https, for example. If name-data integrity is not validated (and it is optional) or fails, then the web origin is, as usual, the place from which the object bytes were received. Applications making use of ni names SHOULD take this into account in their trust models.
如果成功验证了名称数据的完整性，并且散列足够强且足够长，那么命名对象字节的“web源”[RFC6454]实际上将是获取ni名称的位置，而不是获取对象字节的位置。例如，如果对通过服务器验证的https访问的HTML页面中包含的脚本使用ni名称，这似乎提供了一个潜在的好处。如果名称数据完整性未经验证（并且是可选的）或失败，则web源通常是接收对象字节的位置。使用ni名称的应用程序应在其信任模型中考虑到这一点。
Some implementations might mishandle ni URIs that include non-base64 characters, whitespace, or other non-conforming strings, and that could lead to erroneously considering names to be the same when they are not. An ni URI that is malformed in such ways MUST NOT be treated as matching any other ni URI. Implementers need to check the behaviour of libraries for such parsing problems.
一些实现可能会错误地处理包含非base64字符、空格或其他不一致字符串的ni URI，这可能导致错误地认为名称是相同的，而不是相同的。在这种情况下格式错误的ni URI不得被视为与任何其他ni URI匹配。实现者需要检查库的行为是否存在此类解析问题。
This work has been supported by the EU FP7 project SAIL. The authors would like to thank SAIL participants to our naming discussions, especially Jean-Francois Peltier, for their input.
这项工作得到了欧盟FP7项目SAIL的支持。作者要感谢参加我们命名讨论的SAIL参与者，特别是Jean-Francois Peltier，感谢他们的投入。
The authors would also like to thank Carsten Bormann, Martin Duerst, Tobias Heer, Bjoern Hoehrmann, Tero Kivinen, Barry Leiba, Larry Masinter, David McGrew, Alexey Melnikov, Bob Moskowitz, Jonathan Rees, Eric Rescorla, Zach Shelby, and Martin Thomas for their comments and input to the document. Thanks, in particular, to James Manger for correcting the examples.
作者还要感谢Carsten Bormann、Martin Duerst、Tobias Heer、Bjoern Hoehrmann、Tero Kivinen、Barry Leiba、Larry Masinter、David McGrew、Alexey Melnikov、Bob Moskowitz、Jonathan Rees、Eric Rescorla、Zach Shelby和Martin Thomas对本文件的评论和投入。特别感谢James Manger纠正了这些示例。
[ISOIEC7812] ISO, "Identification cards -- Identification of issuers -- Part 1: Numbering system", ISO/IEC 7812-1:2006, October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812]ISO，“识别卡——发卡机构的识别——第1部分：编号系统”，ISO/IEC 7812-1:2006，2006年10月<http://www.iso.org/iso/iso_catalogue/ catalog\u tc/catalog\u detail.htm？csnumber=39698>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，2010年4月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[SHA-256] NIST, "Secure Hash Standard", FIPS 180-3, October 2008, <http://csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf>.
[SHA-256]NIST，“安全哈希标准”，FIPS 180-32008年10月<http://csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf>。
[CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09), December 2009.
[CCN]Jacobson，V.，Smetters，D.，Thornton，J.，Plass，M.，Briggs，N.，和R.Braynard，“网络命名内容”，第五届新兴网络实验和技术国际会议记录（CoNEXT'09），2009年12月。
[DECPARAMS] Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, D., and B. Ohlman, "The Named Information (ni) URI Scheme: Optional Features", Work in Progress, June 2012.
[DECPARAMS]Hallam Baker，P.，Stradling，R.，Farrell，S.，Kutscher，D.，和B.Ohlman，“命名信息（ni）URI方案：可选特性”，正在进行的工作，2012年6月。
[Luhn] Wikipedia, "Luhn mod N algorithm", September 2011, <http://en.wikipedia.org/w/ index.php?title=Luhn_mod_N_algorithm&oldid=449928878>.
[Luhn]维基百科，“Luhn mod N算法”，2011年9月<http://en.wikipedia.org/w/ php？title=Luhn\u mod\u N\u算法&oldid=449928878>。
[Magnet] Wikipedia, "Magnet URI scheme", March 2013, <http://en.wikipedia.org/w/ index.php?title=Magnet_URI_scheme&oldid=546892719>.
[磁铁]维基百科，“磁铁URI方案”，2013年3月<http://en.wikipedia.org/w/ index.php？title=Magnet\u URI\u scheme&oldid=546892719>。
[NETINF-ARCHITECTURE] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and M. Karl, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications, Volume 36, Issue 7, pages 721-735, ISSN 0140-3664, 1 April 2013, <http://www.sciencedirect.com/science/article/pii/ S0140366413000364>.
[NETINF-ARCHITECTURE]Dannewitz，C.，Kutscher，D.，Ohlman，B.，Farrell，S.，Ahlgren，B.，和M.Karl，“信息网络（NETINF）-以信息为中心的网络架构”，计算机通信，第36卷，第7期，第721-735页，ISSN 0140-3664，2013年4月1日<http://www.sciencedirect.com/science/article/pii/ S0140366413000364>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4773] Huston, G., "Administration of the IANA Special Purpose IPv6 Address Block", RFC 4773, December 2006.
[RFC4773]Huston，G.“IANA专用IPv6地址块的管理”，RFC 4773，2006年12月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843]Nikander，P.，Laganier，J.，和F.Dupont，“覆盖可路由加密哈希标识符（RAYD）的IPv6前缀”，RFC 4843，2007年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009.
[RFC5513]Farrel，A.，“三字母首字母缩写词的IANA考虑”，RFC5513，2009年4月1日。
[RFC6149] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, March 2011.
[RFC6149]Turner，S.和L.Chen，“MD2历史地位”，RFC 61492011年3月。
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, March 2011.
[RFC6150]Turner，S.和L.Chen，“MD4的历史地位”，RFC 61502011年3月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012.
[RFC6797]Hodges，J.，Jackson，C.，和A.Barth，“HTTP严格传输安全（HSTS）”，RFC 67972012年11月。
Authors' Addresses
作者地址
Stephen Farrell Trinity College Dublin Dublin, 2 Ireland Phone: +353-1-896-2354 EMail: stephen.farrell@cs.tcd.ie
斯蒂芬·法雷尔三一学院都柏林，2爱尔兰电话：+353-1-896-2354电子邮件：斯蒂芬。farrell@cs.tcd.ie
Dirk Kutscher NEC Kurfuersten-Anlage 36 Heidelberg Germany EMail: kutscher@neclab.eu
Dirk Kutscher NEC Kurfuersten Anlage 36德国海德堡电子邮件：kutscher@neclab.eu
Christian Dannewitz University of Paderborn Paderborn Germany EMail: cdannewitz@googlemail.com
帕德博恩基督教丹尼维兹大学帕德博恩德国电子邮件：cdannewitz@googlemail.com
Borje Ohlman Ericsson Stockholm S-16480 Sweden EMail: Borje.Ohlman@ericsson.com
Borje Ohlman Ericsson斯德哥尔摩S-16480瑞典电子邮件：Borje。Ohlman@ericsson.com
Ari Keranen Ericsson Jorvas 02420 Finland EMail: ari.keranen@ericsson.com
Ari Keranen Ericsson Jorvas 02420芬兰电子邮件：Ari。keranen@ericsson.com
Phillip Hallam-Baker Comodo Group Inc. EMail: philliph@comodo.com
Phillip Hallam Baker Comodo Group Inc.电子邮件：philliph@comodo.com