Re: [IMAP] APPEND Command Usage
Alexey Melnikov <[email protected]>
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <[email protected]> |
Hi Michael, On 17/12/2014 12:01, Michael M Slusarz wrote: > Quoting Jayantheesh S B <[email protected]>: > >> 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. > > Some quick thoughts: > > - Section 2 says a "client SHALL not try to upload mail more than > advertised limit in the APPEND command.". I would think that should > be MUST, not SHALL. If a client understands APPENDLIMIT, it knows the > maximum size the server would accept. Sending data over this limit is > explicitly ignoring process/resource limits advertised by the server. SHALL and MUST have the same meaning according to RFC 2119. > - Section 4: It seems like a good place to reiterate that LITERAL+ > SHOULD NOT be used, even if APPENDLIMIT is available, since there may > be other reasons why a server would reject an APPEND and the client > should only proceed with APPENDs only when the initial "handshake" has > been accepted by the server. APPEND is a place where we probably need > the extra round-trip in exchange for preventing potentially large > amounts of bandwidth to be used. Right. Or I can add this text to my update to LITERAL+ (currently expired draft-melnikov-rfc2088bis-00.txt) > - There's discussion of LIST + STATUS (RFC 5819). But this is > actually an addition to STATUS itself. The spec should be written as > extending STATUS, and then a discussion/example of how this can be > used if 5819 is supported. (If we want to force an APPENDLIMIT > client/server to also be LIST-STATUS compliant for performance > reasons, that's fine. But seems to be a policy decision rather than a > technical explanation.) This section is not quite right, but I need to rereview it in more details. _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext