File: rfc2778.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites:
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 35,150 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






Network Working Group                                          M. Day
Request for Comments: 2778                                      Lotus
Category: Informational                                  J. Rosenberg
                                                          dynamicsoft
                                                            H. Sugano
                                                              Fujitsu
                                                        February 2000


               A Model for Presence and Instant Messaging

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

   This document defines an abstract model for a presence and instant
   messaging system. It defines the various entities involved, defines
   terminology, and outlines the services provided by the system. The
   goal is to provide a common vocabulary for further work on
   requirements for protocols and markup for presence and instant
   messaging.

1. Introduction

   A presence and instant messaging system allows users to subscribe to
   each other and be notified of changes in state, and for users to send
   each other short instant messages. To facilitate development of a
   suite of protocols to provide this service, we believe that it is
   valuable to first develop a model for the system. The model consists
   of the various entities involved, descriptions of the basic functions
   they provide, and most importantly, definition of a vocabulary which
   can be used to facilitate discussion.

   We note that the purpose of this model is to be descriptive and
   universal: we want the model to map reasonably onto all of the
   systems that are informally described as presence or instant
   messaging systems. The model is not intended to be prescriptive or
   achieve interoperability: an element that appears in the model will
   not necessarily be an element of an interoperable protocol, and may
   not even be a good idea.



Day, et al.                  Informational                      [Page 1]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


   In this document, each element of the model appears in upper case
   (e.g., PRESENCE SERVICE). No term in lower case or mixed case is
   intended to be a term of the model.

   The first part of this document is intended as an overview of the
   model.  The overview includes diagrams, and terms are presented in an
   order that is intended to help the reader understand the relationship
   between elements. The second part of the document is the actual
   definition of the model, with terms presented in alphabetical order
   for ease of reference.

   The overview is intended to be helpful but is not definitive; it may
   contain inadvertent differences from the definitions in the model.
   For any such difference, the definition(s) in the model are taken to
   be correct, rather than the explanation(s) in the overview.

2. Overview

   The model is intended to provide a means for understanding,
   comparing, and describing systems that support the services typically
   referred to as presence and instant messaging. It consists of a
   number of named entities that appear, in some form, in existing
   systems. No actual implementation is likely to have every entity of
   the model as a distinct part. Instead, there will almost always be
   parts of the implementation that embody two or more entities of the
   model. However, different implementations may combine entities in
   different ways.

   The model defines two services: a PRESENCE SERVICE and an INSTANT
   MESSAGE SERVICE. The PRESENCE SERVICE serves to accept information,
   store it, and distribute it.  The information stored is
   (unsurprisingly) PRESENCE INFORMATION. The INSTANT MESSAGE SERVICE
   serves to accept and deliver INSTANT MESSAGES to INSTANT INBOXES.

2.1 PRESENCE SERVICE

   The PRESENCE SERVICE has two distinct sets of "clients" (remember,
   these may be combined in an implementation, but treated separately in
   the model).  One set of clients, called PRESENTITIES, provides
   PRESENCE INFORMATION to be stored and distributed.  The other set of
   clients, called WATCHERS, receives PRESENCE INFORMATION from the
   service.









Day, et al.                  Informational                      [Page 2]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


                    +---------------------------+
                    |     PRESENCE SERVICE      |
                    |                           |
                    +---------------------------+
                        ^                 |
                        |                 |
                        |                 v
                 +------------+       +------------+
                 | PRESENTITY |       |  WATCHER   |
                 +------------+       +------------+


                 Fig. 1: Overview of Presence Service

   There are two kinds of WATCHERS, called FETCHERS and SUBSCRIBERS. A
   FETCHER simply requests the current value of some PRESENTITY's
   PRESENCE INFORMATION from the PRESENCE SERVICE. In contrast, a
   SUBSCRIBER requests notification from the PRESENCE SERVICE of
   (future) changes in some PRESENTITY's PRESENCE INFORMATION.  A
   special kind of FETCHER is one that fetches information on a regular
   basis.  This is called a POLLER.

              +----------------WATCHER---------------+
              |                                      |
              |  +----FETCHER---+  +--SUBSCRIBER--+  |
              |  |              |  |              |  |
              |  | +--POLLER--+ |  |              |  |
              |  | |          | |  |              |  |
              |  | +----------+ |  |              |  |
              |  +--------------+  +--------------+  |
              +--------------------------------------+

                   Fig. 2: Varieties of WATCHER

   The PRESENCE SERVICE also has WATCHER INFORMATION about WATCHERS and
   their activities in terms of fetching or subscribing to PRESENCE
   INFORMATION.  The PRESENCE SERVICE may also distribute WATCHER
   INFORMATION to some WATCHERS, using the same mechanisms that are
   available for distributing PRESENCE INFORMATION.

   Changes to PRESENCE INFORMATION are distributed to SUBSCRIBERS via
   NOTIFICATIONS. Figures 3a through 3c show the flow of information as
   a piece of PRESENCE INFORMATION is changed from P1 to P2.








