Network Working Group E. Wilde
Request for Comments: 5147 UC Berkeley
Updates: 2046 M. Duerst
Category: Standards Track Aoyama Gakuin University
April 2008
Network Working Group E. Wilde
Request for Comments: 5147 UC Berkeley
Updates: 2046 M. Duerst
Category: Standards Track Aoyama Gakuin University
April 2008
URI Fragment Identifiers for the text/plain Media Type
文本/普通媒体类型的URI片段标识符
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust.
此备忘录为文本/纯MIME实体定义URI片段标识符。这些片段标识符使得引用文本/纯MIME实体的部分成为可能，可以通过字符位置或范围，或者行位置或范围来标识。片段标识符还可能包含完整性检查的信息，以使其更加健壮。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What Is text/plain? . . . . . . . . . . . . . . . . . . . 3
1.2. What Is a URI Fragment Identifier? . . . . . . . . . . . . 4
1.3. Why text/plain Fragment Identifiers? . . . . . . . . . . . 4
1.4. Incremental Deployment . . . . . . . . . . . . . . . . . . 5
1.5. Notation Used in This Memo . . . . . . . . . . . . . . . . 5
2. Fragment Identification Methods . . . . . . . . . . . . . . . 5
2.1. Fragment Identification Principles . . . . . . . . . . . . 6
2.1.1. Positions and Ranges . . . . . . . . . . . . . . . . . 6
2.1.2. Characters and Lines . . . . . . . . . . . . . . . . . 7
2.2. Combining the Principles . . . . . . . . . . . . . . . . . 7
2.2.1. Character Position . . . . . . . . . . . . . . . . . . 7
2.2.2. Character Range . . . . . . . . . . . . . . . . . . . 8
2.2.3. Line Position . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Line Range . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Fragment Identifier Robustness . . . . . . . . . . . . . . 8
3. Fragment Identification Syntax . . . . . . . . . . . . . . . . 9
3.1. Integrity Checks . . . . . . . . . . . . . . . . . . . . . 9
4. Fragment Identifier Processing . . . . . . . . . . . . . . . . 10
4.1. Handling of Line Endings in text/plain MIME Entities . . . 10
4.2. Handling of Position Values . . . . . . . . . . . . . . . 11
4.3. Handling of Integrity Checks . . . . . . . . . . . . . . . 11
4.4. Syntax Errors in Fragment Identifiers . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What Is text/plain? . . . . . . . . . . . . . . . . . . . 3
1.2. What Is a URI Fragment Identifier? . . . . . . . . . . . . 4
1.3. Why text/plain Fragment Identifiers? . . . . . . . . . . . 4
1.4. Incremental Deployment . . . . . . . . . . . . . . . . . . 5
1.5. Notation Used in This Memo . . . . . . . . . . . . . . . . 5
2. Fragment Identification Methods . . . . . . . . . . . . . . . 5
2.1. Fragment Identification Principles . . . . . . . . . . . . 6
2.1.1. Positions and Ranges . . . . . . . . . . . . . . . . . 6
2.1.2. Characters and Lines . . . . . . . . . . . . . . . . . 7
2.2. Combining the Principles . . . . . . . . . . . . . . . . . 7
2.2.1. Character Position . . . . . . . . . . . . . . . . . . 7
2.2.2. Character Range . . . . . . . . . . . . . . . . . . . 8
2.2.3. Line Position . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Line Range . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Fragment Identifier Robustness . . . . . . . . . . . . . . 8
3. Fragment Identification Syntax . . . . . . . . . . . . . . . . 9
3.1. Integrity Checks . . . . . . . . . . . . . . . . . . . . . 9
4. Fragment Identifier Processing . . . . . . . . . . . . . . . . 10
4.1. Handling of Line Endings in text/plain MIME Entities . . . 10
4.2. Handling of Position Values . . . . . . . . . . . . . . . 11
4.3. Handling of Integrity Checks . . . . . . . . . . . . . . . 11
4.4. Syntax Errors in Fragment Identifiers . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
This memo updates the text/plain media type defined in RFC 2046 [3] by defining URI fragment identifiers for text/plain MIME entities. This makes it possible to refer to parts of a text/plain MIME entity. Such parts can be identified by either character position or range, or by line position or range. Integrity checking information can be added to a fragment identifier to make it more robust, enabling applications to detect changes of the entity.
本备忘录通过为文本/普通MIME实体定义URI片段标识符，更新RFC 2046[3]中定义的文本/普通媒体类型。这使得引用文本/纯MIME实体的部分成为可能。这些部件可以通过字符位置或范围，或行位置或范围来识别。完整性检查信息可以添加到片段标识符中，使其更加健壮，从而使应用程序能够检测实体的更改。
This section gives an introduction to the general concepts of text/ plain MIME entities and URI fragment identifiers, and it discusses the need for fragment identifiers for text/plain and deployment issues. Section 2 discusses the principles and methods on which this memo is based. Section 3 defines the syntax, and Section 4 discusses processing of text/plain fragment identifiers. Section 5 shows some examples.
本节介绍了文本/普通MIME实体和URI片段标识符的一般概念，并讨论了文本/普通和部署问题对片段标识符的需求。第2节讨论了本备忘录所依据的原则和方法。第3节定义了语法，第4节讨论了文本/普通片段标识符的处理。第5节给出了一些例子。
Internet Media Types (often referred to as "MIME types"), as defined in RFC 2045 [2] and RFC 2046 [3], are used to identify different types and sub-types of media. RFC 2046 [3] and RFC 3676 [6] specify the text/plain media type, which is used for simple, unformatted text. Quoting from RFC 2046 [3]: "Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks".
RFC 2045[2]和RFC 2046[3]中定义的互联网媒体类型（通常称为“MIME类型”）用于识别不同类型和子类型的媒体。RFC 2046[3]和RFC 3676[6]指定用于简单、未格式化文本的文本/普通媒体类型。引用RFC 2046[3]：“纯文本不提供或允许格式化命令、字体属性规范、处理指令、解释指令或内容标记。纯文本仅被视为线性字符序列，可能被换行符或分页符打断。”。
The text/plain media type does not restrict the character encoding; any character encoding may be used. In the absence of an explicit character encoding declaration, US-ASCII [13] is assumed as the default character encoding. This variability of the character encoding makes it impossible to count characters in a text/plain MIME entity without taking the character encoding into account, because there are many character encodings using more than one octet per character.
文本/普通媒体类型不限制字符编码；可以使用任何字符编码。在没有显式字符编码声明的情况下，假定US-ASCII[13]为默认字符编码。字符编码的这种可变性使得在不考虑字符编码的情况下无法对文本/纯MIME实体中的字符进行计数，因为有许多字符编码每个字符使用一个以上的八位字节。
The biggest advantage of text/plain MIME entities is their ease of use and their portability among different platforms. As long as they use popular character encodings (such as US-ASCII or UTF-8 [12]), they can be displayed and processed on virtually every computer system. The only remaining interoperability issue is the representation of line endings, which is discussed in Section 4.1.
文本/纯MIME实体的最大优势在于其易用性和在不同平台之间的可移植性。只要它们使用流行的字符编码（如US-ASCII或UTF-8[12]），它们就可以在几乎所有计算机系统上显示和处理。唯一剩下的互操作性问题是行尾的表示，这将在第4.1节中讨论。
URIs are the identification mechanism for resources on the Web. The URI syntax specified in RFC 3986 [7] optionally includes a so-called "fragment identifier", separated by a number sign ('#'). The fragment identifier consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. The semantics of a fragment identifier are a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result.
URI是Web上资源的标识机制。RFC 3986[7]中指定的URI语法可选地包括所谓的“片段标识符”，由数字符号（“#”）分隔。片段标识符由用户代理在成功完成检索操作后解释的附加参考信息组成。片段标识符的语义是检索操作产生的数据的属性，而与引用中使用的URI类型无关。因此，片段标识符的格式和解释取决于检索结果的媒体类型。
The most popular fragment identifier is defined for text/html (defined in RFC 2854 [10]) and makes it possible to refer to a specific element (identified by the value of a 'name' or 'id' attribute) of an HTML document. This makes it possible to reference a specific part of a Web page, rather than a Web page as a whole.
最流行的片段标识符是为text/html（在RFC 2854[10]中定义）定义的，它使得引用html文档的特定元素（由“name”或“id”属性的值标识）成为可能。这样就可以引用网页的特定部分，而不是整个网页。
Referring to specific parts of a resource can be very useful because it enables users and applications to create more specific references. Users can create references to the part they really are interested in or want to talk about, rather than always pointing to a complete resource. Even though it is suggested that fragment identification methods are specified in a media type's MIME registration (see [15]), many media types do not have fragment identification methods associated with them.
引用资源的特定部分非常有用，因为它使用户和应用程序能够创建更具体的引用。用户可以创建对他们真正感兴趣或想要谈论的部分的引用，而不是总是指向完整的资源。尽管建议在媒体类型的MIME注册中指定片段标识方法（参见[15]），但许多媒体类型都没有与之关联的片段标识方法。
Fragment identifiers are only useful if supported by the client, because they are only interpreted by the client. Therefore, a new fragment identification method will require some time to be adopted by clients, and older clients will not support it. However, because the URI still works even if the fragment identifier is not supported (the resource is retrieved, but the fragment identifier is not interpreted), rapid adoption is not highly critical to ensure the success of a new fragment identification method.
片段标识符只有在客户端支持时才有用，因为它们只由客户端解释。因此，新的片段识别方法需要一段时间才能被客户端采用，而旧客户端将不支持它。但是，由于即使不支持片段标识符（检索资源，但不解释片段标识符），URI仍然有效，因此快速采用对于确保新片段标识方法的成功并不十分关键。
Fragment identifiers for text/plain, as defined in this memo, make it possible to refer to specific parts of a text/plain MIME entity, using concepts of positions and ranges, which may be applied to characters and lines. Thus, text/plain fragment identifiers enable users to exchange information more specifically, thereby reducing the time and effort that is necessary to manually search for the relevant part of a text/plain MIME entity.
本备忘录中定义的文本/纯文本的片段标识符，使用可应用于字符和行的位置和范围概念，可以引用文本/纯文本MIME实体的特定部分。因此，文本/普通片段标识符使用户能够更具体地交换信息，从而减少手动搜索文本/普通MIME实体的相关部分所需的时间和精力。
The text/plain format does not support the embedding of links, so in most environments, text/plain resources can only serve as targets for links, and not as sources. However, when combining the text/plain fragment identifiers specified in this memo with out-of-line linking mechanisms such as XLink [14], it becomes possible to "bind" link resources to text/plain resources and thereby "embed" links into text/plain resources. Thus, the text/plain fragment identifiers specified in this memo open a path for text/plain files to become bidirectionally navigable resources in hypermedia systems such as the Web.
文本/纯文本格式不支持嵌入链接，因此在大多数环境中，文本/纯文本资源只能作为链接的目标，而不能作为源。但是，当将本备忘录中指定的文本/纯文本片段标识符与XLink[14]等离线链接机制相结合时，可以将链接资源“绑定”到文本/纯文本资源，从而将链接“嵌入”到文本/纯文本资源中。因此，本备忘录中指定的文本/纯文本片段标识符为文本/纯文本文件打开了一条路径，使其成为Web等超媒体系统中的双向可导航资源。
As long as text/plain fragment identifiers are not supported universally, it is important to consider the implications of incremental deployment. Clients (for example, Web browsers) not supporting the text/plain fragment identifier described in this memo will work with URI references to text/plain MIME entities, but they will fail to locate the sub-resource identified by the fragment identifier. This is a reasonable fallback behavior, and in general, users should take into account the possibility that a program interpreting a given URI will fail to interpret the fragment identifier part. Since fragment identifier evaluation is local to the client (and happens after retrieving the MIME entity), there is no reliable way for a server to determine whether a requesting client is using a URI containing a fragment identifier.
只要文本/普通片段标识符不被普遍支持，重要的是考虑增量部署的含义。不支持本备忘录中描述的文本/纯文本片段标识符的客户端（例如，Web浏览器）将使用对文本/纯文本MIME实体的URI引用，但它们将无法找到由片段标识符标识的子资源。这是一种合理的回退行为，一般来说，用户应该考虑解释给定URI的程序将无法解释片段标识符部分的可能性。由于片段标识符评估是客户端本地的（并且在检索MIME实体之后发生），因此服务器无法可靠地确定请求客户端是否使用包含片段标识符的URI。
The capitalized 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 [4].
本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
The identification of fragments of text/plain MIME entities can be based on different foundations. Since it is not possible to insert explicit, invisible identifiers into a text/plain MIME entity (for example, as used in HTML documents, implemented through dedicated attributes), fragment identification has to rely on certain inherent properties of the MIME entity. This memo specifies fragment identification using four different methods, which are character positions and ranges, and line positions and ranges, augmented by an integrity check mechanism for improving the robustness of fragment identifiers.
文本/纯MIME实体片段的识别可以基于不同的基础。由于无法将显式、不可见的标识符插入到文本/纯MIME实体中（例如，在HTML文档中使用，通过专用属性实现），片段标识必须依赖于MIME实体的某些固有属性。该备忘录使用四种不同的方法指定片段识别，即字符位置和范围、行位置和范围，并通过完整性检查机制进行增强，以提高片段标识符的鲁棒性。
When interpreting character or line numbers, implementations MUST take the character encoding of the MIME entity into account, because character count and octet count may differ for the character encoding being used. For example, a MIME entity using the UTF-16 encoding (as specified in RFC 2781 [11]) uses two octets per character in most cases, and sometimes four octets per character. It can also have a leading BOM (Byte-Order Mark), which does not count as a character and thus also affects the mapping from a simple octet count to a character count.
在解释字符或行号时，实现必须考虑MIME实体的字符编码，因为所使用的字符编码的字符计数和八位字节计数可能不同。例如，使用UTF-16编码的MIME实体（如RFC 2781[11]中所述）在大多数情况下每个字符使用两个八位字节，有时每个字符使用四个八位字节。它还可以有一个前导BOM（字节顺序标记），它不作为字符计数，因此也会影响从简单的八位字节计数到字符计数的映射。
Fragment identification can be done by combining two orthogonal principles, which are positions and ranges, and characters and lines. This section describes the principles themselves, while Section 2.2 describes the combination of the principles.
片段识别可以通过结合两个正交原则来完成，即位置和范围、字符和线条。本节描述了原则本身，而第2.2节描述了原则的组合。
A position does not identify an actual fragment of the MIME entity, but a position inside the MIME entity, which can be regarded as a fragment of length zero. The use case for positions is to provide pointers for applications that may use them to implement functionalities such as "insert some text here", which needs a position rather than a fragment. Positions are counted from zero; position zero being before the first character or line of a text/ plain MIME entity. Thus, a text/plain MIME entity having one character has two positions, one before the first character (position zero), and one after the first character (position 1).
位置不标识MIME实体的实际片段，而是标识MIME实体内部的位置，可以将其视为长度为零的片段。位置的用例是为应用程序提供指针，这些应用程序可能使用它们来实现诸如“在此处插入一些文本”之类的功能，这需要位置而不是片段。位置从零开始计数；位置0位于文本/纯MIME实体的第一个字符或行之前。因此，具有一个字符的文本/普通MIME实体有两个位置，一个在第一个字符之前（位置0），一个在第一个字符之后（位置1）。
Since positions are fragments of length zero, applications SHOULD use other methods than highlighting to indicate positions, the most obvious way being the positioning of a cursor (if the application supports the concept of a cursor).
由于位置是长度为零的片段，应用程序应该使用高亮显示以外的其他方法来指示位置，最明显的方法是定位光标（如果应用程序支持光标的概念）。
Ranges, on the other hand, identify fragments of a MIME entity that have a length that may be greater than zero. As a general principle for ranges, they specify both a lower and an upper bound. The start or the end of a range specification may be omitted, defaulting to the first or last position of the MIME entity, respectively. The end of a range must have a value greater than or equal to the start. A range with identical start and end is legal and identifies a range of length zero, which is equivalent to a position.
另一方面，范围标识长度可能大于零的MIME实体片段。作为范围的一般原则，它们同时指定下限和上限。范围规范的开始或结束可以省略，分别默认为MIME实体的第一个或最后一个位置。范围的结束值必须大于或等于开始值。起点和终点相同的范围是合法的，并标识长度为零的范围，该范围相当于一个位置。
Applications that support a concept such as highlighting SHOULD use such a concept to indicate fragments of lengths greater than zero to the user.
支持突出显示等概念的应用程序应使用此类概念向用户指示长度大于零的片段。
For positions and ranges, it is implicitly assumed that if a number is greater than the actual number of elements in the MIME entity, then it is referring to the last element of the MIME entity (see Section 4 for details).
对于位置和范围，隐式地假设，如果一个数字大于MIME实体中元素的实际数量，则它指的是MIME实体的最后一个元素（有关详细信息，请参见第4节）。
The concept of positions and ranges can be applied to characters or lines. In both cases, positions indicate points between these entities, while ranges identify zero or more of these entities by indicating positions.
位置和范围的概念可以应用于字符或行。在这两种情况下，位置指示这些实体之间的点，而范围通过指示位置来标识这些实体中的零个或多个。
Character positions are numbered starting with zero (ignoring initial BOM marks or similar concepts that are not part of the actual textual content of a text/plain MIME entity), and counting each character separately, with the exception of line endings, which are always counted as one character (see Section 4.1 for details).
字符位置从零开始编号（忽略初始BOM标记或不属于文本/纯MIME实体实际文本内容一部分的类似概念），并单独计算每个字符，但行尾除外，行尾始终计算为一个字符（有关详细信息，请参见第4.1节）。
Line positions are numbered starting with zero (with line position zero always being identical with character position zero); Section 4.1 describes how line endings are identified. Fragments identified by lines include the line endings, so applications identifying line-based fragments MUST include the line endings in the fragment identification they are using (e.g., the highlighted selection). If a MIME entity does not contain any line endings, then it consists of a single (the first) line.
行位置从零开始编号（行位置零始终与字符位置零相同）；第4.1节描述了如何识别线端点。由行标识的片段包括行尾，因此标识基于行的片段的应用程序必须在其使用的片段标识中包括行尾（例如，高亮显示的选择）。如果MIME实体不包含任何行尾，则它由一行（第一行）组成。
In the following sections, the principles described in the preceding section (positions/ranges and characters/lines) are combined, resulting in four use cases. The schemes mentioned below refer to the fragment identifier syntax, described in detail in Section 3.
在下面的章节中，将前面章节中描述的原则（位置/范围和字符/行）结合起来，形成四个用例。下面提到的方案指的是片段标识符语法，详细描述见第3节。
To identify a character position (i.e., a fragment of length zero between two characters), the 'char' scheme followed by a single number is used. This method identifies a position between two characters (or before the first or after the last character), rather than identifying a fragment consisting of a number of characters. Character position counting starts with zero, so the character position before the first character of a text/plain MIME entity has the character position zero, and a MIME entity containing n distinct characters has n+1 distinct character positions, the last one having the character position n.
为了识别字符位置（即两个字符之间长度为零的片段），使用“char”方案后跟一个数字。此方法标识两个字符之间（或第一个字符之前或最后一个字符之后）的位置，而不是标识由多个字符组成的片段。字符位置计数从零开始，因此文本/纯MIME实体的第一个字符之前的字符位置具有字符位置零，并且包含n个不同字符的MIME实体具有n+1个不同字符位置，最后一个具有字符位置n。
To identify a fragment of one or more characters (a character range), the 'char' scheme followed by a range specification is used. A character range is a consecutive region of the MIME entity that extends from the starting character position of the range to the ending character position of the range.
要识别一个或多个字符（字符范围）的片段，使用“char”方案，后跟范围规范。字符范围是MIME实体的连续区域，从范围的起始字符位置延伸到范围的结束字符位置。
To identify a line position (i.e., a fragment of length zero between two lines), the 'line' scheme followed by a single number is used. This method identifies a position between two lines (or before the first or after the last line), rather than identifying a fragment consisting of a number of lines. Line position counting starts with zero, so the line position before the first line of a text/plain MIME entity has the line position zero, and a MIME entity containing n distinct lines has n+1 distinct line positions, the last one having the line position n.
为了识别线位置（即，两条线之间长度为零的片段），使用“线”方案，后跟一个数字。该方法识别两行之间（或第一行之前或最后一行之后）的位置，而不是识别由多行组成的片段。行位置计数从零开始，因此文本/纯MIME实体第一行之前的行位置具有行位置零，并且包含n个不同行的MIME实体具有n+1个不同行位置，最后一个具有行位置n。
To identify a fragment of one or more lines (a line range), the 'line' scheme followed by a range specification is used. A line range is a consecutive region of the MIME entity that extends from the starting line position of the range to the ending line position of the range.
为了识别一条或多条线（线范围）的片段，使用“线”方案和范围规范。行范围是MIME实体的连续区域，从范围的起始行位置延伸到范围的结束行位置。
It is easily possible that a modification of the referenced resource will break a fragment identifier. If applications want to create more robust fragment identifiers, they may do so by adding integrity-check information to fragment identifiers. Such information is used to detect changes in the resource. Applications can then warn users about the possibility that a fragment identifier might have been broken by a modification of the resource.
对引用资源的修改很可能会破坏片段标识符。如果应用程序想要创建更健壮的片段标识符，可以通过向片段标识符添加完整性检查信息来实现。此类信息用于检测资源中的更改。然后，应用程序可以警告用户，修改资源可能会破坏片段标识符。
Fragment identifiers are interpreted by clients, and therefore integrity-check information is defined on MIME entities rather than on the resource itself. This means that the integrity-check information is specific to a certain entity. Specifically, content encodings and/or content transfer encodings must be removed before using integrity-check information.
片段标识符由客户端解释，因此完整性检查信息是在MIME实体上定义的，而不是在资源本身上定义的。这意味着完整性检查信息特定于某个实体。具体而言，在使用完整性检查信息之前，必须删除内容编码和/或内容传输编码。
Integrity-check information may specify the character encoding that has been used when creating the information, and if such a specification is present, clients MUST check whether the character
完整性检查信息可以指定在创建信息时使用的字符编码，如果存在此类规范，客户端必须检查字符编码是否正确
encoding specified and the character encoding of the retrieved MIME entity are equal, and clients MUST NOT use the integrity check information if these values differ. However, clients MAY choose to transcode the retrieved MIME entity in the case of differing character encodings, and after doing so, apply integrity checks. Please note that this method is inherently unreliable because certain characters or character sequences may have been lost or normalized due to restrictions in one of the character encodings used.
指定的编码与检索到的MIME实体的字符编码相等，如果这些值不同，客户端不得使用完整性检查信息。但是，在不同字符编码的情况下，客户机可以选择对检索到的MIME实体进行转码，并在转码后应用完整性检查。请注意，这种方法本质上是不可靠的，因为某些字符或字符序列可能由于所用字符编码之一的限制而丢失或规范化。
The syntax for the text/plain fragment identifiers is straightforward. The syntax defines four schemes, 'char', 'line', and integrity check (which can either be 'length' or 'md5'). The 'char' and 'line' schemes can be used in two different variants, either the position variant (with a single number), or the range variant (with two comma-separated numbers). An integrity check can either use the 'length' or the 'md5' scheme to specify a value. 'length' in this case serves as a very weak but easy to calculate integrity check.
文本/普通片段标识符的语法非常简单。该语法定义了四种模式，“char”、“line”和完整性检查（可以是“length”或“md5”）。“char”和“line”方案可用于两种不同的变体，位置变体（带有一个数字）或范围变体（带有两个逗号分隔的数字）。完整性检查可以使用“长度”或“md5”方案来指定值在这种情况下，“长度”作为一个非常弱但易于计算的完整性检查。
The following syntax definition uses ABNF as defined in RFC 5234 [9], including the rules DIGIT and HEXDIG. The mime-charset rule is defined in RFC 2978 [5].
以下语法定义使用RFC 5234[9]中定义的ABNF，包括规则DIGIT和HEXDIG。mime字符集规则在RFC 2978[5]中定义。
NOTE: In the descriptions that follow, specified text values MUST be used exactly as given, using exactly the indicated lower-case letters. In this respect, the ABNF usage differs from [9].
注意：在下面的说明中，指定的文本值必须完全按照给定值使用，并完全使用指示的小写字母。在这方面，ABNF的用法不同于[9]。
text-fragment = text-scheme 0*( ";" integrity-check )
text-scheme = ( char-scheme / line-scheme )
char-scheme = "char=" ( position / range )
line-scheme = "line=" ( position / range )
integrity-check = ( length-scheme / md5-scheme )
[ "," mime-charset ]
position = number
range = ( position "," [ position ] ) / ( "," position )
number = 1*( DIGIT )
length-scheme = "length=" number
md5-scheme = "md5=" md5-value
md5-value = 32HEXDIG
text-fragment = text-scheme 0*( ";" integrity-check )
text-scheme = ( char-scheme / line-scheme )
char-scheme = "char=" ( position / range )
line-scheme = "line=" ( position / range )
integrity-check = ( length-scheme / md5-scheme )
[ "," mime-charset ]
position = number
range = ( position "," [ position ] ) / ( "," position )
number = 1*( DIGIT )
length-scheme = "length=" number
md5-scheme = "md5=" md5-value
md5-value = 32HEXDIG
An integrity check can either specify a MIME entity's length, or its MD5 fingerprint. In both cases, it can optionally specify the character encoding that has been used when calculating the integrity
完整性检查可以指定MIME实体的长度，也可以指定其MD5指纹。在这两种情况下，它都可以选择指定在计算完整性时使用的字符编码
check, so that clients interpreting the fragment identifier may check whether they are using the same character encoding for their calculations. For lengths, the character encoding can be necessary because it can influence the character count. As an example, Unicode includes precomposed characters for writing Vietnamese, but in the windows-1258 encoding, also used for writing Vietnamese, some characters have to be encoded with separate diacritics, which means that two characters will be counted. Applying Unicode terminology, this means that the length of a text/plain MIME entity is computed based on its "code points". For MD5 fingerprints, the character encoding is necessary because the MD5 algorithm works on the binary representation of the text/plain resource.
检查，以便解释片段标识符的客户机可以检查他们的计算是否使用相同的字符编码。对于长度，字符编码是必要的，因为它会影响字符计数。例如，Unicode包括用于编写越南语的预合成字符，但在同样用于编写越南语的windows-1258编码中，某些字符必须使用单独的变音符号进行编码，这意味着将计算两个字符。应用Unicode术语，这意味着文本/纯MIME实体的长度是基于其“代码点”计算的。对于MD5指纹，字符编码是必要的，因为MD5算法工作于文本/普通资源的二进制表示。
To allow future changes to this specification to address developments in cryptography, implementations MUST ignore new types of integrity checks, with names other than 'length' and 'md5'. If several integrity checks are present, an application can use whatever integrity checks it understands, and among these, those integrity checks that provide an appropriate trade-off between performance and the need for integrity checking. Please see Section 4.3 for further details.
为了允许将来对本规范进行更改以解决密码学的发展，实现必须忽略新类型的完整性检查，名称不是“length”和“md5”。如果存在多个完整性检查，应用程序可以使用其理解的任何完整性检查，其中包括在性能和完整性检查需求之间提供适当权衡的完整性检查。更多详情请参见第4.3节。
The length of a text/plain MIME entity is calculated by using the principles defined in Section 2.1.2. The MD5 fingerprint of a text/ plain MIME entity is calculated by using the algorithm presented in [1], encoding the result in 32 hexadecimal digits (using uppercase or lowercase letters) as a representation of the 128 bits that are the result of the MD5 algorithm. Calculation of integrity checks is done after stripping any potential content-encodings or content-transfer-encodings of the transport mechanism.
使用第2.1.2节中定义的原则计算文本/纯MIME实体的长度。文本/纯MIME实体的MD5指纹是通过使用[1]中介绍的算法计算的，将结果编码为32个十六进制数字（使用大写或小写字母）作为MD5算法结果128位的表示。完整性检查的计算是在剥离传输机制的任何潜在内容编码或内容传输编码之后完成的。
Applications implementing support for the mechanism described in this memo MUST behave as described in the following sections.
实现对本备忘录中所述机制的支持的应用程序的行为必须符合以下各节的描述。
In Internet messages, line endings in text/plain MIME entities are represented by CR+LF character sequences (see RFC 2046 [3] and RFC 3676 [6]). However, some protocols (such as HTTP) additionally allow other conventions for line endings. Also, some operating systems store text/plain entities locally with different line endings (in most cases, Unix uses LF, MacOS traditionally uses CR, and Windows uses CR+LF).
在Internet消息中，文本/纯MIME实体中的行尾由CR+LF字符序列表示（参见RFC 2046[3]和RFC 3676[6]）。但是，某些协议（如HTTP）还允许其他行结束约定。此外，一些操作系统使用不同的行尾在本地存储文本/普通实体（在大多数情况下，Unix使用LF，MacOS传统上使用CR，Windows使用CR+LF）。
Independent of the number of bytes or characters used to represent a line ending, each line ending MUST be counted as one single
与用于表示行尾的字节数或字符数无关，每个行尾必须作为一个单独的字符计数
character. Implementations interpreting text/plain fragment identifiers MUST take into account the line ending conventions of the protocols and other contexts that they work in.
性格解释文本/纯片段标识符的实现必须考虑协议的行结束约定以及它们工作的其他上下文。
As an example, an implementation working in the context of a Web browser supporting http: URIs has to support the various line ending conventions permitted by HTTP. As another example, an implementation used on local files (e.g., with the file: URI scheme) has to support the conventions used for local storage. All implementations SHOULD support the Internet-wide CR+LF line ending convention, and MAY support additional conventions not related to the protocols or systems they work with.
例如，在支持http:uri的Web浏览器上下文中工作的实现必须支持http允许的各种行尾约定。作为另一个示例，在本地文件上使用的实现（例如，使用file:URI方案）必须支持用于本地存储的约定。所有实现都应支持互联网范围的CR+LF线路结束约定，并且可能支持与它们所使用的协议或系统无关的其他约定。
Implementers should be aware of the fact that line endings in plain text entities can be represented by other characters or character sequences than CR+LF. Besides the abovementioned CR and LF, there are also NEL and CR+NEL. In general, the encoding of line endings can also depend on the character encoding of the MIME entity, and implementations have to take this into account where necessary.
实现者应该知道，纯文本实体中的行尾可以由CR+LF以外的其他字符或字符序列表示。除上述CR和LF外，还有NEL和CR+NEL。一般来说，行尾的编码也可以依赖于MIME实体的字符编码，实现必须在必要时考虑这一点。
If any position value (as a position or as part of a range) is greater than the length of the actual MIME entity, then it identifies the last character position or line position of the MIME entity. If the first position value in a range is not present, then the range extends from the start of the MIME entity. If the second position value in a range is not present, then the range extends to the end of the MIME entity. If a range scheme's positions are not properly ordered (i.e., the first number is less than the second), then the fragment identifier MUST be ignored.
如果任何位置值（作为位置或范围的一部分）大于实际MIME实体的长度，则它标识MIME实体的最后一个字符位置或行位置。如果某个范围中的第一个位置值不存在，则该范围从MIME实体的开头开始扩展。如果某个范围中的第二个位置值不存在，则该范围将扩展到MIME实体的末尾。如果范围方案的位置顺序不正确（即，第一个数字小于第二个），则必须忽略片段标识符。
Clients are not required to implement the handling of integrity checks, so they MAY choose to ignore integrity check information altogether. However, if they do implement integrity checking, the following applies:
客户机不需要实现完整性检查的处理，因此他们可以选择完全忽略完整性检查信息。但是，如果他们确实实施了完整性检查，则以下情况适用：
If a fragment identifier contains one or more integrity checks, and a client retrieves a MIME entity and, using some integrity check(s), detects that the entity has changed (observing the character encoding specification as described in Section 3.1, if present), then the client SHOULD NOT interpret the text/plain fragment identifier. A client MAY signal this situation to the user.
如果片段标识符包含一个或多个完整性检查，并且客户端检索MIME实体，并使用一些完整性检查检测到该实体已更改（遵守第3.1节中描述的字符编码规范，如果存在），则客户端不应解释文本/纯片段标识符。客户机可以向用户发出这种情况的信号。
If a fragment identifier contains a syntax error (i.e., does not conform to the syntax specified in Section 3), then it MUST be ignored by clients. Clients MUST NOT make any attempt to correct or guess fragment identifiers. Syntax errors MAY be reported by clients.
如果片段标识符包含语法错误（即，不符合第3节中指定的语法），则客户端必须忽略它。客户端不得尝试更正或猜测片段标识符。客户端可能会报告语法错误。
The following examples show some usages for the fragment identifiers defined in this memo.
以下示例显示了此备忘录中定义的片段标识符的一些用法。
http://example.com/text.txt#char=100
http://example.com/text.txt#char=100
This URI identifies the position after the 100th character of the text.txt MIME entity. It should be noted that it is not clear which octet(s) of the MIME entity this will be without retrieving the MIME entity and thus knowing which character encoding it is using (in case of HTTP, this information will be given in the Content-Type header of the response). If the MIME entity has fewer than 100 characters, the URI identifies the position after the MIME entity's last character.
此URI标识text.txt MIME实体的第100个字符后的位置。应该注意的是，如果不检索MIME实体并因此知道它使用的是哪个字符编码（对于HTTP，此信息将在响应的内容类型标头中给出），则不清楚该MIME实体的哪个八位字节。如果MIME实体少于100个字符，URI将标识MIME实体最后一个字符后的位置。
http://example.com/text.txt#line=10,20
http://example.com/text.txt#line=10,20
This URI identifies lines 11 to 20 of the text.txt MIME entity. If the MIME entity has fewer than 11 lines, it identifies the position after the last line. If the MIME entity has less than 20 but at least 11 lines, it identifies the range from line 11 to the last line of the MIME entity.
此URI标识text.txt MIME实体的第11到20行。如果MIME实体少于11行，它将标识最后一行之后的位置。如果MIME实体的行数少于20行，但至少有11行，则会标识从第11行到MIME实体最后一行的范围。
https://example.com/text.txt#line=,1
https://example.com/text.txt#line=,1
This URI identifies the first line. Please note that the URI scheme has been changed to https.
此URI标识第一行。请注意，URI方案已更改为https。
ftp://example.com/text.txt#line=10,20;length=9876,UTF-8
ftp://example.com/text.txt#line=10,20;length=9876,UTF-8
As in the second example, this URI identifies lines 11 to 20 of the text.txt MIME entity. The additional length integrity check specifies that the MIME entity has a length of 9876 characters when encoded in UTF-8. If the client supports the length scheme, it may test the retrieved MIME entity for its length, but only if the retrieved MIME entity uses the UTF-8 encoding or has been locally transcoded into this encoding.
与第二个示例一样，此URI标识text.txt MIME实体的第11到20行。附加长度完整性检查指定MIME实体在UTF-8中编码时的长度为9876个字符。如果客户机支持长度方案，它可以测试检索到的MIME实体的长度，但前提是检索到的MIME实体使用UTF-8编码或已在本地转码为该编码。
Please note that the FTP protocol, as well as some other protocols underlying some other URI schemes, do not provide explicit information about the media type of the resource being retrieved. Using fragment identifiers with such URI schemes is therefore inherently unreliable. Current user agents use various heuristics to infer some media type for further processing. Processing of the fragment identifier according to this memo is only appropriate if the inferred media type is text/plain.
请注意，FTP协议以及一些其他URI方案下的一些其他协议没有提供有关所检索资源的媒体类型的明确信息。因此，在这样的URI方案中使用片段标识符本质上是不可靠的。当前的用户代理使用各种试探法来推断某些媒体类型以供进一步处理。仅当推断出的媒体类型为文本/普通时，根据本备忘录处理片段标识符才合适。
IANA has added a reference to this specification in the text/plain Media Type registration.
IANA在文本/普通媒体类型注册中添加了对本规范的引用。
The fact that software implementing fragment identifiers for plain text and software not implementing them differs in behavior, and the fact that different software may show documents or fragments to users in different ways, can lead to misunderstandings on the part of users. Such misunderstandings might be exploited in a way similar to spoofing or phishing.
实现纯文本片段标识符的软件与未实现纯文本片段标识符的软件在行为上有所不同，并且不同的软件可能以不同的方式向用户显示文档或片段，这一事实可能会导致用户的误解。这种误解可能以类似于欺骗或网络钓鱼的方式被利用。
In particular, care has to be taken if fragment identifiers are used together with a mechanism that allows showing only the part of a document identified by a fragment. One scenario may be the use of a fragment identifier to hide small-print legal text. Another scenario may be the inclusion of site-key-like material, which may give the user the impression of using the real site rather than a fake site; other scenarios may also be possible. Possible countermeasures may include but are not limited to displaying the included content within clearly visible boundaries and limiting inclusion to material from the same security realm or from realms that give explicit permission to be included in another realm.
特别是，如果将片段标识符与只允许显示由片段标识的文档部分的机制一起使用，则必须小心。一种情况可能是使用片段标识符隐藏小字体法律文本。另一种情况可能是包含类似站点密钥的材料，这可能会给用户使用真实站点而不是虚假站点的印象；其他情况也可能发生。可能的对策可能包括但不限于在清晰可见的边界内显示包含的内容，并限制包含来自同一安全领域或明确允许包含在另一领域的领域的材料。
Please note that the above issues all apply to the client side; fragment identifiers are not used when resolving a URI to retrieve the representation of a resource, but are only applied on the client side.
请注意，上述问题均适用于客户方；在解析URI以检索资源的表示形式时，不使用片段标识符，而只应用于客户端。
Implementers and users of fragment identifiers for plain text should also be aware of the security considerations in RFC 3986 [7] and RFC 3987 [8].
纯文本片段标识符的实现者和用户还应该了解RFC 3986[7]和RFC 3987[8]中的安全注意事项。
[1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[1] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[2] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[5] Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[6] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[6] Gellens，R.，“文本/普通格式和DelSp参数”，RFC 3676，2004年2月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[8] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRI)", RFC 3987, January 2005.
[8] Duerst，M.和M.Suignard，“国际化资源标识符（IRI）”，RFC 3987，2005年1月。
[9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[9] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[10] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[10] Connolly，D.和L.Masinter，“文本/html”媒体类型”，RFC 28542000年6月。
[11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[11] Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[12] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[13] ANSI X3.4-1986, "Coded Character Set - 7-Bit American National Standard Code for Information Interchange", 1986.
[13] ANSI X3.4-1986，“编码字符集-信息交换用7位美国国家标准代码”，1986年。
[14] DeRose, S., Maler, E., and D. Orchard, "XML Linking Language (XLink) Version 1.0", World Wide Web Consortium Recommendation, June 2001, <http://www.w3.org/TR/xlink/>.
[14] DeRose，S.，Maler，E.，和D.Orchard，“XML链接语言（XLink）1.0版”，万维网联盟建议，2001年6月<http://www.w3.org/TR/xlink/>.
[15] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[15] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
Thanks for comments and suggestions provided by Marcel Baschnagel, Stephane Bortzmeyer, Tim Bray, Iain Calder, John Cowan, Spencer Dawkins, Lisa Dusseault, Benja Fallenstein, Ted Hardie, Sam Hartman, Sandro Hawke, Jeffrey Hutzelman, Cullen Jennings, Graham Klyne, Dan Kohn, Henrik Levkowetz, Chris Newman, Mark Nottingham, Conrad Parker, and Tim Polk.
感谢Marcel Baschnagel、Stephane Bortzmeyer、Tim Bray、Iain Calder、John Cowan、Spencer Dawkins、Lisa Dusseault、Benja Fallenstein、Ted Hardie、Sam Hartman、Sandro Hawke、Jeffrey Hutzelman、Cullen Jennings、Graham Klyne、Dan Kohn、Henrik Levkowetz、Chris Newman、Mark Nottingham、Conrad Parker提供的评论和建议，还有蒂姆·波尔克。
Authors' Addresses
作者地址
Erik Wilde UC Berkeley School of Information, 311 South Hall Berkeley, CA 94720-4600 U.S.A.
Erik Wilde加州大学伯克利分校信息学院，311 South Hall Berkeley，加利福尼亚州94720-4600美国。
Phone: +1-510-6432253
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/
Phone: +1-510-6432253
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/
Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
Martin Duerst（注：请尽可能用u-umlaut写“Duerst”，例如用XML和HTML写“Dü；rst”）。青山学院大学5-10-1 Fuchinobe Sagamihara，神奈川229-8558日本
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.
本文件受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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.