Network Working Group A. Gulbrandsen, Ed.
Request for Comments: 5161 Oryx Mail Systems GmbH
Category: Standards Track A. Melnikov, Ed.
Isode Limited
March 2008
Network Working Group A. Gulbrandsen, Ed.
Request for Comments: 5161 Oryx Mail Systems GmbH
Category: Standards Track A. Melnikov, Ed.
Isode Limited
March 2008
The IMAP ENABLE 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
摘要
Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports.
大多数IMAP扩展都由客户机在需要时使用，并且服务器支持它。但是，一些扩展要求服务器知道客户端是否支持该扩展。ENABLE扩展允许IMAP客户机说出它支持哪些扩展。
Several IMAP extensions allow the server to return unsolicited responses specific to these extensions in certain circumstances. However, servers cannot send those unsolicited responses until they know that the clients support such extensions and thus won't choke on the extension response data.
一些IMAP扩展允许服务器在某些情况下返回特定于这些扩展的未经请求的响应。但是，服务器无法发送这些未经请求的响应，除非它们知道客户端支持此类扩展，从而不会阻塞扩展响应数据。
Up until now, extensions have typically stated that a server cannot send the unsolicited responses until after the client has used a command with the extension data (i.e., at that point the server knows the client is aware of the extension). CONDSTORE ([RFC4551]), ANNOTATE ([ANNOTATE]), and some extensions under consideration at the moment use various commands to enable server extensions. For example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE uses a side effect of FETCH.
到目前为止，扩展通常表示，在客户机使用带有扩展数据的命令之前（即，此时服务器知道客户机知道扩展），服务器无法发送未经请求的响应。CONDSTORE（[RFC4551]）、ANNOTATE（[ANNOTATE]）和目前正在考虑的一些扩展使用各种命令来启用服务器扩展。例如，CONDSTORE使用SELECT或FETCH参数，ANNOTATE使用FETCH的副作用。
The ENABLE extension provides an explicit indication from the client that it supports particular extensions. This is done using a new ENABLE command.
ENABLE扩展提供了来自客户端的明确指示，表明它支持特定扩展。这是使用新的ENABLE命令完成的。
An IMAP server that supports ENABLE advertises this by including the word ENABLE in its capability list.
支持ENABLE的IMAP服务器通过在其功能列表中包含单词ENABLE来播发此消息。
Most IMAP extensions do not require the client to enable the extension in any way.
大多数IMAP扩展不要求客户端以任何方式启用扩展。
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 [RFC5234] and [RFC3501].
形式语法由[RFC5234]和[RFC3501]定义。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided.
以“C:”开头的示例行由客户端发送，以“S:”开头的示例行由服务器发送。五个字符[…]意味着某些东西被省略了。
Arguments: capability names
参数：功能名称
Result: OK: Relevant capabilities enabled BAD: No arguments, or syntax error in an argument
结果：确定：相关功能已启用错误：参数中没有参数或语法错误
The ENABLE command takes a list of capability names, and requests the server to enable the named extensions. Once enabled using ENABLE, each extension remains active until the IMAP connection is closed. For each argument, the server does the following:
ENABLE命令获取功能名称列表，并请求服务器启用命名扩展。使用ENABLE启用后，每个扩展都将保持活动状态，直到IMAP连接关闭。对于每个参数，服务器执行以下操作：
- If the argument is not an extension known to the server, the server MUST ignore the argument.
- 如果该参数不是服务器已知的扩展，服务器必须忽略该参数。
- If the argument is an extension known to the server, and it is not specifically permitted to be enabled using ENABLE, the server MUST ignore the argument. (Note that knowing about an extension doesn't necessarily imply supporting that extension.)
- 如果参数是服务器已知的扩展，并且不允许使用ENABLE启用该参数，则服务器必须忽略该参数。（请注意，了解扩展并不一定意味着支持该扩展。）
- If the argument is an extension that is supported by the server and that needs to be enabled, the server MUST enable the extension for the duration of the connection. At present, this applies only to CONDSTORE ([RFC4551]). Note that once an extension is enabled, there is no way to disable it.
- 如果参数是服务器支持且需要启用的扩展，则服务器必须在连接期间启用该扩展。目前，这仅适用于CONDSTORE（[RFC4551]）。请注意，一旦启用了扩展，就无法禁用它。
If the ENABLE command is successful, the server MUST send an untagged ENABLED response (see Section 3.2).
如果ENABLE命令成功，服务器必须发送一个未标记的ENABLED响应（参见第3.2节）。
Clients SHOULD only include extensions that need to be enabled by the server. At the time of publication, CONDSTORE is the only such extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE enabling command" as defined in [RFC4551]). Future RFCs may add to this list.
客户端应该只包括需要由服务器启用的扩展。在发布时，CONDSTORE是唯一的此类扩展（即，ENABLE CONDSTORE是[RFC4551]中定义的附加“CONDSTORE enabling command”）。未来的RFC可能会添加到此列表中。
The ENABLE command is only valid in the authenticated state (see [RFC3501]), before any mailbox is selected. Clients MUST NOT issue ENABLE once they SELECT/EXAMINE a mailbox; however, server implementations don't have to check that no mailbox is selected or was previously selected during the duration of a connection.
在选择任何邮箱之前，ENABLE命令仅在已验证状态（请参阅[RFC3501]）下有效。客户端在选择/检查邮箱后不得发出ENABLE；但是，服务器实现不必检查连接期间是否未选择邮箱或以前是否已选择邮箱。
The ENABLE command can be issued multiple times in a session. It is additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a single command "ENABLE a b c". When multiple ENABLE commands are issued, each corresponding ENABLED response SHOULD only contain extensions enabled by the corresponding ENABLE command.
一个会话中可以多次发出ENABLE命令。它是添加剂；i、 例如，“ENABLE a b”，后跟“ENABLE c”，与单个命令“ENABLE a b c”相同。发出多个启用命令时，每个相应的启用响应应仅包含由相应的启用命令启用的扩展。
There are no limitations on pipelining ENABLE. For example, it is possible to send ENABLE and then immediately SELECT, or a LOGIN immediately followed by ENABLE.
对管道启用没有限制。例如，可以先发送ENABLE，然后立即选择，或者在登录后立即发送ENABLE。
The server MUST NOT change the CAPABILITY list as a result of executing ENABLE; i.e., a CAPABILITY command issued right after an ENABLE command MUST list the same capabilities as a CAPABILITY command issued before the ENABLE command. This is demonstrated in the following example:
服务器不得因执行ENABLE而更改能力列表；i、 例如，在启用命令之后发出的能力命令必须列出与在启用命令之前发出的能力命令相同的能力。下面的示例演示了这一点：
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t3 OK foo again
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t3 OK foo again
In the following example, the client enables CONDSTORE:
在以下示例中，客户端启用CONDSTORE：
C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled
C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled
Contents: capability listing
内容：能力清单
The ENABLED response occurs as a result of an ENABLE command. The capability listing contains a space-separated listing of capability names that the server supports and that were successfully enabled. The ENABLED response may contain no capabilities, which means that no extensions listed by the client were successfully enabled.
启用的响应是ENABLE命令的结果。功能列表包含服务器支持且已成功启用的功能名称的空格分隔列表。已启用的响应可能不包含任何功能，这意味着未成功启用客户端列出的任何扩展。
Designers of IMAP extensions are discouraged from creating extensions that require ENABLE unless there is no good alternative design. Specifically, extensions that cause potentially incompatible behavior changes to deployed server responses (and thus benefit from ENABLE) have a higher complexity cost than extensions that do not.
不鼓励IMAP扩展的设计者创建需要启用的扩展，除非没有好的替代设计。具体地说，对部署的服务器响应造成潜在不兼容行为更改的扩展（并因此受益于ENABLE）比没有更改的扩展具有更高的复杂性成本。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234] including the core rules in Appendix B.1. [RFC3501] defines the non-terminals "capability" and "command-any".
以下语法规范使用[RFC5234]中规定的增广巴科斯诺尔形式（ABNF）符号，包括附录B.1中的核心规则。[RFC3501]定义了非终端的“能力”和“任何命令”。
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.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
capability =/ "ENABLE"
能力=/“启用”
command-any =/ "ENABLE" 1*(SP capability)
command-any =/ "ENABLE" 1*(SP capability)
response-data =/ "*" SP enable-data CRLF
response-data =/ "*" SP enable-data CRLF
enable-data = "ENABLED" *(SP capability)
启用数据=“已启用”*（SP功能）
It is believed that this extension doesn't add any security considerations that are not already present in the base IMAP protocol [RFC3501].
据信，此扩展没有添加任何在基本IMAP协议[RFC3501]中尚未出现的安全注意事项。
The IANA has added ENABLE to the IMAP4 Capabilities Registry.
IANA已将ENABLE添加到IMAP4功能注册表中。
The editors would like to thank Randy Gellens, Chris Newman, Peter Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus Daboo, Ken Murchison, and Eric Burger for comments and corrections. However, this doesn't necessarily mean that they endorse this extension, agree with all details, or are responsible for errors introduced by the editors.
编辑们要感谢兰迪·盖伦斯、克里斯·纽曼、彼得·科茨、戴夫·克里德兰、马克·克里斯平、内德·弗里德、丹·卡普、塞勒斯·达布、肯·默奇森和埃里克·伯格的评论和更正。然而，这并不一定意味着他们认可这个扩展，同意所有细节，或者对编辑引入的错误负责。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[RFC4551]Melnikov，A.和S.Hole，“条件存储操作或快速标志更改再同步的IMAP扩展”，RFC 45512006年6月。
[ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work in Progress, August 2006.
[注释]Daboo，C.和R.Gellens，“IMAP注释扩展”，正在进行的工作，2006年8月。
Editors' Addresses
编辑地址
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
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.