idnits 2.17.1 draft-ietf-lemonade-catenate-00.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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 84: '... OPTIONAL flag parenth...' RFC 2119 keyword, line 86: '... OPTIONAL date/time st...' RFC 2119 keyword, line 98: '... OPTIONAL substring sp...' RFC 2119 keyword, line 141: '... OPTIONAL flag parenth...' RFC 2119 keyword, line 143: '... OPTIONAL date/time st...' (1 more instance...) 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 5, 2003) is 7448 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 2822 (ref. '2') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2359 (ref. '3') (Obsoleted by RFC 4315) ** Obsolete normative reference: RFC 2234 (ref. '4') (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 4, 2004 December 5, 2003 6 Internet Message Access Protocol (IMAP) CATENATE Extension 7 draft-ietf-lemonade-catenate-00 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 4, 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 and message 54 part identifiers from the currently selected mailbox. The server 55 takes all of the pieces and catenates them into the output message. 57 There are some obvious uses for the CATENATE command. The motivating 58 use case for this command was to provide a way for a 59 resource-constrained client to compose a message for future delivery 60 which contains data that already exists in that client's IMAP [1] 61 store. Because the client does not have to download and re-upload 62 potentially large message parts, bandwidth and processing limitations 63 do not have as much impact. (Mechanisms for sending the message are 64 outside of the scope of this document.) 66 CATENATE can also be used to copy parts of a message to another 67 mailbox for archival purposes while getting rid of undesired parts. 68 In environments where server storage is limited, a client could get 69 rid of large message parts by copying over only the necessary parts 70 and then deleting the original message. CATENATE could also be used 71 to add data to a message such as prepending message header fields or 72 including other data by making a copy of the original and catenating 73 the new data. 75 2. The CATENATE Capability 77 A server which supports this extension returns "CATENATE" as one of 78 the responses to the CAPABILITY command. 80 3. The CATENATE command 82 Arguments: mailbox name 84 OPTIONAL flag parenthesized list 86 OPTIONAL date/time string 88 one or more message parts to catenate, specified as: 90 message literal 92 or 94 sequence number 96 body section specifier 98 OPTIONAL substring specifier 100 Responses: no specific responses for this command 102 Result: 104 OK - catenate completed 106 NO - catenate error: can't append to that mailbox, 107 error in flags or date/time or message text, or 108 can't fetch that data 110 BAD - command unknown or arguments invalid 112 The CATENATE command concatenates all of the message parts and 113 appends them as a new message to the end of the specified mailbox. 114 The optional flag parenthesized list and date/time string are used 115 just as they are in the APPEND command, setting the flags and the 116 internal date, respectively. The subsequent parameters specify the 117 message parts that are appended sequentially to the output message. 119 If a message literal is specified (indicated by the octet count 120 enclosed in braces), the octets following the count are appended just 121 as they would be with the APPEND command. If a message body part is 122 specified (indicated by the sequence number), the octets of that body 123 part (or the partial body part if a substring range is specified) are 124 appended, as if the literal returned in a FETCH BODY response were 125 put in place of the message part specifier. 127 The client is responsible for making sure that the catenated message 128 is in the format of an RFC 2822 [2] message. This includes inserting 129 appropriate MIME boundaries between body parts if necessary. 131 Responses behave just as the APPEND command. If the server implements 132 the IMAP UIDPLUS extension [3], it will also return an APPENDUID 133 response code in the tagged OK response. 135 The CATENATE command is valid in the selected state. 137 4. The UID CATENATE command 139 Arguments: mailbox name 141 OPTIONAL flag parenthesized list 143 OPTIONAL date/time string 145 one or more message parts to catenate, specified as: 147 message literal 149 or 151 unique identifier 153 body section specifier 155 OPTIONAL substring specifier 157 Responses: no specific responses for this command 159 Result: 161 OK - catenate completed 163 NO - catenate error: can't append to that mailbox, 164 error in flags or date/time or message text, or 165 can't fetch that data 167 BAD - command unknown or arguments invalid 169 The UID CATENATE command is identical to the CATENATE command except 170 that instead of taking message sequence numbers as arguments, it 171 takes unique identifiers. The message parts are catenated and 172 appended just as the CATENATE command. 174 5. Formal Syntax 176 The following syntax specification uses the Augmented Backus-Naur 177 Form (ABNF) [4] notation. Any elements not specified in ABNF [4] 178 appear in the formal syntax of IMAP [1]. 180 partial = "<" number "." nz-number ">" 182 catenate = "CATENATE" SP mailbox [SP flag-list] [SP date-time] SP 183 1*(literal / (seq-number section [partial])) 185 uidcatenate = "UID" SP catenate 187 6. Security Considerations 189 The CATENATE extension does not raise any security considerations 190 that are not present in the base protocol, and these issues are 191 discussed in IMAP [1]. 193 Normative References 195 [1] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 196 RFC 3501, March 2003. 198 [2] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 200 [3] Myers, J., "IMAP4 UIDPLUS Extension", RFC 2359, June 1998. 202 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 203 Specifications: ABNF", RFC 2234, November 1997. 205 Author's Address 207 Peter W. Resnick 208 QUALCOMM Incorporated 209 5775 Morehouse Drive 210 San Diego, CA 92121-1714 211 US 213 Phone: +1 858 651 4478 214 EMail: presnick@qualcomm.com 215 URI: http://www.qualcomm.com/~presnick/ 217 Intellectual Property Statement 219 The IETF takes no position regarding the validity or scope of any 220 intellectual property or other rights that might be claimed to 221 pertain to the implementation or use of the technology described in 222 this document or the extent to which any license under such rights 223 might or might not be available; neither does it represent that it 224 has made any effort to identify any such rights. Information on the 225 IETF's procedures with respect to rights in standards-track and 226 standards-related documentation can be found in BCP-11. Copies of 227 claims of rights made available for publication and any assurances of 228 licenses to be made available, or the result of an attempt made to 229 obtain a general license or permission for the use of such 230 proprietary rights by implementors or users of this specification can 231 be obtained from the IETF Secretariat. 233 The IETF invites any interested party to bring to its attention any 234 copyrights, patents or patent applications, or other proprietary 235 rights which may cover technology that may be required to practice 236 this standard. Please address the information to the IETF Executive 237 Director. 239 Full Copyright Statement 241 Copyright (C) The Internet Society (2003). All Rights Reserved. 243 This document and translations of it may be copied and furnished to 244 others, and derivative works that comment on or otherwise explain it 245 or assist in its implementation may be prepared, copied, published 246 and distributed, in whole or in part, without restriction of any 247 kind, provided that the above copyright notice and this paragraph are 248 included on all such copies and derivative works. However, this 249 document itself may not be modified in any way, such as by removing 250 the copyright notice or references to the Internet Society or other 251 Internet organizations, except as needed for the purpose of 252 developing Internet standards in which case the procedures for 253 copyrights defined in the Internet Standards process must be 254 followed, or as required to translate it into languages other than 255 English. 257 The limited permissions granted above are perpetual and will not be 258 revoked by the Internet Society or its successors or assignees. 260 This document and the information contained herein is provided on an 261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 Acknowledgment 269 Funding for the RFC Editor function is currently provided by the 270 Internet Society.