rfc9586.original   rfc9586.txt 
Network Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Request for Comments: 9586 Isode
Intended status: Experimental A. P. Achuthan Category: Experimental A. P. Achuthan
Expires: 6 October 2024 V. Nagulakonda ISSN: 2070-1721 V. Nagulakonda
A. Singh A. Singh
Yahoo! Yahoo!
L. Alves L. Alves
4 April 2024 May 2024
IMAP Extension for only using and returning UIDs IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only
draft-ietf-extra-imap-uidonly-08
Abstract Abstract
The UIDONLY extension to the Internet Message Access Protocol (RFC The UIDONLY extension to the Internet Message Access Protocol (RFCs
3501/RFC 9051) allows clients to enable a mode in which information 3501 and 9051) allows clients to enable a mode in which information
about mailbox changes is returned using only Unique Identifiers about mailbox changes is returned using only Unique Identifiers
(UIDs). Message numbers are not returned in responses, and can't be (UIDs). Message numbers are not returned in responses and cannot be
used in requests once this extension is enabled. This helps both used in requests once this extension is enabled. This helps both
clients and servers to reduce resource usage required to maintain a clients and servers to reduce resource usage required to maintain a
map between message numbers and UIDs. map between message numbers and UIDs.
This document defines an experimental IMAP extension. This document defines an experimental IMAP extension.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
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 defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 6 October 2024. 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/rfc9586.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 UIDONLY extension . . . . . . . . . . . . . . . . . . . . 3 3. The UIDONLY Extension
3.1. Enabling UIDONLY extension . . . . . . . . . . . . . . . 4 3.1. Enabling the UIDONLY Extension
3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE . . . . . . . . . 4 3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE
3.3. Changes to UID FETCH/UID STORE . . . . . . . . . . . . . 4 3.3. Changes to UID FETCH / UID STORE
3.4. Changes to EXPUNGE/UID EXPUNGE . . . . . . . . . . . . . 5 3.4. Changes to EXPUNGE / UID EXPUNGE
3.5. Changes to UID SEARCH . . . . . . . . . . . . . . . . . . 5 3.5. Changes to UID SEARCH
3.6. Changes to how other mailbox changes are announced . . . 5 3.6. Changes to How Other Mailbox Changes Are Announced
3.7. Interaction with CONDSTORE and QRESYNC extensions . . . . 6 3.7. Interaction with the CONDSTORE and QRESYNC Extensions
3.8. Interaction with other extensions . . . . . . . . . . . . 6 3.8. Interaction with Other Extensions
4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Formal Syntax
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations
7. Alternative solutions not taken . . . . . . . . . . . . . . . 7 7. Alternative Solutions Not Taken
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 eliminating use of message numbers. This Protocol [RFC3501] [RFC9051] for eliminating the use of message
extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 numbers. This extension is compatible with both IMAP4rev1 [RFC3501]
[RFC9051]. and IMAP4rev2 [RFC9051].
The UIDONLY extension of the Internet Message Access Protocol (RFC The UIDONLY extension of the Internet Message Access Protocol allows
3501/RFC 9051) allows clients to request that servers only use and clients to request that servers only use and return UIDs. This helps
return UIDs. This helps both clients and servers to reduce resource both clients and servers to reduce resource usage required to
usage required for maintenance of message number to UID map. maintain a map between message numbers and UIDs.
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
the server to the client. Lines prefixed with "// " are comments 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 names of IMAP commands or responses Other capitalized words are names of IMAP commands or responses
[RFC3501][RFC9051] or keywords from this document. [RFC3501] [RFC9051] or keywords from this document.
3. The UIDONLY extension 3. The UIDONLY Extension
An IMAP server advertises support for the UIDONLY extension by An IMAP server advertises support for the UIDONLY extension by
including the "UIDONLY" capability in the CAPABILITY response/ including the "UIDONLY" capability in the CAPABILITY response/
response code. response code.
Once the UIDONLY extension is enabled (see Section 3.1), the client Once the UIDONLY extension is enabled (see Section 3.1), the client
MUST NOT use message sequence numbers (including the special marker MUST NOT use message sequence numbers (including the special marker
"*") in any arguments to IMAP commands, and the server MUST return a "*") in any arguments to IMAP commands, and the server MUST return a
tagged BAD response if the client uses message sequence numbers. The tagged BAD response if the client uses message sequence numbers. The
server MUST include the UIDREQUIRED response code in such BAD server MUST include the UIDREQUIRED response code in such BAD
responses (see below). Additionally, once the UIDONLY extension is responses (see below). Additionally, once the UIDONLY extension is
enabled, the server MUST NOT return message sequence numbers in any enabled, the server MUST NOT return message sequence numbers in any
response. response.
The UIDREQUIRED response code is defined as follows: The UIDREQUIRED response code is defined as follows:
UIDREQUIRED Once UIDONLY extension is enabled the server returns the UIDREQUIRED: Once the UIDONLY extension is enabled, the server
UIDREQUIRED response code when the client issues a command that returns the UIDREQUIRED response code when the client issues a
includes message numbers instead of UIDs. command that includes message numbers instead of UIDs.
C: 07 FETCH 10000:14589 (UID FLAGS) C: 07 FETCH 10000:14589 (UID FLAGS)
S: 07 BAD [UIDREQUIRED] Message numbers are not allowed S: 07 BAD [UIDREQUIRED] Message numbers are not allowed
once UIDONLY is enabled once UIDONLY is enabled
The UIDONLY extension affects how information about new, expunged or The UIDONLY extension affects how information about new, expunged, or
changed messages is returned in unsolicited responses. In changed messages is returned in unsolicited responses. In
partucular, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID particular, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID
EXPUNGE, as well as how unsolicited mailbox changes are announced. EXPUNGE, as well as how unsolicited mailbox changes are announced.
The following subsections describe changes introduced by this The following subsections describe changes introduced by this
extension in more detail. extension in more detail.
3.1. Enabling UIDONLY extension 3.1. Enabling the UIDONLY Extension
As the UIDONLY extension affects how information about new, expunged As the UIDONLY extension affects how information about new, expunged,
or changed messages is returned in unsolicited responses, it has to or changed messages is returned in unsolicited responses, it has to
be enabled by the client first using the ENABLE command. be enabled by the client first using the ENABLE command.
S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY
AUTH=SCRAM-SHA-256] AUTH=SCRAM-SHA-256]
C: 01 ENABLE UIDONLY C: 01 ENABLE UIDONLY
S: * ENABLED UIDONLY S: * ENABLED UIDONLY
S: 01 OK ENABLE completed S: 01 OK ENABLE completed
3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE 3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE
When UIDONLY is enabled, FETCH, STORE, SEARCH, COPY and MOVE commands When UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY, and MOVE
are prohibited and MUST result in a tagged BAD response. Clients commands are prohibited and MUST result in a tagged BAD response.
should instead use UID FETCH, UID STORE, UID SEARCH, UID COPY or UID Clients should instead use UID FETCH, UID STORE, UID SEARCH, UID
MOVE respectively. COPY, or UID MOVE, respectively.
3.3. Changes to UID FETCH/UID STORE 3.3. Changes to UID FETCH / UID STORE
When UIDONLY is enabled, all FETCH responses that would be returned When UIDONLY is enabled, all FETCH responses that would be returned
by UID FETCH/UID STORE are replaced by UIDFETCH responses. by UID FETCH / UID STORE are replaced by UIDFETCH responses.
Note that UIDFETCH response contains the same response data items as Note that the UIDFETCH response contains the same response data items
specified for the FETCH response. The UID is always returned at the as specified for the FETCH response. The UID is always returned at
beginning of a UIDFETCH response, and it can also appear in the UID the beginning of a UIDFETCH response, and it can also appear in the
response data item, if requested by the client. While the UID UID response data item, if requested by the client. While the UID
response data item is redundant when requested, it can simplify response data item is redundant when requested, it can simplify the
updating of existing (non UIDONLY) implementations to support updating of existing (non-UIDONLY) implementations to support
UIDONLY. UIDONLY.
C: 10 UID FETCH 25900:26600 (FLAGS) C: 10 UID FETCH 25900:26600 (FLAGS)
[...] [...]
S: * 25996 UIDFETCH (FLAGS (\Seen)) S: * 25996 UIDFETCH (FLAGS (\Seen))
S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered)) S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered))
S: * 26600 UIDFETCH (FLAGS ()) S: * 26600 UIDFETCH (FLAGS ())
S: 10 OK FETCH completed S: 10 OK FETCH completed
C: 11 UID FETCH 25900:26600 (UID FLAGS) C: 11 UID FETCH 25900:26600 (UID FLAGS)
S: * 25900 UIDFETCH (FLAGS (\Seen) UID 25900) S: * 25900 UIDFETCH (FLAGS (\Seen) UID 25900)
S: * 25902 UIDFETCH (FLAGS (\Flagged) UID 25902) S: * 25902 UIDFETCH (FLAGS (\Flagged) UID 25902)
S: * 26310 UIDFETCH (FLAGS (\Answered) UID 26310) S: * 26310 UIDFETCH (FLAGS (\Answered) UID 26310)
S: * 26311 UIDFETCH (FLAGS () UID 26311) S: * 26311 UIDFETCH (FLAGS () UID 26311)
S: * 26498 UIDFETCH (FLAGS (\Answered) UID 26498) S: * 26498 UIDFETCH (FLAGS (\Answered) UID 26498)
[...] [...]
S: 11 OK FETCH completed S: 11 OK FETCH completed
3.4. Changes to EXPUNGE/UID EXPUNGE 3.4. Changes to EXPUNGE / UID EXPUNGE
When UIDONLY is enabled, all EXPUNGED responses that would be When UIDONLY is enabled, all EXPUNGED responses that would be
returned by EXPUNGE/UID EXPUNGE are replaced by VANISHED responses, returned by EXPUNGE / UID EXPUNGE are replaced by VANISHED responses,
as defined in [RFC7162]. Note that a server that implements UIDONLY as defined in [RFC7162]. Note that a server that implements the
extension is not required (but allowed) to also implement CONDSTORE UIDONLY extension is not required (but allowed) to also implement the
and/or QRESYNC extensions. CONDSTORE and/or QRESYNC extensions.
C: 12 EXPUNGE C: 12 EXPUNGE
S: * VANISHED 405,407,410,425 S: * VANISHED 405,407,410,425
S: 12 OK expunged S: 12 OK expunged
3.5. Changes to UID SEARCH 3.5. Changes to UID SEARCH
The "<sequence set>" UID SEARCH criterion is prohibited (and results The "<sequence set>" UID SEARCH criterion is prohibited (and results
in a tagged BAD response) once UIDONLY is enabled. Clients should in a tagged BAD response) once UIDONLY is enabled. Clients should
use ALL or "UID <sequence set>" UID SEARCH criterion instead. use ALL or "UID <sequence set>" UID SEARCH criterion instead.
3.6. Changes to how other mailbox changes are announced 3.6. Changes to How Other Mailbox Changes Are Announced
When UIDONLY is enabled, all changes to flags (and other dynamic When UIDONLY is enabled, all changes to flags (and other dynamic
message attributes) are returned using UIDFETCH responses, instead of message attributes) are returned using UIDFETCH responses instead of
FETCH responses. FETCH responses.
Similarly, all expunged messages are announced using VANISHED Similarly, all expunged messages are announced using VANISHED
responses instead of EXPUNGE responses. responses instead of EXPUNGE responses.
This extension doesn't affect EXISTS or RECENT responses. This extension doesn't affect EXISTS or RECENT responses.
UID MOVE/UID COPY commands SHOULD return the COPYUID response code, The UID MOVE / UID COPY commands SHOULD return the COPYUID response
as specified in [RFC4315]. code, as specified in [RFC4315].
Use of the UIDNOTSTICKY response code (see [RFC4315]) is not Use of the UIDNOTSTICKY response code (see [RFC4315]) is not
compatible with the UIDONLY extension, i.e. a server that advertises compatible with the UIDONLY extension, i.e., a server that advertises
the UIDONLY extension MUST NOT return UIDNOTSTICKY response code. the UIDONLY extension MUST NOT return a UIDNOTSTICKY response code.
C: 15 UID move 597 "Archives/2023/2023-05" C: 15 UID move 597 "Archives/2023/2023-05"
S: * OK [COPYUID 1685977201 597 2] UID MOVE S: * OK [COPYUID 1685977201 597 2] UID MOVE
S: * VANISHED 597 S: * VANISHED 597
S: 15 OK UID MOVE Completed S: 15 OK UID MOVE Completed
3.7. Interaction with CONDSTORE and QRESYNC extensions 3.7. Interaction with the CONDSTORE and QRESYNC Extensions
The CONDSTORE extension is compatible with the UIDONLY extension. The CONDSTORE extension is compatible with the UIDONLY extension.
The MODSEQ message data item is returned in UIDFETCH responses The MODSEQ message data item is returned in UIDFETCH responses
instead of FETCH responses. instead of FETCH responses.
The QRESYNC extension is compatible with the UIDONLY extension, but The QRESYNC extension is compatible with the UIDONLY extension, but
once UIDONLY is enabled, the fourth SELECT QRESYNC parameter once UIDONLY is enabled, the fourth SELECT QRESYNC parameter (see
("Message Sequence Match Data", see Section 3.2.5.2 of [RFC7162]) Section 3.2.5.2 ("Message Sequence Match Data") of [RFC7162]) MUST
MUST NOT be used. The server MUST return a tagged BAD response if NOT be used. The server MUST return a tagged BAD response if such a
such a parameter is observed once UIDONLY is enabled. parameter is observed once UIDONLY is enabled.
3.8. Interaction with other extensions 3.8. Interaction with Other Extensions
IMAP extensions might define other commands that accept message IMAP extensions might define other commands that accept message
sequence numbers ("sequence-set" ABNF non terminal, see Section 9 of sequence numbers ("sequence-set" ABNF non-terminal; see Section 9 of
[RFC9051]). Once UIDONLY is enabled, the server MUST reject such [RFC9051]). Once UIDONLY is enabled, the server MUST reject such
commands with tagged BAD response. For example, SORT and THREAD commands with a tagged BAD response. For example, the SORT and
[RFC5256] commands are prohibited, similarly to the SEARCH command. THREAD [RFC5256] commands are prohibited, similarly to the SEARCH
However UID SORT and UID THREAD can be used instead. command. However, UID SORT and UID THREAD can be used instead.
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 in
Section 9 of IMAP4 [RFC9051]. Section 9 of IMAP4 [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>
capability =/ "UIDONLY" capability =/ "UIDONLY"
;; <capability> from [RFC9051] ;; <capability>; see RFC 9051
message-data =/ uidfetch-resp message-data =/ uidfetch-resp
uidfetch-resp = uniqueid SP "UIDFETCH" SP msg-att uidfetch-resp = uniqueid SP "UIDFETCH" SP msg-att
;; The uniqueid is the UID of ;; The uniqueid is the UID of
;; the corresponding message ;; the corresponding message
message-data =/ expunged-resp message-data =/ expunged-resp
expunged-resp = <defines VANISHED response, see RFC 7162> expunged-resp = <defines VANISHED response; see RFC 7162>
resp-text-code =/ "UIDREQUIRED" resp-text-code =/ "UIDREQUIRED"
5. Security Considerations 5. Security Considerations
This IMAP extension is not believed to add any additional Security This IMAP extension is not believed to add any additional Security
Considerations beyond the ones that are generally applicable to Considerations beyond the ones that are generally applicable to
IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
6. IANA Considerations 6. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a Standards Track or
IESG approved Informational or Experimental RFC. The registry is IESG-approved Informational or Experimental RFC.
currently located at:
https://www.iana.org/assignments/imap4-capabilities
IANA is requested to add definition of the UIDONLY extension to this
registry with [RFCXXXX] as the reference.
IANA is also requested to add definition of the UIDREQUIRED response IANA has added the UIDONLY extension to the "IMAP Capabilities"
code to the "IMAP Response Codes" registry with [RFCXXXX] as the registry with RFC 9586 as the reference. The registry is located at
reference. The registry is currently located at: <https://www.iana.org/assignments/imap4-capabilities/>.
https://www.iana.org/assignments/imap-response-codes/imap-response-codes.xhtml IANA has also added the UIDREQUIRED response code to the "IMAP
Response Codes" registry with RFC 9586 as the reference. The
registry is located at <https://www.iana.org/assignments/imap-
response-codes/>.
7. Alternative solutions not taken 7. Alternative Solutions Not Taken
An earlier draft of this document proposed use of FETCH responses An earlier draft version of this document proposed use of FETCH
with the message number parameter always be set to 0. This was responses with the message number parameter always set to 0. This
judged to be too risky, as this could have caused unexpected side was considered to be too risky as it could cause unexpected side
effects and cache corruptions in client code that was not properly effects and cache corruptions in client code that was not properly
updated to handle lack of message numbers. updated to handle a lack of message numbers.
8. Acknowledgments
Editors of this document would like to thank the following people who
provided useful comments and/or participated in discussions that lead
to this document, in particular: Arnt Gulbrandsen, Ken Murchison,
Bron Gondwana, Barry Leiba and Elwyn Davis.
This document is similar to draft-gulbrandsen-imap-uidonly-00.txt,
but some different syntactic choices were made in the end.
9. Normative References 8. 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>.
skipping to change at page 9, line 5 skipping to change at line 364
[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. Informative References
[IMAP-UIDONLY-ORIG]
Gulbrandsen, A., "The IMAP UIDONLY Extension", Work in
Progress, Internet-Draft, draft-gulbrandsen-imap-uidonly-
00, 25 April 2014, <https://datatracker.ietf.org/doc/html/
draft-gulbrandsen-imap-uidonly-00>.
Acknowledgments
The editors of this document would like to thank the following people
who provided useful comments and/or participated in discussions that
lead to this document: Arnt Gulbrandsen, Ken Murchison, Bron
Gondwana, Barry Leiba, and Elwyn Davis.
This document is similar to [IMAP-UIDONLY-ORIG], but some different
syntactic choices were made in the end.
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 Inc. Yahoo Inc.
Email: arunprakash@myyahoo.com Email: arunprakash@myyahoo.com
 End of changes. 50 change blocks. 
139 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.48.