Network Working Group R. Chandhok
Request for Comments: 2919 G. Wenger
Category: Standards Track QUALCOMM, Inc.
March 2001
Network Working Group R. Chandhok
Request for Comments: 2919 G. Wenger
Category: Standards Track QUALCOMM, Inc.
March 2001
List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
列表Id：用于标识邮件列表的结构化字段和命名空间
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time.
处理电子邮件列表消息的软件（服务器和用户代理）需要可靠地识别属于特定邮件列表的消息。随着列表管理头的出现，为邮件列表提供唯一标识符变得更加重要，而不管在任何给定时间充当列表处理器的特定主机是什么。
The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use.
列表Id头为这样的标识符提供了一个标准位置。此外，还描述了基于完全限定域名的列表标识符的名称空间。这个名称空间旨在保证需要它的列表所有者的唯一性，同时允许一个不太严格的名称空间供实验和个人使用。
By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available.
通过包含列表Id字段，列表服务器可以使邮件客户端更容易为用户提供执行列表功能的自动化工具。列表标识符可以作为一个键，使许多自动化处理任务变得更容易，从而更广泛地可用。
Internet mailing lists have evolved into fairly sophisticated forums for group communication and collaboration; however, corresponding changes in the underlying infrastructure have lagged behind. Recent
互联网邮件列表已经演变成相当复杂的群体交流和协作论坛；然而，底层基础设施的相应变化却滞后了。最近的
proposals like [RFC2369] have expanded the functionality that the MUA can provide by providing more information in each message sent by the mailing list distribution software.
[RFC2369]等提案通过在邮件列表分发软件发送的每条邮件中提供更多信息，扩展了MUA可以提供的功能。
Actually implementing such functionality in the MUA depends on the ability to accurately identify messages as belonging to a particular mailing list. The problem then becomes what attribute or property to use to identify a mailing list. The most likely candidate is the submission address of the mailing list itself. Unfortunately, when the list server host, the list processing software, or the submission policy of the list changes the submission address itself can change. This causes great difficulty for automated processing and filtering.
在MUA中实际实现此类功能取决于准确识别属于特定邮件列表的邮件的能力。然后问题就变成了使用什么属性或属性来标识邮件列表。最有可能的候选地址是邮件列表本身的提交地址。不幸的是，当列表服务器主机、列表处理软件或列表的提交策略更改时，提交地址本身可能会更改。这给自动化处理和过滤带来了极大的困难。
In order to further automate (and make more accurate) the processing a software agent can do, there needs to be some unique identifier to use as an identifier for the mailing list. This identifier can be simply used for string matching in a filter, or it can be used in more sophisticated systems to uniquely identify messages as belonging to a particular mailing list independent of the particular host delivering the actual messages. This identifier can also act as a key into a database of mailing lists.
为了进一步自动化（并使其更准确）软件代理可以执行的处理，需要有一些唯一的标识符用作邮件列表的标识符。该标识符可以简单地用于过滤器中的字符串匹配，也可以在更复杂的系统中使用，以唯一地标识属于特定邮件列表的邮件，而不依赖于传递实际邮件的特定主机。该标识符还可以作为邮件列表数据库的密钥。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
The list identifier will, in most cases, appear like a host name in a domain of the list owner. In other words, the domain name system is used to delegate namespace authority for list identifiers just as it has been used to distribute that authority for other internet resources.
在大多数情况下，列表标识符将在列表所有者的域中显示为主机名。换句话说，域名系统用于为列表标识符委派名称空间权限，就像它用于为其他internet资源分配该权限一样。
Using the domain name system as a basis for the list identifier namespace is intended to leverage an existing authority structure into a new area of application. By using the domain name system to delegate list identifier namespace authority, it becomes instantly clear who has the right to create a particular list identifier, and separates the list identifier from any particular delivery host or mechanism. Only the rights-holder of a domain or subdomain has the authority to create list identifiers in the namespace of that domain. For example, only the rights-holder to the "acm.org" domain has the authority to create list identifiers in "acm.org" domain.
使用域名系统作为列表标识符命名空间的基础旨在利用现有的权限结构进入新的应用领域。通过使用域名系统来委托列表标识符命名空间权限，可以立即明确谁有权创建特定的列表标识符，并将列表标识符与任何特定的交付主机或机制分离。只有域或子域的权限持有者才有权在该域的命名空间中创建列表标识符。例如，只有“acm.org”域的权利持有人才有权在“acm.org”域中创建列表标识符。
While it is perfectly acceptable for a list identifier to be completely independent of the domain name of the host machine servicing the mailing list, the owner of a mailing list MUST NOT generate list identifiers in any domain namespace for which they do not have authority. For example, a mailing list hosting service may choose to assign list identifiers in their own domain based namespace, or they may allow their clients (the list owners) to provide list identifiers in a namespace for which the owner has authority.
虽然列表标识符完全独立于为邮件列表提供服务的主机的域名是完全可以接受的，但邮件列表的所有者不得在其没有权限的任何域命名空间中生成列表标识符。例如，邮件列表宿主服务可以选择在其自己的基于域的名称空间中分配列表标识符，或者它们可以允许其客户机（列表所有者）在所有者具有权限的名称空间中提供列表标识符。
If the owner of the list does not have the authority to create a list identifier in a domain-based namespace, they may create unmanaged list identifiers in the special unmanaged domain "localhost". This would apply to personal users, or users unable to afford domain name registration fees.
如果列表的所有者无权在基于域的命名空间中创建列表标识符，则他们可以在特殊的非托管域“localhost”中创建非托管列表标识符。这将适用于个人用户，或无力支付域名注册费的用户。
The syntax for a list identifier in ABNF [RFC2234] follows:
ABNF[RFC2234]中列表标识符的语法如下：
list-id = list-label "." list-id-namespace
列表id=列表标签“.”列表id命名空间
list-label = dot-atom-text
list-label = dot-atom-text
list-id-namespace = domain-name / unmanaged-list-id-namespace
列表id命名空间=域名/非托管列表id命名空间
unmanaged-list-id-namespace = "localhost"
unmanaged-list-id-namespace = "localhost"
domain-name = dot-atom-text
domain-name = dot-atom-text
Where:
哪里：
dot-atom-text is defined in [DRUMS]
点原子文本在[鼓]中定义
"localhost" is a reserved domain name is defined in [RFC2606]
“localhost”是[RFC2606]中定义的保留域名
In addition, a list identifier (list-id) MUST NOT be longer than 255 octets in length, for future compatibility. It should be noted that "localhost" is not valid for the domain-name rule.
此外，为了将来的兼容性，列表标识符（列表id）的长度不得超过255个八位字节。应该注意，“localhost”对于域名规则无效。
This document presents a header field which will provide an identifier for an e-mail distribution list. This header SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to this particular distinct list. There MUST be no more than one of each field present in any given message.
此文档提供一个标题字段，该字段将为电子邮件通讯组列表提供标识符。此标题应包含在列表分发的所有消息（包括对单个用户的命令响应）中，以及该消息明确适用于此特殊列表的其他消息中。在任何给定消息中，每个字段不得超过一个。
This field MUST only be generated by mailing list software, not end users.
此字段只能由邮件列表软件生成，不能由最终用户生成。
The contents of the List-Id header mostly consist of angle-bracket ('<', '>') enclosed identifier, with internal whitespace being ignored. MTAs MUST NOT insert whitespace within the brackets, but client applications should treat any such whitespace, that might be inserted by poorly behaved MTAs, as characters to ignore.
列表Id标题的内容主要由尖括号（“<”、“>”）括起的标识符组成，内部空白被忽略。MTA不得在括号内插入空格，但客户端应用程序应将任何此类空格（可能由行为不良的MTA插入）视为可忽略的字符。
The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822].
列表标题字段受[RFC822]中所述的邮件标题编码和字符限制的约束。
The List-Id header MAY optionally include a description by including it as a "phrase" [DRUMS] before the angle-bracketed list identifier. The MUA MAY choose to use this description in its user interface; however, any MUA that intends to make use of the description should be prepared to properly parse and decode any encoded strings or other legal phrase components. For many MUAs the parsing of the List-Id header will simply consist of extracting the list identifier from between the delimiting angle brackets.
列表Id头可以选择性地包括描述，方法是将其作为“短语”[DRUMS]包含在带括号的角度列表标识符之前。MUA可以选择在其用户界面中使用该描述；然而，任何打算使用描述的MUA都应该准备好正确解析和解码任何编码字符串或其他合法短语组件。对于许多MUA，列表Id头的解析将只包括从定界尖括号之间提取列表标识符。
The syntax of the List-Id header follows:
列表Id标题的语法如下所示：
list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF
list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF
where phrase and CRLF are as defined in [DRUMS]. Unlike most headers in [RFC822], the List-Id header does not allow free insertion of whitespace and comments around tokens. Any descriptive text must be presented in the optional phrase component of the header.
其中短语和CRLF的定义见[鼓]。与[RFC822]中的大多数头不同，列表Id头不允许在标记周围自由插入空格和注释。任何描述性文本必须显示在标题的可选短语组件中。
Examples:
示例：
List-Id: List Header Mailing List <list-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List"
<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
List-Id: List Header Mailing List <list-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List"
<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
Although the list identifier MAY be changed by the mailing list administrator this is not desirable. (Note that there is no disadvantage to changing the description portion of the List-Id header.) A MUA may not recognize the change to the list identifier because the MUA SHOULD treat a different list identifier as a different list. As such the mailing list administrator SHOULD avoid changing the list identifier even when the host serving the list
虽然邮件列表管理员可以更改列表标识符，但这是不可取的。（注意，更改列表Id头的描述部分没有缺点。）MUA可能无法识别对列表标识符的更改，因为MUA应将不同的列表标识符视为不同的列表。因此，邮件列表管理员应避免更改列表标识符，即使在主机为列表提供服务时也是如此
changes. On the other hand, transitioning from an informal unmanaged-list-id-namespace to a domain namespace is an acceptable reason to change the list identifier. Also if the focus of the list changes sufficiently the administrator may wish to retire the previous list and its associated identifier to start a new list reflecting the new focus.
变化。另一方面，从非正式的非托管列表id命名空间转换到域命名空间是更改列表标识符的一个可接受的理由。此外，如果列表的焦点发生了充分的变化，管理员可能希望取消以前的列表及其相关标识符，以启动反映新焦点的新列表。
This proposal seeks to leverage the existing administrative process already in place for domain name allocation. In particular, we exploit the fact that domain name ownership creates a namespace that by definition can be used to create unique identifiers within the domain.
本提案旨在利用现有的域名分配管理流程。特别是，我们利用了这样一个事实：域名所有权创建了一个名称空间，根据定义，该名称空间可用于在域内创建唯一标识符。
In addition, there must be a mechanism for identification of mailing lists that are administrated by some entity without administrative access to a domain. In this case, general heuristics can be given to reduce the chance of collision, but it cannot be guaranteed. If a list owner requires a guarantee, they are free to register a domain name under their control.
此外，必须有一种识别邮件列表的机制，这些邮件列表由某个实体管理，没有对域的管理访问权限。在这种情况下，可以给出一般的启发式方法来减少碰撞的机会，但不能保证。如果列表所有者需要担保，他们可以自由注册其控制下的域名。
It is suggested, but not required, that list identifiers be created under a subdomain of "list-id" within any given domain. This can help to reduce internal conflicts between the administrators of the subdomains of large organizations. For example, list identifiers at "within.com" are generated in the subdomain of "list-id.within.com".
建议（但不是必需）在任何给定域内的“列表id”子域下创建列表标识符。这有助于减少大型组织子域管理员之间的内部冲突。例如，“within.com”上的列表标识符是在“list-id.within.com”的子域中生成的。
List-IDs not ending with ".localhost" MUST be globally unique in reference to all other mailing lists.
列表ID不以“.localhost”结尾，在引用所有其他邮件列表时必须是全局唯一的。
List owners wishing to use the special "localhost" namespace for their list identifier SHOULD use the month and year (in the form MMYYYY) that they create the list identifier as a "subdomain" of the "localhost" namespace. In addition, some portion of the list identifier MUST be a randomly generated string. List owners generating such identifiers should refer to [MSGID] for further suggestions on generating a unique identifier, and [RFC1750] for suggestions on generating random numbers. In particular, list identifiers that have a random component SHOULD contain a hex encoding of 128 bits of randomness (resulting in 32 hex characters) as part of the list identifier
希望为其列表标识符使用特殊“localhost”命名空间的列表所有者应使用创建列表标识符的月份和年份（格式为mmyyy）作为“localhost”命名空间的“子域”。此外，列表标识符的某些部分必须是随机生成的字符串。生成此类标识符的列表所有者应参考[MSGID]了解关于生成唯一标识符的进一步建议，并参考[RFC1750]了解关于生成随机数的建议。特别是，具有随机分量的列表标识符应包含128位随机性的十六进制编码（产生32个十六进制字符），作为列表标识符的一部分
Thus, list identifiers such as
<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
<da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
guidelines, while <lenas-jokes.021999.localhost> and
Thus, list identifiers such as
<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
<da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
guidelines, while <lenas-jokes.021999.localhost> and
<mylist.localhost> do not. A particular list owner with several lists MAY choose to use the same random number subdomain when generating list identifiers for each of the lists.
<mylist.localhost>不要。具有多个列表的特定列表所有者在为每个列表生成列表标识符时可以选择使用相同的随机数子域。
List-IDs ending with ".localhost" are not guaranteed to be globally unique.
以“.localhost”结尾的列表ID不保证全局唯一。
There is only one operation defined for list identifiers, that of case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE [RFC822]). The sole use of a list identifier is to identify a mailing list, and the sole use of the List-Id header is to mark a particular message as belonging to that list. The comparison operation MUST ignore any part of the List-Id header outside of the angle brackets, the MUA MAY choose to inform the user if the descriptive name of a mailing list changes.
仅为列表标识符定义了一个操作，即不区分大小写的相等操作（参见第3.4.7节，大小写独立[RFC822]）。列表标识符的唯一用途是标识邮件列表，列表Id头的唯一用途是将特定邮件标记为属于该列表。比较操作必须忽略尖括号外列表Id标题的任何部分，MUA可以选择通知用户邮件列表的描述性名称是否发生变化。
A list that is a sublist for another list in a nested mailing list hierarchy MUST NOT modify the List-Id header field; however, this will only be possible when the nested mailing list is aware of the relationship between it and its "parent" mailing lists. If a mailing list processor encounters a List-Id header field from any unexpected source it SHOULD NOT pass it through to the list. This implies that mailing list processors may have to be updated to properly support List-Ids for nested lists.
作为嵌套邮件列表层次结构中另一个列表的子列表的列表不得修改列表Id标题字段；但是，只有当嵌套邮件列表知道它与其“父”邮件列表之间的关系时，这才可能实现。如果邮件列表处理程序遇到来自任何意外源的列表Id头字段，则不应将其传递给列表。这意味着可能必须更新邮件列表处理器，以正确支持嵌套列表的列表ID。
There are very few new security concerns generated with this proposal. Message headers are an existing standard, designed to easily accommodate new types. There may be concern with headers being forged, but this problem is inherent in Internet e-mail, not specific to the header described in this document. Further, the implications are relatively harmless.
这项提议很少产生新的安全问题。消息头是一种现有的标准，旨在方便地容纳新类型。可能存在伪造邮件头的问题，但这是Internet电子邮件中固有的问题，而不是本文档中描述的邮件头特有的问题。此外，这些影响相对无害。
As mentioned above, mail list processors SHOULD NOT allow any user-originated List-Id fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.
如上所述，邮件列表处理者不应允许任何源于用户的列表Id字段传递到其列表中，以免混淆用户并可能造成安全问题。
On the client side, a forged list identifier may break automated processing. The list identifier (in its current form) SHOULD NOT be used as an indication of the authenticity of the message.
在客户端，伪造的列表标识符可能会中断自动处理。列表标识符（当前形式）不应用作消息真实性的指示。
The numerous participants of the List-Header [LISTHEADER] and ListMom-Talk [LISTMOM] mailing lists contributed much to the formation and structure of this document.
列表标题[LISTHEADER]和ListMom Talk[ListMom]邮件列表的众多参与者为本文件的形成和结构做出了巨大贡献。
Grant Neufeld <grant@acm.org> focused much of the early discussion, and thus was essential in the creation of this document.
格兰特·纽菲尔德<grant@acm.org>集中了早期讨论的大部分内容，因此对本文件的编制至关重要。
References
工具书类
[LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com
<http://www.nisto.com/listspec/mail/>
<http://www.nisto.com/listspec/>
[LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com
<http://www.nisto.com/listspec/mail/>
<http://www.nisto.com/listspec/>
[LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
<http://cgi.skyweyr.com/ListMom.Home>
[LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
<http://cgi.skyweyr.com/ListMom.Home>
[MSGID] J. Zawinski, M. Curtin, "Recommendations for generating Message IDs", Work in Progress.
[MSGID]J.Zawinski，M.Curtin，“生成消息ID的建议”，正在进行中。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，RFC 822，1982年8月。
[RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，Crocker S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]克罗克，D.和P.奥威尔。“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC2369] 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.
[RFC2369]Neufeld G.和J.Baer，“使用URL作为核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，1998年7月。
[RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]东湖，第三大道和S.帕尼茨。“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC2822] Resnick, P., Editor, "Internet Message Format Standard", STD 11, RFC 2822, March 2001.
[RFC2822]Resnick，P.，编辑，“互联网消息格式标准”，STD 11，RFC 2822，2001年3月。
Authors' Addresses
作者地址
Ravinder Chandhok QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA
Ravinder Chandhok高通公司，美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
EMail: chandhok@qualcomm.com
EMail: chandhok@qualcomm.com
Geoffrey Wenger QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA
杰弗里·温格高通公司，美国加利福尼亚州圣地亚哥莫尔豪斯大道5775号，邮编92121
EMail: gwenger@qualcomm.com
EMail: gwenger@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。