idnits 2.17.1 draft-gahrns-imap-namespace-05.txt: ** The Abstract section seems to be numbered -(416): 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 8 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: ---------------------------------------------------------------------------- == Line 399 has weird spacing: '...te that the n...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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: A prefix string MAY NOT contain a hierarchy delimiter, if it is not needed as part of the prefix. -- 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 9659 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' ** Obsolete normative reference: RFC 2192 (ref. 'IMAP-URL') (Obsoleted by RFC 5092) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 5 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-05.txt November 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 June 1997. Distribution of this draft is 30 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 users' 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 IMAP4 Namespace November 1997 56 2. Conventions used in this document 58 In examples, "C:" and "S:" indicate lines sent by the client and 59 server respectively. 61 Personal Namespace: A namespace that the server considers within the 62 personal scope of the authenticated user on a particular connection. 63 Typically, only the authenticated user has access to mailboxes in 64 their Personal Namespace. It is the part of the namespace that 65 belongs to the user that is allocated for mailboxes. If an INBOX 66 exists for a user, it MUST appear within the user's personal 67 namespace. In the typical case, there SHOULD be only one Personal 68 Namespace on a server. 70 Other Users' Namespace: A namespace that consists of mailboxes from 71 the Personal Namespaces of other users. To access mailboxes in the 72 Other Users' Namespace, the currently authenticated user MUST be 73 explicitly granted access rights. For example, it is common for a 74 manager to grant to their secretary access rights to their mailbox. 75 In the typical case, there SHOULD be only one Other Users' Namespace 76 on a server. 78 Shared Namespace: A namespace that consists of mailboxes that are 79 intended to be shared amongst users and do not exist within a user's 80 Personal Namespace. 82 The namespaces a server uses MAY differ on a per-user basis. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in [RFC-2119]. 88 3. Introduction and Overview 90 Clients often attempt to create mailboxes for such purposes as 91 maintaining a record of sent messages (e.g. "Sent Mail") or 92 temporarily saving messages being composed (e.g. "Drafts"). For 93 these clients to inter-operate correctly with the variety of IMAP4 94 servers available, the user must enter the prefix of the Personal 95 Namespace used by the server. Using the NAMESPACE command, a client 96 is able to automatically discover this prefix without manual user 97 configuration. 99 In addition, users are often required to manually enter the prefixes 100 of various namespaces in order to view the mailboxes located there. 101 For example, they might be required to enter the prefix of #shared 102 to view the shared mailboxes namespace. The NAMESPACE command allows 103 a client to automatically discover the namespaces that are available 104 on a server. This allows a client to present the available 105 namespaces to the user in what ever manner it deems appropriate. 107 Gahrns and Newman 2 108 IMAP4 Namespace November 1997 110 For example, a client could choose to initially display only 111 personal mailboxes, or it may choose to display the complete list of 112 mailboxes available, and initially position the user at the root of 113 their Personal Namespace. 115 A server MAY choose to make available to the NAMESPACE command only 116 a subset of the complete set of namespaces the server supports. To 117 provide the ability to access these namespaces, a client SHOULD 118 allow the user the ability to manually enter a namespace prefix. 120 4. Requirements 122 IMAP4 servers that support this extension MUST list the keyword 123 NAMESPACE in their CAPABILITY response. 125 The NAMESPACE command is valid in the Authenticated and Selected 126 state. 128 5. NAMESPACE Command 130 Arguments: none 132 Response: an untagged NAMESPACE response that contains the prefix 133 and hierarchy delimiter to the server's Personal 134 Namespace(s), Other Users' Namespace(s), and Shared 135 Namespace(s) that the server wishes to expose. The 136 response will contain a NIL for any namespace class that 137 is not available. Namespace_Response_Extensions MAY be 138 included in the response. Namespace_Response_Extensions 139 which are not on the IETF standards track, MUST be 140 prefixed with an "X-". 142 Result: OK - Command completed 143 NO - Error: Can't complete command 144 BAD - argument invalid 146 Example 5.1: 147 =========== 149 < A server that supports a single personal namespace. No leading 150 prefix is used on personal mailboxes and "/" is the hierarchy 151 delimiter.> 153 C: A001 NAMESPACE 154 S: * NAMESPACE (("" "/")) NIL NIL 155 S: A001 OK NAMESPACE command completed 157 Gahrns and Newman 3 158 IMAP4 Namespace November 1997 160 Example 5.2: 161 =========== 163 < A user logged on anonymously to a server. No personal 164 mailboxes are associated with the anonymous user and the user 165 does not have access to the Other Users' Namespace. No prefix is 166 required to access shared mailboxes and the hierarchy delimiter 167 is "." > 169 C: A001 NAMESPACE 170 S: * NAMESPACE NIL NIL (("" ".")) 171 S: A001 OK NAMESPACE command completed 173 Example 5.3: 174 =========== 176 < A server that contains a Personal Namespace and a single Shared 177 Namespace. > 179 C: A001 NAMESPACE 180 S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/")) 181 S: A001 OK NAMESPACE command completed 183 Example 5.4: 184 =========== 186 < A server that contains a Personal Namespace, Other Users' 187 Namespace and multiple Shared Namespaces. Note that the 188 hierarchy delimiter used within each namespace can be 189 different. > 191 C: A001 NAMESPACE 192 S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/") 193 ("#public/" "/")("#ftp/" "/")("#news." ".")) 194 S: A001 OK NAMESPACE command completed 196 The prefix string allows a client to do things such as automatically 197 creating personal mailboxes or LISTing all available mailboxes 198 within a namespace. 200 Example 5.5: 201 =========== 203 < A server that supports only the Personal Namespace, with a 204 leading prefix of INBOX to personal mailboxes and a hierarchy 205 delimiter of "."> 207 Gahrns and Newman 4 208 IMAP4 Namespace November 1997 210 C: A001 NAMESPACE 211 S: * NAMESPACE (("INBOX." ".")) NIL NIL 212 S: A001 OK NAMESPACE command completed 214 < Automatically create a mailbox to store sent items.> 216 C: A002 CREATE "INBOX.Sent Mail" 217 S: A002 OK CREATE command completed 219 Although typically a server will support only a single Personal 220 Namespace, and a single Other User's Namespace, circumstances exist 221 where there MAY be multiples of these, and a client MUST be prepared 222 for them. If a client is configured such that it is required to 223 create a certain mailbox, there can be circumstances where it is 224 unclear which Personal Namespaces it should create the mailbox in. 225 In these situations a client SHOULD let the user select which 226 namespaces to create the mailbox in. 228 Example 5.6: 229 =========== 231 < In this example, a server supports 2 Personal Namespaces. In 232 addition to the regular Personal Namespace, the user has an 233 additional personal namespace to allow access to mailboxes in an 234 MH format mailstore. > 236 < The client is configured to save a copy of all mail sent by the 237 user into a mailbox called 'Sent Mail'. Furthermore, after a 238 message is deleted from a mailbox, the client is configured to 239 move that message to a mailbox called 'Deleted Items'.> 241 < Note that this example demonstrates how some extension flags 242 can be passed to further describe the #mh namespace. > 244 C: A001 NAMESPACE 245 S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2"))) 246 NIL NIL 247 S: A001 OK NAMESPACE command completed 249 < It is desired to keep only one copy of sent mail. It is unclear 250 which Personal Namespace the client should use to create the 251 'Sent Mail' mailbox. The user is prompted to select a namespace 252 and only one 'Sent Mail' mailbox is created. > 254 C: A002 CREATE "Sent Mail" 255 S: A002 OK CREATE command completed 257 < The client is designed so that it keeps two 'Deleted Items' 258 mailboxes, one for each namespace. > 260 C: A003 CREATE "Delete Items" 262 Gahrns and Newman 5 263 IMAP4 Namespace November 1997 265 S: A003 OK CREATE command completed 267 C: A004 CREATE "#mh/Deleted Items" 268 S: A004 OK CREATE command completed 270 The next level of hierarchy following the Other Users' Namespace 271 prefix SHOULD consist of , where is a user name 272 as per the IMAP4 LOGIN or AUTHENTICATE command. 274 A client can construct a LIST command by appending a "%" to the 275 Other Users' Namespace prefix to discover the Personal Namespaces of 276 other users that are available to the currently authenticated user. 278 In response to such a LIST command, a server SHOULD NOT return user 279 names that have not granted access to their personal mailboxes to 280 the user in question. 282 A server MAY return a LIST response containing only the names of 283 users that have explicitly granted access to the user in question. 285 Alternatively, a server MAY return NO to such a LIST command, 286 requiring that a user name be included with the Other Users' 287 Namespace prefix before listing any other user's mailboxes. 289 Example 5.7: 290 =========== 292 < A server that supports providing a list of other user's 293 mailboxes that are accessible to the currently logged on user. > 295 C: A001 NAMESPACE 296 S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL 297 S: A001 OK NAMESPACE command completed 299 C: A002 LIST "" "Other Users/%" 300 S: * LIST () "/" "Other Users/Mike" 301 S: * LIST () "/" "Other Users/Karen" 302 S: * LIST () "/" "Other Users/Matthew" 303 S: * LIST () "/" "Other Users/Tesa" 304 S: A002 OK LIST command completed 306 Example 5.8: 307 =========== 309 < A server that does not support providing a list of other user's 310 mailboxes that are accessible to the currently logged on user. 311 The mailboxes are listable if the client includes the name of the 312 other user with the Other Users' Namespace prefix. > 314 Gahrns and Newman 6 315 IMAP4 Namespace November 1997 317 C: A001 NAMESPACE 318 S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL 319 S: A001 OK NAMESPACE command completed 321 < In this example, the currently logged on user has access to the 322 Personal Namespace of user Mike, but the server chose to suppress 323 this information in the LIST response. However, by appending the 324 user name Mike (received through user input) to the Other Users' 325 Namespace prefix, the client is able to get a listing of the 326 personal mailboxes of user Mike. > 328 C: A002 LIST "" "#Users/%" 329 S: A002 NO The requested item could not be found. 331 C: A003 LIST "" "#Users/Mike/%" 332 S: * LIST () "/" "#Users/Mike/INBOX" 333 S: * LIST () "/" "#Users/Mike/Foo" 334 S: A003 OK LIST command completed. 336 A prefix string MAY NOT contain a hierarchy delimiter, if it is not 337 needed as part of the prefix. 339 Example 5.9: 340 =========== 342 < A server that allows access to the Other Users' Namespace by 343 prefixing the others' mailboxes with a '~' followed by 344 , where is a user name as per the IMAP4 345 LOGIN or AUTHENTICATE command.> 347 C: A001 NAMESPACE 348 S: * NAMESPACE (("" "/")) (("~" "/")) NIL 349 S: A001 OK NAMESPACE command completed 351 < List the mailboxes for user mark > 353 C: A002 LIST "" "~mark/%" 354 S: * LIST () "/" "~mark/INBOX" 355 S: * LIST () "/" "~mark/foo" 356 S: A002 OK LIST command completed 358 Historical convention has been to start all namespaces with the "#" 359 character. Namespaces that include the "#" character are not IMAP 360 URL [IMAP-URL] friendly requiring the "#" character to be 361 represented as %23 when within URLs. As such, server implementers 362 MAY instead consider using namespace prefixes that do not contain 363 the "#" character. 365 Gahrns and Newman 7 366 IMAP4 Namespace November 1997 368 6. Formal Syntax 370 The following syntax specification uses the augmented Backus-Naur 371 Form (BNF) as described in [ABNF]. 373 atom = 374 ; as defined in [RFC-2060] 376 Namespace = nil / "(" 1*( "(" string SP (<"> QUOTED_CHAR <"> / 377 nil) *(Namespace_Response_Extension) ")" ) ")" 379 Namespace_Command = "NAMESPACE" 381 Namespace_Response_Extension = SP string SP "(" string *(SP string) 382 ")" 384 Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP 385 Namespace 387 ; The first Namespace is the Personal Namespace(s) 388 ; The second Namespace is the Other Users' Namespace(s) 389 ; The third Namespace is the Shared Namespace(s) 391 nil = 392 ; as defined in [RFC-2060] 394 QUOTED_CHAR = 395 ; as defined in [RFC-2060] 397 string = 398 ; as defined in [RFC-2060] 399 ; Note that the namespace prefix is to a mailbox and following 400 ; IMAP4 convention, any international string in the NAMESPACE 401 ; response MUST be of modified UTF-7 format as described in 402 ; [RFC-2060]. 404 7. Security Considerations 406 In response to a LIST command containing an argument of the Other 407 Users' Namespace prefix, a server SHOULD NOT list users that have 408 not granted access to their personal mailboxes to the currently 409 authenticated user. Providing such a list, could compromise 410 security by potentially disclosing confidential information of who 411 is located on the server, or providing a starting point of a list of 412 user accounts to attack. 414 8. References 416 [RFC-2060], Crispin, M., "Internet Message Access Protocol � Version 417 4rev1", RFC 2060, University of Washington, December 1996. 419 Gahrns and Newman 8 420 IMAP4 Namespace November 1997 422 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 423 Requirement Levels", RFC 2119, Harvard University, March 1997 425 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for 426 Syntax Specifications: ABNF", draft-drums-abnf-04.txt (work in 427 progress), Internet Mail Consortium, September 1997 429 [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, 430 September 1997 432 9. Acknowledgments 434 Many people have participated in the discussion of IMAP namespaces 435 on the IMAP mailing list. In particular, the authors would like to 436 thank Mark Crispin for many of the concepts relating to the Personal 437 Namespace and accessing the Personal Namespace of other users, Steve 438 Hole for summarizing the two namespace models, John Myers and Jack 439 De Winter for their work in a preceding effort trying to define a 440 standardized personal namespace, and Larry Osterman for his review 441 and collaboration on this document. 443 11. Author's Addresses 445 Mike Gahrns 446 Microsoft 447 One Microsoft Way 448 Redmond, WA, 98072, USA 449 Phone: (425) 936-9833 450 Email: mikega@microsoft.com 452 Chris Newman 453 Innosoft International, Inc. 454 1050 East Garvey Ave. South 455 West Covina, CA, 91790, USA 456 Email: chris.newman@innosoft.com 458 Gahrns and Newman 9