The IMAP NOTIFY Extension
RFC 5465

Approval announcement
Draft of message to be sent after approval:

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>, 
    lemonade mailing list <lemonade@ietf.org>, 
    lemonade chair <lemonade-chairs@tools.ietf.org>
Subject: Protocol Action: 'The IMAP NOTIFY Extension' to 
         Proposed Standard 

The IESG has approved the following document:

- 'The IMAP NOTIFY Extension '
   <draft-ietf-lemonade-imap-notify-08.txt> as a Proposed Standard

This document is the product of the Enhancements to Internet email to 
Support Diverse Service Environments Working Group. 

The IESG contact persons are Chris Newman and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-notify-08.txt

Technical Summary

The IDLE command (defined in [RFC2177]) provides a way for the client 
to go into a mode where the IMAP server pushes notifications about 
IMAP mailstore events for the selected mailbox.  However, the IDLE 
extension doesn't restrict or control which server events can be sent, 
or what information the server sends in response to each event.  Also, 
IDLE only applies to the selected mailbox, thus requiring an 
additional TCP connection per mailbox.

This document defines an IMAP extension that allows clients to express 
their preferences about unsolicited events generated by the server. 
The extension allows clients to only receive events they are 
interested in, while servers know that they don't need to go into 
effort of generating certain types of untagged responses.

Working Group Summary

There was an early discussion about document allowing mailbox matching 
criteria that were too expensive to implement in servers.  The current 
draft represents consensus among active WG members.  There was a 
discussion about not having any events tied together. However some 
implementers expressed concerns about difficulty of implementing 
certain event combinations untied. The current text is a compromise 
and represents consensus among active WG members.

Document Quality

Multiple client developers (at least 4) expressed the desire to have 
this feature. Multiple server developers committed to implement the 
extension (at least 3) and a couple of developers already have 
prototype implementations.

Personnel

Eric Burger is the document shepherd for this document.  Chris Newman
is the Responsible Area Director.

RFC Editor

In section 5.6 (MailboxMetadataChange),
insert a new paragraph after the 1st paragraph:

    A client willing to receive unsolicited METADATA responses as a
    result of using the MailboxMetadataChange event in the NOTIFY
    command doesn't have to issue ENABLE METADATA.

In section 5.7 (ServerMetadataChange),
insert a new paragraph after the 1st paragraph:

    A client willing to receive unsolicited METADATA responses as a
    result of using the ServerMetadataChange event in the NOTIFY
    command doesn't have to issue ENABLE METADATA
    or ENABLE METADATA-SERVER.

In section 10.1, change the first sentence:

OLD:
    It is requested that the following entry be added to the IMAP4 List
                                                             ^^^^^^^^^^
    Extended registry [LISTEXT]:
    ^^^^^^^^
NEW:
    It is requested that the following entry be added to the
    LIST-EXTENDED response registry [LISTEXT]:
    ^^^^^^^^^^^^^^^^^^^^^^