idnits 2.17.1 draft-gahrns-imap-child-mailbox-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 7) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 ([RFC-2060]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In some instances a server that supports the CHILDREN extension MAY NOT be able to determine whether a mailbox has children. For example it may have difficulty determining whether there are child mailboxes when LISTing mailboxes while operating in a particular namespace. -- 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 (December 1999) is 8892 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ABNF' is mentioned on line 220, but not defined == Unused Reference: 'RFC-2234' is defined on line 253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Gahrns, Microsoft 2 R. Cheng, Microsoft 3 Internet Draft 4 Document: draft-gahrns-imap-child-mailbox-02.txt December 1999 6 IMAP4 Child Mailbox Extension 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 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 0. Meta Information on this draft 30 This information is intended to facilitate discussion. It will be 31 removed when this document leaves the Internet-Draft stage. 33 This draft is now being discussed on the IMAPEXT mailing list at 34 ietf-imapext@imc.org. Subscription requests can be sent to ietf- 35 imapext-request@imc.org (send an email message with the word 36 "subscribe" in the body). More information on the mailing list 37 along with a WWW archive of back messages is available at 38 HTTP://www.imc.org. Earlier discussion took place on the IMAP 39 Mailing List imap@u.washington.edu 41 At the 45th IETF in Oslo, and 46th IETF in Washington, there was 42 further discussion regarding this draft. I am making what I believe 43 should be the final editorial changes to this draft. 45 At several of the previous IMC interop events, several IMAP vendors 46 have done implementations of this proposal. Further discussions are 47 needed as to whether this draft should be submitted as a proposed 48 standard or as an informational or historical RFC. Submitting as an 49 information or historical RFC would serve to document the current 51 Gahrns and Cheng 1 52 IMAP4 Child Mailbox Extension December 1999 54 implementations and elements of it could become a basis of a general 55 LIST extension. 57 There is some interest in starting a completely new LIST Extension 58 draft that addresses general extensibility of the LIST command. 59 Similar functionality to the \HasChildren and \HasNoChildren flags 60 could be incorporated into this new LIST Extension, but the client 61 would then have an opportunity to request whether or not the server 62 should return this information. This could be an advantage over the 63 current draft for servers where this information is expensive to 64 compute, since the server would only need to compute the information 65 when it knew that the client requesting the information was able to 66 use it. 68 Changes since April 99, draft-01 70 Incorporated comments from the list discussions: 72 1) Explicitly note that it is an error for the server to return both 73 a \HasChildren and a \NoInferiors attribute in a LIST response. 75 2) Note that the \HasChildren and \HasNoChildren attribute may not 76 apply to the LSUB command. 78 3) Note how \HasChildren and \HasNoChildren apply in the referral 79 case. 81 4) Added back advertising CHILDREN in the capability response as was 82 the consensus during the Washington IMAP-EXT WG. Rational was that 83 this made it easier for clients. 85 1. Abstract 87 Many IMAP4 [RFC-2060] clients present to the user a hierarchical 88 view of the mailboxes that a user has access to. Rather than 89 initially presenting to the user the entire mailbox hierarchy, it is 90 often preferable to show to the user a collapsed outline list of the 91 mailbox hierarchy (particularly if there is a large number of 92 mailboxes). The user can then expand the collapsed outline 93 hierarchy as needed. It is common to include within the collapsed 94 hierarchy a visual clue (such as a "+") to indicate that there are 95 child mailboxes under a particular mailbox. When the visual clue 96 is clicked the hierarchy list is expanded to show the child 97 mailboxes. 99 The CHILDREN extension provides a mechanism for a client to 100 efficiently determine if a particular mailbox has children, without 101 issuing a LIST "" * or a LIST "" % for each mailbox name. 103 Gahrns and Cheng Expires June 2000 2 104 IMAP4 Child Mailbox Extension December 1999 106 2. Conventions used in this document 108 In examples, "C:" and "S:" indicate lines sent by the client and 109 server respectively. If such lines are wrapped without a new "C:" 110 or "S:" label, then the wrapping is for editorial clarity and is not 111 part of the command. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 115 this document are to be interpreted as described in [RFC-2119]. 117 3. Requirements 119 IMAP4 servers that support this extension MUST list the keyword 120 CHILDREN in their CAPABILITY response. 122 The CHILDREN extension defines two new attributes that MAY be 123 returned within a LIST response. 125 \HasChildren - The presence of this attribute indicates that the 126 mailbox has child mailboxes. 128 Servers SHOULD NOT return \HasChildren if child mailboxes exist, but 129 none will be displayed to the current user in a LIST response (as 130 should be the case where child mailboxes exist, but a client does 131 not have permissions to access them.) In this case, \HasNoChildren 132 SHOULD be used. 134 In many cases, however, a server may not be able to efficiently 135 compute whether a user has access to all child mailboxes, or 136 multiple users may be accessing the same account and simultaneously 137 changing the mailbox hierarchy. As such a client MUST be prepared 138 to accept the \HasChildren attribute as a hint. That is, a mailbox 139 MAY be flagged with the \HasChildren attribute, but no child 140 mailboxes will appear in a subsequent LIST response. 142 Example 3.1: 143 ============ 145 /*** Consider a server that has the following mailbox hierarchy: 147 INBOX 148 ITEM_1 149 ITEM_1A 150 ITEM_2 151 TOP_SECRET 153 Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is 154 a child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of 155 ITEM_2 that the currently logged on user does NOT have access to. 157 Gahrns and Cheng Expires June 2000 3 158 IMAP4 Child Mailbox Extension December 1999 160 Note that in this case, the server is not able to efficiently 161 compute access rights to child mailboxes and responds with a 162 \HasChildren attribute for mailbox ITEM_2, even though 163 ITEM_2/TOP_SECRET does not appear in the list response. ***/ 165 C: A001 LIST "" * 166 S: * LIST (\HasNoChildren) "/" INBOX 167 S: * LIST (\HasChildren) "/" ITEM_1 168 S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A 169 S: * LIST (\HasChildren) "/" ITEM_2 170 S: A001 OK LIST Completed 172 \HasNoChildren - The presence of this attribute indicates that the 173 mailbox has NO child mailboxes that are accessible to the currently 174 authenticated user. If a mailbox has the \Noinferiors attribute, 175 the \HasNoChildren attribute is redundant and SHOULD be omitted in 176 the LIST response. 178 In some instances a server that supports the CHILDREN extension MAY 179 NOT be able to determine whether a mailbox has children. For 180 example it may have difficulty determining whether there are child 181 mailboxes when LISTing mailboxes while operating in a particular 182 namespace. 184 In these cases, a server MAY exclude both the \HasChildren and 185 \HasNoChildren attributes in the LIST response. As such, a client 186 can not make any assumptions about whether a mailbox has children 187 based upon the absence of a single attribute. 189 It is an error for the server to return both a \HasChildren and a 190 \HasNoChildren attribute in a LIST response. 192 It is an error for the server to return both a \HasChildren and a 193 \NoInferiors attribute in a LIST response. 195 Note: the \HasNoChildren attribute should not be confused with the 196 IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that 197 no child mailboxes exist now and none can be created in the future. 199 The \HasChildren and \HasNoChildren attributes might not be returned 200 in response to a LSUB response. Many servers maintain a simple 201 mailbox subscription list that is not updated when the underlying 202 mailbox structure is changed. A client MUST NOT assume that 203 hierarchy information will be maintained in the subscription list. 205 RLIST is a command defined in [RFC-2193] that includes in a LIST 206 response mailboxes that are accessible only via referral. That is, 207 a client must explicitly issue an RLIST command to see a list of 208 these mailboxes. Thus in the case where a mailbox has child 209 mailboxes that are available only via referral, the mailboxes would 211 Gahrns and Cheng Expires June 2000 4 212 IMAP4 Child Mailbox Extension December 1999 214 appear as \HasNoChildren in response to the LIST command, and 215 \HasChildren in response to the RLIST command. 217 5. Formal Syntax 219 The following syntax specification uses the augmented Backus-Naur 220 Form (BNF) as described in [ABNF]. 222 Two new mailbox attributes are defined as flag_extensions to the 223 IMAP4 mailbox_list response: 225 HasChildren = "\HasChildren" 227 HasNoChildren = "\HasNoChildren" 229 6. Security Considerations 231 This extension provides a client a more efficient means of 232 determining whether a particular mailbox has children. If a mailbox 233 has children, but the currently authenticated user does not have 234 access to any of them, the server SHOULD respond with a 235 \HasNoChildren attribute. In many cases, however, a server may not 236 be able to efficiently compute whether a user has access to all 237 child mailboxes. If such a server responds with a \HasChildren 238 attribute, when in fact the currently authenticated user does not 239 have access to any child mailboxes, potentially more information is 240 conveyed about the mailbox than intended. A server designed with 241 such levels of security in mind SHOULD NOT attach the \HasChildren 242 attribute to a mailbox unless the server is certain that the user 243 has access to at least one of the child mailboxes. 245 7. References 247 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 248 4rev1", RFC 2060, University of Washington, December 1996. 250 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 251 Requirement Levels", RFC 2119, Harvard University, March 1997 253 [RFC-2234], D. Crocker and P. Overell, Editors, "Augmented BNF for 254 Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, 255 November 1997 257 [RFC-2193], Gahrns, M, "IMAP4 Mailbox Referrals", RFC 2193, 258 Microsoft Corporation, September 1997 260 8. Acknowledgments 262 Gahrns and Cheng Expires June 2000 5 263 IMAP4 Child Mailbox Extension December 1999 265 The authors would like to thank the participants of several IMC Mail 266 Connect events for their input when this idea was originally 267 presented and refined. 269 9. Author's Address 271 Mike Gahrns 272 Microsoft 273 One Microsoft Way 274 Redmond, WA, 98072 276 Phone: (425) 936-9833 277 Email: mikega@microsoft.com 279 Raymond Cheng 280 Microsoft 281 One Microsoft Way 282 Redmond, WA, 98072 284 Phone: (425) 703-4913 285 Email: raych@microsoft.com 287 Gahrns and Cheng Expires June 2000 6 288 IMAP4 Child Mailbox Extension December 1999 290 Full Copyright Statement 292 Copyright (C) The Internet Society (1999). All Rights Reserved. 294 This document and translations of it may be copied and furnished 295 to others, and derivative works that comment on or otherwise 296 explain it or assist in its implementation may be prepared, copied, 297 published and distributed, in whole or in part, without 298 restriction of any kind, provided that the above copyright notice 299 and this paragraph are included on all such copies and derivative 300 works. However, this document itself may not be modified in any 301 way, such as by removing the copyright notice or references to the 302 Internet Society or other Internet organizations, except as needed 303 For the purpose of developing Internet standards in which case the 304 procedures for copyrights defined in the Internet Standards 305 process must be followed, or as required to translate it into 306 languages other than English. 308 The limited permissions granted above are perpetual and will not 309 be revoked by the Internet Society or its successors or assigns. 311 This document and the information contained herein is provided on 312 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 313 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 314 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 315 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 316 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 318 Gahrns and Cheng Expires June 2000 7