idnits 2.17.1 draft-ietf-lemonade-catenate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 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 85: '... OPTIONAL flag parenth...' RFC 2119 keyword, line 87: '... OPTIONAL date/time st...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 30, 2003) is 7423 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) ** Obsolete normative reference: RFC 3501 (ref. '1') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2192 (ref. '2') (Obsoleted by RFC 5092) ** Obsolete normative reference: RFC 2822 (ref. '3') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2359 (ref. '5') (Obsoleted by RFC 4315) ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LEMONADE P. Resnick 3 Internet-Draft QUALCOMM Incorporated 4 Expires: June 29, 2004 December 30, 2003 6 Internet Message Access Protocol (IMAP) CATENATE Extension 7 draft-ietf-lemonade-catenate-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on June 29, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 The CATENATE extension to the Internet Message Access Protocol (IMAP) 38 allows clients to create messages on the IMAP server which may 39 contain a combination of new data along with parts of (or entire) 40 messages already on the server. Using this extension, the client can 41 catenate parts of an already existing message on to a new message 42 without having to first download the data and then upload it back to 43 the server. 45 1. Introduction 47 The CATENATE extension to the Internet Message Access Protocol (IMAP) 48 [1] allows the client to create a message on the server which can 49 include the text of messages (or parts of messages) that already 50 exist on the server without having to FETCH them and APPEND them back 51 to the server. The CATENATE command works much like the APPEND 52 command except that, instead of a single message literal, the command 53 can take as arguments any combination of message literals (as 54 described in IMAP [1]) and message URLs (as described in the IMAP URL 55 Scheme [2] specification). The server takes all of the pieces and 56 catenates them into the output message. 58 There are some obvious uses for the CATENATE command. The motivating 59 use case for this command was to provide a way for a 60 resource-constrained client to compose a message for future delivery 61 which contains data that already exists in that client's IMAP store. 62 Because the client does not have to download and re-upload 63 potentially large message parts, bandwidth and processing limitations 64 do not have as much impact. (Mechanisms for sending the message are 65 outside of the scope of this document.) 67 CATENATE can also be used to copy parts of a message to another 68 mailbox for archival purposes while getting rid of undesired parts. 69 In environments where server storage is limited, a client could get 70 rid of large message parts by copying over only the necessary parts 71 and then deleting the original message. CATENATE could also be used 72 to add data to a message such as prepending message header fields or 73 including other data by making a copy of the original and catenating 74 the new data. 76 2. The CATENATE Capability 78 A server which supports this extension returns "CATENATE" as one of 79 the responses to the CAPABILITY command. 81 3. The CATENATE command 83 Arguments: mailbox name 85 OPTIONAL flag parenthesized list 87 OPTIONAL date/time string 89 one or more message parts to catenate, specified as: 91 message literal 93 or 95 message (or message part) URL 97 Responses: no specific responses for this command 99 Result: 101 OK - catenate completed 103 NO - catenate error: can't append to that mailbox, 104 error in flags or date/time or message text, or 105 can't fetch that data 107 BAD - command unknown or arguments invalid 109 The CATENATE command concatenates all of the message parts and 110 appends them as a new message to the end of the specified mailbox. 111 The optional flag parenthesized list and date/time string are used 112 just as they are in the APPEND command, setting the flags and the 113 internal date, respectively. The subsequent parameters specify the 114 message parts that are appended sequentially to the output message. 116 If a message literal is specified (indicated by the octet count 117 enclosed in braces), the octets following the count are appended just 118 as they would be with the APPEND command. If a message URL is 119 specified, the octets of that body part are appended, as if the 120 literal returned in a FETCH BODY response were put in place of the 121 message part specifier. The CATENATE command does not cause the \Seen 122 flag to be set for any catenated body part. 124 Note: This document only describes the behavior of the CATENATE 125 command using a message URL (as defined by [2]) which refers to a 126 specific message or message part in the currently selected mailbox 127 on the current IMAP server. (Because of that, the CATENATE command 128 is valid in the selected state for purposes of this 129 specification.) Use of a URL that refers to anything other than a 130 message or message part from the currently selected mailbox on the 131 current IMAP server is outside of the scope of this document, 132 would require an extension to this specification, and a server 133 implementing only this specification would return NO to such a 134 request. 136 The client is responsible for making sure that the catenated message 137 is in the format of an RFC 2822 [3] message. This includes inserting 138 appropriate MIME [4] boundaries between body parts if necessary. 140 Responses behave just as the APPEND command. If the server implements 141 the IMAP UIDPLUS extension [5], it will also return an APPENDUID 142 response code in the tagged OK response. 144 4. Formal Syntax 146 The following syntax specification uses the Augmented Backus-Naur 147 Form (ABNF) [6] notation. Undefined elements are defined in the 148 formal syntax of the ABNF [6], IMAP [1], and IMAP URL [2] 149 specifications. 151 catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] 152 1*(SP (literal / imapurl)) 154 Figure 1 156 5. Security Considerations 158 The CATENATE extension does not raise any security considerations 159 that are not present for the base protocol or in the use of IMAP 160 URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] 161 documents. 163 Normative References 165 [1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 166 RFC 3501, March 2003. 168 [2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 170 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 172 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 173 Extensions (MIME) Part One: Format of Internet Message Bodies", 174 RFC 2045, November 1996. 176 [5] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998. 178 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 179 Specifications: ABNF", RFC 2234, November 1997. 181 Author's Address 183 Peter W. Resnick 184 QUALCOMM Incorporated 185 5775 Morehouse Drive 186 San Diego, CA 92121-1714 187 US 189 Phone: +1 858 651 4478 190 EMail: presnick@qualcomm.com 191 URI: http://www.qualcomm.com/~presnick/ 193 Intellectual Property Statement 195 The IETF takes no position regarding the validity or scope of any 196 intellectual property or other rights that might be claimed to 197 pertain to the implementation or use of the technology described in 198 this document or the extent to which any license under such rights 199 might or might not be available; neither does it represent that it 200 has made any effort to identify any such rights. Information on the 201 IETF's procedures with respect to rights in standards-track and 202 standards-related documentation can be found in BCP-11. Copies of 203 claims of rights made available for publication and any assurances of 204 licenses to be made available, or the result of an attempt made to 205 obtain a general license or permission for the use of such 206 proprietary rights by implementors or users of this specification can 207 be obtained from the IETF Secretariat. 209 The IETF invites any interested party to bring to its attention any 210 copyrights, patents or patent applications, or other proprietary 211 rights which may cover technology that may be required to practice 212 this standard. Please address the information to the IETF Executive 213 Director. 215 Full Copyright Statement 217 Copyright (C) The Internet Society (2003). All Rights Reserved. 219 This document and translations of it may be copied and furnished to 220 others, and derivative works that comment on or otherwise explain it 221 or assist in its implementation may be prepared, copied, published 222 and distributed, in whole or in part, without restriction of any 223 kind, provided that the above copyright notice and this paragraph are 224 included on all such copies and derivative works. However, this 225 document itself may not be modified in any way, such as by removing 226 the copyright notice or references to the Internet Society or other 227 Internet organizations, except as needed for the purpose of 228 developing Internet standards in which case the procedures for 229 copyrights defined in the Internet Standards process must be 230 followed, or as required to translate it into languages other than 231 English. 233 The limited permissions granted above are perpetual and will not be 234 revoked by the Internet Society or its successors or assignees. 236 This document and the information contained herein is provided on an 237 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 238 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 239 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 240 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 241 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 243 Acknowledgment 245 Funding for the RFC Editor function is currently provided by the 246 Internet Society.