File: rfc2779.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1459 lines) | stat: -rw-r--r-- 47,420 bytes parent folder | download | duplicates (5)
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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459






Network Working Group                                            M. Day
Request for Comments: 2779                                        Lotus
Category: Informational                                     S. Aggarwal
                                                              Microsoft
                                                                G. Mohr
                                                              Activerse
                                                             J. Vincent
                                                          Into Networks
                                                          February 2000


           Instant Messaging / Presence Protocol Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   Presence and Instant Messaging have recently emerged as a new medium
   of communications over the Internet.  Presence is a means for
   finding, retrieving, and subscribing to changes in the presence
   information (e.g. "online" or "offline") of other users. Instant
   messaging is a means for sending small, simple messages that are
   delivered immediately to online users.

   Applications of presence and instant messaging currently use
   independent, non-standard and non-interoperable protocols developed
   by various vendors.  The goal of the Instant Messaging and Presence
   Protocol (IMPP) Working Group is to define a standard protocol so
   that independently developed applications of instant messaging and/or
   presence can interoperate across the Internet. This document defines
   a minimal set of requirements that IMPP must meet.












Day, et al.                  Informational                      [Page 1]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


Table of Contents

   1. Terminology...................................................  3
   2. Shared Requirements...........................................  4
    2.1. Namespace and Administration...............................  5
    2.2. Scalability................................................  5
    2.3. Access Control.............................................  6
    2.4. Network Topology...........................................  6
    2.5. Message Encryption and Authentication......................  7
   3. Additional Requirements for PRESENCE INFORMATION..............  7
    3.1. Common Presence Format.....................................  7
    3.2. Presence Lookup and Notification...........................  8
    3.3. Presence Caching and Replication...........................  8
    3.4. Performance................................................  9
   4. Additional Requirements for INSTANT MESSAGES..................  9
    4.1. Common Message Format......................................  9
    4.2. Reliability................................................ 10
    4.3. Performance................................................ 10
    4.4. Presence Format............................................ 10
   5. Security Considerations....................................... 11
    5.1. Requirements related to SUBSCRIPTIONS...................... 11
    5.2. Requirements related to NOTIFICATION....................... 12
    5.3. Requirements related to receiving a NOTIFICATION........... 13
    5.4. Requirements related to INSTANT MESSAGES................... 13
   6. References.................................................... 14
   7. Authors' Addresses............................................ 15
   8. Appendix: Security Expectations and Deriving Requirements..... 16
    8.1. Presence Information....................................... 16
     8.1.1. Subscription............................................ 16
     8.1.2. Publication............................................. 19
     8.1.3. Publication for Notification............................ 19
     8.1.4. Receiving a Notification................................ 20
    8.2. Instant Messaging.......................................... 21
     8.2.1. Named Instant Messaging................................. 21
     8.2.2. Anonymous Instant Messaging............................. 23
     8.2.3. Administrator Expectations.............................. 24
   Full Copyright Statement......................................... 26














Day, et al.                  Informational                      [Page 2]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


1. Terminology

   The following terms are defined in [RFC 2778] and are used with those
   definitions in this document:

   ACCESS RULES
   CLOSED
   FETCHER
   INSTANT INBOX
   INSTANT MESSAGE
   NOTIFICATION
   OPEN
   POLLER
   PRESENCE INFORMATION
   PRESENCE SERVICE
   PRESENTITY
   PRINCIPAL
   PROXY
   SERVER
   STATUS
   SUBSCRIBER
   SUBSCRIPTION
   WATCHER

   The terms MUST and SHOULD are used in the following sense while
   specifying requirements:

   MUST: A proposed solution will have to meet this requirement.
   SHOULD: A proposed solution may choose not to meet this requirement.

   Note that this usage of MUST and SHOULD differs from that of RFC
   2119.

   Additionally, the following terms are used in this document and
   defined here:

   ADMINISTRATOR: A PRINCIPAL with authority over local computer and
   network resources, who manages local DOMAINS or FIREWALLS. For
   security and other purposes, an ADMINISTRATOR often needs or wants to
   impose restrictions on network usage based on traffic type, content,
   volume, or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over
   some or all of that PRINCIPAL's computer and network resources.

   DOMAIN: A portion of a NAMESPACE.

   ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER
   (all defined in [RFC 2778]).




