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

>
> > 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.

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