idnits 2.17.1 draft-ietf-lemonade-catenate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 11, 2004) is 7076 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: 11 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 11, 2005 December 11, 2004 6 Internet Message Access Protocol (IMAP) CATENATE Extension 7 draft-ietf-lemonade-catenate-03 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 11, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The CATENATE extension to the Internet Message Access Protocol (IMAP) 43 allows clients to create messages on the IMAP server which may 44 contain a combination of new data along with parts of (or entire) 45 messages already on the server. Using this extension, the client can 46 catenate parts of an already existing message on to a new message 47 without having to first download the data and then upload it back to 48 the server. 50 1. Introduction 52 The CATENATE extension to the Internet Message Access Protocol (IMAP) 53 [1] allows the client to create a message on the server which can 54 include the text of messages (or parts of messages) that already 55 exist on the server without having to FETCH them and APPEND them back 56 to the server. The CATENATE command works much like the APPEND 57 command except that, instead of a single message literal, the command 58 can take as arguments any combination of message literals (as 59 described in IMAP [1]) and message URLs (as described in the IMAP URL 60 Scheme [2] specification). The server takes all of the pieces and 61 catenates them into the output message. 63 There are some obvious uses for the CATENATE command. The motivating 64 use case for this command was to provide a way for a 65 resource-constrained client to compose a message for subsequent 66 submission which contains data that already exists in that client's 67 IMAP store. Because the client does not have to download and 68 re-upload potentially large message parts, bandwidth and processing 69 limitations do not have as much impact. In addition, since CATENATE 70 creates the message in the client's IMAP store, the command also 71 addresses the desire of the client to archive a copy of a sent 72 message without having to upload the message twice. (Mechanisms for 73 sending the message are outside of the scope of this document.) 75 CATENATE can also be used to copy parts of a message to another 76 mailbox for archival purposes while getting rid of undesired parts. 77 In environments where server storage is limited, a client could get 78 rid of large message parts by copying over only the necessary parts 79 and then deleting the original message. CATENATE could also be used 80 to add data to a message such as prepending message header fields or 81 including other data by making a copy of the original and catenating 82 the new data. 84 2. The CATENATE Capability 86 A server which supports this extension returns "CATENATE" as one of 87 the responses to the CAPABILITY command. 89 3. The CATENATE command 91 Arguments: mailbox name 92 message parameter list or NIL 93 one or more message parts to catenate, specified as: 94 message literal 95 or 96 message (or message part) URL 98 Responses: no specific responses for this command 100 Result: 101 OK - catenate completed 102 NO - catenate error: can't append to that mailbox, error in flags 103 or date/time or message text, or can't fetch that data 104 BAD - command unknown or arguments invalid 106 The CATENATE command concatenates all of the message parts and 107 appends them as a new message to the end of the specified mailbox. 108 The message parameters defined in this document for the message 109 parameter list are a parenthesized flag list (indicated by "FLAGS") 110 and date/time string (indicated by "DATE") that are used just as they 111 are in the APPEND command, setting the flags and the internal date, 112 respectively. The subsequent command parameters specify the message 113 parts that are appended sequentially to the output message. 115 If a message literal is specified (indicated by the "TEXT"), the 116 octets following the count are appended just as they would be with 117 the APPEND command. If a message URL is specified (indicated by 118 "URL"), the octets of the body part pointed to by that URL are 119 appended, as if the literal returned in a FETCH BODY response were 120 put in place of the message part specifier. The CATENATE command 121 does not cause the \Seen flag to be set for any catenated body part. 123 Note: This document only describes the behavior of the CATENATE 124 command using a message URL (as defined by [2]) which refers to a 125 specific message or message part in the currently selected mailbox 126 on the current IMAP server. (Because of that, the CATENATE 127 command is valid in the selected state for purposes of this 128 specification.) Use of a URL that refers to anything other than a 129 message or message part from the currently selected mailbox on the 130 current IMAP server is outside of the scope of this document, 131 would require an extension to this specification, and a server 132 implementing only this specification would return NO to such a 133 request. 135 The client is responsible for making sure that the catenated message 136 is in the format of an RFC 2822 [3] message. This includes inserting 137 appropriate MIME [4] boundaries between body parts if necessary. 139 Responses behave just as the APPEND command. If the server 140 implements the IMAP UIDPLUS extension [5], it will also return an 141 APPENDUID response code in the tagged OK response. Two response 142 codes are provided in section 4 which can be used in the tagged NO 143 response if the CATENATE command fails. 145 4. Response Codes 147 When a CATENATE command fails it may return a response code that 148 describes a reason for the failure. 150 4.1 BADURL Response 152 The BADURL response code is returned if the CATENATE fails to process 153 one of the specified URLs. Possible reasons for this are bad url 154 syntax, unrecognized URL schema, invalid message UID, invalid body 155 part. The BADURL response code contains the first URL specified as a 156 parameter to the CATENATE command that has caused the operation to 157 fail. 159 4.2 TOOBIG Response 161 The TOOBIG response code is returned if the resulting message will 162 exceed the 4Gb IMAP message limit. This might happen, for example, 163 if the client specifies 3 URLs for 2Gb messages. Note, that even if 164 the server doesn't return TOOBIG, it still has to be defensive 165 against misbehaving or malicious clients that try to construct a 166 message over 4Gb limit. The server may also wish to return the 167 TOOBIG response code if the resulting message exceeds the server 168 specific message size limit. 170 5. Formal Syntax 172 The following syntax specification uses the Augmented Backus-Naur 173 Form (ABNF) [6] notation. Elements not defined here can be found in 174 the formal syntax of the ABNF [6] and IMAP [1] specifications. Note 175 that resp-text-code is extended from original IMAP [1] specification. 177 catenate = "CATENATE" SP mailbox SP parameters 178 1*(SP (text-literal / url)) 180 parameters = ("(" parameter *(SP parameter) ")") / "NIL" 182 parameter = ("FLAGS" SP flag-list) / ("DATE" SP date-time) 184 text-literal = "TEXT" SP literal 186 url = "URL" SP astring 188 badurl_response_code = "BADURL" SP url-text 190 url-resp-text= 1*(%x01-09 / %x0B-0C / %x0E-5B / %x5D-FE) 191 ; Any TEXT-CHAR except "]" 193 toobig_response_code = "TOOBIG" 195 resp-text-code =/ badurl_response_code / toobig_response_code 197 The astring in the definition of url and the url-text in the 198 definition of badurl_response_code contain an imapurl as defined by 199 [2]. 201 6. Acknowledgments 203 Thanks to Alexey Melnikov for the Examples. Thanks to all of the 204 LEMONADE working group for their input. 206 7. Security Considerations 208 The CATENATE extension does not raise any security considerations 209 that are not present for the base protocol or in the use of IMAP 210 URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] 211 documents. 213 8. IANA Considerations 215 IMAP4 capabilities are registered by publishing a standards track or 216 IESG approved experimental RFC. The registry is currently located at 217 . This document 218 defines the CATENATE IMAP capability. IANA is requested to add this 219 capability to the registry. 221 Appendix A. Examples 223 Lines not starting with "C: " or "S: " are continuations of the 224 previous lines. 226 The original message in examples 1 and 2 below (UID = 20) has the 227 following structure: 228 multipart/mixed MIME message with two body parts: 229 1. text/plain 230 2. application/x-zip-compressed 232 Example 1: The following example demonstrates how a CATENATE client 233 can replace an attachment in a draft message, without the need to 234 download it to the client and upload it back. 236 C: A003 CATENATE Drafts FLAGS (\Seen \Draft $MDNSent) 237 URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 238 UID=20;section=HEADER" TEXT {40} 239 S: + Ready for literal data 240 C: --------------030308070208000400050907 241 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 242 UID=20;section=1.1" TEXT {40} 243 S: + Ready for literal data 244 C: --------------030308070208000400050907 245 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 246 UID=30" {44} 247 S: + Ready for literal data 248 C: --------------030308070208000400050907-- 249 C: 250 S: A003 OK CATENATE Completed 251 Example 2: The following example demonstrates how CATENATE can be 252 used to replace edited text in a draft message, as well as header 253 fields for the top level message part (e.g. Subject has changed). 254 The previous version of the draft is marked as \Deleted. Note, that 255 the server also supports the UIDPLUS extension, so the APPENDUID 256 response code is returned in the successful OK response to the 257 CATENATE command. 259 C: A003 CATENATE Drafts FLAGS (\Seen \Draft $MDNSent) TEXT {738} 260 S: + Ready for literal data 261 C: Return-Path: 262 C: Received: from [127.0.0.2] 263 C: by rufus.example.org via TCP (internal) with ESMTPA; 264 C: Thu, 11 Nov 2004 16:57:07 +0000 265 C: Message-ID: <419399E1.6000505@example.org> 266 C: Date: Thu, 12 Nov 2004 16:57:05 +0000 267 C: From: Bob Ar 268 C: X-Accept-Language: en-us, en 269 C: MIME-Version: 1.0 270 C: To: foo@example.net 271 C: Subject: About our holiday trip 272 C: Content-Type: multipart/mixed; 273 C: boundary="------------030308070208000400050907" 274 C: 275 C: --------------030308070208000400050907 276 C: Content-Type: text/plain; charset=us-ascii; format=flowed 277 C: Content-Transfer-Encoding: 7bit 278 C: 279 C: Our travel agent has sent the updated schedule. 280 C: 281 C: Cheers, 282 C: Bob 283 C: --------------030308070208000400050907 284 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 285 UID=20;Section=1.2" TEXT {44} 286 S: + Ready for literal data 287 C: --------------030308070208000400050907-- 288 C: 289 S: A003 OK [APPENDUID 385759045 45] CATENATE Completed 290 C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) 291 S: A004 OK STORE completed 292 Example 3: The following example demonstrates how CATENATE can be 293 used to strip attachments. Below a PowerPoint attachment was 294 replaced by a small text part explaining that the attachment was 295 stripped. 297 C: A003 CATENATE Drafts FLAGS (\Seen \Draft $MDNSent) 298 URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 299 UID=21;section=HEADER" TEXT {40} 300 S: + Ready for literal data 301 C: --------------030308070208000400050903 302 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 303 UID=21;section=1.1" TEXT {255} 304 S: + Ready for literal data 305 C: --------------030308070208000400050903 306 C: Content-type: text/plain; charset="us-ascii" 307 C: Content-transfer-encoding: 7bit 308 C: 309 C: This bodypart contained a Power Point presentation, that was 310 C: deleted upon your request. 311 C: --------------030308070208000400050903-- 312 C: 313 S: A003 OK CATENATE Completed 314 Example 4: The following example demonstrates a failed CATENATE 315 command. The server returns the BADURL response code to indicate 316 that one of the provided URLs is invalid. This example also 317 demonstrates how CATENATE can be used to construct a digest of 318 several messages. 320 C: A003 CATENATE Sent FLAGS (\Seen $MDNSent) TEXT {541} 321 S: + Ready for literal data 322 C: Return-Path: 323 C: Received: from [127.0.0.2] 324 C: by rufus.example.org via TCP (internal) with ESMTPA; 325 C: Thu, 11 Nov 2004 16:57:07 +0000 326 C: Message-ID: <419399E1.6000505@example.org> 327 C: Date: Thu, 21 Nov 2004 16:57:05 +0000 328 C: From: Farren Oo 329 C: X-Accept-Language: en-us, en 330 C: MIME-Version: 1.0 331 C: To: bar@example.org 332 C: Subject: Digest of the mailing list for today 333 C: Content-Type: multipart/digest; 334 C: boundary="------------030308070208000400050904" 335 C: 336 C: --------------030308070208000400050904 337 C: URL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/; 338 UID=11467" TEXT {40} 339 S: + Ready for literal data 340 C: --------------030308070208000400050904 341 C: URL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/; 342 UID=113330;section=1.5.9" TEXT {40} 343 S: + Ready for literal data 344 C: --------------030308070208000400050904 345 C: URL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/; 346 UID=11916" TEXT {44} 347 S: + Ready for literal data 348 C: --------------030308070208000400050904-- 349 C: 350 S: A003 NO [BADURL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/ 351 ;UID=113330;section=1.5.9"] CATENATE has failed, one message expunged 353 9 Normative References 355 [1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 356 RFC 3501, March 2003. 358 [2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 360 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 362 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 363 Extensions (MIME) Part One: Format of Internet Message Bodies", 364 RFC 2045, November 1996. 366 [5] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998. 368 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 369 Specifications: ABNF", RFC 2234, November 1997. 371 Author's Address 373 Peter W. Resnick 374 QUALCOMM Incorporated 375 5775 Morehouse Drive 376 San Diego, CA 92121-1714 377 US 379 Phone: +1 858 651 4478 380 EMail: presnick@qualcomm.com 381 URI: http://www.qualcomm.com/~presnick/ 383 Intellectual Property Statement 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org. 407 Disclaimer of Validity 409 This document and the information contained herein are provided on an 410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 412 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 413 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 414 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 417 Copyright Statement 419 Copyright (C) The Internet Society (2004). This document is subject 420 to the rights, licenses and restrictions contained in BCP 78, and 421 except as set forth therein, the authors retain all their rights. 423 Acknowledgment 425 Funding for the RFC Editor function is currently provided by the 426 Internet Society.