idnits 2.17.1 draft-ietf-lemonade-catenate-05.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 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. ** 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 : ---------------------------------------------------------------------------- ** 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 96: '... OPTIONAL flag parenth...' RFC 2119 keyword, line 97: '... OPTIONAL date/time st...' RFC 2119 keyword, line 104: '... Responses: OPTIONAL NO responses: B...' 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 (March 14, 2005) is 6981 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. '4') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2359 (ref. '6') (Obsoleted by RFC 4315) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) == Outdated reference: A later version (-08) exists of draft-melnikov-imap-ext-abnf-00 Summary: 11 errors (**), 0 flaws (~~), 3 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: September 15, 2005 March 14, 2005 6 Internet Message Access Protocol (IMAP) CATENATE Extension 7 draft-ietf-lemonade-catenate-05 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 September 15, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The CATENATE extension to the Internet Message Access Protocol (IMAP) 43 extends the APPEND command to allow clients to create messages on the 44 IMAP server which may contain a combination of new data along with 45 parts of (or entire) messages already on the server. Using this 46 extension, the client can catenate parts of an already existing 47 message on to a new message without having to first download the data 48 and then upload it back to 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 extension extends the APPEND command so 57 that, instead of a single message literal, the command can take as 58 arguments any combination of message literals (as described in IMAP 59 [1]) and message URLs (as described in the IMAP URL Scheme [2] 60 specification). The server takes all of the pieces and catenates 61 them into the output message. The CATENATE extension can also 62 co-exist with the MULTIAPPEND extension [3] to APPEND multiple 63 messages in a single command. 65 There are some obvious uses for the CATENATE extension. The 66 motivating use case was to provide a way for a resource-constrained 67 client to compose a message for subsequent submission which contains 68 data that already exists in that client's IMAP store. Because the 69 client does not have to download and re-upload potentially large 70 message parts, bandwidth and processing limitations do not have as 71 much impact. In addition, since the client can create a message in 72 its own IMAP store, the command also addresses the desire of the 73 client to archive a copy of a sent message without having to upload 74 the message twice. (Mechanisms for sending the message are outside 75 of the scope of this document.) 77 The extended APPEND command can also be used to copy parts of a 78 message to another mailbox for archival purposes while getting rid of 79 undesired parts. In environments where server storage is limited, a 80 client could get rid of large message parts by copying over only the 81 necessary parts and then deleting the original message. The 82 mechanism could also be used to add data to a message such as 83 prepending message header fields or including other data by making a 84 copy of the original and catenating the new data. 86 2. The CATENATE Capability 88 A server which supports this extension returns "CATENATE" as one of 89 the responses to the CAPABILITY command. 91 3. The APPEND command 93 Arguments: mailbox name 94 (The following can be repeated in the presence of the 95 MULTIAPPEND extension [3]) 96 OPTIONAL flag parenthesized list 97 OPTIONAL date/time string 98 a single message literal or one or more message parts 99 to catenate, specified as: 100 message literal 101 or 102 message (or message part) URL 104 Responses: OPTIONAL NO responses: BADURL, TOOBIG 106 Result: 107 OK - append completed 108 NO - append error: can't append to that mailbox, error in flags 109 or date/time or message text, or can't fetch that data 110 BAD - command unknown or arguments invalid 112 The APPEND command concatenates all of the message parts and appends 113 them as a new message to the end of the specified mailbox. The 114 parenthesized flag list and date/time string set the flags and the 115 internal date, respectively, as described in IMAP [1]. The 116 subsequent command parameters specify the message parts that are 117 appended sequentially to the output message. 119 If the original form of APPEND is used, a message literal follows the 120 optional flag list and date/time string which is appended as 121 described in IMAP [1]. If the extended form is used, "CATENATE" and 122 a parenthesized list of message literals and message URLs follows, 123 each of which are appended to the new message. If a message literal 124 is specified (indicated by "TEXT"), the octets following the count 125 are appended. If a message URL is specified (indicated by "URL"), 126 the octets of the body part pointed to by that URL are appended, as 127 if the literal returned in a FETCH BODY response were put in place of 128 the message part specifier. The APPEND command does not cause the 129 \Seen flag to be set for any catenated body part. The APPEND command 130 does not change the selected mailbox. 132 In the extended APPEND command, the string following "URL" is an IMAP 133 URL [2] and is interpreted according to the rules of [2]. The 134 present document only describes the behavior of the command using 135 IMAP URLs which refer to specific messages or message parts on the 136 current IMAP server from the current authenticated IMAP session. 137 Because of that, only relative (i.e., having no scheme or ) 138 IMAP message or message part URLs are used. The base URL for 139 evaluating the relative URL is considered "imap://user@server/", 140 where "user" is the user name of the currently authenticated user, 141 and "server" is the domain name of the current server. When in the 142 selected state, the base URL is considered 143 "imap://user@server/mailbox", where "mailbox" is the encoded name of 144 the currently selected mailbox. Additionally, since the APPEND 145 command is valid in the authenticated state of an IMAP session, no 146 further LOGIN or AUTHENTICATE command is performed for URLs specified 147 in the extended APPEND command. 149 Note: Use of an absolute IMAP URL or any URL that refers to 150 anything other than a message or message part from the current 151 authenticated IMAP session is outside of the scope of this 152 document, would require an extension to this specification, and a 153 server implementing only this specification would return NO to 154 such a request. 156 The client is responsible for making sure that the catenated message 157 is in the format of an Internet Message Format (RFC 2822) [4] or 158 Multipurpose Internet Mail Extension (MIME) [5] message. In 159 particular, when a URL is catenated, the server copies octets, 160 unchanged, from the indicated message or message part to the 161 catenated message. It does no data conversion (e.g. MIME transfer 162 encodings); nor any verification that the data is appropriate for the 163 MIME part of the message into which it is inserted. The client is 164 also responsible for inserting appropriate MIME boundaries between 165 body parts, and writing MIME Content-Type and 166 Content-Transfer-Encoding lines as needed in the appropriate places. 168 Responses behave just as the original APPEND command described in 169 IMAP [1]. If the server implements the IMAP UIDPLUS extension [6], 170 it will also return an APPENDUID response code in the tagged OK 171 response. Two response codes are provided in section 4 which can be 172 used in the tagged NO response if the APPEND command fails. 174 4. Response Codes 176 When a APPEND command fails it may return a response code that 177 describes a reason for the failure. 179 4.1 BADURL Response 181 The BADURL response code is returned if the APPEND fails to process 182 one of the specified URLs. Possible reasons for this are bad URL 183 syntax, unrecognized URL schema, invalid message UID, or invalid body 184 part. The BADURL response code contains the first URL specified as a 185 parameter to the APPEND command that has caused the operation to 186 fail. 188 4.2 TOOBIG Response 190 The TOOBIG response code is returned if the resulting message will 191 exceed the 4GB IMAP message limit. This might happen, for example, 192 if the client specifies 3 URLs for 2GB messages. Note, that even if 193 the server doesn't return TOOBIG, it still has to be defensive 194 against misbehaving or malicious clients that try to construct a 195 message over the 4GB limit. The server may also wish to return the 196 TOOBIG response code if the resulting message exceeds a server 197 specific message size limit. 199 5. Formal Syntax 201 The following syntax specification uses the Augmented Backus-Naur 202 Form (ABNF) [7] notation. Elements not defined here can be found in 203 the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions 204 [8] specifications. Note that capability and resp-text-code are 205 extended from the IMAP [1] specification and append-data is extended 206 from the IMAP ABNF extensions [8] specification. 208 append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")" 210 cat-part = text-literal / url 212 text-literal = "TEXT" SP literal 214 url = "URL" SP astring 216 resp-text-code =/ toobig_response_code / badurl_response_code 218 toobig_response_code = "TOOBIG" 220 badurl_response_code = "BADURL" SP url-resp-text 222 url-resp-text = 1*(%x01-09 / 223 %x0B-0C / 224 %x0E-5B / 225 %x5D-FE) ; Any TEXT-CHAR except "]" 227 capability =/ "CATENATE" 229 The astring in the definition of url and the url-resp-text in the 230 definition of badurl_response_code each contain an imapurl as defined 231 by [2]. 233 6. Acknowledgments 235 Thanks to the members of the LEMONADE working group for their input. 236 Special thanks to Alexey Melnikov for the Examples. 238 7. Security Considerations 240 The CATENATE extension does not raise any security considerations 241 that are not present for the base protocol or in the use of IMAP 242 URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] 243 documents. 245 8. IANA Considerations 247 IMAP4 capabilities are registered by publishing a standards track or 248 IESG approved experimental RFC. The registry is currently located at 249 . This document 250 defines the CATENATE IMAP capability. IANA is requested to add this 251 capability to the registry. 253 Appendix A. Examples 255 Lines not starting with "C: " or "S: " are continuations of the 256 previous lines. 258 The original message in examples 1 and 2 below (UID = 20) has the 259 following structure: 260 multipart/mixed MIME message with two body parts: 261 1. text/plain 262 2. application/x-zip-compressed 264 Example 1: The following example demonstrates how a CATENATE client 265 can replace an attachment in a draft message, without the need to 266 download it to the client and upload it back. 268 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE 269 (URL "/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER" 270 TEXT {42} 271 S: + Ready for literal data 272 C: 273 C: --------------030308070208000400050907 274 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20;section=1.MIME" 275 URL "/Drafts;UIDVALIDITY=385759045/;UID=20;section=1" TEXT {42} 276 S: + Ready for literal data 277 C: 278 C: --------------030308070208000400050907 279 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44} 280 S: + Ready for literal data 281 C: --------------030308070208000400050907-- 282 C: ) 283 S: A003 OK catenate append completed 284 Example 2: The following example demonstrates how the CATENATE 285 extension can be used to replace edited text in a draft message, as 286 well as header fields for the top level message part (e.g. Subject 287 has changed). The previous version of the draft is marked as 288 \Deleted. Note, that the server also supports the UIDPLUS extension, 289 so the APPENDUID response code is returned in the successful OK 290 response to the APPEND command. 292 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738} 293 S: + Ready for literal data 294 C: Return-Path: 295 C: Received: from [127.0.0.2] 296 C: by rufus.example.org via TCP (internal) with ESMTPA; 297 C: Thu, 11 Nov 2004 16:57:07 +0000 298 C: Message-ID: <419399E1.6000505@example.org> 299 C: Date: Thu, 12 Nov 2004 16:57:05 +0000 300 C: From: Bob Ar 301 C: X-Accept-Language: en-us, en 302 C: MIME-Version: 1.0 303 C: To: foo@example.net 304 C: Subject: About our holiday trip 305 C: Content-Type: multipart/mixed; 306 C: boundary="------------030308070208000400050907" 307 C: 308 C: --------------030308070208000400050907 309 C: Content-Type: text/plain; charset=us-ascii; format=flowed 310 C: Content-Transfer-Encoding: 7bit 311 C: 312 C: Our travel agent has sent the updated schedule. 313 C: 314 C: Cheers, 315 C: Bob 316 C: --------------030308070208000400050907 317 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20;Section=2.MIME" 318 URL "/Drafts;UIDVALIDITY=385759045/;UID=20;Section=2" TEXT {46} 319 S: + Ready for literal data 320 C: 321 C: --------------030308070208000400050907-- 322 C: ) 323 S: A003 OK [APPENDUID 385759045 45] append Completed 324 C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) 325 S: A004 OK STORE completed 326 Example 3: The following example demonstrates how the CATENATE 327 extension can be used to strip attachments. Below a PowerPoint 328 attachment was replaced by a small text part explaining that the 329 attachment was stripped. 331 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE 332 (URL "/Drafts;UIDVALIDITY=385759045/;UID=21;section=HEADER" 333 TEXT {42} 334 S: + Ready for literal data 335 C: 336 C: --------------030308070208000400050903 337 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21;section=1.MIME" 338 URL "/Drafts;UIDVALIDITY=385759045/;UID=21;section=1" TEXT {256} 339 S: + Ready for literal data 340 C: 341 C: --------------030308070208000400050903 342 C: Content-type: text/plain; charset="us-ascii" 343 C: Content-transfer-encoding: 7bit 344 C: 345 C: This body part contained a Power Point presentation, that was 346 C: deleted upon your request. 347 C: --------------030308070208000400050903-- 348 C: ) 349 S: A003 OK append Completed 350 Example 4: The following example demonstrates a failed APPEND 351 command. The server returns the BADURL response code to indicate 352 that one of the provided URLs is invalid. This example also 353 demonstrates how the CATENATE extension can be used to construct a 354 digest of several messages. 356 C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541} 357 S: + Ready for literal data 358 C: Return-Path: 359 C: Received: from [127.0.0.2] 360 C: by rufus.example.org via TCP (internal) with ESMTPA; 361 C: Thu, 11 Nov 2004 16:57:07 +0000 362 C: Message-ID: <419399E1.6000505@example.org> 363 C: Date: Thu, 21 Nov 2004 16:57:05 +0000 364 C: From: Farren Oo 365 C: X-Accept-Language: en-us, en 366 C: MIME-Version: 1.0 367 C: To: bar@example.org 368 C: Subject: Digest of the mailing list for today 369 C: Content-Type: multipart/digest; 370 C: boundary="------------030308070208000400050904" 371 C: 372 C: --------------030308070208000400050904 373 C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42} 374 S: + Ready for literal data 375 C: 376 C: --------------030308070208000400050904 377 C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330;section=1.5.9" 378 TEXT {42} 379 S: + Ready for literal data 380 C: 381 C: --------------030308070208000400050904 382 C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {42} 383 S: + Ready for literal data 384 C: 385 C: --------------030308070208000400050904-- 386 C: ) 387 S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330; 388 section=1.5.9"] CATENATE append has failed, one message expunged 390 Note that the server could have validated the URLs as they were 391 received and therefore could have returned the tagged NO response 392 with BADURL response-code in place of any continuation request after 393 the URL was received. 395 9. Normative References 397 [1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 398 RFC 3501, March 2003. 400 [2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 402 [3] Crispin, M., "Internet Message Access Protocol (IMAP) - 403 MULTIAPPEND Extension", RFC 3502, March 2003. 405 [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 407 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 408 Extensions (MIME) Part One: Format of Internet Message Bodies", 409 RFC 2045, November 1996. 411 [6] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998. 413 [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 414 Specifications: ABNF", RFC 2234, November 1997. 416 [8] Melnikov, A., "Collected extensions to IMAP4 ABNF", 417 Internet-Draft draft-melnikov-imap-ext-abnf-00, March 2005. 419 Author's Address 421 Peter W. Resnick 422 QUALCOMM Incorporated 423 5775 Morehouse Drive 424 San Diego, CA 92121-1714 425 US 427 Phone: +1 858 651 4478 428 Email: presnick@qualcomm.com 429 URI: http://www.qualcomm.com/~presnick/ 431 Intellectual Property Statement 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at 453 ietf-ipr@ietf.org. 455 Disclaimer of Validity 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 459 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 460 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 461 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 462 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Copyright Statement 467 Copyright (C) The Internet Society (2005). This document is subject 468 to the rights, licenses and restrictions contained in BCP 78, and 469 except as set forth therein, the authors retain all their rights. 471 Acknowledgment 473 Funding for the RFC Editor function is currently provided by the 474 Internet Society.