IMAP MESSAGELIMIT Extension
draft-ietf-extra-imap-messagelimit-10

# Gunter Van de Velde, RTG AD, comments for draft-ietf-extra-imap-messagelimit-10

## Many thanks for writing this document. I found the text easy to process even when not being a IMAP expert. 

#GENERIC COMMENTS
#================
## 


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

155	         The server doesn't allow more than <N> \Deleted messages to be
156	         operated on by a single UID EXPUNGE command.  The lowest
157	         processed UID is <LastUID>.  The client needs to repeat the
158	         operation for remaining messages, if required.

[minor]
Is there a reason why a backslash is used before \Deleted instead of only Deleted?
(i do not hav esignificant IMAP knowledge, but at first glance this looks as an odd construct)

523	Index
524
525	   M
526
527	      M
528
529	         MESSAGELIMIT (response code)
530	            Section 3.1, Paragraph 2.2.1

[minor]
Are the above lines supposed to be in the reference section? they look as a left over from a copy/paste

I am also a little worried that breaking old clients with no good error reporting is going to become an issue. The methods described in the document push the failure into the future, but seems to not meanwhile cause client warnings that they should do something (upgrade). I am assuming no better error handling is possible with IMAP ?

NITS:

  C: 05 UID COPY 18000:21000 "Trash"

It seems a bit weird to COPY (instead of MOVE) messages to a Trash? Maybe rename "Trash" to "Backup" ?

** Section 7.1 
  IMAP4 capabilities are registered by publishing a standards track or
   IESG approved Informational or Experimental RFC.  The registry is
   currently located at:
      https://www.iana.org/assignments/imap-capabilities/

Could the rational for the first sentence be provided?  Technically, the “IMAP Capabilities” registry has an “IETF Review” policy.  In theory, a BCP status document would also qualify.  However, why would this document have to explain the registration policy of a registry it is not creating.  Is that the first sentence needed?

Perhaps this entire section could just read:

NEW (proposed)

IANA is requested to add the registrations of the capability names of "MESSAGELIMIT=" and "SAVELIMIT=" to the “IMAP Capabilities” registry (https://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml#imap-capabilities-1) and use this document for the reference for both entries.

Thanks for the work done in this document.

I have a real concern on how this new system can be deployed with 'new' servers and 'legacy' clients especially for the COPY operations if part of the COPY is not done, i.e., could be run multiple times by the end user :-( I fear that section 4.2 is too optimistic on this deployment issue. Why not having a negotiation between client and server and for legacy not implementing this limit ?

Note: I may have misunderstood the proposal.