1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Internet Engineering Task Force (IETF) S. Brandt
Request for Comments: 8508 Verizon
Category: Standards Track January 2019
ISSN: 2070-1721
<span class="h1">IMAP REPLACE Extension</span>
Abstract
This document defines an IMAP extension that can be used to replace
an existing message in a message store with a new message. Message
replacement is a common operation for clients that automatically save
drafts or notes as a user composes them.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8508">https://www.rfc-editor.org/info/rfc8508</a>.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Brandt Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
Table of Contents
<a href="#section-1">1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions Used in This Document . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Advertising Support for REPLACE . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. REPLACE Command . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. UID REPLACE Command . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.4">3.4</a>. Semantics of REPLACE and UID REPLACE . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.5">3.5</a>. IMAP State Diagram Impacts . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Interaction with Other Extensions . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. CATENATE . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. UIDPLUS . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.4">4.4</a>. IMAP Events in Sieve . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.5">4.5</a>. CONDSTORE/QRESYNC . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.6">4.6</a>. OBJECTID . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.7">4.7</a>. MULTIAPPEND . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Overview</span>
This document defines an IMAP ([<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>]) extension to facilitate the
replacement of an existing message with a new one. This is
accomplished by defining a new REPLACE command and extending the
Unique Identifier (UID) command to allow UID REPLACE.
Since there is no replace function in the base IMAP specification,
clients have instead had to use a combination of three separate
commands issued in serial fashion; APPEND, STORE, and EXPUNGE.
Pipelining of these three commands is not recommended since failure
of any individual command should prevent subsequent commands from
being executed lest the original message version be lost.
Because of the non-atomic nature of the existing sequence,
interruptions can leave messages in intermediate states that can be
seen and acted upon by other clients. Such interruptions can also
strand older revisions of messages, thereby forcing the user to
manually clean up multiple revisions of the same message in order to
avoid wasteful quota consumption. Additionally, the existing
sequence can fail on APPEND due to an over-quota condition even
<span class="grey">Brandt Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
though the subsequent STORE/EXPUNGE would free up enough space for
the newly revised message. And finally, server efficiencies may be
possible with a single logical message replacement operation as
compared to the existing APPEND/STORE/EXPUNGE sequence.
In its simplest form, the REPLACE command is a single-command
encapsulation of APPEND, STORE +flags \DELETED, and UID EXPUNGE for a
message, except that it avoids any of the quota implications or
intermediate states associated with the three-command sequence.
Server developers are encouraged to implement REPLACE as an atomic
operation to simplify error handling, minimize operational concerns,
and reduce potential security problems. For systems where this is
not possible, communication with the requesting client must ensure no
confusion of message store state. A server MUST NOT generate a
response code for the STORE +flags \DELETED portion of the sequence.
Additionally, servers supporting the REPLACE command MUST NOT infer
any inheritance of content, flags, or annotations from the message
being replaced.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
Formal syntax is defined by [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
Example lines prefaced by "C:" are sent by the client, and ones
prefaced by "S:" are sent by the server.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. REPLACE and UID REPLACE</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Advertising Support for REPLACE</span>
Servers that implement the REPLACE extension will return "REPLACE" as
one of the supported capabilities in the CAPABILITY command response.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. REPLACE Command</span>
Arguments: message sequence number
mailbox name
OPTIONAL flag parenthesized list
OPTIONAL date/time string
message literal
Responses: no specific responses for this command
<span class="grey">Brandt Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
Result: OK - replace completed
NO - replace error; can't remove specified message
or can't add new message content
BAD - command unknown or arguments invalid
Example:
C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822388-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C:
S: * OK [APPENDUID 1 2000] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A003 OK Replace completed
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. UID REPLACE Command</span>
This extends the first form of the UID command (see <a href="./rfc3501#section-6.4.8">Section 6.4.8 of
[RFC3501]</a>) to add the REPLACE command defined above as a valid
argument. This form of REPLACE uses a UID rather than a sequence
number as its first parameter.
Example:
C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822389-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C: Hopefully next year you can join us.
C:
S: * OK [APPENDUID 1 2001] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A004 OK Replace completed
<span class="grey">Brandt Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Semantics of REPLACE and UID REPLACE</span>
The REPLACE and UID REPLACE commands take five arguments: a message
identifier, a named mailbox, an optional parenthesized flag list, an
optional message date/time string, and a message literal. The
message literal will be appended to the named mailbox, and the
message specified by the message identifier will be removed from the
selected mailbox. These operations will appear to the client as a
single action. This has the same effect as the following sequence:
1. APPEND
2. [UID] STORE +FLAGS.SILENT \DELETED
3. UID EXPUNGE
In the cited sequence, the quota implications of APPEND are evaluated
within the context of the pending EXPUNGE so that only the net quota
consumption is considered. Additionally, the EXPUNGE portion of the
sequence only applies to the specified message, not all messages
flagged as "\Deleted".
Although the effect of REPLACE is identical to the steps above, the
semantics are not identical; similar to MOVE [<a href="./rfc6851" title=""Internet Message Access Protocol (IMAP) - MOVE Extension"">RFC6851</a>], the
intermediate states do not occur and the response codes are
different. In particular, the response codes for APPEND and EXPUNGE
will be returned while those for the STORE operation MUST NOT be
generated.
When an error occurs while processing REPLACE or UID REPLACE, the
server MUST NOT leave the selected mailbox in an inconsistent state;
any untagged EXPUNGE response MUST NOT be sent until all actions are
successfully completed.
While it may be common for the named mailbox argument to match the
selected mailbox for the common use case of replacing a draft, the
REPLACE extension intentionally does not require the two to be the
same. As an example, it's possible to use the REPLACE command to
replace a message in the \Drafts special-use mailbox (see <a href="./rfc6154#section-2">Section 2
of [RFC6154]</a>) with a message in the \Sent special-use mailbox
following message submission.
Because of the similarity of REPLACE to APPEND, extensions that
affect APPEND affect REPLACE in the same way. Response codes such as
TRYCREATE (see <a href="./rfc3501#section-6.3.11">Section 6.3.11 of [RFC3501]</a>), along with those defined
by extensions, are sent as appropriate. See <a href="#section-4">Section 4</a> for more
information about how REPLACE interacts with other IMAP extensions.
<span class="grey">Brandt Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. IMAP State Diagram Impacts</span>
Unlike the APPEND command, which is valid in the authenticated state,
the REPLACE and UID REPLACE commands MUST only be valid in the
selected state. This difference from APPEND is necessary since
REPLACE operates on message sequence numbers. Additionally, the
REPLACE extension intentionally follows the convention for UID
commands found in <a href="./rfc3501#section-6.4.8">Section 6.4.8 of [RFC3501]</a> in that the UID variant
of the command does not support use from the authenticated state.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Interaction with Other Extensions</span>
This section describes how REPLACE interacts with some other IMAP
extensions.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. ACL</span>
The Access Control List (ACL) rights [<a href="./rfc4314" title=""IMAP4 Access Control List (ACL) Extension"">RFC4314</a>] required for UID
REPLACE are the union of the ACL rights required for UID STORE and
UID EXPUNGE in the current mailbox, and APPEND in the target mailbox.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. CATENATE</span>
Servers supporting both REPLACE and CATENATE [<a href="./rfc4469" title=""Internet Message Access Protocol (IMAP) CATENATE Extension"">RFC4469</a>] MUST support
the additional append-data and resp-text-code elements defined in
<a href="#section-5">Section 5</a> ("Formal Syntax") of [<a href="./rfc4469" title=""Internet Message Access Protocol (IMAP) CATENATE Extension"">RFC4469</a>] in conjunction with the
REPLACE command. When combined with CATENATE, REPLACE can become
quite an efficient way of message manipulation.
<span class="grey">Brandt Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
Example:
User composes message and attaches photo
----------------------------------------
C: A010 APPEND Drafts (\Seen \Draft) {1201534}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Message-ID: <B238822388-0100003@example.org>
C: MIME-Version: 1.0
C: Content-Type: multipart/mixed;
C: boundary="------------030305060306060609050804"
C:
C: --------------030305060306060609050804
C: Content-Type: text/plain; charset=utf-8; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Here is picture from the fireworks
C:
C: Yours...
C: Fritz
C:
C: --------------030305060306060609050804
C: Content-Type: image/jpeg;
C: name="Fireworks.jpg"
C: Content-Transfer-Encoding: base64
C: Content-Disposition: attachment;
C: filename="Fireworks.jpg"
C:
<large base64 encoded part goes here>
C:
C: --------------030305060306060609050804--
S: A010 OK [APPENDUID 1 3002] APPEND complete
User completes message with To: and Subject: fields
---------------------------------------------------
C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
S: + Ready for literal data
C: To: Mitzy <miss.mitzy@example.org>
C: Subject: My view of the fireworks
C: URL "/Drafts/;UID=3002")
S: * OK [APPENDUID 1 3003] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A011 OK REPLACE completed
<span class="grey">Brandt Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. UIDPLUS</span>
Servers supporting both REPLACE and UIDPLUS [<a href="./rfc4315" title=""Internet Message Access Protocol (IMAP) - UIDPLUS extension"">RFC4315</a>] SHOULD send
APPENDUID in response to a UID REPLACE command. For additional
information, see <a href="./rfc4315#section-3">Section 3 of [RFC4315]</a>. Servers implementing
REPLACE and UIDPLUS are also advised to send the APPENDUID response
code in an untagged OK before sending the EXPUNGE or replaced
responses. (Sending APPENDUID in the tagged OK as described in the
UIDPLUS specification means that the client first receives EXPUNGE
for a message and afterwards APPENDUID for the new message. It can
be unnecessarily difficult to process that sequence usefully.)
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. IMAP Events in Sieve</span>
REPLACE applies to IMAP events in Sieve [<a href="./rfc6785" title=""Support for Internet Message Access Protocol (IMAP) Events in Sieve"">RFC6785</a>] in the same way
that APPEND does. Therefore, REPLACE can cause a Sieve script to be
invoked with the imap.cause set to "APPEND". Because the
intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by
REPLACE, no action will be taken that results in an imap.cause of
FLAG.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. CONDSTORE/QRESYNC</span>
Servers implementing both REPLACE and CONDSTORE/QRESYNC [<a href="./rfc7162" title=""IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)"">RFC7162</a>]
MUST treat the message being replaced as if it were being removed
with a UID EXPUNGE command. Sections <a href="#section-3.2.9">3.2.9</a> and <a href="#section-3.2.10">3.2.10</a> of [<a href="./rfc7162" title=""IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)"">RFC7162</a>]
are particularly relevant for this condition.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. OBJECTID</span>
Servers implementing both REPLACE and OBJECTID [<a href="./rfc8474" title=""IMAP Extension for Object Identifiers"">RFC8474</a>] MUST return
different EMAILIDs for both the replaced and replacing messages. The
only exception to this is the case outlined in <a href="#section-5.1">Section 5.1</a> ("EMAILID
Identifier for Identical Messages") of [<a href="./rfc8474" title=""IMAP Extension for Object Identifiers"">RFC8474</a>] when the server
detects that both messages' immutable content is identical.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. MULTIAPPEND</span>
The REPLACE extension has no interaction with MULTIAPPEND [<a href="./rfc3502" title=""Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension"">RFC3502</a>].
This document explicitly does not outline a method for replacing
multiple messages concurrently.
<span class="grey">Brandt Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Formal Syntax</span>
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]. [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>] defines
the non-terminals "capability","command-select", "mailbox",
"seq-number", and "uid". [<a href="./rfc4466" title=""Collected Extensions to IMAP4 ABNF"">RFC4466</a>] defines the non-terminal
"append-message".
Except as noted otherwise, all alphabetic characters are case
insensitive. The use of uppercase or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
capability =/ "REPLACE"
command-select =/ replace
replace = "REPLACE" SP seq-number SP mailbox append-message
uid =/ "UID" SP replace
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document is believed to add no security problems beyond those
that may already exist with the base IMAP specification. The REPLACE
command may actually prevent some potential security problems because
it avoids intermediate message states that could possibly be
exploited by an attacker.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
The IANA has added REPLACE to the "IMAP Capabilities" registry at
<<a href="https://www.iana.org/assignments/imap-capabilities">https://www.iana.org/assignments/imap-capabilities</a>>.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3501">RFC3501</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, DOI 10.17487/RFC3501, March 2003,
<<a href="https://www.rfc-editor.org/info/rfc3501">https://www.rfc-editor.org/info/rfc3501</a>>.
[<a id="ref-RFC4314">RFC4314</a>] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
<a href="./rfc4314">RFC 4314</a>, DOI 10.17487/RFC4314, December 2005,
<<a href="https://www.rfc-editor.org/info/rfc4314">https://www.rfc-editor.org/info/rfc4314</a>>.
<span class="grey">Brandt Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
[<a id="ref-RFC4315">RFC4315</a>] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", <a href="./rfc4315">RFC 4315</a>, DOI 10.17487/RFC4315,
December 2005, <<a href="https://www.rfc-editor.org/info/rfc4315">https://www.rfc-editor.org/info/rfc4315</a>>.
[<a id="ref-RFC4466">RFC4466</a>] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", <a href="./rfc4466">RFC 4466</a>, DOI 10.17487/RFC4466, April 2006,
<<a href="https://www.rfc-editor.org/info/rfc4466">https://www.rfc-editor.org/info/rfc4466</a>>.
[<a id="ref-RFC4469">RFC4469</a>] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", <a href="./rfc4469">RFC 4469</a>, DOI 10.17487/RFC4469, April
2006, <<a href="https://www.rfc-editor.org/info/rfc4469">https://www.rfc-editor.org/info/rfc4469</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC6785">RFC6785</a>] Leiba, B., "Support for Internet Message Access Protocol
(IMAP) Events in Sieve", <a href="./rfc6785">RFC 6785</a>, DOI 10.17487/RFC6785,
November 2012, <<a href="https://www.rfc-editor.org/info/rfc6785">https://www.rfc-editor.org/info/rfc6785</a>>.
[<a id="ref-RFC7162">RFC7162</a>] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", <a href="./rfc7162">RFC 7162</a>,
DOI 10.17487/RFC7162, May 2014,
<<a href="https://www.rfc-editor.org/info/rfc7162">https://www.rfc-editor.org/info/rfc7162</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8474">RFC8474</a>] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", <a href="./rfc8474">RFC 8474</a>, DOI 10.17487/RFC8474, September
2018, <<a href="https://www.rfc-editor.org/info/rfc8474">https://www.rfc-editor.org/info/rfc8474</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3502">RFC3502</a>] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", <a href="./rfc3502">RFC 3502</a>, DOI 10.17487/RFC3502,
March 2003, <<a href="https://www.rfc-editor.org/info/rfc3502">https://www.rfc-editor.org/info/rfc3502</a>>.
[<a id="ref-RFC6154">RFC6154</a>] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
Special-Use Mailboxes", <a href="./rfc6154">RFC 6154</a>, DOI 10.17487/RFC6154,
March 2011, <<a href="https://www.rfc-editor.org/info/rfc6154">https://www.rfc-editor.org/info/rfc6154</a>>.
<span class="grey">Brandt Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8508">RFC 8508</a> IMAP REPLACE Extension January 2019</span>
[<a id="ref-RFC6851">RFC6851</a>] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
Access Protocol (IMAP) - MOVE Extension", <a href="./rfc6851">RFC 6851</a>,
DOI 10.17487/RFC6851, January 2013,
<<a href="https://www.rfc-editor.org/info/rfc6851">https://www.rfc-editor.org/info/rfc6851</a>>.
Acknowledgements
The author would like to thank the participants of IMAPEXT with
particular thanks to Arnt Gulbrandsen, Alexey Melnikov, Chris Newman,
and Bron Gondwana for their specific contributions.
Author's Address
Stuart Brandt
Verizon
22001 Loudoun County Parkway
Ashburn, VA 20147
United States of America
Email: stujenerin@aol.com
Brandt Standards Track [Page 11]
</pre>
|
