Internet Draft J. Neystadt draft-neystadt-imap-status-counters-00.txt Comverse Technology Expires: October 2002 April 2002 IMAP4 rev1 û STATUS-COUNTERS Extension Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 1. Abstract This document describes STATUS-COUNTERS extension to IMAP4rev1 protocol. This extension enables Mail User Agents to retrieve messages counters grouped by message context. Neystadt Expires - October 2002 [Page 1] IMAP4 rev1 û STATUS-EX Extension April 2002 2. Table of Contents 1. Abstract......................................................1 2. Table of Contents.............................................2 3. Requirements..................................................2 4. Conventions Used in this Document.............................3 5. Introduction and Overview.....................................3 6. Open Issues for Discussion....................................3 7. Features......................................................3 7.1 CAPABILITY................................................3 7.2 STATUS command............................................3 7.3 COUNTERS response.........................................4 8. Implementation Guidelines.....................................5 8.1 Server Issues.............................................5 8.2 Client Issues.............................................6 9. Formal Syntax.................................................6 10. Security Considerations......................................6 11. References...................................................6 12. Change Log...................................................7 13. Author's Addresses...........................................7 3. Requirements [IMAP4] defines a STATUS command that enables Mail User Agent to query status of mailboxes on the server. [UM-ISSUES] documents outline a number of additional requirements beyond that RFC. The following are the requirements with some adaptations. [UM-ISSUES] 2.2.1 Mailbox Summary (Per-context counters in mailbox status command) The common TUI prompt "you have two new voice messages, six unheard messages, and one new fax message" requires more information than is made available by IMAP. The IMAP status command provides a count of new and total messages with standardized attributes extracted from the message headers. This pre-determined information does not include information about the message type. Without defined conventions to the status command, a client would have to download the header for each message to determine its type. There should be an extensible mechanism for sending arbitrary message summary data in the LIST command. With proper MTA support for the necessary message-context attribute and support for reading the flags, a single command can extract enough data to count the messages in various categories. For adequate performance, the MTA must pre-parse the messages to extract the necessary information into an index for this request as messages are deposited. Neystadt Expires - October 2002 [Page 2] IMAP4 rev1 û STATUS-EX Extension April 2002 4. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 5. Introduction and Overview The STATUS-COUNTERS extends existing [IMAP]Æs STATUS command. This command enables the following functionality: Enable MUA to get mailbox counters per groups of messages according Message-Context attribute. For example MUA can know that Inbox contain 5 unseen fax messages. 6. Open Issues for Discussion - Currently there is no way to request counters of per only specific message context. If MUA requests new ôCOUNTERSö data item it will get them all. This can be wasteful on large amount of folders. On other hand this would complicate the command furthermore. If somebody thinks this must be added, please say so. - Should EXAMINE and SELECT include COUNTERS untagged response as well? - Current proposal suggests a fixed counters list (UNSEEN, EXISTS, IMPORTANT, RECENT), instead we could define that COUNTER receives a list of counters definitions. Every counter will be defined as using SEARCHÆes syntax. Internally server will do SEARCH, count the results and return the number. This is more complicate, but more generic and flexible. 7. Features 7.1 CAPABILITY The STATUS-COUNTERS extension may be used with any IMAP4 server implementation that returns "STATUS-COUNTERS" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise the STATUS-COUNTERS capability, the client MUST NOT use the STATUS-COUNTERS extension and continue working with multiple old STATUS commands and FETCHes as specified in the base IMAP specification. 7.2 STATUS command Neystadt Expires - October 2002 [Page 3] IMAP4 rev1 û STATUS-EX Extension April 2002 A new meta-data item named COUNTERS is added to existing data items of STATUS. Syntax: COUNTERS[status data item names] New data item: IMPORTANCE New untagged response COUNTERS should be returned if COUNTERS were requested. Response to COUNTERS can be slow, since some server implementations may need to go over whole mailbox and traverse all message headers in order to calculate counters. UIDNEXT and UIDVALIDITY should not be passed as parameters to COUNTERS, since they cannot be grouped by Message-Context. STATUS-COUNTERS defines new data item û ôIMPORTANCEö which is defined as all messages whose æImportance:Æ MIME header value is æHighÆ. Example: C: A CAPABILITY S: * CAPABILITY ... STATUS-COUNTERS ... S: A OK CAPABILITY ... C: B STATUS Inbox (UIDNEXT UIDVALIDITY COUNTERS(MESSAGES UNSEEN IMPORTANT RECENT)) S: * STATUS Inbox (UIDNEXT 850 UIDVALIDITY 1234 COUNTERS ( All ((MESSAGES 100 Unseen 30 Important 20 Unseen-Important 10 Recent 5) "Voice-Message" (MESSAGES 10 Unseen 3 Important 2 Unseen-Important 1 Recent 5) "Fax-Message" (MESSAGES 10 Unseen 3 Important 2 Unseen-Important 1 Recent 5))) S: B OK STATUS completed. 7.3 COUNTERS response Contents: parenthesized list messages groups (by Message-Context) each one including parenthesized list of counters COUNTERS response list is of the following form: (Group1 (Attribute1 Value Attribute2 Value) Group2 (à) à) Group names can either be Message-Context keywords as defined in [Message-Context] (i.e. Voice-Message, Fax-Message, à) or ôAllö. Neystadt Expires - October 2002 [Page 4] IMAP4 rev1 û STATUS-EX Extension April 2002 ôAllö is a special tag used to indicate aggregated counters of all messages, ignoring Message-Context attribute. Message-Context is determined by inspecting Message-Context MIME header of the message and extracting its value. If no messages of given context is present in the mailbox, the response for it is not sent (like of no SMS messages in the example). Valid group attributes are STATUS data items. Here are the details of the counters: Messages, Recent, These attributes have same meaning like in Unseen STATUS defined in imap, but are returned per given Message-Context (or All). Important Number of important messages per given Message-Context (or All). Unseen-Important Number of messages that are both Unseen and Important per given Message-Context (or All). This extension allows imap server to implement additional attributes and provide it per message-context (i.e. X-My-Special- Counter) See previous section for the example of COUNTERS response. 8. Implementation Guidelines 8.1 Server Issues Since in order to calculate message counters the MIME headers of the messages are inspected, this calculation can consume significant amount of resources and time. Server implementations are recommended to generate the counters during the submission of the message (in MTA) or persistently cache it after they are calculated 1st time. MUAs are expected to queries for all counters of all subscribed mailboxes during every login, in order to display to the user the status of his mail account and enable to select mailboxes with important or unseen messages. So counters should be stored per mailbox and their retrieval should be lightweight. Neystadt Expires - October 2002 [Page 5] IMAP4 rev1 û STATUS-EX Extension April 2002 8.2 Client Issues Is imap server implementation does not support this command, its logic can be achieved by the following algorithm: For the given mailbox do: 1. a SELECT mailbox 2. b FETCH 1:* BODY[HEADER (Importance Message-Context)] 3. Calculate the counters from FETCH responses. This approach puts a burden on server (if performed on each login) and generates a lot of traffic. It is expected that MUAs will need to request STATUS-COUNTERS for all generating mailboxes list for display. MUA should not request STATUS-COUNTERS for all mailboxes on the server, since the amount can be extremely large. Instead MUAs should request STATUS-COUNTERS only mailbox that subscriber wants to feet the display or the list of the one he has subscribed to (obtained with LSUB). 9. Formal Syntax To be written after initial approval by workgroupà 10. Security Considerations There is a potential inconsistency that may be introduced by server between actual messages in the mailboxes and information report by STATUS-EX. This can happen if the server maliciously reports wrong information. User Agents must not rely blindly on the correspondence between STAUS-EX and messages themselves. It can be resource consuming for some server implementations to handle STATUS-EX command with large list of mailboxes. This can potentially facilitate DoS attack. It is recommended for servers to implement artificial delay between two subsequent STATUS-EX commands. 11. References [IMAP4], Crispin, M., "Internet Message Access Protocol û Version 4rev1", RFC 2060, December 1996. [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for Syntax Specifications: ABNF", Work in Progress. Neystadt Expires - October 2002 [Page 6] IMAP4 rev1 û STATUS-EX Extension April 2002 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [UM-ISSUES] Vaudreuil, G., ôMessaging profile for telephone-based Messaging clientsö, draft-vaudreuil-um-issues-00, February 21, 2002. [Message-Context] Burger, E., et al, ôMessage Context for Internet Mailö, draft-ietf-vpim-hint-07, June 5, 2001. [VPIM] Vaudreuil, G., ôVoice Profile for Internetö, RFC 1911, February 1996. 12. Change Log 00 Initial Revision. 13. Author's Addresses John Neystadt Comverse Technology Habarzel 29, Ramat Hahayal Phone: +972-3-645-4185 Tel-Aviv, Israel, 69710 Email: john@comverse.com Neystadt Expires - October 2002 [Page 7]