IMAP4 Multimailbox SEARCH Extension
RFC 7377

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: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'IMAP4 Multimailbox SEARCH Extension' to Proposed Standard (draft-ietf-appsawg-multimailbox-search-04.txt)

The IESG has approved the following document:
- 'IMAP4 Multimailbox SEARCH Extension'
  (draft-ietf-appsawg-multimailbox-search-04.txt) as Proposed Standard

This document is the product of the Applications Area Working Group.

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/


Technical Summary

   The IMAP4 specification allows the searching of only the selected
   mailbox.  A user often wants to search multiple mailboxes, and a
   client that wishes to support this must issue a series of SELECT and
   SEARCH commands, waiting for each to complete before moving on to the
   next.  This extension allows a client to search multiple mailboxes
   with one command, limiting round trips delay, and not requiring
   disruption of the currently selected mailbox.  This extension also
   uses MAILBOX and TAG fields in ESEARCH responses, allowing a client
   to pipeline the searches if it chooses.  This document updates RFC
   4466 and obsoletes RFC 6237.

Working Group Summary

   The document was reviewed on the imapext mailing list by several
   participants. This is also where the original work on RFC 6237 was
   done.  There was some discussion within the interested community on
   that list (around a half dozen regular contributors) about whether
   there was ample implementation experience to justify moving it to the
   Standards Track, and after some concerns were addressed in that
   regard, consensus was reached to proceed.

   There is another mechanism referred to as “\all” that a few
   believe to be the more widely deployed solution, but it has not been
   documented and there don’t appear to be any plans to do so.

   There is an imapext thread where this discussion took place,
   including anecdotes of implementation as well as some from people who
   chose not to implement and their reasons.  The thread begins here:

   http://www.ietf.org/mail-archive/web/imapext/current/msg05151.html

   The OpsDir review resulted in the addition of section 2.4.

Document Quality

   This document moves the contained extension from Experimental status
   (originally RFC 6237) to the standards track after some
   implementation experience has shown it to be useful and stable. An
   Implementation Status section appears in the draft.

Personnel

   Murray Kucherawy is the document shepherd.
   Pete Resnick is the responsible Area Director.