idnits 2.17.00 (12 Aug 2021) /tmp/idnits47250/draft-gahrns-imap-child-mailbox-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 59 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 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 (November 1997) is 8952 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 (Obsoleted by RFC 3501) -- No information found for draft-drums-abnf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNF' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 4 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-00.txt November 1997 6 IMAP4 Child Mailbox Extension 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 "working draft" or "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire before June 1998. Distribution of this draft is 30 unlimited. 32 1. Abstract 34 Many IMAP4 [RFC-2060] clients present to the user a hierarchical 35 view of the mailboxes that a user has access to. Rather than 36 initially presenting to the user the entire mailbox hierarchy, it is 37 often preferable to show to the user a collapsed outline list of the 38 mailbox hierarchy (particularly if there is a large number of 39 mailboxes). The user can then expand the collapsed outline 40 hierarchy as needed. It is common to include within the collapsed 41 hierarchy a visual clue (such as a ''+'') to indicate that there are 42 child mailboxes under a particular mailbox. When the visual clue 43 is clicked the hierarchy list is expanded to show the child 44 mailboxes. 46 The CHILDREN extension provides a mechanism for a client to 47 efficiently determine if a particular mailbox has children, without 48 issuing a LIST '' * or a LIST '' % for each mailbox name. 50 Gahrns and Cheng 1 51 IMAP4 Child Mailbox Extension November 1997 53 2. Conventions used in this document 55 In examples, "C:" and "S:" indicate lines sent by the client and 56 server respectively. If such lines are wrapped without a new "C:" 57 or "S:" label, then the wrapping is for editorial clarity and is not 58 part of the command. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 62 this document are to be interpreted as described in [RFC-2119]. 64 3. Requirements 66 IMAP4 servers that support this extension MUST list the keyword 67 CHILDREN in their CAPABILITY response. 69 The CHILDREN extension defines two new attributes that MAY be 70 returned within a LIST response: 72 \HasChildren - The presence of this attribute indicates that the 73 mailbox has child mailboxes. 75 A server SHOULD NOT set this attribute if there are child mailboxes, 76 and the user does not have permissions to access any of them. In 77 this case, \HasNoChildren SHOULD be used. 79 In many cases, however, a server may not be able to efficiently 80 compute whether a user has access to all child mailboxes. As such a 81 client MUST be prepared to accept the \HasChildren attribute as a 82 hint. That is, a mailbox MAY be flagged with the \HasChildren 83 attribute, but no child mailboxes will appear in the LIST response. 85 \HasNoChildren - The presence of this attribute indicates that the 86 mailbox has NO child mailboxes that are accessible to the currently 87 authenticated user. 89 Example 3.1: 90 ============ 92 < Consider a server that has the following mailbox hierarchy: 94 INBOX 95 ITEM_1 96 ITEM_1A 97 ITEM_2 98 TOP_SECRET 100 Gahrns and Cheng 2 101 IMAP4 Child Mailbox Extension November 1997 103 Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is 104 a child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of 105 ITEM_2 that the currently logged on user does NOT have access to. 107 Note that in this case, the server is not able to efficiently 108 compute access rights to child mailboxes and responds with a 109 \HasChildren attribute for mailbox ITEM_2, even though 110 ITEM_2/TOP_SECRET does not appear in the list response. > 112 C: A001 LIST "" * 113 S: * LIST (\HasNoChildren) "/" INBOX 114 S: * LIST (\HasChildren) "/" ITEM_1 115 S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A 116 S: * LIST (\HasChildren) "/" ITEM_2 117 S: A001 OK LIST Completed 119 In some instances a server that supports the CHILDREN extension MAY 120 NOT be able to determine whether a mailbox has children. For 121 example it may have difficulty determining whether there are child 122 mailboxes when LISTing mailboxes while operating in a particular 123 namespace. 125 In these cases, a server MAY exclude both the \HasChildren and 126 \HasNoChildren attributes in the LIST response. As such, a client 127 can not make any assumptions about whether a mailbox has children 128 based upon the absence of a single attribute. It is an error for the 129 server to return both a \HasChildren and a \HasNoChildren attribute 130 in a LIST response. 132 Note: the \HasNoChildren attribute should not be confused with the 133 IMAP4 [RFC-2060] defined attribute \NoInferiors which indicates that 134 no child mailboxes exist now and none can be created in the future. 136 5. Formal Syntax 138 The following syntax specification uses the augmented Backus-Naur 139 Form (BNF) as described in [ABNF]. 141 Two new mailbox attributes are defined as flag_extensions to the 142 IMAP4 mailbox_list response: 144 HasChildren = "\HasChildren" 146 HasNoChildren = "\HasNoChildren" 148 6. Security Considerations 150 This extension provides a client a more efficient means of 151 determining whether a particular mailbox has children. If a mailbox 153 Gahrns and Cheng 3 154 IMAP4 Child Mailbox Extension November 1997 156 has children, but the currently authenticated user does not have 157 access to any of them, the server SHOULD respond with a 158 \HasNoChildren attribute. In many cases, however, a server may not 159 be able to efficiently compute whether a user has access to all 160 child mailboxes. If such a server responds with a \HasChildren 161 attribute, when in fact the currently authenticated user does not 162 have access to any child mailboxes, potentially more information is 163 conveyed about the mailbox than intended. In most situations this 164 will not be a security concern, because if information regarding 165 whether a mailbox has children is considered sensitive, a user would 166 not be granted access to that mailbox in the first place. 168 7. References 170 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 171 4rev1", RFC 2060, University of Washington, December 1996. 173 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 174 Requirement Levels", RFC 2119, Harvard University, March 1997 176 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for 177 Syntax Specifications: ABNF", draft-drums-abnf-04.txt (work in 178 progress), Internet Mail Consortium, September 1997 180 8. Acknowledgments 182 The authors would like to thank the participants of the IMC Mail 183 Connect 3 event for their input when this idea was originally 184 presented. 186 9. Author's Address 188 Mike Gahrns 189 Microsoft 190 One Microsoft Way 191 Redmond, WA, 98072 193 Phone: (425) 936-9833 194 Email: mikega@microsoft.com 196 Raymond Cheng 197 Microsoft 198 One Microsoft Way 199 Redmond, WA, 98072 201 Phone: (425) 703-4913 202 Email: raych@microsoft.com 204 Gahrns and Cheng 4