The IMAP APPENDLIMIT Extension
draft-ietf-imapapnd-appendlimit-extension-10

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

[Ballot comment]
Thanks for your work on this extension, it seems useful, I just have a few comments that can be left to the editors and AD to handle if I disappear for maternity leave. 

I think the security considerations section could be a bit more clear on the actual risks with this extension.  I think the flow of the section can be improved to make these risks a bit more clear.

First, this extension lets you find out the limit for either the server or individual mailboxes, so shouldn't the first part of the description focus on a possible DoS filling up those resources?

I'm not sure why there is a focus on "without this extension".

Then, it's a common security programming practice to enforce size limitations in code.  Why is there a focus on an attacker sending append content that exceeds the allowable size rather than just saying that such append content should be rejected?

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

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-imapapnd-appendlimit-extension-07.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the IMAP Capabilities registry located at:

http://www.iana.org/assignments/imap-capabilities/

a single, new capability is to be added to the registry as follows:

Capability Name: APPENDLIMIT
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: imapapnd-chairs@ietf.org, barryleiba@gmail.com, sm+ietf@elandsys.com, "S Moonesamy" , draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The IMAP APPENDLIMIT Extension) to Proposed Standard


The IESG has received a request from the IMAP APPEND Extensions WG
(imapapnd) to consider the following document:
- 'The IMAP APPENDLIMIT Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-01-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an extension to the IMAP service whereby a
  server can inform the client about a maximum mail upload size,
  allowing the client to avoid sending APPEND commands that will fail
  because of the messages are too large.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/ballot/


No IPR declarations have been submitted directly on this I-D.

1.  Summary

S. Moonesamy is the Document Shepherd for this document. Barry Leiba is
the Responsible Area Director.

The document 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.  The type of RFC being requested
is Proposed Standard as the draft defines a protocol that will have
to be supported on by an IMAP client and an IMAP server.

2. Review and Consensus

The document was reviewed by the Imapapnd Working Group.  There was a
small number of participants interested in the draft.    Stu Brandt
stated that the specification has been implemented by AOL.  Timo
Sirainen and Arnt Gulbrandsen asked a question about why implement an
IMAP capability that is going to be a problem in only some very rare
cases.  Although the document addresses that in Section 1, it did not
convince part of the working group.  Alexey Melnikov reviewed several
iterations of the draft, including the version for the WGLC.  The WG
Consensus on the IMAP APPENDLIMIT Extension can be described as rough
even though there wasn't any noteworthy controversy.

3. Intellectual Property

Each author stated that the draft is in conformance with BCPs 78 and 79.

4. Other Points

idnits returns a warning about a missing reference for RFC4549.  There
is a reference to that RFC in Section 4 of the document.  (AD note: It's
complaining about a missing reference, not a missing citation, and this
is because the heading for Section 8.2 is malformed, so IDnits doesn't
see the reference.  Authors should fix.)

1.  Summary

S. Moonesamy is the Document Shepherd for this document. Barry Leiba is the Responsible Area Director.

The document 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.  The type of RFC being requested is Proposed Standard as the draft defines a capability which will have to be supported on by an IMAP client and an IMAP server.

2. Review and Consensus

The document was reviewed by the Imapapdb Working Group.  There was a small number of participants interested in the draft.    Stu Brandt stated that the specification has been implemented by AOL.  Timo Sirainen  and Arnt Gulbrandsen asked a question about why implement an IMAP capability that is going to be a problem in only some very rare cases.  Although the document addresses that in Section 1, it did not convince part of the working group.  Alexey Melnikov reviewed several iterations of the draft, including the version for the WGLC.  The WG Consensus on the IMAP APPENDLIMIT Extension can be described as rough even though there wasn't any noteworthy controversy.

3. Intellectual Property

Each author stated that the draft is in conformance with BCPs 78 and 79.

4. Other Points

This document requests that IANA adds "APPENDLIMIT" capability in the Internet Message Access Protocol (IMAP) Capabilities Registry.

idnits returns a warning about a missing reference for RFC4549.  There is a reference to that RFC in Section 4 of the document.