[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2180) 00

Network Working Group                                          M. Gahrns
Obsoletes: 2180                                                Microsoft
Category: Informational                                      A. Melnikov
Expires: April 2005                                  Isode Ltd. (Editor)



                 IMAP4 Multi-Accessed Mailbox Practice
                 draft-melnikov-imap-rfc2180bis-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a revision of RFC 2180 by Mike Gahrns.  A revised
   version of this draft document will be submitted to the RFC editor as
   an Informational document. Discussion and suggestions for improvement
   are requested, and should be sent to the IMAP4 Mailing list
   (imap@CAC.Washington.EDU). To subscribe to the list, send email to
   <listproc@u.washington.edu> with the text "subscribe imap YourName"
   in the body of the message. Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

1. Abstract

   IMAP4[IMAP4] is rich client/server protocol that allows a client to
   access and manipulate electronic mail messages on a server.  Within



Gahrns                        Informational             FORMFEED[Page 1]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   the protocol framework, it is possible to have differing results for
   particular client/server interactions. If a protocol does not allow
   for this, it is often unduly restrictive.

   For example, when multiple clients are accessing a mailbox and one
   attempts to delete the mailbox, an IMAP4 server may choose to
   implement a solution based upon server architectural constraints or
   individual preference.

   With this flexibility comes greater client responsibility.  It is not
   sufficient for a client to be written based upon the behavior of a
   particular IMAP server.  Rather the client must be based upon the
   behavior allowed by the protocol.

   By documenting common IMAP4 server practice for the case of
   simultaneous client access to a mailbox, we hope to ensure the widest
   amount of inter-operation between IMAP4 clients and servers.

   The behavior described in this document reflects the practice of some
   existing servers or behavior that the consensus of the IMAP mailing
   list has deemed to be reasonable.  The behavior described within this
   document is believed to be [IMAP4] compliant. However, this document
   is not meant to define IMAP4 compliance, nor is it an exhaustive list
   of valid IMAP4 behavior. [IMAP4] must always be consulted to
   determine IMAP4 compliance, especially for server behavior not
   described within this document.

2. Conventions used in this document

   In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
   clients (client #1, client #2 and client #3) that are connected to a
   server.  "S1:", "S2:" and "S3:" indicated lines sent by the server to
   client #1, client #2 and client #3 respectively.

   A shared mailbox, is a mailbox that can be used by multiple users.

   A multi-accessed mailbox, is a mailbox that has multiple clients
   simultaneously accessing it.

   A client is said to have accessed a mailbox after a successful SELECT
   or EXAMINE command.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].


3. Deletion/Renaming of a multi-accessed mailbox



Gahrns                        Informational             FORMFEED[Page 2]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   If an external agent or multiple clients are accessing a mailbox,
   care must be taken when handling the deletion or renaming of the
   mailbox. Following are some strategies an IMAP server may choose to
   use when dealing with this situation.


3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
     mailbox

   In some cases, this behavior may not be practical.  For example, if a
   large number of clients are accessing a shared mailbox, the window in
   which no clients have the mailbox accessed may be small or non-
   existent, effectively rendering the mailbox undeletable or
   unrenamable.

   Example:

   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
   to DELETE the mailbox and is refused>

             C1: A001 DELETE FOO
             S1: A001 NO Mailbox FOO is in use by another user.


3.2. The server MAY allow the DELETE command of a multi-accessed
     mailbox, but keep the information in the mailbox available for
     those clients that currently have access to the mailbox.

   When all clients have finished accessing the mailbox, it is
   permanently removed.  For clients that do not already have access to
   the mailbox, the 'ghosted' mailbox would not be available.  For
   example, it would not be returned to these clients in a subsequent
   LIST or LSUB command and would not be a valid mailbox argument to any
   other IMAP command until the reference count of clients accessing the
   mailbox reached 0.

   In some cases, this behavior may not be desirable. For example if
   someone created a mailbox with offensive or sensitive information,
   one might prefer to have the mailbox deleted and all access to the
   information contained within removed immediately, rather than
   continuing to allow access until the client closes the mailbox.

   Furthermore, this behavior, may prevent 'recycling' of the same
   mailbox name until all clients have finished accessing the original
   mailbox.

   Example:




