diff options
Diffstat (limited to 'imap/docs/rfc/rfc4469.txt')
| -rw-r--r-- | imap/docs/rfc/rfc4469.txt | 731 |
1 files changed, 0 insertions, 731 deletions
diff --git a/imap/docs/rfc/rfc4469.txt b/imap/docs/rfc/rfc4469.txt deleted file mode 100644 index da365514..00000000 --- a/imap/docs/rfc/rfc4469.txt +++ /dev/null @@ -1,731 +0,0 @@ - - - - - - -Network Working Group P. Resnick -Request for Comments: 4469 QUALCOMM Incorporated -Updates: 3501, 3502 April 2006 -Category: Standards Track - - - Internet Message Access Protocol (IMAP) CATENATE 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 (2006). - -Abstract - - The CATENATE extension to the Internet Message Access Protocol (IMAP) - extends the APPEND command to allow clients to create messages on the - IMAP server that may contain a combination of new data along with - parts of (or entire) messages already on the server. Using this - extension, the client can catenate parts of an already existing - message onto a new message without having to first download the data - and then upload it back to the server. - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 1] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -1. Introduction - - The CATENATE extension to the Internet Message Access Protocol (IMAP) - [1] allows the client to create a message on the server that can - include the text of messages (or parts of messages) that already - exist on the server without having to FETCH them and APPEND them back - to the server. The CATENATE extension extends the APPEND command so - that, instead of a single message literal, the command can take as - arguments any combination of message literals (as described in IMAP - [1]) and message URLs (as described in the IMAP URL Scheme [2] - specification). The server takes all the pieces and catenates them - into the output message. The CATENATE extension can also coexist - with the MULTIAPPEND extension [3] to APPEND multiple messages in a - single command. - - There are some obvious uses for the CATENATE extension. The - motivating use case was to provide a way for a resource-constrained - client to compose a message for subsequent submission that contains - data that already exists in that client's IMAP store. Because the - client does not have to download and re-upload potentially large - message parts, bandwidth and processing limitations do not have as - much impact. In addition, since the client can create a message in - its own IMAP store, the command also addresses the desire of the - client to archive a copy of a sent message without having to upload - the message twice. (Mechanisms for sending the message are outside - the scope of this document.) - - The extended APPEND command can also be used to copy parts of a - message to another mailbox for archival purposes while getting rid of - undesired parts. In environments where server storage is limited, a - client could get rid of large message parts by copying over only the - necessary parts and then deleting the original message. The - mechanism could also be used to add data to a message (such as - prepending message header fields) or to include other data by making - a copy of the original and catenating the new data. - -2. The CATENATE Capability - - A server that supports this extension returns "CATENATE" as one of - the responses to the CAPABILITY command. - - - - - - - - - - - -Resnick Standards Track [Page 2] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -3. The APPEND Command - - Arguments: mailbox name - (The following can be repeated in the presence of the - MULTIAPPEND extension [3]) - OPTIONAL flag parenthesized list - OPTIONAL date/time string - a single message literal or one or more message parts to - catenate, specified as: - message literal - or - message (or message part) URL - - Responses: OPTIONAL NO responses: BADURL, TOOBIG - - Result: OK - append completed - NO - append error: can't append to that mailbox, error - in flags or date/time or message text, or can't - fetch that data - BAD - command unknown or arguments invalid - - The APPEND command concatenates all the message parts and appends - them as a new message to the end of the specified mailbox. The - parenthesized flag list and date/time string set the flags and the - internal date, respectively, as described in IMAP [1]. The - subsequent command parameters specify the message parts that are - appended sequentially to the output message. - - If the original form of APPEND is used, a message literal follows the - optional flag list and date/time string, which is appended as - described in IMAP [1]. If the extended form is used, "CATENATE" and - a parenthesized list of message literals and message URLs follows, - each of which is appended to the new message. If a message literal - is specified (indicated by "TEXT"), the octets following the count - are appended. If a message URL is specified (indicated by "URL"), - the octets of the body part pointed to by that URL are appended, as - if the literal returned in a FETCH BODY response were put in place of - the message part specifier. The APPEND command does not cause the - \Seen flag to be set for any catenated body part. The APPEND command - does not change the selected mailbox. - - In the extended APPEND command, the string following "URL" is an IMAP - URL [2] and is interpreted according to the rules of [2]. The - present document only describes the behavior of the command using - IMAP URLs that refer to specific messages or message parts on the - current IMAP server from the current authenticated IMAP session. - Because of that, only relative IMAP message or message part URLs - (i.e., those having no scheme or <iserver>) are used. The base URL - - - -Resnick Standards Track [Page 3] - -RFC 4469 IMAP CATENATE Extension April 2006 - - - for evaluating the relative URL is considered "imap://user@server/", - where "user" is the user name of the currently authenticated user and - "server" is the domain name of the current server. When in the - selected state, the base URL is considered - "imap://user@server/mailbox", where "mailbox" is the encoded name of - the currently selected mailbox. Additionally, since the APPEND - command is valid in the authenticated state of an IMAP session, no - further LOGIN or AUTHENTICATE command is performed for URLs specified - in the extended APPEND command. - - Note: Use of an absolute IMAP URL or any URL that refers to - anything other than a message or message part from the current - authenticated IMAP session is outside the scope of this document - and would require an extension to this specification, and a server - implementing only this specification would return NO to such a - request. - - The client is responsible for making sure that the catenated message - is in the format of an Internet Message Format (RFC 2822) [4] or - Multipurpose Internet Mail Extension (MIME) [5] message. In - particular, when a URL is catenated, the server copies octets, - unchanged, from the indicated message or message part to the - catenated message. It does no data conversion (e.g., MIME transfer - encodings) nor any verification that the data is appropriate for the - MIME part of the message into which it is inserted. The client is - also responsible for inserting appropriate MIME boundaries between - body parts, and writing MIME Content-Type and Content-Transfer- - Encoding lines as needed in the appropriate places. - - Responses behave just as the original APPEND command described in - IMAP [1]. If the server implements the IMAP UIDPLUS extension [6], - it will also return an APPENDUID response code in the tagged OK - response. Two response codes are provided in Section 4 that can be - used in the tagged NO response if the APPEND command fails. - -4. Response Codes - - When a APPEND command fails, it may return a response code that - describes a reason for the failure. - -4.1. BADURL Response - - The BADURL response code is returned if the APPEND fails to process - one of the specified URLs. Possible reasons for this are bad URL - syntax, unrecognized URL schema, invalid message UID, or invalid body - part. The BADURL response code contains the first URL specified as a - parameter to the APPEND command that has caused the operation to - fail. - - - -Resnick Standards Track [Page 4] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -4.2. TOOBIG Response - - The TOOBIG response code is returned if the resulting message will - exceed the 4-GB IMAP message limit. This might happen, for example, - if the client specifies 3 URLs for 2-GB messages. Note that even if - the server doesn't return TOOBIG, it still has to be defensive - against misbehaving or malicious clients that try to construct a - message over the 4-GB limit. The server may also wish to return the - TOOBIG response code if the resulting message exceeds a server- - specific message size limit. - -5. Formal Syntax - - The following syntax specification uses the Augmented Backus-Naur - Form (ABNF) [7] notation. Elements not defined here can be found in - the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions - [8] specifications. Note that capability and resp-text-code are - extended from the IMAP [1] specification and append-data is extended - from the IMAP ABNF extensions [8] specification. - - append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")" - - cat-part = text-literal / url - - text-literal = "TEXT" SP literal - - url = "URL" SP astring - - resp-text-code =/ toobig-response-code / badurl-response-code - - toobig-response-code = "TOOBIG" - - badurl-response-code = "BADURL" SP url-resp-text - - url-resp-text = 1*(%x01-09 / - %x0B-0C / - %x0E-5B / - %x5D-FE) ; Any TEXT-CHAR except "]" - - capability =/ "CATENATE" - - The astring in the definition of url and the url-resp-text in the - definition of badurl-response-code each contain an imapurl as defined - by [2]. - - - - - - - -Resnick Standards Track [Page 5] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -6. Acknowledgements - - Thanks to the members of the LEMONADE working group for their input. - Special thanks to Alexey Melnikov for the examples. - -7. Security Considerations - - The CATENATE extension does not raise any security considerations - that are not present for the base protocol or in the use of IMAP - URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] - documents. - -8. IANA Considerations - - IMAP4 capabilities are registered by publishing a standards track or - IESG approved experimental RFC. The registry is currently located at - <http://www.iana.org/assignments/imap4-capabilities>. This document - defines the CATENATE IMAP capability. The IANA has added this - capability to the registry. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 6] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -Appendix A. Examples - - Lines not starting with "C: " or "S: " are continuations of the - previous lines. - - The original message in examples 1 and 2 below (UID = 20) has the - following structure: - - - multipart/mixed MIME message with two body parts: - - 1. text/plain - - 2. application/x-zip-compressed - - Example 1: The following example demonstrates how a CATENATE client - can replace an attachment in a draft message, without the need to - download it to the client and upload it back. - - C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE - (URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER" - TEXT {42} - S: + Ready for literal data - C: - C: --------------030308070208000400050907 - C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME" - URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42} - S: + Ready for literal data - C: - C: --------------030308070208000400050907 - C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44} - S: + Ready for literal data - C: - C: --------------030308070208000400050907-- - C: ) - S: A003 OK catenate append completed - - - - - - - - - - - - - - - -Resnick Standards Track [Page 7] - -RFC 4469 IMAP CATENATE Extension April 2006 - - - Example 2: The following example demonstrates how the CATENATE - extension can be used to replace edited text in a draft message, as - well as header fields for the top level message part (e.g., Subject - has changed). The previous version of the draft is marked as - \Deleted. Note that the server also supports the UIDPLUS extension, - so the APPENDUID response code is returned in the successful OK - response to the APPEND command. - - C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738} - S: + Ready for literal data - C: Return-Path: <bar@example.org> - C: Received: from [127.0.0.2] - C: by rufus.example.org via TCP (internal) with ESMTPA; - C: Thu, 11 Nov 2004 16:57:07 +0000 - C: Message-ID: <419399E1.6000505@example.org> - C: Date: Thu, 12 Nov 2004 16:57:05 +0000 - C: From: Bob Ar <bar@example.org> - C: X-Accept-Language: en-us, en - C: MIME-Version: 1.0 - C: To: foo@example.net - C: Subject: About our holiday trip - C: Content-Type: multipart/mixed; - C: boundary="------------030308070208000400050907" - C: - C: --------------030308070208000400050907 - C: Content-Type: text/plain; charset=us-ascii; format=flowed - C: Content-Transfer-Encoding: 7bit - C: - C: Our travel agent has sent the updated schedule. - C: - C: Cheers, - C: Bob - C: --------------030308070208000400050907 - C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME" - URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44} - S: + Ready for literal data - C: - C: --------------030308070208000400050907-- - C: ) - S: A003 OK [APPENDUID 385759045 45] append Completed - C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) - S: A004 OK STORE completed - - - - - - - - - -Resnick Standards Track [Page 8] - -RFC 4469 IMAP CATENATE Extension April 2006 - - - Example 3: The following example demonstrates how the CATENATE - extension can be used to strip attachments. Below, a PowerPoint - attachment was replaced by a small text part explaining that the - attachment was stripped. - - C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE - (URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER" - TEXT {42} - S: + Ready for literal data - C: - C: --------------030308070208000400050903 - C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME" - URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255} - S: + Ready for literal data - C: - C: --------------030308070208000400050903 - C: Content-type: text/plain; charset="us-ascii" - C: Content-transfer-encoding: 7bit - C: - C: This body part contained a Power Point presentation that was - C: deleted upon your request. - C: --------------030308070208000400050903-- - C: ) - S: A003 OK append Completed - - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 9] - -RFC 4469 IMAP CATENATE Extension April 2006 - - - Example 4: The following example demonstrates a failed APPEND - command. The server returns the BADURL response code to indicate - that one of the provided URLs is invalid. This example also - demonstrates how the CATENATE extension can be used to construct a - digest of several messages. - - C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541} - S: + Ready for literal data - C: Return-Path: <foo@example.org> - C: Received: from [127.0.0.2] - C: by rufus.example.org via TCP (internal) with ESMTPA; - C: Thu, 11 Nov 2004 16:57:07 +0000 - C: Message-ID: <419399E1.6000505@example.org> - C: Date: Thu, 21 Nov 2004 16:57:05 +0000 - C: From: Farren Oo <foo@example.org> - C: X-Accept-Language: en-us, en - C: MIME-Version: 1.0 - C: To: bar@example.org - C: Subject: Digest of the mailing list for today - C: Content-Type: multipart/digest; - C: boundary="------------030308070208000400050904" - C: - C: --------------030308070208000400050904 - C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42} - S: + Ready for literal data - C: - C: --------------030308070208000400050904 - C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9" - TEXT {42} - S: + Ready for literal data - C: - C: --------------030308070208000400050904 - C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44} - S: + Ready for literal data - C: - C: --------------030308070208000400050904-- - C: ) - S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330; - section=1.5.9"] CATENATE append has failed, one message expunged - - Note that the server could have validated the URLs as they were - received and therefore could have returned the tagged NO response - with BADURL response-code in place of any continuation request after - the URL was received. - - - - - - - -Resnick Standards Track [Page 10] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -9. Normative References - - [1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", - RFC 3501, March 2003. - - [2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. - - [3] Crispin, M., "Internet Message Access Protocol (IMAP) - - MULTIAPPEND Extension", RFC 3502, March 2003. - - [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - RFC 2045, November 1996. - - [6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS - extension", RFC 4315, December 2005. - - [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", - RFC 4466, April 2006. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 11] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -Author's Address - - Peter W. Resnick - QUALCOMM Incorporated - 5775 Morehouse Drive - San Diego, CA 92121-1714 - US - - Phone: +1 858 651 4478 - EMail: presnick@qualcomm.com - URI: http://www.qualcomm.com/~presnick/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 12] - -RFC 4469 IMAP CATENATE Extension April 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - 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 the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - 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. - -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. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Resnick Standards Track [Page 13] - |