idnits 2.17.1 draft-ietf-simple-imdn-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1742. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2008) is 5669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2141 (ref. 'URN') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3798 (Obsoleted by RFC 8098) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE E. Burger 3 Internet-Draft 4 Intended status: Standards Track H. Khartabil 5 Expires: April 20, 2009 Ericsson Australia 6 October 17, 2008 8 Instant Message Disposition Notification 9 draft-ietf-simple-imdn-09 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 20, 2009. 36 Abstract 38 Instant Messaging (IM) refers to the transfer of messages between 39 users in real-time. This document provides a mechanism whereby 40 endpoints can request Instant Message Disposition Notifications 41 (IMDN), including delivery, processing, and displayed notifications, 42 for page-mode instant messages. 44 The Common Profile for Instant Messaging (CPIM) data format specified 45 in RFC 3862 is extended with new header fields that enable endpoints 46 to request IMDNs. A new message format is also defined to convey 47 IMDNs. 49 This document also describes how SIP entities behave using this 50 extension. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.3. Display . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7 63 6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 7 64 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 65 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 9 68 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 72 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 11 73 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 74 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12 75 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 77 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15 78 8.1. Constructing Processing Notifications . . . . . . . . . . 16 79 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 17 80 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 20 81 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 20 82 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 21 84 11.1.1. The Element . . . . . . . . . . . . . . . 22 85 11.1.2. The Element . . . . . . . . . . . . . . . . 22 86 11.1.3. The Element . . . . . . . . . . . . . 22 87 11.1.4. The Element . . . . . . . . . 23 88 11.1.5. The Element . . . . . . . . . . . . . . . . 23 89 11.1.6. The , 90 and 91 Elements . . . . . . . . . . . 23 92 11.1.7. The Element . . . . . . . . . . . . . . . . . 23 93 11.1.8. MIME Type for IMDN Payload . . . . . . . . . . . . . . 23 94 11.1.9. The RelaxNG Schema . . . . . . . . . . . . . . . . . . 23 95 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 27 96 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 27 97 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 27 98 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 28 99 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 28 100 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 29 101 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 30 102 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33 105 14.3. IMDN as a Certified Delivery Service . . . . . . . . . . . 34 106 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 107 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 34 108 15.2. XML Registration . . . . . . . . . . . . . . . . . . . . . 35 109 15.3. Registration for urn:ietf:params:imdn . . . . . . . . . . 35 110 15.4. Content-Disposition: notification . . . . . . . . . . . . 36 111 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 112 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37 114 17.2. Informative References . . . . . . . . . . . . . . . . . . 37 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 116 Intellectual Property and Copyright Statements . . . . . . . . . . 39 118 1. Introduction 120 In many user-to-user message exchange systems, message senders often 121 wish to know if the human recipient actually received a message or 122 has the message displayed. 124 Electronic Mail [RFC2821] offers a solution to this need with Message 125 Delivery Notifications [RFC3798]. After the recipient views the 126 message, her mail user agent generates a Message Delivery 127 Notification, or MDN. The MDN is an e-mail that follows the format 128 prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an 129 automaton can process the message. 131 The common presence and instant messaging (CPIM) format, Message/CPIM 132 [RFC3862], is a message format used to generate instant messages. 133 The session initiation protocol, SIP [RFC3261], can carry instant 134 messages generated using message/CPIM in SIP MESSAGE requests 135 [RFC3428]. 137 This document extends the Message/CPIM message format in much the 138 same way Message Delivery Notifications extends Electronic Mail. 139 This extension enables Instant Message Senders to request, create, 140 and send Instant Message Disposition Notifications (IMDN). This 141 mechanism works for page-mode as well as session mode instant 142 messages. This document only discusses page-mode. Session mode is 143 left for future standardisation efforts. 145 This specification defines three categories of disposition types, 146 "delivery", "processing", and "displayed". Specific disposition 147 types provide more detailed information. For example, the "delivery" 148 category includes "delivered" to indicate successful delivery and 149 "failed" to indicate failure in delivery. 151 2. Conventions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 This document refers generically to the sender of a message in the 158 masculine (he/him/his) and the recipient of the message in the 159 feminine (she/her/hers). This convention is purely for convenience 160 and makes no assumption about the gender of a message sender or 161 recipient. 163 3. Terminology 165 o IM: An Instant Message generated using the Message/CPIM format. 166 o IMDN: An Instant Message Disposition Notification generated using 167 the Message/CPIM format that carries an IMDN XML document. 168 o Message: an IM or an IMDN generated using the Message/CPIM format. 169 o IM Sender: An endpoint (User Agent) generating and sending an IM. 170 Also, the endpoint request IMDNs for an IM. Quite often, the IM 171 Sender is the IMDN Recipient. However, that is not always the 172 case, since the IMDN uses the From header in the CPIM message. 173 That value is often the IM Sender's Address of Record (AOR). This 174 address may in fact resolve to different User Agents. 175 o IM Recipient: An endpoint (User Agent) that receives IMs. The IM 176 Recipient, as the node that presumably renders the IM to the user, 177 generates and sends delivery IMDNs to IMs, if requested by the IM 178 Sender and allowed by the IM Recipient. 179 o Endpoint: An IM Sender or an IM Recipient. 180 o Intermediary: An entity in the network, most often an application 181 server, including URI-List servers and Store-and-Forward servers, 182 that forwards an IM to its final destination. Intermediaries also 183 can generate and send processing IMDNs to IMs, if requested by the 184 IM Sender and allowed by policy. 185 o Gateway: An intermediary that translates between different IM 186 systems that use different protocols. 187 o IMDN Payload: An XML document carrying the disposition 188 notification information. In this specification, it is of MIME 189 type "message/imdn+xml". 190 o Disposition type: the type of IMDN that can be requested. This 191 specification defines three categories of disposition types, 192 "delivery", "processing", and "display". 193 o Transport Protocol Message: A SIP or other protocol message that 194 contains an IM or IMDN. 196 4. Overview 198 The diagram below shows the basic protocol flow. An IM Sender 199 creates an IM, adds IMDN request information the IM Sender is 200 interested in receiving and then sends the IM. At a certain point in 201 time, the IM Recipient or an intermediary determines that the user or 202 application has received, did not receive, displayed, or otherwise 203 disposed the IM. The mechanism by which an IM Recipient determines 204 its user has read an IM is beyond the scope of this document. At 205 that point, the IM Recipient or intermediary automatically generates 206 a notification message to the IM Sender. This notification message 207 is the Instant Message Disposition Notification (IMDN). 209 +--------------+ +--------------+ 210 | IM Sender | | IM Recipient | 211 |IMDN Recipient| | IMDN Sender | 212 +--------------+ +--------------+ 213 | | 214 | | 215 | 1. IM requesting IMDN | 216 |-------------------------------------->| 217 | | 218 | | 219 | 2. IMDN (disposition) | 220 |<--------------------------------------| 221 | | 222 | | 224 Basic IMDN Message Flow 226 Note the recipient of an IMDN, in some instances, may not be the IM 227 Sender. This is specifically true for page-mode IMs where the 228 Address of Record (AOR) of the IM Sender, that is present in the IM, 229 resolves to a different location or user agent than the IM 230 originated. This could happen, for example, if resolving the AOR 231 results in forking the request to multiple user agents. For 232 simplicity, the rest of this document assumes that the IM Sender and 233 the IMDN Recipient are the same and therefore will refer to both as 234 the IM Sender. 236 5. Disposition Types 238 There are three broad categories of disposition states. They are 239 delivery, processing, and display. 241 5.1. Delivery 243 The delivery notification type indicates whether the IM has been 244 delivered to the IM Recipient or not. The delivery notification type 245 can have the following states: 246 o "delivered" to indicate successful delivery. 247 o "failed" to indicate failure in delivery. 248 o "forbidden" indicate denial for the IM Sender to receive the 249 requested IMDN. The IM Recipient can send the "forbidden" state, 250 but usually it is an intermediary that sends the message if one 251 configures it to do so. For example, it is possible the 252 administrator has disallowed IMDNs. 254 o "error" to indicate an error in determining the fate of an IM. 256 5.2. Processing 258 The processing notification type indicates that an intermediary has 259 processed an IM. The processing notification type can have the 260 following states: 261 o "processed" is a general state of the IM indicating that the 262 intermediary has performed its task on the IM. 263 o "stored" state indicates that the intermediary stored the IM for 264 later delivery. 265 o "forbidden" indicate denial for the IM Sender to receive the 266 requested IMDN. The "forbidden" state is sent by an intermediary 267 that is configured to do so. For example, the administrator has 268 disallowed IMDNs. 269 o "error" to indicate an error in determining the fate of an IM. 271 5.3. Display 273 The display notification type indicates whether the IM Recipient 274 rendered the IM to the user or not. The display notification type 275 can have the following states: 276 o "displayed" is a state indicating that the IM has been rendered to 277 the user. 278 o "forbidden" indicate denial, by the IM Recipient, for the IM 279 Sender to receive the requested IMDN. 280 o "error" to indicate an error in determining the fate of an IM. 282 In addition to text, some IMs may contain audio, video, and still 283 images. Therefore, the state "displayed" includes the start of 284 rendering the audio or video file to the user. 286 Since there is no positive acknowledgement from the user, one cannot 287 determine the user actually read the IM. Thus, one cannot use the 288 protocol described here as a service to prove someone actually read 289 the IM. 291 6. New CPIM Header Fields 293 This specification extends the CPIM data format specified in RFC 3862 294 [RFC3862]. A new name space is created as well as a number of new 295 CPIM header fields. 297 6.1. CPIM Header Field Namespace 299 Per CPIM [RFC3862], this specification defines a new name space for 300 the CPIM extension header fields defined in the following sections. 302 The name space is: 304 urn:ietf:params:imdn 306 As per CPIM [RFC3862] requirements, the new header fields defined in 307 the following sections are prepended, in CPIM messages, by a prefix 308 assigned to the URN through the NS header field of the CPIM message. 309 The remaining of this specification always assumes an NS header field 310 like this one: 312 NS: imdn . 314 Of course, clients are free to use any prefix while servers and 315 intermediaries must accept any legal name space prefix specification. 317 6.2. Disposition-Notification 319 The IM Sender MUST include the Disposition-Notification header field 320 to indicate the desire to receive IMDNs from the IM Recipient, for 321 that specific IM. Section 10 defines the syntax. 323 6.3. Message-ID 325 The IM Sender MUST include the Message-ID header field in the IM that 326 he wishes to receive an IMDN on. The Message-ID contains a globally 327 unique message identifier the IM Sender can use to correlate received 328 IMDNs. Because the Message-ID is used by the sender to correlate 329 IMDNs with their respective IMs, the Message-ID MUST be selected so 330 that: 332 o There is a minimal chance of any two Message-IDs accidentally 333 colliding within the time period within which an IMDN might be 334 received. 335 o It is prohibitive for an attacker who has seen one or more valid 336 Message-IDs to generate additional valid Message-IDs. 338 The first requirement is a correctness requirement to ensure correct 339 matching by the sender. The second requirement prevents off-path 340 attackers from forging IMDNs. In order to meet both of these 341 requirements, it is RECOMMENDED that Message-IDs be generated using a 342 cryptographically secure pseudorandom number generator and contain at 343 least 64 bits of randomness, thus reducing the chance of a successful 344 guessing attack to n/2^64, where n is the number of outstanding valid 345 messages. 347 When the IM Sender receives an IMDN, it can compare its value with 348 the value of the element present in the IMDN payload. 349 IMDNs also carry this header field. Note that since the IMDN is 350 itself an IM, the Message-ID of the IMDN will be different than the 351 Message-ID of the original IM. Section 10 defines the syntax. 353 6.4. Original-To 355 An intermediary MAY insert an Original-To header field to the IM. 356 The value of the Original-To field MUST be the address of the IM 357 Receiver. The IM Recipient uses this header to indicate the original 358 IM address in the IMDNs. The IM Recipient does this by populating 359 the element in the IMDN. The intermediary 360 MUST insert this header if the intermediary changes the CPIM To 361 header field value. The header field MUST NOT appear more than once 362 in an IM. The intermediary MUST NOT change this header field value 363 if it is already present. Section 10 defines the syntax. 365 6.5. IMDN-Record-Route 367 An intermediary MAY insert an IMDN-Record-Route header field to the 368 IM. This enables the intermediary to receive and process the IMDN on 369 its way back to the IM Sender. The value of the IMDN-Record-Route 370 header field MUST be the address of the intermediary. Multiple IMDN- 371 Record-Route header fields can appear in an IM. Section 10 defines 372 the syntax. 374 6.6. IMDN-Route 376 The IMDN-Route header field provides routing information by including 377 one or more addresses where to route the IMDN. An intermediary that 378 needs the IMDN to flow back through the same intermediary MUST add 379 the IMDN-Record-Route header. When the IM Recipient creates the 380 corresponding IMDN, the IM Recipient copies the IMDN-Record-Route 381 headers into corresponding IMDN-Route header fields. Section 10 382 defines the syntax. 384 7. Endpoint Behaviour 386 7.1. IM Sender 388 7.1.1. Constructing Instant Messages 390 An IM is constructed using CPIM Message Format defined in RFC 3862 391 [RFC3862]. 393 7.1.1.1. Adding a Message-ID Header Field 395 If the IM sender requests the reception of IMDNs, the IM sender MUST 396 include a Message-ID header field. This header field enables the IM 397 Sender to match any IMDNs with their corresponding IMs. See 398 Section 6.3 for Message-ID uniqueness requirements. 400 7.1.1.2. Adding a DateTime Header Field 402 Some devices are not able to retain state over long periods. For 403 example, mobile devices may have memory limits or battery limits. 404 These limits may mean these devices may not be able to, or may chose 405 not to, keep sent messages for the purposes of correlating IMDNs with 406 sent IMs. To make some use of IMDN in this case, we add a time stamp 407 to the IM to indicate when the user sent the message. The IMDN 408 returns this time stamp to enable the user to correlate the IM with 409 the IMDN at the human level. We use the DateTime CPIM header field 410 for this purpose. Thus, if the IM Sender would like an IMDN, the IM 411 Sender MUST include the DateTime CPIM header field. 413 7.1.1.3. Adding a Disposition-Notification Header Field 415 The Disposition-Notification conveys the type of disposition 416 notification requested by the IM sender. There are three types of 417 disposition notification: delivery, processing, and display. The 418 delivery notification is further subdivided into failure and success 419 delivery notifications. An IM Sender requests failure delivery 420 notification by including a Disposition-Notification header field 421 with value "negative-delivery". Similarly, a success notification is 422 requested by including a Disposition-Notification header field with 423 value "positive-delivery". The IM Send can request both types of 424 delivery notifications for the same IM. 426 The IM Sender can request a processing notification by including a 427 Disposition-Notification header field with value "processing". 429 The IM Sender can also request a display notification. The IM Sender 430 MUST include a Disposition-Notification header field with the value 431 "display" to request a display IMDN. 433 The absence of this header field or the presence of the header field 434 with an empty value indicates that the IM Sender is not requesting 435 any IMDNs. Disposition-Notification header field values are comma 436 separated. The IM Sender MAY request more than one type of IMDN for 437 a single IM. 439 Future extensions may define other disposition notifications not 440 defined in this document. 442 Section 10 describes the formal syntax for the Disposition- 443 Notification header field. The following is an example CPIM body of 444 an IM where the IM Sender requests positive and negative delivery 445 notifications, but neither display notification nor processing 446 notifications: 448 From: Alice 449 To: Bob 450 NS: imdn 451 imdn.Message-ID: 34jk324j 452 DateTime: 2006-04-04T12:16:49-05:00 453 imdn.Disposition-Notification: positive-delivery, negative-delivery 454 Content-type: text/plain 455 Content-length: 12 457 Hello World 459 7.1.2. Matching IMs with IMDNs 461 An IM Sender matches an IMDN to an IM by matching the Message-ID 462 header field value in the IM with the element value in 463 the body of the IMDN. If the IM was delivered to multiple 464 recipients, the IM Sender uses the element and the 465 element in the XML body of the IMDN it 466 received to determine if the IM was sent to multiple recipients and 467 to identify the IM Recipient that sent the IMDN. 469 An IM Sender can determine an IMDN is a disposition notification by 470 noting the Content-Disposition in the IMDN is "notification". This 471 does mean the IM Sender MUST understand the Content-Disposition MIME 472 header in CPIM messages. 474 7.1.3. Keeping State 476 This specification does not mandate the IM Sender to keep state for a 477 sent IM. 479 Once an IM Sender sends an IM containing an IMDN request, it MAY 480 preserve the IM context, principally the Message-ID, and other user- 481 identifiable information such as the IM subject or content, and date 482 and time it was sent. Without preservation of the IM context, the IM 483 Sender will not be able to correlate the IMDN with the IM it sent. 484 The IM Sender may find it impossible to preserve IM state if it has 485 limited resources or does not have non-volatile memory and then loses 486 power. 488 There is, however, the concept of "Sent Items" box in an application 489 that stores sent IMs. This "Sent Items" box has the necessary 490 information and may have a fancy user interface indicating the state 491 of a sent IM. A unique Message-ID for this purpose proves to be 492 useful. The length of time for items to remain in the "Sent Items" 493 box is a user choice. The user is usually free to keep or delete 494 items from the "Sent Items" box as she pleases or as the memory on 495 the device reaches capacity. 497 Clearly, if an IM Sender loses its sent items state, for example, the 498 user deletes items from the "Send Items" box, the client may use a 499 different display strategy in response to apparently unsolicited 500 IMDNs. 502 This specification also does not mandate an IM Sender to run any 503 timers waiting for an IMDN. There are no time limits associated with 504 when IMDNs may be received. 506 IMDNs may legitimately never be received, so the time between the 507 sending of an IM and the generation and ultimate receipt of the IMDN 508 may simply take a very long time. Some clients may choose to purge 509 the state associated with the sent IM. This is the reason for adding 510 the time stamp in the IM and having it returned in the IMDN. This 511 gives the user some opportunity of remembering what IM was sent. For 512 example if the IMDN indicates that the IM the user sent at 2 p.m. 513 last Thursday was delivered, the user has a chance of remembering 514 that they sent an IM at 2 p.m. last Thursday. 516 7.1.4. Aggregation of IMDNs 518 An IM Sender may send an IM to multiple recipients in one Transport 519 Protocol Message (typically using a URI-List server 520 [I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender 521 that requested IMDNs MUST be prepared to receive multiple aggregated 522 or non-aggregated IMDNs. See Section 8.2 for details. 524 7.2. IM Recipient 526 7.2.1. Constructing IMDNs 528 IM recipients examine the contents of the Disposition-Notification 529 header field of the CPIM message to determine if the recipient needs 530 to generate an IMDN for that IM. Disposition-Notification header 531 fields of CPIM messages can include one or more values. IM 532 recipients may need to generate zero, one, or more IMDNs for that IM, 533 for example a delivery notification as well as a display 534 notification. In this case, the IM Recipient MUST be able to 535 construct multiple IMDNs per IM. An IM Recipient MUST NOT construct 536 more than one IMDN per disposition type. That is, it must not 537 generate a delivery notification indicating "delivered" then followed 538 by a delivery notification indicating "failed" for the same IM. If 539 the IM Sender requested only failure notifications and the IM was 540 successfully delivered, then no IMDNs will be generated. If the IM 541 recipient does not understand a value of the Disposition-Notification 542 header field, the IM recipient ignores that value. 544 The IM Recipient MUST NOT generate "processing" notifications. 546 A Disposition-Notification header field MUST NOT appear in an IMDN 547 since it is forbidden to request an IMDN for an IMDN. An IM Sender 548 MUST ignore a delivery notification request in an IMDN if present. 549 The IM Sender MUST NOT send an IMDN for an IMDN. 551 An IMDN MUST contain a Message-ID header field. The same rules of 552 uniqueness for the Message-ID header field that appears in an IM 553 apply to an IMDN. The Message-ID header field in the IMDN is 554 different and unrelated to the one in the IM. 556 An IM may contain an IMDN-Record-Route header field (see Section 8 557 for details). If IMDN-Record-Route header fields appear in the IM, 558 the IM Recipient constructing the IMDN MUST copy the contents of the 559 IMDN-Record-Route header fields into IMDN-Route header fields in the 560 IMDN and maintain the order. The IMDN is then sent to the URI in the 561 top IMDN-Route header field. IMDN-Record-Route header fields do not 562 make sense in an IMDN and therefore MUST NOT be placed in an IMDN. 563 IMDN Recipients MUST ignore it if present. 565 If there is no IMDN-Record-Route header field, the IM Recipient MUST 566 send the IMDN to the URI in the From header field. 568 As stated in CPIM [RFC3862], CPIM messages may need to support MIME 569 headers other than Content-type. IM Recipients MUST insert a 570 Content-Disposition header field, set to the value "notification". 571 This indicates to the IM Sender that the message is an IMDN to an IM 572 it has earlier sent. 574 7.2.1.1. Constructing Delivery Notifications 576 The IM Recipient constructs a delivery notification in a similar 577 fashion as an IM, using a CPIM body [RFC3862] that carries a 578 Disposition Notification XML document formatted according to the 579 rules specified in Section 11. The MIME type of the Disposition 580 Notification XML document is "message/imdn+xml". 582 Section 10 defines the schema for an IMDN. 584 An example CPIM body of IMDN looks like the following: 586 From: Bob 587 To: Alice 588 NS: imdn 589 imdn.Message-ID: d834jied93rf 590 Content-type: message/imdn+xml 591 Content-Disposition: notification 592 Content-length: ... 594 595 596 34jk324j 597 2008-04-04T12:16:49-05:00 598 im:bob@example.com 599 im:bob@example.com 601 602 603 604 605 606 608 7.2.1.2. Constructing Display Notifications 610 The IM Recipient constructs a display notification in a similar 611 fashion as the delivery notification. See Section 7.2.1.1 for 612 details. 614 Section 10 defines the schema for an IMDN. 616 An example looks like the following: 618 From: Bob 619 To: Alice 620 NS: imdn 621 imdn.Message-ID: dfjkleriou432333 622 Content-type: message/imdn+xml 623 Content-Disposition: notification 624 Content-length: ... 626 627 628 34jk324j 629 2008-04-04T12:16:49-05:00 630 im:bob@example.com 631 im:bob@example.com 633 634 635 636 637 638 640 There are situations where the IM Recipient cannot determine if or 641 when the IM has been displayed. The IM Recipient in this case 642 generates a display notification with a value of "error" to 643 indicate an internal error by the server. Note that the IM Recipient 644 may choose to ignore any IMDN requests and not to send any IMDNs. An 645 IM recipient may not wish to let a sender know if a particular 646 message has been displayed to her or not. This could be on a per- 647 message, per-sender, or programmed policy choice. 649 8. Intermediary Behaviour 651 In this context, intermediaries are application servers (including 652 URI-List servers and Store-and-Forward server) and gateways. A 653 gateway is a server that translates between different IM systems that 654 use different protocols. 656 A URI-List server may change the IM Recipient address from its own to 657 the address of the final recipient of that IM for every copy it makes 658 that it sends to the list members (see 659 [I-D.ietf-sip-uri-list-message] for details). In this case, if the 660 IM Sender is requesting an IMDN, the intermediary SHOULD add an 661 Original-To header field to the IM populating it with the address 662 that was in the CPIM To header field before it was changed. That is, 663 the intermediary populates the Original-To header field with the 664 intermediary address. Of course, one may configure an intermediary 665 to restrict it from rewriting or populating the Original-To field. 666 An intermediary MUST NOT add an Original-To header field if one 667 already exists. An intermediary MAY have an administrative 668 configuration to not reveal the original Request-URI, and as such, 669 MUST NOT add an Original-To header. 671 An intermediary MAY choose to remain on the path of IMDNs for a 672 specific IM. It can do so by adding a CPIM IMDN-Record-Route header 673 field as the top IMDN-Record-Route header field. The value of this 674 field MUST be the intermediary's own address. An intermediary that 675 does not support this extension will obviously not add the IMDN- 676 Record-Route header field. This allows IMDNs to traverse directly 677 from the IM Recipient to the IM Sender even if the IM traversed an 678 intermediary not supporting this extension. 680 An intermediary receiving an IMDN checks the top IMDN-Route header 681 field. If that header field carries the intermediary address, the 682 intermediary removes that value and forwards the IMDN to the address 683 indicated in the now top IMDN-Route header field. If no additional 684 IMDN-Route header fields are present, the IMDN is forwarded to the 685 address in the CPIM To header field. 687 An intermediary MUST remove any information about the final 688 recipients of a list if the list membership is not disclosed. The 689 intermediary does that by removing the element and/or 690 element from the body of the IMDN before 691 forwarding it to the IM Sender. 693 8.1. Constructing Processing Notifications 695 Intermediaries are the only entities that construct processing 696 notifications. They do so only if the IM Sender has requested a 697 "processing" notification by including a Disposition-Notification 698 header field with value "processing". 700 The intermediary can create and send "processing" notifications 701 indicating that an IM has been processed or stored. The intermediary 702 MUST NOT send more than one IMDN for the same disposition type. 703 I.e., it must not send a "processing" notification indicating that an 704 IM is being "processed" followed by another IMDN indicating that the 705 same IM is "stored". 707 An intermediary constructs a "processing" notification in a similar 708 fashion as the delivery notification. See Section 7.2.1.1 for 709 details. 711 An example looks like the following: 713 Content-type: Message/CPIM 715 From: Bob 716 To: Alice 717 Content-type: message/imdn+xml 718 Content-Disposition: notification 719 Content-length: ... 721 722 723 34jk324j 724 2008-04-04T12:16:49-05:00 725 im:bob@example.com 726 im:bob@example.com 728 729 730 731 732 733 735 There are situations where the intermediary cannot know the fate of 736 an IM. The intermediary in this case generates a processing 737 notification with a value of "error" to indicate so. 739 8.2. Aggregation of IMDNs 741 As previously described, URI-List servers are intermediaries. 743 A URI-List server may choose to aggregate IMDNs using local policy 744 for making such a decision or it may send individual IMDNs instead. 745 When a URI-List server receives an IM and decides to aggregate IMDNs, 746 it can wait for a configurable period of time or until all recipients 747 have sent the IMDN, whichever comes first, before the URI-List server 748 sends an aggregated IMDN. Note that some IMDNs, for example 749 "displayed" notifications, may never come due to user settings. It 750 is an administrator configuration and an implementation issue how 751 long to wait before sending an aggregated IMDN and before a URI-List 752 server removes state for that IM. 754 A URI-List server MAY choose to send multiple aggregated IMDNs. A 755 timer can be started and when it fires, the URI-List server can 756 aggregate whatever IMDNs it has so far for that IM, send the 757 aggregated IMDN and restart the timer for the next batch. This is 758 needed for scenarios where the IM Sender has requested more than one 759 IMDN for a specific IM, for example, delivery notifications as well 760 as display notifications, or when the URI-List server is short on 761 resources and chooses to prioritise forwarding IMs over IMDNs. 763 A second timer can be running and when it fires, the state of the IM 764 is deleted. In this case, the URI-List server consumes any IMDNs 765 that might arrive after that time. 767 Please note the references to timers in the above paragraphs are not 768 normative and are only present to help describe one way one might 769 implement aggregation. 771 A URI-List server MAY aggregate IMDNs for the case where the list 772 membership information is not disclosed. There may be scenarios 773 where the URI-List server starts sending aggregated IMDNs and switch 774 to individual ones or visa versa. A timer firing so often may in 775 fact have that effect. 777 The aggregated IMDN is constructed using the multipart/mixed MIME 778 type and including all the received IMDNs as message/imdn+xml as 779 individual payloads. 781 Below is an example of aggregated IMDNs. 783 From: Bob 784 To: Alice 785 NS: imdn 786 imdn.Message-ID: d834jied93rf 787 Content-type: multipart/mixed; 788 boundary="imdn-boundary" 789 Content-Disposition: notification 790 Content-length: ... 792 --imdn-boundary 793 Content-type: message/imdn+xml 795 796 797 34jk324j 798 2008-04-04T12:16:49-05:00 799 im:bob@example.com 800 im:bob@example.com 802 803 804 805 806 807 809 --imdn-boundary 810 Content-type: message/imdn+xml 812 813 814 34jk324j 815 2008-04-04T12:16:49-05:00 816 im:bob@example.com 817 im:bob@example.com 819 820 821 822 823 824 826 --imdn-boundary 828 9. Identifying Messages 830 Messages are typically carried in a transport protocol like SIP 831 [RFC3261]. If the payload carried by the transport protocol does not 832 contain any parts of type Message/CPIM then the message is an IM. If 833 the payload contains any parts of type Message/CPIM, and none of 834 those parts contains a payload that is of type "message/imdn+xml", 835 the message is an IM. It is not valid to attempt to carry both an IM 836 and an IMDN in a multipart payload in a single transport protocol 837 message. 839 A message is identified as a delivery notification by examining its 840 contents. The message is a delivery notification if the Content-type 841 header field present has a value of "message/imdn+xml", the Content- 842 Disposition header field has a value of "notification", and the 843 element appears in that xml body. 845 A message is identified as a processing notification or display 846 notification in a similar fashion as a delivery notification. The 847 difference is that for a processing notification, the element appears in the xml body. For a display 849 notification, the element appears in the xml 850 body. 852 10. Header Fields Formal Syntax 854 The following syntax specification uses the message header field 855 syntax as described in Section 3 of RFC 3862 [RFC3862]. 857 Header field syntax is described without a name space qualification. 858 Following the rules in RFC 3862 [RFC3862], header field names and 859 other text are case sensitive and MUST be used as given, using 860 exactly the indicated upper case and lower case letters. 862 Disposition-Notification = 863 "Disposition-Notification" ": " 864 [(notify-req *(COMMA notify-req))] 866 notify-req = 867 ("negative-delivery" / "positive-delivery" / 868 "processing" / "display" / Token) *(SEMI disp-notify-params) 870 disp-notify-params = Ext-param 872 Message-ID = "Message-ID" ": " Token 874 Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" 876 IMDN-Record-Route = 877 "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" 879 IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 881 SEMI = SP ";" SP ; semicolon 883 COMMA = SP "," SP ; comma 885 11. IMDN Format 887 11.1. Structure of XML-Encoded IMDN Payload 889 An IMDN Payload is an XML document [XML] that MUST be well formed and 890 MUST be valid according to schemas, including extension schemas, 891 available to the validater and applicable to the XML document. The 892 IMDN Payload MUST be based on XML 1.0 and MUST be encoded using 893 UTF-8. 895 The schema allows qualified extension elements in several positions 896 other than the "urn:ietf:params:xml:ns:imdn" namespace. To maintain 897 forwards compatibility (newer instance documents can be used by 898 existing consumers) the new specifications MUST NOT extend the 899 allowable content of this specification. The backwards compatibility 900 (existing instance documents can also be used by updated new 901 consumers) MAY break if there are conflicts with the existing 902 qualified names of extension elements and possible new 903 specifications. The IETF MAY specify new extension elements within 904 the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/ 905 imdn+xml MIME type. 907 Possible future specifications can add new element definitions with 908 the combine="interleave" pattern. When multiple elements of this new 909 type are then allowed, the new definition MUST contain the 910 cardinality rule. If the new specification does allow 911 only a single new element, the cardinality rule MUST be 912 used. These cardinality requirements maintain the backwards 913 compatibility of existing instance documents with newer consumers. 914 Also the new specification MUST then re-define either the "anyIMDN" 915 extension, or the individual extension points which reference it, so 916 that new element definitions do not match with this redefined, and 917 more limited wildcard pattern. 919 The name space identifier for elements defined by this specification 920 is a URN [URN], using the name space identifier 'ietf' defined by 921 [URN_NS] and extended by [IANA]. This urn is: 922 urn:ietf:params:xml:ns:imdn. 924 This name space declaration indicates the name space on which the 925 IMDN is based. 927 The root element is . The element has sub-elements, 928 namely , , , , , and one of , 930 or . A also 931 appears as a sub-element of , and . The elements are described 933 in details in the following sections. 935 , can be extended in the future to include new disposition 936 notification types or other elements, as described in Section 11.1.9. 938 11.1.1. The Element 940 The element is mandatory according to the XML schema and 941 carries the message id that appeared in the Message-ID header field 942 of the IM. 944 11.1.2. The Element 946 The element is mandatory and carries the date and time the 947 IM was sent (not the IMDN). This information is obtained from the 948 DateTime header field of the IM. 950 11.1.3. The Element 952 The element is optional and carries the URI of the 953 final recipient. This information is obtained from the CPIM To 954 header field of the IM. 956 11.1.4. The Element 958 The element is optional and carries the URI 959 of the original recipient. It MUST be present if the IM carried the 960 Original-To header field. This information is obtained from the 961 Original-To header field of the IM. 963 11.1.5. The Element 965 The element is optional. If present it MUST cary the text 966 and, if present, language attribute, that was in the Subject header 967 field, if any. This allows for a human level correlation between an 968 IM and an IMDN. If there are more than one Subject header fields in 969 an IM, selecting any one of them to place in the IMDN payload 970 element will suffice. The sender then needs to compare 971 Subject header fields until a match or not match is determined. 973 11.1.6. The , and 974 Elements 976 The appearance of one of the , and elements is mandatory and 978 carries the disposition type that the IM Sender requested and is 979 being reported. It carries the sub-element . 981 11.1.7. The Element 983 The element is mandatory and carries the result of the 984 disposition request. For notification type , 985 it can carry one of the sub-elements , , 986 or . For notification type , it can carry one of the sub-elements , 988 or . For notification type , it can carry one of the sub-elements , 990 , or . means the disposition 991 was denied. means internal server error. It can also be 992 extended to carry any other status extension. 994 11.1.8. MIME Type for IMDN Payload 996 The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN 997 MUST identify the payload as MIME type "message/imdn+xml" in the 998 Content-type header field. 1000 11.1.9. The RelaxNG Schema 1002 1003 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1099 1105 1106 1107 1108 1109 1111 1112 1113 1114 1115 1116 1118 1119 1120 1121 1122 1123 1125 1126 1127 1128 1129 1130 1132 1139 1140 1141 1142 1143 1144 1145 1146 1147 1149 1150 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1164 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1181 1183 12. Transporting Messages using SIP 1185 12.1. Endpoint Behaviour 1187 12.1.1. Sending Requests 1189 The IM Sender constructs a SIP MESSAGE request using RFC 3428 1190 [RFC3428]. The Content-type header field indicates the MIME type of 1191 the request payload. When using this extension, the Content-type 1192 header field MUST be of MIME type "message/cpim" [RFC3862] for both 1193 IMs and IMDNs. The IM Sender constructs the payload according to 1194 Section 7. 1196 The IM Sender constructs a SIP MESSAGE request to multiple recipients 1197 in a similar manner as a SIP MESSAGE request to a single recipient. 1198 Multiple-Recipient MESSAGE Requests in SIP 1199 [I-D.ietf-sip-uri-list-message] describes the differences. 1201 IM senders can remain anonymous. For example, the sender can set the 1202 SIP From header field of the SIP message to an anonymous URI. As 1203 there is no return address, anonymous IM senders SHOULD NOT request 1204 disposition notifications. An IM Recipient MAY ignore such request 1205 if the IM Sender is anonymous. 1207 12.1.2. Sending Responses 1209 An endpoint receiving a SIP MESSAGE request constructs a SIP response 1210 according to RFC 3428 [RFC3428]. Of course, an endpoint will send a 1211 SIP response to the MESSAGE request regardless of the type of message 1212 (IM or IMDN) is has received, or the disposition type it has been 1213 asked for. 1215 12.1.3. Receiving Requests 1217 12.1.3.1. Instant Message 1219 A SIP MESSAGE request is identified as an IM by examining its 1220 contents according to Section 9. 1222 If an IM Recipient received a SIP MESSAGE request that is an IM that 1223 requested a positive-delivery notification, and that IM Recipient has 1224 constructed and sent a SIP 2xx class response, it MAY generate a 1225 positive-delivery notification after making sure that the IM has been 1226 delivered to the user or application. A gateway, for example, can 1227 generate a 2xx response before the final recipient received the IM. 1228 The IM Recipient constructs a positive-delivery notification 1229 according to Section 7.2.1.1. The IM Recipient places the message as 1230 the payload in a SIP MESSAGE request. 1232 If an IM Recipient received a SIP MESSAGE request that is an IM that 1233 requested a negative-delivery, and that IM Recipient has constructed 1234 and sent a 2xx class response, it SHOULD generate a negative-delivery 1235 notification if it learnt that the final recipient or application did 1236 not receive the IM (a gateway, for example, can generate a 2xx 1237 response before it has an error response from downstream or before 1238 any internal timers fire waiting for a response). The negative- 1239 delivery notification is constructed according to Section 7.2.1.1. 1240 The message is then placed as the payload in a SIP MESSAGE request. 1242 If an IM Recipient received a SIP MESSAGE request that is an IM that 1243 requested a negative-delivery notification, and the IM Recipient has 1244 constructed and sent an non-2xx final response, it MUST NOT generate 1245 a negative-delivery notification. 1247 If an IM Recipient received a SIP MESSAGE request that is an IM that 1248 requested a display notification, and that IM Recipient has 1249 constructed and sent a SIP 2xx class response, it MAY generate a 1250 display notification after making sure that the IM has been presented 1251 to the user or application. It is outside the scope of this document 1252 how a determination can be made whether the IM has been read. Note 1253 that the option to send a display notification or not can be left to 1254 the user. An application may allow a user to configure such choice. 1255 The IM Recipient constructs the display notification according to 1256 Section 7.2.1.2. The IM Recipient places the message as the payload 1257 in a SIP MESSAGE request. 1259 For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP 1260 To header field using the address that appeared in the SIP From 1261 header field in the IM. 1263 12.1.3.2. Delivery Notification 1265 A SIP MESSAGE request is identified as delivery notification by 1266 examining its contents according to Section 9. 1268 12.1.3.3. Display Notification 1270 A SIP MESSAGE request is identified as display notification by 1271 examining its contents according to Section 9. 1273 12.2. Intermediary Behaviour 1275 In this context, intermediaries include application servers, 1276 including URI-List servers, Store-and-Forward servers, and gateways. 1277 SIP Proxies MUST NOT generate IMDNs but MUST forward them like any 1278 other SIP request. 1280 Intermediaries forward a SIP MESSAGE request to multiple recipients 1281 according to [I-D.ietf-sip-uri-list-message]. 1283 If an intermediary receives an IM, the intermediary examines the 1284 body. If the body is of type "message/cpim" the intermediary then 1285 looks for a Disposition-Notification CPIM header field in the 1286 message. If the Disposition-Notification CPIM header field has 1287 either the value "positive-delivery" or "negative-delivery", and, in 1288 processing the IM, the intermediary generates a SIP 2xx class 1289 response to the MESSAGE request, then the intermediary performs the 1290 following actions. 1292 If the Disposition-Notification header field contains a value of 1293 "positive-delivery", the intermediary MUST NOT generate a delivery 1294 notification if it receives a SIP 2xx class response for the sent IM. 1295 Just because a downstream entity received a MESSAGE request does not 1296 mean the message was relayed to its ultimate destination or was 1297 delivered. Thus, the intermediary cannot say delivery occurred just 1298 because it received a 2xx response. 1300 If the Disposition-Notification header field contains a value of 1301 "negative-delivery", the intermediary SHOULD generate a delivery 1302 notification if it receives a SIP 4xx, 5xx or 6xx class final 1303 response for the sent IM. If it has received a SIP 2xx class 1304 response followed by a negative-delivery notification, the 1305 intermediary forwards that negative-delivery notification or 1306 aggregates it. 1308 If the Disposition-Notification header field contains a value of 1309 "processing", the intermediary MAY generate a processing notification 1310 after it has forwarded or stored the IM. The rest of the procedures 1311 in Section 8.1 apply. 1313 The procedure for generating such IMDN is the same as that of an IM 1314 Recipient (Section 7.2.1.1). 1316 The element of the XML body is populated with the URI 1317 of the IM Recipient. 1319 If an intermediary receives a SIP MESSAGE request carrying a positive 1320 delivery notification or a display notification, it forwards it using 1321 the rules in Section 8. 1323 13. Transporting Messages using MSRP 1325 MSRP [RFC4975] already provides a built-in mechanism to supply 1326 positive and negative delivery reports. These reports do not provide 1327 built-in Display or Processing notifications. However, these 1328 notifications in session mode are not as useful as they are for page- 1329 mode. This is because the base use case for MSRP is that the 1330 recipient user agent immediately renders SEND requests sequentially, 1331 providing the session experience. This is unlike page-mode requests 1332 where a user has to actively initiate the display of the message. 1333 That is, they need to click on a button, open a message, and so on to 1334 read the message. 1336 If new requirements arise in the future determining the need for IMDN 1337 in MSRP, new specifications can be drafted. 1339 14. Security Considerations 1341 IMDNs provide a fine-grained view of the activity of the IM Recipient 1342 and thus deserves particularly careful confidentiality protection so 1343 that only the intended recipient of the IMDN will receive the IMDN. 1344 In most cases, the intended recipient of the IMDN is the IM Sender. 1346 Since the IM transport protocol carries the IMDN, all security 1347 considerations of the underlying IM protocol also apply to the IMDNs. 1349 The threats in the IMDN system, over and beyond the threats inherent 1350 to IM include the following: 1351 o A malicious endpoint attempts to send messages to a user that 1352 would normally not wish to receive messages from that endpoint by 1353 convincing the IMDN system to "bounce" an IMDN from an 1354 unsuspecting endpoint to the user. 1355 o A malicious endpoint attempts to flood an IM Sender with IMDNs by 1356 convincing a URI-List server to send IMDNs to an unsuspecting IM 1357 Sender. 1358 o A malicious intermediary or node attempts to flood a target node 1359 with IMDNs by inserting the target's address in the From field or 1360 IMDN-Record-Route field 1361 o A malicious node in the network that attempts to modify an IMDN 1362 from an IM Recipient. 1363 o A malicious intermediary attempts to forward an IMDN from an IM 1364 Recipient to the IM Sender, where the IM Recipient would not 1365 normally forward the IMDN to that IM Sender if the IM Recipient 1366 knew the identity of the IM Sender. 1367 o A malicious endpoint that attempts to discover for a Request-URI 1368 of an endpoint beyond an intermediary, where the endpoint would 1369 normally wish to keep its identity private from the malicious 1370 endpoint. 1371 o A malicious node in the network that attempts to eavesdrop on IMDN 1372 traffic to, for example, learn Request-URI or traffic pattern 1373 information. 1374 o A malicious node in the network attempts to stage a denial of 1375 service attack on an intermediary by requesting a large list 1376 expansion. 1378 The protocol cannot protect against attacks that include the 1379 following: 1380 o A malicious intermediary directly revealing the identity of a 1381 downstream endpoint that would not normally wish its identity 1382 revealed. Keeping such information private is an intermediary 1383 implementation issue. 1384 o A malicious IM Recipient that alters the time of the IMDN. There 1385 is no protocol mechanism for ensuring that the IM Recipient does 1386 not lie about the time or purposely holds an IMDN for transmission 1387 to make it appear that the IM was displayed to the user read later 1388 than it actually did. 1389 o A deletion attack on an IMDN. This is a trade-off between privacy 1390 and security. The privacy considerations allow the IM Recipient 1391 to silently ignore an IMDN request. Any mechanism that would 1392 reliably indicate that a malicious node deleted an IM Recipient's 1393 IMDN would also serve the purpose of detecting an IM Recipient 1394 that chose not to issue an IMDN. 1396 To combat eavesdropping, modification, and man-in-the-middle attacks, 1397 we require some level of authentication and integrity protections. 1398 That said, there are circumstances where strong integrity would be 1399 overkill. The presumption is the IM Sender has and sets the 1400 expectation for the level of protection. The procedures for 1401 integrity protection are as follows. 1402 o If the IM Recipient has a certificate, it MUST sign the IMDN. 1403 Signing the IMDN provides integrity protection. While an 1404 intermediary can replace the IMDN body, the IM Sender (the 1405 recipient of the IMDN) can validate the signature and note the 1406 IMDN does not come directly from the IM Receiver. This is not a 1407 problem if the IM Sender trusts the intermediary. Likewise, an 1408 IMDN in response to a signed IM without a signature indicates 1409 something bad might have happened. 1410 o If the IM is encrypted, the IM Recipient or intermediary MUST 1411 encrypt the IMDN body, as an attacker may attempt to discern the 1412 user's activity profile and identity from sniffing IMDNs on the 1413 network. 1414 o The two above rules are cumulative. 1415 The IM Recipient or intermediary MUST be capable of accessing the IM 1416 Sender's public certificate in order to verify the signature in the 1417 IM. 1419 CPIM security considerations [RFC3862] apply here, as this is an 1420 extension of CPIM. In order to make the IMDN mechanism independent 1421 of the transport protocol, the Work Group made the design choice of 1422 putting routing information into the IMDN application layer payload. 1423 One consequence of this choice is it eliminates the possibility of 1424 having end-to-end encryption. 1426 An attacker can mount a distributed denial of service attack on a 1427 node by sending lots of IMs to the node with IMDN requests. Note 1428 that this is the same problem as there is without IMDN; IMDN simply 1429 linearly increases the load on the node under attack. One can 1430 mitigate, but not eliminate this threat by the endpoint immediately 1431 ignoring requests that are not authenticated. 1433 One way to address the potential for a malicious node to use the IMDN 1434 system to anonomize attacks is to log all IMDN requests on the IM 1435 Recipient User Agent. This allows for tracking of attacks, if only 1436 after they occur. Note this also puts a burden on the IM Recipient 1437 User Agent host. Limited User Agents may not be able to preserve 1438 much of a log. 1440 Likewise, an attacker can mount a denial of service attack on an 1441 intermediary by asking the intermediary to explode a large list. 1443 The following security considerations apply when using IMDNs: 1445 14.1. Forgery 1447 IMs can be forged. To protect against that, an IM can be signed. An 1448 intermediary that receives a signed message and needs to modify any 1449 part of it that is included in the signature (like adding an 1450 Original-To header field to the CPIM header fields), MUST consume the 1451 IM and create a new copy of it that the intermediary signs itself. 1453 IMDNs may be forged as easily as ordinary IMs. Endpoints and 1454 intermediaries that wish to make automatic use of IMDNs should take 1455 appropriate precautions to minimize the potential damage from denial- 1456 of-service attacks. Security threats related to forged IMDNs include 1457 the sending of a falsified IMDN when the indicated disposition of the 1458 IM has not actually occurred. For example, display notification 1459 could be forged to indicate that an IM has been displayed to the 1460 Recipient. Unsolicited IMDNs is also another form of forgery. 1462 14.2. Confidentiality 1464 There may be cases where an IM Recipient does not wish to reveal the 1465 information that he has received or in fact read the IM. In this 1466 situation, it is acceptable for the IM Recipient to silently ignore 1467 requests for an IMDN. It is strongly RECOMMENDED that the IM 1468 Recipient obtain the user's consent before sending an IMDN. 1469 Circumstances where the IM Recipient does not ask for the user's 1470 consent include IM systems that, for regulatory reasons, are required 1471 to issue an IMDN, such as in the health care field or financial 1472 community. 1474 An IM Recipient can obtain such consent by a prompt or dialog box on 1475 a per-IM basis, globally through the user's setting of a preference, 1476 or other, user-configurable mechanism. The user might also indicate 1477 globally that IMDNs are never to be sent or that a "forbidden" IMDN 1478 status is always sent in response to a request for an IMDN. 1480 There are situations where a user sends an IM and requests IMDNs to a 1481 list whose member information is not disclosed. In this situation, 1482 the user will learn of the list members. Therefore, in this case, 1483 the URI-List server MUST remove any information about list members. 1484 If the number of members in the list is also not disclosed, the URL- 1485 List server MUST only deliver one aggregated IMDN. Alternatively, 1486 the URI-list server MAY reject the IM. 1488 It is possible for a list server to not understand IMDN. IM 1489 Recipients may note the To header field is a list name and not the IM 1490 Recipient's name. In this case, the IM Recipient can take the 1491 appropriate action if it wishes to keep its identity private. 1493 An unencrypted IMDN could reveal confidential information about an 1494 encrypted IM. The same level of security applied to an IM MUST be 1495 applied to its IMDNs. For example, if an IM is signed and encrypted, 1496 the IMDN must be signed and encrypted. 1498 14.3. IMDN as a Certified Delivery Service 1500 IMDNs cannot be relied on as a guarantee that an IM was or was not 1501 seen by the user. Even if IMDNs are not actively forged, they may be 1502 lost in transit. Moreover, the IM Recipient may bypass the IMDN 1503 issuing mechanism through policy or manipulation of their User Agent 1504 Server. 1506 15. IANA Considerations 1508 15.1. message/imdn+xml MIME TYPE 1510 This document registers a new MIME type "message/imdn+xml", and 1511 registers a new XML name space. 1513 This specification follows the guidelines of RFC 3023 [RFC3023]. 1515 MIME media type: message 1517 MIME subtype name: imdn+xml 1519 Mandatory parameters: none 1521 Optional parameters: Same as charset parameter application/xml as 1522 specified in RFC 3023 [RFC3023]. 1524 Encoding considerations: Same as encoding considerations of 1525 application/xml as specified in RFC 3023 [RFC3023]. 1527 Security considerations: See section 10 of RFC 3023 [RFC3023] and 1528 Section 14 of this document. 1530 Interoperability considerations: none. 1532 Published specification: This document. 1534 Applications which use this media type: This document type is used to 1535 support CPIM based instant messaging. 1537 Additional information: None 1539 Magic number: None 1541 File extension: .cl or .xml 1543 Macintosh file type code: "TEXT" 1545 Personal and email address for further information: Hisham Khartabil 1546 (hisham.khartabil@gmail.com) 1548 Intended Usage: COMMON 1550 Author/change controller: The IETF . 1552 15.2. XML Registration 1554 This section registers a new XML name space and schema, as per 1555 guidelines in the IETF XML Registry [IANA]. 1557 URI: The URI for this name space is urn:ietf:params:xml:ns:imdn. 1559 XML: The schema for this name space is in Section 11.1.9 above. 1561 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1562 (hisham.khartabil@gmail.com) . 1564 15.3. Registration for urn:ietf:params:imdn 1566 Registry name: imdn 1568 Specification: RFC XXXX. Additional values may be defined by a 1569 Standards Action [RFC2434] that updates or obsoletes RFC XXXX. 1571 Repository: [RFC EDITOR: fill in by IANA] 1573 Index value: The index value is a CPIM message IMDN header name, 1574 which may consist of a sequence from a restricted set of US-ASCII 1575 characters, as defined above. 1577 URN Formation: The URI for a header is formed from its name by: 1579 a) replacing any non-URN characters (as defined by RFC 2141[URN]) 1580 with the corresponding '%hh' escape sequence (per RFC 3986 1581 [RFC2396]); and 1582 b) prepending the resulting string with 'urn:ietf:params:imdn:'. 1584 Thus, the URI corresponding to the CPIM message IMDN header 1585 'Disposition-Notification:' would be 1586 'urn:ietf:params:imdn:Disposition-Notification'. 1588 Initial values; 1590 (preamble) 1592 +--------------------------+---------------------+ 1593 | Index Value | Reference | 1594 +--------------------------+---------------------+ 1595 | Disposition-Notification | RFCXXXX Section 6.2 | 1596 | Message-ID | RFCXXX Section 6.3 | 1597 | Original-To | RFCXXX Section 6.4 | 1598 | IMDN-Record-Route | RFCXXX Section 6.5 | 1599 | IMDN-Route | RFCXXX Section 6.6 | 1600 +--------------------------+---------------------+ 1602 (postamble) 1604 15.4. Content-Disposition: notification 1606 This document registers one new Content-Disposition header field 1607 "disposition-types": notification. The authors request that this 1608 value be recorded in the IANA registry for Mail Content Dispositions. 1610 Descriptions of this "disposition-types", including motivation and 1611 examples, are given in Section 7.2.1.1 and Section 9. 1613 Short descriptions suitable for the IANA registry are: 1615 notification the body of the message is a notification according to 1616 an earlier request for a disposition notification to an instant 1617 message 1619 16. Acknowledgements 1621 Special thanks to Jari Urpalainen for the thorough review and 1622 suggestions for the RelaxNG Schema. 1624 The authors would also like to thank Paul Kyzivat, Ben Campbell, Adam 1625 Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen, 1626 Miguel Garcia, Eric McMurry, Jon Peterson, and Robert Sparks for 1627 their comments and support. In addition, we would like to thank the 1628 Gen-Art reviewer extrodinaire, Spencer Dawkins. 1630 17. References 1632 17.1. Normative References 1634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1635 Requirement Levels", BCP 14, RFC 2119, March 1997. 1637 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1638 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1639 October 1998. 1641 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1642 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1644 [IANA] Mealling, M., "The IETF XML Registry", RFC 3688, 1645 January 2004. 1647 [URN] Moats, R., "The URN Syntax", RFC 2141, May 1997. 1649 [RFC3023] Murata, M., "XML Media Types", RFC 3023, March 1997. 1651 [XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second 1652 Edition)", W3C CR CR-xml11-20011006, October 2000. 1654 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1655 Resource Identifier (URI): Generic Syntax", STD 66, 1656 RFC 3986, January 2005. 1658 17.2. Informative References 1660 [RFC3261] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., 1661 Johnston, A., Peterson, J., Sparks, R., Handley, M., and 1662 E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1663 June 2002. 1665 [RFC3428] Campbell, B., "SIP Extension for Instant Messaging", 1666 RFC 3428, December 2002. 1668 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1669 April 2001. 1671 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1672 Notification", RFC 3798, May 2004. 1674 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1675 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1677 [URN_NS] Moats, R., "The URN Namespace for IETF Documents", 1678 RFC 2648, August 1999. 1680 [I-D.ietf-sip-uri-list-message] 1681 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 1682 MESSAGE Requests in the Session Initiation Protocol 1683 (SIP)", draft-ietf-sip-uri-list-message-03 (work in 1684 progress), December 2007. 1686 Authors' Addresses 1688 Eric Burger 1689 New Hampshire 1690 USA 1692 Phone: 1693 Fax: +1 603 457 5933 1694 Email: eburger@standardstrack.com 1696 Hisham Khartabil 1697 Ericsson Australia 1698 Melbourne 1699 Australia 1701 Phone: +61 416 108 890 1702 Email: hisham.khartabil@gmail.com 1704 Full Copyright Statement 1706 Copyright (C) The IETF Trust (2008). 1708 This document is subject to the rights, licenses and restrictions 1709 contained in BCP 78, and except as set forth therein, the authors 1710 retain all their rights. 1712 This document and the information contained herein are provided on an 1713 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1714 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1715 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1716 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1717 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1718 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1720 Intellectual Property 1722 The IETF takes no position regarding the validity or scope of any 1723 Intellectual Property Rights or other rights that might be claimed to 1724 pertain to the implementation or use of the technology described in 1725 this document or the extent to which any license under such rights 1726 might or might not be available; nor does it represent that it has 1727 made any independent effort to identify any such rights. Information 1728 on the procedures with respect to rights in RFC documents can be 1729 found in BCP 78 and BCP 79. 1731 Copies of IPR disclosures made to the IETF Secretariat and any 1732 assurances of licenses to be made available, or the result of an 1733 attempt made to obtain a general license or permission for the use of 1734 such proprietary rights by implementers or users of this 1735 specification can be obtained from the IETF on-line IPR repository at 1736 http://www.ietf.org/ipr. 1738 The IETF invites any interested party to bring to its attention any 1739 copyrights, patents or patent applications, or other proprietary 1740 rights that may cover technology that may be required to implement 1741 this standard. Please address the information to the IETF at 1742 ietf-ipr@ietf.org.