Day, et al.                  Informational                      [Page 3]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


                   +---------------------------+
                   |     PRESENCE SERVICE      |
                   |            P1             |
                   +---------------------------+


                +------------+       +------------+
                |   P1->P2   |       |     P1     |
                | PRESENTITY |       | SUBSCRIBER |
                +------------+       +------------+

                   Fig. 3a: NOTIFICATION (Step 1)



                   +---------------------------+
                   |     PRESENCE SERVICE      |
                   |          P1->P2           |
                   +---------------------------+
                       ^
                       |P2
                +------------+       +------------+
                |     P2     |       |    P1      |
                | PRESENTITY |       | SUBSCRIBER |
                +------------+       +------------+

                   Fig. 3b: NOTIFICATION (Step 2)



                   +---------------------------+
                   |     PRESENCE SERVICE      |
                   |            P2             |
                   +---------------------------+
                                           |P2
                                           v
                +------------+       +------------+
                |     P2     |       |   P1->P2   |
                | PRESENTITY |       | SUBSCRIBER |
                +------------+       +------------+

                   Fig. 3c: NOTIFICATION (Step 3)

2.2 INSTANT MESSAGE SERVICE

   The INSTANT MESSAGE SERVICE also has two distinct sets of "clients":
   SENDERS and INSTANT INBOXES. A SENDER provides INSTANT MESSAGES to
   the INSTANT MESSAGE SERVICE for delivery. Each INSTANT MESSAGE is



Day, et al.                  Informational                      [Page 4]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


   addressed to a particular INSTANT INBOX ADDRESS, and the INSTANT
   MESSAGE SERVICE attempts to deliver the message to a corresponding
   INSTANT INBOX.

                 +---------------------------+
                 |  INSTANT MESSAGE SERVICE  |
                 |                           |
                 +---------------------------+
                     ^                 |
                     |                 |
                     |                 v
              +------------+       +---------------+
              |   SENDER   |       | INSTANT INBOX |
              +------------+       +---------------+

            Fig. 4: Overview of Instant Message Service

2.3 Protocols

   A PRESENCE PROTOCOL defines the interaction between PRESENCE SERVICE,
   PRESENTITIES, and WATCHERS. PRESENCE INFORMATION is carried by the
   PRESENCE PROTOCOL.

   An INSTANT MESSAGE PROTOCOL defines the interaction between INSTANT
   MESSAGE SERVICE, SENDERS, and INSTANT INBOXES. INSTANT MESSAGES are
   carried by the INSTANT MESSAGE PROTOCOL.

   In terms of this model, we believe that the IMPP working group is
   planning to develop detailed requirements and specifications for the
   structure and formats of the PRESENCE PROTOCOL, PRESENCE INFORMATION,
   INSTANT MESSAGE PROTOCOL, and INSTANT MESSAGES.

2.4 Formats

   The model defines the PRESENCE INFORMATION to consist of an arbitrary
   number of elements, called PRESENCE TUPLES. Each such element
   consists of a STATUS marker (which might convey information such as
   online/offline/busy/away/do not disturb), an optional COMMUNICATION
   ADDRESS, and optional OTHER PRESENCE MARKUP.  A COMMUNICATION ADDRESS
   includes a COMMUNICATION MEANS and a CONTACT ADDRESS. One type of
   COMMUNICATION MEANS, and the only one defined by this model, is
   INSTANT MESSAGE SERVICE.  One type of CONTACT ADDRESS, and the only
   one defined by this model, is INSTANT INBOX ADDRESS. However, other
   possibilities exist: a COMMUNICATION MEANS might indicate some form
   of telephony, for example, with the corresponding CONTACT ADDRESS
   containing a telephone number.





