idnits 2.17.1 draft-gahrns-imap-practice-00.txt: ** The Abstract section seems to be numbered -(508): 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-18) 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 1 longer page, the longest (page 11) being 60 lines 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. ** The abstract seems to contain references ([RFC2060]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 78: '...SHOULD and MAY are terms that are defined in accordance with [RFC-2060]....' RFC 2119 keyword, line 88: '...3.1. The server MAY fail the DELETE/RE...' RFC 2119 keyword, line 105: '...3.2. The server MAY allow the DELETE c...' RFC 2119 keyword, line 163: '...3.3. The server MAY allow the DELETE/R...' RFC 2119 keyword, line 182: '...3.4. The server MAY allow the RENAME o...' (18 more instances...) 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 (March 1997) is 9896 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) == Missing Reference: 'RFC2060' is mentioned on line 59, but not defined ** Obsolete undefined reference: RFC 2060 (Obsoleted by RFC 3501) == Missing Reference: 'NEWNAME' is mentioned on line 189, but not defined ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gahrns 3 Internet Draft Microsoft 4 Document: draft-gahrns-imap-practice-00.txt March 1997 6 IMAP4 Implementation Practice 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 September 1997. Distribution of this 30 draft is unlimited. 32 1. Abstract 34 IMAP4[rfc2060] is rich client/server protocol that allows a client 35 to access and manipulate electronic mail messages on a server. 36 Within the protocol framework, it is possible to have differing 37 results for particular client/server interactions. If a protocol 38 does not allow for this, it is often unduly restrictive. 40 For example, when multiple clients are accessing a mailbox and one 41 attempts to delete the mailbox, an IMAP4 server may choose to 42 implement a solution based upon server architectural constraints or 43 individual preference. 45 With this flexibility comes greater client responsibility. It is 46 not sufficient for a client to be written based upon the behavior of 47 a particular IMAP server. Rather the client must be based upon the 48 behavior allowed by the protocol. 50 By documenting common IMAP4 server practice for the case of 51 simultaneous client access to a mailbox, we hope to ensure the 52 widest amount of inter-operation between IMAP4 clients and servers. 54 The behavior described in this document reflects the practice of 55 some existing servers or behavior that the consensus of the IMAP 56 mailing list has deemed to be reasonable. The behavior described 57 within this document is believed to be [RFC2060] compliant. However, 58 this document is not meant to define IMAP4 compliance, nor is it and 59 exhaustive list of valid IMAP4 behavior. [RFC2060] must always be 60 consulted to determine IMAP4 compliance, especially for server 61 behavior not described within this document. 63 2. Conventions used in this document 65 In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 66 different clients (client #1, client #2 and client #3) that are 67 connected to a server. "S1:", "S2:" and "S3:" indicated lines sent 68 by the server to client #1, client #2 and client #3 respectively. 70 A shared mailbox, is a mailbox that can be used by multiple users. 72 A multi-accessed mailbox, is a mailbox that has multiple clients 73 simultaneously accessing it. 75 A client is said have accessed a mailbox after a successful SELECT 76 or EXAMINE command. 78 SHOULD and MAY are terms that are defined in accordance with [RFC- 79 2060]. 81 3. Deletion/Renaming of a multi-accessed mailbox 83 When multiple clients are accessing a mailbox, care must be taken 84 when handling the deletion or renaming of the mailbox by one of the 85 clients. Following are some strategies an IMAP server may choose to 86 use when dealing with this. 88 3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed 89 mailbox 91 In some cases, this behavior may not be practical. For example, if 92 a large number of clients are accessing a shared mailbox, the window 93 in which no clients have the mailbox accessed may be small or non- 94 existent, effectively rendering the mailbox undeletable or 95 unrenamable. 97 Example: 99 102 C1: A001 DELETE FOO 103 S1: A001 NO Mailbox FOO is in use by another user. 105 3.2. The server MAY allow the DELETE command of a multi-accessed 106 mailbox, but keep the information in the mailbox available for 107 those clients that currently have access to the mailbox. 109 When all clients have finished accessing the mailbox, it is 110 permanently removed. For clients that do not already have access to 111 the mailbox, the 'ghosted' mailbox would not be available. For 112 example, it would not be returned to these clients in a subsequent 113 LIST or LSUB command and would not be a valid mailbox argument to 114 any other IMAP command until the reference count of clients 115 accessing the mailbox reached 0. 117 In some cases, this behavior may not be desirable. For example if 118 someone created a mailbox with offensive or sensitive information, 119 one might prefer to have the mailbox deleted and all access to the 120 information contained within removed immediately, rather than 121 continuing to allow access until the client closes the mailbox. 123 Furthermore, this behavior, prevents 'recycling' of the same mailbox 124 name until all clients have finished accessing the original mailbox. 126 Example: 128 131 C1: A001 DELETE FOO 132 S1: A001 OK Mailbox FOO is deleted. 134 136 C2: B001 STATUS FOO (MESSAGES) 137 S2: * STATUS FOO (MESSAGES 6) 138 S2: B001 OK STATUS completed 140 143 C3: C001 STATUS FOO (MESSAGES) 144 S3: C001 NO Mailbox does not exist 146 149 C3: C002 CREATE FOO 150 S3: C002 NO Mailbox FOO is still in use. Try again later. 152 155 C2: B002 CLOSE 156 S2: B002 OK CLOSE Completed 157 160 C3: C003 CREATE FOO 161 S3: C003 OK CREATE Completed 163 3.3. The server MAY allow the DELETE/RENAME of a multi-accessed 164 mailbox, but disconnect all other clients who have the mailbox 165 accessed by sending a untagged BYE response. 167 A server may often choose to disconnect clients in the DELETE case, 168 but may choose to implement a "friendlier" method for the RENAME 169 case. 171 Example: 173 176 C1: A002 DELETE FOO 177 S1: A002 OK DELETE completed. 179 180 S2: * BYE Mailbox FOO has been deleted. 182 3.4. The server MAY allow the RENAME of a multi-accessed mailbox by 183 simply changing the name attribute on the mailbox. 185 Other clients that have access to the mailbox can continue issuing 186 commands such as FETCH that do not reference the mailbox name. 187 Clients would discover the renaming the next time they referred to 188 the old mailbox name. Some servers MAY choose to include the 189 [NEWNAME] response code in their tagged NO response to a command 190 that contained the old mailbox name, as a hint to the client that 191 the operation can succeed if the command is issued with the new 192 mailbox name. 194 Example: 196 199 C1: A001 RENAME FOO BAR 200 S1: A001 OK RENAME completed. 202 205 C2: B001 FETCH 2:4 (FLAGS) 206 S2: * 2 FETCH . . . 207 S2: * 3 FETCH . . . 208 S2: * 4 FETCH . . . 209 S2: B001 OK FETCH completed 211 214 C2: B002 STATUS FOO (MESSAGES) 215 S2: B002 NO [NEWNAME FOO BAR] Mailbox has been renamed 217 4. Expunging of messages on a multi-accessed mailbox 219 When multiple clients are accessing a mailbox, care must be taken 220 when handling the EXPUNGE of messages. Other clients accessing the 221 mailbox may be in the midst of issuing a command that depends upon 222 message sequence numbers. Because an EXPUNGE response can not be 223 sent while responding to a FETCH, STORE or SEARCH command, it is not 224 possible to immediately notify the client of the EXPUNGE. This can 225 result in ambiguity if the client issues a FETCH, STORE or SEARCH 226 operation on a message that has been EXPUNGED. 228 4.1. Fetching of EXPUNGED messages 230 Following are some strategies an IMAP server may choose to use when 231 dealing with a FETCH command on expunged messages. 233 Consider the following scenario: 235 - Client #1 and Client #2 have mailbox FOO selected. 236 - There are 7 messages in the mailbox. 237 - Messages 4:7 are marked for deletion. 238 - Client #1 issues an EXPUNGE, to expunge messages 4:7 240 4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but 241 keep the messages available to satisfy subsequent FETCH commands 242 until it is able to send an EXPUNGE response to each client. 244 In some cases, the behavior of keeping "ghosted" messages may not be 245 desirable. For example if a message contained offensive or 246 sensitive information, one might prefer to instantaneously remove 247 all access to the information, regardless of whether another client 248 is in the midst of accessing it. 250 Example: (Building upon the scenario outlined in 4.1.) 252 255 C2: B001 FETCH 4:7 RFC822 256 S2: * 4 FETCH RFC822 . . . (RFC822 info returned) 257 S2: * 5 FETCH RFC822 . . . (RFC822 info returned) 258 S2: * 6 FETCH RFC822 . . . (RFC822 info returned) 259 S2: * 7 FETCH RFC822 . . . (RFC822 info returned) 260 S2: B001 OK FETCH Completed 262 265 C2: B002 NOOP 266 S2: * 4 EXPUNGE 267 S2: * 4 EXPUNGE 268 S2: * 4 EXPUNGE 269 S2: * 4 EXPUNGE 270 S2: * 3 EXISTS 271 S2: B002 OK NOOP Complete 273 275 C2: B003 FETCH 4:7 RFC822 276 S2: B003 NO Messages 4:7 are no longer available. 278 4.1.2 The server MAY allow the EXPUNGE of a multi-access mailbox, 279 and on subsequent FETCH commands return a tagged NO, and FETCH 280 responses only for the non-expunged messages. 282 If all of the messages in the subsequent FETCH command have been 283 expunged, the server SHOULD return only a tagged NO. 285 After receiving a tagged NO FETCH response, the client SHOULD issue 286 a NOOP command so that it will be informed of any pending EXPUNGE 287 responses. The client may then either reissue the failed FETCH 288 command, or by examining the EXPUNGE response from the NOOP and the 289 FETCH response from the FETCH, determine that the FETCH failed 290 because of pending expunges. 292 Example: (Building upon the scenario outlined in 4.1.) 294 298 C2: B001 FETCH 3:5 ENVELOPE 299 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) 300 S2: B001 NO Some of the requested messages no longer exist 302 305 C2: B002 NOOP 306 S2: * EXPUNGE 4 307 S2: * EXPUNGE 4 308 S2: * EXPUNGE 4 309 S2: * EXPUNGE 4 310 S2: * 3 EXISTS 311 S2: B002 OK NOOP Completed. 313 317 4.1.3 The server MAY allow the EXPUNGE of a multi-access mailbox, and 318 on subsequent FETCH commands return a tagged OK, "NIL FETCH 319 Responses" for expunged messages, and FETCH responses for non 320 -expunged messages. 322 If all of the messages in the subsequent FETCH command have been 323 expunged, the server SHOULD return only a tagged NO. In this case, 324 the client SHOULD issue a NOOP command so that it will be informed 325 of any pending EXPUNGE responses. The client may then either 326 reissue the failed FETCH command, or by examining the EXPUNGE 327 response from the NOOP, determine that the FETCH failed because of 328 pending expunges. 330 "NIL FETCH responses" are a representation of empty data as 331 appropriate for the FETCH argument specified. 333 Example: 335 * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) 336 * 1 FETCH (FLAGS ()) 337 * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") 338 * 1 FETCH (RFC822 "") 339 * 1 FETCH (RFC822.HEADER "") 340 * 1 FETCH (RFC822.TEXT "") 341 * 1 FETCH (RFC822.SIZE 0) 342 * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) 343 * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) 344 * 1 FETCH (BODY[
] "") 345 * 1 FETCH (BODY[
] "") 347 In some cases, a client may not be able to distinguish between "NIL 348 FETCH responses" received because a message was expunged and those 349 received because the data actually was NIL. For example, a * 5 350 FETCH (FLAGS ()) response could be received if no flags were set on 351 message 5, or because message 5 was expunged. In a case of potential 352 ambiguity, the client SHOULD issue a command such as NOOP to force 353 the sending of the EXPUNGE responses to resolve any ambiguity. 355 Example: (Building upon the scenario outlined in 4.1.) 357 361 C2: B002 FETCH 3:5 ENVELOPE 362 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) 363 S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL 364 NIL NIL) 365 S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL 366 NIL NIL) 367 S2: B002 OK FETCH Completed 369 372 C2: B002 FETCH 4:7 ENVELOPE 373 S2: B002 NO Messages 4:7 have been expunged. 375 4.1.4 To avoid the situation altogether, the server MAY fail the 376 EXPUNGE of a multi-accessed mailbox 378 In some cases, this behavior may not be practical. For example, if 379 a large number of clients are accessing a shared mailbox, the window 380 in which no clients have the mailbox accessed may be small or non- 381 existent, effectively rendering the message unexpungeable. 383 4.2. Storing of expunged messages 385 Following are some strategies an IMAP server may choose to use when 386 dealing with a STORE command on expunged messages. 388 4.2.1 If the ".SILENT" suffix is used, and the STORE completed 389 successfully for all the non-expunged messages, the server SHOULD 390 return a tagged OK. 392 Example: (Building upon the scenario outlined in 4.1.) 394 398 C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) 399 S2: B001 OK 401 4.2.2. If the ".SILENT" suffix is not used, and only expunged messages 402 are referenced, the server SHOULD return only a tagged NO. 404 Example: (Building upon the scenario outlined in 4.1.) 405 407 C2: B001 STORE 5:7 +FLAGS (\SEEN) 408 S2: B001 NO Messages have been expunged 410 4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged 411 and non-expunged messages are referenced, the server MAY set the 412 flags and return a FETCH response for the non-expunged messages 413 along with a tagged NO. 415 After receiving a tagged NO STORE response, the client SHOULD issue 416 a NOOP command so that it will be informed of any pending EXPUNGE 417 responses. The client may then either reissue the failed STORE 418 command, or by examining the EXPUNGE responses from the NOOP and 419 FETCH responses from the STORE, determine that the STORE failed 420 because of pending expunges. 422 Example: (Building upon the scenario outlined in 4.1.) 424 427 C2: B001 STORE 1:7 +FLAGS (\SEEN) 428 S2: * FETCH 1 FLAGS (\SEEN) 429 S2: * FETCH 2 FLAGS (\SEEN) 430 S2: * FETCH 3 FLAGS (\SEEN) 431 S2: B001 NO Some of the messages no longer exist. 433 C2: B002 NOOP 434 S2: * EXPUNGE 4 435 S2: * EXPUNGE 4 436 S2: * EXPUNGE 4 437 S2: * EXPUNGE 4 438 S2: * 3 EXISTS 439 S2: B002 OK NOOP Completed. 441 445 4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged 446 and non-expunged messages are referenced, the server MAY return 447 only an untagged NO and not set any flags, nor return any FETCH 448 responses 450 After receiving a tagged NO STORE response, the client SHOULD issue 451 a NOOP command so that it will be informed of any pending EXPUNGE 452 responses. The client would then re-issue the STORE command after 453 updating its message list per any EXPUNGE response. 455 If a large number of clients are accessing a shared mailbox, the 456 window in which there are no pending expunges may be small or non- 457 existent, effectively disallowing a client from setting the flags on 458 all messages at once. 460 Example: (Building upon the scenario outlined in 4.1.) 462 465 C2: B001 STORE 1:7 +FLAGS (\SEEN) 466 S2: B001 NO Some of the messages no longer exist. 468 470 C2: B002 NOOP 471 S2: * EXPUNGE 4 472 S2: * EXPUNGE 4 473 S2: * EXPUNGE 4 474 S2: * EXPUNGE 4 475 S2: * 3 EXISTS 476 S2: B002 OK NOOP Completed. 478 481 C2: B003 STORE 1:3 +FLAGS (\SEEN) 482 S2: * FETCH 1 FLAGS (\SEEN) 483 S2: * FETCH 2 FLAGS (\SEEN) 484 S2: * FETCH 3 FLAGS (\SEEN) 485 S2: B003 OK STORE Completed 487 4.2. Searching of EXPUNGED messages 489 A server MAY simply not return a search response for messages that 490 have been expunged and it has not been able to inform the client 491 about. If a client was expecting a particular message to be 492 returned in a search result, and it was not, the client SHOULD issue 493 a NOOP command to see if the message was expunged by another client. 495 5. Security Considerations 497 This document describes behavior of servers that use the IMAP4 498 protocol, and as such, has the same security considerations as 499 described in [RFC-2060]. 501 In particular, some described server behavior does not allow for the 502 immediate deletion of information when a mailbox is accessed by 503 multiple clients. This may be a consideration when dealing with 504 sensitive information where immediate deletion would be preferred. 506 6. References 508 [RFC-2060], Crispin, M., "Internet Message Access Protocol � Version 509 4rev1", RFC 2060, University of Washington, December 1996. 511 7. Acknowledgments 513 This document is the result of discussions on the IMAP4 mailing list 514 and is meant to reflect consensus of this group. In particular, 515 Raymond Cheng, Mark Crispin, Jack De Winter, Jim Evans, Steve Hole, 516 Mark Keasling, Barry Leiba, Pat Moran, Larry Osterman, Chris Newman, 517 and Vladimir Vulovic were significant participants in this 518 discussion or made suggestions to this document. 520 8. Author's Address 522 Mike Gahrns 523 Microsoft 524 One Microsoft Way 525 Redmond, WA, 98072 527 Phone: (206) 936-9833 528 Email: mikega@microsoft.co 530 m