idnits 2.17.1 draft-ietf-impp-model-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 767 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ENVY' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'PIPR' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'PRESENCE' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RPIM' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RVP-ADDR' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RVP' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'SIP-PIP' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'WHODP' is defined on line 705, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ENVY' -- Possible downref: Normative reference to a draft: ref. 'PIPR' -- Possible downref: Normative reference to a draft: ref. 'PRESENCE' -- Possible downref: Normative reference to a draft: ref. 'RPIM' -- Possible downref: Normative reference to a draft: ref. 'RVP-ADDR' -- Possible downref: Normative reference to a draft: ref. 'RVP' -- Possible downref: Normative reference to a draft: ref. 'SIP-PIP' -- Possible downref: Normative reference to a draft: ref. 'WHODP' Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mark Day 2 Expires February 28, 2000 Lotus 4 Jonathan Rosenberg 5 Bell Labs 7 Hiroyasu Sugano 8 Fujitsu 10 A Model for Presence and Instant Messaging 12 draft-ietf-impp-model-03.txt 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document and related documents are discussed on the impp mailing 32 list. To join the list, send mail to impp-request@iastate.edu. To 33 contribute to the discussion, send mail to impp@iastate.edu. The 34 archives are at http://lists.fsck.com/cgi-bin/wilma/pip. The IMPP 35 working group charter, including the current list of group documents, 36 can be found at http://www.ietf.org/html.charters/impp-charter.html. 38 1. Abstract 40 This document defines an abstract model for a presence and instant 41 messaging system. It defines the various entities involved, defines 42 terminology, and outlines the services provided by the system. The 43 goal is to provide a common vocabulary for further work on 44 requirements for protocols and markup for presence and instant 45 messaging. 47 2. Introduction 49 A presence and instant messaging system allows users to subscribe to 50 each other and be notified of changes in state, and for users to send 51 each other short instant messages. A number of requirements and 52 protocols have been proposed to support it [WHODP, ENVY, PRESENCE, 53 RVP-ADDR, RPIM, SIP-PIP, PIPR, RVP]. To facilitate development of a 54 suite of protocols to provide this service, we believe that it is 56 valuable to first develop a model for the system. The model consists 57 of the various entities involved, descriptions of the basic functions 58 they provide, and most importantly, definition of a vocabulary which 59 can be used to facilitate discussion. 61 We note that the purpose of this model is to be descriptive and 62 universal: we want the model to map reasonably onto all of the systems 63 that are informally described as presence or instant messaging 64 systems. The model is not intended to be prescriptive or achieve 65 interoperability: an element that appears in the model will not 66 necessarily be an element of an interoperable protocol, and may not 67 even be a good idea. 69 In this document, each element of the model appears in upper case 70 (e.g., PRESENCE SERVICE). No term in lower case or mixed case is 71 intended to be a term of the model. 73 The first part of this document is intended as an overview of the 74 model. The overview includes diagrams, and terms are presented in an 75 order that is intended to help the reader understand the relationship 76 between elements. The second part of the document is the actual 77 definition of the model, with terms presented in alphabetical order 78 for ease of reference. 80 The overview is intended to be helpful but is not definitive; it may 81 contain inadvertent differences from the definitions in the model. For 82 any such difference, the definition(s) in the model are taken to be 83 correct, rather than the explanation(s) in the overview. 85 3. Overview 87 The model is intended to provide a means for understanding, comparing, 88 and describing systems that support the services typically referred to 89 as presence and instant messaging. It consists of a number of named 90 entities that appear, in some form, in existing systems. No actual 91 implementation is likely to have every entity of the model as a 92 distinct part. Instead, there will almost always be parts of the 93 implementation that embody two or more entities of the model. However, 94 different implementations may combine entities in different ways. 96 The model defines two services: a PRESENCE SERVICE and an INSTANT 97 MESSAGE SERVICE. The PRESENCE SERVICE serves to accept information, 98 store it, and distribute it. The information stored is 99 (unsurprisingly) PRESENCE INFORMATION. The INSTANT MESSAGE SERVICE 100 serves to accept and deliver INSTANT MESSAGES to INSTANT 101 INBOXES. 103 3.1 PRESENCE SERVICE 105 The PRESENCE SERVICE has two distinct sets of "clients" (remember, 106 these may be combined in an implementation, but treated separately in 107 the model). One set of clients, called PRESENTITIES, provides 108 PRESENCE INFORMATION to be stored and distributed. The other set of 109 clients, called WATCHERS, receives PRESENCE INFORMATION from the 110 service. 112 +---------------------------+ 113 | PRESENCE SERVICE | 114 | | 115 +---------------------------+ 116 ^ | 117 | | 118 | v 119 +------------+ +------------+ 120 | PRESENTITY | | WATCHER | 121 +------------+ +------------+ 123 Fig. 1: Overview of Presence Service 125 There are two kinds of WATCHERS, called FETCHERS and SUBSCRIBERS. A 126 FETCHER simply requests the current value of some PRESENTITY's 127 PRESENCE INFORMATION from the PRESENCE SERVICE. In contrast, a 128 SUBSCRIBER requests notification from the PRESENCE SERVICE of (future) 129 changes in some PRESENTITY's PRESENCE INFORMATION. A special kind of 130 FETCHER is one that fetches information on a regular basis. This is 131 called a POLLER. 133 +----------------WATCHER---------------+ 134 | | 135 | +----FETCHER---+ +--SUBSCRIBER--+ | 136 | | | | | | 137 | | +--POLLER--+ | | | | 138 | | | | | | | | 139 | | +----------+ | | | | 140 | +--------------+ +--------------+ | 141 +--------------------------------------+ 143 Fig. 2: Varieties of WATCHER 145 The PRESENCE SERVICE also has WATCHER INFORMATION about WATCHERS and 146 their activities in terms of fetching or subscribing to PRESENCE 147 INFORMATION. The PRESENCE SERVICE may also distribute WATCHER 148 INFORMATION to some WATCHERS, using the same mechanisms that are 149 available for distributing PRESENCE INFORMATION. 151 Changes to PRESENCE INFORMATION are distributed to SUBSCRIBERS via 152 NOTIFICATIONS. Figures 3a through 3c show the flow of information as a 153 piece of PRESENCE INFORMATION is changed from P1 to P2. 155 +---------------------------+ 156 | PRESENCE SERVICE | 157 | P1 | 158 +---------------------------+ 160 +------------+ +------------+ 161 | P1->P2 | | P1 | 162 | PRESENTITY | | SUBSCRIBER | 163 +------------+ +------------+ 165 Fig. 3a: NOTIFICATION (Step 1) 167 +---------------------------+ 168 | PRESENCE SERVICE | 169 | P1->P2 | 170 +---------------------------+ 171 ^ 172 |P2 173 +------------+ +------------+ 174 | P2 | | P1 | 175 | PRESENTITY | | SUBSCRIBER | 176 +------------+ +------------+ 178 Fig. 3b: NOTIFICATION (Step 2) 180 +---------------------------+ 181 | PRESENCE SERVICE | 182 | P2 | 183 +---------------------------+ 184 |P2 185 v 186 +------------+ +------------+ 187 | P2 | | P1->P2 | 188 | PRESENTITY | | SUBSCRIBER | 189 +------------+ +------------+ 191 Fig. 3c: NOTIFICATION (Step 3) 193 3.2 INSTANT MESSAGE SERVICE 195 The INSTANT MESSAGE SERVICE also has two distinct sets of "clients": 196 SENDERS and INSTANT INBOXES. A SENDER provides INSTANT MESSAGES to the 197 INSTANT MESSAGE SERVICE for delivery. Each INSTANT MESSAGE is 198 addressed to a particular INSTANT INBOX ADDRESS, and the INSTANT 199 MESSAGE SERVICE attempts to deliver the message to a corresponding 200 INSTANT INBOX. 202 +---------------------------+ 203 | INSTANT MESSAGE SERVICE | 204 | | 205 +---------------------------+ 206 ^ | 207 | | 208 | v 209 +------------+ +---------------+ 210 | SENDER | | INSTANT INBOX | 211 +------------+ +---------------+ 213 Fig. 4: Overview of Instant Message Service 215 3.3 Protocols 217 A PRESENCE PROTOCOL defines the interaction between PRESENCE SERVICE, 218 PRESENTITIES, and WATCHERS. PRESENCE INFORMATION is carried by the 219 PRESENCE PROTOCOL. 221 An INSTANT MESSAGE PROTOCOL defines the interaction between INSTANT 222 MESSAGE SERVICE, SENDERS, and INSTANT INBOXES. INSTANT MESSAGES are 223 carried by the INSTANT MESSAGE PROTOCOL. 225 In terms of this model, we believe that the IMPP working 226 group is planning to develop detailed requirements and specifications 227 for the structure and formats of the PRESENCE PROTOCOL, PRESENCE 228 INFORMATION, INSTANT MESSAGE PROTOCOL, and INSTANT MESSAGES. 230 3.4 Formats 232 The model defines the PRESENCE INFORMATION to consist of an arbitrary 233 number of elements, called PRESENCE TUPLES. Each such element consists 234 of a STATUS marker (which might convey information such as 235 online/offline/busy/away/do not disturb), an optional COMMUNICATION 236 ADDRESS, and optional OTHER PRESENCE MARKUP. A COMMUNICATION ADDRESS 237 includes a COMMUNICATION MEANS and a CONTACT ADDRESS. One type of 238 COMMUNICATION MEANS, and the only one defined by this model, is 239 INSTANT MESSAGE SERVICE. One type of CONTACT ADDRESS, and the only 240 one defined by this model, is INSTANT INBOX ADDRESS. However, other 241 possibilities exist: a COMMUNICATION MEANS might indicate some form of 242 telephony, for example, with the corresponding CONTACT ADDRESS 243 containing a telephone number. 245 +------------------------------------+ 247 | PRESENCE INFORMATION | 248 +------------------------------------+ 249 | +-------------------------------+ 250 =>| PRESENCE TUPLE | 251 | +-------------------------------+ 252 | | +-------------------------+ 253 | =>| STATUS | 254 | | +-------------------------+ 255 | | +-------------------------+ 256 | =>| COMMUNICATION ADDRESS | 257 | | +-------------------------+ 258 | | | +-----------------+ 259 | | =>| CONTACT MEANS | 260 | | | +-----------------+ 261 | | | +-----------------+ 262 | | =>| CONTACT ADDRESS | 263 | | +-----------------+ 264 | | +-------------------------+ 265 | =>| OTHER MARKUP | 266 | +-------------------------+ 267 | +-------------------------------+ 268 =>| PRESENCE TUPLE | 269 | +-------------------------------+ 270 | | +-------------------------+ 271 | =>| STATUS | 272 | | +-------------------------+ 273 | | +-------------------------+ 274 | =>| COMMUNICATION ADDRESS | 275 | | +-------------------------+ 276 | | | +-----------------+ 277 | | =>| CONTACT MEANS | 278 | | | +-----------------+ 279 | | | +-----------------+ 280 | | =>| CONTACT ADDRESS | 281 | | +-----------------+ 282 | | +-------------------------+ 283 | =>| OTHER MARKUP | 284 | +-------------------------+ 285 | +-------------------------------+ 286 =>| PRESENCE TUPLE | 287 | +-------------------------------+ 288 | ... 290 Fig. 5: The structure of PRESENCE INFORMATION 292 STATUS is further defined by the model to have at least two states 293 that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT 294 MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will 295 not be accepted. OPEN and CLOSED may also be applicable to other 296 COMMUNICATION MEANS -- OPEN mapping to some state meaning "available" 297 or "open for business" while CLOSED means "unavailable" or "closed to 298 business." The model allows STATUS to include other values, which may 299 be interpretable by programs or only by persons. The model also 300 allows STATUS to consist of single or multiple values. 302 3.5 Presence and its effect on Instant Messages 304 An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT 305 INBOX ADDRESS is the information that can be included in PRESENCE 306 INFORMATION to define how an INSTANT MESSAGE should be delivered to 307 that INSTANT INBOX. As noted above, certain values of the STATUS 308 marker indicate whether INSTANT MESSAGES will be accepted at the 309 INSTANT INBOX. The model does not otherwise constrain the delivery 310 mechanism or format for instant messages. Reasonable people can 311 disagree about whether this omission is a strength or a weakness of 312 this model. 314 3.6 PRINCIPALS and their agents 316 This model includes other elements that are useful in characterizing 317 how the protocol and markup work. PRINCIPALS are the people, groups, 318 and/or software in the "real world" outside the system that use the 319 system as a means of coordination and communication. It is entirely 320 outside the model how the real world maps onto PRINCIPALS -- the 321 system of model entities knows only that two distinct PRINCIPALS are 322 distinct, and two identical PRINCIPALS are identical. 324 A PRINCIPAL interacts with the system via one of several user agents 325 (INBOX USER AGENT; SENDER USER AGENT; PRESENCE USER AGENT; WATCHER 326 USER AGENT). As usual, the different kinds of user agents are split 327 apart in this model even though most implementations will combine at 328 least some of them. A user agent is purely coupling between a 329 PRINCIPAL and some core entity of the system (respectively, INSTANT 330 INBOX; SENDER; PRESENTITY; WATCHER). 332 +---------------------------+ 333 | PRESENCE SERVICE | 334 +---------------------------+ 335 ^ | 336 | PRESENCE PROTOCOL | 337 | v 338 +------------+ +------------+ 339 | PRESENTITY | | WATCHER | 340 +------------+ +------------+ 341 ^ ^ 342 | | 343 | | 344 o +--------------+ +-------------+ o 345 /|\ -->| PRESENCE UA | | WATCHER UA |<-- /|\ 346 X +--------------+ +-------------+ X 348 (PRINCIPAL) (PRINCIPAL) 350 Fig. 6: A presence system 352 +---------------------------+ 353 | INSTANT MESSAGE SERVICE | 354 +---------------------------+ 355 ^ | 356 IM| INSTANT MESSAGE |IM 357 | PROTOCOL v 358 +------------+ +---------------+ 359 | SENDER | | INSTANT INBOX | 360 +------------+ +---------------+ 361 ^ ^ 362 | | 363 | | 364 o +-------------+ +------------------+ o 365 /|\ -->| SENDER UA | | INSTANT INBOX UA |<-- /|\ 367 X +-------------+ +------------------+ X 369 (PRINCIPAL) (PRINCIPAL) 371 Fig. 7: An instant messaging system 373 3.7 Examples 375 A simple example of applying the model is to describe a generic "buddy 376 list" application. These applications typically expose the user's 377 presence to others, and make it possible to see the presence of 378 others. So we could describe a buddy list as the combination of a 379 PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL, 380 using a single PRESENTITY and a single SUBSCRIBER. 382 We could then extend our example to instant messaging and describe a 383 generic "instant messenger" as essentially a buddy list with 384 additional capabilities for sending and receiving instant messages. So 385 an instant messenger would be the combination of a PRESENCE USER 386 AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER USER 387 AGENT for a single PRINCIPAL, using a single PRESENTITY, single 388 SUBSCRIBER, and single INSTANT INBOX, with the PRESENTITY's PRESENCE 389 INFORMATION including an INSTANT INBOX ADDRESS that leads to the 391 INSTANT INBOX. 393 4. Model 395 ACCESS RULES: constraints on how a PRESENCE SERVICE makes PRESENCE 396 INFORMATION available to WATCHERS. For each PRESENTITY's PRESENCE 398 INFORMATION, the applicable ACCESS RULES are manipulated by the 399 PRESENCE USER AGENT of a PRINCIPAL that controls the PRESENTITY. 401 Motivation: We need some way of talking about hiding presence 402 information from people. 404 CLOSED: a distinguished value of the STATUS marker. In the context of 405 INSTANT MESSAGES, this value means that the associated INSTANT INBOX 406 ADDRESS, if any, corresponds to an INSTANT INBOX that is unable to 407 accept an INSTANT MESSAGE. This value may have an analogous meaning 408 for other COMMUNICATION MEANS, but any such meaning is not defined by 409 this model. Contrast with OPEN. 411 COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT 412 ADDRESS. 414 COMMUNICATION MEANS: indicates a method whereby communication can take 415 place. INSTANT MESSAGE SERVICE is one example of a COMMUNICATION MEANS. 417 CONTACT ADDRESS: a specific point of contact via some COMMUNICATION 418 MEANS. When using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS is 419 an INSTANT INBOX ADDRESS. 421 DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE delivers 422 received INSTANT MESSAGES to INSTANT INBOXES. For each INSTANT INBOX, 423 the applicable DELIVERY RULES are manipulated by the INBOX USER AGENT 424 of a PRINCIPAL that controls the INSTANT INBOX. 426 Motivation: We need a way of talking about filtering instant 427 messages. 429 FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE to 430 for the PRESENCE INFORMATION of one or more PRESENTITIES, but has 431 not asked for a SUBSCRIPTION to be created. 433 INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more 434 INSTANT INBOXES controlled by that PRINCIPAL. 436 Motivation: This is intended to isolate the core functionality of an 437 INSTANT INBOX from how it might appear to be manipulated by a 438 product. This manipulation includes fetching messages, deleting 439 messages, and setting DELIVERY RULES. We deliberately take no position 440 on whether the INBOX USER AGENT, INSTANT INBOX, and INSTANT MESSAGE 441 SERVICE are colocated or distributed across machines. 443 INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by 445 the INSTANT INBOX's PRINCIPAL. 447 INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's 448 PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The 449 STATUS and INSTANT INBOX ADDRESS information are sufficient to 450 determine whether the PRINCIPAL appears ready to accept the INSTANT 451 MESSAGE. 453 Motivation: The definition is pretty loose about exactly how 455 any of this works, even leaving open the possibility of reusing parts 456 of the email infrastructure for instant messaging. 458 INSTANT MESSAGE: an identifiable unit of data, of small size, to be 459 sent to an INSTANT INBOX. 461 Motivation: We do not define "small" but we seek in this 462 definition to avoid the possibility of transporting an 463 arbitrary-length stream labelled as an "instant message." 465 INSTANT MESSAGE PROTOCOL: The messages that can be exchanged between 466 a SENDER USER AGENT and an INSTANT MESSAGE SERVICE, or 467 between an INSTANT MESSAGE SERVICE and an INSTANT INBOX. 469 INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES. 471 -- May require authentication of SENDER USER AGENTS and/or 472 INSTANT INBOXES. 474 -- May have different authentication requirements for different 475 INSTANT INBOXES, and may also have different authentication 476 requirements for different INSTANT INBOXES controlled by a 478 single PRINCIPAL. 480 -- May have an internal structure involving multiple SERVERS 481 and/or PROXIES. There may be complex patterns of redirection 482 and/or proxying while retaining logical connectivity to a single 483 INSTANT MESSAGE SERVICE. Note that an INSTANT MESSAGE SERVICE does 484 not require having a distinct SERVER -- the service may be 485 implemented as direct communication between SENDER and INSTANT 486 INBOX. 488 -- May have an internal structure involving other INSTANT MESSAGE 489 SERVICES, which may be independently accessible in their own right as 490 well as being reachable through the initial INSTANT MESSAGE SERVICE. 492 SENDER USER AGENT: means for a PRINCIPAL to manipulate zero or more 493 SENDERS. 495 NOTIFICATION: a message sent from the PRESENCE SERVICE to a SUBSCRIBER 496 when there is a change in the PRESENCE INFORMATION of some PRESENTITY 497 of interest, as recorded in one or more SUBSCRIPTIONS. 499 Motivation: We deliberately take no position on what part of the 500 changed information is included in a NOTIFICATION. 502 OPEN: a distinguished value of the STATUS marker. In the context of 503 INSTANT MESSAGES, this value means that the associated INSTANT 504 INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is 505 ready to accept an INSTANT MESSAGE. This value may have an 506 analogous meaning for other COMMUNICATION MEANS, but any such 507 meaning is not defined by this model. Contrast with CLOSED. 509 OTHER PRESENCE MARKUP: any additional information included in the 510 PRESENCE INFORMATION of a PRESENTITY. The model does not define this 511 further. 513 POLLER: a FETCHER that requests PRESENCE INFORMATION on a regular basis. 515 PRESENCE INFORMATION: consists of one or more PRESENCE TUPLES. 517 PRESENCE PROTOCOL: The messages that can be exchanged between a 518 PRESENTITY and a PRESENCE SERVICE, or a WATCHER and a PRESENCE 519 SERVICE. 521 PRESENCE SERVICE: accepts, stores, and distributes PRESENCE 522 INFORMATION. 524 -- May require authentication of PRESENTITIES, and/or WATCHERS, and/or 525 INSTANT INBOXES. 527 -- May have different authentication requirements for different 528 PRESENTITIES. 530 -- May have different authentication requirements for different 531 WATCHERS, and may also have different authentication requirements 532 for different PRESENTITIES being watched by a single WATCHER. 534 -- May have an internal structure involving multiple SERVERS 535 and/or PROXIES. There may be complex patterns of redirection 536 and/or proxying while retaining logical connectivity to a single 537 PRESENCE SERVICE. Note that a PRESENCE SERVICE does not require 538 having a distinct SERVER -- the service may be implemented as 539 direct communication among PRESENTITY and WATCHERS. 541 -- May have an internal structure involving other PRESENCE SERVICES, 542 which may be independently accessible in their own right as well 544 as being reachable through the initial PRESENCE SERVICE. 546 PRESENCE TUPLE: consists of a STATUS, an optional COMMUNICATION 547 ADDRESS, and optional OTHER PRESENCE MARKUP. 549 PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more 550 PRESENTITIES. 552 Motivation: This is essentially a "model/view" distinction: the 554 PRESENTITY is the model of the presence being exposed, and is 555 independent of its manifestation in any user interface. In 556 addition, we deliberately take no position on how the PRESENCE 557 USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or 558 distributed across machines. 560 PRESENTITY (presence entity): provides PRESENCE INFORMATION to a 561 PRESENCE SERVICE. 563 Motivation: We don't like to coin new words, but "presentity" 564 seemed worthwhile so as to have an unambiguous term for the entity 565 of interest to a presence service. Note that the presentity is not 566 (usually) located in the presence service: the presence service 567 only has a recent version of the presentity's presence 568 information. The presentity initiates changes in the presence 569 information to be distributed by the presence service. 571 PRINCIPAL: human, program, or collection of humans and/or programs 572 that chooses to appear to the PRESENCE SERVICE as a single actor, 573 distinct from all other PRINCIPALS. 575 Motivation: We need a clear notion of the actors outside the 576 system. "Principal" seems as good a term as any. 578 PROXY: a SERVER that communicates PRESENCE INFORMATION, INSTANT 579 MESSAGES, SUBSCRIPTIONS and/or NOTIFICATIONS to another SERVER. Sometimes 581 a PROXY acts on behalf of a PRESENTITY, WATCHER, or INSTANT INBOX. 583 SENDER: source of INSTANT MESSAGES to be delivered by the INSTANT 584 MESSAGE SERVICE. 586 SERVER: an indivisible unit of a PRESENCE SERVICE or INSTANT MESSAGE SERVICE. 588 SPAM: unwanted INSTANT MESSAGES. 590 SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL. 592 STALKING: using PRESENCE INFORMATION to infer the whereabouts of a 593 PRINCIPAL, especially for malicious or illegal purposes. 595 STATUS: a distinguished part of the PRESENCE INFORMATION of a 596 PRESENTITY. STATUS has at least the mutually-exclusive values OPEN 597 and CLOSED, which have meaning for the acceptance of INSTANT MESSAGES, 598 and may have meaning for other COMMUNICATION MEANS. There may be other 599 values of STATUS that do not imply anything about INSTANT MESSAGE 600 acceptance. These other values of STATUS may be combined with OPEN and 601 CLOSED or they may be mutually-exclusive with those values. 603 Some implementations may combine STATUS with other entities. For 604 example, an implementation might make an INSTANT INBOX ADDRESS 605 visible only when the INSTANT INBOX can accept an INSTANT 606 MESSAGE. Then, the existence of an INSTANT INBOX ADDRESS implies 607 OPEN, while its absence implies CLOSED. 609 SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to 610 notify it immediately of changes in the PRESENCE INFORMATION of one or 611 more PRESENTITIES. 613 SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a 614 SUBSCRIBER's request to be notified of changes in the PRESENCE 615 INFORMATION of one or more PRESENTITIES. 617 VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes 618 WATCHER INFORMATION available to WATCHERS. For each WATCHER's WATCHER 619 INFORMATION, the applicable VISIBILITY RULES are manipulated by the 620 WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER. 622 Motivation: We need a way of talking about hiding watcher information 623 from people. 625 WATCHER: requests PRESENCE INFORMATION about a PRESENTITY, or 626 WATCHER INFORMATION about a WATCHER, from the PRESENCE 627 SERVICE. Special types of WATCHER are FETCHER, POLLER, and 628 SUBSCRIBER. 630 WATCHER INFORMATION: information about WATCHERS that have received 631 PRESENCE INFORMATION about a particular PRESENTITY within a particular 632 recent span of time. WATCHER INFORMATION is maintained by the PRESENCE 633 SERVICE, which may choose to present it in the same form as PRESENCE 634 INFORMATION; that is, the service may choose to make WATCHERS look 635 like a special form of PRESENTITY. 637 Motivation: If a PRESENTITY wants to know who knows about it, it 638 is not enough to examine only information about SUBSCRIPTIONS. A 639 WATCHER might repeatedly fetch information without ever 640 subscribing. Alternately, a WATCHER might repeatedly subscribe, 641 then cancel the SUBSCRIPTION. Such WATCHERS should be visible to 642 the PRESENTITY if the PRESENCE SERVICE offers WATCHER INFORMATION, 643 but will not be appropriately visible if the WATCHER INFORMATION 644 includes only SUBSCRIPTIONS. 646 WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or 647 more WATCHERS controlled by that PRINCIPAL. 649 Motivation: As with PRESENCE USER AGENT and PRESENTITY, the 650 distinction here is intended to isolate the core functionality of a 652 WATCHER from how it might appear to be manipulated by a product. As 653 previously, we deliberately take no position on whether the WATCHER 654 USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or distributed 655 across machines. 657 5. Security Considerations 659 This document provides a model and vocabulary for systems with certain 660 intrinsic security issues. In particular, presence and instant 661 messaging systems must deal with "the three S's": STALKING, SPOOFING, 662 and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER INFORMATION are 663 intended to deal with STALKING. The several kinds of authentication 664 mentioned for INSTANT MESSAGE SERVICE and PRESENCE SERVICE are 665 intended to deal with SPOOFING. DELIVERY RULES are intended to deal 666 with SPAM. 668 6. Conclusion 670 This document has provided a model for a presence and instant 671 messaging system. The purpose of the model is to provide a common 672 vocabulary for the further work of defining and implementing 673 interoperable presence and instant messaging protocols. 675 7. Acknowledgements 677 This document has been improved by comments from Jesse Vincent and 678 Colin Benson, by the participants in the Cambridge, MA meeting on June 679 11, 1999, and by Roy Salisbury, who contributed the original version 680 of Figure 5. The authors gratefully acknowledge their assistance. 682 8. References 684 [ENVY] M. Day. ''HTTP Envy'' and Presence Information Protocols. 685 Internet-Draft draft-day-envy-00.txt 687 [PIPR] M. Calsyn, L. Dusseault. Presence Information Protocol 688 Requirements. Internet-Draft draft-dusseault-pipr-00.txt 690 [PRESENCE] V. Saraswat, J. Malcolm, C. Apple. The Presence 691 Protocol. Internet-Draft draft-saraswat-presenceprotocol-00.txt 693 [RPIM] M. Day. Requirements for Presence and Instant Messaging. 694 Internet-Draft draft-day-rpim-00.txt 696 [RVP-ADDR] L. Dusseault, G. Mohr. Addressing and Location for 697 RVP. Internet-Draft draft-dusseault-rvp-addr-00.txt 699 [RVP] M. Calsyn, L. Dusseault, G. Mohr. RVP: A Presence Notification 700 Protocol. Internet-Draft draft-calsyn-rvp-01.txt 702 [SIP-PIP] J. Rosenberg, H.Schulzrinne. SIP For Presence. 703 Internet-Draft draft-rosenberg-sip-pip-00.txt 705 [WHODP] G. Mohr. WhoDP: Widely Hosted Object Data Protocol. 706 Internet-Draft draft-mohr-whodp-00.txt 708 9. Authors' Addresses 710 Mark Day 711 Lotus Development Corporation 712 55 Cambridge Parkway 713 Cambridge, MA 02142 714 USA 715 email: Mark_Day@lotus.com 717 Jonathan Rosenberg 718 Lucent Technologies, Bell Laboratories 719 Rm. 4C-526 720 101 Crawfords Corner Rd. 721 Holmdel, NJ 07733 722 USA 723 email: jdrosen@bell-labs.com 725 Hiroyasu Sugano 726 Fujitsu Laboratories Ltd. 727 64 Nishiwaki, Ohkubo-cho 728 Akashi 674-8555 729 Japan 730 email: suga@flab.fujitsu.co.jp