Subject: [imapext] Review of draft-ietf-imapapnd-appendlimit-extension-03

From: S Moonesamy <[email-masked]>
Date: Sat, 03 Oct 2015 09:04:02 -0700

Hello,

I read draft-ietf-imapapnd-appendlimit-extension-03 [1] and I have 
some comments.

In Section 2:

   "IMAP client should be able to parse both kind of formats."

I suggest capitalizing the "should" to follow the conventions 
specified in Section 1.1 (RFC 2119).

   "By looking at the upload size advertised by the IMAP server,
    client MUST not try to upload mail more than advertised limit."

Shouldn't this be "APPEND" instead of "upload"?

In Section 3:

   "IMAP server should return the mailbox name that matches the
    STATUS specification and the requested mailbox status information."

Is the "should" a RFC 2119 recommendation?  If so, I suggest capitalizing it.

   'IMAP server should recognize an extra "RETURN (STATUS (APPENDLIMIT))"
   at the end of a LIST command and emit an extra STATUS response for
   each matching mailbox.'

Is the "should" a RFC 2119 recommendation?

   "If the server does not support this extension, then client should
    use STATUS command instead."

Is the "should" a RFC 2119 recommendation?  Why is this a recommendation?

In Section 4:

   "STATUS APPENDLIMIT must be fast and there is no need to evaluate
    remaining quotas (if any) when returning APPENDLIMIT values."

Is the "must" a RFC 2119 requirement?  Saying "must be fast" is 
ambiguous.  I am unsure about whether this is implementor guidance or 
a requirement.  If it is a requirement, I suggest stating clearly 
what the requirement is.

In Section 5:

   "A number indicating the fixed maximum message size in bytes
    that the server will accept."

Shouldn't this be "octets" instead of "bytes"?

   "APPENDLIMIT=0 indicates the server SHALL not accept APPEND
   command due to size restriction."

Is the "SHALL not" is a RFC 2119 requirement, the "not" will have to 
be capitalized as well.  Why is this a requirement?  I could read the 
about as an explanation about what "APPENDLIMIT=0" means or I could 
read it as meaning that the server must implement this by not 
accepting the APPEND command.

The Security Considerations Section does not say much.  Why is it 
believed that "this extension doesn't add any new security 
considerations" which is not already discussed in RFC 3501?  I 
suggest looking at this in terms of "we gave some thought to this, we 
found/did not find security issues".

Section 8.1 lists the normative references.  There isn't any 
reference in the previous sections to RFC 5322, RFC 2088 and RFC 
5258.  I suggest adding some text in the draft (not in Section 8) to 
point to those specifications if they are necessary to understand 
this technical specification.

There is a downward reference to RFC 4549 as that document is 
"Informational" whereas this document is intended to be published as 
a "Proposed Standard".  Is it necessary for me to read RFC 4549 to 
understand or implement the specification in this draft?

Regards,
S. Moonesamy

1. https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-03

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 3 Oct 2015 19:57:29 +0100

Hi SM,

> On 3 Oct 2015, at 17:04, S Moonesamy <[email-masked]> wrote:
> 
> Hello,
> 
> I read draft-ietf-imapapnd-appendlimit-extension-03 [1] and I have some comments.
> 
> In Section 2:
> 
> I suggest capitalizing the "should" to follow the conventions specified in Section 1.1 (RFC 2119).

I don't think we need normative language here, but I can be convinced otherwise.
> Shouldn't this be "APPEND" instead of "upload"?

They are the same thing, so I think either is fine.
> Is the "should" a RFC 2119 recommendation?  If so, I suggest capitalizing it.

This sounds more like a MUST.
> Is the "should" a RFC 2119 recommendation?
Again, probably a MUST.
> Is the "should" a RFC 2119 recommendation?  Why is this a recommendation?

I think this is non normative.
> Is the "must" a RFC 2119 requirement?  Saying "must be fast" is ambiguous.  I am unsure about whether this is implementor guidance or a requirement.  If it is a requirement, I suggest stating clearly what the requirement is.

It is a performance requirement, but it is not really possible to test for compliance. So this is more of a quality of service issue.
> Is the "SHALL not" is a RFC 2119 requirement, the "not" will have to be capitalized as well.  Why is this a requirement?  I could read the about as an explanation about what "APPENDLIMIT=0" means or I could read it as meaning that the server must implement this by not accepting the APPEND command.

The latter, I think.
> 
> The Security Considerations Section does not say much.  Why is it believed that "this extension doesn't add any new security considerations" which is not already discussed in RFC 3501?  I suggest looking at this in terms of "we gave some thought to this, we found/did not find security issues".

Clients can test the limit by trying different sizes, but this makes it easier for clients to find out the limit. On the server side servers still need to handle APPEND abuse, so this is not really different Sent from my iPad
> 
> Section 8.1 lists the normative references.  There isn't any reference in the previous sections to RFC 5322, RFC 2088 and RFC 5258.  I suggest adding some text in the draft (not in Section 8) to point to those specifications if they are necessary to understand this technical specification.

RFC 2088 (LITERAL+) should be referenced in section 4, so I suggest it should be mentioned there.

5258 can probably be omitted.

> There is a downward reference to RFC 4549 as that document is "Informational" whereas this document is intended to be published as a "Proposed Standard".  Is it necessary for me to read RFC 4549 to understand or implement the specification in this draft?

As https://datatracker.ietf.org/doc/rfc4549/referencedby/ shows 3 Standard Track RFCs pointing to RFC 4549, it can be added into the downref registry. I suggest you just mention that in the writeup.

This reference can also be moved to Informative, because of how RFC 4549 is used.
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext

---