Day, et al.                  Informational                      [Page 5]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


      +------------------------------------+
      | PRESENCE INFORMATION               |
      +------------------------------------+
       | +-------------------------------+
       =>| PRESENCE TUPLE                |
       | +-------------------------------+
       |   | +-------------------------+
       |   =>| STATUS                  |
       |   | +-------------------------+
       |   | +-------------------------+
       |   =>| COMMUNICATION ADDRESS   |
       |   | +-------------------------+
       |   |     | +-----------------+
       |   |     =>| CONTACT MEANS   |
       |   |     | +-----------------+
       |   |     | +-----------------+
       |   |     =>| CONTACT ADDRESS |
       |   |       +-----------------+
       |   | +-------------------------+
       |   =>| OTHER MARKUP            |
       |     +-------------------------+
       | +-------------------------------+
       =>| PRESENCE TUPLE                |
       | +-------------------------------+
       |   | +-------------------------+
       |   =>| STATUS                  |
       |   | +-------------------------+
       |   | +-------------------------+
       |   =>| COMMUNICATION ADDRESS   |
       |   | +-------------------------+
       |   |     | +-----------------+
       |   |     =>| CONTACT MEANS   |
       |   |     | +-----------------+
       |   |     | +-----------------+
       |   |     =>| CONTACT ADDRESS |
       |   |       +-----------------+
       |   | +-------------------------+
       |   =>| OTHER MARKUP            |
       |     +-------------------------+
       | +-------------------------------+
       =>| PRESENCE TUPLE                |
       | +-------------------------------+
       |    ...

        Fig. 5: The structure of PRESENCE INFORMATION






Day, et al.                  Informational                      [Page 6]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


   STATUS is further defined by the model to have at least two states
   that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT
   MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will
   not be accepted. OPEN and CLOSED may also be applicable to other
   COMMUNICATION MEANS -- OPEN mapping to some state meaning "available"
   or "open for business" while CLOSED means "unavailable" or "closed to
   business." The model allows STATUS to include other values, which may
   be interpretable by programs or only by persons.  The model also
   allows STATUS to consist of single or multiple values.

2.5 Presence and its effect on Instant Messages

   An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT
   INBOX ADDRESS is the information that can be included in PRESENCE
   INFORMATION to define how an INSTANT MESSAGE should be delivered to
   that INSTANT INBOX. As noted above, certain values of the STATUS
   marker indicate whether INSTANT MESSAGES will be accepted at the
   INSTANT INBOX.  The model does not otherwise constrain the delivery
   mechanism or format for instant messages. Reasonable people can
   disagree about whether this omission is a strength or a weakness of
   this model.

2.6 PRINCIPALS and their agents

   This model includes other elements that are useful in characterizing
   how the protocol and markup work. PRINCIPALS are the people, groups,
   and/or software in the "real world" outside the system that use the
   system as a means of coordination and communication. It is entirely
   outside the model how the real world maps onto PRINCIPALS -- the
   system of model entities knows only that two distinct PRINCIPALS are
   distinct, and two identical PRINCIPALS are identical.

   A PRINCIPAL interacts with the system via one of several user agents
   (INBOX USER AGENT; SENDER USER AGENT; PRESENCE USER AGENT; WATCHER
   USER AGENT). As usual, the different kinds of user agents are split
   apart in this model even though most implementations will combine at
   least some of them. A user agent is purely coupling between a
   PRINCIPAL and some core entity of the system (respectively, INSTANT
   INBOX; SENDER; PRESENTITY; WATCHER).












Day, et al.                  Informational                      [Page 7]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


                   +---------------------------+
                   |     PRESENCE SERVICE      |
                   +---------------------------+
                       ^                   |
                       | PRESENCE PROTOCOL |
                       |                   v
                +------------+       +------------+
                | PRESENTITY |       |  WATCHER   |
                +------------+       +------------+
                      ^                   ^
                      |                   |
                      |                   |
        o      +--------------+      +-------------+      o
       /|\  -->| PRESENCE UA  |      | WATCHER UA  |<--  /|\
        X      +--------------+      +-------------+      X

   (PRINCIPAL)                                        (PRINCIPAL)

                    Fig. 6: A presence system


                  +---------------------------+
                  |  INSTANT MESSAGE SERVICE  |
                  +---------------------------+
                      ^                    |
                    IM|   INSTANT MESSAGE  |IM
                      |       PROTOCOL     v
               +------------+        +---------------+
               |   SENDER   |        | INSTANT INBOX |
               +------------+        +---------------+
                     ^                      ^
                     |                      |
                     |                      |
       o      +-------------+       +------------------+      o
      /|\  -->|  SENDER UA  |       |  INBOX UA        |<--  /|\
       X      +-------------+       +------------------+      X

   (PRINCIPAL)                                           (PRINCIPAL)

                Fig. 7: An instant messaging system











