Network Working Group A. Gulbrandsen
Request for Comments: 4978 Oryx Mail Systems GmbH
Category: Standards Track August 2007
Network Working Group A. Gulbrandsen
Request for Comments: 4978 Oryx Mail Systems GmbH
Category: Standards Track August 2007
The IMAP COMPRESS Extension
IMAP压缩扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed.
压缩扩展允许有效地压缩IMAP连接。
Table of Contents
目录
1. Introduction and Overview .......................................2
2. Conventions Used in This Document ...............................2
3. The COMPRESS Command ............................................3
4. Compression Efficiency ..........................................4
5. Formal Syntax ...................................................6
6. Security Considerations .........................................6
7. IANA Considerations .............................................6
8. Acknowledgements ................................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
1. Introduction and Overview .......................................2
2. Conventions Used in This Document ...............................2
3. The COMPRESS Command ............................................3
4. Compression Efficiency ..........................................4
5. Formal Syntax ...................................................6
6. Security Considerations .........................................6
7. IANA Considerations .............................................6
8. Acknowledgements ................................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
A server which supports the COMPRESS extension indicates this with one or more capability names consisting of "COMPRESS=" followed by a supported compression algorithm name as described in this document.
支持压缩扩展的服务器使用一个或多个功能名称来表示这一点，这些功能名称由“COMPRESS=”组成，后跟本文档中描述的受支持的压缩算法名称。
The goal of COMPRESS is to reduce the bandwidth usage of IMAP.
压缩的目标是减少IMAP的带宽使用。
Compared to PPP compression (see [RFC1962]) and modem-based compression (see [MNP] and [V42BIS]), COMPRESS offers much better compression efficiency. COMPRESS can be used together with Transport Security Layer (TLS) [RFC4346], Simple Authentication and Security layer (SASL) encryption, Virtual Private Networks (VPNs), etc. Compared to TLS compression [RFC3749], COMPRESS has the following (dis)advantages:
与PPP压缩（参见[RFC1962]）和基于调制解调器的压缩（参见[MNP]和[V42BIS]）相比，压缩提供了更好的压缩效率。COMPRESS可与传输安全层（TLS）[RFC4346]、简单身份验证和安全层（SASL）加密、虚拟专用网络（VPN）等一起使用。与TLS压缩[RFC3749]相比，COMPRESS具有以下（dis）优势：
- COMPRESS can be implemented easily both by IMAP servers and clients.
- 压缩可以通过IMAP服务器和客户端轻松实现。
- IMAP COMPRESS benefits from an intimate knowledge of the IMAP protocol's state machine, allowing for dynamic and aggressive optimization of the underlying compression algorithm's parameters.
- IMAP压缩得益于对IMAP协议状态机的深入了解，允许对底层压缩算法的参数进行动态和积极的优化。
- When the TLS layer implements compression, any protocol using that layer can transparently benefit from that compression (e.g., SMTP and IMAP). COMPRESS is specific to IMAP.
- 当TLS层实现压缩时，使用该层的任何协议都可以透明地从该压缩中获益（例如，SMTP和IMAP）。压缩特定于IMAP。
In order to increase interoperation, it is desirable to have as few different compression algorithms as possible, so this document specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is standard, widely available and fairly efficient, so it is the only algorithm defined by this document.
为了增加互操作性，需要尽可能少地使用不同的压缩算法，因此本文档仅指定一种。DEFLATE算法（在[RFC1951]中定义）是标准的、广泛可用的和相当有效的，因此它是本文档定义的唯一算法。
In order to increase interoperation, IMAP servers that advertise this extension SHOULD also advertise the TLS DEFLATE compression mechanism as defined in [RFC3749]. IMAP clients MAY use either COMPRESS or TLS compression, however, if the client and server support both, it is RECOMMENDED that the client choose TLS compression.
为了增加互操作性，播发此扩展的IMAP服务器还应播发[RFC3749]中定义的TLS DEFLATE压缩机制。IMAP客户端可以使用压缩或TLS压缩，但是，如果客户端和服务器都支持，建议客户端选择TLS压缩。
The extension adds one new command (COMPRESS) and no new responses.
扩展添加了一个新命令（COMPRESS），但没有新的响应。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Formal syntax is defined by [RFC4234] as modified by [RFC3501].
形式语法由[RFC4234]定义，并由[RFC3501]修改。
In the examples, "C:" and "S:" indicate lines sent by the client and server respectively. "[...]" denotes elision.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。“[…]”表示省略。
Arguments: Name of compression mechanism: "DEFLATE".
参数：压缩机制的名称：“DEFLATE”。
Responses: None
答复：无
Result: OK The server will compress its responses and expects the client to compress its commands. NO Compression is already active via another layer. BAD Command unknown, invalid or unknown argument, or COMPRESS already active.
结果：确定服务器将压缩其响应，并期望客户端压缩其命令。未通过另一层激活任何压缩。错误命令未知、参数无效或未知，或压缩已处于活动状态。
The COMPRESS command instructs the server to use the named compression mechanism ("DEFLATE" is the only one defined) for all commands and/or responses after COMPRESS.
COMPRESS命令指示服务器对压缩后的所有命令和/或响应使用命名压缩机制（“DEFLATE”是唯一定义的压缩机制）。
The client MUST NOT send any further commands until it has seen the result of COMPRESS. If the response was OK, the client MUST compress starting with the first command after COMPRESS. If the server response was BAD or NO, the client MUST NOT turn on compression.
在看到压缩结果之前，客户端不得发送任何进一步的命令。如果响应正常，则客户端必须从compress之后的第一个命令开始压缩。如果服务器响应错误或否，则客户端不得打开压缩。
If the server responds NO because it knows that the same mechanism is active already (e.g., because TLS has negotiated the same mechanism), it MUST send COMPRESSIONACTIVE as resp-text-code (see [RFC3501], Section 7.1), and the resp-text SHOULD say which layer compresses.
如果服务器响应否，因为它知道相同的机制已处于活动状态（例如，因为TLS已协商相同的机制），则必须将COMPRESSIONACTIVE作为resp文本代码发送（请参阅[RFC3501]，第7.1节），并且resp文本应说明压缩的层。
If the server issues an OK response, the server MUST compress starting immediately after the CRLF which ends the tagged OK response. (Responses issued by the server before the OK response will, of course, still be uncompressed.) If the server issues a BAD or NO response, the server MUST NOT turn on compression.
如果服务器发出OK响应，则服务器必须在CRLF结束标记的OK响应后立即开始压缩。（当然，在OK响应之前服务器发出的响应仍将被解压缩。）如果服务器发出错误或无响应，则服务器不得打开压缩。
For DEFLATE (as for many other compression mechanisms), the compressor can trade speed against quality. When decompressing there isn't much of a tradeoff. Consequently, the client and server are both free to pick the best reasonable rate of compression for the data they send.
对于DEFLATE（与许多其他压缩机制一样），压缩机可以权衡速度和质量。解压时没有多少折衷。因此，客户机和服务器都可以为它们发送的数据选择最佳的合理压缩率。
When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see [RFC4422]) security layers, the sending order of the three extensions MUST be first COMPRESS, then SASL, and finally TLS. That is, before data is transmitted it is first compressed. Second, if a SASL security layer has been negotiated, the compressed data is then signed and/or encrypted accordingly. Third, if a TLS security layer has been negotiated, the data from the previous step is signed and/or
当COMPRESS与TLS（请参见[RFC4346]）或SASL（请参见[RFC4422]）安全层结合使用时，三个扩展的发送顺序必须是先压缩，然后是SASL，最后是TLS。也就是说，在传输数据之前，首先对其进行压缩。其次，如果已协商SASL安全层，则压缩数据将被相应地签名和/或加密。第三，如果已协商TLS安全层，则对上一步骤中的数据进行签名和/或
encrypted accordingly. When receiving data, the processing order MUST be reversed. This ensures that before sending, data is compressed before it is encrypted, independent of the order in which the client issues COMPRESS, AUTHENTICATE, and STARTTLS.
相应地加密。接收数据时，必须颠倒处理顺序。这确保了在发送数据之前，数据在加密之前被压缩，而与客户端发出COMPRESS、AUTHENTICATE和STARTTLS的顺序无关。
The following example illustrates how commands and responses are compressed during a simple login sequence:
以下示例说明了在简单登录序列中如何压缩命令和响应：
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
C: a starttls
S: a OK TLS active
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
C: a starttls
S: a OK TLS active
From this point on, everything is encrypted.
从这一点开始，一切都是加密的。
C: b login arnt tnra
S: b OK Logged in as arnt
C: c compress deflate
S: d OK DEFLATE active
C: b login arnt tnra
S: b OK Logged in as arnt
C: c compress deflate
S: d OK DEFLATE active
From this point on, everything is compressed before being encrypted.
从这一点开始，所有内容在加密之前都会被压缩。
The following example demonstrates how a server may refuse to compress twice:
以下示例演示了服务器如何拒绝压缩两次：
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
[...]
C: c compress deflate
S: c NO [COMPRESSIONACTIVE] DEFLATE active via TLS
S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
[...]
C: c compress deflate
S: c NO [COMPRESSIONACTIVE] DEFLATE active via TLS
This section is informative, not normative.
本节内容丰富，不规范。
IMAP poses some unusual problems for a compression layer.
IMAP为压缩层带来了一些不寻常的问题。
Upstream is fairly simple. Most IMAP clients send the same few commands again and again, so any compression algorithm that can exploit repetition works efficiently. The APPEND command is an exception; clients that send many APPEND commands may want to surround large literals with flushes in the same way as is recommended for servers later in this section.
上游相当简单。大多数IMAP客户端一次又一次地发送相同的几个命令，因此任何可以利用重复的压缩算法都能有效地工作。APPEND命令是一个例外；发送许多APPEND命令的客户机可能希望以与本节后面推荐的服务器相同的方式，用刷新来包围大型文本。
Downstream has the unusual property that several kinds of data are sent, confusing all dictionary-based compression algorithms.
下游有一个不寻常的特性，即发送多种数据，混淆了所有基于字典的压缩算法。
One type is IMAP responses. These are highly compressible; zlib using its least CPU-intensive setting compresses typical responses to 25-40% of their original size.
一种是IMAP响应。这些是高度可压缩的；zlib使用最少的CPU密集设置将典型响应压缩到原始大小的25-40%。
Another type is email headers. These are equally compressible, and benefit from using the same dictionary as the IMAP responses.
另一种类型是电子邮件标题。这些都是同样可压缩的，并且受益于使用与IMAP响应相同的字典。
A third type is email body text. Text is usually fairly short and includes much ASCII, so the same compression dictionary will do a good job here, too. When multiple messages in the same thread are read at the same time, quoted lines etc. can often be compressed almost to zero.
第三种类型是电子邮件正文文本。文本通常比较短，并且包含很多ASCII码，因此相同的压缩字典在这里也可以做得很好。当同一线程中的多条消息同时被读取时，带引号的行等通常会被压缩到几乎为零。
Finally, attachments (non-text email bodies) are transmitted, either in binary form or encoded with base-64.
最后，附件（非文本电子邮件正文）以二进制形式或用base-64编码的方式传输。
When attachments are retrieved in binary form, DEFLATE may be able to compress them, but the format of the attachment is usually not IMAP-like, so the dictionary built while compressing IMAP does not help. The compressor has to adapt its dictionary from IMAP to the attachment's format, and then back. A few file formats aren't compressible at all using deflate, e.g., .gz, .zip, and .jpg files.
当以二进制形式检索附件时，DEFLATE可能能够对其进行压缩，但附件的格式通常与IMAP不同，因此在压缩IMAP时生成的字典没有帮助。压缩器必须将其字典从IMAP调整为附件的格式，然后再重新调整。一些文件格式在使用deflate时根本不可压缩，例如.gz、.zip和.jpg文件。
When attachments are retrieved in base-64 form, the same problems apply, but the base-64 encoding adds another problem. 8-bit compression algorithms such as deflate work well on 8-bit file formats, however base-64 turns a file into something resembling 6-bit bytes, hiding most of the 8-bit file format from the compressor.
当以base-64格式检索附件时，同样的问题也会出现，但base-64编码会增加另一个问题。诸如deflate之类的8位压缩算法在8位文件格式上运行良好，但是base-64将文件转换为类似于6位字节的内容，从而对压缩器隐藏了大部分8位文件格式。
When using the zlib library (see [RFC1951]), the functions deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to implement this extension. The windowBits value must be in the range -8 to -15, or else deflateInit2() uses the wrong format. deflateParams() can be used to improve compression rate and resource use. The Z_FULL_FLUSH argument to deflate() can be used to clear the dictionary (the receiving peer does not need to do anything).
使用zlib库（请参见[RFC1951]）时，函数deflateInit2（）、deflate（）、inflateInit2（）和inflate（）足以实现此扩展。windowBits值必须在-8到-15范围内，否则deflateInit2（）使用了错误的格式。deflateParams（）可用于提高压缩率和资源利用率。deflate（）的Z_FULL_FLUSH参数可用于清除字典（接收对等方无需执行任何操作）。
A client can improve downstream compression by implementing BINARY (defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY. In the author's experience, the improvement ranges from 5% to 40% depending on the attachment being downloaded.
客户机可以通过实现二进制（在[RFC3516]中定义）和使用FETCH BINARY而不是FETCH BODY来改进下游压缩。根据作者的经验，根据下载的附件，改进的幅度从5%到40%不等。
A server can improve downstream compression if it hints to the compressor that the data type is about to change strongly, e.g., by sending a Z_FULL_FLUSH at the start and end of large non-text literals (before and after '*CHAR8' in the definition of literal in RFC 3501, page 86). Small literals are best left alone. A possible boundary is 5k.
如果服务器向压缩器提示数据类型即将发生强烈变化，例如，通过在大型非文本文本文本的开始和结束处发送Z_FULL_FLUSH（RFC 3501第86页文本定义中“*CHAR8”之前和之后），则可以改进下游压缩。最好不要使用小文本。可能的边界为5k。
A server can improve the CPU efficiency both of the server and the client if it adjusts the compression level (e.g., using the deflateParams() function in zlib) at these points, to avoid trying to compress incompressible attachments. A very simple strategy is to change the level to 0 at the start of a literal provided the first two bytes are either 0x1F 0x8B (as in deflate-compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the rest of the time. More complex strategies are possible.
如果服务器在这些点上调整压缩级别（例如，使用zlib中的deflateParams（）函数），以避免试图压缩不可压缩的附件，则服务器和客户端都可以提高CPU效率。一个非常简单的策略是在文本开头将级别更改为0，前提是前两个字节为0x1F 0x8B（如在deflate压缩文件中）或0xFF 0xD8（JPEG），并在其余时间将其保持在1-5。更复杂的策略是可能的。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC4234]. This syntax augments the grammar specified in [RFC3501]. [RFC4234] defines SP and [RFC3501] defines command-auth, capability, and resp-text-code.
以下语法规范使用[RFC4234]中指定的增广巴科斯诺尔形式（ABNF）表示法。此语法扩充了[RFC3501]中指定的语法。[RFC4234]定义SP，[RFC3501]定义命令验证、能力和resp文本代码。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
command-auth =/ compress
命令auth=/compress
compress = "COMPRESS" SP algorithm
compress=“compress”SP算法
capability =/ "COMPRESS=" algorithm
;; multiple COMPRESS capabilities allowed
capability =/ "COMPRESS=" algorithm
;; multiple COMPRESS capabilities allowed
algorithm = "DEFLATE"
algorithm = "DEFLATE"
resp-text-code =/ "COMPRESSIONACTIVE"
resp文本代码=/“压缩活动”
Note that due the syntax of capability names, future algorithm names must be atoms.
请注意，由于功能名称的语法，未来的算法名称必须是atoms。
As for TLS compression [RFC3749].
至于TLS压缩[RFC3749]。
The IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.
IANA已将COMPRESS=DEFLATE添加到IMAP功能列表中。
Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, Randall Gellens, Tony Hansen, Cullen Jennings, Stephane Maes, Alexey Melnikov, Lyndon Nerenberg, and Zoltan Ordogh have all helped with this document.
Eric Burger、Dave Cridland、Tony Finch、Ned Freed、Philip Guenther、Randall Gellens、Tony Hansen、Cullen Jennings、Stephane Maes、Alexey Melnikov、Lyndon Nerenberg和Zoltan Ordogh都参与了本文件的编写。
The author would also like to thank various people in the rooms at meetings, whose help is real, but not reflected in the author's mailbox.
作者还要感谢会议室里的各种人，他们的帮助是真实的，但没有反映在作者的邮箱中。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC1962]兰德，D.“PPP压缩控制协议（CCP）”，RFC1962，1996年6月。
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[RFC3516]Nerenberg，L.，“IMAP4二进制内容扩展”，RFC3516，2003年4月。
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[RFC3749]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，2004年5月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[V42BIS] ITU, "V.42bis: Data compression procedures for data circuit-terminating equipment (DCE) using error correction procedures", http://www.itu.int/rec/T-REC-V.42bis, January 1990.
[V42BIS]ITU，“V.42bis：使用纠错程序的数据电路终端设备（DCE）的数据压缩程序”，http://www.itu.int/rec/T-REC-V.42bis，1990年1月。
[MNP] Gilbert Held, "The Complete Modem Reference", Second Edition, Wiley Professional Computing, ISBN 0-471-00852-4, May 1994.
[MNP]吉尔伯特主持了《完整的调制解调器参考》，第二版，威利专业计算，ISBN 0-471-00852-41994年5月。
Author's Address
作者地址
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Oryx邮件系统有限公司Schweppermannstr。德国慕尼黑8D-81671
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.