idnits 2.17.1 draft-ietf-imapext-list-extensions-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MboxRefer]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 2001) is 8413 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 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) == Outdated reference: A later version (-04) exists of draft-gahrns-imap-child-mailbox-03 ** Downref: Normative reference to an Informational draft: draft-gahrns-imap-child-mailbox (ref. 'ChildMbox') ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group B. Leiba 3 Internet Draft IBM T.J. Watson Research Center 4 Document: draft-ietf-imapext-list-extensions-00.txt October 2000 5 Expires April 2001 7 IMAP4 LIST Command Extensions 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 A revised version of this draft document will be submitted to the RFC 29 editor as an Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested, and should 31 be sent to ietf-imapext@imc.org. This document will expire before 30 32 April 2001. Distribution of this memo is unlimited. 34 1. Abstract 36 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we 37 add extensions that require specialized lists (see [MboxRefer] for an 38 example) we expand the number of list commands, as each extension 39 must add its function to both LIST and LSUB. This document describes 40 extensions to the LIST command that allow these additions to be done 41 in mutually compatible options to the LIST command, avoiding the 42 exponential increase in specialized list commands. 44 B. Leiba Expires April 2001 [Page 45 1] 46 Internet DRAFT IMAP4 LIST Command Extensions October 2000 48 2. Conventions used in this document 50 In examples, "C:" indicates lines sent by a client that is connected 51 to a server. "S:" indicates lines sent by the server to the client. 53 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 54 used in this document as specified in RFC 2119 [Keywords]. 56 3. Introduction 58 The extensions to the LIST command will be accomplished by amending 59 the syntax to allow options to be specified. The list of options 60 will replace the several commands that are currently used to mix and 61 match the information requested. The new syntax is backward- 62 compatible, with no ambiguity: if the first word after the command 63 name begins with a parenthesis, the new syntax is being used; if it 64 does not, it's in the original syntax. 66 By adding options to the LIST command, we are announcing the intent 67 to phase out and eventually to deprecate the base LSUB command as 68 well as the RLIST and RLSUB commands described in [MboxRefer]. We 69 are also defining the mechanism to request extended mailbox 70 information, such as is described in the now-expired "Child Mailbox 71 Extension" draft [ChildMbox]. 73 4. LIST Command Options 75 The LIST command syntax is extended by adding a parenthesized list of 76 command options between the command name and the reference name (see 77 the formal syntax in section 6 for specific details). Command 78 options will be defined in this document and in approved extension 79 documents; each option will be enabled by a capability string (one 80 capability may enable multiple options), and a client MUST NOT send 81 an option for which the server has not advertised support. A server 82 MAY ignore options it does not recognize. 84 This extension is identified by the capability string "LISTEXT", and 85 support for it is a prerequisite for any future extensions that 86 require specialized forms of the LIST command. Such extensions MUST 87 refer to this document and MUST add their function through command 88 options as described herein. 90 The options defined in this specification are 91 SUBSCRIBED - causes the LIST command to list subscribed 92 mailboxes, rather than the actual mailboxes. This will often 93 be a subset of the actual mailboxes. It's also possible for 94 this list to contain the names of mailboxes that don't exist. 96 Internet DRAFT IMAP4 LIST Command Extensions October 2000 98 In any case, the list MUST include exactly those mailbox names 99 that match the selection criteria and are subscribed to. This 100 option is intended to replace the LSUB command, and MUST be 101 supported by all servers. 102 REMOTE - causes the LIST command to show remote mailboxes as 103 well as local ones, as described in [MboxRefer]. This option 104 is intended to replace the RLIST command and, in conjunction 105 with the SUBSCRIBED option, the RLSUB command. This option is 106 only available on servers that also support RFC-2193. 107 CHILDREN - Requests mailbox child information as originally 108 proposed in [ChildMbox]. See section 5, below, for details. 109 Support for this is optional, but this option MUST be accepted 110 by all servers (though it MAY be ignored). 112 5. The CHILDREN Option 114 The CHILDREN option implements the Child Mailbox Extension, 115 originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft 116 Corporation. Most of the information in this section is taken 117 directly from their original specification [ChildMbox]. The CHILDREN 118 option is simply an indication that the client wants this 119 information; a server MAY provide it even if the option is not 120 specified, or MAY ignore the option entirely. 122 Many IMAP4 [IMAP4] clients present to the user a hierarchical view of 123 the mailboxes that a user has access to. Rather than initially 124 presenting to the user the entire mailbox hierarchy, it is often 125 preferable to show to the user a collapsed outline list of the 126 mailbox hierarchy (particularly if there is a large number of 127 mailboxes). The user can then expand the collapsed outline hierarchy 128 as needed. It is common to include within the collapsed hierarchy a 129 visual clue (such as a ''+'') to indicate that there are child 130 mailboxes under a particular mailbox. When the visual clue is 131 clicked the hierarchy list is expanded to show the child mailboxes. 133 The Child Mailbox Extension provides a mechanism for a client to 134 efficiently determine if a particular mailbox has children, without 135 issuing a LIST '' * or a LIST '' % for each mailbox name. 137 The Child Mailbox Extension defines two new attributes that MAY be 138 returned within a LIST response: \HasChildren and \HasNoChildren. 139 While these attributes MAY be returned in response to any LIST 140 command, the CHILDREN option is provided to indicate that the client 141 particularly wants this information. If the CHILDREN option is 142 present, the server SHOULD return these attributes even if their 143 computation is expensive. 145 \HasChildren - The presence of this attribute indicates that the mailbox 146 Internet DRAFT IMAP4 LIST Command Extensions October 2000 148 has child mailboxes. 150 A server SHOULD NOT set this attribute if there are child 151 mailboxes, and the user does not have permissions to access any 152 of them. In this case, \HasNoChildren SHOULD be used. 154 In many cases, however, a server may not be able to efficiently 155 compute whether a user has access to all child mailboxes. As 156 such a client MUST be prepared to accept the \HasChildren 157 attribute as a hint. That is, a mailbox MAY be flagged with the 158 \HasChildren attribute, but no child mailboxes will appear in 159 the LIST response. 161 \HasNoChildren - The presence of this attribute indicates that the 162 mailbox has NO child mailboxes that are accessible to the 163 currently authenticated user. 165 In some instances a server that supports the Child Mailbox Extension 166 might not be able to determine whether a mailbox has children. For 167 example it may have difficulty determining whether there are child 168 mailboxes when LISTing mailboxes while operating in a particular 169 namespace. 171 In these cases, a server MAY exclude both the \HasChildren and 172 \HasNoChildren attributes in the LIST response. As such, a client 173 can not make any assumptions about whether a mailbox has children 174 based upon the absence of a single attribute. In particular, some 175 servers may not be able to combine the SUBSCRIBED and CHILDREN 176 options. Such servers MUST honour the SUBSCRIBED option, and they 177 will simply ignore the CHILDREN option if both are requested. 179 It is an error for the server to return both a \HasChildren and a 180 \HasNoChildren attribute in a LIST response. 182 Note: the \HasNoChildren attribute should not be confused with the 183 IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no 184 child mailboxes exist now and none can be created in the future. 186 6. Examples 188 The first example shows the complete local hierarchy that will be 189 used for the other examples. 191 C: A01 LIST "" "*" 192 S: * LIST (\Marked \NoInferiors) "/" "inbox" 193 S: * LIST () "/" "Fruit" 194 S: * LIST () "/" "Fruit/Apple" 195 S: * LIST () "/" "Fruit/Banana" 197 Internet DRAFT IMAP4 LIST Command Extensions October 2000 199 S: * LIST () "/" "Tofu" 200 S: * LIST () "/" "Vegetable" 201 S: * LIST () "/" "Vegetable/Broccoli" 202 S: A01 OK done 204 In the next example, we'll see the subscribed mailboxes. This is 205 equivalent to . Note that the mailbox called 206 "Fruit/Peach" is subscribed to, but does not actually exist (perhaps 207 it was deleted while still subscribed). 209 C: A02 LIST (SUBSCRIBE) "" "*" 210 S: * LIST (\Marked \NoInferiors) "/" "inbox" 211 S: * LIST () "/" "Fruit" 212 S: * LIST () "/" "Fruit/Banana" 213 S: * LIST () "/" "Fruit/Peach" 214 S: A02 OK done 216 The next example shows the use of the CHILDREN option. The client, 217 without having to list the second level of hierarchy, now knows which 218 of the top-level mailboxes have sub-mailboxes (children) and which do 219 not. Note that it's not necessary for the server to return the 220 \HasNoChildren flag for the inbox, because the \NoInferiors flag 221 already implies that, and has a stronger meaning. 223 C: A03 LIST (CHILDREN) "" "%" 224 S: * LIST (\Marked \NoInferiors) "/" "inbox" 225 S: * LIST (\HasChildren) "/" "Fruit" 226 S: * LIST (\HasNoChildren) "/" "Tofu" 227 S: * LIST (\HasChildren) "/" "Vegetable" 228 S: A03 OK done 230 In this example we see more mailboxes, which reside on another server 231 to which we may obtain referrals. This is similar to the command 232 . We also see the mixing of two options. Note that in 233 the case of the remote mailboxes, the server might or might not be 234 able to include CHILDREN information; it includes it if it can, and 235 omits it if it can't. 237 C: A04 LIST (REMOTE CHILDREN) "" "%" 238 S: * LIST (\Marked \NoInferiors) "/" "inbox" 239 S: * LIST (\HasChildren) "/" "Fruit" 240 S: * LIST (\HasNoChildren) "/" "Tofu" 241 S: * LIST (\HasChildren) "/" "Vegetable" 242 S: * LIST () "/" "Bread" 243 S: * LIST (\HasChildren) "/" "Meat" 244 S: A04 OK done 246 B. Leiba Expires April 2001 [Page 247 5] 249 Internet DRAFT IMAP4 LIST Command Extensions October 2000 251 7. Formal Syntax 253 The following syntax specification uses the augmented Backus-Naur 254 Form (BNF) as described in [ABNF]. Terms not defined here are taken 255 from [IMAP4]. 257 child-mbox-flag = "\HasChildren" / "\HasNoChildren" 258 ; flags for Child Mailbox Extension, at most one 259 ; possible per LIST response 261 list = "LIST" [SP list-options] SP mailbox SP list-mailbox 263 list-options = "(" [option *(SP option)] ")" 265 mbox-list-oflag := child-mbox-flag 267 option = "SUBSCRIPTIONS" / "CHILDREN" / "REMOTE" / 268 option-extension 270 option-extension = atom 272 8. Security Considerations 274 This document describes syntactic changes to the specification of the 275 IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST 276 command has the same security considerations as those commands. They 277 are described in [IMAP4] and [MboxRefer]. 279 The Child Mailbox Extension provides a client a more efficient means 280 of determining whether a particular mailbox has children. If a 281 mailbox has children, but the currently authenticated user does not 282 have access to any of them, the server SHOULD respond with a 283 \HasNoChildren attribute. In many cases, however, a server may not 284 be able to efficiently compute whether a user has access to all child 285 mailboxes. If such a server responds with a \HasChildren attribute, 286 when in fact the currently authenticated user does not have access to 287 any child mailboxes, potentially more information is conveyed about 288 the mailbox than intended. In most situations this will not be a 289 security concern, because if information regarding whether a mailbox 290 has children is considered sensitive, a user would not be granted 291 access to that mailbox in the first place. 293 9. References 295 [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version 296 4rev1"; RFC 2060; University of Washington; December 1996. 298 Internet DRAFT IMAP4 LIST Command Extensions October 2000 300 [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193; 301 Microsoft Corporation; September 1997. 303 [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension"; 304 draft-gahrns-imap-child-mailbox-03.txt; Microsoft Corporation; 305 November 1997 -- expired, listed for historical reference. 307 [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate 308 Requirement Levels"; RFC 2119; Harvard University; March 1997. 310 [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax 311 Specifications: ABNF", RFC 2234, November 1997. 313 10. Acknowledgements 315 Mike Gahrns and Raymond Cheng of Microsoft Corporation originally 316 devised the Child Mailbox Extension and proposed it in 1997; the 317 idea, as well as most of the text in section 5, is theirs. 319 11. Author's Address 321 Barry Leiba 322 IBM T.J. Watson Research Center 323 30 Saw Mill River Road 324 Hawthorne, NY 10532 326 Phone: 1-914-784-7941 327 Email: leiba@watson.ibm.com 329 B. Leiba Expires April 2001