Day, et al.                  Informational                      [Page 8]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


2.7 Examples

   A simple example of applying the model is to describe a generic
   "buddy list" application. These applications typically expose the
   user's presence to others, and make it possible to see the presence
   of others. So we could describe a buddy list as the combination of a
   PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL,
   using a single PRESENTITY and a single SUBSCRIBER.

   We could then extend our example to instant messaging and describe a
   generic "instant messenger" as essentially a buddy list with
   additional capabilities for sending and receiving instant messages.
   So an instant messenger would be the combination of a PRESENCE USER
   AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER USER AGENT
   for a single PRINCIPAL, using a single PRESENTITY, single SUBSCRIBER,
   and single INSTANT INBOX, with the PRESENTITY's PRESENCE INFORMATION
   including an INSTANT INBOX ADDRESS that leads to the INSTANT INBOX.

3. Model

   ACCESS RULES: constraints on how a PRESENCE SERVICE makes PRESENCE
      INFORMATION available to WATCHERS. For each PRESENTITY's PRESENCE
      INFORMATION, the applicable ACCESS RULES are manipulated by the
      PRESENCE USER AGENT of a PRINCIPAL that controls the PRESENTITY.

      Motivation: We need some way of talking about hiding presence
      information from people.

   CLOSED: a distinguished value of the STATUS marker. In the context of
      INSTANT MESSAGES, this value means that the associated INSTANT
      INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is
      unable to accept an INSTANT MESSAGE.  This value may have an
      analogous meaning for other COMMUNICATION MEANS, but any such
      meaning is not defined by this model. Contrast with OPEN.

   COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT
      ADDRESS.

   COMMUNICATION MEANS: indicates a method whereby communication can
      take place. INSTANT MESSAGE SERVICE is one example of a
      COMMUNICATION MEANS.

   CONTACT ADDRESS: a specific point of contact via some COMMUNICATION
      MEANS. When using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS
      is an INSTANT INBOX ADDRESS.






Day, et al.                  Informational                      [Page 9]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


   DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE
      delivers received INSTANT MESSAGES to INSTANT INBOXES. For each
      INSTANT INBOX, the applicable DELIVERY RULES are manipulated by
      the INBOX USER AGENT of a PRINCIPAL that controls the INSTANT
      INBOX.

      Motivation: We need a way of talking about filtering instant
      messages.

   FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE to for
      the PRESENCE INFORMATION of one or more PRESENTITIES, but has not
      asked for a SUBSCRIPTION to be created.

   INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more
      INSTANT INBOXES controlled by that PRINCIPAL.

      Motivation: This is intended to isolate the core functionality of
      an INSTANT INBOX from how it might appear to be manipulated by a
      product. This manipulation includes fetching messages, deleting
      messages, and setting DELIVERY RULES. We deliberately take no
      position on whether the INBOX USER AGENT, INSTANT INBOX, and
      INSTANT MESSAGE SERVICE are colocated or distributed across
      machines.

   INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by
      the INSTANT INBOX's PRINCIPAL.

   INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's
      PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The
      STATUS and INSTANT INBOX ADDRESS information are sufficient to
      determine whether the PRINCIPAL appears ready to accept the
      INSTANT MESSAGE.

      Motivation: The definition is pretty loose about exactly how any
      of this works, even leaving open the possibility of reusing parts
      of the email infrastructure for instant messaging.

   INSTANT MESSAGE: an identifiable unit of data, of small size, to be
      sent to an INSTANT INBOX.

      Motivation: We do not define "small" but we seek in this
      definition to avoid the possibility of transporting an arbitrary-
      length stream labelled as an "instant message."