Gahrns                        Informational             FORMFEED[Page 3]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
   mailbox FOO>

             C1: A001 DELETE FOO
             S1: A001 OK Mailbox FOO is deleted.

   <Client #2 is still able to operate on the deleted mailbox>

             C2: B001 STORE 1 +FLAGS (\Seen)
             S2: * 1 FETCH (FLAGS (\Seen))
             S2: B001 OK STORE completed

   <Client #3 which did not have access to the mailbox prior to the
   deletion by client #1 does not have access to the mailbox>

             C3: C001 STATUS FOO (MESSAGES)
             S3: C001 NO Mailbox does not exist

   <Nor is client #3 able to create a mailbox with the name FOO, while
   the reference count is non zero>

             C3: C002 CREATE FOO
             S3: C002 NO Mailbox FOO is still in use. Try again later.

   <Client #2 closes its access to the mailbox, no other clients have
   access to the mailbox FOO and reference count becomes 0>

             C2: B002 CLOSE
             S2: B002 OK CLOSE Completed

   <Now that the reference count on FOO has reached 0, the mailbox name
   can be recycled>

             C3: C003 CREATE FOO
             S3: C003 OK CREATE Completed


3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
     mailbox, but disconnect all other clients who have the mailbox
     accessed by sending a untagged BYE response.

   A server may often choose to disconnect clients in the DELETE case,
   but may choose to implement a "friendlier" method for the RENAME
   case.

   Example:

   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs



Gahrns                        Informational             FORMFEED[Page 4]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   the mailbox FOO>

             C1: A002 DELETE FOO
             S1: A002 OK DELETE completed.

   <Server disconnects all other users of the mailbox>
             S2: * BYE Mailbox FOO has been deleted.


3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
     simply changing the name attribute on the mailbox.

   Other clients that have access to the mailbox can continue issuing
   commands such as FETCH that do not reference the mailbox name.
   Clients would discover the renaming the next time they referred to
   the old mailbox name.  Some servers MAY choose to include the
   REFERRAL response code [REFERRAL] in their tagged NO response to a
   command that contained the URL for the old mailbox name, as a hint to
   the client that the operation can succeed if the command is issued
   with the new mailbox name.

   Example:

   <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
   the mailbox.>

             C1: A001 RENAME FOO BAR
             S1: A001 OK RENAME completed.

   <Client #2 is still able to do operations that do not reference the
   mailbox name>

             C2: B001 FETCH 2:4 (FLAGS)
             S2: * 2 FETCH . . .
             S2: * 3 FETCH . . .
             S2: * 4 FETCH . . .
             S2: B001 OK FETCH completed

   <Client #2 is not able to do operations that reference the mailbox
   name>

             C2: B002 APPEND FOO {300}
             C2: Date: Mon, 7 Feb 1994 21:52:25 0800 (PST)
             C2: . . .
             S2: B002 NO [REFERRAL IMAP://user;AUTH=*@SERVER.EXAMPLE.COM/FOO
                  IMAP://user;AUTH=*@SERVER.EXAMPLE.COM/BAR] Mailbox has been renamed
             In the example above SERVER.EXAMPLE.COM references the
             server the client is connected to.



Gahrns                        Informational             FORMFEED[Page 5]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


4. Expunging of messages on a multi-accessed mailbox

   If an external agent or multiple clients are accessing a mailbox,
   care must be taken when handling the EXPUNGE of messages.  Other
   clients accessing the mailbox may be in the midst of issuing a
   command that depends upon message sequence numbers.  Because an
   EXPUNGE response can not be sent while responding to a FETCH, STORE
   or SEARCH command, it is not possible to immediately notify the
   client of the EXPUNGE.  This can result in ambiguity if the client
   issues a FETCH, STORE or SEARCH operation on a message that has been
   EXPUNGED.


4.1. Fetching of expunged messages

   Following are some strategies an IMAP server may choose to use when
   dealing with a FETCH command on expunged messages.

   Consider the following scenario:

   - Client #1 and Client #2 have mailbox FOO selected.
   - There are 7 messages in the mailbox.
   - Messages 4:7 are marked for deletion.
   - Client #1 issues an EXPUNGE, to expunge messages 4:7


4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
       keep the messages available to satisfy subsequent FETCH commands
       until it is able to send an EXPUNGE response to each client.

   In some cases, the behavior of keeping "ghosted" messages may not be
   desirable.  For example if a message contained offensive or sensitive
   information, one might prefer to instantaneously remove all access to
   the information, regardless of whether another client is in the midst
   of accessing it.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 is still able to access the expunged messages because the
   server has kept a 'ghosted' copy of the messages until it is able to
   notify client #2 of the EXPUNGE>

             C2: B001 FETCH 4:7 RFC822
             S2: * 4 FETCH (RFC822 . . . <RFC822 info returned>)
             S2: * 5 FETCH (RFC822 . . . <RFC822 info returned>)
             S2: * 6 FETCH (RFC822 . . . <RFC822 info returned>)
             S2: * 7 FETCH (RFC822 . . . <RFC822 info returned>)
             S2: B001 OK FETCH Completed



Gahrns                        Informational             FORMFEED[Page 6]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   <Client #2 issues a command where it can get notified of the EXPUNGE>

             C2: B002 NOOP
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 3 EXISTS
             S2: B002 OK NOOP Complete

   <Client #2 no longer has access to the expunged messages>

             C2: B003 FETCH 4:7 RFC822
             S2: B003 NO Messages 4:7 are no longer available.


4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
      and on subsequent FETCH commands return FETCH responses only for
      non-expunged messages and a tagged NO.

   After receiving a tagged NO FETCH response, the client SHOULD issue a
   NOOP command so that it will be informed of any pending EXPUNGE
   responses.  The client may then either reissue the failed FETCH
   command, or by examining the EXPUNGE response from the NOOP and the
   FETCH response from the FETCH, determine that the FETCH failed
   because of pending expunges.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 attempts to FETCH a mix of expunged and non-expunged
   messages.  A FETCH response is returned only for then non-expunged
   messages along with a tagged NO>

             C2: B001 FETCH 3:5 ENVELOPE
             S2: * 3 FETCH (ENVELOPE . . . <ENVELOPE info returned>)
             S2: B001 NO Some of the requested messages no longer exist

   <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
   to be informed of any pending EXPUNGE responses>

             C2: B002 NOOP
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 3 EXISTS
             S2: B002 OK NOOP Completed.




Gahrns                        Informational             FORMFEED[Page 7]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   <By receiving a FETCH response for message 3, and an EXPUNGE response
   that indicates messages 4:7 have been expunged, the client does not
   need to re-issue the FETCH>


4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
      on subsequent FETCH commands return the usual FETCH responses for
      non-expunged messages, "NIL FETCH Responses" for expunged
      messages, and a tagged OK response.

   If all of the messages in the subsequent FETCH command have been
   expunged, the server SHOULD return only a tagged NO.  In this case,
   the client SHOULD issue a NOOP command so that it will be informed of
   any pending EXPUNGE responses.  The client may then either reissue
   the failed FETCH command, or by examining the EXPUNGE response from
   the NOOP, determine that the FETCH failed because of pending
   expunges.

   "NIL FETCH responses" are a representation of empty data as
   appropriate for the FETCH argument specified.

   Example:

   * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
   * 1 FETCH (FLAGS ())
   * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
   * 1 FETCH (RFC822 "")
   * 1 FETCH (RFC822.HEADER "")
   * 1 FETCH (RFC822.TEXT "")
   * 1 FETCH (RFC822.SIZE 0)
   * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
   * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
   * 1 FETCH (BODY[<section>] "")
   * 1 FETCH (BODY[<section>]<partial> "")

   In some cases, a client may not be able to distinguish between "NIL
   FETCH responses" received because a message was expunged and those
   received because the data actually was NIL.  For example, a  * 5
   FETCH (FLAGS ()) response could be received if no flags were set on
   message 5, or because message 5 was expunged. In a case of potential
   ambiguity, the client SHOULD issue a command such as NOOP to force
   the sending of the EXPUNGE responses to resolve any ambiguity.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 attempts to access a mix of expunged and non-expunged
   messages.  Normal data is returned for non-expunged message, "NIL
   FETCH responses" are returned for expunged messages>



Gahrns                        Informational             FORMFEED[Page 8]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


             C2: B002 FETCH 3:5 ENVELOPE
             S2: * 3 FETCH (ENVELOPE . . . <ENVELOPE info returned>)
             S2: * 4 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
                   NIL NIL))
             S2: * 5 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
                   NIL NIL))
             S2: B002 OK FETCH Completed

   <Client #2 attempts to FETCH only expunged messages and receives a
   tagged NO response>

             C2: B002 FETCH 4:7 ENVELOPE
             S2: B002 NO Messages 4:7 have been expunged.


