From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5438.txt | 2131 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2131 insertions(+) create mode 100644 doc/rfc/rfc5438.txt (limited to 'doc/rfc/rfc5438.txt') diff --git a/doc/rfc/rfc5438.txt b/doc/rfc/rfc5438.txt new file mode 100644 index 0000000..3b8b921 --- /dev/null +++ b/doc/rfc/rfc5438.txt @@ -0,0 +1,2131 @@ + + + + + + +Network Working Group E. Burger +Request for Comments: 5438 Unaffiliated +Category: Standards Track H. Khartabil + Ericsson Australia + February 2009 + + + Instant Message Disposition Notification (IMDN) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +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) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + Instant Messaging (IM) refers to the transfer of messages between + users in real-time. This document provides a mechanism whereby + endpoints can request Instant Message Disposition Notifications + (IMDN), including delivery, processing, and display notifications, + for page-mode instant messages. + + The Common Presence and Instant Messaging (CPIM) data format + specified in RFC 3862 is extended with new header fields that enable + endpoints to request IMDNs. A new message format is also defined to + convey IMDNs. + + This document also describes how SIP entities behave using this + extension. + + + + + + + + +Burger & Khartabil Standards Track [Page 1] + +RFC 5438 IMDN February 2009 + + +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 Element ..........................21 + 11.1.2. The Element ............................22 + 11.1.3. The Element .......................22 + 11.1.4. The Element ..............22 + 11.1.5. The Element .............................22 + 11.1.6. The , + , and + Elements ...................22 + 11.1.7. The 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 + + + +Burger & Khartabil Standards Track [Page 2] + +RFC 5438 IMDN February 2009 + + + 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 ...................................37 + +1. Introduction + + In many user-to-user message exchange systems, message senders often + wish to know if the human recipient actually received a message or + has the message displayed. + + Electronic mail [RFC5321] offers a solution to this need 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 + prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an + automaton can process the message. + + The Common Presence and Instant Messaging (CPIM) format, Message/CPIM + [RFC3862], is a message format used to generate instant messages. + The Session Initiation Protocol (SIP [RFC3261]) can carry instant + messages generated using message/CPIM in SIP MESSAGE requests + [RFC3428]. + + This document extends the Message/CPIM message format in much the + same way Message Disposition Notifications extends electronic mail. + This extension enables Instant Message Senders to request, create, + and send Instant Message Disposition Notifications (IMDN). This + mechanism works for page-mode as well as session-mode instant + messages. This document only discusses page-mode. Session-mode is + left for future standardisation efforts. + + + + + + + + +Burger & Khartabil Standards Track [Page 3] + +RFC 5438 IMDN February 2009 + + + This specification defines three categories of disposition types: + "delivery", "processing", and "display". Specific disposition types + provide more detailed information. For example, the "delivery" + category includes "delivered" to indicate successful delivery and + "failed" to indicate failure in delivery. + +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 in the + masculine (he/him/his) and the recipient of the message in the + feminine (she/her/hers). This convention is purely for convenience + and makes no assumption about the gender of a message sender or + recipient. + +3. Terminology + + o IM: An Instant Message generated using the Message/CPIM format. + + o IMDN: An Instant Message Disposition Notification generated using + the Message/CPIM format that carries an IMDN XML document. + + o Message: An IM or an IMDN generated using the Message/CPIM format. + + o 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. + + o 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. + + o Endpoint: An IM Sender or an IM Recipient. + + o 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. + + + + + +Burger & Khartabil Standards Track [Page 4] + +RFC 5438 IMDN February 2009 + + + o Gateway: An intermediary that translates between different IM + systems that use different protocols. + + o IMDN payload: An XML document carrying the disposition + notification information. In this specification, it is of MIME + type "message/imdn+xml". + + o Disposition type: This specification defines three categories of + disposition types: "delivery", "processing", and "display". + + o Transport Protocol Message: A SIP or other protocol message that + contains an IM or IMDN. + +4. Overview + + The diagram below shows the basic protocol flow. An IM Sender + creates an IM, adds IMDN request information that the IM Sender is + interested in receiving, and then sends the IM. At a certain point + in time, the IM Recipient or an intermediary determines that the user + or application has received, did not receive, displayed, or otherwise + disposed of the IM. The mechanism by which an IM Recipient + determines its user has read an IM is beyond the scope of this + document. At that point, the IM Recipient or intermediary + automatically generates a notification message to the IM Sender. + This notification message 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 Flow + + Note the recipient of an IMDN, in some instances, may not be the IM + Sender. This is specifically true for page-mode IMs where the + Address of Record (AOR) of the IM Sender, which is present in the IM, + resolves to a different location or user agent than that from which + + + +Burger & Khartabil Standards Track [Page 5] + +RFC 5438 IMDN February 2009 + + + the IM originated. This could happen, for example, if resolving the + AOR results in forking the request to multiple user agents. For + simplicity, the rest of this document assumes that the IM Sender and + the IMDN Recipient are the same and therefore will refer to both as + the IM Sender. + +5. Disposition Types + + There are three broad categories of disposition states. They are + delivery, processing, and display. + +5.1. Delivery + + The delivery notification type indicates whether or not the IM has + been delivered to the IM Recipient. The delivery notification type + can have the following states: + + o "delivered" to indicate successful delivery. + + o "failed" to indicate failure in delivery. + + o "forbidden" to indicate denial for the IM Sender to receive the + requested IMDN. The IM Recipient can send the "forbidden" state, + but usually it is an intermediary that sends the message, if one + configures it to do so. For example, it is possible the + administrator has disallowed IMDNs. + + o "error" to indicate an error in determining the fate of an IM. + +5.2. Processing + + The processing notification type indicates that an intermediary has + processed an IM. The processing notification type can have the + following states: + + o "processed" to indicate that the intermediary has performed its + task on the IM. This is a general state of the IM. + + o "stored" to indicate that the intermediary stored the IM for later + delivery. + + o "forbidden" to indicate denial for the IM Sender to receive the + requested IMDN. The "forbidden" state is sent by an intermediary + that is configured to do so. For example, the administrator has + disallowed IMDNs. + + o "error" to indicate an error in determining the fate of an IM. + + + + +Burger & Khartabil Standards Track [Page 6] + +RFC 5438 IMDN February 2009 + + +5.3. Display + + The display notification type indicates whether or not the IM + Recipient rendered the IM to the user. The display notification type + can have the following states: + + o "displayed" to indicate that the IM has been rendered to the user. + + o "forbidden" to indicate denial, by the IM Recipient, for the IM + Sender to receive the requested IMDN. + + o "error" to indicate an error in determining the fate of an IM. + + In addition to text, some IMs may contain audio, video, and still + images. Therefore, the state "displayed" includes the start of + rendering the audio or video file to the user. + + Since there is no positive acknowledgement from the user, one cannot + determine if the user actually read the IM. Thus, one cannot use the + protocol described here 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]. A new namespace is created as well as a number of new + CPIM header fields. + +6.1. CPIM Header Field Namespace + + Per 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:imdn + + As per CPIM [RFC3862] requirements, the new header fields defined in + the following sections are prepended, in CPIM messages, by a prefix + assigned to the URN through the NS header field of the CPIM message. + The remainder of this specification always assumes an NS header field + like this one: + + NS: imdn . + + Of course, clients are free to use any prefix while servers and + intermediaries must accept any legal namespace prefix specification. + + + + + +Burger & Khartabil Standards Track [Page 7] + +RFC 5438 IMDN February 2009 + + +6.2. Disposition-Notification + + The IM Sender MUST include the Disposition-Notification header field + to indicate the desire 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 for + which he wishes to receive an IMDN. The Message-ID contains a + globally unique message identifier that the IM Sender can use to + correlate received IMDNs. Because the Message-ID is used by the + sender to correlate IMDNs with their respective IMs, the Message-ID + MUST be selected so that: + + o There is a minimal chance of any two Message-IDs accidentally + colliding during the time period within which an IMDN might be + received. + + o 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 to ensure correct + matching by the sender. The second requirement prevents off-path + attackers from forging IMDNs. In order to meet both of these + requirements, it is RECOMMENDED that Message-IDs be generated using a + cryptographically secure, pseudo-random number generator and contain + at least 64 bits of randomness, thus reducing the chance of a + successful guessing attack 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 element present in the IMDN payload. + IMDNs also carry this header field. Note that since the IMDN is + itself an IM, the Message-ID of the IMDN will be different than 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. The IM Recipient does this by populating + the element in the IMDN. The intermediary + MUST insert this header if the intermediary 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 is already present. Section 10 defines the syntax. + + + +Burger & Khartabil Standards Track [Page 8] + +RFC 5438 IMDN February 2009 + + +6.5. IMDN-Record-Route + + An intermediary MAY insert an IMDN-Record-Route header field to the + IM. This enables the intermediary to 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 provides routing information by including + one or more addresses to which to route the IMDN. 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 + corresponding IMDN, the IM Recipient copies the IMDN-Record-Route + headers into 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 enables the IM + Sender to 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 are not able to retain state over long periods. For + example, mobile devices may have memory or battery limits. Such + limits mean these devices may not be able to, or may choose not to, + keep sent messages for the purposes of correlating IMDNs with sent + IMs. To make some use of IMDN in this case, we add a time stamp to + the IM to indicate when the user sent the message. The IMDN returns + this time stamp to enable the user to correlate the IM with the IMDN + at the human level. We use the DateTime CPIM header field for this + purpose. Thus, if the IM Sender would like an IMDN, the IM Sender + MUST include the DateTime CPIM header field. + + + + +Burger & Khartabil Standards Track [Page 9] + +RFC 5438 IMDN February 2009 + + +7.1.1.3. Adding a Disposition-Notification Header Field + + The Disposition-Notification conveys the type of disposition + notification requested by the IM Sender. There are three types of + disposition notification: delivery, processing, and display. The + delivery notification is further subdivided into failure and success + delivery notifications. An IM Sender requests 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. + + The absence of this header field or the presence of the header field + with an empty value indicates that the IM Sender is not 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 not + defined in this document. + + Section 10 describes the formal syntax for the Disposition- + Notification header field. The following is an example CPIM body of + an IM where the IM Sender requests positive and negative delivery + notifications, but not display notification or processing + notifications: + + From: Alice + To: Bob + NS: 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 World + + + + + + +Burger & Khartabil Standards Track [Page 10] + +RFC 5438 IMDN February 2009 + + +7.1.2. Matching IMs with IMDNs + + An IM Sender matches an IMDN to an IM by matching the Message-ID + header field value in the IM with the element value in + the body of the IMDN. If the IM was delivered to multiple + recipients, the IM Sender uses the element and the + element in the XML body of the IMDN it + received to determine if the IM was sent to multiple recipients and + to identify the IM Recipient that sent the IMDN. + + An IM Sender can determine an IMDN is a disposition notification by + noting if the Content-Disposition in the IMDN is "notification". + This does mean the IM Sender MUST understand the Content-Disposition + MIME header in CPIM messages. + +7.1.3. Keeping State + + This specification does not mandate the IM Sender to keep state for a + sent IM. + + Once an IM Sender sends an IM containing an IMDN request, it MAY + preserve the IM context (principally the Message-ID), other user- + identifiable information such as the IM subject or content, and the + date and time it was sent. Without preservation of the IM context, + the IM Sender will not be able to correlate the IMDN with the IM it + sent. The IM Sender may find it impossible to preserve IM state if + it has limited resources or does not have non-volatile memory and + then loses power. + + There is, however, the concept of a "Sent Items" box in an + application that stores sent IMs. This "Sent Items" box has the + necessary information and may have a fancy user interface indicating + the state of a sent IM. A unique Message-ID for this purpose proves + to be useful. The length of time for items to remain in the "Sent + Items" box is a user choice. The user is usually free to keep or + delete items from the "Sent Items" box as she pleases or as the + memory on the device reaches capacity. + + 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 in response to apparently unsolicited + IMDNs. + + This specification also does not mandate an IM Sender to run any + timers waiting for an IMDN. There are no time limits regarding when + IMDNs may be received. + + + + + +Burger & Khartabil Standards Track [Page 11] + +RFC 5438 IMDN February 2009 + + + IMDNs may legitimately never be received, so the time between the + sending of an IM and the generation and ultimate receipt of the IMDN + may simply take a very long time. Some clients may choose to purge + the state associated with the sent IM. This is the reason for adding + the time stamp in the IM and having it returned in the IMDN. This + gives the user some opportunity to remember what IM was sent. For + example, if the IMDN indicates that the IM the user sent at 2 p.m. + last Thursday was delivered, the user has a chance to remember that + they sent an IM 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 examine the contents of the Disposition-Notification + header field of the CPIM message to determine if the recipient needs + to generate an IMDN for that IM. Disposition-Notification header + fields of CPIM messages can include one or more values. IM + Recipients may need to generate zero, one, or more IMDNs for that IM, + for example, a delivery notification as well as a display + notification. In this 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. That is, it must not + generate a delivery notification indicating "delivered" followed by a + delivery notification indicating "failed" for the same IM. If the IM + Sender requested only failure notifications and the IM was + successfully delivered, then no IMDNs will be generated. If the IM + Recipient does not understand a value of the Disposition-Notification + header field, the IM Recipient ignores that value. + + The IM Recipient MUST NOT generate "processing" notifications. + + A Disposition-Notification header field MUST NOT appear in an IMDN + since it is forbidden to request an IMDN for an IMDN. An IM Sender + MUST ignore a delivery notification request in an IMDN if present. + The IM Sender MUST NOT send an IMDN for an IMDN. + + + + + + + +Burger & Khartabil Standards Track [Page 12] + +RFC 5438 IMDN February 2009 + + + An IMDN MUST contain a Message-ID header field. The same rules of + uniqueness for the Message-ID header field that appears in an IM + apply to an IMDN. The Message-ID header field in the IMDN is + different 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 the + IMDN-Record-Route header fields into IMDN-Route header fields in the + IMDN and maintain their order. The IMDN is then sent to the URI in + the top IMDN-Route header field. IMDN-Record-Route header fields do + not make sense in an IMDN and therefore MUST NOT be placed in an + IMDN. IMDN Recipients MUST ignore it if 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 indicates to the IM Sender that the message is an IMDN to an IM + it has earlier sent. + +7.2.1.1. Constructing Delivery Notifications + + The IM Recipient constructs a delivery notification in a similar + fashion as an IM, using a CPIM body [RFC3862] that carries a + Disposition Notification XML document formatted according to the + rules specified in Section 11. The MIME type of the Disposition + Notification XML document is "message/imdn+xml". + + Section 10 defines the schema for an IMDN. + + The following is an example CPIM body of an IMDN: + + From: Bob + To: Alice + NS: imdn + imdn.Message-ID: d834jied93rf + Content-type: message/imdn+xml + Content-Disposition: notification + Content-length: ... + + + + 34jk324j + 2008-04-04T12:16:49-05:00 + im:bob@example.com + + + +Burger & Khartabil Standards Track [Page 13] + +RFC 5438 IMDN February 2009 + + + im:bob@example.com + + + + + + + +7.2.1.2. Constructing Display Notifications + + The IM Recipient constructs a display notification in a similar + fashion as the delivery notification. See Section 7.2.1.1 for + details. + + Section 10 defines the schema for an IMDN. + + The following is an example: + + From: Bob + To: Alice + NS: imdn + imdn.Message-ID: dfjkleriou432333 + Content-type: message/imdn+xml + Content-Disposition: notification + Content-length: ... + + + + 34jk324j + 2008-04-04T12:16:49-05:00 + im:bob@example.com + im:bob@example.com + + + + + + + + There are situations where the IM Recipient cannot determine if or + when the IM has been displayed. The IM Recipient in this case + generates a display notification with a value of "error" to + indicate an internal error by the server. Note that the IM Recipient + may choose to ignore any IMDN requests and not send any IMDNs. An IM + + + + + +Burger & Khartabil Standards Track [Page 14] + +RFC 5438 IMDN February 2009 + + + Recipient may not wish to let a sender know whether or not a + particular message has been displayed to her. This could be a per- + message, per-sender, or programmed policy choice. + +8. Intermediary Behaviour + + 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 + that it 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, populating it with + the address that was in the CPIM To header field before it was + changed. That is, the intermediary populates the Original-To header + field with the intermediary address. Of course, one may configure an + intermediary to restrict it 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 is not linked in any way to the + initial IM and can end up at a different user agent from where the + initial IM originated, depending on how the recipient URI gets + resolved. Therefore, IM replies may traverse different + intermediaries. An IMDN, on the other hand, needs to traverse the + same intermediaries as the IM itself since those intermediaries may + be required to report negative delivery notifications if the IM was + not delivered successfully. Some of those intermediaries are, for + example, store-and-forward servers that may report that an IM has + been processed and later report that the IM has failed to be + delivered. + + For the reasons stated above, an intermediary MAY choose to remain on + the path of IMDNs for a specific IM. It can do so 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 does not support this extension will + obviously not add the IMDN-Record-Route header field. This allows + IMDNs to traverse directly from the IM Recipient to the IM Sender + even if the IM traversed an intermediary not supporting this + extension. + + + + + +Burger & Khartabil Standards Track [Page 15] + +RFC 5438 IMDN February 2009 + + + An intermediary receiving 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 + indicated in the new top IMDN-Route header field. If no additional + IMDN-Route header fields are present, 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 is not disclosed. The + intermediary does that by removing the element and/or + element from the body of the IMDN before + forwarding it to the IM Sender. + +8.1. Constructing Processing Notifications + + Intermediaries are the only entities that construct processing + notifications. They do so only if the IM Sender has requested a + "processing" notification by including a Disposition-Notification + header field with value "processing". + + The intermediary can create and send "processing" notifications + indicating that an IM has been processed or stored. The intermediary + MUST NOT send more than one IMDN for the same disposition type -- + i.e., it must not send a "processing" notification indicating that an + IM is being "processed" followed by another IMDN indicating that the + same IM is "stored". + + An intermediary constructs a "processing" notification in a similar + fashion as the IM Recipient constructs a delivery notification. See + Section 7.2.1.1 for details. + + The following is an example: + + Content-type: Message/CPIM + + From: Bob + To: Alice + Content-type: message/imdn+xml + Content-Disposition: notification + Content-length: ... + + + + 34jk324j + 2008-04-04T12:16:49-05:00 + im:bob@example.com + im:bob@example.com + + + +Burger & Khartabil Standards Track [Page 16] + +RFC 5438 IMDN February 2009 + + + + + + + + + + There are situations where the intermediary cannot know the fate of + an IM. The intermediary in this case generates a processing + notification with a value of "error" to indicate so. + +8.2. Constructing Delivery Notifications + + Intermediaries MAY construct negative delivery notifications. They + do so only if the IM Sender has requested a "negative-delivery" + notification by including a Disposition-Notification header field + with value "negative-delivery" AND an error was returned for that IM. + + The intermediary can create and send "negative-delivery" + notifications indicating that an IM has failed to be delivered. The + intermediary MUST NOT send more than one IMDN for the same + disposition type -- i.e., it must not send a "failed" notification + indicating that an IM has failed followed by another IMDN indicating + that an IMDN is "forbidden". + + An intermediary constructs a "negative-delivery" notification much + like the IM Recipient. See Section 7.2.1.1 for details. + +8.3. Aggregation of IMDNs + + As previously described, URI-List servers are intermediaries. + + A URI-List server may choose (using local policy) to aggregate IMDNs + or it may send individual IMDNs instead. When a URI-List server + receives an IM and decides to aggregate IMDNs, it can wait for a + configurable period of time or until all recipients have sent the + IMDN, whichever comes first, before it sends an aggregated IMDN. + Note that some IMDNs, for example "displayed" notifications, may + never come due to user settings. How long to wait before sending an + aggregated IMDN and before a URI-List server removes state for that + IM is an administrator configuration and implementation issue. + + A URI-List server MAY choose to send multiple aggregated IMDNs. A + timer can be started, and when it fires, the URI-List server can + aggregate whatever IMDNs it has so far for that IM, send the + aggregated IMDN, and restart the timer for the next batch. This is + needed for scenarios where the IM Sender has requested more than one + + + + +Burger & Khartabil Standards Track [Page 17] + +RFC 5438 IMDN February 2009 + + + IMDN for a specific IM -- for example, delivery notifications as well + as display notifications -- or when the URI-List server is short on + resources and chooses to prioritise forwarding IMs over IMDNs. + + A second timer can be running, and when it fires, the state of the IM + is deleted. In this case, the URI-List server consumes any IMDNs + that might arrive after that time. + + Please note the references to timers in the above paragraphs are not + normative and are only present to help describe one way one might + implement aggregation. + + A URI-List server MAY aggregate IMDNs for the case where the list + membership information is not disclosed. There may be scenarios + where the URI-List server starts sending aggregated IMDNs and + switches to individual ones or visa versa. A timer firing often may + in fact have that effect. + + The aggregated IMDN is constructed using the multipart/mixed MIME + type and including as individual payloads all the IMDNS that were + received as message/imdn+xml. + + Below is an example of aggregated IMDNs. + + From: Bob + To: Alice + NS: imdn + imdn.Message-ID: d834jied93rf + Content-type: multipart/mixed; + boundary="imdn-boundary" + Content-Disposition: notification + Content-length: ... + + --imdn-boundary + Content-type: message/imdn+xml + + + + 34jk324j + 2008-04-04T12:16:49-05:00 + im:bob@example.com + im:bob@example.com + + + + + + + + +Burger & Khartabil Standards Track [Page 18] + +RFC 5438 IMDN February 2009 + + + + + + + --imdn-boundary + Content-type: message/imdn+xml + + + + 34jk324j + 2008-04-04T12:16:49-05:00 + im:bob@example.com + im:bob@example.com + + + + + + + + --imdn-boundary + +9. Identifying Messages + + Messages are typically carried in a transport protocol like SIP + [RFC3261]. If the payload carried by the transport protocol does not + contain any parts of type Message/CPIM, then the message is an IM. + If the payload contains any parts of type Message/CPIM, and none of + those parts contains a payload that is of type "message/imdn+xml", + the message is an IM. It is not valid to attempt to carry both an IM + and an IMDN in a multipart payload in a single transport protocol + message. + + A message is identified as a delivery notification by examining its + contents. The message is a delivery notification if the Content-type + header field present has a value of "message/imdn+xml", the Content- + Disposition header field has a value of "notification", and the + element appears in that XML body. + + A message is identified as a processing notification or display + notification in a similar fashion as a delivery notification. The + difference is that, for a processing notification, the element appears in the XML body. For a display + notification, the element appears in the XML + body. + + + + + +Burger & Khartabil Standards Track [Page 19] + +RFC 5438 IMDN February 2009 + + +10. Header Fields Formal Syntax + + The following syntax specification uses the message header field + syntax as described in Section 3 of RFC 3862 [RFC3862]. + + Header field syntax is described without a namespace qualification. + Following the rules in RFC 3862 [RFC3862], header field names and + other text are case sensitive and MUST be used as given, using + exactly the indicated upper-case and lower-case letters. + + 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 ; comma + +11. IMDN Format + +11.1. Structure of an XML-Encoded IMDN Payload + + An IMDN payload is an XML document [XML] that MUST be well-formed and + MUST be valid according to schemas, including extension schemas, + available to the validater and applicable to the XML document. The + IMDN payload MUST be based on XML 1.0 and MUST be encoded using + UTF-8. + + The schema allows qualified extension elements in several positions + other than the "urn:ietf:params:xml:ns:imdn" namespace. To maintain + forwards compatibility (i.e., newer instance documents can be used by + existing consumers), the new specifications MUST NOT extend the + allowable content of this specification. The backwards compatibility + + + +Burger & Khartabil Standards Track [Page 20] + +RFC 5438 IMDN February 2009 + + + (i.e., existing instance documents can also be used by updated, new + consumers) MAY break if there are conflicts with the existing + qualified names of extension elements and possible future + specifications. The IETF MAY specify new extension elements within + the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/ + imdn+xml MIME type. + + Possible future specifications can add new element definitions with + the combine="interleave" pattern. When multiple elements of this new + type are then allowed, the new definition MUST contain the + cardinality rule. If the new specification does allow + only a single new element, the cardinality rule MUST be + used. These cardinality requirements maintain the backwards + compatibility of existing instance documents with newer consumers. + Also, the new specification MUST then redefine either the "anyIMDN" + extension or the individual extension points that reference it, so + that new element definitions do not match with this redefined and + more limited wildcard pattern. + + The namespace identifier for elements defined by this specification + is a URN [URN], using the namespace identifier 'ietf' defined by + [URN_NS] and extended by [IANA]. This urn is: + urn:ietf:params:xml:ns:imdn. + + This namespace declaration indicates the namespace on which the IMDN + is based. + + The root element is . The element has sub-elements, + namely , , , , , and one of , + , or . A + also appears as a sub-element of , + , and . The elements + are described in detail in the following sections. + + 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 Element + + The element is mandatory according to the XML schema and + carries the message ID that appeared in the Message-ID header field + of the IM. + + + + + + + + +Burger & Khartabil Standards Track [Page 21] + +RFC 5438 IMDN February 2009 + + +11.1.2. The Element + + The element is mandatory and carries the date and time the + IM was sent (not the IMDN). This information is obtained from the + DateTime header field of the IM. + +11.1.3. The Element + + The element is optional and carries the URI of the + final recipient. This information is obtained from the CPIM To + header field of the IM. + +11.1.4. The Element + + The element is optional and carries the URI + of the original recipient. It MUST be present if the IM carried the + Original-To header field. This information is obtained from the + Original-To header field of the IM. + +11.1.5. The Element + + The element is optional. If present, it MUST carry the + text and language attributes that were in the Subject header field, + if any. This allows for a human-level correlation between an IM and + an IMDN. If there are more than one Subject header fields in an IM, + selecting any one of them to place in the IMDN payload + element will suffice. The sender then needs to compare Subject + header fields until a match or not match is determined. + +11.1.6. The , , and + Elements + + The appearance of one of the , , and elements is mandatory and + carries the disposition type that the IM Sender requested and is + being reported. It carries the sub-element . + +11.1.7. The Element + + The element is mandatory and carries the result of the + disposition request. For notification type , + it can carry one of the sub-elements , , + , or . For notification type , it can carry one of the sub-elements , + , or . For notification type , it can carry one of the sub-elements , + + + + + +Burger & Khartabil Standards Track [Page 22] + +RFC 5438 IMDN February 2009 + + + , , or . means the disposition + was denied. means internal server error. The + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Burger & Khartabil Standards Track [Page 23] + +RFC 5438 IMDN February 2009 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Burger & Khartabil Standards Track [Page 24] + +RFC 5438 IMDN February 2009 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Burger & Khartabil Standards Track [Page 25] + +RFC 5438 IMDN February 2009 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Burger & Khartabil Standards Track [Page 26] + +RFC 5438 IMDN February 2009 + + + + + + + +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 indicates 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 for which it has + been asked. + +12.1.3. Receiving Requests + +12.1.3.1. Instant Message + + A SIP MESSAGE request is identified as an IM by examining its + contents according to Section 9. + + If an IM Recipient received a SIP MESSAGE request that is an IM + requesting a positive-delivery notification, and that IM Recipient + has constructed and sent a SIP 2xx class response, it MAY generate a + positive-delivery notification after making sure that the IM has been + + + +Burger & Khartabil Standards Track [Page 27] + +RFC 5438 IMDN February 2009 + + + delivered to the user or application. A gateway, for example, can + generate a 2xx response before the final recipient received the IM. + The IM Recipient constructs a positive-delivery notification + according to Section 7.2.1.1. The IM Recipient places the message as + the payload in a SIP MESSAGE request. + + If an IM Recipient received a SIP MESSAGE request that is an IM + requesting a negative-delivery, and that IM Recipient has constructed + and sent a 2xx class response, it SHOULD generate a negative-delivery + notification if it learnt that the final recipient or application did + not receive the IM (a gateway, for example, can generate a 2xx + response before it has an error response from downstream or before + any internal timers fire waiting for a response). The negative- + delivery notification is constructed according to Section 7.2.1.1. + The message is then placed as the payload in a SIP MESSAGE request. + + If an IM Recipient received a SIP MESSAGE request that is an IM + requesting a negative-delivery notification, and the IM Recipient has + constructed and sent a non-2xx final response, it MUST NOT generate a + negative-delivery notification. + + If an IM Recipient received a SIP MESSAGE request that is an IM + requesting a display notification, and that IM Recipient has + constructed and sent a SIP 2xx class response, it MAY generate a + display notification after making sure that the IM has been presented + to the user or application. It is outside the scope of this document + to discuss how a determination can be made whether the IM has been + read. Note that the decision whether or not to send a display + notification can be left to the user. An application may allow a + user to configure such a choice. The IM Recipient constructs the + display notification according to Section 7.2.1.2. The IM Recipient + places the message as the payload in a SIP MESSAGE request. + + For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP + To header field using the address that appeared in the SIP From + header field in the IM. + +12.1.3.2. Delivery Notification + + A SIP MESSAGE request is identified as a delivery notification by + examining its contents according to Section 9. + +12.1.3.3. Display Notification + + A SIP MESSAGE request is identified as a display notification by + examining its contents according to Section 9. + + + + + +Burger & Khartabil Standards Track [Page 28] + +RFC 5438 IMDN February 2009 + + +12.2. Intermediary Behaviour + + In this context, intermediaries include application servers + (including URI-List and store-and-forward servers) and gateways. SIP + Proxies MUST NOT generate IMDNs but MUST forward them like any other + SIP request. + + Intermediaries forward a SIP MESSAGE request to multiple recipients + according to [RFC5365]. + + If an intermediary receives an IM, the intermediary examines 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 the Disposition-Notification CPIM header field has + either the value "positive-delivery" or "negative-delivery", and, in + processing the IM, the intermediary generates a SIP 2xx class + response to the MESSAGE request, then the intermediary performs the + following actions. + + If the Disposition-Notification header field contains a value of + "positive-delivery", the intermediary MUST NOT generate a delivery + notification if it receives a SIP 2xx class response for the sent IM. + Just because a downstream entity received a MESSAGE request does not + mean the message was relayed to its ultimate destination or was + delivered. Thus, the intermediary cannot say delivery occurred just + because it received a 2xx response. + + If the Disposition-Notification header field contains a value of + "negative-delivery", the intermediary SHOULD generate a delivery + notification if it receives a SIP 4xx, 5xx, or 6xx class final + response for the sent IM. If it has received a SIP 2xx class + response followed by a negative-delivery notification, the + intermediary 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 that of an + IM Recipient (Section 7.2.1.1). + + The element of the XML body is populated with the URI + of the IM Recipient. + + + + + + +Burger & Khartabil Standards Track [Page 29] + +RFC 5438 IMDN February 2009 + + + 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. + +13. Transporting Messages using MSRP + + The Message Session Relay Protocol (MSRP) [RFC4975] already provides + a built-in mechanism to supply positive and negative delivery + reports. These reports do not provide built-in display or processing + notifications. However, these notifications in session-mode are not + as useful as they are for page-mode. This is because the base use + case for MSRP is that the recipient user agent immediately renders + SEND requests sequentially, providing the session experience. This + is unlike page-mode requests where a user has to actively initiate + the display of the message. That is, they need to click on a button, + open a message, and so on to read the message. + + If new requirements arise in the future determining the need for IMDN + in MSRP, new specifications can be drafted. + +14. Security Considerations + + IMDNs provide a fine-grained view of the activity of the IM + Recipient, and thus deserve particularly careful confidentiality + protection so that only the intended recipient of the IMDN will + receive the IMDN. In most cases, the intended recipient of the IMDN + is the IM Sender. + + Since the IM transport protocol carries the IMDN, all security + considerations of the underlying IM protocol also apply to the IMDNs. + + The threats in the IMDN system, over and beyond the threats inherent + to IM, include the following: + + o A malicious endpoint attempts to send messages to a user that + would normally not wish to receive messages from that endpoint by + convincing the IMDN system to "bounce" an IMDN from an + unsuspecting endpoint to the user. + + o A malicious endpoint attempts to flood an IM Sender with IMDNs by + convincing a URI-List server to send IMDNs to an unsuspecting IM + Sender. + + o A malicious intermediary or node attempts to flood a target node + with IMDNs by inserting the target's address in the From field or + IMDN-Record-Route field. + + + + + +Burger & Khartabil Standards Track [Page 30] + +RFC 5438 IMDN February 2009 + + + o A malicious node in the network attempts to modify an IMDN from an + IM Recipient. + + o A malicious intermediary attempts to forward an IMDN from an IM + Recipient to the IM Sender, where the IM Recipient would not + normally forward the IMDN to that IM Sender if the IM Recipient + knew the identity of the IM Sender. + + o A malicious endpoint attempts to discover the Request-URI of an + endpoint beyond an intermediary, where the endpoint would normally + wish to keep its identity private from the malicious endpoint. + + o A malicious node in the network attempts to eavesdrop on IMDN + traffic to, for example, learn Request-URI or traffic pattern + information. + + o A malicious node in the network attempts 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: + + o A malicious intermediary directly revealing the identity of a + downstream endpoint that would not normally wish its identity + revealed. Keeping such information private is an intermediary + implementation issue. + + o A malicious IM Recipient alters the time of the IMDN. There is no + protocol mechanism for ensuring that the IM Recipient does not lie + about the time or purposely holds an IMDN for transmission to make + it appear that the IM displayed to the user was read later than it + actually was. + + o A deletion attack on an IMDN. This is a trade-off between privacy + and security. The privacy considerations allow the IM Recipient + to silently ignore an IMDN request. Any mechanism that would + reliably indicate that a malicious node deleted an IM Recipient's + IMDN would also serve the purpose of detecting an IM Recipient + that chose not to issue an IMDN. + + To combat eavesdropping, modification, and man-in-the-middle attacks, + we require some level of authentication and integrity protections. + That said, there are circumstances where strong integrity would be + overkill. The presumption is that the IM Sender has, and sets the + expectation for, the level of protection. The procedures for + integrity protection are as follows. + + + + +Burger & Khartabil Standards Track [Page 31] + +RFC 5438 IMDN February 2009 + + + o 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 the + IMDN does not come directly from the IM Receiver. This is not a + problem if the IM Sender trusts the intermediary. Likewise, an + IMDN in response to a signed IM without a signature indicates + something bad might have happened. + + o If the IM is encrypted, the IM Recipient or intermediary MUST + encrypt the IMDN body, as an attacker may attempt to discern the + user's activity profile and identity from sniffing IMDNs on the + network. + + o The two above rules are cumulative. + + The IM Recipient or intermediary MUST be capable of accessing the IM + Sender's public certificate in order to verify the signature in the + IM. + + CPIM security considerations [RFC3862] apply here, as this is an + extension of CPIM. In order to make the IMDN mechanism independent + of the transport protocol, the Working Group made the design choice + of putting routing information into the IMDN application-layer + payload. One consequence of this choice is it eliminates the + possibility of having end-to-end encryption. + + An attacker can mount a distributed denial-of-service attack on a + node by sending lots of IMs to the node with IMDN requests. Note + that this is the same problem as there is without IMDN; IMDN simply + linearly increases the load on the node under attack. One can + mitigate, but not eliminate, this threat by the endpoint immediately + ignoring requests that are not authenticated. + + One way to address the potential for a malicious node to use the IMDN + system to anonymize attacks is to log all IMDN requests on the IM + Recipient user agent. This allows for tracking of attacks, if only + after they occur. Note this also puts a burden on the IM Recipient + user agent host. Limited user agents may not be able to preserve + much of a log. + + Likewise, an attacker can mount a denial-of-service attack on an + intermediary by asking the intermediary to explode a large list. + + The following security considerations apply when using IMDNs. + + + + + + +Burger & Khartabil Standards Track [Page 32] + +RFC 5438 IMDN February 2009 + + +14.1. Forgery + + IMs can be forged. To protect against that, an IM can be signed. An + intermediary that receives a signed message and needs to modify any + part of it that is included in the signature (like adding an + Original-To header field to the CPIM header fields) MUST consume the + IM and create a new copy of it that the intermediary signs itself. + + IMDNs may be forged as easily as ordinary IMs. Endpoints and + intermediaries that wish to make automatic use of IMDNs should take + appropriate precautions to minimize the potential damage from denial- + of-service attacks. Security threats related to forged IMDNs include + the sending of a falsified IMDN when the indicated disposition of the + IM has not actually occurred. For example, display notification + could be forged to indicate that an IM has been displayed to the + Recipient. Unsolicited IMDNs is also another form of forgery. + +14.2. Confidentiality + + There may be cases where an IM Recipient does not wish to reveal that + she has received, or in fact read, the IM. In this situation, it is + acceptable for the IM Recipient to silently ignore requests for an + IMDN. It is strongly RECOMMENDED that the IM Recipient obtain the + user's consent before sending an IMDN. Circumstances where the IM + Recipient does not ask for the user's consent include IM systems + that, for regulatory reasons, are required to issue an IMDN, such as + in the health care field or financial community. + + An IM Recipient can obtain such consent by a prompt or dialog box on + a per-IM basis, globally through the user's setting of a preference, + or another, user-configurable mechanism. The user might also + indicate globally that IMDNs are never to be sent or that a + "forbidden" IMDN status is always sent in response to a request for + an IMDN. + + There are situations where a user sends an IM and requests IMDNs to a + list whose member information is not disclosed. In this situation, + the user will learn of the list members. Therefore, in this case, + the URI-List server MUST remove any information about list members. + If the number of members in the list is also not disclosed, the URI- + List server MUST only deliver one aggregated IMDN. Alternatively, + the URI-list server MAY reject the IM. + + It is possible for a list server to not understand IMDN. IM + Recipients may note the To header field is a list name and not the IM + Recipient's name. In this case, the IM Recipient can take the + appropriate action if it wishes to keep its identity private. + + + + +Burger & Khartabil Standards Track [Page 33] + +RFC 5438 IMDN February 2009 + + + An unencrypted IMDN could reveal confidential information about an + encrypted IM. The same level of security applied to an IM MUST be + applied to its IMDNs. For example, if an IM is signed and encrypted, + the IMDN must be signed and encrypted. + +14.3. IMDN as a Certified Delivery Service + + IMDNs cannot be relied on as a guarantee that an IM was or was not + seen by the user. Even if IMDNs are not actively forged, they may be + lost in transit. Moreover, the IM Recipient may bypass the IMDN + issuing mechanism through policy or manipulation of their user agent + Server. + +15. IANA Considerations + +15.1. message/imdn+xml MIME TYPE + + This document registers a new MIME type "message/imdn+xml", and + registers a new XML namespace. + + This specification follows the guidelines of RFC 3023 [RFC3023]. + + 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 + + + + +Burger & Khartabil Standards Track [Page 34] + +RFC 5438 IMDN February 2009 + + + 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 IETF + +15.2. XML Registration + + This section registers a new XML namespace and schema, as per + guidelines in the IETF XML Registry [IANA]. + + URI: urn:ietf:params:xml:ns:imdn + + XML: The schema for this namespace is in Section 11.1.9 above. + + Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil + (hisham.khartabil@gmail.com) + +15.3. URN Registration for IMDN Header Parameters + + Per [RFC3553], please establish the following registry. New entries + to the registry are Specification Required. + + Registry name: urn:ietf:params:imdn + + Specification: RFC 5438. Additional values may be defined by a + Standards Action [RFC5226] that updates or obsoletes RFC 5438. + + Repository: RFC 5438 + + Index value: Values subordinate to urn:ietf:params:imdn require RFC + publication. The index value is the IMDN header name. The index + value must follow the rules for a legal IMDN header name. In + particular, the IMDN header name, and thus the index value to + register, must be a string of octets taken from the restricted set of + US-ASCII characters per Section 3.1 of [RFC3553]. The index value is + case sensitive. + + URN Formation: The URI for a header is formed from its name by + + a) replacing any non-URN characters (as defined by RFC 2141 [URN]) + with the corresponding '%hh' escape sequence (per RFC 3986 + [RFC3986]) and + + + +Burger & Khartabil Standards Track [Page 35] + +RFC 5438 IMDN February 2009 + + + b) prepending the resulting string with 'urn:ietf:params:imdn:'. + + Thus, the URI corresponding to the CPIM message IMDN header + 'Disposition-Notification:' would be + 'urn:ietf:params:imdn:Disposition-Notification'. + + 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, which has been recorded in the + IANA registry for Mail Content Dispositions. + + Descriptions of this "disposition-types", including motivation and + examples, are given in Section 7.2.1.1 and Section 9. + + Short descriptions suitable for the IANA registry are: + + notification: 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 + + Special thanks to Jari Urpalainen for the thorough review and + suggestions for the RelaxNG schema. + + The authors would also like 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. In addition, we would like to thank the + Gen-Art reviewer extraordinaire, Spencer Dawkins. + + + + + + + + +Burger & Khartabil Standards Track [Page 36] + +RFC 5438 IMDN February 2009 + + +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. + + + +Burger & Khartabil Standards Track [Page 37] + +RFC 5438 IMDN February 2009 + + + [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 + + + + + + + + + + + + + + + + + + + + + +Burger & Khartabil Standards Track [Page 38] + -- cgit v1.2.3