idnits 2.17.1 draft-ietf-lemonade-catenate-04.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 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. ** 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 8 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 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 (February 16, 2005) is 7010 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) Summary: 12 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: August 20, 2005 February 16, 2005 6 Internet Message Access Protocol (IMAP) CATENATE Extension 7 draft-ietf-lemonade-catenate-04 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 August 20, 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 modifies the APPEND command to allow clients to create messages on 44 the IMAP server which may contain a combination of new data along 45 with 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 modifies 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 the 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 new APPEND command can also be used to copy parts of a message to 78 another mailbox for archival purposes while getting rid of undesired 79 parts. In environments where server storage is limited, a client 80 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 old 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 new form is used, the token "CATENATE" 122 and a parenthesized list of message literals and message URLs 123 follows, each of which are appended to the new message. If a message 124 literal is specified (indicated by the "TEXT"), the octets following 125 the count are appended. If a message URL is specified (indicated by 126 "URL"), the octets of the body part pointed to by that URL are 127 appended, as if the literal returned in a FETCH BODY response were 128 put in place of the message part specifier. The APPEND command does 129 not cause the \Seen flag to be set for any catenated body part. 131 Note: This document only describes the behavior of the APPEND 132 command using message URLs (as defined by [2]) which refer to 133 specific messages or message parts on the current IMAP server. 134 Use of a URL that refers to anything other than a message or 135 message part on the current IMAP server is outside of the scope of 136 this document, would require an extension to this specification, 137 and a server implementing only this specification would return NO 138 to such a request. 140 The client is responsible for making sure that the catenated message 141 is in the format of an RFC 2822 [4] message. This includes inserting 142 appropriate MIME [5] boundaries between body parts if necessary. 144 Responses behave just as the APPEND command described in IMAP [1]. 145 If the server implements the IMAP UIDPLUS extension [6], it will also 146 return an APPENDUID response code in the tagged OK response. Two 147 response codes are provided in section 4 which can be used in the 148 tagged NO response if the APPEND command fails. 150 4. Response Codes 152 When a APPEND command fails it may return a response code that 153 describes a reason for the failure. 155 4.1 BADURL Response 157 The BADURL response code is returned if the APPEND fails to process 158 one of the specified URLs. Possible reasons for this are bad url 159 syntax, unrecognized URL schema, invalid message UID, invalid body 160 part. The BADURL response code contains the first URL specified as a 161 parameter to the APPEND command that has caused the operation to 162 fail. 164 4.2 TOOBIG Response 166 The TOOBIG response code is returned if the resulting message will 167 exceed the 4Gb IMAP message limit. This might happen, for example, 168 if the client specifies 3 URLs for 2Gb messages. Note, that even if 169 the server doesn't return TOOBIG, it still has to be defensive 170 against misbehaving or malicious clients that try to construct a 171 message over 4Gb limit. The server may also wish to return the 172 TOOBIG response code if the resulting message exceeds the server 173 specific message size limit. 175 5. Formal Syntax 177 The following syntax specification uses the Augmented Backus-Naur 178 Form (ABNF) [7] notation. Elements not defined here can be found in 179 the formal syntax of the ABNF [7] and IMAP [1] specifications. Note 180 that resp-text-code is extended from original IMAP [1] specification. 182 append = "APPEND" SP mailbox 1*append-message 183 ; only a single append-message may appear 184 ; if MULTIAPPEND capability is not present 186 append-message = append-opts SP (literal / append-catenate) 188 append-opts = [SP flag-list] [SP date-time] 190 append-catenate = "CATENATE" SP "(" catenate-parts ")" 192 catenate-parts = (text-literal / url) *(SP (text-literal / url)) 194 text-literal = "TEXT" SP literal 196 url = "URL" SP astring 198 badurl_response_code = "BADURL" SP url-resp-text 200 url-resp-text = 1*(%x01-09 / 201 %x0B-0C / 202 %x0E-5B / 203 %x5D-FE) ; Any TEXT-CHAR except "]" 205 toobig_response_code = "TOOBIG" 207 resp-text-code =/ badurl_response_code / toobig_response_code 209 The astring in the definition of url and the url-resp-text in the 210 definition of badurl_response_code each contain an imapurl as defined 211 by [2]. 213 6. Acknowledgments 215 Thanks to the members of the LEMONADE working group for their input. 216 Special thanks to Alexey Melnikov for the Examples. 218 7. Security Considerations 220 The CATENATE extension does not raise any security considerations 221 that are not present for the base protocol or in the use of IMAP 222 URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] 223 documents. 225 8. IANA Considerations 227 IMAP4 capabilities are registered by publishing a standards track or 228 IESG approved experimental RFC. The registry is currently located at 229 . This document 230 defines the CATENATE IMAP capability. IANA is requested to add this 231 capability to the registry. 233 Appendix A. Examples 235 Lines not starting with "C: " or "S: " are continuations of the 236 previous lines. 238 The original message in examples 1 and 2 below (UID = 20) has the 239 following structure: 240 multipart/mixed MIME message with two body parts: 241 1. text/plain 242 2. application/x-zip-compressed 244 Example 1: The following example demonstrates how a CATENATE client 245 can replace an attachment in a draft message, without the need to 246 download it to the client and upload it back. 248 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE 249 (URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 250 UID=20;section=HEADER" TEXT {40} 251 S: + Ready for literal data 252 C: --------------030308070208000400050907 253 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 254 UID=20;section=1.MIME" URL "imap://imap.example.org/Drafts; 255 UIDVALIDITY=385759045/;UID=20;section=1" TEXT {40} 256 S: + Ready for literal data 257 C: --------------030308070208000400050907 258 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 259 UID=30" {44} 260 S: + Ready for literal data 261 C: --------------030308070208000400050907-- 262 C: ) 263 S: A003 OK catenate append completed 264 Example 2: The following example demonstrates how the CATENATE 265 extension can be used to replace edited text in a draft message, as 266 well as header fields for the top level message part (e.g. Subject 267 has changed). The previous version of the draft is marked as 268 \Deleted. Note, that the server also supports the UIDPLUS extension, 269 so the APPENDUID response code is returned in the successful OK 270 response to the APPEND command. 272 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738} 273 S: + Ready for literal data 274 C: Return-Path: 275 C: Received: from [127.0.0.2] 276 C: by rufus.example.org via TCP (internal) with ESMTPA; 277 C: Thu, 11 Nov 2004 16:57:07 +0000 278 C: Message-ID: <419399E1.6000505@example.org> 279 C: Date: Thu, 12 Nov 2004 16:57:05 +0000 280 C: From: Bob Ar 281 C: X-Accept-Language: en-us, en 282 C: MIME-Version: 1.0 283 C: To: foo@example.net 284 C: Subject: About our holiday trip 285 C: Content-Type: multipart/mixed; 286 C: boundary="------------030308070208000400050907" 287 C: 288 C: --------------030308070208000400050907 289 C: Content-Type: text/plain; charset=us-ascii; format=flowed 290 C: Content-Transfer-Encoding: 7bit 291 C: 292 C: Our travel agent has sent the updated schedule. 293 C: 294 C: Cheers, 295 C: Bob 296 C: --------------030308070208000400050907 297 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 298 UID=20;Section=2.MIME" URL "imap://imap.example.org/Drafts; 299 UIDVALIDITY=385759045/;UID=20;Section=2" TEXT {44} 300 S: + Ready for literal data 301 C: --------------030308070208000400050907-- 302 C: ) 303 S: A003 OK [APPENDUID 385759045 45] append Completed 304 C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted) 305 S: A004 OK STORE completed 306 Example 3: The following example demonstrates how the CATENATE 307 extension can be used to strip attachments. Below a PowerPoint 308 attachment was replaced by a small text part explaining that the 309 attachment was stripped. 311 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE 312 (URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 313 UID=21;section=HEADER" TEXT {40} 314 S: + Ready for literal data 315 C: --------------030308070208000400050903 316 C: URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/; 317 UID=21;section=1.MIME" URL "imap://imap.example.org/Drafts; 318 UIDVALIDITY=385759045/;UID=21;section=1" TEXT {255} 319 S: + Ready for literal data 320 C: --------------030308070208000400050903 321 C: Content-type: text/plain; charset="us-ascii" 322 C: Content-transfer-encoding: 7bit 323 C: 324 C: This bodypart contained a Power Point presentation, that was 325 C: deleted upon your request. 326 C: --------------030308070208000400050903-- 327 C: ) 328 S: A003 OK append Completed 329 Example 4: The following example demonstrates a failed APPEND 330 command. The server returns the BADURL response code to indicate 331 that one of the provided URLs is invalid. This example also 332 demonstrates how the CATENATE extension can be used to construct a 333 digest of several messages. 335 C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541} 336 S: + Ready for literal data 337 C: Return-Path: 338 C: Received: from [127.0.0.2] 339 C: by rufus.example.org via TCP (internal) with ESMTPA; 340 C: Thu, 11 Nov 2004 16:57:07 +0000 341 C: Message-ID: <419399E1.6000505@example.org> 342 C: Date: Thu, 21 Nov 2004 16:57:05 +0000 343 C: From: Farren Oo 344 C: X-Accept-Language: en-us, en 345 C: MIME-Version: 1.0 346 C: To: bar@example.org 347 C: Subject: Digest of the mailing list for today 348 C: Content-Type: multipart/digest; 349 C: boundary="------------030308070208000400050904" 350 C: 351 C: --------------030308070208000400050904 352 C: URL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/; 353 UID=11467" TEXT {40} 354 S: + Ready for literal data 355 C: --------------030308070208000400050904 356 C: URL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/; 357 UID=113330;section=1.5.9" TEXT {40} 358 S: + Ready for literal data 359 C: --------------030308070208000400050904 360 C: URL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/; 361 UID=11916" TEXT {44} 362 S: + Ready for literal data 363 C: --------------030308070208000400050904-- 364 C: ) 365 S: A003 NO [BADURL "imap://imap.example.org/INBOX;UIDVALIDITY=785799047/ 366 ;UID=113330;section=1.5.9"] CATENATE append has failed, one message expunged 368 9. Normative References 370 [1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 371 RFC 3501, March 2003. 373 [2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 375 [3] Crispin, M., "Internet Message Access Protocol (IMAP) - 376 MULTIAPPEND Extension", RFC 3502, March 2003. 378 [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 380 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 381 Extensions (MIME) Part One: Format of Internet Message Bodies", 382 RFC 2045, November 1996. 384 [6] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998. 386 [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 387 Specifications: ABNF", RFC 2234, November 1997. 389 Author's Address 391 Peter W. Resnick 392 QUALCOMM Incorporated 393 5775 Morehouse Drive 394 San Diego, CA 92121-1714 395 US 397 Phone: +1 858 651 4478 398 Email: presnick@qualcomm.com 399 URI: http://www.qualcomm.com/~presnick/ 401 Intellectual Property Statement 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Disclaimer of Validity 427 This document and the information contained herein are provided on an 428 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 429 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 430 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 431 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 432 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 433 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 Copyright Statement 437 Copyright (C) The Internet Society (2005). This document is subject 438 to the rights, licenses and restrictions contained in BCP 78, and 439 except as set forth therein, the authors retain all their rights. 441 Acknowledgment 443 Funding for the RFC Editor function is currently provided by the 444 Internet Society.