rfc2180.txt

mgcp协议源代码。支持多种编码：g711


RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


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                      [Page 8]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


             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                      [Page 9]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


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: * FETCH 1 FLAGS (\SEEN)
             S2: * FETCH 2 FLAGS (\SEEN)
             S2: * FETCH 3 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                     [Page 10]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


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: * FETCH 1 FLAGS
             (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 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
   command to see if the message was expunged by another client.




Gahrns                       Informational                     [Page 11]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


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                     [Page 12]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


   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 [RFC-2060].

   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

   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 2060, University of Washington, December 1996.

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 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                     [Page 13]

RFC 2180         IMAP4 Multi-Accessed Mailbox Practice         July 1997


8. Author's Address

   Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98072

   Phone: [phone]
   EMail: [e-mail]










































Gahrns                       Informational                     [Page 14]