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

[Alexey Melnikov <[e-mail]>]

Hi Barry,

On 10/12/2015 19:10, Barry Leiba wrote:
> Hi, Narendra, and thanks for the responses.  I'm eliminating all the
> things we're in agreement on, so we can discuss the others a bit.
  [snip]
> On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy<[e-mail]>  wrote:
>> The proposal that a client MUST avoid LITERAL+/NSLs presumes there is a
>> limit when in fact there may actually not be one.  Of course there is always
>> a finite limit, but there may be no policy limit.  In fact we don't plan to
>> implement the limit as we've never had a request for it and don't see a need
>> to deny authenticated users from appending a mail (and see some dangers in
>> that).
>>
>> I think MAY works in that it proposes a strategy, and doesn't confuse issues
>> with servers that already implement LITERAL+ but not a limit.  Otherwise you
>> may be placing a new requirement on old software to police the new MUST, or
>> implementing the limit places addition requirements to alter behaviour of
>> LITERAL+ support to enforce this which IMO over-complicates it.
> But the point of the use of LITERAL+ with APPEND isn't just about this
> spec and overall limits -- it's about whether we should use LITERAL+
> with APPEND *at all*.  There are other reasons that any particular
> APPEND might fail, and one point of using literals (and *never*
> allowing quoted strings, for example) is exactly to give the server a
> chance to say "NO" to the APPEND *before* the message data is shipped
> over.  Using LITERAL+ for APPEND data violates that.
>
> It was always the intent of LITERAL+ that it be used as a way to
> eliminate the extra round trip on short strings, where the OK from the
> server isn't necessary -- such as for username and password at login,
> or for mailbox names in various places (including the mailbox name in
> an APPEND command.
>
> My point here is that we now have an opportunity to stress this: that
> it's not a generally good idea to use LITERAL+ for the message data in
> an APPEND command, because it doesn't give the server the opportunity
> to say, "OK, yes, go ahead and send me the message."
No strong preference, but would it be better to stress that in the 
2088bis draft?
> I'm absolutely willing to accept that "MUST NOT" use LITERAL+ for that
> is too strong.  But I'm still going to hold out for "SHOULD NOT", and
> would like to continue the discussion of why you disapprove.
  [snip]
>> "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.
> "Is considered to be" is not useful specification language.  If you
> want this to affect what clients or servers do, you should word this
> in terms that more specifically tell them what you want them to do.
> Please come up with a better way to say what you really mean here.
>
> Let me take a stab, and you can see if this has the right sense (edit
> as appropriate, of course):
>
> OLD
>     STATUS APPENDLIMIT is considered to be fast and there is no need to
>     evaluate remaining quotas (if any) when returning APPENDLIMIT values.
>     APPEND can still fail due to ACL and quota related issues, even if the
>     message being appended is smaller than the APPENDLIMIT.
>
> NEW
>     Computing the APPENDLIMIT should be fast, and need not take ACLs,
>     quotas, and other such information into account.  The APPENDLIMIT
>     specifies one part of the policy, but an APPEND command can still fail
>     due to issues related to ACLs and quotas issues, even if the message
>     being appended is smaller than the APPENDLIMIT.
>
> END
I like this.
> Also, why is this in Section 4, rather than in, say, a Section 3.3?
> It has nothing to do with the APPEND response, which is the subject of
> Section 4.