Review of draft-ietf-imapapnd-appendlimit-extension-03

Hello,

I read draft-ietf-imapapnd-appendlimit-extension-03 [1] and I have 
some comments.

In Section 2:

   "IMAP client should be able to parse both kind of formats."

I suggest capitalizing the "should" to follow the conventions 
specified in Section 1.1 (RFC 2119).

   "By looking at the upload size advertised by the IMAP server,
    client MUST not try to upload mail more than advertised limit."

Shouldn't this be "APPEND" instead of "upload"?

In Section 3:

   "IMAP server should return the mailbox name that matches the
    STATUS specification and the requested mailbox status information."

Is the "should" a RFC 2119 recommendation?  If so, I suggest capitalizing it.

   'IMAP server should recognize an extra "RETURN (STATUS (APPENDLIMIT))"
   at the end of a LIST command and emit an extra STATUS response for
   each matching mailbox.'

Is the "should" a RFC 2119 recommendation?

   "If the server does not support this extension, then client should
    use STATUS command instead."

Is the "should" a RFC 2119 recommendation?  Why is this a recommendation?

In Section 4:

   "STATUS APPENDLIMIT must be fast and there is no need to evaluate
    remaining quotas (if any) when returning APPENDLIMIT values."

Is the "must" a RFC 2119 requirement?  Saying "must be fast" is 
ambiguous.  I am unsure about whether this is implementor guidance or 
a requirement.  If it is a requirement, I suggest stating clearly 
what the requirement is.

In Section 5:

   "A number indicating the fixed maximum message size in bytes
    that the server will accept."

Shouldn't this be "octets" instead of "bytes"?

   "APPENDLIMIT=0 indicates the server SHALL not accept APPEND
   command due to size restriction."

Is the "SHALL not" is a RFC 2119 requirement, the "not" will have to 
be capitalized as well.  Why is this a requirement?  I could read the 
about as an explanation about what "APPENDLIMIT=0" means or I could 
read it as meaning that the server must implement this by not 
accepting the APPEND command.

The Security Considerations Section does not say much.  Why is it 
believed that "this extension doesn't add any new security 
considerations" which is not already discussed in RFC 3501?  I 
suggest looking at this in terms of "we gave some thought to this, we 
found/did not find security issues".

Section 8.1 lists the normative references.  There isn't any 
reference in the previous sections to RFC 5322, RFC 2088 and RFC 
5258.  I suggest adding some text in the draft (not in Section 8) to 
point to those specifications if they are necessary to understand 
this technical specification.

There is a downward reference to RFC 4549 as that document is 
"Informational" whereas this document is intended to be published as 
a "Proposed Standard".  Is it necessary for me to read RFC 4549 to 
understand or implement the specification in this draft?

Regards,
S. Moonesamy

1. https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-03 

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext