rfc2778.txt

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

       |   |     | +-----------------+
       |   |     =>| CONTACT ADDRESS |
       |   |       +-----------------+
       |   | +-------------------------+
       |   =>| OTHER MARKUP            |
       |     +-------------------------+
       | +-------------------------------+
       =>| PRESENCE TUPLE                |
       | +-------------------------------+
       |    ...

        Fig. 5: The structure of PRESENCE INFORMATION






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


   STATUS is further defined by the model to have at least two states
   that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT
   MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will
   not be accepted. OPEN and CLOSED may also be applicable to other
   COMMUNICATION MEANS -- OPEN mapping to some state meaning "available"
   or "open for business" while CLOSED means "unavailable" or "closed to
   business." The model allows STATUS to include other values, which may
   be interpretable by programs or only by persons.  The model also
   allows STATUS to consist of single or multiple values.

2.5 Presence and its effect on Instant Messages

   An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT
   INBOX ADDRESS is the information that can be included in PRESENCE
   INFORMATION to define how an INSTANT MESSAGE should be delivered to
   that INSTANT INBOX. As noted above, certain values of the STATUS
   marker indicate whether INSTANT MESSAGES will be accepted at the
   INSTANT INBOX.  The model does not otherwise constrain the delivery
   mechanism or format for instant messages. Reasonable people can
   disagree about whether this omission is a strength or a weakness of
   this model.

2.6 PRINCIPALS and their agents

   This model includes other elements that are useful in characterizing
   how the protocol and markup work. PRINCIPALS are the people, groups,
   and/or software in the "real world" outside the system that use the
   system as a means of coordination and communication. It is entirely
   outside the model how the real world maps onto PRINCIPALS -- the
   system of model entities knows only that two distinct PRINCIPALS are
   distinct, and two identical PRINCIPALS are identical.

   A PRINCIPAL interacts with the system via one of several user agents
   (INBOX USER AGENT; SENDER USER AGENT; PRESENCE USER AGENT; WATCHER
   USER AGENT). As usual, the different kinds of user agents are split
   apart in this model even though most implementations will combine at
   least some of them. A user agent is purely coupling between a
   PRINCIPAL and some core entity of the system (respectively, INSTANT
   INBOX; SENDER; PRESENTITY; WATCHER).












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


                   +---------------------------+
                   |     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 system











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


2.7 Examples

   A simple example of applying the model is to describe a generic
   "buddy list" application. These applications typically expose the
   user's presence to others, and make it possible to see the presence
   of others. So we could describe a buddy list as the combination of a
   PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL,
   using a single PRESENTITY and a single SUBSCRIBER.

   We could then extend our example to instant messaging and describe a
   generic "instant messenger" as essentially a buddy list with
   additional capabilities for sending and receiving instant messages.
   So an instant messenger would be the combination of a PRESENCE USER
   AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER USER AGENT
   for a single PRINCIPAL, using a single PRESENTITY, single SUBSCRIBER,
   and single INSTANT INBOX, with the PRESENTITY's PRESENCE INFORMATION
   including an INSTANT INBOX ADDRESS that leads to the 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 are manipulated by the
      PRESENCE USER AGENT of a PRINCIPAL that controls the 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 value means that the associated INSTANT
      INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is
      unable 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 OPEN.

   COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT
      ADDRESS.

   COMMUNICATION MEANS: indicates a method whereby communication can
      take place. INSTANT MESSAGE SERVICE is one example of a
      COMMUNICATION MEANS.

   CONTACT ADDRESS: a specific point of contact via some COMMUNICATION
      MEANS. When using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS
      is an INSTANT INBOX ADDRESS.






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


   DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE
      delivers received INSTANT MESSAGES to INSTANT INBOXES. For each
      INSTANT INBOX, the applicable DELIVERY RULES are manipulated by
      the INBOX USER AGENT of a PRINCIPAL that controls the INSTANT
      INBOX.

      Motivation: We need a way of talking about filtering instant
      messages.

   FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE to for
      the PRESENCE INFORMATION of one or more PRESENTITIES, but has not
      asked for a SUBSCRIPTION to be created.

   INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more
      INSTANT INBOXES controlled by that PRINCIPAL.

      Motivation: This is intended to isolate the core functionality of
      an INSTANT INBOX from how it might appear to be manipulated by a
      product. This manipulation includes fetching messages, deleting
      messages, and setting DELIVERY RULES. We deliberately take no
      position on whether the INBOX USER AGENT, INSTANT INBOX, and
      INSTANT MESSAGE SERVICE are colocated or distributed across
      machines.

   INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by
      the INSTANT INBOX's PRINCIPAL.

   INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's
      PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The
      STATUS and INSTANT INBOX ADDRESS information are sufficient to
      determine whether the PRINCIPAL appears 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 do not define "small" but we seek in this
      definition to avoid the possibility of transporting an arbitrary-
      length stream labelled as an "instant message."








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


   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.

      -- May require authentication of SENDER USER AGENTS and/or INSTANT
         INBOXES.

      -- 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.

      -- 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 having a distinct SERVER -- the
         service may be implemented as direct communication between
         SENDER and INSTANT INBOX.

      -- 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.



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


   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