idnits 2.17.00 (12 Aug 2021) /tmp/idnits36921/draft-gahrns-imap-namespace-01.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. == 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 6 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 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 (June 1997) is 9105 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' == Outdated reference: draft-newman-url-imap has been published as RFC 2192 Summary: 11 errors (**), 0 flaws (~~), 4 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 C. Newman, Innosoft 3 Internet Draft 4 Document: draft-gahrns-imap-namespace-01.txt June 1997 6 IMAP4 Namespace 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 November 1997. Distribution of this 30 draft is unlimited. 32 1. Abstract 34 IMAP4[RFC-2060] does not define a default server namespace. As a 35 result, two common namespace models have evolved: 37 The "Personal Mailbox" model, in which the default namespace that is 38 presented consists of only the user's personal mailboxes. To access 39 shared mailboxes, the user must use an escape mechanism to reach 40 another namespace. 42 The "Complete Hierarchy" model, in which the default namespace that 43 is presented includes the user's personal mailboxes along with any 44 other mailboxes they have access to. 46 These two models, create difficulties for certain client operations. 47 This document defines a NAMESPACE command that allows a client to 48 discover the prefixes of namespaces used by a server for personal 49 mailboxes, other user's mailboxes, and shared mailboxes. This 50 allows a client to avoid much of the manual user configuration that 51 is now necessary when mixing and matching IMAP4 clients and servers. 53 Gahrns and Newman 1 54 2. Conventions used in this document 56 In examples, "C:" and "S:" indicate lines sent by the client and 57 server respectively. 59 Personal Namespace: A namespace that the server considers within the 60 personal scope of the authenticated user on a particular connection. 61 Typically, only the authenticated user has access to mailboxes in 62 their Personal Namespace. The specially defined IMAP4 mailbox INBOX 63 resides in a user's personal namespace. 65 Other Users' Namespace: A namespace that consists of mailboxes from 66 the Personal Namespaces of other users. To access mailboxes in the 67 Other Users' Namespace, the currently authenticated user MUST be 68 explicitly granted access rights. For example, it is common for a 69 manager to grant to their secretary access rights to their mailbox. 71 Shared Namespace: A namespace that consists of mailboxes that are 72 intended to be shared amongst users and do not exist within a user's 73 Personal Namespace. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in [RFC-2119]. 79 3. Introduction and Overview 81 Clients often attempt to create mailboxes for such purposes as 82 maintaining a record of sent messages (e.g. "Sent Mail") or 83 temporarily saving messages being composed (e.g. "Drafts"). For 84 these clients to inter-operate correctly with the variety of IMAP4 85 servers available, the user must enter the prefix of the Personal 86 Namespace used by the server. Using the NAMESPACE command, a client 87 is able to automatically discover this prefix without manual user 88 configuration. 90 In addition, users are often required to manually enter the prefixes 91 of various namespaces in order to view the mailboxes located there. 92 For example, they might be required to enter the prefix of #shared 93 to view the shared mailboxes namespace. The NAMESPACE command allows 94 a client to automatically discover the namespaces that are available 95 on a server. This allows a client to present the available 96 namespaces to the user in which ever manner it deems appropriate. 97 For example, a client could choose to initially display only 98 personal mailboxes, or it may choose to display the complete list of 99 mailboxes available, and initially position the user at the root of 100 their Personal Namespace. 102 A server MAY choose to make available to the NAMESPACE command only 103 a subset of the complete set of namespaces the server supports. 105 Gahrns and Newman 2 106 4. Requirements 108 IMAP4 servers that support this extension MUST list the keyword 109 NAMESPACE in their CAPABILITY response. 111 5. NAMESPACE Command 113 Arguments: none 115 Response: an untagged NAMESPACE response that contains the prefix 116 to the server's default Personal Namespace, the Other 117 Users' Namespace, and the Shared Namespace that the 118 server wishes to expose. The Personal Namespace and 119 Other User's Namespace prefix are each to a single 120 namespace, and as such, MUST end with the hierarchy 121 character used in that namespace. The Shared Namespace 122 prefix MAY be to multiple namespaces. If the Shared 123 Namespace prefix is to multiple namespaces, the 124 hierarchy character is not included in the prefix. 126 Result: OK - Command completed 127 NO - Error: Can't complete command 128 BAD - argument invalid 130 If a particular namespace is not available, the prefix to that 131 namespace is NIL. 133 Example: 135 < A server that supports only the personal namespace. No leading 136 prefix is used on personal mailboxes. > 138 C: A001 NAMESPACE 139 S: * NAMESPACE "" NIL NIL 140 S: A001 OK NAMESPACE command completed 142 Example: 144 < A user logged on anonymously to a server. No personal 145 mailboxes are associated with the anonymous user. No prefix is 146 required to access shared mailboxes. > 148 C: A001 NAMESPACE 149 S: * NAMESPACE NIL NIL "" 150 S: A001 OK NAMESPACE command completed 152 The Personal Namespace prefix returned MUST be to a single Personal 153 Namespace and MUST end with the hierarchy character used in that 155 Gahrns and Newman 3 156 namespace. This allows a client to use the Personal Namespace 157 prefix to automatically create personal mailboxes. 159 Example: 161 < A server that supports only the Personal Namespace, with a 162 leading prefix of INBOX to personal mailboxes. > 164 C: A001 NAMESPACE 165 S: * NAMESPACE "INBOX." NIL NIL 166 S: A001 OK NAMESPACE command completed 168 C: A002 CREATE "INBOX.Sent Mail" 169 S: A002 OK CREATE command completed 171 The Other Users' Namespace prefix MUST be to a single Other Users' 172 Namespace and MUST end with the hierarchy character used in that 173 namespace. The next level of hierarchy following the Other Users' 174 Namespace prefix SHOULD consist of , where is a 175 user name as per the IMAP4 LOGIN or AUTHENTICATE command. 177 A client can construct a LIST command by appending a "%" to the 178 Other Users' Namespace prefix to discover the Personal Namespaces of 179 other users that are available to the currently authenticate user. 181 In response to such a LIST command, a server SHOULD NOT return user 182 names that have not granted access to their personal mailboxes to 183 the user in question. 185 A server MAY return a LIST response containing only the names of 186 users that have explicitly granted access to the user in question. 187 Alternatively, a server MAY return NO to such a LIST command, 188 requiring that a user name be included with the Other Users' 189 Namespace prefix before listing any other user's mailboxes. 191 Example: 193 < A server that supports providing a list of other user's 194 mailboxes that are accessible to the currently logged on user. > 196 C: A001 NAMESPACE 197 S: * NAMESPACE "" "Other Users/" NIL 198 S: A001 OK NAMESPACE command completed 200 C: A002 LIST "" "Other Users/%" 201 S: * LIST () "/" "Other Users/Mike" 202 S: * LIST () "/" "Other Users/Karen" 203 S: A002 OK LIST command completed 205 Gahrns and Newman 4 206 Example: 208 < A server that does not support providing a list of other user's 209 mailboxes that are accessible to the currently logged on user. 210 The mailboxes are listable if the client includes the name of the 211 other user with the Other Users' Namespace prefix. > 213 C: A001 NAMESPACE 214 S: * NAMESPACE "" "#Users/" NIL 215 S: A001 OK NAMESPACE command completed 217 < In this example, the currently logged on user has access to the 218 Personal Namespace of user Mike, but the server chose to suppress 219 this information in the LIST response. However, by appending the 220 user name Mike (received through user input) to the Other Users' 221 Namespace prefix, the client is able to get a listing of the 222 personal mailboxes of user Mike. > 224 C: A002 LIST "" "#Users/%" 225 S: A002 NO The requested item could not be found. 227 C: A003 LIST "" "#Users/Mike/%" 228 S: * LIST () "/" "#Users/Mike/INBOX" 229 S: * LIST () "/" "#Users/Mike/Foo" 230 S: A003 OK LIST command completed. 232 The shared mailboxes prefix MAY be to multiple Shared Namespaces. A 233 client can construct a LIST command by appending a "%" to the Shared 234 Namespace prefix to discover available Shared Namespaces. 236 Example: 238 < A server that contains a single Shared Namespace. > 240 C: A001 NAMESPACE 241 S: * NAMESPACE "" NIL "Public Folders/" 242 S: A001 OK NAMESPACE command completed 244 C: A002 LIST "" "Public Folders/%" 245 S: * LIST () "/" "Public Folders/Foo" 246 S: * LIST () "/" "Public Folders/Bar" 247 S: A002 OK LIST command completed. 249 Example: 251 < A server that contains multiple Shared Namespaces. Note that 252 the hierarchy delimiter used within each namespace can be 253 different. > 255 C: A001 NAMESPACE 256 S: * NAMESPACE "~/mail/" NIL "#" 257 S: A001 OK NAMESPACE command completed 259 Gahrns and Newman 5 260 C: A002 LIST "" "#%" 261 S: * LIST () "." "#News" 262 S: * LIST () "/" "#Shared" 263 S: A002 OK LIST command completed. 265 Historical convention has been to start all namespaces with the "#" 266 character. Namespaces that include the "#" character are not IMAP 267 URL [IMAP-URL] friendly requiring the "#" character to be 268 represented as %23 when within URLs. As such, server implementers 269 MAY instead consider using namespace prefixes that do not contain 270 the "#" character. 272 6. Formal Syntax 274 The following syntax specification uses the augmented Backus-Naur 275 Form (BNF) as described in [ABNF]. 277 Namespace_Command = "NAMESPACE" 279 Namespace_Response = "*" SPACE "NAMESPACE" SPACE Prefix SPACE Prefix 280 SPACE Prefix 281 ; The first prefix is a prefix to the Personal Namespace 282 ; The second prefix is a prefix to the Other Users' Namespace 283 ; The third prefix is a prefix to the Shared Namespace 285 mailbox = 286 ;