Network Working Group B. Leiba
Request for Comments: 5258 IBM T.J. Watson Research Center
Obsoletes: 3348 A. Melnikov
Updates: 2193 Isode Limited
Category: Standards Track June 2008
Network Working Group B. Leiba
Request for Comments: 5258 IBM T.J. Watson Research Center
Obsoletes: 3348 A. Melnikov
Updates: 2193 Isode Limited
Category: Standards Track June 2008
Internet Message Access Protocol version 4 - LIST Command Extensions
Internet消息访问协议版本4-列表命令扩展
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
摘要
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands.
IMAP4有两个用于列出邮箱的命令：LIST和LSUB。由于我们添加了需要专门列表的扩展（如邮箱引用），因此我们必须扩展列表命令的数量，因为每个扩展都必须将其功能添加到list和LSUB，而这些命令按照定义是不可扩展的。如果我们需要这些扩展一起工作，我们必须添加一组命令来混合不同的选项，这些命令随着每个新扩展的增加而增加。本文档描述了对基本列表命令的扩展，该扩展允许使用与列表命令相互兼容的选项进行这些添加，从而避免了专用列表命令的指数级增长。
Table of Contents
目录
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 4
3.1. Initial List of Selection Options . . . . . . . . . . . . 7
3.2. Initial List of Return Options . . . . . . . . . . . . . . 8
3.3. General Principles for Returning LIST Responses . . . . . 9
3.4. Additional Requirements on LIST-EXTENDED Clients . . . . . 9
3.5. CHILDINFO Extended Data Item . . . . . . . . . . . . . . . 10
4. The CHILDREN Return Option . . . . . . . . . . . . . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Internationalization Considerations . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Guidelines for IANA . . . . . . . . . . . . . . . . . . . 23
9.2. Registration Procedure and Change Control . . . . . . . . 23
9.3. Registration Template for LIST-EXTENDED Options . . . . . 25
9.4. Initial LIST-EXTENDED Option Registrations . . . . . . . . 25
9.5. Registration Template for LIST-EXTENDED Extended Data
Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.6. Initial LIST-EXTENDED Extended Data Item Registrations . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 30
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 4
3.1. Initial List of Selection Options . . . . . . . . . . . . 7
3.2. Initial List of Return Options . . . . . . . . . . . . . . 8
3.3. General Principles for Returning LIST Responses . . . . . 9
3.4. Additional Requirements on LIST-EXTENDED Clients . . . . . 9
3.5. CHILDINFO Extended Data Item . . . . . . . . . . . . . . . 10
4. The CHILDREN Return Option . . . . . . . . . . . . . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Internationalization Considerations . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Guidelines for IANA . . . . . . . . . . . . . . . . . . . 23
9.2. Registration Procedure and Change Control . . . . . . . . 23
9.3. Registration Template for LIST-EXTENDED Options . . . . . 25
9.4. Initial LIST-EXTENDED Option Registrations . . . . . . . . 25
9.5. Registration Template for LIST-EXTENDED Extended Data
Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.6. Initial LIST-EXTENDED Extended Data Item Registrations . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 30
The LIST command is extended by amending the syntax to allow options and multiple patterns to be specified. The list of options replaces the several commands that are currently used to mix and match the information requested. The new syntax is backward compatible, with no ambiguity: the new syntax is being used if one of the following conditions is true:
通过修改语法来扩展LIST命令，以允许指定选项和多个模式。选项列表将替换当前用于混合和匹配请求信息的多个命令。新语法向后兼容，没有歧义：如果以下条件之一为真，则使用新语法：
1. if the first word after the command name begins with a parenthesis ("LIST selection options")
1. 如果命令名后的第一个单词以括号开头（“列表选择选项”）
2. if the second word after the command name begins with a parenthesis ("multiple mailbox patterns")
2. 如果命令名后的第二个单词以括号开头（“多个邮箱模式”）
3. if the LIST command has more than 2 parameters ("LIST return options")
3. 如果LIST命令有两个以上的参数（“列表返回选项”）
Otherwise the original syntax is used.
否则将使用原始语法。
By adding options to the LIST command, we are announcing the intent to phase out and eventually to deprecate the RLIST and RLSUB commands described in [MBRef]. We are also defining the mechanism to request extended mailbox information, such as is described in the Child Mailbox Extension [CMbox]. The base LSUB command is not deprecated by this extension; rather, this extension adds a way to obtain subscription information with more options, with those server implementations that support it. Clients that simply need a list of subscribed mailboxes, as provided by the LSUB command, SHOULD continue to use that command.
通过向LIST命令添加选项，我们宣布了逐步淘汰并最终弃用[MBRef]中描述的RLIST和RLSUB命令的意图。我们还定义了请求扩展邮箱信息的机制，如子邮箱扩展[CMbox]中所述。此扩展不推荐使用base LSUB命令；相反，此扩展添加了一种通过更多选项获取订阅信息的方法，以及支持它的服务器实现。仅需要LSUB命令提供的订阅邮箱列表的客户端应继续使用该命令。
This document defines an IMAP4 extension that is identified by the capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes the following changes to the IMAP4 protocol, which are described in more detail in Section 3 and Section 4:
本文档定义了由功能字符串“LIST-EXTENDED”标识的IMAP4扩展。LIST-EXTENDED扩展对IMAP4协议进行了以下更改，第3节和第4节对此进行了详细描述：
a. defines new syntax for LIST command options.
a. 定义列表命令选项的新语法。
b. extends LIST to allow for multiple mailbox patterns.
b. 扩展列表以允许多个邮箱模式。
c. adds LIST command selection options: SUBSCRIBED, REMOTE, and RECURSIVEMATCH.
c. 添加列表命令选择选项：SUBSCRIBED、REMOTE和RECURSIVEMATCH。
d. adds LIST command return options: SUBSCRIBED and CHILDREN.
d. 添加列表命令返回选项：已订阅和子项。
e. adds new mailbox attributes: "\NonExistent", "\Subscribed", "\Remote", "\HasChildren", and "\HasNoChildren".
e. 添加新邮箱属性：“\noexistent”、“\Subscribed”、“\Remote”、“\HasChildren”和“\HasNoChildren”。
f. adds CHILDINFO extended data item.
f. 添加CHILDINFO扩展数据项。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
在示例中，“C:”表示连接到服务器的客户端发送的线路。“S:”表示服务器发送到客户端的行。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document as specified in RFC 2119 [Kwds].
按照RFC 2119[Kwds]的规定，本文件中使用了关键词“必须”、“不得”、“应该”、“不应该”和“可以”。
The term "canonical LIST pattern" refers to the canonical pattern constructed internally by the server from the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command returns only mailboxes that match the canonical LIST pattern.
术语“规范列表模式”是指服务器通过引用和邮箱名称参数（IMAP4的第6.3.8节）在内部构建的规范模式。[IMAP4]LIST命令仅返回与规范列表模式匹配的邮箱。
Other terms are introduced where they are referenced for the first time.
其他术语在首次引用时引入。
This extension updates the syntax of the LIST command to allow for multiple mailbox patterns to be specified, if they are enclosed in parentheses. A mailbox name matches a list of mailbox patterns if it matches at least one mailbox pattern. If a mailbox name matches multiple mailbox patterns from the list, the server SHOULD return only a single LIST response.
此扩展将更新LIST命令的语法，以允许指定多个邮箱模式（如果它们包含在括号中）。如果邮箱名称至少与一个邮箱模式匹配，则它与邮箱模式列表匹配。如果邮箱名称与列表中的多个邮箱模式匹配，则服务器应仅返回单个列表响应。
Note that the non-extended LIST command is required to treat an empty ("" string) mailbox name argument as a special request to return the hierarchy delimiter and the root name of the name given in the reference parameter (as per [IMAP4]). However, ANY extended LIST command (extended in any of 3 ways specified in Section 1, or any combination thereof) MUST NOT treat the empty mailbox name as such a special request, and any regular processing described in this document applies. In particular, if an extended LIST command has multiple mailbox names and one (or more) of them is the empty string, the empty string MUST be ignored for the purpose of matching.
请注意，需要使用非扩展列表命令将空（“”字符串）邮箱名称参数视为特殊请求，以返回层次分隔符和引用参数中给定名称的根名称（根据[IMAP4]）。但是，任何扩展列表命令（以第1节中指定的3种方式中的任何一种或其组合进行扩展）不得将空邮箱名称视为特殊请求，本文档中描述的任何常规处理均适用。特别是，如果扩展列表命令具有多个邮箱名称，并且其中一个（或多个）为空字符串，则必须忽略空字符串以进行匹配。
Some servers might restrict which patterns are allowed in a LIST command. If a server doesn't accept a particular pattern, it MUST silently ignore it.
某些服务器可能会限制LIST命令中允许的模式。如果服务器不接受特定的模式，它必须默默地忽略它。
The LIST command syntax is also extended in two additional ways: by adding a parenthesized list of command options between the command name and the reference name (LIST selection options) and an optional
列表命令语法还通过两种附加方式进行了扩展：在命令名和引用名（列表选择选项）之间添加一个带括号的命令选项列表，以及一个可选的
list of options at the end that control what kind of information should be returned (LIST return options). See the formal syntax in Section 6 for specific details.
末尾控制应返回何种信息的选项列表（列出返回选项）。有关具体细节，请参见第6节中的正式语法。
A LIST selection option tells the server which mailbox names should be selected by the LIST operation. The server should return information about all mailbox names that match any of the "canonical LIST pattern" (as described above) and satisfy additional selection criteria (if any) specified by the LIST selection options. Let's call any such mailbox name a "matched mailbox name". When multiple selection options are specified, the server MUST return information about mailbox names that satisfy every selection option, unless a description of a particular specified option prescribes special rules. An example of an option prescribing special rules is the RECURSIVEMATCH selection option described later in this section. We will use the term "selection criteria" when referring collectively to all selection options specified in a LIST command.
列表选择选项告诉服务器列表操作应选择哪些邮箱名称。服务器应返回与任何“规范列表模式”（如上所述）匹配并满足列表选择选项指定的其他选择条件（如果有）的所有邮箱名称的信息。让我们将任何这样的邮箱名称为“匹配邮箱名”。指定多个选择选项时，服务器必须返回满足每个选择选项的邮箱名称信息，除非特定指定选项的说明规定了特殊规则。规定特殊规则的选项的一个示例是本节后面介绍的RECURSIVEMATCH选择选项。我们将使用术语“选择标准”来统称列表命令中指定的所有选择选项。
A LIST return option controls which information is returned for each matched mailbox name. Note that return options MUST NOT cause the server to report information about additional mailbox names. If the client has not specified any return option, only information about attributes should be returned by the server. (Of course, the server is allowed to include any other information at will.)
列表返回选项控制为每个匹配的邮箱名称返回哪些信息。请注意，返回选项不得导致服务器报告有关其他邮箱名称的信息。如果客户端未指定任何返回选项，则服务器只应返回有关属性的信息。（当然，服务器可以随意包含任何其他信息。）
Both selection and return command options will be defined in this document and in approved extension documents; each option will be enabled by a capability string (one capability may enable multiple options), and a client MUST NOT send an option for which the server has not advertised support. A server MUST respond to options it does not recognize with a BAD response. The client SHOULD NOT specify any option more than once; however, if the client does this, the server MUST act as if it received the option only once. The order in which options are specified by the client is not significant.
选择和返回命令选项将在本文件和批准的扩展文件中定义；每个选项都将由一个功能字符串启用（一个功能可以启用多个选项），并且客户端不得发送服务器尚未公布支持的选项。服务器必须以错误响应响应它无法识别的选项。客户不得多次指定任何选项；但是，如果客户机执行此操作，服务器必须像只收到一次选项一样工作。客户指定选项的顺序并不重要。
In general, each selection option except RECURSIVEMATCH will have a corresponding return option. The REMOTE selection option is an anomaly in this regard, and does not have a corresponding return option. That is because it expands, rather than restricts, the set of mailboxes that are returned. Future extensions to this specification should keep parallelism in mind and define a pair of corresponding options.
通常，除RECURSIVEMATCH之外的每个选择选项都有相应的返回选项。远程选择选项在这方面是一个异常，没有相应的返回选项。这是因为它扩展而不是限制返回的邮箱集。该规范的未来扩展应该记住并行性，并定义一对相应的选项。
This extension is identified by the capability string "LIST-EXTENDED", and support for it is a prerequisite for any future extensions that require specialized forms of the LIST command. Such extensions MUST refer to this document and MUST add their function through command options as described herein. Note that extensions
此扩展由功能字符串“LIST-EXTENDED”标识，对它的支持是将来任何需要专门形式的LIST命令的扩展的先决条件。此类扩展必须参考本文档，并且必须通过本文所述的命令选项添加其功能。请注意，扩展
that don't require support for an extended LIST command, but use extended LIST responses (see below), don't need to advertise the "LIST-EXTENDED" capability string.
如果不需要支持扩展列表命令，但使用扩展列表响应（请参见下文），则不需要公布“LIST-extended”功能字符串。
This extension also defines extensions to the LIST response, allowing a series of extended fields at the end, a parenthesized list of tagged data (also referred to as "extended data item"). The first element of an extended field is a tag, which identifies the type of data. Tags MUST be registered with IANA, as described in Section 9.5 of this document. An example of such an extended set might be
此扩展还定义了列表响应的扩展，允许在末尾使用一系列扩展字段，即带括号的标记数据列表（也称为“扩展数据项”）。扩展字段的第一个元素是标记，用于标识数据类型。如本文件第9.5节所述，标签必须向IANA注册。这种扩展集的一个例子可能是
tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))
桌布（（“边”“花边”）（“颜色”“红色”））（X样本“文本”））
or
或
tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))
桌布（“边”“花边”）（X样本“文本”“更多文本”））
See the formal syntax, in Section 6, for the full syntactic details. The server MUST NOT return any extended data item unless the client has expressed its ability to support extended LIST responses, for example, by using an extended LIST command. The server MAY return data in the extended fields that was not directly solicited by the client in the corresponding LIST command. For example, the client can enable extra extended fields by using another IMAP extension that make use of the extended LIST responses. The client MUST ignore all extended fields it doesn't recognize.
有关完整的语法细节，请参见第6节中的正式语法。服务器不得返回任何扩展数据项，除非客户端已表示其支持扩展列表响应的能力，例如，通过使用扩展列表命令。服务器可以返回扩展字段中的数据，这些数据不是客户端在相应的LIST命令中直接请求的。例如，客户端可以通过使用另一个利用扩展列表响应的IMAP扩展来启用额外的扩展字段。客户端必须忽略它无法识别的所有扩展字段。
The LIST-EXTENDED capability also defines several new mailbox attributes.
列表扩展功能还定义了几个新的邮箱属性。
The "\NonExistent" attribute indicates that a mailbox name does not refer to an existing mailbox. Note that this attribute is not meaningful by itself, as mailbox names that match the canonical LIST pattern but don't exist must not be returned unless one of the two conditions listed below is also satisfied:
“\NonExistent”属性表示邮箱名称不引用现有邮箱。请注意，此属性本身没有意义，因为必须同时满足以下两个条件之一，才能返回与规范列表模式匹配但不存在的邮箱名称：
a. The mailbox name also satisfies the selection criteria (for example, it is subscribed and the "SUBSCRIBED" selection option has been specified).
a. 邮箱名称也满足选择条件（例如，它已订阅并且已指定“订阅”选择选项）。
b. "RECURSIVEMATCH" has been specified, and the mailbox name has at least one descendant mailbox name that does not match the LIST pattern and does match the selection criteria.
b. 已指定“RECURSIVEMATCH”，并且邮箱名称至少有一个子代邮箱名称与列表模式不匹配且与选择条件匹配。
In practice, this means that the "\NonExistent" attribute is usually returned with one or more of "\Subscribed", "\Remote", "\HasChildren", or the CHILDINFO extended data item (see their description below).
实际上，这意味着“\NonExistent”属性通常与一个或多个“\Subscribed”、“\Remote”、“\haschilds”或CHILDINFO扩展数据项一起返回（请参见下面的描述）。
The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" attribute MUST be supported and MUST be accurately computed.
“\NonExistent”属性意味着“\NoSelect”。必须支持并准确计算“\NonExistent”属性。
The selection options defined in this specification are as follows:
本规范中定义的选择选项如下：
SUBSCRIBED - causes the LIST command to list subscribed names, rather than the existing mailboxes. This will often be a subset of the actual mailboxes. It's also possible for this list to contain the names of mailboxes that don't exist. In any case, the list MUST include exactly those mailbox names that match the canonical list pattern and are subscribed to. This option is intended to supplement the LSUB command. Of particular note are the mailbox attributes as returned by this option, compared with what is returned by LSUB. With the latter, the attributes returned may not reflect the actual attribute status on the mailbox name, and the \NoSelect attribute has a second special meaning (it indicates that this mailbox is not, itself, subscribed, but that it has descendant mailboxes that are). With the SUBSCRIBED selection option described here, the attributes are accurate and complete, and have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, and some servers must do significant extra work to respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue to use "LSUB" unless they specifically want the additional information offered by "LIST (SUBSCRIBED)".
SUBSCRIBED-使LIST命令列出已订阅的名称，而不是现有邮箱。这通常是实际邮箱的一个子集。此列表还可能包含不存在的邮箱的名称。在任何情况下，该列表都必须包含与规范列表模式匹配且已订阅的邮箱名称。此选项旨在补充LSUB命令。特别要注意的是，与LSUB返回的邮箱属性相比，此选项返回的邮箱属性。对于后者，返回的属性可能不会反映邮箱名称上的实际属性状态，并且\n选择属性具有第二个特殊含义（它表示此邮箱本身未订阅，但其子代邮箱已订阅）。使用此处描述的订阅选择选项，属性是准确和完整的，没有特殊含义。因此，“LSUB”和“LIST（SUBSCRIBED）”不是一回事，一些服务器必须做大量额外的工作来响应“LIST（SUBSCRIBED）”。因此，客户应该继续使用“LSUB”，除非他们特别想要“LIST（SUBSCRIBED）”提供的附加信息。
This option defines a new mailbox attribute, "\Subscribed", that indicates that a mailbox name is subscribed to. The "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED selection option is specified.
此选项定义一个新的邮箱属性“\Subscribed”，表示已订阅邮箱名称。必须支持“\Subscribed”属性，并且在指定Subscribed选择选项时必须准确计算该属性。
Note that the SUBSCRIBED selection option implies the SUBSCRIBED return option (see below).
请注意，SUBSCRIBED selection选项意味着SUBSCRIBED return选项（见下文）。
REMOTE - causes the LIST command to show remote mailboxes as well as local ones, as described in [MBRef]. This option is intended to replace the RLIST command and, in conjunction with the SUBSCRIBED selection option, the RLSUB command.
远程-使LIST命令显示远程邮箱和本地邮箱，如[MBRef]中所述。此选项用于替换RLIST命令，并与已订阅的选择选项一起替换RLSUB命令。
This option defines a new mailbox attribute, "\Remote", that indicates that a mailbox is a remote mailbox. The "\Remote" attribute MUST be accurately computed when the REMOTE option is specified.
此选项定义一个新的邮箱属性“\Remote”，该属性指示邮箱是远程邮箱。指定远程选项时，必须准确计算“\Remote”属性。
The REMOTE selection option has no interaction with other options. Its effect is to tell the server to apply the other options, if
远程选择选项与其他选项没有交互作用。其效果是告诉服务器应用其他选项（如果需要）
any, to remote mailboxes, in addition to local ones. In particular, it has no interaction with RECURSIVEMATCH (see below). A request for (REMOTE RECURSIVEMATCH) is invalid, because a request for (RECURSIVEMATCH) is. A request for (REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, both local and remote.
除本地邮箱外，任何邮箱都可以发送到远程邮箱。特别是，它与RECURSIVEMATCH没有交互（见下文）。对（远程RECURSIVEMATCH）的请求无效，因为对（RECURSIVEMATCH）的请求无效。对（REMOTE RECURSIVEMATCH SUBSCRIBED）的请求请求所有订阅的邮箱，包括本地和远程邮箱。
RECURSIVEMATCH - this option forces the server to return information about parent mailboxes that don't match other selection options, but have some submailboxes that do. Information about children is returned in the CHILDINFO extended data item, as described in Section 3.5.
RECURSIVEMATCH-此选项强制服务器返回与其他选择选项不匹配的父邮箱的信息，但有一些子邮箱可以这样做。如第3.5节所述，在CHILDINFO扩展数据项中返回有关子项的信息。
Note 1: In order for a parent mailbox to be returned, it still has to match the canonical LIST pattern.
注意1：为了返回父邮箱，它仍然必须匹配规范列表模式。
Note 2: When returning the CHILDINFO extended data item, it doesn't matter whether or not the submailbox matches the canonical LIST pattern. See also example 9 in Section 5.
注意2：返回CHILDINFO扩展数据项时，子邮箱是否匹配规范列表模式并不重要。另请参见第5节中的示例9。
The RECURSIVEMATCH option MUST NOT occur as the only selection option (or only with REMOTE), as it only makes sense when other selection options are also used. The server MUST return BAD tagged response in such case.
RECURSIVEMATCH选项不能作为唯一的选择选项出现（或仅与REMOTE一起出现），因为它只有在同时使用其他选择选项时才有意义。在这种情况下，服务器必须返回错误的标记响应。
Note that even if the RECURSIVEMATCH option is specified, the client MUST still be able to handle a case when a CHILDINFO extended data item is returned and there are no submailboxes that meet the selection criteria of the subsequent LIST command, as they can be deleted/renamed after the LIST response was sent, but before the client had a chance to access them.
请注意，即使指定了RECURSIVEMATCH选项，当返回CHILDINFO扩展数据项且没有满足后续LIST命令选择条件的子邮箱时，客户端仍必须能够处理这种情况，因为在发送LIST响应后可以删除/重命名子邮箱，但在客户有机会访问它们之前。
The return options defined in this specification are as follows:
本规范中定义的返回选项如下：
SUBSCRIBED - causes the LIST command to return subscription state for all matching mailbox names. The "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED return option is specified. Further, all mailbox flags MUST be accurately computed (this differs from the behavior of the LSUB command).
SUBSCRIBED-使LIST命令返回所有匹配邮箱名称的订阅状态。必须支持“\Subscribed”属性，并且在指定Subscribed return选项时必须准确计算该属性。此外，必须准确计算所有邮箱标志（这与LSUB命令的行为不同）。
CHILDREN - requests mailbox child information as originally proposed in [CMbox]. See Section 4, below, for details. This option MUST be supported by all servers.
CHILDREN-请求[CMbox]中最初建议的邮箱子信息。详情见下文第4节。所有服务器都必须支持此选项。
This section outlines several principles that can be used by server implementations of this document to decide whether a LIST response should be returned, as well as how many responses and what kind of information they may contain.
本节概述了本文档的服务器实现可以使用的几个原则，以确定是否应返回列表响应，以及响应的数量和可能包含的信息类型。
1. At most one LIST response should be returned for each mailbox name that matches the canonical LIST pattern. Server implementors must not assume that clients will be able to assemble mailbox attributes and other information returned in multiple LIST responses.
1. 对于与规范列表模式匹配的每个邮箱名称，最多应返回一个列表响应。服务器实现者不得假设客户端将能够组装邮箱属性和在多个列表响应中返回的其他信息。
2. There are only two reasons for including a matching mailbox name in the responses to the LIST command (note that the server is allowed to return unsolicited responses at any time, and such responses are not governed by this rule):
2. 在对LIST命令的响应中包含匹配的邮箱名称只有两个原因（请注意，允许服务器随时返回未经请求的响应，此类响应不受此规则的约束）：
A. The mailbox name also satisfies the selection criteria.
A.邮箱名称也满足选择标准。
B. The mailbox name doesn't satisfy the selection criteria, but it has at least one descendant mailbox name that satisfies the selection criteria and that doesn't match the canonical LIST pattern.
B.邮箱名称不满足选择条件，但至少有一个子代邮箱名称满足选择条件，并且与规范列表模式不匹配。
For more information on this case, see the CHILDINFO extended data item described in Section 3.5. Note that the CHILDINFO extended data item can only be returned when the RECURSIVEMATCH selection option is specified.
有关此情况的更多信息，请参阅第3.5节中描述的CHILDINFO扩展数据项。请注意，仅当指定RECURSIVEMATCH选择选项时，才能返回CHILDINFO扩展数据项。
3. Attributes returned in the same LIST response must be treated additively. For example, the following response
3. 必须对同一列表响应中返回的属性进行附加处理。例如，下面的响应
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is subscribed.
表示“水果/桃子”邮箱不存在，但已订阅。
All clients that support this extension MUST treat an attribute with a stronger meaning as implying any attribute that can be inferred from it. For example, the client must treat the presence of the \NoInferiors attribute as if the \HasNoChildren attribute was also sent by the server.
所有支持此扩展的客户端都必须将具有更强含义的属性视为暗示可以从中推断的任何属性。例如，客户端必须将\NoInferiors属性的存在视为\HasNoChildren属性也是由服务器发送的。
The following table summarizes inference rules described in Section 3.
下表总结了第3节中描述的推理规则。
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
The CHILDINFO extended data item MUST NOT be returned unless the client has specified the RECURSIVEMATCH selection option.
除非客户端指定了RECURSIVEMATCH选择选项，否则不能返回CHILDINFO扩展数据项。
The CHILDINFO extended data item in a LIST response describes the selection criteria that has caused it to be returned and indicates that the mailbox has at least one descendant mailbox that matches the selection criteria.
列表响应中的CHILDINFO扩展数据项描述导致其返回的选择条件，并指示邮箱至少有一个与选择条件匹配的子代邮箱。
The LSUB command indicates this condition by using the "\NoSelect" attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since "\NoSelect" retains its original meaning here. Further, the CHILDINFO extended data item is more general, in that it can be used with any extended set of selection criteria.
LSUB命令通过使用“\NoSelect”属性来指示这种情况，但是LIST（SUBSCRIBED）命令不能这样做，因为“\NoSelect”在这里保留其原始含义。此外，CHILDINFO扩展数据项更通用，因为它可以与任何扩展的选择标准集一起使用。
Note: Some servers allow for mailboxes to exist without requiring their parent to exist. For example, a mailbox "Customers/ABC" can exist while the mailbox "Customers" does not. As CHILDINFO extended data item is not allowed if the RECURSIVEMATCH selection option is not specified, such servers SHOULD use the "\NonExistent \HasChildren" attribute pair to signal to the client that there is a descendant mailbox that matches the selection criteria. See example 11 in Section 5.
注意：某些服务器允许邮箱存在，而不要求其父级存在。例如，邮箱“Customers/ABC”可以存在，而邮箱“Customers”则不存在。由于如果未指定RECURSIVEMATCH选择选项，则不允许使用CHILDINFO扩展数据项，因此此类服务器应使用“\NonExistent\HasChildrent”属性对向客户端发出信号，表明存在与选择条件匹配的子代邮箱。参见第5节中的示例11。
The returned selection criteria allow the client to distinguish a solicited response from an unsolicited one, as well as to distinguish among solicited responses caused by multiple pipelined LIST commands that specify different criteria.
返回的选择标准允许客户端区分请求响应和非请求响应，以及区分由指定不同标准的多个流水线列表命令引起的请求响应。
Servers SHOULD ONLY return a non-matching mailbox name along with CHILDINFO if at least one matching child is not also being returned. That is, servers SHOULD suppress redundant CHILDINFO responses.
如果至少有一个匹配的子项未被返回，则服务器应仅返回不匹配的邮箱名称以及CHILDINFO。也就是说，服务器应该抑制冗余的CHILDINFO响应。
Examples 8 and 10 in Section 5 demonstrate the difference between present CHILDINFO extended data item and the "\HasChildren" attribute.
第5节中的示例8和10演示了当前CHILDINFO扩展数据项与“\HasChildren”属性之间的差异。
The following table summarizes interaction between the "\NonExistent" attribute and CHILDINFO (the first column indicates whether the parent mailbox exists):
下表总结了“\NonExistent”属性和CHILDINFO之间的交互（第一列指示父邮箱是否存在）：
+--------+--------------+--------------------+----------------------+
| exists | meets the | has a child that | returned |
| | selection | meets the | LIST-EXTENDED |
| | criteria | selection criteria | attributes and |
| | | | CHILDINFO |
+--------+--------------+--------------------+----------------------+
| no | no | no | no LIST response |
| | | | returned |
| yes | no | no | no LIST response |
| | | | returned |
| no | yes | no | (\NonExistent |
| | | | <attr>) |
| yes | yes | no | (<attr>) |
| no | no | yes | (\NonExistent) + |
| | | | CHILDINFO |
| yes | no | yes | () + CHILDINFO |
| no | yes | yes | (\NonExistent |
| | | | <attr>) + CHILDINFO |
| yes | yes | yes | (<attr>) + CHILDINFO |
+--------+--------------+--------------------+----------------------+
+--------+--------------+--------------------+----------------------+
| exists | meets the | has a child that | returned |
| | selection | meets the | LIST-EXTENDED |
| | criteria | selection criteria | attributes and |
| | | | CHILDINFO |
+--------+--------------+--------------------+----------------------+
| no | no | no | no LIST response |
| | | | returned |
| yes | no | no | no LIST response |
| | | | returned |
| no | yes | no | (\NonExistent |
| | | | <attr>) |
| yes | yes | no | (<attr>) |
| no | no | yes | (\NonExistent) + |
| | | | CHILDINFO |
| yes | no | yes | () + CHILDINFO |
| no | yes | yes | (\NonExistent |
| | | | <attr>) + CHILDINFO |
| yes | yes | yes | (<attr>) + CHILDINFO |
+--------+--------------+--------------------+----------------------+
where <attr> is one or more attributes that correspond to the selection criteria; for example, for the SUBSCRIBED option the <attr> is \Subscribed.
其中<attr>是对应于选择标准的一个或多个属性；例如，对于SUBSCRIBED选项，<attr>是\SUBSCRIBED。
The CHILDREN return option implements the Child Mailbox Extension, originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft Corporation. Most of the information in this section is taken directly from their original specification [CMbox]. The CHILDREN return option is simply an indication that the client wants this information; a server MAY provide it even if the option is not specified.
CHILDREN return选项实现了子邮箱扩展，该扩展最初由Microsoft Corporation的Mike Gahrns和Raymond Cheng提出。本节中的大部分信息直接取自其原始规范[CMbox]。儿童返回选项只是表明客户需要此信息；即使未指定该选项，服务器也可以提供该选项。
Many IMAP4 [IMAP4] 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 visual clue (such as a ''+'') to indicate that there are child mailboxes under a particular mailbox. When the visual clue is
许多IMAP4[IMAP4]客户端向用户呈现用户有权访问的邮箱的分层视图。与其最初向用户显示整个邮箱层次结构，通常更可取的做法是向用户显示邮箱层次结构的折叠大纲列表（特别是在存在大量邮箱的情况下）。然后，用户可以根据需要展开折叠的大纲层次结构。通常在折叠的层次结构中包含可视线索（如“+”），以指示特定邮箱下存在子邮箱。当视觉线索是
clicked, the hierarchy list is expanded to show the child mailboxes. The CHILDREN return option provides a mechanism for a client to efficiently determine whether a particular mailbox has children, without issuing a LIST "" * or a LIST "" % for each mailbox name. The CHILDREN return option defines two new attributes that MUST be returned within a LIST response: \HasChildren and \HasNoChildren. Although these attributes MAY be returned in response to any LIST command, the CHILDREN return option is provided to indicate that the client particularly wants this information. If the CHILDREN return option is present, the server MUST return these attributes even if their computation is expensive.
单击后，层次结构列表将展开以显示子邮箱。CHILDREN return选项为客户端提供了一种机制，可以有效地确定特定邮箱是否有子邮箱，而无需为每个邮箱名称发出列表“”*或列表“”。CHILDREN return选项定义了两个必须在列表响应中返回的新属性：\HasChildren和\HasNoChildren。尽管这些属性可以响应任何LIST命令而返回，但是提供了childrent选项来指示客户机特别需要这些信息。如果存在childrent选项，则服务器必须返回这些属性，即使它们的计算很昂贵。
\HasChildren
\有孩子
The presence of this attribute indicates that the mailbox has child mailboxes. A server SHOULD NOT set this attribute if there are child mailboxes and the user does not have permission to access any of them. In this case, \HasNoChildren SHOULD be used. In many cases, however, a server may not be able to efficiently compute whether a user has access to any child mailbox. Note that even though the \HasChildren attribute for a mailbox must be correct at the time of processing of the mailbox, a client must be prepared to deal with a situation when a mailbox is marked with the \HasChildren attribute, but no child mailbox appears in the response to the LIST command. This might happen, for example, due to children mailboxes being deleted or made inaccessible to the user (using access control) by another client before the server is able to list them.
此属性的存在表示邮箱具有子邮箱。如果存在子邮箱且用户没有访问任何子邮箱的权限，则服务器不应设置此属性。在这种情况下，不应使用儿童。然而，在许多情况下，服务器可能无法有效地计算用户是否有权访问任何子邮箱。请注意，即使邮箱的\HasChildren属性在处理邮箱时必须正确，客户端也必须准备好处理使用\HasChildren属性标记邮箱但在对LIST命令的响应中未显示任何子邮箱的情况。例如，这可能是由于在服务器能够列出子邮箱之前，另一个客户端删除了子邮箱或使其无法访问（使用访问控制）。
\HasNoChildren
\无子女
The presence of this attribute indicates that the mailbox has NO child mailboxes that are accessible to the currently authenticated user.
此属性的存在表示邮箱没有可供当前经过身份验证的用户访问的子邮箱。
It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in the same LIST response.
服务器在同一列表响应中返回\HasChildren和\HasNoChildren属性是错误的。
Note: the \HasNoChildren attribute should not be confused with the IMAP4 [IMAP4] defined attribute \NoInferiors, which indicates that no child mailboxes exist now and none can be created in the future.
注意：不应将\HasNoChildren属性与IMAP4[IMAP4]定义的属性\n周期混淆，这表示现在不存在子邮箱，将来也不能创建子邮箱。
1: The first example shows the complete local hierarchy that will be used for the other examples.
1：第一个示例显示了将用于其他示例的完整本地层次结构。
C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done
C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done
2: In the next example, we will see the subscribed mailboxes. This is similar to, but not equivalent with, <LSUB "" "*">. Note that the mailbox called "Fruit/Peach" is subscribed to, but does not actually exist (perhaps it was deleted while still subscribed). The "Fruit" mailbox is not subscribed to, but it has two subscribed children. The "Vegetable" mailbox is subscribed and has two children; one of them is subscribed as well.
2：在下一个示例中，我们将看到订阅的邮箱。这类似于但不等同于，<LSUB”““*”>。请注意，名为“Fruit/Peach”的邮箱已订阅，但实际上并不存在（可能在订阅时已被删除）。“水果”邮箱未订阅，但它有两个已订阅的子邮箱。“蔬菜”邮箱已订阅，有两个孩子；其中一个也被订阅了。
C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done
C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done
3: The next example shows the use of the CHILDREN option. The client, without having to list the second level of hierarchy, now knows which of the top-level mailboxes have submailboxes (children) and which do not. Note that it's not necessary for the server to return the \HasNoChildren attribute for the inbox, because the \NoInferiors attribute already implies that, and has a stronger meaning.
3：下一个示例显示了CHILDREN选项的使用。客户端不必列出第二级层次结构，现在就可以知道顶级邮箱中哪些有子邮箱（子邮箱），哪些没有子邮箱。请注意，服务器没有必要为收件箱返回\HasNoChildren属性，因为\NoInferiors属性已经暗示了这一点，并且具有更强的含义。
C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done
C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done
4: In this example, we see more mailboxes that reside on another server. This is similar to the command <RLIST "" "%">.
4：在本例中，我们看到更多邮箱位于另一台服务器上。这类似于命令<RLIST”“%”。
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done
5: The following example also requests the server to include mailboxes that reside on another server. The server returns information about all mailboxes that are subscribed. This is similar to the command <RLSUB "" "*">. We also see the use of two selection options.
5:以下示例还请求服务器包含驻留在另一台服务器上的邮箱。服务器返回有关已订阅的所有邮箱的信息。这类似于命令<RLSUB”“*”>。我们还看到了两个选择选项的使用。
C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done
C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done
6: The following example requests the server to include mailboxes that reside on another server. The server is asked to return subscription information for all returned mailboxes. This is different from the example above.
6:以下示例请求服务器包含驻留在另一台服务器上的邮箱。服务器被要求返回所有返回邮箱的订阅信息。这与上面的例子不同。
Note that the output of this command is not a superset of the output in the previous example, as it doesn't include LIST response for the non-existent "Fruit/Peach".
请注意，此命令的输出不是上一示例中输出的超集，因为它不包括不存在的“水果/桃子”的列表响应。
C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat"
S: A06 OK done
C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat"
S: A06 OK done
7: In the following example, the client has specified multiple mailbox patterns. Note that this example does not use the mailbox hierarchy used in the previous examples.
7:在下面的示例中，客户端指定了多个邮箱模式。请注意，此示例不使用前面示例中使用的邮箱层次结构。
C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004"
S: BBB OK done
C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004"
S: BBB OK done
8: The following example demonstrates the difference between the \HasChildren attribute and the CHILDINFO extended data item.
8:以下示例演示\HasChildren属性和CHILDINFO扩展数据项之间的差异。
Let's assume there is the following hierarchy:
假设存在以下层次结构：
C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo"
S: C01 OK done
C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo"
S: C01 OK done
If the client asks RETURN (CHILDREN), it will get this:
如果客户端要求返回（子级），它将得到以下结果：
C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done
C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done
A) Let's also assume that the mailbox "Foo/Baz" is the only subscribed mailbox. Then we get this result:
A） 我们还假设邮箱“Foo/Baz”是唯一订阅的邮箱。然后我们得到这个结果：
C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done
C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done
Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server will return no mailboxes (as the mailboxes "Moo", "Foo", and "Inbox" are NOT subscribed). However, if the client issues this:
现在，如果客户端发出<LIST（SUBSCRIBED）“%”，服务器将不返回任何邮箱（因为邮箱“Moo”、“Foo”和“Inbox”未订阅）。但是，如果客户发布以下信息：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
(i.e., the mailbox "Foo" is not subscribed, but it has a child that is.)
（即，邮箱“Foo”未订阅，但它有一个子邮箱。）
A1) If the mailbox "Foo" had also been subscribed, the last command would return this:
A1）如果邮箱“Foo”也已订阅，则最后一个命令将返回以下内容：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
or even this:
甚至这个：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO"
("SUBSCRIBED"))
S: C04 OK done
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO"
("SUBSCRIBED"))
S: C04 OK done
A2) If we assume instead that the mailbox "Foo" is not part of the original hierarchy and is not subscribed, the last command will give this result:
A2）如果我们假设邮箱“Foo”不是原始层次结构的一部分并且未订阅，则最后一个命令将给出以下结果：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
B) Now, let's assume that no mailbox is subscribed. In this case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return no responses, as there are no subscribed children (even though "Foo" has children).
B） 现在，假设没有订阅邮箱。在这种情况下，命令<LIST（SUBSCRIBED RECURSIVEMATCH）“%”将不返回任何响应，因为没有订阅的子级（即使“Foo”有子级）。
C) And finally, suppose that only the mailboxes "Foo" and "Moo" are subscribed. In that case, we see this result:
C） 最后，假设只有邮箱“Foo”和“Moo”被订阅。在这种情况下，我们看到这样的结果：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done
(which means that the mailbox "Foo" has children, but none of them is subscribed).
（这意味着邮箱“Foo”有子项，但没有订阅任何子项）。
9: The following example demonstrates that the CHILDINFO extended data item is returned whether or not children mailboxes match the canonical LIST pattern.
9：以下示例演示了无论子邮箱是否匹配规范列表模式，都将返回CHILDINFO扩展数据项。
Let's assume there is the following hierarchy:
假设存在以下层次结构：
C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "qux2/bar2"
S: D01 OK done
C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "qux2/bar2"
S: D01 OK done
And that the following mailboxes are subscribed:
并已订阅以下邮箱：
C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D02 OK done
C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D02 OK done
The client issues the following command first:
客户端首先发出以下命令：
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
and the server may also include (but this would violate a SHOULD NOT in Section 3.5, because CHILDINFO is redundant)
服务器还可能包括（但这将违反第3.5节中的a，因为CHILDINFO是冗余的）
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
The CHILDINFO extended data item is returned for mailboxes "foo2", "baz2", and "eps2", because all of them have subscribed children, even though for the mailbox "foo2" only one of the two subscribed children matches the pattern, for the mailbox "baz2" all the subscribed children match the pattern, and for the mailbox "eps2" none of the subscribed children matches the pattern.
对于邮箱“foo2”、“baz2”和“eps2”，会返回CHILDINFO扩展数据项，因为它们都有订阅的子项，即使对于邮箱“foo2”，两个订阅的子项中只有一个匹配该模式，对于邮箱“baz2”，所有订阅的子项都匹配该模式，对于邮箱“eps2”没有订阅的子项与模式匹配。
Note that if the client issues
请注意，如果客户端出现问题
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
The LIST responses for mailboxes "foo2", "baz2", and "eps2" still have the CHILDINFO extended data item, even though this information is redundant and the client can determine it by itself.
邮箱“foo2”、“baz2”和“eps2”的列表响应仍然具有CHILDINFO扩展数据项，即使此信息是冗余的，并且客户端可以自行确定。
10: The following example shows usage of multiple mailbox patterns. It also demonstrates that the presence of the CHILDINFO extended data item doesn't necessarily imply \HasChildren.
10:下面的示例显示了多个邮箱模式的用法。它还表明CHILDINFO扩展数据项的存在并不一定意味着\HasChildren。
C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo
S: a1 OK done
C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo
S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done
11: The following example shows how a server that supports missing mailbox hierarchy elements can signal to a client that didn't specify the RECURSIVEMATCH selection option that there is a child mailbox that matches the selection criteria.
11:以下示例显示了支持缺少邮箱层次结构元素的服务器如何向未指定RECURSIVEMATCH选择选项的客户端发出信号，表明存在与选择条件匹配的子邮箱。
C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz
S: a1 OK done
C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz
S: a1 OK done
C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done
C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done
C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
S: a3 OK done
C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
S: a3 OK done
C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock
S: a3.1 OK done
C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock
S: a3.1 OK done
Because "music/rock" is the only mailbox under "music", there's no need for the server to also return "music". However clients must handle both cases.
由于“music/rock”是“music”下的唯一邮箱，服务器无需同时返回“music”。然而，客户必须处理这两种情况。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [ABNF]. Terms not defined here are taken from [IMAP4]. In particular, note that the version of "mailbox-list" below, which defines the payload of the LIST response, updates the version defined in the IMAP specification. It is pointed to by "mailbox-data", which is defined in [IMAP4].
以下语法规范使用[ABNF]中所述的增广的Backus Naur形式（ABNF）。此处未定义的术语取自[IMAP4]。特别要注意，下面定义列表响应有效负载的“邮箱列表”版本更新了IMAP规范中定义的版本。它由[IMAP4]中定义的“邮箱数据”指向。
"vendor-token" is defined in [ACAP]. Note that this normative reference to ACAP will be an issue in moving this spec forward, since it introduces a dependency on ACAP. The definitions of "vendor-token" and of the IANA registry must eventually go somewhere else, in a document that can be moved forward on the standards track independently of ACAP.
“供应商令牌”在[ACAP]中定义。请注意，此对ACAP的规范性引用将是本规范向前发展的一个问题，因为它引入了对ACAP的依赖。“供应商代币”和IANA注册中心的定义最终必须放在其他地方，在一个可以独立于ACAP在标准轨道上向前移动的文档中。
childinfo-extended-item = "CHILDINFO" SP "("
list-select-base-opt-quoted
*(SP list-select-base-opt-quoted) ")"
; Extended data item (mbox-list-extended-item)
; returned when the RECURSIVEMATCH
; selection option is specified.
; Note 1: the CHILDINFO tag can be returned
; with and without surrounding quotes, as per
; mbox-list-extended-item-tag production.
; Note 2: The selection options are always returned
; quoted, unlike their specification in
; the extended LIST command.
childinfo-extended-item = "CHILDINFO" SP "("
list-select-base-opt-quoted
*(SP list-select-base-opt-quoted) ")"
; Extended data item (mbox-list-extended-item)
; returned when the RECURSIVEMATCH
; selection option is specified.
; Note 1: the CHILDINFO tag can be returned
; with and without surrounding quotes, as per
; mbox-list-extended-item-tag production.
; Note 2: The selection options are always returned
; quoted, unlike their specification in
; the extended LIST command.
child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; attributes for CHILDREN return option, at most one
; possible per LIST response
child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; attributes for CHILDREN return option, at most one
; possible per LIST response
eitem-standard-tag = atom ; a tag for extended list data defined in a Standard ; Track or Experimental RFC.
eitem标准标签=原子；用于标准中定义的扩展列表数据的标记；跟踪或实验RFC。
eitem-vendor-tag = vendor-token "-" atom ; a vendor-specific tag for extended list data
eitem供应商标签=供应商令牌“-”原子；扩展列表数据的特定于供应商的标记
list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat [SP list-return-opts]
list=“list”[SP list select opts]SP邮箱SP mbox或pat[SP list return opts]
list-return-opts = "RETURN" SP "(" [return-option *(SP return-option)] ")" ; list return options, e.g., CHILDREN
列表返回选项=“返回”SP”（“[返回选项*（SP返回选项）]”）；列出返回选项，例如子项
list-select-base-opt = "SUBSCRIBED" / option-extension ; options that can be used by themselves
列表选择base opt=“SUBSCRIBED”/option扩展；可以自己使用的选项
list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
list-select-independent-opt = "REMOTE" / option-extension ; options that do not syntactically interact with ; other options
列表选择独立opt=“REMOTE”/opt扩展；在语法上不与之交互的选项；其他选择
list-select-mod-opt = "RECURSIVEMATCH" / option-extension ; options that require a list-select-base-opt ; to also be present
列表选择mod opt=“RECURSIVEMATCH”/option扩展；需要列表的选项选择基本选项；出席
list-select-opt = list-select-base-opt / list-select-independent-opt / list-select-mod-opt ; An option registration template is described in ; Section 9.3 of this document.
列表选择选项=列表选择基本选项/列表选择独立选项/列表选择修改选项；选项注册模板如中所述；本文件第9.3节。
list-select-opts = "(" [
(*(list-select-opt SP) list-select-base-opt
*(SP list-select-opt))
/ (list-select-independent-opt
*(SP list-select-independent-opt))
] ")"
; Any number of options may be in any order.
; If a list-select-mod-opt appears, then a
; list-select-base-opt must also appear.
; This allows these:
; ()
; (REMOTE)
; (SUBSCRIBED)
; (SUBSCRIBED REMOTE)
; (SUBSCRIBED RECURSIVEMATCH)
; (SUBSCRIBED REMOTE RECURSIVEMATCH)
; But does NOT allow these:
; (RECURSIVEMATCH)
; (REMOTE RECURSIVEMATCH)
list-select-opts = "(" [
(*(list-select-opt SP) list-select-base-opt
*(SP list-select-opt))
/ (list-select-independent-opt
*(SP list-select-independent-opt))
] ")"
; Any number of options may be in any order.
; If a list-select-mod-opt appears, then a
; list-select-base-opt must also appear.
; This allows these:
; ()
; (REMOTE)
; (SUBSCRIBED)
; (SUBSCRIBED REMOTE)
; (SUBSCRIBED RECURSIVEMATCH)
; (SUBSCRIBED REMOTE RECURSIVEMATCH)
; But does NOT allow these:
; (RECURSIVEMATCH)
; (REMOTE RECURSIVEMATCH)
mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] ; This is the list information pointed to by the ABNF ; item "mailbox-data", which is defined in [IMAP4]
邮箱列表=“（“[mbx列表标志]”）SP（DQUOTE QUOTE-CHAR DQUOTE/nil）SP邮箱[SP mbox列表扩展]；这是ABNF指出的列表信息；[IMAP4]中定义的“邮箱数据”项
mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")"
mbox列表扩展=“（“[mbox列表扩展项*（SP mbox列表扩展项）]”）
mbox-list-extended-item = mbox-list-extended-item-tag SP tagged-ext-val
mbox列表扩展项=mbox列表扩展项标记SP tagged ext val
mbox-list-extended-item-tag = astring
; The content MUST conform to either "eitem-vendor-tag"
; or "eitem-standard-tag" ABNF productions.
; A tag registration template is described in this
; document in Section 9.5.
mbox-list-extended-item-tag = astring
; The content MUST conform to either "eitem-vendor-tag"
; or "eitem-standard-tag" ABNF productions.
; A tag registration template is described in this
; document in Section 9.5.
mbx-list-oflag =/ child-mbox-flag / "\Subscribed" / "\Remote"
mbx-list-oflag =/ child-mbox-flag / "\Subscribed" / "\Remote"
mbx-list-sflag =/ "\NonExistent"
mbx列表sflag=/“\n不存在”
mbox-or-pat = list-mailbox / patterns
mbox-or-pat = list-mailbox / patterns
option-extension = (option-standard-tag / option-vendor-tag)
[SP option-value]
option-extension = (option-standard-tag / option-vendor-tag)
[SP option-value]
option-standard-tag = atom ; an option defined in a Standards Track or ; Experimental RFC
选项标准标签=原子；标准轨道或轨道中定义的选项；实验RFC
option-val-comp = astring /
option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")"
option-val-comp = astring /
option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")"
option-value = "(" option-val-comp ")"
选项值=“（“选项值补偿”）”
option-vendor-tag = vendor-token "-" atom ; a vendor-specific option, non-standard
选项供应商标签=供应商令牌“-”原子；供应商特定选项，非标准
patterns = "(" list-mailbox *(SP list-mailbox) ")"
patterns = "(" list-mailbox *(SP list-mailbox) ")"
return-option = "SUBSCRIBED" / "CHILDREN" / option-extension
return-option = "SUBSCRIBED" / "CHILDREN" / option-extension
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
; Extensions that follow this general
; syntax should use nstring instead of
; astring when appropriate in the context
; of the extension.
; Note that a message set or a "number"
; can always be represented as an "atom".
; A URL should be represented as
; a "quoted" string.
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
; Extensions that follow this general
; syntax should use nstring instead of
; astring when appropriate in the context
; of the extension.
; Note that a message set or a "number"
; can always be represented as an "atom".
; A URL should be represented as
; a "quoted" string.
tagged-ext-simple = sequence-set / number
tagged-ext-simple = sequence-set / number
tagged-ext-val = tagged-ext-simple / "(" [tagged-ext-comp] ")"
tagged ext val=tagged ext simple/“（“[tagged ext comp]”）
The LIST command selection option types defined in this specification involve simple tests of mailbox properties. However, future extensions to LIST-EXTENDED may define selection options that do more sophisticated tests. In the case of a test that requires matching text, in the presence of the COMPARATOR [I18N] extension, the active comparator must be used to do comparisons. Such LIST-EXTENDED extensions MUST indicate in their specification the interaction with the COMPARATOR [I18N] extension.
本规范中定义的列表命令选择选项类型涉及邮箱属性的简单测试。然而，列表扩展的未来扩展可能会定义进行更复杂测试的选择选项。如果测试需要匹配文本，在比较器[I18N]扩展存在的情况下，必须使用活动比较器进行比较。这种列表扩展扩展必须在其规范中指明与比较器[I18N]扩展的交互。
This document describes syntactic changes to the specification of the IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST command has the same security considerations as those commands. They are described in [IMAP4] and [MBRef].
本文档描述了对IMAP4命令列表、LSUB、RLIST和RLSUB规范的语法更改，修改后的列表命令与这些命令具有相同的安全注意事项。它们在[IMAP4]和[MBRef]中有描述。
The Child Mailbox 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 any child mailbox. 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. In most situations, this will not be a security concern, because if information regarding whether a mailbox has children is considered sensitive, a user would not be granted access to that mailbox in the first place.
子邮箱扩展为客户端提供了一种更有效的方法来确定特定邮箱是否有子邮箱。如果邮箱有子项，但当前经过身份验证的用户无权访问其中任何子项，则服务器应使用\HasNoChildren属性进行响应。然而，在许多情况下，服务器可能无法有效地计算用户是否有权访问任何子邮箱。如果这样的服务器使用\HasChildren属性响应，而实际上当前经过身份验证的用户没有访问任何子邮箱的权限，则可能会传递比预期更多的有关邮箱的信息。在大多数情况下，这不是一个安全问题，因为如果有关邮箱是否有子邮箱的信息被视为敏感信息，则用户首先不会被授予访问该邮箱的权限。
The CHILDINFO extended data item has the same security considerations as the \HasChildren attribute described above.
CHILDINFO扩展数据项与上述\HasChildren属性具有相同的安全注意事项。
IANA has created two new registries for LIST-EXTENDED options and LIST-EXTENDED response data. The templates and the initial registrations are detailed below.
IANA为列表扩展选项和列表扩展响应数据创建了两个新的注册表。下面详细介绍了模板和初始注册。
Registration of a LIST-EXTENDED option is done by filling in the template in Section 9.3 and sending it via electronic mail to iana@iana.org. Registration of a LIST-EXTENDED extended data item is done by filling in the template in Section 9.5 and sending it via electronic mail to iana@iana.org. IANA has the right to reject obviously bogus registrations, but will perform no review of claims made in the registration form.
通过填写第9.3节中的模板并通过电子邮件发送给iana@iana.org. 通过填写第9.5节中的模板并通过电子邮件发送给iana@iana.org. IANA有权拒绝明显虚假的注册，但不会对注册表格中的索赔进行审查。
A LIST-EXTENDED option/extended data item name that starts with "V-" is reserved for vendor-specific options/extended data items. All options, whether they are vendor specific or global, should be registered with IANA. If a LIST-EXTENDED extended data item is returned as a result of requesting a particular LIST-EXTENDED option,
以“V-”开头的列表扩展选项/扩展数据项名称保留给特定于供应商的选项/扩展数据项。所有选项，无论是供应商特定选项还是全局选项，都应向IANA注册。如果由于请求特定的列表扩展选项而返回列表扩展数据项，
the name of the option SHOULD be used as the name of the LIST-EXTENDED extended data item.
选项的名称应用作列表扩展数据项的名称。
Each vendor-specific option/extended data item MUST start with its vendor-token ("vendor prefix"). The vendor-token MUST be registered with IANA, using the [ACAP] vendor subtree registry.
每个特定于供应商的选项/扩展数据项必须以其供应商令牌（“供应商前缀”）开头。供应商令牌必须使用[ACAP]供应商子树注册表向IANA注册。
Standard LIST-EXTENDED option/extended data item names are case insensitive. If the vendor prefix is omitted from a vendor-specific LIST-EXTENDED option/extended data item name, the rest is case insensitive. The vendor prefix itself is not case sensitive, as it might contain non-ASCII characters. While the registration procedures do not require it, authors of LIST-EXTENDED options/extended data items are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an Internet-Draft. LIST-EXTENDED option/extended data items intended for widespread use should be standardized through the normal IETF process, when appropriate.
标准列表扩展选项/扩展数据项名称不区分大小写。如果特定于供应商的列表扩展选项/扩展数据项名称中省略了供应商前缀，则其余前缀不区分大小写。供应商前缀本身不区分大小写，因为它可能包含非ASCII字符。虽然注册程序不要求，但鼓励列表扩展选项/扩展数据项的作者在可行时寻求社区审查和评论。作者可以通过将其建议机制的规范发布为互联网草案来寻求社区审查。适用时，应通过正常的IETF流程对广泛使用的列表扩展选项/扩展数据项进行标准化。
Comments on registered LIST-EXTENDED options/extended response data should first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG mailing list. Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the registration itself. If IANA approves of this, the comment will be made accessible in conjunction with the registration LIST-EXTENDED options/extended response data itself.
关于已注册列表扩展选项/扩展响应数据的评论应首先发送给机制的“所有者”和/或IMAPEXT WG邮件列表。在合理尝试联系所有者后，意见提交人可要求IANA将其意见附在注册本身上。如果IANA批准，评论将与注册列表-扩展选项/扩展响应数据一起提供。
Once a LIST-EXTENDED registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
IANA发布列表扩展注册后，作者可要求更改其定义。变更请求遵循与注册请求相同的程序。
The owner of a LIST-EXTENDED registration may pass responsibility for the registered option/extended data item to another person or agency by informing IANA; this can be done without discussion or review.
列表扩展注册的所有者可以通过通知IANA将注册选项/扩展数据项的责任转移给另一个人或机构；这可以在不进行讨论或审查的情况下完成。
The IESG may reassign responsibility for a LIST-EXTENDED option/extended data item. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community.
IESG可重新分配列表扩展选项/扩展数据项的责任。最常见的情况是，当注册作者去世、失去联系或无法进行对社区重要的更改时，可以对机制进行更改。
LIST-EXTENDED registrations may not be deleted; mechanisms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field. Such LIST-EXTENDED options/extended data items will be clearly marked in the lists published by IANA.
不得删除列表扩展注册；通过更改“预期用途”字段，可以宣布不再适合使用的机制已过时。IANA发布的列表中将明确标记此类列表扩展选项/扩展数据项。
The IESG is considered to be the owner of all LIST-EXTENDED options/extended data items that are on the IETF standards track.
IESG被认为是IETF标准轨道上所有列表扩展选项/扩展数据项的所有者。
To: iana@iana.org Subject: Registration of LIST-EXTENDED option X
致：iana@iana.org主题：登记列表扩展选项X
LIST-EXTENDED option name:
列表-扩展选项名称：
LIST-EXTENDED option type: (One of SELECTION or RETURN)
列表扩展选项类型：（选择或返回之一）
Implied return options(s), if the option type is SELECTION: (zero or more)
隐含回报选项，如果选项类型为选择：（零或更多）
LIST-EXTENDED option description:
列表-扩展选项说明：
Published specification (optional, recommended):
发布的规范（可选，推荐）：
Security considerations:
安全考虑：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
预期用途：（通用、有限用途或过时）
Person and email address to contact for further information:
Person and email address to contact for further information:translate error, please retry
Owner/Change controller:
业主/变更控制人：
(Any other information that the author deems interesting may be added below this line.)
（作者认为有趣的任何其他信息可添加在此行下方。）
The LIST-EXTENDED option registry has been populated with the following entries:
列表扩展选项注册表已填充以下条目：
1. To: iana@iana.org Subject: Registration of LIST-EXTENDED option SUBSCRIBED
1. 致：iana@iana.org主题：登记已认购的列表扩展期权
LIST-EXTENDED option name: SUBSCRIBED
列表-扩展选项名称：已订阅
LIST-EXTENDED option type: SELECTION
列表扩展选项类型：选择
Implied return options(s): SUBSCRIBED
隐含回报期权：已认购
LIST-EXTENDED option description: Causes the LIST command to list subscribed mailboxes, rather than the actual mailboxes.
LIST-EXTENDED选项说明：使LIST命令列出已订阅的邮箱，而不是实际的邮箱。
Published specification: RFC 5258, Section 3.
出版规范：RFC 5258，第3节。
Security considerations: RFC 5258, Section 8.
安全注意事项：RFC 5258，第8节。
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
2. To: iana@iana.org Subject: Registration of LIST-EXTENDED option REMOTE
2. 致：iana@iana.org主题：注册列表扩展选项远程
LIST-EXTENDED option name: REMOTE
列表扩展选项名称：远程
LIST-EXTENDED option type: SELECTION
列表扩展选项类型：选择
Implied return options(s): (none)
隐含回报期权：（无）
LIST-EXTENDED option description: Causes the LIST command to return remote mailboxes as well as local ones, as described in RFC 2193.
LIST-EXTENDED选项说明：导致LIST命令返回远程邮箱和本地邮箱，如RFC 2193中所述。
Published specification: RFC 5258, Section 3.
出版规范：RFC 5258，第3节。
Security considerations: RFC 5258, Section 8.
安全注意事项：RFC 5258，第8节。
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
3. To: iana@iana.org Subject: Registration of LIST-EXTENDED option SUBSCRIBED
3. 致：iana@iana.org主题：登记已认购的列表扩展期权
LIST-EXTENDED option name: SUBSCRIBED
列表-扩展选项名称：已订阅
LIST-EXTENDED option type: RETURN
列表扩展选项类型：返回
LIST-EXTENDED option description: Causes the LIST command to return subscription state.
LIST-EXTENDED选项说明：导致LIST命令返回订阅状态。
Published specification: RFC 5258, Section 3.
出版规范：RFC 5258，第3节。
Security considerations: RFC 5258, Section 8.
安全注意事项：RFC 5258，第8节。
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
4. To: iana@iana.org Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
4. 致：iana@iana.org主题：注册列表扩展选项RECURSIVEMATCH
LIST-EXTENDED option name: RECURSIVEMATCH
列表扩展选项名称：RECURSIVEMATCH
LIST-EXTENDED option type: SELECTION
列表扩展选项类型：选择
Implied return options(s): (none)
隐含回报期权：（无）
LIST-EXTENDED option description: Requests that CHILDINFO extended data item (childinfo-extended-item) is to be returned.
列表扩展选项说明：请求返回CHILDINFO扩展数据项（CHILDINFO扩展项）。
Published specification: RFC 5258, Section 3.
出版规范：RFC 5258，第3节。
Security considerations: RFC 5258, Section 8.
安全注意事项：RFC 5258，第8节。
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
5. To: iana@iana.org Subject: Registration of LIST-EXTENDED option CHILDREN
5. 致：iana@iana.org主题：列表扩展选项子项的注册
LIST-EXTENDED option name: CHILDREN
列表扩展选项名称：子项
LIST-EXTENDED option type: RETURN
列表扩展选项类型：返回
LIST-EXTENDED option description: Requests mailbox child information.
列表扩展选项说明：请求邮箱子信息。
Published specification: RFC 5258, Section 3 and Section 4.
已发布规范：RFC 5258，第3节和第4节。
Security considerations: RFC 5258, Section 8.
安全注意事项：RFC 5258，第8节。
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
To: iana@iana.org Subject: Registration of X LIST-EXTENDED extended data item
致：iana@iana.org主题：X列表扩展数据项的注册
LIST-EXTENDED extended data item tag:
列表-扩展数据项标记：
LIST-EXTENDED extended data item description:
列表-扩展数据项说明：
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any):
哪些列表扩展选项（及其类型）导致返回此扩展数据项（如果有）：
Published specification (optional, recommended):
发布的规范（可选，推荐）：
Security considerations:
安全考虑：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
预期用途：（通用、有限用途或过时）
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Owner/Change controller:
业主/变更控制人：
(Any other information that the author deems interesting may be added below this line.)
（作者认为有趣的任何其他信息可添加在此行下方。）
The LIST-EXTENDED extended data item registry has been populated with the following entries:
列表扩展数据项注册表已填充以下项：
1. To: iana@iana.org Subject: Registration of CHILDINFO LIST-EXTENDED extended data item
1. 致：iana@iana.org主题：注册CHILDINFO列表-扩展数据项
LIST-EXTENDED extended data item tag: CHILDINFO
列表-扩展数据项标记：CHILDINFO
LIST-EXTENDED extended data item description: The CHILDINFO extended data item describes the selection criteria that has caused it to be returned and indicates that the mailbox has one or more child mailboxes that match the selection criteria.
LIST-EXTENDED EXTENDED data item description:CHILDINFO EXTENDED data item描述导致其返回的选择条件，并指示邮箱具有一个或多个与选择条件匹配的子邮箱。
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): RECURSIVEMATCH selection option
哪个列表扩展选项（及其类型）导致返回此扩展数据项（如果有）：递归匹配选择选项
Published specification: RFC 5258, Section 3.5.
出版规范：RFC 5258，第3.5节。
Security considerations: RFC 5258, Section 8.
安全注意事项：RFC 5258，第8节。
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
Mike Gahrns and Raymond Cheng of Microsoft Corporation originally devised the Child Mailbox Extension and proposed it in 1997; the idea, as well as most of the text in Section 4, is theirs.
微软公司的Mike Gahrns和Raymond Cheng最初设计了儿童邮箱扩展，并于1997年提出；这个想法以及第4节中的大部分文本都是他们的。
This document is the result of discussions on the IMAP4 and IMAPEXT mailing lists and is meant to reflect consensus of those groups. In particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry Greenfield, Dave Cridland, and Pete Maclean were active participants in those discussions or made suggestions to this document.
本文件是关于IMAP4和IMAPEXT邮件列表讨论的结果，旨在反映这些群体的共识。特别是，马克·克里斯宾、菲利普·根瑟、赛勒斯·达布、蒂莫·西莱宁、肯·默奇森、罗伯·西姆博斯基、史蒂夫·霍尔、阿恩特·古尔布兰森、拉里·格林菲尔德、戴夫·克里德兰和皮特·麦克林都是这些讨论的积极参与者，或对本文件提出了建议。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[I18N]Newman，C.，Gulbrandsen，A.，和A.Melnikov，“互联网消息访问协议国际化”，RFC 5255，2008年6月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[Kwds]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 1997.
[MBRef]Gahrns，M.，“IMAP4邮箱转介”，RFC 2193，1997年9月。
[CMbox] Gahrns, M. and R. Cheng, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", RFC 3348, July 2002.
[CMbox]Gahrns，M.和R.Cheng，“互联网消息操作协议（IMAP4）子邮箱扩展”，RFC 3348，2002年7月。
Authors' Addresses
作者地址
Barry Leiba IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
Barry Leiba IBM T.J.Watson研究中心美国纽约州霍桑市天际大道19号，邮编10532
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
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.