rfc3348.txt (11868B)
1 2 3 4 5 6 7 Network Working Group M. Gahrns 8 Request for Comments: 3348 R. Cheng 9 Category: Informational Microsoft 10 July 2002 11 12 13 The Internet Message Action Protocol (IMAP4) 14 Child Mailbox Extension 15 16 Status of this Memo 17 18 This memo provides information for the Internet community. It does 19 not specify an Internet standard of any kind. Distribution of this 20 memo is unlimited. 21 22 Copyright Notice 23 24 Copyright (C) The Internet Society (2002). All Rights Reserved. 25 26 Abstract 27 28 The Internet Message Action Protocol (IMAP4) CHILDREN extension 29 provides a mechanism for a client to efficiently determine if a 30 particular mailbox has children, without issuing a LIST "" * or a 31 LIST "" % for each mailbox. 32 33 1. Conventions used in this document 34 35 In examples, "C:" and "S:" indicate lines sent by the client and 36 server respectively. If such lines are wrapped without a new "C:" or 37 "S:" label, then the wrapping is for editorial clarity and is not 38 part of the command. 39 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC-2119]. 43 44 2. Introduction and Overview 45 46 Many IMAP4 [RFC-2060] clients present to the user a hierarchical view 47 of the mailboxes that a user has access to. Rather than initially 48 presenting to the user the entire mailbox hierarchy, it is often 49 preferable to show to the user a collapsed outline list of the 50 mailbox hierarchy (particularly if there is a large number of 51 mailboxes). The user can then expand the collapsed outline hierarchy 52 as needed. It is common to include within the collapsed hierarchy a 53 54 55 56 57 58 Gahrns, et al. Informational [Page 1] 59 60 RFC 3348 IMAP4 Child Mailbox Extension July 2002 61 62 63 visual clue (such as a "+") to indicate that there are child 64 mailboxes under a particular mailbox. When the visual clue is 65 clicked the hierarchy list is expanded to show the child mailboxes. 66 67 Several IMAP vendors implemented this proposal, and it is proposed to 68 document this behavior and functionality as an Informational RFC. 69 70 There is interest in addressing the general extensibility of the IMAP 71 LIST command through an IMAP LIST Extension draft. Similar 72 functionality to the \HasChildren and \HasNoChildren flags could be 73 incorporated into this new LIST Extension. It is proposed that the 74 more general LIST Extension draft proceed on the standards track with 75 this proposal being relegated to informational status only. 76 77 If the functionality of the \HasChildren and \HasNoChildren flags 78 were incorporated into a more general LIST extension, this would have 79 the advantage that a client could then have the opportunity to 80 request whether or not the server should return this information. 81 This would be an advantage over the current draft for servers where 82 this information is expensive to compute, since the server would only 83 need to compute the information when it knew that the client 84 requesting the information was able to consume it. 85 86 3. Requirements 87 88 IMAP4 servers that support this extension MUST list the keyword 89 CHILDREN in their CAPABILITY response. 90 91 The CHILDREN extension defines two new attributes that MAY be 92 returned within a LIST response. 93 94 \HasChildren - The presence of this attribute indicates that the 95 mailbox has child mailboxes. 96 97 Servers SHOULD NOT return \HasChildren if child mailboxes exist, but 98 none will be displayed to the current user in a LIST response (as 99 should be the case where child mailboxes exist, but a client does not 100 have permissions to access them.) In this case, \HasNoChildren 101 SHOULD be used. 102 103 In many cases, however, a server may not be able to efficiently 104 compute whether a user has access to all child mailboxes, or multiple 105 users may be accessing the same account and simultaneously changing 106 the mailbox hierarchy. As such a client MUST be prepared to accept 107 the \HasChildren attribute as a hint. That is, a mailbox MAY be 108 flagged with the \HasChildren attribute, but no child mailboxes will 109 appear in a subsequent LIST response. 110 111 112 113 114 Gahrns, et al. Informational [Page 2] 115 116 RFC 3348 IMAP4 Child Mailbox Extension July 2002 117 118 119 Example 3.1: 120 ============ 121 122 /*** Consider a server that has the following mailbox hierarchy: 123 124 INBOX 125 ITEM_1 126 ITEM_1A 127 ITEM_2 128 TOP_SECRET 129 130 Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is a 131 child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2 132 that the currently logged on user does NOT have access to. 133 134 Note that in this case, the server is not able to efficiently compute 135 access rights to child mailboxes and responds with a \HasChildren 136 attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not 137 appear in the list response. ***/ 138 139 C: A001 LIST "" * 140 S: * LIST (\HasNoChildren) "/" INBOX 141 S: * LIST (\HasChildren) "/" ITEM_1 142 S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A 143 S: * LIST (\HasChildren) "/" ITEM_2 144 S: A001 OK LIST Completed 145 146 \HasNoChildren - The presence of this attribute indicates that the 147 mailbox has NO child mailboxes that are accessible to the currently 148 authenticated user. If a mailbox has the \Noinferiors attribute, the 149 \HasNoChildren attribute is redundant and SHOULD be omitted in the 150 LIST response. 151 152 In some instances a server that supports the CHILDREN extension MAY 153 NOT be able to determine whether a mailbox has children. For example 154 it may have difficulty determining whether there are child mailboxes 155 when LISTing mailboxes while operating in a particular namespace. 156 157 In these cases, a server MAY exclude both the \HasChildren and 158 \HasNoChildren attributes in the LIST response. As such, a client 159 can not make any assumptions about whether a mailbox has children 160 based upon the absence of a single attribute. 161 162 It is an error for the server to return both a \HasChildren and a 163 \HasNoChildren attribute in a LIST response. 164 165 166 167 168 169 170 Gahrns, et al. Informational [Page 3] 171 172 RFC 3348 IMAP4 Child Mailbox Extension July 2002 173 174 175 It is an error for the server to return both a \HasChildren and a 176 \NoInferiors attribute in a LIST response. 177 178 Note: the \HasNoChildren attribute should not be confused with the 179 IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that 180 no child mailboxes exist now and none can be created in the future. 181 182 The \HasChildren and \HasNoChildren attributes might not be returned 183 in response to a LSUB response. Many servers maintain a simple 184 mailbox subscription list that is not updated when the underlying 185 mailbox structure is changed. A client MUST NOT assume that 186 hierarchy information will be maintained in the subscription list. 187 188 RLIST is a command defined in [RFC-2193] that includes in a LIST 189 response mailboxes that are accessible only via referral. That is, a 190 client must explicitly issue an RLIST command to see a list of these 191 mailboxes. Thus in the case where a mailbox has child mailboxes that 192 are available only via referral, the mailboxes would appear as 193 \HasNoChildren in response to the LIST command, and \HasChildren in 194 response to the RLIST command. 195 196 5. Formal Syntax 197 198 The following syntax specification uses the augmented Backus-Naur 199 Form (BNF) as described in [ABNF]. 200 201 Two new mailbox attributes are defined as flag_extensions to the 202 IMAP4 mailbox_list response: 203 204 HasChildren = "\HasChildren" 205 206 HasNoChildren = "\HasNoChildren" 207 208 6. Security Considerations 209 210 This extension provides a client a more efficient means of 211 determining whether a particular mailbox has children. If a mailbox 212 has children, but the currently authenticated user does not have 213 access to any of them, the server SHOULD respond with a 214 \HasNoChildren attribute. In many cases, however, a server may not 215 be able to efficiently compute whether a user has access to all child 216 mailboxes. If such a server responds with a \HasChildren attribute, 217 when in fact the currently authenticated user does not have access to 218 any child mailboxes, potentially more information is conveyed about 219 the mailbox than intended. A server designed with such levels of 220 security in mind SHOULD NOT attach the \HasChildren attribute to a 221 mailbox unless the server is certain that the user has access to at 222 least one of the child mailboxes. 223 224 225 226 Gahrns, et al. Informational [Page 4] 227 228 RFC 3348 IMAP4 Child Mailbox Extension July 2002 229 230 231 7. References 232 233 [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 234 4rev1", RFC 2060, December 1996. 235 236 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 239 [RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for 240 Syntax Specifications: ABNF", RFC 2234, November 1997. 241 242 [RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 243 1997. 244 245 8. Acknowledgments 246 247 The authors would like to thank the participants of several IMC Mail 248 Connect events for their input when this idea was originally 249 presented and refined. 250 251 9. Author's Address 252 253 Mike Gahrns 254 Microsoft 255 One Microsoft Way 256 Redmond, WA, 98052 257 Phone: (425) 936-9833 258 EMail: mikega@microsoft.com 259 260 Raymond Cheng 261 Microsoft 262 One Microsoft Way 263 Redmond, WA, 98052 264 Phone: (425) 703-4913 265 EMail: raych@microsoft.com 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 Gahrns, et al. Informational [Page 5] 283 284 RFC 3348 IMAP4 Child Mailbox Extension July 2002 285 286 287 10. Full Copyright Statement 288 289 Copyright (C) The Internet Society (2002). All Rights Reserved. 290 291 This document and translations of it may be copied and furnished to 292 others, and derivative works that comment on or otherwise explain it 293 or assist in its implementation may be prepared, copied, published 294 and distributed, in whole or in part, without restriction of any 295 kind, provided that the above copyright notice and this paragraph are 296 included on all such copies and derivative works. However, this 297 document itself may not be modified in any way, such as by removing 298 the copyright notice or references to the Internet Society or other 299 Internet organizations, except as needed for the purpose of 300 developing Internet standards in which case the procedures for 301 copyrights defined in the Internet Standards process must be 302 followed, or as required to translate it into languages other than 303 English. 304 305 The limited permissions granted above are perpetual and will not be 306 revoked by the Internet Society or its successors or assigns. 307 308 This document and the information contained herein is provided on an 309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 315 Acknowledgement 316 317 Funding for the RFC Editor function is currently provided by the 318 Internet Society. 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 Gahrns, et al. Informational [Page 6] 339