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

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 05 Jan 2016 11:10:25 -0800

Alissa Cooper 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.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's unusual to see author names without first initials in the document
header. Not sure if that was intentional but seems like it should be
fixed (assuming the authors have both first names and surnames).

= Section 2 =

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

   An IMAP client SHOULD be able to parse both formats.  By looking at
   the upload size advertised by the IMAP server, a client MUST NOT try
   to APPEND mail more than the advertised limit."

The first and last normative requirements here seem too strict
considering that this extension basically allows an optimization. That
is, if a client decides not to find out the append limit for a particular
mailbox using STATUS or LIST, that doesn't seem to create any particular
problem. Likewise, it seems better for a client to avoid sending an
attachment larger than a known limit, but doing so doesn't seem so
problematic as to warrant a MUST NOT.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 05 Jan 2016 15:50:46 -0800

Hello,
>problematic as to warrant a MUST NOT.

I'll suggest writing the first sentence as follows:

   In this case the client can get an APPENDLIMIT value by either issuing
   a STATUS or a LIST command.

I avoided including a normative recommendation to keep it simple.

There is the following in Section 6:

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

I'll suggest some text:

   By looking at the upload size advertised by the IMAP server a client
   can avoid trying to APPEND mail more than the advertised limit."

Regards,
S. Moonesamy (as document shepherd)

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Jan 2016 12:21:27 -0800

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

It is a mistake.  It will be fixed in the next revision of the draft.

>problematic as to warrant a MUST NOT.

NEW

    By looking at the upload size advertised by the IMAP server a client
    can avoid trying to APPEND mail more than the advertised limit.
END

Regards,

---

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

Dear All,

Updated the document with the below text proposed by SM.

NEW

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Wednesday, January 06, 2016 3:21 PM
To: Alissa Cooper; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [imapext] Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Hi Alissa,

>is, if a client decides not to find out the append limit for a 
>particular mailbox using STATUS or LIST, that doesn't seem to create 
>any particular problem. Likewise, it seems better for a client to avoid 
>sending an attachment larger than a known limit, but doing so doesn't 
>seem so problematic as to warrant a MUST NOT.

NEW

Regards,

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