4.1.4 To avoid the situation altogether, the server MAY fail the
      EXPUNGE of a multi-accessed mailbox

   In some cases, this behavior may not be practical.  For example, if a
   large number of clients are accessing a shared mailbox, the window in
   which no clients have the mailbox accessed may be small or non-
   existent, effectively rendering the message unexpungeable.


4.2. Storing of expunged messages

   Following are some strategies an IMAP server may choose to use when
   dealing with a STORE command on expunged messages.


4.2.1 If the ".SILENT" suffix is used, and the STORE completed
      successfully for all the non-expunged messages, the server SHOULD
      return a tagged OK.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 tries to silently STORE flags on expunged and non-
   expunged messages.  The server sets the flags on the non-expunged
   messages and returns OK>

             C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
             S2: B001 OK









Gahrns                        Informational             FORMFEED[Page 9]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
       are referenced, the server SHOULD return only a tagged NO.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 tries to STORE flags only on expunged messages>

             C2: B001 STORE 5:7 +FLAGS (\SEEN)
             S2: B001 NO  Messages have been expunged


4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
       and non-expunged messages are referenced, the server MAY set the
       flags and return a FETCH response for the non-expunged messages
       along with a tagged NO.

   After receiving a tagged NO STORE response, the client SHOULD issue a
   NOOP command so that it will be informed of any pending EXPUNGE
   responses.  The client may then either reissue the failed STORE
   command, or by examining the EXPUNGE responses from the NOOP and
   FETCH responses from the STORE, determine that the STORE failed
   because of pending expunges.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 tries to STORE flags on a mixture of expunged and non-
   expunged messages>

             C2: B001 STORE 1:7 +FLAGS (\SEEN)
             S2: * 1 FETCH (FLAGS (\SEEN))
             S2: * 2 FETCH (FLAGS (\SEEN))
             S2: * 3 FETCH (FLAGS (\SEEN))
             S2: B001 NO Some of the messages no longer exist.

             C2: B002 NOOP
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 3 EXISTS
             S2: B002 OK NOOP Completed.

   <By receiving FETCH responses for messages 1:3, and an EXPUNGE
   response that indicates messages 4:7 have been expunged, the client
   does not need to re-issue the STORE>






Gahrns                        Informational            FORMFEED[Page 10]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
       and non-expunged messages are referenced, the server MAY return
       an untagged NO and not set any flags.

   After receiving a tagged NO STORE response, the client SHOULD issue a
   NOOP command so that it will be informed of any pending EXPUNGE
   responses.  The client would then re-issue the STORE command after
   updating its message list per any EXPUNGE response.

   If a large number of clients are accessing a shared mailbox, the
   window in which there are no pending expunges may be small or non-
   existent, effectively disallowing a client from setting the flags on
   all messages at once.

   Example:  (Building upon the scenario outlined in 4.1.)

   <Client #2 tries to STORE flags on a mixture of expunged and non-
   expunged messages>

             C2: B001 STORE 1:7 +FLAGS (\SEEN)
             S2: B001 NO  Some of the messages no longer exist.

   <Client #2 issues a NOOP to be informed of the EXPUNGED messages>

             C2: B002 NOOP
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 4 EXPUNGE
             S2: * 3 EXISTS
             S2: B002 OK NOOP Completed.

   <Client #2 updates its message list and re-issues the STORE on only
   those messages that have not been expunged>

             C2: B003 STORE 1:3 +FLAGS (\SEEN)
             S2: * 1 FETCH (FLAGS (\SEEN))
             S2: * 2 FETCH (FLAGS (\SEEN))
             S2: * 3 FETCH (FLAGS (\SEEN))
             S2: B003 OK  STORE Completed


