1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4469.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,731 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                         P. Resnick
    1.11 +Request for Comments: 4469                         QUALCOMM Incorporated
    1.12 +Updates: 3501, 3502                                           April 2006
    1.13 +Category: Standards Track
    1.14 +
    1.15 +
    1.16 +       Internet Message Access Protocol (IMAP) CATENATE Extension
    1.17 +
    1.18 +Status of This Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Copyright Notice
    1.27 +
    1.28 +   Copyright (C) The Internet Society (2006).
    1.29 +
    1.30 +Abstract
    1.31 +
    1.32 +   The CATENATE extension to the Internet Message Access Protocol (IMAP)
    1.33 +   extends the APPEND command to allow clients to create messages on the
    1.34 +   IMAP server that may contain a combination of new data along with
    1.35 +   parts of (or entire) messages already on the server.  Using this
    1.36 +   extension, the client can catenate parts of an already existing
    1.37 +   message onto a new message without having to first download the data
    1.38 +   and then upload it back to the server.
    1.39 +
    1.40 +
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Resnick                     Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 4469                IMAP CATENATE Extension               April 2006
    1.64 +
    1.65 +
    1.66 +1.  Introduction
    1.67 +
    1.68 +   The CATENATE extension to the Internet Message Access Protocol (IMAP)
    1.69 +   [1] allows the client to create a message on the server that can
    1.70 +   include the text of messages (or parts of messages) that already
    1.71 +   exist on the server without having to FETCH them and APPEND them back
    1.72 +   to the server.  The CATENATE extension extends the APPEND command so
    1.73 +   that, instead of a single message literal, the command can take as
    1.74 +   arguments any combination of message literals (as described in IMAP
    1.75 +   [1]) and message URLs (as described in the IMAP URL Scheme [2]
    1.76 +   specification).  The server takes all the pieces and catenates them
    1.77 +   into the output message.  The CATENATE extension can also coexist
    1.78 +   with the MULTIAPPEND extension [3] to APPEND multiple messages in a
    1.79 +   single command.
    1.80 +
    1.81 +   There are some obvious uses for the CATENATE extension.  The
    1.82 +   motivating use case was to provide a way for a resource-constrained
    1.83 +   client to compose a message for subsequent submission that contains
    1.84 +   data that already exists in that client's IMAP store.  Because the
    1.85 +   client does not have to download and re-upload potentially large
    1.86 +   message parts, bandwidth and processing limitations do not have as
    1.87 +   much impact.  In addition, since the client can create a message in
    1.88 +   its own IMAP store, the command also addresses the desire of the
    1.89 +   client to archive a copy of a sent message without having to upload
    1.90 +   the message twice.  (Mechanisms for sending the message are outside
    1.91 +   the scope of this document.)
    1.92 +
    1.93 +   The extended APPEND command can also be used to copy parts of a
    1.94 +   message to another mailbox for archival purposes while getting rid of
    1.95 +   undesired parts.  In environments where server storage is limited, a
    1.96 +   client could get rid of large message parts by copying over only the
    1.97 +   necessary parts and then deleting the original message.  The
    1.98 +   mechanism could also be used to add data to a message (such as
    1.99 +   prepending message header fields) or to include other data by making
   1.100 +   a copy of the original and catenating the new data.
   1.101 +
   1.102 +2.  The CATENATE Capability
   1.103 +
   1.104 +   A server that supports this extension returns "CATENATE" as one of
   1.105 +   the responses to the CAPABILITY command.
   1.106 +
   1.107 +
   1.108 +
   1.109 +
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Resnick                     Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.120 +
   1.121 +
   1.122 +3.  The APPEND Command
   1.123 +
   1.124 +   Arguments:  mailbox name
   1.125 +               (The following can be repeated in the presence of the
   1.126 +               MULTIAPPEND extension [3])
   1.127 +               OPTIONAL flag parenthesized list
   1.128 +               OPTIONAL date/time string
   1.129 +               a single message literal or one or more message parts to
   1.130 +               catenate, specified as:
   1.131 +                           message literal
   1.132 +                           or
   1.133 +                           message (or message part) URL
   1.134 +
   1.135 +   Responses:  OPTIONAL NO responses: BADURL, TOOBIG
   1.136 +
   1.137 +   Result:     OK -  append completed
   1.138 +               NO -  append error: can't append to that mailbox, error
   1.139 +                     in flags or date/time or message text, or can't
   1.140 +                     fetch that data
   1.141 +               BAD - command unknown or arguments invalid
   1.142 +
   1.143 +   The APPEND command concatenates all the message parts and appends
   1.144 +   them as a new message to the end of the specified mailbox.  The
   1.145 +   parenthesized flag list and date/time string set the flags and the
   1.146 +   internal date, respectively, as described in IMAP [1].  The
   1.147 +   subsequent command parameters specify the message parts that are
   1.148 +   appended sequentially to the output message.
   1.149 +
   1.150 +   If the original form of APPEND is used, a message literal follows the
   1.151 +   optional flag list and date/time string, which is appended as
   1.152 +   described in IMAP [1].  If the extended form is used, "CATENATE" and
   1.153 +   a parenthesized list of message literals and message URLs follows,
   1.154 +   each of which is appended to the new message.  If a message literal
   1.155 +   is specified (indicated by "TEXT"), the octets following the count
   1.156 +   are appended.  If a message URL is specified (indicated by "URL"),
   1.157 +   the octets of the body part pointed to by that URL are appended, as
   1.158 +   if the literal returned in a FETCH BODY response were put in place of
   1.159 +   the message part specifier.  The APPEND command does not cause the
   1.160 +   \Seen flag to be set for any catenated body part.  The APPEND command
   1.161 +   does not change the selected mailbox.
   1.162 +
   1.163 +   In the extended APPEND command, the string following "URL" is an IMAP
   1.164 +   URL [2] and is interpreted according to the rules of [2].  The
   1.165 +   present document only describes the behavior of the command using
   1.166 +   IMAP URLs that refer to specific messages or message parts on the
   1.167 +   current IMAP server from the current authenticated IMAP session.
   1.168 +   Because of that, only relative IMAP message or message part URLs
   1.169 +   (i.e., those having no scheme or <iserver>) are used.  The base URL
   1.170 +
   1.171 +
   1.172 +
   1.173 +Resnick                     Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.176 +
   1.177 +
   1.178 +   for evaluating the relative URL is considered "imap://user@server/",
   1.179 +   where "user" is the user name of the currently authenticated user and
   1.180 +   "server" is the domain name of the current server.  When in the
   1.181 +   selected state, the base URL is considered
   1.182 +   "imap://user@server/mailbox", where "mailbox" is the encoded name of
   1.183 +   the currently selected mailbox.  Additionally, since the APPEND
   1.184 +   command is valid in the authenticated state of an IMAP session, no
   1.185 +   further LOGIN or AUTHENTICATE command is performed for URLs specified
   1.186 +   in the extended APPEND command.
   1.187 +
   1.188 +      Note: Use of an absolute IMAP URL or any URL that refers to
   1.189 +      anything other than a message or message part from the current
   1.190 +      authenticated IMAP session is outside the scope of this document
   1.191 +      and would require an extension to this specification, and a server
   1.192 +      implementing only this specification would return NO to such a
   1.193 +      request.
   1.194 +
   1.195 +   The client is responsible for making sure that the catenated message
   1.196 +   is in the format of an Internet Message Format (RFC 2822) [4] or
   1.197 +   Multipurpose Internet Mail Extension (MIME) [5] message.  In
   1.198 +   particular, when a URL is catenated, the server copies octets,
   1.199 +   unchanged, from the indicated message or message part to the
   1.200 +   catenated message.  It does no data conversion (e.g., MIME transfer
   1.201 +   encodings) nor any verification that the data is appropriate for the
   1.202 +   MIME part of the message into which it is inserted.  The client is
   1.203 +   also responsible for inserting appropriate MIME boundaries between
   1.204 +   body parts, and writing MIME Content-Type and Content-Transfer-
   1.205 +   Encoding lines as needed in the appropriate places.
   1.206 +
   1.207 +   Responses behave just as the original APPEND command described in
   1.208 +   IMAP [1].  If the server implements the IMAP UIDPLUS extension [6],
   1.209 +   it will also return an APPENDUID response code in the tagged OK
   1.210 +   response.  Two response codes are provided in Section 4 that can be
   1.211 +   used in the tagged NO response if the APPEND command fails.
   1.212 +
   1.213 +4.  Response Codes
   1.214 +
   1.215 +   When a APPEND command fails, it may return a response code that
   1.216 +   describes a reason for the failure.
   1.217 +
   1.218 +4.1.  BADURL Response
   1.219 +
   1.220 +   The BADURL response code is returned if the APPEND fails to process
   1.221 +   one of the specified URLs.  Possible reasons for this are bad URL
   1.222 +   syntax, unrecognized URL schema, invalid message UID, or invalid body
   1.223 +   part.  The BADURL response code contains the first URL specified as a
   1.224 +   parameter to the APPEND command that has caused the operation to
   1.225 +   fail.
   1.226 +
   1.227 +
   1.228 +
   1.229 +Resnick                     Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.232 +
   1.233 +
   1.234 +4.2.  TOOBIG Response
   1.235 +
   1.236 +   The TOOBIG response code is returned if the resulting message will
   1.237 +   exceed the 4-GB IMAP message limit.  This might happen, for example,
   1.238 +   if the client specifies 3 URLs for 2-GB messages.  Note that even if
   1.239 +   the server doesn't return TOOBIG, it still has to be defensive
   1.240 +   against misbehaving or malicious clients that try to construct a
   1.241 +   message over the 4-GB limit.  The server may also wish to return the
   1.242 +   TOOBIG response code if the resulting message exceeds a server-
   1.243 +   specific message size limit.
   1.244 +
   1.245 +5.  Formal Syntax
   1.246 +
   1.247 +   The following syntax specification uses the Augmented Backus-Naur
   1.248 +   Form (ABNF) [7] notation.  Elements not defined here can be found in
   1.249 +   the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
   1.250 +   [8] specifications.  Note that capability and resp-text-code are
   1.251 +   extended from the IMAP [1] specification and append-data is extended
   1.252 +   from the IMAP ABNF extensions [8] specification.
   1.253 +
   1.254 +   append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
   1.255 +
   1.256 +   cat-part = text-literal / url
   1.257 +
   1.258 +   text-literal = "TEXT" SP literal
   1.259 +
   1.260 +   url = "URL" SP astring
   1.261 +
   1.262 +   resp-text-code =/ toobig-response-code / badurl-response-code
   1.263 +
   1.264 +   toobig-response-code = "TOOBIG"
   1.265 +
   1.266 +   badurl-response-code = "BADURL" SP url-resp-text
   1.267 +
   1.268 +   url-resp-text = 1*(%x01-09 /
   1.269 +                      %x0B-0C /
   1.270 +                      %x0E-5B /
   1.271 +                      %x5D-FE) ; Any TEXT-CHAR except "]"
   1.272 +
   1.273 +   capability =/ "CATENATE"
   1.274 +
   1.275 +   The astring in the definition of url and the url-resp-text in the
   1.276 +   definition of badurl-response-code each contain an imapurl as defined
   1.277 +   by [2].
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Resnick                     Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.288 +
   1.289 +
   1.290 +6.  Acknowledgements
   1.291 +
   1.292 +   Thanks to the members of the LEMONADE working group for their input.
   1.293 +   Special thanks to Alexey Melnikov for the examples.
   1.294 +
   1.295 +7.  Security Considerations
   1.296 +
   1.297 +   The CATENATE extension does not raise any security considerations
   1.298 +   that are not present for the base protocol or in the use of IMAP
   1.299 +   URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2]
   1.300 +   documents.
   1.301 +
   1.302 +8.  IANA Considerations
   1.303 +
   1.304 +   IMAP4 capabilities are registered by publishing a standards track or
   1.305 +   IESG approved experimental RFC.  The registry is currently located at
   1.306 +   <http://www.iana.org/assignments/imap4-capabilities>.  This document
   1.307 +   defines the CATENATE IMAP capability.  The IANA has added this
   1.308 +   capability to the registry.
   1.309 +
   1.310 +
   1.311 +
   1.312 +
   1.313 +
   1.314 +
   1.315 +
   1.316 +
   1.317 +
   1.318 +
   1.319 +
   1.320 +
   1.321 +
   1.322 +
   1.323 +
   1.324 +
   1.325 +
   1.326 +
   1.327 +
   1.328 +
   1.329 +
   1.330 +
   1.331 +
   1.332 +
   1.333 +
   1.334 +
   1.335 +
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Resnick                     Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.344 +
   1.345 +
   1.346 +Appendix A.  Examples
   1.347 +
   1.348 +   Lines not starting with "C: " or "S: " are continuations of the
   1.349 +   previous lines.
   1.350 +
   1.351 +   The original message in examples 1 and 2 below (UID = 20) has the
   1.352 +   following structure:
   1.353 +
   1.354 +
   1.355 +      multipart/mixed MIME message with two body parts:
   1.356 +
   1.357 +      1.  text/plain
   1.358 +
   1.359 +      2.  application/x-zip-compressed
   1.360 +
   1.361 +   Example 1: The following example demonstrates how a CATENATE client
   1.362 +   can replace an attachment in a draft message, without the need to
   1.363 +   download it to the client and upload it back.
   1.364 +
   1.365 +   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
   1.366 +    (URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
   1.367 +    TEXT {42}
   1.368 +   S: + Ready for literal data
   1.369 +   C:
   1.370 +   C: --------------030308070208000400050907
   1.371 +   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
   1.372 +    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
   1.373 +   S: + Ready for literal data
   1.374 +   C:
   1.375 +   C: --------------030308070208000400050907
   1.376 +   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
   1.377 +   S: + Ready for literal data
   1.378 +   C:
   1.379 +   C: --------------030308070208000400050907--
   1.380 +   C: )
   1.381 +   S: A003 OK catenate append completed
   1.382 +
   1.383 +
   1.384 +
   1.385 +
   1.386 +
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Resnick                     Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.400 +
   1.401 +
   1.402 +   Example 2: The following example demonstrates how the CATENATE
   1.403 +   extension can be used to replace edited text in a draft message, as
   1.404 +   well as header fields for the top level message part (e.g., Subject
   1.405 +   has changed).  The previous version of the draft is marked as
   1.406 +   \Deleted.  Note that the server also supports the UIDPLUS extension,
   1.407 +   so the APPENDUID response code is returned in the successful OK
   1.408 +   response to the APPEND command.
   1.409 +
   1.410 +   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
   1.411 +   S: + Ready for literal data
   1.412 +   C: Return-Path: <bar@example.org>
   1.413 +   C: Received: from [127.0.0.2]
   1.414 +   C:           by rufus.example.org via TCP (internal) with ESMTPA;
   1.415 +   C:           Thu, 11 Nov 2004 16:57:07 +0000
   1.416 +   C: Message-ID: <419399E1.6000505@example.org>
   1.417 +   C: Date: Thu, 12 Nov 2004 16:57:05 +0000
   1.418 +   C: From: Bob Ar <bar@example.org>
   1.419 +   C: X-Accept-Language: en-us, en
   1.420 +   C: MIME-Version: 1.0
   1.421 +   C: To: foo@example.net
   1.422 +   C: Subject: About our holiday trip
   1.423 +   C: Content-Type: multipart/mixed;
   1.424 +   C:               boundary="------------030308070208000400050907"
   1.425 +   C:
   1.426 +   C: --------------030308070208000400050907
   1.427 +   C: Content-Type: text/plain; charset=us-ascii; format=flowed
   1.428 +   C: Content-Transfer-Encoding: 7bit
   1.429 +   C:
   1.430 +   C: Our travel agent has sent the updated schedule.
   1.431 +   C:
   1.432 +   C: Cheers,
   1.433 +   C: Bob
   1.434 +   C: --------------030308070208000400050907
   1.435 +   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
   1.436 +    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
   1.437 +   S: + Ready for literal data
   1.438 +   C:
   1.439 +   C: --------------030308070208000400050907--
   1.440 +   C: )
   1.441 +   S: A003 OK [APPENDUID 385759045 45] append Completed
   1.442 +   C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
   1.443 +   S: A004 OK STORE completed
   1.444 +
   1.445 +
   1.446 +
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Resnick                     Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.456 +
   1.457 +
   1.458 +   Example 3: The following example demonstrates how the CATENATE
   1.459 +   extension can be used to strip attachments.  Below, a PowerPoint
   1.460 +   attachment was replaced by a small text part explaining that the
   1.461 +   attachment was stripped.
   1.462 +
   1.463 +   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
   1.464 +    (URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
   1.465 +    TEXT {42}
   1.466 +   S: + Ready for literal data
   1.467 +   C:
   1.468 +   C: --------------030308070208000400050903
   1.469 +   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
   1.470 +    URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
   1.471 +   S: + Ready for literal data
   1.472 +   C:
   1.473 +   C: --------------030308070208000400050903
   1.474 +   C: Content-type: text/plain; charset="us-ascii"
   1.475 +   C: Content-transfer-encoding: 7bit
   1.476 +   C:
   1.477 +   C: This body part contained a Power Point presentation that was
   1.478 +   C: deleted upon your request.
   1.479 +   C: --------------030308070208000400050903--
   1.480 +   C: )
   1.481 +   S: A003 OK append Completed
   1.482 +
   1.483 +
   1.484 +
   1.485 +
   1.486 +
   1.487 +
   1.488 +
   1.489 +
   1.490 +
   1.491 +
   1.492 +
   1.493 +
   1.494 +
   1.495 +
   1.496 +
   1.497 +
   1.498 +
   1.499 +
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Resnick                     Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.512 +
   1.513 +
   1.514 +   Example 4: The following example demonstrates a failed APPEND
   1.515 +   command.  The server returns the BADURL response code to indicate
   1.516 +   that one of the provided URLs is invalid.  This example also
   1.517 +   demonstrates how the CATENATE extension can be used to construct a
   1.518 +   digest of several messages.
   1.519 +
   1.520 +   C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
   1.521 +   S: + Ready for literal data
   1.522 +   C: Return-Path: <foo@example.org>
   1.523 +   C: Received: from [127.0.0.2]
   1.524 +   C:           by rufus.example.org via TCP (internal) with ESMTPA;
   1.525 +   C:           Thu, 11 Nov 2004 16:57:07 +0000
   1.526 +   C: Message-ID: <419399E1.6000505@example.org>
   1.527 +   C: Date: Thu, 21 Nov 2004 16:57:05 +0000
   1.528 +   C: From: Farren Oo <foo@example.org>
   1.529 +   C: X-Accept-Language: en-us, en
   1.530 +   C: MIME-Version: 1.0
   1.531 +   C: To: bar@example.org
   1.532 +   C: Subject: Digest of the mailing list for today
   1.533 +   C: Content-Type: multipart/digest;
   1.534 +   C:               boundary="------------030308070208000400050904"
   1.535 +   C:
   1.536 +   C: --------------030308070208000400050904
   1.537 +   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
   1.538 +   S: + Ready for literal data
   1.539 +   C:
   1.540 +   C: --------------030308070208000400050904
   1.541 +   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
   1.542 +    TEXT {42}
   1.543 +   S: + Ready for literal data
   1.544 +   C:
   1.545 +   C: --------------030308070208000400050904
   1.546 +   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
   1.547 +   S: + Ready for literal data
   1.548 +   C:
   1.549 +   C: --------------030308070208000400050904--
   1.550 +   C: )
   1.551 +   S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
   1.552 +   section=1.5.9"] CATENATE append has failed, one message expunged
   1.553 +
   1.554 +   Note that the server could have validated the URLs as they were
   1.555 +   received and therefore could have returned the tagged NO response
   1.556 +   with BADURL response-code in place of any continuation request after
   1.557 +   the URL was received.
   1.558 +
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Resnick                     Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.568 +
   1.569 +
   1.570 +9.  Normative References
   1.571 +
   1.572 +   [1]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
   1.573 +        RFC 3501, March 2003.
   1.574 +
   1.575 +   [2]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
   1.576 +
   1.577 +   [3]  Crispin, M., "Internet Message Access Protocol (IMAP) -
   1.578 +        MULTIAPPEND Extension", RFC 3502, March 2003.
   1.579 +
   1.580 +   [4]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
   1.581 +
   1.582 +   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   1.583 +        Extensions (MIME) Part One: Format of Internet Message Bodies",
   1.584 +        RFC 2045, November 1996.
   1.585 +
   1.586 +   [6]  Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
   1.587 +        extension", RFC 4315, December 2005.
   1.588 +
   1.589 +   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
   1.590 +        Specifications: ABNF", RFC 4234, October 2005.
   1.591 +
   1.592 +   [8]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
   1.593 +        RFC 4466, April 2006.
   1.594 +
   1.595 +
   1.596 +
   1.597 +
   1.598 +
   1.599 +
   1.600 +
   1.601 +
   1.602 +
   1.603 +
   1.604 +
   1.605 +
   1.606 +
   1.607 +
   1.608 +
   1.609 +
   1.610 +
   1.611 +
   1.612 +
   1.613 +
   1.614 +
   1.615 +
   1.616 +
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Resnick                     Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.624 +
   1.625 +
   1.626 +Author's Address
   1.627 +
   1.628 +   Peter W. Resnick
   1.629 +   QUALCOMM Incorporated
   1.630 +   5775 Morehouse Drive
   1.631 +   San Diego, CA  92121-1714
   1.632 +   US
   1.633 +
   1.634 +   Phone: +1 858 651 4478
   1.635 +   EMail: presnick@qualcomm.com
   1.636 +   URI:   http://www.qualcomm.com/~presnick/
   1.637 +
   1.638 +
   1.639 +
   1.640 +
   1.641 +
   1.642 +
   1.643 +
   1.644 +
   1.645 +
   1.646 +
   1.647 +
   1.648 +
   1.649 +
   1.650 +
   1.651 +
   1.652 +
   1.653 +
   1.654 +
   1.655 +
   1.656 +
   1.657 +
   1.658 +
   1.659 +
   1.660 +
   1.661 +
   1.662 +
   1.663 +
   1.664 +
   1.665 +
   1.666 +
   1.667 +
   1.668 +
   1.669 +
   1.670 +
   1.671 +
   1.672 +
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Resnick                     Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 4469                IMAP CATENATE Extension               April 2006
   1.680 +
   1.681 +
   1.682 +Full Copyright Statement
   1.683 +
   1.684 +   Copyright (C) The Internet Society (2006).
   1.685 +
   1.686 +   This document is subject to the rights, licenses and restrictions
   1.687 +   contained in BCP 78, and except as set forth therein, the authors
   1.688 +   retain all their rights.
   1.689 +
   1.690 +   This document and the information contained herein are provided on an
   1.691 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.692 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   1.693 +   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   1.694 +   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   1.695 +   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.696 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.697 +
   1.698 +Intellectual Property
   1.699 +
   1.700 +   The IETF takes no position regarding the validity or scope of any
   1.701 +   Intellectual Property Rights or other rights that might be claimed to
   1.702 +   pertain to the implementation or use of the technology described in
   1.703 +   this document or the extent to which any license under such rights
   1.704 +   might or might not be available; nor does it represent that it has
   1.705 +   made any independent effort to identify any such rights.  Information
   1.706 +   on the procedures with respect to rights in RFC documents can be
   1.707 +   found in BCP 78 and BCP 79.
   1.708 +
   1.709 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.710 +   assurances of licenses to be made available, or the result of an
   1.711 +   attempt made to obtain a general license or permission for the use of
   1.712 +   such proprietary rights by implementers or users of this
   1.713 +   specification can be obtained from the IETF on-line IPR repository at
   1.714 +   http://www.ietf.org/ipr.
   1.715 +
   1.716 +   The IETF invites any interested party to bring to its attention any
   1.717 +   copyrights, patents or patent applications, or other proprietary
   1.718 +   rights that may cover technology that may be required to implement
   1.719 +   this standard.  Please address the information to the IETF at
   1.720 +   ietf-ipr@ietf.org.
   1.721 +
   1.722 +Acknowledgement
   1.723 +
   1.724 +   Funding for the RFC Editor function is provided by the IETF
   1.725 +   Administrative Support Activity (IASA).
   1.726 +
   1.727 +
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Resnick                     Standards Track                    [Page 13]
   1.734 +