Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: imapapnd-chairs@ietf.org, barryleiba@gmail.com, sm+ietf@elandsys.com, "S Moonesamy" <sm+ietf@elandsys.com>, draft-ietf-imapapnd-appendlimit-extension@ietf.org, imapext@ietf.org, "The IESG" <iesg@ietf.org>, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'The IMAP APPENDLIMIT Extension' to Proposed Standard (draft-ietf-imapapnd-appendlimit-extension-10.txt)

The IESG has approved the following document:
- 'The IMAP APPENDLIMIT Extension'
  (draft-ietf-imapapnd-appendlimit-extension-10.txt) as Proposed Standard

This document is the product of the IMAP APPEND Extensions Working Group.

The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/


Ballot Text

Technical Summary

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.

Review and Consensus

The document was reviewed by the Imapapnd Working Group.  There was a
small number of participants interested in the draft.    There is at least one
implementation of this, but some participants are skeptical about broad
acceptance, as this extension addresses an issue that is not commonly much
of a problem.  Although the document addresses that in Section 1, it did not
convince part of the working group.  The WG consensus on this extension
can be described as rough, even though there wasn't any noteworthy controversy.

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

RFC Editor Note