RFC 2779

Instant Messaging / Presence Protocol Requirements

📅 published February 2000, from ietf

RFC 2779: Instant Messaging / Presence Protocol Requirements 💬✨

Network Working Group 🌸 this one's from the group that was trying to get IM and presence to play nicely across the whole Internet. It's Request for Comments 2779, the Informational category, dated February 2000.

The authors are M. Day (Lotus), S. Aggarwal (Microsoft), G. Mohr (Activerse), and J. Vincent (Into Networks). Its header doesn't list anything it obsoletes or updates, so it's a standalone doc 🫶

Status of this Memo 📋

okay so this memo is just giving info to the Internet community 💅 it is NOT a standard of any kind. and anyone can share it, as much as they want 🦋

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

Abstract 🌈

ok bestie, presence and instant messaging have basically blown up as a brand new way to talk online 💬 presence is how you find out whether someone is "online" or "offline," then grab that info and subscribe to any changes 👀 instant messaging is sending short, simple messages that land right away on people who are online ⚡

the problem is that apps doing this right now each use their own non-standard protocols from different vendors, so they can't talk to each other 😭 the Instant Messaging and Presence Protocol (IMPP) Working Group wants one standard protocol so independently built IM and presence apps can interoperate across the Internet 🤝 this document sets out a minimal set of requirements that IMPP has to meet 💖

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

1. Terminology 🧚

okay so these terms are defined in [RFC 2778] and this doc uses them with those exact definitions 💅

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

here's the key bit 👑 when this doc writes requirements, MUST and SHOULD mean:

  • MUST: A proposed solution will have to meet this requirement.
  • SHOULD: A proposed solution may choose not to meet this requirement.
heads up: this usage of MUST and SHOULD is NOT the same as RFC 2119. don't mix them up bestie 🙈

also, these terms get defined right 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]).
  • 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 🫶

ok this section is about the non-security requirements that a PRESENCE SERVICE and an INSTANT MESSAGE SERVICE have in common 💕 Section 6 covers what's specific to a PRESENCE SERVICE, Section 7 covers what's specific to an INSTANT MESSAGE SERVICE, and Section 8 covers security considerations. Also, Section 11 is an appendix with historical context that helps you trace where the requirements in Section 8 came from. It is NOT a statement of current IMPP requirements, so don't treat it like one 🙅‍♀️

heads up bestie: the cross-references here point at Sections 6, 7, 8 and 11, but the table of contents doesn't line up with that. I've kept every reference exactly as the original wrote it 🎀

presence and IM are gonna be SO valuable for people on mobile IP wireless devices 📱 and the number of wirelessly connected devices is expected to grow a LOT in the coming years 📈 it's not realistic to assume separate protocols will exist just for the wireless parts of the Internet. wireless tech is also maturing fast, so this work has to account for where the tech will be when these protocols are actually deployed ⏳

so the protocols this group designs have to work in the kind of environment mobile wireless devices live in 🥹 that means high latency, low bandwidth and possibly intermittent connectivity (which makes it important to minimize round-trip delays), modest computing power, battery constraints, small displays, and so on ✨ most importantly, the protocols have 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.
  • (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, and 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. 🫣✨

part 1 of 5 done bestie, more coming soon 💖🦋

2.4. Network Topology 🗺️

Okay so intermediaries like PROXIES might be necessitated between IP and non-IP networks, and also when an end-user wants anonymity and wants to hide their IP address. Main character privacy 🕵️‍♀️

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. No messing with my texts 😤

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. Replay attacks are not it 🙅‍♀️

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. Privacy is the moment 🫶

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. Opt-in energy, no pressure 💅

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. Everyone has to speak the same basic language first 🌸

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

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. Ways to reach them, iykyk 📮

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. Add all the extras you want, just don't break the core stuff 🧩

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. Homework for the working group 📚

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

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. Peeking is always allowed 🫣

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. Following someone should never be blocked by their offline status 🙈

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. Spill the tea to every subscriber, unless the ACCESS RULES say no 🍵

3.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT. Ghost detection, but make it useful 👻

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. Nobody says bye before the crash, and the protocol knows it 💀

3.3. Presence Caching and Replication 🗂️

3.3.1. The protocol MUST include mechanisms to allow PRESENCE INFORMATION to be cached. Stash it, babe 🍓

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

3.3.3 The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms. Caching can't be a loophole 🙅‍♀️💖

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. Speed is the whole vibe, so presence updates should be as quick as a text 🏃‍♀️💨

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. Same base format, everybody in the chat 💬

4.1.2. The common base format for an INSTANT MESSAGE MUST identify the sender and intended recipient. Who said it and who it's for, obviously 💅

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

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. Backup contact info is very much recommended 📞

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. Emojis and secret stuff both have to fit 🌍🔒

4.1.6. The protocol must reflect best current practices related to internationalization. Every language deserves to be seen 🌏

4.1.7. The protocol must reflect best current practices related to accessibility. Everyone gets to chat 🫂

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. More homework for the working group 📝

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. Message IDs need rules, bestie 🔢

4.1.10. The common message format SHOULD be based on IETF-standard MIME [RFC 2045]. Same MIME energy as everything else 📎

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. Read receipts, but make them honest 📬

4.3 Performance 🏎️

4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid to allow for comfortable conversational exchanges of short messages. No lag in the group chat, period 💨

4.4 Presence Format 🟢

4.4.1. The common presence format MUST define a minimum standard presence schema suitable for INSTANT MESSAGE SERVICES. The bare minimum, but make it cute 🎀

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. OPEN or CLOSED, no in-between drama 🚪

4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to messaging or communication modes other than INSTANT MESSAGE SERVICES. Those two can go anywhere 🌸

5. Security Considerations 🛡️

Security considerations are addressed in section 2.3, Access Control, and section 2.5, Message authentication and encryption. Okay, so this part is the serious bit 😭

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 expectations got a glow-up into real 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. Admins can have extra powers, but never at the expense of regular PRINCIPALs 👑

Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR PRINCIPALS. A, B, and C are the main characters here 🎭

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. A needs to know it's really B 🕵️‍♀️

5.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION to B obvious to a third party C. Stalker-proof, if A wants it 🫣

5.1.3. The protocol MUST provide B with means of allowing an unauthenticated subscription by A. B gets to decide if a no-login subscription is okay 🔓

5.1.4. The protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A. A should be able to confirm the tea arrived intact 🍵

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. If B says no, B has to say so 🙃

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. Nobody gets subscribed without a yes 🚫

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. Unfollow whenever, no explanation needed 👋

5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's SUBSCRIPTION to B. Hands off A's subscription 🙅‍♀️

5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD inform A of the cancellation. A should hear about it 🫶

5.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION to B, at any time. Check the status whenever you want 🔍

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. B always gets to know who's watching 👀

5.1.12. The protocol MUST provide B means of identifying and authenticating the SUBSCRIBER's PRINCIPAL, A. B needs to know who A really is 🪪

5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL from subscribing. B can block anyone they don't vibe with 🚷

5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS from subscribing. No anon stalkers allowed 🙅‍♀️

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. Polite blocking exists, and the protocol doesn't force anyone to serve it 🥀

5.1.16. B MUST be able to cancel A's subscription at will. B can end it whenever they like 💅

5.1.17. The protocol MUST NOT require A to reveal A's IP address to B. Your IP address is yours, bestie 🦋

5.1.18 The protocol MUST NOT require B to reveal B's IP address to A. Same rule for B, no IP oversharing 🫶🌈

okay so, picture this: when a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to another PRINCIPAL A, here's what the protocol has to handle 💅

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

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". 🙈 B gets to decide who sees what, and that's giving main character energy 👑

5.2.4. The protocol MUST provide means of protecting B from another PRINCIPAL C "spoofing" notification messages about B. 🛡️ Nobody gets to fake B's notifications, periodt.

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

When a PRINCIPAL A receives a notification message from another principal B, conveying PRESENCE INFORMATION, here's what A gets to expect 🦋

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. 🎀 No random strangers in her notifs, bestie.

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

When a user A sends an INSTANT MESSAGE M to another user B, this is where things get really serious, so let's go 🔥

5.4.1. A MUST receive confirmation of non-delivery. 📭 If it doesn't arrive, A has to find out.

5.4.2. If M is delivered, B MUST receive the message only once. 🙅‍♀️ No double texts allowed.

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

5.4.6. The protocol MUST provide A means of ensuring that no other PRINCIPAL C can see the content of M. 🕵️‍♀️ Private means private.

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. 🧾 Nobody messes with the message, full stop.

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. ✍️ Signing is iconic, we love a receipt.

5.4.10. B MUST be able to prevent A from sending him messages. 🚫 B has the final say on who gets to slide into the DMs 💖

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.

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)

8. Appendix: Security Expectations and Deriving Requirements 🧚

okay this appendix is the behind-the-scenes tea ☕ It's 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. So no sneaky new rules hiding in here, just the receipts 🧾💜

8.1. PRESENCE INFORMATION ✨

Okay so for PRESENCE INFORMATION, the controlling PRINCIPAL's privacy interests are literally the main character 👑🔒. We agreed that "polite blocking" (denying without saying the subscription is denied, or giving false info) should be possible 🫶. Basically the blocked person never gets a "you've been blocked" notification, they just... don't get the good stuff 🙈.

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. Alice should be able to authenticate B, but she shouldn't have to authenticate every single SUBSCRIPTION. That caveat is there because of performance concerns, among other things, and it applies to a lot of the other requirements below too. [Requirement 5.1.1]

