1
2
3
4
5Internet Engineering Task Force (IETF) A. Melnikov
6Request for Comments: 9586 Isode
7Category: Experimental A. P. Achuthan
8ISSN: 2070-1721 V. Nagulakonda
9 A. Singh
10 Yahoo!
11 L. Alves
12 May 2024
13
14
15 IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only
16
17Abstract
18
19 The UIDONLY extension to the Internet Message Access Protocol (RFCs
20 3501 and 9051) allows clients to enable a mode in which information
21 about mailbox changes is returned using only Unique Identifiers
22 (UIDs). Message numbers are not returned in responses and cannot be
23 used in requests once this extension is enabled. This helps both
24 clients and servers to reduce resource usage required to maintain a
25 map between message numbers and UIDs.
26
27 This document defines an experimental IMAP extension.
28
29Status of This Memo
30
31 This document is not an Internet Standards Track specification; it is
32 published for examination, experimental implementation, and
33 evaluation.
34
35 This document defines an Experimental Protocol for the Internet
36 community. This document is a product of the Internet Engineering
37 Task Force (IETF). It represents the consensus of the IETF
38 community. It has received public review and has been approved for
39 publication by the Internet Engineering Steering Group (IESG). Not
40 all documents approved by the IESG are candidates for any level of
41 Internet Standard; see Section 2 of RFC 7841.
42
43 Information about the current status of this document, any errata,
44 and how to provide feedback on it may be obtained at
45 https://www.rfc-editor.org/info/rfc9586.
46
47Copyright Notice
48
49 Copyright (c) 2024 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
51
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (https://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Revised BSD License text as described in Section 4.e of the
59 Trust Legal Provisions and are provided without warranty as described
60 in the Revised BSD License.
61
62 This document may contain material from IETF Documents or IETF
63 Contributions published or made publicly available before November
64 10, 2008. The person(s) controlling the copyright in some of this
65 material may not have granted the IETF Trust the right to allow
66 modifications of such material outside the IETF Standards Process.
67 Without obtaining an adequate license from the person(s) controlling
68 the copyright in such materials, this document may not be modified
69 outside the IETF Standards Process, and derivative works of it may
70 not be created outside the IETF Standards Process, except to format
71 it for publication as an RFC or to translate it into languages other
72 than English.
73
74Table of Contents
75
76 1. Introduction and Overview
77 2. Document Conventions
78 3. The UIDONLY Extension
79 3.1. Enabling the UIDONLY Extension
80 3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE
81 3.3. Changes to UID FETCH / UID STORE
82 3.4. Changes to EXPUNGE / UID EXPUNGE
83 3.5. Changes to UID SEARCH
84 3.6. Changes to How Other Mailbox Changes Are Announced
85 3.7. Interaction with the CONDSTORE and QRESYNC Extensions
86 3.8. Interaction with Other Extensions
87 4. Formal Syntax
88 5. Security Considerations
89 6. IANA Considerations
90 7. Alternative Solutions Not Taken
91 8. Normative References
92 9. Informative References
93 Acknowledgments
94 Authors' Addresses
95
961. Introduction and Overview
97
98 This document defines an extension to the Internet Message Access
99 Protocol [RFC3501] [RFC9051] for eliminating the use of message
100 numbers. This extension is compatible with both IMAP4rev1 [RFC3501]
101 and IMAP4rev2 [RFC9051].
102
103 The UIDONLY extension of the Internet Message Access Protocol allows
104 clients to request that servers only use and return UIDs. This helps
105 both clients and servers to reduce resource usage required to
106 maintain a map between message numbers and UIDs.
107
1082. Document Conventions
109
110 In protocol examples, this document uses a prefix of "C:" to denote
111 lines sent by the client to the server and "S:" for lines sent by the
112 server to the client. Lines prefixed with "//" are comments
113 explaining the previous protocol line. These prefixes and comments
114 are not part of the protocol. Lines without any of these prefixes
115 are continuations of the previous line, and no line break is present
116 in the protocol unless specifically mentioned.
117
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
120 "OPTIONAL" in this document are to be interpreted as described in BCP
121 14 [RFC2119] [RFC8174] when, and only when, they appear in all
122 capitals, as shown here.
123
124 Other capitalized words are names of IMAP commands or responses
125 [RFC3501] [RFC9051] or keywords from this document.
126
1273. The UIDONLY Extension
128
129 An IMAP server advertises support for the UIDONLY extension by
130 including the "UIDONLY" capability in the CAPABILITY response/
131 response code.
132
133 Once the UIDONLY extension is enabled (see Section 3.1), the client
134 MUST NOT use message sequence numbers (including the special marker
135 "*") in any arguments to IMAP commands, and the server MUST return a
136 tagged BAD response if the client uses message sequence numbers. The
137 server MUST include the UIDREQUIRED response code in such BAD
138 responses (see below). Additionally, once the UIDONLY extension is
139 enabled, the server MUST NOT return message sequence numbers in any
140 response.
141
142 The UIDREQUIRED response code is defined as follows:
143
144 UIDREQUIRED: Once the UIDONLY extension is enabled, the server
145 returns the UIDREQUIRED response code when the client issues a
146 command that includes message numbers instead of UIDs.
147
148 C: 07 FETCH 10000:14589 (UID FLAGS)
149 S: 07 BAD [UIDREQUIRED] Message numbers are not allowed
150 once UIDONLY is enabled
151
152 The UIDONLY extension affects how information about new, expunged, or
153 changed messages is returned in unsolicited responses. In
154 particular, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID
155 EXPUNGE, as well as how unsolicited mailbox changes are announced.
156
157 The following subsections describe changes introduced by this
158 extension in more detail.
159
1603.1. Enabling the UIDONLY Extension
161
162 As the UIDONLY extension affects how information about new, expunged,
163 or changed messages is returned in unsolicited responses, it has to
164 be enabled by the client first using the ENABLE command.
165
166 S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY
167 AUTH=SCRAM-SHA-256]
168 C: 01 ENABLE UIDONLY
169 S: * ENABLED UIDONLY
170 S: 01 OK ENABLE completed
171
1723.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE
173
174 When UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY, and MOVE
175 commands are prohibited and MUST result in a tagged BAD response.
176 Clients should instead use UID FETCH, UID STORE, UID SEARCH, UID
177 COPY, or UID MOVE, respectively.
178
1793.3. Changes to UID FETCH / UID STORE
180
181 When UIDONLY is enabled, all FETCH responses that would be returned
182 by UID FETCH / UID STORE are replaced by UIDFETCH responses.
183
184 Note that the UIDFETCH response contains the same response data items
185 as specified for the FETCH response. The UID is always returned at
186 the beginning of a UIDFETCH response, and it can also appear in the
187 UID response data item, if requested by the client. While the UID
188 response data item is redundant when requested, it can simplify the
189 updating of existing (non-UIDONLY) implementations to support
190 UIDONLY.
191
192 C: 10 UID FETCH 25900:26600 (FLAGS)
193 [...]
194 S: * 25996 UIDFETCH (FLAGS (\Seen))
195 S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered))
196 S: * 26600 UIDFETCH (FLAGS ())
197 S: 10 OK FETCH completed
198
199 C: 11 UID FETCH 25900:26600 (UID FLAGS)
200 S: * 25900 UIDFETCH (FLAGS (\Seen) UID 25900)
201 S: * 25902 UIDFETCH (FLAGS (\Flagged) UID 25902)
202 S: * 26310 UIDFETCH (FLAGS (\Answered) UID 26310)
203 S: * 26311 UIDFETCH (FLAGS () UID 26311)
204 S: * 26498 UIDFETCH (FLAGS (\Answered) UID 26498)
205 [...]
206 S: 11 OK FETCH completed
207
2083.4. Changes to EXPUNGE / UID EXPUNGE
209
210 When UIDONLY is enabled, all EXPUNGED responses that would be
211 returned by EXPUNGE / UID EXPUNGE are replaced by VANISHED responses,
212 as defined in [RFC7162]. Note that a server that implements the
213 UIDONLY extension is not required (but allowed) to also implement the
214 CONDSTORE and/or QRESYNC extensions.
215
216 C: 12 EXPUNGE
217 S: * VANISHED 405,407,410,425
218 S: 12 OK expunged
219
2203.5. Changes to UID SEARCH
221
222 The "<sequence set>" UID SEARCH criterion is prohibited (and results
223 in a tagged BAD response) once UIDONLY is enabled. Clients should
224 use ALL or "UID <sequence set>" UID SEARCH criterion instead.
225
2263.6. Changes to How Other Mailbox Changes Are Announced
227
228 When UIDONLY is enabled, all changes to flags (and other dynamic
229 message attributes) are returned using UIDFETCH responses instead of
230 FETCH responses.
231
232 Similarly, all expunged messages are announced using VANISHED
233 responses instead of EXPUNGE responses.
234
235 This extension doesn't affect EXISTS or RECENT responses.
236
237 The UID MOVE / UID COPY commands SHOULD return the COPYUID response
238 code, as specified in [RFC4315].
239
240 Use of the UIDNOTSTICKY response code (see [RFC4315]) is not
241 compatible with the UIDONLY extension, i.e., a server that advertises
242 the UIDONLY extension MUST NOT return a UIDNOTSTICKY response code.
243
244 C: 15 UID move 597 "Archives/2023/2023-05"
245 S: * OK [COPYUID 1685977201 597 2] UID MOVE
246 S: * VANISHED 597
247 S: 15 OK UID MOVE Completed
248
2493.7. Interaction with the CONDSTORE and QRESYNC Extensions
250
251 The CONDSTORE extension is compatible with the UIDONLY extension.
252 The MODSEQ message data item is returned in UIDFETCH responses
253 instead of FETCH responses.
254
255 The QRESYNC extension is compatible with the UIDONLY extension, but
256 once UIDONLY is enabled, the fourth SELECT QRESYNC parameter (see
257 Section 3.2.5.2 ("Message Sequence Match Data") of [RFC7162]) MUST
258 NOT be used. The server MUST return a tagged BAD response if such a
259 parameter is observed once UIDONLY is enabled.
260
2613.8. Interaction with Other Extensions
262
263 IMAP extensions might define other commands that accept message
264 sequence numbers ("sequence-set" ABNF non-terminal; see Section 9 of
265 [RFC9051]). Once UIDONLY is enabled, the server MUST reject such
266 commands with a tagged BAD response. For example, the SORT and
267 THREAD [RFC5256] commands are prohibited, similarly to the SEARCH
268 command. However, UID SORT and UID THREAD can be used instead.
269
2704. Formal Syntax
271
272 The following syntax specification uses the Augmented Backus-Naur
273 Form (ABNF) notation as specified in [ABNF].
274
275 Non-terminals referenced but not defined below are as defined in
276 Section 9 of IMAP4 [RFC9051].
277
278 Except as noted otherwise, all alphabetic characters are case
279 insensitive. The use of uppercase or lowercase characters to define
280 token strings is for editorial clarity only. Implementations MUST
281 accept these strings in a case-insensitive fashion.
282
283 SP = <Defined in RFC 5234>
284
285 capability =/ "UIDONLY"
286 ;; <capability>; see RFC 9051
287
288 message-data =/ uidfetch-resp
289
290 uidfetch-resp = uniqueid SP "UIDFETCH" SP msg-att
291 ;; The uniqueid is the UID of
292 ;; the corresponding message
293
294 message-data =/ expunged-resp
295
296 expunged-resp = <defines VANISHED response; see RFC 7162>
297
298 resp-text-code =/ "UIDREQUIRED"
299
3005. Security Considerations
301
302 This IMAP extension is not believed to add any additional Security
303 Considerations beyond the ones that are generally applicable to
304 IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
305
3066. IANA Considerations
307
308 IMAP4 capabilities are registered by publishing a Standards Track or
309 IESG-approved Informational or Experimental RFC.
310
311 IANA has added the UIDONLY extension to the "IMAP Capabilities"
312 registry with RFC 9586 as the reference. The registry is located at
313 <https://www.iana.org/assignments/imap4-capabilities/>.
314
315 IANA has also added the UIDREQUIRED response code to the "IMAP
316 Response Codes" registry with RFC 9586 as the reference. The
317 registry is located at <https://www.iana.org/assignments/imap-
318 response-codes/>.
319
3207. Alternative Solutions Not Taken
321
322 An earlier draft version of this document proposed use of FETCH
323 responses with the message number parameter always set to 0. This
324 was considered to be too risky as it could cause unexpected side
325 effects and cache corruptions in client code that was not properly
326 updated to handle a lack of message numbers.
327
3288. Normative References
329
330 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
331 Specifications: ABNF", STD 68, RFC 5234,
332 DOI 10.17487/RFC5234, January 2008,
333 <https://www.rfc-editor.org/info/rfc5234>.
334
335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
336 Requirement Levels", BCP 14, RFC 2119,
337 DOI 10.17487/RFC2119, March 1997,
338 <https://www.rfc-editor.org/info/rfc2119>.
339
340 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
341 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
342 <https://www.rfc-editor.org/info/rfc3501>.
343
344 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
345 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
346 December 2005, <https://www.rfc-editor.org/info/rfc4315>.
347
348 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
349 Protocol - SORT and THREAD Extensions", RFC 5256,
350 DOI 10.17487/RFC5256, June 2008,
351 <https://www.rfc-editor.org/info/rfc5256>.
352
353 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
354 Changes Resynchronization (CONDSTORE) and Quick Mailbox
355 Resynchronization (QRESYNC)", RFC 7162,
356 DOI 10.17487/RFC7162, May 2014,
357 <https://www.rfc-editor.org/info/rfc7162>.
358
359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
361 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
362
363 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
364 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
365 DOI 10.17487/RFC9051, August 2021,
366 <https://www.rfc-editor.org/info/rfc9051>.
367
3689. Informative References
369
370 [IMAP-UIDONLY-ORIG]
371 Gulbrandsen, A., "The IMAP UIDONLY Extension", Work in
372 Progress, Internet-Draft, draft-gulbrandsen-imap-uidonly-
373 00, 25 April 2014, <https://datatracker.ietf.org/doc/html/
374 draft-gulbrandsen-imap-uidonly-00>.
375
376Acknowledgments
377
378 The editors of this document would like to thank the following people
379 who provided useful comments and/or participated in discussions that
380 lead to this document: Arnt Gulbrandsen, Ken Murchison, Bron
381 Gondwana, Barry Leiba, and Elwyn Davis.
382
383 This document is similar to [IMAP-UIDONLY-ORIG], but some different
384 syntactic choices were made in the end.
385
386Authors' Addresses
387
388 Alexey Melnikov
389 Isode Limited
390 Email: alexey.melnikov@isode.com
391 URI: https://www.isode.com
392
393
394 Arun Prakash Achuthan
395 Yahoo Inc.
396 Email: arunprakash@myyahoo.com
397
398
399 Vikram Nagulakonda
400 Yahoo Inc.
401 Email: nvikram_imap@yahoo.com
402
403
404 Ashutosh Singh
405 Yahoo Inc.
406 Email: ashutoshvsingh@yahoo.com
407
408
409 Luis Alves
410 Email: luis.alves@lafaspot.com
411