Network Working Group N. Freed
Request for Comments: 2920 Innosoft
STD: 60 September 2000
Obsoletes: 2197
Category: Standards Track
Network Working Group N. Freed
Request for Comments: 2920 Innosoft
STD: 60 September 2000
Obsoletes: 2197
Category: Standards Track
SMTP Service Extension for Command Pipelining
用于命令管道的SMTP服务扩展
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.
此备忘录定义了简单邮件传输协议（SMTP）服务的扩展，通过该扩展，服务器可以指示其在单个传输控制协议（TCP）发送操作中接受多个命令的能力范围。对多个命令使用单个TCP发送操作可以显著提高SMTP性能。
Although SMTP is widely and robustly deployed, certain extensions may nevertheless prove useful. In particular, many parts of the Internet make use of high latency network links. SMTP's intrinsic one command-one response structure is significantly penalized by high latency links, often to the point where the factors contributing to overall connection time are dominated by the time spent waiting for responses to individual commands (turnaround time).
尽管SMTP被广泛且可靠地部署，但某些扩展可能仍然很有用。特别是，互联网的许多部分使用高延迟网络链接。SMTP固有的“一个命令一个响应”结构会受到高延迟链接的严重影响，通常导致总体连接时间的因素主要取决于等待单个命令响应的时间（周转时间）。
In the best of all worlds it would be possible to simply deploy SMTP client software that makes use of command pipelining: batching up multiple commands into single TCP send operations. Unfortunately, the original SMTP specification [RFC-821] did not explicitly state that SMTP servers must support this. As a result a non-trivial number of Internet SMTP servers cannot adequately handle command pipelining. Flaws known to exist in deployed servers include:
在最好的情况下，可以简单地部署使用命令管道的SMTP客户端软件：将多个命令批处理到单个TCP发送操作中。不幸的是，原始SMTP规范[RFC-821]没有明确规定SMTP服务器必须支持此功能。因此，相当数量的Internet SMTP服务器无法充分处理命令管道。已部署服务器中已知存在的缺陷包括：
(1) Connection handoff and buffer flushes in the middle of the SMTP dialogue. Creation of server processes for incoming SMTP connections is a useful, obvious, and harmless implementation technique. However, some SMTP servers defer process forking and connection handoff until some intermediate point in the SMTP dialogue. When this is done material read from the TCP connection and kept in process buffers can be lost.
(1) 连接切换和缓冲刷新在SMTP对话的中间。为传入SMTP连接创建服务器进程是一种有用、明显且无害的实现技术。但是，某些SMTP服务器将进程分叉和连接切换延迟到SMTP对话中的某个中间点。完成此操作后，从TCP连接读取并保存在进程缓冲区中的资料可能会丢失。
(2) Flushing the TCP input buffer when an SMTP command fails. SMTP commands often fail but there is no reason to flush the TCP input buffer when this happens. Nevertheless, some SMTP servers do this.
(2) SMTP命令失败时刷新TCP输入缓冲区。SMTP命令经常失败，但发生这种情况时没有理由刷新TCP输入缓冲区。不过，有些SMTP服务器会这样做。
(3) Improper processing and promulgation of SMTP command failures. For example, some SMTP servers will refuse to accept a DATA command if the last RCPT TO command fails, paying no attention to the success or failure of prior RCPT TO command results. Other servers will accept a DATA command even when all previous RCPT TO commands have failed. Although it is possible to accommodate this sort of behavior in a client that employs command pipelining, it does complicate the construction of the client unnecessarily.
(3) SMTP命令失败的处理和发布不正确。例如，如果最后一个RCPT-to命令失败，某些SMTP服务器将拒绝接受数据命令，而不注意之前RCPT-to命令结果的成功或失败。即使以前的所有RCPT TO命令都失败，其他服务器也会接受数据命令。虽然可以在采用命令管道的客户端中容纳这种行为，但它确实会不必要地使客户端的构造复杂化。
This memo uses the mechanism described in [RFC-1869] to define an extension to the SMTP service whereby an SMTP server can declare that it is capable of handling pipelined commands. The SMTP client can then check for this declaration and use pipelining only when the server declares itself capable of handling it.
此备忘录使用[RFC-1869]中描述的机制来定义SMTP服务的扩展，SMTP服务器可以通过该扩展声明它能够处理流水线命令。然后，SMTP客户端可以检查此声明，并且仅当服务器声明自己能够处理此声明时才使用管道。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
本文档偶尔使用大写字母表示的术语。当术语“必须”、“不得”、“应该”、“不应该”和“可能”出现大写时，它们用于表示本规范的特殊要求。[RFC-1123]中对术语“必须”、“应该”和“可能”的含义进行了讨论；术语“不得”和“不应”是此用法的逻辑扩展。
The Command Pipelining extension is defined as follows:
命令管道扩展的定义如下：
(1) the name of the SMTP service extension is Pipelining;
(1) SMTP服务扩展名为管道；
(2) the EHLO keyword value associated with the extension is PIPELINING;
(2) 与扩展关联的EHLO关键字值是pipeline；
(3) no parameter is used with the PIPELINING EHLO keyword;
(3) 没有参数与Pipelineing EHLO关键字一起使用；
(4) no additional parameters are added to either the MAIL FROM or RCPT TO commands.
(4) 没有向MAIL FROM或RCPT to命令添加其他参数。
(5) no additional SMTP verbs are defined by this extension; and,
(5) 此扩展未定义其他SMTP谓词；和
(6) the next section specifies how support for the extension affects the behavior of a server and client SMTP.
(6) 下一节指定对扩展的支持如何影响服务器和客户端SMTP的行为。
When a client SMTP wishes to employ command pipelining, it first issues the EHLO command to the server SMTP. If the server SMTP responds with code 250 to the EHLO command, and the response includes the EHLO keyword value PIPELINING, then the server SMTP has indicated that it can accommodate SMTP command pipelining.
当客户端SMTP希望采用命令管道时，它首先向服务器SMTP发出EHLO命令。如果服务器SMTP以代码250响应EHLO命令，并且响应包含EHLO关键字值管道，则服务器SMTP已指示它可以容纳SMTP命令管道。
Once the client SMTP has confirmed that support exists for the pipelining extension, the client SMTP may then elect to transmit groups of SMTP commands in batches without waiting for a response to each individual command. In particular, the commands RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere in a pipelined command group. The EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP commands can only appear as the last command in a group since their success or failure produces a change of state which the client SMTP must accommodate. (NOOP is included in this group so it can be used as a synchronization point.)
一旦客户端SMTP确认存在对管道扩展的支持，客户端SMTP就可以选择成批传输SMTP命令组，而无需等待对每个命令的响应。特别是，命令RSET、MAIL-FROM、SEND-FROM、SOML-FROM、SAML-FROM和RCPT-TO都可以出现在流水线命令组中的任何位置。EHLO、DATA、VRFY、EXPN、TURN、QUIT和NOOP命令只能作为组中的最后一个命令出现，因为它们的成功或失败会导致客户端SMTP必须适应的状态更改。（此组中包括NOOP，因此可以将其用作同步点。）
Additional commands added by other SMTP extensions may only appear as the last command in a group unless otherwise specified by the extensions that define the commands.
由其他SMTP扩展添加的其他命令只能作为组中的最后一个命令显示，除非定义这些命令的扩展另有指定。
The actual transfer of message content is explicitly allowed to be the first "command" in a group. That is, a RSET/MAIL FROM sequence used to initiate a new message transaction can be placed in the same group as the final transfer of the headers and body of the previous message.
明确允许将消息内容的实际传输作为组中的第一个“命令”。也就是说，用于启动新消息事务的RSET/MAIL FROM序列可以与前一消息的头和正文的最终传输放在同一组中。
Client SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group. For example, if none of the RCPT TO recipient addresses were accepted the client must then check the response to the DATA command -- the client cannot assume that the DATA command will be rejected just because none of the RCPT TO commands worked. If the DATA command was properly rejected the client SMTP can just issue RSET, but if the DATA command
采用管道的客户端SMTP实现必须检查与组中每个命令相关联的所有状态。例如，如果没有接受任何RCPT到收件人的地址，那么客户端必须检查对数据命令的响应——客户端不能认为数据命令将被拒绝，因为RCPT到收件人的任何命令都不起作用。如果数据命令被正确拒绝，客户端SMTP可以只发出RSET，但是如果数据命令
was accepted the client SMTP should send a single dot.
已接受客户端SMTP应发送单个点。
Command statuses MUST be coordinated with responses by counting each separate response and correlating that count with the number of commands known to have been issued. Multiline responses MUST be supported. Matching on the basis of either the error code value or associated text is expressly forbidden.
命令状态必须与响应相协调，方法是对每个单独的响应进行计数，并将该计数与已知已发出的命令数相关联。必须支持多行响应。明确禁止基于错误代码值或相关文本进行匹配。
Client SMTP implementations MAY elect to operate in a nonblocking fashion, processing server responses immediately upon receipt, even if there is still data pending transmission from the client's previous TCP send operation. If nonblocking operation is not supported, however, client SMTP implementations MUST also check the TCP window size and make sure that each group of commands fits entirely within the window. The window size is usually, but not always, 4K octets. Failure to perform this check can lead to deadlock conditions.
客户端SMTP实现可能选择以非阻塞方式运行，在收到服务器响应后立即处理，即使客户端以前的TCP发送操作仍有数据等待传输。但是，如果不支持非阻塞操作，客户端SMTP实现还必须检查TCP窗口大小，并确保每组命令完全适合该窗口。窗口大小通常为4K八位字节，但并不总是如此。未能执行此检查可能导致死锁情况。
Clients MUST NOT confuse responses to multiple commands with multiline responses. Each command requires one or more lines of response, the last line not containing a dash between the response code and the response string.
客户端不得将对多个命令的响应与多行响应混淆。每个命令都需要一行或多行响应，最后一行在响应代码和响应字符串之间不包含破折号。
A server SMTP implementation that offers the pipelining extension:
提供管道扩展的服务器SMTP实现：
(1) MUST respond to commands in the order they are received from the client.
(1) 必须按照从客户端接收命令的顺序响应命令。
(2) SHOULD elect to store responses to grouped RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO commands in an internal buffer so they can sent as a unit.
(2) 应选择将对分组的RSET、MAIL FROM、SEND FROM、SOML FROM、SAML FROM和RCPT to命令的响应存储在内部缓冲区中，以便它们可以作为一个单元发送。
(3) SHOULD issue a positive response to the DATA command if and only if one or more valid RCPT TO addresses have been previously received.
(3) 当且仅当先前已收到一个或多个有效的RCPT to地址时，应向数据命令发出肯定响应。
(4) MUST NOT, after issuing a positive response to a DATA command with no valid recipients and subsequently receiving an empty message, send any message whatsoever to anybody.
(4) 在对没有有效收件人的数据命令发出肯定响应并随后收到空消息后，不得向任何人发送任何消息。
(5) MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP.
(5) 不得缓冲对EHLO、DATA、VRFY、EXPN、TURN、QUIT和NOOP的响应。
(6) MUST NOT buffer responses to unrecognized commands.
(6) 不能缓冲对无法识别的命令的响应。
(7) MUST send all pending responses immediately whenever the local TCP input buffer is emptied.
(7) 每当本地TCP输入缓冲区清空时，必须立即发送所有挂起的响应。
(8) MUST NOT make assumptions about commands that are yet to be received.
(8) 不得对尚未收到的命令进行假设。
(9) MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
(9) 在任何情况下，不得刷新或以其他方式丢失TCP输入缓冲区的内容。
(10) SHOULD issue response text that indicates, either implicitly or explicitly, what command the response matches.
（10） 应该发出响应文本，隐式或显式地指示响应匹配的命令。
The overriding intent of these server requirements is to make it as easy as possible for servers to conform to these pipelining extensions.
这些服务器要求的首要目的是使服务器尽可能容易地符合这些管道扩展。
Consider the following SMTP dialogue that does not use pipelining:
考虑以下不使用流水线的SMTP对话：
S: <wait for open connection>
C: <open connection to server>
S: 220 Innosoft.com SMTP service ready
C: HELO dbc.mtview.ca.us
S: 250 Innosoft.com
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
S: 250 sender <mrose@dbc.mtview.ca.us> OK
C: RCPT TO:<ned@innosoft.com>
S: 250 recipient <ned@innosoft.com> OK
C: RCPT TO:<dan@innosoft.com>
S: 250 recipient <dan@innosoft.com> OK
C: RCPT TO:<kvc@innosoft.com>
S: 250 recipient <kvc@innosoft.com> OK
C: DATA
S: 354 enter mail, end with line containing only "."
...
C: .
S: 250 message sent
C: QUIT
S: 221 goodbye
S: <wait for open connection>
C: <open connection to server>
S: 220 Innosoft.com SMTP service ready
C: HELO dbc.mtview.ca.us
S: 250 Innosoft.com
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
S: 250 sender <mrose@dbc.mtview.ca.us> OK
C: RCPT TO:<ned@innosoft.com>
S: 250 recipient <ned@innosoft.com> OK
C: RCPT TO:<dan@innosoft.com>
S: 250 recipient <dan@innosoft.com> OK
C: RCPT TO:<kvc@innosoft.com>
S: 250 recipient <kvc@innosoft.com> OK
C: DATA
S: 354 enter mail, end with line containing only "."
...
C: .
S: 250 message sent
C: QUIT
S: 221 goodbye
The client waits for a server response a total of 9 times in this simple example. But if pipelining is employed the following dialogue is possible:
在这个简单的示例中，客户端总共等待服务器响应9次。但如果采用管道，则可以进行以下对话：
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<ned@innosoft.com>
C: RCPT TO:<dan@innosoft.com>
C: RCPT TO:<kvc@innosoft.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 250 recipient <ned@innosoft.com> OK
S: 250 recipient <dan@innosoft.com> OK
S: 250 recipient <kvc@innosoft.com> OK
S: 354 enter mail, end with line containing only "."
...
C: .
C: QUIT
S: 250 message sent
S: 221 goodbye
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<ned@innosoft.com>
C: RCPT TO:<dan@innosoft.com>
C: RCPT TO:<kvc@innosoft.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 250 recipient <ned@innosoft.com> OK
S: 250 recipient <dan@innosoft.com> OK
S: 250 recipient <kvc@innosoft.com> OK
S: 354 enter mail, end with line containing only "."
...
C: .
C: QUIT
S: 250 message sent
S: 221 goodbye
The total number of turnarounds has been reduced from 9 to 4.
周转次数已从9次减少到4次。
The next example illustrates one possible form of behavior when pipelining is used and all recipients are rejected:
下一个示例说明了当使用管道且拒绝所有收件人时的一种可能的行为形式：
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<nsb@thumper.bellcore.com>
C: RCPT TO:<galvin@tis.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
S: 550 remote mail to <galvin@tis.com> not allowed
S: 554 no valid recipients given
C: QUIT
S: 221 goodbye
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<nsb@thumper.bellcore.com>
C: RCPT TO:<galvin@tis.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
S: 550 remote mail to <galvin@tis.com> not allowed
S: 554 no valid recipients given
C: QUIT
S: 221 goodbye
The client SMTP waits for the server 4 times here as well. If the server SMTP does not check for at least one valid recipient prior to accepting the DATA command, the following dialogue would result:
客户端SMTP在此也会等待服务器4次。如果服务器SMTP在接受数据命令之前未检查至少一个有效的收件人，则会出现以下对话框：
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<nsb@thumper.bellcore.com>
C: RCPT TO:<galvin@tis.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
S: 550 remote mail to <galvin@tis.com> not allowed
S: 354 enter mail, end with line containing only "."
C: .
C: QUIT
S: 554 no valid recipients
S: 221 goodbye
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<mrose@dbc.mtview.ca.us>
C: RCPT TO:<nsb@thumper.bellcore.com>
C: RCPT TO:<galvin@tis.com>
C: DATA
S: 250 sender <mrose@dbc.mtview.ca.us> OK
S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
S: 550 remote mail to <galvin@tis.com> not allowed
S: 354 enter mail, end with line containing only "."
C: .
C: QUIT
S: 554 no valid recipients
S: 221 goodbye
This RFC does not discuss security issues and is not believed to raise any security issues not endemic in electronic mail and present in fully conforming implementations of [RFC-821].
本RFC不讨论安全问题，也不认为会提出任何安全问题，这些问题不是电子邮件中特有的，也不会出现在[RFC-821]的完全一致性实施中。
This document is based on the SMTP service extension model presented in RFC 1425. Marshall Rose's description of SMTP command pipelining in his book "The Internet Message" also served as a source of inspiration for this extension.
本文档基于RFC 1425中介绍的SMTP服务扩展模型。Marshall Rose在其著作《Internet消息》中对SMTP命令管道的描述也为该扩展提供了灵感。
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC-821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC-1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October, 1989.
[RFC-1123]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC-1854] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
[RFC-1854]弗里德，N.，“用于命令管道的SMTP服务扩展”，RFC 18541995年10月。
[RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-1869]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[RFC-2197] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[RFC-2197]弗里德，N.，“用于命令管道的SMTP服务扩展”，RFC 2197，1997年9月。
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Innosoft International，Inc.美国加利福尼亚州西科维纳湖大道1050号，邮编：91790
Phone: +1 626 919 3600
Fax: +1 626 919 361
EMail: ned.freed@innosoft.com
Phone: +1 626 919 3600
Fax: +1 626 919 361
EMail: ned.freed@innosoft.com
This document is a product of work done by the Internet Engineering Task Force Working Group on Messaging Extensions, Alan Cargille, chair.
本文档是Internet工程任务组消息传递扩展工作组主席Alan Cargille所做工作的成果。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。