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

Hi Alexey,
At 11:57 03-10-2015, Alexey Melnikov wrote:
>I don't think we need normative language here, but I can be 
>convinced otherwise.

An IMAP client implementing this specification will have to support 
the formal syntax specified in Section 5.  I suggest removing the RFC 
2119 key word in that (Section 2) sentence.

>They are the same thing, so I think either is fine.

Ok.

>This sounds more like a MUST.

I suggest looking at this Section 3.1 recommendation (or requirement) 
from an interoperability perspective.  The IMAP client is looking for 
the per mailbox specific limit.  What the IMAP client needs to know 
is the STATUS response which the IMAP server will send as a 
response.  It may be better to rephrase that sentence.



>>  '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.

Ok.  I'll wait to see what the authors think about this.

>I think this is non normative.

Ok.

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

"must be fast" is subjective.  I suggest rewriting the sentence 
without RFC 2119 key words if we do not want to encourage debates 
about "fast". :-)






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

Ok.


>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

How about explaining that this extension does not introduce anything 
new and, as such, it does not create any new security issues?

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

Thanks for the feedback.

Regards,
S. Moonesamy 

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