INTERNET-DRAFT Mark Day Expires: November 17, 1999 Lotus Sonu Aggarwal Microsoft Gordon Mohr Activerse Jesse Vincent Instant Messaging / Presence Protocol Requirements draft-ietf-impp-reqts-00.txt [IMPP LIST DISCUSSION DRAFT 01, 1999-05-17] 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. 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. 3. Contents 1. Status of this Memo 2. Abstract 3. Contents 4. Terminology 5. Shared Requirements 5.1. Namespace and Administration 5.2. Scalability 5.3. Access Control 5.4. Network Topology 5.5. Message Encryption and Authentication 6. Additional Requirements for PRESENCE INFORMATION 6.1. Common Presence Format 6.2. Presence Lookup and Notification 6.3. Presence Caching and Replication 7. Additional Requirements for INSTANT MESSAGES 7.1. Common Message Format 7.2. Reliability 8. Open Issues and ToDos for this Draft 9. Security Considerations 9.1. Requirements related to SUBSCRIPTIONS 9.2. Requirements related to NOTIFICATION 9.3. Requirements related to receiving a NOTIFICATION 9.4. Requirements related to INSTANT MESSAGES 10. References 11. Authors' Addresses 12. Appendix: Security Expectations and Deriving Requirements 12.1. Presence Information 12.1.1. Subscription 12.1.2. Publication 12.1.3. Publication for Notification 12.1.4. Receiving a Notification 12.2. Instant Messaging 12.2.1. Named Instant Messaging 12.2.2 Anonymous Instant Messaging 12.2.3 Administrator Expectations 4. Terminology The following terms are defined in [Model] and are used with those definitions in this document: ACCESS RULES FETCHER INSTANT INBOX INSTANT MESSAGE NOTIFICATION PRESENCE INFORMATION PRESENCE SERVICE PRESENTITY PRINCIPAL PROXY SERVER STATUS SUBSCRIBER SUBSCRIPTION WATCHER The terms MUST, SHOULD, and MAY are used with the meaning defined in [RFC 2119]. 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, or WATCHER (all defined in [Model]). 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. 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. OFFLINE: A STATUS indicating that any associated INSTANT INBOX cannot serve as a means to convey an INSTANT MESSAGE to its PRINCIPAL. ONLINE: A STATUS indicating that any associated INSTANT INBOX may be able to serve as a means to convey an INSTANT MESSAGE to its PRINCIPAL. Note that an ONLINE status may be further refined to indicate "busy," "do not disturb," and the like. OUT OF CONTACT: A situation in which som 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. 5. Shared Requirements 5.1. Namespace and Administration 5.1.1. The protocol(s) MUST define a single NAMESPACE. In general, an ENTITY that makes PRESENCE INFORMATION available can receive INSTANT MESSAGES, and vice versa. 5.1.2. The administration and naming of ENTITIES within a given DOMAIN MUST be able to operate independently of actions in any other DOMAIN. 5.1.3. The protocol MUST allow for an arbitrary number of DOMAINS within the NAMESPACE. 5.2. Scalability 5.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. 5.2.2. The protocol MUST continue to meet its other functional and performance requirements even when there are millions of ENTITIES within a single DOMAIN. 5.2.3. The protocol MUST continue to meet its other functional and performance requirements even when there are millions of DOMAINS within the single NAMESPACE. 5.2.4. The protocol MUST continue to meet its other functional and performance requirements even when every single SUBSCRIBER has SUBSCRIPTIONS to hundreds of PRESENTITIES. 5.2.5. The protocol MUST continue to meet its other functional and performance requirements even when thousands of distinct SUBSCRIBERS have SUBSCRIPTIONS to a single PRESENTITY. 5.2.6. The protocol MUST continue to meet its other functional and performance requirements even when every single SUBSCRIBER has SUBSCIPTIONS to PRESENTITIES in hundreds of distinct DOMAINS. 5.2.7. The transport of INSTANT MESSAGES SHOULD be sufficiently rapid to allow for comfortable conversational exchanges of short messages. 5.2.8. When a PRESENTITY changes its PRESENCE INFORMATION, any SUBSCRIBER to that information MUST be notified of the changed information, except when prevented by ACCESS RULES, as rapidly as an INSTANT MESSAGE would be delivered. 5.3. Access Control 5.3.1. The PRINCIPAL controlling a PRESENTITY MUST be able to control which FETCHERS can observe its PRESENCE INFORMATION. 5.3.2. The PRINCIPAL controlling a PRESENTITY MUST be able to control which SUBSCRIBERS can have SUBSCRIPTIONS to its PRESENCE INFORMATION. 5.3.3. The PRINCIPAL controlling a PRESENTITY MUST be able to control what PRESENCE INFORMATION a particular WATCHER will see, either by fetching or NOTIFICATION. 5.3.4. The PRINCIPAL controlling a PRESENTITY MUST be able to control which other PRINCIPALS, if any, can update the PRESENCE INFORMATION of that PRESENTITY. 5.3.5. The PRINCIPAL controlling an INSTANT INBOX MUST be able to control which other PRINCIPALS, if any, can send INSTANT MESSAGES to that INSTANT INBOX. 5.3.6. The PRINCIPAL controlling an INSTANT INBOX MUST be able to control which other PRINCIPALS, if any, can read INSTANT MESSAGES from that INSTANT INBOX. 5.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. 5.4. Network Topology 5.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both directly and via intermediaries, such as PROXIES. 5.4.2. The protocol MUST allow the sending of a NOTIFICATION both directly and via intermediaries, such as PROXIES. 5.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both directly and via intermediaries, such as PROXIES. 5.4.4 The protocol's network traffic MUST be sufficiently well- characterized that ADMINISTRATORS can apply local policies via FIREWALLS. 5.4.5 The protocol proxying facilities and transport practices MUST allow ADMINISTRATORS ways to enable protocol activity through existing and commonly-deployed FIREWALLS. 5.5. Message Encryption and Authentication 5.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. 5.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. 5.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. 5.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. 6. Additional Requirements for PRESENCE INFORMATION The requirements in section 6 are applicable only to PRESENCE INFORMATION and not to INSTANT MESSAGES. 6.1. Common Presence Format 6.1.1. All ENTITIES MUST produce and consume at least a common base format for PRESENCE INFORMATION. 6.1.2. The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported. 6.1.3. The common presence format MUST include a means to represent at least the following STATUS conditions: online/offline, and available/busy/idle. 6.1.4. 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. 6.1.5. 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. 6.1.6. The working group MUST define the extension and registration mechanisms for presence information schema. 6.1.7. The presence format SHOULD be based on IETF-standards such as vCard [RFC 2426] if possible. 6.2. Presence Lookup and Notification 6.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE INFORMATION even when the PRESENTITY is not in communication with the PRESENCE SERVICE. 6.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is not in communication with the PRESENCE SERVICE. 6.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. 6.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER goes OUT OF CONTACT. 6.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. 6.3. Presence Caching and Replication 6.3.1. The protocol MUST include mechanisms to allow PRESENCE INFORMATION to be cached. 6.3.2. The protocol MUST include mechanisms to allow cached PRESENCE INFORMATION to be updated when the master copy changes. 6.3.3 The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms. 7. Additional Requirements for INSTANT MESSAGES The requirements in section 7 are applicable only to INSTANT MESSAGES and not to PRESENCE INFORMATION. 7.1. Common Message Format 7.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST implement at least a common base format for INSTANT MESSAGES. 7.1.2. The common base format for an INSTANT MESSAGE MUST identify the sender and intended recipient. 7.1.3. The common message format MUST include a return address for the receiver to reply to the sender with another INSTANT MESSAGE. 7.1.4. The common message format SHOULD include standard forms of return addresses or contact means for media other than INSTANT MESSAGES, such as telephone numbers or email addresses. 7.1.5. The common message format MUST permit the encoding and identification of the message payload to allow for non-ASCII or encrypted content. 7.1.6. The common message format MUST provide for the association of a reply with the message that prompted that reply. 7.1.7. This reply-association mechanism MUST allow a user agent to organize instant message exchanges into conversational threads. 7.1.8. The common message format SHOULD be based on IETF-standard MIME [RFC 2045]. 7.2. Reliability 7.2.1. The protocol MUST inform the sender of the INSTANT MESSAGE's SUCCESSFUL DELIVERY or reasons for failure. 8. Open Issues and ToDos for this Draft Is it required that there be a one-to-one mapping of the existing email namespace onto the IMPP NAMESPACE? 9. Security Considerations Security considerations are addressed in section 5.3, Access Control, and section 5.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. The following are the requirements derived from the expectations above. 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. 9.1. Requirements related to SUBSCRIPTIONS When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION: 9.1.1. The protocol MUST provide A means of identifying and authenticating that the PRESENTITY subscribed to is controlled by B. 9.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION to B obvious to a third party C. 9.1.3. The protocol MUST provide B with means of allowing an unauthenticated subscription by A. 9.1.4. The protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A. 9.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. 9.1.6. The protocol MUST NOT let any third party C force A to subscribe to B's PRESENCE INFORMATION without A's consent. 9.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, B stops informing A of changes to its PRESENCE INFORMATION. 9.1.8. The protocol MUST NOT let a third party C cancel A's subscription to B. 9.1.9. If A's subscription to B is cancelled, the service SHOULD inform A of the cancellation. 9.1.10. A SHOULD be able to determine the status of A's subscription to B, at any time. 9.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. 9.1.12. The protocol MUST provide B means of identifying and authenticating the SUBSCRIBER's PRINCIPAL, A. 9.1.13. It MUST be possible for B to prevent any particular PRINCIPAL from subscribing. 9.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS from subscribing. 9.1.15. It MUST be possible for B to deny A's subscription while appearing to A as if the subscription has been granted ("polite blocking"). The protocol MUST NOT mandate B to service subscriptions that it denies in this manner. 9.1.16. B MUST be able to cancel A's subscription at will. 9.1.17. B's ADMINISTRATOR MUST have the option to determine the set of PRINCIPALS or their PROXIES subscribed to B at any time. 9.1.18. B's ADMINISTRATOR MUST have the option to manage all aspects of B's presence information. 9.1.19. B's ADMINISTRATOR MUST have the option to control who can access B's presence information and exchange instant messages with B. 9.2. Requirements related to NOTIFICATION When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to another PRINCIPAL A: 9.2.1. The protocol MUST provide means of ensuring that only the PRINCIPAL A being sent the NOTIFICATION by B can read the NOTIFICATION. 9.2.2. A SHOULD receive all NOTIFICATIONS intended for her. 9.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". 9.2.4. The protocol MUST provide means of protecting B from another PRINCIPAL C "spoofing" notification messages about B. 9.3. Requirements related to receiving a NOTIFICATION When a PRINCIPAL A receives a notification message from another principal B, conveying PRESENCE INFORMATION, 9.3.1. The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B. 9.3.2. The protocol MUST ensure that A only receives NOTIFICATIONS from entities she's subscribed to. 9.3.3. The protocol MUST provide A means of verifying that the notification was sent by B. 9.4. Requirements related to INSTANT MESSAGES When a user A sends an INSTANT MESSAGE M to another user B, 9.4.1. A MUST receive confirmation of non-delivery. 9.4.2. If M is delivered, B MUST receive the message only once. 9.4.3. The protocol MUST provide B means of verifying that A sent the message. 9.4.4. B MUST be able to reply to the message via another instant message. 9.4.5. The protocol MUST NOT always require A to reveal A's IP address, for A to send an instant message. 9.4.6. The protocol MUST provide A means of ensuring that no other PRINCIPAL C can see the content of M. 9.4.7. The protocol MUST provide A means of ensuring that no other PRINCIPAL C can tamper with M. 9.4.8. B MUST be able to read M. 9.4.9. The protocol MUST allow A to sign the message, using existing standards for digital signatures. 9.4.10. The protocol MUST provide B means of verifying M's integrity. 9.4.11. B MUST be able to prevent A from sending him future messages 10. References [Aggarwal et al., 1998] S. Aggarwal, M. Day, G. Mohr, "Presence Information Protocol Requirements", draft-aggarwal-pip-reqts-00.txt [Day, 1998] M. Day, "Requirements for Presence and Instant Messaging", draft-day-rpim-00.txt [Model] M. Day and J. Rosenberg. "A Model for Presence." draft-ietf-impp-model-00.txt. [Calsyn & Dusseault, 1998] M. Calsyn and L. Dusseault. "Presence Information Protocol Requirements", draft-dusseault-pipr-00.txt [RFC 2426] F. Dawson and T. Howes. "vCard MIME Directory Profile." RFC 2426, September 1998. [RFC 2045] N. Freed and N. Borenstein. "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies." RFC 2045, November 1996. [RFC 2119] S. Bradner. "Key Words for Use in RFCs to Indicate Requirement Levels." RFC 2119, March 1997. 11. Authors' Addresses Mark Day <Mark_Day@lotus.com> Lotus Development Corporation 55 Cambridge Parkway Cambridge, MA 02142 USA Sonu Aggarwal <email@example.com> Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Gordon Mohr <firstname.lastname@example.org> Activerse, Inc. 1301 W. 25th St Suite 500 Austin, TX USA Jesse Vincent <email@example.com> 22 Kirkstall Rd Newton, MA 02160 USA 12. 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. 12.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. 12.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 9.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 9.1.2] 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 9.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 9.1.4] A5. B will inform A if B refuses A's subscription Discussion: Stands as a requirement. [Requirement 9.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 9.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 9.1.7] A8. no third party, C, can cancel A's subscription to B. Discussion: Stands, although the administrative exception does apply. [Requirement 9.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 an attempt to inform, but this is not required. [Requirement 9.1.9] Bob expects: B1. B will be informed that A subscribed to B's presence information, as long as A has not subscribed anonymously. Discussion: This essentially stands. However, B can also choose to determine A's subscription after the fact. [Requirement 9.1.10] B2. A is identifiable and authenticated. Discussion: This stands as a requirement. [Requirement 9.1.11] B3. B can prevent a particular user, D, from subscribing. Discussion: This stands as a requirement. [Requirement 9.1.12] B4. B can prevent anonymous users from subscribing. Discussion: This stands as a requirement. [Requirement 9.1.13] B5. B's presence information is not republished by A to a third party, E, who does not. Discussion: This is practically impossible to enforce, so it is omitted from the requirement set. B6. B can deny A's subscription without letting A know that she's been blocked. Discussion: This "polite blocking" capability essentially stands; accepting a "denied" subscription should bear no implication on servicing it for status notifications. [Requirement 9.1.14] B7. B can cancel A's subscription at will. Discussion: Stands as a requirement. [Requirement 9.1.15] Charlie, bob's network administrator expects: C1. C knows who is subscribed to B at all times. Discussion: Administrators should be able to determine who is subscribed, but needn't be continuously informed of the list of subscribers. Also, in some cases user agents (e.g. proxies) may have subscribed on behalf of users, and in these cases the administrator can only determine the identity of these agents, not their users. [Requirement 9.1.16] C2. C can manage all aspects of A's presence information. Discussion: This stands as a requirement. [Requirement 9.1.17] C3. C can control who can access A's presence information and exchange instant messages with A. Discussion: This stands in principle, but C should be able to waive these capabilities if C desires. [Requirement 9.1.18] 12.1.2. Publication The publisher of status information, Bob, expects: B1. That information about B is not provided to any entity without B's knowledge and consent. Discussion: This is nearly impossible to accomplish, so it is omitted from the requirements. 12.1.3. Publication for Notification When information is published for notification, B expects: B1. only a person being sent a notification, A, can read the notification. Discussion: Stands as a requirement. [Requirement 9.2.1] B2. A reliably receives all notifications intended for her. Discussion: This stands, although "Reliably" is a little strong (e.g. network outages, etc.). [Requirement 9.2.2] B3. B can prevent A from receiving notifications, even if A is ordinarily permitted to see such notifications. This is a variation on "polite blocking." Discussion: This stands as a requirement. Also incorporated into this requirement is the notifications equivalent of the next expectation, B4. [Requirement 9.2.3] B4. B can provide two interested parties A and E with different status information at the same time. (B could represent the same event differently to different people.) Discussion: This stands as a requirement; it has been incorporated into the corresponding requirement for B3 above. B5. B expects that malicious C cannot spoof notification messages about B. Discussion: Stands in principle, but it should be optional for B. [Requirement 9.2.4] 12.1.4. Receiving a Notification When Alice receives a notification, the recipient, Alice, expects: A1. That the notification information is accurate, truthful. Discussion: Stands in principle, although being "truthful" can't be a requirement, and the verification is optional for Alice. [Requirement 9.3.1] A2. That information about subscriptions remains private; people do not learn that A's subscription to B's information exists by watching notifications occur. Discussion: This is omitted from the requirements, as traffic analysis, even of encrypted traffic, can convey this information in some situations. A3. That she only receives notifications of things she's subscribed to. Discussion: Stands as a requirement. [Requirement 9.3.2] A4. Notifications come from the apparent sender, B. Discussion: Stands in principle, although the verification should be optional for A. [Requirement 9.3.3] A5. A can tell the difference between a message generated by the user, and a message legitimately generated by the agent on behalf of the user. Discussion: This could be quite difficult to enforce and could unduly restrict usage scenarios; this is omitted from the requirements. A6. That information given by agents on behalf of users can also be expected to be truthful, complete, and legitimately offered; the user permitted the agent to publish these notifications. Discussion: This is difficult to enforce and is omitted from the requirements. A7. A can prove that a notification from B was delivered in a timely fashion and can prove exactly how long the message took to be delivered. Discussion: This is difficult to enforce and is omitted from the requirements. For example, such proof may entail global time synchronization mechanisms (since any system clocks have associated unreliability), which is outside the scope of this effort. A8. A can prove that B was indeed the sender of a given message. Discussion: This is a duplication of expectation A4 above and is reflected in the corresponding requirement 9.3.3. 12.2. INSTANT MESSAGEs 12.2.1. Named Instant Messaging When a user Alice sends an instant message M to another user Bob: Alice expects that she: A1. will receive notification of non-delivery Discussion: Stands as a requirement. [Requirement 9.4.1] Alice expects that Bob: B1. will receive the message Discussion: covered by A1 and is reflected in the corresponding requirement 9.4.1. B2. will receive the message quickly Discussion: Stands as a requirement, although this is also covered elsewhere (in the non-security requirements), so this is omitted from the security requirements. B3. will receive the message only once Discussion: Stands as a requirement. [Requirement 9.4.2] B4. will be able to verify that Alice sent the message Discussion: Stands as a requirement. [Requirement 9.4.3] B5. will not know whether there were BCCs Discussion: Emulating e-mail conventions and social protocols is not a core goal of this effort, and therefore references to standard mail fields are omitted from the requirements. B6. will be able to reply to the message Discussion: Stands in principle; the recipient should be able to reply via an instant message. [Requirement 9.4.4] B7. will know if he was a bcc recipient Discussion: Omitted, as noted above. B8. will not be able to determine any information about A (such as her location or IP address) without A's knowledge and consent. Discussion: "Any information about A" is too general; the requirement should focus on IP address. Further, "without A's knowledge and consent" may be overkill. [Requirement 9.4.5] Alice expects that no other user Charlie will be able to: C1. see the content of M Discussion: Stands in principle, although this should not be mandated for all IM communication. [Requirement 9.4.6] C2. tamper with M Discussion: Stands, with the same caveat as above. [Requirement 9.4.7] C3. know that M was sent Discussion: It is impossible to prevent traffic analysis, and this is therefore omitted from the requirements. When a user Bob receives an instant message M from another user Alice: Bob expects that Bob: D1. will be able to read M Discussion: Stands as a requirement. [Requirement 9.4.8] D2. will be able to verify M's authenticity (both Temporal and the sender's identity) Discussion: As noted earlier, it is not reasonable to directly require temporal checks. The protocol should, however, allow signing messages using existing standards for signing. [Requirement 9.4.9] D3. will be able to verify M's integrity Discussion: Stands as a requirement. [Requirement 9.4.10] D4. will be able to prevent A from sending him future messages Discussion: Stands as a requirement. [Requirement 9.4.11] Bob expects that Alice: E1. intended to send the message to Bob Discussion: This is covered by the corresponding requirement 9.4.6 for C1 above. E2. informed Bob of all CCs. Discussion: As noted earlier, references to cc:'s are omitted from the requirements. 12.2.2. Anonymous Instant Messaging Discussion: Anonymous instant messaging, as in "hiding the identity of the sender", is not deemed to be a core requirement of the protocol and references to it are therefore omitted from the requirements. Implementations may provide facilities for anonymous messaging if they wish, in ways that are consistent with the other requirements. When a user Alice sends an anonymous instant message to another user Bob: Alice expects that Bob: B1. will receive the message B2. will receive the message quickly B3. will receive the message only once AB4.1. cannot know Alice sent it AB4.2. will know that the IM is anonymous, and not from a specific named user AB4.3 may not allow anonymous IMs B5. will not know whether there were BCCs B6. will be able to reply to the message Alice expects that she: C1. will receive notification of non-delivery AC2. will receive an error if the IM was refused Bob expects that he: D1. will be able to read M D2. will be able to verify M's authenticity (both temporal and the sender's identity) D3. will be able to verify M's integrity AD4. will know if an IM was sent anonymously AD5. will be able to automatically discard anonymous IM if desired AD6. will be able to control whether an error is sent to Alice if M is discarded. 12.2.3. Administrator Expectations Charlie, Alice's network administrator expects: C1. that C will be able to send A instant messages at any time. C2. that A will receive any message he sends while A is online. C3. that A will not be able to refuse delivery of any instant messages sent by C. Discussion for C1-C3: It is not clear this needs to be specially handled at the protocol level; Administrators may accomplish the above objectives through other means. For example, an administrator may send a message to a user through the normal mechanisms. This is therefore omitted from the requirements.