Network Working Group N. Freed
Request for Comments: 2442 D. Newman
Category: Informational Innosoft
J. Belissent
Sun Microsystems
M. Hoy
Mainbrace
November 1998
Network Working Group N. Freed
Request for Comments: 2442 D. Newman
Category: Informational Innosoft
J. Belissent
Sun Microsystems
M. Hoy
Mainbrace
November 1998
The Batch SMTP Media Type
批处理SMTP媒体类型
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document defines a MIME content type suitable for tunneling an ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g., [RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such as NOTARY [RFC-1891] over unextended SMTP transport infrastructure. Enabling the transfer of multiple separate messages in a single transactional unit.
本文档定义了一种MIME内容类型，适用于通过任何支持MIME的传输对ESMTP[RFC-821，RFC-1869]事务进行隧道传输。此类型可用于多种目的，包括：扩展基于MIME的端到端安全服务（例如，[RFC-1847]），以覆盖消息信封信息和消息内容。允许在未扩展的SMTP传输基础设施上使用特定的SMTP扩展，如公证人[RFC-1891]。支持在单个事务单元中传输多个单独的消息。
Requirements Notation
需求符号
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 Application/batch-SMTP Content Type
应用程序/批处理SMTP内容类型
The "application/batch-SMTP" MIME content type is a container for the client side of an SMTP or ESMTP transaction. In keeping with traditional SMTP, the contents are line oriented and CRLF line terminators MUST be used.
“应用程序/批处理SMTP”MIME内容类型是SMTP或ESMTP事务客户端的容器。与传统SMTP保持一致，内容是面向行的，必须使用CRLF行终止符。
The "application/batch-SMTP" type is defined as follows:
“应用程序/批处理SMTP”类型定义如下：
Media type name: application Media subtype name: batch-SMTP Required parameters: none Optional parameters: required-extensions Encoding considerations: 8bit material may appear, so quoted-printable or base64 encoding may be necessary on transports that do not support 8bit. While the content of this type is line-oriented and uses conventional CR/LF terminators, lines longer than 7bit and 8bit encodings allow (998 octets) may appear, hence quoted-printable or base64 encoding may be necessary even in conjunction with 8bit transports. Security considerations: Discussed in the Security Considerations Section.
媒体类型名称：应用程序媒体子类型名称：批处理SMTP必需参数：无可选参数：必需的扩展编码注意事项：可能会出现8位材料，因此在不支持8位的传输上可能需要引用的可打印或base64编码。虽然这种类型的内容是面向行的，并使用传统的CR/LF终止符，但可能会出现长度超过7位和8位编码允许的行（998个八位字节），因此，即使与8位传输结合使用，也可能需要引用的可打印或base64编码。安全注意事项：在安全注意事项部分讨论。
How application/batch-SMTP is used
如何使用应用程序/批处理SMTP
The following diagram illustrates how the application/batch-SMTP type is intended to be used:
下图说明了如何使用应用程序/批处理SMTP类型：
application/batch-SMTP object
+----------------+
| |
+-----------+ v +----------+ v +-----------+
| batch | | MIME- | | batch |
=> | SMTP | => | capable | => | SMTP | =>
| generator | |transport | | processor |
^ +-----------+ +----------+ +-----------+ ^
| |
+-- conventional SMTP/RFC822 message transaction --+
application/batch-SMTP object
+----------------+
| |
+-----------+ v +----------+ v +-----------+
| batch | | MIME- | | batch |
=> | SMTP | => | capable | => | SMTP | =>
| generator | |transport | | processor |
^ +-----------+ +----------+ +-----------+ ^
| |
+-- conventional SMTP/RFC822 message transaction --+
A conventional SMTP message transaction is converted into an application/batch-SMTP object by the batch SMTP generator. This object is then carried over some type of MIME-capable transport. Once the destination is reached the object is presented to a batch SMTP processor, which converts the application/batch-SMTP object back into a conventional SMTP message transaction.
批处理SMTP生成器将常规SMTP邮件事务转换为应用程序/批处理SMTP对象。然后，该对象将通过某种类型的支持MIME的传输进行传输。到达目的地后，对象将呈现给批处理SMTP处理器，该处理器将应用程序/批处理SMTP对象转换回常规SMTP消息事务。
Generation of application/batch-SMTP material
生成应用程序/批SMTP材料
Application/batch-SMTP material is generated by a specially modified SMTP client operating without a corresponding SMTP server. The client simply assumes a successful response to all commands it issues. The resulting content then consists of the collected output from the SMTP client.
应用程序/批处理SMTP材料由经过特殊修改的SMTP客户端生成，该客户端在没有相应SMTP服务器的情况下运行。客户机只是假设对它发出的所有命令都有成功的响应。然后，生成的内容由从SMTP客户端收集的输出组成。
Honoring SMTP restrictions
遵守SMTP限制
Most batch SMTP processors will be constructed by modifying and extending existing SMTP servers. As such, all of the restrictions on SMTP constructs imposed by RFC 821, RFC 1123, and RFC 1869 MUST be observed. In particular, restrictions on command and data line lengths, number of recipients, and so on still exist and apply to batch SMTP.
大多数批处理SMTP处理器将通过修改和扩展现有SMTP服务器来构建。因此，必须遵守RFC 821、RFC 1123和RFC 1869对SMTP构造施加的所有限制。特别是，对命令行和数据行长度、收件人数量等的限制仍然存在，并适用于批处理SMTP。
Use of SMTP Extensions
SMTP扩展的使用
Since no SMTP server is present the client must be prepared to make certain assumptions about which SMTP extensions can be used. The generator MAY assume that ESMTP [RFC-1869] facilities are available, that is, it is acceptable to use the EHLO command and additional parameters on MAIL FROM and RCPT TO. If EHLO is used MAY assume that the 8bitMIME [RFC-1652], SIZE [RFC-1870], and NOTARY [RFC-1891] extensions are available. In particular, NOTARY SHOULD be used. MAY create private bilateral agreements which specify the availability of additional SMTP extensions. Additional SMTP extensions MUST NOT be used in the absence of such an agreement, and, perhaps more importantly, a conformant generation of application/batch-SMTP objects MUST be able to produce objects restricted to use of the extensions listed above.
由于不存在SMTP服务器，客户端必须准备好对可以使用哪些SMTP扩展进行某些假设。发电机可能假设ESMTP[RFC-1869]设施可用，也就是说，可以使用EHLO命令和来自和RCPT的邮件上的附加参数。如果使用EHLO，则可以假设8bitMIME[RFC-1652]、大小[RFC-1870]和公证[RFC-1891]扩展可用。特别是，应使用公证人。可以创建私人双边协议，指定附加SMTP扩展的可用性。在没有此类协议的情况下，不得使用其他SMTP扩展，可能更重要的是，一致生成的应用程序/批处理SMTP对象必须能够生成仅限于使用上述扩展的对象。
The "required-extensions" content type parameter MAY be used to communicate a list of the extensions actually used, specified as a comma-separated list of EHLO responses. If absent it defaults to the list "8bitMIME,SIZE,NOTARY". Any use by private bilateral agreement of additional or different extensions MUST be noted in the "required-extensions" parameter.
“RequiredExtensions”内容类型参数可用于传递实际使用的扩展列表，指定为以逗号分隔的EHLO响应列表。如果不存在，则默认为列表“8bitMIME、大小、公证人”。私人双边协议使用额外或不同扩展时，必须在“所需扩展”参数中注明。
Note that many SMTP extensions simply do not make sense in the context of batch SMTP. For example, the pipelining extension [RFC-2197] makes no sense in the absence of a network connection.
请注意，许多SMTP扩展在批处理SMTP上下文中根本没有意义。例如，在没有网络连接的情况下，管道扩展[RFC-2197]毫无意义。
Handling Multiple Messages
处理多条消息
Generators SHOULD attempt to minimize the number of messages placed in a single application/batch-SMTP object. Ideally a single application/batch-SMTP object will be created for each message. Note, however, that some uses of application/batch-SMTP (e.g., mail bagging) may exist solely to take advantage of the multiple messages in a single container capability of batch SMTP, so requiring one message per container is not possible.
生成器应尽量减少单个应用程序/批处理SMTP对象中的邮件数。理想情况下，将为每条邮件创建单个应用程序/批处理SMTP对象。但是，请注意，应用程序/批处理SMTP的某些用途（例如，邮件打包）可能仅仅是为了利用批处理SMTP在单个容器中的多条邮件功能，因此不可能要求每个容器都有一条邮件。
DISCUSSION: The SMTP protocol provides for the transfer of a series of messages over a single connection. This extends in a natural way to batch SMTP. However, the issues in batch SMTP are somewhat different. Suppose, for example, that a batch SMTP processor receives an application/batch-SMTP object containing two messages but is unable to process the second message because of a storage allocation failure. But suppose that not only does this failure preclude processing of the second message, it also precludes recording that the first message has already been processed. Subsequent reprocessing of the application/batch-SMTP could then lead to duplication of the first message.
讨论：SMTP协议提供通过单个连接传输一系列消息。这以一种自然的方式扩展到批处理SMTP。但是，批处理SMTP中的问题有些不同。例如，假设批处理SMTP处理器接收到包含两条消息的应用程序/批处理SMTP对象，但由于存储分配失败而无法处理第二条消息。但是，假设该故障不仅排除了第二条消息的处理，还排除了第一条消息已经被处理的记录。随后重新处理应用程序/批处理SMTP可能会导致第一封邮件重复。
This issue is not materially different from the well-known problems with SMTP synchronization that in practice often lead to duplicated messages. Since this behavior is inherent in SMTP to begin with it is not incumbent on application/batch-SMTP to completely address the issue. Nevertheless, it seems prudent for application/batch-SMTP to try and not make matters even worse.
这个问题与众所周知的SMTP同步问题没有实质性区别，SMTP同步问题在实践中经常导致重复的邮件。由于此行为是SMTP固有的，因此应用程序/批处理SMTP不必完全解决此问题。尽管如此，应用程序/批处理SMTP还是应该谨慎地尝试，不要让事情变得更糟。
Transport of application/batch-SMTP objects
应用程序/批处理SMTP对象的传输
Application/batch-SMTP objects may be transported by any transport capable of preserving their MIME labelling, e.g., HTTP or SMTP.
应用程序/批处理SMTP对象可以通过任何能够保留其MIME标签的传输进行传输，例如HTTP或SMTP。
Transports MUST remain cognizant of the special nature of application/batch-SMTP. An application/batch-SMTP object contains one or more "frozen" SMTP message transactions. SMTP message transactions typically carry with them various assumptions about quality of service, e.g., that messages will either be delivered successfully or a nondelivery notification will be returned, that a nondelivery notification will be returned if delivery cannot be accomplished in a timely fashion, and so on. It is vital that the encapsulation of these objects for carriage over other forms of transport not interfere with these capabilities.
传输必须了解应用程序/批处理SMTP的特殊性质。应用程序/批处理SMTP对象包含一个或多个“冻结”SMTP邮件事务。SMTP邮件事务通常附带关于服务质量的各种假设，例如，邮件将成功传递或将返回未送达通知，如果无法及时完成传递，将返回未送达通知，等等。将这些对象封装在其他形式的传输上时，不得干扰这些功能，这一点至关重要。
Processing of application/batch-SMTP material
处理申请/批处理SMTP材料
Processing of application/batch-SMTP material is considerably more complex than generating it. As might be expected, a modified SMTP/ESMTP processor is used. However, since it cannot return information to the client, it must handle all error conditions that arise itself. In other words, a batch SMTP processor assumes both the responsibilities of a traditional SMTP server as well as part of the responsibilities of a traditional SMTP client.
处理应用程序/批处理SMTP材料比生成材料要复杂得多。正如预期的那样，使用了经过修改的SMTP/ESMTP处理器。但是，由于它不能将信息返回给客户机，因此它必须处理自身出现的所有错误情况。换句话说，批处理SMTP处理器既承担传统SMTP服务器的责任，也承担传统SMTP客户端的部分责任。
As such, a conforming processor: MUST check MIME content type information to insure that the material it has been presented with is labelled as application/batch-SMTP and doesn't specify any extensions the processor doesn't support in the "required-extensions" parameter. Application/batch-SMTP objects that employ an unsupported extension SHOULD be forwarded to the local postmaster for manual inspection and handling. MUST accept any syntactically valid EHLO or HELO command. MUST accept any syntactically valid MAIL FROM command. A conforming processor, MAY, if it so desires, note the unacceptability of some part of a given MAIL FROM command and use this information to subsequently generate non-delivery notifications for any or all recipients. MUST accept any syntactically valid RCPT TO command. A conforming processor SHOULD note the unacceptability of some part of a given RCPT TO command and subsequently use this information to generate a non-delivery notification for this recipient in lieu of actually delivering the message. MUST accept any of the additional parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP extensions on the MAIL FROM and RCPT TO commands. MUST accept the DATA command even when no valid recipients are present. 8bit MIME messages MUST be accepted. MUST accept the RSET command and handle multiple messages in a single application/batch-SMTP object. Processors MUST process each message in an application/batch-SMTP object once and SHOULD take whatever steps are necessary to avoid processing a message more than once. For example, if processing of an application/batch-SMTP object containing multiple messages is interrupted at an intermediate point it should subsequently be restarted at the end of the last message that was completely processed. SHOULD forward any syntactically invalid application/batch-SMTP message to the local postmaster for manual inspection and handling.
因此，合格的处理者：必须检查MIME内容类型信息，以确保其提供的材料标记为应用程序/批处理SMTP，并且在“所需扩展”参数中未指定处理者不支持的任何扩展。使用不受支持扩展名的应用程序/批处理SMTP对象应转发给本地邮政局长，以便手动检查和处理。必须接受任何语法有效的EHLO或HELO命令。必须接受来自命令的任何语法有效的邮件。如果合规处理方愿意，可注意到来自司令部的给定邮件的某些部分不可接受，并使用此信息为任何或所有收件人生成未送达通知。必须接受任何语法有效的RCPT TO命令。合规处理方应注意，给定RCPT的某些部分无法接受命令，并随后使用此信息为该收件人生成未送达通知，以代替实际送达消息。必须接受MAIL FROM和RCPT TO命令上8bitMIME、SIZE和NOTARY SMTP扩展名定义的任何其他参数。即使没有有效的收件人，也必须接受DATA命令。必须接受8位MIME消息。必须接受RSET命令并在单个应用程序/批处理SMTP对象中处理多封邮件。处理者必须对应用程序/批处理SMTP对象中的每封邮件处理一次，并应采取任何必要的步骤以避免多次处理邮件。例如，如果包含多条消息的应用程序/批处理SMTP对象的处理在中间点中断，则应在最后一条完全处理的消息结束时重新启动该对象。应将任何语法无效的应用程序/批处理SMTP邮件转发给本地邮政局长，以便手动检查和处理。
Security Considerations
安全考虑
Application/batch-SMTP implements a tunneling mechanism. In general tunneling mechanisms are prone to abuse because they may provide a means of bypassing existing security restrictions. For example, an application/batch-SMTP tunnel implemented over an existing SMTP transport may allow someone to bypass relay restrictions imposed to block redistribution of spam.
应用程序/批处理SMTP实现隧道机制。一般来说，隧道机制容易被滥用，因为它们可能提供一种绕过现有安全限制的方法。例如，通过现有SMTP传输实现的应用程序/批处理SMTP隧道可能允许某人绕过为阻止垃圾邮件重新分发而施加的中继限制。
Application/batch-SMTP processors SHOULD implement access restrictions designed to limit access to the processor to authorized generators only. (Note that this facility may be provided automatically if application/batch-SMTP is being used to secure message envelope information.)
应用程序/批处理SMTP处理器应实施访问限制，旨在将对处理器的访问限制为仅授权的生成器。（请注意，如果使用应用程序/批处理SMTP保护邮件信封信息，则可能会自动提供此功能。）
Acknowledgements
致谢
The general concept of batch SMTP has been around for a long time. One particular type of batch SMTP was defined by Alan Crosswell and used on BITNET to overcome BITNET's native 8 character limit on user and host names. However, this form of batch SMTP differed from the current proposal in that it envisioned having the server return the status code responses to the client. In this case the client bore the burden of correlating responses with the original SMTP dialogue after the fact.
批量SMTP的一般概念由来已久。Alan Crosswell定义了一种特定类型的批处理SMTP，并在BITNET上使用它来克服BITNET对用户名和主机名的本机8个字符限制。但是，这种形式的批处理SMTP与当前的方案不同，它设想让服务器向客户端返回状态码响应。在这种情况下，客户机承担了事后将响应与原始SMTP对话关联起来的责任。
Unfortunately this approach proved not to work well in practice. BITNET eventually switched to the same basic form of batch SMTP that has been defined here. Unfortunately that definition was, to the best of the present authors' knowledge, never captured in a formal specification. It should also be noted that the definition given here also differs in that it takes SMTP extensions into account.
不幸的是，这种方法在实践中效果不佳。BITNET最终切换到此处定义的相同基本形式的批处理SMTP。不幸的是，就目前作者所知，该定义从未在正式规范中得到体现。还应注意，此处给出的定义也有所不同，因为它考虑了SMTP扩展。
Einar Stefferud had previously considered the problem of carrying extended SMTP messages over unextended SMTP transports. He proposed that some form of "double enveloping" technology be developed to address this problem. The mechanism presented here effectively implements the type of solution he proposed.
Einar Stefferud以前曾考虑过在未扩展的SMTP传输上传输扩展的SMTP消息的问题。他建议开发某种形式的“二次包络”技术来解决这个问题。这里介绍的机制有效地实现了他提出的解决方案类型。
References
工具书类
[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-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822 August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-1123] Braden, B., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123]Braden，B，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC-1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC-1652]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 1652，1994年7月。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847]Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年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-1870] Klensin, J., Freed, N., Moore, K., "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November, 1995.
[RFC-1870]Klensin，J.，Freed，N.，Moore，K.，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，1995年11月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，1996年12月。
[RFC-2197] Freed, N. and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[RFC-2197]Freed，N.和A.Cargille，“用于命令管道的SMTP服务扩展”，RFC 2197，1997年9月。
Authors' Addresses
作者地址
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 3614
EMail: ned.freed@innosoft.com
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Dan Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Dan Newman Innosoft International，Inc.美国加利福尼亚州西科维纳湖大道1050号，邮编：91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@innosoft.com
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@innosoft.com
Mark Hoy Mainbrace Corporation 1136 West Evelyn Avenue Sunnyvale, CA 94086
美国加利福尼亚州桑尼维尔西伊夫林大道1136号马克·霍伊公司，邮编94086
tel: +1 408 774 5265
fax: +1 408 774 5290
email: mark.hoy@mainbrace.com
tel: +1 408 774 5265
fax: +1 408 774 5290
email: mark.hoy@mainbrace.com
Jacques Bellisent SunSoft
Jacques Bellist SunSoft
Phone: +1 650 786 3630
EMail: jacques.belissent@eng.sun.com
Phone: +1 650 786 3630
EMail: jacques.belissent@eng.sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。