Hi all,
I might be a little late, I'll send it for your consideration anyway.
Comments are prompt as I have to type it up quickly; let me know if it's not verbose enough.

General:
There are a good deal of abbreviations that are not spelled out on their first use (nor later on in the document).


Section 1: "Formal syntax is defined by [RFC5234<http://tools.ietf.org/html/rfc5234>]."

I guess what you mean to say is that the formal syntax is defined using the ABNF notation defined in RFC5234.


Section 2: "This document defines an IMAP extension to move messages from one mailbox to another."

This document defines new IMAP commands to move messages?


Section 2: "This function (very common in MUA UIs) is not provided by stock IMAP ..."

What is "stock imap"? One particular spec/product?


Section 2: "and cope with partial failures and side effects"
What side effects? If you have a reference that discusses those, add it. If you don't, remove it.


Section 3: "each message SHOULD either be moved or unaffected"

I'd say MUST; there's no third option.



Section 3: "The server SHOULD NOT leave a message in neither or both mailboxes afterwards"

I'd say MUST NOT; leave no room for fuzzy state.



Section 3:

"   UID MOVE is the same as the three-command sequence in all other

   respects, which implies that extensions which affect the three-

   command sequence also affect UID MOVE, and that response codes such

   as COPYUID, TRYCREATE and so on should be sent as appropriate."

Isn't there a less complicated way of saying this? For example:

Since the UID MOVE command consist of three individual commands (COPY, STORE, EXPUGE), it also triggers execution of the extensions (if any) to these commands on the server-side. Consequently, the UID MOVE command returns response codes of each command the their extensions (i.e. COPYUID, TRYCREATE, etc.).



Section 3:

"Implementers will need to read [RFC4315<http://tools.ietf.org/html/rfc4315>] to understand what UID

   EXPUNGE does. Implementing [RFC4315<http://tools.ietf.org/html/rfc4315>] is not necessary."

That sounds very awkward. Does it really make UIDPLUS a normative reference?



Section 3:

"   Note that moving messages to the current mailbox is well-defined, so

   that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE

   sequence is."

This is not good enough, especially when ACLs are in use.

Considering RFC4314 permissions:

-    COPY requires that I have 'r' right at the source and 'i' right at the destination.

-    STORE requires that I have 't' right at the source.

-    EXPUNGE requires that I have 'e' right at the source.

Consequently, I must have 'i' at the destination and 'r'+'t'+'e' at the source.



Section 3:

"   The MOVE command performs the same actions UID MOVE. Notably, the

   server may send EXPUNGE (or VANISHED) messages before the tagged

   response, so the client cannot safely send more commands with MSN

   arguments while the server is processing MOVE."

All right, but does it trigger extensions the same way UID MOVE does?

Some extensions do not operate with UIDs.

Also, a server implementation could translate MSNs to UIDs during execution - which would trigger extensions hooked onto UID, too (even though MSNs were used in the request). I.e. If UIDPLUS were to fire when MSNs were used in the MOVE command, would that break the client?

Any thoughts?



Section 4.

This is a nice idea, but not quite future-proof.

Were all extensions (at least those that are found in RFCs) enumerated to date?



Section 4.2:

"it requires the same ACL rights as the union of those three commands"

The union of three commands is a command-triplet, not access rights.

I think what you want to say is that the UID MOVE requires that all permissions that those three commands require if executed one-by-one.

What about the MSN MOVE command? (this is clearly missing from this section)



Section 5:

"[RFC3501<http://tools.ietf.org/html/rfc3501>] defines the non-terminals "capability", "command", "set" and "mailbox"."

You might want to change "command" to "command-select" (or, add command-select).



Section 5:

"     capability     =/ "MOVE"

      command-select =/ ["UID "] "MOVE" SP set SP mailbox"

RFC3501 does not define "set". Do you mean sequence-set? That's not good for UIDs.

I guess a new non-terminal to represent a message reference is in order?

Any thoughts on this?

   reference           = reference-type SP reference-value

   reference-type      = "UID" / "SEQ" / "URLAUTH" / reference-type-ext

   reference-type-ext  = atom

                         ; It is not required that new reference types

                         ; begin with "X-", see [XDASH]

   reference-value     = uniqueid / \         ; see [IMAP]

                         sequence-set / \     ; see [IMAP]

                         authorized-url / \   ; see [URLAUTH]

                         reference-value-ext

   authorized-url      = authimapurlfull / \  ; see [URLAUTH]

                         authimapurlrump      ; see [URLAUTH]

   reference-value-ext = atom

                         ; New reference values MUST correspond to

                         ; reference-type-ext



Section 6:

"   This document is believed to add no security problems."

Provided that the server does verify that all required permissions are in place.



Section 6:

"Problems with these algorithms can lead to mail loss."

You mean bad implementations of good algorithms, or just badly designed algorithms, right?



Section 9:

I'd think RFC4315 is not a normative reference; after all, one can always go with MSNs.

I guess it depends on how the MSN to UID translation turns out.



Thank you for considering.



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.