Internet Engineering Task Force (IETF)                       A. Melnikov
Request for Comments: 5819                                 Isode Limited
Category: Standards Track                                    T. Sirainen
ISSN: 2070-1721                                             Unaffiliated
                                                              March 2010
        
Internet Engineering Task Force (IETF)                       A. Melnikov
Request for Comments: 5819                                 Isode Limited
Category: Standards Track                                    T. Sirainen
ISSN: 2070-1721                                             Unaffiliated
                                                              March 2010
        

IMAP4 Extension for Returning STATUS Information in Extended LIST

IMAP4扩展,用于在扩展列表中返回状态信息

Abstract

摘要

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command.

许多IMAP客户端显示有关IMAP邮箱中的邮件总数/未查看邮件总数的信息。为了做到这一点,他们必须发出LIST或LSUB命令,列出所有可用的邮箱,然后对找到的每个邮箱执行STATUS命令。此文档提供了对LIST命令的扩展,该命令允许客户端请求邮箱的状态信息以及通常由LIST命令返回的其他信息。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5819.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc5819.

Copyright Notice

版权公告

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. STATUS Return Option to LIST Command ............................2
   3. Examples ........................................................3
   4. Formal Syntax ...................................................4
   5. Security Considerations .........................................4
   6. IANA Considerations .............................................4
   7. Acknowledgements ................................................5
   8. Normative References ............................................5
        
   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. STATUS Return Option to LIST Command ............................2
   3. Examples ........................................................3
   4. Formal Syntax ...................................................4
   5. Security Considerations .........................................4
   6. IANA Considerations .............................................4
   7. Acknowledgements ................................................5
   8. Normative References ............................................5
        
1. Introduction
1. 介绍

Many IMAP clients display information about the total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command.

许多IMAP客户端显示有关IMAP邮箱中的邮件总数/未查看邮件总数的信息。为了做到这一点,他们必须发出LIST或LSUB命令,列出所有可用的邮箱,然后对找到的每个邮箱执行STATUS命令。此文档提供了对LIST命令的扩展,该命令允许客户端请求邮箱的状态信息以及通常由LIST命令返回的其他信息。

1.1. Conventions Used in This Document
1.1. 本文件中使用的公约

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", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Kwds].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[Kwds]中所述进行解释。

2. STATUS Return Option to LIST Command
2. 列表命令的状态返回选项

[RFC3501] explicitly disallows mailbox patterns in the STATUS command. The main reason was to discourage frequent use of the STATUS command by clients, as it might be quite expensive for an IMAP server to perform. However, this prohibition had resulted in an opposite effect: a new generation of IMAP clients appeared, that issues a STATUS command for each mailbox returned by the LIST command. This behavior is suboptimal to say at least. It wastes extra bandwidth and, in the case of a client that doesn't support IMAP pipelining, also degrades performance by using too many round trips. This document tries to remedy the situation by specifying a single command that can be used by the client to request all the necessary information. In order to achieve this goal, this document is extending the LIST command with a new return option, STATUS. This option takes STATUS data items as parameters. For each selectable

[RFC3501]明确禁止STATUS命令中的邮箱模式。主要原因是不鼓励客户机频繁使用STATUS命令,因为IMAP服务器执行该命令可能会非常昂贵。但是,这一禁令产生了相反的效果:出现了新一代IMAP客户端,它为LIST命令返回的每个邮箱发出STATUS命令。至少可以说,这种行为是次优的。它浪费了额外的带宽,并且在不支持IMAP管道的客户端中,由于使用了太多的往返,性能也会下降。本文档试图通过指定一个命令来纠正这种情况,客户端可以使用该命令来请求所有必要的信息。为了实现这一目标,本文使用新的返回选项STATUS扩展LIST命令。此选项将状态数据项作为参数。对于每个可选择的

mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option.

在与列表模式和选择选项匹配的邮箱中,服务器必须返回未标记的列表响应,然后返回包含状态返回选项中请求的信息的未标记状态响应。

If an attempted STATUS for a listed mailbox fails because the mailbox can't be selected (e.g., if the "l" ACL right [ACL] is granted to the mailbox and the "r" right is not granted, or due to a race condition between LIST and STATUS changing the mailbox to \NoSelect), the STATUS response MUST NOT be returned and the LIST response MUST include the \NoSelect attribute. This means the server may have to buffer the LIST reply until it has successfully looked up the necessary STATUS information.

如果由于无法选择邮箱而导致列表邮箱的尝试状态失败(例如,如果向邮箱授予“l”ACL权限[ACL],而未授予“r”权限,或者由于列表和状态之间的竞争条件,将邮箱更改为\n选择),不能返回状态响应,列表响应必须包含\n选择属性。这意味着服务器可能必须缓冲列表回复,直到成功查找必要的状态信息。

If the server runs into unexpected problems while trying to look up the STATUS information, it MAY drop the corresponding STATUS reply. In such a situation, the LIST command would still return a tagged OK reply.

如果服务器在试图查找状态信息时遇到意外问题,它可能会删除相应的状态回复。在这种情况下,LIST命令仍将返回带标记的OK应答。

3. Examples
3. 例子
   C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
   S: * LIST () "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
   S: * LIST () "." "foo"
   S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
   S: * LIST (\NoSelect) "." "bar"
   S: A01 OK List completed.
        
   C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
   S: * LIST () "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
   S: * LIST () "." "foo"
   S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
   S: * LIST (\NoSelect) "." "bar"
   S: A01 OK List completed.
        

The "bar" mailbox isn't selectable, so it has no STATUS reply.

“bar”邮箱不可选择,因此没有状态回复。

   C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
      (MESSAGES))
   S: * LIST (\Subscribed) "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.
        
   C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
      (MESSAGES))
   S: * LIST (\Subscribed) "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.
        

The LIST reply for "foo" is returned because it has matching children, but no STATUS reply is returned because "foo" itself doesn't match the selection criteria.

返回“foo”的列表答复是因为它有匹配的子项,但没有返回状态答复,因为“foo”本身与选择条件不匹配。

4. Formal Syntax
4. 形式语法

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF]. Terms not defined here are taken from [RFC3501] and [LISTEXT].

以下语法规范使用[ABNF]中所述的增广巴科斯诺尔形式(BNF)。此处未定义的术语取自[RFC3501]和[ListText]。

return-option =/ status-option

返回选项=/status选项

status-option = "STATUS" SP "(" status-att *(SP status-att) ")" ;; This ABNF production complies with ;; <option-extension> syntax.

status option=“status”SP”(“status att*(SP status att)”)”;;本ABNF产品符合<选项扩展>语法。

5. Security Considerations
5. 安全考虑

This extension makes it a bit easier for clients to overload the server by requesting STATUS information for a large number of mailboxes. However, as already noted in the introduction, existing clients already try to do that by generating a large number of STATUS commands for each mailbox in which they are interested. While performing STATUS information retrieval for big lists of mailboxes, a server implementation needs to make sure that it can still serve other IMAP connections and yield execution to other connections, when necessary.

此扩展通过请求大量邮箱的状态信息,使客户端更容易过载服务器。但是,正如介绍中已经提到的,现有客户端已经尝试通过为它们感兴趣的每个邮箱生成大量状态命令来实现这一点。在对大的邮箱列表执行状态信息检索时,服务器实现需要确保它仍然可以为其他IMAP连接提供服务,并在必要时让其他连接执行。

6. IANA Considerations
6. IANA考虑

IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The "IMAP 4 Capabilities" registry is available from the IANA webiste:

IMAP4功能通过发布标准跟踪或IESG批准的实验RFC进行注册。“IMAP 4功能”注册表可从IANA webiste获得:

      http://www.iana.org
        
      http://www.iana.org
        

This document defines the LIST-STATUS IMAP capability. IANA has added it to the registry.

本文档定义了列表状态IMAP功能。IANA已将其添加到注册表中。

IANA has also added the following new LIST-EXTENDED option to the IANA registry established by [LISTEXT]:

IANA还向[ListText]建立的IANA注册表添加了以下新的列表扩展选项:

To: iana@iana.org Subject: Registration of LIST-EXTENDED option STATUS

致:iana@iana.org主题:列表扩展选项状态的注册

LIST-EXTENDED option name: STATUS

列表-扩展选项名称:状态

LIST-EXTENDED option type: RETURN

列表扩展选项类型:返回

LIST-EXTENDED option description: Causes the LIST command to return STATUS responses in addition to LIST responses.

LIST-EXTENDED选项说明:使LIST命令除了返回LIST响应外,还返回状态响应。

Published specification: RFC 5819

已发布规范:RFC 5819

Security considerations: RFC 5819

安全注意事项:RFC 5819

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
        
7. Acknowledgements
7. 致谢

Thanks to Philip Van Hoof who pointed out that STATUS and LIST commands should be combined in order to optimize traffic and number of round trips.

感谢Philip Van Hoof,他指出应该结合状态和列表命令,以优化交通和往返次数。

8. Normative References
8. 规范性引用文件

[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月。

[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.

[ACL]Melnikov,A.,“IMAP4访问控制列表(ACL)扩展”,RFC 4314,2005年12月。

[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[Kwds]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[LISTEXT] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, June 2008.

[ListText]Leiba,B.和A.Melnikov,“互联网消息访问协议第4版-列表命令扩展”,RFC 5258,2008年6月。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3501]Crispin,M.,“互联网消息访问协议-版本4rev1”,RFC 35012003年3月。

Authors' Addresses

作者地址

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/
        

Timo Sirainen

蒂莫·西莱宁

   EMail: tss@iki.fi
        
   EMail: tss@iki.fi