rfc2779.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            M. Day
Request for Comments: 2779                                        Lotus
Category: Informational                                     S. Aggarwal
                                                              Microsoft
                                                                G. Mohr
                                                              Activerse
                                                             J. Vincent
                                                          Into Networks
                                                          February 2000


           Instant Messaging / Presence Protocol Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   Presence and Instant Messaging have recently emerged as a new medium
   of communications over the Internet.  Presence is a means for
   finding, retrieving, and subscribing to changes in the presence
   information (e.g. "online" or "offline") of other users. Instant
   messaging is a means for sending small, simple messages that are
   delivered immediately to online users.

   Applications of presence and instant messaging currently use
   independent, non-standard and non-interoperable protocols developed
   by various vendors.  The goal of the Instant Messaging and Presence
   Protocol (IMPP) Working Group is to define a standard protocol so
   that independently developed applications of instant messaging and/or
   presence can interoperate across the Internet. This document defines
   a minimal set of requirements that IMPP must meet.












Day, et al.                  Informational                      [Page 1]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


Table of Contents

   1. Terminology...................................................  3
   2. Shared Requirements...........................................  4
    2.1. Namespace and Administration...............................  5
    2.2. Scalability................................................  5
    2.3. Access Control.............................................  6
    2.4. Network Topology...........................................  6
    2.5. Message Encryption and Authentication......................  7
   3. Additional Requirements for PRESENCE INFORMATION..............  7
    3.1. Common Presence Format.....................................  7
    3.2. Presence Lookup and Notification...........................  8
    3.3. Presence Caching and Replication...........................  8
    3.4. Performance................................................  9
   4. Additional Requirements for INSTANT MESSAGES..................  9
    4.1. Common Message Format......................................  9
    4.2. Reliability................................................ 10
    4.3. Performance................................................ 10
    4.4. Presence Format............................................ 10
   5. Security Considerations....................................... 11
    5.1. Requirements related to SUBSCRIPTIONS...................... 11
    5.2. Requirements related to NOTIFICATION....................... 12
    5.3. Requirements related to receiving a NOTIFICATION........... 13
    5.4. Requirements related to INSTANT MESSAGES................... 13
   6. References.................................................... 14
   7. Authors' Addresses............................................ 15
   8. Appendix: Security Expectations and Deriving Requirements..... 16
    8.1. Presence Information....................................... 16
     8.1.1. Subscription............................................ 16
     8.1.2. Publication............................................. 19
     8.1.3. Publication for Notification............................ 19
     8.1.4. Receiving a Notification................................ 20
    8.2. Instant Messaging.......................................... 21
     8.2.1. Named Instant Messaging................................. 21
     8.2.2. Anonymous Instant Messaging............................. 23
     8.2.3. Administrator Expectations.............................. 24
   Full Copyright Statement......................................... 26














Day, et al.                  Informational                      [Page 2]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


1. Terminology

   The following terms are defined in [RFC 2778] and are used with those
   definitions in this document:

   ACCESS RULES
   CLOSED
   FETCHER
   INSTANT INBOX
   INSTANT MESSAGE
   NOTIFICATION
   OPEN
   POLLER
   PRESENCE INFORMATION
   PRESENCE SERVICE
   PRESENTITY
   PRINCIPAL
   PROXY
   SERVER
   STATUS
   SUBSCRIBER
   SUBSCRIPTION
   WATCHER

   The terms MUST and SHOULD are used in the following sense while
   specifying requirements:

   MUST: A proposed solution will have to meet this requirement.
   SHOULD: A proposed solution may choose not to meet this requirement.

   Note that this usage of MUST and SHOULD differs from that of RFC
   2119.

   Additionally, the following terms are used in this document and
   defined here:

   ADMINISTRATOR: A PRINCIPAL with authority over local computer and
   network resources, who manages local DOMAINS or FIREWALLS. For
   security and other purposes, an ADMINISTRATOR often needs or wants to
   impose restrictions on network usage based on traffic type, content,
   volume, or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over
   some or all of that PRINCIPAL's computer and network resources.

   DOMAIN: A portion of a NAMESPACE.

   ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER
   (all defined in [RFC 2778]).




Day, et al.                  Informational                      [Page 3]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   FIREWALL: A point of administrative control over connectivity.
   Depending on the policies being enforced, parties may need to take
   unusual measures to establish communications through the FIREWALL.

   IDENTIFIER: A means of indicating a point of contact, intended for
   public use such as on a business card. Telephone numbers, email
   addresses, and typical home page URLs are all examples of IDENTIFIERS
   in other systems.  Numeric IP addresses like 10.0.0.26 are not, and
   neither are URLs containing numerous CGI parameters or long arbitrary
   identifiers.

   INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT
   MESSAGE is sending it.

   NAMESPACE: The system that maps from a name of an ENTITY to the
   concrete implementation of that ENTITY. A NAMESPACE may be composed
   of a number of distinct DOMAINS.

   OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE
   SERVICE cannot communicate.

   SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was
   transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the
   INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually
   also implies that an INBOX USER AGENT has handled the message in a
   way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not
   imply that the message was actually seen by that PRINCIPAL.

