rfc9394.original   rfc9394.txt 
Network Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Request for Comments: 9394 Isode
Updates: 5267, 4731 (if approved) A. P. Achuthan Updates: 4731, 5267 A. P. Achuthan
Intended status: Standards Track V. Nagulakonda Category: Standards Track V. Nagulakonda
Expires: 24 June 2023 Yahoo! ISSN: 2070-1721 Yahoo!
L. Alves L. Alves
21 December 2022 June 2023
IMAP Paged SEARCH & FETCH Extension IMAP PARTIAL Extension for Paged SEARCH and FETCH
draft-ietf-extra-imap-partial-04
Abstract Abstract
The PARTIAL extension of the Internet Message Access Protocol (RFC The PARTIAL extension of the Internet Message Access Protocol (see
3501/RFC 9051) allows clients to limit the number of search results RFCs 3501 and 9051) allows clients to limit the number of SEARCH
returned, as well as to perform incremental (paged) searches. This results returned, as well as to perform incremental (paged) searches.
also helps servers to optimize resource usage when performing This also helps servers to optimize resource usage when performing
searches. searches.
This document extends PARTIAL SEARCH return option originally This document extends the 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 RFCs 4731 and 9051.
Status of This Memo This document updates RFCs 4731 and 5267.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9394.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are 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
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
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions
3. The PARTIAL extension . . . . . . . . . . . . . . . . . . . . 3 3. The PARTIAL Extension
3.1. Incremental SEARCH and partial results . . . . . . . . . 3 3.1. Incremental SEARCH and Partial Results
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
3.3. Extension to UID FETCH . . . . . . . . . . . . . . . . . 6 3.3. Extension to UID FETCH
3.4. Use of PARTIAL and CONDSTORE IMAP extensions together . . 7 3.4. Use of "PARTIAL" and "CONDSTORE" IMAP Extensions Together
4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Formal Syntax
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations
6.1. Changes/additions to the IMAP4 capabilities registry . . 9 6.1. Changes/Additions to the IMAP Capabilities Registry
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References
8. Normative References . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References
Acknowledgments
Authors' Addresses
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] [RFC9051] for performing incremental searches and
This extension is compatible with both IMAP4rev1 [RFC3501] and fetches. This extension is compatible with both IMAP4rev1 [RFC3501]
IMAP4rev2 [RFC9051]. and IMAP4rev2 [RFC9051]. This extension uses IMAP extensibility
rules defined in [RFC4466].
The PARTIAL extension of the Internet Message Access Protocol (RFC The PARTIAL extension of the Internet Message Access Protocol allows
3501/RFC 9051) allows clients to limit the number of search results clients to limit the number of SEARCH results returned, as well as to
returned, as well as to perform incremental (paged) searches. This perform incremental (paged) searches. This also helps servers to
also helps servers to optimize resource usage when performing optimize resource usage when performing searches.
searches.
This document extends PARTIAL SEARCH return option originally This document extends the 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 RFCs 4731 and 9051.
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 breaks are
in the protocol unless specifically mentioned. present 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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 capitalized words are IMAP key words [RFC3501] [RFC9051] or key
keywords from this document. words 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 the "PARTIAL" capability in the CAPABILITY response/ including the "PARTIAL" capability in the CAPABILITY response /
response code. response code.
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 [RFC4731][RFC9051] response a subset of the results denoted ESEARCH response [RFC4731] [RFC9051] a subset of the results denoted
by the sequence range given as the mandatory argument. The first by the sequence range given as the mandatory argument. The first
result (message with the lowest matching UID) is 1; thus, the first result (message with the lowest matching Unique Identifier (UID)) is
500 results would be obtained by a return option of "PARTIAL 1:500", 1; thus, the first 500 results would be obtained by a return option
and the second 500 by "PARTIAL 501:1000". This intentionally mirrors of "PARTIAL 1:500" and the second 500 by "PARTIAL 501:1000". This
message sequence numbers. intentionally mirrors message sequence numbers.
It is also possible to direct the server to start SEARCH from the It is also possible to direct the server to start the SEARCH from the
latest matching (with the highest UID) message. This can be done by latest matching (with the highest UID) message. This can be done by
prepending "-" to the index. For example -1 is the last message, -2 prepending "-" to the index. For example, -1 is the last message, -2
is next to the last and so on. Using this syntax helps server is next to the last, and so on. Using this syntax helps server
implementations to optimize their SEARCHes. implementations to optimize their SEARCHes.
A single command MUST NOT contain more than one PARTIAL or ALL search A single command MUST NOT contain more than one PARTIAL or 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.
For SEARCH results, the entire result list MUST be ordered in mailbox For SEARCH results, the entire list of results MUST be ordered in
order, that is, in UID or message sequence number order. mailbox order -- that is, in UID or message sequence number order.
Where a PARTIAL SEARCH return option references results that do not In cases where a PARTIAL SEARCH return option references results that
exist, by using a range which starts or ends higher (or lower) than do not exist by using a range that starts or ends higher (or lower)
the current number of results, then the server returns the results than the current number of results, the server returns the results
that are in the set. This yields a PARTIAL return data item that that are in the set. This yields a PARTIAL return data item that
has, as payload, the original range and a potentially missing set of has, as payload, the original range and a potentially missing set of
results that may be shorter than the extent of the range. If the results that may be shorter than the extent of the range. If the
whole range references results that do not exist, a special value whole range references results that do not exist, a special value
"NIL" is returned by the server instead of the sequence set. "NIL" is returned by the server instead of the sequence set.
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 in Because mailboxes may change, clients might wish to use PARTIAL in
combination with UPDATE (see [RFC5267]) if the server also advertises combination with UPDATE (see [RFC5267]) if the server also advertises
CONTEXT=SEARCH capability, especially if the intent is to walk a the "CONTEXT=SEARCH" capability, especially if the intent is to walk
large set of results; however, these return options do not interact a 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.
// 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.
// 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.
3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return 3.2. Interaction between PARTIAL, MIN, MAX, and SAVE SEARCH Return
options Options
This section only applies if the server advertises PARTIAL IMAP This section only applies if the server advertises the "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.1, it is an error to specify both PARTIAL As specified in Section 3.1, it is an error to specify both the
and ALL result options in the same SEARCH command. PARTIAL 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 the MIN/MAX/COUNT result options are 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. references to all messages returned by the PARTIAL result option.
When the SAVE and PARTIAL result options are combined with the MIN or When the SAVE and PARTIAL result options are combined with the MIN or
the MAX result option, and the COUNT result option is absent, 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 are returned (if the SEARCH
result is not empty), and the "$" marker would contain all messages result is not empty), and the "$" marker would contain references to
returned by the PARTIAL result option together with the corresponding all messages returned by the PARTIAL result option together with the
MIN/MAX message. corresponding MIN/MAX message.
If the SAVE and PARTIAL result options are combined with both MIN and If the SAVE and PARTIAL result options are combined with both the MIN
MAX result options, and the COUNT result options is absent, the and MAX result options and the COUNT result option is absent, the
PARTIAL, MIN and MAX are returned (if the search result is not PARTIAL, MIN, and MAX result options are returned (if the SEARCH
empty), and the "$" marker would contain all messages returned by the result is not empty), and the "$" marker would contain references to
PARTIAL result option together with the MIN and the MAX messages. all messages returned by the PARTIAL result option together with the
MIN and MAX messages.
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, and the "$" marker result option, the PARTIAL and COUNT result options are returned, and
would always contain all messages found by the SEARCH or UID SEARCH the "$" marker would always contain references to all messages found
command. by the SEARCH or UID SEARCH command.
The following table summarizes the additional requirement on ESEARCH Table 1 summarizes additional requirements for ESEARCH server
server implementations described in this section. implementations described in this section.
+==============================+=====================+ Note regarding Table 1: "[m]" means optional "MIN" and/or "MAX".
| Combination of Result option | "$" marker value |
+==============================+=====================+
| SAVE PARTIAL | PARTIAL |
+------------------------------+---------------------+
| SAVE PARTIAL MIN | PARTIAL & MIN |
+------------------------------+---------------------+
| SAVE PARTIAL MAX | PARTIAL & MAX |
+------------------------------+---------------------+
| SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX |
+------------------------------+---------------------+
| SAVE PARTIAL COUNT [m] | all found messages |
+------------------------------+---------------------+
Table 1 +===============================+=====================+
| Combination of Result Options | "$" Marker Value |
+===============================+=====================+
| SAVE PARTIAL | PARTIAL |
+-------------------------------+---------------------+
| SAVE PARTIAL MIN | PARTIAL & MIN |
+-------------------------------+---------------------+
| SAVE PARTIAL MAX | PARTIAL & MAX |
+-------------------------------+---------------------+
| SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX |
+-------------------------------+---------------------+
| SAVE PARTIAL COUNT [m] | all found messages |
+-------------------------------+---------------------+
Note for the table: '[m]' means optional "MIN" and/or "MAX" Table 1
3.3. Extension to UID FETCH 3.3. Extension to UID FETCH
The PARTIAL extension also extends the UID FETCH command with a The PARTIAL extension also extends the UID FETCH command with a
PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same
syntax as the PARTIAL SEARCH result option. Presence of the PARTIAL syntax as the PARTIAL SEARCH result option. The presence of the
FETCH modifier instructs the server to only return FETCH results for PARTIAL FETCH modifier instructs the server to only return FETCH
messages in the specified range. It is useful when the sequence-set results for messages in the specified range. It is useful when the
(first) parameter to the UID FETCH command includes unknown number of sequence-set (first) parameter in the UID FETCH command includes an
messages. unknown number of 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
3.4. Use of PARTIAL and CONDSTORE IMAP extensions together 3.4. Use of "PARTIAL" and "CONDSTORE" IMAP Extensions Together
This section is informative. This section is informative.
The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE
FETCH modifier. FETCH modifier [RFC7162].
// 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: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600) S: * 12888 FETCH (FLAGS (\Flagged \Answered
S: 101 OK FETCH completed ) MODSEQ (98306) UID 25997)
S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600)
S: 101 OK FETCH completed
The above example causes the server to first select the last 30 The above example causes the server to first select the last 30
messages and then only return flag changes for subset of these messages and then only return flag changes for a subset of those
messages which have MODSEQ higher than 98305. messages that have MODSEQ higher than 98305.
Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in
the UID FETCH command is not important, i.e. the above example can the UID FETCH command is not important, i.e., the above example can
also use "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 also use the "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305
PARTIAL -1:-30)" command and it would result in the same responses. PARTIAL -1:-30)" command and it would result in the same responses.
4. Formal syntax 4. 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
IMAP4rev1 [RFC3501] or IMAP4rev2 [RFC9051]. IMAP4rev1 [RFC3501] or IMAP4rev2 [RFC9051].
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 uppercase or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
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
;; <fetch-modifier> from [RFC4466].
5. Security Considerations 5. Security Considerations
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 [RFC3501] does not change the underlying security considerations of IMAP4rev1
and IMAP4rev2 [RFC9051]. The authors and reviewers believe that no [RFC3501] and IMAP4rev2 [RFC9051]. The authors and reviewers believe
new security issues are introduced with these additional IMAP4 that no new security issues are introduced with these additional
capabilities. IMAP4 capabilities.
This document defines an optimization that can both reduce the amount This document defines an optimization that can reduce both the amount
of work performed by the server, as well at the amount of data of work performed by the server and the amount of data returned to
returned to the client. Use of this extension is likely to cause the the client. Use of this extension is likely to cause the server and
server and the client to use less memory than when the extension is the client to use less memory than when the extension is not used.
not used. However, as this is going to be new code in both the However, as this is going to be new code in both the client and the
client and the server, rigorous testing of such code is required in server, rigorous testing of such code is required in order to avoid
order to avoid introducing of new implementation bugs. introducing new implementation bugs.
6. IANA Considerations 6. IANA Considerations
6.1. Changes/additions to the IMAP4 capabilities registry 6.1. Changes/Additions to the IMAP Capabilities Registry
IMAP4 capabilities are registered by publishing a standards track or
IESG approved Informational or Experimental RFC. The registry is
currently located at:
https://www.iana.org/assignments/imap4-capabilities
IANA is requested to add definition of the PARTIAL extension with RFC
XXXX as the reference.
7. Acknowledgments
This document was motivated by Yahoo! team and their questions about IMAP4 capabilities are registered by publishing a Standards Track or
best client practices for dealing with large mailboxes. IESG-approved Informational or Experimental RFC. The registry is
currently located at <https://www.iana.org/assignments/imap-
capabilities>.
Editor of this document would like to thank the following people who IANA has added the PARTIAL extension to the "IMAP Capabilities"
provided useful comments or participated in discussions of this registry with RFC 9394 as the reference.
document: Timo Sirainen and Barry Leiba.
This document uses lots of text from RFC 5267. Thus work of the RFC 7. References
5267 authors Dave Cridland and Curtis King is appreciated.
8. Normative References 7.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, 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>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
<https://www.rfc-editor.org/info/rfc4466>.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH [RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is Command for Controlling What Kind of Information Is
Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006, Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006,
<https://www.rfc-editor.org/info/rfc4731>. <https://www.rfc-editor.org/info/rfc4731>.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
DOI 10.17487/RFC5267, July 2008, DOI 10.17487/RFC5267, July 2008,
<https://www.rfc-editor.org/info/rfc5267>. <https://www.rfc-editor.org/info/rfc5267>.
[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>.
7.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>.
Acknowledgments
This document was motivated by the Yahoo! team and their questions
about best client practices for dealing with large mailboxes.
The authors of this document would like to thank the following
people, who provided useful comments or participated in discussions
of this document: Timo Sirainen and Barry Leiba.
This document uses a lot of text from RFC 5267. Thus, the work of
the RFC 5267 authors -- Dave Cridland and Curtis King -- is
appreciated.
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
 End of changes. 75 change blocks. 
186 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.48.