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

Dear SM,

Thanks for the feedback. 

Please find the response inline. 

Regards,
Jay

-----Original Message-----
From: S Moonesamy [mailto:[email protected]] 
Sent: Sunday, October 04, 2015 4:49 AM
To: Alexey Melnikov; [email protected]
Cc: Jayantheesh S B; Narendra Singh Bisht
Subject: Re: [imapext] 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.


[Jay] I am fine with changing this to "MUST". Please refer the latest version of the draft.

>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". :-)

[Jay] Changed this sentence. Please refer the latest version of the document.

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


[Jay] Addressed this review comments in the next version of the document. 

>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