📄 rfc2778.txt
字号:
single WATCHER.
-- May have an internal structure involving multiple SERVERS
and/or PROXIES. There may be complex patterns of redirection
and/or proxying while retaining logical connectivity to a
single PRESENCE SERVICE. Note that a PRESENCE SERVICE does not
require having a distinct SERVER -- the service may be
implemented as direct communication among PRESENTITY and
WATCHERS.
-- May have an internal structure involving other PRESENCE
SERVICES, which may be independently accessible in their own
right as well as being reachable through the initial PRESENCE
SERVICE.
PRESENCE TUPLE: consists of a STATUS, an optional COMMUNICATION
ADDRESS, and optional OTHER PRESENCE MARKUP.
PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more
PRESENTITIES.
Motivation: This is essentially a "model/view" distinction: the
PRESENTITY is the model of the presence being exposed, and is
independent of its manifestation in any user interface. In
addition, we deliberately take no position on how the PRESENCE
USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or
distributed across machines.
PRESENTITY (presence entity): provides PRESENCE INFORMATION to a
PRESENCE SERVICE.
Day, et al. Informational [Page 12]
RFC 2778 A Model for Presence and Instant Messaging February 2000
Motivation: We don't like to coin new words, but "presentity"
seemed worthwhile so as to have an unambiguous term for the entity
of interest to a presence service. Note that the presentity is not
(usually) located in the presence service: the presence service
only has a recent version of the presentity's presence
information. The presentity initiates changes in the presence
information to be distributed by the presence service.
PRINCIPAL: human, program, or collection of humans and/or programs
that chooses to appear to the PRESENCE SERVICE as a single actor,
distinct from all other PRINCIPALS.
Motivation: We need a clear notion of the actors outside the
system. "Principal" seems as good a term as any.
PROXY: a SERVER that communicates PRESENCE INFORMATION, INSTANT
MESSAGES, SUBSCRIPTIONS and/or NOTIFICATIONS to another SERVER.
Sometimes a PROXY acts on behalf of a PRESENTITY, WATCHER, or
INSTANT INBOX.
SENDER: source of INSTANT MESSAGES to be delivered by the INSTANT
MESSAGE SERVICE.
SENDER USER AGENT: means for a PRINCIPAL to manipulate zero or more
SENDERS.
SERVER: an indivisible unit of a PRESENCE SERVICE or INSTANT MESSAGE
SERVICE.
SPAM: unwanted INSTANT MESSAGES.
SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.
STALKING: using PRESENCE INFORMATION to infer the whereabouts of a
PRINCIPAL, especially for malicious or illegal purposes.
STATUS: a distinguished part of the PRESENCE INFORMATION of a
PRESENTITY. STATUS has at least the mutually-exclusive values OPEN
and CLOSED, which have meaning for the acceptance of INSTANT
MESSAGES, and may have meaning for other COMMUNICATION MEANS.
There may be other values of STATUS that do not imply anything
about INSTANT MESSAGE acceptance. These other values of STATUS may
be combined with OPEN and CLOSED or they may be mutually-exclusive
with those values.
Day, et al. Informational [Page 13]
RFC 2778 A Model for Presence and Instant Messaging February 2000
Some implementations may combine STATUS with other entities. For
example, an implementation might make an INSTANT INBOX ADDRESS
visible only when the INSTANT INBOX can accept an INSTANT MESSAGE.
Then, the existence of an INSTANT INBOX ADDRESS implies OPEN,
while its absence implies CLOSED.
SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to
notify it immediately of changes in the PRESENCE INFORMATION of
one or more PRESENTITIES.
SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a
SUBSCRIBER's request to be notified of changes in the PRESENCE
INFORMATION of one or more PRESENTITIES.
VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes WATCHER
INFORMATION available to WATCHERS. For each WATCHER's WATCHER
INFORMATION, the applicable VISIBILITY RULES are manipulated by
the WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER.
Motivation: We need a way of talking about hiding watcher
information from people.
WATCHER: requests PRESENCE INFORMATION about a PRESENTITY, or WATCHER
INFORMATION about a WATCHER, from the PRESENCE SERVICE. Special
types of WATCHER are FETCHER, POLLER, and SUBSCRIBER.
WATCHER INFORMATION: information about WATCHERS that have received
PRESENCE INFORMATION about a particular PRESENTITY within a
particular recent span of time. WATCHER INFORMATION is maintained
by the PRESENCE SERVICE, which may choose to present it in the
same form as PRESENCE INFORMATION; that is, the service may choose
to make WATCHERS look like a special form of PRESENTITY.
Motivation: If a PRESENTITY wants to know who knows about it, it
is not enough to examine only information about SUBSCRIPTIONS. A
WATCHER might repeatedly fetch information without ever
subscribing. Alternately, a WATCHER might repeatedly subscribe,
then cancel the SUBSCRIPTION. Such WATCHERS should be visible to
the PRESENTITY if the PRESENCE SERVICE offers WATCHER INFORMATION,
but will not be appropriately visible if the WATCHER INFORMATION
includes only SUBSCRIPTIONS.
WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or more
WATCHERS controlled by that PRINCIPAL.
Day, et al. Informational [Page 14]
RFC 2778 A Model for Presence and Instant Messaging February 2000
Motivation: As with PRESENCE USER AGENT and PRESENTITY, the
distinction here is intended to isolate the core functionality of
a WATCHER from how it might appear to be manipulated by a product.
As previously, we deliberately take no position on whether the
WATCHER USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or
distributed across machines.
4. Security Considerations
This document provides a model and vocabulary for systems with
certain intrinsic security issues. In particular, presence and
instant messaging systems must deal with "the three S's": STALKING,
SPOOFING, and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER
INFORMATION are intended to deal with STALKING. The several kinds of
authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE
SERVICE are intended to deal with SPOOFING. DELIVERY RULES are
intended to deal with SPAM.
5. Conclusion
This document has provided a model for a presence and instant
messaging system. The purpose of the model is to provide a common
vocabulary for the further work of defining and implementing
interoperable presence and instant messaging protocols.
6. Acknowledgements
This document has been improved by comments from Jesse Vincent and
Colin Benson, by the participants in the Cambridge, MA meeting on
June 11, 1999, and by Roy Salisbury, who contributed the original
version of Figure 5. The authors gratefully acknowledge their
assistance.
Day, et al. Informational [Page 15]
RFC 2778 A Model for Presence and Instant Messaging February 2000
7. Authors' Addresses
Mark Day
SightPath, Inc.
135 Beaver Street
Waltham, MA 02452
USA
EMail: mday@alum.mit.edu
(Formerly Mark_Day@lotus.com)
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07046
Email: jdrosen@dynamicsoft.com
Hiroyasu Sugano
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi 674-8555
Japan
EMail: suga@flab.fujitsu.co.jp
Day, et al. Informational [Page 16]
RFC 2778 A Model for Presence and Instant Messaging February 2000
8. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Day, et al. Informational [Page 17]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -