Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension
Jamie Nicolson <[email protected]> Fri, 24 Jul 2015 09:15:28 -0700
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <CACU8CfRic7DxGHRunURREic_ckRcACguk5q12S_o8wWuiXnXsw@mail.gmail.com> |
On Fri, Jul 24, 2015 at 3:28 AM, Alexey Melnikov <[email protected]> wrote: > Hi Jamie, > > > On 23 Jul 2015, at 19:41, Jamie Nicolson <[email protected]> wrote: > > > > Section 3.2: This section seems to imply that the extended list syntax > for STATUS APPENDLIMIT must be supported by any server that advertises the > APPENDLIMIT capability, regardless of whether it supports LIST-EXTENDED and > LIST-STATUS. > > That is my preference. > > > I think we should clarify that this section will only apply to servers > that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT. Supporting the > new syntax might be non-trivial, and will be wasted work for servers that > don't support per-mailbox limits (see below). > > Can you elaborate on why handling one extra STATUS attribute name is > complicated for you? It's only one extra STATUS attribute if the server already supports LIST-EXTENDED and LIST-STATUS, and in that case I agree, the server should add support for the APPENDLIMIT attribute. I was talking about a hypothetical server that doesn't support LIST-EXTENDED at all (like Gmail until recently). In order to conform to this APPENDLIMIT spec, if they wanted per-mailbox limits they would have to add support for a " RETURN (STATUS (APPENDLIMIT))" at the end of their LIST command, right? Maybe not a lot of work, but it seems unnecessary, and odd to support a syntax that is similar to LIST-EXTENDED without actually supporting LIST-EXTENDED. This doesn't actually matter to our implementation, because we won't support per-mailbox limits. _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext