Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension

On Thu, Jul 23, 2015 at 1:41 PM, Jayantheesh S B <[email protected]>
wrote:

>  Hi Jamie,
>
>
>
> How does the client know whether there is a mailbox-specific limit unless
> it issues a SELECT or LIST command? If a limit is specified in the
> CAPABILITY, does that mean there are no mailbox-specific limits? I thought
> it was possible to have both.
>
>
>
> Let’s keep it simple.
>
> We cannot have both.
>
>
>
> When APPENDLIMIT value is specified in the capability response, that
> indicates that server does not support mailbox specific limit.
>
> It’s one for everyone.
>
> E.g.
>
> CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
>
>
>
> When APPENDLIMIT is omitted in capability response, that means server is
> having mailbox specific append limits.
>
> E.g.
>
> CAPABILITY IMAP4rev1 ID APPENDLIMIT
>
> In this case client can get it by LIST or SELECT response.
>

OK, so a server implementor that wants system-wide mailbox limits can just
specify APPENDLIMIT=XXX in the CAPABILITY and then ignore the parts of the
spec that discuss per-mailbox limits? Sounds good to me.


>
>
> Even if they don't have to support all of LIST-EXTENDED and LIST-STATUS,
> doesn't this require the server to change their parser to accept this new
> syntax, and their LIST implementation to return it? That is a non-trivial
> amount of work.
>
>
>
> Yes, If server is supporting mailbox-specific append limit then they have
> to have append limit value in LIST or SELECT response.
>

You said "LIST or SELECT". Does that mean they don't need to support both?
I propose the server only needs to support the append limit in LIST if it
supports LIST-EXTENDED and LIST-STATUS. That way a client, having seen the
server's capabilities, can decide whether to get the per-mailbox append
limit from LIST (which is presumably more efficient) or, if the server does
not have these capabilities, by SELECT (probably slower).


>
> We can edit the spec, to make it more clear in the next revision.
>
>
>
> Regards,
>
> Jay
>
>
>
> *From:* Jamie Nicolson [mailto:[email protected]]
> *Sent:* Thursday, July 23, 2015 3:46 PM
> *To:* Jayantheesh S B
> *Cc:* Jayantheesh S.B ([email protected]);
> [email protected]; [email protected]
>
> *Subject:* Re: [imapext] Review for first draft for
> draft-ietf-imapapnd-appendlimit-extension
>
>
>
>
>
>
>
> On Thu, Jul 23, 2015 at 12:05 PM, Jayantheesh S B <[email protected]>
> wrote:
>
> HI Jamie,
>
>
>
> Thanks for reviewing the document again.
>
>
>
> Please find my response.
>
>
>
> Regards,
>
> Jay
>
> ---------- Forwarded message ----------
>
> From: Jamie Nicolson <[email protected]>
>
> Date: Thu, Jul 23, 2015 at 1:41 PM
>
> Subject: Re: [imapext] Review for first draft for
> draft-ietf-imapapnd-appendlimit-extension
>
> To: Naren <[email protected]>
>
> Cc: "[email protected]" <[email protected]>, "Jayantheesh S.B"
>
> <[email protected]>
>
>
>
>
>
> Thanks Jay. A few comments.
>
>
>
> 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. 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).
>
>
>
> [Jay] When server does not support the mailbox specific limit, then
> capability response is enough for the client to know the limit.
>
>
>
> SELECT and LIST response is needed *only* when server supports mailbox
> specific limit. It is not mandatory for the server to implement LIST
> STATUS, LIST-EXTENDED to get the mailbox specific limit.
>
>
>
> How does the client know whether there is a mailbox-specific limit unless
> it issues a SELECT or LIST command? If a limit is specified in the
> CAPABILITY, does that mean there are no mailbox-specific limits? I thought
> it was possible to have both.
>
>
>
>
>
>
>
> “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.”
>
>
>
> Even if they don't have to support all of LIST-EXTENDED and LIST-STATUS,
> doesn't this require the server to change their parser to accept this new
> syntax, and their LIST implementation to return it? That is a non-trivial
> amount of work.
>
>
>
>
>
>
>
> Mailbox-specific appendlimits: Our server will have a single appendlimit
> for all mailboxes, so we don't need the per-mailbox limits. However, the
> only way for a client to determine this will be to issue a SELECT or
> extended LIST on the target mailbox and note the absence of a per-mailbox
> appendlimit response. SELECT is expensive, and not all servers support
> extended list. Is there a way we could annotate the APPENDLIMIT capability
> to indicate that per-mailbox limits are not supported, so clients needn't
> bother querying them? It could be something as simple as adding a magic
> atom-char like '+' or
>
> '!':
>
>
>
> APPENDLIMIT=25000000!   ; system-wide append limit is 25000000,
>
> applies to all mailboxes
>
>
>
> [Jay] In Section 2, its mentioned that, when an IMAP server does not
> support the mailbox specific limit (Google server case), then as part of
> capability response, supported limit value can be published. But, if the
> server supports mailbox specific limit, then APPENDLIMIT *value* will be
> omitted as part of Capability response. It will send only APPENDLIMIT
> string in the capability, then client can always get the mailbox specific
> limit as part of SELECT, LIST response.
>
>
>
> The spec says that the server can return a limit in the capability AND
> also have per-mailbox limits:
>
>
>
>  The
>
> advertised upload limit is common across the mailboxes, but client
>
> can still issue SELECT/EXAMINE or LIST command to get the mailbox
>
> specific upload limit set by the IMAP server.  In this case,
>
> APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command
>
> takes precedence over the value returned as part of CAPABILITY
>
> response
>
>
>
> So a client that sees a limit in the capability still does not know
> whether there are per-mailbox limits, and must issue a SELECT or LIST to
> find out.
>
>
>
>
>
> “The following example, demonstrates the APPENDLIMIT capability with
>
> mailbox limit.
>
>
>
> C: t1 CAPABILITY
>
> S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
>
> S: t1 OK foo
>
>
>
> *If APPENDLIMIT value is omitted in CAPABILITY response, then client*
>
> *SHOULD issue SELECT/EXAMINE or LIST** command to get the mailbox
> specific*
>
> *limit set by the server.*  New response code APPENDLIMIT is added to get
>
> the mailbox specific limit.  Refer section 5 for response code syntax.
>
>
>
> The following example demonstrates, its usage.
>
>
>
> C: t1 CAPABILITY
>
> S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
>
> S: t1 OK foo
>
>
>
> C: t2 SELECT INBOX
>
> S: * 172 EXISTS
>
> S: * OK [APPENDLIMIT 257890] Maximum upload limit
>
> S: * OK [UIDVALIDITY 3857529045] UIDs valid
>
> S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
>
> S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
>
> S: t2 OK [READ-WRITE] SELECT completed”
>
>
>
> Kindly let us know, if this answers your question. Please revert back for
> any clarification.
>
>
>
> Regards,
>
> Jay
>
>
>
> On Mon, Jul 20, 2015 at 3:29 PM, Naren <[email protected]>
> wrote:
>
> >
>
> > Hello Working Group,
>
> >
>
> > We have published the first draft for
> draft-ietf-imapapnd-appendlimit-extension.
>
> >
>
> > Please review the draft and drop your comments.
>
> >
>
> > http://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extens
>
> > ion/
>
> >
>
> > --
>
> > Thanks & Regards
>
> > -Naren
>
> >
>
> > _______________________________________________
>
> > imapext mailing list
>
> > [email protected]
>
> > https://www.ietf.org/mailman/listinfo/imapext
>
> >
>
>
>
>
>

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