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

From: Jamie Nicolson <[email-masked]>
Date: Mon, 3 Aug 2015 17:38:43 -0700

>
> > 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.
>
> [Alexey] 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".
>

I'm confused on this point--if we are worried that clients will not be able
to parse APPENDLIMIT=<value>, then should we require that APPENDLIMIT
always accompany APPENDLIMIT=<value>? Otherwise, if the server just
specifies APPENDLIMIT=<value> the client might not respect it at all. I
think this will also mean the client can no longer determine from the
CAPABILITY response whether the server supports per-mailbox limits, which
means clients will have to issue a STATUS or LIST...STATUS before they can
perform an append. It would be nice to avoid that, but it's not essential
to me.

> 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
>
> [Alexey] 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.
>

I agree that it should not be sent in the SELECT response because of the
waste of bandwidth.

> > 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.
>
> [Alexey] 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.
>

So you're saying,
- All servers must implement the APPENDLIMIT data item for the STATUS
command.
- Servers that support LIST-STATUS and APPENDLIMIT must implement the
APPENDLIMIT list status item.

That sounds fine to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 04 Aug 2015 11:21:35 +0100

Hi Jamie,

On 04/08/2015 01:38, Jamie Nicolson wrote:
>     [Alexey] 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".
>
>
> I'm confused on this point--if we are worried that clients will not be 
> able to parse APPENDLIMIT=<value>, then should we require that 
> APPENDLIMIT always accompany APPENDLIMIT=<value>?
I am suggesting that the text is clear that both "APPENDLIMIT=<value>" 
and "APPENDLIMIT" are valid capabilities and that clients should check 
for both. This is not very clear unless one looks for ABNF. I think some 
implementors might miss that.
> Otherwise, if the server just specifies APPENDLIMIT=<value> the client 
> might not respect it at all. I think this will also mean the client 
> can no longer determine from the CAPABILITY response whether the 
> server supports per-mailbox limits, which means clients will have to 
> issue a STATUS or LIST...STATUS before they can perform an append. It 
> would be nice to avoid that, but it's not essential to me.
I prefer having the distinction. So basically the current ABNF is fine, 
we just need to tweak the text in Section 2.
>     [Alexey] 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.
>
>
> I agree that it should not be sent in the SELECT response because of 
> the waste of bandwidth.
Hopefully we are getting consensus on this point :-).

>     [Alexey] 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?
Yes. I think this is marginally easier to implement for servers that 
don't support LIST-EXTENDED and it would take almost no effort to 
support by servers that already support LIST-STATUS.
This however makes it slightly more difficult for clients to implement. 
Although I suspect that clients that care about this would be happy with 
just using STATUS or STATUS-in-LIST (when supported) on a couple of 
special use mailboxes like Drafts and Sent.