From: S Moonesamy <[email-masked]>
Date: Sun, 04 Oct 2015 01:11:02 -0700

Hi Alexey,
At 11:57 03-10-2015, Alexey Melnikov wrote:
>As 
><https://datatracker.ietf.org/doc/rfc4549/referencedby/>https://datatracker.ietf.org/doc/rfc4549/referencedby/ 
>shows 3 Standard Track RFCs pointing to RFC 4549, it can be added 
>into the downref registry. I suggest you just mention that in the writeup.
>

Thanks for verifying the RFC 4549.  The three references are 
informative, i.e. it's not a downref.  I'll suggest using RFC 4549 as 
an Informative reference if the working group is okay with that.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Sun, 04 Oct 2015 01:48:47 -0700

Hi Alexey,
>I don't think we need normative language here, but I can be 

An IMAP client implementing this specification will have to support 
the formal syntax specified in Section 5.  I suggest removing the RFC 
2119 key word in that (Section 2) sentence.

>They are the same thing, so I think either is fine.

Ok.

>This sounds more like a MUST.

I suggest looking at this Section 3.1 recommendation (or requirement) 
from an interoperability perspective.  The IMAP client is looking for 
the per mailbox specific limit.  What the IMAP client needs to know 
is the STATUS response which the IMAP server will send as a 
response.  It may be better to rephrase that sentence.

>>Is the "should" a RFC 2119 recommendation?

Ok.  I'll wait to see what the authors think about this.

>I think this is non normative.

Ok.

>It is a performance requirement, but it is not really possible to 
>test for compliance. So this is more of a quality of service issue.

"must be fast" is subjective.  I suggest rewriting the sentence 
without RFC 2119 key words if we do not want to encourage debates 
about "fast". :-)

>>Is the "SHALL not" is a RFC 2119 requirement, the "not" will have 
>>to be capitalized as well.  Why is this a requirement?  I could 
>>read the about as an explanation about what "APPENDLIMIT=0" means 
>>or I could read it as meaning that the server must implement this 
>>by not accepting the APPEND command.
>
>The latter, I think.

Ok.

>Clients can test the limit by trying different sizes, but this makes 
>it easier for clients to find out the limit. On the server side 
>servers still need to handle APPEND abuse, so this is not really 
>different Sent from my iPad

How about explaining that this extension does not introduce anything 
new and, as such, it does not create any new security issues?

>5258 can probably be omitted.

Thanks for the feedback.

Regards,
S. Moonesamy

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 7 Oct 2015 22:13:12 +0000

Dear SM,

Thanks for the feedback. 

Please find the response inline. 

Regards,
Jay

-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Sunday, October 04, 2015 4:49 AM
To: Alexey Melnikov; [email-masked]
Cc: Jayantheesh S B; Narendra Singh Bisht
Subject: Re: [imapext] Review of draft-ietf-imapapnd-appendlimit-extension-03

Hi Alexey,
>I don't think we need normative language here, but I can be convinced 

An IMAP client implementing this specification will have to support the formal syntax specified in Section 5.  I suggest removing the RFC
2119 key word in that (Section 2) sentence.

Ok.

>This sounds more like a MUST.

I suggest looking at this Section 3.1 recommendation (or requirement) from an interoperability perspective.  The IMAP client is looking for the per mailbox specific limit.  What the IMAP client needs to know is the STATUS response which the IMAP server will send as a response.  It may be better to rephrase that sentence.

[Jay] I am fine with changing this to "MUST". Please refer the latest version of the draft.

Ok.

>It is a performance requirement, but it is not really possible to test 
>for compliance. So this is more of a quality of service issue.

"must be fast" is subjective.  I suggest rewriting the sentence without RFC 2119 key words if we do not want to encourage debates about "fast". :-)

[Jay] Changed this sentence. Please refer the latest version of the document.

>>  "APPENDLIMIT=0 indicates the server SHALL not accept APPEND  command 
>> due to size restriction."
>>

Ok.

>Clients can test the limit by trying different sizes, but this makes it 
>easier for clients to find out the limit. On the server side servers 
>still need to handle APPEND abuse, so this is not really different Sent 
>from my iPad

How about explaining that this extension does not introduce anything new and, as such, it does not create any new security issues?

[Jay] Addressed this review comments in the next version of the document. 

Thanks for the feedback.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Wed, 14 Oct 2015 14:19:47 -0700

Hi Jay,

>[Jay] Changed this sentence. Please refer the latest version of the document.

This is what you have in -04:

   "STATUS APPENDLIMIT should be fast and there ..."

Would you be okay with removing the "should" so that it does not 
sound like a recommendation?

In Section 2:

   "In this case the client should get APPENDLIMIT value by issuing
    STATUS or LIST command."

Thanks for adding text to the Security Considerations Section.

Regards,
S. Moonesamy

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 14 Oct 2015 21:49:40 +0000

Dear SM,

Please find the response inline 

Regards,
Jay
-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 5:20 PM
To: Jayantheesh S B; Alexey Melnikov; [email-masked]
Cc: Jayantheesh S B; Narendra Singh Bisht
Subject: Re: [imapext] Review of draft-ietf-imapapnd-appendlimit-extension-03

Hi Jay,

>"must be fast" is subjective.  I suggest rewriting the sentence without 
>RFC 2119 key words if we do not want to encourage debates about "fast". 
>:-)
>

Would you be okay with removing the "should" so that it does not sound like a recommendation?

[Jay]  - Please find the updated text below. 

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

In Section 2:

[Jay] - Yes, this is a RFC 2119 recommendation. I will change to SHOULD in the next version.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Wed, 14 Oct 2015 14:58:15 -0700

Hi Jay,

Ok.

Ok.

Regards,
S. Moonesamy