< draft-ietf-morg-multimailbox-search-06.txt		draft-ietf-morg-multimailbox-search-07.txt >
	Message ORGanization Working Group B. Leiba		Message ORGanization Working Group B. Leiba
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Updates: 4466 (if approved) A. Melnikov		Updates: 4466 (if approved) A. Melnikov
	Intended status: Experimental Isode Limited		Intended status: Experimental Isode Limited
	Expires: August 14, 2011 February 10, 2011		Expires: September 6, 2011 March 5, 2011
	IMAP4 Multimailbox SEARCH Extension		IMAP4 Multimailbox SEARCH Extension
	draft-ietf-morg-multimailbox-search-06		draft-ietf-morg-multimailbox-search-07
	Abstract		Abstract
	The IMAP4 specification allows the searching only of the selected		The IMAP4 specification allows the searching only of the selected
	mailbox. A user often wants to search multiple mailboxes, and a		mailbox. A user often wants to search multiple mailboxes, and a
	client that wishes to support this must issue a series of SELECT and		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		SEARCH commands, waiting for each to complete before moving on to the
	next. This extension allows a client to search multiple mailboxes		next. This extension allows a client to search multiple mailboxes
	with one command, limiting the round-trips and waiting for various		with one command, limiting the round-trips and waiting for various
	searches to complete, and not requiring disruption of the currently		searches to complete, and not requiring disruption of the currently
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 14, 2011.		This Internet-Draft will expire on September 6, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 23 ¶
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	This section defines a new ESEARCH command, which works similarly to		This section defines a new ESEARCH command, which works similarly to
	the UID SEARCH command described in section 2.6.1 of [RFC4466]		the UID SEARCH command described in section 2.6.1 of [RFC4466]
	(initially described in section 6.4.4 of [RFC3501] and extended by		(initially described in section 6.4.4 of [RFC3501] and extended by
	[RFC4731]).		[RFC4731]).
	The ESEARCH command further extends searching by allowing for		The ESEARCH command further extends searching by allowing for
	optional source and result options. This document does not define		optional source and result options. This document does not define
	any new result options (see Section 3.1 of [RFC4731]). A server that		any new result options (see Section 3.1 of [RFC4731]). A server that
	supports this extension includes [[fix-for-pub-1: "X-DRAFT-I05-MMBX"		supports this extension includes "MULTISEARCH" in its IMAP capability
	(changes for publication)]] in its IMAP capability string.		string.
	Because there has been confusion about this, it is worth pointing out		Because there has been confusion about this, it is worth pointing out
	that with ESEARCH, as with *any* SEARCH or UID SEARCH command, it		that with ESEARCH, as with *any* SEARCH or UID SEARCH command, it
	MUST NOT be considered an error if the search terms include a range		MUST NOT be considered an error if the search terms include a range
	of message numbers that extends (or, in fact, starts) beyond the end		of message numbers that extends (or, in fact, starts) beyond the end
	of the mailbox. For example, a client might want to establish a		of the mailbox. For example, a client might want to establish a
	rolling window through the search results this way:		rolling window through the search results this way:
	C: tag1 UID ESEARCH FROM "frobozz" 1:100		C: tag1 UID ESEARCH FROM "frobozz" 1:100
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	mailboxes that are subordinate to it, through an indefinitely		mailboxes that are subordinate to it, through an indefinitely
	deep hierarchy. The "subtree-one" specifier results in a search		deep hierarchy. The "subtree-one" specifier results in a search
	of the specified mailbox and all selectable child mailboxes, one		of the specified mailbox and all selectable child mailboxes, one
	hierarchy level down.		hierarchy level down.
	If "subtree" is specified, the server MUST defend against loops in		If "subtree" is specified, the server MUST defend against loops in
	the hierarchy (for example, those caused by recursive file-system		the hierarchy (for example, those caused by recursive file-system
	links within the message store). The server SHOULD do this by		links within the message store). The server SHOULD do this by
	keeping track of the mailboxes that have been searched, and		keeping track of the mailboxes that have been searched, and
	terminating the hierarchy traversal when a repeat is found. If it		terminating the hierarchy traversal when a repeat is found. If it
	can not do that, it MAY do it by limiting the hierarchy depth.		cannot do that, it MAY do it by limiting the hierarchy depth.
	If the source options are not present, the value "selected" is		If the source options are not present, the value "selected" is
	assumed -- that is, only the currently selected mailbox is searched.		assumed -- that is, only the currently selected mailbox is searched.
	The "personal" source option is a particularly convenient way to		The "personal" source option is a particularly convenient way to
	search all of the current user's mailboxes. Note that there is no		search all of the current user's mailboxes. Note that there is no
	way to use wildcard characters to search all mailboxes; the		way to use wildcard characters to search all mailboxes; the
	"mailboxes" source option does not do wildcard expansion.		"mailboxes" source option does not do wildcard expansion.
	If the source options include (or default to) "selected", the IMAP		If the source options include (or default to) "selected", the IMAP
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 16 ¶
	searched in one command, and/or on the server resources that will be		searched in one command, and/or on the server resources that will be
	devoted to responding to a single client, are reasonable limitations		devoted to responding to a single client, are reasonable limitations
	for an implementation to impose.		for an implementation to impose.
	Implementations MUST, of course, apply access controls appropriately,		Implementations MUST, of course, apply access controls appropriately,
	limiting a user's access to ESEARCH in the same way its access is		limiting a user's access to ESEARCH in the same way its access is
	limited for any other IMAP commands. This extension has no data-		limited for any other IMAP commands. This extension has no data-
	access risks beyond what may be there in the unextended IMAP		access risks beyond what may be there in the unextended IMAP
	implementation.		implementation.
			Mailboxes matching the source options for which the logged in user
			lacks sufficient rights MUST be ignored by the ESEARCH command
			processing (see the paragraph about this in Section 2.2). In
			particular, any attempt to distinguish insufficient access from non-
			existent mailboxes may expose information about the mailbox hierarchy
			that isn't otherwise available to the client.
			If "subtree" is specified, the server MUST defend against loops in
			the hierarchy (see the paragraph about this in Section 2.2).
	6. IANA Considerations		6. IANA Considerations
	IMAP4 capabilities are registered by publishing a standards track or		IMAP4 capabilities are registered by publishing a standards track or
	IESG approved experimental RFC. The registry is currently located		IESG approved experimental RFC. The registry is currently located
	here:		here:
	http://www.iana.org/assignments/imap4-capabilities		http://www.iana.org/assignments/imap4-capabilities
	This document defines the IMAP capability [[fix-for-pub-2: X-DRAFT-		This document defines the IMAP capability "MULTISEARCH" and IANA is
	I03-MMBX (changes for publication)]], and IANA is asked to add it to		asked to add it to the registry.
	the registry.
	7. Acknowledgements		7. Acknowledgements
	The authors gratefully acknowledge feedback provided by Timo		The authors gratefully acknowledge feedback provided by Timo
	Sirainen, Peter Coates and Arnt Gulbrandsen.		Sirainen, Peter Coates and Arnt Gulbrandsen.
	8. Normative References		8. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 7 change blocks.
	9 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/