Day, et al.                  Informational                     [Page 10]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


   INSTANT MESSAGE PROTOCOL: The messages that can be exchanged between
      a SENDER USER AGENT and an INSTANT MESSAGE SERVICE, or between an
      INSTANT MESSAGE SERVICE and an INSTANT INBOX.

   INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES.

      -- May require authentication of SENDER USER AGENTS and/or INSTANT
         INBOXES.

      -- May have different authentication requirements for different
         INSTANT INBOXES, and may also have different authentication
         requirements for different INSTANT INBOXES controlled by a
         single PRINCIPAL.

      -- May have an internal structure involving multiple SERVERS
         and/or PROXIES. There may be complex patterns of redirection
         and/or proxying while retaining logical connectivity to a
         single INSTANT MESSAGE SERVICE. Note that an INSTANT MESSAGE
         SERVICE does not require having a distinct SERVER -- the
         service may be implemented as direct communication between
         SENDER and INSTANT INBOX.

      -- May have an internal structure involving other INSTANT MESSAGE
         SERVICES, which may be independently accessible in their own
         right as well as being reachable through the initial INSTANT
         MESSAGE SERVICE.

   NOTIFICATION: a message sent from the PRESENCE SERVICE to a
         SUBSCRIBER when there is a change in the PRESENCE INFORMATION
         of some PRESENTITY of interest, as recorded in one or more
         SUBSCRIPTIONS.

         Motivation: We deliberately take no position on what part of
         the changed information is included in a NOTIFICATION.

   OPEN: a distinguished value of the STATUS marker. In the context of
      INSTANT MESSAGES, this value means that the associated INSTANT
      INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is
      ready to accept an INSTANT MESSAGE.  This value may have an
      analogous meaning for other COMMUNICATION MEANS, but any such
      meaning is not defined by this model. Contrast with CLOSED.

   OTHER PRESENCE MARKUP: any additional information included in the
      PRESENCE INFORMATION of a PRESENTITY. The model does not define
      this further.

   POLLER: a FETCHER that requests PRESENCE INFORMATION on a regular
      basis.



Day, et al.                  Informational                     [Page 11]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


   PRESENCE INFORMATION: consists of one or more PRESENCE TUPLES.

   PRESENCE PROTOCOL: The messages that can be exchanged between a
      PRESENTITY and a PRESENCE SERVICE, or a WATCHER and a PRESENCE
      SERVICE.

   PRESENCE SERVICE: accepts, stores, and distributes PRESENCE
      INFORMATION.

      -- May require authentication of PRESENTITIES, and/or WATCHERS.

      -- May have different authentication requirements for different
         PRESENTITIES.

      -- May have different authentication requirements for different
         WATCHERS, and may also have different authentication
         requirements for different PRESENTITIES being watched by a
         single WATCHER.

      -- May have an internal structure involving multiple SERVERS
         and/or PROXIES. There may be complex patterns of redirection
         and/or proxying while retaining logical connectivity to a
         single PRESENCE SERVICE. Note that a PRESENCE SERVICE does not
         require having a distinct SERVER -- the service may be
         implemented as direct communication among PRESENTITY and
         WATCHERS.

      -- May have an internal structure involving other PRESENCE
         SERVICES, which may be independently accessible in their own
         right as well as being reachable through the initial PRESENCE
         SERVICE.

   PRESENCE TUPLE: consists of a STATUS, an optional COMMUNICATION
      ADDRESS, and optional OTHER PRESENCE MARKUP.

   PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more
      PRESENTITIES.

      Motivation: This is essentially a "model/view" distinction: the
      PRESENTITY is the model of the presence being exposed, and is
      independent of its manifestation in any user interface. In
      addition, we deliberately take no position on how the PRESENCE
      USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or
      distributed across machines.

   PRESENTITY (presence entity): provides PRESENCE INFORMATION to a
      PRESENCE SERVICE.




Day, et al.                  Informational                     [Page 12]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


      Motivation: We don't like to coin new words, but "presentity"
      seemed worthwhile so as to have an unambiguous term for the entity
      of interest to a presence service. Note that the presentity is not
      (usually) located in the presence service: the presence service
      only has a recent version of the presentity's presence
      information.  The presentity initiates changes in the presence
      information to be distributed by the presence service.

   PRINCIPAL: human, program, or collection of humans and/or programs
      that chooses to appear to the PRESENCE SERVICE as a single actor,
      distinct from all other PRINCIPALS.

      Motivation: We need a clear notion of the actors outside the
      system. "Principal" seems as good a term as any.

   PROXY: a SERVER that communicates PRESENCE INFORMATION, INSTANT
      MESSAGES, SUBSCRIPTIONS and/or NOTIFICATIONS to another SERVER.
      Sometimes a PROXY acts on behalf of a PRESENTITY, WATCHER, or
      INSTANT INBOX.

   SENDER: source of INSTANT MESSAGES to be delivered by the INSTANT
      MESSAGE SERVICE.

   SENDER USER AGENT: means for a PRINCIPAL to manipulate zero or more
      SENDERS.

   SERVER: an indivisible unit of a PRESENCE SERVICE or INSTANT MESSAGE
      SERVICE.

   SPAM: unwanted INSTANT MESSAGES.

   SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.

   STALKING: using PRESENCE INFORMATION to infer the whereabouts of a
      PRINCIPAL, especially for malicious or illegal purposes.

   STATUS: a distinguished part of the PRESENCE INFORMATION of a
      PRESENTITY. STATUS has at least the mutually-exclusive values OPEN
      and CLOSED, which have meaning for the acceptance of INSTANT
      MESSAGES, and may have meaning for other COMMUNICATION MEANS.
      There may be other values of STATUS that do not imply anything
      about INSTANT MESSAGE acceptance. These other values of STATUS may
      be combined with OPEN and CLOSED or they may be mutually-exclusive
      with those values.







