idnits 2.17.1 draft-ietf-simple-imdn-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1686. 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 (April 2, 2008) is 5868 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) == Missing Reference: 'RFCXXXX' is mentioned on line 1555, but not defined ** 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE E. Burger 3 Internet-Draft BEA Systems, Inc. 4 Intended status: Standards Track H. Khartabil 5 Expires: October 4, 2008 April 2, 2008 7 Instant Message Disposition Notification 8 draft-ietf-simple-imdn-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 4, 2008. 35 Abstract 37 Instant Messaging (IM) refers to the transfer of messages between 38 users in real-time. This document provides a mechanism whereby 39 endpoints can request Instant Message Disposition Notifications 40 (IMDN), including delivery, processing, and read notifications, for 41 page-mode instant messages. 43 The Common Profile for Instant Messaging (CPIM) data format specified 44 in RFC 3862 is extended with new header fields that enable endpoints 45 to request IMDNs. A new message format is also defined to convey 46 IMDNs. 48 This document also describes how SIP entities behave using this 49 extension. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7 62 6.1. CPIM Header Field Namespace . . . . . . . . . . . . . . . 7 63 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 64 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 67 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 71 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 72 7.1.3. Keeping State . . . . . . . . . . . . . . . . . . . . 11 73 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12 74 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 76 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Constructing Processing Notifications . . . . . . . . . . 15 78 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 17 79 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 19 80 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19 81 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20 83 11.1.1. The Element . . . . . . . . . . . . . . . 21 84 11.1.2. The Element . . . . . . . . . . . . . . . . 21 85 11.1.3. The Element . . . . . . . . . . . . . 21 86 11.1.4. The Element . . . . . . . . . 21 87 11.1.5. The Element . . . . . . . . . . . . . . . . 21 88 11.1.6. The Element . . . . . . . . . . . . . . 21 89 11.1.7. The Element . . . . . . . . . . . . . . . . . 21 90 11.1.8. The Element . . . . . . . . . . . . . . . . . . 22 91 11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 22 92 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 22 93 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 26 94 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26 95 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26 96 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26 97 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26 98 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 99 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28 100 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 101 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 103 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 32 104 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 105 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32 106 15.2. URN Sub-Namespace Registration for 107 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 33 108 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33 109 15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 34 110 15.5. Message/CPIM Header Field Registration . . . . . . . . . . 34 111 15.6. Content-Disposition: notification . . . . . . . . . . . . 34 112 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 113 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 17.1. Normative References . . . . . . . . . . . . . . . . . . . 35 115 17.2. Informative References . . . . . . . . . . . . . . . . . . 35 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 117 Intellectual Property and Copyright Statements . . . . . . . . . . 37 119 1. Introduction 121 In many user-to-user message exchange systems, message senders often 122 wish to know if the human recipient actually received or read a 123 message. 125 Electronic Mail [RFC2821] deals with this situation with Message 126 Delivery Notifications [RFC3798]. After the recipient views the 127 message, her mail user agent generates a Message Delivery 128 Notification, or MDN. The MDN is an e-mail that follows the format 129 prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an 130 automaton can process the message. 132 The common presence and instant messaging (CPIM) format, Message/CPIM 133 [RFC3862], is a message format used to generate instant messages. 134 The session initiation protocol, SIP [RFC3261], can carry instant 135 messages generated using message/CPIM in SIP MESSAGE requests 136 [RFC3428]. 138 This document extends the Message/CPIM message format in much the 139 same way Message Delivery Notifications extends Electronic Mail. 140 This extension enables Instant Message Senders to request, create, 141 and send Instant Message Disposition Notifications (IMDN). This 142 mechanism works for page-mode as well as session mode instant 143 messages. This document only discusses page-mode. Session mode is 144 left for future standardisation efforts. 146 IMDNs include positive delivery, negative delivery (i.e., a message 147 did not get delivered successfully), read notifications (i.e., a 148 message was rendered) as well as processed notifications. By using 149 CPIM header fields, the IMDN request and delivery are abstracted 150 outside the transport protocol allowing interoperability between 151 different IM systems. 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, namely "delivery", "processing" and 194 "read" disposition types. 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, read, 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 that the recipient of an IMDN, in some instances, may not be the 229 IM 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 read. 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. Read 275 The read notification type indicates whether the IM Recipient 276 rendered the IM to the user or not. The read notification type can 277 have the following states: 278 o "read" is a state indicating that the IM has been rendered to the 279 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 "read" includes playing the audio or 286 video file to the user. 288 Since there is no positive acknowledgement from the user, one cannot 289 determine _a priori_ the user actually read the IM. Thus, one cannot 290 use the protocol described here as a non-repudiation service. 292 6. New CPIM Header Fields 294 This specification extends the CPIM data format specified in RFC 3862 295 [RFC3862]. A new name space is created as well as a number of new 296 CPIM header fields. 298 6.1. CPIM Header Field Namespace 300 Per CPIM [RFC3862], this specification defines a new name space for 301 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. When the IM Sender receives an IMDN, it can compare its value 329 with the value of the element present in the IMDN 330 payload. IMDNs also carry this header field. Note that since the 331 IMDN is itself an IM, the Message-ID of the IMDN will be different 332 than the Message-ID of the original IM. Section 10 defines the 333 syntax. 335 6.4. Original-To 337 An intermediary MAY insert an Original-To header field to the IM. 338 The value of the Original-To field MUST be the address of the IM 339 Receiver. The IM Recipient uses this header to indicate the original 340 IM address in the IMDNs. The IM Recipient does this by populating 341 the element in the IMDN. The intermediary 342 MUST insert this header if the intermediary changes the CPIM To 343 header field value. The header field MUST NOT appear more than once 344 in an IM. The intermediary MUST NOT change this header field value 345 if it is already present. Section 10 defines the syntax. 347 6.5. IMDN-Record-Route 349 An intermediary MAY insert an IMDN-Record-Route header field to the 350 IM. The value of the IMDN-Record-Route header field MUST be the 351 address of the intermediary. Multiple IMDN-Record-Route header 352 fields can appear in an IM. Section 10 defines the syntax. 354 6.6. IMDN-Route 356 The IMDN-Route header field provides routing information by including 357 one or more addresses where to route the IMDN. An intermediary that 358 needs the IMDN to flow back through the same intermediary MUST add 359 the IMDN-Record-Route header. When the IM Recipient creates the 360 corresponding IMDN, the IM Recipient copies the IMDN-Record-Route 361 headers into corresponding IMDN-Route header fields. Section 10 362 defines the syntax. 364 7. Endpoint Behaviour 366 7.1. IM Sender 368 7.1.1. Constructing Instant Messages 370 An IM is constructed using CPIM Message Format defined in RFC 3862 371 [RFC3862]. 373 7.1.1.1. Adding a Message-ID Header Field 375 If the IM sender requests the reception of IMDNs, the IM sender MUST 376 include a Message-ID header field. The Message-ID field is populated 377 with a value that is unique with at least 32 bits of randomness. 378 This header field enables the IM Sender to match any IMDNs with their 379 corresponding IMs. 381 7.1.1.2. Adding a DateTime Header Field 383 Some devices are not able to retain state over long periods. For 384 example, mobile devices may have memory limits or battery limits. 385 These limits may mean these devices may not be able to, or may chose 386 not to, keep sent messages for the purposes of correlating IMDNs with 387 sent IMs. To make some use of IMDN in this case, we add a time stamp 388 to the IM to indicate when the user sent the message. The IMDN 389 returns this time stamp to enable the user to correlate the IM with 390 the IMDN at the human level. We use the DateTime CPIM header field 391 for this purpose. Thus, if the IM Sender would like an IMDN, the IM 392 Sender MUST include the DateTime CPIM header field. 394 7.1.1.3. Adding a Disposition-Notification Header Field 396 The Disposition-Notification conveys the type of disposition 397 notification requested by the IM sender. There are three types of 398 disposition notification: delivery, processing, and read. The 399 delivery notification is further subdivided into failure and success 400 delivery notifications. An IM Sender requests failure delivery 401 notification by including a Disposition-Notification header field 402 with value "negative-delivery". Similarly, a success notification is 403 requested by including a Disposition-Notification header field with 404 value "positive-delivery". The IM Send can request both types of 405 delivery notifications for the same IM. 407 The IM Sender can request a processing notification by including a 408 Disposition-Notification header field with value "processing". 410 The IM Sender can also request a read notification. The IM Sender 411 MUST include a Disposition-Notification header field with the value 412 "read" to request a read request. 414 The absence of this header field or the presence of the header field 415 with an empty value indicates that the IM Sender is not requesting 416 any IMDNs. Disposition-Notification header field values are comma 417 separated. The IM Sender MAY request more than one type of IMDN for 418 a single IM. 420 Future extensions may define other disposition notifications not 421 defined in this document. 423 Section 10 describes the formal syntax for the Disposition- 424 Notification header field. The following is an example CPIM body of 425 an IM where the IM Sender requests positive and negative delivery 426 notifications, but neither read notification nor processing 427 notifications: 429 From: Alice 430 To: Bob 431 NS: imdn 432 imdn.Message-ID: 34jk324j 433 DateTime: 2006-04-04T12:16:49-05:00 434 imdn.Disposition-Notification: positive-delivery, negative-delivery 435 Content-type: text/plain 436 Content-length: 12 438 Hello World 440 7.1.2. Matching IMs with IMDNs 442 An IM Sender matches an IMDN to an IM by matching the Message-ID 443 header field value in the IM with the element value in 444 the body of the IMDN. If the IM was delivered to multiple 445 recipients, the IM Sender uses the element and the 446 element in the XML body of the IMDN it 447 received to determine if the IM was sent to multiple recipients and 448 to identify the IM Recipient that sent the IMDN. 450 An IM Sender can determine an IMDN is a disposition notification by 451 noting the Content-Disposition in the IMDN is "notification". This 452 does mean the IM Sender MUST understand the Content-Disposition MIME 453 header in CPIM messages. 455 7.1.3. Keeping State 457 This specification does not mandate the IM Sender to keep state for a 458 sent IM. 460 Once an IM Sender sends an IM containing an IMDN request, it MAY 461 preserve the IM context, principally the Message-ID, and other user- 462 identifiable information such as the IM subject or content, and date 463 and time it was sent. Without preservation of the IM context, the IM 464 Sender will not be able to correlate the IMDN with the IM it sent. 465 The IM Sender may find it impossible to preserve IM state if it has 466 limited resources or does not have non-volatile memory and then loses 467 power. 469 There is, however, the concept of "Sent Items" box in an application 470 that stores sent IMs. This "Sent Items" box has the necessary 471 information and may have a fancy user interface indicating the state 472 of a sent IM. A unique Message-ID for this purpose proves to be 473 useful. The length of time for items to remain in the "Sent Items" 474 box is a user choice. The user is usually free to keep or delete 475 items from the "Sent Items" box as she pleases or as the memory on 476 the device reaches capacity. 478 Clearly, if an IM Sender loses its sent items state, for example, the 479 user deletes items from the "Send Items" box, the client may use a 480 different display strategy in response to apparently unsolicited 481 IMDNs. 483 This specification also does not mandate an IM Sender to run any 484 timers waiting for an IMDN. There are no time limits associated with 485 when IMDNs may be received. 487 IMDNs may legitimately never be received. Likewise, the recipient 488 may take a long time to actually read the message, so the time 489 between the sending of an IM and the generation and ultimate receipt 490 of the IMDN may simply take a very long time. Some clients may 491 choose to purge the state associated with the sent IM. This is the 492 reason for adding the time stamp in the IM and having it returned in 493 the IMDN. This gives the user some opportunity of remembering what 494 IM was sent. For example if the IMDN indicates that the IM the user 495 sent at 2 p.m. last Thursday was delivered, the user has a chance of 496 remembering that they sent an IM at 2 p.m. last Thursday. 498 7.1.4. Aggregation of IMDNs 500 An IM Sender may send an IM to multiple recipients in one Transport 501 Protocol Message (typically using a URI-List server 502 [I-D.ietf-sip-uri-list-message]) and request IMDNs. An IM Sender 503 that requested IMDNs MUST be prepared to receive multiple aggregated 504 or non-aggregated IMDNs. See Section 8.2 for details. 506 7.2. IM Recipient 508 7.2.1. Constructing IMDNs 510 IM recipients examine the contents of the Disposition-Notification 511 header field of the CPIM message to determine if the recipient needs 512 to generate an IMDN for that IM. Disposition-Notification header 513 fields of CPIM messages can include one or more values. IM 514 recipients may need to generate zero, one, or more IMDNs for that IM, 515 for example a delivery notification as well as a read notification. 516 In this case, the IM Recipient MUST be able to construct multiple 517 IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN 518 per disposition type. That is, it must not generate a delivery 519 notification indicating "delivered" then followed by a delivery 520 notification indicating "failed" for the same IM. If the IM Sender 521 requested only failure notifications and the IM was successfully 522 delivered, then no IMDNs will be generated. If the IM recipient does 523 not understand a value of the Disposition-Notification header field, 524 the IM recipient ignores that value. 526 The IM Recipient MUST NOT generate "processing" notifications. 528 A Disposition-Notification header field MUST NOT appear in an IMDN 529 since it is forbidden to request an IMDN for an IMDN. An IM Sender 530 MUST ignore a delivery notification request in an IMDN if present. 531 The IM Sender MUST NOT send an IMDN for an IMDN. 533 An IMDN MUST contain a Message-ID header field. The same rules of 534 uniqueness for the Message-ID header field that appears in an IM 535 apply to an IMDN. The Message-ID header field in the IMDN is 536 different and unrelated to the one in the IM. 538 An IM may contain an IMDN-Record-Route header field (see Section 8 539 for details). If IMDN-Record-Route header fields appear in the IM, 540 the IM Recipient constructing the IMDN MUST copy the contents of the 541 IMDN-Record-Route header fields into IMDN-Route header fields in the 542 IMDN and maintain the order. The IMDN is then sent to the URI in the 543 top IMDN-Route header field. IMDN-Record-Route header fields do not 544 make sense in an IMDN and therefore MUST NOT be placed in an IMDN. 545 IMDN Recipients MUST ignore it if present. 547 As stated in CPIM [RFC3862], CPIM messages may need to support MIME 548 headers other than Content-type. IM Recipients MUST insert a 549 Content-Disposition header field, set to the value "notification". 550 This indicates to the IM Sender that the message is an IMDN to an IM 551 it has earlier sent. 553 7.2.1.1. Constructing Delivery Notifications 555 The IM Recipient constructs a delivery notification in a similar 556 fashion as an IM, using a CPIM body [RFC3862] that carries a 557 Disposition Notification XML document formatted according to the 558 rules specified in Section 11. The MIME type of the Disposition 559 Notification XML document is "message/imdn+xml". 561 Section 10 defines the schema for an IMDN. 563 An example CPIM body of IMDN looks like the following: 565 From: Bob 566 To: Alice 567 NS: imdn 568 imdn.Message-ID: d834jied93rf 569 Content-type: message/imdn+xml 570 Content-Disposition: notification 571 Content-length: ... 573 574 575 34jk324j 576 2006-04-04T12:16:49-05:00 577 im:bob@example.com 578 579 im:bob@example.com 580 581 582 583 584 585 586 587 The IM was successfully Delivered 588 590 7.2.1.2. Constructing Read Notifications 592 The IM Recipient constructs a read notification in a similar fashion 593 as the delivery notification. See Section 7.2.1.1 for details. 595 Section 10 defines the schema for an IMDN. 597 An example looks like the following: 599 From: Bob 600 To: Alice 601 NS: imdn 602 imdn.Message-ID: dfjkleriou432333 603 Content-type: message/imdn+xml 604 Content-Disposition: notification 605 Content-length: ... 607 608 609 34jk324j 610 2006-04-04T12:16:49-05:00 611 im:bob@example.com 612 613 im:bob@example.com 614 615 616 617 618 619 620 621 The IM has been read 622 624 There are situations where the IM Recipient cannot determine if or 625 when the IM has been read. The IM Recipient in this case generates a 626 read notification with a value of "error" to indicate an 627 internal error by the server. Note that the IM Recipient may choose 628 to ignore any IMDN requests and not to send any IMDNs. An IM 629 recipient may not wish to let a sender know she read, or did not 630 read, a particular message. Likewise, she may not want anyone to 631 know if she reads messages. This could be on a per-message, per- 632 sender, or programmed policy choice. 634 8. Intermediary Behaviour 636 In this context, intermediaries are application servers (including 637 URI-List servers and Store-and-Forward server) and gateways. A 638 gateway is a server that translates between different IM systems that 639 use different protocols. 641 A URI-List server may change the IM Recipient address from its own to 642 the address of the final recipient of that IM for every copy it makes 643 that it sends to the list members (see 644 [I-D.ietf-sip-uri-list-message] for details). In this case, if the 645 IM Sender is requesting an IMDN, the intermediary SHOULD add an 646 Original-To header field to the IM populating it with the address 647 that was in the CPIM To header field before it was changed. That is, 648 the intermediary populates the Original-To header field with the 649 intermediary address. Of course, one may configure an intermediary 650 to restrict it from re-writing or populating the Original-To field. 651 An intermediary MUST NOT add an Original-To header field if one 652 already exists. An intermediary MAY have an administrative 653 configuration to not reveal the original Request-URI, and as such, 654 MUST NOT add an Original-To header. 656 An intermediary MAY choose to remain on the path of IMDNs for a 657 specific IM. It can do so by adding a CPIM IMDN-Record-Route header 658 field as the top IMDN-Record-Route header field and populating it 659 with its own address. An intermediary that does not support this 660 extension will obviously not add the IMDN-Record-Route header field. 661 This allows IMDNs to traverse directly from the IM Recipient to the 662 IM Sender even if the IM traversed an intermediary not supporting 663 this extension. 665 An intermediary receiving an IMDN checks the top IMDN-Route header 666 field. If that header field carries the intermediary address, the 667 intermediary removes that value and forwards the IMDN to the address 668 indicated in the now top IMDN-Route header field. If no additional 669 IMDN-Route header fields are present, the IMDN is forwarded to the 670 address in the CPIM To header field. 672 An intermediary MUST remove any information about the final 673 recipients of a list if the list membership is not disclosed. The 674 intermediary does that by removing the element and/or 675 element from the body of the IMDN before 676 forwarding it to the IM Sender. 678 8.1. Constructing Processing Notifications 680 Intermediaries are the only entities that construct processing 681 notifications. They do so only if the IM Sender has requested a 682 "processing" notification by including a Disposition-Notification 683 header field with value "processing". 685 The intermediary can create and send "processing" notifications 686 indicating that an IM has been processed or stored. The intermediary 687 MUST NOT send more than one IMDN for the same disposition type. 688 I.e., it must not send a "processing" notification indicating that an 689 IM is being "processed" followed by another IMDN indicating that the 690 same IM is "stored". 692 An intermediary constructs a "processing" notification in a similar 693 fashion as the delivery notification. See Section 7.2.1.1 for 694 details. 696 An example looks like the following: 698 Content-type: Message/CPIM 700 From: Bob 701 To: Alice 702 Content-type: message/imdn+xml 703 Content-Disposition: notification 704 Content-length: ... 706 707 34jk324j 708 2006-04-04T12:16:49-05:00 709 im:bob@example.com 710 711 im:bob@example.com 712 713 714 715 716 717 718 719 The IM has been processed 720 722 There are situations where the intermediary cannot know the fate of 723 an IM. The intermediary in this case generates a processing 724 notification with a value of "error" to indicate so. 726 8.2. Aggregation of IMDNs 728 As previously described, URI-List servers are intermediaries. 730 A URI-List server may choose to aggregate IMDNs using local policy 731 for making such a decision or it may send individual IMDNs instead. 732 When a URI-List server receives an IM and decides to aggregate IMDNs, 733 it can wait for a configurable period of time or until all recipients 734 have sent the IMDN, whichever comes first, before the URI-List server 735 sends an aggregated IMDN. Note that some IMDNs, for example "read" 736 notifications, may never come due to user settings. It is an 737 administrator configuration and an implementation issue how long to 738 wait before sending an aggregated IMDN and before a URI-List server 739 removes state for that IM. 741 A URI-List server MAY choose to send multiple aggregated IMDNs. A 742 timer can be started and when it fires, the URI-List server can 743 aggregate whatever IMDNs it has so far for that IM, send the 744 aggregated IMDN and restart the timer for the next batch. This is 745 needed for scenarios where the IM Sender has requested more than one 746 IMDN for a specific IM, for example, delivery notifications as well 747 as read notifications, or when the URI-List server is short on 748 resources and chooses to prioritise forwarding IMs over IMDNs. 750 A second timer can be running and when it fires, the state of the IM 751 is deleted. In this case, the URI-List server consumes any IMDNs 752 that might arrive after that time. 754 Please note the references to timers in the above paragraphs are not 755 normative and are only present to help describe one way one might 756 implement aggregation. 758 A URI-List server MAY aggregate IMDNs for the case where the list 759 membership information is not disclosed. There may be scenarios 760 where the URI-List server starts sending aggregated IMDNs and switch 761 to individual ones or visa versa. A timer firing so often may in 762 fact have that effect. 764 The aggregated IMDN is constructed using the multipart/mixed MIME 765 type and including all the received IMDNs as message/imdn+xml as 766 individual payloads. 768 Below is an example of aggregated IMDNs. 770 From: Bob 771 To: Alice 772 NS: imdn 773 imdn.Message-ID: d834jied93rf 774 Content-type: multipart/mixed; 775 boundary="imdn-boundary" 776 Content-Disposition: notification 777 Content-length: ... 779 --imdn-boundary 780 Content-type: message/imdn+xml 782 783 784 34jk324j 785 2006-04-04T12:16:49-05:00 786 im:bob@example.com 787 788 im:bob@example.com 789 790 791 792 793 794 795 796 The IM was successfully Delivered 797 799 --imdn-boundary 800 Content-type: message/imdn+xml 802 803 804 34jk324j 805 2006-04-04T12:16:49-05:00 806 im:bob@example.com 807 808 im:bob@example.com 809 810 811 812 813 814 815 816 The IM was successfully Delivered 817 819 --imdn-boundary 821 9. Identifying Messages 823 Messages are typically carried in a transport protocol like SIP 824 [RFC3261]. If the payload carried by the transport protocol does not 825 contain any parts of type Message/CPIM then the message is an IM. If 826 the payload contains any parts of type Message/CPIM, and none of 827 those parts contains a payload that is of type "message/imdn+xml", 828 the message is an IM. It is not valid to attempt to carry both an IM 829 and an IMDN in a multipart payload in a single transport protocol 830 message. 832 A message is identified as a delivery notification by examining its 833 contents. The message is a delivery notification if the Content-type 834 header field present has a value of "message/imdn+xml", the Content- 835 Disposition header field has a value of "notification", and the 836 element in that xml body has a sub-element . 838 A message is identified as a processing notification or read 839 notification in a similar fashion as a delivery notification. The 840 difference is that the element in that xml body has a 841 sub-element of and respectively. 843 10. Header Fields Formal Syntax 845 The following syntax specification uses the message header field 846 syntax as described in Section 3 of RFC 3862 [RFC3862]. 848 Header field syntax is described without a name space qualification. 849 Following the rules in RFC 3862 [RFC3862], header field names and 850 other text are case sensitive and MUST be used as given, using 851 exactly the indicated upper case and lower case letters. 853 Disposition-Notification = 854 "Disposition-Notification" ": " 855 [(notify-req *(COMMA notify-req))] 857 notify-req = 858 ("negative-delivery" / "positive-delivery" / 859 "processing" / "read" / Token) *(SEMI disp-notif-params) 861 disp-notify-params = generic-param 863 Message-ID = "Message-ID" ": " Token 865 Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" 867 IMDN-Record-Route = 868 "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" 870 IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 872 11. IMDN Format 874 11.1. Structure of XML-Encoded IMDN Payload 876 An IMDN Payload is an XML document [XML] that MUST be well formed and 877 MUST be valid according to schemas, including extension schemas, 878 available to the validater and applicable to the XML document. The 879 IMDN Payload MUST be based on XML 1.0 and MUST be encoded using 880 UTF-8. 882 The name space identifier for elements defined by this specification 883 is a URN [URN], using the name space identifier 'ietf' defined by 884 [URN_NS] and extended by [IANA]. This urn is: 885 urn:ietf:params:xml:ns:imdn. 887 This name space declaration indicates the name space on which the 888 IMDN is based. 890 The root element is . The element has sub-elements, 891 namely , , , , , , , and . 893 Those elements are described in details in the following sections. 895 and can be extended in the future to include 896 new sub-elements not defined in this document, as described in 897 Section 15.3. 899 11.1.1. The Element 901 The element is mandatory according to the XML schema and 902 carries the message id that appeared in the Message-ID header field 903 of the IM. 905 11.1.2. The Element 907 The element is mandatory and carries the date and time the 908 IM was sent (not the IMDN). This information is obtained from the 909 DateTime header field of the IM. 911 11.1.3. The Element 913 The element is optional and carries the URI of the 914 final recipient. This information is obtained from the CPIM To 915 header field of the IM. 917 11.1.4. The Element 919 The element is optional and carries the URI 920 of the original recipient. It MUST be present if the IM carried the 921 Original-To header field. This information is obtained from the 922 Original-To header field of the IM. 924 11.1.5. The Element 926 The element is optional and carries the text that was in 927 the Subject header field, if any. This allows for a human level 928 correlation between an IM and an IMDN. 930 11.1.6. The Element 932 The element is mandatory and carries the disposition 933 type that the IM Sender requested and is being reported. It can 934 carry one of the sub-elements , , or any 935 other future extension. 937 11.1.7. The Element 939 The element is mandatory and carries the result of the 940 disposition request in the element. For disposition 941 type , it can carry one of the sub-elements , 942 , or . For disposition type , it 943 can carry one of the sub-elements , or . 944 For disposition type , it can carry one of the sub- 945 elements , , or . 946 means the disposition was denied. means internal server 947 error. It can also carry any other future extension. 949 11.1.8. The Element 951 The element is optional and carries a human readable text. It 952 has the "lang" attribute that indicates the language the text is 953 written in. 955 11.2. MIME Type for IMDN Payload 957 The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN 958 MUST identify the payload as MIME type "message/imdn+xml" in the 959 Content-type header field. 961 11.3. The RelaxNG Schema 962 963 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 996 997 998 999 1000 1001 1002 1003 1004 1005 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1093 1094 1095 1097 1098 1099 1100 1101 1102 lang 1103 1104 1105 1106 1107 1108 1109 1111 1112 1113 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1136 1138 12. Transporting Messages using SIP 1140 12.1. Endpoint Behaviour 1142 12.1.1. Sending Requests 1144 The IM Sender constructs a SIP MESSAGE request using RFC 3428 1145 [RFC3428]. The Content-type header field indicates the MIME type of 1146 the request payload. When using this extension, the Content-type 1147 header field MUST be of MIME type "message/cpim" [RFC3862] for both 1148 IMs and IMDNs. The IM Sender constructs the payload according to 1149 Section 7. 1151 The IM Sender constructs a SIP MESSAGE request to multiple recipients 1152 in a similar manner as a SIP MESSAGE request to a single recipient. 1153 Multiple-Recipient MESSAGE Requests in SIP 1154 [I-D.ietf-sip-uri-list-message] describes the differences. 1156 IM senders can remain anonymous. For example, the sender can set the 1157 SIP From header field of the SIP message to an anonymous URI. As 1158 there is no return address, anonymous IM senders SHOULD NOT request 1159 disposition notifications. An IM Recipient can ignore such request 1160 if the IM Sender is anonymous. 1162 12.1.2. Sending Responses 1164 An endpoint receiving a SIP MESSAGE request constructs a SIP response 1165 according to RFC 3428 [RFC3428]. Of course, an endpoint will send a 1166 SIP response to the MESSAGE request regardless of the type of message 1167 (IM or IMDN) is has received, or the disposition type it has been 1168 asked for. 1170 12.1.3. Receiving Requests 1172 12.1.3.1. Instant Message 1174 A SIP MESSAGE request is identified as an IM by examining its 1175 contents according to Section 9. 1177 If an IM Recipient received a SIP MESSAGE request that is an IM that 1178 requested a positive-delivery notification, and that IM Recipient has 1179 constructed and sent a SIP 2xx class response, it MAY generate a 1180 positive-delivery notification after making sure that the IM has been 1181 delivered to the user or application. A gateway, for example, can 1182 generate a 2xx response before the final recipient received the IM. 1183 The IM Recipient constructs a positive-delivery notification 1184 according to Section 7.2.1.1. The IM Recipient places the message as 1185 the payload in a SIP MESSAGE request. 1187 If an IM Recipient received a SIP MESSAGE request that is an IM that 1188 requested a negative-delivery, and that IM Recipient has constructed 1189 and sent a 2xx class response, it SHOULD generate a negative-delivery 1190 notification if it learnt that the final recipient or application did 1191 not receive the IM (a gateway, for example, can generate a 2xx 1192 response before it has an error response from downstream or before 1193 any internal timers fire waiting for a response). The negative- 1194 delivery notification is constructed according to Section 7.2.1.1. 1195 The message is then placed as the payload in a SIP MESSAGE request. 1197 If an IM Recipient received a SIP MESSAGE request that is an IM that 1198 requested a negative-delivery notification, and the IM Recipient has 1199 constructed and sent an non-2xx final response, it MUST NOT generate 1200 a negative-delivery notification. 1202 If an IM Recipient received a SIP MESSAGE request that is an IM that 1203 requested a read notification, and that IM Recipient has constructed 1204 and sent a SIP 2xx class response, it MAY generate a read 1205 notification after making sure that the IM has been presented to the 1206 user or application. It is outside the scope of this document how 1207 such determination can be made. Note that the option to send a read 1208 notification or not can be left to the user. An application may 1209 allow a user to configure such choice. The IM Recipient constructs 1210 the read notification according to Section 7.2.1.2. The IM Recipient 1211 places the message as the payload in a SIP MESSAGE request. 1213 For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP 1214 To header field using the address that appeared in the SIP From 1215 header field in the IM. 1217 12.1.3.2. Delivery Notification 1219 A SIP MESSAGE request is identified as delivery notification by 1220 examining its contents according to Section 9. 1222 12.1.3.3. Read Notification 1224 A SIP MESSAGE request is identified as read notification by examining 1225 its contents according to Section 9. 1227 12.2. Intermediary Behaviour 1229 In this context, intermediaries include application servers, 1230 including URI-List servers, Store-and-Forward servers, and gateways. 1231 SIP Proxies MUST NOT generate IMDNs but MUST forward them like any 1232 other SIP request. 1234 Intermediaries forward a SIP MESSAGE request to multiple recipients 1235 according to [I-D.ietf-sip-uri-list-message]. 1237 If an intermediary receives an IM, the intermediary examines the 1238 body. If the body is of type "message/cpim" the intermediary then 1239 looks for a Disposition-Notification CPIM header field in the 1240 message. If the Disposition-Notification CPIM header field has 1241 either the value "positive-delivery" or "negative-delivery", and, in 1242 processing the IM, the intermediary generates a SIP 2xx class 1243 response to the MESSAGE request, then the intermediary performs the 1244 following actions. 1246 If the Disposition-Notification header field contains a value of 1247 "positive-delivery", the intermediary MUST NOT generate a delivery 1248 notification if it receives a SIP 2xx class response for the sent IM. 1249 Just because a downstream entity received a MESSAGE request does not 1250 mean the message was relayed to its ultimate destination or was 1251 delivered. Thus, the intermediary cannot say delivery occurred just 1252 because it received a 2xx response. 1254 If the Disposition-Notification header field contains a value of 1255 "negative-delivery", the intermediary SHOULD generate a delivery 1256 notification if it receives a SIP 4xx, 5xx or 6xx class final 1257 response for the sent IM. If it has received a SIP 2xx class 1258 response followed by a negative-delivery notification, the 1259 intermediary forwards that negative-delivery notification or 1260 aggregates it. 1262 If the Disposition-Notification header field contains a value of 1263 "processing", the intermediary MAY generate a processing notification 1264 after it has forwarded or stored the IM. The rest of the procedures 1265 in Section 8.1 apply. 1267 The procedure for generating such IMDN is the same as that of an IM 1268 Recipient (Section 7.2.1.1). 1270 The element of the XML body is populated with the URI 1271 of the IM Recipient. 1273 If an intermediary receives a SIP MESSAGE request carrying a positive 1274 delivery notification or a read notification, it forwards it using 1275 the rules in Section 8. 1277 13. Transporting Messages using MSRP 1279 MSRP already provides a built-in mechanism to supply positive and 1280 negative delivery reports. These reports do not provide built-in 1281 Read or Processing notifications. However, these notifications in 1282 session mode are not as useful as they are for page-mode. This is 1283 because the base use case for MSRP is that the recipient user agent 1284 immediately renders SEND requests sequentially, providing the session 1285 experience. This is unlike page-mode requests where a user has to 1286 actively read the message. That is, they need to click on a button, 1287 open a message, and so on to read the message. 1289 If new requirements arise in the future determining the need for IMDN 1290 in MSRP, new specifications can be drafted. 1292 14. Security Considerations 1294 IMDNs provide a fine-grained view of the activity of the IM Recipient 1295 and thus deserves particularly careful confidentiality protection so 1296 that only the intended recipient of the IMDN will receive the IMDN. 1297 In most cases, the intended recipient of the IMDN is the IM Sender. 1299 Since the IM transport protocol carries the IMDN, all security 1300 considerations of the underlying IM protocol also apply to the IMDNs. 1302 The threats in the IMDN system, over and beyond the threats inherent 1303 to IM include the following: 1304 o A malicious endpoint attempts to send messages to a user that 1305 would normally not wish to receive messages from that endpoint by 1306 convincing the IMDN system to "bounce" an IMDN from an 1307 unsuspecting endpoint to the user. 1308 o A malicious endpoint attempts to flood an IM Sender with IMDNs by 1309 convincing a URI-List server to send IMDNs to an unsuspecting IM 1310 Sender. 1311 o A malicious node in the network that attempts to modify an IMDN 1312 from an IM Recipient. 1313 o A malicious intermediary attempts to forward an IMDN from an IM 1314 Recipient to the IM Sender, where the IM Recipient would not 1315 normally forward the IMDN to that IM Sender if the IM Recipient 1316 knew the identity of the IM Sender. 1317 o A malicious endpoint that attempts to discover for a Request-URI 1318 of an endpoint beyond an intermediary, where the endpoint would 1319 normally wish to keep its identity private from the malicious 1320 endpoint. 1321 o A malicious node in the network that attempts to eavesdrop on IMDN 1322 traffic to, for example, learn Request-URI or traffic pattern 1323 information. 1324 o A malicious node in the network attempts to stage a denial of 1325 service attack on an intermediary by requesting a large list 1326 expansion. 1328 The protocol cannot protect against attacks that include the 1329 following: 1330 o A malicious intermediary directly revealing the identity of a 1331 downstream endpoint that would not normally wish its identity 1332 revealed. Keeping such information private is an intermediary 1333 implementation issue. 1334 o A malicious IM Recipient that alters the time of the IMDN. There 1335 is no protocol mechanism for ensuring that the IM Recipient does 1336 not lie about the time or purposely holds an IMDN for transmission 1337 to make it appear that the user read an IM later than they 1338 actually did. 1339 o A deletion attack on an IMDN. This is a trade-off between privacy 1340 and security. The privacy considerations allow the IM Recipient 1341 to silently ignore an IMDN request. Any mechanism that would 1342 reliably indicate that a malicious node deleted an IM Recipient's 1343 IMDN would also serve the purpose of detecting an IM Recipient 1344 that chose not to issue an IMDN. 1346 To combat eavesdropping, modification, and man-in-the-middle attacks, 1347 we require some level of authentication and integrity protections. 1348 That said, there are circumstances where strong integrity would be 1349 overkill. The presumption is the IM Sender has and sets the 1350 expectation for the level of protection. The procedures for 1351 integrity protection are as follows. 1352 o If the IM Recipient has a certificate, it MUST sign the IMDN. 1353 Signing the IMDN provides integrity protection. While an 1354 intermediary can replace the IMDN body, the IM Sender (the 1355 recipient of the IMDN) can validate the signature and note the 1356 IMDN does not come directly from the IM Receiver. This is not a 1357 problem if the IM Sender trusts the intermediary. Likewise, an 1358 IMDN in response to a signed IM without a signature indicates 1359 something bad might have happened. 1360 o If the IM is encrypted, the IM Recipient or intermediary MUST 1361 encrypt the IMDN body, as an attacker may attempt to discern the 1362 user's activity profile and identity from sniffing IMDNs on the 1363 network. 1364 o The two above rules are cumulative. 1365 The IM Recipient or intermediary MUST be capable of accessing the IM 1366 Sender's public certificate in order to verify the signature in the 1367 IM. 1369 CPIM security considerations [RFC3862] apply here, as this is an 1370 extension of CPIM. In order to make the IMDN mechanism independent 1371 of the transport protocol, the Work Group made the design choice of 1372 putting routing information into the IMDN application layer payload. 1373 One consequence of this choice is it eliminates the possibility of 1374 having end-to-end encryption. 1376 An attacker can mount a distributed denial of service attack on a 1377 node by sending lots of IMs to the node with IMDN requests. Note 1378 that this is the same problem as there is without IMDN; IMDN simply 1379 linearly increases the load on the node under attack. One can 1380 mitigate, but not eliminate this threat by the endpoint immediately 1381 ignoring requests that are not authenticated. 1383 Likewise, an attacker can mount a denial of service attack on an 1384 intermediary by asking the intermediary to explode a large list. 1386 The following security considerations apply when using IMDNs: 1388 14.1. Forgery 1390 IMs can be forged. To protect against that, an IM can be signed. An 1391 intermediary that receives a signed message and needs to modify any 1392 part of it that is included in the signature (like adding an 1393 Original-To header field to the CPIM header fields), MUST consume the 1394 IM and create a new copy of it that the intermediary signs itself. 1396 IMDNs may be forged as easily as ordinary IMs. Endpoints and 1397 intermediaries that wish to make automatic use of IMDNs should take 1398 appropriate precautions to minimize the potential damage from denial- 1399 of-service attacks. Security threats related to forged IMDNs include 1400 the sending of a falsified IMDN when the indicated disposition of the 1401 IM has not actually occurred. For example, read notification could 1402 be forged to indicate that an IM Recipient has read the IM. 1403 Unsolicited IMDNs is also another form of forgery. 1405 14.2. Confidentiality 1407 There may be cases where an IM Recipient does not wish to reveal the 1408 information that he has received or in fact read the IM. In this 1409 situation, it is acceptable for the IM Recipient to silently ignore 1410 requests for an IMDN. It is strongly RECOMMENDED that the IM 1411 Recipient obtain the user's consent before sending an IMDN. 1412 Circumstances where the IM Recipient does not ask for the user's 1413 consent include IM systems that, for regulatory reasons, are required 1414 to issue an IMDN, such as in the health care field or financial 1415 community. 1417 An IM Recipient can obtain such consent by a prompt or dialog box on 1418 a per-IM basis, globally through the user's setting of a preference, 1419 or other, user-configurable mechanism. The user might also indicate 1420 globally that IMDNs are never to be sent or that a "forbidden" IMDN 1421 status is always sent in response to a request for an IMDN. 1423 There are situations where a user sends an IM and requests IMDNs to a 1424 list whose member information is not disclosed. In this situation, 1425 the user will learn of the list members. Therefore, in this case, 1426 the URI-List server MUST remove any information about list members. 1427 If the number of members in the list is also not disclosed, the URL- 1428 List server MUST only deliver one aggregated IMDN. Alternatively, 1429 the URI-list server MAY reject the IM. 1431 It is possible for a list server to not understand IMDN. IM 1432 Recipients may note the To is a list name and not the IM Recipient's 1433 name. In this case, the IM Recipient can take the appropriate action 1434 if it wishes to keep its identity private. 1436 An unencrypted IMDN could reveal confidential information about an 1437 encrypted IM. The same level of security applied to an IM MUST be 1438 applied to its IMDNs. For example, if an IM is signed and encrypted, 1439 the IMDN must be signed and encrypted. 1441 14.3. Non-Repudiation 1443 IMDNs cannot be relied on as a guarantee that an IM was or was not 1444 seen by the user. Even if IMDNs are not actively forged, they may be 1445 lost in transit. Moreover, the IM Recipient may bypass the IMDN 1446 issuing mechanism through policy or manipulation of their User Agent 1447 Server. 1449 15. IANA Considerations 1451 15.1. message/imdn+xml MIME TYPE 1453 This document registers a new MIME type "message/imdn+xml", and 1454 registers a new XML name space. 1456 This specification follows the guidelines of RFC 3023 [RFC3023]. 1458 MIME media type: message 1460 MIME subtype name: imdn+xml 1462 Mandatory parameters: none 1464 Optional parameters: Same as charset parameter application/xml as 1465 specified in RFC 3023 [RFC3023]. 1467 Encoding considerations: Same as encoding considerations of 1468 application/xml as specified in RFC 3023 [RFC3023]. 1470 Security considerations: See section 10 of RFC 3023 [RFC3023] and 1471 Section 14 of this document. 1473 Interoperability considerations: none. 1475 Published specification: This document. 1477 Applications which use this media type: This document type is used to 1478 support CPIM based instant messaging. 1480 Additional information: None 1482 Magic number: None 1484 File extension: .cl or .xml 1486 Macintosh file type code: "TEXT" 1488 Personal and email address for further information: Hisham Khartabil 1489 (hisham.khartabil@gmail.com) 1491 Intended Usage: COMMON 1493 Author/change controller: The IETF . 1495 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 1497 This section registers a new XML name space, as per guidelines in the 1498 IETF XML Registry [IANA]. 1500 URI: The URI for this name space is urn:ietf:params:xml:ns:imdn. 1502 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1503 (hisham.khartabil@gmail.com) . 1505 15.3. Schema Registration 1507 This section registers a new XML schema per the procedures in [IANA]. 1508 Extensions MUST be standards track documents. 1510 URI: urn:ietf:params:xml:ns:imdn 1512 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1513 (hisham.khartabil@gmail.com) 1515 The XML for this schema can be found as the sole content of 1516 Section 11.3. 1518 15.4. Registration for urn:ietf:params:imdn 1520 Registry name: imdn 1522 Specification: RFC XXXX. Additional values may be defined by 1523 standards track RFCs that update or obsolete RFC XXXX (Specification 1524 Required). 1526 Repository: http://www.iana.org/assignments/imdn 1528 Index value: The index value is a CPIM message IMDN header name, 1529 which may consist of a sequence from a restricted set of US-ASCII 1530 characters, as defined above. 1532 URN Formation: The URI for a header is formed from its name by: 1533 a) replacing any non-URN characters (as defined by RFC 2141[URN]) 1534 with the corresponding '%hh' escape sequence (per RFC 3986 1535 [RFC2396]); and 1536 b) prepending the resulting string with 'urn:ietf:params:imdn:'. 1538 Thus, the URI corresponding to the CPIM message IMDN header 1539 'Disposition-Notification:' would be 1540 'urn:ietf:params:imdn:Disposition-Notification'. 1542 15.5. Message/CPIM Header Field Registration 1544 This document registers the following message/cpim header fields in 1545 the imdn fields registry: 1547 Disposition-Notification - [RFCXXXX] 1549 Message-ID - [RFCXXXX] 1551 Original-To - [RFCXXXX] 1553 IMDN-Record-Route - [RFCXXXX] 1555 IMDN-Route - [RFCXXXX] 1557 15.6. Content-Disposition: notification 1559 This document registers one new Content-Disposition header field 1560 "disposition-types": notification. The authors request that this 1561 value be recorded in the IANA registry for Content-Dispositions. 1563 Descriptions of this "disposition-types", including motivation and 1564 examples, are given in Section 7.2.1.1 and Section 9. 1566 Short descriptions suitable for the IANA registry are: 1568 notification the body of the message is a notification according to 1569 an earlier request for a disposition notification to an instant 1570 message 1572 16. Acknowledgements 1574 The authors would like to thank Paul Kyzivat, Ben Campbell, Adam 1575 Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, 1576 Eric McMurry, Jari Urpalainen, Jon Peterson, and Robert Sparks for 1577 their comments and support. In addition, we would like to thank the 1578 Gen-Art reviewer extrodinaire, Spencer Dawkins. 1580 17. References 1582 17.1. Normative References 1584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1585 Requirement Levels", BCP 14, RFC 2119, March 1997. 1587 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1588 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1590 [IANA] Mealling, M., "The IETF XML Registry", RFC 3688, 1591 January 2004. 1593 [URN] Moats, R., "The URN Syntax", RFC 2141, May 1997. 1595 [RFC3023] Murata, M., "XML Media Types", RFC 3023, March 1997. 1597 [XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second 1598 Edition)", W3C CR CR-xml11-20011006, October 2000. 1600 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1601 Resource Identifier (URI): Generic Syntax", STD 66, 1602 RFC 3986, January 2005. 1604 17.2. Informative References 1606 [RFC3261] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., 1607 Johnston, A., Peterson, J., Sparks, R., Handley, M., and 1608 E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1609 June 2002. 1611 [RFC3428] Campbell, B., "SIP Extension for Instant Messaging", 1612 RFC 3428, December 2002. 1614 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1615 April 2001. 1617 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 1618 Notification", RFC 3798, May 2004. 1620 [URN_NS] Moats, R., "The URN Namespace for IETF Documents", 1621 RFC 2648, August 1999. 1623 [I-D.ietf-sip-uri-list-message] 1624 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 1625 MESSAGE Requests in the Session Initiation Protocol 1626 (SIP)", draft-ietf-sip-uri-list-message-03 (work in 1627 progress), December 2007. 1629 Authors' Addresses 1631 Eric Burger 1632 BEA Systems, Inc. 1633 4 Van de Graaff Dr. 1634 Burlington, MA 01803 1635 USA 1637 Phone: +1 781 993 7437 1638 Fax: +1 603 457 5933 1639 Email: eric.burger@bea.com 1641 Hisham Khartabil 1642 Melbourne 1643 Australia 1645 Phone: +61 416 108 890 1646 Email: hisham.khartabil@gmail.com 1648 Full Copyright Statement 1650 Copyright (C) The IETF Trust (2008). 1652 This document is subject to the rights, licenses and restrictions 1653 contained in BCP 78, and except as set forth therein, the authors 1654 retain all their rights. 1656 This document and the information contained herein are provided on an 1657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1659 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1660 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1661 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1664 Intellectual Property 1666 The IETF takes no position regarding the validity or scope of any 1667 Intellectual Property Rights or other rights that might be claimed to 1668 pertain to the implementation or use of the technology described in 1669 this document or the extent to which any license under such rights 1670 might or might not be available; nor does it represent that it has 1671 made any independent effort to identify any such rights. Information 1672 on the procedures with respect to rights in RFC documents can be 1673 found in BCP 78 and BCP 79. 1675 Copies of IPR disclosures made to the IETF Secretariat and any 1676 assurances of licenses to be made available, or the result of an 1677 attempt made to obtain a general license or permission for the use of 1678 such proprietary rights by implementers or users of this 1679 specification can be obtained from the IETF on-line IPR repository at 1680 http://www.ietf.org/ipr. 1682 The IETF invites any interested party to bring to its attention any 1683 copyrights, patents or patent applications, or other proprietary 1684 rights that may cover technology that may be required to implement 1685 this standard. Please address the information to the IETF at 1686 ietf-ipr@ietf.org.