rfc9586xml2.original.xml   rfc9586.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R <!-- pre-edited by ST 04/08/24 -->
FC.2119.xml'>
<!ENTITY rfc3501 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.3501.xml'>
<!ENTITY rfc4315 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.4315.xml'>
<!ENTITY rfc5256 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.5256.xml'>
<!ENTITY rfc7162 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.7162.xml'>
<!ENTITY rfc8174 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml'>
<!ENTITY rfc9051 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.9051.xml'>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="exp" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap-uido
nly-08">
<?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 UIDONLY">
IMAP Extension for only using and returning UIDs
</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" category="exp" ipr="pre5378Trust
200902" docName="draft-ietf-extra-imap-uidonly-08" number="9586" obsoletes="" up
dates="" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="IMAP UIDONLY">IMAP Extension for Using and Returning Unique I
dentifiers (UIDs) Only</title>
<seriesInfo name="RFC" value="9586"/>
<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 Inc.</organization>
Yahoo Inc.
</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 Inc.</organization>
Yahoo Inc.
</organization>
<address> <address>
<email>nvikram_imap@yahoo.com</email> <email>nvikram_imap@yahoo.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Singh" fullname="Ashutosh Singh"> <author initials="A." surname="Singh" fullname="Ashutosh Singh">
<organization abbrev="Yahoo!"> <organization abbrev="Yahoo!">Yahoo Inc.</organization>
Yahoo Inc.
</organization>
<address> <address>
<email>ashutoshvsingh@yahoo.com</email> <email>ashutoshvsingh@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 month="May" year="2024"/>
<area>ART</area>
<workgroup>extra</workgroup>
<date year="2024"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
<abstract> the title) for use on https://www.rfc-editor.org/search. -->
<t>The UIDONLY extension to the Internet Message Access P <abstract>
rotocol (RFC 3501/RFC 9051) <t>The UIDONLY extension to the Internet Message Access Protocol (RFCs
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 (UIDs). about mailbox changes is returned using only Unique Identifiers (UIDs).
Message numbers are not returned in responses, Message numbers are not returned in responses and cannot be used in
and can't be used in requests once this extension is enabled. requests once this extension is enabled. This helps both clients and
This helps both clients and servers to reduce resource usage required to m servers to reduce resource usage required to maintain a map between
aintain a map between message numbers and UIDs. message numbers and UIDs.
<!--Bron's version:
This allows both clients and servers to avoid requiring resources to maint
ain a map between message numbers and UIDs.
-->
</t> </t>
<t> <t>
This document defines an experimental IMAP extension. This document defines an experimental IMAP extension.
</t> </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
col <xref target="RFC3501"/>
for eliminating use of message numbers.
This extension is compatible with both IMAP4rev1 <xref target="RFC3501"/>
and IMAP4rev2 <xref target="RFC9051"/>.</t>
<t>This document defines an extension to the Internet Message Access Proto col <xref target="RFC3501" format="default"/> <xref target="RFC9051" format="def ault"/> for eliminating the use of message numbers. This extension is compatible with both IMAP4rev1 <xref target="RFC3501" format="default"/> and IMAP4rev2 <xr ef target="RFC9051" format="default"/>.</t>
<t> <t>
The UIDONLY extension of the Internet Message Access Protocol (RFC 3501/RF The UIDONLY extension of the Internet Message Access Protocol allows clien
C 9051) ts to request that servers only use and return UIDs. This helps both clients and
allows clients to request that servers only use and return UIDs. servers to reduce resource usage required to maintain a map between message num
This helps both clients and servers to reduce resource usage required for bers and UIDs.
maintenance of message number to UID map.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Document Conventions</name>
<section title="Document Conventions"> <t>In protocol examples, this document uses a prefix of "C:" to denote lin
<t>In protocol examples, this document uses a prefix of " es sent by the client to the server and "S:" for lines sent by the server to the
C: " to denote lines sent by the client to the server, and client. Lines prefixed with "//" are comments explaining the previous protocol
"S: " for lines sent by the server to the client. Lines p line. These prefixes and comments are not part of the protocol. Lines without an
refixed with "// " are comments explaining the previous protocol line. y of these prefixes are continuations of the previous line, and no line break is
These prefixes and comments are not part of the protocol. present in the protocol unless specifically mentioned.</t>
Lines without any of these prefixes are continuations of the previous line, <t>
and no line break is present in the protocol unless speci The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>RE
fically mentioned.</t> QUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
<t> /bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and bed in BCP
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format
14 <xref target="RFC2119"/> <xref target="RFC8174"/> ="default"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t> <t>
Other capitalised words are names of IMAP commands or responses <xref targ et="RFC3501"/><xref target="RFC9051"/> Other capitalized words are names of IMAP commands or responses <xref targ et="RFC3501" format="default"/> <xref target="RFC9051" format="default"/>
or keywords from this document. or keywords from this document.
</t> </t>
</section>
</section> <section anchor="imap-uidonly" numbered="true" toc="default">
<name>The UIDONLY Extension</name>
<section title="The UIDONLY extension" anchor="imap-uidonly"> <t>An IMAP server advertises support for the UIDONLY extension
<t>An IMAP server advertises support for the UIDONLY extension
by including the "UIDONLY" capability in the CAPABILITY response/respons e code.</t> by including the "UIDONLY" capability in the CAPABILITY response/respons e code.</t>
<t>
<t> Once the UIDONLY extension is enabled (see <xref target="enabling" forma
Once the UIDONLY extension is enabled (see <xref target="enabling"/>), t="default"/>),
the client MUST NOT use message sequence numbers (including the special the client <bcp14>MUST NOT</bcp14> use message sequence numbers (includi
marker "*") ng the special marker "*")
in any arguments to IMAP commands, and the server MUST return a tagged B in any arguments to IMAP commands, and the server <bcp14>MUST</bcp14> re
AD response turn a tagged BAD response
if the client uses message sequence numbers. The server MUST include the if the client uses message sequence numbers. The server <bcp14>MUST</bcp
UIDREQUIRED response code in such BAD responses (see below). 14> include the UIDREQUIRED response code in such BAD responses (see below).
Additionally, once the UIDONLY extension is enabled, Additionally, once the UIDONLY extension is enabled,
the server MUST NOT return message sequence numbers in any response. the server <bcp14>MUST NOT</bcp14> return message sequence numbers in an
</t> y response.
</t>
<t>The UIDREQUIRED response code is defined as follows: <t>The UIDREQUIRED response code is defined as follows:
</t>
<list style='hanging'> <dl newline="false" spacing="normal">
<t hangText='UIDREQUIRED'> <dt>UIDREQUIRED:</dt><dd><t>Once the UIDONLY extension is enabled, the s
<!-- erver returns the UIDREQUIRED response code when the client issues a command tha
<iref item='UIDREQUIRED (response code)'/> t includes message numbers instead of UIDs.
--> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<list>
<t>
Once UIDONLY extension is enabled the server returns the UIDREQUIRED r
esponse code when the client issues a command
that includes message numbers instead of UIDs.
</t>
<t>
<figure><artwork><![CDATA[
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
]]></artwork></figure> ]]></artwork>
</t> </dd>
</dl>
</list> <t>The UIDONLY extension affects how information about new, expunged,
</t> or changed messages is returned in unsolicited responses.
</list> In particular,
</t>
<t>The UIDONLY extension affects how information about new, expunged
or changed messages is returned in unsolicited responses. In partucular,
it affects responses to UID FETCH/UID STORE/EXPUNGE/UID EXPUNGE, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID EXPUNGE,
as well as how unsolicited mailbox changes are announced. as well as how unsolicited mailbox changes are announced.
</t> </t>
<t>The following subsections describe changes introduced by this extension
<t>The following subsections describe changes introduced by this extensi
on
in more detail.</t> in more detail.</t>
<section anchor="enabling" numbered="true" toc="default">
<section title="Enabling UIDONLY extension" anchor="enabling"> <name>Enabling the UIDONLY Extension</name>
<t>
<t> 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 be or changed messages is returned in unsolicited responses, it has to be
enabled by the client first using the ENABLE command. enabled by the client first using the ENABLE command.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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
]]></artwork></figure> ]]></artwork>
</section>
</section> <section numbered="true" toc="default">
<name>Changes to FETCH/STORE/SEARCH/COPY/MOVE</name>
<section title="Changes to FETCH/STORE/SEARCH/COPY/MOVE"> <t>When UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY, and MOVE com
mands are prohibited
<t>When UIDONLY is enabled, FETCH, STORE, SEARCH, COPY and MOVE comman and <bcp14>MUST</bcp14> result in a tagged BAD response. Clients shoul
ds are prohibited d instead use UID FETCH,
and MUST result in a tagged BAD response. Clients should instead use U UID STORE, UID SEARCH, UID COPY, or UID MOVE, respectively.</t>
ID FETCH, </section>
UID STORE, UID SEARCH, UID COPY or UID MOVE respectively.</t> <section numbered="true" toc="default">
<name>Changes to UID FETCH / UID STORE</name>
</section> <t>When UIDONLY is enabled, all FETCH responses that would be returned b
y UID FETCH / UID STORE
<section title="Changes to UID FETCH/UID STORE">
<t>When UIDONLY is enabled, all FETCH responses that would be returned
by UID FETCH/UID STORE
are replaced by UIDFETCH responses.</t> are replaced by UIDFETCH responses.</t>
<t>Note that the UIDFETCH response contains the same response data items
<t>Note that UIDFETCH response contains the same response data items a as specified for the FETCH response.
s specified for the FETCH response.
The UID is always returned at the beginning of a UIDFETCH response, The UID is always returned at the beginning of a UIDFETCH response,
and it can also appear in the UID response data item, if requested by the client. and it can also appear in the UID response data item, if requested by the client.
While the UID response data item is redundant when requested, it can s While the UID response data item is redundant when requested, it can s
implify updating implify the updating
of existing (non UIDONLY) implementations to support UIDONLY.</t> of existing (non-UIDONLY) implementations to support UIDONLY.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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
]]></artwork></figure> ]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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
]]></artwork></figure> ]]></artwork>
</section>
</section> <section numbered="true" toc="default">
<name>Changes to EXPUNGE / UID EXPUNGE</name>
<section title="Changes to EXPUNGE/UID EXPUNGE"> <t>When UIDONLY is enabled, all EXPUNGED responses that would be returne
d by EXPUNGE / UID EXPUNGE
<t>When UIDONLY is enabled, all EXPUNGED responses that would be retur are replaced by VANISHED responses, as defined in <xref target="RFC716
ned by EXPUNGE/UID EXPUNGE 2" format="default"/>. Note that a server that implements the UIDONLY extension
are replaced by VANISHED responses, as defined in <xref target="RFC716 is not required (but allowed) to also implement the CONDSTORE and/or QRESYNC ext
2"/>. Note that a server ensions.</t>
that implements UIDONLY extension is not required (but allowed) to als <artwork name="" type="" align="left" alt=""><![CDATA[
o implement CONDSTORE and/or QRESYNC extensions.</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure> ]]></artwork>
</section>
</section> <section numbered="true" toc="default">
<name>Changes to UID SEARCH</name>
<section title="Changes to UID SEARCH"> <t>The "&lt;sequence set&gt;" UID SEARCH criterion is prohibited (and re
sults in a tagged BAD response) once UIDONLY is enabled.
<t>The "&lt;sequence set&gt;" UID SEARCH criterion is prohibited (and
results in a tagged BAD response) once UIDONLY is enabled.
Clients should use ALL or "UID &lt;sequence set&gt;" UID SEARCH criter ion instead.</t> Clients should use ALL or "UID &lt;sequence set&gt;" UID SEARCH criter ion instead.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Changes to How Other Mailbox Changes Are Announced</name>
<section title="Changes to how other mailbox changes are announced"> <t>When UIDONLY is enabled, all changes to flags (and other dynamic mess
age attributes)
<t>When UIDONLY is enabled, all changes to flags (and other dynamic me are returned using UIDFETCH responses instead of FETCH responses.</t>
ssage attributes) <t>Similarly, all expunged messages are announced using VANISHED respons
are returned using UIDFETCH responses, instead of FETCH responses.</t> es
<t>Similarly, all expunged messages are announced using VANISHED respo
nses
instead of EXPUNGE responses.</t> instead of EXPUNGE responses.</t>
<t>This extension doesn't affect EXISTS or RECENT responses.</t> <t>This extension doesn't affect EXISTS or RECENT responses.</t>
<t>The UID MOVE / UID COPY commands <bcp14>SHOULD</bcp14> return the COP
<t>UID MOVE/UID COPY commands SHOULD return the COPYUID response code, YUID response code, as specified in <xref target="RFC4315" format="default"/>.
as specified in <xref target="RFC4315"/>. </t>
</t> <t>Use of the UIDNOTSTICKY response code (see <xref target="RFC4315" for
mat="default"/>) is not compatible with the UIDONLY extension, i.e., a server th
<t>Use of the UIDNOTSTICKY response code (see <xref target="RFC4315"/> at advertises the UIDONLY extension <bcp14>MUST NOT</bcp14> return a UIDNOTSTICK
) is not compatible with the UIDONLY extension, Y response code.</t>
i.e. a server that advertises the UIDONLY extension MUST NOT return UI <artwork name="" type="" align="left" alt=""><![CDATA[
DNOTSTICKY response code.</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure> ]]></artwork>
</section>
</section> <section numbered="true" toc="default">
<name>Interaction with the CONDSTORE and QRESYNC Extensions</name>
<section title="Interaction with CONDSTORE and QRESYNC extensions"> <t>
<t>
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 instead of FETCH responses. The MODSEQ message data item is returned in UIDFETCH responses instead of FETCH responses.
</t> </t>
<t>
<t>
The QRESYNC extension is compatible with the UIDONLY extension, but on ce UIDONLY is enabled, The QRESYNC extension is compatible with the UIDONLY extension, but on ce UIDONLY is enabled,
the fourth SELECT QRESYNC parameter ("Message Sequence Match Data", se the fourth SELECT QRESYNC parameter (see Section <xref target="RFC7162
e Section 3.2.5.2 of <xref target="RFC7162"/>) " section="3.2.5.2"
MUST NOT be used. The server MUST return a tagged BAD response if such sectionFormat="bare">"Message Sequence Match Data"</xref> of <xref target="RFC71
a parameter is observed once UIDONLY is enabled. 62"/>)
</t> <bcp14>MUST NOT</bcp14> be used. The server <bcp14>MUST</bcp14> return
a tagged BAD response if such a parameter is observed once UIDONLY is enabled.
</section> </t>
</section>
<section title="Interaction with other extensions"> <section numbered="true" toc="default">
<name>Interaction with Other Extensions</name>
<t>IMAP extensions might define other commands that accept message seq <t>IMAP extensions might define other commands that accept message seque
uence numbers ("sequence-set" ABNF non terminal, see Section 9 of <xref target=" nce numbers ("sequence-set" ABNF non-terminal; see <xref target="RFC9051" sectio
RFC9051"/>). nFormat="of" section="9"/>).
Once UIDONLY is enabled, the server MUST reject such commands with tag Once UIDONLY is enabled, the server <bcp14>MUST</bcp14> reject such co
ged BAD response. mmands with a tagged BAD response. For example, the SORT and THREAD <xref target
="RFC5256" format="default"/> commands are prohibited, similarly to the SEARCH c
For example, SORT and THREAD <xref target="RFC5256"/> commands are pro ommand. However, UID SORT and UID THREAD can be used instead.
hibited, similarly to the SEARCH command. </t>
However UID SORT and UID THREAD can be used instead. </section>
</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Formal syntax"> <name>Formal Syntax</name>
<t>The following syntax specification uses the Augmented <t>The following syntax specification uses the Augmented Backus-Naur Form
Backus-Naur Form (ABNF) notation as specified in <xref target="ABNF"/>.</t> (ABNF) notation as specified in <xref target="RFC5234" format="default"/>.</t>
<t>Non-terminals referenced but not defined below are as <t>Non-terminals referenced but not defined below are as defined in <xref
defined by Section 9 of <xref target="RFC9051">IMAP4</xref>.</t> target="RFC9051" sectionFormat="of" section="9">IMAP4</xref>.</t>
<t>Except as noted otherwise, all alphabetic characters a <t>Except as noted otherwise, all alphabetic characters are case insensiti
re case-insensitive. ve.
The use of upper or lower case characters to define token strings is for e The use of uppercase or lowercase characters to define token strings is fo
ditorial clarity only. r editorial clarity only.
Implementations MUST accept these strings in a case-insensitive fashion.</ Implementations <bcp14>MUST</bcp14> accept these strings in a case-insensi
t> tive fashion.</t>
<sourcecode type="abnf"><![CDATA[
<figure><artwork>
<![CDATA[
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"
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations"> <t>
<t>
This IMAP extension is not believed to add any additional Security Conside rations This IMAP extension is not believed to add any additional Security Conside rations
beyond the ones that are generally applicable to IMAP4rev1 <xref target="R beyond the ones that are generally applicable to IMAP4rev1 <xref target="R
FC3501"/> FC3501" format="default"/>
and IMAP4rev2 <xref target="RFC9051"/>. and IMAP4rev2 <xref target="RFC9051" format="default"/>.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations"> <t>IMAP4 capabilities are registered by publishing a Standards Track or IE
SG-approved Informational or Experimental RFC.
<t> </t>
IMAP4 capabilities are registered by publishing a <t>IANA has added the UIDONLY extension to
standards track or the "IMAP Capabilities" registry with RFC 9586 as the reference. The regis
IESG approved Informational or Experimental RFC. try is located at <eref target="https://www.iana.org/assignments/imap4-capabilit
The registry is currently located at: ies/" brackets="angle"/>.
</t> </t>
<t>IANA has also added the UIDREQUIRED response code
<figure><artwork><![CDATA[ to the "IMAP Response Codes" registry with RFC 9586 as the reference.
https://www.iana.org/assignments/imap4-capabilities The registry is located at <eref target="https://www.iana.org/assignments/
]]></artwork></figure> imap-response-codes/" brackets="angle"/>.
<t>IANA is requested to add definition of the UIDONLY ext
ension to
this registry with [RFCXXXX] as the reference.
</t> </t>
<t>IANA is also requested to add definition of the UIDREQ
UIRED response code
to the "IMAP Response Codes" registry with [RFCXXXX] as the reference.
The registry is currently located at:
</t>
<figure><artwork><![CDATA[
https://www.iana.org/assignments/imap-response-codes/imap-response-codes.xhtm
l
]]></artwork></figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Alternative solutions not taken"> <name>Alternative Solutions Not Taken</name>
<t> <t>
An earlier draft of this document proposed use of FETCH responses with An earlier draft version of this document proposed use of FETCH responses
the message number parameter always be set to 0. with
This was judged to be too risky, as this could have caused unexpected the message number parameter always set to 0.
This was considered to be too risky as it could cause unexpected
side effects and cache corruptions in client code that was not properly up dated side effects and cache corruptions in client code that was not properly up dated
to handle lack of message numbers. to handle a lack of message numbers.
</t> </t>
</section> </section>
</middle>
<back>
<displayreference target="RFC5234" to="ABNF"/>
<displayreference target="I-D.gulbrandsen-imap-uidonly" to="IMAP-UIDONLY-ORI
G"/>
<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.523
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.431
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.525
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.716
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905
1.xml"/>
</references>
<section title="Acknowledgments"> <references>
<name>Informative References</name>
<!--draft-gulbrandsen-imap-uidonly; IESG State: Expired-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.dra
ft-gulbrandsen-imap-uidonly.xml"/>
</references>
<section numbered="false">
<name>Acknowledgments</name>
<t> <t>
Editors of this document would like to thank the following people The editors of this document would like to thank the following people
who provided useful comments and/or participated in discussions that who provided useful comments and/or participated in discussions that
lead to this document, in particular: Arnt Gulbrandsen, Ken Murchison, lead to this document: <contact fullname="Arnt Gulbrandsen"/>, <contact fu
Bron Gondwana, Barry Leiba and Elwyn Davis. llname="Ken Murchison"/>, <contact fullname="Bron Gondwana"/>, <contact fullname
="Barry Leiba"/>, and <contact fullname="Elwyn Davis"/>.
</t> </t>
<t> <t>
This document is similar to draft-gulbrandsen-imap-uidonly-00.txt,
but some different syntactic choices were made in the end.
</t>
</section> <!--[rfced] FYI: "draft-gulbrandsen-imap-uidonly-00" did not have a
reference entry, so we created one under "Informative References"
as shown below.
</middle> Original:
<back> This document is similar to draft-gulbrandsen-imap-uidonly-00.txt,
<references title="Normative References"> but some different syntactic choices were made in the end.
&rfc2119;
&rfc8174;
&rfc3501;
<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>
&rfc4315; Current:
&rfc5256; This document is similar to [IMAP-UIDONLY], but some
&rfc7162; different syntactic choices were made in the end.
&rfc9051;
</references> Informative Reference Entry:
[IMAP-UIDONLY]
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>.
-->
This document is similar to <xref target="I-D.gulbrandsen-imap-uidonly"/>,
but some different syntactic choices were made in the end.
</t>
</section>
<!-- </back>
<references title="Informative References">
</references> <!-- [rfced] Please review the "Inclusive Language" portion of the online
--> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
-&gt;
</back>
</rfc> </rfc>
 End of changes. 65 change blocks. 
379 lines changed or deleted 295 lines changed or added

This html diff was produced by rfcdiff 1.48.