Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
Registration Procedures for Message Header Fields
消息头字段的注册过程
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.
本规范定义了Internet邮件、HTTP、Netnews和其他应用程序使用的消息头字段的注册过程。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structure of this Document . . . . . . . . . . . . . . . 3
1.2. Document Terminology and Conventions . . . . . . . . . . 4
2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4
2.1. Permanent and Provisional Header Fields. . . . . . . . . 4
2.2. Definitions of Message Header Fields . . . . . . . . . . 5
2.2.1. Application-specific Message Header Fields. . . . 5
2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6
3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6
4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6
4.1. Header Field Specification . . . . . . . . . . . . . . . 7
4.2. Registration Templates . . . . . . . . . . . . . . . . . 7
4.2.1. Permanent Message Header Field Registration
Template. . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Provisional Message Header Field Submission
Template. . . . . . . . . . . . . . . . . . . . . 8
4.3. Submission of Registration . . . . . . . . . . . . . . . 10
4.4. Objections to Registration . . . . . . . . . . . . . . . 10
4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11
4.6. Comments on Header Definitions . . . . . . . . . . . . . 12
4.7. Location of Header Field Registry. . . . . . . . . . . . 12
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structure of this Document . . . . . . . . . . . . . . . 3
1.2. Document Terminology and Conventions . . . . . . . . . . 4
2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4
2.1. Permanent and Provisional Header Fields. . . . . . . . . 4
2.2. Definitions of Message Header Fields . . . . . . . . . . 5
2.2.1. Application-specific Message Header Fields. . . . 5
2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6
3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6
4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6
4.1. Header Field Specification . . . . . . . . . . . . . . . 7
4.2. Registration Templates . . . . . . . . . . . . . . . . . 7
4.2.1. Permanent Message Header Field Registration
Template. . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Provisional Message Header Field Submission
Template. . . . . . . . . . . . . . . . . . . . . 8
4.3. Submission of Registration . . . . . . . . . . . . . . . 10
4.4. Objections to Registration . . . . . . . . . . . . . . . 10
4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11
4.6. Comments on Header Definitions . . . . . . . . . . . . . 12
4.7. Location of Header Field Registry. . . . . . . . . . . . 12
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
This specification defines registration procedures for the message header field names used by Internet mail, HTTP, newsgroup feeds and other Internet applications. It is not intended to be a replacement for protocol-specific registries, such as the SIP registry [30].
本规范定义了Internet邮件、HTTP、新闻组提要和其他Internet应用程序使用的消息头字段名称的注册过程。它并不打算取代特定于协议的注册表，如SIP注册表[30]。
Benefits of a central registry for message header field names include:
邮件标题字段名称的中央注册表的好处包括：
o providing a single point of reference for standardized and widely-used header field names;
o 为标准化和广泛使用的标题字段名称提供单一参考点；
o providing a central point of discovery for established header fields, and easy location of their defining documents;
o 为已建立的标题字段提供中心发现点，并方便地定位其定义文档；
o discouraging multiple definitions of a header field name for different purposes;
o 阻止为不同目的对标题字段名称进行多个定义；
o helping those proposing new header fields discern established trends and conventions, and avoid names that might be confused with existing ones;
o 帮助提议新标题字段的人识别既定趋势和惯例，避免将名称与现有名称混淆；
o encouraging convergence of header field name usage across multiple applications and protocols.
o 鼓励跨多个应用程序和协议使用标题字段名。
The primary specification for Internet message header fields in email is the Internet mail message format specification, RFC 2822 [4]. HTTP/1.0 [10] and HTTP/1.1 [24] define message header fields (respectively, the HTTP-header and message-header protocol elements) for use with HTTP. RFC 1036 [5] defines message header elements for use with Netnews feeds. These specifications also define a number of header fields, and provide for extension through the use of new field-names.
电子邮件中Internet邮件头字段的主要规范是Internet邮件格式规范RFC 2822[4]。HTTP/1.0[10]和HTTP/1.1[24]定义用于HTTP的消息头字段（分别是HTTP头和消息头协议元素）。RFC 1036[5]定义了用于Netnews提要的消息头元素。这些规范还定义了许多标题字段，并通过使用新字段名提供扩展。
There are many other Internet standards track documents that define additional header fields for use within the same namespaces, notably MIME [11] and related specifications. Other Internet applications that use MIME, such as SIP (RFC 3261 [30]) may also use many of the same header fields (but note that IANA maintains a separate registry of header fields used with SIP).
还有许多其他Internet标准跟踪文档定义了在相同名称空间中使用的附加头字段，特别是MIME[11]和相关规范。其他使用MIME的Internet应用程序，如SIP（RFC 3261[30]）也可能使用许多相同的头字段（但请注意，IANA维护着与SIP一起使用的头字段的单独注册表）。
Although in principle each application defines its own set of valid header fields, exchange of messages between applications (e.g., mail to Netnews gateways), common use of MIME encapsulation, and the possibility of common processing for various message types (e.g., a common message archive and retrieval facility) makes it desirable to have a common point of reference for standardized and proposed header fields. Listing header fields together reduces the chance of an accidental collision, and helps implementers find relevant information. The message header field registries defined here serve that purpose.
虽然原则上每个应用程序都定义了自己的一组有效头字段、应用程序之间的消息交换（例如，邮件到Netnews网关）、MIME封装的常见用法以及对各种消息类型进行通用处理的可能性（例如，通用的消息存档和检索设施）使标准化和建议的标题字段有一个共同的参考点成为可能。同时列出标题字段可以减少意外冲突的可能性，并帮助实现者找到相关信息。此处定义的消息头字段注册表用于此目的。
Section 2 discusses the purpose of this specification, and indicates some sources of information about defined message header fields.
第2节讨论了本规范的目的，并指出了有关已定义消息头字段的一些信息源。
Section 4 defines the message header field name repositories, and sets out requirements and procedures for creating entries in them.
第4节定义了消息头字段名称存储库，并列出了在其中创建条目的要求和过程。
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 BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
Many message header fields are defined in standards-track documents, which means they have been subjected to a process of community review and achieved consensus that they provide a useful and well-founded capability, or represent a widespread use of which developers should be aware. Some are defined for experimental use, typically indicating consensus regarding their purpose but not necessarily concerning their technical details. Many others have been defined and adopted ad-hoc to address a locally occurring requirement; some of these have found widespread use.
许多消息头字段是在标准跟踪文档中定义的，这意味着它们经过了社区审查，并达成了共识，即它们提供了有用且有充分依据的功能，或者代表了开发人员应该知道的广泛使用。有些定义为实验用途，通常表示对其目的达成共识，但不一定涉及其技术细节。为满足本地发生的需求，还专门定义和采用了许多其他方法；其中一些已经被广泛使用。
The catalogues defined here are intended to cater for all of these header fields, while maintaining a clear distinction and status for those which have community consensus. To this end, two repositories are defined:
此处定义的目录旨在满足所有这些标题字段的要求，同时保持社区一致意见者的明确区别和地位。为此，定义了两个存储库：
o A Permanent Message Header Field Registry, intended for headers defined in IETF standards-track documents, those that have achieved a comparable level of community review, or are generally recognized to be in widespread use. The assignment policy for such registration is "Specification Required", as defined by RFC 2434 [3], where the specification must be published in an RFC (standards-track, experimental, informational or historic), or as an "Open Standard" in the sense of RFC 2026, section 7 [1].
o 一种永久性的消息头字段注册表，用于IETF标准跟踪文件中定义的头、已达到可比社区审查水平的头或通常被认为广泛使用的头。此类注册的转让政策为RFC 2434[3]定义的“要求规范”，其中规范必须在RFC（标准跟踪、实验、信息或历史）中发布，或作为RFC 2026第7节[1]意义上的“开放标准”发布。
o A Provisional Message Header Field Repository, intended for any header field proposed by any developer, without making any claim about its usefulness or the quality of its definition. The policy for recording these is "Private Use", per RFC 2434 [3].
o 一种临时消息头字段存储库，用于任何开发人员提议的任何头字段，而不声明其有用性或其定义的质量。根据RFC 2434[3]，记录这些信息的政策为“私人使用”。
Neither repository tracks the syntax, semantics or type of field-values. Only the field-names, applicable protocols and status are registered; all other details are specified in the defining documents referenced by repository entries. Significant updates to such references (e.g., the replacement of a Proposed Standard RFC by a Draft Standard RFC, but not necessarily the revision of an Internet-draft) SHOULD be accompanied by updates to the corresponding repository entries.
这两个存储库都不跟踪字段值的语法、语义或类型。仅注册字段名称、适用协议和状态；所有其他详细信息都在存储库条目引用的定义文档中指定。对此类参考文件的重大更新（例如，用标准RFC草案替换提议的标准RFC，但不一定是对互联网草案的修订）应伴随相应存储库条目的更新。
RFC 2822 [4] defines a general syntax for message headers, and also defines a number of fields for use with Internet mail. HTTP/1.0 [10] and HTTP/1.1 [24] do likewise for HTTP. Additional field names are defined in a variety of standards-track RFC documents, including: RFC 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC 2156 [14], RFC 2183 [15], RFC 2045 [11], RFC 2046 [12], RFC 2557 [23], RFC 2227 [16], RFC 2231 [17], RFC 2298 [18], RFC 2369 [19], RFC 2421 [21], RFC 2518 [22], RFC 2617 [25], RFC 2821 [26], RFC 2912 [27], RFC 2919 [28], RFC 2965 [29], and RFC 3282 [31].
RFC 2822[4]定义了消息头的通用语法，还定义了许多用于Internet邮件的字段。HTTP/1.0[10]和HTTP/1.1[24]也适用于HTTP。其他字段名称在各种标准跟踪RFC文档中定义，包括：RFC 1036[5]、RFC 1496[6]、RFC 1505[7]、RFC 1864[9]、RFC 2156[14]、RFC 2183[15]、RFC 2045[11]、RFC 2046[12]、RFC 2557[23]、RFC 2227[16]、RFC 2231[17]、RFC 2298[18]、RFC 2369[19]、RFC 2421[21]、RFC 2518[22]、RFC 2617[25]、RFC 2821[26]，RFC 2912[27]、RFC 2919[28]、RFC 2965[29]和RFC 3282[31]。
Internet applications that use similar message headers include Internet mail [26] [4], NNTP newsgroup feeds [5], HTTP web access [24] and any other that uses MIME [11] encapsulation of message content.
使用类似消息头的互联网应用程序包括互联网邮件[26][4]、NNTP新闻组源[5]、HTTP web访问[24]以及任何其他使用MIME[11]封装消息内容的应用程序。
In some cases (notably HTTP [24]), the header syntax and usage is redefined for the specific application. This registration is concerned only with the allocation and specification of field names, and not with the details of header implementation in specific protocols.
在某些情况下（尤其是HTTP[24]），针对特定应用程序重新定义了标头语法和用法。这种注册只涉及字段名的分配和指定，而不涉及特定协议中的报头实现细节。
In some cases, the same field name may be specified differently (by different documents) for use with different application protocols; e.g., The Date: header field used with HTTP has a different syntax than the Date: used with Internet mail. In other cases, a field name may have a common specification across multiple protocols (ignoring protocol-specific lexical and character set conventions); e.g., this is generally the case for MIME header fields with names of the form 'Content-*'.
在某些情况下，相同的字段名可能会以不同的方式（由不同的文档）指定，以用于不同的应用协议；e、 例如，HTTP使用的Date:header字段的语法与Internet邮件使用的Date:header字段的语法不同。在其他情况下，字段名可能具有跨多个协议的通用规范（忽略协议特定的词汇和字符集约定）；e、 例如，名称形式为“Content-*”的MIME头字段通常就是这种情况。
Thus, we need to accommodate application-specific fields, while wishing to recognize and promote (where appropriate) commonality of other fields across multiple applications. Common repositories are used for all applications, and each registered header field specifies the application protocol for which the corresponding definition applies. A given field name may have multiple registry entries for different protocols; in the Permanent Message Header Field registry, a given header field name may be registered only once for any given protocol. (In some cases, the registration may reference several defining documents.)
因此，我们需要适应特定于应用程序的字段，同时希望识别和促进（在适当情况下）跨多个应用程序的其他字段的通用性。公共存储库用于所有应用程序，每个注册的头字段指定应用相应定义的应用程序协议。给定的字段名可能有多个不同协议的注册表项；在永久消息头字段注册表中，对于任何给定协议，给定的头字段名称只能注册一次。（在某些情况下，注册可能引用多个定义文件。）
Some header fields with names of the form Content-* are associated with the MIME data object encapsulation and labelling framework. These header fields can meaningfully be applied to a data object separately from the protocol used to carry it.
一些名为Content-*的标题字段与MIME数据对象封装和标签框架相关联。这些头字段可以有意义地应用于数据对象，与用于承载它的协议不同。
MIME is used with email messages and other protocols that specify a MIME-based data object format. MIME header fields used with such protocols are defined in the registry with the protocol "mime", and as such are presumed to be usable in conjunction with any protocol that conveys MIME objects.
MIME与电子邮件和其他指定基于MIME的数据对象格式的协议一起使用。与此类协议一起使用的MIME头字段在注册表中使用协议“MIME”进行定义，因此假定可与传输MIME对象的任何协议一起使用。
Other protocols do not convey MIME objects, but define a number of header fields with similar names and functions to MIME. Notably, HTTP defines a number of entity header fields that serve a purpose in HTTP similar to MIME header fields in email. Some of these header fields have the same names and similar functions to their MIME counterparts (though there are some variations). Such header fields must be registered separately for any non-MIME-carrying protocol with which they may be used.
其他协议不传递MIME对象，但定义了许多与MIME具有类似名称和函数的头字段。值得注意的是，HTTP定义了许多实体头字段，这些字段在HTTP中的用途类似于电子邮件中的MIME头字段。其中一些头字段与MIME对应字段具有相同的名称和类似的函数（尽管有一些变体）。对于任何非MIME承载协议，这些头字段必须单独注册，以便与之配合使用。
It is poor practice to reuse a header field name from another protocol simply because the fields have similar (even "very similar") meanings. Protocols should share header field names only when their meanings are identical in all foreseeable circumstances. In particular, new header field names of the form Content-* should not be defined for non-MIME-carrying protocols unless their specification is exactly the same as in MIME.
仅仅因为字段具有相似（甚至“非常相似”）的含义，重用来自另一个协议的头字段名是一种糟糕的做法。只有在所有可预见的情况下，协议的含义相同时，协议才应共享标题字段名。特别是，不应为非MIME承载协议定义表单Content-*的新头字段名称，除非它们的规范与MIME中的规范完全相同。
RFCs defining new header fields for Internet mail, HTTP, or MIME MUST include appropriate header registration template(s) (as given in Section 4.2) for all headers defined in the document in their IANA considerations section. Use of the header registry MAY be mandated by other protocol specifications, however, in the absence of such a mandate use of the registry is not required.
为Internet邮件、HTTP或MIME定义新标题字段的RFC必须为其IANA注意事项部分中文档中定义的所有标题包含适当的标题注册模板（如第4.2节所述）。其他协议规范可能会强制使用头注册表，但是，在没有此类强制的情况下，不需要使用注册表。
The procedure for registering a message header field is:
注册消息头字段的过程如下：
1. Construct a header field specification
1. 构造标题字段规范
2. Prepare a registration template
2. 准备注册模板
3. Submit the registration template
3. 提交注册模板
Registration of a new message header field starts with construction of a proposal that describes the syntax, semantics and intended use of the field. For entries in the Permanent Message Header Field Registry, this proposal MUST be published as an RFC, or as an Open Standard in the sense described by RFC 2026, section 7 [1].
注册一个新的消息头字段首先要构造一个描述该字段的语法、语义和预期用途的建议。对于永久消息标题字段注册表中的条目，本提案必须作为RFC或RFC 2026第7节[1]所述的开放标准发布。
A registered field name SHOULD conform at least to the syntax defined by RFC 2822 [4], section 3.6.8.
注册字段名应至少符合RFC 2822[4]第3.6.8节定义的语法。
Further, the "." character is reserved to indicate a naming sub-structure and MUST NOT be included in any registered field name. Currently, no specific sub-structure is defined; if used, any such structure MUST be defined by a standards track RFC document.
此外，“.”字符保留用于指示命名子结构，不得包含在任何已注册的字段名中。目前，没有定义具体的子结构；如果使用，任何此类结构必须由标准跟踪RFC文档定义。
Header field names may sometimes be used in URIs, URNs and/or XML. To comply with the syntactic constraints of these forms, it is recommended that characters in a registered field name are restricted to those that can be used without escaping in a URI [20] or URN [13], and that are also legal in XML [32] element names.
标题字段名有时可能用于URI、URN和/或XML中。为了遵守这些表单的语法约束，建议将注册字段名中的字符限制为在URI[20]或URN[13]中不转义即可使用的字符，以及在XML[32]元素名中也是合法的字符。
Thus, for maximum flexibility, header field names SHOULD further be restricted to just letters, digits, hyphen ('-') and underscore ('_') characters, with the first character being a letter or underscore.
因此，为了获得最大的灵活性，标题字段名称应该进一步限制为仅包含字母、数字、连字符（'-'）和下划线（''''）字符，第一个字符是字母或下划线。
The registration template for a message header field may be contained in the defining document, or prepared separately.
消息头字段的注册模板可以包含在定义文档中，也可以单独准备。
A header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], and MUST have a name which is unique among all the registered permanent field names that may be used with the same application protocol.
在永久消息头字段注册表中注册的头必须发布为RFC或RFC 2026第7节[1]所述意义上的“开放标准”，并且必须具有可与相同应用协议一起使用的所有注册永久字段名称中唯一的名称。
The registration template has the following form.
注册模板具有以下表单。
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
永久消息头字段注册模板：
Header field name: The name requested for the new header field. This MUST conform to the header field specification details noted in Section 4.1.
标题字段名称：为新标题字段请求的名称。这必须符合第4.1节所述的标题字段规范细节。
Applicable protocol: Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), "netnews" (RFC 1036), or cite any other standards-track RFC defining the protocol with which the header is intended to be used.
适用的协议：指定“邮件”（RFC 2822）、“mime”（RFC 2045）、“http”（RFC 2616）、“网络新闻”（RFC 1036），或引用任何其他标准跟踪RFC，以定义要使用报头的协议。
Status: Specify "standard", "experimental", "informational", "historic", "obsoleted", or some other appropriate value according to the type and status of the primary document in which it is defined. For non-IETF specifications, those formally approved by other standards bodies should be labelled as "standard"; others may be "informational" or "deprecated" depending on the reason for registration.
状态：根据定义的主要文档的类型和状态，指定“标准”、“实验”、“信息”、“历史”、“过时”或其他适当的值。对于非IETF规范，其他标准机构正式批准的规范应标记为“标准”；其他可能是“信息性”或“不推荐”，具体取决于注册原因。
Author/Change controller: For Internet standards-track, state "IETF". For other open standards, give the name of the publishing body (e.g., ANSI, ISO, ITU, W3C, etc.). For other specifications, give the name, email address, and organization name of the primary specification author. A postal address, home page URI, telephone and fax numbers may also be included.
作者/变更控制员：对于互联网标准跟踪，请注明“IETF”。对于其他开放标准，请提供发布机构的名称（例如ANSI、ISO、ITU、W3C等）。对于其他规范，请提供主要规范作者的姓名、电子邮件地址和组织名称。还可能包括邮政地址、主页URI、电话和传真号码。
Specification document(s): Reference to document that specifies the header for use with the indicated protocol, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections MAY also be included, but is not required.
规范文档：指指定用于所指示协议的标题的文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的说明，但不是必需的。
Related information: Optionally, citations to additional documents containing further relevant information. (This part of the registry may also be used for IESG comments.) Where a primary specification refers to another document for substantial technical detail, the referenced document is usefully mentioned here.
相关信息：可选地，引用包含进一步相关信息的其他文件。（注册中心的这一部分也可用于IESG评论。）如果主要规范参考了另一份文件以获取实质性技术细节，此处提及的参考文件是有用的。
Registration as a Provisional Message Header Field does not imply any kind of endorsement by the IETF, IANA or any other body.
注册为临时消息头字段并不意味着IETF、IANA或任何其他机构的任何认可。
The main requirements for a header field to be included in the provisional repository are that it MUST have a citable specification, and there MUST NOT be a corresponding entry (with same field name and protocol) in the permanent header field registry.
临时存储库中要包含的标题字段的主要要求是，它必须具有可引用的规范，并且永久标题字段注册表中不得有相应的条目（具有相同的字段名称和协议）。
The specification SHOULD indicate an email address for sending technical comments and discussion of the proposed message header.
规范应指明用于发送技术意见和讨论建议消息头的电子邮件地址。
The submission template has the following form.
提交模板具有以下表单。
PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
临时邮件标题字段提交模板：
Header field name: The name proposed for the new header field. This SHOULD conform to the field name specification details noted in Section 4.1.
标题字段名称：为新标题字段建议的名称。这应符合第4.1节中注明的字段名称规范细节。
Applicable protocol: Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), "netnews" (RFC 1036), or cite any other standards-track RFC defining the protocol with which the header is intended to be used.
适用的协议：指定“邮件”（RFC 2822）、“mime”（RFC 2045）、“http”（RFC 2616）、“网络新闻”（RFC 1036），或引用任何其他标准跟踪RFC，以定义要使用报头的协议。
Status: Specify: "provisional". This will be updated if and when the header registration is subsequently moved to the permanent registry.
状态：指定：“临时”。如果随后将标题注册移动到永久注册中心，则会更新此信息。
Author/Change controller: The name, email address, and organization name of the submission author, who may authorize changes to or retraction of the repository entry. A postal address, home page URI, telephone and fax numbers may also be included. If the proposal comes from a standards body working group, give the name and home page URI of the working group, and an email address for discussion of or comments on the specification.
作者/更改控制者：提交作者的姓名、电子邮件地址和组织名称，提交作者可授权更改或收回存储库条目。还可能包括邮政地址、主页URI、电话和传真号码。如果提案来自标准机构工作组，请提供工作组的名称和主页URI，以及用于讨论或评论规范的电子邮件地址。
Specification document(s): Reference to document that specifies the header for use with the indicated protocol. The document MUST be an RFC, a current Internet-draft or the URL of a publicly accessible document (so IANA can verify availability of the specification). An indication of the relevant sections MAY also be included, but is not required.
规范文件：指指定用于指定协议的标题的文件。该文档必须是RFC、当前Internet草稿或公开访问文档的URL（以便IANA可以验证规范的可用性）。也可以包括相关章节的说明，但不是必需的。
NOTE: if the specification is available in printed form only, then an Internet draft containing full reference to the paper document should be published and cited in the registration template. The paper specification MAY be cited under related information.
注：如果本规范仅以印刷形式提供，则应在注册模板中发布并引用包含纸质文件完整参考的互联网草案。可在相关信息下引用纸质规范。
Related information: Optionally, citations to additional documents containing further relevant information.
相关信息：可选地，引用包含进一步相关信息的其他文件。
The registration template is submitted for incorporation in one of the IANA message header field repositories by one of the following methods:
注册模板通过以下方法之一提交，以便并入其中一个IANA消息头字段存储库：
o An IANA considerations section in a defining RFC, calling for registration of the message header and referencing information as required by the registration template within the same document. Registration of the header is then processed as part of the RFC publication process.
o 定义RFC中的IANA注意事项部分，要求注册消息头并引用同一文档中注册模板所需的信息。然后，作为RFC发布过程的一部分处理标题的注册。
o Send a copy of the template to the designated email discussion list [33] [34]. Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address [35]. IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 4.1 and Section 4.2.2, unless the IESG or their designated expert have requested that it not be published (see Section 4.4). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied.
o 将模板副本发送到指定的电子邮件讨论列表[33][34]。留出一段合理的时间（至少2周）进行讨论和评论，然后将模板发送至IANA指定的电子邮件地址[35]。如果要求的名称和规范文件符合第4.1节和第4.2.2节所述标准，IANA将发布模板信息，除非IESG或其指定专家要求不发布（见第4.4节）。IESG的指定专家应向IANA确认已满足注册标准。
When a new entry is recorded in the permanent message header field registry, IANA will remove any corresponding entries (with the same field name and protocol) from the provisional registry.
当一个新条目记录在永久消息头字段注册表中时，IANA将从临时注册表中删除任何相应条目（具有相同的字段名和协议）。
Listing of an entry in the provisional repository should not be lightly refused. An entry MAY be refused if there is some credible reason to believe that such registration will be harmful. In the absence of such objection, IANA SHOULD allow any registration that meets the criteria set out in Section 4.1 and Section 4.2.2. Some reasonable grounds for refusal might be:
不应轻易拒绝在临时存储库中列出条目。如果有可信的理由相信登记有害，则可拒绝入境。在没有此类异议的情况下，IANA应允许符合第4.1节和第4.2.2节规定标准的任何注册。拒绝的一些合理理由可能是：
o There is IETF consensus that publication is considered likely to harm the Internet technical infrastructure in some way.
o IETF一致认为，出版物可能以某种方式损害互联网技术基础设施。
o Disreputable or frivolous use of the registration facilities.
o 不名誉或轻率地使用登记设施。
o The proposal is sufficiently lacking in purpose, or misleading about its purpose, that it can be held to be a waste of time and effort.
o 该提案缺乏目的，或对其目的具有误导性，因此可能被认为是浪费时间和精力。
o Conflict with some current IETF activity.
o 与某些当前IETF活动冲突。
Note that objections or disagreements about technical detail are not, of themselves, considered grounds to refuse listing in the provisional repository. After all, one of its purposes is to allow developers to communicate with a view to combining their ideas, expertise and energy to the maximum benefit of the Internet community.
请注意，关于技术细节的异议或分歧本身并不被视为拒绝在临时存储库中列出的理由。毕竟，它的一个目的是让开发人员进行交流，以期将他们的想法、专业知识和精力结合起来，为互联网社区带来最大利益。
Publication in an RFC or other form of Open Standard document (per RFC 2026 [1], section 7) is sufficient grounds for publication in the permanent registry.
以RFC或其他形式的开放式标准文件（根据RFC 2026[1]，第7节）发布是在永久注册处发布的充分理由。
To assist IANA in determining whether or not there is a sustainable objection to any registration, IESG nominates a designated expert to liaise with IANA about new registrations. For the most part, the designated expert's role is to confirm to IANA that the registration criteria have been satisfied.
为了帮助IANA确定是否存在对任何注册的持续异议，IESG指定了一名专家与IANA就新注册事宜进行联络。在大多数情况下，指定专家的作用是向IANA确认已满足注册标准。
The IESG or their designated expert MAY require any change or commentary to be attached to any registry entry.
IESG或其指定专家可要求将任何变更或注释附在任何登记条目上。
The IESG is the final arbiter of any objection.
IESG是任何异议的最终仲裁人。
Change control of a header field registration is subject to the same condition as the initial registration; i.e., publication (or reclassification) of an Open Standards specification for a Permanent Message Header Field, or on request of the indicated author/change controller for a Provisional Message Header (like the original submission, subject to review on the designated email discussion list [33].)
标题字段注册的变更控制受与初始注册相同的条件约束；i、 例如，发布（或重新分类）永久邮件标题字段的开放标准规范，或应指定作者/变更控制者的请求发布临时邮件标题（如原始提交，需在指定的电子邮件讨论列表上进行审查[33]）
A change to a permanent message header field registration MAY be requested by the IESG.
IESG可能会请求更改永久消息头字段注册。
A change to or retraction of any Provisional Message Header Field Repository entry MAY be requested by the IESG or designated expert.
IESG或指定专家可请求更改或撤销任何临时消息头字段存储库条目。
IANA MAY remove any Provisional Message Header Field Repository entry whose corresponding specification document is no longer available (e.g., expired Internet-draft, or URL not resolvable). Anyone may notify IANA of any such cases by sending an email to the designated email address [35]. Before removing an entry for this reason, IANA SHOULD contact the registered Author/Change controller to determine whether a replacement for the specification document (consistent with the requirements of section Section 4.2.2) is available.
IANA可以删除其相应规范文档不再可用的任何临时消息头字段存储库条目（例如，过期的互联网草稿或无法解析的URL）。任何人都可以通过向指定的电子邮件地址发送电子邮件通知IANA任何此类情况[35]。在出于此原因删除条目之前，IANA应联系注册作者/变更控制员，以确定是否可以替换规范文件（符合第4.2.2节的要求）。
It is intended that entries in the Permanent Message Header Field Registry may be used in the construction of URNs (per RFC 2141 [13]) which have particular requirements for uniqueness and persistence (per RFC 1737 [8]). Therefore, once an entry is made in the Permanent Message Header Registry, the combination of the header name and applicable protocol MUST NOT subsequently be registered for any other purpose. (This is not to preclude revision of the applicable specification(s) within the appropriate IETF Consensus rules, and corresponding updates to the specification citation in the header registration.)
永久消息头字段注册表中的条目可用于构建URN（根据RFC 2141[13]），该URN对唯一性和持久性有特殊要求（根据RFC 1737[8]）。因此，一旦在永久消息头注册表中创建了一个条目，随后不得出于任何其他目的注册头名称和适用协议的组合。（这并不排除在适当的IETF共识规则内对适用规范进行修订，以及对标题注册中规范引用的相应更新。）
Comments on proposed registrations should be sent to the designated email discussion list [33].
建议注册的意见应发送至指定的电子邮件讨论列表[33]。
The message header field registry is accessible from IANA's web site
http://www.iana.org/assignments/message-headers/
message-header-index.html
The message header field registry is accessible from IANA's web site
http://www.iana.org/assignments/message-headers/
message-header-index.html
This specification calls for:
本规范要求：
o A new IANA registry for permanent message header fields per Section 4 of this document. The policy for inclusion in this registry is described in Section 4.1 and Section 4.2.1.
o 根据本文件第4节，为永久消息头字段创建新的IANA注册表。第4.1节和第4.2.1节介绍了纳入本登记册的政策。
o A new IANA repository listing provisional message header fields per Section 4 of this document. The policy for inclusion in this registry is described in Section 4.1 and Section 4.2.2.
o 一个新的IANA存储库，根据本文档第4节列出临时消息头字段。第4.1节和第4.2.2节描述了纳入本注册中心的政策。
o IESG appoints a designated expert to advise IANA whether registration criteria for proposed registrations have been satisfied.
o IESG任命一名指定专家，告知IANA是否满足拟议注册的注册标准。
No initial registry entries are provided.
没有提供初始注册表项。
No security considerations are introduced by this specification beyond those already inherent in the use of message headers.
除了在使用消息头时已经固有的安全注意事项外，本规范没有引入其他安全注意事项。
The shape of the registries described here owes much to energetic discussion of previous versions by many denizens of the IETF-822 mailing list.
这里描述的注册表的形状在很大程度上归功于IETF-822邮件列表的许多居民对以前版本的积极讨论。
The authors also gratefully acknowledge the contribution of those who provided valuable feedback on earlier versions of this memo: Charles Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle Cotton.
作者还感谢那些对本备忘录早期版本提供宝贵反馈的人的贡献：查尔斯·林赛、戴夫·克罗克、皮特·雷斯尼克、雅各布·帕尔姆、内德·弗里德、米歇尔·科顿。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[4] Resnick，P.，Ed.，“互联网信息格式”，RFC 2822，2001年4月。
[5] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[5] Horton，M.和R.Adams，“USENET消息交换标准”，RFC 1036，1987年12月。
[6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages", RFC 1496, August 1993.
[6] Alvestrand，H.，Jordan，K.，和J.Romaguera，“当消息中存在MIME内容类型时，将消息从X.400/88降级到X.400/84的规则”，RFC 1496，1993年8月。
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, August 1993.
[7] Costanzo，A.，Robinson，D.，和R.Ullmann，“互联网消息的编码头字段”，RFC 15051993年8月。
[8] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[8] Sollins，K.和L.Masinter，“统一资源名称的功能要求”，RFC 1737，1994年12月。
[9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[9] Myers，J.和M.Rose，“Content-MD5标题字段”，RFC 18641995年10月。
[10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[10] Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[11] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[12] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[13] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[14] Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[15] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[15] Troost，R.，Dorner，S.，和K.Moore，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[16] Mogul，J.和P.Leach，“HTTP的简单命中计量和使用限制”，RFC 2227，1997年10月。
[17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[17] Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.
[18] Hansen，T.和G.Vaudreuil编辑，“消息处置通知”，RFC 3798，2004年5月。
[19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[19] Neufeld，G.和J.Baer，“将URL用作核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，1998年7月。
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[20] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[21] Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 3801，2004年6月。
[22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[22] Goland，Y.，Whitehead，E.，Faizi，A.，Carter，S.，和D.Jensen，“分布式创作的HTTP扩展——WEBDAV”，RFC25181999年2月。
[23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[23] Palme，F.，Hopmann，A.，Shelness，N.，和E.Stefferud，“聚合文档的MIME封装，如HTML（MHTML）”，RFC2557，1999年3月。
[24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[24] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[25] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[26] 《简单邮件传输协议》，RFC 28212001年4月。
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[27] Klyne，G.“为MIME内容指明媒体特征”，RFC 2912，2000年9月。
[28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[28] Chandhok，R.和G.Wenger，“列表Id：用于识别邮件列表的结构化字段和名称空间”，RFC 2919，2001年3月。
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[29] Kristol，D.和L.Montulli，“HTTP状态管理机制”，RFC 29652000年10月。
[30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[30] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[31] Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
[32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[32] Bray，T.，Paoli，J.，Sperberg McQueen，C.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C推荐XML，2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>.
[33] "Mail address for announcement of new header field submissions", Mail address: ietf-message-headers@lists.ietf.org
[33] “新标题字段提交公告的邮件地址”，邮件地址：ietf消息-headers@lists.ietf.org
[34] "Mail address for subscription to ietf-message-headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO THE MAILING LIST ITSELF)", Mail address: ietf-message-headers-request@lists.ietf.org
[34] “订阅ietf消息的邮件地址-headers@lists.ietf.org.（不要向邮件列表本身发送订阅请求）”，邮件地址：ietf邮件头-request@lists.ietf.org
[35] "Mail address for submission of new header field templates", Mail address: iana@iana.org
[35] “提交新标题字段模板的邮件地址”，邮件地址：iana@iana.org
Graham Klyne Nine by Nine
格雷厄姆·克莱恩九乘九
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Mark Nottingham BEA Systems 235 Montgomery St. Level 15 San Francisco, CA 94104 USA
马克诺丁汉BEA系统235蒙哥马利圣级15旧金山，CA 94104美国
EMail: mnot@pobox.com
EMail: mnot@pobox.com
Jeffrey C. Mogul HP Labs 1501 Page Mill Road Palo Alto, CA 94304 US
美国加利福尼亚州帕洛阿尔托米尔路1501号杰弗里·C·莫卧儿惠普实验室，邮编94304
EMail: JeffMogul@acm.org
EMail: JeffMogul@acm.org
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。