imapext-2007
view docs/rfc/rfc5162.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group A. Melnikov
8 Request for Comments: 5162 D. Cridland
9 Category: Standards Track Isode Ltd
10 C. Wilson
11 Nokia
12 March 2008
15 IMAP4 Extensions for Quick Mailbox Resynchronization
17 Status of This Memo
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
25 Abstract
27 This document defines an IMAP4 extension, which gives an IMAP client
28 the ability to quickly resynchronize any previously opened mailbox as
29 part of the SELECT command, without the need for server-side state or
30 additional client round-trips. This extension also introduces a new
31 response that allows for a more compact representation of a list of
32 expunged messages (and always includes the Unique Identifiers (UIDs)
33 expunged).
58 Melnikov, et al. Standards Track [Page 1]
60 RFC 5162 IMAP Quick Mailbox Resync March 2008
63 Table of Contents
65 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
67 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4
68 3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 4
69 3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 8
70 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 10
71 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 11
72 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 11
73 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 12
74 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
75 4. Server Implementation Considerations . . . . . . . . . . . . . 15
76 4.1. Server Implementations That Don't Store Extra State . . . 15
77 4.2. Server Implementations Storing Minimal State . . . . . . . 16
78 4.3. Additional State Required on the Server . . . . . . . . . 16
79 5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
86 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
88 1. Introduction and Overview
90 The [CONDSTORE] extension gives a disconnected client the ability to
91 quickly resynchronize IMAP flag changes for previously seen messages.
92 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox
93 is opened. In order for the client to discover which messages have
94 been expunged, the client still has to issue a UID FETCH or a UID
95 SEARCH command. This document defines an extension to [CONDSTORE]
96 that allows a reconnecting client to perform full resynchronization,
97 including discovery of expunged messages, in a single round-trip.
98 This extension also introduces a new response, VANISHED, that allows
99 for a more compact representation of a list of expunged messages.
101 This extension can be useful for mobile clients that can experience
102 frequent disconnects caused by environmental factors (battery life,
103 signal strength, etc.). Such clients need a way to quickly reconnect
104 to the IMAP server, while minimizing delay experienced by the user as
105 well as the amount of traffic (and hence the expense) generated by
106 resynchronization.
114 Melnikov, et al. Standards Track [Page 2]
116 RFC 5162 IMAP Quick Mailbox Resync March 2008
119 By extending the SELECT command to perform the additional
120 resynchronization, this also allows clients to reduce concurrent
121 connections to the IMAP server held purely for the sake of avoiding
122 the resynchronization.
124 The quick resync IMAP extension is present if an IMAP4 server returns
125 "QRESYNC" as one of the supported capabilities to the CAPABILITY
126 command.
128 Servers supporting this extension MUST implement and advertise
129 support for the [ENABLE] IMAP extension. Also, the presence of the
130 "QRESYNC" capability implies support for the [CONDSTORE] IMAP
131 extension even if the CONDSTORE capability isn't advertised. A
132 server compliant with this specification is REQUIREd to support
133 "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE
134 enabling commands", as defined in [CONDSTORE], and have identical
135 results), but there is no requirement for a compliant server to
136 support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE
137 QRESYNC CONDSTORE" command also tells the server that it SHOULD start
138 sending VANISHED responses (see Section 3.6) instead of EXPUNGE
139 responses. This change remains in effect until the connection is
140 closed.
142 For compatibility with clients that only support the [CONDSTORE] IMAP
143 extension, servers SHOULD advertise CONDSTORE in the CAPABILITY
144 response as well.
146 A client making use of this extension MUST issue "ENABLE QRESYNC"
147 once it is authenticated. A server MUST respond with a tagged BAD
148 response if the QRESYNC parameter to the SELECT/EXAMINE command or
149 the VANISHED UID FETCH modifier is specified and the client hasn't
150 issued "ENABLE QRESYNC" in the current connection.
152 This document puts additional requirements on a server implementing
153 the [CONDSTORE] extension. Each mailbox that supports persistent
154 storage of mod-sequences, i.e., for which the server has sent a
155 HIGHESTMODSEQ untagged OK response code on a successful SELECT/
156 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more
157 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the
158 server MUST associate the incremented mod-sequence with the UIDs of
159 the expunged messages.
161 A client that supports CONDSTORE but not this extension might
162 resynchronize a mailbox and discover that its HIGHESTMODSEQ has
163 increased from the value cached by the client. If the increase is
164 only due to messages having been expunged since the client last
165 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE
166 command that returns no data. Thus, a client that supports CONDSTORE
170 Melnikov, et al. Standards Track [Page 3]
172 RFC 5162 IMAP Quick Mailbox Resync March 2008
175 but not this extension might incur a penalty of an unneeded round-
176 trip when resynchronizing some mailboxes (those that have had
177 messages expunged but no flag changes since the last
178 synchronization).
180 This extra round-trip is only incurred by clients that support
181 CONDSTORE but not this extension, and only when a mailbox has had
182 messages expunged but no flag changes to non-expunged messages.
183 Since CONDSTORE is a relatively new extension, it is thought likely
184 that clients that support it will also support this extension.
186 2. Requirements Notation
188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
190 document are to be interpreted as described in [RFC2119].
192 In examples, "C:" and "S:" indicate lines sent by the client and
193 server respectively. If a single "C:" or "S:" label applies to
194 multiple lines, then the line breaks between those lines are for
195 editorial clarity only and are not part of the actual protocol
196 exchange. The five characters [...] means that something has been
197 elided.
199 Understanding of the IMAP message sequence numbers and UIDs and the
200 EXPUNGE response [RFC3501] is essential when reading this document.
202 3. IMAP Protocol Changes
204 3.1. QRESYNC Parameter to SELECT/EXAMINE
206 The Quick Resynchronization parameter to SELECT/EXAMINE commands has
207 four arguments:
209 o the last known UIDVALIDITY,
211 o the last known modification sequence,
213 o the optional set of known UIDs, and
215 o an optional parenthesized list of known sequence ranges and their
216 corresponding UIDs.
218 A server MUST respond with a tagged BAD response if the Quick
219 Resynchronization parameter to SELECT/EXAMINE command is specified
220 and the client hasn't issued "ENABLE QRESYNC" in the current
221 connection.
226 Melnikov, et al. Standards Track [Page 4]
228 RFC 5162 IMAP Quick Mailbox Resync March 2008
231 Before opening the specified mailbox, the server verifies all
232 arguments for syntactic validity. If any parameter is not
233 syntactically valid, the server returns the tagged BAD response, and
234 the mailbox remains unselected. Once the check is done, the server
235 opens the mailbox as if no SELECT/EXAMINE parameters are specified
236 (this is subject to processing of other parameters as defined in
237 other extensions). In particular this means that the server MUST
238 send all untagged responses as specified in Sections 6.3.1 and 6.3.2
239 of [RFC3501].
241 After that, the server checks the UIDVALIDITY value provided by the
242 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY
243 for the mailbox being opened, then the server MUST ignore the
244 remaining parameters and behave as if no dynamic message data
245 changed. The client can discover this situation by comparing the
246 UIDVALIDITY value returned by the server. This behavior allows the
247 client not to synchronize the mailbox or decide on the best
248 synchronization strategy.
250 Example: Attempting to resynchronize INBOX, but the provided
251 UIDVALIDITY parameter doesn't match the current UIDVALIDITY
252 value.
254 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
255 41,43:211,214:541))
256 S: * 464 EXISTS
257 S: * 3 RECENT
258 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
259 S: * OK [UIDNEXT 550] Predicted next UID
260 S: * OK [HIGHESTMODSEQ 90060128194045007]
261 S: * OK [UNSEEN 12] Message 12 is first unseen
262 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
263 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
264 \Deleted \Seen \*)] Permanent flags
265 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
267 Modification Sequence and UID Parameters:
269 A server that doesn't support the persistent storage of mod-sequences
270 for the mailbox MUST send the OK untagged response including the
271 NOMODSEQ response code with every successful SELECT or EXAMINE
272 command, as described in [CONDSTORE]. Such a server doesn't need to
273 remember mod-sequences for expunged messages in the mailbox. It MUST
274 ignore the remaining parameters and behave as if no dynamic message
275 data changed.
277 If the provided UIDVALIDITY matches that of the selected mailbox, the
278 server then checks the last known modification sequence.
282 Melnikov, et al. Standards Track [Page 5]
284 RFC 5162 IMAP Quick Mailbox Resync March 2008
287 The server sends the client any pending flag changes (using FETCH
288 responses that MUST contain UIDs) and expunges those that have
289 occurred in this mailbox since the provided modification sequence.
291 If the list of known UIDs was also provided, the server should only
292 report flag changes and expunges for the specified messages. If the
293 client did not provide the list of UIDs, the server acts as if the
294 client has specified "1:<maxuid>", where <maxuid> is the mailbox's
295 UIDNEXT value minus 1. If the mailbox is empty and never had any
296 messages in it, then lack of the list of UIDs is interpreted as an
297 empty set of UIDs.
299 Thus, the client can process just these pending events and need not
300 perform a full resynchronization. Without the message sequence
301 number matching information, the result of this step is semantically
302 equivalent to the client issuing:
303 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE
304 "mod-sequence-value" VANISHED)
306 Example:
307 C: A03 SELECT INBOX (QRESYNC (67890007
308 90060115194045000 41,43:211,214:541))
309 S: * OK [CLOSED]
310 S: * 314 EXISTS
311 S: * 15 RECENT
312 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
313 S: * OK [UIDNEXT 567] Predicted next UID
314 S: * OK [HIGHESTMODSEQ 90060115205545359]
315 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
316 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
317 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
318 \Deleted \Seen \*)] Permanent flags
319 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
320 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
321 (90060115194045001))
322 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
323 (90060115194045308))
324 S: ...
325 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
326 (90060115194045001))
327 S: A03 OK [READ-WRITE] mailbox selected
329 Message sequence match data:
331 A client MAY provide a parenthesized list of a message sequence set
332 and the corresponding UID sets. Both MUST be provided in ascending
333 order. The server uses this data to restrict the range for which it
334 provides expunged message information.
338 Melnikov, et al. Standards Track [Page 6]
340 RFC 5162 IMAP Quick Mailbox Resync March 2008
343 Conceptually, the client provides a small sample of sequence numbers
344 for which it knows the corresponding UIDs. The server then compares
345 each sequence number and UID pair the client provides with the
346 current state of the mailbox. If a pair matches, then the client
347 knows of any expunges up to, and including, the message, and thus
348 will not include that range in the VANISHED response, even if the
349 "mod-sequence-value" provided by the client is too old for the server
350 to have data of when those messages were expunged.
352 Thus, if the Nth message number in the first set in the list is 4,
353 and the Nth UID in the second set in the list is 8, and the mailbox's
354 fourth message has UID 8, then no UIDs equal to or less than 8 are
355 present in the VANISHED response. If the (N+1)th message number is
356 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox
357 has UID 25, then the lowest UID included in the VANISHED response
358 would be 9.
360 In the following two examples, the server is unable to remember
361 expunges at all, and only UIDs with messages divisible by three are
362 present in the mailbox. In the first example, the client does not
363 use the fourth parameter; in the second, it provides it. This
364 example is somewhat extreme, but shows that judicious usage of the
365 sequence match data can save a substantial amount of bandwidth.
367 Example:
368 C: A04 SELECT INBOX (QRESYNC (67890007
369 90060115194045000 1:29997))
370 S: * 10003 EXISTS
371 S: * 5 RECENT
372 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
373 S: * OK [UIDNEXT 30013] Predicted next UID
374 S: * OK [HIGHESTMODSEQ 90060115205545359]
375 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
376 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
377 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
378 \Deleted \Seen \*)] Permanent flags
379 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
380 29998:29999,30001:30002,30004:30005,30007:30008
381 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
382 (90060115194045027))
383 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
384 (90060115194045028))
385 S: ...
386 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
387 (90060115194045031))
388 S: A04 OK [READ-WRITE] mailbox selected
394 Melnikov, et al. Standards Track [Page 7]
396 RFC 5162 IMAP Quick Mailbox Resync March 2008
399 Example:
400 C: B04 SELECT INBOX (QRESYNC (67890007
401 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
402 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
403 29994,29997)))
404 S: * 10003 EXISTS
405 S: * 5 RECENT
406 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
407 S: * OK [UIDNEXT 30013] Predicted next UID
408 S: * OK [HIGHESTMODSEQ 90060115205545359]
409 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
410 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
411 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
412 \Deleted \Seen \*)] Permanent flags
413 S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
414 30008
415 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
416 (90060115194045027))
417 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
418 (90060115194045028))
419 S: ...
420 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
421 (90060115194045031))
422 S: B04 OK [READ-WRITE] mailbox selected
424 3.2. VANISHED UID FETCH Modifier
426 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH
427 commands to include an optional FETCH modifier. This document
428 defines a new UID FETCH modifier: VANISHED.
430 Note, that the VANISHED UID FETCH modifier is NOT allowed with a
431 FETCH command. The server MUST return a tagged BAD response if this
432 response is specified as a modifier to the FETCH command.
434 A server MUST respond with a tagged BAD response if the VANISHED UID
435 FETCH modifier is specified and the client hasn't issued "ENABLE
436 QRESYNC" in the current connection.
438 The VANISHED UID FETCH modifier MUST only be specified together with
439 the CHANGEDSINCE UID FETCH modifier.
441 The VANISHED UID FETCH modifier instructs the server to report those
442 messages from the UID set parameter that have been expunged and whose
443 associated mod-sequence is larger than the specified mod-sequence.
444 That is, the client requests to be informed of messages from the
445 specified set that were expunged since the specified mod-sequence.
446 Note that the mod-sequence(s) associated with these messages were
450 Melnikov, et al. Standards Track [Page 8]
452 RFC 5162 IMAP Quick Mailbox Resync March 2008
455 updated when the messages were expunged (as described above). The
456 expunged messages are reported using the VANISHED response as
457 described in Section 3.6, which MUST contain the EARLIER tag. Any
458 VANISHED (EARLIER) responses MUST be returned before any FETCH
459 responses, as otherwise the client might get confused about how
460 message numbers map to UIDs.
462 Note: A server that receives a mod-sequence smaller than <minmodseq>,
463 where <minmodseq> is the value of the smallest expunged mod-sequence
464 it remembers minus one, MUST behave as if it was requested to report
465 all expunged messages from the provided UID set parameter.
467 Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware
468 client [CONDSTORE] needs to issue separate commands to learn of flag
469 changes and expunged messages since the last synchronization:
471 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
472 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
473 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
474 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
475 $AutoJunk $MDNSent))
476 S: s100 OK FETCH completed
477 C: s101 UID SEARCH 300:500
478 S: * SEARCH 404 406 407 408 410 412
479 S: s101 OK search completed
481 Where 300 and 500 are the lowest and highest UIDs from client's
482 cache. The second SEARCH response tells the client that the messages
483 with UIDs 407, 410, and 412 are still present, but their flags
484 haven't changed since the specified modification sequence.
486 Using the VANISHED UID FETCH modifier, it is sufficient to issue only
487 a single command:
489 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
490 VANISHED)
491 S: * VANISHED (EARLIER) 300:310,405,411
492 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
493 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
494 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
495 $AutoJunk $MDNSent))
496 S: s100 OK FETCH completed
506 Melnikov, et al. Standards Track [Page 9]
508 RFC 5162 IMAP Quick Mailbox Resync March 2008
511 3.3. EXPUNGE Command
513 Arguments: none
515 Responses: untagged responses: EXPUNGE or VANISHED
517 Result: OK - expunge completed
518 NO - expunge failure: can't expunge (e.g., permission denied)
519 BAD - command unknown or arguments invalid
521 This section updates the definition of the EXPUNGE command described
522 in Section 6.4.3 of [RFC3501].
524 The EXPUNGE command permanently removes all messages that have the
525 \Deleted flag set from the currently selected mailbox. Before
526 returning an OK to the client, those messages that are removed are
527 reported using a VANISHED response or EXPUNGE responses.
529 If the server is capable of storing modification sequences for the
530 selected mailbox, it MUST increment the per-mailbox mod-sequence if
531 at least one message was permanently removed due to the execution of
532 the EXPUNGE command. For each permanently removed message, the
533 server MUST remember the incremented mod-sequence and corresponding
534 UID. If at least one message got expunged, the server MUST send the
535 updated per-mailbox modification sequence using the HIGHESTMODSEQ
536 response code (defined in [CONDSTORE]) in the tagged OK response.
538 Example: C: A202 EXPUNGE
539 S: * 3 EXPUNGE
540 S: * 3 EXPUNGE
541 S: * 5 EXPUNGE
542 S: * 8 EXPUNGE
543 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
545 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
546 set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The
547 second "* 3 EXPUNGE" reports message # 4 as expunged (the message
548 number got decremented due to the previous EXPUNGE response). See
549 the description of the EXPUNGE response in [RFC3501] for further
550 explanation.
552 Note that if the server chooses to always send VANISHED responses
553 instead of EXPUNGE responses, the previous example might look like
554 this:
556 Example: C: B202 EXPUNGE
557 S: * VANISHED 405,407,410,425
558 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
562 Melnikov, et al. Standards Track [Page 10]
564 RFC 5162 IMAP Quick Mailbox Resync March 2008
567 Here messages with message numbers 3, 4, 7, and 11 have respective
568 UIDs 405, 407, 410, and 425.
570 3.4. CLOSE Command
572 Arguments: none
574 Responses: no specific responses for this command
576 Result: OK - close completed, now in authenticated state
577 BAD - command unknown or arguments invalid
579 This section updates the definition of the CLOSE command described in
580 Section 6.4.2 of [RFC3501].
582 The CLOSE command permanently removes all messages that have the
583 \Deleted flag set from the currently selected mailbox, and returns to
584 the authenticated state from the selected state. No untagged EXPUNGE
585 (or VANISHED) responses are sent.
587 If the server is capable of storing modification sequences for the
588 selected mailbox, it MUST increment the per-mailbox mod-sequence if
589 at least one message was permanently removed due to the execution of
590 the CLOSE command. For each permanently removed message, the server
591 MUST remember the incremented mod-sequence and corresponding UID. If
592 at least one message got expunged, the server MUST send the updated
593 per-mailbox modification sequence using the HIGHESTMODSEQ response
594 code (defined in [CONDSTORE]) in the tagged OK response.
596 Example: C: A202 CLOSE
597 S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
599 3.5. UID EXPUNGE Command
601 Arguments: message set
603 Responses: untagged responses: EXPUNGE or VANISHED
605 Result: OK - expunge completed
606 NO - expunge failure: can't expunge (e.g., permission denied)
607 BAD - command unknown or arguments invalid
609 This section updates the definition of the UID EXPUNGE command
610 described in Section 2.1 of [UIDPLUS]. Servers that implement both
611 [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as
612 described in this section.
618 Melnikov, et al. Standards Track [Page 11]
620 RFC 5162 IMAP Quick Mailbox Resync March 2008
623 The UID EXPUNGE command permanently removes from the currently
624 selected mailbox all messages that both have the \Deleted flag set
625 and have a UID that is included in the specified message set. If a
626 message either does not have the \Deleted flag set or has a UID that
627 is not included in the specified message set, it is not affected.
629 This command is particularly useful for disconnected mode clients.
630 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the
631 server, the client can avoid inadvertently removing any messages that
632 have been marked as \Deleted by other clients between the time that
633 the client was last connected and the time the client resynchronizes.
635 Before returning an OK to the client, those messages that are removed
636 are reported using a VANISHED response or EXPUNGE responses.
638 If the server is capable of storing modification sequences for the
639 selected mailbox, it MUST increment the per-mailbox mod-sequence if
640 at least one message was permanently removed due to the execution of
641 the UID EXPUNGE command. For each permanently removed message, the
642 server MUST remember the incremented mod-sequence and corresponding
643 UID. If at least one message got expunged, the server MUST send the
644 updated per-mailbox modification sequence using the HIGHESTMODSEQ
645 response code (defined in [CONDSTORE]) in the tagged OK response.
647 Example: C: . UID EXPUNGE 3000:3002
648 S: * 3 EXPUNGE
649 S: * 3 EXPUNGE
650 S: * 3 EXPUNGE
651 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
653 Note: In this example, at least messages with message numbers 3, 4,
654 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3
655 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE"
656 reports message # 4 as expunged (the message number got decremented
657 due to the previous EXPUNGE response). See the description of the
658 EXPUNGE response in [RFC3501] for further explanation.
660 3.6. VANISHED Response
662 Contents: an optional EARLIER tag
664 list of UIDs
666 The VANISHED response reports that the specified UIDs have been
667 permanently removed from the mailbox. This response is similar to
668 the EXPUNGE response [RFC3501]; however, it can return information
669 about multiple messages, and it returns UIDs instead of message
674 Melnikov, et al. Standards Track [Page 12]
676 RFC 5162 IMAP Quick Mailbox Resync March 2008
679 numbers. The first benefit saves bandwidth, while the second is more
680 convenient for clients that only use UIDs to access the IMAP server.
682 The VANISHED response has the same restrictions on when it can be
683 sent as does the EXPUNGE response (see below).
685 The VANISHED response has two forms. The first form contains the
686 EARLIER tag, which signifies that the response was caused by a UID
687 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This
688 response is sent if the UID set parameter to the UID FETCH (VANISHED)
689 command includes UIDs of messages that are no longer in the mailbox.
690 When the client sees a VANISHED EARLIER response, it MUST NOT
691 decrement message sequence numbers for each successive message in the
692 mailbox.
694 The second form doesn't contain the EARLIER tag and is described
695 below. Once a client has issued "ENABLE QRESYNC", the server SHOULD
696 use the VANISHED response without the EARLIER tag instead of the
697 EXPUNGE response. The server SHOULD continue using VANISHED in lieu
698 of EXPUNGE for the duration of the connection. In particular, this
699 affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as
700 well as messages expunged in other connections. Such a VANISHED
701 response MUST NOT contain the EARLIER tag.
703 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
704 or because messages were expunged in other connections (i.e., the
705 VANISHED response without the EARLIER tag) also decrements the number
706 of messages in the mailbox; it is not necessary for the server to
707 send an EXISTS response with the new value. It also decrements
708 message sequence numbers for each successive message in the mailbox
709 (see the example at the end of this section). Note that a VANISHED
710 response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
711 other connections SHOULD only contain UIDs for messages expunged
712 since the last VANISHED/EXPUNGE response sent for the currently
713 opened mailbox or since the mailbox was opened. That is, servers
714 SHOULD NOT send UIDs for previously expunged messages, unless
715 explicitly requested to do so by the UID FETCH (VANISHED) command.
717 Note that client implementors must take care to properly decrement
718 the number of messages in the mailbox even if a server violates this
719 last SHOULD or repeats the same UID multiple times in the returned
720 UID set. In general, this means that a client using this extension
721 should either avoid using message numbers entirely, or have a
722 complete mapping of UIDs to message sequence numbers for the selected
723 mailbox.
730 Melnikov, et al. Standards Track [Page 13]
732 RFC 5162 IMAP Quick Mailbox Resync March 2008
735 Because clients handle the two different forms of the VANISHED
736 response differently, servers MUST NOT report UIDs resulting from a
737 UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same
738 VANISHED response as UIDs of messages expunged now (i.e., messages
739 expunged in other connections). Instead, the server MUST send
740 separate VANISHED responses: one with the EARLIER tag and one
741 without.
743 A VANISHED response MUST NOT be sent when no command is in progress,
744 nor while responding to a FETCH, STORE, or SEARCH command. This rule
745 is necessary to prevent a loss of synchronization of message sequence
746 numbers between client and server. A command is not "in progress"
747 until the complete command has been received; in particular, a
748 command is not "in progress" during the negotiation of command
749 continuation.
751 Note: UID FETCH, UID STORE, and UID SEARCH are different commands
752 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent
753 during a UID command. However, the VANISHED response MUST NOT be
754 sent during a UID SEARCH command that contains message numbers in the
755 search criteria.
757 The update from the VANISHED response MUST be recorded by the client.
759 Example: Let's assume that there is the following mapping between
760 message numbers and UIDs in the currently selected mailbox (here "X"
761 marks messages with the \Deleted flag set, and "x" represents UIDs
762 which are not relevant for the example):
764 Message numbers: 1 2 3 4 5 6 7 8 9 10 11
765 UIDs: x 504 505 507 508 x 510 x x x 625
766 \Deleted messages: X X X X
768 In the presence of the extension defined in this document:
770 C: A202 EXPUNGE
771 S: * VANISHED 505,507,510,625
772 S: A202 OK EXPUNGE completed
774 Without the QRESYNC extension, the same example might look like:
776 C: A202 EXPUNGE
777 S: * 3 EXPUNGE
778 S: * 3 EXPUNGE
779 S: * 5 EXPUNGE
780 S: * 8 EXPUNGE
781 S: A202 OK EXPUNGE completed
786 Melnikov, et al. Standards Track [Page 14]
788 RFC 5162 IMAP Quick Mailbox Resync March 2008
791 (Continuing previous example) If subsequently messages with UIDs 504
792 and 508 got marked as \Deleted:
794 C: A210 EXPUNGE
795 S: * VANISHED 504,508
796 S: A210 OK EXPUNGE completed
798 i.e., the last VANISHED response only contains UIDs of messages
799 expunged since the previous VANISHED response.
801 3.7. CLOSED Response Code
803 The CLOSED response code has no parameters. A server implementing
804 the extension defined in this document MUST return the CLOSED
805 response code when the currently selected mailbox is closed
806 implicitly using the SELECT/EXAMINE command on another mailbox. The
807 CLOSED response code serves as a boundary between responses for the
808 previously opened mailbox (which was closed) and the newly selected
809 mailbox: all responses before the CLOSED response code relate to the
810 mailbox that was closed, and all subsequent responses relate to the
811 newly opened mailbox.
813 There is no need to return the CLOSED response code on completion of
814 the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose
815 purpose is to close the currently selected mailbox without opening a
816 new one.
818 4. Server Implementation Considerations
820 This section describes a minimalist implementation, a moderate
821 implementation, and an example of a full implementation.
823 4.1. Server Implementations That Don't Store Extra State
825 Strictly speaking, a server implementation that doesn't remember mod-
826 sequences associated with expunged messages can be considered
827 compliant with this specification. Such implementations return all
828 expunged messages specified in the UID set of the UID FETCH
829 (VANISHED) command every time, without paying attention to the
830 specified CHANGEDSINCE mod-sequence. Such implementations are
831 discouraged, as they can end up returning VANISHED responses that are
832 bigger than the result of a UID SEARCH command for the same UID set.
834 Clients that use the message sequence match data can reduce the scope
835 of this VANISHED response substantially in the typical case where
836 expunges have not happened, or happen only toward the end of the
837 mailbox.
842 Melnikov, et al. Standards Track [Page 15]
844 RFC 5162 IMAP Quick Mailbox Resync March 2008
847 4.2. Server Implementations Storing Minimal State
849 A server that stores the HIGHESTMODSEQ value at the time of the last
850 EXPUNGE can omit the VANISHED response when a client provides a
851 MODSEQ value that is equal to, or higher than, the current value of
852 this datum, that is, when there have been no EXPUNGEs.
854 A client providing message sequence match data can reduce the scope
855 as above. In the case where there have been no expunges, the server
856 can ignore this data.
858 4.3. Additional State Required on the Server
860 When compared to the [CONDSTORE] extension, this extension requires
861 servers to store additional state associated with expunged messages.
862 Note that implementations are not required to store this state in
863 persistent storage; however, use of persistent storage is advisable.
865 One possible way to correctly implement the extension described in
866 this document is to store a queue of <UID set, mod-sequence> pairs.
867 <UID set> can be represented as a sequence of <min UID, max UID>
868 pairs.
870 When messages are expunged, one or more entries are added to the
871 queue tail.
873 When the server receives a request to return messages expunged since
874 a given mod-sequence, it will search the queue from the tail (i.e.,
875 going from the highest expunged mod-sequence to the lowest) until it
876 sees the first record with a mod-sequence less than or equal to the
877 given mod-sequence or it reaches the head of the queue.
879 Note that indefinitely storing information about expunged messages
880 can cause storage and related problems for an implementation. In the
881 worst case, this could result in almost 64Gb of storage for each IMAP
882 mailbox. For example, consider an implementation that stores <min
883 UID, max UID, mod-sequence> triples for each range of messages
884 expunged at the same time. Each triple requires 16 octets: 4 octets
885 for each of the two UIDs, and 8 octets for the mod-sequence. Assume
886 that there is a mailbox containing a single message with a UID of
887 2**32-1 (the maximum possible UID value), where messages had
888 previously existed with UIDs starting at 1, and have been expunged
889 one at a time. For this mailbox alone, storage is required for the
890 triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2,
891 modseq4294967294>.
898 Melnikov, et al. Standards Track [Page 16]
900 RFC 5162 IMAP Quick Mailbox Resync March 2008
903 Hence, implementations are encouraged to adopt strategies to protect
904 against such storage problems, such as limiting the size of the queue
905 used to store mod-sequences for expunged messages and "expiring"
906 older records when this limit is reached. When the selected
907 implementation-specific queue limit is reached, the oldest record(s)
908 are deleted from the queue (note that such records are located at the
909 queue head). For all such "expired" records, the server needs to
910 store a single mod-sequence, which is the highest mod-sequence for
911 all "expired" expunged messages.
913 Note that if the client provides the message sequence match data,
914 this can heavily reduce the data cost of sending a complete set of
915 missing UIDs; thus, reducing the problems for clients if a server is
916 unable to persist much of this queue. If the queue contains data
917 back to the requested mod-sequence, this data can be ignored.
919 Also, note that if the UIDVALIDITY of the mailbox changes or if the
920 mailbox is deleted, then any state associated with expunged messages
921 doesn't need to be preserved and SHOULD be deleted.
923 5. Updated Synchronization Sequence
925 This section updates the description of optimized synchronization in
926 Section 6.1 of the [IMAP-DISC].
928 An advanced disconnected mail client should use the QRESYNC and
929 [CONDSTORE] extensions when they are supported by the server. The
930 client uses the value from the HIGHESTMODSEQ OK response code
931 received on mailbox opening to determine if it needs to
932 resynchronize. Once the synchronization is complete, it MUST cache
933 the received value (unless the mailbox UIDVALIDITY value has changed;
934 see below). The client MUST update its copy of the HIGHESTMODSEQ
935 value whenever the server sends a subsequent HIGHESTMODSEQ OK
936 response code.
938 After completing a full synchronization, the client MUST also take
939 note of any unsolicited MODSEQ FETCH data items received from the
940 server. Whenever the client receives a tagged response to a command,
941 it calculates the highest value among all MODSEQ FETCH data items
942 received since the last tagged response. If this value is bigger
943 than the client's copy of the HIGHESTMODSEQ value, then the client
944 MUST use this value as its new HIGHESTMODSEQ value.
946 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
947 value with a MODSEQ FETCH data item value as soon as it is received
948 because servers are not required to send MODSEQ FETCH data items in
949 increasing modseqence order. This can lead to the client missing
950 some changes in case of connectivity loss.
954 Melnikov, et al. Standards Track [Page 17]
956 RFC 5162 IMAP Quick Mailbox Resync March 2008
959 When opening the mailbox for synchronization, the client uses the
960 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC
961 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ
962 values, as known to the client. It can be optionally followed by the
963 set of UIDs, for example, if the client is only interested in partial
964 synchronization of the mailbox. The client may also transmit a list
965 containing its knowledge of message numbers.
967 If the SELECT/EXAMINE command is successful, the client compares
968 UIDVALIDITY as described in step d)1) in Section 3 of the
969 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one
970 returned by the server and the server also returns the HIGHESTMODSEQ
971 response code, then the server reports expunged messages and returns
972 flag changes for all messages specified by the client in the UID set
973 parameter (or for all messages in the mailbox, if the client omitted
974 the UID set parameter). At this point, the client is synchronized,
975 except for maybe the new messages.
977 If upon a successful SELECT/EXAMINE (QRESYNC) command the client
978 receives a NOMODSEQ OK untagged response (instead of the
979 HIGHESTMODSEQ response code), it MUST remove the last known
980 HIGHESTMODSEQ value from its cache and follow the more general
981 instructions in Section 3 of the [IMAP-DISC].
983 At this point, the client is in sync with the server regarding old
984 messages. This client can now fetch information about new messages
985 (if requested by the user).
987 Step d) ("Server-to-client synchronization") in Section 4 of the
988 [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is
989 amended as follows:
991 d) "Server-to-client synchronization" -- for each mailbox that
992 requires synchronization, do the following:
994 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC]
995 for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
997 If the UIDVALIDITY value returned by the server differs, the
998 client MUST
1000 * empty the local cache of that mailbox;
1002 * "forget" the cached HIGHESTMODSEQ value for the mailbox;
1010 Melnikov, et al. Standards Track [Page 18]
1012 RFC 5162 IMAP Quick Mailbox Resync March 2008
1015 * remove any pending "actions" which refer to UIDs in that
1016 mailbox. Note, this doesn't affect actions performed on
1017 client generated fake UIDs (see Section 5 of the
1018 [IMAP-DISC]);
1020 2) Fetch the current "descriptors";
1022 I) Discover new messages.
1024 3) Fetch the bodies of any "interesting" messages that the client
1025 doesn't already have.
1027 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ
1028 value has changed on the server while the client was
1029 offline:
1031 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
1032 S: * 172 EXISTS
1033 S: * 1 RECENT
1034 S: * OK [UNSEEN 12] Message 12 is first unseen
1035 S: * OK [UIDVALIDITY 3857529045] UIDs valid
1036 S: * OK [UIDNEXT 201] Predicted next UID
1037 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1038 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
1039 S: * OK [HIGHESTMODSEQ 20010715194045007]
1040 S: * VANISHED (EARLIER) 1:5,7:8,10:15
1041 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
1042 FLAGS (\Deleted))
1043 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
1044 FLAGS ($NoJunk $AutoJunk $MDNSent))
1045 ...
1046 S: A142 OK [READ-WRITE] SELECT completed
1048 6. Formal Syntax
1050 The following syntax specification uses the Augmented Backus-Naur
1051 Form (ABNF) notation as specified in [ABNF].
1053 Non-terminals referenced but not defined below are as defined by
1054 [RFC3501], [CONDSTORE], or [IMAPABNF].
1056 Except as noted otherwise, all alphabetic characters are case-
1057 insensitive. The use of upper or lower case characters to define
1058 token strings is for editorial clarity only. Implementations MUST
1059 accept these strings in a case-insensitive fashion.
1066 Melnikov, et al. Standards Track [Page 19]
1068 RFC 5162 IMAP Quick Mailbox Resync March 2008
1071 capability =/ "QRESYNC"
1073 select-param = "QRESYNC" SP "(" uidvalidity SP
1074 mod-sequence-value [SP known-uids]
1075 [SP seq-match-data] ")"
1076 ;; conforms to the generic select-param
1077 ;; syntax defined in [IMAPABNF]
1079 seq-match-data = "(" known-sequence-set SP known-uid-set ")"
1081 uidvalidity = nz-number
1083 known-uids = sequence-set
1084 ;; sequence of UIDs, "*" is not allowed
1086 known-sequence-set = sequence-set
1087 ;; set of message numbers corresponding to
1088 ;; the UIDs in known-uid-set, in ascending order.
1089 ;; * is not allowed.
1091 known-uid-set = sequence-set
1092 ;; set of UIDs corresponding to the messages in
1093 ;; known-sequence-set, in ascending order.
1094 ;; * is not allowed.
1096 message-data =/ expunged-resp
1098 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
1100 rexpunges-fetch-mod = "VANISHED"
1101 ;; VANISHED UID FETCH modifier conforms
1102 ;; to the fetch-modifier syntax
1103 ;; defined in [IMAPABNF]. It is only
1104 ;; allowed in the UID FETCH command.
1106 resp-text-code =/ "CLOSED"
1108 7. Security Considerations
1110 As always, it is important to thoroughly test clients and servers
1111 implementing this extension, as it changes how the server reports
1112 expunged messages to the client.
1114 Security considerations relevant to [CONDSTORE] are relevant to this
1115 extension.
1117 This document doesn't raise any new security concerns not already
1118 raised by [CONDSTORE] or [RFC3501].
1122 Melnikov, et al. Standards Track [Page 20]
1124 RFC 5162 IMAP Quick Mailbox Resync March 2008
1127 8. IANA Considerations
1129 IMAP4 capabilities are registered by publishing a standards track or
1130 IESG approved experimental RFC. The registry is currently located
1131 at:
1133 http://www.iana.org/assignments/imap4-capabilities
1135 This document defines the QRESYNC IMAP capability. IANA has added
1136 this capability to the registry.
1138 9. Acknowledgments
1140 Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging
1141 creation of this document.
1143 Valuable comments, both in agreement and in dissent, were received
1144 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen,
1145 Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp,
1146 Eric Rescorla, and Mike Zraly.
1148 This document takes substantial text from [RFC3501] by Mark Crispin.
1150 10. References
1152 10.1. Normative References
1154 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1155 Specifications: ABNF", STD 68, RFC 5234, January 2008.
1157 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for
1158 Conditional STORE Operation or Quick Flag Changes
1159 Resynchronization", RFC 4551, June 2006.
1161 [ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
1162 ENABLE Extension", RFC 5161, March 2008.
1164 [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
1165 IMAP4 ABNF", RFC 4466, April 2006.
1167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1168 Requirement Levels", BCP 14, RFC 2119, March 1997.
1170 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1171 4rev1", RFC 3501, March 2003.
1173 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
1174 UIDPLUS extension", RFC 4315, December 2005.
1178 Melnikov, et al. Standards Track [Page 21]
1180 RFC 5162 IMAP Quick Mailbox Resync March 2008
1183 10.2. Informative References
1185 [IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations For
1186 Disconnected Imap4 Clients", RFC 4549, June 2006.
1188 [UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP)
1189 UNSELECT command", RFC 3691, February 2004.
1191 Authors' Addresses
1193 Alexey Melnikov
1194 Isode Ltd
1195 5 Castle Business Village
1196 36 Station Road
1197 Hampton, Middlesex TW12 2BX
1198 UK
1200 EMail: Alexey.Melnikov@isode.com
1203 Dave Cridland
1204 Isode Ltd
1205 5 Castle Business Village
1206 36 Station Road
1207 Hampton, Middlesex TW12 2BX
1208 UK
1210 EMail: dave.cridland@isode.com
1213 Corby Wilson
1214 Nokia
1215 5 Wayside Rd.
1216 Burlington, MA 01803
1217 USA
1219 EMail: corby@computer.org
1234 Melnikov, et al. Standards Track [Page 22]
1236 RFC 5162 IMAP Quick Mailbox Resync March 2008
1239 Full Copyright Statement
1241 Copyright (C) The IETF Trust (2008).
1243 This document is subject to the rights, licenses and restrictions
1244 contained in BCP 78, and except as set forth therein, the authors
1245 retain all their rights.
1247 This document and the information contained herein are provided on an
1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1250 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1251 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1255 Intellectual Property
1257 The IETF takes no position regarding the validity or scope of any
1258 Intellectual Property Rights or other rights that might be claimed to
1259 pertain to the implementation or use of the technology described in
1260 this document or the extent to which any license under such rights
1261 might or might not be available; nor does it represent that it has
1262 made any independent effort to identify any such rights. Information
1263 on the procedures with respect to rights in RFC documents can be
1264 found in BCP 78 and BCP 79.
1266 Copies of IPR disclosures made to the IETF Secretariat and any
1267 assurances of licenses to be made available, or the result of an
1268 attempt made to obtain a general license or permission for the use of
1269 such proprietary rights by implementers or users of this
1270 specification can be obtained from the IETF on-line IPR repository at
1271 http://www.ietf.org/ipr.
1273 The IETF invites any interested party to bring to its attention any
1274 copyrights, patents or patent applications, or other proprietary
1275 rights that may cover technology that may be required to implement
1276 this standard. Please address the information to the IETF at
1277 ietf-ipr@ietf.org.
1290 Melnikov, et al. Standards Track [Page 23]