The IMAP ENABLE Extension
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.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
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.