rfc2778.txt

中、英文RFC文档大全打包下载完全版 .

         requirements for different PRESENTITIES being watched by a
         single WATCHER.

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

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

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

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

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

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




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


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

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

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

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

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

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

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

   SPAM: unwanted INSTANT MESSAGES.

   SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.

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

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







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


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

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

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

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

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

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

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

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

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







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


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

4. Security Considerations

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

5. Conclusion

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

6. Acknowledgements

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



















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


7. Authors' Addresses

   Mark Day
   SightPath, Inc.
   135 Beaver Street
   Waltham, MA 02452
   USA

   EMail: [e-mail]
   (Formerly [e-mail])


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

   Email: [e-mail]


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

   EMail: [e-mail]























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]