4.3. Searching of expunged messages

   A server MAY simply not return a search response for messages that
   have been expunged and it has not been able to inform the client
   about.  If a client was expecting a particular message to be returned
   in a search result, and it was not, the client SHOULD issue a NOOP



Gahrns                        Informational            FORMFEED[Page 11]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   command to see if the message was expunged by another client.


4.4 Copying of expunged messages

   COPY is the only IMAP4 sequence number command that is safe to allow
   an EXPUNGE response on.  This is because a client is not permitted to
   cascade several COPY commands together. A client is required to wait
   and confirm that the copy worked before issuing another one.

4.4.1 The server MAY disallow the COPY of messages in a multi-access
      mailbox that contains expunged messages.

   Pending EXPUNGE response(s) MUST be returned to the COPY command.

   Example:

             C: A001 COPY 2,4,6,8 FRED
             S: * 4 EXPUNGE
             S: A001 NO COPY rejected, because some of the requested
                messages were expunged

   Note: Non of the above messages are copied because if a COPY command
   is unsuccessful, the server MUST restore the destination mailbox to
   its state before the COPY attempt.


4.4.2 The server MAY allow the COPY of messages in a multi-access
      mailbox that contains expunged messages.

   Pending EXPUNGE response(s) MUST be returned to the COPY command.
   Messages that are copied are messages corresponding to sequence
   numbers before any EXPUNGE response.

   Example:

             C: A001 COPY 2,4,6,8 FRED
             S: * 3 EXPUNGE
             S: A001 OK COPY completed

   In the above example, the messages that are copied to FRED are
   messages 2,4,6,8 at the start of the COPY command.  These are
   equivalent to messages 2,3,5,7 at the end of the COPY command.  The
   EXPUNGE response can't take place until after the messages from the
   COPY command are identified (because of the "no expunge while no
   commands in progress" rule).





Gahrns                        Informational            FORMFEED[Page 12]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   Example:

             C: A001 COPY 2,4,6,8 FRED
             S: * 4 EXPUNGE
             S: A001 OK COPY completed

   In the above example, message 4 was copied before it was expunged,
   and MUST appear in the destination mailbox FRED.


5. Security Considerations

   This document describes behavior of servers that use the IMAP4
   protocol, and as such, has the same security considerations as
   described in [IMAP4].

   In particular, some described server behavior does not allow for the
   immediate deletion of information when a mailbox is accessed by
   multiple clients.  This may be a consideration when dealing with
   sensitive information where immediate deletion would be preferred.


6. References

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 3501, University of Washington, March 2003.

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [REFERRAL] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
   Microsoft, September 1997


7.  Acknowledgments

   This document is the result of discussions on the IMAP4 mailing list
   and is meant to reflect consensus of this group.  In particular,
   Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
   Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
   Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
   Winter were active participants in this discussion or made
   suggestions to this document.








Gahrns                        Informational            FORMFEED[Page 13]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


8. Author's and Editor's Addresses

   Author: Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98072

   Phone: (206) 936-9833
   EMail: mikega@microsoft.com


   Editor: Alexey Melnikov
   Isode Limited
   5 Castle Business Village,
   36 Station Road,
   Hampton, Middlesex,
   United Kingdom, TW12 2BX

   Phone: +44 77 53759732
   Email: alexey.melnikov@isode.com



10.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS



Gahrns                        Informational            FORMFEED[Page 14]


RFC 2180bis       IMAP4 Multi-Accessed Mailbox Practice     October 2004


   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

   11.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Appendix A. Change History

    Changes from RFC 2180.
     1.  Updated boilerplate and references.
     2.  Fixed wrong formatting in section 3.4.
     3.  Fixed syntax of several FETCH responses.
     4.  Replaced obsoleted NEWNAME response code with REFERRAL.

Appendix B. ToDo

     1.  List preferred choices
     2.  Abstract must not be numbered




Gahrns                        Informational            FORMFEED[Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/