Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension
Alexey Melnikov <[email protected]> Fri, 24 Jul 2015 12:45:57 +0200
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <[email protected]> |
Hi, On 24 Jul 2015, at 02:02, Jamie Nicolson <[email protected]> wrote: >> On Thu, Jul 23, 2015 at 1:41 PM, Jayantheesh S B <[email protected]> wrote: >> Hi Jamie, >> >> >> >> How does the client know whether there is a mailbox-specific limit unless it issues a SELECT or LIST command? If a limit is specified in the CAPABILITY, does that mean there are no mailbox-specific limits? I thought it was possible to have both. >> >> >> >> Let’s keep it simple. >> >> We cannot have both. >> >> >> >> When APPENDLIMIT value is specified in the capability response, that indicates that server does not support mailbox specific limit. >> >> It’s one for everyone. >> >> E.g. >> >> CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890 >> >> >> >> When APPENDLIMIT is omitted in capability response, that means server is having mailbox specific append limits. >> >> E.g. >> >> CAPABILITY IMAP4rev1 ID APPENDLIMIT >> >> In this case client can get it by LIST or SELECT response. >> > > OK, so a server implementor that wants system-wide mailbox limits can just specify APPENDLIMIT=XXX in the CAPABILITY and then ignore the parts of the spec that discuss per-mailbox limits? Sounds good to me. From a server implementor's point of view this is easier to implement. From a client implementor's point of view, having a new STATUS item which is only available some of the time adds asymmetry to the protocol, which makes it slightly more difficult to implement, especially in presence of multiple extensions. _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext