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