A2. no third party will know that A has subscribed to B.

Discussion: Honestly this is kind of unreasonable to enforce as-is 😭. In some topologies nothing can stop someone from doing traffic analysis and figuring out that A subscribed to B. So we should only require that the protocol not expose subscription information in any obvious manner. [Requirement 5.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" can mean two things 🤔: (i) B allows an unauthenticated subscription by A, and (ii) B might not know A's stated identity. Requirement (i) is reasonable [Requirement 8.1.3], but (ii) doesn't really look like a core requirement. It can be simulated just fine with 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. Nobody gets to force you into a follow 🙅‍♀️. [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 💅. But implementations may have to deal with a timing window where A, after sending her cancellation request, still gets a notification that B sent before B received that cancellation. So the requirement should focus on B ceasing to send presence information, rather than A 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: The intent is reasonable, but there are a bunch of scenarios (like an overburdened server, a clogged network, or a server crash) where telling A about the cancellation is undesirable or impossible 💀. So the service should make an attempt to inform A, but this is not required. [Requirement 5.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. B can also choose to figure out A's subscription after the fact, though 👀. [Requirement 5.1.10]

B2. A is identifiable and authenticated.

Discussion: This stands as a requirement. [Requirement 5.1.11]

B3. B can prevent a particular user, D, from subscribing.

Discussion: This stands as a requirement. [Requirement 5.1.12]

B4. B can prevent anonymous users from subscribing.

Discussion: This stands as a requirement. [Requirement 5.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's left out of 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 shouldn't imply anything about servicing it for status notifications. [Requirement 5.1.14]

B7. B can cancel A's subscription at will.

Discussion: Stands as a requirement. Power move 👑. [Requirement 5.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 they don't need to be continuously informed of the subscriber list 📋. Also, in some cases user agents (like proxies) may have subscribed on behalf of users. In those cases the administrator can only figure out the identity of those agents, not the users behind them. [Requirement 5.1.16]

C2. C can manage all aspects of A's presence information.

Discussion: This stands as a requirement. [Requirement 5.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 wants to 🫶. [Requirement 5.1.18]

8.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 pull off, so it's left out of the requirements 😔.

8.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. Private means private 🔐. [Requirement 5.2.1]

B2. A reliably receives all notifications intended for her.

Discussion: This stands, although "Reliably" is a little strong (think network outages and stuff) 🌧️. [Requirement 5.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. It also covers the notifications version of the next expectation, B4. [Requirement 5.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's been folded 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 5.2.4]

8.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 verification is optional for Alice 🫧. [Requirement 5.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 left out of the requirements, because traffic analysis, even of encrypted traffic, can reveal this in some situations 👀.

A3. That she only receives notifications of things she's subscribed to.

Discussion: Stands as a requirement. No random notifications, thank you 🙅‍♀️. [Requirement 5.3.2]

A4. Notifications come from the apparent sender, B.

Discussion: Stands in principle, although verification should be optional for A. [Requirement 5.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 really hard to enforce and could unduly restrict usage scenarios, so it's left out of 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, so it's left out of 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, so it's left out of the requirements. For example, that kind of proof may need global time synchronization mechanisms (since any system clock has some unreliability built in), and that's outside the scope of this effort ⏰.

A8. A can prove that B was indeed the sender of a given message.

Discussion: This duplicates expectation A4 above and is reflected in the corresponding requirement 5.3.3 🫶.

8.2. INSTANT MESSAGEs 💌

8.2.1. Named Instant Messaging

okay so this is where we look at what happens 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 5.4.1] 📬

Alice expects that Bob:

  • B1. will receive the message Discussion: covered by A1 and is reflected in the corresponding requirement 5.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 5.4.2] 🎀
  • B4. will be able to verify that Alice sent the message Discussion: Stands as a requirement. [Requirement 5.4.3] ✨
  • B5. will not know whether there were BCCs Discussion: We're not trying to copy email vibes or social etiquette here, bestie 💅 so references to standard mail fields got left out of 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 5.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 5.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 5.4.6] 🔒
  • C2. tamper with M Discussion: Stands, with the same caveat as above. [Requirement 5.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 5.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 5.4.9] ✍️
  • D3. will be able to verify M's integrity Discussion: Stands as a requirement. [Requirement 5.4.10] 💜
  • D4. will be able to prevent A from sending him future messages Discussion: Stands as a requirement. [Requirement 5.4.11] 🚫

Bob expects that Alice:

  • E1. intended to send the message to Bob Discussion: This is covered by the corresponding requirement 5.4.6 for C1 above. 🎯
  • E2. informed Bob of all CCs. Discussion: As noted earlier, references to cc:'s are omitted from the requirements. 📋

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

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

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈✨

📦 where this page comes from