340 lines
10 KiB
Plaintext
340 lines
10 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2010 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
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.
|
||
|
||
|
||
|
||
Melnikov & Sirainen Standards Track [Page 1]
|
||
|
||
RFC 5819 TITLE* March 2010
|
||
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
1.1. Conventions Used in This Document
|
||
|
||
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.
|
||
|
||
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].
|
||
|
||
2. STATUS Return Option to LIST Command
|
||
|
||
[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
|
||
|
||
|
||
|
||
Melnikov & Sirainen Standards Track [Page 2]
|
||
|
||
RFC 5819 TITLE* March 2010
|
||
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
3. Examples
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Sirainen Standards Track [Page 3]
|
||
|
||
RFC 5819 TITLE* March 2010
|
||
|
||
|
||
4. Formal Syntax
|
||
|
||
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].
|
||
|
||
return-option =/ status-option
|
||
|
||
status-option = "STATUS" SP "(" status-att *(SP status-att) ")"
|
||
;; This ABNF production complies with
|
||
;; <option-extension> syntax.
|
||
|
||
5. Security Considerations
|
||
|
||
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.
|
||
|
||
6. IANA Considerations
|
||
|
||
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:
|
||
|
||
http://www.iana.org
|
||
|
||
This document defines the LIST-STATUS IMAP capability. IANA has
|
||
added it to the registry.
|
||
|
||
IANA has also added the following new LIST-EXTENDED option to the
|
||
IANA registry established by [LISTEXT]:
|
||
|
||
To: iana@iana.org
|
||
Subject: Registration of LIST-EXTENDED option STATUS
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Melnikov & Sirainen Standards Track [Page 4]
|
||
|
||
RFC 5819 TITLE* March 2010
|
||
|
||
|
||
Published specification: RFC 5819
|
||
|
||
Security considerations: RFC 5819
|
||
|
||
Intended usage: COMMON
|
||
|
||
Person and email address to contact for further information:
|
||
Alexey Melnikov <Alexey.Melnikov@isode.com>
|
||
|
||
Owner/Change controller: iesg@ietf.org
|
||
|
||
7. Acknowledgements
|
||
|
||
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.
|
||
|
||
8. Normative References
|
||
|
||
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
|
||
Syntax Specifications: ABNF", STD 68, RFC 5234, January
|
||
2008.
|
||
|
||
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
|
||
RFC 4314, December 2005.
|
||
|
||
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[LISTEXT] Leiba, B. and A. Melnikov, "Internet Message Access
|
||
Protocol version 4 - LIST Command Extensions", RFC 5258,
|
||
June 2008.
|
||
|
||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||
4rev1", RFC 3501, March 2003.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Sirainen Standards Track [Page 5]
|
||
|
||
RFC 5819 TITLE* March 2010
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Alexey Melnikov
|
||
Isode Limited
|
||
5 Castle Business Village
|
||
36 Station Road
|
||
Hampton, Middlesex TW12 2BX
|
||
UK
|
||
|
||
EMail: Alexey.Melnikov@isode.com
|
||
URI: http://www.melnikov.ca/
|
||
|
||
|
||
Timo Sirainen
|
||
|
||
EMail: tss@iki.fi
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov & Sirainen Standards Track [Page 6]
|
||
|