idnits 2.17.1 draft-ietf-simple-imdn-10.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 1750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1774. 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 (December 09, 2008) is 5615 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: June 12, 2009 Ericsson Australia 6 December 09, 2008 8 Instant Message Disposition Notification 9 draft-ietf-simple-imdn-10 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 June 12, 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. Constructing Delivery Notifications . . . . . . . . . . . 17 80 8.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 18 81 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 20 82 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 20 83 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 21 85 11.1.1. The Element . . . . . . . . . . . . . . . 22 86 11.1.2. The Element . . . . . . . . . . . . . . . . 22 87 11.1.3. The Element . . . . . . . . . . . . . 22 88 11.1.4. The Element . . . . . . . . . 23 89 11.1.5. The Element . . . . . . . . . . . . . . . . 23 90 11.1.6. The , 91 and 92 Elements . . . . . . . . . . . 23 93 11.1.7. The Element . . . . . . . . . . . . . . . . . 23 94 11.1.8. MIME Type for IMDN Payload . . . . . . . . . . . . . . 23 95 11.1.9. The RelaxNG Schema . . . . . . . . . . . . . . . . . . 23 97 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 27 98 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 27 99 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 27 100 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 28 101 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 28 102 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 29 103 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 30 104 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 105 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33 107 14.3. IMDN as a Certified Delivery Service . . . . . . . . . . . 34 108 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 109 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 34 110 15.2. XML Registration . . . . . . . . . . . . . . . . . . . . . 35 111 15.3. Registration for urn:ietf:params:imdn . . . . . . . . . . 35 112 15.4. Content-Disposition: notification . . . . . . . . . . . . 36 113 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 114 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37 116 17.2. Informative References . . . . . . . . . . . . . . . . . . 37 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 118 Intellectual Property and Copyright Statements . . . . . . . . . . 39 120 1. Introduction 122 In many user-to-user message exchange systems, message senders often 123 wish to know if the human recipient actually received a message or 124 has the message displayed. 126 Electronic Mail [RFC2821] offers a solution to this need with Message 127 Delivery Notifications [RFC3798]. After the recipient views the 128 message, her mail user agent generates a Message Delivery 129 Notification, or MDN. The MDN is an e-mail that follows the format 130 prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an 131 automaton can process the message. 133 The common presence and instant messaging (CPIM) format, Message/CPIM 134 [RFC3862], is a message format used to generate instant messages. 135 The session initiation protocol, SIP [RFC3261], can carry instant 136 messages generated using message/CPIM in SIP MESSAGE requests 137 [RFC3428]. 139 This document extends the Message/CPIM message format in much the 140 same way Message Delivery Notifications extends Electronic Mail. 141 This extension enables Instant Message Senders to request, create, 142 and send Instant Message Disposition Notifications (IMDN). This 143 mechanism works for page-mode as well as session mode instant 144 messages. This document only discusses page-mode. Session mode is 145 left for future standardisation efforts. 147 This specification defines three categories of disposition types, 148 "delivery", "processing", and "displayed". Specific disposition 149 types provide more detailed information. For example, the "delivery" 150 category includes "delivered" to indicate successful delivery and 151 "failed" to indicate failure in delivery. 153 2. Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 This document refers generically to the sender of a message in the 160 masculine (he/him/his) and the recipient of the message in the 161 feminine (she/her/hers). This convention is purely for convenience 162 and makes no assumption about the gender of a message sender or 163 recipient. 165 3. Terminology 167 o IM: An Instant Message generated using the Message/CPIM format. 168 o IMDN: An Instant Message Disposition Notification generated using 169 the Message/CPIM format that carries an IMDN XML document. 170 o Message: an IM or an IMDN generated using the Message/CPIM format. 171 o IM Sender: An endpoint (User Agent) generating and sending an IM. 172 Also, the endpoint request IMDNs for an IM. Quite often, the IM 173 Sender is the IMDN Recipient. However, that is not always the 174 case, since the IMDN uses the From header in the CPIM message. 175 That value is often the IM Sender's Address of Record (AOR). This 176 address may in fact resolve to different User Agents. 177 o IM Recipient: An endpoint (User Agent) that receives IMs. The IM 178 Recipient, as the node that presumably renders the IM to the user, 179 generates and sends delivery IMDNs to IMs, if requested by the IM 180 Sender and allowed by the IM Recipient. 181 o Endpoint: An IM Sender or an IM Recipient. 182 o Intermediary: An entity in the network, most often an application 183 server, including URI-List servers and Store-and-Forward servers, 184 that forwards an IM to its final destination. Intermediaries also 185 can generate and send processing IMDNs to IMs, if requested by the 186 IM Sender and allowed by policy. 187 o Gateway: An intermediary that translates between different IM 188 systems that use different protocols. 189 o IMDN Payload: An XML document carrying the disposition 190 notification information. In this specification, it is of MIME 191 type "message/imdn+xml". 192 o Disposition type: the type of IMDN that can be requested. This 193 specification defines three categories of disposition types, 194 "delivery", "processing", and "display". 195 o Transport Protocol Message: A SIP or other protocol message that 196 contains an IM or IMDN. 198 4. Overview 200 The diagram below shows the basic protocol flow. An IM Sender 201 creates an IM, adds IMDN request information the IM Sender is 202 interested in receiving and then sends the IM. At a certain point in 203 time, the IM Recipient or an intermediary determines that the user or 204 application has received, did not receive, displayed, or otherwise 205 disposed the IM. The mechanism by which an IM Recipient determines 206 its user has read an IM is beyond the scope of this document. At 207 that point, the IM Recipient or intermediary automatically generates 208 a notification message to the IM Sender. This notification message 209 is the Instant Message Disposition Notification (IMDN). 211 +--------------+ +--------------+ 212 | IM Sender | | IM Recipient | 213 |IMDN Recipient| | IMDN Sender | 214 +--------------+ +--------------+ 215 | | 216 | | 217 | 1. IM requesting IMDN | 218 |-------------------------------------->| 219 | | 220 | | 221 | 2. IMDN (disposition) | 222 |<--------------------------------------| 223 | | 224 | | 226 Basic IMDN Message Flow 228 Note the recipient of an IMDN, in some instances, may not be the IM 229 Sender. This is specifically true for page-mode IMs where the 230 Address of Record (AOR) of the IM Sender, that is present in the IM, 231 resolves to a different location or user agent than the IM 232 originated. This could happen, for example, if resolving the AOR 233 results in forking the request to multiple user agents. For 234 simplicity, the rest of this document assumes that the IM Sender and 235 the IMDN Recipient are the same and therefore will refer to both as 236 the IM Sender. 238 5. Disposition Types 240 There are three broad categories of disposition states. They are 241 delivery, processing, and display. 243 5.1. Delivery 245 The delivery notification type indicates whether the IM has been 246 delivered to the IM Recipient or not. The delivery notification type 247 can have the following states: 248 o "delivered" to indicate successful delivery. 249 o "failed" to indicate failure in delivery. 250 o "forbidden" indicate denial for the IM Sender to receive the 251 requested IMDN. The IM Recipient can send the "forbidden" state, 252 but usually it is an intermediary that sends the message if one 253 configures it to do so. For example, it is possible the 254 administrator has disallowed IMDNs. 256 o "error" to indicate an error in determining the fate of an IM. 258 5.2. Processing 260 The processing notification type indicates that an intermediary has 261 processed an IM. The processing notification type can have the 262 following states: 263 o "processed" is a general state of the IM indicating that the 264 intermediary has performed its task on the IM. 265 o "stored" state indicates that the intermediary stored the IM for 266 later delivery. 267 o "forbidden" indicate denial for the IM Sender to receive the 268 requested IMDN. The "forbidden" state is sent by an intermediary 269 that is configured to do so. For example, the administrator has 270 disallowed IMDNs. 271 o "error" to indicate an error in determining the fate of an IM. 273 5.3. Display 275 The display notification type indicates whether the IM Recipient 276 rendered the IM to the user or not. The display notification type 277 can have the following states: 278 o "displayed" is a state indicating that the IM has been rendered to 279 the user. 280 o "forbidden" indicate denial, by the IM Recipient, for the IM 281 Sender to receive the requested IMDN. 282 o "error" to indicate an error in determining the fate of an IM. 284 In addition to text, some IMs may contain audio, video, and still 285 images. Therefore, the state "displayed" includes the start of 286 rendering the audio or video file to the user. 288 Since there is no positive acknowledgement from the user, one cannot 289 determine the user actually read the IM. Thus, one cannot use the 290 protocol described here as a service to prove someone actually read 291 the IM. 293 6. New CPIM Header Fields 295 This specification extends the CPIM data format specified in RFC 3862 296 [RFC3862]. A new name space is created as well as a number of new 297 CPIM header fields. 299 6.1. CPIM Header Field Namespace 301 Per CPIM [RFC3862], this specification defines a new name space for 302 the CPIM extension header fields defined in the following sections. 304 The name space is: 306 urn:ietf:params:imdn 308 As per CPIM [RFC3862] requirements, the new header fields defined in 309 the following sections are prepended, in CPIM messages, by a prefix 310 assigned to the URN through the NS header field of the CPIM message. 311 The remaining of this specification always assumes an NS header field 312 like this one: 314 NS: imdn . 316 Of course, clients are free to use any prefix while servers and 317 intermediaries must accept any legal name space prefix specification. 319 6.2. Disposition-Notification 321 The IM Sender MUST include the Disposition-Notification header field 322 to indicate the desire to receive IMDNs from the IM Recipient, for 323 that specific IM. Section 10 defines the syntax. 325 6.3. Message-ID 327 The IM Sender MUST include the Message-ID header field in the IM that 328 he wishes to receive an IMDN on. The Message-ID contains a globally 329 unique message identifier the IM Sender can use to correlate received 330 IMDNs. Because the Message-ID is used by the sender to correlate 331 IMDNs with their respective IMs, the Message-ID MUST be selected so 332 that: 334 o There is a minimal chance of any two Message-IDs accidentally 335 colliding within the time period within which an IMDN might be 336 received. 337 o It is prohibitive for an attacker who has seen one or more valid 338 Message-IDs to generate additional valid Message-IDs. 340 The first requirement is a correctness requirement to ensure correct 341 matching by the sender. The second requirement prevents off-path 342 attackers from forging IMDNs. In order to meet both of these 343 requirements, it is RECOMMENDED that Message-IDs be generated using a 344 cryptographically secure pseudorandom number generator and contain at 345 least 64 bits of randomness, thus reducing the chance of a successful 346 guessing attack to n/2^64, where n is the number of outstanding valid 347 messages. 349 When the IM Sender receives an IMDN, it can compare its value with 350 the value of the element present in the IMDN payload. 351 IMDNs also carry this header field. Note that since the IMDN is 352 itself an IM, the Message-ID of the IMDN will be different than the 353 Message-ID of the original IM. Section 10 defines the syntax. 355 6.4. Original-To 357 An intermediary MAY insert an Original-To header field to the IM. 358 The value of the Original-To field MUST be the address of the IM 359 Receiver. The IM Recipient uses this header to indicate the original 360 IM address in the IMDNs. The IM Recipient does this by populating 361 the element in the IMDN. The intermediary 362 MUST insert this header if the intermediary changes the CPIM To 363 header field value. The header field MUST NOT appear more than once 364 in an IM. The intermediary MUST NOT change this header field value 365 if it is already present. Section 10 defines the syntax. 367 6.5. IMDN-Record-Route 369 An intermediary MAY insert an IMDN-Record-Route header field to the 370 IM. This enables the intermediary to receive and process the IMDN on 371 its way back to the IM Sender. The value of the IMDN-Record-Route 372 header field MUST be the address of the intermediary. Multiple IMDN- 373 Record-Route header fields can appear in an IM. Section 10 defines 374 the syntax. 376 6.6. IMDN-Route 378 The IMDN-Route header field provides routing information by including 379 one or more addresses where to route the IMDN. An intermediary that 380 needs the IMDN to flow back through the same intermediary MUST add 381 the IMDN-Record-Route header. When the IM Recipient creates the 382 corresponding IMDN, the IM Recipient copies the IMDN-Record-Route 383 headers into corresponding IMDN-Route header fields. Section 10 384 defines the syntax. 386 7. Endpoint Behaviour 388 7.1. IM Sender 390 7.1.1. Constructing Instant Messages 392 An IM is constructed using CPIM Message Format defined in RFC 3862 393 [RFC3862]. 395 7.1.1.1. Adding a Message-ID Header Field 397 If the IM sender requests the reception of IMDNs, the IM sender MUST 398 include a Message-ID header field. This header field enables the IM 399 Sender to match any IMDNs with their corresponding IMs. See 400 Section 6.3 for Message-ID uniqueness requirements. 402 7.1.1.2. Adding a DateTime Header Field 404 Some devices are not able to retain state over long periods. For 405 example, mobile devices may have memory limits or battery limits. 406 These limits may mean these devices may not be able to, or may chose 407 not to, keep sent messages for the purposes of correlating IMDNs with 408 sent IMs. To make some use of IMDN in this case, we add a time stamp 409 to the IM to indicate when the user sent the message. The IMDN 410 returns this time stamp to enable the user to correlate the IM with 411 the IMDN at the human level. We use the DateTime CPIM header field 412 for this purpose. Thus, if the IM Sender would like an IMDN, the IM 413 Sender MUST include the DateTime CPIM header field. 415 7.1.1.3. Adding a Disposition-Notification Header Field 417 The Disposition-Notification conveys the type of disposition 418 notification requested by the IM sender. There are three types of 419 disposition notification: delivery, processing, and display. The 420 delivery notification is further subdivided into failure and success 421 delivery notifications. An IM Sender requests failure delivery 422 notification by including a Disposition-Notification header field 423 with value "negative-delivery". Similarly, a success notification is 424 requested by including a Disposition-Notification header field with 425 value "positive-delivery". The IM Send can request both types of 426 delivery notifications for the same IM. 428 The IM Sender can request a processing notification by including a 429 Disposition-Notification header field with value "processing". 431 The IM Sender can also request a display notification. The IM Sender 432 MUST include a Disposition-Notification header field with the value 433 "display" to request a display IMDN. 435 The absence of this header field or the presence of the header field 436 with an empty value indicates that the IM Sender is not requesting 437 any IMDNs. Disposition-Notification header field values are comma 438 separated. The IM Sender MAY request more than one type of IMDN for 439 a single IM. 441 Future extensions may define other disposition notifications not 442 defined in this document. 444 Section 10 describes the formal syntax for the Disposition- 445 Notification header field. The following is an example CPIM body of 446 an IM where the IM Sender requests positive and negative delivery 447 notifications, but neither display notification nor processing 448 notifications: 450 From: Alice 451 To: Bob 452 NS: imdn 453 imdn.Message-ID: 34jk324j 454 DateTime: 2006-04-04T12:16:49-05:00 455 imdn.Disposition-Notification: positive-delivery, negative-delivery 456 Content-type: text/plain 457 Content-length: 12 459 Hello World 461 7.1.2. Matching IMs with IMDNs 463 An IM Sender matches an IMDN to an IM by matching the Message-ID 464 header field value in the IM with the element value in 465 the body of the IMDN. If the IM was delivered to multiple 466 recipients, the IM Sender uses the element and the 467 element in the XML body of the IMDN it 468 received to determine if the IM was sent to multiple recipients and 469 to identify the IM Recipient that sent the IMDN. 471 An IM Sender can determine an IMDN is a disposition notification by 472 noting the Content-Disposition in the IMDN is "notification". This 473 does mean the IM Sender MUST understand the Content-Disposition MIME 474 header in CPIM messages. 476 7.1.3. Keeping State 478 This specification does not mandate the IM Sender to keep state for a 479 sent IM. 481 Once an IM Sender sends an IM containing an IMDN request, it MAY 482 preserve the IM context, principally the Message-ID, and other user- 483 identifiable information such as the IM subject or content, and date 484 and time it was sent. Without preservation of the IM context, the IM 485 Sender will not be able to correlate the IMDN with the IM it sent. 486 The IM Sender may find it impossible to preserve IM state if it has 487 limited resources or does not have non-volatile memory and then loses 488 power. 490 There is, however, the concept of "Sent Items" box in an application 491 that stores sent IMs. This "Sent Items" box has the necessary 492 information and may have a fancy user interface indicating the state 493 of a sent IM. A unique Message-ID for this purpose proves to be 494 useful. The length of time for items to remain in the "Sent Items" 495 box is a user choice. The user is usually free to keep or delete 496 items from the "Sent Items" box as she pleases or as the memory on 497 the device reaches capacity. 499 Clearly, if an IM Sender loses its sent items state, for example, the 500 user deletes items from the "Send Items" box, the client may use a 501 different display strategy in response to apparently unsolicited 502 IMDNs. 504 This specification also does not mandate an IM Sender to run any 505 timers waiting for an IMDN. There are no time limits associated with 506 when IMDNs may be received. 508 IMDNs may legitimately never be received, so the time between the 509 sending of an IM and the generation and ultimate receipt of the IMDN 510 may simply take a very long time. Some clients may choose to purge 511 the state associated with the sent IM. This is the reason for adding 512 the time stamp in the IM and having it returned in the IMDN. This 513 gives the user some opportunity of remembering what IM was sent. For 514 example if the IMDN indicates that the IM the user sent at 2 p.m. 515 last Thursday was delivered, the user has a chance of remembering 516 that they sent an IM at 2 p.m. last Thursday. 518 7.1.4. Aggregation of IMDNs 520 An IM Sender may send an IM to multiple recipients in one Transport 521 Protocol Message (typically using a URI-List server 522 [I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender 523 that requested IMDNs MUST be prepared to receive multiple aggregated 524 or non-aggregated IMDNs. See Section 8.3 for details. 526 7.2. IM Recipient 528 7.2.1. Constructing IMDNs 530 IM recipients examine the contents of the Disposition-Notification 531 header field of the CPIM message to determine if the recipient needs 532 to generate an IMDN for that IM. Disposition-Notification header 533 fields of CPIM messages can include one or more values. IM 534 recipients may need to generate zero, one, or more IMDNs for that IM, 535 for example a delivery notification as well as a display 536 notification. In this case, the IM Recipient MUST be able to 537 construct multiple IMDNs per IM. An IM Recipient MUST NOT construct 538 more than one IMDN per disposition type. That is, it must not 539 generate a delivery notification indicating "delivered" then followed 540 by a delivery notification indicating "failed" for the same IM. If 541 the IM Sender requested only failure notifications and the IM was 542 successfully delivered, then no IMDNs will be generated. If the IM 543 recipient does not understand a value of the Disposition-Notification 544 header field, the IM recipient ignores that value. 546 The IM Recipient MUST NOT generate "processing" notifications. 548 A Disposition-Notification header field MUST NOT appear in an IMDN 549 since it is forbidden to request an IMDN for an IMDN. An IM Sender 550 MUST ignore a delivery notification request in an IMDN if present. 551 The IM Sender MUST NOT send an IMDN for an IMDN. 553 An IMDN MUST contain a Message-ID header field. The same rules of 554 uniqueness for the Message-ID header field that appears in an IM 555 apply to an IMDN. The Message-ID header field in the IMDN is 556 different and unrelated to the one in the IM. 558 An IM may contain an IMDN-Record-Route header field (see Section 8 559 for details). If IMDN-Record-Route header fields appear in the IM, 560 the IM Recipient constructing the IMDN MUST copy the contents of the 561 IMDN-Record-Route header fields into IMDN-Route header fields in the 562 IMDN and maintain the order. The IMDN is then sent to the URI in the 563 top IMDN-Route header field. IMDN-Record-Route header fields do not 564 make sense in an IMDN and therefore MUST NOT be placed in an IMDN. 565 IMDN Recipients MUST ignore it if present. 567 If there is no IMDN-Record-Route header field, the IM Recipient MUST 568 send the IMDN to the URI in the From header field. 570 As stated in CPIM [RFC3862], CPIM messages may need to support MIME 571 headers other than Content-type. IM Recipients MUST insert a 572 Content-Disposition header field, set to the value "notification". 573 This indicates to the IM Sender that the message is an IMDN to an IM 574 it has earlier sent. 576 7.2.1.1. Constructing Delivery Notifications 578 The IM Recipient constructs a delivery notification in a similar 579 fashion as an IM, using a CPIM body [RFC3862] that carries a 580 Disposition Notification XML document formatted according to the 581 rules specified in Section 11. The MIME type of the Disposition 582 Notification XML document is "message/imdn+xml". 584 Section 10 defines the schema for an IMDN. 586 An example CPIM body of IMDN looks like the following: 588 From: Bob 589 To: Alice 590 NS: imdn 591 imdn.Message-ID: d834jied93rf 592 Content-type: message/imdn+xml 593 Content-Disposition: notification 594 Content-length: ... 596 597 598 34jk324j 599 2008-04-04T12:16:49-05:00 600 im:bob@example.com 601 im:bob@example.com 603 604 605 606 607 608 610 7.2.1.2. Constructing Display Notifications 612 The IM Recipient constructs a display notification in a similar 613 fashion as the delivery notification. See Section 7.2.1.1 for 614 details. 616 Section 10 defines the schema for an IMDN. 618 An example looks like the following: 620 From: Bob 621 To: Alice 622 NS: imdn 623 imdn.Message-ID: dfjkleriou432333 624 Content-type: message/imdn+xml 625 Content-Disposition: notification 626 Content-length: ... 628 629 630 34jk324j 631 2008-04-04T12:16:49-05:00 632 im:bob@example.com 633 im:bob@example.com 635 636 637 638 639 640 642 There are situations where the IM Recipient cannot determine if or 643 when the IM has been displayed. The IM Recipient in this case 644 generates a display notification with a value of "error" to 645 indicate an internal error by the server. Note that the IM Recipient 646 may choose to ignore any IMDN requests and not to send any IMDNs. An 647 IM recipient may not wish to let a sender know if a particular 648 message has been displayed to her or not. This could be on a per- 649 message, per-sender, or programmed policy choice. 651 8. Intermediary Behaviour 653 In this context, intermediaries are application servers (including 654 URI-List servers and Store-and-Forward server) and gateways. A 655 gateway is a server that translates between different IM systems that 656 use different protocols. 658 A URI-List server may change the IM Recipient address from its own to 659 the address of the final recipient of that IM for every copy it makes 660 that it sends to the list members (see 661 [I-D.ietf-sip-uri-list-message] for details). In this case, if the 662 IM Sender is requesting an IMDN, the intermediary SHOULD add an 663 Original-To header field to the IM populating it with the address 664 that was in the CPIM To header field before it was changed. That is, 665 the intermediary populates the Original-To header field with the 666 intermediary address. Of course, one may configure an intermediary 667 to restrict it from rewriting or populating the Original-To field. 668 An intermediary MUST NOT add an Original-To header field if one 669 already exists. An intermediary MAY have an administrative 670 configuration to not reveal the original Request-URI, and as such, 671 MUST NOT add an Original-To header. 673 An IM reply for a page-mode IM is not linked in any way to the 674 initial IM and can end up at a diffent user agent from where the 675 initial IM originated, depending on how the recipient URI gets 676 resolved. Therefore, IM replies may traverse different 677 intermediaries. An IMDN, on the other hand, needs to traverse the 678 same intermediares as the IM itself since those intermediares may be 679 required to report negative delivery notifications if the IM was not 680 delivered successfully. Some of those interdemiaries are, for 681 example, store-and-forward servers that may report that an IM has 682 been processed and later report that the IM has failed to be 683 delivered. 685 For the reasons stated above, an intermediary MAY choose to remain on 686 the path of IMDNs for a specific IM. It can do so by adding a CPIM 687 IMDN-Record-Route header field as the top IMDN-Record-Route header 688 field. The value of this field MUST be the intermediary's own 689 address. An intermediary that does not support this extension will 690 obviously not add the IMDN-Record-Route header field. This allows 691 IMDNs to traverse directly from the IM Recipient to the IM Sender 692 even if the IM traversed an intermediary not supporting this 693 extension. 695 An intermediary receiving an IMDN checks the top IMDN-Route header 696 field. If that header field carries the intermediary address, the 697 intermediary removes that value and forwards the IMDN to the address 698 indicated in the now top IMDN-Route header field. If no additional 699 IMDN-Route header fields are present, the IMDN is forwarded to the 700 address in the CPIM To header field. 702 An intermediary MUST remove any information about the final 703 recipients of a list if the list membership is not disclosed. The 704 intermediary does that by removing the element and/or 705 element from the body of the IMDN before 706 forwarding it to the IM Sender. 708 8.1. Constructing Processing Notifications 710 Intermediaries are the only entities that construct processing 711 notifications. They do so only if the IM Sender has requested a 712 "processing" notification by including a Disposition-Notification 713 header field with value "processing". 715 The intermediary can create and send "processing" notifications 716 indicating that an IM has been processed or stored. The intermediary 717 MUST NOT send more than one IMDN for the same disposition type. 718 I.e., it must not send a "processing" notification indicating that an 719 IM is being "processed" followed by another IMDN indicating that the 720 same IM is "stored". 722 An intermediary constructs a "processing" notification in a similar 723 fashion as the delivery notification. See Section 7.2.1.1 for 724 details. 726 An example looks like the following: 728 Content-type: Message/CPIM 730 From: Bob 731 To: Alice 732 Content-type: message/imdn+xml 733 Content-Disposition: notification 734 Content-length: ... 736 737 738 34jk324j 739 2008-04-04T12:16:49-05:00 740 im:bob@example.com 741 im:bob@example.com 743 744 745 746 747 748 750 There are situations where the intermediary cannot know the fate of 751 an IM. The intermediary in this case generates a processing 752 notification with a value of "error" to indicate so. 754 8.2. Constructing Delivery Notifications 756 Intermediaries MAY construct negative delivery notifications. They 757 do so only if the IM Sender has requested a "negative-delivery" 758 notification by including a Disposition-Notification header field 759 with value "negative-delivery" AND an error was returned for that IM. 761 The intermediary can create and send "negative-delivery" 762 notifications indicating that an IM has failed to be delivered. The 763 intermediary MUST NOT send more than one IMDN for the same 764 disposition type. I.e., it must not send a "failed" notification 765 indicating that an IM has failed followed by another IMDN indicating 766 that an IMDN is "forbidden". 768 An intermediary constructs a "negative-delivery" notification much 769 like the IM Recipient. See Section 7.2.1.1 for details. 771 8.3. Aggregation of IMDNs 773 As previously described, URI-List servers are intermediaries. 775 A URI-List server may choose to aggregate IMDNs using local policy 776 for making such a decision or it may send individual IMDNs instead. 777 When a URI-List server receives an IM and decides to aggregate IMDNs, 778 it can wait for a configurable period of time or until all recipients 779 have sent the IMDN, whichever comes first, before the URI-List server 780 sends an aggregated IMDN. Note that some IMDNs, for example 781 "displayed" notifications, may never come due to user settings. It 782 is an administrator configuration and an implementation issue how 783 long to wait before sending an aggregated IMDN and before a URI-List 784 server removes state for that IM. 786 A URI-List server MAY choose to send multiple aggregated IMDNs. A 787 timer can be started and when it fires, the URI-List server can 788 aggregate whatever IMDNs it has so far for that IM, send the 789 aggregated IMDN and restart the timer for the next batch. This is 790 needed for scenarios where the IM Sender has requested more than one 791 IMDN for a specific IM, for example, delivery notifications as well 792 as display notifications, or when the URI-List server is short on 793 resources and chooses to prioritise forwarding IMs over IMDNs. 795 A second timer can be running and when it fires, the state of the IM 796 is deleted. In this case, the URI-List server consumes any IMDNs 797 that might arrive after that time. 799 Please note the references to timers in the above paragraphs are not 800 normative and are only present to help describe one way one might 801 implement aggregation. 803 A URI-List server MAY aggregate IMDNs for the case where the list 804 membership information is not disclosed. There may be scenarios 805 where the URI-List server starts sending aggregated IMDNs and switch 806 to individual ones or visa versa. A timer firing so often may in 807 fact have that effect. 809 The aggregated IMDN is constructed using the multipart/mixed MIME 810 type and including all the received IMDNs as message/imdn+xml as 811 individual payloads. 813 Below is an example of aggregated IMDNs. 815 From: Bob 816 To: Alice 817 NS: imdn 818 imdn.Message-ID: d834jied93rf 819 Content-type: multipart/mixed; 820 boundary="imdn-boundary" 821 Content-Disposition: notification 822 Content-length: ... 824 --imdn-boundary 825 Content-type: message/imdn+xml 827 828 829 34jk324j 830 2008-04-04T12:16:49-05:00 831 im:bob@example.com 832 im:bob@example.com 834 835 836 837 838 839 841 --imdn-boundary 842 Content-type: message/imdn+xml 844 845 846 34jk324j 847 2008-04-04T12:16:49-05:00 848 im:bob@example.com 849 im:bob@example.com 851 852 853 854 855 856 858 --imdn-boundary 860 9. Identifying Messages 862 Messages are typically carried in a transport protocol like SIP 863 [RFC3261]. If the payload carried by the transport protocol does not 864 contain any parts of type Message/CPIM then the message is an IM. If 865 the payload contains any parts of type Message/CPIM, and none of 866 those parts contains a payload that is of type "message/imdn+xml", 867 the message is an IM. It is not valid to attempt to carry both an IM 868 and an IMDN in a multipart payload in a single transport protocol 869 message. 871 A message is identified as a delivery notification by examining its 872 contents. The message is a delivery notification if the Content-type 873 header field present has a value of "message/imdn+xml", the Content- 874 Disposition header field has a value of "notification", and the 875 element appears in that xml body. 877 A message is identified as a processing notification or display 878 notification in a similar fashion as a delivery notification. The 879 difference is that for a processing notification, the element appears in the xml body. For a display 881 notification, the element appears in the xml 882 body. 884 10. Header Fields Formal Syntax 886 The following syntax specification uses the message header field 887 syntax as described in Section 3 of RFC 3862 [RFC3862]. 889 Header field syntax is described without a name space qualification. 890 Following the rules in RFC 3862 [RFC3862], header field names and 891 other text are case sensitive and MUST be used as given, using 892 exactly the indicated upper case and lower case letters. 894 Disposition-Notification = 895 "Disposition-Notification" ": " 896 [(notify-req *(COMMA notify-req))] 898 notify-req = 899 ("negative-delivery" / "positive-delivery" / 900 "processing" / "display" / Token) *(SEMI disp-notify-params) 902 disp-notify-params = Ext-param 904 Message-ID = "Message-ID" ": " Token 906 Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" 908 IMDN-Record-Route = 909 "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" 911 IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 913 SEMI = *SP ";" *SP ; semicolon 915 COMMA = *SP "," *SP ; comma 917 11. IMDN Format 919 11.1. Structure of XML-Encoded IMDN Payload 921 An IMDN Payload is an XML document [XML] that MUST be well formed and 922 MUST be valid according to schemas, including extension schemas, 923 available to the validater and applicable to the XML document. The 924 IMDN Payload MUST be based on XML 1.0 and MUST be encoded using 925 UTF-8. 927 The schema allows qualified extension elements in several positions 928 other than the "urn:ietf:params:xml:ns:imdn" namespace. To maintain 929 forwards compatibility (newer instance documents can be used by 930 existing consumers) the new specifications MUST NOT extend the 931 allowable content of this specification. The backwards compatibility 932 (existing instance documents can also be used by updated new 933 consumers) MAY break if there are conflicts with the existing 934 qualified names of extension elements and possible new 935 specifications. The IETF MAY specify new extension elements within 936 the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/ 937 imdn+xml MIME type. 939 Possible future specifications can add new element definitions with 940 the combine="interleave" pattern. When multiple elements of this new 941 type are then allowed, the new definition MUST contain the 942 cardinality rule. If the new specification does allow 943 only a single new element, the cardinality rule MUST be 944 used. These cardinality requirements maintain the backwards 945 compatibility of existing instance documents with newer consumers. 946 Also the new specification MUST then re-define either the "anyIMDN" 947 extension, or the individual extension points which reference it, so 948 that new element definitions do not match with this redefined, and 949 more limited wildcard pattern. 951 The name space identifier for elements defined by this specification 952 is a URN [URN], using the name space identifier 'ietf' defined by 953 [URN_NS] and extended by [IANA]. This urn is: 954 urn:ietf:params:xml:ns:imdn. 956 This name space declaration indicates the name space on which the 957 IMDN is based. 959 The root element is . The element has sub-elements, 960 namely , , , , , and one of , 962 or . A also 963 appears as a sub-element of , and . The elements are described 965 in details in the following sections. 967 , can be extended in the future to include new disposition 968 notification types or other elements, as described in Section 11.1.9. 970 11.1.1. The Element 972 The element is mandatory according to the XML schema and 973 carries the message id that appeared in the Message-ID header field 974 of the IM. 976 11.1.2. The Element 978 The element is mandatory and carries the date and time the 979 IM was sent (not the IMDN). This information is obtained from the 980 DateTime header field of the IM. 982 11.1.3. The Element 984 The element is optional and carries the URI of the 985 final recipient. This information is obtained from the CPIM To 986 header field of the IM. 988 11.1.4. The Element 990 The element is optional and carries the URI 991 of the original recipient. It MUST be present if the IM carried the 992 Original-To header field. This information is obtained from the 993 Original-To header field of the IM. 995 11.1.5. The Element 997 The element is optional. If present it MUST cary the text 998 and, if present, language attribute, that was in the Subject header 999 field, if any. This allows for a human level correlation between an 1000 IM and an IMDN. If there are more than one Subject header fields in 1001 an IM, selecting any one of them to place in the IMDN payload 1002 element will suffice. The sender then needs to compare 1003 Subject header fields until a match or not match is determined. 1005 11.1.6. The , and 1006 Elements 1008 The appearance of one of the , and elements is mandatory and 1010 carries the disposition type that the IM Sender requested and is 1011 being reported. It carries the sub-element . 1013 11.1.7. The Element 1015 The element is mandatory and carries the result of the 1016 disposition request. For notification type , 1017 it can carry one of the sub-elements , , 1018 or . For notification type , it can carry one of the sub-elements , 1020 or . For notification type , it can carry one of the sub-elements , 1022 , or . means the disposition 1023 was denied. means internal server error. It can also be 1024 extended to carry any other status extension. 1026 11.1.8. MIME Type for IMDN Payload 1028 The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN 1029 MUST identify the payload as MIME type "message/imdn+xml" in the 1030 Content-type header field. 1032 11.1.9. The RelaxNG Schema 1034 1035 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1131 1137 1138 1139 1140 1141 1143 1144 1145 1146 1147 1148 1150 1151 1152 1153 1154 1155 1157 1158 1159 1160 1161 1162 1164 1171 1172 1173 1174 1175 1176 1177 1178 1179 1181 1182 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1196 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1213 1215 12. Transporting Messages using SIP 1217 12.1. Endpoint Behaviour 1219 12.1.1. Sending Requests 1221 The IM Sender constructs a SIP MESSAGE request using RFC 3428 1222 [RFC3428]. The Content-type header field indicates the MIME type of 1223 the request payload. When using this extension, the Content-type 1224 header field MUST be of MIME type "message/cpim" [RFC3862] for both 1225 IMs and IMDNs. The IM Sender constructs the payload according to 1226 Section 7. 1228 The IM Sender constructs a SIP MESSAGE request to multiple recipients 1229 in a similar manner as a SIP MESSAGE request to a single recipient. 1230 Multiple-Recipient MESSAGE Requests in SIP 1231 [I-D.ietf-sip-uri-list-message] describes the differences. 1233 IM senders can remain anonymous. For example, the sender can set the 1234 SIP From header field of the SIP message to an anonymous URI. As 1235 there is no return address, anonymous IM senders SHOULD NOT request 1236 disposition notifications. An IM Recipient MAY ignore such request 1237 if the IM Sender is anonymous. 1239 12.1.2. Sending Responses 1241 An endpoint receiving a SIP MESSAGE request constructs a SIP response 1242 according to RFC 3428 [RFC3428]. Of course, an endpoint will send a 1243 SIP response to the MESSAGE request regardless of the type of message 1244 (IM or IMDN) is has received, or the disposition type it has been 1245 asked for. 1247 12.1.3. Receiving Requests 1249 12.1.3.1. Instant Message 1251 A SIP MESSAGE request is identified as an IM by examining its 1252 contents according to Section 9. 1254 If an IM Recipient received a SIP MESSAGE request that is an IM that 1255 requested a positive-delivery notification, and that IM Recipient has 1256 constructed and sent a SIP 2xx class response, it MAY generate a 1257 positive-delivery notification after making sure that the IM has been 1258 delivered to the user or application. A gateway, for example, can 1259 generate a 2xx response before the final recipient received the IM. 1260 The IM Recipient constructs a positive-delivery notification 1261 according to Section 7.2.1.1. The IM Recipient places the message as 1262 the payload in a SIP MESSAGE request. 1264 If an IM Recipient received a SIP MESSAGE request that is an IM that 1265 requested a negative-delivery, and that IM Recipient has constructed 1266 and sent a 2xx class response, it SHOULD generate a negative-delivery 1267 notification if it learnt that the final recipient or application did 1268 not receive the IM (a gateway, for example, can generate a 2xx 1269 response before it has an error response from downstream or before 1270 any internal timers fire waiting for a response). The negative- 1271 delivery notification is constructed according to Section 7.2.1.1. 1272 The message is then placed as the payload in a SIP MESSAGE request. 1274 If an IM Recipient received a SIP MESSAGE request that is an IM that 1275 requested a negative-delivery notification, and the IM Recipient has 1276 constructed and sent an non-2xx final response, it MUST NOT generate 1277 a negative-delivery notification. 1279 If an IM Recipient received a SIP MESSAGE request that is an IM that 1280 requested a display notification, and that IM Recipient has 1281 constructed and sent a SIP 2xx class response, it MAY generate a 1282 display notification after making sure that the IM has been presented 1283 to the user or application. It is outside the scope of this document 1284 how a determination can be made whether the IM has been read. Note 1285 that the option to send a display notification or not can be left to 1286 the user. An application may allow a user to configure such choice. 1287 The IM Recipient constructs the display notification according to 1288 Section 7.2.1.2. The IM Recipient places the message as the payload 1289 in a SIP MESSAGE request. 1291 For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP 1292 To header field using the address that appeared in the SIP From 1293 header field in the IM. 1295 12.1.3.2. Delivery Notification 1297 A SIP MESSAGE request is identified as delivery notification by 1298 examining its contents according to Section 9. 1300 12.1.3.3. Display Notification 1302 A SIP MESSAGE request is identified as display notification by 1303 examining its contents according to Section 9. 1305 12.2. Intermediary Behaviour 1307 In this context, intermediaries include application servers, 1308 including URI-List servers, Store-and-Forward servers, and gateways. 1309 SIP Proxies MUST NOT generate IMDNs but MUST forward them like any 1310 other SIP request. 1312 Intermediaries forward a SIP MESSAGE request to multiple recipients 1313 according to [I-D.ietf-sip-uri-list-message]. 1315 If an intermediary receives an IM, the intermediary examines the 1316 body. If the body is of type "message/cpim" the intermediary then 1317 looks for a Disposition-Notification CPIM header field in the 1318 message. If the Disposition-Notification CPIM header field has 1319 either the value "positive-delivery" or "negative-delivery", and, in 1320 processing the IM, the intermediary generates a SIP 2xx class 1321 response to the MESSAGE request, then the intermediary performs the 1322 following actions. 1324 If the Disposition-Notification header field contains a value of 1325 "positive-delivery", the intermediary MUST NOT generate a delivery 1326 notification if it receives a SIP 2xx class response for the sent IM. 1327 Just because a downstream entity received a MESSAGE request does not 1328 mean the message was relayed to its ultimate destination or was 1329 delivered. Thus, the intermediary cannot say delivery occurred just 1330 because it received a 2xx response. 1332 If the Disposition-Notification header field contains a value of 1333 "negative-delivery", the intermediary SHOULD generate a delivery 1334 notification if it receives a SIP 4xx, 5xx or 6xx class final 1335 response for the sent IM. If it has received a SIP 2xx class 1336 response followed by a negative-delivery notification, the 1337 intermediary forwards that negative-delivery notification or 1338 aggregates it. 1340 If the Disposition-Notification header field contains a value of 1341 "processing", the intermediary MAY generate a processing notification 1342 after it has forwarded or stored the IM. The rest of the procedures 1343 in Section 8.1 apply. 1345 The procedure for generating such IMDN is the same as that of an IM 1346 Recipient (Section 7.2.1.1). 1348 The element of the XML body is populated with the URI 1349 of the IM Recipient. 1351 If an intermediary receives a SIP MESSAGE request carrying a positive 1352 delivery notification or a display notification, it forwards it using 1353 the rules in Section 8. 1355 13. Transporting Messages using MSRP 1357 MSRP [RFC4975] already provides a built-in mechanism to supply 1358 positive and negative delivery reports. These reports do not provide 1359 built-in Display or Processing notifications. However, these 1360 notifications in session mode are not as useful as they are for page- 1361 mode. This is because the base use case for MSRP is that the 1362 recipient user agent immediately renders SEND requests sequentially, 1363 providing the session experience. This is unlike page-mode requests 1364 where a user has to actively initiate the display of the message. 1365 That is, they need to click on a button, open a message, and so on to 1366 read the message. 1368 If new requirements arise in the future determining the need for IMDN 1369 in MSRP, new specifications can be drafted. 1371 14. Security Considerations 1373 IMDNs provide a fine-grained view of the activity of the IM Recipient 1374 and thus deserves particularly careful confidentiality protection so 1375 that only the intended recipient of the IMDN will receive the IMDN. 1376 In most cases, the intended recipient of the IMDN is the IM Sender. 1378 Since the IM transport protocol carries the IMDN, all security 1379 considerations of the underlying IM protocol also apply to the IMDNs. 1381 The threats in the IMDN system, over and beyond the threats inherent 1382 to IM include the following: 1383 o A malicious endpoint attempts to send messages to a user that 1384 would normally not wish to receive messages from that endpoint by 1385 convincing the IMDN system to "bounce" an IMDN from an 1386 unsuspecting endpoint to the user. 1387 o A malicious endpoint attempts to flood an IM Sender with IMDNs by 1388 convincing a URI-List server to send IMDNs to an unsuspecting IM 1389 Sender. 1390 o A malicious intermediary or node attempts to flood a target node 1391 with IMDNs by inserting the target's address in the From field or 1392 IMDN-Record-Route field 1393 o A malicious node in the network that attempts to modify an IMDN 1394 from an IM Recipient. 1395 o A malicious intermediary attempts to forward an IMDN from an IM 1396 Recipient to the IM Sender, where the IM Recipient would not 1397 normally forward the IMDN to that IM Sender if the IM Recipient 1398 knew the identity of the IM Sender. 1399 o A malicious endpoint that attempts to discover for a Request-URI 1400 of an endpoint beyond an intermediary, where the endpoint would 1401 normally wish to keep its identity private from the malicious 1402 endpoint. 1403 o A malicious node in the network that attempts to eavesdrop on IMDN 1404 traffic to, for example, learn Request-URI or traffic pattern 1405 information. 1406 o A malicious node in the network attempts to stage a denial of 1407 service attack on an intermediary by requesting a large list 1408 expansion. 1410 The protocol cannot protect against attacks that include the 1411 following: 1412 o A malicious intermediary directly revealing the identity of a 1413 downstream endpoint that would not normally wish its identity 1414 revealed. Keeping such information private is an intermediary 1415 implementation issue. 1416 o A malicious IM Recipient that alters the time of the IMDN. There 1417 is no protocol mechanism for ensuring that the IM Recipient does 1418 not lie about the time or purposely holds an IMDN for transmission 1419 to make it appear that the IM was displayed to the user read later 1420 than it actually did. 1421 o A deletion attack on an IMDN. This is a trade-off between privacy 1422 and security. The privacy considerations allow the IM Recipient 1423 to silently ignore an IMDN request. Any mechanism that would 1424 reliably indicate that a malicious node deleted an IM Recipient's 1425 IMDN would also serve the purpose of detecting an IM Recipient 1426 that chose not to issue an IMDN. 1428 To combat eavesdropping, modification, and man-in-the-middle attacks, 1429 we require some level of authentication and integrity protections. 1430 That said, there are circumstances where strong integrity would be 1431 overkill. The presumption is the IM Sender has and sets the 1432 expectation for the level of protection. The procedures for 1433 integrity protection are as follows. 1434 o If the IM Recipient has a certificate, it MUST sign the IMDN. 1435 Signing the IMDN provides integrity protection. While an 1436 intermediary can replace the IMDN body, the IM Sender (the 1437 recipient of the IMDN) can validate the signature and note the 1438 IMDN does not come directly from the IM Receiver. This is not a 1439 problem if the IM Sender trusts the intermediary. Likewise, an 1440 IMDN in response to a signed IM without a signature indicates 1441 something bad might have happened. 1442 o If the IM is encrypted, the IM Recipient or intermediary MUST 1443 encrypt the IMDN body, as an attacker may attempt to discern the 1444 user's activity profile and identity from sniffing IMDNs on the 1445 network. 1446 o The two above rules are cumulative. 1447 The IM Recipient or intermediary MUST be capable of accessing the IM 1448 Sender's public certificate in order to verify the signature in the 1449 IM. 1451 CPIM security considerations [RFC3862] apply here, as this is an 1452 extension of CPIM. In order to make the IMDN mechanism independent 1453 of the transport protocol, the Work Group made the design choice of 1454 putting routing information into the IMDN application layer payload. 1455 One consequence of this choice is it eliminates the possibility of 1456 having end-to-end encryption. 1458 An attacker can mount a distributed denial of service attack on a 1459 node by sending lots of IMs to the node with IMDN requests. Note 1460 that this is the same problem as there is without IMDN; IMDN simply 1461 linearly increases the load on the node under attack. One can 1462 mitigate, but not eliminate this threat by the endpoint immediately 1463 ignoring requests that are not authenticated. 1465 One way to address the potential for a malicious node to use the IMDN 1466 system to anonomize attacks is to log all IMDN requests on the IM 1467 Recipient User Agent. This allows for tracking of attacks, if only 1468 after they occur. Note this also puts a burden on the IM Recipient 1469 User Agent host. Limited User Agents may not be able to preserve 1470 much of a log. 1472 Likewise, an attacker can mount a denial of service attack on an 1473 intermediary by asking the intermediary to explode a large list. 1475 The following security considerations apply when using IMDNs: 1477 14.1. Forgery 1479 IMs can be forged. To protect against that, an IM can be signed. An 1480 intermediary that receives a signed message and needs to modify any 1481 part of it that is included in the signature (like adding an 1482 Original-To header field to the CPIM header fields), MUST consume the 1483 IM and create a new copy of it that the intermediary signs itself. 1485 IMDNs may be forged as easily as ordinary IMs. Endpoints and 1486 intermediaries that wish to make automatic use of IMDNs should take 1487 appropriate precautions to minimize the potential damage from denial- 1488 of-service attacks. Security threats related to forged IMDNs include 1489 the sending of a falsified IMDN when the indicated disposition of the 1490 IM has not actually occurred. For example, display notification 1491 could be forged to indicate that an IM has been displayed to the 1492 Recipient. Unsolicited IMDNs is also another form of forgery. 1494 14.2. Confidentiality 1496 There may be cases where an IM Recipient does not wish to reveal the 1497 information that he has received or in fact read the IM. In this 1498 situation, it is acceptable for the IM Recipient to silently ignore 1499 requests for an IMDN. It is strongly RECOMMENDED that the IM 1500 Recipient obtain the user's consent before sending an IMDN. 1501 Circumstances where the IM Recipient does not ask for the user's 1502 consent include IM systems that, for regulatory reasons, are required 1503 to issue an IMDN, such as in the health care field or financial 1504 community. 1506 An IM Recipient can obtain such consent by a prompt or dialog box on 1507 a per-IM basis, globally through the user's setting of a preference, 1508 or other, user-configurable mechanism. The user might also indicate 1509 globally that IMDNs are never to be sent or that a "forbidden" IMDN 1510 status is always sent in response to a request for an IMDN. 1512 There are situations where a user sends an IM and requests IMDNs to a 1513 list whose member information is not disclosed. In this situation, 1514 the user will learn of the list members. Therefore, in this case, 1515 the URI-List server MUST remove any information about list members. 1516 If the number of members in the list is also not disclosed, the URL- 1517 List server MUST only deliver one aggregated IMDN. Alternatively, 1518 the URI-list server MAY reject the IM. 1520 It is possible for a list server to not understand IMDN. IM 1521 Recipients may note the To header field is a list name and not the IM 1522 Recipient's name. In this case, the IM Recipient can take the 1523 appropriate action if it wishes to keep its identity private. 1525 An unencrypted IMDN could reveal confidential information about an 1526 encrypted IM. The same level of security applied to an IM MUST be 1527 applied to its IMDNs. For example, if an IM is signed and encrypted, 1528 the IMDN must be signed and encrypted. 1530 14.3. IMDN as a Certified Delivery Service 1532 IMDNs cannot be relied on as a guarantee that an IM was or was not 1533 seen by the user. Even if IMDNs are not actively forged, they may be 1534 lost in transit. Moreover, the IM Recipient may bypass the IMDN 1535 issuing mechanism through policy or manipulation of their User Agent 1536 Server. 1538 15. IANA Considerations 1540 15.1. message/imdn+xml MIME TYPE 1542 This document registers a new MIME type "message/imdn+xml", and 1543 registers a new XML name space. 1545 This specification follows the guidelines of RFC 3023 [RFC3023]. 1547 MIME media type: message 1549 MIME subtype name: imdn+xml 1551 Mandatory parameters: none 1553 Optional parameters: Same as charset parameter application/xml as 1554 specified in RFC 3023 [RFC3023]. 1556 Encoding considerations: Same as encoding considerations of 1557 application/xml as specified in RFC 3023 [RFC3023]. 1559 Security considerations: See section 10 of RFC 3023 [RFC3023] and 1560 Section 14 of this document. 1562 Interoperability considerations: none. 1564 Published specification: This document. 1566 Applications which use this media type: This document type is used to 1567 support CPIM based instant messaging. 1569 Additional information: None 1571 Magic number: None 1573 File extension: .cl or .xml 1575 Macintosh file type code: "TEXT" 1577 Personal and email address for further information: Hisham Khartabil 1578 (hisham.khartabil@gmail.com) 1580 Intended Usage: COMMON 1582 Author/change controller: The IETF . 1584 15.2. XML Registration 1586 This section registers a new XML name space and schema, as per 1587 guidelines in the IETF XML Registry [IANA]. 1589 URI: The URI for this name space is urn:ietf:params:xml:ns:imdn. 1591 XML: The schema for this name space is in Section 11.1.9 above. 1593 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1594 (hisham.khartabil@gmail.com) . 1596 15.3. Registration for urn:ietf:params:imdn 1598 Registry name: imdn 1600 Specification: RFC XXXX. Additional values may be defined by a 1601 Standards Action [RFC2434] that updates or obsoletes RFC XXXX. 1603 Repository: [RFC EDITOR: fill in by IANA] 1605 Index value: The index value is a CPIM message IMDN header name, 1606 which may consist of a sequence from a restricted set of US-ASCII 1607 characters, as defined above. 1609 URN Formation: The URI for a header is formed from its name by: 1611 a) replacing any non-URN characters (as defined by RFC 2141[URN]) 1612 with the corresponding '%hh' escape sequence (per RFC 3986 1613 [RFC2396]); and 1614 b) prepending the resulting string with 'urn:ietf:params:imdn:'. 1616 Thus, the URI corresponding to the CPIM message IMDN header 1617 'Disposition-Notification:' would be 1618 'urn:ietf:params:imdn:Disposition-Notification'. 1620 Initial values; 1622 (preamble) 1624 +--------------------------+---------------------+ 1625 | Index Value | Reference | 1626 +--------------------------+---------------------+ 1627 | Disposition-Notification | RFCXXXX Section 6.2 | 1628 | Message-ID | RFCXXX Section 6.3 | 1629 | Original-To | RFCXXX Section 6.4 | 1630 | IMDN-Record-Route | RFCXXX Section 6.5 | 1631 | IMDN-Route | RFCXXX Section 6.6 | 1632 +--------------------------+---------------------+ 1634 (postamble) 1636 15.4. Content-Disposition: notification 1638 This document registers one new Content-Disposition header field 1639 "disposition-types": notification. The authors request that this 1640 value be recorded in the IANA registry for Mail Content Dispositions. 1642 Descriptions of this "disposition-types", including motivation and 1643 examples, are given in Section 7.2.1.1 and Section 9. 1645 Short descriptions suitable for the IANA registry are: 1647 notification the body of the message is a notification according to 1648 an earlier request for a disposition notification to an instant 1649 message 1651 16. Acknowledgements 1653 Special thanks to Jari Urpalainen for the thorough review and 1654 suggestions for the RelaxNG Schema. 1656 The authors would also like to thank Paul Kyzivat, Ben Campbell, Adam 1657 Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen, 1658 Miguel Garcia, Eric McMurry, Jon Peterson, and Robert Sparks for 1659 their comments and support. In addition, we would like to thank the 1660 Gen-Art reviewer extrodinaire, Spencer Dawkins. 1662 17. References 1664 17.1. Normative References 1666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1667 Requirement Levels", BCP 14, RFC 2119, March 1997. 1669 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1670 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1671 October 1998. 1673 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1674 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1676 [IANA] Mealling, M., "The IETF XML Registry", RFC 3688, 1677 January 2004. 1679 [URN] Moats, R., "The URN Syntax", RFC 2141, May 1997. 1681 [RFC3023] Murata, M., "XML Media Types", RFC 3023, March 1997. 1683 [XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second 1684 Edition)", W3C CR CR-xml11-20011006, October 2000. 1686 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1687 Resource Identifier (URI): Generic Syntax", STD 66, 1688 RFC 3986, January 2005. 1690 17.2. Informative References 1692 [RFC3261] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., 1693 Johnston, A., Peterson, J., Sparks, R., Handley, M., and 1694 E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1695 June 2002. 1697 [RFC3428] Campbell, B., "SIP Extension for Instant Messaging", 1698 RFC 3428, December 2002. 1700 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1701 April 2001. 1703 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1704 Notification", RFC 3798, May 2004. 1706 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1707 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1709 [URN_NS] Moats, R., "The URN Namespace for IETF Documents", 1710 RFC 2648, August 1999. 1712 [I-D.ietf-sip-uri-list-message] 1713 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 1714 MESSAGE Requests in the Session Initiation Protocol 1715 (SIP)", draft-ietf-sip-uri-list-message-03 (work in 1716 progress), December 2007. 1718 Authors' Addresses 1720 Eric Burger 1721 New Hampshire 1722 USA 1724 Phone: 1725 Fax: +1 603 457 5933 1726 Email: eburger@standardstrack.com 1728 Hisham Khartabil 1729 Ericsson Australia 1730 Melbourne 1731 Australia 1733 Phone: +61 416 108 890 1734 Email: hisham.khartabil@gmail.com 1736 Full Copyright Statement 1738 Copyright (C) The IETF Trust (2008). 1740 This document is subject to the rights, licenses and restrictions 1741 contained in BCP 78, and except as set forth therein, the authors 1742 retain all their rights. 1744 This document and the information contained herein are provided on an 1745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1752 Intellectual Property 1754 The IETF takes no position regarding the validity or scope of any 1755 Intellectual Property Rights or other rights that might be claimed to 1756 pertain to the implementation or use of the technology described in 1757 this document or the extent to which any license under such rights 1758 might or might not be available; nor does it represent that it has 1759 made any independent effort to identify any such rights. Information 1760 on the procedures with respect to rights in RFC documents can be 1761 found in BCP 78 and BCP 79. 1763 Copies of IPR disclosures made to the IETF Secretariat and any 1764 assurances of licenses to be made available, or the result of an 1765 attempt made to obtain a general license or permission for the use of 1766 such proprietary rights by implementers or users of this 1767 specification can be obtained from the IETF on-line IPR repository at 1768 http://www.ietf.org/ipr. 1770 The IETF invites any interested party to bring to its attention any 1771 copyrights, patents or patent applications, or other proprietary 1772 rights that may cover technology that may be required to implement 1773 this standard. Please address the information to the IETF at 1774 ietf-ipr@ietf.org.