idnits 2.17.1 draft-melnikov-imapext-status-in-list-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 264. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2008) is 5799 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group/MORG A. Melnikov 3 BOF Isode Limited 4 Internet-Draft T. Sirainen 5 Intended status: Standards Track June 10, 2008 6 Expires: December 12, 2008 8 IMAP4 Extension for returning STATUS information in extended LIST 9 draft-melnikov-imapext-status-in-list-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 12, 2008. 36 Abstract 38 Many IMAP clients display information about total number of messages/ 39 total number of unseen messages in IMAP mailboxes. In order to do 40 that they are forced to issue a LIST or LSUB command, to list all 41 available mailboxes, followed by a STATUS command for each mailbox 42 found. This document provides an extension to LIST command that 43 allows the client to request STATUS information for mailboxes 44 together with other information typically returned by the LIST 45 command. 47 Note 49 A revised version of this draft document will be submitted to the RFC 50 editor as a Proposed Standard for the Internet Community. Discussion 51 and suggestions for improvement are requested, and should be sent to 52 morg@ietf.org. 54 Table of Contents 56 1. Conventions used in this document . . . . . . . . . . . . . . . 3 58 2. STATUS return option to LIST command . . . . . . . . . . . . . 3 60 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 73 Intellectual Property and Copyright Statements . . . . . . . . 7 75 1. Conventions used in this document 77 In examples, "C:" indicates lines sent by a client that is connected 78 to a server. "S:" indicates lines sent by the server to the client. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [Kwds]. 84 2. STATUS return option to LIST command 86 [RFC3501] explicitly disallows mailbox patterns in the STATUS 87 command. The main reason was to discourage frequent use of the 88 STATUS command by clients, as it might be quite expensive for an IMAP 89 server to perform. However this prohibition had resulted in an 90 opposite effect: a new generation of IMAP clients appeared, that 91 issues STATUS command for each mailbox returned by the LIST command. 92 This behaviour is suboptimal to say at least: it wastes extra 93 bandwidth and, in the case of a client that doesn't support IMAP 94 pipelining, also degrades performance by using too many round trips. 95 This document tries to remedy the situation by specifying a single 96 command that can be used by the client to request all the necessary 97 information. In order to achieve this goal this document is 98 extending the LIST command command with a new return option: STATUS. 99 This option takes STATUS data items as parameters. For each 100 selectable mailbox matching the list pattern and selection options, 101 the server MUST return an untagged LIST response followed by an 102 untagged STATUS response containing the information requested in the 103 STATUS return option. 105 If an attempted STATUS for a listed mailbox fails because the mailbox 106 can't be selected (e.g. if the "l" ACL right [ACL] is granted to the 107 mailbox and the "r" right is not granted, or due to a race condition 108 between LIST and STATUS changing the mailbox to \NoSelect), the 109 STATUS response MUST NOT be returned and the LIST response MUST 110 include the \NoSelect attribute. This means the server may have to 111 buffer the LIST reply until it has successfully looked up the 112 necessary STATUS information. 114 3. Examples 116 C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN)) 117 S: * LIST () "." "INBOX" 118 S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16) 119 S: * LIST () "." "foo" 120 S: * STATUS "foo" (MESSAGES 30 UNSEEN 29) 121 S: * LIST (\NoSelect) "." "bar" 122 S: A01 OK List completed. 124 "bar" mailbox isn't selectable, so it has no STATUS reply. 126 C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS 127 (MESSAGES)) 128 S: * LIST (\Subscribed) "." "INBOX" 129 S: * STATUS "INBOX" (MESSAGES 17) 130 S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED")) 131 S: A02 OK List completed. 133 LIST reply for "foo" is returned because it has matching children, 134 but no STATUS reply is returned because "foo" itself doesn't match 135 the selection criteria. 137 4. Formal Syntax 139 The following syntax specification uses the augmented Backus-Naur 140 Form (BNF) as described in [ABNF]. Terms not defined here are taken 141 from [RFC3501], [LISTEXT]. 143 return-option =/ status-option 145 status-option = "STATUS" SP "(" status-att *(SP status-att) ")" 146 ;; This ABNF production complies with 147 ;; syntax. 149 5. Security Considerations 151 [[anchor4: TBD]] 153 6. IANA Considerations 155 IMAP4 capabilities are registered by publishing a standards track or 156 IESG approved experimental RFC. The registry is currently located 157 at: 159 http://www.iana.org/assignments/imap4-capabilities 161 This document defines the X-DRAFT-I00-LIST-STATUS [[anchor5: Note to 162 RFC Editor: fix before publication]] IMAP capability. IANA is 163 requested to add it to the registry. 165 IANA is also requested to add the following new LIST-EXTENDED option 166 to the IANA registry established by [LISTEXT]: 168 To: iana@iana.org 169 Subject: Registration of LIST-EXTENDED option STATUS 171 LIST-EXTENDED option name: STATUS 173 LIST-EXTENDED option type: RETURN 175 LIST-EXTENDED option description: Causes the LIST command to return 176 STATUS responses in addition to LIST responses. 178 Published specification : XXXX. 180 Security considerations: XXXX. 182 Intended usage: COMMON 184 Person and email address to contact for further information: Alexey 185 Melnikov 187 Owner/Change controller: iesg@ietf.org 189 7. Acknowledgements 191 TBD. 193 8. Normative References 195 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 196 Specifications: ABNF", RFC 5234, January 2008. 198 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 199 RFC 4314. 201 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", RFC 2119, March 1997. 204 [LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command 205 Extensions", RFC 5258, 2008. 207 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 208 4rev1", RFC 3501, March 2003. 210 Authors' Addresses 212 Alexey Melnikov 213 Isode Limited 214 5 Castle Business Village 215 36 Station Road 216 Hampton, Middlesex TW12 2BX 217 UK 219 Email: Alexey.Melnikov@isode.com 220 URI: http://www.melnikov.ca/ 222 Timo Sirainen 224 Email: tss@iki.fi 226 Full Copyright Statement 228 Copyright (C) The IETF Trust (2008). 230 This document is subject to the rights, licenses and restrictions 231 contained in BCP 78, and except as set forth therein, the authors 232 retain all their rights. 234 This document and the information contained herein are provided on an 235 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 236 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 237 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 238 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 239 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 240 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 242 Intellectual Property 244 The IETF takes no position regarding the validity or scope of any 245 Intellectual Property Rights or other rights that might be claimed to 246 pertain to the implementation or use of the technology described in 247 this document or the extent to which any license under such rights 248 might or might not be available; nor does it represent that it has 249 made any independent effort to identify any such rights. Information 250 on the procedures with respect to rights in RFC documents can be 251 found in BCP 78 and BCP 79. 253 Copies of IPR disclosures made to the IETF Secretariat and any 254 assurances of licenses to be made available, or the result of an 255 attempt made to obtain a general license or permission for the use of 256 such proprietary rights by implementers or users of this 257 specification can be obtained from the IETF on-line IPR repository at 258 http://www.ietf.org/ipr. 260 The IETF invites any interested party to bring to its attention any 261 copyrights, patents or patent applications, or other proprietary 262 rights that may cover technology that may be required to implement 263 this standard. Please address the information to the IETF at 264 ietf-ipr@ietf.org.