idnits 2.17.1 draft-melnikov-imap-rfc2180bis-00.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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 708. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 651), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages -- Found 15 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** There are 2 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2180, but the abstract doesn't seem to directly say this. It does mention RFC2180 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gahrns 3 Obsoletes: 2180 Microsoft 4 Category: Informational A. Melnikov 5 Expires: April 2005 Isode Ltd. (Editor) 7 IMAP4 Multi-Accessed Mailbox Practice 8 draft-melnikov-imap-rfc2180bis-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a revision of RFC 2180 by Mike Gahrns. A revised 34 version of this draft document will be submitted to the RFC editor as 35 an Informational document. Discussion and suggestions for improvement 36 are requested, and should be sent to the IMAP4 Mailing list 37 (imap@CAC.Washington.EDU). To subscribe to the list, send email to 38 with the text "subscribe imap YourName" 39 in the body of the message. Distribution of this memo is unlimited. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 1. Abstract 47 IMAP4[IMAP4] is rich client/server protocol that allows a client to 48 access and manipulate electronic mail messages on a server. Within 50 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 52 the protocol framework, it is possible to have differing results for 53 particular client/server interactions. If a protocol does not allow 54 for this, it is often unduly restrictive. 56 For example, when multiple clients are accessing a mailbox and one 57 attempts to delete the mailbox, an IMAP4 server may choose to 58 implement a solution based upon server architectural constraints or 59 individual preference. 61 With this flexibility comes greater client responsibility. It is not 62 sufficient for a client to be written based upon the behavior of a 63 particular IMAP server. Rather the client must be based upon the 64 behavior allowed by the protocol. 66 By documenting common IMAP4 server practice for the case of 67 simultaneous client access to a mailbox, we hope to ensure the widest 68 amount of inter-operation between IMAP4 clients and servers. 70 The behavior described in this document reflects the practice of some 71 existing servers or behavior that the consensus of the IMAP mailing 72 list has deemed to be reasonable. The behavior described within this 73 document is believed to be [IMAP4] compliant. However, this document 74 is not meant to define IMAP4 compliance, nor is it an exhaustive list 75 of valid IMAP4 behavior. [IMAP4] must always be consulted to 76 determine IMAP4 compliance, especially for server behavior not 77 described within this document. 79 2. Conventions used in this document 81 In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different 82 clients (client #1, client #2 and client #3) that are connected to a 83 server. "S1:", "S2:" and "S3:" indicated lines sent by the server to 84 client #1, client #2 and client #3 respectively. 86 A shared mailbox, is a mailbox that can be used by multiple users. 88 A multi-accessed mailbox, is a mailbox that has multiple clients 89 simultaneously accessing it. 91 A client is said to have accessed a mailbox after a successful SELECT 92 or EXAMINE command. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC-2119]. 98 3. Deletion/Renaming of a multi-accessed mailbox 100 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 102 If an external agent or multiple clients are accessing a mailbox, 103 care must be taken when handling the deletion or renaming of the 104 mailbox. Following are some strategies an IMAP server may choose to 105 use when dealing with this situation. 107 3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed 108 mailbox 110 In some cases, this behavior may not be practical. For example, if a 111 large number of clients are accessing a shared mailbox, the window in 112 which no clients have the mailbox accessed may be small or non- 113 existent, effectively rendering the mailbox undeletable or 114 unrenamable. 116 Example: 118 121 C1: A001 DELETE FOO 122 S1: A001 NO Mailbox FOO is in use by another user. 124 3.2. The server MAY allow the DELETE command of a multi-accessed 125 mailbox, but keep the information in the mailbox available for 126 those clients that currently have access to the mailbox. 128 When all clients have finished accessing the mailbox, it is 129 permanently removed. For clients that do not already have access to 130 the mailbox, the 'ghosted' mailbox would not be available. For 131 example, it would not be returned to these clients in a subsequent 132 LIST or LSUB command and would not be a valid mailbox argument to any 133 other IMAP command until the reference count of clients accessing the 134 mailbox reached 0. 136 In some cases, this behavior may not be desirable. For example if 137 someone created a mailbox with offensive or sensitive information, 138 one might prefer to have the mailbox deleted and all access to the 139 information contained within removed immediately, rather than 140 continuing to allow access until the client closes the mailbox. 142 Furthermore, this behavior, may prevent 'recycling' of the same 143 mailbox name until all clients have finished accessing the original 144 mailbox. 146 Example: 148 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 150 153 C1: A001 DELETE FOO 154 S1: A001 OK Mailbox FOO is deleted. 156 158 C2: B001 STORE 1 +FLAGS (\Seen) 159 S2: * 1 FETCH (FLAGS (\Seen)) 160 S2: B001 OK STORE completed 162 165 C3: C001 STATUS FOO (MESSAGES) 166 S3: C001 NO Mailbox does not exist 168 171 C3: C002 CREATE FOO 172 S3: C002 NO Mailbox FOO is still in use. Try again later. 174 177 C2: B002 CLOSE 178 S2: B002 OK CLOSE Completed 180 183 C3: C003 CREATE FOO 184 S3: C003 OK CREATE Completed 186 3.3. The server MAY allow the DELETE/RENAME of a multi-accessed 187 mailbox, but disconnect all other clients who have the mailbox 188 accessed by sending a untagged BYE response. 190 A server may often choose to disconnect clients in the DELETE case, 191 but may choose to implement a "friendlier" method for the RENAME 192 case. 194 Example: 196 202 C1: A002 DELETE FOO 203 S1: A002 OK DELETE completed. 205 206 S2: * BYE Mailbox FOO has been deleted. 208 3.4. The server MAY allow the RENAME of a multi-accessed mailbox by 209 simply changing the name attribute on the mailbox. 211 Other clients that have access to the mailbox can continue issuing 212 commands such as FETCH that do not reference the mailbox name. 213 Clients would discover the renaming the next time they referred to 214 the old mailbox name. Some servers MAY choose to include the 215 REFERRAL response code [REFERRAL] in their tagged NO response to a 216 command that contained the URL for the old mailbox name, as a hint to 217 the client that the operation can succeed if the command is issued 218 with the new mailbox name. 220 Example: 222 225 C1: A001 RENAME FOO BAR 226 S1: A001 OK RENAME completed. 228 231 C2: B001 FETCH 2:4 (FLAGS) 232 S2: * 2 FETCH . . . 233 S2: * 3 FETCH . . . 234 S2: * 4 FETCH . . . 235 S2: B001 OK FETCH completed 237 240 C2: B002 APPEND FOO {300} 241 C2: Date: Mon, 7 Feb 1994 21:52:25 0800 (PST) 242 C2: . . . 243 S2: B002 NO [REFERRAL IMAP://user;AUTH=*@SERVER.EXAMPLE.COM/FOO 244 IMAP://user;AUTH=*@SERVER.EXAMPLE.COM/BAR] Mailbox has been renamed 245 In the example above SERVER.EXAMPLE.COM references the 246 server the client is connected to. 248 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 250 4. Expunging of messages on a multi-accessed mailbox 252 If an external agent or multiple clients are accessing a mailbox, 253 care must be taken when handling the EXPUNGE of messages. Other 254 clients accessing the mailbox may be in the midst of issuing a 255 command that depends upon message sequence numbers. Because an 256 EXPUNGE response can not be sent while responding to a FETCH, STORE 257 or SEARCH command, it is not possible to immediately notify the 258 client of the EXPUNGE. This can result in ambiguity if the client 259 issues a FETCH, STORE or SEARCH operation on a message that has been 260 EXPUNGED. 262 4.1. Fetching of expunged messages 264 Following are some strategies an IMAP server may choose to use when 265 dealing with a FETCH command on expunged messages. 267 Consider the following scenario: 269 - Client #1 and Client #2 have mailbox FOO selected. 270 - There are 7 messages in the mailbox. 271 - Messages 4:7 are marked for deletion. 272 - Client #1 issues an EXPUNGE, to expunge messages 4:7 274 4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but 275 keep the messages available to satisfy subsequent FETCH commands 276 until it is able to send an EXPUNGE response to each client. 278 In some cases, the behavior of keeping "ghosted" messages may not be 279 desirable. For example if a message contained offensive or sensitive 280 information, one might prefer to instantaneously remove all access to 281 the information, regardless of whether another client is in the midst 282 of accessing it. 284 Example: (Building upon the scenario outlined in 4.1.) 286 290 C2: B001 FETCH 4:7 RFC822 291 S2: * 4 FETCH (RFC822 . . . ) 292 S2: * 5 FETCH (RFC822 . . . ) 293 S2: * 6 FETCH (RFC822 . . . ) 294 S2: * 7 FETCH (RFC822 . . . ) 295 S2: B001 OK FETCH Completed 297 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 299 301 C2: B002 NOOP 302 S2: * 4 EXPUNGE 303 S2: * 4 EXPUNGE 304 S2: * 4 EXPUNGE 305 S2: * 4 EXPUNGE 306 S2: * 3 EXISTS 307 S2: B002 OK NOOP Complete 309 311 C2: B003 FETCH 4:7 RFC822 312 S2: B003 NO Messages 4:7 are no longer available. 314 4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, 315 and on subsequent FETCH commands return FETCH responses only for 316 non-expunged messages and a tagged NO. 318 After receiving a tagged NO FETCH response, the client SHOULD issue a 319 NOOP command so that it will be informed of any pending EXPUNGE 320 responses. The client may then either reissue the failed FETCH 321 command, or by examining the EXPUNGE response from the NOOP and the 322 FETCH response from the FETCH, determine that the FETCH failed 323 because of pending expunges. 325 Example: (Building upon the scenario outlined in 4.1.) 327 331 C2: B001 FETCH 3:5 ENVELOPE 332 S2: * 3 FETCH (ENVELOPE . . . ) 333 S2: B001 NO Some of the requested messages no longer exist 335 338 C2: B002 NOOP 339 S2: * 4 EXPUNGE 340 S2: * 4 EXPUNGE 341 S2: * 4 EXPUNGE 342 S2: * 4 EXPUNGE 343 S2: * 3 EXISTS 344 S2: B002 OK NOOP Completed. 346 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 348 352 4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and 353 on subsequent FETCH commands return the usual FETCH responses for 354 non-expunged messages, "NIL FETCH Responses" for expunged 355 messages, and a tagged OK response. 357 If all of the messages in the subsequent FETCH command have been 358 expunged, the server SHOULD return only a tagged NO. In this case, 359 the client SHOULD issue a NOOP command so that it will be informed of 360 any pending EXPUNGE responses. The client may then either reissue 361 the failed FETCH command, or by examining the EXPUNGE response from 362 the NOOP, determine that the FETCH failed because of pending 363 expunges. 365 "NIL FETCH responses" are a representation of empty data as 366 appropriate for the FETCH argument specified. 368 Example: 370 * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) 371 * 1 FETCH (FLAGS ()) 372 * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") 373 * 1 FETCH (RFC822 "") 374 * 1 FETCH (RFC822.HEADER "") 375 * 1 FETCH (RFC822.TEXT "") 376 * 1 FETCH (RFC822.SIZE 0) 377 * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) 378 * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) 379 * 1 FETCH (BODY[
] "") 380 * 1 FETCH (BODY[
] "") 382 In some cases, a client may not be able to distinguish between "NIL 383 FETCH responses" received because a message was expunged and those 384 received because the data actually was NIL. For example, a * 5 385 FETCH (FLAGS ()) response could be received if no flags were set on 386 message 5, or because message 5 was expunged. In a case of potential 387 ambiguity, the client SHOULD issue a command such as NOOP to force 388 the sending of the EXPUNGE responses to resolve any ambiguity. 390 Example: (Building upon the scenario outlined in 4.1.) 392 396 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 398 C2: B002 FETCH 3:5 ENVELOPE 399 S2: * 3 FETCH (ENVELOPE . . . ) 400 S2: * 4 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL 401 NIL NIL)) 402 S2: * 5 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL 403 NIL NIL)) 404 S2: B002 OK FETCH Completed 406 409 C2: B002 FETCH 4:7 ENVELOPE 410 S2: B002 NO Messages 4:7 have been expunged. 412 4.1.4 To avoid the situation altogether, the server MAY fail the 413 EXPUNGE of a multi-accessed mailbox 415 In some cases, this behavior may not be practical. For example, if a 416 large number of clients are accessing a shared mailbox, the window in 417 which no clients have the mailbox accessed may be small or non- 418 existent, effectively rendering the message unexpungeable. 420 4.2. Storing of expunged messages 422 Following are some strategies an IMAP server may choose to use when 423 dealing with a STORE command on expunged messages. 425 4.2.1 If the ".SILENT" suffix is used, and the STORE completed 426 successfully for all the non-expunged messages, the server SHOULD 427 return a tagged OK. 429 Example: (Building upon the scenario outlined in 4.1.) 431 435 C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) 436 S2: B001 OK 438 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 440 4.2.2. If the ".SILENT" suffix is not used, and only expunged messages 441 are referenced, the server SHOULD return only a tagged NO. 443 Example: (Building upon the scenario outlined in 4.1.) 445 447 C2: B001 STORE 5:7 +FLAGS (\SEEN) 448 S2: B001 NO Messages have been expunged 450 4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged 451 and non-expunged messages are referenced, the server MAY set the 452 flags and return a FETCH response for the non-expunged messages 453 along with a tagged NO. 455 After receiving a tagged NO STORE response, the client SHOULD issue a 456 NOOP command so that it will be informed of any pending EXPUNGE 457 responses. The client may then either reissue the failed STORE 458 command, or by examining the EXPUNGE responses from the NOOP and 459 FETCH responses from the STORE, determine that the STORE failed 460 because of pending expunges. 462 Example: (Building upon the scenario outlined in 4.1.) 464 467 C2: B001 STORE 1:7 +FLAGS (\SEEN) 468 S2: * 1 FETCH (FLAGS (\SEEN)) 469 S2: * 2 FETCH (FLAGS (\SEEN)) 470 S2: * 3 FETCH (FLAGS (\SEEN)) 471 S2: B001 NO Some of the messages no longer exist. 473 C2: B002 NOOP 474 S2: * 4 EXPUNGE 475 S2: * 4 EXPUNGE 476 S2: * 4 EXPUNGE 477 S2: * 4 EXPUNGE 478 S2: * 3 EXISTS 479 S2: B002 OK NOOP Completed. 481 485 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 487 4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged 488 and non-expunged messages are referenced, the server MAY return 489 an untagged NO and not set any flags. 491 After receiving a tagged NO STORE response, the client SHOULD issue a 492 NOOP command so that it will be informed of any pending EXPUNGE 493 responses. The client would then re-issue the STORE command after 494 updating its message list per any EXPUNGE response. 496 If a large number of clients are accessing a shared mailbox, the 497 window in which there are no pending expunges may be small or non- 498 existent, effectively disallowing a client from setting the flags on 499 all messages at once. 501 Example: (Building upon the scenario outlined in 4.1.) 503 506 C2: B001 STORE 1:7 +FLAGS (\SEEN) 507 S2: B001 NO Some of the messages no longer exist. 509 511 C2: B002 NOOP 512 S2: * 4 EXPUNGE 513 S2: * 4 EXPUNGE 514 S2: * 4 EXPUNGE 515 S2: * 4 EXPUNGE 516 S2: * 3 EXISTS 517 S2: B002 OK NOOP Completed. 519 522 C2: B003 STORE 1:3 +FLAGS (\SEEN) 523 S2: * 1 FETCH (FLAGS (\SEEN)) 524 S2: * 2 FETCH (FLAGS (\SEEN)) 525 S2: * 3 FETCH (FLAGS (\SEEN)) 526 S2: B003 OK STORE Completed 528 4.3. Searching of expunged messages 530 A server MAY simply not return a search response for messages that 531 have been expunged and it has not been able to inform the client 532 about. If a client was expecting a particular message to be returned 533 in a search result, and it was not, the client SHOULD issue a NOOP 535 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 537 command to see if the message was expunged by another client. 539 4.4 Copying of expunged messages 541 COPY is the only IMAP4 sequence number command that is safe to allow 542 an EXPUNGE response on. This is because a client is not permitted to 543 cascade several COPY commands together. A client is required to wait 544 and confirm that the copy worked before issuing another one. 546 4.4.1 The server MAY disallow the COPY of messages in a multi-access 547 mailbox that contains expunged messages. 549 Pending EXPUNGE response(s) MUST be returned to the COPY command. 551 Example: 553 C: A001 COPY 2,4,6,8 FRED 554 S: * 4 EXPUNGE 555 S: A001 NO COPY rejected, because some of the requested 556 messages were expunged 558 Note: Non of the above messages are copied because if a COPY command 559 is unsuccessful, the server MUST restore the destination mailbox to 560 its state before the COPY attempt. 562 4.4.2 The server MAY allow the COPY of messages in a multi-access 563 mailbox that contains expunged messages. 565 Pending EXPUNGE response(s) MUST be returned to the COPY command. 566 Messages that are copied are messages corresponding to sequence 567 numbers before any EXPUNGE response. 569 Example: 571 C: A001 COPY 2,4,6,8 FRED 572 S: * 3 EXPUNGE 573 S: A001 OK COPY completed 575 In the above example, the messages that are copied to FRED are 576 messages 2,4,6,8 at the start of the COPY command. These are 577 equivalent to messages 2,3,5,7 at the end of the COPY command. The 578 EXPUNGE response can't take place until after the messages from the 579 COPY command are identified (because of the "no expunge while no 580 commands in progress" rule). 582 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 584 Example: 586 C: A001 COPY 2,4,6,8 FRED 587 S: * 4 EXPUNGE 588 S: A001 OK COPY completed 590 In the above example, message 4 was copied before it was expunged, 591 and MUST appear in the destination mailbox FRED. 593 5. Security Considerations 595 This document describes behavior of servers that use the IMAP4 596 protocol, and as such, has the same security considerations as 597 described in [IMAP4]. 599 In particular, some described server behavior does not allow for the 600 immediate deletion of information when a mailbox is accessed by 601 multiple clients. This may be a consideration when dealing with 602 sensitive information where immediate deletion would be preferred. 604 6. References 606 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 607 4rev1", RFC 3501, University of Washington, March 2003. 609 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", RFC 2119, Harvard University, March 1997. 612 [REFERRAL] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, 613 Microsoft, September 1997 615 7. Acknowledgments 617 This document is the result of discussions on the IMAP4 mailing list 618 and is meant to reflect consensus of this group. In particular, 619 Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, 620 Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry 621 Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De 622 Winter were active participants in this discussion or made 623 suggestions to this document. 625 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 627 8. Author's and Editor's Addresses 629 Author: Mike Gahrns 630 Microsoft 631 One Microsoft Way 632 Redmond, WA, 98072 634 Phone: (206) 936-9833 635 EMail: mikega@microsoft.com 637 Editor: Alexey Melnikov 638 Isode Limited 639 5 Castle Business Village, 640 36 Station Road, 641 Hampton, Middlesex, 642 United Kingdom, TW12 2BX 644 Phone: +44 77 53759732 645 Email: alexey.melnikov@isode.com 647 10. Full Copyright Statement 649 Copyright (C) The Internet Society (2004). This document is subject 650 to the rights, licenses and restrictions contained in BCP 78, and 651 except as set forth therein, the authors retain all their rights. 653 This document and translations of it may be copied and furnished to 654 others, and derivative works that comment on or otherwise explain it 655 or assist in its implementation may be prepared, copied, published 656 and distributed, in whole or in part, without restriction of any 657 kind, provided that the above copyright notice and this paragraph are 658 included on all such copies and derivative works. However, this 659 document itself may not be modified in any way, such as by removing 660 the copyright notice or references to the Internet Society or other 661 Internet organizations, except as needed for the purpose of 662 developing Internet standards in which case the procedures for 663 copyrights defined in the Internet Standards process must be 664 followed, or as required to translate it into languages other than 665 English. 667 The limited permissions granted above are perpetual and will not be 668 revoked by the Internet Society or its successors or assigns. 670 This document and the information contained herein are provided on an 671 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 RFC 2180bis IMAP4 Multi-Accessed Mailbox Practice October 2004 675 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 676 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 677 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 678 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 679 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 681 Acknowledgement 683 Funding for the RFC Editor function is currently provided by the 684 Internet Society. 686 11. Intellectual Property 688 The IETF takes no position regarding the validity or scope of any 689 Intellectual Property Rights or other rights that might be claimed to 690 pertain to the implementation or use of the technology described in 691 this document or the extent to which any license under such rights 692 might or might not be available; nor does it represent that it has 693 made any independent effort to identify any such rights. Information 694 on the procedures with respect to rights in RFC documents can be 695 found in BCP 78 and BCP 79. 697 Copies of IPR disclosures made to the IETF Secretariat and any 698 assurances of licenses to be made available, or the result of an 699 attempt made to obtain a general license or permission for the use of 700 such proprietary rights by implementers or users of this 701 specification can be obtained from the IETF on-line IPR repository at 702 http://www.ietf.org/ipr. 704 The IETF invites any interested party to bring to its attention any 705 copyrights, patents or patent applications, or other proprietary 706 rights that may cover technology that may be required to implement 707 this standard. Please address the information to the IETF at ietf- 708 ipr@ietf.org. 710 Appendix A. Change History 712 Changes from RFC 2180. 713 1. Updated boilerplate and references. 714 2. Fixed wrong formatting in section 3.4. 715 3. Fixed syntax of several FETCH responses. 716 4. Replaced obsoleted NEWNAME response code with REFERRAL. 718 Appendix B. ToDo 720 1. List preferred choices 721 2. Abstract must not be numbered