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

Hi SM,

> On 3 Oct 2015, at 17:04, S Moonesamy <[email protected]> wrote:
> 
> 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).

I don't think we need normative language here, but I can be convinced otherwise.
> 
>  "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"?

They are the same thing, so I think either is fine.
> 
> 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.

This sounds more like a MUST.
> 
>  '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?
Again, probably a MUST.
> 
>  "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?

I think this is non normative.
> 
> 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.

It is a performance requirement, but it is not really possible to test for compliance. So this is more of a quality of service issue.
> 
> 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 latter, I think.
> 
> 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".

Clients can test the limit by trying different sizes, but this makes it easier for clients to find out the limit. On the server side servers still need to handle APPEND abuse, so this is not really different Sent from my iPad
> 
> 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.

RFC 2088 (LITERAL+) should be referenced in section 4, so I suggest it should be mentioned there.

5258 can probably be omitted.

> 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?

As https://datatracker.ietf.org/doc/rfc4549/referencedby/ shows 3 Standard Track RFCs pointing to RFC 4549, it can be added into the downref registry. I suggest you just mention that in the writeup.

This reference can also be moved to Informative, because of how RFC 4549 is used.
> 
> 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

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