Re: [imapext] Review of draft-ietf-imapapnd-appendlimit-extension-00

[Jayantheesh S B <[e-mail]>]

Hi Alexey,

Thanks for your review comments. 

Please find my response inline.

Regards,
Jay
-----Original Message-----
From: Alexey Melnikov [mailto:[e-mail]] 
Sent: Sunday, July 26, 2015 10:53 AM
To: IMAPAPND WG
Subject: [imapext] Review of draft-ietf-imapapnd-appendlimit-extension-00

Hi,
SM asked me to review the document, so I reread everything for the first time in a couple of months. Here are my comments:


> 2. APPENDLIMIT Extension
> 
> An IMAP server that supports APPENDLIMIT advertises this by including 
> the word APPENDLIMIT in its capability list.  IMAP server shall 
> publish the supported mail upload size as part of CAPABILITY response.

As per the recent discussion, the above text should be amended to make it clear that both "APPENDLIMIT" and "APPENDLIMIT=<value>" can be advertised. As traditionally IMAP uses exact match for capabilities, "APPENDLIMIT=..." is not going to work for a client that looks for exact match with "APPENDLIMIT".


[Jay] I will update this section with updated text in the next version of the document. 

> The
> advertised upload limit is common across the mailboxes, but client can 
> still issue SELECT/EXAMINE or LIST command to get the mailbox specific 
> upload limit set by the IMAP server.  In this case, APPENDLIMIT value 
> obtained as part of SELECT/EXAMINE or LIST command takes precedence 
> over the value returned as part of CAPABILITY response.

 [snip]

> 3. Mailbox specific APPENDLIMIT
> 
> IMAP server can still have mailbox specific APPENDLIMIT restriction, 
> which may not be advertised as part of CAPABILITY response.  In this 
> case, client can issue SELECT/EXAMINE command to get the per mailbox 
> specific limit set by the server.  Similarly, if client wish to know 
> the mailbox specific limit in authenticated state, can be done by 
> issuing the LIST command in combination with STATUS command.

I think you should clarify here that a standalone STATUS command can also be used.
[Jay] Ok
> 3.1 SELECT response
> 
> Client can get the per mailbox append limit by issuing the SELECT/ 
> EXAMINE command.  APPENDLIMIT size to this mailbox is obtained as part 
> of untagged OK response.  In this case, this APPENDLIMIT value will 
> supersede the value received as part of CAPABILITY response.  If no 
> per-mailbox APPENDLIMIT is specified for a folder, but the server did 
> specify a common APPENDLIMIT in the CAPABILITY response, then the 
> common APPENDLIMIT applies to that folder.
> 
> C: t2 SELECT INBOX
> S: * 172 EXISTS
> S: * OK [APPENDLIMIT 257890] Maximum upload limit
> S: [...]
> S: t2 OK [READ-WRITE] SELECT completed

After Chris Newman's comment that a new SELECT/EXAMINE response code going to waste lots of bandwidth as most of the time it would be returned and the client is not going to care, I am wondering again if we should remove the SELECT response. But I don't have strong feelings on this.


[Jay] Based on the others feedback, we can decide on this item.

> In the above example, APPENDLIMIT represents the maximum upload size 
> for this mailbox.
> 
> OK [APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
>                      Refer to section 5 for more information.  If this
>                      is missing, the client can always honour the
>                      value received as part of CAPABILITY response.

It occurred to me that this response code can also be returned in a NO response on a failed APPEND. It might be worth saying that. (This would cover a slightly different case from TOOBIG response code.)

> 3.2 LIST response
> 
> IMAP client can get the mailbox specific APPENDLIMIT in authenticated 
> state, where it do not need to issue SELECT/EXAMINE command.  LIST 
> command in combination with STATUS command can be issued to get the 
> per mailbox specific APPENDLIMIT set by the server.

> Refer RFC 5819 for the
> usage of LIST command in combination with STATUS command.  Note that a 
> server implementing this extension, is syntactically compatible with 
> RFC 5819, however support for RFC 5258 or RFC 5819 is not required, 
> when implementing this extension.

After the discussion with Jamie I am wondering if we have to require use of extended LIST with the new APPENDLIMIT STATUS item. Maybe we can just require implementation of the APPENDLIMIT STATUS item, and STATUS-in-LIST will take care of this, if also advertised?
[Jay] Based on others feedback, we can decide on this item.
> 5. Formal syntax
> 
> The following syntax specification uses the Augmented Backus-Naur Form 
> (ABNF) notation as specified in [RFC5234] including the core rules in 
> Appendix B.1.  [RFC3501] defines the non-terminals "capability", 
> "resp-text-code" and "status-att".
> Except as noted otherwise, all alphabetic characters are case- 
> insensitive.  The use of upper or lower case characters to define 
> token strings is for editorial clarity only.  Implementations MUST 
> accept these strings in a case-insensitive fashion.
>     
> appendlimit-cap = "APPENDLIMIT" ["=" append-limit-value] capability /= 
> appendlimit-cap
> 
> appendlimit-respcode = "APPENDLIMIT" SP append-limit-value 
> resp-text-code /= appendlimit-respcode
> 
> append-limit-value = 1*DIGIT
>                      ; Unsigned 64-bit integer
>                      ; (0 <= n < 18,446,744,073,709,551,615)

After thinking more about this, I think we should revert to 32 bit limits, because if a message is >= 2**32 octets, FETCH RFC822.SIZE would be unable to return the message size, so other things would break.


[Jay] Ok, I will updated to 32 bit in the next version of the document. 

So I think we should have a separate extension that takes care of 64bit message/body part sizes.

Best Regards,
Alexey