idnits 2.17.1 draft-gahrns-imap-practice-01.txt: ** The Abstract section seems to be numbered -(595): 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 1 longer page, the longest (page 1) being 699 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 81: '...SHOULD and MAY are terms that are defined in accordance with [RFC-2060]....' RFC 2119 keyword, line 91: '...3.1. The server MAY fail the DELETE/RE...' RFC 2119 keyword, line 111: '...3.2. The server MAY allow the DELETE c...' RFC 2119 keyword, line 175: '...3.3. The server MAY allow the DELETE/R...' RFC 2119 keyword, line 194: '...3.4. The server MAY allow the RENAME o...' (23 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 (April 1997) is 9873 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 62, but not defined ** Obsolete undefined reference: RFC 2060 (Obsoleted by RFC 3501) == Missing Reference: 'NEWNAME' is mentioned on line 201, 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-01.txt April 1997 6 IMAP4 Multi-Accessed Mailbox 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 October 1997. Distribution of this draft 30 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 Gahrns 1 55 IMAP4 Multi-Accessed Mailbox Practice April 1997 57 The behavior described in this document reflects the practice of 58 some existing servers or behavior that the consensus of the IMAP 59 mailing list has deemed to be reasonable. The behavior described 60 within this document is believed to be [RFC2060] compliant. However, 61 this document is not meant to define IMAP4 compliance, nor is it and 62 exhaustive list of valid IMAP4 behavior. [RFC2060] must always be 63 consulted to determine IMAP4 compliance, especially for server 64 behavior not described within this document. 66 2. Conventions used in this document 68 In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 69 different clients (client #1, client #2 and client #3) that are 70 connected to a server. "S1:", "S2:" and "S3:" indicated lines sent 71 by the server to client #1, client #2 and client #3 respectively. 73 A shared mailbox, is a mailbox that can be used by multiple users. 75 A multi-accessed mailbox, is a mailbox that has multiple clients 76 simultaneously accessing it. 78 A client is said to have accessed a mailbox after a successful 79 SELECT or EXAMINE command. 81 SHOULD and MAY are terms that are defined in accordance with [RFC- 82 2060]. 84 3. Deletion/Renaming of a multi-accessed mailbox 86 If an external agent or multiple clients are accessing a mailbox, 87 care must be taken when handling the deletion or renaming of the 88 mailbox. Following are some strategies an IMAP server may choose to 89 use when dealing with this. 91 3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed 92 mailbox 94 In some cases, this behavior may not be practical. For example, if 95 a large number of clients are accessing a shared mailbox, the window 96 in which no clients have the mailbox accessed may be small or non- 97 existent, effectively rendering the mailbox undeletable or 98 unrenamable. 100 Example: 102 105 C1: A001 DELETE FOO 106 S1: A001 NO Mailbox FOO is in use by another user. 108 Gahrns 2 109 IMAP4 Multi-Accessed Mailbox Practice April 1997 111 3.2. The server MAY allow the DELETE command of a multi-accessed 112 mailbox, but keep the information in the mailbox available for 113 those clients that currently have access to the mailbox. 115 When all clients have finished accessing the mailbox, it is 116 permanently removed. For clients that do not already have access to 117 the mailbox, the 'ghosted' mailbox would not be available. For 118 example, it would not be returned to these clients in a subsequent 119 LIST or LSUB command and would not be a valid mailbox argument to 120 any other IMAP command until the reference count of clients 121 accessing the mailbox reached 0. 123 In some cases, this behavior may not be desirable. For example if 124 someone created a mailbox with offensive or sensitive information, 125 one might prefer to have the mailbox deleted and all access to the 126 information contained within removed immediately, rather than 127 continuing to allow access until the client closes the mailbox. 129 Furthermore, this behavior, may prevent 'recycling' of the same 130 mailbox name until all clients have finished accessing the original 131 mailbox. 133 Example: 135 138 C1: A001 DELETE FOO 139 S1: A001 OK Mailbox FOO is deleted. 141 143 C2: B001 STATUS FOO (MESSAGES) 144 S2: * STATUS FOO (MESSAGES 6) 145 S2: B001 OK STATUS completed 147 150 C3: C001 STATUS FOO (MESSAGES) 151 S3: C001 NO Mailbox does not exist 153 156 C3: C002 CREATE FOO 157 S3: C002 NO Mailbox FOO is still in use. Try again later. 159 162 C2: B002 CLOSE 164 Gahrns 3 165 IMAP4 Multi-Accessed Mailbox Practice April 1997 167 S2: B002 OK CLOSE Completed 169 172 C3: C003 CREATE FOO 173 S3: C003 OK CREATE Completed 175 3.3. The server MAY allow the DELETE/RENAME of a multi-accessed 176 mailbox, but disconnect all other clients who have the mailbox 177 accessed by sending a untagged BYE response. 179 A server may often choose to disconnect clients in the DELETE case, 180 but may choose to implement a "friendlier" method for the RENAME 181 case. 183 Example: 185 188 C1: A002 DELETE FOO 189 S1: A002 OK DELETE completed. 191 192 S2: * BYE Mailbox FOO has been deleted. 194 3.4. The server MAY allow the RENAME of a multi-accessed mailbox by 195 simply changing the name attribute on the mailbox. 197 Other clients that have access to the mailbox can continue issuing 198 commands such as FETCH that do not reference the mailbox name. 199 Clients would discover the renaming the next time they referred to 200 the old mailbox name. Some servers MAY choose to include the 201 [NEWNAME] response code in their tagged NO response to a command 202 that contained the old mailbox name, as a hint to the client that 203 the operation can succeed if the command is issued with the new 204 mailbox name. 206 Example: 208 211 C1: A001 RENAME FOO BAR 212 S1: A001 OK RENAME completed. 214 217 Gahrns 4 218 IMAP4 Multi-Accessed Mailbox Practice April 1997 220 C2: B001 FETCH 2:4 (FLAGS) 221 S2: * 2 FETCH . . . 222 S2: * 3 FETCH . . . 223 S2: * 4 FETCH . . . 224 S2: B001 OK FETCH completed 226 229 C2: B002 STATUS FOO (MESSAGES) 230 S2: B002 NO [NEWNAME FOO BAR] Mailbox has been renamed 232 4. Expunging of messages on a multi-accessed mailbox 234 If an external agent or multiple clients are accessing a mailbox, 235 care must be taken when handling the EXPUNGE of messages. Other 236 clients accessing the mailbox may be in the midst of issuing a 237 command that depends upon message sequence numbers. Because an 238 EXPUNGE response can not be sent while responding to a FETCH, STORE 239 or SEARCH command, it is not possible to immediately notify the 240 client of the EXPUNGE. This can result in ambiguity if the client 241 issues a FETCH, STORE or SEARCH operation on a message that has been 242 EXPUNGED. 244 4.1. Fetching of expunged messages 246 Following are some strategies an IMAP server may choose to use when 247 dealing with a FETCH command on expunged messages. 249 Consider the following scenario: 251 - Client #1 and Client #2 have mailbox FOO selected. 252 - There are 7 messages in the mailbox. 253 - Messages 4:7 are marked for deletion. 254 - Client #1 issues an EXPUNGE, to expunge messages 4:7 256 4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but 257 keep the messages available to satisfy subsequent FETCH commands 258 until it is able to send an EXPUNGE response to each client. 260 In some cases, the behavior of keeping "ghosted" messages may not be 261 desirable. For example if a message contained offensive or 262 sensitive information, one might prefer to instantaneously remove 263 all access to the information, regardless of whether another client 264 is in the midst of accessing it. 266 Example: (Building upon the scenario outlined in 4.1.) 268 Gahrns 5 269 IMAP4 Multi-Accessed Mailbox Practice April 1997 271 275 C2: B001 FETCH 4:7 RFC822 276 S2: * 4 FETCH RFC822 . . . (RFC822 info returned) 277 S2: * 5 FETCH RFC822 . . . (RFC822 info returned) 278 S2: * 6 FETCH RFC822 . . . (RFC822 info returned) 279 S2: * 7 FETCH RFC822 . . . (RFC822 info returned) 280 S2: B001 OK FETCH Completed 282 285 C2: B002 NOOP 286 S2: * 4 EXPUNGE 287 S2: * 4 EXPUNGE 288 S2: * 4 EXPUNGE 289 S2: * 4 EXPUNGE 290 S2: * 3 EXISTS 291 S2: B002 OK NOOP Complete 293 295 C2: B003 FETCH 4:7 RFC822 296 S2: B003 NO Messages 4:7 are no longer available. 298 4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, 299 and on subsequent FETCH commands return FETCH responses only for 300 non-expunged messages and a tagged NO. 302 After receiving a tagged NO FETCH response, the client SHOULD issue 303 a NOOP command so that it will be informed of any pending EXPUNGE 304 responses. The client may then either reissue the failed FETCH 305 command, or by examining the EXPUNGE response from the NOOP and the 306 FETCH response from the FETCH, determine that the FETCH failed 307 because of pending expunges. 309 Example: (Building upon the scenario outlined in 4.1.) 311 315 C2: B001 FETCH 3:5 ENVELOPE 316 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) 317 S2: B001 NO Some of the requested messages no longer exist 319 322 Gahrns 6 323 IMAP4 Multi-Accessed Mailbox Practice April 1997 325 C2: B002 NOOP 326 S2: * 4 EXPUNGE 327 S2: * 4 EXPUNGE 328 S2: * 4 EXPUNGE 329 S2: * 4 EXPUNGE 330 S2: * 3 EXISTS 331 S2: B002 OK NOOP Completed. 333 337 4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and 338 on subsequent FETCH commands return the usual FETCH responses for 339 non-expunged messages, "NIL FETCH Responses" for expunged 340 messages, and a tagged OK response. 342 If all of the messages in the subsequent FETCH command have been 343 expunged, the server SHOULD return only a tagged NO. In this case, 344 the client SHOULD issue a NOOP command so that it will be informed 345 of any pending EXPUNGE responses. The client may then either 346 reissue the failed FETCH command, or by examining the EXPUNGE 347 response from the NOOP, determine that the FETCH failed because of 348 pending expunges. 350 "NIL FETCH responses" are a representation of empty data as 351 appropriate for the FETCH argument specified. 353 Example: 355 * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) 356 * 1 FETCH (FLAGS ()) 357 * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") 358 * 1 FETCH (RFC822 "") 359 * 1 FETCH (RFC822.HEADER "") 360 * 1 FETCH (RFC822.TEXT "") 361 * 1 FETCH (RFC822.SIZE 0) 362 * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) 363 * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) 364 * 1 FETCH (BODY[
] "") 365 * 1 FETCH (BODY[
] "") 367 In some cases, a client may not be able to distinguish between "NIL 368 FETCH responses" received because a message was expunged and those 369 received because the data actually was NIL. For example, a * 5 370 FETCH (FLAGS ()) response could be received if no flags were set on 371 message 5, or because message 5 was expunged. In a case of potential 372 ambiguity, the client SHOULD issue a command such as NOOP to force 373 the sending of the EXPUNGE responses to resolve any ambiguity. 375 Gahrns 7 376 IMAP4 Multi-Accessed Mailbox Practice April 1997 378 Example: (Building upon the scenario outlined in 4.1.) 380 384 C2: B002 FETCH 3:5 ENVELOPE 385 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) 386 S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL 387 NIL NIL) 388 S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL 389 NIL NIL) 390 S2: B002 OK FETCH Completed 392 395 C2: B002 FETCH 4:7 ENVELOPE 396 S2: B002 NO Messages 4:7 have been expunged. 398 4.1.4 To avoid the situation altogether, the server MAY fail the 399 EXPUNGE of a multi-accessed mailbox 401 In some cases, this behavior may not be practical. For example, if 402 a large number of clients are accessing a shared mailbox, the window 403 in which no clients have the mailbox accessed may be small or non- 404 existent, effectively rendering the message unexpungeable. 406 4.2. Storing of expunged messages 408 Following are some strategies an IMAP server may choose to use when 409 dealing with a STORE command on expunged messages. 411 4.2.1 If the ".SILENT" suffix is used, and the STORE completed 412 successfully for all the non-expunged messages, the server SHOULD 413 return a tagged OK. 415 Example: (Building upon the scenario outlined in 4.1.) 417 421 C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) 422 S2: B001 OK 424 4.2.2. If the ".SILENT" suffix is not used, and only expunged messages 425 are referenced, the server SHOULD return only a tagged NO. 427 Gahrns 8 428 IMAP4 Multi-Accessed Mailbox Practice April 1997 430 Example: (Building upon the scenario outlined in 4.1.) 432 434 C2: B001 STORE 5:7 +FLAGS (\SEEN) 435 S2: B001 NO Messages have been expunged 437 4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged 438 and non-expunged messages are referenced, the server MAY set the 439 flags and return a FETCH response for the non-expunged messages 440 along with a tagged NO. 442 After receiving a tagged NO STORE response, the client SHOULD issue 443 a NOOP command so that it will be informed of any pending EXPUNGE 444 responses. The client may then either reissue the failed STORE 445 command, or by examining the EXPUNGE responses from the NOOP and 446 FETCH responses from the STORE, determine that the STORE failed 447 because of pending expunges. 449 Example: (Building upon the scenario outlined in 4.1.) 451 454 C2: B001 STORE 1:7 +FLAGS (\SEEN) 455 S2: * FETCH 1 FLAGS (\SEEN) 456 S2: * FETCH 2 FLAGS (\SEEN) 457 S2: * FETCH 3 FLAGS (\SEEN) 458 S2: B001 NO Some of the messages no longer exist. 460 C2: B002 NOOP 461 S2: * 4 EXPUNGE 462 S2: * 4 EXPUNGE 463 S2: * 4 EXPUNGE 464 S2: * 4 EXPUNGE 465 S2: * 3 EXISTS 466 S2: B002 OK NOOP Completed. 468 472 4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged 473 and non-expunged messages are referenced, the server MAY return 474 only an untagged NO and not set any flags, nor return any FETCH 475 responses 477 After receiving a tagged NO STORE response, the client SHOULD issue 478 a NOOP command so that it will be informed of any pending EXPUNGE 480 Gahrns 9 481 IMAP4 Multi-Accessed Mailbox Practice April 1997 483 responses. The client would then re-issue the STORE command after 484 updating its message list per any EXPUNGE response. 486 If a large number of clients are accessing a shared mailbox, the 487 window in which there are no pending expunges may be small or non- 488 existent, effectively disallowing a client from setting the flags on 489 all messages at once. 491 Example: (Building upon the scenario outlined in 4.1.) 493 496 C2: B001 STORE 1:7 +FLAGS (\SEEN) 497 S2: B001 NO Some of the messages no longer exist. 499 501 C2: B002 NOOP 502 S2: * 4 EXPUNGE 503 S2: * 4 EXPUNGE 504 S2: * 4 EXPUNGE 505 S2: * 4 EXPUNGE 506 S2: * 3 EXISTS 507 S2: B002 OK NOOP Completed. 509 512 C2: B003 STORE 1:3 +FLAGS (\SEEN) 513 S2: * FETCH 1 FLAGS (\SEEN) 514 S2: * FETCH 2 FLAGS (\SEEN) 515 S2: * FETCH 3 FLAGS (\SEEN) 516 S2: B003 OK STORE Completed 518 4.3. Searching of expunged messages 520 A server MAY simply not return a search response for messages that 521 have been expunged and it has not been able to inform the client 522 about. If a client was expecting a particular message to be 523 returned in a search result, and it was not, the client SHOULD issue 524 a NOOP command to see if the message was expunged by another client. 526 4.4 Copying of expunged messages 528 COPY is the only IMAP4 sequence number command that is safe to allow 529 an EXPUNGE response on. This is because a client is not permitted 530 to cascade several COPY commands together. A client is required to 531 wait and confirm that the copy worked before issuing another one. 533 Gahrns 10 534 IMAP4 Multi-Accessed Mailbox Practice April 1997 536 4.4.1 The server MAY disallow the COPY of messages in a multi-access 537 mailbox that contains expunged messages. 539 Pending EXPUNGE response(s) MUST be returned to the COPY command. 541 Example: 542 C: A001 COPY 2,4,6,8 FRED 543 S: * 4 EXPUNGE 544 S: A001 NO COPY rejected, because some of the requested 545 messages were expunged 547 Note: Non of the above messages are copied because if a COPY command 548 is unsuccessful, the server MUST restore the destination mailbox to 549 its state before the COPY attempt. 551 4.4.2 The server MAY allow the COPY of messages in a multi-access 552 mailbox that contains expunged messages. 554 Pending EXPUNGE response(s) MUST be returned to the COPY command. 555 Messages that are copied are messages corresponding to sequence 556 numbers before any EXPUNGE response. 558 Example: 559 C: A001 COPY 2,4,6,8 FRED 560 S: * 3 EXPUNGE 561 S: A001 OK COPY completed 563 In the above example, the messages that are copied to FRED are 564 messages 2,4,6,8 at the start of the COPY command. These are 565 equivalent to messages 2,3,5,7 at the end of the COPY command. The 566 EXPUNGE response can't take place until after the messages from the 567 COPY command are identified (because of the "no expunge while no 568 commands in progress" rule. 570 Example: 571 C: A001 COPY 2,4,6,8 FRED 572 S: * 4 EXPUNGE 573 S: A001 OK COPY completed 575 In the above example, message 4 was copied before it was expunged, 576 and MUST appear in the destination mailbox FRED. 578 5. Security Considerations 580 This document describes behavior of servers that use the IMAP4 581 protocol, and as such, has the same security considerations as 582 described in [RFC-2060]. 584 In particular, some described server behavior does not allow for the 585 immediate deletion of information when a mailbox is accessed by 587 Gahrns 11 588 IMAP4 Multi-Accessed Mailbox Practice April 1997 590 multiple clients. This may be a consideration when dealing with 591 sensitive information where immediate deletion would be preferred. 593 6. References 595 [RFC-2060], Crispin, M., "Internet Message Access Protocol � Version 596 4rev1", RFC 2060, University of Washington, December 1996. 598 7. Acknowledgments 600 This document is the result of discussions on the IMAP4 mailing list 601 and is meant to reflect consensus of this group. In particular, 602 Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, 603 Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry 604 Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De 605 Winter were active participants in this discussion or made 606 suggestions to this document. 608 8. Author's Address 610 Mike Gahrns 611 Microsoft 612 One Microsoft Way 613 Redmond, WA, 98072 615 Phone: (206) 936-9833 616 Email: 617 mikega@microsoft.co 619 m 621 Gahrns 12