Re: [IMAP] APPEND Command Usage

On 16/12/2014 23:21, Jayantheesh S B 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)
Comments on the new section 3.2 that you've added:
> 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 rfc5819 for the
> usage of LIST command in combination with STATUS command usage.
Nit: drop the last "usage".

I suggest you add the following sentence after the one quoted above:

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.
>
> The following example demonstrates, its usage.
>
> C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
> S: * LIST () "."  "INBOX"
> S: * STATUS "INBOX" (APPENDLIMIT 257890)
> S: t1 OK List completed.
>
> New attribute APPNDLIMIT is added to get the limit set by the server for
Typo: APPENDLIMIT
> this mailbox as part of STATUS command.  The STATUS response occurs as a
> result of an STATUS command.  It returns the mailbox name that matches
> the STATUS specification and the requested mailbox status information.
> IMAP server should recognize an extra "RETURN (STATUS(APPENDLIMIT))" at
Please change "RETURN (STATUS(APPENDLIMIT))" to ""RETURN (STATUS 
(APPENDLIMIT))", as spaces are significant.
> the end of a list command and emit an extra STATUS response for each
> matching mailbox.  Refer to section [5] for the syntax.

How did you manage to generate [5]? This is going to be misinterpreted as a document reference by various IETF tools. Just use "5".

It might also be worth pointing out that just calling STATUS with APPENDLIMIT is also acceptable. It would be worth adding an example of that as well.

> 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