Re: [IMAP] APPEND Command Usage

Thanks for your comments.

I will update the review comments in the next version.

Regards,
Jay
From: Alexey Melnikov [mailto:[email protected]]
Sent: Thursday, December 18, 2014 7:35 AM
To: Jayantheesh S B; 'Stuart Brandt'; '[email protected]'
Subject: Re: [imapext] [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]<mailto:[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]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/imapext

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