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

From: Barry Leiba <[email-masked]>
Date: Mon, 7 Dec 2015 13:24:09 -0500

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Dec 2015 09:10:44 -0500

One thing I'd like to follow up on:

> There's a lot of editing needed here.

On thinking about this more and talking it over with SM...
There are two important reasons we might ask a native English speaker
to go over a document for this:
1. If the English usage is sufficiently unclear that we're concerned
that it couldn't get properly reviewed.  This is NOT the case with
this document.
2. If the editing would be sufficiently extensive that we're concerned
that when the RFC Editor makes the changes, subtle changes to the
meaning might happen, and they might go unnoticed.  This is what I'm
concerned about.

Given that (1) is not a concern, we think we can let this point go,
and just make sure we re-review carefully during the AUTH48 stage
(after the RFC Editor has done their work).  I'm sure the authors will
do that, and SM and I will also.  Alexey has also volunteered to check
it during AUTH48 (thanks, Alexey).  I think that's a good set of
reviewers, and I think we'll be OK.

Barry

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Dec 2015 07:05:57 -0800

Hi Jay, Naren, Alexey,

Although I did not mention all the working group participants by 
name, please comment if you have an opinion about this.

>about what's in the CAPABILITY response.)

draft-ietf-imapapnd-appendlimit-extension-06 references RFC 
2088.  Alexey is editing the second draft of the Working Group.  That 
draft proposes to replace RFC 2088 and obsolete it in a few months 
(if there is agreement to do that).

The alternatives are:

   (a) Keep the reference to RFC 2088

   (b) Change the reference to draft-ietf-imapapnd-rfc2088bis

If draft-ietf-imapapnd-rfc2088bis does not become an RFC, the 
reference can be changed back to RFC 2088.  The impact on 
draft-ietf-imapapnd-appendlimit-extension is that its publication as 
a RFC will be delayed until draft-ietf-imapapnd-rfc2088bis is 
published as a RFC.

Which alternative do you prefer?

Regards,
S. Moonesamy (as document shepherd)

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Dec 2015 15:37:23 +0000

Hi SM,

On 08/12/2015 15:05, S Moonesamy wrote:
> Hi Jay, Naren, Alexey,
>
> Although I did not mention all the working group participants by name, 
> please comment if you have an opinion about this.
>
> draft-ietf-imapapnd-appendlimit-extension-06 references RFC 2088. 
> Alexey is editing the second draft of the Working Group.  That draft 
> proposes to replace RFC 2088 and obsolete it in a few months (if there 
> is agreement to do that).
>
> The alternatives are:
>
> draft-ietf-imapapnd-appendlimit-extension is that its publication as a 
> RFC will be delayed until draft-ietf-imapapnd-rfc2088bis is published 
> as a RFC.
>
I slightly prefer to have a reference to draft-ietf-imapapnd-rfc2088bis, 
but if draft-ietf-imapapnd-rfc2088bis takes too long (we can discuss 
what exactly that means ;-)), I would be Ok with switching back to RFC 2088.

Best Regards,
Alexey

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 08 Dec 2015 21:31:48 +0000

------ Original Message ------
From: "S Moonesamy" <[email-masked]>
To: "[email-masked]" <[email-masked]>; "Jayantheesh S B" 
<[email-masked]>; "Narendra Bisht" <[email-masked]>; 
"Alexey Melnikov" <[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>; "Barry Leiba" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 9/12/2015 4:05:57 a.m.
Subject: [imapext] Referencing RFC 2088 (was: AD review of 
draft-ietf-imapapnd-appendlimit-extension-06)

>>opportunity to make it firmer, and say "The client MUST avoid".  No?

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.

  Adrien

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 9 Dec 2015 00:21:07 +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:[email-masked]] On Behalf Of Barry Leiba
Sent: Monday, December 07, 2015 1:24 PM
To: [email-masked]
Cc: [email-masked]
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

-- 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

-- 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

-- 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

"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."

NEW

"Refer [RFC5819]

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.)

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."

"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

"The syntax of the

"If this
 capability is omitted, no information is conveyed about the server's  fixed maximum mail upload size."

-- 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?

"In addition, no
 issues are addressed involving trusted systems and possible release  of information via the mechanisms described in this document."

"IMAP APPENDLIMIT extension doesn't add any new security considerations  that are not already present in the base IMAP protocol [RFC3501]."

-- Section 7 --

"IMAP4 capabilities are registered by publishing a standards track or  IESG approved experimental RFC.  The registry is currently located at:

 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

(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
[email-masked]
https://www.ietf.org/mailman/listinfo/imapext

---

From: Narendra Bisht <[email-masked]>
Date: Wed, 9 Dec 2015 16:52:30 +0000

Please find answers in-lined.
We are working on a new version, will update soon.

Thanks & Regards
- Naren

-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Monday, December 07, 2015 1:24 PM
To: [email-masked]
Cc: [email-masked]
Subject: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

[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. 

[Naren] We will provide a xml document going forward.

-- Abstract --

I suggest this:

NEW

[Naren] Fine

-- Introduction --

[Naren] we will address this in the next version.
-- Section 2 --

[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.

Maybe this?:

NEW

[Naren] This is fine
-- Section 3 --

NEW

[Naren] Fine
-- Section 3.1 --

What does this mean?

[Naren] We will remove the redundant info here.
-- 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".

[Naren] Fine, we will change the title accordingly.
"IMAP client can issue LIST in combination with STATUS command to get  the mailbox specific upload value, if the server supports LIST-STATUS  extension."

NEW

[Naren] Fine.

NEW
[Naren] Fine

[Naren] Fine
-- Section 4 --

What?

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.)
 [Naren] We will change it to a MUST, as well we will use NSL in place of LITERAL+ 

What does that 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.  
-- Section 5 --

[Naren] Ok

NEW

[Naren] Fine

"The syntax of the

"If this

[Naren] ok

-- Section 6 --

What?  How?

[Naren] What we meant here is that using this extension it will easy and quicker to get the upload limit and using that limit against the server.

"In addition, no

-- Section 7 --

NEW

[Naren] Fine

-- Section 8.2 --
[Naren] Sure
--
Barry

---

From: S Moonesamy <[email-masked]>
Date: Wed, 09 Dec 2015 10:13:42 -0800

Hi Jay, Naren,
At 07:37 08-12-2015, Alexey Melnikov wrote:
>I slightly prefer to have a reference to 
>draft-ietf-imapapnd-rfc2088bis, but if 
>draft-ietf-imapapnd-rfc2088bis takes too long (we can discuss what 
>exactly that means ;-)), I would be Ok with switching back to RFC 2088.

As nobody else expressed a preference I suggest changing the 
reference from RFC 2088 to draft-ietf-imapapnd-rfc2088bis.  As a note 
for myself, I'll have to update the document shepherd write-up to explain this.

There is a comment from Adrien de Croy at 
http://www.ietf.org/mail-archive/web/imapext/current/msg05639.html 
Could you please reply to that comment?

Regards,

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Dec 2015 18:51:01 +0000

Hi,

> 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,…
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]
> What we mean here is client should be ready to handle this no matter when the capability is sent.
+1.
> [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.
> There's nowhere that it's noted otherwise, so please eliminate that phrase.
Should we still keep "All alphabetic characters are case-insensitiv"? 
Not many people remember that about ABNF.

---

From: Naren <[email-masked]>
Date: Wed, 9 Dec 2015 18:19:56 -0500

I agree with Adrien, on this.
I think MAY will be more appropriate here.

On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <[email-masked]> wrote:

> To: "[email-masked]" <[email-masked]>; "Jayantheesh S B" <
> [email-masked]>; "Narendra Bisht" <[email-masked]>;
> Cc: "[email-masked]" <
> [email-masked]>; "Barry Leiba" <
> [email-masked]>; "[email-masked]" <[email-masked]>
> 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).
>

