RFC 2778
A Model for Presence and Instant Messaging
RFC 2778: A Model for Presence and Instant Messaging 💖
Okay bestie, this one is the foundation doc for presence and instant messaging, and it's from February 2000 🌸. It's an Informational RFC, which means it gives info to the Internet community and doesn't set a standard ✨. The authors are M. Day (Lotus), J. Rosenberg (dynamicsoft), and H. Sugano (Fujitsu) 🫶. Its header doesn't have any "Obsoletes" or "Updates" line, so it isn't listed as replacing or changing any other RFC 💅.
Status of this Memo 🎀
This memo gives info to the Internet community. It isn't an Internet standard of any kind, and anyone can distribute it freely 🦋.
Copyright Notice 🌈
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract ✨
This doc defines an abstract model for a presence and instant messaging system 🧚. It names the entities involved, defines the terminology, and lays out the services the system provides 💅. The whole point is to give everyone a common vocabulary for future work on requirements for protocols and markup for presence and instant messaging 🔥.
1. Introduction ✨
Presence and instant messaging systems let users subscribe to each other and get notified when each other's state changes 👀. They also let users send each other short instant messages 💬. Before anyone builds a suite of protocols for this, the authors think it's worth making a model of the system first 🧠. The model has the entities involved, what they do, and most importantly, a vocabulary you can use to talk about all of it without going in circles 🍓.
The model is meant to be descriptive and universal 🌍. The goal is for it to map reasonably well onto every system people informally call presence or instant messaging 💖. It is not prescriptive, and it isn't about achieving interoperability 🙈. So an element in the model won't necessarily show up as part of an interoperable protocol, and it might not even be a good idea 💀.
In this doc, every element of the model is written in upper case, like PRESENCE SERVICE 💅. Any term in lower or mixed case is not meant to be a term of the model 🫶.
The first part of the doc is an overview of the model 🦋. It has diagrams, and the terms show up in an order meant to help you see how the elements relate ✨. The second part is the actual definition of the model, with the terms in alphabetical order so they're easy to look up 📚.
The overview is helpful, but it isn't the final word 💅. It might have accidental differences from the model's definitions 🙈. If there's ever a difference, the definitions in the model win, not the explanations in the overview 👑.
2. Overview 🧚
The model gives you a way to understand, compare, and describe systems that support what people call presence and instant messaging 🌸. It's made of a bunch of named entities that show up in some form in existing systems 🔥. No real implementation is likely to have every entity as its own separate piece 😭. Instead, parts of an implementation almost always bundle two or more entities together 💜. Different implementations can mix the entities in different ways 🌈.
The model defines two services 💖: a PRESENCE SERVICE and an INSTANT MESSAGE SERVICE ✨. The PRESENCE SERVICE takes in information, stores it, and distributes it 🎀. The information it stores is (unsurprisingly) PRESENCE INFORMATION 💅. The INSTANT MESSAGE SERVICE takes INSTANT MESSAGES in and delivers them to INSTANT INBOXES 🦋.
2.1 PRESENCE SERVICE 🌸
The PRESENCE SERVICE has two distinct sets of "clients" 🫶. (Remember, these might be combined in a real implementation, but the model treats them separately 🙈.) One set, called PRESENTITIES, provides PRESENCE INFORMATION to be stored and distributed 💅. The other set, called WATCHERS, receives PRESENCE INFORMATION from the service 👀.
+---------------------------+
| PRESENCE SERVICE |
| |
+---------------------------+
^ |
| |
| v
+------------+ +------------+
| PRESENTITY | | WATCHER |
+------------+ +------------+Fig. 1: Overview of Presence Service
There are two kinds of WATCHERS 💖: FETCHERS and SUBSCRIBERS ✨. A FETCHER just asks the PRESENCE SERVICE for the current value of some PRESENTITY's PRESENCE INFORMATION 🎀. A SUBSCRIBER, on the other hand, asks the PRESENCE SERVICE to notify it about (future) changes to some PRESENTITY's PRESENCE INFORMATION 🔥. There's also a special kind of FETCHER that fetches information on a regular basis 🍓. That one is called a POLLER 💅.
+----------------WATCHER---------------+
| |
| +----FETCHER---+ +--SUBSCRIBER--+ |
| | | | | |
| | +--POLLER--+ | | | |
| | | | | | | |
| | +----------+ | | | |
| +--------------+ +--------------+ |
+--------------------------------------+Fig. 2: Varieties of WATCHER
The PRESENCE SERVICE also keeps WATCHER INFORMATION about its WATCHERS and what they're doing, in terms of fetching or subscribing to PRESENCE INFORMATION 👀. It can also send WATCHER INFORMATION out to some WATCHERS 🫶. It uses the same mechanisms it has for distributing PRESENCE INFORMATION to do that 🦋.
Changes to PRESENCE INFORMATION go out to SUBSCRIBERS through NOTIFICATIONS 🔔. Figures 3a through 3c show how the info flows when a piece of PRESENCE INFORMATION changes from P1 to P2 ✨.
+---------------------------+
| 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 gives INSTANT MESSAGES to the INSTANT MESSAGE SERVICE for delivery ✨. Each INSTANT MESSAGE is addressed to a particular INSTANT INBOX ADDRESS, and the service tries to deliver it to the matching 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 the PRESENCE SERVICE, PRESENTITIES, and WATCHERS 🫶. PRESENCE INFORMATION is carried by the PRESENCE PROTOCOL 💅.
An INSTANT MESSAGE PROTOCOL defines the interaction between the INSTANT MESSAGE SERVICE, SENDERS, and INSTANT INBOXES 🦋. INSTANT MESSAGES are carried by the INSTANT MESSAGE PROTOCOL 💜.
In terms of this model, the authors believe 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 ✨
okay so the model says PRESENCE INFORMATION is made up of any number of little bits called PRESENCE TUPLES 🧩 Each tuple has a STATUS marker (think online/offline/busy/away/do not disturb 💅), an optional COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. A COMMUNICATION ADDRESS is a COMMUNICATION MEANS plus a CONTACT ADDRESS. The only COMMUNICATION MEANS this model defines is INSTANT MESSAGE SERVICE, and the only CONTACT ADDRESS it defines is INSTANT INBOX ADDRESS. BUT other stuff is possible too! A COMMUNICATION MEANS could be some kind of telephony, where the CONTACT ADDRESS is a phone number 📞
+------------------------------------+
| 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
STATUS is further defined by the model to have at least two states that interact with INSTANT MESSAGE delivery 🎀 The first is OPEN, where INSTANT MESSAGES will be accepted, and the second is CLOSED, where they won't be. OPEN and CLOSED can also apply to other COMMUNICATION MEANS: OPEN maps to something like "available" or "open for business," while CLOSED means "unavailable" or "closed to business." The model lets STATUS hold other values too, which might be readable by programs or only by humans. And STATUS can be a single value or multiple values. Main character flexibility 👑
2.5 Presence and its effect on Instant Messages 💌
An INSTANT INBOX is basically a receptacle for INSTANT MESSAGES 📥 Its INSTANT INBOX ADDRESS is the info you can put inside PRESENCE INFORMATION to say how an INSTANT MESSAGE should get delivered to that INSTANT INBOX. As mentioned above, certain STATUS values tell you whether INSTANT MESSAGES will be accepted at the INSTANT INBOX. Otherwise the model doesn't restrict the delivery mechanism or the format of instant messages at all. Reasonable people can disagree about whether that's a strength or a weakness of this model 🤷♀️
2.6 PRINCIPALS and their agents 🕵️♀️
This model has a few more elements that help explain how the protocol and markup work 🧠 PRINCIPALS are the people, groups, and/or software out in the "real world" that use the system to coordinate and communicate. How the real world maps onto PRINCIPALS is totally outside the model. The system only knows that two distinct PRINCIPALS are distinct, and two identical PRINCIPALS are identical. Simple as that 💅
A PRINCIPAL interacts with the system through one of several user agents: INBOX USER AGENT, SENDER USER AGENT, PRESENCE USER AGENT, or WATCHER USER AGENT. As usual, the model splits these kinds of user agents apart, even though most implementations will combine at least some of them 🫶 A user agent is purely the link between a PRINCIPAL and a core entity in the system (INSTANT INBOX, SENDER, PRESENTITY, or WATCHER, respectively).
+---------------------------+
| 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 system2.7 Examples 🧁
Let's start with a simple one: a generic "buddy list" app 💕 These apps usually show the user's presence to others, and let you see everyone else's presence too. So a buddy list is the combo of a PRESENCE USER AGENT and a WATCHER USER AGENT for a single PRINCIPAL, using a single PRESENTITY and a single SUBSCRIBER.
Then we can level up to instant messaging. A generic "instant messenger" is basically a buddy list with extra powers for sending and receiving instant messages 📱 So an instant messenger is the combo of a PRESENCE USER AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER USER AGENT for a single PRINCIPAL, using a single PRESENTITY, a single SUBSCRIBER, and a single INSTANT INBOX. The PRESENTITY's PRESENCE INFORMATION includes an INSTANT INBOX ADDRESS that leads to that 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 get manipulated by the PRESENCE USER AGENT of the PRINCIPAL that controls that 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 means the associated INSTANT INBOX ADDRESS (if there is one) points to an INSTANT INBOX that can't accept an INSTANT MESSAGE. This value might have a similar meaning for other COMMUNICATION MEANS, but this model doesn't define any such meaning. Contrast with OPEN.
COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT ADDRESS.
COMMUNICATION MEANS: a method by which communication can happen. INSTANT MESSAGE SERVICE is one example.
CONTACT ADDRESS: a specific point of contact via some COMMUNICATION MEANS. When you're using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS is an INSTANT INBOX ADDRESS 📬
DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE delivers received INSTANT MESSAGES to INSTANT INBOXES. For each INSTANT INBOX, the applicable DELIVERY RULES get manipulated by the INBOX USER AGENT of the PRINCIPAL that controls that INSTANT INBOX.
Motivation: We need a way of talking about filtering instant messages 🧹
FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE for the PRESENCE INFORMATION of one or more PRESENTITIES, but has not asked for a SUBSCRIPTION to be created 👀
INBOX USER AGENT: a means for a PRINCIPAL to manipulate zero or more INSTANT INBOXES controlled by that PRINCIPAL.
Motivation: This is meant to separate the core functionality of an INSTANT INBOX from how it might look to be manipulated by a product. That manipulation includes fetching messages, deleting messages, and setting DELIVERY RULES. The model deliberately takes no position on whether the INBOX USER AGENT, INSTANT INBOX, and INSTANT MESSAGE SERVICE are colocated or distributed across machines 🖥️
INSTANT INBOX: a receptacle for INSTANT MESSAGES that is meant to be read by the INSTANT INBOX's PRINCIPAL.
INSTANT INBOX ADDRESS: indicates whether and how a PRESENTITY's PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The STATUS and the INSTANT INBOX ADDRESS information together are enough to figure out whether the PRINCIPAL seems 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 don't define "small," but this definition aims to avoid the possibility of transporting an arbitrary-length stream labelled as an "instant message." No giant streams in my DMs, thank you 🙅♀️
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 ✨
- It may require authentication of SENDER USER AGENTS and/or INSTANT INBOXES.
- It 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.
- It 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 a distinct SERVER. The service may be implemented as direct communication between SENDER and INSTANT INBOX 🧚
Okay bestie, the glossary is still going, so here's the rest of the vocab 📚✨
- 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. 🔁
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.
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.
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.
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 🔐
Okay, this part is serious, so stay with me 😤 Presence and instant messaging systems come with built-in security drama. This document gives everyone a shared vocabulary for it. The big three are "the three S's": STALKING, SPOOFING, and SPAM. Presence and instant messaging systems must deal with all three.
ACCESS RULES, VISIBILITY RULES, and WATCHER INFORMATION are meant to deal with STALKING. The several kinds of authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE SERVICE are meant to deal with SPOOFING. DELIVERY RULES are meant to deal with SPAM. 🛡️
5. Conclusion 🌸
This document has provided a model for a presence and instant messaging system. It's giving "shared vocabulary for future work," because 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. Big thank-yous to everyone who helped 💖
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.jp8. Full Copyright Statement ⚖️
Legal text stays word-for-word, bestie, because it has to. 📜
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. ✨
📦 where this page comes from
- ietf: rfc2778 2000-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms