Skip to main content

The IMAP ENABLE Extension
draft-gulbrandsen-imap-enable-05

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: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'The IMAP ENABLE Extension' to 
         Proposed Standard 

The IESG has approved the following document:

- 'The IMAP ENABLE Extension '
   <draft-gulbrandsen-imap-enable-06.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gulbrandsen-imap-enable-06.txt

Ballot Text

Technical Summary
 
  Most IMAP extensions are used by the client when the client wants
  to and the server supports the extension. However, a few extensions
  require the server to know whether a client supports that extension.
  The ENABLE extension allows an IMAP client to say which extensions
  it supports.
 
Working Group Summary
 
  This is the product of an individual submitter.
 
Protocol Quality
 
  This was reviewed for the IESG by Chris Newman.  The IMAP community
  has resisted the idea of client capabilities for a long time in an
  effort to minimize state complexity.  However, proposed IMAP
  extensions in progress in the Lemonade and EAI WGs require server
  knowledge of client capabilities and most felt a clean ENABLE
  command was superior to multiple commands that have side-effects
  that alter future server behavior or responses.  Controversial
  points in the development of this proposal involve whether the
  command is permitted in all states or just authenticated state,
  and how to announce changes triggered by the command.  This proposal
  has been discussed extensively by Lemonade WG participants, IMAP
  extensions WG participants and by the EAI design team.  At least 7
  people have reviewed the document.  Posted comments were addressed
  in document revisions. There are at least 5 existing implementations
  (3 servers and 2 clients).

Note to RFC Editor

Section 2., paragraph 2
OLD:
  the client is aware of the extension). CONSTORE ([RFC4551]),
NEW:
  the client is aware of the extension). CONDSTORE ([RFC4551]),
                                           ^^^

Section 3.1, paragraph 4:
OLD:
    - If the argument is an extension is supported by the server and
      which needs to be enabled,
NEW:
    - If the argument is an extension which is supported by the server
      and which needs to be enabled,
                                      ^^^^^

Please remove the following from the Informative References:

      [RFC2177]  Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997.

RFC Editor Note