Day, et al.                  Informational                      [Page 3]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   FIREWALL: A point of administrative control over connectivity.
   Depending on the policies being enforced, parties may need to take
   unusual measures to establish communications through the FIREWALL.

   IDENTIFIER: A means of indicating a point of contact, intended for
   public use such as on a business card. Telephone numbers, email
   addresses, and typical home page URLs are all examples of IDENTIFIERS
   in other systems.  Numeric IP addresses like 10.0.0.26 are not, and
   neither are URLs containing numerous CGI parameters or long arbitrary
   identifiers.

   INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT
   MESSAGE is sending it.

   NAMESPACE: The system that maps from a name of an ENTITY to the
   concrete implementation of that ENTITY. A NAMESPACE may be composed
   of a number of distinct DOMAINS.

   OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE
   SERVICE cannot communicate.

   SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was
   transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the
   INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually
   also implies that an INBOX USER AGENT has handled the message in a
   way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not
   imply that the message was actually seen by that PRINCIPAL.

2. Shared Requirements

   This section describes non-security requirements that are common to
   both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE.  Section 6
   describes requirements specific to a PRESENCE SERVICE, while Section
   7 describes requirements specific to an INSTANT MESSAGE SERVICE.
   Section 8 describes security considerations. The reader should note
   that Section 11 is an appendix that provides historical context and
   aids in tracing the origins of requirements in Section 8. Section 11
   is not, however, a statement of current IMPP requirements.

   It is expected that Presence and Instant Messaging services will be
   particularly valuable to users over mobile IP wireless access
   devices.  Indeed the number of devices connected to the Internet via
   wireless means is expected to grow substantially in the coming years.
   It is not reasonable to assume that separate protocols will be
   available for the wireless portions of the Internet. In addition, we
   note that wireless infrastructure is maturing rapidly; the work
   undertaken by this group should take into account the expected state
   of the maturity of the technology in the time-frame in which the



Day, et al.                  Informational                      [Page 4]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   Presence and Instant Messaging protocols are expected to be deployed.

   To this end, the protocols designed by this Working Group must be
   suitable for operation in a context typically associated with mobile
   wireless access devices, viz.  high latency, low bandwidth and
   possibly intermittent connectivity (which lead to a desire to
   minimize round-trip delays), modest computing power, battery
   constraints, small displays, etc. In particular, the protocols must
   be designed to be reasonably efficient for small payloads.

2.1. Namespace and Administration

   2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available
   independent of whether an INSTANT MESSAGE SERVICE is available, and
   vice-versa.

   2.1.2. The protocols must not assume that an INSTANT INBOX is
   necessarily reached by the same IDENTIFIER as that of a PRESENTITY.
   Specifically, the protocols must assume that some INSTANT INBOXes may
   have no associated PRESENTITIES, and vice versa.

   2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached
   via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.

   2.1.4. The administration and naming of ENTITIES within a given
   DOMAIN MUST be able to operate independently of actions in any other
   DOMAIN.

   2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS
   within the NAMESPACE.

2.2. Scalability

   2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate
   with ENTITIES in another DOMAIN, without the DOMAINS having
   previously been aware of each other.

   The protocol MUST be capable of meeting  its other functional and
   performance requirements even when

      -- (2.2.2) there are millions of ENTITIES within a single DOMAIN.

      -- (2.2.3) there are millions of DOMAINS within the single
         NAMESPACE.







Day, et al.                  Informational                      [Page 5]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


      -- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds
         of PRESENTITIES.

      -- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to
         a single PRESENTITY.

      -- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to
         PRESENTITIES in hundreds of distinct DOMAINS.

   These are protocol design goals; implementations may choose to place
   lower limits.

