idnits 2.17.1 draft-gahrns-imap-namespace-00.txt: ** The Abstract section seems to be numbered -(261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 (2024-04-26) 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) 2024 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. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 4) being 60 lines 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 ([RFC-2060]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1997) is 9873 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) ** 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: 11 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gahrns, Microsoft 3 J. Myers 4 J. De Winter, Wildbear Consulting 5 Internet Draft 6 Document: draft-gahrns-imap-namespace-00.txt April 1997 8 IMAP4 Namespace 10 Status of this Memo 12 This document is an Internet Draft. 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 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 A revised version of this draft document will be submitted to the 29 RFC editor as a Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested. This 31 document will expire before October 1997. Distribution of this draft 32 is unlimited. 34 1. Abstract 36 IMAP4[RFC-2060] does not define a default mailbox namespace and 37 hierarchy. As such, server behavior regarding namespaces can 38 differ, creating difficulties for certain client operations. 40 This document defines a #personal namespace for identifying a user's 41 personal mailbox scope and a CANONICAL command that allows the 42 discovery of the preferred name of a mailbox within the server's 43 default mailbox hierarchy. 45 By using the #personal namespace, a client is able to automatically 46 create or access a mailbox without first configuring a server 47 specific personal mailbox prefix. For example, many clients often 48 create at initial start up time a "Sent Mail" or "Draft" mailbox. 50 In addition, the #personal mailbox namespace allows a client to 51 present a view to the user that is completely restricted to the 52 user's personal folders without displaying any shared mailboxes. 54 Gahrns, Myers and De Winter 1 55 By using the CANONICAL command, a client is able to determine where 56 a mailbox exists in the server's entire default mailbox hierarchy. 57 Used in conjunction with #personal namespace, a graphical client is 58 able to display a server's entire default hierarchy, starting the 59 user at their personal space. 61 2. Conventions used in this document 63 In examples, "C:" and "S:" indicate lines sent by the client and 64 server respectively. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 68 this document are to be interpreted as described in [RFC-2119]. 70 3. Introduction and Overview 72 A mailbox can be known by different names. For example, for the 73 user authenticated as joe, the mailbox INBOX could also be known as 74 /var/spool/mail/joe. A mailbox can also exist in more than one 75 namespace. For example, the mailbox #news.comp.mail.imap could also 76 be known as "#shared/internet newsgroups/comp/mail/imap". 78 The canonical name of a mailbox is the server's preferred name of 79 the mailbox within the server's default hierarchy. 81 The canonical name of a mailbox MAY be different for different 82 logged on users. For example, for the user logged on as "joe", the 83 canonical name of their INBOX mailbox may be "INBOX". The canonical 84 name of this same mailbox could be "users.joe.INBOX" for any other 85 user not logged on as "joe". 87 4. Requirements 89 IMAP4 servers that support this extension MUST list the keyword 90 CANONICAL in their CAPABILITY response. A server that implements 91 the CANONICAL command MUST also define a #personal namespace. 93 If a mailbox has multiple names, a subscription to any one of the 94 mailbox names SHOULD result in a subscription to the canonical name 95 of the mailbox. 97 5. #personal namespace 99 #personal is the namespace that the server considers within the 100 personal scope of the authenticated user on a particular connection. 101 Servers defining this namespace MUST use "/" as the hierachy 103 Gahrns, Myers and De Winter 2 104 separator within the #personal namespace. Servers MAY use use 105 different hierarchy separators outside the #personal namespace. 107 IMAP4 defines INBOX as a special mailbox reserved to mean 'the 108 primary mailbox for this user on this server'. If this mailbox 109 exists on the server, it MAY also appear in the #personal namespace 110 as #personal/INBOX. 112 Typically, no other users will have access to the mailboxes within 113 the #personal namespace unless the user has explicitly granted 114 access rights to other users. 116 By defining a #personal namespace, servers allow clients the ability 117 to create personal scope mailboxes or limit a list response to 118 personal scope mailboxes, without regard to the underlying default 119 mailbox hierarchy a server has choosen. 121 Example: 123 C: A001 CREATE "#personal/sent mail" 124 S: A001 OK CREATE completed 126 C: A002 LIST "" "#personal/%" 127 S: * LIST () "/" "#personal/INBOX" 128 S: * LIST () "/" "#personal/sent mail" 129 S: A002 OK LIST completed 131 6. CANONICAL Command 133 Argument: namespace or mailbox name 135 Responses: LIST response for the canonical mailbox name 137 Result: OK - Command completed 138 NO - Error: Can't complete command 139 BAD - argument invalid 141 The CANONICAL command calculates the canonical name of the mailbox 142 and generates an untagged LIST response as if a LIST command were 143 issued with an empty reference argument and the canonical name of 144 the mailbox as the pattern. 146 Gahrns, Myers and De Winter 3 147 Example: 149 Consider a server with a default hierarchy as follows: 151 The user's personal scope starts at the INBOX mailbox. 152 Personal mailboxes are created as inferiors to INBOX, with "." 153 as the hierarchy delimiter. 154 Shared mailboxes are created at the same level as INBOX. 156 INBOX 157 INBOX. 158 160 C: A001 CANONICAL #personal 161 S: * LIST () "." "INBOX" 162 S: A001 OK Completed 164 C: A002 CANONICAL #personal/foo 165 S: * LIST () "." "INBOX.foo" 166 S: A002 OK Completed 168 C: A003 CANONICAL foo 169 S: * LIST () "." "foo" 170 S: A003 OK Completed 172 Example: 174 Consider a server with a default hierarchy that starts right at 175 the user's #personal namespace. In this example, #personal does 176 not translate to a selectable mailbox. 178 C: A001 CANONICAL #personal 179 S: * LIST (\Noselect) "/" "" 180 S: A001 OK Completed 182 C: A002 CANONICAL "#personal/foo" 183 S: * LIST (\Noinferiors) "/" "foo" 184 S: A002 OK 186 C: A003 CANONICAL "#personal/inbox" 187 S: * LIST () "/" "inbox" 188 S: A003 OK 190 Example: 192 Consider a mailbox that is known by two different names. 193 CANONICAL returns the same canonical name for each. 195 C: A001 CANONICAL #news.alt.comp.mail.imap 196 S: * LIST () "/" "public/internet news/alt/comp/mail/imap" 197 S: A001 OK CANONICAL completed 199 Gahrns, Myers and De Winter 4 200 C: A002 CANONICAL "public folders/internet news/alt/comp/imap" 201 S: * LIST () "/" "public folders/internet news/alt/comp/imap" 202 S: A002 OK CANONICAL completed 204 Example: 206 Using the CANONICAL command, a graphical client can discover 207 where in the exposed default hierarchy it should present the 208 user's personal mailboxes. Using the LIST command, the graphical 209 client can complete the display of a "tree" control that shows 210 the initial set of mailboxes a client has access to. 212 C: A001 CANONICAL #personal 213 S: * list () "/" "All/Users/Joe" 214 S: A001 OK CANONICAL completed 216 To complete the tree view, the client issues a LIST % command on 217 each hierarchy above the personal scope so that it can gather the 218 information needed to complete the display of the "tree" control. 220 C: A002 LIST "" "All/Users/%" 221 S: * LIST () "" "All/Users/Joe" 222 S: * LIST () "" "All/Users/Fred" 223 S: A002 OK LIST completed 225 C: A003 LIST "" "All/%" 226 S: * LIST (\Noselect) "" "Users" 227 S: * LIST (\Noselect) "" "Shared" 228 S: A003 OK LIST completed. 230 The client now has gathered enough information so that it could 231 display to the user a "tree" control such as: 233 All 234 Users 235 +Joe 236 +Fred 237 +Shared 239 Where lower level of hierarchy is denoted by indentation, and "+" 240 indicates a hierarchy level that has not yet been expanded by the 241 user. 243 7. Formal Syntax 245 The following syntax specification uses the augmented Backus-Naur 246 Form (BNF) as described in [ABNF]. 248 Canonical = "CANONICAL" SPACE mailbox 250 mailbox = 251 ;