2. Shared Requirements

   This section describes non-security requirements that are common to
   both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE.  Section 6
   describes requirements specific to a PRESENCE SERVICE, while Section
   7 describes requirements specific to an INSTANT MESSAGE SERVICE.
   Section 8 describes security considerations. The reader should note
   that Section 11 is an appendix that provides historical context and
   aids in tracing the origins of requirements in Section 8. Section 11
   is not, however, a statement of current IMPP requirements.

   It is expected that Presence and Instant Messaging services will be
   particularly valuable to users over mobile IP wireless access
   devices.  Indeed the number of devices connected to the Internet via
   wireless means is expected to grow substantially in the coming years.
   It is not reasonable to assume that separate protocols will be
   available for the wireless portions of the Internet. In addition, we
   note that wireless infrastructure is maturing rapidly; the work
   undertaken by this group should take into account the expected state
   of the maturity of the technology in the time-frame in which the



Day, et al.                  Informational                      [Page 4]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   Presence and Instant Messaging protocols are expected to be deployed.

   To this end, the protocols designed by this Working Group must be
   suitable for operation in a context typically associated with mobile
   wireless access devices, viz.  high latency, low bandwidth and
   possibly intermittent connectivity (which lead to a desire to
   minimize round-trip delays), modest computing power, battery
   constraints, small displays, etc. In particular, the protocols must
   be designed to be reasonably efficient for small payloads.

2.1. Namespace and Administration

   2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available
   independent of whether an INSTANT MESSAGE SERVICE is available, and
   vice-versa.

   2.1.2. The protocols must not assume that an INSTANT INBOX is
   necessarily reached by the same IDENTIFIER as that of a PRESENTITY.
   Specifically, the protocols must assume that some INSTANT INBOXes may
   have no associated PRESENTITIES, and vice versa.

   2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached
   via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.

   2.1.4. The administration and naming of ENTITIES within a given
   DOMAIN MUST be able to operate independently of actions in any other
   DOMAIN.

   2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS
   within the NAMESPACE.

2.2. Scalability

   2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate
   with ENTITIES in another DOMAIN, without the DOMAINS having
   previously been aware of each other.

   The protocol MUST be capable of meeting  its other functional and
   performance requirements even when

      -- (2.2.2) there are millions of ENTITIES within a single DOMAIN.

      -- (2.2.3) there are millions of DOMAINS within the single
         NAMESPACE.







Day, et al.                  Informational                      [Page 5]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


      -- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds
         of PRESENTITIES.

      -- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to
         a single PRESENTITY.

      -- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to
         PRESENTITIES in hundreds of distinct DOMAINS.

   These are protocol design goals; implementations may choose to place
   lower limits.

2.3. Access Control

   The PRINCIPAL controlling a PRESENTITY MUST be able to control

      -- (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE
         INFORMATION.

      -- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that
         PRESENTITY's PRESENCE INFORMATION.

      -- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see
         for that PRESENTITY, regardless of whether the WATCHER gets it
         by fetching or NOTIFICATION.

      -- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE
         INFORMATION of that PRESENTITY.

   The PRINCIPAL controlling an INSTANT INBOX MUST be able to control

      -- (2.3.5) which other PRINCIPALS, if any, can send INSTANT
         MESSAGES to that INSTANT INBOX.

      -- (2.3.6) which other PRINCIPALS, if any, can read INSTANT
         MESSAGES from that INSTANT INBOX.

   2.3.7. Access control MUST be independent of presence: the PRESENCE
   SERVICE MUST be able to make access control decisions even when the
   PRESENTITY is OUT OF CONTACT.

2.4. Network Topology

   Note that intermediaries such as PROXIES may be necessitated between
   IP and non-IP networks, and by an end-user's desire to provide
   anonymity and hide their IP address.





Day, et al.                  Informational                      [Page 6]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both
   directly and via intermediaries, such as PROXIES.

   2.4.2. The protocol MUST allow the sending of a NOTIFICATION both
   directly and via intermediaries, such as PROXIES.

   2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both
   directly and via intermediaries, such as PROXIES.

   2.4.4. The protocol proxying facilities and transport practices MUST
   allow ADMINISTRATORS ways to enable and disable protocol activity
   through existing and commonly-deployed FIREWALLS.  The protocol MUST
   specify how it can be effectively filtered by such FIREWALLS.

2.5. Message Encryption and Authentication

   2.5.1. The protocol MUST provide means to ensure confidence that a
   received message (NOTIFICATION or INSTANT MESSAGE) has not been
   corrupted or tampered with.

   2.5.2. The protocol MUST provide means to ensure confidence that a
   received message (NOTIFICATION or INSTANT MESSAGE) has not been
   recorded and played back by an adversary.