diff options
Diffstat (limited to 'imap/docs/rfc/rfc3502.txt')
| -rw-r--r-- | imap/docs/rfc/rfc3502.txt | 395 |
1 files changed, 0 insertions, 395 deletions
diff --git a/imap/docs/rfc/rfc3502.txt b/imap/docs/rfc/rfc3502.txt deleted file mode 100644 index f6b61a44..00000000 --- a/imap/docs/rfc/rfc3502.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group M. Crispin -Request for Comments: 3502 University of Washington -Category: Standards Track March 2003 - - - Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes the multiappending extension to the Internet - Message Access Protocol (IMAP) (RFC 3501). This extension provides - substantial performance improvements for IMAP clients which upload - multiple messages at a time to a mailbox on the server. - - A server which supports this extension indicates this with a - capability name of "MULTIAPPEND". - -Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to - be interpreted as described in [KEYWORDS]. - -Introduction - - The MULTIAPPEND extension permits uploading of multiple messages with - a single command. When used in conjunction with the [LITERAL+] - extension, the entire upload is accomplished in a single - command/response round trip. - - A MULTIAPPEND APPEND operation is atomic; either all messages are - successfully appended, or no messages are appended. - - In the base IMAP specification, each message must be appended in a - separate command, and there is no mechanism to "unappend" messages if - an error occurs while appending. Also, some mail stores may require - - - -Crispin Standards Track [Page 1] - -RFC 3502 IMAP MULTIAPPEND March 2003 - - - an expensive "open/lock + sync/unlock/close" operation as part of - appending; this can be quite expensive if it must be done on a - per-message basis. - - If the server supports both LITERAL+ and pipelining but not - MULTIAPPEND, it may be possible to get some of the performance - advantages of MULTIAPPEND by doing a pipelined "batch" append. - However, it will not work as well as MULTIAPPEND for the following - reasons: - - 1) Multiple APPEND commands, even as part of a pipelined batch, - are non-atomic by definition. There is no way to revert the - mailbox to the state before the batch append in the event of an - error. - - 2) It may not be feasible for the server to coalesce pipelined - APPEND operations so as to avoid the "open/lock + - sync/unlock/close" overhead described above. In any case, such - coalescing would be timing dependent and thus potentially - unreliable. In particular, with traditional UNIX mailbox files, - it is assumed that a lock is held only for a single atomic - operation, and many applications disregard any lock that is - older than 5 minutes. - - 3) If an error occurs, depending upon the nature of the error, - it is possible for additional messages to be appended after the - error. For example, the user wants to append 5 messages, but a - disk quota error occurs with the third message because of its - size. However, the fourth and fifth messages have already been - sent in the pipeline, so the mailbox ends up with the first, - second, fourth, and fifth messages of the batch appended. - -6.3.11. APPEND Command - - Arguments: mailbox name - one or more messages to upload, specified as: - OPTIONAL flag parenthesized list - OPTIONAL date/time string - message literal - - Data: no specific responses for this command - - Result: OK - append completed - NO - append error: can't append to that mailbox, error - in flags or date/time or message text, - append cancelled - BAD - command unknown or arguments invalid - - - - -Crispin Standards Track [Page 2] - -RFC 3502 IMAP MULTIAPPEND March 2003 - - - The APPEND command appends the literal arguments as new messages - to the end of the specified destination mailbox. This argument - SHOULD be in the format of an [RFC-2822] message. 8-bit - characters are permitted in the message. A server implementation - that is unable to preserve 8-bit data properly MUST be able to - reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] - content transfer encoding. - - Note: There MAY be exceptions, e.g., draft messages, in - which required [RFC-2822] header lines are omitted in the - message literal argument to APPEND. The full implications - of doing so MUST be understood and carefully weighed. - - If a flag parenthesized list is specified, the flags SHOULD be set - in the resulting message; otherwise, the flag list of the - resulting message is set empty by default. - - If a date-time is specified, the internal date SHOULD be set in - the resulting message; otherwise, the internal date of the - resulting message is set to the current date and time by default. - - A zero-length message literal argument is an error, and MUST - return a NO. This can be used to cancel the append. - - If the append is unsuccessful for any reason (including being - cancelled), the mailbox MUST be restored to its state before the - APPEND attempt; no partial appending is permitted. The server MAY - return an error before processing all the message arguments. - - If the destination mailbox does not exist, a server MUST return an - error, and MUST NOT automatically create the mailbox. Unless it - is certain that the destination mailbox can not be created, the - server MUST send the response code "[TRYCREATE]" as the prefix of - the text of the tagged NO response. This gives a hint to the - client that it can attempt a CREATE command and retry the APPEND - if the CREATE is successful. - - If the mailbox is currently selected, the normal new message - actions SHOULD occur. Specifically, the server SHOULD notify the - client immediately via an untagged EXISTS response. If the server - does not do so, the client MAY issue a NOOP command (or failing - that, a CHECK command) after one or more APPEND commands. - - - - - - - - - -Crispin Standards Track [Page 3] - -RFC 3502 IMAP MULTIAPPEND March 2003 - - - Example: C: A003 APPEND saved-messages (\Seen) {329} - S: + Ready for literal data - C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) - C: From: Fred Foobar <foobar@Blurdybloop.example.COM> - C: Subject: afternoon meeting - C: To: mooch@owatagu.example.net - C: Message-Id: <B27397-0100000@Blurdybloop.example.COM> - C: MIME-Version: 1.0 - C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII - C: - C: Hello Joe, do you think we can meet at 3:30 tomorrow? - C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295} - S: + Ready for literal data - C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST) - C: From: Joe Mooch <mooch@OWaTaGu.example.net> - C: Subject: Re: afternoon meeting - C: To: foobar@blurdybloop.example.com - C: Message-Id: <a0434793874930@OWaTaGu.example.net> - C: MIME-Version: 1.0 - C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII - C: - C: 3:30 is fine with me. - C: - S: A003 OK APPEND completed - C: A004 APPEND bogusname (\Flagged) {1023} - S: A004 NO [TRYCREATE] No such mailbox as bogusname - C: A005 APPEND test (\Flagged) {99} - S: + Ready for literal data - C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST) - C: From: Fred Foobar <fred@example.com> - C: Subject: hmm... - C: {35403} - S: A005 NO APPEND failed: Disk quota exceeded - - Note: The APPEND command is not used for message delivery, - because it does not provide a mechanism to transfer [SMTP] - envelope information. - -Modification to IMAP4rev1 Base Protocol Formal Syntax - - The following syntax specification uses the Augmented Backus-Naur - Form (ABNF) notation as specified in [ABNF]. - - append = "APPEND" SP mailbox 1*append-message - - append-message = [SP flag-list] [SP date-time] SP literal - - - - - -Crispin Standards Track [Page 4] - -RFC 3502 IMAP MULTIAPPEND March 2003 - - -MULTIAPPEND Interaction with UIDPLUS Extension - - Servers which support both MULTIAPPEND and [UIDPLUS] will have the - "resp-code-apnd" rule modified as follows: - - resp-code-apnd = "APPENDUID" SP nz-number SP set - - That is, the APPENDUID response code returns as many UIDs as there - were messages appended in the multiple append. The UIDs returned - should be in the order the articles where appended. The message set - may not contain extraneous UIDs or the symbol "*". - -Security Considerations - - The MULTIAPPEND extension does not raise any security considerations - that are not present in the base [IMAP] protocol, and these issues - are discussed in [IMAP]. Nevertheless, it is important to remember - that IMAP4rev1 protocol transactions, including electronic mail data, - are sent in the clear over the network unless protection from - snooping is negotiated, either by the use of STARTTLS, privacy - protection is negotiated in the AUTHENTICATE command, or some other - protection mechanism is in effect. - -Normative References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [IMAP] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 3501, March 2003. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet - Mail Extensions) Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April - 2001. - - - - - - - - - - - -Crispin Standards Track [Page 5] - -RFC 3502 IMAP MULTIAPPEND March 2003 - - -Informative References - - [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, - January 1997. - - [UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988. - - [SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC - 2821, April 2001. - -Author's Address - - Mark R. Crispin - Networks and Distributed Computing - University of Washington - 4545 15th Avenue NE - Seattle, WA 98105-4527 - - Phone: (206) 543-5762 - EMail: MRC@CAC.Washington.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Crispin Standards Track [Page 6] - -RFC 3502 IMAP MULTIAPPEND March 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - 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 is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - -Crispin Standards Track [Page 7] - |