< draft-melnikov-imap-partial-01.txt		draft-melnikov-imap-partial-02.txt >
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode		Internet-Draft Isode
	Updates: 5267, 4731 (if approved) A. P. Achuthan		Updates: 5267, 4731 (if approved) A. P. Achuthan
	Intended status: Standards Track V. Nagulakonda		Intended status: Standards Track V. Nagulakonda
	Expires: 20 May 2022 Yahoo!		Expires: 16 July 2022 L. Alves
	L. Alves		Yahoo!
	Verizon		12 January 2022
	16 November 2021
	IMAP Paged SEARCH & FETCH Extension		IMAP Paged SEARCH & FETCH Extension
	draft-melnikov-imap-partial-01		draft-melnikov-imap-partial-02
	Abstract		Abstract
	The PARTIAL extension of the Internet Message Access Protocol (RFC		The PARTIAL extension of the Internet Message Access Protocol (RFC
	3501/RFC 9051) allows clients to limit the number of search results		3501/RFC 9051) allows clients to limit the number of search results
	returned, as well as to perform incremental (paged) searches. This		returned, as well as to perform incremental (paged) searches. This
	also helps servers to optimize resource usage when performing		also helps servers to optimize resource usage when performing
	searches.		searches.
	This document extends PARTIAL SEARCH return option originally		This document extends PARTIAL SEARCH return option originally
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 45 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 20 May 2022.		This Internet-Draft will expire on 16 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3		1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
	2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3		2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3
	3. The PARTIAL extension . . . . . . . . . . . . . . . . . . . . 3		3. The PARTIAL extension . . . . . . . . . . . . . . . . . . . . 3
	3.1. Incremental SEARCH and partial results . . . . . . . . . 4		3.1. Incremental SEARCH and partial results . . . . . . . . . 4
	3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH		3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH
	return options . . . . . . . . . . . . . . . . . . . . . 5		return options . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Extension to UID FETCH . . . . . . . . . . . . . . . . . 6		3.3. Extension to UID FETCH . . . . . . . . . . . . . . . . . 6
	3.4. Use of PARTIAL and CONDSTORE IMAP extensions together . . 7		3.4. Use of PARTIAL and CONDSTORE IMAP extensions together . . 7
	4. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 7		4. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 7
	4.1. Returning limits on the number of messages processed in a		4.1. Returning limits on the number of messages processed in a
	single SEARCH/FETCH/STORE/COPY/MOVE command . . . . . . . 7		single SEARCH/FETCH/STORE/COPY/MOVE command . . . . . . . 8
	5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Changes/additions to the IMAP4 capabilities registry . . 9		7.1. Changes/additions to the IMAP4 capabilities registry . . 11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction and Overview		1. Introduction and Overview
	This document defines an extension to the Internet Message Access		This document defines an extension to the Internet Message Access
	Protocol [RFC3501] for performing incremental searches and fetches.		Protocol [RFC3501] for performing incremental searches and fetches.
	This extension is compatible with both IMAP4rev1 [RFC3501] and		This extension is compatible with both IMAP4rev1 [RFC3501] and
	IMAP4rev2 [RFC9051].		IMAP4rev2 [RFC9051].
	The PARTIAL extension of the Internet Message Access Protocol (RFC		The PARTIAL extension of the Internet Message Access Protocol (RFC
	3501/RFC 9051) allows clients to limit the number of search results		3501/RFC 9051) allows clients to limit the number of search results
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	Other capitalised words are IMAP keywords [RFC3501][RFC9051] or		Other capitalised words are IMAP keywords [RFC3501][RFC9051] or
	keywords from this document.		keywords from this document.
	3. The PARTIAL extension		3. The PARTIAL extension
	An IMAP server advertises support for the PARTIAL extension by		An IMAP server advertises support for the PARTIAL extension by
	including "PARTIAL" capability in the CAPABILITY response/response		including "PARTIAL" capability in the CAPABILITY response/response
	code.		code.
			Clients that implement support for PARTIAL extension MUST also
			support the MESSAGELIMIT response code (see Section 4).
	3.1. Incremental SEARCH and partial results		3.1. Incremental SEARCH and partial results
	The PARTIAL search return option causes the server to provide in an		The PARTIAL search return option causes the server to provide in an
	ESEARCH response a subset of the results denoted by the sequence		ESEARCH response a subset of the results denoted by the sequence
	range given as the mandatory argument. The first result (message		range given as the mandatory argument. The first result (message
	with the lowest matching UID) is 1; thus, the first 500 results would		with the lowest matching UID) is 1; thus, the first 500 results would
	be obtained by a return option of "PARTIAL 1:500", and the second 500		be obtained by a return option of "PARTIAL 1:500", and the second 500
	by "PARTIAL 501:1000". This intentionally mirrors message sequence		by "PARTIAL 501:1000". This intentionally mirrors message sequence
	numbers.		numbers.
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 35 ¶
	The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE		The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE
	FETCH modifier.		FETCH modifier.
	// Returning information for the last 30 messages in the UID range		// Returning information for the last 30 messages in the UID range
	// that have any flag/keyword modified since modseq 98305		// that have any flag/keyword modified since modseq 98305
	C: 101 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-30 CHANGEDSINCE 98305)		C: 101 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-30 CHANGEDSINCE 98305)
	S: * 12888 FETCH (FLAGS (\Flagged \Answered) MODSEQ (98306) UID 25997)		S: * 12888 FETCH (FLAGS (\Flagged \Answered) MODSEQ (98306) UID 25997)
	S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600)		S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600)
	S: 101 OK FETCH completed		S: 101 OK FETCH completed
	Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers is		The above example causes the server to first select the last 30
	not important.		messages and then only return flag changes for subset of these
			messages which have MODSEQ higher than 98305.
			Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in
			the UID FETCH command is not important, i.e. the above example can
			also use "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305
			PARTIAL -1:-30)" command and it would result in the same responses.
	4. The MESSAGELIMIT extension		4. The MESSAGELIMIT extension
	An IMAP server advertises support for the MESSAGELIMIT extension by		An IMAP server advertises support for the MESSAGELIMIT extension by
	including "MESSAGELIMIT=<limit>" capability in the CAPABILITY		including "MESSAGELIMIT=<limit>" capability in the CAPABILITY
	response/response code, where "<limit>" is a positive integer that		response/response code, where "<limit>" is a positive integer that
	conveys the maximum number of messages that can be processed in a		conveys the maximum number of messages that can be processed in a
	single SEARCH/FETCH/STORE/COPY/MOVE command.		single SEARCH/FETCH/STORE/COPY/MOVE command.
	4.1. Returning limits on the number of messages processed in a single		4.1. Returning limits on the number of messages processed in a single
	SEARCH/FETCH/STORE/COPY/MOVE command		SEARCH/FETCH/STORE/COPY/MOVE command
	// Should this be a separate IMAP capability?		// Do we need a way to specify SEARCH criterion for "all UIDs after"
	// Also, should this also affect SEARCH? If yes, do we need a way to		// or "all UIDs before" a specific UID?
	// specify SEARCH criterion for "all UIDs after" or "all UIDs before"
	// a specific UID?
	If a server implementation doesn't allow more than <N> messages to be		If a server implementation doesn't allow more than <N> messages to be
	operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command, it MUST		operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command, it MUST
	return the MESSAGELIMIT response code defined below:		return the MESSAGELIMIT response code defined below:
	MESSAGELIMIT The server doesn't allow more than <N> messages to be operated		MESSAGELIMIT The server doesn't allow more than <N> messages to be operated
	on by a single SEARCH/FETCH/STORE/COPY/MOVE command. The		on by a single SEARCH/FETCH/STORE/COPY/MOVE command. The
	lowest processed UID is <LastUID>. The client needs to repeat		lowest processed UID is <LastUID>. The client needs to repeat
	the operation for remaining messages.		the operation for remaining messages, if required.
			In the following example the <N> value is 1000 and the lowest
			processed UID <LastUID> is 23221.
	C: 03 FETCH 10000:14589 (UID FLAGS)		C: 03 FETCH 10000:14589 (UID FLAGS)
	S: * 14589 FETCH (FLAGS (\Seen) UID 25000)		S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
	S: * 14588 FETCH (FLAGS (\Answered) UID 24998)		S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
	S: ... further 997 fetch responses		S: ... further 997 fetch responses
	S: * 13590 FETCH (FLAGS () UID 23221)		S: * 13590 FETCH (FLAGS () UID 23221)
	S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial		S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial
	results		results
	In the above example the <N> value is 1000 and the lowest		In the following example the client searches for UNDELETED UIDs
	processed UID <LastUID> is 23221.		between 22000:25000. The total number of matching messages
			exceeds the server's published 1000 messages limit.
			C: 04 UID SEARCH UID 22000:25000 UNDELETED
			S: * SEARCH 25000 24998 (... 997 UIDs ...) 23221
			S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 partial results
			The following example demonstrates copy of messages with UIDs
			between 18000:21000. The total message count exceeds the
			server's published 1000 messages limit.
			C: 05 UID COPY 18000:21000 "Trash"
			S: * NO [MESSAGELIMIT 1000 20001] Too many messages to copy
			S: 05 OK [COPYUID 1397597919 20001:21000 21363:22362] COPY completed for the last 1000 messages
			// Open Issue:
			The following example shows MOVE of messages with UIDs between
			18000:21000. The total message count exceeds the server's
			published 1000 messages limit. The client that wants to move
			all messages in the range and observes a MESSAGELIMIT response
			code, can repeat the command by updating the UID set parameter
			specified in the command. The client needs to keep doing this
			until MESSAGELIMIT response is not returned (or until a tagged
			NO/BAD is returned).
			C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12"
			S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some messages were not moved
			S: * 12336 EXPUNGE
			S: * 12335 EXPUNGE
			...
			S: * 11335 EXPUNGE
			S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last 1000 messages
			The following example shows update of flags for messages with
			UIDs between 18000:20000. The total message count exceeds the
			server's published 1000 messages limit. The client that wants
			to change flags for all messages in the range and observes a
			MESSAGELIMIT response code, can repeat the command by updating
			the UID set parameter specified in the command. The client
			needs to keep doing this until MESSAGELIMIT response is not
			returned (or until a tagged NO/BAD is returned).
			C: 07 UID STORE 18000:20000 +FLAGS (\Seen)
			S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000)
			S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998)
			...
			S: * 10216 FETCH (FLAGS (\Seen) UID 19578)
			S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last 1000 messages
			The following example shows use of MESSAGELIMIT response code
			together with the PARTIAL extension. The total message count
			exceeds the server's published 1000 messages limit.
			C: 08 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500)
			S: 08 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000 message limit
			Note that when the server needs to return both EXPUNGEISSUED
			([RFC9051]) and MESSAGELIMIT response codes, the former MUST be
			returned in the tagged OK response, while the latter MUST be returned
			in an untagged NO response. The following example demonstrates that:
			C: 031 FETCH 10000:14589 (UID FLAGS)
			S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
			S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
			S: ... further 997 fetch responses
			S: * 13590 FETCH (FLAGS () UID 23221)
			S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial
			results
			S: 031 OK [EXPUNGEISSUED] Some messages were also expunged
	5. Formal syntax		5. Formal syntax
	The following syntax specification uses the Augmented Backus-Naur		The following syntax specification uses the Augmented Backus-Naur
	Form (ABNF) notation as specified in [ABNF].		Form (ABNF) notation as specified in [ABNF].
	Non-terminals referenced but not defined below are as defined by		Non-terminals referenced but not defined below are as defined by
	IMAP4 [RFC3501].		IMAP4 [RFC3501].
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	skipping to change at page 9, line 31 ¶		skipping to change at page 11, line 24 ¶
	tagged-ext-simple =/ partial-range-last		tagged-ext-simple =/ partial-range-last
	fetch-modifier =/ modifier-partial		fetch-modifier =/ modifier-partial
	capability =/ "MESSAGELIMIT=" message-limit		capability =/ "MESSAGELIMIT=" message-limit
	;; <capability> from [RFC3501]		;; <capability> from [RFC3501]
	message-limit = nz-number		message-limit = nz-number
	resp-text-code =/ "MESSAGELIMIT" SP message-limit SP uniqueid		resp-text-code =/ "MESSAGELIMIT" SP message-limit [SP uniqueid]
	;; No more than nz-number messages can be processed		;; No more than nz-number messages can be processed
	;; by any command at a time. The last (lowest) processed		;; by any command at a time. The last (lowest) processed
	;; UID is uniqueid.		;; UID is uniqueid.
			;; The last parameter is omitted, when not known.
	6. Security Considerations		6. Security Considerations
	TBD.		TBD.
	7. IANA Considerations		7. IANA Considerations
	7.1. Changes/additions to the IMAP4 capabilities registry		7.1. Changes/additions to the IMAP4 capabilities registry
	IMAP4 capabilities are registered by publishing a standards track or		IMAP4 capabilities are registered by publishing a standards track or
	skipping to change at page 10, line 13 ¶		skipping to change at page 12, line 5 ¶
	https://www.iana.org/assignments/imap4-capabilities		https://www.iana.org/assignments/imap4-capabilities
	IANA is requested to add definition of the PARTIAL extension to point		IANA is requested to add definition of the PARTIAL extension to point
	to this document.		to this document.
	8. Acknowledgments		8. Acknowledgments
	This document was motivated by Yahoo! team and their questions about		This document was motivated by Yahoo! team and their questions about
	best client practices for dealing with large mailboxes.		best client practices for dealing with large mailboxes.
			Editor of this document would like to thank the following people who
			provided useful comments or participated in discussions of this
			document: Timo Sirainen.
	This document uses lots of text from RFC 5267. Thus work of the RFC		This document uses lots of text from RFC 5267. Thus work of the RFC
	5267 authors Dave Cridland and Curtis King is appreciated.		5267 authors Dave Cridland and Curtis King is appreciated.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for		[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
	Syntax Specifications: ABNF", RFC 5234, January 2008,		Syntax Specifications: ABNF", RFC 5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
End of changes. 14 change blocks.
	31 lines changed or deleted		114 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/