-- 
Thanks & Regards
-Narendra

---

From: S Moonesamy <[email-masked]>
Date: Wed, 09 Dec 2015 22:54:23 -0800

Hi Naren,
At 08:52 09-12-2015, Narendra Bisht wrote:
>-- 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,"
>[Naren] We purposefully marked it as a MAY, because it alerts 
>implementations to the possibility, but doesn't have any effect in 
>interoperability.

Barry highlighted that the MAY can be interpreted in two ways:

   1. The IMAP server must not advertise this capability until after the user
      has logged in.

   2. The IMAP server may advertise this capability after the user 
has logged in.

Your explanation could be read as meaning that:

   (a) The IMAP server can advertise this capability before the user 
has logged in.

   (b) The IMAP server can advertise this capability after the user 
has logged in.

Does the second sentence in the first paragraph of Section 2 mean (a) and (b)?

Regards,

---

From: Naren <[email-masked]>
Date: Thu, 10 Dec 2015 10:52:37 -0500

Yes, you right SM.

Our MAY means
(a) The IMAP server can advertise this capability before the user has
logged in.
*OR*
(b) The IMAP server can advertise this capability after the user has logged
in.

Thanks
-Naren

On Thu, Dec 10, 2015 at 1:54 AM, S Moonesamy <[email-masked]> wrote:

>> including the name APPENDLIMIT in its capability list. IMAP server  MAY
>> advertise this capability after user has logged in."
>>
>> 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,"
>   2. The IMAP server may advertise this capability after the user has
> logged in.
>
>   (a) The IMAP server can advertise this capability before the user has
> logged in.
>
>   (b) The IMAP server can advertise this capability after the user has
> logged in.
>

-- 
Thanks & Regards
-Narendra

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Dec 2015 08:32:49 -0800

Hi Naren,
At 07:52 10-12-2015, Naren wrote:
>OR

Based on the AD review [1] and the short discussion about that 
sentence in Section 2, my opinion is that the intent of the what is 
written in the draft is not clear.  What are the implications of (a) 
and (b)?  What if the IMAP server advertises that there is a limit 
which applies to all mailboxes before the user has logged in?

Regards,

1. http://www.ietf.org/mail-archive/web/imapext/current/msg05633.html

---

From: Naren <[email-masked]>
Date: Thu, 10 Dec 2015 12:15:13 -0500

Hi SM,

We can rephrase that sentence to

"IMAP server MAY advertise this CAPABILITY before or after user has logged
in.The client SHOULD be ready to handle this CAPABILITY irrespective of
user authenticated state"

We do not see any implications in this being advertised before user logged
in.
Can you elaborate more about your concern on this.

Thanks

On Thu, Dec 10, 2015 at 11:32 AM, S Moonesamy <[email-masked]> wrote:

> Based on the AD review [1] and the short discussion about that sentence in
> Section 2, my opinion is that the intent of the what is written in the
> draft is not clear.  What are the implications of (a) and (b)?  What if the
> IMAP server advertises that there is a limit which applies to all mailboxes
> before the user has logged in?
>
> Regards,

-- 
Thanks & Regards
-Narendra

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Dec 2015 17:17:45 +0000

On 10/12/2015 17:15, Naren wrote:
> "IMAP server MAY advertise this CAPABILITY before or after user has 
> logged in.The client SHOULD

IMHO, this is not correct use of SHOULD. The client that doesn't support 
both is broken. I suggest you replace SHOULD with "needs to" or the like.

> be ready to handle this CAPABILITY irrespective of user authenticated 
> state"
>
> We do not see any implications in this being advertised before user 
> logged in.
> On Thu, Dec 10, 2015 at 11:32 AM, S Moonesamy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Naren,
>         (a) The IMAP server can advertise this capability before the
>         user has logged in.
>         OR
>         (b) The IMAP server can advertise this capability after the
>         user has logged in.
>
>
>     sentence in Section 2, my opinion is that the intent of the what
>     is written in the draft is not clear.  What are the implications
>     of (a) and (b)?  What if the IMAP server advertises that there is
>     a limit which applies to all mailboxes before the user has logged in?
>
>     Regards,

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Dec 2015 17:19:53 +0000

> which applies to all mailboxes before the user has logged in?
The it means that the limit applies to all users. However the server can 
also return another limit for some users after logging in, which will 
override the globally announced limit. So it is not OR, but AND/OR.

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 10 Dec 2015 17:26:52 +0000

I agree with Alexey.  So the updated text looks like

"IMAP server MAY advertise this CAPABILITY before or after user has logged in. The client needs to be ready to handle this CAPABILITY irrespective of user authenticated state."

