1

邓超
lib/Mail/rfc6851.html
--- a/lib/Mail/rfc6851.html 0 → 100644
查看文件 @9fdece9
+++ b/lib/Mail/rfc6851.html 0 → 100644
查看文件 @9fdece9
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <meta name="robots" content="index,follow" />
+    <meta name="creator" content="rfchandler version 0.2" />
+    <meta name="citation_author" content="A. Gulbrandsen"/>
+    <meta name="citation_author" content="N. Freed"/>
+    <meta name="citation_publication_date" content="January, 2013"/>
+    <meta name="citation_title" content="Internet Message Access Protocol (IMAP) - MOVE Extension"/>
+    <meta name="citation_doi" content="10.17487/RFC6851"/>
+    <meta name="citation_issn" content="2070-1721"/>
+    <meta name="citation_technical_report_number" content="rfc6851"/>
+    <meta name="citation_pdf_url" content="https://www.rfc-editor.org/rfc/pdfrfc/rfc6851.txt.pdf"/>
+    <title>RFC 6851: Internet Message Access Protocol (IMAP) - MOVE Extension</title>
+
+
+    <style type="text/css">
+        @media only screen
+        and (min-width: 992px)
+        and (max-width: 1199px) {
+            body { font-size: 14pt; }
+            div.content { width: 96ex; margin: 0 auto; }
+        }
+        @media only screen
+        and (min-width: 768px)
+        and (max-width: 991px) {
+            body { font-size: 14pt; }
+            div.content { width: 96ex; margin: 0 auto; }
+        }
+        @media only screen
+        and (min-width: 480px)
+        and (max-width: 767px) {
+            body { font-size: 11pt; }
+            div.content { width: 96ex; margin: 0 auto; }
+        }
+        @media only screen
+        and (max-width: 479px) {
+            body { font-size: 8pt; }
+            div.content { width: 96ex; margin: 0 auto; }
+        }
+        @media only screen
+        and (min-device-width : 375px)
+        and (max-device-width : 667px) {
+            body { font-size: 9.5pt; }
+            div.content { width: 96ex; margin: 0; }
+        }
+        @media only screen
+        and (min-device-width: 1200px) {
+            body { font-size: 10pt; margin: 0 4em; }
+            div.content { width: 96ex; margin: 0; }
+        }
+        h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
+            font-weight: bold;
+            /* line-height: 0pt; */
+            display: inline;
+            white-space: pre;
+            font-family: monospace;
+            font-size: 1em;
+            font-weight: bold;
+        }
+        pre {
+            font-size: 1em;
+            margin-top: 0px;
+            margin-bottom: 0px;
+        }
+        .pre {
+            white-space: pre;
+            font-family: monospace;
+        }
+        .header{
+            font-weight: bold;
+        }
+        .newpage {
+            page-break-before: always;
+        }
+        .invisible {
+            text-decoration: none;
+            color: white;
+        }
+        a.selflink {
+            color: black;
+            text-decoration: none;
+        }
+        @media print {
+            body {
+                font-family: monospace;
+                font-size: 10.5pt;
+            }
+            h1, h2, h3, h4, h5, h6 {
+                font-size: 1em;
+            }
+
+            a:link, a:visited {
+                color: inherit;
+                text-decoration: none;
+            }
+            .noprint {
+                display: none;
+            }
+        }
+        @media screen {
+            .grey, .grey a:link, .grey a:visited {
+                color: #777;
+            }
+            .docinfo {
+                background-color: #EEE;
+            }
+            .top {
+                border-top: 7px solid #EEE;
+            }
+            .bgwhite  { background-color: white; }
+            .bgred    { background-color: #F44; }
+            .bggrey   { background-color: #666; }
+            .bgbrown  { background-color: #840; }
+            .bgorange { background-color: #FA0; }
+            .bgyellow { background-color: #EE0; }
+            .bgmagenta{ background-color: #F4F; }
+            .bgblue   { background-color: #66F; }
+            .bgcyan   { background-color: #4DD; }
+            .bggreen  { background-color: #4F4; }
+
+            .legend   { font-size: 90%; }
+            .cplate   { font-size: 70%; border: solid grey 1px; }
+        }
+    </style>
+    <!--[if IE]>
+    <style>
+        body {
+            font-size: 13px;
+            margin: 10px 10px;
+        }
+    </style>
+    <![endif]-->    <script type="text/javascript"><!--
+function addHeaderTags() {
+    var spans = document.getElementsByTagName("span");
+    for (var i=0; i < spans.length; i++) {
+        var elem = spans[i];
+        if (elem) {
+            var level = elem.getAttribute("class");
+            if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
+                elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
+            }
+        }
+    }
+}
+var legend_html = "Colour legend:<br />      <table>         <tr><td>Unknown:</td>                   <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Draft:</td>                     <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Informational:</td>             <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Experimental:</td>              <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Best Common Practice:</td>      <td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Proposed Standard:</td>         <td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Internet Standard:</td>         <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Historic:</td>                  <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Obsolete:</td>                  <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>     </table>";
+function showElem(id) {
+    var elem = document.getElementById(id);
+    elem.innerHTML = eval(id+"_html");
+    elem.style.visibility='visible';
+}
+function hideElem(id) {
+    var elem = document.getElementById(id);
+    elem.style.visibility='hidden';
+    elem.innerHTML = "";
+}
+// -->
+</script></head>
+<body>
+<span class="pre noprint docinfo">[<a href="https://www.rfc-editor.org" title="RFC Editor">RFC Home</a>] [<a href="/rfc/rfc6851.txt">TEXT</a>|<a href="/rfc/pdfrfc/rfc6851.txt.pdf">PDF</a>|<a href="/rfc/rfc6851.html">HTML</a>] [<a href='https://datatracker.ietf.org/doc/rfc6851' title='IETF Datatracker information for this document'>Tracker</a>] [<a href="https://datatracker.ietf.org/ipr/search/?rfc=6851&amp;submit=rfc" title="IPR disclosures related to this document">IPR</a>] [<a href='https://www.rfc-editor.org/info/rfc6851' title='Info page'>Info page</a>]                  </span><br/><span class="pre noprint docinfo">                                                                        </span><br /><span class="pre noprint docinfo">                                                       PROPOSED STANDARD</span><br /><span class="pre noprint docinfo">                                                                        </span><pre>Internet Engineering Task Force (IETF)                    A. Gulbrandsen
+Request for Comments: 6851
+Category: Standards Track                                  N. Freed, Ed.
+ISSN: 2070-1721                                                   Oracle
+                                                            January 2013
+
+
+        <span class="h1">Internet Message Access Protocol (IMAP) - MOVE Extension</span>
+
+Abstract
+
+   This document defines an IMAP extension consisting of two new
+   commands, MOVE and UID MOVE, that are used to move messages from one
+   mailbox to another.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   <a href="http://www.rfc-editor.org/info/rfc6851">http://www.rfc-editor.org/info/rfc6851</a>.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 1]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>
+
+   This document defines an IMAP [<a href="./rfc3501" title="&quot;INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1&quot;">RFC3501</a>] extension to facilitate
+   moving messages from one mailbox to another.  This is accomplished by
+   defining a new MOVE command and extending the UID command to allow
+   UID MOVE.
+
+   A move function is not provided in the base IMAP specification, so
+   clients have instead had to use a combination of the COPY, STORE, and
+   EXPUNGE commands to perform this very common operation.
+
+   Implementors have long pointed out some shortcomings with this
+   approach.  Because the moving of a message is not an atomic process,
+   interruptions can leave messages in intermediate states.  Because
+   multiple clients can be accessing the mailboxes at the same time,
+   clients can see messages in intermediate states even without
+   interruptions.  If the source mailbox contains other messages that
+   are flagged for deletion, the third step can have the side effect of
+   expunging more than just the set of moved messages.  Additionally,
+   servers with certain types of back-end message stores might have
+   efficient ways of moving messages, which don't involve the actual
+   copying of data.  Such efficiencies are often not available to the
+   COPY/STORE/EXPUNGE process.
+
+   The MOVE extension is present in any IMAP implementation that returns
+   "MOVE" as one of the supported capabilities to the CAPABILITY
+   command.
+
+<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Conventions Used in This Document</span>
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].
+
+   Formal syntax is specified using ABNF [<a href="./rfc5234" title="&quot;Augmented BNF for Syntax Specifications: ABNF&quot;">RFC5234</a>].
+
+   Example lines prefaced by "C:" are sent by the client and ones
+   prefaced by "S:" by the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 2]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  MOVE and UID MOVE</span>
+
+<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  MOVE Command</span>
+
+   Arguments: sequence set
+              mailbox name
+
+   Responses: no specific responses for this command
+
+   Result: OK - move completed
+
+           NO - move error: can't move those messages or to that name
+
+           BAD - command unknown or arguments invalid
+
+<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  UID MOVE Command</span>
+
+   This extends the first form of the UID command (see <a href="./rfc3501#section-6.4.8">[RFC3501],
+   Section&nbsp;6.4.8</a>) to add the MOVE command defined above as a valid
+   argument.
+
+<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Semantics of MOVE and UID MOVE</span>
+
+   The MOVE command takes two arguments: a message set (sequence numbers
+   for MOVE, UIDs for UID MOVE) and a named mailbox.  Each message
+   included in the set is moved, rather than copied, from the selected
+   (source) mailbox to the named (target) mailbox.
+
+   This means that a new message is created in the target mailbox with a
+   new UID, the original message is removed from the source mailbox, and
+   it appears to the client as a single action.  This has the same
+   effect for each message as this sequence:
+
+   1.  [UID] COPY
+
+   2.  [UID] STORE +FLAGS.SILENT \DELETED
+
+   3.  UID EXPUNGE
+
+   Although the effect of the MOVE is the same as the preceding steps,
+   the semantics are not identical: The intermediate states produced by
+   those steps do not occur, and the response codes are different.  In
+   particular, though the COPY and EXPUNGE response codes will be
+   returned, response codes for a STORE MUST NOT be generated and the
+   \DELETED flag MUST NOT be set for any message.
+
+
+
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 3]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+   Because a MOVE applies to a set of messages, it might fail partway
+   through the set.  Regardless of whether the command is successful in
+   moving the entire set, each individual message SHOULD either be moved
+   or unaffected.  The server MUST leave each message in a state where
+   it is in at least one of the source or target mailboxes (no message
+   can be lost or orphaned).  The server SHOULD NOT leave any message in
+   both mailboxes (it would be bad for a partial failure to result in a
+   bunch of duplicate messages).  This is true even if the server
+   returns a tagged NO response to the command.
+
+   Because of the similarity of MOVE to COPY, extensions that affect
+   COPY affect MOVE in the same way.  Response codes such as TRYCREATE
+   (see <a href="./rfc3501#section-6.4.7">[RFC3501], Section&nbsp;6.4.7</a>), as well as those defined by
+   extensions, are sent as appropriate.  See <a href="#section-4">Section 4</a> for more
+   information about how MOVE interacts with other IMAP extensions.
+
+   An example:
+
+       C: a UID MOVE 42:69 foo
+       S: * OK [COPYUID 432432 42:69 1202:1229]
+       S: * 22 EXPUNGE
+       S: (more expunges)
+       S: a OK Done
+
+   Note that the server may send unrelated EXPUNGE responses as well, if
+   any happen to have been expunged at the same time; this is normal
+   IMAP operation.
+
+   Implementers will need to read [<a href="./rfc4315" title="&quot;Internet Message Access Protocol (IMAP) - UIDPLUS extension&quot;">RFC4315</a>] to understand what UID
+   EXPUNGE does, though full implementation of [<a href="./rfc4315" title="&quot;Internet Message Access Protocol (IMAP) - UIDPLUS extension&quot;">RFC4315</a>] is not
+   necessary.
+
+   Note that moving a message to the currently selected mailbox (that
+   is, where the source and target mailboxes are the same) is allowed
+   when copying the message to the currently selected mailbox is
+   allowed.
+
+   The server may send EXPUNGE (or VANISHED) responses before the tagged
+   response, so the client cannot safely send more commands with message
+   sequence number arguments while the server is processing MOVE or UID
+   MOVE.
+
+   Both MOVE and UID MOVE can be pipelined with other commands, but care
+   has to be taken.  Both commands modify sequence numbers and also
+   allow unrelated EXPUNGE responses.  The renumbering of other messages
+   in the source mailbox following any EXPUNGE response can be
+   surprising and makes it unsafe to pipeline any command that relies on
+   message sequence numbers after a MOVE or UID MOVE.  Similarly, MOVE
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 4]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+   cannot be pipelined with a command that might cause message
+   renumbering.  See <a href="./rfc3501#section-5.5">[RFC3501], Section&nbsp;5.5</a>, for more information about
+   ambiguities as well as handling requirements for both clients and
+   servers.
+
+<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Interaction with Other Extensions</span>
+
+   This section describes how MOVE interacts with some other IMAP
+   extensions.
+
+<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  <a href="./rfc2087">RFC 2087</a>, QUOTA</span>
+
+   The QUOTA extension (defined by [<a href="./rfc2087" title="&quot;IMAP4 QUOTA extension&quot;">RFC2087</a>]) may interact with MOVE on
+   some servers, in the sense that a MOVE command may succeed where COPY
+   would cause a quota overrun.
+
+<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  <a href="./rfc4314">RFC 4314</a>, Access Control List (ACL)</span>
+
+   The ACL rights [<a href="./rfc4314" title="&quot;IMAP4 Access Control List (ACL) Extension&quot;">RFC4314</a>] required for MOVE and UID MOVE are the union
+   of the ACL rights required for UID STORE, UID COPY, and UID EXPUNGE.
+
+<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  <a href="./rfc4315">RFC 4315</a>, UIDPLUS</span>
+
+   Servers supporting UIDPLUS [<a href="./rfc4315" title="&quot;Internet Message Access Protocol (IMAP) - UIDPLUS extension&quot;">RFC4315</a>] SHOULD send COPYUID in response
+   to a UID MOVE command.  For additional information see <a href="./rfc4315#section-3">Section&nbsp;3 of
+   [RFC4315]</a>.
+
+   Servers implementing UIDPLUS are also advised to send the COPYUID
+   response code in an untagged OK before sending EXPUNGE or moved
+   responses.  (Sending COPYUID in the tagged OK, as described in the
+   UIDPLUS specification, means that clients first receive an EXPUNGE
+   for a message and afterwards COPYUID for the same message.  It can be
+   unnecessarily difficult to process that sequence usefully.)
+
+<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  <a href="./rfc5162">RFC 5162</a>, QRESYNC</span>
+
+   The QRESYNC extension [<a href="./rfc5162" title="&quot;IMAP4 Extensions for Quick Mailbox Resynchronization&quot;">RFC5162</a>] states that the server SHOULD send
+   VANISHED rather than EXPUNGE in response to the UID EXPUNGE command.
+   The same requirement applies to MOVE, and a QRESYNC-enabled client
+   needs to handle both VANISHED and EXPUNGE responses to a UID MOVE
+   command.
+
+   If the server is capable of storing modification sequences for the
+   selected mailbox, it MUST increment the per-mailbox mod-sequence if
+   at least one message was permanently moved due to the execution of
+   the MOVE/UID MOVE command.  For each permanently removed message, the
+   server MUST remember the incremented mod-sequence and corresponding
+   UID.  If at least one message was moved, the server MUST send the
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 5]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+   updated per-mailbox modification sequence using the HIGHESTMODSEQ
+   response code (defined in [<a href="./rfc4551" title="&quot;IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization&quot;">RFC4551</a>]) in the tagged or untagged OK
+   response.
+
+   When one or more messages are moved to a target mailbox, if the
+   server is capable of storing modification sequences for the mailbox,
+   the server MUST generate and assign new modification sequence numbers
+   to the moved messages that are higher than the highest modification
+   sequence of the messages originally in the mailbox.
+
+<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  IMAP Events in Sieve</span>
+
+   MOVE applies to IMAP events in Sieve [<a href="./rfc6785" title="&quot;Support for Internet Message Access Protocol (IMAP) Events in Sieve&quot;">RFC6785</a>] in the same way as
+   COPY does.  Therefore, MOVE can cause a Sieve script to be invoked
+   with the imap.cause set to "COPY".  Because MOVE does not cause flags
+   to be changed, a MOVE command will not result in a script invocation
+   with the imap.cause set to "FLAG".
+
+<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Formal Syntax</span>
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [<a href="./rfc5234" title="&quot;Augmented BNF for Syntax Specifications: ABNF&quot;">RFC5234</a>].  [<a href="./rfc3501" title="&quot;INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1&quot;">RFC3501</a>] defines
+   the non-terminals "capability", "command-select", "sequence-set", and
+   "mailbox".
+
+   Except as noted otherwise, all alphabetic characters are case
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   capability     =/ "MOVE"
+
+   command-select =/ move
+   move           = "MOVE" SP sequence-set SP mailbox
+   uid            = "UID" SP (copy / fetch / search / store / move)
+
+<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>
+
+   MOVE does not introduce any new capabilities to IMAP, and this limits
+   the security impact.  However, the transactional semantics of MOVE
+   may interact with specific implementations in ways that could have
+   unexpected consequences.  For example, moving messages between
+   mailboxes under the quota root may require temporary suspension of
+   quota checking.
+
+   An additional area of concern is interaction with antispam,
+   antivirus, and other security scanning and auditing mechanisms.
+   Different mailboxes may have different security policies that could
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 6]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+   interact with MOVE in complex ways.  Scanning with updated rules may
+   also be required when messages are moved even when the underlying
+   policy has not changed.
+
+   MOVE does relieve a problem with the base specification, since client
+   authors currently have to devise and implement complicated algorithms
+   to handle partial failures of the STORE/COPY/EXPUNGE trio.
+   Incomplete or improper implementation of these algorithms can lead to
+   mail loss.
+
+<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>
+
+   The IANA has added MOVE to the "IMAP 4 Capabilities" registry,
+   &lt;<a href="http://www.iana.org/assignments/imap4-capabilities">http://www.iana.org/assignments/imap4-capabilities</a>&gt;.
+
+<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>
+
+   This document is dedicated to the memory of Mark Crispin, the
+   inventor of the IMAP protocol, author of the IMAP protocol
+   specification [<a href="./rfc3501" title="&quot;INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1&quot;">RFC3501</a>], and contributor to many other email
+   specifications in the IETF.
+
+   An extension like this has been proposed many times, by many people.
+   This document is based on several of those proposals, most recently
+   that by Witold Krecicki.  Witold, Benoit Claise, Adrien W. de Croy,
+   Stephen Farrell, Bron Gondwana, Dan Karp, Christian Ketterer, Murray
+   Kucherawy, Jan Kundrat, Barry Leiba, Alexey Melnikov, Kathleen
+   Moriarty, Zoltan Ordogh, Pete Resnick, Timo Sirainen, Michael
+   Slusarz, and others provided valuable comments.
+
+<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>
+
+<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>
+
+   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
+
+   [<a id="ref-RFC3501">RFC3501</a>]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003.
+
+   [<a id="ref-RFC4314">RFC4314</a>]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
+              <a href="./rfc4314">RFC 4314</a>, December 2005.
+
+   [<a id="ref-RFC4315">RFC4315</a>]  Crispin, M., "Internet Message Access Protocol (IMAP) -
+              UIDPLUS extension", <a href="./rfc4315">RFC 4315</a>, December 2005.
+
+
+
+
+
+
+<span class="grey">Gulbrandsen &amp; Freed          Standards Track                    [Page 7]</span></pre>
+<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
+<span class="grey"><a href="./rfc6851">RFC 6851</a>                  IMAP - MOVE Extension             January 2013</span>
+
+
+   [<a id="ref-RFC4551">RFC4551</a>]  Melnikov, A. and S. Hole, "IMAP Extension for Conditional
+              STORE Operation or Quick Flag Changes Resynchronization",
+              <a href="./rfc4551">RFC 4551</a>, June 2006.
+
+   [<a id="ref-RFC5162">RFC5162</a>]  Melnikov, A., Cridland, D., and C. Wilson, "IMAP4
+              Extensions for Quick Mailbox Resynchronization", <a href="./rfc5162">RFC 5162</a>,
+              March 2008.
+
+   [<a id="ref-RFC5234">RFC5234</a>]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
+
+<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>
+
+   [<a id="ref-RFC2087">RFC2087</a>]  Myers, J., "IMAP4 QUOTA extension", <a href="./rfc2087">RFC 2087</a>,
+              January 1997.
+
+   [<a id="ref-RFC6785">RFC6785</a>]  Leiba, B., "Support for Internet Message Access Protocol
+              (IMAP) Events in Sieve", <a href="./rfc6785">RFC 6785</a>, November 2012.
+
+Authors' Addresses
+
+   Arnt Gulbrandsen
+   Schweppermannstr. 8
+   D-81671 Muenchen
+   Germany
+
+   Fax:   +49 89 4502 9758
+   EMail: arnt@gulbrandsen.priv.no
+
+
+   Ned Freed (editor)
+   Oracle
+   800 Royal Oaks
+   Monrovia, CA  91016-6347
+   USA
+
+   EMail: ned+ietf@mrochek.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen &amp; Freed          Standards Track                    [Page 8]
+</pre>
+
+</body>
+</html>
+