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
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Network Working Group D. Cridland
Request for Comments: 5267 C. King
Category: Standards Track Isode Limited
July 2008
<span class="h1">Contexts for IMAP4</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The IMAP4rev1 protocol has powerful search facilities as part of the
core protocol, but lacks the ability to create live, updated results
that can be easily handled. This memo provides such an extension,
and shows how it can be used to provide a facility similar to virtual
mailboxes.
<span class="grey">Cridland & King Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Extended Sort Syntax . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. ESORT Extension . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Ranges in Extended Sort Results . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Extended SORT Example . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Context Hint . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Notifications of Changes . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3.1">4.3.1</a>. Refusing to Update Contexts . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.3.2">4.3.2</a>. Common Features of ADDTO and REMOVEFROM . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3.3">4.3.3</a>. ADDTO Return Data Item . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3.4">4.3.4</a>. REMOVEFROM Return Data Item . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.3.5">4.3.5</a>. The CANCELUPDATE Command . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Partial Results . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.5">4.5</a>. Caching Results . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5">5</a>. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A">Appendix A</a>. Cookbook . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.1">A.1</a>. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.2">A.2</a>. Trash Mailboxes . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.3">A.3</a>. Immediate EXPUNGE Notifications . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.4">A.4</a>. Monitoring Counts . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.5">A.5</a>. Resynchronizing Contexts . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-B">Appendix B</a>. Server Implementation Notes . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="grey">Cridland & King Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Although the basic SEARCH command defined in [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>], and as enhanced
by [<a href="#ref-ESEARCH" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">ESEARCH</a>], is relatively compact in its representation, this
reduction saves only a certain amount of data, and huge mailboxes
might overwhelm the storage available for results on even relatively
high-end desktop machines.
The SORT command defined in [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>] provides useful features, but is
hard to use effectively on changing mailboxes over low-bandwidth
connections.
This memo borrows concepts from [<a href="#ref-ACAP" title=""ACAP -- Application Configuration Access Protocol"">ACAP</a>], such as providing a windowed
view onto search or sort results, and making updates that are
bandwidth and round-trip efficient. These are provided by two
extensions: "ESORT" and "CONTEXT".
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
In examples, "C:" and "S:" indicate lines sent by the client
messaging user agent and IMAP4rev1 ([<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]) server, respectively.
"//" indicates inline comments not part of the protocol exchange.
Line breaks are liberally inserted for clarity. Examples are
intended to be read in order, such that the state remains from one
example to the next.
Although the examples show a server that supports [<a href="#ref-ESEARCH" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">ESEARCH</a>], this is
not a strict requirement of this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
Other capitalized words are typically names of IMAP extensions or
commands -- these are uppercased for clarity only, and are case-
insensitive.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Extended Sort Syntax</span>
Servers implementing the extended SORT provide a suite of extensions
to the SORT and UID SORT commands defined in [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>]. This allows for
return options, as used with SEARCH and specified in [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>], to
be used with SORT in a similar manner.
The SORT and UID SORT commands are extended by the addition of an
optional list of return options that follow a RETURN atom immediately
after the command. If this is missing, the server will return
results as specified in [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>].
<span class="grey">Cridland & King Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
The extended SORT command always returns results in the requested
sort order, but is otherwise identical in its behaviour to the
extended SEARCH command defined in [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>], as extended by
[<a href="#ref-ESEARCH" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">ESEARCH</a>]. In particular, the extended SORT command returns results
in an ESEARCH response.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. ESORT Extension</span>
Servers advertising the capability "ESORT" support the return options
specified in [<a href="#ref-ESEARCH" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">ESEARCH</a>] in the SORT command. These return options are
adapted as follows:
MIN
Return the message number/UID of the lowest sorted message
satisfying the search criteria.
MAX
Return the message number/UID of the highest sorted message
satisfying the search criteria.
ALL
Return all message numbers/UIDs which match the search criteria,
in the requested sort order, using a sequence-set. Note the use
of ranges described below in <a href="#section-3.2">Section 3.2</a>.
COUNT
As in [<a href="#ref-ESEARCH" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">ESEARCH</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Ranges in Extended Sort Results</span>
Any ranges given by the server, including those given as part of the
sequence-set, in an ESEARCH response resulting from an extended SORT
or UID SORT command, MUST be ordered in increasing numerical order
after expansion, as per usual [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>] rules.
In particular this means that 10:12 is equivalent to 12:10, and
10,11,12. To avoid confusion, servers SHOULD present ranges only
when the first seq-number is lower than the second; that is, either
of the forms 10:12 or 10,11,12 is acceptable, but 12:10 SHOULD be
avoided.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Extended SORT Example</span>
If the list of return options is present but empty, then the server
provides the ALL return data item in an ESEARCH response. This is
functionally equivalent to an unextended UID SORT command, but can
use a smaller representation:
<span class="grey">Cridland & King Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
C: E01 UID SORT RETURN () (REVERSE DATE) UTF-8 UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "E01") UID ALL 23765,23764,23763,23761,[<a href="#ref-...">...</a>]
S: E01 OK Sort completed
Note that the initial three results are not represented as the range
23765:23763 as mandated in <a href="#section-3.2">Section 3.2</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Contexts</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Overview</span>
The Contexts extension is present in any IMAP4rev1 server that
includes the string "CONTEXT=SEARCH", and/or "CONTEXT=SORT", within
its advertised capabilities.
In the case of CONTEXT=SEARCH, the server supports the extended
SEARCH command syntax described in [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>], and accepts three
additional return options.
Servers advertising CONTEXT=SORT also advertise the SORT capability,
as described in [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>], support the extended SORT command syntax
described in <a href="#section-3">Section 3</a>, and accept three additional return options
for this extended SORT.
These additional return options allow for notifications of changes to
the results of SEARCH or SORT commands, and also allow for access to
partial results.
A server advertising the CONTEXT=SEARCH extension will order all
SEARCH results, whether from a UID SEARCH or SEARCH command, in
mailbox order -- that is, by message number and UID. Therefore, the
UID SEARCH, SEARCH, UID SORT, or SORT command used -- collectively
known as the searching command -- will always have an order, the
requested order, which will be the mailbox order for UID SEARCH and
SEARCH commands.
All of the return specifiers have no interaction with either each
other or any return specifiers defined in [<a href="#ref-ESEARCH" title=""IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned"">ESEARCH</a>] or <a href="#section-3.1">Section 3.1</a>;
however, it is believed that implementations supporting CONTEXT will
also support ESEARCH and ESORT.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Context Hint</span>
The return option CONTEXT SHOULD be used by a client to indicate that
subsequent use of the search criteria are likely. Servers MAY ignore
this return option or use it as a hint to maintain a full result
cache, or index.
<span class="grey">Cridland & King Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
A client might choose to obtain a count of matching messages prior to
obtaining actual results. Here, the client signals its intention to
fetch the results themselves:
C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A01") COUNT 23765
S: A01 OK Search completed.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Notifications of Changes</span>
The search return option UPDATE, if used by a client, causes the
server to issue unsolicited notifications containing updates to the
results that would be returned by an unmodified searching command.
These update sets are carried in ADDTO and REMOVEFROM data items in
ESEARCH responses.
These ESEARCH responses carry a search correlator of the searching
command, hence clients MUST NOT reuse tags, as already specified in
Section 2.2.1 of [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]. An attempt to use UPDATE where a tag is
already in use with a previous searching command that itself used
UPDATE SHALL result in the server rejecting the searching command
with a BAD response.
Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients
in a timely manner, as and when results change, whether by new
messages arriving in the mailbox, metadata such as flags being
changed, or messages being expunged.
Typically, this would occur at the same time as the FETCH, EXISTS, or
EXPUNGE responses carrying the source of the change.
Updates will cease when the mailbox is no longer selected, or when
the CANCELUPDATE command, defined in <a href="#section-4.3.5">Section 4.3.5</a>, is issued by the
client, whichever is sooner.
Unlike [<a href="#ref-ACAP" title=""ACAP -- Application Configuration Access Protocol"">ACAP</a>], there is no requirement that a context need be created
with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with
a CONTEXT does not affect the results caused by later searching
commands -- there is no snapshot facility.
There is no interaction between UPDATE and any other return options;
therefore, use of RETURN (UPDATE MIN), for example, does not notify
about the minimum UID or sequence number, but notifies instead about
all changes to the set of matching messages. In particular, this
means that a client using UPDATE and PARTIAL on the same search
program could receive notifications about messages that do not
currently interest it.
<span class="grey">Cridland & King Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Finally, as specified in the errata to [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>], any message sequence
numbers used in the search program are evaluated at the time the
command is received; therefore, if the messages referred to by such
message sequence numbers change, no notifications will be emitted.
This time, the client will require notifications of updates and
chooses to obtain a count:
C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED
KEYWORD $Junk
S: * ESEARCH (TAG "B01") COUNT 74
S: B01 OK Search completed, will notify.
// Note that the following is rejected, and has no effect:
C: B01 SORT RETURN (UPDATE) FLAGGED
S: B01 BAD Tag reuse
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Refusing to Update Contexts</span>
In some cases, the server MAY refuse to provide updates, such as if
an internal limit on the number of update contexts is reached. In
such a case, an untagged NO is generated during processing of the
command with a response-code of NOUPDATE. The response-code
contains, as argument, the tag of the search command for which the
server is refusing to honour the UPDATE request.
Other return options specified SHALL still be honoured.
Servers MUST provide at least one updating context per client, and
SHOULD provide more -- see <a href="#appendix-B">Appendix B</a> for strategies on reducing the
impact of additional updating contexts. Since sorted contexts
require a higher implementation cost than unsorted contexts, refusal
to provide updates for a SORT command does not imply that SEARCH
contexts will also be refused.
This time, the client will require notifications of updates, and
chooses to obtain a count:
C: B02 UID SORT RETURN (UPDATE COUNT) UTF-8
KEYWORD $Junk
S: * ESEARCH (TAG "B02") COUNT 74
S: * NO [NOUPDATE "B02"] Too many contexts
S: B02 OK Search completed, will not notify.
Client handling might be to retry with a UID SEARCH command, or else
cancel an existing context; see <a href="#section-4.3.5">Section 4.3.5</a>.
<span class="grey">Cridland & King Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Common Features of ADDTO and REMOVEFROM</span>
The result update set included in the return data item is specified
as UIDs or message numbers, depending on how the UPDATE was
specified. If the UPDATE was present in a SEARCH or SORT command,
the results will be message numbers; in a UID SEARCH or UID SORT
command, they will be UIDs.
The client MUST process ADDTO and REMOVEFROM return data items in the
order they appear, including those within a single ESEARCH response.
Correspondingly, servers MUST generate ADDTO and REMOVEFROM responses
such that the results are maintained in the requested order.
As with any response aside from EXPUNGE, ESEARCH responses carrying
ADDTO and/or REMOVEFROM return data items MAY be sent at any time.
In particular, servers MAY send such responses when no command is in
progress, during the processing of any command, or when the client is
using the IDLE facility described in [<a href="#ref-IDLE" title=""IMAP4 IDLE command"">IDLE</a>]. Implementors are
recommended to read [<a href="#ref-NOTIFY" title=""The IMAP NOTIFY Extension"">NOTIFY</a>] as a mechanism for clients to signal
servers that they are willing to process responses at any time, and
are also recommended to pay close attention to Section 5.3 of [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>].
It is anticipated that typical server implementations will emit ADDTO
when they normally emit the causal FETCH or EXISTS, and similarly
emit REMOVEFROM when they normally emit the causal FETCH or EXPUNGE.
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. ADDTO Return Data Item</span>
The ADDTO return data item contains, as payload, a list containing
pairs of a context position and a set of result updates in the
requested order to be inserted at the context position. Where the
searching command is a SEARCH or UID SEARCH command, the context
position MAY be zero. Each pair is processed in the order that it
appears.
Note that an ADDTO containing message sequence numbers added as a
result of those messages being delivered or appended MUST be sent
after the EXISTS notification itself, in order that those sequence
numbers are valid.
If the context position is non-zero, the result update is inserted at
the given context position, meaning that the first result in the set
will occupy the new context position after insertion, and any prior
existing result at that context position will be shifted to a later
context position.
<span class="grey">Cridland & King Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Where the context position is zero, the client MAY insert the message
numbers or UIDs in the result list such that the result list is
maintained in mailbox order. In this case, servers are RECOMMENDED
to order the result update into mailbox order to produce the shortest
representation in set-syntax.
[<a id="ref-...">...</a>]
S: * 23762 FETCH (FLAGS (\Deleted \Seen))
S: * 23763 FETCH (FLAGS ($Junk \Seen))
S: * ESEARCH (TAG "B01") UID ADDTO (0 32768:32769)
Note that this example assumes messages 23762 and 23763 with UIDs
32768 and 32769 (respectively) previously had neither \Deleted nor
$Junk set. Also note that only the ADDTO is included, and not the
(now changed) COUNT.
If the searching command "C01" initially generated a result list of
2734:2735, then the following three responses are equivalent, and
yield a result list of 2731:2735:
[<a id="ref-...">...</a>]
S: * ESEARCH (TAG "C01") UID ADDTO (1 2733 1 2732 1 2731)
S: * ESEARCH (TAG "C01") UID ADDTO (1 2733) ADDTO (1 2731:2732)
S: * ESEARCH (TAG "C01") UID ADDTO (1 2731:2733)
The last is the preferred representation.
<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>. REMOVEFROM Return Data Item</span>
The REMOVEFROM return data item contains, as payload, a list
containing pairs of a context position and a set of result updates in
the requested order to be removed starting from the context position.
Where the searching command is a SEARCH or UID SEARCH command, the
context position MAY be zero. Each pair is processed in the order
that it appears.
If the context position is non-zero, the results are removed at the
given context position, meaning that the first result in the set will
occupy the given context position before removal, and any prior
existing result at that context position will be shifted to an
earlier context position.
Where the context position is zero, the client removes the message
numbers or UIDs in the result list wherever they occur, and servers
are RECOMMENDED to order the result list in mailbox order to obtain
the best benefit from the set-syntax.
<span class="grey">Cridland & King Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Note that a REMOVEFROM containing message sequence numbers removed as
a result of those messages being expunged MUST be sent prior to the
expunge notification itself, in order that those sequence numbers
remain valid.
Here, a message in the result list is expunged. The REMOVEFROM is
shown to happen without any command in progress; see <a href="#section-4.3.2">Section 4.3.2</a>.
Note that EXPUNGE responses do not have this property.
[<a id="ref-...">...</a>]
S: * ESEARCH (TAG "B01") UID REMOVEFROM (0 32768)
C: B03 NOOP
S: * 23762 EXPUNGE
S: B03 OK Nothing done.
<span class="h4"><a class="selflink" id="section-4.3.5" href="#section-4.3.5">4.3.5</a>. The CANCELUPDATE Command</span>
When a client no longer wishes to receive updates, it may issue the
CANCELUPDATE command, which will prevent all updates to the contexts
named in the arguments from being transmitted by the server. The
command takes, as arguments, one or more tags of the commands used to
request updates.
The server MAY free any resource associated with a context so
disabled -- however, the client is free to issue further searching
commands with the same criteria and requested order, including
PARTIAL requests.
C: B04 CANCELUPDATE "B01"
S: B04 OK No further updates.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Partial Results</span>
The PARTIAL search return option causes the server to provide in an
ESEARCH response a subset of the results denoted by the sequence
range given as the mandatory argument. The first result is 1; thus,
the first 500 results would be obtained by a return option of
"PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This
intentionally mirrors message sequence numbers.
A single command MUST NOT contain more than one PARTIAL or ALL search
return option -- that is, either one PARTIAL, one ALL, or neither
PARTIAL nor ALL is allowed.
For SEARCH results, the entire result list MUST be ordered in mailbox
order, that is, in UID or message sequence number order.
<span class="grey">Cridland & King Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Where a PARTIAL search return option references results that do not
exist, by using a range which starts or ends higher than the current
number of results, then the server returns the results that are in
the set. This yields a PARTIAL return data item that has, as
payload, the original range and a potentially missing set of results
that may be shorter than the extent of the range.
Clients need not request PARTIAL results in any particular order.
Because mailboxes may change, clients will often wish to use PARTIAL
in combination with UPDATE, especially if the intent is to walk a
large set of results; however, these return options do not interact
-- the UPDATE will provide notifications for all matching results.
// Recall from A01 that there are 23764 results.
C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED
UNKEYWORD $Junk
C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED
UNKEYWORD $Junk
C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...)
// 264 results in set syntax elided,
// this spans the end of the results.
S: A02 OK Completed.
S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...)
// 500 results in set syntax elided.
S: A03 OK Completed.
S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL)
// No results are present, this is beyond the end of the results.
S: A04 OK Completed.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Caching Results</span>
Server implementations MAY cache results from a SEARCH or SORT,
whether or not hinted to by CONTEXT, in order to make subsequent
searches more efficient, perhaps by recommencing a subsequent PARTIAL
search where a previous search left off. However, servers MUST
behave identically whether or not internal caching is taking place;
therefore, any such cache is required to be updated as changes to the
mailbox occur. An alternate strategy would be to discard results
when any change occurs to the mailbox.
<span class="grey">Cridland & King Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Formal Syntax</span>
The collected formal syntax. This uses ABNF as defined in [<a href="#ref-ABNF" title=""Augmented BNF for Syntax Specifications: ABNF"">ABNF</a>].
It includes definitions from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>], [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>], and [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>].
capability =/ "CONTEXT=SEARCH" / "CONTEXT=SORT" / "ESORT"
;; <capability> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
command-select =/ "CANCELUPDATE" 1*(SP quoted)
;; <command-select> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
context-position = number
;; Context position may be 0 for SEARCH result additions.
;; <number> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
modifier-context = "CONTEXT"
modifier-partial = "PARTIAL" SP partial-range
partial-range = nz-number ":" nz-number
;; A range 500:400 is the same as 400:500.
;; This is similar to <seq-range> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>],
;; but cannot contain "*".
modifier-update = "UPDATE"
search-return-opt =/ modifier-context / modifier-partial /
modifier-update
;; All conform to <search-return-opt>, from [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>]
resp-text-code =/ "NOUPDATE" SP quoted
;; <resp-text-code> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
ret-data-addto = "ADDTO"
SP "(" context-position SP sequence-set
*(SP context-position SP sequence-set)
")"
;; <sequence-set> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
ret-data-partial = "PARTIAL"
SP "(" partial-range SP partial-results ")"
;; <partial-range> is the requested range.
partial-results = sequence-set / "NIL"
;; <sequence-set> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
;; NIL indicates no results correspond to the requested range.
<span class="grey">Cridland & King Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
ret-data-removefrom = "REMOVEFROM"
SP "(" context-position SP sequence-set
*(SP context-position SP sequence-set)
")"
;; <sequence-set> from [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>]
search-return-data =/ ret-data-partial / ret-data-addto /
ret-data-removefrom
;; All conform to <search-return-data>, from [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>]
sort =/ extended-sort
;; <sort> from [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>]
extended-sort = ["UID" SP] "SORT" search-return-opts
SP sort-criteria SP search-criteria
;; <search-return-opts> from [<a href="#ref-IMAP-ABNF" title=""Collected Extensions to IMAP4 ABNF"">IMAP-ABNF</a>]
;; <sort-criteria> and <search-criteria> from [<a href="#ref-SORT" title=""Internet Message Access Protocol - SORT and THREAD Extensions"">SORT</a>]
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document defines additional IMAP4 capabilities. As such, it
does not change the underlying security considerations of [<a href="#ref-IMAP" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">IMAP</a>].
The authors and reviewers believe that no new security issues are
introduced with these additional IMAP4 capabilities.
Creation of a large number of contexts may provide an avenue for
denial-of-service attacks by authorized users. Implementors may
reduce this by limiting the number of contexts possible to create,
via the protocol features described in <a href="#section-4.3.1">Section 4.3.1</a>; by reducing the
impact of contexts by the implementation strategies described in
<a href="#appendix-B">Appendix B</a>; and by logging context creation and usage so that
administrative remedies may be applied.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IMAP4 capabilities are registered by publishing a Standards Track or
IESG-approved Experimental RFC.
This document defines the ESORT, CONTEXT=SEARCH, and CONTEXT=SORT
IMAP capabilities. IANA has added them to the registry accordingly.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Much of the design of this extension can be found in ACAP. Valuable
comments, both in agreement and in dissent, were received from Alexey
Melnikov, Arnt Gulbrandsen, Cyrus Daboo, Filip Navara, Mark Crispin,
Peter Coates, Philip Van Hoof, Randall Gellens, Timo Sirainen, Zoltan
<span class="grey">Cridland & King Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Ordogh, and others, and many of these comments have had significant
influence on the design or the text. The authors are grateful to all
those involved, including those not mentioned here.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-ABNF">ABNF</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-ESEARCH">ESEARCH</a>] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", <a href="./rfc4731">RFC 4731</a>, November 2006.
[<a id="ref-IMAP">IMAP</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003.
[<a id="ref-IMAP-ABNF">IMAP-ABNF</a>] Melnikov, A. and C. Daboo, "Collected Extensions to
IMAP4 ABNF", <a href="./rfc4466">RFC 4466</a>, April 2006.
[<a id="ref-KEYWORDS">KEYWORDS</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>, March 1997.
[<a id="ref-SORT">SORT</a>] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", <a href="./rfc5256">RFC 5256</a>,
June 2008.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-ACAP">ACAP</a>] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", <a href="./rfc2244">RFC 2244</a>, November 1997.
[<a id="ref-IDLE">IDLE</a>] Leiba, B., "IMAP4 IDLE command", <a href="./rfc2177">RFC 2177</a>, June 1997.
[<a id="ref-NOTIFY">NOTIFY</a>] Melnikov, A., Gulbrandsen, A., and C. King, "The IMAP
NOTIFY Extension", Work in Progress, March 2008.
<span class="grey">Cridland & King Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Cookbook</span>
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Virtual Mailboxes</span>
It is possible to use the facilities described within this memo to
create a facility largely similar to a virtual mailbox, but handled
on the client side.
Initially, the client SELECTs the real "backing" mailbox. Next, it
can switch to a filtered view at any time by issuing a RETURN (COUNT
UPDATE CONTEXT), and using RETURN (PARTIAL x:y) as the user scrolls,
feeding the results into a FETCH as required to populate summary
views.
<a href="#appendix-A">A</a> typically useful view is "UID SORT (DATE) RETURN (...) UTF-8
UNSEEN UNDELETED", which can be used to show the mailbox sorted into
INTERNALDATE order, filtered to only show messages which are unread
and not yet deleted.
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Trash Mailboxes</span>
Certain contexts are particularly useful for client developers
wishing to present something similar to the common trash mailbox
metaphor in limited bandwidth. The simple criteria of UNDELETED only
matches undeleted messages, and the corresponding DELETED search key
can be used to display a per-mailbox trash-like virtual mailbox.
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. Immediate EXPUNGE Notifications</span>
The command "SEARCH RETURN (UPDATE) ALL" can be used to create a
context that notifies immediately about expunged messages, yet will
not affect message sequence numbers until the normal EXPUNGE message
can be sent. This may be useful for clients wishing to show this
behavior without losing the benefit of sequence numbering.
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. Monitoring Counts</span>
A client need not maintain any result cache at all, but instead it
can maintain a simple count of messages matching the search criteria.
Typically, this would use the SEARCH command, as opposed to UID
SEARCH, due to its smaller representation. Such usage might prove
useful in monitoring the number of flagged, but unanswered, messages,
for example, with "SEARCH RETURN (UPDATE COUNT) FLAGGED UNANSWERED".
<span class="grey">Cridland & King Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
<span class="h3"><a class="selflink" id="appendix-A.5" href="#appendix-A.5">A.5</a>. Resynchronizing Contexts</span>
The creation of a context, and immediate access to it, can all be
accomplished in a single round-trip. Therefore, whilst it is
possible to elide resynchronization if no changes have occurred, it
is simpler in most cases to resynchronize by simply recreating the
context.
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Server Implementation Notes</span>
Although a server may cache the results, this is neither mandated nor
required, especially when the client uses SEARCH or UID SEARCH
commands. UPDATE processing, for example, can be achieved
efficiently by comparison of the old flag state (if any) and the new,
and PARTIAL can be achieved by re-running the search until the
suitable window is required. This is a result of there being no
snapshot facility.
For example, on a new message, the server can simply test for matches
against all current UPDATE context search programs, and for any that
match, send the ADDTO return data.
Similarly, for a flag change on an existing message, the server can
check whether the message matched with its old flags, whether it
matches with new flags, and provide ADDTO or REMOVEFROM return data
accordingly if these results differ.
For PARTIAL requests, the server can perform a full search,
discarding results until the lower bound is hit, and stopping the
search when sufficient results have been obtained.
With some additional state, it is possible to restart PARTIAL
searches, thus avoiding performing the initial discard phase.
For the best performance, however, caching the full search results is
needed, which can allow for faster responses at the expense of
memory. One reasonable strategy would be to balance this trade-off
at run-time, discarding search results after a suitable timeout, and
regenerating them as required.
This yields state requirements of storing the search program for any
UPDATE contexts, and optionally storing both search program and
(updated) results for further contexts as required.
<span class="grey">Cridland & King Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Note that in the absence of a server-side results cache, it may be
impossible to know if an expunged message previously matched unless
the original message is still available. Therefore, some
implementations may be forced into using a results cache in many
circumstances.
UPDATE contexts created with SORT or UID SORT will almost certainly
require some form of results caching, however.
Authors' Addresses
Dave Cridland
Isode Limited
5 Castle Business Village
36, Station Road
Hampton, Middlesex TW12 2BX
GB
EMail: dave.cridland@isode.com
Curtis King
Isode Limited
5 Castle Business Village
36, Station Road
Hampton, Middlesex TW12 2BX
GB
EMail: cking@mumbo.ca
<span class="grey">Cridland & King Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5267">RFC 5267</a> IMAP CONTEXT July 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Cridland & King Standards Track [Page 18]
</pre>
|