2.3. Access Control

   The PRINCIPAL controlling a PRESENTITY MUST be able to control

      -- (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE
         INFORMATION.

      -- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that
         PRESENTITY's PRESENCE INFORMATION.

      -- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see
         for that PRESENTITY, regardless of whether the WATCHER gets it
         by fetching or NOTIFICATION.

      -- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE
         INFORMATION of that PRESENTITY.

   The PRINCIPAL controlling an INSTANT INBOX MUST be able to control

      -- (2.3.5) which other PRINCIPALS, if any, can send INSTANT
         MESSAGES to that INSTANT INBOX.

      -- (2.3.6) which other PRINCIPALS, if any, can read INSTANT
         MESSAGES from that INSTANT INBOX.

   2.3.7. Access control MUST be independent of presence: the PRESENCE
   SERVICE MUST be able to make access control decisions even when the
   PRESENTITY is OUT OF CONTACT.

2.4. Network Topology

   Note that intermediaries such as PROXIES may be necessitated between
   IP and non-IP networks, and by an end-user's desire to provide
   anonymity and hide their IP address.





Day, et al.                  Informational                      [Page 6]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both
   directly and via intermediaries, such as PROXIES.

   2.4.2. The protocol MUST allow the sending of a NOTIFICATION both
   directly and via intermediaries, such as PROXIES.

   2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both
   directly and via intermediaries, such as PROXIES.

   2.4.4. The protocol proxying facilities and transport practices MUST
   allow ADMINISTRATORS ways to enable and disable protocol activity
   through existing and commonly-deployed FIREWALLS.  The protocol MUST
   specify how it can be effectively filtered by such FIREWALLS.

2.5. Message Encryption and Authentication

   2.5.1. The protocol MUST provide means to ensure confidence that a
   received message (NOTIFICATION or INSTANT MESSAGE) has not been
   corrupted or tampered with.

   2.5.2. The protocol MUST provide means to ensure confidence that a
   received message (NOTIFICATION or INSTANT MESSAGE) has not been
   recorded and played back by an adversary.

   2.5.3. The protocol MUST provide means to ensure that a sent message
   (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that
   the sender allows.

   2.5.4. The protocol MUST allow any client to use the means to ensure
   non-corruption, non-playback, and privacy, but the protocol MUST NOT
   require that all clients use these means at all times.

3. Additional Requirements for PRESENCE INFORMATION

   The requirements in section 6 are applicable only to PRESENCE
   INFORMATION and not to INSTANT MESSAGES.  Additional constraints on
   PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear
   in Section 7.4.

3.1. Common Presence Format

   3.1.1. All ENTITIES MUST produce and consume at least a common base
   format for PRESENCE INFORMATION.

   3.1.2. The common presence format MUST include a means to uniquely
   identify the PRESENTITY whose PRESENCE INFORMATION is reported.





Day, et al.                  Informational                      [Page 7]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   3.1.3. The common presence format MUST include a means to encapsulate
   contact information for the PRESENTITY's PRINCIPAL (if applicable),
   such as email address, telephone number, postal address, or the like.

   3.1.4. There MUST be a means of extending the common presence format
   to represent additional information not included in the common
   format, without undermining or rendering invalid the fields of the
   common format.

   3.1.5. The working group must define the extension and registration
   mechanisms for presence information schema, including new STATUS
   conditions and new forms for OTHER PRESENCE MARKUP.

   3.1.6. The presence format SHOULD be based on IETF standards such as
   vCard [RFC 2426] if possible.

3.2. Presence Lookup and Notification

   3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE
   INFORMATION even when the PRESENTITY is OUT OF CONTACT.

   3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a
   PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF
   CONTACT.

   3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's
   PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the
   PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER,
   unless prevented by the PRESENTITY's ACCESS RULES.

   3.2.4. The protocol MUST provide a mechanism for detecting when a
   PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.

   3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER
   gracefully telling the service that it will no longer be in
   communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT
   due to unanticipated failures.

3.3. Presence Caching and Replication

   3.3.1. The protocol MUST include mechanisms to allow PRESENCE
   INFORMATION to be cached.

   3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE
   INFORMATION to be updated when the master copy changes.






Day, et al.                  Informational                      [Page 8]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   3.3.3 The protocol caching facilities MUST NOT circumvent established
   ACCESS RULES or restrict choice of authentication/encryption
   mechanisms.

3.4 Performance

   3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any
   SUBSCRIBER to that information MUST be notified of the changed
   information rapidly, except when such notification is entirely
   prevented by ACCESS RULES. This requirement is met if each
   SUBSCRIBER's NOTIFICATION is transported as rapidly as an INSTANT
   MESSAGE would be transported to an INSTANT INBOX.

4. Additional Requirements for INSTANT MESSAGES

   The requirements in section 4 are applicable only to INSTANT MESSAGES
   and not to PRESENCE INFORMATION, with the exception of Section 4.4.
   Section 4.4 describes constraints on PRESENCE INFORMATION that are
   relevant only to systems that support both INSTANT MESSAGES and
   PRESENCE INFORMATION.

4.1. Common Message Format

   4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST
   implement at least a common base format for INSTANT MESSAGES.

   4.1.2. The common base format for an INSTANT MESSAGE MUST identify
   the sender and intended recipient.

   4.1.3. The common message format MUST include a return address for
   the receiver to reply to the sender with another INSTANT MESSAGE.

   4.1.4. The common message format SHOULD include standard forms of
   addresses or contact means for media other than INSTANT MESSAGES,
   such as telephone numbers or email addresses.

   4.1.5. The common message format MUST permit the encoding and
   identification of the message payload to allow for non-ASCII or
   encrypted content.

   4.1.6. The protocol must reflect best current practices related to
   internationalization.

   4.1.7. The protocol must reflect best current practices related to
   accessibility.






Day, et al.                  Informational                      [Page 9]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   4.1.8. The working group MUST define the extension and registration
   mechanisms for the message format, including new fields and new
   schemes for INSTANT INBOX ADDRESSES.

   4.1.9. The working group MUST determine whether the common message
   format includes fields for numbering or identifying messages. If
   there are such fields, the working group MUST define the scope within
   which such identifiers are unique and the acceptable means of
   generating such identifiers.

   4.1.10. The common message format SHOULD be based on IETF-standard
   MIME [RFC 2045].

4.2. Reliability

   4.2.1. The protocol MUST include mechanisms so that a sender can be
   informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons
   for failure.  The working group must determine what mechanisms apply
   when final delivery status is unknown, such as when a message is
   relayed to non-IMPP systems.

4.3 Performance

   4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid
   to allow for comfortable conversational exchanges of short messages.

4.4 Presence Format

   4.4.1. The common presence format MUST define a minimum standard
   presence schema suitable for INSTANT MESSAGE SERVICES.

   4.4.2. When used in a system supporting INSTANT MESSAGES, the common
   presence format MUST include a means to represent the STATUS
   conditions OPEN and CLOSED.

   4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to
   messaging or communication modes other than INSTANT MESSAGE SERVICES.














Day, et al.                  Informational                     [Page 10]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


5. Security Considerations

   Security considerations are addressed in section 2.3, Access Control,
   and section 2.5, Message authentication and encryption.

   This section describes further security-related requirements that the
   protocol must meet.

   The security requirements were derived from a set of all-encompassing
   "security expectations" that were then evaluated for practicality and
   implementability and translated into requirements.  In the appendix,
   we describe the expectations and the process used to transform them
   into requirements. In this section, we simply list the consolidated
   set of derived requirements.

   Note that in the requirements, ADMINISTRATORs may have privileges
   beyond those allowed to PRINCIPALs referred to in the requirements.
   (Unless otherwise noted, the individual expectations specifically
   refer to PRINCIPALs.)  It is up to individual implementations to
   control administrative access and implement the security privileges
   of ADMINISTRATORs without compromising the requirements made on
   PRINCIPALs.

   Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR
   PRINCIPALS.

5.1. Requirements related to SUBSCRIPTIONS

   When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION:

   5.1.1. The protocol MUST provide A means of identifying and
   authenticating that the PRESENTITY subscribed to is controlled by B.

   5.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION
   to B obvious to a third party C.

   5.1.3. The protocol MUST provide B with means of allowing an
   unauthenticated subscription by A.

   5.1.4. The protocol MUST provide A means of verifying the accurate
   receipt of the content B chooses to disclose to A.

   5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may
   choose to accept A's SUBSCRIPTION, but fail to deliver any
   information to it (so-called "polite blocking"). See 5.1.15.

   5.1.6. The protocol MUST NOT let any third party C force A to
   subscribe to B's PRESENCE INFORMATION without A's consent.



Day, et al.                  Informational                     [Page 11]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE
   INFORMATION at any time and for any reason.  When A does so, the
   PRESENCE SERVICE stops informing A of changes to B's PRESENCE
   INFORMATION.

   5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's
   SUBSCRIPTION to B.

   5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD
   inform A of the cancellation.

   5.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION
   to B, at any time.

   5.1.11. The protocol MUST provide B means of learning about A's
   SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION
   and afterwards.

   5.1.12. The protocol MUST provide B means of identifying and
   authenticating the SUBSCRIBER's PRINCIPAL, A.

   5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL
   from subscribing.

   5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS
   from subscribing.

   5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE
   to deny A's subscription while appearing to A as if the subscription
   has been granted (this is sometimes called "polite blocking").  The
   protocol MUST NOT mandate the PRESENCE SERVICE to service
   subscriptions that are treated in this manner.

   5.1.16. B MUST be able to cancel A's subscription at will.

   5.1.17. The protocol MUST NOT require A to reveal A's IP address to
   B.

   5.1.18 The protocol MUST NOT require B to reveal B's IP address to A.

5.2. Requirements related to NOTIFICATION

   When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to
   another PRINCIPAL A:

   5.2.1. The protocol MUST provide means of ensuring that only the
   PRINCIPAL A being sent the NOTIFICATION by B can read the
   NOTIFICATION.



Day, et al.                  Informational                     [Page 12]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   5.2.2. A should receive all NOTIFICATIONS intended for her.

   5.2.3. It MUST be possible for B to prevent A from receiving
   notifications, even if A is ordinarily permitted to see such
   notifications.  It MUST be possible for B to, at its choosing, notify
   different subscribers differently, through different notification
   mechanisms or through publishing different content. This is a
   variation on "polite blocking".

   5.2.4. The protocol MUST provide means of protecting B from another
   PRINCIPAL C "spoofing" notification messages about B.

   5.2.5. The protocol MUST NOT require that A reveal A's IP address to
   B.

   5.2.6. The protocol MUST NOT require that B reveal B's IP address to
   A.

5.3. Requirements related to receiving a NOTIFICATION

   When a PRINCIPAL A receives a notification message from another
   principal B, conveying PRESENCE INFORMATION,

   5.3.1. The protocol MUST provide A means of verifying that the
   presence information is accurate, as sent by B.

   5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS
   from entities she has subscribed to.

   5.3.3. The protocol MUST provide A means of verifying that the
   notification was sent by B.

5.4. Requirements related to INSTANT MESSAGES

   When a user A sends an INSTANT MESSAGE M to another user B,

   5.4.1. A MUST receive confirmation of non-delivery.

   5.4.2. If M is delivered, B MUST receive the message only once.

   5.4.3. The protocol MUST provide B means of verifying that A sent the
   message.

   5.4.4. B MUST be able to reply to the message via another instant
   message.

   5.4.5. The protocol MUST NOT always require A to reveal A's IP
   address, for A to send an instant message.



Day, et al.                  Informational                     [Page 13]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   5.4.6. The protocol MUST provide A means of ensuring that no other
   PRINCIPAL C can see the content of M.

   5.4.7. The protocol MUST provide A means of ensuring that no other
   PRINCIPAL C can tamper with M, and B means to verify that no
   tampering has occurred.

   5.4.8. B must be able to read M.

   5.4.9. The protocol MUST allow A to sign the message, using existing
   standards for digital signatures.

   5.4.10. B MUST be able to prevent A from sending him messages

6. References

   [RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for
              Presence and Instant Messaging", RFC 2778, February 2000.

   [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
              RFC 2426, September 1998.

   [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) - Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.























Day, et al.                  Informational                     [Page 14]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


7. Authors' Addresses

   Mark Day
   SightPath, Inc.
   135 Beaver Street
   Waltham, MA 02452
   USA

   EMail: mday@alum.mit.edu
   (Formerly Mark_Day@lotus.com)


   Sonu Aggarwal
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
   USA

   EMail: sonuag@microsoft.com


   Gordon Mohr

   EMail: gojomo@usa.net
   (Formerly gojomo@activerse.com)


   Jesse Vincent
   Into Networks, Inc.
   150 Cambridgepark Drive
   Cambridge, MA 02140
   USA

   EMail: jesse@intonet.com
   (Formerly jvincent@microsoft.com)
















Day, et al.                  Informational                     [Page 15]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


8. Appendix: Security Expectations and Deriving Requirements

   This appendix is based on the security expectations discussed on the
   impp mailing list and assembled by Jesse Vincent.  The original form
   of numbering has been preserved in this appendix (so there are
   several different items labeled B1, for example). The derived
   requirements have new numbers that are consistent with the main body
   of the document.  This appendix is included to provide a connection
   from discussions on the list to the requirements of Section 8, but it
   is not intended to introduce any new requirements beyond those
   presented in Sections 5 through 8.

8.1. PRESENCE INFORMATION

   In the case of PRESENCE INFORMATION, the controlling PRINCIPAL's
   privacy interests are paramount; we agreed that "polite blocking"
   (denying without saying that the subscription is denied, or providing
   false information) should be possible.

   8.1.1. Subscription

   When a user Alice subscribes to another person, Bob's presence info,
   Alice expects:

   A1. the PRESENTITY's PRINCIPAL, B, is identifiable and authenticated

       Discussion: Stands as a requirement.  Note that the protocol
       should provide Alice the capability of authenticating, without
       requiring that Alice authenticate every SUBSCRIPTION.  This
       caveat is made necessary by performance concerns, among others,
       and applies to many of the other requirements derived below.
       [Requirement 5.1.1]

   A2. no third party will know that A has subscribed to B.

       Discussion: This is somewhat unreasonable to enforce as is.  For
       example, in some topologies, nothing can prevent someone doing
       traffic analysis to deduce that A has subscribed to B.  We should
       merely require that the protocol not expose subscription
       information in any obvious manner. [Requirement 5.1.2]











Day, et al.                  Informational                     [Page 16]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   A3. A has the capability to subscribe to B's presence without B's
   knowledge, if B permits anonymous subscriptions.

       Discussion: An "anonymous subscription" above can have two
       implications - (i) B may allow an unauthenticated subscription by
       A, and (ii) B may be unaware of A's stated identity.  Requirement
       (i) is reasonable [Requirement 8.1.3], but (ii) doesn't appear to
       be a core requirement -- it can be adequately simulated via a
       subscription pseudonym.

   A4. A will accurately receive what B chooses to disclose to A
   regarding B's presence.

       Discussion: Stands as a requirement, with the "optional"
       caveat. [Requirement 8.1.4]

   A5. B will inform A if B refuses A's subscription

       Discussion:  Stands as a requirement. [Requirement 5.1.5]

   A6. No third party, C can force A to subscribe to B's presence
   without A's consent.

       Discussion: Stands as a requirement. [Requirement 5.1.6]

   A7. A can cancel her subscription to B's presence at any time and for
   any reason. When A does so, she will receive no further information
   about B's presence information.

       Discussion: This essentially stands.  However, implementations
       may have to contend with a timing window where A receives, after
       sending her cancellation request, a notification sent by B before
       B received the cancellation request.  Therefore, the requirement
       should focus on B's ceasing to send presence information, rather
       than A's ceasing to receive it. [Requirement 5.1.7]

   A8. no third party, C, can cancel A's subscription to B.

       Discussion: Stands, although the administrative exception does
       apply. [Requirement 5.1.8]

   A9. A is notified if her subscription to B is cancelled for any
   reason.

       Discussion: Although the intent is reasonable, there are a number
       of scenarios (e.g. overburdened server, clogged network, server
       crash) where delivering a notification to A of the cancellation
       is undesirable or impossible.  Therefore, the service should make



Day, et al.                  Informational                     [Page 17]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


       an attempt to inform, but this is not required. [Requirement
       5.1.9]

   Bob expects:

   B1. B will be informed that A subscribed to B's presence information,
   as long as A has not subscribed anonymously.

       Discussion: This essentially stands.  However, B can also choose
       to determine A's subscription after the fact.  [Requirement
       5.1.10]

   B2. A is identifiable and authenticated.

       Discussion: This stands as a requirement. [Requirement 5.1.11]

   B3. B can prevent a particular user, D, from subscribing.

       Discussion:  This stands as a requirement. [Requirement 5.1.12]

   B4. B can prevent anonymous users from subscribing.

       Discussion:  This stands as a requirement. [Requirement 5.1.13]

   B5. B's presence information is not republished by A to a third
   party, E, who does not.

       Discussion: This is practically impossible to enforce, so it is
       omitted from the requirement set.

   B6. B can deny A's subscription without letting A know that she's
   been blocked.

       Discussion: This "polite blocking" capability essentially stands;
       accepting a "denied" subscription should bear no implication on
       servicing it for status notifications. [Requirement 5.1.14]

   B7. B can cancel A's subscription at will.

       Discussion:  Stands as a requirement. [Requirement 5.1.15]

   Charlie, bob's network administrator expects:

   C1. C knows who is subscribed to B at all times.

       Discussion: Administrators should be able to determine who is
       subscribed, but needn't be continuously informed of the list of
       subscribers.  Also, in some cases user agents (e.g. proxies) may



Day, et al.                  Informational                     [Page 18]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


       have subscribed on behalf of users, and in these cases the
       administrator can only determine the identity of these agents,
       not their users. [Requirement 5.1.16]

   C2. C can manage all aspects of A's presence information.

       Discussion: This stands as a requirement. [Requirement 5.1.17]

   C3. C can control who can access A's presence information and
   exchange instant messages with A.

       Discussion: This stands in principle, but C should be able to
       waive these capabilities if C desires. [Requirement 5.1.18]

   8.1.2. Publication

   The publisher of status information, Bob, expects:

   B1. That information about B is not provided to any entity without
   B's knowledge and consent.

       Discussion: This is nearly impossible to accomplish, so it is
       omitted from the requirements.

   8.1.3. Publication for Notification

   When information is published for notification, B expects:

   B1. only a person being sent a notification, A, can read the
   notification.

       Discussion: Stands as a requirement. [Requirement 5.2.1]

   B2. A reliably receives all notifications intended for her.

       Discussion: This stands, although "Reliably" is a little strong
       (e.g. network outages, etc.). [Requirement 5.2.2]

   B3. B can prevent A from receiving notifications, even if A is
   ordinarily permitted to see such notifications.  This is a variation
   on "polite blocking."

       Discussion: This stands as a requirement. Also incorporated into
       this requirement is the notifications equivalent of the next
       expectation, B4. [Requirement 5.2.3]






Day, et al.                  Informational                     [Page 19]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   B4. B can provide two interested parties A and E with different
   status information at the same time. (B could represent the same
   event differently to different people.)

       Discussion: This stands as a requirement; it has been
       incorporated into the corresponding requirement for B3 above.

   B5. B expects that malicious C cannot spoof notification messages
   about B.

       Discussion: Stands in principle, but it should be optional for B.
       [Requirement 5.2.4]

   8.1.4. Receiving a Notification

   When Alice receives a notification, the recipient, Alice, expects:

   A1. That the notification information is accurate, truthful.

       Discussion: Stands in principle, although being "truthful" can't
       be a requirement, and the verification is optional for Alice.
       [Requirement 5.3.1]

   A2. That information about subscriptions remains private; people do
   not learn that A's subscription to B's information exists by watching
   notifications occur.

       Discussion: This is omitted from the requirements, as traffic
       analysis, even of encrypted traffic, can convey this information
       in some situations.

   A3. That she only receives notifications of things she's subscribed
   to.

       Discussion:  Stands as a requirement. [Requirement 5.3.2]

   A4. Notifications come from the apparent sender, B.

       Discussion: Stands in principle, although the verification should
       be  optional for A. [Requirement 5.3.3]

   A5. A can tell the difference between a message generated by the
   user, and a message legitimately generated by the agent on behalf of
   the user.

       Discussion: This could be quite difficult to enforce and could
       unduly restrict usage scenarios; this is omitted from the
       requirements.



Day, et al.                  Informational                     [Page 20]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   A6. That information given by agents on behalf of users can also be
   expected to be truthful, complete, and legitimately offered; the user
   permitted the agent to publish these notifications.

       Discussion: This is difficult to enforce and is omitted from the
       requirements.

   A7. A can prove that a notification from B was delivered in a timely
   fashion and can prove exactly how long the message took to be
   delivered.

       Discussion: This is difficult to enforce and is omitted from the
       requirements.  For example, such proof may entail global time
       synchronization mechanisms (since any system clocks have
       associated unreliability), which is outside the scope of this
       effort.

   A8. A can prove that B was indeed the sender of a given message.

       Discussion: This is a duplication of expectation A4 above and is
       reflected in the corresponding requirement 5.3.3.

8.2. INSTANT MESSAGEs

   8.2.1. Named Instant Messaging

   When a user Alice sends an instant message M to another user Bob:

   Alice expects that she:

   A1. will receive notification of non-delivery

       Discussion: Stands as a requirement. [Requirement 5.4.1]

   Alice expects that Bob:

   B1. will receive the message

       Discussion: covered by A1 and is reflected in the corresponding
       requirement 5.4.1.

   B2. will receive the message quickly

       Discussion: Stands as a requirement, although this is also
       covered elsewhere (in the non-security requirements), so this is
       omitted from the security requirements.





Day, et al.                  Informational                     [Page 21]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   B3. will receive the message only once

       Discussion: Stands as a requirement. [Requirement 5.4.2]

   B4. will be able to verify that Alice sent the message

       Discussion:  Stands as a requirement. [Requirement 5.4.3]

   B5. will not know whether there were BCCs

       Discussion: Emulating e-mail conventions and social protocols is
       not a core goal of this effort, and therefore references to
       standard mail fields are omitted from the requirements.

   B6. will be able to reply to the message

       Discussion: Stands in principle; the recipient should be able to
       reply via an instant message. [Requirement 5.4.4]

   B7. will know if he was a bcc recipient

       Discussion: Omitted, as noted above.

   B8. will not be able to determine any information about A (such as
   her location or IP address) without A's knowledge and consent.

       Discussion: "Any information about A" is too general; the
       requirement should focus on IP address.  Further, "without A's
       knowledge and consent" may be overkill. [Requirement 5.4.5]

   Alice expects that no other user Charlie will be able to:

   C1. see the content of M

       Discussion: Stands in principle, although this should not be
       mandated for all IM communication. [Requirement 5.4.6]

   C2. tamper with M

       Discussion: Stands, with the same caveat as above.
       [Requirement 5.4.7]

   C3. know that M was sent

       Discussion: It is impossible to prevent traffic analysis, and
       this is therefore omitted from the requirements.





Day, et al.                  Informational                     [Page 22]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   When a user Bob receives an instant message M from another user
   Alice:

   Bob expects that Bob:

   D1. will be able to read M

       Discussion: Stands as a requirement. [Requirement 5.4.8]

   D2. will be able to verify M's authenticity (both Temporal and the
   sender's identity)

       Discussion: As noted earlier, it is not reasonable to directly
       require temporal checks.  The protocol should, however, allow
       signing messages using existing standards for signing.
       [Requirement 5.4.9]

   D3. will be able to verify M's integrity

       Discussion:  Stands as a requirement. [Requirement 5.4.10]

   D4. will be able to prevent A from sending him future messages

       Discussion: Stands as a requirement. [Requirement 5.4.11]

   Bob expects that Alice:

   E1. intended to send the message to Bob

       Discussion: This is covered by the corresponding requirement
       5.4.6 for C1 above.

   E2. informed Bob of all CCs.

       Discussion: As noted earlier, references to cc:'s are omitted
       from the requirements.

   8.2.2. Anonymous Instant Messaging

       Discussion: Anonymous instant messaging, as in "hiding the
       identity of the sender", is not deemed to be a core requirement
       of the protocol and references to it are therefore omitted from
       the requirements. Implementations may provide facilities for
       anonymous messaging if they wish, in ways that are consistent
       with the other requirements.

   When a user Alice sends an anonymous instant message to another user
   Bob:



Day, et al.                  Informational                     [Page 23]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   Alice expects that Bob:

   B1. will receive the message

   B2. will receive the message quickly

   B3. will receive the message only once

   AB4.1. cannot know Alice sent it

   AB4.2. will know that the IM is anonymous, and not from a specific
   named user

   AB4.3   may not allow anonymous IMs

   B5. will not know whether there were BCCs

   B6. will be able to reply to the message

   Alice expects that she:

   C1. will receive notification of non-delivery

   AC2. will receive an error if the IM was refused

   Bob expects that he:

   D1. will be able to read M

   D2. will be able to verify M's authenticity (both temporal and the
   sender's identity)

   D3. will be able to verify M's integrity

   AD4. will know if an IM was sent anonymously

   AD5. will be able to automatically discard anonymous IM if desired

   AD6. will be able to control whether an error is sent to Alice if M
   is discarded.

   8.2.3. Administrator Expectations

   Charlie, Alice's network administrator expects:

   C1. that C will be able to send A instant messages at any time.

   C2. that A will receive any message he sends while A is online.



Day, et al.                  Informational                     [Page 24]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   C3. that A will not be able to refuse delivery of any instant
   messages sent by C.

       Discussion for C1-C3: It is not clear this needs to be specially
       handled at the protocol level; Administrators may accomplish the
       above objectives through other means.  For example, an
       administrator may send a message to a user through the normal
       mechanisms.  This is therefore omitted from the requirements.











































Day, et al.                  Informational                     [Page 25]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Day, et al.                  Informational                     [Page 26]