idnits 2.17.1 draft-gahrns-imap-namespace-02.txt: ** The Abstract section seems to be numbered -(305): 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-19) 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 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 9805 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: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gahrns, Microsoft 3 C. Newman, Innosoft 4 Internet Draft 5 Document: draft-gahrns-imap-namespace-02.txt June 1997 7 IMAP4 Namespace 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 25 munnari.oz.au. 27 A revised version of this draft document will be submitted to the 28 RFC editor as a Proposed Standard for the Internet Community. 29 Discussion and suggestions for improvement are requested. This 30 document will expire before November 1997. Distribution of this 31 draft is unlimited. 33 1. Abstract 35 IMAP4[RFC-2060] does not define a default server namespace. As a 36 result, two common namespace models have evolved: 38 The 'Personal Mailbox' model, in which the default namespace that is 39 presented consists of only the user's personal mailboxes. To access 40 shared mailboxes, the user must use an escape mechanism to reach 41 another namespace. 43 The 'Complete Hierarchy' model, in which the default namespace that 44 is presented includes the user's personal mailboxes along with any 45 other mailboxes they have access to. 47 These two models, create difficulties for certain client operations. 48 This document defines a NAMESPACE command that allows a client to 49 discover the prefixes of namespaces used by a server for personal 50 mailboxes, other user's mailboxes, and shared mailboxes. This 51 allows a client to avoid much of the manual user configuration that 52 is now necessary when mixing and matching IMAP4 clients and servers. 54 Gahrns and Newman 1 55 2. Conventions used in this document 57 In examples, "C:" and "S:" indicate lines sent by the client and 58 server respectively. 60 Personal Namespace: A namespace that the server considers within the 61 personal scope of the authenticated user on a particular connection. 62 Typically, only the authenticated user has access to mailboxes in 63 their Personal Namespace. The specially defined IMAP4 mailbox INBOX 64 resides in a user's personal namespace. 66 Other Users' Namespace: A namespace that consists of mailboxes from 67 the Personal Namespaces of other users. To access mailboxes in the 68 Other Users' Namespace, the currently authenticated user MUST be 69 explicitly granted access rights. For example, it is common for a 70 manager to grant to their secretary access rights to their mailbox. 72 Shared Namespace: A namespace that consists of mailboxes that are 73 intended to be shared amongst users and do not exist within a user's 74 Personal Namespace. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 78 this document are to be interpreted as described in [RFC-2119]. 80 3. Introduction and Overview 82 Clients often attempt to create mailboxes for such purposes as 83 maintaining a record of sent messages (e.g. "Sent Mail") or 84 temporarily saving messages being composed (e.g. "Drafts"). For 85 these clients to inter-operate correctly with the variety of IMAP4 86 servers available, the user must enter the prefix of the Personal 87 Namespace used by the server. Using the NAMESPACE command, a client 88 is able to automatically discover this prefix without manual user 89 configuration. 91 In addition, users are often required to manually enter the prefixes 92 of various namespaces in order to view the mailboxes located there. 93 For example, they might be required to enter the prefix of #shared 94 to view the shared mailboxes namespace. The NAMESPACE command allows 95 a client to automatically discover the namespaces that are available 96 on a server. This allows a client to present the available 97 namespaces to the user in which ever manner it deems appropriate. 98 For example, a client could choose to initially display only 99 personal mailboxes, or it may choose to display the complete list of 100 mailboxes available, and initially position the user at the root of 101 their Personal Namespace. 103 A server MAY choose to make available to the NAMESPACE command only 104 a subset of the complete set of namespaces the server supports. 106 Gahrns and Newman 2 107 4. Requirements 109 IMAP4 servers that support this extension MUST list the keyword 110 NAMESPACE in their CAPABILITY response. 112 The NAMESPACE command is valid in the Authenticated and Selected 113 state. 115 5. NAMESPACE Command 117 Arguments: none 119 Response: an untagged NAMESPACE response that contains the prefix 120 to the server's default Personal Namespace, the Other 121 Users' Namespace, and the Shared Namespace that the 122 server wishes to expose. The Personal Namespace and 123 Other User's Namespace prefix are each to a single 124 namespace, and as such, MUST end with the hierarchy 125 character used in that namespace. The Shared Namespace 126 prefix MAY be to multiple namespaces. If the Shared 127 Namespace prefix is to multiple namespaces, the 128 hierarchy character is not included in the prefix. 130 Result: OK - Command completed 131 NO - Error: Can't complete command 132 BAD - argument invalid 134 If a particular namespace is not available, the prefix to that 135 namespace is NIL. 137 Example: 139 < A server that supports only the personal namespace. No leading 140 prefix is used on personal mailboxes. > 142 C: A001 NAMESPACE 143 S: * NAMESPACE "" NIL NIL 144 S: A001 OK NAMESPACE command completed 146 Example: 148 < A user logged on anonymously to a server. No personal 149 mailboxes are associated with the anonymous user. No prefix is 150 required to access shared mailboxes. > 152 C: A001 NAMESPACE 153 S: * NAMESPACE NIL NIL "" 154 S: A001 OK NAMESPACE command completed 156 Gahrns and Newman 3 157 The Personal Namespace prefix returned MUST be to a single Personal 158 Namespace and MUST end with the hierarchy character used in that 159 namespace. This allows a client to use the Personal Namespace 160 prefix to automatically create personal mailboxes. 162 Example: 164 < A server that supports only the Personal Namespace, with a 165 leading prefix of INBOX to personal mailboxes. > 167 C: A001 NAMESPACE 168 S: * NAMESPACE "INBOX." NIL NIL 169 S: A001 OK NAMESPACE command completed 171 C: A002 CREATE "INBOX.Sent Mail" 172 S: A002 OK CREATE command completed 174 The Other Users' Namespace prefix MUST be to a single Other Users' 175 Namespace and MUST end with the hierarchy character used in that 176 namespace. The next level of hierarchy following the Other Users' 177 Namespace prefix SHOULD consist of , where is a 178 user name as per the IMAP4 LOGIN or AUTHENTICATE command. 180 A client can construct a LIST command by appending a "%" to the 181 Other Users' Namespace prefix to discover the Personal Namespaces of 182 other users that are available to the currently authenticate user. 184 In response to such a LIST command, a server SHOULD NOT return user 185 names that have not granted access to their personal mailboxes to 186 the user in question. 188 A server MAY return a LIST response containing only the names of 189 users that have explicitly granted access to the user in question. 190 Alternatively, a server MAY return NO to such a LIST command, 191 requiring that a user name be included with the Other Users' 192 Namespace prefix before listing any other user's mailboxes. 194 Example: 196 < A server that supports providing a list of other user's 197 mailboxes that are accessible to the currently logged on user. > 199 C: A001 NAMESPACE 200 S: * NAMESPACE "" "Other Users/" NIL 201 S: A001 OK NAMESPACE command completed 203 C: A002 LIST "" "Other Users/%" 204 S: * LIST () "/" "Other Users/Mike" 205 S: * LIST () "/" "Other Users/Karen" 206 S: A002 OK LIST command completed 208 Gahrns and Newman 4 209 Example: 211 < A server that does not support providing a list of other user's 212 mailboxes that are accessible to the currently logged on user. 213 The mailboxes are listable if the client includes the name of the 214 other user with the Other Users' Namespace prefix. > 216 C: A001 NAMESPACE 217 S: * NAMESPACE "" "#Users/" NIL 218 S: A001 OK NAMESPACE command completed 220 < In this example, the currently logged on user has access to the 221 Personal Namespace of user Mike, but the server chose to suppress 222 this information in the LIST response. However, by appending the 223 user name Mike (received through user input) to the Other Users' 224 Namespace prefix, the client is able to get a listing of the 225 personal mailboxes of user Mike. > 227 C: A002 LIST "" "#Users/%" 228 S: A002 NO The requested item could not be found. 230 C: A003 LIST "" "#Users/Mike/%" 231 S: * LIST () "/" "#Users/Mike/INBOX" 232 S: * LIST () "/" "#Users/Mike/Foo" 233 S: A003 OK LIST command completed. 235 The shared mailboxes prefix MAY be to multiple Shared Namespaces. A 236 client can construct a LIST command by appending a "%" to the Shared 237 Namespace prefix to discover available Shared Namespaces. 239 Example: 241 < A server that contains a single Shared Namespace. > 243 C: A001 NAMESPACE 244 S: * NAMESPACE "" NIL "Public Folders/" 245 S: A001 OK NAMESPACE command completed 247 C: A002 LIST "" "Public Folders/%" 248 S: * LIST () "/" "Public Folders/Foo" 249 S: * LIST () "/" "Public Folders/Bar" 250 S: A002 OK LIST command completed. 252 Example: 254 < A server that contains multiple Shared Namespaces. Note that 255 the hierarchy delimiter used within each namespace can be 256 different. > 258 Gahrns and Newman 5 259 C: A001 NAMESPACE 260 S: * NAMESPACE "~/mail/" NIL "#" 261 S: A001 OK NAMESPACE command completed 263 C: A002 LIST "" "#%" 264 S: * LIST () "." "#News" 265 S: * LIST () "/" "#Shared" 266 S: A002 OK LIST command completed. 268 Historical convention has been to start all namespaces with the "#" 269 character. Namespaces that include the "#" character are not IMAP 270 URL [IMAP-URL] friendly requiring the "#" character to be 271 represented as %23 when within URLs. As such, server implementers 272 MAY instead consider using namespace prefixes that do not contain 273 the "#" character. 275 6. Formal Syntax 277 The following syntax specification uses the augmented Backus-Naur 278 Form (BNF) as described in [ABNF]. 280 Namespace_Command = "NAMESPACE" 282 Namespace_Response = "*" SPACE "NAMESPACE" SPACE Prefix SPACE Prefix 283 SPACE Prefix 284 ; The first prefix is a prefix to the Personal Namespace 285 ; The second prefix is a prefix to the Other Users' Namespace 286 ; The third prefix is a prefix to the Shared Namespace 288 mailbox = 289 ;