From: imapext [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Thursday, December 10, 2015 12:18 PM
To: Naren; S Moonesamy
Cc: Narendra Bisht; [email-masked]; Barry Leiba; [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 (Section 2)

Hi SM,

"IMAP server MAY advertise this CAPABILITY before or after user has logged in.The client SHOULD

IMHO, this is not correct use of SHOULD. The client that doesn't support both is broken. I suggest you replace SHOULD with "needs to" or the like.

be ready to handle this CAPABILITY irrespective of user authenticated state"

We do not see any implications in this being advertised before user logged in.
Can you elaborate more about your concern on this.

Thanks

On Thu, Dec 10, 2015 at 11:32 AM, S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Naren,
At 07:52 10-12-2015, Naren wrote:
Our MAY means
(a) The IMAP server can advertise this capability before the user has logged in.
OR
(b) The IMAP server can advertise this capability after the user has logged in.

Based on the AD review [1] and the short discussion about that sentence in Section 2, my opinion is that the intent of the what is written in the draft is not clear.  What are the implications of (a) and (b)?  What if the IMAP server advertises that there is a limit which applies to all mailboxes before the user has logged in?

Regards,

--
Thanks & Regards
-Narendra

imapext mailing list

[email-masked]<mailto:[email-masked]>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Dec 2015 10:24:15 -0800

Hi Naren,
At 09:15 10-12-2015, Naren wrote:
>logged in.The client SHOULD be ready to handle this CAPABILITY 
>irrespective of user authenticated state"
>

By implications, I meant:

   (i)  What are the advantages of advertising the upload limit before the user
        has logged in?

   (ii) What are the disadvantages of advertising the upload limit before the
        user has logged in?

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Dec 2015 14:10:28 -0500

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.

> [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.

I think you missed my point.

The situation I'm talking about is this:

- The server has no global limit, so no number is advertised on the
CAPABILITY response.  The spec says, therefore, that per-mailbox
limits have to be advertised on, say, STATUS commands.  Fine.

- There's a limit of, say, 50,000 for INBOX.  So when I do STATUS
INBOX (APPENDLIMIT), the server responds with "* STATUS INBOX
(APPENDLIMIT 50000)".  Fine.

- But there's no limit on the "Stuff-to-save" mailbox.  No limit at all.

How does the server respond when I do "STATUS Stuff-to-save
(APPENDLIMIT)" ?  Why is it not a problem that the spec doesn't answer
this question?

> when the capability is sent.

Great, and I saw the discussion in the other thread.  My sense here is
that 2119 key words aren't appropriate for this at all: there's no
choice here that needs a "MAY" -- you're just talking about how the
protocol works when this option is in effect:

NEW
An IMAP server that supports APPENDLIMIT extension advertises this by
including the name APPENDLIMIT in its capability list in Authenticated
state.  The server may also advertise this extension before the user has
logged in.
END

(With this formulation, if you really want to say "MAY" in the last
sentence, I won't object further.

> 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?
>
>  [Naren] We will change it to a MUST

Hold off on this, because there's still discussion based on Adrian's
message in another thread... which I'll bring back here:

On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <[email-masked]> wrote:
> 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."

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.

> 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

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.

> What?  How? If it's true (it might be, but you haven't said), then you
> should explain it.
>
> [Naren] What we meant here is that using this extension it will easy
> and quicker to get the upload limit and using that limit against the
> server.

Why?  I don't understand why that helps anyone mount an attack.  And
in any case, it needs to be explained here in the document.

Barry

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Dec 2015 12:34:45 -0800

Hi Alexey, Naren,
At 09:19 10-12-2015, Alexey Melnikov wrote:
>The it means that the limit applies to all users. However the server 
>can also return another limit for some users after logging in, which 
>will override the globally announced limit. So it is not OR, but AND/OR.

This is from Section 2:

   C: t1 CAPABILITY
   S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
   S: t1 OK foo

The explanation (above that text in the draft) says that 257890 is 
for all mailboxes.  In Section 3 there is the following:

   "IMAP server can have mailbox specific APPENDLIMIT value, which
    will not be advertised as part of CAPABILITY response."

Won't the IMAP client assume that the IMAP server would not have 
advertised "257890" as the limit if there is a mailbox specific 
APPENDLIMIT value?

Regards,
S. Moonsamy (as document shepherd)

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 10 Dec 2015 21:39:10 +0000

Dear SM,

Please find our response inline. 

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Thursday, December 10, 2015 1:24 PM
To: Naren; [email-masked]
Cc: Narendra Bisht; [email-masked]; Barry Leiba
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 (Section 2)

Hi Naren,

[Jay]  One advantage I can think of is.
 A server can have a customized APPENDLIMIT for different users (based on some SLA).
 The server advertises a static APPENDLIMIT before user logs in, to display it support for the extension.
After user logged in then server can show the user specific APPENDLIMIT.

[Jay] I don't see any disadvantage in sending the limit before user logged in. 

Regards,
S. Moonesamy

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 10 Dec 2015 22:39:40 +0000

Hi Barry,

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 10, 2015 2:10 PM
To: Narendra Bisht; Adrien de Croy
Cc: [email-masked]; [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

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.

- The server has no global limit, so no number is advertised on the CAPABILITY response.  The spec says, therefore, that per-mailbox limits have to be advertised on, say, STATUS commands.  Fine.

- There's a limit of, say, 50,000 for INBOX.  So when I do STATUS INBOX (APPENDLIMIT), the server responds with "* STATUS INBOX (APPENDLIMIT 50000)".  Fine.

How does the server respond when I do "STATUS Stuff-to-save (APPENDLIMIT)" ?  Why is it not a problem that the spec doesn't answer this question?

[Jay] We understood the situation. In this case we can have a big value to the APPENDLIMIT, like 2^32 - 1.
We can have it documented. We can have a line like:
"If server decides not to have any upload limit for a mailbox, then it can have a huge number set for APPENDLIMIT"

> when the capability is sent.

Great, and I saw the discussion in the other thread.  My sense here is that 2119 key words aren't appropriate for this at all: there's no choice here that needs a "MAY" -- you're just talking about how the protocol works when this option is in effect:

NEW
An IMAP server that supports APPENDLIMIT extension advertises this by including the name APPENDLIMIT in its capability list in Authenticated state.  The server may also advertise this extension before the user has logged in.
END

(With this formulation, if you really want to say "MAY" in the last sentence, I won't object further.

[Jay] OK
>  [Naren] We will change it to a MUST

Hold off on this, because there's still discussion based on Adrian's message in another thread... which I'll bring back here:

On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <[email-masked]> 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).
>
> 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

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."

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.

[Jay] "SHOULD NOT" looks reasonable to me, as per the above explanation.

> 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

NEW

END
[Jay] Fine

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.

[Jay] Alright
> and quicker to get the upload limit and using that limit against the 

Why?  I don't understand why that helps anyone mount an attack.  And in any case, it needs to be explained here in the document.

[Jay] If the APPENDLIMIT is known beforehand, it's easy to overwhelm server with huge data which is beyond the APPENDLIMIT.
This might facilitate  Denial-of-Service attacks.
Makes sense?

> What does this mean, and why is it here?

[Jay] We will remove this
> Doesn't the presence of the first paragraph belie that?
[Jay] Yes, we will modify accordingly

Barry

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Dec 2015 15:11:56 -0800

Hi Jay, Naren,
>[Jay] I don't see any disadvantage in sending the limit before user logged in.

I'll quote from 
http://www.ietf.org/mail-archive/web/imapext/current/msg05657.html

   "If the APPENDLIMIT is known beforehand, it's easy to overwhelm server with
    huge data which is beyond the APPENDLIMIT.  This might facilitate
    Denial-of-Service attacks.
    Makes sense?"

Is that as a disadvantage (question (ii))?  Barry asked why that 
helps anyone mount an attack.  The above reply says that it is easy 
to overwhelm the IMAP server if the (APPENDLIMIT) value is known 
beforehand.  Why should the IMAP server advertise the value before 
the user logs in when it can easily be used to generate an attack?

Regards,

---

From: Stu Brandt <[email-masked]>
Date: Thu, 10 Dec 2015 18:14:11 -0500

Barry -

On the issue of "there's no limit on this mailbox", doesn't the IMAP 
protocol itself establish an append size limit through rfc3501 BNF alone?

literal         = "{" number "}" CRLF *CHAR8

number          = 1*DIGIT
                     ; Unsigned 32-bit integer
                     ; (0 <= n < 4,294,967,296)

This would support the notion of advertising APPENDLIMIT=4294967295 for 
those who *claim* to have no limit since ultimately there *is* a limit.

- Stuart

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 10 Dec 2015 23:26:04 +0000

Dear SM,

Regards,
Jay
-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Thursday, December 10, 2015 6:12 PM
To: Jayantheesh S B; Naren; [email-masked]
Cc: Narendra Bisht; [email-masked]; Barry Leiba
Subject: RE: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 (Section 2)

Hi Jay, Naren,

I'll quote from

Is that as a disadvantage (question (ii))?  Barry asked why that helps anyone mount an attack.  The above reply says that it is easy to overwhelm the IMAP server if the (APPENDLIMIT) value is known beforehand.  Why should the IMAP server advertise the value before the user logs in when it can easily be used to generate an attack?

[Jay] Yes, what you say is correct. But, even if user knows the APPENDLIMIT before log-in, user needs to be in authenticated state to perform any APPEND related operations for any potential attack.

Regards,

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 10 Dec 2015 23:51:11 +0000

please don't further entrench the hard MAX_INT32 limit on message size, 
it will have to be overturned eventually.  4GB gets smaller every day.

------ Original Message ------
From: "Stu Brandt" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 11/12/2015 12:14:11 p.m.
Subject: Re: [imapext] AD review of 
draft-ietf-imapapnd-appendlimit-extension-06

>number = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n < 
>4,294,967,296)This would support the notion of advertising 
>APPENDLIMIT=4294967295 for those who *claim* to have no limit since 
>ultimately there *is* a limit.
>
>- Stuart
>
>>Hi Barry, Please find our response inline. Regards, Jay -----Original 
>>Message----- From: imapext [mailto:[email-masked]] On Behalf 
>>Of Barry Leiba Sent: Thursday, December 10, 2015 2:10 PM To: Narendra 
>>Bisht; Adrien de Croy Cc: 
>>[email-masked]; [email-masked] 
>>Subject: Re: [imapext] AD review of 
>>draft-ietf-imapapnd-appendlimit-extension-06 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.
>>>APPENDLIMIT, and wants to advertise that to the client, but there's 
>>>no global limit. So it says "APPENDLIMIT" in response to CAPABILITY, 
>>>problem? [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.
>>I think you missed my point. The situation I'm talking about is this: 
>>CAPABILITY response. The spec says, therefore, that per-mailbox limits 
>>have to be advertised on, say, STATUS commands. Fine. - There's a 
>>limit of, say, 50,000 for INBOX. So when I do STATUS INBOX 
>>(APPENDLIMIT), the server responds with "* STATUS INBOX (APPENDLIMIT 
>>50000)". Fine. - But there's no limit on the "Stuff-to-save" mailbox. 
>>No limit at all. How does the server respond when I do "STATUS 
>>Stuff-to-save (APPENDLIMIT)" ? Why is it not a problem that the spec 
>>doesn't answer this question? [Jay] We understood the situation. In 
>>this case we can have a big value to the APPENDLIMIT, like 2^32 - 1. 
>>We can have it documented. We can have a line like: "If server decides 
>>not to have any upload limit for a mailbox, then it can have a huge 
>>number set for APPENDLIMIT"
>>>-- 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.)
>>>interoperability. What we mean here is client should be ready to 
>>>handle this no matter when the capability is sent.
>>protocol works when this option is in effect: NEW An IMAP server that 
>>supports APPENDLIMIT extension advertises this by including the name 
>>APPENDLIMIT in its capability list in Authenticated state. The server 
>>may also advertise this extension before the user has logged in. END 
>>sentence, I won't object further. [Jay] OK
>>>-- Section 4 -- "Client can avoid use of LITERAL+ [RFC2088], when 
>>>maximum upload size supported by the IMAP server is unknown." What? 
>>>If not, why not? [Naren] We will change it to a MUST
>>message in another thread... which I'll bring back here: On Tue, Dec 
>>8, 2015 at 4:31 PM, Adrien de Croy mailto:[email-masked] wrote:
>>>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.
>>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." 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. [Jay] "SHOULD NOT" looks reasonable to me, as per the 
>>above explanation.
>>>"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* 
>>>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.
>>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 [Jay] Fine 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. [Jay] Alright
>>>-- 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. [Naren] What we meant here is that using this extension 
>>>it will easy and quicker to get the upload limit and using that limit 
>>>against the server.
>>Why? I don't understand why that helps anyone mount an attack. And in 
>>any case, it needs to be explained here in the document. And you 
>>didn't respond to these questions in my review: [Jay] If the 
>>APPENDLIMIT is known beforehand, it's easy to overwhelm server with 
>>Denial-of-Service attacks. Makes sense?
>>>"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?
>>[Jay] Yes, we will modify accordingly Barry 
>>_______________________________________________ imapext mailing list 
>>[email-masked]://www.ietf.org/mailman/listinfo/imapext 
>>_______________________________________________ imapext mailing list 
>>[email-masked]://www.ietf.org/mailman/listinfo/imapext
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 10 Dec 2015 23:53:40 +0000

One thing I'm not clear on.

Is this supposed really to limit the max message size, or just really 
APPEND?  For example would COPY or MOVE trigger this?

If it's really a max size of a message in a folder, it should also apply 
to COPY and MOVE.

And I'd suggest that having a different limit in different folders will 
result in some nasty support calls.

Adrien

------ Original Message ------
From: "Barry Leiba" <[email-masked]>
To: "Narendra Bisht" <[email-masked]>; "Adrien de Croy" 
<[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 11/12/2015 8:10:28 a.m.
Subject: Re: [imapext] AD review of 
draft-ietf-imapapnd-appendlimit-extension-06

>>no
>>by
>>the
>>opportunity
>>a
>>always
>>issues
>>behaviour of
>>fast?  If so, then
>>[RFC3501]."

---

From: Stu Brandt <[email-masked]>
Date: Thu, 10 Dec 2015 19:20:58 -0500

Adrien -

I'm not looking to further entrench it, rather I'm pointing out that as 
long as the BNF itself defines a limit on the size of 'number', then a 
server's claim of having no limit is irrelevant. Such a server could 
express its limitless APPENDLIMIT by referring to the BNF defined 
limit.  I would hope that if/when 'number' as MAX_UINT32 is extended, 
the next logical step would be MAX_UINT64 which itself is yet another 
limit.

- Stuart

On 12/10/15 6:51 PM, Adrien de Croy wrote:
> please don't further entrench the hard MAX_INT32 limit on message 
> size, it will have to be overturned eventually.  4GB gets smaller 
> every day.
> From: "Stu Brandt" <[email-masked] 
> <mailto:[email-masked]>>
> To: "[email-masked]" <[email-masked] <mailto:[email-masked]>>
>> This would support the notion of advertising APPENDLIMIT=4294967295 
>> for those who *claim* to have no limit since ultimately there *is* a 
>> limit.
>>
>> - Stuart
>>
>>> Cc:[email-masked];[email-masked]
>>> On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croymailto:[email-masked]  wrote:

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 11 Dec 2015 00:44:24 +0000

Understood

However I think you'll find some implementations are already 
non-compliant in that they handle larger messages already.  We already 
use 64bits.

I understand at the time that IMAP was written the concept of a 4GB 
message was almost inconceivable, and probably Mark didn't want people 
to use 16bits, but for a protocol that sends numbers as texts with no 
limit on the number of decimal digits being transmitted, it makes no 
sense to set a max size, only a minimum upper limit.  I'm not aware of 
any other protocol (leastwise not in the email space) that uses text to 
send numbers that places a limit like this on the underlying data type 
or width.  In fact the whole benefit of using text is that it frees you 
from that, implementers can choose whatever underlying type they see 
fit, bearing in mind the environment they work in.

I'd suggest if someone wants to advertise no limit, it should use a 
non-numeric keyword, rather than overloading 0, or -1 or whatever which 
flavour of maxint is at the moment.

Adrien

------ Original Message ------
From: "Stu Brandt" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 11/12/2015 1:20:58 p.m.
Subject: Re: [imapext] AD review of 
draft-ietf-imapapnd-appendlimit-extension-06

>>To: mailto:[email-masked] <[email-masked]>
>>>>Hi Barry, Please find our response inline. Regards, Jay 
>>>>-----Original Message----- From: imapext 
>>>>[mailto:[email-masked]] On Behalf Of Barry Leiba Sent: 
>>>>Thursday, December 10, 2015 2:10 PM To: Narendra Bisht; Adrien de 
>>>>Croy Cc: [email-masked]; 
>>>>[email-masked] Subject: Re: [imapext] AD review of 
>>>>draft-ietf-imapapnd-appendlimit-extension-06 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.
>>>>>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? [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.
>>>>I think you missed my point. The situation I'm talking about is 
>>>>this: - The server has no global limit, so no number is advertised 
>>>>on the CAPABILITY response. The spec says, therefore, that 
>>>>per-mailbox limits have to be advertised on, say, STATUS commands. 
>>>>Fine. - There's a limit of, say, 50,000 for INBOX. So when I do 
>>>>STATUS INBOX (APPENDLIMIT), the server responds with "* STATUS INBOX 
>>>>(APPENDLIMIT 50000)". Fine. - But there's no limit on the 
>>>>"Stuff-to-save" mailbox. No limit at all. How does the server 
>>>>respond when I do "STATUS Stuff-to-save (APPENDLIMIT)" ? Why is it 
>>>>not a problem that the spec doesn't answer this question? [Jay] We 
>>>>understood the situation. In this case we can have a big value to 
>>>>the APPENDLIMIT, like 2^32 - 1. We can have it documented. We can 
>>>>have a line like: "If server decides not to have any upload limit 
>>>>for a mailbox, then it can have a huge number set for APPENDLIMIT"
>>>>>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.)
>>>>Great, and I saw the discussion in the other thread. My sense here 
>>>>is that 2119 key words aren't appropriate for this at all: there's 
>>>>no choice here that needs a "MAY" -- you're just talking about how 
>>>>the protocol works when this option is in effect: NEW An IMAP server 
>>>>that supports APPENDLIMIT extension advertises this by including the 
>>>>name APPENDLIMIT in its capability list in Authenticated state. The 
>>>>server may also advertise this extension before the user has logged 
>>>>in. END (With this formulation, if you really want to say "MAY" in 
>>>>the last sentence, I won't object further. [Jay] OK
>>>>>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. 
>>>>>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." 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. [Jay] "SHOULD NOT" looks 
>>>>reasonable to me, as per the above explanation.
>>>>>"STATUS APPENDLIMIT is considered to be fast" What does that mean? 
>>>>>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.
>>>>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 [Jay] Fine 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. [Jay] Alright
>>>>>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. [Naren] What we meant here is that using 
>>>>>this extension it will easy and quicker to get the upload limit and 
>>>>>using that limit against the server.
>>>>in any case, it needs to be explained here in the document. And you 
>>>>>possible release of information via the mechanisms described in 
>>>>>this document." What does this mean, and why is it here?
>>>>>considerations that are not already present in the base IMAP 
>>>>>protocol [RFC3501]." Doesn't the presence of the first paragraph 
>>>>>belie that?

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 11 Dec 2015 16:49:23 +1300

> On 11/12/2015, at 2:27 PM, Stu Brandt <[email-masked]> wrote:
> 
> Wow....so do you already support 18Ebyte appends/fetches?  That's pretty impressive. You must have spent a lot of time on code to ensure streaming between network and storage.

You seem to be confusing size with bandwidth / throughput. 

And just because someone might want to transfer a file just over 4GB doesn't mean they want to transfer a 18EB file. But if someone provisions a system big enough they can do it. If they want to stop that they already have quota. 

Talk to Bill Gates about how his "nobody will ever need more than 640kB RAM" worked out. 

> 
> - Stuart
> 
> 
>> On 12/10/15 7:44 PM, Adrien de Croy wrote:
>> Understood
>>  
>> However I think you'll find some implementations are already non-compliant in that they handle larger messages already.  We         already use 64bits.
>>  
>> I understand at the time that IMAP was written the concept of a 4GB message was almost inconceivable, and probably Mark didn't want people to use 16bits, but for a protocol that sends numbers as texts with no limit on the number of decimal digits being transmitted, it makes no sense to set a max size, only a minimum upper limit.  I'm not aware of any other protocol (leastwise not in the email space) that uses text to send numbers that places a limit like this on the underlying data type or width.  In fact the whole benefit of using text is that it frees you from that, implementers can choose whatever underlying type they see fit, bearing in mind the environment they work in.
>>  
>> I'd suggest if someone wants to advertise no limit, it should use a non-numeric keyword, rather than overloading 0, or -1 or whatever which flavour of maxint is at the moment.
>>  
>> Adrien
>>  
>> To: "Adrien de Croy" <[email-masked]>; "[email-masked]" <[email-masked]>
>>> I'm not looking to further entrench it, rather I'm pointing out that as long as the BNF itself defines a limit on the size of 'number', then a server's claim of having no limit is irrelevant. Such a server could express its limitless APPENDLIMIT by referring to the BNF defined limit.  I would hope that if/when 'number' as MAX_UINT32 is extended, the next logical step would be MAX_UINT64 which itself is yet another limit. 
>>> 
>>> - Stuart
>>> 
>>> 
>>>> please don't further entrench the hard MAX_INT32 limit on message size, it will have to be overturned eventually.  4GB gets smaller every day.
>>>>  
>>>>> On the issue of "there's no limit on this mailbox", doesn't the IMAP protocol itself establish an append size limit through rfc3501 BNF alone?
>>>>> 
>>>>> This would support the notion of advertising APPENDLIMIT=4294967295 for those who *claim* to have no limit since ultimately there *is* a limit.
>>>>> 
>>>>> - Stuart
>>>>> 
>>>>>> On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy mailto:[email-masked] wrote:

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 11 Dec 2015 08:29:14 +0000

> than 640kB RAM" worked out. 

Factually speaking it worked out well; he was right. MS-DOS had various 
constraints, e.g. singletasking, lack of memory protection and the 640k 
limit. The question was whether to raise that limit; 896k would have been 
possible at a cost of some compatibility breaks. Bill said, spread over 
several remarks, "no, let's keep 640k, people are going to upgrade for 
other reasons, not because of the 640k" and in hindsight I think he was 
clearly right.

There's a lesson in that quotation for RFC authors: People are going to 
twist your words around and make you have said stupid things, so watch what 
you write.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Dec 2015 09:20:42 +0000

On 10 December 2015 at 17:19, Alexey Melnikov <[email-masked]>
wrote:

>> Based on the AD review [1] and the short discussion about that sentence
>> in Section 2, my opinion is that the intent of the what is written in the
I feel this is much more confusing than it should be.

If the server gives a pre-auth APPENDLIMIT, but does not give a post-auth
APPENDLIMIT, does this mean that there is a general append limit but it
does not apply to me, or that there is a general append limit and there's
no change for me, or is it an error?

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Dec 2015 09:22:03 +0000

> no change for me, or is it an error?
Also, why would my client care about what append limit other users have?

Dave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 11 Dec 2015 09:32:03 +0000

Dave Cridland writes:
> If the server gives a pre-auth APPENDLIMIT, but does not give a 
> post-auth APPENDLIMIT, does this mean that there is a general 
> append limit but it does not apply to me, or that there is a 
> general append limit and there's no change for me, or is it an 
> error?

Similar questions apply to the relationship between those two sizes and the 
Submission SIZE.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Dec 2015 10:28:33 +0000

On 10/12/2015 23:53, Adrien de Croy wrote:
> APPEND?
Just APPEND.
> For example would COPY or MOVE trigger this?
No. In order to express that limit, there is the QUOTA extension.
> If it's really a max size of a message in a folder, it should also 
> apply to COPY and MOVE.
>
> And I'd suggest that having a different limit in different folders 
> will result in some nasty support calls.
>
> Adrien
>
>
> <[email-masked]>; 
> "[email-masked]" <[email-masked]>
>>> is a
>>> Otherwise you
>>>   issues are addressed involving trusted systems and possible 
>>> release  of information via the mechanisms described in this document."
>>>
>>> protocol [RFC3501]."

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Dec 2015 10:30:33 +0000

On 10/12/2015 23:11, S Moonesamy wrote:
> Is that as a disadvantage (question (ii))?  Barry asked why that helps 
> anyone mount an attack.  The above reply says that it is easy to 
> overwhelm the IMAP server if the (APPENDLIMIT) value is known 
> beforehand.  Why should the IMAP server advertise the value before the 
> user logs in when it can easily be used to generate an attack?
Well, in order to use this limit, one has to login first (APPEND is 
unavailable in unauthenticated state). And once you are logged in, you 
are allowed to know this limit anyway. So I don't think this makes a 
difference.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Dec 2015 10:38:34 +0000

Hi Barry,

  [snip]
> On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy<[email-masked]>  wrote:
No strong preference, but would it be better to stress that in the 
2088bis draft?
  [snip]
>     being appended is smaller than the APPENDLIMIT.
I like this.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Dec 2015 10:39:51 +0000

>   (i)  What are the advantages of advertising the upload limit before 
A server can advertise a limit which applies to all or most users.
>   (ii) What are the disadvantages of advertising the upload limit 
Other than a few extra bytes in the initial CAPABILITY, there are no 
disadvantages I can think of.

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 11 Dec 2015 10:45:25 +0000

------ Original Message ------

>over.  Using LITERAL+ for APPEND data violates that.
OK fair point, the extra round trip for APPEND only isn't that big a 
deal.

Do we need to ad an addenda to LITERAL+ then?

>would like to continue the discussion of why you disapprove.

Happy with the SHOULD NOT.

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 11 Dec 2015 10:56:24 +0000

p.s. it seems pretty common to use LITERAL+ on APPEND, Thunderbird and 
iOS clients do it.  eM Client does not.  No data on others.

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Barry Leiba" <[email-masked]>; "Narendra Bisht" 
<[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 11/12/2015 11:45:25 p.m.
Subject: Re: [imapext] AD review of 
draft-ietf-imapapnd-appendlimit-extension-06

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Dec 2015 14:37:36 +0000

Dave,

On 11/12/2015 09:20, Dave Cridland wrote:
> On 10 December 2015 at 17:19, Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         sentence in Section 2, my opinion is that the intent of the
>         what is written in the draft is not clear.  What are the
>         implications of (a) and (b)? What if the IMAP server
>         advertises that there is a limit which applies to all
>         mailboxes before the user has logged in?
>
>     The it means that the limit applies to all users. However the
>     server can also return another limit for some users after logging
>     in, which will override the globally announced limit. So it is not
>     OR, but AND/OR.
>
>
> post-auth APPENDLIMIT,

To make sure that we are all on the same page, I wrote down rules for 
CAPABILITY responses/response codes. I am sure it is incomplete and 
might be even wrong in some respects, but it should be a start:

<https://datatracker.ietf.org/doc/draft-melnikov-imap-capabilities/?include_text=1>

> does this mean that there is a general append limit but it does not 
> apply to me, or that there is a general append limit and there's no 
> change for me,

Taking into consideration the above, the "no change for me" case.

> or is it an error?

Let's talk about CAPABILITY response codes only (automatically sent by 
the server) and ignore CAPABILITY commands.

<client connects to the server>
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ APPENDLIMIT=4096 STARTTLS 
AUTH=SCRAM-SHA-1] Blah-blah server ready
C: t1 STARTTLS
S: t1 OK
<TLS handshake>
C: t2 AUTHENTICATE ...
  ...
S: t2 OK [CAPABILITY IMAP4rev1 LITERAL+ APPENDLIMIT=8192 STARTTLS 
AUTH=SCRAM-SHA-1] Authenticated

So, the last value always wins. Also, once the server is returned 
APPENDLIMIT, it has to include it in all subsequent CAPABILITY response 
codes. So the server can't just omit the second APPENLIMIT.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Dec 2015 14:42:49 +0000

Hi SM,

On 10/12/2015 20:34, S Moonesamy wrote:
> The explanation (above that text in the draft) says that 257890 is for 
> all mailboxes.  In Section 3 there is the following:
>
Right, if the server has different limits for different mailboxes, it 
would have advertised just "APPENDLIMIT".

I was talking about APPENDLIMIT=<n> being returned before and after 
authentication and what it means. See my reply to Dave.

Best Regards,
Alexey

---

From: Jayantheesh S B <[email-masked]>
Date: Tue, 15 Dec 2015 17:26:32 +0000

Hi All,

Please find our response updated. 

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Adrien de Croy
Sent: Friday, December 11, 2015 5:45 AM
To: Barry Leiba; Narendra Bisht
Cc: [email-masked]; [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

------ Original Message ------

>over.  Using LITERAL+ for APPEND data violates that.
OK fair point, the extra round trip for APPEND only isn't that big a deal.

[Jay] We will update the draft with SHOULD  NOT

Adrien

---

From: Jayantheesh S B <[email-masked]>
Date: Tue, 15 Dec 2015 17:54:01 +0000

Hi Barry/All,

Please find the proposed text for conveying  that there no limit for mailboxes.

NEW
3.  Mailbox specific APPENDLIMIT

   IMAP server can have mailbox specific APPENDLIMIT value, which will
   not be advertised as part of CAPABILITY response. The IMAP server can
   publish a huge limit for a mailbox to convey that there is no APPENDLIMIT
   for a mailbox. The following  subsections describe the changes to the
   STATUS and LIST commands in  support of this situation.
END

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Jayantheesh S B
Sent: Thursday, December 10, 2015 5:40 PM
To: Barry Leiba; Narendra Bisht; Adrien de Croy
Cc: [email-masked]; [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

Hi Barry,

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 10, 2015 2:10 PM
To: Narendra Bisht; Adrien de Croy
Cc: [email-masked]; [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

NEW

[Jay] OK

OLD

NEW

END
[Jay] Fine

[Jay] Alright

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Dec 2015 14:46:26 -0500

>    STATUS and LIST commands in  support of this situation.

I am not happy with using "a huge limit", nor any particular number
for this.  Sure, the IMAP grammar limits the length of a literal to
"number", which is defined thus in RFC 3501:

      number          = 1*DIGIT

So, yes, we *could* say (rather than the vague "a huge limit") that
4294967296 is what you use if you want to say that there's no limit.
But I don't like overloading things that way: this *is* advertising a
limit, rather than saying that there isn't one.

Why do we think there's anything wrong with using, say, the word
"NONE" (either case-insensitive or case-sensitive; I don't care)?
What's wrong with this?:

C: t1 STATUS INBOX (APPENDLIMIT)
S: * STATUS INBOX (APPENDLIMIT NONE)
S: t1 OK STATUS completed

Why is that not acceptable?

Barry

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 16 Dec 2015 11:58:34 +1100

> S: t1 OK STATUS completed

If you're going to do that, why not make it (APPENDLIMIT NIL),
which already has exactly the meaning that we want?

Bron.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Dec 2015 15:14:31 -0500

> which already has exactly the meaning that we want?

Yes, I'd forgotten about the existing token "NIL".  I like that approach.

Barry

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 17 Dec 2015 03:39:02 +0000

------ Original Message ------
From: "Barry Leiba" <[email-masked]>
To: "Bron Gondwana" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 17/12/2015 9:14:31 a.m.
Subject: Re: [imapext] AD review of 

>Yes, I'd forgotten about the existing token "NIL".  I like that 
+1

Definitely not a fan of overloading the meaning of magic numbers

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Dec 2015 10:15:41 +0000

> On 17 Dec 2015, at 03:39, Adrien de Croy <[email-masked]> wrote:
> 

I don't think this is a particular important point (there are always limits of some kind), but I like NIL.

---

From: Narendra Bisht <[email-masked]>
Date: Thu, 17 Dec 2015 17:01:26 +0000

The data type for APPENDLIMIT is NUMBER.
Will it accommodate a NIL?

-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Thursday, December 17, 2015 5:16 AM
To: [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

>>> If you're going to do that, why not make it (APPENDLIMIT NIL), which 
>>> already has exactly the meaning that we want?
>>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Dec 2015 17:20:30 +0000

Hi,

> Will it accommodate a NIL?

RFC 3501 defines:
status-att-list =  status-att SP number *(SP status-att SP number)

RFC 4466 redefines status-att-list:
status-att-list = status-att-val *(SP status-att-val)
                      ;; Redefines status-att-list from RFC 3501.

status-att-val  = ("MESSAGES" SP number) /
                      ("RECENT" SP number) /
                      ("UIDNEXT" SP nz-number) /
                      ("UIDVALIDITY" SP nz-number) /
                      ("UNSEEN" SP number)
                      ;; Extensions to the STATUS responses
                      ;; should extend this production.
                      ;; Extensions should use the generic
                      ;; syntax defined by tagged-ext.

So, I think you should add RFC 4466 to Normative references, then add 
the following to Section 5 of your draft:

appendlimit-status-att-val = "APPENDLIMIT" SP (number / nil)
status-att-val /= appendlimit-status-att-val
                             ;; status-att-val is defined in RFC 4466

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Dec 2015 12:32:58 -0500

> The data type for APPENDLIMIT is NUMBER.

I don't understand that statement: there are no "data types" in IMAP
commands.  There's ABNF.

> Will it accommodate a NIL?

It will if you change the ABNF like this:

OLD
appendlimit-respcode = "APPENDLIMIT" SP number

NEW
appendlimit-respcode = "APPENDLIMIT" SP (number / "NIL")

END

...and you'd add text explaining that if there is no limit for a
particular mailbox, the STATUS APPENDLIMIT response for that mailbox
is NIL.

There's no need to allow NIL in appendlimit-cap, because if there's no
limit you just don't send that item at all.

Barry

---

From: Stu Brandt <[email-masked]>
Date: Thu, 17 Dec 2015 12:37:02 -0500

Since RFC 3501 section 4.5 states...

    The special form "NIL" represents the non-existence of a particular
    data item that is represented as a string or parenthesized list, as
    distinct from the empty string "" or the empty parenthesized list ().

...does the introduction of nil as an alternative to number now imply 
that an update to this text is necessary?

- Stuart

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Dec 2015 17:56:35 +0000

Hi Barry,

> I don't understand that statement: there are no "data types" in IMAP
ABNF for status responses in RFC 3501 doesn't allow anything other than 
a "number". This inflexibility was fixed in RFC 4466.
> appendlimit-respcode = "APPENDLIMIT" SP (number / "NIL")
This change is in addition to what I suggested for STATUS.
+1
> limit you just don't send that item at all.
Agreed.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Dec 2015 17:58:04 +0000

> that an update to this text is necessary?
We can consider it, but I don't think this is actually a big deal. 
Because the text above doesn't say that "nil" can't be used anywhere 
else ;-).

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 17 Dec 2015 20:31:06 +0000

Hi Barry,

Please find the latest version of the draft (version 07) attached. As per the review discussion, we have updated the draft.

We have attached XML and Text version of the draft. Kindly go through the same and share your comments.

We will upload the draft once if all the review comments has been addressed.

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 17, 2015 12:33 PM
To: Narendra Bisht
Cc: Alexey Melnikov; [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

> The data type for APPENDLIMIT is NUMBER.

I don't understand that statement: there are no "data types" in IMAP commands.  There's ABNF.

OLD

NEW

END

...and you'd add text explaining that if there is no limit for a particular mailbox, the STATUS APPENDLIMIT response for that mailbox is NIL.

There's no need to allow NIL in appendlimit-cap, because if there's no limit you just don't send that item at all.

Barry

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Dec 2015 13:19:25 -0800

Hi Stu,
At 09:37 17-12-2015, Stu Brandt wrote:
>...does the introduction of nil as an alternative to number now 
>imply that an update to this text is necessary?

Thanks for flagging this.

I don't think so as it is ABNF in 
draft-ietf-imapapnd-appendlimit-extension which will be 
followed.  The following persons are in favor of using "NIL" [1][2][3][4]:

   Barry Leiba (Area Director)
   Bron Gondwana
   Adrien de Croy
   Alexey Melnikov

I suggest going ahead with that.

Regards,

1. http://www.ietf.org/mail-archive/web/imapext/current/msg05682.html
2. http://www.ietf.org/mail-archive/web/imapext/current/msg05681.html
3. http://www.ietf.org/mail-archive/web/imapext/current/msg05683.html
4. http://www.ietf.org/mail-archive/web/imapext/current/msg05684.html

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Dec 2015 17:03:28 -0500

> Please find the latest version of the draft (version 07) attached. As
> per the review discussion, we have updated the draft.
...
> We will upload the draft once if all the review comments has been addressed.

This looks mostly good, and thanks very much for all the work on this.
The ABNF and the Security Considerations still need a bit (see below).
Some editorial nits to fix, as well, before it's ready to post.
Below, "OLD" refers to text in the proposed -07 version.  Except for
the ABNF and Security considerations, these are all very minor
editorial things.

In the abstract, make it "APPEND commands" (plural).

In the Introduction:

OLD
   Several IMAP servers have limitation for mail upload size which is
   not published to the email client.  When email client APPEND a mail
   with huge attachments, using non-synchronizing literals it fails due
   to size restriction set by the IMAP server.
NEW
   Some IMAP servers have limits for mail upload size, and those limits
   are not published to the email client.  When the email client APPENDs
   a message with huge attachments, using non-synchronizing literals,
   the APPEND fails because of the upload limit, but the client has
   already sent the message data anyway.
END

In Section 3:

OLD
   IMAP server can have mailbox specific APPENDLIMIT value, which will
   not be advertised as part of CAPABILITY response.  The IMAP server
   can publish NIL for a mailbox to convey that there is no APPENDLIMIT
   to that mailbox [RFC4466].
NEW
   An IMAP server can have mailbox-specific APPENDLIMIT values, which
   will not be advertised as part of CAPABILITY response.  The IMAP
   server can publish specific values for each mailbox, and can publish
   "NIL" for a mailbox to convey that there is no APPENDLIMIT for that
   mailbox.
END

(I don't think there's any need for a citation to 4466 here; we'll
have it below, by the ABNF.)

In the section titles of 3.1 and 3.2, make it "STATUS response to the"
(not "in the").  This was my error when I suggested the change; sorry.

Similarly, in Section 3.2 take out the word "emit", which was there in error.

In Section 5, I think you misunderstood Alexey's suggestion for using
the 4466 changes.  Let's try this; Alexey, please check that I got
this right:

Replace all the ABNF in Section 5 with this:

NEW
   capability /= "APPENDLIMIT" ["=" number]
               ;; capability is defined in RFC 3501

   status-att /= "APPENDLIMIT"
               ;; status-att is defined in RFC 3501

   status-att-val /= "APPENDLIMIT" SP (number / nil)
               ;; status-att-val is defined in RFC 4466
END

...and also make this change:

OLD
   [RFC3501] defines the non-terminals
   "capability", "resp-text-code" and "status-att".
NEW
   [RFC3501] defines the non-terminals
   "capability" and "status-att", and [RFC4466] defines
   "status-att-val".
END

Reasoning:
First, I think the extra level of indirection, making two lines per
item, was only confusing.

Second, there seem to be three things you need to do: (1) add the
capability string, (2) add the APPENDLIMIT status option, and (3) add
the APPENDLIMIT status response.  Those three items do it.  I don't
know why you had the addition to resp-text-code -- it was always the
wrong thing to have, and we missed it before.

In the paragraph after the ABNF, change "A number indicating the fixed
maximum" to "The number indicates the fixed maximum".

In Section 6, my comment about the security considerations still needs
to be addressed.  You say this:

   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.  However, unless
   implementations are very weak, these extensions do not create any
   vulnerability that has not always existed with IMAP.

I still ask: Why does this information make it quicker and easier to
do a DoS attack?  I don't see it, and the document needs to explain it
clearly.  I can always, with or without this option, try to append a
very large message using a non-synchronizing literal for the message
data.  What is it about this extension that makes it quicker, easier,
or more effective (I'd avoid the more obscure word "efficacious")?

Barry

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 17 Dec 2015 22:57:27 +0000

Hi Barry,

Thanks for the quick review comments. 

For Section 6, this was our reasoning behind the text

Say a server has a limit of 50 MB. Before this extension, an attacker first tries to APPEND 25 MB and it succeeds.
Then he tries  40MB and that too succeeds. Finally he tries 60 MB to find the limit of 
server and use that as start of attack. With this extension the attacker can find the limit in no time, making it easy for him to 
attack.

Regards,
Jay
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 17, 2015 5:03 PM
To: Jayantheesh S B
Cc: Narendra Bisht; Alexey Melnikov; [email-masked]; S Moonesamy ([email-masked]); S Moonesamy ([email-masked])
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

...

This looks mostly good, and thanks very much for all the work on this.
The ABNF and the Security Considerations still need a bit (see below).
Some editorial nits to fix, as well, before it's ready to post.
Below, "OLD" refers to text in the proposed -07 version.  Except for the ABNF and Security considerations, these are all very minor editorial things.

In the Introduction:

OLD

In Section 3:

OLD

(I don't think there's any need for a citation to 4466 here; we'll have it below, by the ABNF.)

In Section 5, I think you misunderstood Alexey's suggestion for using the 4466 changes.  Let's try this; Alexey, please check that I got this right:

NEW

   status-att-val /= "APPENDLIMIT" SP (number / nil)
               ;; status-att-val is defined in RFC 4466 END

OLD

Reasoning:
First, I think the extra level of indirection, making two lines per item, was only confusing.

Second, there seem to be three things you need to do: (1) add the capability string, (2) add the APPENDLIMIT status option, and (3) add the APPENDLIMIT status response.  Those three items do it.  I don't know why you had the addition to resp-text-code -- it was always the wrong thing to have, and we missed it before.

In the paragraph after the ABNF, change "A number indicating the fixed maximum" to "The number indicates the fixed maximum".

In Section 6, my comment about the security considerations still needs to be addressed.  You say this:

I still ask: Why does this information make it quicker and easier to do a DoS attack?  I don't see it, and the document needs to explain it clearly.  I can always, with or without this option, try to append a very large message using a non-synchronizing literal for the message data.  What is it about this extension that makes it quicker, easier, or more effective (I'd avoid the more obscure word "efficacious")?

Barry

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 17 Dec 2015 23:01:14 +0000

Hi All,

I have addressed all the review comments given by Barry except section 6 (discussion going on separate thread) and attached the document.

Kindly go through this version for your review.

Regards,
Jay
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 17, 2015 5:03 PM
To: Jayantheesh S B
Cc: Narendra Bisht; Alexey Melnikov; [email-masked]; S Moonesamy ([email-masked]); S Moonesamy ([email-masked])
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

...

In the Introduction:

OLD

In Section 3:

OLD

NEW

OLD

Reasoning:

Barry

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 17 Dec 2015 23:16:28 +0000

Just to be clear, you're talking about an attack on APPEND from an 
authenticated user?

I think these sorts of attacks have different sorts of solutions, like 
blocking the account.

------ Original Message ------
From: "Jayantheesh S B" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>; "Narendra Bisht" 
<[email-masked]>; "S Moonesamy ([email-masked])" 
<[email-masked]>; "S Moonesamy ([email-masked])" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 18/12/2015 11:57:27 a.m.
Subject: Re: [imapext] AD review of 
draft-ietf-imapapnd-appendlimit-extension-06

>Say a server has a limit of 50 MB. Before this extension, an attacker 
>first tries to APPEND 25 MB and it succeeds.
>server and use that as start of attack. With this extension the 
>attacker can find the limit in no time, making it easy for him to
>attack.
>
>Regards,
>Jay
>Cc: Narendra Bisht; Alexey Melnikov; [email-masked]; S Moonesamy 
>([email-masked]); S Moonesamy ([email-masked])
>the 4466 changes.  Let's try this; Alexey, please check that I got this 
>right:
>
>I still ask: Why does this information make it quicker and easier to do 
>a DoS attack?  I don't see it, and the document needs to explain it

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Dec 2015 18:20:58 -0500

> Then he tries  40MB and that too succeeds. Finally he tries 60 MB to
> find the limit of server and use that as start of attack. With this extension
> the attacker can find the limit in no time, making it easy for him to
> attack.

OK, I see the point now.  It seems a little thin (but, then, the
document does already say it is) -- I can just try to append 300MB,
using non-synch literal, right from the start.

But perhaps this will be more satisfying:

OLD
   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.  However, unless
   implementations are very weak, these extensions do not create any
   vulnerability that has not always existed with IMAP.
NEW
   The IMAP APPENDLIMIT extension described in this document can
   conceivably be used to facilitate Denial-of-Service attacks by allowing
   an attacker to home in on a critical value right away.  The attacker
   might want to send a large data block to the server repeatedly,
   forcing the server to process the block, but would not want to limit
   the scope of its attack by filling an actual mailbox with successful
   appends.  Without this extension, the attacker needs to guess: a
   too-small guess results in an appended message that takes up the
   user's quota, while a far-too-large guess might simply cause the
   server to terminate the connection because of suspected abuse.

   But with this extension, the attacker can immediately choose a
   value that's a little too large, but not so much as to trigger an "abuse"
   response, making it easier to mount such an attack.

   To mitigate this extension's input to such an attack, a server might
   take a harder line on message sizes that are above the APPENDLIMIT
   value -- because the client knows the limit and should not even be
   trying to send such commands, a server might consider even a single
   attempt to be abusive, and terminate the IMAP connection straight
   away.
END

How's that work for you?

Barry

---

From: Jayantheesh S B <[email-masked]>
Date: Fri, 18 Dec 2015 00:08:11 +0000

Thanks Barry.

We have updated the Section 6 with the proposed text. 

Please find the latest one attached. If everyone is fine with this version, I will upload the same.

Regards,
Jay
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 17, 2015 6:21 PM
To: Jayantheesh S B
Cc: Narendra Bisht; Alexey Melnikov; [email-masked]; S Moonesamy ([email-masked]); S Moonesamy ([email-masked])
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

> find the limit of server and use that as start of attack. With this 
> extension the attacker can find the limit in no time, making it easy 
> for him to attack.

OK, I see the point now.  It seems a little thin (but, then, the document does already say it is) -- I can just try to append 300MB, using non-synch literal, right from the start.

OLD

How's that work for you?

Barry

---

From: Dave Cridland <[email-masked]>
Date: Fri, 18 Dec 2015 10:55:29 +0000

On 17 December 2015 at 21:19, S Moonesamy <[email-masked]> wrote:

> draft-ietf-imapapnd-appendlimit-extension which will be followed.  The
> following persons are in favor of using "NIL" [1][2][3][4]:
>

I'm in favour too, but I'm also in favour of using it in the CAPABILITY
string as well. My reasonings:

1) I'd rather minimize the syntactic differences.

2) If a server advertises an appendlimit prior to authentication but wishes
to indicate no limit subsequent, there is currently no method for doing so.
I have no clue why a server would wish to do this, but the specification
seems adamant that changing the limit after login (rather than not
advertising it prior) is useful.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Dec 2015 11:40:08 +0000

>     attempt to be abusive, and terminate the IMAP connection straight
I think this is fine. There is still a problem with clients that don't 
observe APPENDLIMIT and are used by a significant portion by MSP users, 
but hopefully pressure on vendors can help with that.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Dec 2015 11:41:39 +0000

On 18/12/2015 10:55, Dave Cridland wrote:
> On 17 December 2015 at 21:19, S Moonesamy <[email-masked] 
>         ...does the introduction of nil as an alternative to number
>         now imply that an update to this text is necessary?
>
>
>     draft-ietf-imapapnd-appendlimit-extension which will be followed. 
>     The following persons are in favor of using "NIL" [1][2][3][4]:
>
> I'm in favour too, but I'm also in favour of using it in the 
> CAPABILITY string as well. My reasonings:
>
> 2) If a server advertises an appendlimit prior to authentication but 
> wishes to indicate no limit subsequent, there is currently no method 
> for doing so. I have no clue why a server would wish to do this, but 
> the specification seems adamant that changing the limit after login 
> (rather than not advertising it prior) is useful.
I think "adamant" is a bit too strong. But I don't object to what you 
propose.

---

From: Jayantheesh S B <[email-masked]>
Date: Fri, 18 Dec 2015 15:25:51 +0000

Hi All,

If everybody is fine with this version of draft, Shall I upload it?

Kindly share your comments. 

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Jayantheesh S B
Sent: Thursday, December 17, 2015 7:08 PM
To: Barry Leiba
Cc: Alexey Melnikov; Narendra Bisht; S Moonesamy ([email-masked]); S Moonesamy ([email-masked]); [email-masked]
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

Thanks Barry.

Regards,
Jay
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, December 17, 2015 6:21 PM
To: Jayantheesh S B
Cc: Narendra Bisht; Alexey Melnikov; [email-masked]; S Moonesamy ([email-masked]); S Moonesamy ([email-masked])
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

OLD

How's that work for you?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Dec 2015 10:54:57 -0500

> If everybody is fine with this version of draft, Shall I upload it?

I think so.

Barry