rfc2779.txt

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

   2.5.3. The protocol MUST provide means to ensure that a sent message
   (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that
   the sender allows.

   2.5.4. The protocol MUST allow any client to use the means to ensure
   non-corruption, non-playback, and privacy, but the protocol MUST NOT
   require that all clients use these means at all times.

3. Additional Requirements for PRESENCE INFORMATION

   The requirements in section 6 are applicable only to PRESENCE
   INFORMATION and not to INSTANT MESSAGES.  Additional constraints on
   PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear
   in Section 7.4.

3.1. Common Presence Format

   3.1.1. All ENTITIES MUST produce and consume at least a common base
   format for PRESENCE INFORMATION.

   3.1.2. The common presence format MUST include a means to uniquely
   identify the PRESENTITY whose PRESENCE INFORMATION is reported.





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


   3.1.3. The common presence format MUST include a means to encapsulate
   contact information for the PRESENTITY's PRINCIPAL (if applicable),
   such as email address, telephone number, postal address, or the like.

   3.1.4. There MUST be a means of extending the common presence format
   to represent additional information not included in the common
   format, without undermining or rendering invalid the fields of the
   common format.

   3.1.5. The working group must define the extension and registration
   mechanisms for presence information schema, including new STATUS
   conditions and new forms for OTHER PRESENCE MARKUP.

   3.1.6. The presence format SHOULD be based on IETF standards such as
   vCard [RFC 2426] if possible.

3.2. Presence Lookup and Notification

   3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE
   INFORMATION even when the PRESENTITY is OUT OF CONTACT.

   3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a
   PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF
   CONTACT.

   3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's
   PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the
   PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER,
   unless prevented by the PRESENTITY's ACCESS RULES.

   3.2.4. The protocol MUST provide a mechanism for detecting when a
   PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.

   3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER
   gracefully telling the service that it will no longer be in
   communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT
   due to unanticipated failures.

3.3. Presence Caching and Replication

   3.3.1. The protocol MUST include mechanisms to allow PRESENCE
   INFORMATION to be cached.

   3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE
   INFORMATION to be updated when the master copy changes.






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


   3.3.3 The protocol caching facilities MUST NOT circumvent established
   ACCESS RULES or restrict choice of authentication/encryption
   mechanisms.

3.4 Performance

   3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any
   SUBSCRIBER to that information MUST be notified of the changed
   information rapidly, except when such notification is entirely
   prevented by ACCESS RULES. This requirement is met if each
   SUBSCRIBER's NOTIFICATION is transported as rapidly as an INSTANT
   MESSAGE would be transported to an INSTANT INBOX.

4. Additional Requirements for INSTANT MESSAGES

   The requirements in section 4 are applicable only to INSTANT MESSAGES
   and not to PRESENCE INFORMATION, with the exception of Section 4.4.
   Section 4.4 describes constraints on PRESENCE INFORMATION that are
   relevant only to systems that support both INSTANT MESSAGES and
   PRESENCE INFORMATION.

4.1. Common Message Format

   4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST
   implement at least a common base format for INSTANT MESSAGES.

   4.1.2. The common base format for an INSTANT MESSAGE MUST identify
   the sender and intended recipient.

   4.1.3. The common message format MUST include a return address for
   the receiver to reply to the sender with another INSTANT MESSAGE.

   4.1.4. The common message format SHOULD include standard forms of
   addresses or contact means for media other than INSTANT MESSAGES,
   such as telephone numbers or email addresses.

   4.1.5. The common message format MUST permit the encoding and
   identification of the message payload to allow for non-ASCII or
   encrypted content.

   4.1.6. The protocol must reflect best current practices related to
   internationalization.

   4.1.7. The protocol must reflect best current practices related to
   accessibility.






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


   4.1.8. The working group MUST define the extension and registration
   mechanisms for the message format, including new fields and new
   schemes for INSTANT INBOX ADDRESSES.

   4.1.9. The working group MUST determine whether the common message
   format includes fields for numbering or identifying messages. If
   there are such fields, the working group MUST define the scope within
   which such identifiers are unique and the acceptable means of
   generating such identifiers.

   4.1.10. The common message format SHOULD be based on IETF-standard
   MIME [RFC 2045].

4.2. Reliability

   4.2.1. The protocol MUST include mechanisms so that a sender can be
   informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons
   for failure.  The working group must determine what mechanisms apply
   when final delivery status is unknown, such as when a message is
   relayed to non-IMPP systems.

4.3 Performance

   4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid
   to allow for comfortable conversational exchanges of short messages.

4.4 Presence Format

   4.4.1. The common presence format MUST define a minimum standard
   presence schema suitable for INSTANT MESSAGE SERVICES.

   4.4.2. When used in a system supporting INSTANT MESSAGES, the common
   presence format MUST include a means to represent the STATUS
   conditions OPEN and CLOSED.

   4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to
   messaging or communication modes other than INSTANT MESSAGE SERVICES.














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


5. Security Considerations

   Security considerations are addressed in section 2.3, Access Control,
   and section 2.5, Message authentication and encryption.

   This section describes further security-related requirements that the
   protocol must meet.

   The security requirements were derived from a set of all-encompassing
   "security expectations" that were then evaluated for practicality and
   implementability and translated into requirements.  In the appendix,
   we describe the expectations and the process used to transform them
   into requirements. In this section, we simply list the consolidated
   set of derived requirements.

   Note that in the requirements, ADMINISTRATORs may have privileges
   beyond those allowed to PRINCIPALs referred to in the requirements.
   (Unless otherwise noted, the individual expectations specifically
   refer to PRINCIPALs.)  It is up to individual implementations to
   control administrative access and implement the security privileges
   of ADMINISTRATORs without compromising the requirements made on
   PRINCIPALs.

   Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR
   PRINCIPALS.

5.1. Requirements related to SUBSCRIPTIONS

   When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION:

   5.1.1. The protocol MUST provide A means of identifying and
   authenticating that the PRESENTITY subscribed to is controlled by B.

   5.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION
   to B obvious to a third party C.

   5.1.3. The protocol MUST provide B with means of allowing an
   unauthenticated subscription by A.

   5.1.4. The protocol MUST provide A means of verifying the accurate
   receipt of the content B chooses to disclose to A.

   5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may
   choose to accept A's SUBSCRIPTION, but fail to deliver any
   information to it (so-called "polite blocking"). See 5.1.15.

   5.1.6. The protocol MUST NOT let any third party C force A to
   subscribe to B's PRESENCE INFORMATION without A's consent.



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


   5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE
   INFORMATION at any time and for any reason.  When A does so, the
   PRESENCE SERVICE stops informing A of changes to B's PRESENCE
   INFORMATION.

   5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's
   SUBSCRIPTION to B.

   5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD
   inform A of the cancellation.

   5.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION
   to B, at any time.

   5.1.11. The protocol MUST provide B means of learning about A's
   SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION
   and afterwards.

   5.1.12. The protocol MUST provide B means of identifying and
   authenticating the SUBSCRIBER's PRINCIPAL, A.

   5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL
   from subscribing.

   5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS
   from subscribing.

   5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE
   to deny A's subscription while appearing to A as if the subscription
   has been granted (this is sometimes called "polite blocking").  The
   protocol MUST NOT mandate the PRESENCE SERVICE to service
   subscriptions that are treated in this manner.

   5.1.16. B MUST be able to cancel A's subscription at will.

   5.1.17. The protocol MUST NOT require A to reveal A's IP address to
   B.

   5.1.18 The protocol MUST NOT require B to reveal B's IP address to A.

5.2. Requirements related to NOTIFICATION

   When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to
   another PRINCIPAL A:

   5.2.1. The protocol MUST provide means of ensuring that only the
   PRINCIPAL A being sent the NOTIFICATION by B can read the
   NOTIFICATION.



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


   5.2.2. A should receive all NOTIFICATIONS intended for her.

   5.2.3. It MUST be possible for B to prevent A from receiving
   notifications, even if A is ordinarily permitted to see such
   notifications.  It MUST be possible for B to, at its choosing, notify
   different subscribers differently, through different notification
   mechanisms or through publishing different content. This is a
   variation on "polite blocking".

   5.2.4. The protocol MUST provide means of protecting B from another
   PRINCIPAL C "spoofing" notification messages about B.

   5.2.5. The protocol MUST NOT require that A reveal A's IP address to
   B.

   5.2.6. The protocol MUST NOT require that B reveal B's IP address to
   A.

5.3. Requirements related to receiving a NOTIFICATION

   When a PRINCIPAL A receives a notification message from another
   principal B, conveying PRESENCE INFORMATION,

   5.3.1. The protocol MUST provide A means of verifying that the
   presence information is accurate, as sent by B.

   5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS
   from entities she has subscribed to.

   5.3.3. The protocol MUST provide A means of verifying that the
   notification was sent by B.

5.4. Requirements related to INSTANT MESSAGES

   When a user A sends an INSTANT MESSAGE M to another user B,

   5.4.1. A MUST receive confirmation of non-delivery.

   5.4.2. If M is delivered, B MUST receive the message only once.

   5.4.3. The protocol MUST provide B means of verifying that A sent the
   message.

   5.4.4. B MUST be able to reply to the message via another instant
   message.

   5.4.5. The protocol MUST NOT always require A to reveal A's IP
   address, for A to send an instant message.



Day, et al.                  Informational                     [Page 13]