Re: AD review of draft-ietf-imapapnd-appendlimit-extension-06

Hi,

On 09/12/2015 16:52, Narendra Bisht wrote:
> Please find answers in-lined.
> We are working on a new version, will update soon.
>
> Thanks & Regards
> - Naren
>
> -----Original Message-----
> From: imapext [mailto:[email protected]] On Behalf Of Barry Leiba
> Sent: Monday, December 07, 2015 1:24 PM
> To: [email protected]
> Cc: [email protected]
> 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?
Pick a very big number for such a mailbox? 2^31-1?
> [Naren] This draft is to publish the APPENDLIMIT, if there is any. If you accept any size then there is no need to publish this policy.
  [snip]
> -- 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.)
>
> [Naren] We purposefully marked it as a MAY, because it alerts implementations to the possibility, but doesn't have any effect in interoperability.
> What we mean here is client should be ready to handle this no matter when the capability is sent.
+1.
> "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.
>
> [Naren] It's not an advice to the server, we are trying to convey that this approach is considered to be faster than evaluating the remaining quota for a mailbox.
There is similar text in RFC 3501. I actually think this is an important 
implementation consideration, because if one has 10,000 mailboxes and 
STATUS APPENDLIMIT takes non trivial amount of time, getting a response 
from server might take a rather long time.
> -- 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.
>
> [Naren] Ok
Should we still keep "All alphabetic characters are case-insensitiv"? 
Not many people remember that about ABNF.

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