Re: Review of draft-ietf-imapapnd-appendlimit-extension-00

Hi Jamie,

On 04/08/2015 01:38, Jamie Nicolson wrote:
>
>     > 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>?
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.
>
>     > 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.
Hopefully we are getting consensus on this point :-).

>     > 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.
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.
> That sounds fine to me.

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext