Diff: rfc9394xml2.original.xml

	rfc9394xml2.original.xml	rfc9394.xml

	<?xml version="1.0"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.2119.xml'>
	<!ENTITY rfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.3501.xml'>
	<!ENTITY rfc4731 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.4731.xml'>
	<!ENTITY rfc5267 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.5267.xml'>
	<!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.8174.xml'>
	<!ENTITY rfc9051 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.9051.xml'>


		<!-- [CS] updated by Chris 01/23/23 -->

		<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
	<rfc category="std" ipr="pre5378Trust200902" updates="5267, 4731" docName="draft
	-ietf-extra-imap-partial-04">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<front>
	<title abbrev="IMAP PARTIAL">
	IMAP Paged SEARCH & FETCH Extension
	</title>
	<author initials="A." surname="Melnikov" fullname="Alexey Melniko
	v">
	<organization abbrev="Isode">
	Isode Limited
	</organization>
	<address>
	<email>alexey.melnikov@isode.com</email>
	<uri>https://www.isode.com</uri>
	</address>
	</author>


		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
		std" consensus="true" docName="draft-ietf-extra-imap-partial-04" number="9394" i
		pr="pre5378Trust200902" updates="4731, 5267" obsoletes="" xml:lang="en" tocInclu
		de="true" symRefs="true" sortRefs="true" version="3">

		<!-- xml2rfc v2v3 conversion 3.15.3 -->

		<front>
		<title abbrev="IMAP PARTIAL Extension">
		IMAP PARTIAL Extension for Paged SEARCH and FETCH
		</title>
		<seriesInfo name="RFC" value="9394"/>
		<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
		<organization abbrev="Isode">Isode Limited</organization>
		<address>
		<email>alexey.melnikov@isode.com</email>
		<uri>https://www.isode.com</uri>
		</address>
		</author>
	<author initials="A. P." surname="Achuthan" fullname="Arun Prakash Achuthan" >	<author initials="A. P." surname="Achuthan" fullname="Arun Prakash Achuthan" >

	<organization abbrev="Yahoo!">	<organization abbrev="Yahoo!">Yahoo!</organization>
	Yahoo!
	</organization>
	<address>	<address>
	<email>arunprakash@myyahoo.com</email>	<email>arunprakash@myyahoo.com</email>
	</address>	</address>
	</author>	</author>


	<author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">	<author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">

	<organization abbrev="Yahoo!">	<organization abbrev="Yahoo!">Yahoo!</organization>
	Yahoo!
	</organization>
	<address>	<address>
	<email>nvikram_imap@yahoo.com</email>	<email>nvikram_imap@yahoo.com</email>
	</address>	</address>
	</author>	</author>


	<author initials="L." surname="Alves" fullname="Luis Alves">	<author initials="L." surname="Alves" fullname="Luis Alves">
	<address>	<address>
	<email>luis.alves@lafaspot.com</email>	<email>luis.alves@lafaspot.com</email>
	</address>	</address>
	</author>	</author>

		<date year="2023" month="June" />
	<date year="2022"/>	<area>art</area>
	<abstract>	<workgroup>extra</workgroup>
	<t>The PARTIAL extension of the Internet Message Access P	<abstract>
	rotocol (RFC 3501/RFC 9051)	<t>The PARTIAL extension of the Internet Message Access Protocol (see RFCs
	allows clients to limit the number of search results retu	3501 and 9051)
	rned, as well as to perform incremental (paged) searches.	allows clients to limit the number of SEARCH results ret
		urned, as well as to perform incremental (paged) searches.
	This also helps servers to optimize resource usage when performing searche s.	This also helps servers to optimize resource usage when performing searche s.
	</t>	</t>

		<t>This document extends the PARTIAL SEARCH return option originally speci
		fied in RFC 5267.
		It also clarifies some interactions between RFC 5267 and RFCs 4731 and 905
		1.</t>


	<t>This document extends PARTIAL SEARCH return option originally specified	<t>This document updates RFCs 4731 and 5267.</t>
	in RFC 5267.
	It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051
	.</t>

	</abstract>	</abstract>

	</front>	</front>
	<middle>	<middle>
		<section numbered="true" toc="default">
	<section title="Introduction and Overview">	<name>Introduction and Overview</name>
		<t>This document defines an extension to the Internet Message Access Proto
	<t>This document defines an extension to the Internet Message Access Proto	col <xref target="RFC3501" format="default"/> <xref target="RFC9051" format="def
	col <xref target="RFC3501"/>	ault"/>
	for performing incremental searches and fetches.	for performing incremental searches and fetches.

	This extension is compatible with both IMAP4rev1 <xref target="RFC3501"/>	This extension is compatible with both IMAP4rev1 <xref target="RFC3501" fo
	and IMAP4rev2 <xref target="RFC9051"/>.</t>	rmat="default"/> and IMAP4rev2 <xref target="RFC9051" format="default"/>.
		This extension uses IMAP extensibility rules defined in <xref target="RFC4
		466"/>.</t>
	<t>	<t>

	The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RF	The PARTIAL extension of the Internet Message Access Protocol
	C 9051)	allows clients to limit the number of SEARCH results returned, as well as
	allows clients to limit the number of search results returned, as well as	to perform incremental (paged) searches.
	to perform incremental (paged) searches.
	This also helps servers to optimize resource usage when performing searche s.	This also helps servers to optimize resource usage when performing searche s.
	</t>	</t>

		<t>This document extends the PARTIAL SEARCH return option originally speci
	<t>This document extends PARTIAL SEARCH return option originally specified	fied in RFC 5267.
	in RFC 5267.	It also clarifies some interactions between RFC 5267 and RFCs 4731 and 905
	It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051	1.</t>
	.</t>	</section>
		<section numbered="true" toc="default">
	</section>	<name>Document Conventions</name>
		<t>In protocol examples, this document uses a prefix of "C: " to denote li
	<section title="Document Conventions">	nes sent by the client to the server and
	<t>In protocol examples, this document uses a prefix of "	"S: " for lines sent by the server to the client. Lines
	C: " to denote lines sent by the client to the server, and	prefixed with "// " are comments explaining the previous protocol line.
	"S: " for lines sent by the server to the client. Lines p	These prefixes and comments are not part of the protocol
	refixed with "// " are comments explaining the previous protocol line.	. Lines without any of these prefixes are continuations of the previous line,
	These prefixes and comments are not part of the protocol.	and no line breaks are present in the protocol unless sp
	Lines without any of these prefixes are continuations of the previous line,	ecifically mentioned.</t>
	and no line break is present in the protocol unless speci	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	fically mentioned.</t>	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	<t>	"<bcp14>SHOULD NOT</bcp14>",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	"OPTIONAL" in this document are to be interpreted as described in BC	are to be interpreted as described in BCP 14
	P	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	14 <xref target="RFC2119"/> <xref target="RFC8174"/>	when, they appear in all capitals, as shown here.</t>
	when, and only when, they appear in all capitals, as shown here.	<t>Other capitalized words are IMAP key words <xref target="RFC3501"
	</t>	format="default"/> <xref target="RFC9051" format="default"/>
		or key words from this document.</t>
	<!--///Confusion: IMAP keyword is something else. Use "Protocol elements"	</section>
	instead?-->	<section anchor="imap-partial" numbered="true" toc="default">
	<t>Other capitalised words are IMAP keywords <xref target="RFC3501"/	<name>The PARTIAL Extension</name>
	><xref target="RFC9051"/>	<t>An IMAP server advertises support for the PARTIAL extension
	or keywords from this document.</t>	by including the "PARTIAL" capability in the CAPABILITY response / respo
		nse code.</t>
	</section>	<section anchor="partial-def" numbered="true" toc="default">
		<name>Incremental SEARCH and Partial Results</name>
	<section title="The PARTIAL extension" anchor="imap-partial">	<t>

	<t>An IMAP server advertises support for the PARTIAL extension
	by including the "PARTIAL" capability in the CAPABILITY response/respons
	e code.</t>

	<section title="Incremental SEARCH and partial results" anchor="partial-de
	f">

	<t>
	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 <xref target="RFC4731"/><xref target="RFC9051"/> response a subset of the results denoted by the sequence	ESEARCH response <xref target="RFC4731" format="default"/> <xref target="R FC9051" format="default"/> a subset of the results denoted by the sequence
	range given as the mandatory argument.	range given as the mandatory argument.

	The first result (message with the lowest matching UID) is 1;	The first result (message with the lowest matching Unique
		Identifier (UID)) is 1;
	thus, the first 500 results would be obtained by a return option of	thus, the first 500 results would be obtained by a return option of

	"PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This	"PARTIAL 1:500" and the second 500 by "PARTIAL 501:1000". This
	intentionally mirrors message sequence numbers.	intentionally mirrors message sequence numbers.

	</t>	</t>
		<t>
	<t>	It is also possible to direct the server to start the SEARCH from the late
	It is also possible to direct the server to start SEARCH from the latest	st
	matching (with the highest UID) message. This can be done by prepending "- "	matching (with the highest UID) message. This can be done by prepending "- "

	to the index. For example -1 is the last message, -2 is next to the last a nd so on.	to the index. For example, -1 is the last message, -2 is next to the last, and so on.
	Using this syntax helps server implementations to optimize their SEARCHes.	Using this syntax helps server implementations to optimize their SEARCHes.

	</t>	</t>
		<t>
	<t>	A single command <bcp14>MUST NOT</bcp14> contain more than one PARTIAL or
	A single command MUST NOT contain more than one PARTIAL or ALL search	ALL search
	return option -- that is, either one PARTIAL, one ALL, or neither	return option; that is, either one PARTIAL, one ALL, or neither
	PARTIAL nor ALL is allowed.	PARTIAL nor ALL is allowed.

	</t>	</t>
		<t>
	<t>	For SEARCH results, the entire list of results <bcp14>MUST</bcp14> be orde
	For SEARCH results, the entire result list MUST be ordered in mailbox	red in mailbox
	order, that is, in UID or message sequence number order.	order -- that is, in UID or message sequence number order.
	</t>	</t>
		<t>
	<t>	In cases where a PARTIAL SEARCH return option references results that do n
	Where a PARTIAL SEARCH return option references results that do not	ot
	exist, by using a range which starts or ends higher (or lower<!--In case "	exist by using a range that starts or ends higher (or lower) than the curr
	-N" syntax is used-->) than the current	ent
	number of results, then the server returns the results that are in	number of results, the server returns the results that are in
	the set. This yields a PARTIAL return data item that has, as	the set. This yields a PARTIAL return data item that has, as
	payload, the original range and a potentially missing set of results	payload, the original range and a potentially missing set of results
	that may be shorter than the extent of the range.	that may be shorter than the extent of the range.
	If the whole range references results that do not exist,	If the whole range references results that do not exist,
	a special value "NIL" is returned by the server instead of the sequence se t.	a special value "NIL" is returned by the server instead of the sequence se t.

	</t>	</t>
		<t>
	<t>
	Clients need not request PARTIAL results in any particular order.	Clients need not request PARTIAL results in any particular order.
	Because mailboxes may change, clients might wish to use PARTIAL	Because mailboxes may change, clients might wish to use PARTIAL

	in combination with UPDATE (see <xref target="RFC5267"/>) if the server	in combination with UPDATE (see <xref target="RFC5267" format="default"/>)
	also advertises CONTEXT=SEARCH capability, especially if the intent is to	if the server
	walk a	also advertises the "CONTEXT=SEARCH" capability, especially if the intent
		is to walk a
	large set of results; however, these return options do not interact	large set of results; however, these return options do not interact
	-- the UPDATE will provide notifications for all matching results.	-- the UPDATE will provide notifications for all matching results.

	</t>	</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	// Let's assume that the A01 SEARCH without PARTIAL would return	// Let's assume that the A01 SEARCH without PARTIAL would return
	// 23764 results.	// 23764 results.
	C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED	C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED

	UNKEYWORD $Junk	UNKEYWORD $Junk
	S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...)	S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...)
	// 100 most recent results in set syntax elided.	// 100 most recent results in set syntax elided.
	S: A01 OK Completed.	S: A01 OK Completed.

	]]></artwork></figure>	]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	// Let's assume that the A02 SEARCH without PARTIAL would return	// Let's assume that the A02 SEARCH without PARTIAL would return
	// 23764 results.	// 23764 results.
	C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED	C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED

	UNKEYWORD $Junk	UNKEYWORD $Junk
	C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED	C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED

	UNKEYWORD $Junk	UNKEYWORD $Junk
	C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED	C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED

	UNKEYWORD $Junk	UNKEYWORD $Junk
	S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...)	S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...)

	// 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.

	]]></artwork></figure>	]]></artwork>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Interaction between PARTIAL, MIN, MAX, and SAVE SEARCH Return Opti
	<section title="Interaction between PARTIAL, MIN, MAX and SAVE SEARCH re	ons</name>
	turn options">	<t>This section only applies if the server advertises the "PARTIAL" IMAP
		capability or "CONTEXT=SEARCH" <xref target="RFC5267" format="default"/>,
	<t>This section only applies if the server advertises PARTIAL IMAP capabil	together with "ESEARCH" <xref target="RFC4731" format="default"/> and/or I
	ity or CONTEXT=SEARCH <xref target="RFC5267"/>,	MAP4rev2 <xref target="RFC9051" format="default"/>.</t>
	together with ESEARCH <xref target="RFC4731"/> and/or IMAP4rev2 <xref targ	<t>
	et="RFC9051"/>.</t>

	<t>
	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.

	</t>	</t>
		<t>
	<t>	As specified in <xref target="partial-def" format="default"/>, it is an er
	As specified in <xref target="partial-def"/>, it is an error to specify bo	ror to specify both the
	th
	PARTIAL and ALL result options in the same SEARCH command.	PARTIAL and ALL result options in the same SEARCH command.

	</t>	</t>
		<t>
	<t>
	When the SAVE result option is combined with the PARTIAL	When the SAVE result option is combined with the PARTIAL

	result option, and none of MIN/MAX/COUNT result options is	result option and none of the MIN/MAX/COUNT result options are
	present, the corresponding PARTIAL is returned,	present, the corresponding PARTIAL is returned,

	and the "$" marker would contain <!--references to-->all	and the "$" marker would contain references to all
	messages returned by the PARTIAL result option.	messages returned by the PARTIAL result option.

	</t>	</t>
		<t>
	<t>	When the SAVE and PARTIAL result options are combined with the MIN or MAX
	When the SAVE and PARTIAL result options are combined with the MIN or the	result option and the COUNT result option is
	MAX	absent, the corresponding PARTIAL result and MIN/MAX are returned (if the
	result option, and the COUNT result option is	SEARCH result
	absent, the corresponding PARTIAL result and MIN/MAX is returned (if the s	is not empty), and the "$" marker would contain references to all
	earch result
	is not empty), and the "$" marker would contain <!--references to-->all
	messages returned by the PARTIAL result option together with the correspon ding MIN/MAX message.	messages returned by the PARTIAL result option together with the correspon ding MIN/MAX message.

	</t>	</t>
		<t>
	<t>	If the SAVE and PARTIAL result options are combined with both the MIN and
	If the SAVE and PARTIAL result options are combined with both MIN and MAX	MAX result
	result	options and the COUNT result option is absent,
	options, and the COUNT result options is absent,	the PARTIAL, MIN, and MAX result options are returned (if the SEARCH resul
	the PARTIAL, MIN and MAX are returned (if the search result is not empty),	t is not empty),
	and the "$" marker would contain <!--references to-->all	and the "$" marker would contain references to all
	messages returned by the PARTIAL result option together with the MIN and t	messages returned by the PARTIAL result option together with the MIN and M
	he MAX messages.	AX messages.
	</t>	</t>
		<t>
	<t>
	If the SAVE and PARTIAL result options are combined with the COUNT	If the SAVE and PARTIAL result options are combined with the COUNT

	result option, the PARTIAL and COUNT are returned,	result option, the PARTIAL and COUNT result options are returned,
	and the "$" marker would always contain all messages	and the "$" marker would always contain references to all messages
	found by the SEARCH or UID SEARCH command.	found by the SEARCH or UID SEARCH command.

	</t>	</t>
		<t keepWithNext="true">
	<texttable>	<xref target="tab1"/> summarizes additional requirements for ESEARCH
	<preamble>
	The following table summarizes the additional requirement on ESEARCH
	server implementations described in this section.	server implementations described in this section.

	</preamble>	</t>
		<t>
	<ttcol align='center'>Combination of Result option</ttcol>	Note regarding <xref target="tab1"/>: "[m]" means optional "MIN" and/o
	<ttcol align='center'>"$" marker value</ttcol>	r "MAX".
		</t>
	<c>SAVE PARTIAL</c>
	<c>PARTIAL</c>

	<c>SAVE PARTIAL MIN</c>
	<c>PARTIAL & MIN</c>

	<c>SAVE PARTIAL MAX</c>
	<c>PARTIAL & MAX</c>

	<c>SAVE PARTIAL MIN MAX</c>
	<c>PARTIAL & MIN & MAX</c>

	<c>SAVE PARTIAL COUNT [m]</c>
	<c>all found messages</c>

	<postamble>
	Note for the table: '[m]' means optional "MIN" and/or "MAX"
	</postamble>

	</texttable>

	</section>

	<section title="Extension to UID FETCH">


	<t>The PARTIAL extension also extends the UID FETCH command with a PARTIAL	<table anchor="tab1" align="center">
	FETCH modifier.	<thead>
		<tr>
		<th align="center">Combination of Result Options</th>
		<th align="center">"$" Marker Value</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">SAVE PARTIAL</td>
		<td align="center">PARTIAL</td>
		</tr>
		<tr>
		<td align="center">SAVE PARTIAL MIN</td>
		<td align="center">PARTIAL & MIN</td>
		</tr>
		<tr>
		<td align="center">SAVE PARTIAL MAX</td>
		<td align="center">PARTIAL & MAX</td>
		</tr>
		<tr>
		<td align="center">SAVE PARTIAL MIN MAX</td>
		<td align="center">PARTIAL & MIN & MAX</td>
		</tr>
		<tr>
		<td align="center">SAVE PARTIAL COUNT [m]</td>
		<td align="center">all found messages</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section numbered="true" toc="default">
		<name>Extension to UID FETCH</name>
		<t>The PARTIAL extension also extends the UID FETCH command with a PARTI
		AL FETCH modifier.
	The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH resul t option.	The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH resul t option.

	Presence of the PARTIAL FETCH modifier instructs the server to only return	The presence of the PARTIAL FETCH modifier instructs the server to only re
	FETCH results	turn FETCH results
	for messages in the specified range. It is useful when the sequence-set (f	for messages in the specified range. It is useful when the sequence-set (f
	irst) parameter to	irst) parameter in
	the UID FETCH command includes unknown number of messages.</t>	the UID FETCH command includes an unknown number of messages.</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	// 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

	]]></artwork></figure>	]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	// 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

	]]></artwork></figure>	]]></artwork>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Use of "PARTIAL" and "CONDSTORE" IMAP Extensio
	<section title="Use of PARTIAL and CONDSTORE IMAP extensions together">	ns Together</name>
		<t>This section is informative.</t>
	<t>This section is informative.</t>	<t>The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE FETC
		H modifier <xref target="RFC7162"/>.</t>
	<t>The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE	<artwork name="" type="" align="left" alt=""><![CDATA[
	FETCH modifier.</t>

	<figure><artwork><![CDATA[
	// 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 flags/keywords 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
	S: * 12888 FETCH (FLAGS (\Flagged \Answered) MODSEQ (98306) UID 25997)	) (PARTIAL -1:-30 CHANGEDSINCE 98305)
		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

	]]></artwork></figure>	]]></artwork>


	<t>The above example causes the server to first select the last 30 m	<t>The above example causes the server to first select the last 30 messa
	essages	ges
	and then only return flag changes for subset of these messages which	and then only return flag changes for a subset of those messages tha
		t
	have MODSEQ higher than 98305.</t>	have MODSEQ higher than 98305.</t>

		<t>Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in th
	<t>Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers i	e UID FETCH command
	n the UID FETCH command	is not important, i.e., the above example can also use the
	is not important, i.e. the above example can also use
	"UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-3 0)"	"UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-3 0)"
	command and it would result in the same responses.</t>	command and it would result in the same responses.</t>

		</section>
	</section>

	</section>	</section>

		<section numbered="true" toc="default">
		<name>Formal Syntax</name>
		<t>The following syntax specification uses the Augmented Backus-Naur Form
		(ABNF) notation as specified in <xref target="RFC5234" format="default"/>.</t>
		<t>Non-terminals referenced but not defined below are as defined by <xref
		target="RFC3501" format="default">IMAP4rev1</xref> or <xref target="RFC9051" for
		mat="default">IMAP4rev2</xref>.</t>
		<t>Except as noted otherwise, all alphabetic characters are case insensiti
		ve.
		The use of uppercase or lowercase characters to define token strings is fo
		r editorial clarity only.
		Implementations <bcp14>MUST</bcp14> accept these strings in a case-insensi
		tive fashion.</t>


	<section title="Formal syntax">	<sourcecode type="abnf"><![CDATA[
	<t>The following syntax specification uses the Augmented
	Backus-Naur Form (ABNF) notation as specified in <xref target="ABNF"/>.</t>
	<t>Non-terminals referenced but not defined below are as
	defined by <xref target="RFC3501">IMAP4rev1</xref> or <xref target="RFC9051">IMA
	P4rev2</xref>.</t>
	<t>Except as noted otherwise, all alphabetic characters a
	re case-insensitive.
	The use of upper or lower case characters to define token strings is for e
	ditorial clarity only.
	Implementations MUST accept these strings in a case-insensitive fashion.</
	t>

	<figure><artwork>
	<![CDATA[
	SP = <Defined in RFC 5234>	SP = <Defined in RFC 5234>
	MINUS = "-"	MINUS = "-"

	capability =/ "PARTIAL"	capability =/ "PARTIAL"

	;; <capability> from [RFC3501]	;; <capability> from [RFC3501].

	modifier-partial = "PARTIAL" SP partial-range	modifier-partial = "PARTIAL" SP partial-range

	partial-range-first = nz-number ":" nz-number	partial-range-first = nz-number ":" nz-number
	;; Request to search from oldest (lowest UIDs) to	;; Request to search from oldest (lowest UIDs) to
	;; more recent messages.	;; more recent messages.
	;; A range 500:400 is the same as 400:500.	;; A range 500:400 is the same as 400:500.

	;; This is similar to <seq-range> from [RFC3501],	;; This is similar to <seq-range> from [RFC3501]
	;; but cannot contain "*".	;; but cannot contain "*".

	partial-range-last = MINUS nz-number ":" MINUS nz-number	partial-range-last = MINUS nz-number ":" MINUS nz-number
	;; Request to search from newest (highest UIDs) to	;; Request to search from newest (highest UIDs) to
	;; oldest messages.	;; oldest messages.
	;; A range -500:-400 is the same as -400:-500.	;; A range -500:-400 is the same as -400:-500.

	partial-range = partial-range-first / partial-range-last	partial-range = partial-range-first / partial-range-last

	search-return-opt =/ modifier-partial	search-return-opt =/ modifier-partial

	;; All conform to <search-return-opt>, from [IMAP-ABNF]/[RFC9051]	;; All conform to <search-return-opt> from
		;; [RFC4466] and [RFC9051].

	search-return-data =/ ret-data-partial	search-return-data =/ ret-data-partial

	ret-data-partial = "PARTIAL"	ret-data-partial = "PARTIAL"
	SP "(" partial-range SP partial-results ")"	SP "(" partial-range SP partial-results ")"
	;; <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 that 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

	]]></artwork></figure>	;; <fetch-modifier> from [RFC4466].
		]]></sourcecode>
	</section>

	<section title="Security Considerations">


		</section>
		<section numbered="true" toc="default">
		<name>Security Considerations</name>
	<t>	<t>
	This document defines an additional IMAP4 capability. As such, it	This document defines an additional IMAP4 capability. As such, it

	does not change the underlying security considerations of <xref target="RF	does not change the underlying security considerations of IMAP4rev1
	C3501"/> and IMAP4rev2 <xref target="RFC9051"/>.	<xref target="RFC3501" format="default"/> and IMAP4rev2 <xref target="RFC9051" f
		ormat="default"/>.
	The authors and reviewers believe that no new security issues are	The authors and reviewers believe that no new security issues are
	introduced with these additional IMAP4 capabilities.	introduced with these additional IMAP4 capabilities.
	</t>	</t>


	<t>	<t>

	This document defines an optimization that can both reduce the amount of w	This document defines an optimization that can reduce both the amount of w
	ork	ork
	performed by the server, as well at the amount of data returned to the cli	performed by the server and the amount of data returned to the client.
	ent.
	Use of this extension is likely to cause the server and the client to use less memory	Use of this extension is likely to cause the server and the client to use less memory
	than when the extension is not used. However, as this is going	than when the extension is not used. However, as this is going
	to be new code in both the client and the server, rigorous testing of such code	to be new code in both the client and the server, rigorous testing of such code

	is required in order to avoid introducing of new implementation bugs.	is required in order to avoid introducing new implementation bugs.
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="IANA Considerations">	<name>IANA Considerations</name>
		<section numbered="true" toc="default">
	<section title="Changes/additions to the IMAP4 capabilities registry">	<name>Changes/Additions to the IMAP Capabilities Registry</name>
		<t>
	<t>	IMAP4 capabilities are registered by publishing
	IMAP4 capabilities are registered by publishing a	a Standards Track or
	standards track or	IESG-approved Informational or Experimental RFC.
	IESG approved Informational or Experimental RFC.	The registry is currently located at
	The registry is currently located at:	<eref target="https://www.iana.org/assignments/imap-capabilities" brackets="a
	</t>	ngle"/>.
		</t>
	<figure><artwork><![CDATA[	<t>IANA has added the PARTIAL extension to the "IMAP Capabilities" regis
	https://www.iana.org/assignments/imap4-capabilities	try
	]]></artwork></figure>	with RFC 9394 as the reference.
		</t>
	<t>IANA is requested to add definition of the PARTIAL ext
	ension
	with RFC XXXX as the reference.
	</t>

	</section>	</section>


	</section>	</section>

		</middle>
		<back>


	<section title="Acknowledgments">	<displayreference target="RFC5234" to="ABNF"/>

	<t>This document was motivated by Yahoo! team and their questions
	about best client practices for dealing with large mailboxes.</t>

	<t>
	Editor of this document would like to thank the following
	people
	who provided useful comments or participated in discussio
	ns of
	this document: Timo Sirainen and Barry Leiba.
	</t>

	<t>This document uses lots of text from RFC 5267. Thus work of
	the RFC 5267 authors Dave Cridland and Curtis King is appreciated.
	</t>

	</section>

	</middle>
	<back>
	<references title="Normative References">
	&rfc2119;
	&rfc8174;
	&rfc3501;
	&rfc4731;
	&rfc5267;
	<reference anchor="ABNF">
	<front>
	<title>Augmented BNF for Syntax Specifica
	tions: ABNF</title>
	<author initials="D" surname="Crocker" fu
	llname="Dave Crocker" role="editor">
	<organization />
	</author>
	<author initials="P" surname="Overell" fu
	llname="Paul Overell" role="editor">
	<organization />
	</author>
	<date year="2008" month="January"/>
	</front>
	<seriesInfo name="RFC" value="5234" />
	<format type="TXT" target="https://www.rfc-editor
	.org/info/rfc5234" />
	</reference>


	&rfc9051;	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>


		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
		9.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
		4.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.350
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.446
		6.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.473
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.526
		7.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.523
		4.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905
		1.xml"/>
	</references>	</references>

		<references>
	<!--	<name>Informative References</name>
	<references title="Informative References">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.716
		2.xml"/>
	</references>	</references>

	-->	</references>


	</back>	<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>This document was motivated by the Yahoo! team and their questions
		about best client practices for dealing with large mailboxes.</t>
		<t>
		The authors of this document would like to thank the fol
		lowing people,
		who provided useful comments or participated in discussi
		ons of
		this document: <contact fullname="Timo Sirainen"/> and <contact fullname="
		Barry Leiba"/>.
		</t>

		<t>This document uses a lot of text from RFC 5267. Thus, the work of
		the RFC 5267 authors -- <contact fullname="Dave Cridland"/> and <contact f
		ullname="Curtis King"/> -- is appreciated.
		</t>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 73 change blocks.
	388 lines changed or deleted	342 lines changed or added
This html diff was produced by rfcdiff 1.48.