Day, et al.                  Informational                     [Page 13]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


      Some implementations may combine STATUS with other entities. For
      example, an implementation might make an INSTANT INBOX ADDRESS
      visible only when the INSTANT INBOX can accept an INSTANT MESSAGE.
      Then, the existence of an INSTANT INBOX ADDRESS implies OPEN,
      while its absence implies CLOSED.

   SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to
      notify it immediately of changes in the PRESENCE INFORMATION of
      one or more PRESENTITIES.

   SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a
      SUBSCRIBER's request to be notified of changes in the PRESENCE
      INFORMATION of one or more PRESENTITIES.

   VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes WATCHER
      INFORMATION available to WATCHERS. For each WATCHER's WATCHER
      INFORMATION, the applicable VISIBILITY RULES are manipulated by
      the WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER.

      Motivation: We need a way of talking about hiding watcher
      information from people.

   WATCHER: requests PRESENCE INFORMATION about a PRESENTITY, or WATCHER
      INFORMATION about a WATCHER, from the PRESENCE SERVICE. Special
      types of WATCHER are FETCHER, POLLER, and SUBSCRIBER.

   WATCHER INFORMATION: information about WATCHERS that have received
      PRESENCE INFORMATION about a particular PRESENTITY within a
      particular recent span of time. WATCHER INFORMATION is maintained
      by the PRESENCE SERVICE, which may choose to present it in the
      same form as PRESENCE INFORMATION; that is, the service may choose
      to make WATCHERS look like a special form of PRESENTITY.

      Motivation: If a PRESENTITY wants to know who knows about it, it
      is not enough to examine only information about SUBSCRIPTIONS. A
      WATCHER might repeatedly fetch information without ever
      subscribing. Alternately, a WATCHER might repeatedly subscribe,
      then cancel the SUBSCRIPTION.  Such WATCHERS should be visible to
      the PRESENTITY if the PRESENCE SERVICE offers WATCHER INFORMATION,
      but will not be appropriately visible if the WATCHER INFORMATION
      includes only SUBSCRIPTIONS.

   WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or more
      WATCHERS controlled by that PRINCIPAL.







Day, et al.                  Informational                     [Page 14]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


      Motivation: As with PRESENCE USER AGENT and PRESENTITY, the
      distinction here is intended to isolate the core functionality of
      a WATCHER from how it might appear to be manipulated by a product.
      As previously, we deliberately take no position on whether the
      WATCHER USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or
      distributed across machines.

4. Security Considerations

   This document provides a model and vocabulary for systems with
   certain intrinsic security issues. In particular, presence and
   instant messaging systems must deal with "the three S's": STALKING,
   SPOOFING, and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER
   INFORMATION are intended to deal with STALKING.  The several kinds of
   authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE
   SERVICE are intended to deal with SPOOFING. DELIVERY RULES are
   intended to deal with SPAM.

5. Conclusion

   This document has provided a model for a presence and instant
   messaging system. The purpose of the model is to provide a common
   vocabulary for the further work of defining and implementing
   interoperable presence and instant messaging protocols.

6. Acknowledgements

   This document has been improved by comments from Jesse Vincent and
   Colin Benson, by the participants in the Cambridge, MA meeting on
   June 11, 1999, and by Roy Salisbury, who contributed the original
   version of Figure 5. The authors gratefully acknowledge their
   assistance.



















Day, et al.                  Informational                     [Page 15]

RFC 2778       A Model for Presence and Instant Messaging  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)


   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive
   Suite 120
   West Orange, NJ 07046

   Email: jdrosen@dynamicsoft.com


   Hiroyasu Sugano
   Fujitsu Laboratories Ltd.
   64 Nishiwaki, Ohkubo-cho
   Akashi 674-8555
   Japan

   EMail: suga@flab.fujitsu.co.jp























Day, et al.                  Informational                     [Page 16]

RFC 2778       A Model for Presence and Instant Messaging  February 2000


8. 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 17]