imapext-2007

annotate docs/rfc/rfc2342.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group M. Gahrns
yuuji@0 8 Request for Comments: 2342 Microsoft
yuuji@0 9 Category: Standards Track C. Newman
yuuji@0 10 Innosoft
yuuji@0 11 May 1998
yuuji@0 12
yuuji@0 13
yuuji@0 14 IMAP4 Namespace
yuuji@0 15
yuuji@0 16 Status of this Memo
yuuji@0 17
yuuji@0 18 This document specifies an Internet standards track protocol for the
yuuji@0 19 Internet community, and requests discussion and suggestions for
yuuji@0 20 improvements. Please refer to the current edition of the "Internet
yuuji@0 21 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 22 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 23
yuuji@0 24 Copyright Notice
yuuji@0 25
yuuji@0 26 Copyright (C) The Internet Society (1998). All Rights Reserved.
yuuji@0 27
yuuji@0 28 1. Abstract
yuuji@0 29
yuuji@0 30 IMAP4 [RFC-2060] does not define a default server namespace. As a
yuuji@0 31 result, two common namespace models have evolved:
yuuji@0 32
yuuji@0 33 The "Personal Mailbox" model, in which the default namespace that is
yuuji@0 34 presented consists of only the user's personal mailboxes. To access
yuuji@0 35 shared mailboxes, the user must use an escape mechanism to reach
yuuji@0 36 another namespace.
yuuji@0 37
yuuji@0 38 The "Complete Hierarchy" model, in which the default namespace that
yuuji@0 39 is presented includes the user's personal mailboxes along with any
yuuji@0 40 other mailboxes they have access to.
yuuji@0 41
yuuji@0 42 These two models, create difficulties for certain client operations.
yuuji@0 43 This document defines a NAMESPACE command that allows a client to
yuuji@0 44 discover the prefixes of namespaces used by a server for personal
yuuji@0 45 mailboxes, other users' mailboxes, and shared mailboxes. This allows
yuuji@0 46 a client to avoid much of the manual user configuration that is now
yuuji@0 47 necessary when mixing and matching IMAP4 clients and servers.
yuuji@0 48
yuuji@0 49 2. Conventions used in this document
yuuji@0 50
yuuji@0 51 In examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 52 server respectively. If such lines are wrapped without a new "C:" or
yuuji@0 53 "S:" label, then the wrapping is for editorial clarity and is not
yuuji@0 54 part of the command.
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Gahrns & Newman Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 61
yuuji@0 62
yuuji@0 63 Personal Namespace: A namespace that the server considers within the
yuuji@0 64 personal scope of the authenticated user on a particular connection.
yuuji@0 65 Typically, only the authenticated user has access to mailboxes in
yuuji@0 66 their Personal Namespace. It is the part of the namespace that
yuuji@0 67 belongs to the user that is allocated for mailboxes. If an INBOX
yuuji@0 68 exists for a user, it MUST appear within the user's personal
yuuji@0 69 namespace. In the typical case, there SHOULD be only one Personal
yuuji@0 70 Namespace on a server.
yuuji@0 71
yuuji@0 72 Other Users' Namespace: A namespace that consists of mailboxes from
yuuji@0 73 the Personal Namespaces of other users. To access mailboxes in the
yuuji@0 74 Other Users' Namespace, the currently authenticated user MUST be
yuuji@0 75 explicitly granted access rights. For example, it is common for a
yuuji@0 76 manager to grant to their secretary access rights to their mailbox.
yuuji@0 77 In the typical case, there SHOULD be only one Other Users' Namespace
yuuji@0 78 on a server.
yuuji@0 79
yuuji@0 80 Shared Namespace: A namespace that consists of mailboxes that are
yuuji@0 81 intended to be shared amongst users and do not exist within a user's
yuuji@0 82 Personal Namespace.
yuuji@0 83
yuuji@0 84 The namespaces a server uses MAY differ on a per-user basis.
yuuji@0 85
yuuji@0 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 88 document are to be interpreted as described in [RFC-2119].
yuuji@0 89
yuuji@0 90 3. Introduction and Overview
yuuji@0 91
yuuji@0 92 Clients often attempt to create mailboxes for such purposes as
yuuji@0 93 maintaining a record of sent messages (e.g. "Sent Mail") or
yuuji@0 94 temporarily saving messages being composed (e.g. "Drafts"). For
yuuji@0 95 these clients to inter-operate correctly with the variety of IMAP4
yuuji@0 96 servers available, the user must enter the prefix of the Personal
yuuji@0 97 Namespace used by the server. Using the NAMESPACE command, a client
yuuji@0 98 is able to automatically discover this prefix without manual user
yuuji@0 99 configuration.
yuuji@0 100
yuuji@0 101 In addition, users are often required to manually enter the prefixes
yuuji@0 102 of various namespaces in order to view the mailboxes located there.
yuuji@0 103 For example, they might be required to enter the prefix of #shared to
yuuji@0 104 view the shared mailboxes namespace. The NAMESPACE command allows a
yuuji@0 105 client to automatically discover the namespaces that are available on
yuuji@0 106 a server. This allows a client to present the available namespaces to
yuuji@0 107 the user in what ever manner it deems appropriate. For example, a
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Gahrns & Newman Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 117
yuuji@0 118
yuuji@0 119 client could choose to initially display only personal mailboxes, or
yuuji@0 120 it may choose to display the complete list of mailboxes available,
yuuji@0 121 and initially position the user at the root of their Personal
yuuji@0 122 Namespace.
yuuji@0 123
yuuji@0 124 A server MAY choose to make available to the NAMESPACE command only a
yuuji@0 125 subset of the complete set of namespaces the server supports. To
yuuji@0 126 provide the ability to access these namespaces, a client SHOULD allow
yuuji@0 127 the user the ability to manually enter a namespace prefix.
yuuji@0 128
yuuji@0 129 4. Requirements
yuuji@0 130
yuuji@0 131 IMAP4 servers that support this extension MUST list the keyword
yuuji@0 132 NAMESPACE in their CAPABILITY response.
yuuji@0 133
yuuji@0 134 The NAMESPACE command is valid in the Authenticated and Selected
yuuji@0 135 state.
yuuji@0 136
yuuji@0 137 5. NAMESPACE Command
yuuji@0 138
yuuji@0 139 Arguments: none
yuuji@0 140
yuuji@0 141 Response: an untagged NAMESPACE response that contains the prefix
yuuji@0 142 and hierarchy delimiter to the server's Personal
yuuji@0 143 Namespace(s), Other Users' Namespace(s), and Shared
yuuji@0 144 Namespace(s) that the server wishes to expose. The
yuuji@0 145 response will contain a NIL for any namespace class
yuuji@0 146 that is not available. Namespace_Response_Extensions
yuuji@0 147 MAY be included in the response.
yuuji@0 148 Namespace_Response_Extensions which are not on the IETF
yuuji@0 149 standards track, MUST be prefixed with an "X-".
yuuji@0 150
yuuji@0 151 Result: OK - Command completed
yuuji@0 152 NO - Error: Can't complete command
yuuji@0 153 BAD - argument invalid
yuuji@0 154
yuuji@0 155 Example 5.1:
yuuji@0 156 ===========
yuuji@0 157
yuuji@0 158 < A server that supports a single personal namespace. No leading
yuuji@0 159 prefix is used on personal mailboxes and "/" is the hierarchy
yuuji@0 160 delimiter.>
yuuji@0 161
yuuji@0 162 C: A001 NAMESPACE
yuuji@0 163 S: * NAMESPACE (("" "/")) NIL NIL
yuuji@0 164 S: A001 OK NAMESPACE command completed
yuuji@0 165
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Gahrns & Newman Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 173
yuuji@0 174
yuuji@0 175 Example 5.2:
yuuji@0 176 ===========
yuuji@0 177
yuuji@0 178 < A user logged on anonymously to a server. No personal mailboxes
yuuji@0 179 are associated with the anonymous user and the user does not have
yuuji@0 180 access to the Other Users' Namespace. No prefix is required to
yuuji@0 181 access shared mailboxes and the hierarchy delimiter is "." >
yuuji@0 182
yuuji@0 183 C: A001 NAMESPACE
yuuji@0 184 S: * NAMESPACE NIL NIL (("" "."))
yuuji@0 185 S: A001 OK NAMESPACE command completed
yuuji@0 186
yuuji@0 187 Example 5.3:
yuuji@0 188 ===========
yuuji@0 189
yuuji@0 190 < A server that contains a Personal Namespace and a single Shared
yuuji@0 191 Namespace. >
yuuji@0 192
yuuji@0 193 C: A001 NAMESPACE
yuuji@0 194 S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
yuuji@0 195 S: A001 OK NAMESPACE command completed
yuuji@0 196
yuuji@0 197 Example 5.4:
yuuji@0 198 ===========
yuuji@0 199
yuuji@0 200 < A server that contains a Personal Namespace, Other Users'
yuuji@0 201 Namespace and multiple Shared Namespaces. Note that the hierarchy
yuuji@0 202 delimiter used within each namespace can be different. >
yuuji@0 203
yuuji@0 204 C: A001 NAMESPACE
yuuji@0 205 S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
yuuji@0 206 ("#public/" "/")("#ftp/" "/")("#news." "."))
yuuji@0 207 S: A001 OK NAMESPACE command completed
yuuji@0 208
yuuji@0 209 The prefix string allows a client to do things such as automatically
yuuji@0 210 creating personal mailboxes or LISTing all available mailboxes within
yuuji@0 211 a namespace.
yuuji@0 212
yuuji@0 213 Example 5.5:
yuuji@0 214 ===========
yuuji@0 215
yuuji@0 216 < A server that supports only the Personal Namespace, with a
yuuji@0 217 leading prefix of INBOX to personal mailboxes and a hierarchy
yuuji@0 218 delimiter of ".">
yuuji@0 219
yuuji@0 220 C: A001 NAMESPACE
yuuji@0 221 S: * NAMESPACE (("INBOX." ".")) NIL NIL
yuuji@0 222 S: A001 OK NAMESPACE command completed
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Gahrns & Newman Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 229
yuuji@0 230
yuuji@0 231 < Automatically create a mailbox to store sent items.>
yuuji@0 232
yuuji@0 233 C: A002 CREATE "INBOX.Sent Mail"
yuuji@0 234 S: A002 OK CREATE command completed
yuuji@0 235
yuuji@0 236 Although typically a server will support only a single Personal
yuuji@0 237 Namespace, and a single Other User's Namespace, circumstances exist
yuuji@0 238 where there MAY be multiples of these, and a client MUST be prepared
yuuji@0 239 for them. If a client is configured such that it is required to
yuuji@0 240 create a certain mailbox, there can be circumstances where it is
yuuji@0 241 unclear which Personal Namespaces it should create the mailbox in.
yuuji@0 242 In these situations a client SHOULD let the user select which
yuuji@0 243 namespaces to create the mailbox in.
yuuji@0 244
yuuji@0 245 Example 5.6:
yuuji@0 246 ===========
yuuji@0 247
yuuji@0 248 < In this example, a server supports 2 Personal Namespaces. In
yuuji@0 249 addition to the regular Personal Namespace, the user has an
yuuji@0 250 additional personal namespace to allow access to mailboxes in an
yuuji@0 251 MH format mailstore. >
yuuji@0 252
yuuji@0 253 < The client is configured to save a copy of all mail sent by the
yuuji@0 254 user into a mailbox called 'Sent Mail'. Furthermore, after a
yuuji@0 255 message is deleted from a mailbox, the client is configured to
yuuji@0 256 move that message to a mailbox called 'Deleted Items'.>
yuuji@0 257
yuuji@0 258 < Note that this example demonstrates how some extension flags can
yuuji@0 259 be passed to further describe the #mh namespace. >
yuuji@0 260
yuuji@0 261 C: A001 NAMESPACE
yuuji@0 262 S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
yuuji@0 263 NIL NIL
yuuji@0 264 S: A001 OK NAMESPACE command completed
yuuji@0 265
yuuji@0 266 < It is desired to keep only one copy of sent mail. It is unclear
yuuji@0 267 which Personal Namespace the client should use to create the 'Sent
yuuji@0 268 Mail' mailbox. The user is prompted to select a namespace and
yuuji@0 269 only one 'Sent Mail' mailbox is created. >
yuuji@0 270
yuuji@0 271 C: A002 CREATE "Sent Mail"
yuuji@0 272 S: A002 OK CREATE command completed
yuuji@0 273
yuuji@0 274 < The client is designed so that it keeps two 'Deleted Items'
yuuji@0 275 mailboxes, one for each namespace. >
yuuji@0 276
yuuji@0 277 C: A003 CREATE "Delete Items"
yuuji@0 278 S: A003 OK CREATE command completed
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Gahrns & Newman Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 285
yuuji@0 286
yuuji@0 287 C: A004 CREATE "#mh/Deleted Items"
yuuji@0 288 S: A004 OK CREATE command completed
yuuji@0 289
yuuji@0 290 The next level of hierarchy following the Other Users' Namespace
yuuji@0 291 prefix SHOULD consist of <username>, where <username> is a user name
yuuji@0 292 as per the IMAP4 LOGIN or AUTHENTICATE command.
yuuji@0 293
yuuji@0 294 A client can construct a LIST command by appending a "%" to the Other
yuuji@0 295 Users' Namespace prefix to discover the Personal Namespaces of other
yuuji@0 296 users that are available to the currently authenticated user.
yuuji@0 297
yuuji@0 298 In response to such a LIST command, a server SHOULD NOT return user
yuuji@0 299 names that have not granted access to their personal mailboxes to the
yuuji@0 300 user in question.
yuuji@0 301
yuuji@0 302 A server MAY return a LIST response containing only the names of
yuuji@0 303 users that have explicitly granted access to the user in question.
yuuji@0 304
yuuji@0 305 Alternatively, a server MAY return NO to such a LIST command,
yuuji@0 306 requiring that a user name be included with the Other Users'
yuuji@0 307 Namespace prefix before listing any other user's mailboxes.
yuuji@0 308
yuuji@0 309 Example 5.7:
yuuji@0 310 ===========
yuuji@0 311
yuuji@0 312 < A server that supports providing a list of other user's
yuuji@0 313 mailboxes that are accessible to the currently logged on user. >
yuuji@0 314
yuuji@0 315 C: A001 NAMESPACE
yuuji@0 316 S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
yuuji@0 317 S: A001 OK NAMESPACE command completed
yuuji@0 318
yuuji@0 319 C: A002 LIST "" "Other Users/%"
yuuji@0 320 S: * LIST () "/" "Other Users/Mike"
yuuji@0 321 S: * LIST () "/" "Other Users/Karen"
yuuji@0 322 S: * LIST () "/" "Other Users/Matthew"
yuuji@0 323 S: * LIST () "/" "Other Users/Tesa"
yuuji@0 324 S: A002 OK LIST command completed
yuuji@0 325
yuuji@0 326 Example 5.8:
yuuji@0 327 ===========
yuuji@0 328
yuuji@0 329 < A server that does not support providing a list of other user's
yuuji@0 330 mailboxes that are accessible to the currently logged on user.
yuuji@0 331 The mailboxes are listable if the client includes the name of the
yuuji@0 332 other user with the Other Users' Namespace prefix. >
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Gahrns & Newman Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 341
yuuji@0 342
yuuji@0 343 C: A001 NAMESPACE
yuuji@0 344 S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
yuuji@0 345 S: A001 OK NAMESPACE command completed
yuuji@0 346
yuuji@0 347 < In this example, the currently logged on user has access to the
yuuji@0 348 Personal Namespace of user Mike, but the server chose to suppress
yuuji@0 349 this information in the LIST response. However, by appending the
yuuji@0 350 user name Mike (received through user input) to the Other Users'
yuuji@0 351 Namespace prefix, the client is able to get a listing of the
yuuji@0 352 personal mailboxes of user Mike. >
yuuji@0 353
yuuji@0 354 C: A002 LIST "" "#Users/%"
yuuji@0 355 S: A002 NO The requested item could not be found.
yuuji@0 356
yuuji@0 357 C: A003 LIST "" "#Users/Mike/%"
yuuji@0 358 S: * LIST () "/" "#Users/Mike/INBOX"
yuuji@0 359 S: * LIST () "/" "#Users/Mike/Foo"
yuuji@0 360 S: A003 OK LIST command completed.
yuuji@0 361
yuuji@0 362 A prefix string might not contain a hierarchy delimiter, because
yuuji@0 363 in some cases it is not needed as part of the prefix.
yuuji@0 364
yuuji@0 365 Example 5.9:
yuuji@0 366 ===========
yuuji@0 367
yuuji@0 368 < A server that allows access to the Other Users' Namespace by
yuuji@0 369 prefixing the others' mailboxes with a '~' followed by <username>,
yuuji@0 370 where <username> is a user name as per the IMAP4 LOGIN or
yuuji@0 371 AUTHENTICATE command.>
yuuji@0 372
yuuji@0 373 C: A001 NAMESPACE
yuuji@0 374 S: * NAMESPACE (("" "/")) (("~" "/")) NIL
yuuji@0 375 S: A001 OK NAMESPACE command completed
yuuji@0 376
yuuji@0 377 < List the mailboxes for user mark >
yuuji@0 378
yuuji@0 379 C: A002 LIST "" "~mark/%"
yuuji@0 380 S: * LIST () "/" "~mark/INBOX"
yuuji@0 381 S: * LIST () "/" "~mark/foo"
yuuji@0 382 S: A002 OK LIST command completed
yuuji@0 383
yuuji@0 384 Historical convention has been to start all namespaces with the "#"
yuuji@0 385 character. Namespaces that include the "#" character are not IMAP
yuuji@0 386 URL [IMAP-URL] friendly requiring the "#" character to be represented
yuuji@0 387 as %23 when within URLs. As such, server implementers MAY instead
yuuji@0 388 consider using namespace prefixes that do not contain the "#"
yuuji@0 389 character.
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Gahrns & Newman Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 397
yuuji@0 398
yuuji@0 399 6. Formal Syntax
yuuji@0 400
yuuji@0 401 The following syntax specification uses the augmented Backus-Naur
yuuji@0 402 Form (BNF) as described in [ABNF].
yuuji@0 403
yuuji@0 404 atom = <atom>
yuuji@0 405 ; <atom> as defined in [RFC-2060]
yuuji@0 406
yuuji@0 407 Namespace = nil / "(" 1*( "(" string SP (<"> QUOTED_CHAR <"> /
yuuji@0 408 nil) *(Namespace_Response_Extension) ")" ) ")"
yuuji@0 409
yuuji@0 410 Namespace_Command = "NAMESPACE"
yuuji@0 411
yuuji@0 412 Namespace_Response_Extension = SP string SP "(" string *(SP string)
yuuji@0 413 ")"
yuuji@0 414
yuuji@0 415 Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
yuuji@0 416 Namespace
yuuji@0 417
yuuji@0 418 ; The first Namespace is the Personal Namespace(s)
yuuji@0 419 ; The second Namespace is the Other Users' Namespace(s)
yuuji@0 420 ; The third Namespace is the Shared Namespace(s)
yuuji@0 421
yuuji@0 422 nil = <nil>
yuuji@0 423 ; <nil> as defined in [RFC-2060]
yuuji@0 424
yuuji@0 425 QUOTED_CHAR = <QUOTED_CHAR>
yuuji@0 426 ; <QUOTED_CHAR> as defined in [RFC-2060]
yuuji@0 427
yuuji@0 428 string = <string>
yuuji@0 429 ; <string> as defined in [RFC-2060]
yuuji@0 430 ; Note that the namespace prefix is to a mailbox and following
yuuji@0 431 ; IMAP4 convention, any international string in the NAMESPACE
yuuji@0 432 ; response MUST be of modified UTF-7 format as described in
yuuji@0 433 ; [RFC-2060].
yuuji@0 434
yuuji@0 435 7. Security Considerations
yuuji@0 436
yuuji@0 437 In response to a LIST command containing an argument of the Other
yuuji@0 438 Users' Namespace prefix, a server SHOULD NOT list users that have not
yuuji@0 439 granted list access to their personal mailboxes to the currently
yuuji@0 440 authenticated user. Providing such a list, could compromise security
yuuji@0 441 by potentially disclosing confidential information of who is located
yuuji@0 442 on the server, or providing a starting point of a list of user
yuuji@0 443 accounts to attack.
yuuji@0 444
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Gahrns & Newman Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 453
yuuji@0 454
yuuji@0 455 8. References
yuuji@0 456
yuuji@0 457 [RFC-2060], Crispin, M., "Internet Message Access Protocol Version
yuuji@0 458 4rev1", RFC 2060, December 1996.
yuuji@0 459
yuuji@0 460 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 461 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 462
yuuji@0 463 [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
yuuji@0 464 Specifications: ABNF", RFC 2234, November 1997.
yuuji@0 465
yuuji@0 466 [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
yuuji@0 467
yuuji@0 468 9. Acknowledgments
yuuji@0 469
yuuji@0 470 Many people have participated in the discussion of IMAP namespaces on
yuuji@0 471 the IMAP mailing list. In particular, the authors would like to
yuuji@0 472 thank Mark Crispin for many of the concepts relating to the Personal
yuuji@0 473 Namespace and accessing the Personal Namespace of other users, Steve
yuuji@0 474 Hole for summarizing the two namespace models, John Myers and Jack De
yuuji@0 475 Winter for their work in a preceding effort trying to define a
yuuji@0 476 standardized personal namespace, and Larry Osterman for his review
yuuji@0 477 and collaboration on this document.
yuuji@0 478
yuuji@0 479 11. Authors' Addresses
yuuji@0 480
yuuji@0 481 Mike Gahrns
yuuji@0 482 Microsoft
yuuji@0 483 One Microsoft Way
yuuji@0 484 Redmond, WA, 98072, USA
yuuji@0 485
yuuji@0 486 Phone: (425) 936-9833
yuuji@0 487 EMail: mikega@microsoft.com
yuuji@0 488
yuuji@0 489
yuuji@0 490 Chris Newman
yuuji@0 491 Innosoft International, Inc.
yuuji@0 492 1050 East Garvey Ave. South
yuuji@0 493 West Covina, CA, 91790, USA
yuuji@0 494
yuuji@0 495 EMail: chris.newman@innosoft.com
yuuji@0 496
yuuji@0 497
yuuji@0 498
yuuji@0 499
yuuji@0 500
yuuji@0 501
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Gahrns & Newman Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 2342 IMAP4 Namespace May 1998
yuuji@0 509
yuuji@0 510
yuuji@0 511 12. Full Copyright Statement
yuuji@0 512
yuuji@0 513 Copyright (C) The Internet Society (1998). All Rights Reserved.
yuuji@0 514
yuuji@0 515 This document and translations of it may be copied and furnished to
yuuji@0 516 others, and derivative works that comment on or otherwise explain it
yuuji@0 517 or assist in its implementation may be prepared, copied, published
yuuji@0 518 and distributed, in whole or in part, without restriction of any
yuuji@0 519 kind, provided that the above copyright notice and this paragraph are
yuuji@0 520 included on all such copies and derivative works. However, this
yuuji@0 521 document itself may not be modified in any way, such as by removing
yuuji@0 522 the copyright notice or references to the Internet Society or other
yuuji@0 523 Internet organizations, except as needed for the purpose of
yuuji@0 524 developing Internet standards in which case the procedures for
yuuji@0 525 copyrights defined in the Internet Standards process must be
yuuji@0 526 followed, or as required to translate it into languages other than
yuuji@0 527 English.
yuuji@0 528
yuuji@0 529 The limited permissions granted above are perpetual and will not be
yuuji@0 530 revoked by the Internet Society or its successors or assigns.
yuuji@0 531
yuuji@0 532 This document and the information contained herein is provided on an
yuuji@0 533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
yuuji@0 534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
yuuji@0 535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
yuuji@0 536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
yuuji@0 537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 538
yuuji@0 539
yuuji@0 540
yuuji@0 541
yuuji@0 542
yuuji@0 543
yuuji@0 544
yuuji@0 545
yuuji@0 546
yuuji@0 547
yuuji@0 548
yuuji@0 549
yuuji@0 550
yuuji@0 551
yuuji@0 552
yuuji@0 553
yuuji@0 554
yuuji@0 555
yuuji@0 556
yuuji@0 557
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Gahrns & Newman Standards Track [Page 10]
yuuji@0 563

UW-IMAP'd extensions by yuuji