IMAP4 Extension for Returning STATUS Information in Extended LIST
draft-ietf-morg-status-in-list-01
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5819.
|
|
|---|---|---|---|
| Authors | Timo Sirainen , Alexey Melnikov | ||
| Last updated | 2020-01-21 (Latest revision 2009-05-13) | ||
| Replaces | draft-melnikov-imapext-status-in-list | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5819 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Lisa M. Dusseault | ||
| Send notices to | (None) |
draft-ietf-morg-status-in-list-01
IMAPEXT A. Melnikov
Internet-Draft Isode Limited
Intended status: Standards Track T. Sirainen
Expires: November 13, 2009 May 12, 2009
IMAP4 Extension for returning STATUS information in extended LIST
draft-ietf-morg-status-in-list-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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, to list all
Melnikov & Sirainen Expires November 13, 2009 [Page 1]
Internet-Draft STATUS in IMAP LIST May 2009
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.
Note
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
morg@ietf.org.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . . 3
2. STATUS return option to LIST command . . . . . . . . . . . . . 3
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Melnikov & Sirainen Expires November 13, 2009 [Page 2]
Internet-Draft STATUS in IMAP LIST May 2009
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 STATUS command for each mailbox returned by the LIST command.
This behaviour 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 command with a new return option: STATUS.
This option takes STATUS data items as parameters. For each
selectable 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 situation the LIST command would still return a tagged OK
reply.
Melnikov & Sirainen Expires November 13, 2009 [Page 3]
Internet-Draft STATUS in IMAP LIST May 2009
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.
"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.
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.
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], [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 they are interested in. 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.
Melnikov & Sirainen Expires November 13, 2009 [Page 4]
Internet-Draft STATUS in IMAP LIST May 2009
6. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located
at:
http://www.iana.org/assignments/imap4-capabilities
This document defines the X-DRAFT-I00-LIST-STATUS [[anchor4: Note to
RFC Editor: fix before publication]] IMAP capability. IANA is
requested to add it to the registry.
IANA is also requested to add 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.
Published specification : XXXX.
Security considerations: XXXX.
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.
Melnikov & Sirainen Expires November 13, 2009 [Page 5]
Internet-Draft STATUS in IMAP LIST May 2009
8. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314.
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command
Extensions", RFC 5258, 2008.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
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 Expires November 13, 2009 [Page 6]