Re: [IMAP] APPEND Command Usage

For servers that have a single APPENDLIMIT across all mailboxes, it's
easier (and saves bandwidth) to not have to specify any per-mailbox
APPENDLIMIT in the SELECT response. In this case the APPENDLIMIT specified
in the CAPABILITY should hold across all mailboxes. I think this is the
intent, but the only direct statement about this I see in the document is
for the APPENDLIMIT response code to SELECT in section 3.1: "If this is
missing, the client can always honour the value received as part of
CAPABILITY response." I'd like this to be a little more firm, so that the
server can choose to omit the per-mailbox APPENDLIMIT and know that the
client will respect the common limit.

Perhaps you could state this directly in the introduction to section 3,
something like, "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."

On Tue, Dec 16, 2014 at 3:21 PM, Jayantheesh S B <[email protected]>
wrote:
>
> Hi All,
>
> Please find the updated version of the draft attached.
>
> Changes in this version:
>
> 1.  APPEND command response handling changes (Reused TOOBIG response-text
> from rfc4469 )
> 2.  Retrieval of per mailbox limit in  authenticated state by using LIST
> and STATUS command (Reference rfc5819)
>
> Kindly share your comments.
>
> Regards,
> Jay
>
> -----Original Message-----
> From: Stuart Brandt [mailto:[email protected]]
> Sent: Monday, December 15, 2014 10:07 AM
> To: Alexey Melnikov; Jayantheesh S B
> Cc: '[email protected]'
> Subject: Re: [imapext] [IMAP] APPEND Command Usage
>
> Inline comments
>
> On 12/15/14 6:52 AM, Alexey Melnikov wrote:
> > Hi Stuart,
> >
> > On 12/12/2014 15:40, Stuart Brandt wrote:
> >> Inline comments
> >>
> >> On 12/12/14 5:24 AM, Alexey Melnikov wrote:
> >>> Hi Stuart,
> >>>
> >>> On 10/12/2014 19:58, Stuart Brandt wrote:
> >>>> From a server perspective, the proposal solves my concern. From a
> >>>> client perspective, I'm not sure whether the addition of [SP
> >>>> nz-number] to the TOOBIG response would present problems for
> >>>> clients that only implement CATENATE and not APPENDLIMIT. I too
> >>>> would like to see others chime in on that part.
> >>>>
> >>>> From what I see, most IMAP sessions either precede an APPEND with a
> >>>> SELECT/EXAMINE or LIST...likely to confirm the existence of the
> >>>> target mailbox into which they're going to append.  The proposal
> >>>> already covers SELECT/EXAMINE, so would it be reasonable to add the
> >>>> APPENDLIMIT=x as an attribute to the LIST response data in order to
> >>>> reflect any per-mailbox limit and avoid trying to convey the limit
> >>>> as part of the TOOBIG response code to APPEND? Something along the
> >>>> line
> >>>> of:
> >>>>
> >>>> C: t1 LIST "" "%"
> >>>> S: * LIST (\Marked \HasNoChildren) "/" Inbox
> >>>> S: * LIST (\HasNoChildren) "/" ToDo
> >>>> S: * LIST (\HasChildren) "/" Projects
> >>>> S: * LIST (\Sent \HasNoChildren) "/" SentMail
> >>>> S: * LIST (\Marked \Drafts \HasNoChildren \APPENDLIMIT=257890) "/"
> >>>> MyDrafts
> >>>> S: * LIST (\Trash \HasNoChildren) "/" Trash
> >>> All mailbox attributes are typically checked for equality, so this
> >>> this a departure from this principle. (I know we started to violate
> >>> this rule in CAPABILITY response) So personally, I prefer if we add
> >>> a new STATUS item for APPEND limit.
> >>> Then we can use STATUS-in-LIST bridge
> >>> (https://tools.ietf.org/html/rfc5819) to return this information.
> >>>
> >>> As clients that want to obey APPENDLIMIT would need to be modified
> >>> anyway, they might as well be modified to support RFC 5819 syntax.
> >>
> >> And same goes for the server, because the client will want to query
> >> *every* server that supports APPENDLIMIT just in case it has
> >> per-mailbox limits. Unless I'm way off base here, a server with a
> >> simple mailbox-wide APPEND limit would need to implement APPENDLIMIT
> >> *plus* 5819 and 5258 to support the client asking about per-mailbox
> >> limits -- unless we have the client assume that lack of support for
> >> 5819/5258 implies that the server has no per-mailbox limits. Seems
> >> pretty involved.
> > Actually, I was thinking of something simpler, which is syntactically
> > compatible:
> >
> > C: A01 LIST "" % RETURN (STATUS (APPENDLIMIT))
> > S: * LIST () "."  "INBOX"
> > S: * STATUS "INBOX" (APPENDLIMIT 1024000)
> >
> > So basically server should recognize an extra "RETURN (STATUS
> > (APPENDLIMIT))" at the end of a list command and emit an extra STATUS
> > response for each matching mailbox. Support for RFC 5819 and RFC 5258
> > is optional.
>
> That certainly simplifies things. Sounds good.
>
> >
> >
> > My reason for recommending this (other than "compatibility with RFC
> > 5819/5258 is a good thing") is that if the limit is per mailbox, it
> > might be stored with mailbox information and thus might be relatively
> > expensive to retrieve. So a compliant server shouldn't try to retrieve
> > it unless a client asks for this information. So basically we need a
> > signalling mechanism for requesting this information.
>
> Makes complete sense.
>
> >>> But otherwise I am Ok with being able to return this information in
> >>> LIST.
> >
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext
>
>

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