Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
Jayantheesh S B <j.sb@sea.samsung.com> Wed, 09 December 2015 00:21 UTC
Return-Path: <j.sb@sea.samsung.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082D91B29F3; Tue, 8 Dec 2015 16:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOS525d7xvV9; Tue, 8 Dec 2015 16:21:16 -0800 (PST)
Received: from wguard02.sdsamerica.net (bware2.sdsamerica.net [206.67.236.192]) by ietfa.amsl.com (Postfix) with ESMTP id 367141B2A17; Tue, 8 Dec 2015 16:21:10 -0800 (PST)
From: Jayantheesh S B <j.sb@sea.samsung.com>
To: Barry Leiba <barryleiba@computer.org>, "draft-ietf-imapapnd-appendlimit-extension@ietf.org" <draft-ietf-imapapnd-appendlimit-extension@ietf.org>
Thread-Topic: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
Thread-Index: AQHRMRx9gijbZuD2bkC3YmuL4+ER+J7BzChw
Date: Wed, 09 Dec 2015 00:21:07 +0000
Message-ID: <c0d6f2fc05ca41438aa2147898fab2de@SEAMBX01.sea.samsung.com>
References: <CALaySJLE_6+vbeB-SeMk1VHDAtq2VvS9yKe9dhQ2LTzr4y=oTg@mail.gmail.com>
In-Reply-To: <CALaySJLE_6+vbeB-SeMk1VHDAtq2VvS9yKe9dhQ2LTzr4y=oTg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: none
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/42LWxRTwkIqvAFFIyclEJ2cYo6s>
Cc: "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2015 00:21:19 -0000
Dear Barry, Thanks for the detailed review. We will address all your comments and release the updated document. Regards, Jay -----Original Message----- From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Monday, December 07, 2015 1:24 PM To: draft-ietf-imapapnd-appendlimit-extension@ietf.org Cc: imapext@ietf.org Subject: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 Here's my AD review of draft-ietf-imapapnd-appendlimit-extension-06. There are a lot of issues I'd like addressed or discussed with me -- please do discuss anything you don't agree with or feel you need to talk over. I'm going to put this into "Revised I-D Needed" substate while we work this out. There's one really substantive issue I have with the protocol (the rest of this is editorial stuff, albeit significant editorial stuff). The substantive issue is this: Suppose my server supports APPENDLIMIT, and wants to advertise that to the client, but there's no global limit. So it says "APPENDLIMIT" in response to CAPABILITY, without giving a number. Good. Now you're requiring that there be a limit on every mailbox -- the protocol provides no way to tell the client that there's no limit on this mailbox. Why is that not a problem? Overall, this document could use a going-over for proper English -- use of articles, punctuation, that sort of thing. The RFC Editor will do that, of course, but it'd be good for someone from the working group to do it, to make sure that the meaning remains correct. There's a lot of editing needed here. (It also doesn't help that you didn't use the typical tools, such as xml2rfc, which make sure that things are in a common format/layout.) -- Abstract -- "This memo defines an extension to the IMAP service whereby a server can advertise its capability, to support maximum mail upload size using CAPABILITY, STATUS and LIST commands." We have to stop the "this memo" stuff; please call it a "document". And the extension isn't about a capability; it's about a policy. The abstract should say why it's useful to do this, and doesn't need to list what IMAP commands are affected. I suggest this: NEW This document defines an extension to the IMAP service whereby a server can inform a client about a maximum mail upload size, allowing the client to avoid sending APPEND commands that will fail because the messages are too large. END -- Introduction -- IMAP already provides a mechanism for avoiding the overhead of sending too-large APPEND data: synchronizing literals. The problem that this is meant to resolve is caused specifically when APPEND commands use the non-synchronizing literals extension, and the Introduction should say that. -- Section 2 -- "An IMAP server that supports APPENDLIMIT extension advertises this by including the name APPENDLIMIT in its capability list. IMAP server MAY advertise this capability after user has logged in." This says nothing about whether the server is allowed to advertise the capability before the user has logged in. I also don't think this is an appropriate use of 2119 "MAY". If you mean, "The IMAP server MUST NOT advertise this capability until after the user has logged in," then you should say it that way. (And if that's not what you mean, please discuss it with me and clarify.) "APPENDLIMIT capability without any value indicates that the IMAP server has specific upload limit for different mailboxes." Isn't it possible that the server might still have the same limit for all mailboxes, but just doesn't know that up front? Isn't it also possible that the server might have no limit at all for some (or all) mailboxes, but is just indicating support for the extension and *allowing* for limits? Maybe this?: NEW The APPENDLIMIT capability without any value indicates that the IMAP server supports this extension, and that the client will need to discover upload limits for each mailbox, which might differ from mailbox to mailbox. END -- Section 3 -- "In this case, client can issue STATUS or LIST in combination with STATUS command, if the server supports LIST-STATUS capability, to get the per mailbox specific limit." I find this to be a very confusing sentence, perhaps partly because of the punctuation. But I also think it's not necessary, because you already said (in Section 2) what the client needs to do, and the subsections say what changes are made to the protocol. So: NEW The following subsections describe the changes to the STATUS and LIST commands in support of this situation. END -- Section 3.1 -- "IMAP server MUST return the mailbox name that matches the STATUS specification and the requested mailbox status information." What does this mean? Are you saying that the mailbox name is part of the STATUS response? That's in RFC 3501, and doesn't belong here. I don't think you need that paragraph at all, unless you're trying to say something else that I don't understand. -- Section 3.2 -- You have "LIST-STATUS" in the section title, but nothing is actually called "LIST-STATUS" (it's just the name of the IMAP capability string that RFC 5819 uses). I think a better section title here would be "3.2 STATUS response in the LIST command". Which would then mean that the previous section title should be "3.1 STATUS response in the STATUS command". "IMAP client can issue LIST in combination with STATUS command to get the mailbox specific upload value, if the server supports LIST-STATUS extension." This is not anything "in combination with STATUS command"; this is using the STATUS return option on the LIST command. Also, you do need your citation to 5819 here, rather than waiting. NEW If the server advertises the LIST-STATUS capability [RFC5819], the client can issue LIST in combination with the STATUS return option to get the mailbox-specific upload value. END "IMAP server MUST recognize an extra "RETURN (STATUS (APPENDLIMIT))" at the end of a LIST command and emit an extra STATUS response for each matching mailbox." There's nothing "extra" here: NEW The IMAP server MUST recognize the APPENDLIMIT attribute and emit include an appropriate STATUS response for each matching mailbox. END "Refer [RFC5819] for the usage of LIST in combination with STATUS command." You can now eliminate that sentence, because you already have the 5819 citation (above). "If the server does not support this extension, then client should use STATUS command instead." The antecedent to "this" isn't clear. Say "If the server does not support the STATUS return option on the LIST command, then the client should use the STATUS command instead." -- Section 4 -- "Client can avoid use of LITERAL+ [RFC2088], when maximum upload size supported by the IMAP server is unknown." What? Don't you mean "The client SHOULD avoid"? I'd even use this as an opportunity to make it firmer, and say "The client MUST avoid". No? If not, why not? And please don't say "LITERAL+"; please say "non-synchronizing literals". (We should use capability strings only when we're talking about what's in the CAPABILITY response.) "STATUS APPENDLIMIT is considered to be fast" What does that mean? Is this meant to be advice to the server, to make sure that it *is* fast? If so, then say it more that way. If not, then please tell me what it's supposed to mean. -- Section 5 -- "Except as noted otherwise, all alphabetic characters are case- insensitive." There's nowhere that it's noted otherwise, so please eliminate that phrase. "APPENDLIMIT=0 indicates the server SHALL NOT accept APPEND command due to size restriction." That's an incorrect use of 2119 "SHALL NOT". The "due to size restriction" is also a bit odd here. Also also, I presume you want this to apply to "APPENDLIMIT=0" in the CAPABILITY response and *also* "APPENDLIMIT 0" in the STATUS response, yes? I would just say this: NEW An APPENDLIMIT number of 0 indicates the server will not accept any APPEND commands at all for the affected mailboxes. END "The syntax of the parameter follows the augmented BNF notation of [RFC5234]." Why is this here? Didn't you already say it above? "If this capability is omitted, no information is conveyed about the server's fixed maximum mail upload size." Why is this here? It needs to be in Section 2, not here. -- Section 6 -- "The IMAP APPENDLIMIT extension described in this document can conceivably be used to facilitate Denial-of-Service attacks. Specifically, the information contained in the APPENDLIMIT capability and use of the APPEND command make it somewhat quicker and easier to devise an efficacious Denial-of-Service attack." What? How? If it's true (it might be, but you haven't said), then you should explain it. "In addition, no issues are addressed involving trusted systems and possible release of information via the mechanisms described in this document." What does this mean, and why is it here? "IMAP APPENDLIMIT extension doesn't add any new security considerations that are not already present in the base IMAP protocol [RFC3501]." Doesn't the presence of the first paragraph belie that? -- Section 7 -- "IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at: http://www.iana.org/assignments/imap-capabilities This document requests that IANA adds "APPENDLIMIT" capability pointing to this document to the above registry." You don't need to tell IANA how capabilities are registered, and this is an oddly worded way to do it anyway. Just ask them to register the item: NEW IANA is asked to add "APPENDLIMIT" to the IMAP Capabilities registry, using this document as its reference. END (You can also include the URL if you like, but it's not really needed in this case.) -- Section 8.2 -- The Section title is malformed (there's a space in "8. 2"), which is what's causing the "missing reference" warning from IDnits. Please fix that. -- Barry _______________________________________________ imapext mailing list imapext@ietf.org https://www.ietf.org/mailman/listinfo/imapext
- [imapext] AD review of draft-ietf-imapapnd-append… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- [imapext] Referencing RFC 2088 (was: AD review of… S Moonesamy
- Re: [imapext] Referencing RFC 2088 Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] Referencing RFC 2088 S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Bron Gondwana
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba