idnits 2.17.1 draft-ietf-impp-model-02.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 744 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. ** There is 1 instance of lines with control characters in the document. 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 668, but no explicit reference was found in the text == Unused Reference: 'PIPR' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'PRESENCE' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RPIM' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RVP-ADDR' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RVP' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'SIP-PIP' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'WHODP' is defined on line 689, 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: 6 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 23, 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-02.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 55 valuable to first develop a model for the system. The model consists 56 of the various entities involved, descriptions of the basic functions 57 they provide, and most importantly, definition of a vocabulary which 58 can be used to facilitate discussion. 60 We note that the purpose of this model is to be descriptive and 61 universal: we want the model to map reasonably onto all of the systems 62 that are informally described as presence or instant messaging 63 systems. The model is not intended to be prescriptive or achieve 64 interoperability: an element that appears in the model will not 65 necessarily be an element of an interoperable protocol, and may not 66 even be a good idea. 68 In this document, each element of the model appears in upper case 69 (e.g., PRESENCE SERVICE). No term in lower case or mixed case is 70 intended to be a term of the model. 72 The first part of this document is intended as an overview of the 73 model. The overview includes diagrams, and terms are presented in an 74 order that is intended to help the reader understand the relationship 75 between elements. The second part of the document is the actual 76 definition of the model, with terms presented in alphabetical order 77 for ease of reference. 79 The overview is intended to be helpful but is not definitive; it may 80 contain inadvertent differences from the definitions in the model. For 81 any such difference, the definition(s) in the model are taken to be 82 correct, rather than the explanation(s) in the overview. 84 3. Overview 86 The model is intended to provide a means for understanding, comparing, 87 and describing systems that support the services typically referred to 88 as presence and instant messaging. It consists of a number of named 89 entities that appear, in some form, in existing systems. No actual 90 implementation is likely to have every entity of the model as a 91 distinct part. Instead, there will almost always be parts of the 92 implementation that embody two or more entities of the model. However, 93 different implementations may combine entities in different ways. 95 The model defines two services: a PRESENCE SERVICE and an INSTANT 96 MESSAGE SERVICE. The PRESENCE SERVICE serves to accept information, 97 store it, and distribute it. The information stored is 98 (unsurprisingly) PRESENCE INFORMATION. The INSTANT MESSAGE SERVICE 99 serves to accept and deliver INSTANT MESSAGES to INSTANT 100 INBOXES. 102 3.1 PRESENCE SERVICE 104 The PRESENCE SERVICE has two distinct sets of "clients" (remember, 105 these may be combined in an implementation, but treated separately in 106 the model). One set of clients, called PRESENTITIES, provides 107 PRESENCE INFORMATION to be stored and distributed. The other set of 108 clients, called WATCHERS, receives PRESENCE INFORMATION from the 109 service. 111 +---------------------------+ 112 | PRESENCE SERVICE | 113 | | 114 +---------------------------+ 115 ^ | 116 | | 117 | v 118 +------------+ +------------+ 119 | PRESENTITY | | WATCHER | 120 +------------+ +------------+ 122 Fig. 1: Overview of Presence Service 124 There are two kinds of WATCHERS, called FETCHERS and SUBSCRIBERS. A 125 FETCHER simply requests the current value of some PRESENTITY's 126 PRESENCE INFORMATION from the PRESENCE SERVICE. In contrast, a 127 SUBSCRIBER requests notification from the PRESENCE SERVICE of (future) 128 changes in some PRESENTITY's PRESENCE INFORMATION. A special kind of 129 FETCHER is one that fetches information on a regular basis. This is 130 called a POLLER. 132 +----------------WATCHER---------------+ 133 | | 134 | +----FETCHER---+ +--SUBSCRIBER--+ | 135 | | | | | | 136 | | +--POLLER--+ | | | | 137 | | | | | | | | 138 | | +----------+ | | | | 139 | +--------------+ +--------------+ | 140 +--------------------------------------+ 142 Fig. 2: Varieties of WATCHER 144 The PRESENCE SERVICE also has WATCHER INFORMATION about WATCHERS and 145 their activities in terms of fetching or subscribing to PRESENCE 146 INFORMATION. The PRESENCE SERVICE may also distribute WATCHER 147 INFORMATION to some WATCHERS, using the same mechanisms that are 148 available for distributing PRESENCE INFORMATION. 150 Changes to PRESENCE INFORMATION are distributed to SUBSCRIBERS via 151 NOTIFICATIONS. Figures 3a through 3c show the flow of information as a 152 piece of PRESENCE INFORMATION is changed from P1 to P2. 154 +---------------------------+ 155 | PRESENCE SERVICE | 156 | P1 | 157 +---------------------------+ 159 +------------+ +------------+ 160 | P1->P2 | | P1 | 161 | PRESENTITY | | SUBSCRIBER | 162 +------------+ +------------+ 164 Fig. 3a: NOTIFICATION (Step 1) 166 +---------------------------+ 167 | PRESENCE SERVICE | 168 | P1->P2 | 169 +---------------------------+ 170 ^ 171 |P2 172 +------------+ +------------+ 173 | P2 | | P1 | 174 | PRESENTITY | | SUBSCRIBER | 175 +------------+ +------------+ 177 Fig. 3b: NOTIFICATION (Step 2) 179 +---------------------------+ 180 | PRESENCE SERVICE | 181 | P2 | 182 +---------------------------+ 183 |P2 184 v 185 +------------+ +------------+ 186 | P2 | | P1->P2 | 187 | PRESENTITY | | SUBSCRIBER | 188 +------------+ +------------+ 190 Fig. 3c: NOTIFICATION (Step 3) 192 3.2 INSTANT MESSAGE SERVICE 194 The INSTANT MESSAGE SERVICE also has two distinct sets of "clients": 195 SENDERS and INSTANT INBOXES. A SENDER provides INSTANT MESSAGES to the 196 INSTANT MESSAGE SERVICE for delivery. Each INSTANT MESSAGE is 197 addressed to a particular INSTANT INBOX ADDRESS, and the INSTANT 198 MESSAGE SERVICE attempts to deliver the message to a corresponding 199 INSTANT INBOX. 201 +---------------------------+ 202 | INSTANT MESSAGE SERVICE | 203 | | 204 +---------------------------+ 205 ^ | 206 | | 207 | v 208 +------------+ +---------------+ 209 | SENDER | | INSTANT INBOX | 210 +------------+ +---------------+ 212 Fig. 4: Overview of Instant Message Service 214 3.3 Protocols 216 A PRESENCE PROTOCOL defines the interaction between PRESENCE SERVICE, 217 PRESENTITIES, and WATCHERS. PRESENCE INFORMATION is carried by the 218 PRESENCE PROTOCOL. 220 An INSTANT MESSAGE PROTOCOL defines the interaction between INSTANT 221 MESSAGE SERVICE, SENDERS, and INSTANT INBOXES. INSTANT MESSAGES are 222 carried by the INSTANT MESSAGE PROTOCOL. 224 In terms of this model, we believe that the IMPP working 225 group is planning to develop detailed requirements and specifications 226 for the structure and formats of the PRESENCE PROTOCOL, PRESENCE 227 INFORMATION, INSTANT MESSAGE PROTOCOL, and INSTANT MESSAGES. 229 3.4 Formats 231 The model defines the PRESENCE INFORMATION to consist of an arbitrary 232 number of elements, called PRESENCE TUPLES. Each such element consists 233 of a STATUS marker (which might convey information such as 234 online/offline/busy/away/do not disturb), an optional COMMUNICATION 235 ADDRESS, and optional OTHER PRESENCE MARKUP. A COMMUNICATION ADDRESS 236 includes a COMMUNICATION MEANS and a CONTACT ADDRESS. One type of 237 COMMUNICATION MEANS, and the only one defined by this model, is 238 INSTANT MESSAGE SERVICE. One type of CONTACT ADDRESS, and the only 239 one defined by this model, is INSTANT INBOX ADDRESS. However, other 240 possibilities exist: a COMMUNICATION MEANS might indicate some form of 241 telephony, for example, with the corresponding CONTACT ADDRESS 242 containing a telephone number. 244 +--------------------------------+ 245 | PRESENCE INFORMATION | 246 +--------------------------------+ 247 | +--------------------------+ 248 =>| PRESENCE TUPLE | 249 | +--------------------------+ 250 | | +-------------------+ 251 | =>| CONTACT ADDRESS | 252 | | +-------------------+ 253 | | +-------------------+ 254 | =>| STATUS | 255 | | +-------------------+ 256 | | +-------------------+ 257 | =>| OTHER MARKUP | 258 | +-------------------+ 259 | +--------------------------+ 260 =>| PRESENCE TUPLE | 261 | +--------------------------+ 262 | | +-------------------+ 263 | =>| CONTACT ADDRESS | 264 | | +-------------------+ 265 | | +-------------------+ 266 | =>| STATUS | 267 | | +-------------------+ 268 | | +-------------------+ 269 | =>| OTHER MARKUP | 270 | +-------------------+ 271 | +--------------------------+ 272 =>| PRESENCE TUPLE | 273 +--------------------------+ 274 | +-------------------+ 275 =>| CONTACT ADDRESS | 276 | +-------------------+ 277 | +-------------------+ 278 =>| STATUS | 279 | +-------------------+ 280 | +-------------------+ 281 =>| OTHER MARKUP | 282 +-------------------+ 284 Fig. 5: The structure of PRESENCE INFORMATION 286 STATUS is further defined by the model to have at least two states 287 that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT 288 MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will 289 not be accepted. OPEN and CLOSED may also be applicable to other 290 COMMUNICATION MEANS -- OPEN mapping to some state meaning "available" 291 or "open for business" while CLOSED means "unavailable" or "closed to 292 business." The model allows STATUS to include other values, which may 293 be interpretable by programs or only by persons. The model also 294 allows STATUS to consist of single or multiple values. 296 3.5 Presence and its effect on Instant Messages 298 An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT 299 INBOX ADDRESS is the information that can be included in PRESENCE 300 INFORMATION to define how an INSTANT MESSAGE should be delivered to 301 that INSTANT INBOX. As noted above, certain values of the STATUS 302 marker indicate whether INSTANT MESSAGES will be accepted at the 303 INSTANT INBOX. The model does not otherwise constrain the delivery 304 mechanism or format for instant messages. Reasonable people can 305 disagree about whether this omission is a strength or a weakness of 306 this model. 308 3.6 PRINCIPALS and their agents 310 This model includes other elements that are useful in characterizing 311 how the protocol and markup work. PRINCIPALS are the people, groups, 312 and/or software in the "real world" outside the system that use the 313 system as a means of coordination and communication. It is entirely 314 outside the model how the real world maps onto PRINCIPALS -- the 315 system of model entities knows only that two distinct PRINCIPALS are 316 distinct, and two identical PRINCIPALS are identical. 318 A PRINCIPAL interacts with the system via one of several user agents 319 (INBOX USER AGENT; SENDER USER AGENT; PRESENCE USER AGENT; WATCHER 320 USER AGENT). As usual, the different kinds of user agents are split 321 apart in this model even though most implementations will combine at 322 least some of them. A user agent is purely coupling between a 323 PRINCIPAL and some core entity of the system (respectively, INSTANT 324 INBOX; SENDER; PRESENTITY; WATCHER). 326 +---------------------------+ 327 | PRESENCE SERVICE | 328 +---------------------------+ 329 ^ | 330 | PRESENCE PROTOCOL | 331 | v 332 +------------+ +------------+ 333 | PRESENTITY | | WATCHER | 334 +------------+ +------------+ 335 ^ ^ 336 | | 337 | | 338 o +--------------+ +-------------+ o 339 /|\ -->| PRESENCE UA | | WATCHER UA |<-- /|\ 340 X +--------------+ +-------------+ X 342 (PRINCIPAL) (PRINCIPAL) 344 Fig. 6: A presence system 346 +---------------------------+ 347 | INSTANT MESSAGE SERVICE | 348 +---------------------------+ 349 ^ | 350 IM| INSTANT MESSAGE |IM 351 | PROTOCOL v 352 +------------+ +---------------+ 353 | SENDER | | INSTANT INBOX | 354 +------------+ +---------------+ 355 ^ ^ 356 | | 357 | | 358 o +-------------+ +------------------+ o 359 /|\ -->| SENDER UA | | INSTANT INBOX UA |<-- /|\ 360 X +-------------+ +------------------+ X 362 (PRINCIPAL) (PRINCIPAL) 364 Fig. 7: An instant messaging system 366 3.7 Examples 368 A simple example of applying the model is to describe a generic "buddy 369 list" application. These applications typically expose the user's 370 presence to others, and make it possible to see the presence of 371 others. So we could describe a buddy list as the combination of a 372 PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL, 373 using a single PRESENTITY and a single SUBSCRIBER. 375 We could then extend our example to instant messaging and describe a 376 generic "instant messenger" as essentially a buddy list with 377 additional capabilities for sending and receiving instant messages. So 378 an instant messenger would be the combination of a PRESENCE USER 379 AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER USER 380 AGENT for a single PRINCIPAL, using a single PRESENTITY, single 381 SUBSCRIBER, and single INSTANT INBOX, with the PRESENTITY's PRESENCE 382 INFORMATION including an INSTANT INBOX ADDRESS that leads to the 383 INSTANT INBOX. 385 4. Model 387 ACCESS RULES: constraints on how a PRESENCE SERVICE makes PRESENCE 388 INFORMATION available to WATCHERS. For each PRESENTITY's PRESENCE 389 INFORMATION, the applicable ACCESS RULES are manipulated by the 390 PRESENCE USER AGENT of a PRINCIPAL that controls the PRESENTITY. 392 Motivation: We need some way of talking about hiding presence 393 information from people. 395 CLOSED: a distinguished value of the STATUS marker. In the context of 396 INSTANT MESSAGES, this value means that the associated INSTANT INBOX 397 ADDRESS, if any, corresponds to an INSTANT INBOX that is unable to 398 accept an INSTANT MESSAGE. This value may have an analogous meaning 399 for other COMMUNICATION MEANS, but any such meaning is not defined by 400 this model. Contrast with OPEN. 402 COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT 403 ADDRESS. 405 COMMUNICATION MEANS: indicates a method whereby communication can take 406 place. INSTANT MESSAGE SERVICE is one example of a COMMUNICATION MEANS. 408 CONTACT ADDRESS: a specific point of contact via some COMMUNICATION 409 MEANS. When using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS is 410 an INSTANT INBOX ADDRESS. 412 DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE delivers 413 received INSTANT MESSAGES to INSTANT INBOXES. For each INSTANT INBOX, 414 the applicable DELIVERY RULES are manipulated by the INBOX USER AGENT 415 of a PRINCIPAL that controls the INSTANT INBOX. 417 Motivation: We need a way of talking about filtering instant 418 messages. 420 FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE to 421 for the PRESENCE INFORMATION of one or more PRESENTITIES, but has 422 not asked for a SUBSCRIPTION to be created. 424 INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more 425 INSTANT INBOXES controlled by that PRINCIPAL. 427 Motivation: This is intended to isolate the core functionality of an 428 INSTANT INBOX from how it might appear to be manipulated by a 429 product. This manipulation includes fetching messages, deleting 430 messages, and setting DELIVERY RULES. We deliberately take no position 431 on whether the INBOX USER AGENT, INSTANT INBOX, and INSTANT MESSAGE 432 SERVICE are colocated or distributed across machines. 434 INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by 435 the INSTANT INBOX's PRINCIPAL. 437 INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's 438 PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The 439 STATUS and INSTANT INBOX ADDRESS information are sufficient to 440 determine whether the PRINCIPAL appears ready to accept the INSTANT 441 MESSAGE. 443 Motivation: The definition is pretty loose about exactly how 444 any of this works, even leaving open the possibility of reusing parts 445 of the email infrastructure for instant messaging. 447 INSTANT MESSAGE: an identifiable unit of data, of small size, to be 448 sent to an INSTANT INBOX. 450 Motivation: We do not define "small" but we seek in this 451 definition to avoid the possibility of transporting an 452 arbitrary-length stream labelled as an "instant message." 454 INSTANT MESSAGE PROTOCOL: The messages that can be exchanged between 455 a SENDER USER AGENT and an INSTANT MESSAGE SERVICE, or 456 between an INSTANT MESSAGE SERVICE and an INSTANT INBOX. 458 INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES. 460 -- May require authentication of SENDER USER AGENTS and/or 461 INSTANT INBOXES. 463 -- May have different authentication requirements for different 464 INSTANT INBOXES, and may also have different authentication 465 requirements for different INSTANT INBOXES controlled by a 466 single PRINCIPAL. 468 -- May have an internal structure involving multiple SERVERS 469 and/or PROXIES. There may be complex patterns of redirection 470 and/or proxying while retaining logical connectivity to a single 471 INSTANT MESSAGE SERVICE. Note that an INSTANT MESSAGE SERVICE does 472 not require having a distinct SERVER -- the service may be 473 implemented as direct communication between SENDER and INSTANT 474 INBOX. 476 -- May have an internal structure involving other INSTANT MESSAGE 477 SERVICES, which may be independently accessible in their own right as 478 well as being reachable through the initial INSTANT MESSAGE SERVICE. 480 SENDER USER AGENT: means for a PRINCIPAL to manipulate zero or more 481 SENDERS. 483 NOTIFICATION: a message sent from the PRESENCE SERVICE to a SUBSCRIBER 484 when there is a change in the PRESENCE INFORMATION of some PRESENTITY 485 of interest, as recorded in one or more SUBSCRIPTIONS. 487 Motivation: We deliberately take no position on what part of the 488 changed information is included in a NOTIFICATION. 490 OPEN: a distinguished value of the STATUS marker. In the context of 491 INSTANT MESSAGES, this value means that the associated INSTANT 492 INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is 493 ready to accept an INSTANT MESSAGE. This value may have an 494 analogous meaning for other COMMUNICATION MEANS, but any such 495 meaning is not defined by this model. Contrast with CLOSED. 497 OTHER PRESENCE MARKUP: any additional information included in the 498 PRESENCE INFORMATION of a PRESENTITY. The model does not define this 499 further. 501 POLLER: a FETCHER that requests PRESENCE INFORMATION on a regular basis. 503 PRESENCE INFORMATION: consists of one or more PRESENCE TUPLES. 505 PRESENCE PROTOCOL: The messages that can be exchanged between a 506 PRESENTITY and a PRESENCE SERVICE, or a WATCHER and a PRESENCE 507 SERVICE. 509 PRESENCE SERVICE: accepts, stores, and distributes PRESENCE 510 INFORMATION. 512 -- May require authentication of PRESENTITIES, and/or WATCHERS, and/or 513 INSTANT INBOXES. 515 -- May have different authentication requirements for different 516 PRESENTITIES. 518 -- May have different authentication requirements for different 519 WATCHERS, and may also have different authentication requirements 520 for different PRESENTITIES being watched by a single WATCHER. 522 -- May have an internal structure involving multiple SERVERS 523 and/or PROXIES. There may be complex patterns of redirection 524 and/or proxying while retaining logical connectivity to a single 525 PRESENCE SERVICE. Note that a PRESENCE SERVICE does not require 526 having a distinct SERVER -- the service may be implemented as 527 direct communication among PRESENTITY and WATCHERS. 529 -- May have an internal structure involving other PRESENCE SERVICES, 530 which may be independently accessible in their own right as well 531 as being reachable through the initial PRESENCE SERVICE. 533 PRESENCE TUPLE: consists of a STATUS, an optional COMMUNICATION 534 ADDRESS, and optional OTHER PRESENCE MARKUP. 536 PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more 537 PRESENTITIES. 539 Motivation: This is essentially a "model/view" distinction: the 540 PRESENTITY is the model of the presence being exposed, and is 541 independent of its manifestation in any user interface. In 542 addition, we deliberately take no position on how the PRESENCE 543 USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or 544 distributed across machines. 546 PRESENTITY (presence entity): provides PRESENCE INFORMATION to a 547 PRESENCE SERVICE. 549 Motivation: We don't like to coin new words, but "presentity" 550 seemed worthwhile so as to have an unambiguous term for the entity 551 of interest to a presence service. Note that the presentity is not 552 (usually) located in the presence service: the presence service 553 only has a recent version of the presentity's presence 554 information. The presentity initiates changes in the presence 555 information to be distributed by the presence service. 557 PRINCIPAL: human, program, or collection of humans and/or programs 558 that chooses to appear to the PRESENCE SERVICE as a single actor, 559 distinct from all other PRINCIPALS. 561 Motivation: We need a clear notion of the actors outside the 562 system. "Principal" seems as good a term as any. 564 PROXY: a SERVER that communicates PRESENCE INFORMATION, INSTANT 565 MESSAGES, SUBSCRIPTIONS and/or NOTIFICATIONS to another SERVER. Sometimes 566 a PROXY acts on behalf of a PRESENTITY, WATCHER, or INSTANT INBOX. 568 SENDER: source of INSTANT MESSAGES to be delivered by the INSTANT 569 MESSAGE SERVICE. 571 SERVER: an indivisible unit of a PRESENCE SERVICE or INSTANT MESSAGE SERVICE. 573 SPAM: unwanted INSTANT MESSAGES. 575 SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL. 577 STALKING: using PRESENCE INFORMATION to infer the whereabouts of a 578 PRINCIPAL, especially for malicious or illegal purposes. 580 STATUS: a distinguished part of the PRESENCE INFORMATION of a 581 PRESENTITY. STATUS has at least the mutually-exclusive values OPEN 582 and CLOSED, which have meaning for the acceptance of INSTANT MESSAGES, 583 and may have meaning for other COMMUNICATION MEANS. There may be other 584 values of STATUS that do not imply anything about INSTANT MESSAGE 585 acceptance. These other values of STATUS may be combined with OPEN and 586 CLOSED or they may be mutually-exclusive with those values. 588 Some implementations may combine STATUS with other entities. For 589 example, an implementation might make an INSTANT INBOX ADDRESS 590 visible only when the INSTANT INBOX can accept an INSTANT 591 MESSAGE. Then, the existence of an INSTANT INBOX ADDRESS implies 592 OPEN, while its absence implies CLOSED. 594 SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to 595 notify it immediately of changes in the PRESENCE INFORMATION of one or 596 more PRESENTITIES. 598 SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a 599 SUBSCRIBER's request to be notified of changes in the PRESENCE 600 INFORMATION of one or more PRESENTITIES. 602 VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes 603 WATCHER INFORMATION available to WATCHERS. For each WATCHER's WATCHER 604 INFORMATION, the applicable VISIBILITY RULES are manipulated by the 605 WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER. 607 Motivation: We need a way of talking about hiding watcher information 608 from people. 610 WATCHER: requests PRESENCE INFORMATION about a PRESENTITY, or 611 WATCHER INFORMATION about a WATCHER, from the PRESENCE 612 SERVICE. Special types of WATCHER are FETCHER, POLLER, and 613 SUBSCRIBER. 615 WATCHER INFORMATION: information about WATCHERS that have received 616 PRESENCE INFORMATION about a particular PRESENTITY within a particular 617 recent span of time. WATCHER INFORMATION is maintained by the PRESENCE 618 SERVICE, which may choose to present it in the same form as PRESENCE 619 INFORMATION; that is, the service may choose to make WATCHERS look 620 like a special form of PRESENTITY. 622 Motivation: If a PRESENTITY wants to know who knows about it, it 623 is not enough to examine only information about SUBSCRIPTIONS. A 624 WATCHER might repeatedly fetch information without ever 625 subscribing. Alternately, a WATCHER might repeatedly subscribe, 626 then cancel the SUBSCRIPTION. Such WATCHERS should be visible to 627 the PRESENTITY if the PRESENCE SERVICE offers WATCHER INFORMATION, 628 but will not be appropriately visible if the WATCHER INFORMATION 629 includes only SUBSCRIPTIONS. 631 WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or 632 more WATCHERS controlled by that PRINCIPAL. 634 Motivation: As with PRESENCE USER AGENT and PRESENTITY, the 635 distinction here is intended to isolate the core functionality of a 636 WATCHER from how it might appear to be manipulated by a product. As 637 previously, we deliberately take no position on whether the WATCHER 638 USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or distributed 639 across machines. 641 5. Security Considerations 643 This document provides a model and vocabulary for systems with certain 644 intrinsic security issues. In particular, presence and instant 645 messaging systems must deal with "the three S's": STALKING, SPOOFING, 646 and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER INFORMATION are 647 intended to deal with STALKING. The several kinds of authentication 648 mentioned for INSTANT MESSAGE SERVICE and PRESENCE SERVICE are 649 intended to deal with SPOOFING. DELIVERY RULES are intended to deal 650 with SPAM. 652 6. Conclusion 654 This document has provided a model for a presence and instant 655 messaging system. The purpose of the model is to provide a common 656 vocabulary for the further work of defining and implementing 657 interoperable presence and instant messaging protocols. 659 7. Acknowledgements 661 This document has been improved by comments from Jesse Vincent and 662 Colin Benson, by the participants in the Cambridge, MA meeting on June 663 11, 1999, and by Roy Salisbury, who contributed Figure 5. The authors 664 gratefully acknowledge their assistance. 666 8. References 668 [ENVY] M. Day. ''HTTP Envy'' and Presence Information Protocols. 669 Internet-Draft draft-day-envy-00.txt 671 [PIPR] M. Calsyn, L. Dusseault. Presence Information Protocol 672 Requirements. Internet-Draft draft-dusseault-pipr-00.txt 674 [PRESENCE] V. Saraswat, J. Malcolm, C. Apple. The Presence 675 Protocol. Internet-Draft draft-saraswat-presenceprotocol-00.txt 677 [RPIM] M. Day. Requirements for Presence and Instant Messaging. 678 Internet-Draft draft-day-rpim-00.txt 680 [RVP-ADDR] L. Dusseault, G. Mohr. Addressing and Location for 681 RVP. Internet-Draft draft-dusseault-rvp-addr-00.txt 683 [RVP] M. Calsyn, L. Dusseault, G. Mohr. RVP: A Presence Notification 684 Protocol. Internet-Draft draft-calsyn-rvp-01.txt 686 [SIP-PIP] J. Rosenberg, H.Schulzrinne. SIP For Presence. 687 Internet-Draft draft-rosenberg-sip-pip-00.txt 689 [WHODP] G. Mohr. WhoDP: Widely Hosted Object Data Protocol. 690 Internet-Draft draft-mohr-whodp-00.txt 692 9. Authors' Addresses 694 Mark Day 695 Lotus Development Corporation 696 55 Cambridge Parkway 697 Cambridge, MA 02142 698 USA 699 email: Mark_Day@lotus.com 701 Jonathan Rosenberg 702 Lucent Technologies, Bell Laboratories 703 Rm. 4C-526 704 101 Crawfords Corner Rd. 705 Holmdel, NJ 07733 706 USA 707 email: jdrosen@bell-labs.com 709 Hiroyasu Sugano 710 Fujitsu Laboratories Ltd. 711 64 Nishiwaki, Ohkubo-cho 712 Akashi 674-8555 713 Japan 714 email: suga@flab.fujitsu.co.jp