IMAP4 Multimailbox SEARCH Extension
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.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.