Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Jan 2016 15:40:19 -0800

Hi Naren, Jay,
At 15:15 06-01-2016, Ben Campbell wrote:
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>- section 2, last paragraph:
>
>It was not obvious to me if "An IMAP client SHOULD be able to parse both
>formats. " meant both STATUS and LIST, or both global and per-mailbox. I
>assume the former.

In the first paragraph of Section 2 there is the following:

   "An IMAP server can publish the APPENDLIMIT capability in two
    formats."

There are then two examples of the formats.  In the last paragraph of 
Section 2 there is:

   "An IMAP client SHOULD be able to parse both formats."

Does that refer to the two examples in Section 2?

Regards,
S. Moonesamy (as document shepherd)

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jan 2016 07:46:50 -0800

Hi Ben,
>https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

Thanks for the review.  I am waiting for a reply from the authors.

I previously commented that the "both formats" would be covered by 
the ABNF (Section 5).  The normative language in that sentence is 
incorrect though [1].

Regards,

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

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 7 Jan 2016 16:04:19 +0000

Dear SM,

Yes, both text refers to the same examples in Section 2.

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Wednesday, January 06, 2016 6:40 PM
To: Narendra Singh Bisht; Jayantheesh S B
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Hi Naren, Jay,
At 15:15 06-01-2016, Ben Campbell wrote:
>It was not obvious to me if "An IMAP client SHOULD be able to parse 
>both formats. " meant both STATUS and LIST, or both global and 
>per-mailbox. I assume the former.

There are then two examples of the formats.  In the last paragraph of Section 2 there is:

Regards,

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

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jan 2016 08:14:51 -0800

Hi Jay,
>Yes, both text refers to the same examples in Section 2.

Thanks for confirming that.

Why is there a RFC 2119 "SHOULD" in the first sentence of the last 
paragraph of Section 2?

Regards,
S. Moonesamy

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 7 Jan 2016 16:28:16 +0000

Dear SM,

IMAP client implementing this extension, should be capable to parse both Mailbox-specific and Global APPENDLIMIT response.

IMAP client ignoring one format may result in non-compliance to this extension. To stress that point we have added RFC 2119 "SHOULD" in that sentence.  

Regards,
Jay
-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Thursday, January 07, 2016 11:15 AM
To: Jayantheesh S B; Narendra Singh Bisht
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Hi Jay,

Why is there a RFC 2119 "SHOULD" in the first sentence of the last paragraph of Section 2?

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 7 Jan 2016 16:41:05 +0000

> IMAP client ignoring one format may result in non-compliance to this extension. To stress that point we have added RFC 2119 "SHOULD" in that sentence.
SHOULD implies that it is possible for the client not to parse one of 
the variants in some circumstances. I think not using normative language 
is better here (or switch to MUST).

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 7 Jan 2016 16:48:34 +0000

Alexey,

Ok, We will remove the normative language here.

Regards,
Jay
-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Thursday, January 07, 2016 11:41 AM
To: Jayantheesh S B; S Moonesamy; Narendra Singh Bisht
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

> IMAP client ignoring one format may result in non-compliance to this extension. To stress that point we have added RFC 2119 "SHOULD" in that sentence.
SHOULD implies that it is possible for the client not to parse one of the variants in some circumstances. I think not using normative language is better here (or switch to MUST).
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [imapext] Ben Campbell's No Objection on 
> draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)
>
> Hi Jay,

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jan 2016 15:15:43 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-imapapnd-appendlimit-extension-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jan 2016 09:09:06 -0800

Hi Jay, Alexey,

At 08:41 07-01-2016, Alexey Melnikov wrote:
>SHOULD implies that it is possible for the client not to parse one 
>of the variants in some circumstances. I think not using normative 
>language is better here (or switch to MUST).

Yes.  I don't think that using normative language is appropriate in 
that sentence.

At 08:28 07-01-2016, Jayantheesh S B wrote:
>IMAP client implementing this extension, should be capable to parse 
>both Mailbox-specific and Global APPENDLIMIT response.
>
>IMAP client ignoring one format may result in non-compliance to this 
>extension. To stress that point we have added RFC 2119 "SHOULD" in 
>that sentence.

I'll suggest the following text:

   An IMAP client implementing this extension should be able to parse both
   mailbox-specific and global APPENDLIMIT responses.

Regards,

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 7 Jan 2016 17:12:11 +0000

Hi SM,

On 07/01/2016 17:09, S Moonesamy wrote:
>> the variants in some circumstances. I think not using normative 
+1.

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 7 Jan 2016 17:15:58 +0000

Thanks SM.

It's fine for me. If everybody is OK, I will update the proposed text. 

Regards,
Jay
-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Thursday, January 07, 2016 12:09 PM
To: Jayantheesh S B; Narendra Singh Bisht; Alexey Melnikov
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [imapext] Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Hi Jay, Alexey,

>language is better here (or switch to MUST).

Yes.  I don't think that using normative language is appropriate in that sentence.

At 08:28 07-01-2016, Jayantheesh S B wrote:
>extension. To stress that point we have added RFC 2119 "SHOULD" in that 
>sentence.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jan 2016 09:18:38 -0800

Hi Ben,
>https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

OLD
    An IMAP client SHOULD be able to parse both formats.
END

NEW
END

Regards,

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 07 Jan 2016 11:49:36 -0600

On 7 Jan 2016, at 11:18, S Moonesamy wrote:

>> both

Works for me. (And shows I assumed wrong.)

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jan 2016 11:44:36 -0800

Hi Ben,
>Works for me. (And shows I assumed wrong.)

It shows that you did a good review. :-)  It is a positive 
contribution to the draft.

Regards,
S. Moonesamy