imapext-2007

annotate docs/rfc/rfc4469.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group P. Resnick
yuuji@0 8 Request for Comments: 4469 QUALCOMM Incorporated
yuuji@0 9 Updates: 3501, 3502 April 2006
yuuji@0 10 Category: Standards Track
yuuji@0 11
yuuji@0 12
yuuji@0 13 Internet Message Access Protocol (IMAP) CATENATE Extension
yuuji@0 14
yuuji@0 15 Status of This Memo
yuuji@0 16
yuuji@0 17 This document specifies an Internet standards track protocol for the
yuuji@0 18 Internet community, and requests discussion and suggestions for
yuuji@0 19 improvements. Please refer to the current edition of the "Internet
yuuji@0 20 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 21 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 22
yuuji@0 23 Copyright Notice
yuuji@0 24
yuuji@0 25 Copyright (C) The Internet Society (2006).
yuuji@0 26
yuuji@0 27 Abstract
yuuji@0 28
yuuji@0 29 The CATENATE extension to the Internet Message Access Protocol (IMAP)
yuuji@0 30 extends the APPEND command to allow clients to create messages on the
yuuji@0 31 IMAP server that may contain a combination of new data along with
yuuji@0 32 parts of (or entire) messages already on the server. Using this
yuuji@0 33 extension, the client can catenate parts of an already existing
yuuji@0 34 message onto a new message without having to first download the data
yuuji@0 35 and then upload it back to the server.
yuuji@0 36
yuuji@0 37
yuuji@0 38
yuuji@0 39
yuuji@0 40
yuuji@0 41
yuuji@0 42
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Resnick Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 61
yuuji@0 62
yuuji@0 63 1. Introduction
yuuji@0 64
yuuji@0 65 The CATENATE extension to the Internet Message Access Protocol (IMAP)
yuuji@0 66 [1] allows the client to create a message on the server that can
yuuji@0 67 include the text of messages (or parts of messages) that already
yuuji@0 68 exist on the server without having to FETCH them and APPEND them back
yuuji@0 69 to the server. The CATENATE extension extends the APPEND command so
yuuji@0 70 that, instead of a single message literal, the command can take as
yuuji@0 71 arguments any combination of message literals (as described in IMAP
yuuji@0 72 [1]) and message URLs (as described in the IMAP URL Scheme [2]
yuuji@0 73 specification). The server takes all the pieces and catenates them
yuuji@0 74 into the output message. The CATENATE extension can also coexist
yuuji@0 75 with the MULTIAPPEND extension [3] to APPEND multiple messages in a
yuuji@0 76 single command.
yuuji@0 77
yuuji@0 78 There are some obvious uses for the CATENATE extension. The
yuuji@0 79 motivating use case was to provide a way for a resource-constrained
yuuji@0 80 client to compose a message for subsequent submission that contains
yuuji@0 81 data that already exists in that client's IMAP store. Because the
yuuji@0 82 client does not have to download and re-upload potentially large
yuuji@0 83 message parts, bandwidth and processing limitations do not have as
yuuji@0 84 much impact. In addition, since the client can create a message in
yuuji@0 85 its own IMAP store, the command also addresses the desire of the
yuuji@0 86 client to archive a copy of a sent message without having to upload
yuuji@0 87 the message twice. (Mechanisms for sending the message are outside
yuuji@0 88 the scope of this document.)
yuuji@0 89
yuuji@0 90 The extended APPEND command can also be used to copy parts of a
yuuji@0 91 message to another mailbox for archival purposes while getting rid of
yuuji@0 92 undesired parts. In environments where server storage is limited, a
yuuji@0 93 client could get rid of large message parts by copying over only the
yuuji@0 94 necessary parts and then deleting the original message. The
yuuji@0 95 mechanism could also be used to add data to a message (such as
yuuji@0 96 prepending message header fields) or to include other data by making
yuuji@0 97 a copy of the original and catenating the new data.
yuuji@0 98
yuuji@0 99 2. The CATENATE Capability
yuuji@0 100
yuuji@0 101 A server that supports this extension returns "CATENATE" as one of
yuuji@0 102 the responses to the CAPABILITY command.
yuuji@0 103
yuuji@0 104
yuuji@0 105
yuuji@0 106
yuuji@0 107
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Resnick Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 117
yuuji@0 118
yuuji@0 119 3. The APPEND Command
yuuji@0 120
yuuji@0 121 Arguments: mailbox name
yuuji@0 122 (The following can be repeated in the presence of the
yuuji@0 123 MULTIAPPEND extension [3])
yuuji@0 124 OPTIONAL flag parenthesized list
yuuji@0 125 OPTIONAL date/time string
yuuji@0 126 a single message literal or one or more message parts to
yuuji@0 127 catenate, specified as:
yuuji@0 128 message literal
yuuji@0 129 or
yuuji@0 130 message (or message part) URL
yuuji@0 131
yuuji@0 132 Responses: OPTIONAL NO responses: BADURL, TOOBIG
yuuji@0 133
yuuji@0 134 Result: OK - append completed
yuuji@0 135 NO - append error: can't append to that mailbox, error
yuuji@0 136 in flags or date/time or message text, or can't
yuuji@0 137 fetch that data
yuuji@0 138 BAD - command unknown or arguments invalid
yuuji@0 139
yuuji@0 140 The APPEND command concatenates all the message parts and appends
yuuji@0 141 them as a new message to the end of the specified mailbox. The
yuuji@0 142 parenthesized flag list and date/time string set the flags and the
yuuji@0 143 internal date, respectively, as described in IMAP [1]. The
yuuji@0 144 subsequent command parameters specify the message parts that are
yuuji@0 145 appended sequentially to the output message.
yuuji@0 146
yuuji@0 147 If the original form of APPEND is used, a message literal follows the
yuuji@0 148 optional flag list and date/time string, which is appended as
yuuji@0 149 described in IMAP [1]. If the extended form is used, "CATENATE" and
yuuji@0 150 a parenthesized list of message literals and message URLs follows,
yuuji@0 151 each of which is appended to the new message. If a message literal
yuuji@0 152 is specified (indicated by "TEXT"), the octets following the count
yuuji@0 153 are appended. If a message URL is specified (indicated by "URL"),
yuuji@0 154 the octets of the body part pointed to by that URL are appended, as
yuuji@0 155 if the literal returned in a FETCH BODY response were put in place of
yuuji@0 156 the message part specifier. The APPEND command does not cause the
yuuji@0 157 \Seen flag to be set for any catenated body part. The APPEND command
yuuji@0 158 does not change the selected mailbox.
yuuji@0 159
yuuji@0 160 In the extended APPEND command, the string following "URL" is an IMAP
yuuji@0 161 URL [2] and is interpreted according to the rules of [2]. The
yuuji@0 162 present document only describes the behavior of the command using
yuuji@0 163 IMAP URLs that refer to specific messages or message parts on the
yuuji@0 164 current IMAP server from the current authenticated IMAP session.
yuuji@0 165 Because of that, only relative IMAP message or message part URLs
yuuji@0 166 (i.e., those having no scheme or <iserver>) are used. The base URL
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Resnick Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 173
yuuji@0 174
yuuji@0 175 for evaluating the relative URL is considered "imap://user@server/",
yuuji@0 176 where "user" is the user name of the currently authenticated user and
yuuji@0 177 "server" is the domain name of the current server. When in the
yuuji@0 178 selected state, the base URL is considered
yuuji@0 179 "imap://user@server/mailbox", where "mailbox" is the encoded name of
yuuji@0 180 the currently selected mailbox. Additionally, since the APPEND
yuuji@0 181 command is valid in the authenticated state of an IMAP session, no
yuuji@0 182 further LOGIN or AUTHENTICATE command is performed for URLs specified
yuuji@0 183 in the extended APPEND command.
yuuji@0 184
yuuji@0 185 Note: Use of an absolute IMAP URL or any URL that refers to
yuuji@0 186 anything other than a message or message part from the current
yuuji@0 187 authenticated IMAP session is outside the scope of this document
yuuji@0 188 and would require an extension to this specification, and a server
yuuji@0 189 implementing only this specification would return NO to such a
yuuji@0 190 request.
yuuji@0 191
yuuji@0 192 The client is responsible for making sure that the catenated message
yuuji@0 193 is in the format of an Internet Message Format (RFC 2822) [4] or
yuuji@0 194 Multipurpose Internet Mail Extension (MIME) [5] message. In
yuuji@0 195 particular, when a URL is catenated, the server copies octets,
yuuji@0 196 unchanged, from the indicated message or message part to the
yuuji@0 197 catenated message. It does no data conversion (e.g., MIME transfer
yuuji@0 198 encodings) nor any verification that the data is appropriate for the
yuuji@0 199 MIME part of the message into which it is inserted. The client is
yuuji@0 200 also responsible for inserting appropriate MIME boundaries between
yuuji@0 201 body parts, and writing MIME Content-Type and Content-Transfer-
yuuji@0 202 Encoding lines as needed in the appropriate places.
yuuji@0 203
yuuji@0 204 Responses behave just as the original APPEND command described in
yuuji@0 205 IMAP [1]. If the server implements the IMAP UIDPLUS extension [6],
yuuji@0 206 it will also return an APPENDUID response code in the tagged OK
yuuji@0 207 response. Two response codes are provided in Section 4 that can be
yuuji@0 208 used in the tagged NO response if the APPEND command fails.
yuuji@0 209
yuuji@0 210 4. Response Codes
yuuji@0 211
yuuji@0 212 When a APPEND command fails, it may return a response code that
yuuji@0 213 describes a reason for the failure.
yuuji@0 214
yuuji@0 215 4.1. BADURL Response
yuuji@0 216
yuuji@0 217 The BADURL response code is returned if the APPEND fails to process
yuuji@0 218 one of the specified URLs. Possible reasons for this are bad URL
yuuji@0 219 syntax, unrecognized URL schema, invalid message UID, or invalid body
yuuji@0 220 part. The BADURL response code contains the first URL specified as a
yuuji@0 221 parameter to the APPEND command that has caused the operation to
yuuji@0 222 fail.
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Resnick Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 229
yuuji@0 230
yuuji@0 231 4.2. TOOBIG Response
yuuji@0 232
yuuji@0 233 The TOOBIG response code is returned if the resulting message will
yuuji@0 234 exceed the 4-GB IMAP message limit. This might happen, for example,
yuuji@0 235 if the client specifies 3 URLs for 2-GB messages. Note that even if
yuuji@0 236 the server doesn't return TOOBIG, it still has to be defensive
yuuji@0 237 against misbehaving or malicious clients that try to construct a
yuuji@0 238 message over the 4-GB limit. The server may also wish to return the
yuuji@0 239 TOOBIG response code if the resulting message exceeds a server-
yuuji@0 240 specific message size limit.
yuuji@0 241
yuuji@0 242 5. Formal Syntax
yuuji@0 243
yuuji@0 244 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 245 Form (ABNF) [7] notation. Elements not defined here can be found in
yuuji@0 246 the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
yuuji@0 247 [8] specifications. Note that capability and resp-text-code are
yuuji@0 248 extended from the IMAP [1] specification and append-data is extended
yuuji@0 249 from the IMAP ABNF extensions [8] specification.
yuuji@0 250
yuuji@0 251 append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
yuuji@0 252
yuuji@0 253 cat-part = text-literal / url
yuuji@0 254
yuuji@0 255 text-literal = "TEXT" SP literal
yuuji@0 256
yuuji@0 257 url = "URL" SP astring
yuuji@0 258
yuuji@0 259 resp-text-code =/ toobig-response-code / badurl-response-code
yuuji@0 260
yuuji@0 261 toobig-response-code = "TOOBIG"
yuuji@0 262
yuuji@0 263 badurl-response-code = "BADURL" SP url-resp-text
yuuji@0 264
yuuji@0 265 url-resp-text = 1*(%x01-09 /
yuuji@0 266 %x0B-0C /
yuuji@0 267 %x0E-5B /
yuuji@0 268 %x5D-FE) ; Any TEXT-CHAR except "]"
yuuji@0 269
yuuji@0 270 capability =/ "CATENATE"
yuuji@0 271
yuuji@0 272 The astring in the definition of url and the url-resp-text in the
yuuji@0 273 definition of badurl-response-code each contain an imapurl as defined
yuuji@0 274 by [2].
yuuji@0 275
yuuji@0 276
yuuji@0 277
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Resnick Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 285
yuuji@0 286
yuuji@0 287 6. Acknowledgements
yuuji@0 288
yuuji@0 289 Thanks to the members of the LEMONADE working group for their input.
yuuji@0 290 Special thanks to Alexey Melnikov for the examples.
yuuji@0 291
yuuji@0 292 7. Security Considerations
yuuji@0 293
yuuji@0 294 The CATENATE extension does not raise any security considerations
yuuji@0 295 that are not present for the base protocol or in the use of IMAP
yuuji@0 296 URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2]
yuuji@0 297 documents.
yuuji@0 298
yuuji@0 299 8. IANA Considerations
yuuji@0 300
yuuji@0 301 IMAP4 capabilities are registered by publishing a standards track or
yuuji@0 302 IESG approved experimental RFC. The registry is currently located at
yuuji@0 303 <http://www.iana.org/assignments/imap4-capabilities>. This document
yuuji@0 304 defines the CATENATE IMAP capability. The IANA has added this
yuuji@0 305 capability to the registry.
yuuji@0 306
yuuji@0 307
yuuji@0 308
yuuji@0 309
yuuji@0 310
yuuji@0 311
yuuji@0 312
yuuji@0 313
yuuji@0 314
yuuji@0 315
yuuji@0 316
yuuji@0 317
yuuji@0 318
yuuji@0 319
yuuji@0 320
yuuji@0 321
yuuji@0 322
yuuji@0 323
yuuji@0 324
yuuji@0 325
yuuji@0 326
yuuji@0 327
yuuji@0 328
yuuji@0 329
yuuji@0 330
yuuji@0 331
yuuji@0 332
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Resnick Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 341
yuuji@0 342
yuuji@0 343 Appendix A. Examples
yuuji@0 344
yuuji@0 345 Lines not starting with "C: " or "S: " are continuations of the
yuuji@0 346 previous lines.
yuuji@0 347
yuuji@0 348 The original message in examples 1 and 2 below (UID = 20) has the
yuuji@0 349 following structure:
yuuji@0 350
yuuji@0 351
yuuji@0 352 multipart/mixed MIME message with two body parts:
yuuji@0 353
yuuji@0 354 1. text/plain
yuuji@0 355
yuuji@0 356 2. application/x-zip-compressed
yuuji@0 357
yuuji@0 358 Example 1: The following example demonstrates how a CATENATE client
yuuji@0 359 can replace an attachment in a draft message, without the need to
yuuji@0 360 download it to the client and upload it back.
yuuji@0 361
yuuji@0 362 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
yuuji@0 363 (URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
yuuji@0 364 TEXT {42}
yuuji@0 365 S: + Ready for literal data
yuuji@0 366 C:
yuuji@0 367 C: --------------030308070208000400050907
yuuji@0 368 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
yuuji@0 369 URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
yuuji@0 370 S: + Ready for literal data
yuuji@0 371 C:
yuuji@0 372 C: --------------030308070208000400050907
yuuji@0 373 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
yuuji@0 374 S: + Ready for literal data
yuuji@0 375 C:
yuuji@0 376 C: --------------030308070208000400050907--
yuuji@0 377 C: )
yuuji@0 378 S: A003 OK catenate append completed
yuuji@0 379
yuuji@0 380
yuuji@0 381
yuuji@0 382
yuuji@0 383
yuuji@0 384
yuuji@0 385
yuuji@0 386
yuuji@0 387
yuuji@0 388
yuuji@0 389
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Resnick Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 397
yuuji@0 398
yuuji@0 399 Example 2: The following example demonstrates how the CATENATE
yuuji@0 400 extension can be used to replace edited text in a draft message, as
yuuji@0 401 well as header fields for the top level message part (e.g., Subject
yuuji@0 402 has changed). The previous version of the draft is marked as
yuuji@0 403 \Deleted. Note that the server also supports the UIDPLUS extension,
yuuji@0 404 so the APPENDUID response code is returned in the successful OK
yuuji@0 405 response to the APPEND command.
yuuji@0 406
yuuji@0 407 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
yuuji@0 408 S: + Ready for literal data
yuuji@0 409 C: Return-Path: <bar@example.org>
yuuji@0 410 C: Received: from [127.0.0.2]
yuuji@0 411 C: by rufus.example.org via TCP (internal) with ESMTPA;
yuuji@0 412 C: Thu, 11 Nov 2004 16:57:07 +0000
yuuji@0 413 C: Message-ID: <419399E1.6000505@example.org>
yuuji@0 414 C: Date: Thu, 12 Nov 2004 16:57:05 +0000
yuuji@0 415 C: From: Bob Ar <bar@example.org>
yuuji@0 416 C: X-Accept-Language: en-us, en
yuuji@0 417 C: MIME-Version: 1.0
yuuji@0 418 C: To: foo@example.net
yuuji@0 419 C: Subject: About our holiday trip
yuuji@0 420 C: Content-Type: multipart/mixed;
yuuji@0 421 C: boundary="------------030308070208000400050907"
yuuji@0 422 C:
yuuji@0 423 C: --------------030308070208000400050907
yuuji@0 424 C: Content-Type: text/plain; charset=us-ascii; format=flowed
yuuji@0 425 C: Content-Transfer-Encoding: 7bit
yuuji@0 426 C:
yuuji@0 427 C: Our travel agent has sent the updated schedule.
yuuji@0 428 C:
yuuji@0 429 C: Cheers,
yuuji@0 430 C: Bob
yuuji@0 431 C: --------------030308070208000400050907
yuuji@0 432 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
yuuji@0 433 URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
yuuji@0 434 S: + Ready for literal data
yuuji@0 435 C:
yuuji@0 436 C: --------------030308070208000400050907--
yuuji@0 437 C: )
yuuji@0 438 S: A003 OK [APPENDUID 385759045 45] append Completed
yuuji@0 439 C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
yuuji@0 440 S: A004 OK STORE completed
yuuji@0 441
yuuji@0 442
yuuji@0 443
yuuji@0 444
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Resnick Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 453
yuuji@0 454
yuuji@0 455 Example 3: The following example demonstrates how the CATENATE
yuuji@0 456 extension can be used to strip attachments. Below, a PowerPoint
yuuji@0 457 attachment was replaced by a small text part explaining that the
yuuji@0 458 attachment was stripped.
yuuji@0 459
yuuji@0 460 C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
yuuji@0 461 (URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
yuuji@0 462 TEXT {42}
yuuji@0 463 S: + Ready for literal data
yuuji@0 464 C:
yuuji@0 465 C: --------------030308070208000400050903
yuuji@0 466 C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
yuuji@0 467 URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
yuuji@0 468 S: + Ready for literal data
yuuji@0 469 C:
yuuji@0 470 C: --------------030308070208000400050903
yuuji@0 471 C: Content-type: text/plain; charset="us-ascii"
yuuji@0 472 C: Content-transfer-encoding: 7bit
yuuji@0 473 C:
yuuji@0 474 C: This body part contained a Power Point presentation that was
yuuji@0 475 C: deleted upon your request.
yuuji@0 476 C: --------------030308070208000400050903--
yuuji@0 477 C: )
yuuji@0 478 S: A003 OK append Completed
yuuji@0 479
yuuji@0 480
yuuji@0 481
yuuji@0 482
yuuji@0 483
yuuji@0 484
yuuji@0 485
yuuji@0 486
yuuji@0 487
yuuji@0 488
yuuji@0 489
yuuji@0 490
yuuji@0 491
yuuji@0 492
yuuji@0 493
yuuji@0 494
yuuji@0 495
yuuji@0 496
yuuji@0 497
yuuji@0 498
yuuji@0 499
yuuji@0 500
yuuji@0 501
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Resnick Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 509
yuuji@0 510
yuuji@0 511 Example 4: The following example demonstrates a failed APPEND
yuuji@0 512 command. The server returns the BADURL response code to indicate
yuuji@0 513 that one of the provided URLs is invalid. This example also
yuuji@0 514 demonstrates how the CATENATE extension can be used to construct a
yuuji@0 515 digest of several messages.
yuuji@0 516
yuuji@0 517 C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
yuuji@0 518 S: + Ready for literal data
yuuji@0 519 C: Return-Path: <foo@example.org>
yuuji@0 520 C: Received: from [127.0.0.2]
yuuji@0 521 C: by rufus.example.org via TCP (internal) with ESMTPA;
yuuji@0 522 C: Thu, 11 Nov 2004 16:57:07 +0000
yuuji@0 523 C: Message-ID: <419399E1.6000505@example.org>
yuuji@0 524 C: Date: Thu, 21 Nov 2004 16:57:05 +0000
yuuji@0 525 C: From: Farren Oo <foo@example.org>
yuuji@0 526 C: X-Accept-Language: en-us, en
yuuji@0 527 C: MIME-Version: 1.0
yuuji@0 528 C: To: bar@example.org
yuuji@0 529 C: Subject: Digest of the mailing list for today
yuuji@0 530 C: Content-Type: multipart/digest;
yuuji@0 531 C: boundary="------------030308070208000400050904"
yuuji@0 532 C:
yuuji@0 533 C: --------------030308070208000400050904
yuuji@0 534 C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
yuuji@0 535 S: + Ready for literal data
yuuji@0 536 C:
yuuji@0 537 C: --------------030308070208000400050904
yuuji@0 538 C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
yuuji@0 539 TEXT {42}
yuuji@0 540 S: + Ready for literal data
yuuji@0 541 C:
yuuji@0 542 C: --------------030308070208000400050904
yuuji@0 543 C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
yuuji@0 544 S: + Ready for literal data
yuuji@0 545 C:
yuuji@0 546 C: --------------030308070208000400050904--
yuuji@0 547 C: )
yuuji@0 548 S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
yuuji@0 549 section=1.5.9"] CATENATE append has failed, one message expunged
yuuji@0 550
yuuji@0 551 Note that the server could have validated the URLs as they were
yuuji@0 552 received and therefore could have returned the tagged NO response
yuuji@0 553 with BADURL response-code in place of any continuation request after
yuuji@0 554 the URL was received.
yuuji@0 555
yuuji@0 556
yuuji@0 557
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Resnick Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 565
yuuji@0 566
yuuji@0 567 9. Normative References
yuuji@0 568
yuuji@0 569 [1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
yuuji@0 570 RFC 3501, March 2003.
yuuji@0 571
yuuji@0 572 [2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
yuuji@0 573
yuuji@0 574 [3] Crispin, M., "Internet Message Access Protocol (IMAP) -
yuuji@0 575 MULTIAPPEND Extension", RFC 3502, March 2003.
yuuji@0 576
yuuji@0 577 [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
yuuji@0 578
yuuji@0 579 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
yuuji@0 580 Extensions (MIME) Part One: Format of Internet Message Bodies",
yuuji@0 581 RFC 2045, November 1996.
yuuji@0 582
yuuji@0 583 [6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
yuuji@0 584 extension", RFC 4315, December 2005.
yuuji@0 585
yuuji@0 586 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
yuuji@0 587 Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 588
yuuji@0 589 [8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
yuuji@0 590 RFC 4466, April 2006.
yuuji@0 591
yuuji@0 592
yuuji@0 593
yuuji@0 594
yuuji@0 595
yuuji@0 596
yuuji@0 597
yuuji@0 598
yuuji@0 599
yuuji@0 600
yuuji@0 601
yuuji@0 602
yuuji@0 603
yuuji@0 604
yuuji@0 605
yuuji@0 606
yuuji@0 607
yuuji@0 608
yuuji@0 609
yuuji@0 610
yuuji@0 611
yuuji@0 612
yuuji@0 613
yuuji@0 614
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Resnick Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 621
yuuji@0 622
yuuji@0 623 Author's Address
yuuji@0 624
yuuji@0 625 Peter W. Resnick
yuuji@0 626 QUALCOMM Incorporated
yuuji@0 627 5775 Morehouse Drive
yuuji@0 628 San Diego, CA 92121-1714
yuuji@0 629 US
yuuji@0 630
yuuji@0 631 Phone: +1 858 651 4478
yuuji@0 632 EMail: presnick@qualcomm.com
yuuji@0 633 URI: http://www.qualcomm.com/~presnick/
yuuji@0 634
yuuji@0 635
yuuji@0 636
yuuji@0 637
yuuji@0 638
yuuji@0 639
yuuji@0 640
yuuji@0 641
yuuji@0 642
yuuji@0 643
yuuji@0 644
yuuji@0 645
yuuji@0 646
yuuji@0 647
yuuji@0 648
yuuji@0 649
yuuji@0 650
yuuji@0 651
yuuji@0 652
yuuji@0 653
yuuji@0 654
yuuji@0 655
yuuji@0 656
yuuji@0 657
yuuji@0 658
yuuji@0 659
yuuji@0 660
yuuji@0 661
yuuji@0 662
yuuji@0 663
yuuji@0 664
yuuji@0 665
yuuji@0 666
yuuji@0 667
yuuji@0 668
yuuji@0 669
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Resnick Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 4469 IMAP CATENATE Extension April 2006
yuuji@0 677
yuuji@0 678
yuuji@0 679 Full Copyright Statement
yuuji@0 680
yuuji@0 681 Copyright (C) The Internet Society (2006).
yuuji@0 682
yuuji@0 683 This document is subject to the rights, licenses and restrictions
yuuji@0 684 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 685 retain all their rights.
yuuji@0 686
yuuji@0 687 This document and the information contained herein are provided on an
yuuji@0 688 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 689 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
yuuji@0 690 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
yuuji@0 691 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
yuuji@0 692 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 693 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 694
yuuji@0 695 Intellectual Property
yuuji@0 696
yuuji@0 697 The IETF takes no position regarding the validity or scope of any
yuuji@0 698 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 699 pertain to the implementation or use of the technology described in
yuuji@0 700 this document or the extent to which any license under such rights
yuuji@0 701 might or might not be available; nor does it represent that it has
yuuji@0 702 made any independent effort to identify any such rights. Information
yuuji@0 703 on the procedures with respect to rights in RFC documents can be
yuuji@0 704 found in BCP 78 and BCP 79.
yuuji@0 705
yuuji@0 706 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 707 assurances of licenses to be made available, or the result of an
yuuji@0 708 attempt made to obtain a general license or permission for the use of
yuuji@0 709 such proprietary rights by implementers or users of this
yuuji@0 710 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 711 http://www.ietf.org/ipr.
yuuji@0 712
yuuji@0 713 The IETF invites any interested party to bring to its attention any
yuuji@0 714 copyrights, patents or patent applications, or other proprietary
yuuji@0 715 rights that may cover technology that may be required to implement
yuuji@0 716 this standard. Please address the information to the IETF at
yuuji@0 717 ietf-ipr@ietf.org.
yuuji@0 718
yuuji@0 719 Acknowledgement
yuuji@0 720
yuuji@0 721 Funding for the RFC Editor function is provided by the IETF
yuuji@0 722 Administrative Support Activity (IASA).
yuuji@0 723
yuuji@0 724
yuuji@0 725
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Resnick Standards Track [Page 13]
yuuji@0 731

UW-IMAP'd extensions by yuuji