RFC 5438
Instant Message Disposition Notification (IMDN)
Instant Message Disposition Notification (IMDN) 💖
Okay bestie, let's get into the title block tea 🎀 This is RFC 5438, filed under the Network Working Group. It's a Standards Track doc, so this is the real deal, no cap ✨ The authors are E. Burger (Unaffiliated) and H. Khartabil (Ericsson Australia), and it's dated February 2009. The header doesn't list any RFCs it obsoletes or updates, so nothing gets retired or patched here 💅
Status of This Memo 📋
This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💜
Copyright Notice ©
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 📜
Abstract ✨
Instant Messaging (IM) is the transfer of messages between users in real-time ⚡ This document gives endpoints a way to request Instant Message Disposition Notifications (IMDN), covering delivery, processing, and display notifications, for page-mode instant messages 💬
The Common Presence and Instant Messaging (CPIM) data format from RFC 3862 gets new header fields so endpoints can request IMDNs 🎀 It also defines a brand new message format for conveying IMDNs 🔥
Last but not least, it describes how SIP entities behave when they use this extension 🧚
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Terminology .....................................................4
4. Overview ........................................................5
5. Disposition Types ...............................................6
5.1. Delivery ...................................................6
5.2. Processing .................................................6
5.3. Display ....................................................7
6. New CPIM Header Fields ..........................................7
6.1. CPIM Header Field Namespace ................................7
6.2. Disposition-Notification ...................................8
6.3. Message-ID .................................................8
6.4. Original-To ................................................8
6.5. IMDN-Record-Route ..........................................9
6.6. IMDN-Route .................................................9
7. Endpoint Behaviour ..............................................9
7.1. IM Sender ..................................................9
7.1.1. Constructing Instant Messages .......................9
7.1.2. Matching IMs with IMDNs ............................11
7.1.3. Keeping State ......................................11
7.1.4. Aggregation of IMDNs ...............................12
7.2. IM Recipient ..............................................12
7.2.1. Constructing IMDNs .................................12
8. Intermediary Behaviour .........................................15
8.1. Constructing Processing Notifications .....................16
8.2. Constructing Delivery Notifications .......................17
8.3. Aggregation of IMDNs ......................................17
9. Identifying Messages ...........................................19
10. Header Fields Formal Syntax ...................................20
11. IMDN Format ...................................................20
11.1. Structure of an XML-Encoded IMDN Payload .................20
11.1.1. The <message-id> Element ..........................21
11.1.2. The <datetime> Element ............................22
11.1.3. The <recipient-uri> Element .......................22
11.1.4. The <original-recipient-uri> Element ..............22
11.1.5. The <subject> Element .............................22
11.1.6. The <delivery-notification>,
<processing-notification>, and
<display-notification> Elements ...................22
11.1.7. The <status> Element ..............................22
11.1.8. MIME Type for IMDN Payload ........................23
11.1.9. The RelaxNG Schema ................................23
12. Transporting Messages Using SIP ...............................27
12.1. Endpoint Behaviour .......................................27
12.1.1. Sending Requests ..................................27
12.1.2. Sending Responses .................................27
12.1.3. Receiving Requests ................................27
12.2. Intermediary Behaviour ...................................29
13. Transporting Messages using MSRP ..............................30
14. Security Considerations .......................................30
14.1. Forgery ..................................................33
14.2. Confidentiality ..........................................33
14.3. IMDN as a Certified Delivery Service .....................34
15. IANA Considerations ...........................................34
15.1. message/imdn+xml MIME TYPE ...............................34
15.2. XML Registration .........................................35
15.3. URN Registration for IMDN Header Parameters ..............35
15.4. Content-Disposition: notification ........................36
16. Acknowledgements ..............................................36
17. References ....................................................37
17.1. Normative References .....................................37
17.2. Informative References ...................................371. Introduction 🌸
In a lot of user-to-user message exchange systems, senders really want to know whether the human recipient actually received the message or had it displayed 👀
Electronic mail [RFC5321] handles this with Message Disposition Notifications [RFC3798] 💌 After the recipient views the message, her mail user agent generates a Message Disposition Notification, or MDN. The MDN is an email that follows the format RFC 3798 [RFC3798] prescribes, and that fixed format is what lets an automaton process it 🤖
The Common Presence and Instant Messaging (CPIM) format, Message/CPIM [RFC3862], is the message format used to generate instant messages 💬 The Session Initiation Protocol (SIP [RFC3261]) can carry instant messages generated with message/CPIM inside SIP MESSAGE requests [RFC3428] 📨
This document extends the Message/CPIM message format in pretty much the same way MDNs extend electronic mail 🦋 It lets Instant Message Senders request, create, and send Instant Message Disposition Notifications (IMDN) 🫶 The mechanism works for page-mode as well as session-mode instant messages, but this document only discusses page-mode. Session-mode is left for future standardisation efforts 🙈
This spec defines three categories of disposition types: "delivery", "processing", and "display" 🌈 Specific disposition types give more detailed info. For example, the "delivery" category includes "delivered" for successful delivery and "failed" for a delivery failure 💀
2. Conventions 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥
This document refers generically to the sender of a message as "he/him/his" and to the recipient as "she/her/hers". This is purely for convenience and makes no assumption about the gender of a message sender or recipient 💅
3. Terminology 🧚
- IM: An Instant Message generated using the Message/CPIM format.
- IMDN: An Instant Message Disposition Notification generated using the Message/CPIM format that carries an IMDN XML document.
- Message: An IM or an IMDN generated using the Message/CPIM format.
- IM Sender: An endpoint (user agent) generating and sending an IM. Also, the endpoint request IMDNs for an IM. Quite often, the IM Sender is the IMDN Recipient. However, that is not always the case, since the IMDN uses the From header in the CPIM message. That value is often the IM Sender's Address of Record (AOR). This address may in fact resolve to different user agents. 👑
- IM Recipient: An endpoint (user agent) that receives IMs. The IM Recipient, as the node that presumably renders the IM to the user, generates and sends delivery IMDNs to IMs, if requested by the IM Sender and allowed by the IM Recipient. 🌸
- Endpoint: An IM Sender or an IM Recipient. 🎀
- Intermediary: An entity in the network, most often an application server (including URI-List and store-and-forward servers), that forwards an IM to its final destination. Intermediaries also can generate and send processing IMDNs to IMs, if requested by the IM Sender and allowed by policy. 🧚
- Gateway: An intermediary that translates between different IM systems that use different protocols. 🌈
- IMDN payload: An XML document carrying the disposition notification information. In this specification, it is of MIME type
message/imdn+xml. 📦 - Disposition type: This specification defines three categories of disposition types: "delivery", "processing", and "display". 💜
- Transport Protocol Message: A SIP or other protocol message that contains an IM or IMDN. 🦋
4. Overview 🦋
okay so picture this bestie 🧚 an IM Sender writes an IM, adds IMDN request info saying "hey, I wanna know what happens to this," and sends it off. Later on, the IM Recipient or an intermediary figures out that the user or app got it, didn't get it, displayed it, or otherwise disposed of it. How the recipient figures out the user actually read it is outside the scope of this document 🙈 Then the IM Recipient or intermediary automatically sends a notification back to the IM Sender. That notification is the Instant Message Disposition Notification (IMDN) 💌
+--------------+ +--------------+
| IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+
| |
| |
| 1. IM requesting IMDN |
|-------------------------------------->|
| |
| |
| 2. IMDN (disposition) |
|<--------------------------------------|
| |
| |
Basic IMDN Message FlowNgl the recipient of an IMDN might not always be the IM Sender 👀 This is especially true for page-mode IMs, where the Address of Record (AOR) of the IM Sender (the one in the IM) resolves to a different location or user agent than the one the IM came from. This could happen if resolving the AOR forks the request to multiple user agents ✨ To keep things simple, the rest of this document assumes the IM Sender and the IMDN Recipient are the same, so both get called the IM Sender from here on 💅
5. Disposition Types 🎀
There are three broad categories of disposition states, bestie: delivery, processing, and display 🫶
5.1. Delivery 📬
The delivery notification type tells you whether or not the IM got delivered to the IM Recipient. It can be in these states:
"delivered"to indicate successful delivery."failed"to indicate failure in delivery."forbidden"to indicate denial for the IM Sender to receive the requested IMDN. The IM Recipient can send the"forbidden"state, but usually it's an intermediary that sends it, if it's configured to do so. For example, it's possible the administrator has disallowed IMDNs 🙅♀️"error"to indicate an error in determining the fate of an IM.
5.2. Processing ⚙️
The processing notification type shows that an intermediary has processed an IM. It can be in these states:
"processed"to indicate that the intermediary has performed its task on the IM. This is a general state of the IM."stored"to indicate that the intermediary stored the IM for later delivery."forbidden"to indicate denial for the IM Sender to receive the requested IMDN. The"forbidden"state is sent by an intermediary that's configured to do so. For example, the administrator has disallowed IMDNs."error"to indicate an error in determining the fate of an IM.
5.3. Display 👀
The display notification type tells you whether or not the IM Recipient rendered the IM to the user. It can be in these states:
"displayed"to indicate that the IM has been rendered to the user."forbidden"to indicate denial, by the IM Recipient, for the IM Sender to receive the requested IMDN."error"to indicate an error in determining the fate of an IM.
Besides text, some IMs can contain audio, video, and still images 🖼️ So the "displayed" state includes the start of rendering the audio or video file to the user.
Okay real talk: there's no positive acknowledgement from the user, so nobody can tell if the user actually read the IM. That means you can't use this protocol as a service to prove someone actually read the IM 🙈💀
6. New CPIM Header Fields 💖
This specification extends the CPIM data format specified in RFC 3862 [RFC3862]. It creates a new namespace plus a bunch of new CPIM header fields ✨
6.1. CPIM Header Field Namespace 🌸
Following CPIM [RFC3862], this specification defines a new namespace for the CPIM extension header fields defined in the following sections. The namespace is:
urn:ietf:params:imdnAs per CPIM [RFC3862] requirements, the new header fields defined in the following sections get a prefix in CPIM messages, assigned to the URN through the NS header field of the CPIM message. The rest of this specification always assumes an NS header field like this one:
NS: imdn <urn:ietf:params:imdn>Clients are free to use any prefix, while servers and intermediaries must accept any legal namespace prefix specification 🫶
6.2. Disposition-Notification 🔔
The IM Sender MUST include the Disposition-Notification header field to show it wants to receive IMDNs from the IM Recipient for that specific IM. Section 10 defines the syntax.
6.3. Message-ID 🆔
The IM Sender MUST include the Message-ID header field in the IM it wants an IMDN for. The Message-ID holds a globally unique message identifier that the IM Sender can use to correlate received IMDNs. Since the sender uses the Message-ID to match IMDNs with their IMs, the Message-ID MUST be selected so that:
- There is a minimal chance of any two Message-IDs accidentally colliding during the time period within which an IMDN might be received.
- It is prohibitive for an attacker who has seen one or more valid Message-IDs to generate additional valid Message-IDs.
The first requirement is a correctness requirement, so the sender can match things properly. The second requirement stops off-path attackers from forging IMDNs 🛡️ To meet both, it is RECOMMENDED that Message-IDs be generated using a cryptographically secure, pseudo-random number generator and contain at least 64 bits of randomness. That cuts the chance of a successful guessing attack down to n/2^64, where n is the number of outstanding valid messages.
When the IM Sender receives an IMDN, it can compare its value with the value of the <message-id> element in the IMDN payload. IMDNs also carry this header field. Note that since the IMDN is itself an IM, its Message-ID will be different from the Message-ID of the original IM. Section 10 defines the syntax.
6.4. Original-To 🧭
An intermediary MAY insert an Original-To header field into the IM. The value of the Original-To field MUST be the address of the IM Receiver. The IM Recipient uses this header to indicate the original IM address in the IMDNs, by filling in the <original-recipient-uri> element in the IMDN. The intermediary MUST insert this header if it changes the CPIM To header field value. The header field MUST NOT appear more than once in an IM. The intermediary MUST NOT change this header field value if it's already present. Section 10 defines the syntax.
6.5. IMDN-Record-Route 🗺️
An intermediary MAY insert an IMDN-Record-Route header field into the IM. This lets the intermediary receive and process the IMDN on its way back to the IM Sender. The value of the IMDN-Record-Route header field MUST be the address of the intermediary. Multiple IMDN-Record-Route header fields can appear in an IM. Section 10 defines the syntax.
6.6. IMDN-Route 🛤️
The IMDN-Route header field gives routing info by including one or more addresses to route the IMDN to. An intermediary that needs the IMDN to flow back through the same intermediary MUST add the IMDN-Record-Route header. When the IM Recipient creates the matching IMDN, it copies the IMDN-Record-Route headers into the corresponding IMDN-Route header fields. Section 10 defines the syntax.
7. Endpoint Behaviour 🧁
7.1. IM Sender 💌
7.1.1. Constructing Instant Messages ✍️
An IM is constructed using the CPIM message format defined in RFC 3862 [RFC3862].
7.1.1.1. Adding a Message-ID Header Field 🆔
If the IM Sender requests the reception of IMDNs, the IM Sender MUST include a Message-ID header field. This header field lets the IM Sender match any IMDNs with their corresponding IMs. See Section 6.3 for Message-ID uniqueness requirements.
7.1.1.2. Adding a DateTime Header Field ⏰
Some devices can't hold onto state for long periods. For example, mobile devices may have memory or battery limits 🔋 Because of those limits, these devices may not be able to, or may choose not to, keep sent messages around for matching IMDNs with sent IMs. So to make IMDN useful here anyway, we add a timestamp to the IM showing when the user sent it. The IMDN returns this timestamp so the user can match the IM with the IMDN at the human level ✨ That's what the DateTime CPIM header field is for. So if the IM Sender would like an IMDN, the IM Sender MUST include the DateTime CPIM header field.
7.1.1.3. Adding a Disposition-Notification Header Field 🔔
The Disposition-Notification says what type of disposition notification the IM Sender asked for. There are three types: delivery, processing, and display. The delivery notification splits further into failure and success delivery notifications. An IM Sender asks for failure delivery notification by including a Disposition-Notification header field with value "negative-delivery". Similarly, a success notification is requested by including a Disposition-Notification header field with value "positive-delivery". The IM Sender can request both types of delivery notifications for the same IM 💖
The IM Sender can request a processing notification by including a Disposition-Notification header field with value "processing".
The IM Sender can also request a display notification. The IM Sender MUST include a Disposition-Notification header field with the value "display" to request a display IMDN.
No Disposition-Notification header field, or one with an empty value, means the IM Sender isn't requesting any IMDNs. Disposition-Notification header field values are comma-separated. The IM Sender MAY request more than one type of IMDN for a single IM.
Future extensions may define other disposition notifications that aren't defined in this document 🔮
Section 10 describes the formal syntax for the Disposition-Notification header field. Here's an example CPIM body of an IM where the IM Sender asks for positive and negative delivery notifications, but not display or processing notifications 🎀
From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain
Content-length: 12
Hello World7.1.2. Matching IMs with IMDNs
okay so matching is how an IM Sender figures out which IMDN goes with which IM 💖 It checks the Message-ID header field value in the IM against the <message-id> element value in the body of the IMDN 🎀 If the IM went to multiple recipients, the IM Sender also looks at the <recipient-uri> element and the <original-recipient-uri> element in the XML body of the IMDN it received. That's how it can tell the IM went out to a bunch of people and which IM Recipient actually sent that IMDN 🫶
An IM Sender can tell an IMDN is a disposition notification if the Content-Disposition in it is "notification" ✨ Which does mean the IM Sender MUST understand the Content-Disposition MIME header in CPIM messages 💅
7.1.3. Keeping State
this spec does not mandate the IM Sender to keep state for a sent IM 🧚
once an IM Sender sends an IM with an IMDN request, it MAY preserve the IM context (mainly the Message-ID), other user-identifiable info like the IM subject or content, and the date and time it was sent 📝 Without that IM context, the IM Sender won't be able to correlate the IMDN with the IM it sent 🙈 The IM Sender may find it impossible to keep IM state if it has limited resources, or no non-volatile memory, and then loses power 😭
there is, however, the concept of a "Sent Items" box in an app that stores sent IMs 📦 That box has the info needed and may have a fancy UI showing the state of a sent IM ✨ A unique Message-ID for this purpose is super useful 🦋 How long items stay in the "Sent Items" box is a user choice. The user is usually free to keep or delete items as she pleases, or as the device's memory fills up 💜
Clearly, if an IM Sender loses its sent items state (for example, the user deletes items from the "Sent Items" box), the client may use a different display strategy for IMDNs that seem apparently unsolicited 👀
this spec also does not mandate an IM Sender to run any timers while waiting for an IMDN. There are no time limits on when IMDNs may be received ⏳
IMDNs may legitimately never arrive, so the time between sending an IM and the IMDN being generated and finally received may take a very long time 🐌 Some clients may choose to purge the state tied to the sent IM. This is why the time stamp is in the IM and gets returned in the IMDN 🕰️ It gives the user a chance to remember what they sent. For example, if the IMDN says the IM the user sent at 2 p.m. last Thursday was delivered, the user gets to remember "oh yeah, I sent that at 2 p.m. last Thursday" 💅
7.1.4. Aggregation of IMDNs
an IM Sender may send an IM to multiple recipients in one Transport Protocol Message (typically using a URI-List server [RFC5365]) and request IMDNs 📬 An IM Sender that requested IMDNs MUST be prepared to receive multiple aggregated or non-aggregated IMDNs. See Section 8.3 for details 🌈
7.2. IM Recipient
7.2.1. Constructing IMDNs
IM Recipients check the contents of the Disposition-Notification header field in the CPIM message to figure out whether they need to generate an IMDN for that IM 🔍 A Disposition-Notification header field in a CPIM message can hold one or more values. IM Recipients may need to generate zero, one, or more IMDNs for one IM. For example, you could get a delivery notification and a display notification 🎀 In that case, the IM Recipient MUST be able to construct multiple IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN per disposition type 🚫 So it must not send a delivery notification saying "delivered" and then another delivery notification saying "failed" for the same IM 😤 If the IM Sender only asked for failure notifications and the IM was delivered successfully, then no IMDNs get generated 🎉 If the IM Recipient doesn't understand a value in the Disposition-Notification header field, it ignores that value 🙃
The IM Recipient MUST NOT generate "processing" notifications 🙅♀️
A Disposition-Notification header field MUST NOT appear in an IMDN, since asking for an IMDN about an IMDN is forbidden 🙈 An IM Sender MUST ignore a delivery notification request in an IMDN if one is present. The IM Sender MUST NOT send an IMDN for an IMDN 💀
An IMDN MUST contain a Message-ID header field. The same uniqueness rules for the Message-ID header field that show up in an IM also apply to an IMDN 🔐 The Message-ID header field in the IMDN is different from, and unrelated to, the one in the IM 🦋
An IM may contain an IMDN-Record-Route header field (see Section 8 for details). If IMDN-Record-Route header fields appear in the IM, the IM Recipient constructing the IMDN MUST copy the contents of those IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN, keeping their order 📋 The IMDN is then sent to the URI in the top IMDN-Route header field 🚀 IMDN-Record-Route header fields don't make sense in an IMDN, so they MUST NOT be placed in an IMDN. IMDN Recipients MUST ignore it if it's present 🙅♀️
If there is no IMDN-Record-Route header field, the IM Recipient MUST send the IMDN to the URI in the From header field 💌
As stated in CPIM [RFC3862], CPIM messages may need to support MIME headers other than Content-type. IM Recipients MUST insert a Content-Disposition header field set to the value "notification" 🏷️ This tells the IM Sender that the message is an IMDN for an IM it sent earlier 💖
7.2.1.1. Constructing Delivery Notifications
The IM Recipient builds a delivery notification in a similar way to an IM, using a CPIM body [RFC3862] that carries a Disposition Notification XML document formatted according to the rules in Section 11 🧁 The MIME type of that Disposition Notification XML document is "message/imdn+xml" 🎀
Section 10 defines the schema for an IMDN 📖
Here's an example CPIM body of an IMDN 👇
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
</status>
</delivery-notification>
</imdn>7.2.1.2. Constructing Display Notifications
The IM Recipient builds a display notification the same way it builds a delivery notification. See Section 7.2.1.1 for details 🌸
Section 10 defines the schema for an IMDN 📖
Here's the example 👇
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: dfjkleriou432333
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>Sometimes the IM Recipient can't tell if or when the IM has been displayed 🫠 In that case, it generates a display notification with a <status> value of "error" to indicate an internal error by the server 🚨 Also, the IM Recipient may choose to ignore any IMDN requests and not send any IMDNs at all 🤷♀️ An IM Recipient may not want to let a sender know whether a particular message has been displayed to her. That could be a per-message, per-sender, or programmed policy choice 🔒
8. Intermediary Behaviour
so in this context, intermediaries are application servers (including URI-List and store-and-forward servers) and gateways 🌉 A gateway is a server that translates between different IM systems that use different protocols 🔄
A URI-List server may change the IM Recipient address from its own to the address of the final recipient of that IM, for every copy it makes and sends to the list members (see [RFC5365] for details) 📋 In this case, if the IM Sender is requesting an IMDN, the intermediary SHOULD add an Original-To header field to the IM, filling it with the address that was in the CPIM To header field before it got changed 💅 That means the intermediary fills the Original-To header field with the intermediary address. Of course, you can configure an intermediary so it's restricted from rewriting or populating the Original-To field 🔧 An intermediary MUST NOT add an Original-To header field if one already exists. An intermediary MAY have an administrative configuration to not reveal the original Request-URI, and as such, MUST NOT add an Original-To header 🤐
An IM reply for a page-mode IM isn't linked in any way to the initial IM, and it can end up at a different user agent from where the initial IM started, depending on how the recipient URI gets resolved 🗺️ So IM replies may go through different intermediaries. An IMDN, on the other hand, needs to go through the same intermediaries as the IM itself 🛤️ That's because those intermediaries may be required to report negative delivery notifications if the IM wasn't delivered successfully 😬 Some of them, for example store-and-forward servers, may report that an IM has been processed and later report that it failed to be delivered 💔
For the reasons above, an intermediary MAY choose to stay on the path of IMDNs for a specific IM ✨ It can do that by adding a CPIM IMDN-Record-Route header field as the top IMDN-Record-Route header field. The value of this field MUST be the intermediary's own address 🏠 An intermediary that doesn't support this extension obviously won't add the IMDN-Record-Route header field. This lets IMDNs go directly from the IM Recipient back to the IM Sender, even if the IM went through an intermediary that doesn't support this extension 🦋
An intermediary that receives an IMDN checks the top IMDN-Route header field 👀 If that header field carries the intermediary address, the intermediary removes that value and forwards the IMDN to the address in the new top IMDN-Route header field. If there are no additional IMDN-Route header fields, the IMDN is forwarded to the address in the CPIM To header field 📮
An intermediary MUST remove any information about the final recipients of a list if the list membership isn't disclosed 🤫 It does that by removing the <recipient-uri> element and/or <original-recipient-uri> element from the body of the IMDN before forwarding it to the IM Sender 💜
8.1. Constructing Processing Notifications 💌
okay so intermediaries are the ONLY ones who build processing notifications 🫶 and they only do it if the IM Sender asked for one by putting a Disposition-Notification header field with the value "processing" in there ✨
the intermediary can make and send "processing" notifications to say an IM has been processed or stored 💅 but it MUST NOT send more than one IMDN for the same disposition type. so no sending a "processing" notification saying the IM is being "processed" and then ANOTHER one saying that same IM is "stored" 🙈 one per type, bestie!!
building one is basically like how the IM Recipient builds a delivery notification, so go check Section 7.2.1.1 for the deets 🦋
here's an example:
Content-type: Message/CPIM
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<processing-notification>
<status>
<processed/>
</status>
</processing-notification>
</imdn>sometimes the intermediary just can't know what happened to an IM 😭 in that case it makes a processing notification with a <status> value of "error" to say so 💀 honest and iconic 💜
8.2. Constructing Delivery Notifications 🚚
okay the negative ones 🌸 intermediaries MAY build negative delivery notifications ✨ but only if the IM Sender asked for a "negative-delivery" notification by including a Disposition-Notification header field with the value "negative-delivery" AND an error actually came back for that IM 🙅♀️
the intermediary can make and send "negative-delivery" notifications to say an IM failed to get delivered 💔 same rule applies here: it MUST NOT send more than one IMDN for the same disposition type. so no "failed" notification saying the IM failed, followed by a different IMDN saying an IMDN is "forbidden" 😭 that's just chaos
and building one is kinda like the IM Recipient does it, so peep Section 7.2.1.1 for the full breakdown 🧚
8.3. Aggregation of IMDNs 🦋
ngl this part is giving group project energy 🫠 but I promise it's cute
first, reminder: URI-List servers are intermediaries 💁♀️
a URI-List server can decide (based on local policy, its own rules basically 💅) whether to bundle IMDNs together into one aggregated IMDN OR just send them one at a time. if it goes with aggregating, it can wait for a configurable amount of time OR until every recipient has sent their IMDN, whichever happens first ⏰ then it sends the aggregated IMDN 🎀
tea ☕: some IMDNs, like "displayed" ones, may just never show up because of user settings 👀 so waiting around forever isn't the move. how long to wait before sending the aggregated IMDN, and when to forget the state for that IM, is totally up to the administrator's config and the implementation 🫶
a URI-List server MAY send MULTIPLE aggregated IMDNs for the same IM 🌈 here's how that can go: start a timer, and when it fires, grab whatever IMDNs it has collected so far, send them as one aggregate, and restart the timer for the next batch 💜 this comes in clutch when the IM Sender asked for more than one kind of IMDN for a single IM (like delivery notifications AND display notifications) 📬 or when the server is running low on resources and decides forwarding IMs matters more than forwarding IMDNs 🏃♀️💨
there can also be a second timer running 🕰️ and when THAT one fires, the state of the IM gets deleted. after that point, the URI-List server just eats up any IMDNs that show up late 🍽️😋
quick heads up!! the timer stuff in the paragraphs above is NOT normative. it's only there to help explain one way you could build aggregation 🧚 so don't treat it as a rule!
a URI-List server MAY aggregate IMDNs when the list membership info isn't disclosed 🙈 and it's totally possible for a server to start sending aggregated IMDNs and then switch over to individual ones, or the other way around 🔁 a timer going off a lot can actually cause exactly that 🌀
the aggregated IMDN gets built using the multipart/mixed MIME type, with every IMDN that was received (as message/imdn+xml) included as its own individual payload 🎁
here's an example of aggregated IMDNs:
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: multipart/mixed;
boundary="imdn-boundary"
Content-Disposition: notification
Content-length: ...
--imdn-boundary
Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
</status>
</delivery-notification>
</imdn>
--imdn-boundary
Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>
--imdn-boundary9. Identifying Messages 🔍
okay detective time 🕵️♀️ messages usually travel inside a transport protocol like SIP [RFC3261] 📨 if the payload carried by that transport protocol has NO parts of type Message/CPIM, then the message is an IM 💬 and if the payload DOES have Message/CPIM parts, but none of those parts holds a payload of type "message/imdn+xml", it's still an IM ✨
one thing to remember: it is not valid to try to pack both an IM AND an IMDN into a multipart payload in a single transport protocol message 🙅♀️ rule of the group chat, no exceptions 💅
so how do you tell a delivery notification? you look at its contents 👀 it's a delivery notification if the Content-type header field has the value "message/imdn+xml", the Content-Disposition header field has the value "notification", AND the <delivery-notification> element shows up in that XML body 💖
processing notifications and display notifications get identified the same way 🫶 the only difference is which element you're looking for: <processing-notification> for processing, and <display-notification> for display 🎀
10. Header Fields Formal Syntax 📝
this is the grammar part, so buckle up 🤓 the syntax below uses the message header field syntax from Section 3 of RFC 3862 [RFC3862] 💜
header field syntax gets described WITHOUT any namespace qualification 🧼 and following the rules in RFC 3862 [RFC3862], header field names and other text are case sensitive, so they MUST be used exactly as given, with the same upper-case and lower-case letters 🔠 no vibes-based capitalisation allowed 💀
Disposition-Notification =
"Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))]
notify-req =
("negative-delivery" / "positive-delivery" /
"processing" / "display" / Token) *(SEMI disp-notify-params)
disp-notify-params = Ext-param
Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
SEMI = *SP ";" *SP ; semicolon
COMMA = *SP "," *SP ; comma11. IMDN Format 🎀
11.1. Structure of an XML-Encoded IMDN Payload 🧁
an IMDN payload is an XML document [XML] 📄 it MUST be well-formed AND MUST be valid according to the schemas (extension schemas included) that the validator has access to and that apply to the XML document ✅ the payload MUST be based on XML 1.0 AND MUST be encoded using UTF-8 🌸
the schema lets qualified extension elements show up in several spots that aren't in the "urn:ietf:params:xml:ns:imdn" namespace 🌈 to keep things forwards compatible (so newer instance documents still work with existing consumers), new specifications MUST NOT extend the allowable content of this specification 🙅♀️ backwards compatibility (so existing instance documents still work with updated, newer consumers) MAY break if there are clashes with the existing qualified names of extension elements and possible future specifications 💔 and the IETF MAY specify new extension elements inside the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/imdn+xml MIME type 🧚
future specs can add new element definitions using the combine="interleave" pattern ✨ when several elements of that new type are allowed, the new definition MUST contain the <zeroOrMore> cardinality rule 🔁 if the new spec only allows ONE new element, the <optional> cardinality rule MUST be used 🫶 these cardinality rules keep existing instance documents compatible with newer consumers 💜 and the new specification MUST then redefine either the "anyIMDN" extension or the individual extension points that reference it, so that new element definitions don't match this redefined, more limited wildcard pattern 🛡️
the namespace identifier for elements defined by this spec is a URN [URN] 🌍 it uses the namespace identifier 'ietf' defined by [URN_NS] and extended by [IANA] ✨ the full urn is: urn:ietf:params:xml:ns:imdn 💖
this namespace declaration tells you which namespace the IMDN is based on 🎀
the root element is <imdn> 👑 the <imdn> element has these sub-elements: <message-id>, <datetime>, <recipient-uri>, <original-recipient-uri>, <subject>, and ONE of <delivery-notification>, <processing-notification>, or <display-notification> 🌷 a <status> also shows up as a sub-element of <delivery-notification>, <processing-notification>, and <display-notification> 🦋 each element gets its own detailed section, so keep reading 📖
<imdn> can be extended in the future to include new disposition notification types or other elements, as described in Section 11.1.9 🌟
11.1.1. The <message-id> Element 🪪
the <message-id> element is mandatory according to the XML schema 💅 and it carries the message ID that showed up in the Message-ID header field of the IM 🫶
11.1.2. The <datetime> Element ⏰
the <datetime> element is mandatory 💫 it carries the date and time the IM was sent (NOT the IMDN!! 🙈) and that info comes from the DateTime header field of the IM 📅
11.1.3. The <recipient-uri> Element 📬
the <recipient-uri> element is optional 🌸 it carries the URI of the final recipient 🎯 and that info is pulled from the CPIM To header field of the IM 💌
11.1.4. The <original-recipient-uri> Element ✨
okay so the <original-recipient-uri> element is optional 🌸, but if the IM carried an Original-To header field, it MUST be there 💅. It carries the URI of the original recipient, and you grab that info straight from the IM's Original-To header field 🦋.
11.1.5. The <subject> Element 🎀
The <subject> element is optional 💜. If it's there, it MUST carry the text and language attributes that were in the Subject header field (if there was one) 👑. This is how a human can spot the match between an IM and its IMDN, iykyk 🙈. If an IM has more than one Subject header field, picking any one of them for the IMDN payload <subject> element is totally fine ✨. The sender then compares Subject header fields until it's determined to be a match or not a match 💅.
11.1.6. The <delivery-notification>, <processing-notification>, and <display-notification> Elements 🦋
One of the <delivery-notification>, <processing-notification>, and <display-notification> elements is mandatory 💖. It carries the disposition type that the IM Sender requested and that's being reported, and it carries the sub-element <status> 🌈.
11.1.7. The <status> Element 💀
The <status> element is mandatory 💅 and carries the result of the disposition request ✨. Here's the tea:
- For
<delivery-notification>, it can carry one of<delivered>,<failed>,<forbidden>, or<error>📦. - For
<display-notification>, it can carry one of<displayed>,<forbidden>, or<error>👀. - For
<processing-notification>, it can carry one of<processed>,<stored>,<forbidden>, or<error>🧚.
<forbidden> means the disposition was denied 🙅♀️, and <error> means internal server error 😭. The <status> element can also be extended to carry any other status extension 🌸.
11.1.8. MIME Type for IMDN Payload 🍓
The MIME type for the IMDN payload is message/imdn+xml 💜. The IMDN MUST identify the payload as MIME type message/imdn+xml in the Content-type header field 🫶.
11.1.9. The RelaxNG Schema 🧠
Here's the RelaxNG schema, exactly as written. Don't touch a single character, bestie 🎀:
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:imdn">
<start>
<element name="imdn">
<element name="message-id">
<data type="token"/>
</element>
<element name="datetime">
<data type="string"/>
</element>
<optional>
<element name="recipient-uri">
<data type="anyURI"/>
</element>
<element name="original-recipient-uri">
<data type="anyURI"/>
</element>
<optional>
<element name="subject">
<data type="string"/>
</element>
</optional>
</optional>
<choice>
<ref name="deliveryNotification"/>
<ref name="displayNotification"/>
<ref name="processingNotification"/>
<empty/>
</choice>
<ref name="imdnExtension"/>
</element>
</start>
<define name="deliveryNotification">
<element name="delivery-notification">
<element name="status">
<choice>
<element name="delivered">
<empty/>
</element>
<element name="failed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="deliveryExtension"/>
</element>
</element>
</define>
<define name="displayNotification">
<element name="display-notification">
<element name="status">
<choice>
<element name="displayed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="displayExtension"/>
</element>
</element>
</define>
<define name="processingNotification">
<element name="processing-notification">
<element name="status">
<choice>
<element name="processed">
<empty/>
</element>
<element name="stored">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="processingExtension"/>
</element>
</element>
</define>
<define name="commonDispositionStatus">
<choice>
<element name="forbidden">
<empty/>
</element>
<element name="error">
<empty/>
</element>
</choice>
</define>
<!-- <imdn> extension point for the extension schemas to add
new definitions with the combine="interleave" pattern.
Extension schemas should add proper cardinalities. For
example, the <zeroOrMore> cardinality should be used if
the extension is to allow multiple elements, and the
<optional> cardinality should be used if the extension
is to allow a single optional element. -->
<define name="imdnExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- delivery-notification <status> extension point -->
<define name="deliveryExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- display-notification <status> extension point -->
<define name="displayExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- processing-notification <status> extension point -->
<define name="processingExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- wildcard definition for complex elements (of mixed type)
unqualified or qualified in the imdn namespace.
Extension schemas MUST redefine this or the
individual, previous definitions that use this definition.
In other words, the extension schema MUST reduce the
allowable content in order to maintain deterministic
and unambiguous schemas with the interleave pattern. -->
<define name="anyIMDN">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:imdn"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="anyExtension"/>
</element>
</define>
<!-- the rest of the "anyIMDN" wildcard definition -->
<define name="anyExtension">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="any"/>
</choice>
</zeroOrMore>
</define>
<!-- wildcard type for complex elements (of mixed type)
without any namespace or content restrictions -->
<define name="any">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="any"/>
</choice>
</zeroOrMore>
</element>
</define>
</grammar>12. Transporting Messages Using SIP ✨
12.1. Endpoint Behaviour 🌷
12.1.1. Sending Requests 📨
The IM Sender constructs a SIP MESSAGE request using RFC 3428 [RFC3428] 💌. The Content-type header field tells you the MIME type of the request payload. When using this extension, the Content-type header field MUST be of MIME type "message/cpim" [RFC3862] for both IMs and IMDNs 🫶. The IM Sender constructs the payload according to Section 7 ✨.
The IM Sender constructs a SIP MESSAGE request to multiple recipients in a similar manner as a SIP MESSAGE request to a single recipient 👯♀️. "Multiple-Recipient MESSAGE Requests in SIP" [RFC5365] describes the differences 💜.
IM Senders can remain anonymous 🕶️. For example, the sender can set the SIP From header field of the SIP message to an anonymous URI. As there is no return address, anonymous IM Senders SHOULD NOT request disposition notifications 🙈. An IM Recipient MAY ignore such a request if the IM Sender is anonymous 🌈.
12.1.2. Sending Responses 💅
An endpoint receiving a SIP MESSAGE request constructs a SIP response according to RFC 3428 [RFC3428] 🦋. Of course, an endpoint will send a SIP response to the MESSAGE request regardless of the type of message (IM or IMDN) it has received, or the disposition type it has been asked for 💖.
12.1.3. Receiving Requests 🧚
12.1.3.1. Instant Message 💬
okay so first things first, how do you know a SIP MESSAGE request is an IM? You check its contents, following Section 9 🫶
If an IM Recipient gets a SIP MESSAGE request that's an IM asking for a positive-delivery notification, and they've already built and sent a SIP 2xx class response, they MAY generate a positive-delivery notification. But they have to make sure the IM has actually been delivered to the user or application first 🙈 A gateway, for example, can send a 2xx before the final recipient even got the IM, so that 2xx isn't proof of anything. The IM Recipient builds the positive-delivery notification following Section 7.2.1.1, then drops it in as the payload of a SIP MESSAGE request 📦
If an IM Recipient gets a SIP MESSAGE request that's an IM asking for a negative-delivery, and they've already sent a 2xx class response, they SHOULD generate a negative-delivery notification if they found out the final recipient or application did not receive the IM. This is giving "something went wrong behind the scenes" energy 😭 A gateway, for example, can send a 2xx before it hears back an error response from downstream, or before any internal timers go off while it's waiting for a response. The negative-delivery notification is built according to Section 7.2.1.1, and then the message goes in as the payload of a SIP MESSAGE request.
If an IM Recipient gets a SIP MESSAGE request that's an IM asking for a negative-delivery notification, and they've constructed and sent a non-2xx final response, they MUST NOT generate a negative-delivery notification. No notification for you, periodt 💅
If an IM Recipient gets a SIP MESSAGE request that's an IM asking for a display notification, and they've already sent a SIP 2xx class response, they MAY generate a display notification after making sure the IM has been presented to the user or application ✨ Figuring out whether the IM has actually been read is outside the scope of this document, so we're not going there 🦋 Also, the decision to send a display notification can be left up to the user, and an application may let a user configure that choice. The IM Recipient constructs the display notification according to Section 7.2.1.2, then places the message as the payload in a SIP MESSAGE request 🌸
For IMDNs, the IM Recipient fills in the SIP Request-URI and the SIP To header field using the address that appeared in the SIP From header field in the IM. Basically, the notification goes right back to the sender 💜
12.1.3.2. Delivery Notification 📬
A SIP MESSAGE request is identified as a delivery notification by examining its contents according to Section 9. Same energy as before, just checking the contents 🧚
12.1.3.3. Display Notification 👀
A SIP MESSAGE request is identified as a display notification by examining its contents according to Section 9. Contents, contents, contents 💅
12.2. Intermediary Behaviour 🧚♀️
okay, so in this context, intermediaries are things like application servers (including URI-List and store-and-forward servers) and gateways. SIP Proxies MUST NOT generate IMDNs, but they MUST forward them like any other SIP request. Proxies are the messengers, not the authors 📮
Intermediaries forward a SIP MESSAGE request to multiple recipients according to [RFC5365] 🌈
If an intermediary receives an IM, it checks the body. If the body is of type "message/cpim", the intermediary then looks for a Disposition-Notification CPIM header field in the message. If that header field has either the value "positive-delivery" or "negative-delivery", and the intermediary generates a SIP 2xx class response to the MESSAGE request while processing the IM, then the intermediary does the following 🔍
If the Disposition-Notification header field contains a value of "positive-delivery", the intermediary MUST NOT generate a delivery notification when it gets a SIP 2xx class response for the sent IM. Just because a downstream entity got a MESSAGE request doesn't mean the message was relayed to its ultimate destination or was delivered. So the intermediary can't say delivery happened just because it got a 2xx response. Not vibing with that assumption 🙅♀️
If the Disposition-Notification header field contains a value of "negative-delivery", the intermediary SHOULD generate a delivery notification if it gets a SIP 4xx, 5xx, or 6xx class final response for the sent IM. If it already got a SIP 2xx class response followed by a negative-delivery notification, the intermediary either forwards that negative-delivery notification or aggregates it 🫶
If the Disposition-Notification header field contains a value of "processing", the intermediary MAY generate a processing notification after it has forwarded or stored the IM. The rest of the procedures in Section 8.1 apply 💖
The procedure for generating such an IMDN is the same as the one for an IM Recipient (Section 7.2.1.1). Copy the homework, bestie 📝
The <recipient-uri> element of the XML body is populated with the URI of the IM Recipient 🎀
If an intermediary receives a SIP MESSAGE request carrying a positive delivery notification or a display notification, it forwards it using the rules in Section 8. Forwarding is the whole job here 🚀
13. Transporting Messages using MSRP 🦋
The Message Session Relay Protocol (MSRP) [RFC4975] already has a built-in way to supply positive and negative delivery reports ✨ It does NOT give you built-in display or processing notifications, though. Honestly that makes sense, because in session mode these notifications aren't as useful as they are in page mode. The base use case for MSRP is that the recipient user agent renders SEND requests right away, one after another, which is the whole session experience. Page mode is different, because a user has to actively go and open the message, click a button, and so on to read it 📖
If new requirements come up in the future that show a need for IMDN in MSRP, new specifications can be drafted 🌟
14. Security Considerations 🔐
okay, this section is serious business, so buckle up 😭 IMDNs give a fine-grained view of what the IM Recipient is up to, so they deserve really careful confidentiality protection. That way only the intended recipient of the IMDN gets it. In most cases, the intended recipient is the IM Sender 💌
Since the IM transport protocol carries the IMDN, all the security considerations of the underlying IM protocol also apply to IMDNs. Double whammy, no cap 💀
The threats in the IMDN system, on top of the threats that are already inherent to IM, include the following:
- A malicious endpoint tries to send messages to a user who wouldn't normally want messages from that endpoint, by tricking the IMDN system into "bouncing" an IMDN from an unsuspecting endpoint to the user 👻
- A malicious endpoint tries to flood an IM Sender with IMDNs by tricking a URI-List server into sending IMDNs to an unsuspecting IM Sender 🌊
- A malicious intermediary or node tries to flood a target node with IMDNs by inserting the target's address in the
Fromfield orIMDN-Record-Routefield 🚨 - A malicious node in the network tries to modify an IMDN from an IM Recipient 🙈
- A malicious intermediary tries to forward an IMDN from an IM Recipient to the IM Sender, when the IM Recipient wouldn't normally forward the IMDN to that IM Sender if they knew who the IM Sender was 🕵️♀️
- A malicious endpoint tries to discover the
Request-URIof an endpoint beyond an intermediary, when that endpoint would normally want to keep its identity private from the malicious endpoint 🫣 - A malicious node in the network tries to eavesdrop on IMDN traffic to, for example, learn
Request-URIor traffic pattern information 👂 - A malicious node in the network tries to stage a denial-of-service attack on an intermediary by requesting a large list expansion 💥
The protocol cannot protect against attacks that include the following:
- A malicious intermediary directly reveals the identity of a downstream endpoint that wouldn't normally want its identity revealed. Keeping that information private is an intermediary implementation issue 🙃
- A malicious IM Recipient alters the time of the IMDN. There's no protocol mechanism to make sure the IM Recipient doesn't lie about the time, or purposely holds an IMDN for transmission to make it look like the IM was read later than it actually was. Major unreliable narrator energy 🕰️
- A deletion attack on an IMDN. This is a trade-off between privacy and security. The privacy considerations let the IM Recipient silently ignore an IMDN request. Any mechanism that could reliably show a malicious node deleted an IM Recipient's IMDN would also be good for detecting an IM Recipient who chose not to issue an IMDN 🫥
To fight eavesdropping, modification, and man-in-the-middle attacks, we require some level of authentication and integrity protection. That said, there are situations where strong integrity would be overkill 🙄 The presumption is that the IM Sender has set, and sets the expectation for, the level of protection. The procedures for integrity protection are below 🔒
- If the IM Recipient has a certificate, it MUST sign the IMDN. Signing the IMDN provides integrity protection. While an intermediary can replace the IMDN body, the IM Sender (the recipient of the IMDN) can validate the signature and note that the IMDN doesn't come directly from the IM Receiver. That's not a problem if the IM Sender trusts the intermediary. On the flip side, an IMDN in response to a signed IM without a signature means something bad might have happened 🚩
- If the IM is encrypted, the IM Recipient or intermediary MUST encrypt the IMDN body, because an attacker might try to figure out the user's activity profile and identity by sniffing IMDNs on the network 🕵️
- The two above rules are cumulative 💅
The IM Recipient or intermediary MUST be capable of accessing the IM Sender's public certificate so it can verify the signature in the IM 🔑
CPIM security considerations [RFC3862] apply here, because this is an extension of CPIM. To make the IMDN mechanism independent of the transport protocol, the Working Group chose to put routing information into the IMDN application-layer payload. One consequence of that choice is that end-to-end encryption becomes impossible 😤
An attacker can mount a distributed denial-of-service attack on a node by sending lots of IMs with IMDN requests to that node. This is the same problem that exists without IMDN. IMDN just increases the load on the node under attack linearly. You can mitigate this threat, but not eliminate it, by having the endpoint immediately ignore requests that aren't authenticated 🛡️
One way to address the chance that a malicious node uses the IMDN system to anonymize attacks is to log all IMDN requests on the IM Recipient user agent. That lets you track attacks, though only after they happen. Note that this also puts a burden on the IM Recipient user agent host. Limited user agents may not be able to keep much of a log 📓
Likewise, an attacker can mount a denial-of-service attack on an intermediary by asking it to explode a large list 💣
The following security considerations apply when using IMDNs.
14.1. Forgery 🎭
okay so first things first, IMs can be forged 😭 bestie, that's the scary part. the fix is that an IM can be signed 🔐 and now here's the tricky bit: if an intermediary gets a signed message and needs to change any part that's covered by the signature (like tacking an Original-To header field onto the CPIM header fields), it MUST consume the IM and make a brand new copy that it signs itself ✍️ no sneaky edits allowed!
IMDNs can be forged just as easily as regular IMs, so yikes 💀 endpoints and intermediaries that want to use IMDNs automatically should take appropriate precautions to keep the damage from denial-of-service attacks small 🛡️ the forgery threats include a falsified IMDN getting sent when the disposition hasn't actually happened. like, a display notification could be faked to make it look like the IM was displayed to the Recipient 👀 and unsolicited IMDNs are another form of forgery, so be careful, babe 🙅♀️
14.2. Confidentiality 🤫
sometimes an IM Recipient just doesn't want anyone to know they got the IM, or even read it, and that's valid 🫶 in that situation, it's okay for them to quietly ignore requests for an IMDN. but also, it is strongly RECOMMENDED that the IM Recipient gets the user's consent before sending an IMDN 💖 the exceptions are IM systems that are required by regulation to issue an IMDN, like in health care or the financial world 🏥💰
the consent can come from a prompt or dialog box on each IM 💬 or from a global preference setting, or some other user-configurable mechanism ⚙️ the user can also say globally that IMDNs are never to be sent, or that a "forbidden" IMDN status always goes out when someone asks for one 🙅♀️
here's a plot twist 🎢 a user can send an IM and request IMDNs to a list whose member info isn't disclosed. in that case, the user will learn who's on the list, so the URI-List server MUST remove any information about list members 🧹 and if the number of members isn't disclosed either, the URI-List server MUST only deliver one aggregated IMDN 📦 or, as an alternative, the URI-list server MAY reject the IM ✋
a list server might not understand IMDN at all 🙈 IM Recipients might notice that the To header field is a list name rather than their own name. in that case, the IM Recipient can take whatever action they want if they'd like to keep their identity private 🕵️♀️
one more big one 💅 an unencrypted IMDN could leak confidential info about an encrypted IM. so the same level of security that applies to an IM MUST also be applied to its IMDNs 🔒 for example, if an IM is signed and encrypted, the IMDN must be signed and encrypted too. no loopholes, periodt 💯
14.3. IMDN as a Certified Delivery Service 📬
IMDNs cannot be relied on as a guarantee that an IM was or wasn't seen by the user 😬 even when nobody's forging them, they can get lost in transit 🌪️ and the IM Recipient could also skip the IMDN issuing mechanism through policy, or by messing with their user agent Server 🙃
15. IANA Considerations 🎀
15.1. message/imdn+xml MIME TYPE 💌
okay this section registers a brand new MIME type, "message/imdn+xml", and a new XML namespace too ✨ it follows the guidelines in RFC 3023 [RFC3023] and here are all the registration details:
MIME media type: message
MIME subtype name: imdn+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 14 of this document.
Interoperability considerations: none
Published specification: This document
Applications which use this media type: This media type is used to
support CPIM-based instant Messaging.
Additional information: none
Magic number: none
File extension: .cl or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@gmail.com)
Intended Usage: COMMON
Author/change controller: The IETF15.2. XML Registration 🧾
this part registers a new XML namespace and schema, following the guidelines in the IETF XML Registry [IANA] 🌸 the namespace URI is urn:ietf:params:xml:ns:imdn, and its schema lives in Section 11.1.9 above. the registrant contacts are the IETF, the SIMPLE working group, and Hisham Khartabil (hisham.khartabil@gmail.com) 📇
15.3. URN Registration for IMDN Header Parameters 🔖
per [RFC3553], we're setting up a registry for IMDN header parameters 🗂️ new entries are Specification Required, and the registry is called urn:ietf:params:imdn. the specification is RFC 5438, and extra values can be defined by a Standards Action [RFC5226] that updates or obsoletes RFC 5438. the repository is RFC 5438 too 🦋
the index value is the IMDN header name. values under urn:ietf:params:imdn need RFC publication, and the index value has to follow the rules for a legal IMDN header name. so the name has to be a string of octets from the restricted set of US-ASCII characters, per Section 3.1 of [RFC3553]. and the index value is case sensitive, so capitalisation counts 🔠
the URI for a header gets formed from its name in two steps:
a) replacing any non-URN characters (as defined by RFC 2141 [URN])
with the corresponding '%hh' escape sequence (per RFC 3986
[RFC3986]) and
b) prepending the resulting string with 'urn:ietf:params:imdn:'.so the URI for the CPIM message IMDN header Disposition-Notification: would be urn:ietf:params:imdn:Disposition-Notification ✨ and here are the initial values:
+--------------------------+---------------------+
| Index Value | Reference |
+--------------------------+---------------------+
| Disposition-Notification | RFC5438 Section 6.2 |
| Message-ID | RFC5438 Section 6.3 |
| Original-To | RFC5438 Section 6.4 |
| IMDN-Record-Route | RFC5438 Section 6.5 |
| IMDN-Route | RFC5438 Section 6.6 |
+--------------------------+---------------------+15.4. Content-Disposition: notification 📎
this document registers one new Content-Disposition header field "disposition-types": notification 🎉 it's been recorded in the IANA registry for Mail Content Dispositions. the motivation and examples for it are in Section 7.2.1.1 and Section 9 💖
here's the short description for the registry: notification means the payload of the message carrying this Content-Disposition header field value is an Instant Message Disposition Notification, as requested in the corresponding Instant Message 💜
16. Acknowledgements 🫶
huge thanks to Jari Urpalainen for the thorough review and the suggestions for the RelaxNG schema 🌷 the authors also want to thank Paul Kyzivat, Ben Campbell, Adam Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen, Miguel Garcia, Eric McMurry, Jon Peterson, and Robert Sparks for their comments and support 🙌 and a special shoutout to the Gen-Art reviewer extraordinaire, Spencer Dawkins 👑
17. References 📚
17.1. Normative References 🧠
[IANA] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000.17.2. Informative References 🌈
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol
(SIP)", RFC 5365, October 2008.
[URN_NS] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.Authors' Addresses 🖊️
Eric Burger
Unaffiliated
New Hampshire
USA
Phone:
Fax: +1 603 457 5933
EMail: eburger@standardstrack.com
Hisham Khartabil
Ericsson Australia
Melbourne
Australia
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com📦 where this page comes from
- ietf: rfc5438 2009-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms