Network Working Group M. Gahrns
Request for Comments: 3348 R. Cheng
Category: Informational Microsoft
July 2002
Network Working Group M. Gahrns
Request for Comments: 3348 R. Cheng
Category: Informational Microsoft
July 2002
The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
Internet邮件操作协议（IMAP4）子邮箱扩展
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
The Internet Message Action Protocol (IMAP4) CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST "" * or a LIST "" % for each mailbox.
Internet邮件操作协议（IMAP4）子级扩展为客户端提供了一种机制，可以有效地确定特定邮箱是否有子级，而无需为每个邮箱发出列表“”*或列表“”。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If such lines are wrapped without a new "C:" or "S:" label, then the wrapping is for editorial clarity and is not part of the command.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果这些行没有新的“C:”或“S:”标签而被换行，则换行是为了编辑清晰，而不是命令的一部分。
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]中所述进行解释。
Many IMAP4 [RFC-2060] clients present to the user a hierarchical view of the mailboxes that a user has access to. Rather than initially presenting to the user the entire mailbox hierarchy, it is often preferable to show to the user a collapsed outline list of the mailbox hierarchy (particularly if there is a large number of mailboxes). The user can then expand the collapsed outline hierarchy as needed. It is common to include within the collapsed hierarchy a
许多IMAP4[RFC-2060]客户端向用户呈现用户有权访问的邮箱的分层视图。与其最初向用户显示整个邮箱层次结构，通常更可取的做法是向用户显示邮箱层次结构的折叠大纲列表（特别是在存在大量邮箱的情况下）。然后，用户可以根据需要展开折叠的大纲层次结构。在折叠的层次结构中包含
visual clue (such as a "+") to indicate that there are child mailboxes under a particular mailbox. When the visual clue is clicked the hierarchy list is expanded to show the child mailboxes.
指示特定邮箱下有子邮箱的可视线索（如“+”）。单击可视线索时，层次结构列表将展开以显示子邮箱。
Several IMAP vendors implemented this proposal, and it is proposed to document this behavior and functionality as an Informational RFC.
几个IMAP供应商实施了这一建议，并建议将此行为和功能记录为信息RFC。
There is interest in addressing the general extensibility of the IMAP LIST command through an IMAP LIST Extension draft. Similar functionality to the \HasChildren and \HasNoChildren flags could be incorporated into this new LIST Extension. It is proposed that the more general LIST Extension draft proceed on the standards track with this proposal being relegated to informational status only.
通过IMAP列表扩展草案解决IMAP LIST命令的一般扩展性是很有意思的。与\HasChildren和\HasNoChildren标志类似的功能可以合并到此新的列表扩展中。建议在标准轨道上进行更一般的列表扩展草案，该提案仅处于信息状态。
If the functionality of the \HasChildren and \HasNoChildren flags were incorporated into a more general LIST extension, this would have the advantage that a client could then have the opportunity to request whether or not the server should return this information. This would be an advantage over the current draft for servers where this information is expensive to compute, since the server would only need to compute the information when it knew that the client requesting the information was able to consume it.
如果将\HasChildren和\HasNoChildren标志的功能合并到一个更通用的列表扩展中，则这样做的好处是，客户端可以有机会请求服务器是否应返回此信息。与当前的草案相比，这将是一个优势，因为服务器计算此信息的成本很高，因为服务器只需要在知道请求信息的客户端能够使用信息时计算信息。
IMAP4 servers that support this extension MUST list the keyword CHILDREN in their CAPABILITY response.
支持此扩展的IMAP4服务器必须在其功能响应中列出关键字子级。
The CHILDREN extension defines two new attributes that MAY be returned within a LIST response.
CHILDREN扩展定义了两个可以在列表响应中返回的新属性。
\HasChildren - The presence of this attribute indicates that the mailbox has child mailboxes.
\HasChildren-此属性的存在表示邮箱具有子邮箱。
Servers SHOULD NOT return \HasChildren if child mailboxes exist, but none will be displayed to the current user in a LIST response (as should be the case where child mailboxes exist, but a client does not have permissions to access them.) In this case, \HasNoChildren SHOULD be used.
如果存在子邮箱，服务器不应返回\HasChildren，但在列表响应中不会向当前用户显示任何子邮箱（应该是存在子邮箱，但客户端没有访问它们的权限的情况）。在这种情况下，应使用\HasNoChildren。
In many cases, however, a server may not be able to efficiently compute whether a user has access to all child mailboxes, or multiple users may be accessing the same account and simultaneously changing the mailbox hierarchy. As such a client MUST be prepared to accept the \HasChildren attribute as a hint. That is, a mailbox MAY be flagged with the \HasChildren attribute, but no child mailboxes will appear in a subsequent LIST response.
但是，在许多情况下，服务器可能无法有效地计算一个用户是否可以访问所有子邮箱，或者多个用户可能正在访问同一个帐户并同时更改邮箱层次结构。因此，客户端必须准备接受\HasChildren属性作为提示。也就是说，可以使用\HasChildren属性标记邮箱，但在后续列表响应中不会显示任何子邮箱。
Example 3.1:
============
Example 3.1:
============
/*** Consider a server that has the following mailbox hierarchy:
/*** Consider a server that has the following mailbox hierarchy:
INBOX ITEM_1 ITEM_1A ITEM_2 TOP_SECRET
收件箱项目1项目1项目1项目2绝密
Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is a child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2 that the currently logged on user does NOT have access to.
其中收件箱、项目_1和项目_2是顶级邮箱。ITEM_1A是ITEM_1的子邮箱，TOP_SECRET是ITEM_2的子邮箱，当前登录的用户无权访问该子邮箱。
Note that in this case, the server is not able to efficiently compute
access rights to child mailboxes and responds with a \HasChildren
attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
appear in the list response. ***/
Note that in this case, the server is not able to efficiently compute
access rights to child mailboxes and responds with a \HasChildren
attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
appear in the list response. ***/
C: A001 LIST "" *
S: * LIST (\HasNoChildren) "/" INBOX
S: * LIST (\HasChildren) "/" ITEM_1
S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
S: * LIST (\HasChildren) "/" ITEM_2
S: A001 OK LIST Completed
C: A001 LIST "" *
S: * LIST (\HasNoChildren) "/" INBOX
S: * LIST (\HasChildren) "/" ITEM_1
S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
S: * LIST (\HasChildren) "/" ITEM_2
S: A001 OK LIST Completed
\HasNoChildren - The presence of this attribute indicates that the mailbox has NO child mailboxes that are accessible to the currently authenticated user. If a mailbox has the \Noinferiors attribute, the \HasNoChildren attribute is redundant and SHOULD be omitted in the LIST response.
\HasNoChildren-此属性的存在表示邮箱没有可供当前经过身份验证的用户访问的子邮箱。如果邮箱具有\nInferiors属性，\nHasNoChildren属性是多余的，应在列表响应中忽略。
In some instances a server that supports the CHILDREN extension MAY NOT be able to determine whether a mailbox has children. For example it may have difficulty determining whether there are child mailboxes when LISTing mailboxes while operating in a particular namespace.
在某些情况下，支持子扩展的服务器可能无法确定邮箱是否有子扩展。例如，在特定名称空间中操作时列出邮箱时，可能很难确定是否存在子邮箱。
In these cases, a server MAY exclude both the \HasChildren and \HasNoChildren attributes in the LIST response. As such, a client can not make any assumptions about whether a mailbox has children based upon the absence of a single attribute.
在这些情况下，服务器可能会在列表响应中排除\HasChildren和\HasNoChildren属性。因此，客户机不能基于缺少单个属性而对邮箱是否具有子级做出任何假设。
It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in a LIST response.
服务器在列表响应中同时返回\HasChildren和\HasNoChildren属性是错误的。
It is an error for the server to return both a \HasChildren and a \NoInferiors attribute in a LIST response.
服务器在列表响应中同时返回\HasChildren和\NoInferiors属性是错误的。
Note: the \HasNoChildren attribute should not be confused with the IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that no child mailboxes exist now and none can be created in the future.
注意：不应将\HasNoChildren属性与IMAP4[RFC-2060]定义的属性\n混淆，后者表示现在不存在子邮箱，将来也不能创建子邮箱。
The \HasChildren and \HasNoChildren attributes might not be returned in response to a LSUB response. Many servers maintain a simple mailbox subscription list that is not updated when the underlying mailbox structure is changed. A client MUST NOT assume that hierarchy information will be maintained in the subscription list.
响应LSUB响应时可能不会返回\HasChildren和\HasNoChildren属性。许多服务器维护一个简单的邮箱订阅列表，当基础邮箱结构更改时，该列表不会更新。客户端不得假定订阅列表中将维护层次结构信息。
RLIST is a command defined in [RFC-2193] that includes in a LIST response mailboxes that are accessible only via referral. That is, a client must explicitly issue an RLIST command to see a list of these mailboxes. Thus in the case where a mailbox has child mailboxes that are available only via referral, the mailboxes would appear as \HasNoChildren in response to the LIST command, and \HasChildren in response to the RLIST command.
RLIST是[RFC-2193]中定义的一个命令，它包含在只能通过引用访问的列表响应邮箱中。也就是说，客户端必须显式发出RLIST命令才能查看这些邮箱的列表。因此，如果邮箱具有只能通过引用使用的子邮箱，则邮箱将显示为\HasNoChildren以响应LIST命令，而\haschilder以响应RLIST命令。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF].
以下语法规范使用[ABNF]中所述的增广巴科斯诺尔形式（BNF）。
Two new mailbox attributes are defined as flag_extensions to the IMAP4 mailbox_list response:
两个新邮箱属性被定义为IMAP4邮箱列表响应的标志扩展：
HasChildren = "\HasChildren"
HasChildren=“\HasChildren”
HasNoChildren = "\HasNoChildren"
HasNoChildren=“\HasNoChildren”
This extension provides a client a more efficient means of determining whether a particular mailbox has children. If a mailbox has children, but the currently authenticated user does not have access to any of them, the server SHOULD respond with a \HasNoChildren attribute. In many cases, however, a server may not be able to efficiently compute whether a user has access to all child mailboxes. If such a server responds with a \HasChildren attribute, when in fact the currently authenticated user does not have access to any child mailboxes, potentially more information is conveyed about the mailbox than intended. A server designed with such levels of security in mind SHOULD NOT attach the \HasChildren attribute to a mailbox unless the server is certain that the user has access to at least one of the child mailboxes.
此扩展为客户端提供了一种更有效的方法来确定特定邮箱是否有子邮箱。如果邮箱有子项，但当前经过身份验证的用户无权访问其中任何子项，则服务器应使用\HasNoChildren属性进行响应。但是，在许多情况下，服务器可能无法有效地计算用户是否有权访问所有子邮箱。如果这样的服务器使用\HasChildren属性响应，而实际上当前经过身份验证的用户没有访问任何子邮箱的权限，则可能会传递比预期更多的有关邮箱的信息。设计有此类安全级别的服务器不应将\HasChildren属性附加到邮箱，除非服务器确定用户至少有一个子邮箱的访问权限。
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC-2060]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 2060，1996年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC-2234]Crocker，D.和P.Overell，编辑，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 1997.
[RFC-2193]Gahrns，M.，“IMAP4邮箱转介”，RFC 2193，1997年9月。
The authors would like to thank the participants of several IMC Mail Connect events for their input when this idea was originally presented and refined.
作者要感谢几个IMC Mail Connect活动的参与者，感谢他们在最初提出和完善这一想法时所作的投入。
Mike Gahrns Microsoft One Microsoft Way Redmond, WA, 98052 Phone: (425) 936-9833 EMail: mikega@microsoft.com
Mike Gahrns Microsoft One Microsoft Way Redmond，WA，98052电话：（425）936-9833电子邮件：mikega@microsoft.com
Raymond Cheng Microsoft One Microsoft Way Redmond, WA, 98052 Phone: (425) 703-4913 EMail: raych@microsoft.com
Raymond Cheng Microsoft One Microsoft Way华盛顿州雷德蒙98052电话：（425）703-4913电子邮件：raych@microsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。