1. Summary
Murray Kucherawy is the document shepherd.
Pete Resnick is the responsible Area Director.
From the Abstract:
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.
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.
2. Review and Consensus
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” (I am not an IMAP expert by
any stretch so I can’t comment on this myself) 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
3. Intellectual Property
The authors have affirmed that they know of no cause to make any IPR filings
under BCPs 78 and 79. This issue was also specifically called out in the WGLC,
and there were no such statements made by the working group or on the imapext
list (to which the WGLC was forwarded).
4. Other Points
Nothing of note.