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]
`
`GOOGLE 1013
`
`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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`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.
`
` 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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`13
`
`

`

`RFC 2779 Instant Messaging/Presence Protocol February 2000
`
` 5.4.6. The protocol MUST provide A means of ensuring that no other
` PRINCIPAL C can see the content of M.
`
` 5.4.7. The protocol MUST provide A means of ensuring that no other
` PRINCIPAL C can tamper with M, and B means to verify that no
` tampering has occurred.
`
` 5.4.8. B must be able to read M.
`
` 5.4.9. The protocol MUST allow A to sign the message, using existing
` standards for digital signatures.
`
` 5.4.10. B MUST be able to prevent A from sending him messages
`
`6. References
`
` [RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for
` Presence and Instant Messaging", RFC 2778, February 2000.
`
` [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
`RFC 2426, September 1998.
`
` [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
` Extensions (MIME) - Part One: Format of Internet Message
` Bodies", RFC 2045, November 1996.
`
` [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
` Requirement Levels", BCP 14, RFC 2119, March 1997.
`
`Day, et al. Informational [Page 14]
`
`14
`
`

`

`RFC 2779 Instant Messaging/Presence Protocol 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)
`
` Sonu Aggarwal
` Microsoft Corporation
` One Microsoft Way
` Redmond, WA 98052
` USA
`
` EMail: sonuag@microsoft.com
`
` Gordon Mohr
`
` EMail: gojomo@usa.net
` (Formerly gojomo@activerse.com)
`
` Jesse Vincent
` Into Networks, Inc.
` 150 Cambridgepark Drive
` Cambridge, MA 02140
` USA
`
` EMail: jesse@intonet.com
` (Formerly jvincent@microsoft.com)
`
`Day, et al. Informational [Page 15]
`
`15
`
`

`

`RFC 2779 Instant Messaging/Presence Protocol February 2000
`
`8. Appendix: Security Expectations and Deriving Requirements
`
` This appendix is based on the security expectations discussed on the
` impp mailing list and assembled by Jesse Vincent. The original form
` of numbering has been preserved in this appendix (so there are
` several different items labeled B1, for example). The derived
` requirements have new numbers that are consistent with the main body
` of the document. This appendix is included to provide a connection
` from discussions on the list to the requirements of Section 8, but it
` is not intended to introduce any new requirements beyond those
` presented in Sections 5 through 8.
`
`8.1. PRESENCE INFORMATION
`
` In the case of PRESENCE INFORMATION, the controlling PRINCIPAL’s
` privacy interests are paramount; we agreed that "polite blocking"
` (denying without saying that the subscription is denied, or providing
` false information) should be possible.
`
` 8.1.1. Subscription
`
` When a user Alice subscribes to another person, Bob’s presence info,
` Alice expects:
`
` A1. the PRESENTITY’s PRINCIPAL, B, is identifiable and authenticated
`
` Discussion: Stands as a requirement. Note that the protocol
` should provide Alice the capability of authenticating, without
` requiring that Alice authenticate every SUBSCRIPTION. This
` caveat is made necessary by performance concerns, among others,
` and applies to many of the other requirements derived below.
` [Requirement 5.1.1]
`
` A2. no third party will know that A has subscribed to B.
`
` Discussion: This is somewhat unreasonable to enforce as is. For
` example, in some topologies, nothing can prevent someone doing
` traffic analysis to deduce that A has subscribed to B. We should
` merely require that the protocol not expose subscription
` information in any obvious manner. [Requirement 5.1.2]
`
`Day, et al. Informational [Page 16]
`
`16
`
`

`

`RFC 2779 Instant Messaging/Presence Protocol February 2000
`
` A3. A has the capability to subscribe to B’s presence without B’s
` knowledge, if B permits anonymous subscriptions.
`
` Discussion: An "anonymous subscription" above can have two
` implications - (i) B may allow an unauthenticated subscription by
` A, and (ii) B may be unaware of A’s stated identity. Requirement
` (i) is reasonable [Requirement 8.1.3], but (ii) doesn’t appear to
` be a core requirement -- it can be adequately simulated via a
` subscription pseudonym.
`
` A4. A will accurately receive what B chooses to disclose to A
` regarding B’s presence.
`
` Discussion: Stands as a requirement, with the "optional"
` caveat. [Requirement 8.1.4]
`
` A5. B will inform A if B refuses A’s subscription
`
` Discussion: Stands as a requirement. [Requirement 5.1.5]
`
` A6. No third party, C can force A to subscribe to B’s presence
` without A’s consent.
`
` Discussion: Stands as a requirement. [Requirement 5.1.6]
`
` A7. A can cancel her subscription to B’s presence at any time and for
` any reason. When A does so, she will receive no further information
` about B’s presence information.
`
` Discussion: This essentially stands. However, implementations
` may have to contend with a timing window where A receives, after
` sending her cancellation request, a notification sent by B before
` B received the cancellation request. Therefore, the requirement
` should focus on B’s ceasing to send presence information, rather
` than A’s ceasing to receive it. [Requirement 5.1.7]
`
` A8. no third party, C, can cancel A’s subscription to B.
`
` Discussion: Stands, although the administrative exception does
` apply. [Requirement 5.1.8]
`
` A9. A is notified if her subscription to B is cancelled for any
` reason.
`
` Discussion: Although the intent is reasonable, there are a number
` of scenarios (e.g. overburdened server, clogged network, server
` crash) where delivering a notification to A of the cancellation
` is undesirable or impossible. Therefore, the service should make
`
`Day, et al. Informational [Page 17]
`
`17
`
`

`

`RFC 2779 I