< draft-melnikov-imap-partial-00.txt		draft-melnikov-imap-partial-01.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: 25 April 2022 Yahoo!		Expires: 20 May 2022 Yahoo!
	L. Alves		L. Alves
	Verizon		Verizon
	22 October 2021		16 November 2021
	IMAP Paged SEARCH & FETCH Extension		IMAP Paged SEARCH & FETCH Extension
	draft-melnikov-imap-partial-00		draft-melnikov-imap-partial-01
	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
	specified in RFC 5267. It also clarifies some interactions between		specified in RFC 5267. It also clarifies some interactions between
	RFC 5267 and RFC 4731/RFC 9051.		RFC 5267 and RFC 4731/RFC 9051.
			This document also describes the MESSAGELIMIT extension for
			announcing a limit on the number of messages that can be processed in
			a single FETCH/SEARCH/STORE/COPY/MOVE command.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 25 April 2022.		This Internet-Draft will expire on 20 May 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 33 ¶
	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
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2		1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
	2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3		2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3
	3. Incremental SEARCH and partial results . . . . . . . . . . . 3		3. The PARTIAL extension . . . . . . . . . . . . . . . . . . . . 3
	4. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return		3.1. Incremental SEARCH and partial results . . . . . . . . . 4
	options . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH
	5. Extension to FETCH . . . . . . . . . . . . . . . . . . . . . 6		return options . . . . . . . . . . . . . . . . . . . . . 5
	6. Expressing limits on a number of messages used in		3.3. Extension to UID FETCH . . . . . . . . . . . . . . . . . 6
	SEARCH/FETCH/STORE/COPY/MOVE . . . . . . . . . . . . . . 6		3.4. Use of PARTIAL and CONDSTORE IMAP extensions together . . 7
	7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 7		4. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4.1. Returning limits on the number of messages processed in a
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		single SEARCH/FETCH/STORE/COPY/MOVE command . . . . . . . 7
	9.1. Changes/additions to the IMAP4 capabilities registry . . 8		5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	11. Normative References . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7.1. Changes/additions to the IMAP4 capabilities registry . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
			9.1. Normative References . . . . . . . . . . . . . . . . . . 10
			9.2. Informative References . . . . . . . . . . . . . . . . . 10
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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
	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
	specified in RFC 5267.		specified in RFC 5267. It also clarifies some interactions between
			RFC 5267 and RFC 4731/RFC 9051.
			This document also describes the MESSAGELIMIT extension for
			announcing a limit on the number of messages that can be processed in
			a single FETCH/SEARCH/STORE/COPY/MOVE command.
	2. Document Conventions		2. Document Conventions
	In protocol examples, this document uses a prefix of "C: " to denote		In protocol examples, this document uses a prefix of "C: " to denote
	lines sent by the client to the server, and "S: " for lines sent by		lines sent by the client to the server, and "S: " for lines sent by
	the server to the client. Lines prefixed with "// " are comments		the server to the client. Lines prefixed with "// " are comments
	explaining the previous protocol line. These prefixes and comments		explaining the previous protocol line. These prefixes and comments
	are not part of the protocol. Lines without any of these prefixes		are not part of the protocol. Lines without any of these prefixes
	are continuations of the previous line, and no line break is present		are continuations of the previous line, and no line break is present
	in the protocol unless specifically mentioned.		in the protocol unless specifically mentioned.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	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. Incremental SEARCH and partial results		3. The PARTIAL extension
			An IMAP server advertises support for the PARTIAL extension by
			including "PARTIAL" capability in the CAPABILITY response/response
			code.
			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.
	It is also possible to direct the server to start SEARCH from the		It is also possible to direct the server to start SEARCH from the
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 24 ¶
	// 264 results in set syntax elided,		// 264 results in set syntax elided,
	// this spans the end of the results.		// this spans the end of the results.
	S: A02 OK Completed.		S: A02 OK Completed.
	S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...)		S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...)
	// 500 results in set syntax elided.		// 500 results in set syntax elided.
	S: A03 OK Completed.		S: A03 OK Completed.
	S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL)		S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL)
	// No results are present, this is beyond the end of the results.		// No results are present, this is beyond the end of the results.
	S: A04 OK Completed.		S: A04 OK Completed.
	4. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return options		3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return
			options
	This section only applies if the server advertises PARTIAL IMAP		This section only applies if the server advertises PARTIAL IMAP
	capability or CONTEXT=SEARCH [RFC5267], together with ESEARCH		capability or CONTEXT=SEARCH [RFC5267], together with ESEARCH
	[RFC4731] and/or IMAP4rev2"[RFC9051].		[RFC4731] and/or IMAP4rev2"[RFC9051].
	The SAVE result option doesn't change whether the server would return		The SAVE result option doesn't change whether the server would return
	items corresponding to PARTIAL SEARCH result options.		items corresponding to PARTIAL SEARCH result options.
	As specified in Section 3, it is an error to specify both PARTIAL and		As specified in Section 3.1, it is an error to specify both PARTIAL
	ALL result options in the same SEARCH command.		and ALL result options in the same SEARCH command.
	When the SAVE result option is combined with the PARTIAL result		When the SAVE result option is combined with the PARTIAL result
	option, and none of MIN/MAX/COUNT result options is present, the		option, and none of MIN/MAX/COUNT result options is present, the
	corresponding PARTIAL is returned, and the "$" marker would contain		corresponding PARTIAL is returned, and the "$" marker would contain
	all messages returned by the PARTIAL result option.		all messages returned by the PARTIAL result option.
	When the SAVE + PARTIAL result options are combined with the MIN or		When the SAVE + PARTIAL result options are combined with the MIN or
	the MAX result option, and the COUNT result option is absent, the		the MAX result option, and the COUNT result option is absent, the
	corresponding PARTIAL result and MIN/MAX is returned (if the search		corresponding PARTIAL result and MIN/MAX is returned (if the search
	result is not empty), and the "$" marker would contain all messages		result is not empty), and the "$" marker would contain all messages
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 37 ¶
	+------------------------------+---------------------+		+------------------------------+---------------------+
	| SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX |		| SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX |
	+------------------------------+---------------------+		+------------------------------+---------------------+
	| SAVE PARTIAL COUNT [m] | all found messages |		| SAVE PARTIAL COUNT [m] | all found messages |
	+------------------------------+---------------------+		+------------------------------+---------------------+
	Table 1		Table 1
	where '[m]' means optional "MIN" and/or "MAX"		where '[m]' means optional "MIN" and/or "MAX"
	5. Extension to FETCH		3.3. Extension to UID FETCH
	The PARTIAL extension also extends the FETCH command with a PARTIAL		The PARTIAL extension also extends the UID FETCH command with a
	FETCH modifier. The PARTIAL FETCH modifier has the same syntax as		PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same
	the PARTIAL SEARCH result option. Presence of the PARTIAL FETCH		syntax as the PARTIAL SEARCH result option. Presence of the PARTIAL
	modifier instructs the server to only return FETCH results for		FETCH modifier instructs the server to only return FETCH results for
	messages in the specified range. It is useful when the sequence-set		messages in the specified range. It is useful when the sequence-set
	(first) parameter to FETCH/UID FETCH command includes unknown number		(first) parameter to the UID FETCH command includes unknown number of
	of messages.		messages.
	// Returning information for the last 3 messages in the UID range		// Returning information for the last 3 messages in the UID range
	C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3)		C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3)
	S: * 12888 FETCH (FLAGS (\Seen) UID 25996)		S: * 12888 FETCH (FLAGS (\Seen) UID 25996)
	S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997)		S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997)
	S: * 12890 FETCH (FLAGS () UID 26600)		S: * 12890 FETCH (FLAGS () UID 26600)
	S: 10 OK FETCH completed		S: 10 OK FETCH completed
	// Returning information for the first 5 messages in the UID range		// Returning information for the first 5 messages in the UID range
	C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5)		C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5)
	S: * 12591 FETCH (FLAGS (\Seen) UID 25900)		S: * 12591 FETCH (FLAGS (\Seen) UID 25900)
	S: * 12592 FETCH (FLAGS (\Flagged) UID 25902)		S: * 12592 FETCH (FLAGS (\Flagged) UID 25902)
	S: * 12593 FETCH (FLAGS (\Answered) UID 26310)		S: * 12593 FETCH (FLAGS (\Answered) UID 26310)
	S: * 12594 FETCH (FLAGS () UID 26311)		S: * 12594 FETCH (FLAGS () UID 26311)
	S: * 12595 FETCH (FLAGS (\Answered) UID 26498)		S: * 12595 FETCH (FLAGS (\Answered) UID 26498)
	S: 11 OK FETCH completed		S: 11 OK FETCH completed
	6. Expressing limits on a number of messages used in		3.4. Use of PARTIAL and CONDSTORE IMAP extensions together
	SEARCH/FETCH/STORE/COPY/MOVE
			This section is informative.
			The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE
			FETCH modifier.
			// Returning information for the last 30 messages in the UID range
			// that have any flag/keyword modified since modseq 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: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600)
			S: 101 OK FETCH completed
			Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers is
			not important.
			4. The MESSAGELIMIT extension
			An IMAP server advertises support for the MESSAGELIMIT extension by
			including "MESSAGELIMIT=<limit>" capability in the CAPABILITY
			response/response code, where "<limit>" is a positive integer that
			conveys the maximum number of messages that can be processed in a
			single SEARCH/FETCH/STORE/COPY/MOVE command.
			4.1. Returning limits on the number of messages processed in a single
			SEARCH/FETCH/STORE/COPY/MOVE command
	// Should this be a separate IMAP capability?		// Should this be a separate IMAP capability?
	// Also, should this also affect SEARCH? If yes, do we need a way to		// Also, should this also affect SEARCH? If yes, do we need a way to
	// specify SEARCH criterion for "all UIDs after" or "all UIDs before"		// specify SEARCH criterion for "all UIDs after" or "all UIDs before"
	// a specific UID?		// 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 FETCH/STORE/COPY/MOVE command, it MUST return		operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command, it MUST
	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 last		on by a single SEARCH/FETCH/STORE/COPY/MOVE command. The
	processed UID is <LastUID>. The client needs to repeat the		lowest processed UID is <LastUID>. The client needs to repeat
	operation for remaining messages.		the operation for remaining messages.
	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 last		In the above example the <N> value is 1000 and the lowest
	processed UID <LastUID> is 23221.		processed UID <LastUID> is 23221.
	7. 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-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	skipping to change at page 8, line 26 ¶		skipping to change at page 9, line 26 ¶
	;; <partial-range> is the requested range.		;; <partial-range> is the requested range.
	partial-results = sequence-set / "NIL"		partial-results = sequence-set / "NIL"
	;; <sequence-set> from [RFC3501].		;; <sequence-set> from [RFC3501].
	;; NIL indicates no results correspond to the requested range.		;; NIL indicates no results correspond to the requested range.
	tagged-ext-simple =/ partial-range-last		tagged-ext-simple =/ partial-range-last
	fetch-modifier =/ modifier-partial		fetch-modifier =/ modifier-partial
	resp-text-code =/ "MESSAGELIMIT" SP nz-number SP uniqueid		capability =/ "MESSAGELIMIT=" message-limit
			;; <capability> from [RFC3501]
			message-limit = nz-number
			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 processed		;; by any command at a time. The last (lowest) processed
	;; UID is uniqueid.		;; UID is uniqueid.
	8. Security Considerations		6. Security Considerations
	TBD.		TBD.
	9. IANA Considerations		7. IANA Considerations
	9.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
	IESG approved Informational or Experimental RFC. The registry is		IESG approved Informational or Experimental RFC. The registry is
	currently located at:		currently located at:
	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.
	10. 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.
	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.
	11. Normative References		9. 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>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 51 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message		[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
	Access Protocol (IMAP) - Version 4rev2", RFC 9051,		Access Protocol (IMAP) - Version 4rev2", RFC 9051,
	DOI 10.17487/RFC9051, August 2021,		DOI 10.17487/RFC9051, August 2021,
	<https://www.rfc-editor.org/info/rfc9051>.		<https://www.rfc-editor.org/info/rfc9051>.
			9.2. Informative References
			[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
			Changes Resynchronization (CONDSTORE) and Quick Mailbox
			Resynchronization (QRESYNC)", RFC 7162,
			DOI 10.17487/RFC7162, May 2014,
			<https://www.rfc-editor.org/info/rfc7162>.
	Index		Index
	M		M
	M		M
	MESSAGELIMIT (response code)		MESSAGELIMIT (response code)
	Section 6, Paragraph 3.2.1		Section 4.1, Paragraph 3.2.1
	Authors' Addresses		Authors' Addresses
	Alexey Melnikov		Alexey Melnikov
	Isode Limited		Isode Limited
	Email: alexey.melnikov@isode.com		Email: alexey.melnikov@isode.com
	URI: https://www.isode.com		URI: https://www.isode.com
	Arun Prakash Achuthan		Arun Prakash Achuthan
	Yahoo!		Yahoo!
	Email: arunprakash@myyahoo.com		Email: arunprakash@myyahoo.com
	Vikram Nagulakonda		Vikram Nagulakonda
	Yahoo!		Yahoo!
	Email: nvikram_imap@yahoo.com		Email: nvikram_imap@yahoo.com
	Luis Alves		Luis Alves
	Verizon Media		Yahoo!
	Email: luis.alves@lafaspot.com		Email: luis.alves@lafaspot.com
End of changes. 30 change blocks.
	50 lines changed or deleted		110 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/