idnits 2.17.1 draft-ietf-simple-imdn-01.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 on line 1579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1603. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2006) is 6405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1475 == Unused Reference: '8' is defined on line 1516, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2633 (ref. '8') (Obsoleted by RFC 3851) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-15 -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '12') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2298 (ref. '13') (Obsoleted by RFC 3798) == Outdated reference: A later version (-06) exists of draft-niemi-simple-chat-04 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-00 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE E. Burger 3 Internet-Draft Cantata Technology 4 Intended status: Informational H. Khartabil 5 Expires: April 16, 2007 Telio 6 October 13, 2006 8 Instant Message Disposition Notification 9 draft-ietf-simple-imdn-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 16, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Instant Messaging (IM) refers to the transfer of messages between 43 users in real-time. This document provides a mechanism whereby 44 endpoints can request Instant Message Disposition Notifications 45 (IMDN), including delivery, processing and read notifications, for 46 page-mode as well as session mode instant messages. 48 The Common Profile for Instant Messaging (CPIM) data format specified 49 in RFC 3862 is extended with new headers that enable endpoints to 50 request IMDNs. A new message format is also defined to convey IMDNs. 52 This document also describes how SIP and MSRP entities behave using 53 this extension. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7 66 6.1. CPIM Header Namespace . . . . . . . . . . . . . . . . . . 7 67 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 68 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 71 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 75 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 76 7.1.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 10 77 7.1.4. Keeping State . . . . . . . . . . . . . . . . . . . . 11 78 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 80 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14 81 8.1. Constructing Processing Notifications . . . . . . . . . . 15 82 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16 83 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 17 84 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 17 85 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 18 87 11.1.1. The Element . . . . . . . . . . . . . . . 18 88 11.1.2. The Element . . . . . . . . . . . . . . . . 19 89 11.1.3. The Element . . . . . . . . . . . . . 19 90 11.1.4. The Element . . . . . . . . . 19 91 11.1.5. The Element . . . . . . . . . . . . . . . . 19 92 11.1.6. The Element . . . . . . . . . . . . . . 19 93 11.1.7. The Element . . . . . . . . . . . . . . . . . 19 94 11.1.8. The Element . . . . . . . . . . . . . . . . . . 20 95 11.2. MIME Type for IMDN Paylaod . . . . . . . . . . . . . . . . 20 96 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20 97 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 23 98 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24 99 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 24 100 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 24 101 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 24 102 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25 103 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 26 104 13.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26 105 13.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26 106 13.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 27 107 13.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 27 108 13.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 109 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 110 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30 112 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 113 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 114 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 31 115 15.2. URN Sub-Namespace Registration for 116 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32 117 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 32 118 15.4. Message/CPIM Header Field registration . . . . . . . . . . 32 119 15.5. Content-Disposition: notification . . . . . . . . . . . . 33 120 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 121 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 122 17.1. Normative References . . . . . . . . . . . . . . . . . . . 33 123 17.2. Informative References . . . . . . . . . . . . . . . . . . 34 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 125 Intellectual Property and Copyright Statements . . . . . . . . . . 35 127 1. Introduction 129 In many user-to-user message exchange systems, message senders often 130 wish to know if the human recipient actually received or read a 131 message. 133 Electronic Mail [12] deals with this situation with Message Delivery 134 Notifications [13]. After the recipient views the message, her mail 135 user agent generates a Message Delivery Notification, or MDN. The 136 MDN is an e-mail that follows the format prescribed by RFC2298 [13]. 137 The fixed format ensures that an automaton can process the message. 139 Message/CPIM [2] is a message format used to generate instant 140 messages. SIP [9] can carry instant messages generated using 141 message/CPIM in SIP MESSAGE requests [10]. The MSRP [11] SEND 142 request can also be used to carry Message/CPIM messages. 144 This document extends Message/CPIM message format (much like Message 145 Delivery Notifications [13] extends Electronic Mail [12]) to enable 146 Instant Message Senders to request, create and send Instant Message 147 Disposition Notifications (IMDN) for a page-mode as well as session 148 mode instant messages. IMDNs include positive delivery, negative 149 delivery (i.e. a message did not get delivered successfully), read 150 notifications as well as processed notifications. By using CPIM 151 headers, the IMDN request and delivery are abstracted outside the 152 transport protocol allowing interoperability between different IM 153 systems. Likewise, the mechanism does not rely on session-mode 154 versus page-mode. 156 This document also describes how SIP and MSRP entities behave using 157 this extension. 159 2. Conventions 161 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 162 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 163 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and 164 indicate requirement levels for compliant implementations. 166 3. Terminology 168 o IM: An Instant Message generated using the Message/CPIM format. 170 o IMDN: An Instant Message Disposition Notification generated using 171 the Message/CPIM format that carries a IMDN XML document. 173 o Message: an IM or an IMDN generated using the Message/CPIM format. 175 o IM Sender: An endpoint (User Agent) generating and sending an IM. 176 It is also the endpoint that requests IMDNs for an IM. Quite 177 often, the IM Sender is the IMDN Recipient, but that is not always 178 true. 180 o IM Recipient: An endpoint (User Agent) that receives IMs. It is 181 also the endpoint that generates and sends IMDNs to IMs, if 182 requested by the IM Sender. 184 o Endpoint: An IM Sender or an IM Recipient. 186 o Intermediary: An entity in the network that is on the path of an 187 IM to its final destination. 189 o IMDN Payload or XML Document: An XML document carrying the 190 disposition notification information. It is always of MIME type 191 "message/imdn+xml". 193 o Disposition type: the type of IMDN that can be requested. This 194 specification defines three, namely "delivery", "processing" and 195 "read" disposition types. 197 o Transport Protocol Message: An IM or an IMDN wrapped in a 198 transport protocol like SIP or MSRP. 200 4. Overview 202 The basic protocol flow is depicted in the diagram below. An IM 203 Sender creates an IM, adds to it IMDN request information it is 204 interested in receiving, then sends its. At a certain point in time, 205 the IM Recipient or an intermediary determines that the user or 206 application has received, did not receive or has read the IM or 207 otherwise disposed the IM. The mechanism by which an IM Recipient 208 determines its user has read an IM is beyond the scope of this 209 document. At that point, the IM Recipient or intermediary 210 automatically generates a notification message to the IM Sender. 211 This notification message is the Instant Message Disposition 212 Notification (IMDN). 214 +--------------+ +--------------+ 215 | IM Sender | | IM Recipient | 216 |IMDN Recipient| | IMDN Sender | 217 +--------------+ +--------------+ 218 | | 219 | | 220 | 1. IM requesting IMDN | 221 |-------------------------------------->| 222 | | 223 | | 224 | 2. IMDN (disposition) | 225 |<--------------------------------------| 226 | | 227 | | 229 Note that the recipient of an IMDN, in some instances, may not be the 230 IM Sender. This is specifically true for page-mode IMs where the 231 Address of Record (AOR) of the IM Sender, that is present in the 232 IMDN, resolves to a different location to where the IM originated. 233 For simplicity, the rest of this document assumes that the IM Sender 234 and the IMDN Recipient are the same and therefore will refer to both 235 as the IM Sender. 237 5. Disposition Types 239 There are three broad categories of disposition states. They are 240 delivery, processing and read. Future extensions may introduce 241 others. 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: 249 o "delivered" to indicate successful delivery. 251 o "failed" to indicate failure in delivery. 253 o "forbidden" indicate denial by the IM Recipient for the IM Sender 254 to receive the requested IMDN. 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 IM has been 261 processed by an intermediary. The processing notification type can 262 have the following states: 264 o "processed" is a general state of the IM indicating it has been 265 processed. 267 o "stored" state indicates that the IM has been stored by the 268 intermediary for later delivery. 270 o "forbidden" indicate denial by the IM Recipient for the IM Sender 271 to receive the requested IMDN. 273 o "error" to indicate an error in determining the fate of an IM. 275 5.3. Read 277 The read notification type indicates whether the IM Recipient 278 displayed the IM to the user or not. The read notification type can 279 have the following states: 281 o "read" is a state indicating that the IM has been read. 283 o "forbidden" indicate denial by the IM Recipient for the IM Sender 284 to receive the requested IMDN. 286 o "error" to indicate an error in determining the fate of an IM. 288 Since there is no positive acknowledgement from the user, one cannot 289 determine a priori that the user actually read the IM. Thus one MUST 290 NOT 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 [2]. A new namespace is created as well as a number of new CPIM 296 headers. 298 6.1. CPIM Header Namespace 300 Per CPIM [2], this specification defines a new namespace for the CPIM 301 extension headers defined in the following sections. The namespace 302 is: urn:ietf:params:cpim-headers:imdn As per CPIM [2] requirements, 303 the new headers defined in the following sections are prepended by 304 the string "imdn." in CPIM messages. 306 6.2. Disposition-Notification 308 The Disposition-Notification header field is used by the IM Sender to 309 indicate the desire to receive IMDNs, from the IM Recipient, for that 310 specific IM. This header field is not needed if the IM Sender does 311 not request an IMDN. The syntax is defined in Section 10. 313 6.3. Message-ID 315 The Message-ID header field contains a globally unique message 316 identifier that is used by the IM Sender to correlate received IMDNs 317 by comparing its value with the value of the element 318 present in the IMDN payload. This header field is mandatory with 319 sending an IM and requesting an IMDN. IMDNs also carry this header 320 field. The syntax is defined in Section 10. 322 6.4. Original-To 324 The Original-To header field is sometimes added to an IM by an 325 intermediary and populated with of the address of the IM Sender. It 326 is used by the IM Recipient to indicate in the IMDNs (by populating 327 the element) the original address the IM was 328 sent to. This header is mandatory if the intermediary changes the 329 CPIM To header field value. The header MUST NOT appear more than 330 once in an IM. The header field value MUST NOT be changed by an 331 intermediary if it was already present. The syntax is defined in 332 Section 10. 334 6.5. IMDN-Record-Route 336 Intermediaries have the capability of indicating that IMDNs should be 337 sent through it (otherwise, IMDNs will not visit the intermediary). 338 An intermediary that request IMDNs to be sent through itself adds an 339 IMDN-Record-Route header field to the IM. The value of the IMDN- 340 Record-Route header field is set to the address of that intermediary. 341 Multiple IMDN-Record-Route header fields can appear in an IM. The 342 syntax is defined in Section 10. 344 6.6. IMDN-Route 346 The IMDN-Route header field provides routing information by including 347 one or more addresses where an IMDN must be routed through. On 348 creating an IMDN, an IM recipient copies the contents of the IMDN- 349 Record-Route present in the IM into the IMDN-Route of the IMDN. 350 Multiple IMDN-Route header fields can appear in an IMDN. The syntax 351 is defined in Section 10. 353 7. Endpoint Behaviour 355 7.1. IM Sender 357 7.1.1. Constructing Instant Messages 359 An IM is constructed using RFC 3862 [2]. The Content-type header 360 field indicates the MIME type of the request payload. 362 7.1.1.1. Adding a Message-ID Header Field 364 If the IM sender requests the reception of IMDNs, the IM sender MUST 365 include a Message-ID header field. The Message-ID field is populated 366 with a value that is unique with 32 bits of randomness. This header 367 field enables the IM Sender to match any IMDNs with their 368 corresponding IMs. 370 7.1.1.2. Adding a DateTime Header Field 372 Some devices may not implement the concept of "Sent Items" box and 373 therefore no information about an IM is stored. It is therefore 374 necessary to add a time stamp in the IM to indicate when it was sent. 375 This time stamp is returned in the IMDN in order to enable the user 376 to correlate the IM with the IMDN at the human level. The DateTime 377 header field is used for this purpose. The IM MUST contain a 378 DateTime header field if an IMDN is requested. 380 7.1.1.3. Adding a Disposition-Notification Header Field 382 In this specification, the IM Sender can request two types of 383 delivery notifications: a failure delivery notification and a success 384 delivery notification. An IM Sender requests failure delivery 385 notification by including a Disposition-Notification header field 386 with value "negative-delivery". Similarly, a success notification is 387 requested by including a Disposition-Notification header field with 388 value "positive-delivery". Both types of delivery notifications can 389 be requested for the same IM. 391 The IM Sender can request a processing notification by including a 392 Disposition-Notification header field with value "processing". 394 The IM Sender can also request a read notification. It is requested 395 by including a Disposition-Notification header field with value 396 "read". 398 The absence of this header or the presence of the header with empty 399 value indicates that the IM Sender is not requesting any IMDNs. The 400 Disposition-Notification header fields can be comma separated. 402 Future extension may define other disposition notifications not 403 defined in this document. The IM Sender MAY request more than one 404 type of IMDN for a single IM. 406 The formal syntax of the Disposition-Notification header field can be 407 found in Section 10. The following in an example IM where the IM 408 Sender requests positive and negative delivery notifications, but not 409 read notification nor processing notifications: 411 Content-type: Message/CPIM 413 From: Alice 414 To: Bob 415 NS: imdn 416 imdn.Message-ID: 34jk324j 417 DateTime: 2006-04-04T12:16:49-05:00 418 imdn.Disposition-Notification: positive-delivery, negative-delivery 419 Content-type: text/plain 420 Content-length: 12 422 Hello World 424 7.1.2. Matching IMs with IMDNs 426 An IM Sender matches an IMDN to an IM by matching the Message-ID 427 header field value in the IM with the element value in 428 the body of the IMDN. If the IM was delivered to multiple 429 recipients, the IM Sender uses the element or the 430 element in the XML body of the IMDN it 431 received to identify the IM Recipient (IMDN Sender). 433 7.1.3. Aggregation of IMDNs 435 An IM Sender may send an IM to multiple recipients in one Transport 436 Protocol Message (typically using a URI-List server) and request 437 IMDNs. It MAY choose to either get one IMDN from each IM Recipient 438 individually or get an aggregated IMDN (the URI-List server 439 aggregates the IMDNs and send the one or more aggregated IMDNs). The 440 IM Sender requests aggregation by adding the Disposition-Notification 441 header field parameter "aggregate". The absence of such a parameter 442 indicates that the IM Sender does not wish for IMDNs to be 443 aggregated. Aggregation can be requested per disposition type. For 444 example, a IM Sender can request delivery notification to be 445 aggregated but read notifications to be sent individually. For 446 example: 448 Disposition-Notification: positive-delivery;aggregate, read 449 The following is an example of an IM Sender requesting aggregation of 450 both positive delivery notifications and read notifications: 452 Disposition-Notification: positive-delivery;aggregate, read;aggregate 454 An IM Sender that requested an aggregated IMDN MUST be prepared to 455 receive multiple aggregated or non-aggregated IMDNs. See Section 8.2 456 for details. 458 An IM Sender MUST be prepared to receive aggregated IMDNs even if it 459 did not request the URI-List server to do so. See again Section 8.2 460 for details. Note that the "aggregate" parameter is a hint for 461 intermediaries and does not require the intermediaries to aggregate 462 IMDNs. 464 7.1.4. Keeping State 466 This specification does not mandate the IM Sender to keep state for a 467 sent IM. 469 Once an IM Sender sends an IM containing an IMDN request, it MAY 470 preserve the IM context, principally the Message-ID, and other user- 471 identifiable information such as the IM subject or content, and date 472 and time it was sent. Without preservation of the IM context, the IM 473 Sender will not be able to correlate the IMDN with the IM it sent. 474 The IM Sender may find it impossible to preserve IM state if it has 475 limited resources or does not have non-volatile memory and then loses 476 power. 478 There is, however, the concept of "Sent Items" box in an application 479 that stores sent IMs. This "Sent Items" box has the necessary 480 information and may have a fancy user interface indicating the state 481 of a sent IM. Unique Message-ID for this purpose proves to be 482 useful. The length of time for items to remain in the "Sent Items" 483 box is a user choice. The user is usually free to keep or delete 484 items from the "Sent Items" box as she pleases or as the memory on 485 the device reaches capacity. 487 Clearly, if an IM Sender loses its sent items state (user deletes 488 items from the "Send Items" box), the client may use a different 489 display strategy in response to apparently unsolicited IMDNs. 491 This specification also does not mandate an IM Sender to run any 492 timers waiting for an IMDN. There are no time limits associated with 493 when IMDNs may be received. 495 IMDNs may legitimately never be received. On the other hand, and 496 IMDN may simply take a very long time. Some clients may choose to 497 purge the state associated with the sent IM. This is the reason for 498 adding the time stamp in the IM and having it returned in the IMDN. 499 This gives the user some opportunity of remembering what IM was sent. 500 For example if the IMDN indicates that the IM the user sent at 2 p.m. 501 last Thursday was delivered, the user has a chance of remembering 502 that they sent an IM at 2 p.m. last Thursday. 504 7.2. IM Recipient 506 7.2.1. Constructing IMDNs 508 IM recipients examine the contents of the Disposition-Notification 509 header field of the CPIM message to determine if an IMDN must be 510 generated for that IM. Disposition-Notification header fields of 511 CPIM messages can include one or more values. This implies that IM 512 recipients may need to generate zero, one, or more IMDNs for that IM, 513 for example a delivery notification as well as a read notification. 514 In this case the IM Recipient MUST be able to construct multiple 515 IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN 516 per disposition type. I.e. It must not, for example, generate a 517 delivery notification indicating "delivered" then followed by a 518 delivery notification indicating "failed" for the same IM. If the IM 519 Sender requested only failure notifications and the IM was 520 successfully delivered, then no IMDNs will be generated. 522 The IM Recipient MUST NOT generate processing notifications. 524 Disposition-Notification header MUST NOT appear in an IMDN since it 525 does not make sense and is therefore forbidden to request an IMDN for 526 an IMDN. IM Sender MUST ignore it if present. The IM Sender MUST 527 NOT send an IMDN to an IMDN. 529 An IMDN MUST contain a Message-ID header field. The same rules of 530 uniqueness for the Message-ID header field that appears in an IM 531 apply to an IMDN. 533 An IM may contain a IMDN-Record-Route header field (see Section 8 for 534 details). If IMDN-Record-Route header fields appear in the IM, the 535 IM Recipient constructing the IMDN MUST copy the contents of the 536 IMDN-Record-Route header fields into IMDN-Route header fields in the 537 IMDN and maintain the order. The IMDN is then sent to the address in 538 the top IMDN-Route header field. 540 7.2.1.1. Constructing Delivery Notifications 542 A delivery notification is constructed in a similar fashion as an IM, 543 using RFC 3862 [2]. For delivery notifications, the Content-type 544 MUST be of type "message/imdn+xml". It is an XML document. The 545 schema is described Section 11. The delivery notification MUST 546 contain a Content-Disposition header field with value "notification". 547 This indicates to the IM Sender that the message is an IMDN to an IM 548 it has earlier sent. 550 An example looks like the following: 552 Content-type: Message/CPIM 554 From: Bob 555 To: Alice 556 NS: imdn 557 imdn.Message-ID: d834jied93rf 558 Content-type: message/imdn+xml 559 Content-Disposition: notification 560 Content-length: ... 562 563 34jk324j 564 2006-04-04T12:16:49-05:00 565 im:bob@example.com 566 im:bob@example.com 567 568 569 570 571 572 573 The IM was successfully Delivered 574 576 7.2.1.2. Constructing Read Notifications 578 A read notification is constructed in a similar fashion as the 579 delivery notification. See Section 7.2.1.1 for details. 581 An example looks like the following: 583 Content-type: Message/CPIM 585 From: Bob 586 To: Alice 587 NS: imdn 588 imdn.Message-ID: dfjkleriou432333 589 Content-type: message/imdn+xml 590 Content-Disposition: notification 591 Content-length: ... 593 594 34jk324j 595 2006-04-04T12:16:49-05:00 596 im:bob@example.com 597 im:bob@example.com 598 599 600 601 602 603 604 The IM has been read 605 607 There are situations where the IM Recipient cannot determine if or 608 when the IM has been read. The IM Recipient in this case generates a 609 read notification with a value of "error" to indicate an 610 internal error by the server. 612 8. Intermediary Behaviour 614 In this context, application servers (including URI-List servers and 615 Store-and-Forward server) and gateways are defined as intermediaries. 617 An intermediary that forwards an IM MAY change the recipient address 618 in the CPIM To header field when forwarding (for example, a URI-List 619 server changes the IM Recipient address from its own to the address 620 of the final recipient of that IM for every copy it makes to be sent 621 to the list members). In this case, the intermediary MUST add an 622 Original-To header field to the IM populating it with the address 623 that was in the To header field before it was changed. I.e. The 624 Original-To header is populated with the intermediary address. An 625 intermediary MUST NOT add an Original-To header field if one already 626 exists. 628 An intermediary MAY choose to remain on the path of IMDNs for a 629 specific IM. It can do so by adding a CPIM IMDN-Record-Route header 630 field as the top IMDN-Record-Route header and populating it with its 631 own address. An intermediary that does not support this extension 632 will obviously not add the IMDN-Record-Route header. This allows 633 IMDNs to traverse directly from the IM Recipient to the IM Sender 634 even if the IM traversed an intermediary not supporting this 635 extension. 637 An intermediary receiving an IMDN checks the top IMDN-Route header 638 field. If that header field carries the intermediary address, the 639 intermediary pops that header and forwards the IMDN to the address 640 indicated in the now top IMDN-Route header. If no IMDN-Route headers 641 are present, the IMDN is forwarded to the address in the To header 642 field. 644 An intermediary MUST remove any information about the final 645 recipients of a list if the list membership is not disclosed. The 646 intermediary does that by removing the element and/or 647 element from the body of the IMDN before 648 forwarding it to the IM Sender. 650 8.1. Constructing Processing Notifications 652 Intermediaries are the only entities that construct processing 653 notifications. They do so only if the IM Sender has requested a 654 processing notification by including a Disposition-Notification 655 header field with value "processing". 657 The intermediary can create and send processing notifications 658 indicating that an IM has been processed or stored. The intermediary 659 MUST NOT send more than one IMDN for the same disposition type. I.e. 660 It must not send a processing notification indicating that an IM is 661 being "processed" followed by another IMDN indicating that the same 662 IM is "stored". 664 A processing notification is constructed in a similar fashion as the 665 delivery notification. See Section 7.2.1.1 for details. 667 An example looks like the following: 669 Content-type: Message/CPIM 671 From: Bob 672 To: Alice 673 Content-type: message/imdn+xml 674 Content-Disposition: notification 675 Content-length: ... 677 678 34jk324j 679 2006-04-04T12:16:49-05:00 680 im:bob@example.com 681 im:bob@example.com 682 683 684 685 686 687 688 The IM has been processed 689 691 There are situations where the intermediary cannot know the fate of 692 an IM. The intermediary in this case generates a processing 693 notification with a value of "error" to indicate so. 695 8.2. Aggregation of IMDNs 697 In this context, URI-List servers are defined as intermediaries. 699 When a URI-List server receives an IM, it needs to examine 700 Disposition-Notification header fields. If an IMDN request contains 701 the "aggregate" parameter, the URI-List server MUST wait for a 702 configurable period of time or until all recipients have sent the 703 IMDN (whichever comes first) before the URI-List server sends an 704 aggregated IMDN. Note that some IMDNs, for example read 705 notifications, may never come due to user settings. It is an 706 administrator configuration and an implementation issue how long to 707 wait before sending an aggregated IMDN and before a URI-List server 708 removes state for that IM. 710 A URI-List server MAY choose to send multiple aggregated IMDNs even 711 if the requester asked for one aggregated IM. A timer can be started 712 and when it fires, the URI-List server can aggregate whatever IMDNs 713 it has so far for that IM, send the aggregated IMDN and restart the 714 timer for the next batch. This is needed for scenarios where the IM 715 Sender has requested more than one IMDN for a specific IM, for 716 example, delivery notifications as well as read notifications, or 717 when the URI-List server is short on resources and chooses to 718 prioritise forwarding IMs over IMDNs. A second timer can be running 719 and when it fires, the state of the IM is deleted. In this case, the 720 URI-List server consumes any IMDNs that might arrive after that time. 722 A URI-List server MAY aggregate IMDNs even if the IM Sender did not 723 request it to do so. This is to handle the case where the list 724 membership information is not disclosed. The URI-List server MAY 725 also choose to ignore an aggregation request and send individual 726 IMDNs instead. 728 The aggregated IMDN is constructed using the multipart/mixed MIME 729 type and including all the received IMDNs as message/imdn+xml as 730 individual payloads. 732 There are scenarios where an intermediary needs to generate IMDNs, 733 see Section 12.2 for further details. 735 9. Identifying Messages 737 Messages are typically carried in a transport protocol like SIP [9]. 738 The message is an IM if the content-type header field present in it 739 has a value that is NOT "message/imdn+xml". 741 A message is identified as a delivery notification by examining its 742 contents. The message is a delivery notification if: the Content- 743 type header field present has a value of "message/imdn+xml", the 744 Content-Disposition header field has a value of "notification", and 745 the element in that xml body has a sub-element 746 . 748 A message is identified as a processing notification or read 749 notification in a similar fashion as a delivery notification. The 750 difference is that the element in that xml body has a 751 sub-element of and respectively. 753 10. Header Fields Formal Syntax 755 The following syntax specification uses the message header syntax as 756 described in Section 3 of RFC3862 [2]. 758 Header syntax is described without a namespace qualification. 759 Following the rules in RFC3862 [2], header names and other text are 760 case sensitive and MUST be used as given, using exactly the indicated 761 upper-case and lower-case letters. 763 Disposition-Notification = 764 "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))] 765 notify-req = 766 ("negative-delivery" / "positive-delivery" / 767 "processing" / "read" / Token) *(SEMI disp-notif-params) 769 disp-notify-params = "aggregate" / generic-param 771 Message-ID = "Message-ID" ": " Token 773 Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" 775 IMDN-Record-Route = "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" 777 IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 779 11. IMDN Format 781 11.1. Structure of XML-Encoded IMDN Payload 783 An IMDN Payload is an XML document [7] that MUST be well-formed and 784 MUST be valid according to schemas, including extension schemas, 785 available to the validater and applicable to the XML document. The 786 IMDN Payload MUST be based on XML 1.0 and MUST be encoded using 787 UTF-8. 789 The namespace identifier for elements defined by this specification 790 is a URN [4], using the namespace identifier 'ietf' defined by [5] 791 and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. 793 This namespace declaration indicates the namespace on which the IMDN 794 is based. 796 The root element is . The element has sub-elements, 797 namely , , , , , , , and . 799 Those elements are described in details in the following sections. 801 and can be extended in the future to include 802 new sub-elements not defined in this document. Those new elements 803 MUST be defined in an RFC. 805 11.1.1. The Element 807 The element is mandatory according to the XML schema and 808 carries the message id that appeared in the Message-ID header field 809 of the IM. 811 11.1.2. The Element 813 The element is mandatory and carries the date and time the 814 IM was sent (not the IMDN). This information is obtained from the 815 DateTime header field of the IM. 817 11.1.3. The Element 819 The element is optional and carries the URI of the 820 final recipient. This information is obtained from the To header 821 field of the IM. 823 11.1.4. The Element 825 The element is optional and carries the URI 826 of the original recipient. It MUST be present if the IM carried the 827 Original-To header field. This information is obtained from the 828 Original-To header field of the IM. 830 11.1.5. The Element 832 The element is optional and carries the text that was in 833 the Subject header field, if any. This allows for a human level 834 correlation between an IM and an IMDN. 836 11.1.6. The Element 838 The element is mandatory and carries the disposition 839 type that the IM Sender requested and is being reported. It can 840 carry one of the sub-elements , , or any 841 other future extension. 843 11.1.7. The Element 845 The element is mandatory and carries the result of the 846 disposition request in the element. For disposition 847 type , it can carry one of the sub-elements , 848 , or . For disposition type , it 849 can carry one of the sub-elements , or . 850 For disposition type , it can carry one of the sub- 851 elements , , or . 852 means the disposition was denied. means internal server 853 error. It can also carry any other future extension. 855 11.1.8. The Element 857 The element is optional and carries a human readable text. It 858 has the "lang" attribute that indicates the language the text is 859 written in. 861 11.2. MIME Type for IMDN Paylaod 863 The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN 864 MUST identify the payload as MIME type "message/imdn+xml" in the 865 Content-type header field. 867 11.3. The RelaxNG Schema 869 870 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 903 904 905 906 907 908 909 910 911 912 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 986 987 988 989 990 991 992 993 994 995 996 997 998 1000 1001 1002 1004 1005 1006 1007 1008 lang 1009 1010 1011 1012 1013 1014 1016 1017 1018 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1041 1043 12. Transporting Messages using SIP 1044 12.1. Endpoint Behaviour 1046 12.1.1. Sending Requests 1048 A SIP MESSAGE request is constructed using RFC 3428 [10]. The 1049 Content-type header field indicates the MIME type of the request 1050 payload. When using this extension, the Content-type header field 1051 MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The 1052 payload is constructed according to Section 7. 1054 A SIP MESSAGE request to multiple recipients is constructed in a 1055 similar manner as a SIP MESSAGE request to a single recipient. The 1056 differences are indicated in [15]. 1058 12.1.2. Sending Responses 1060 An endpoint receiving a SIP MESSAGE request constructs a SIP response 1061 according to RFC3428 [10]. Of course, an endpoint will send a 1062 response to the MESSAGE request regardless of they type of message 1063 (IM or IMDN) is has received, or the disposition type it has been 1064 asked for. 1066 12.1.3. Receiving Requests 1068 12.1.3.1. Instant Message 1070 A SIP MESSAGE request is identified as an IM by examining its 1071 contents according to Section 9. 1073 If an IM Recipient received a SIP MESSAGE request that is an IM that 1074 requested a positive-delivery notification, and that IM Recipient has 1075 constructed and sent a SIP 2xx class response, it MAY generate a 1076 positive-delivery notification after making sure that the IM has been 1077 delivered to the user or application (a GW, for example, can generate 1078 a 2xx response before it has been guaranteed that the final recipient 1079 has actually received the IM). The positive-delivery notification is 1080 constructed according to Section 7.2.1.1. The message is then placed 1081 as the payload in a SIP MESSAGE request. 1083 If an IM Recipient received a SIP MESSAGE request that is an IM that 1084 requested a negative-delivery, and that IM Recipient has constructed 1085 and sent a 2xx class response, it SHOULD generate a negative-delivery 1086 notification if it learnt that the final recipient or application did 1087 not receive the IM (a GW, for example, can generate a 2xx response 1088 before it has been guaranteed that the final recipient has actually 1089 received the IM). The negative-delivery notification is constructed 1090 according to Section 7.2.1.1. The message is then placed as the 1091 payload in a SIP MESSAGE request. 1093 If an IM Recipient received a SIP MESSAGE request that is an IM that 1094 requested a negative-delivery notification, and the IM Recipient has 1095 constructed and sent an error response, it MUST NOT generate a 1096 negative-delivery notification. 1098 If an IM Recipient received a SIP MESSAGE request that is an IM that 1099 requested a read notification, and that IM Recipient has constructed 1100 and sent a SIP 2xx class response, it MAY generate a read 1101 notification after making sure that the IM has been presented to the 1102 user or application. It is outside the scope of this document how 1103 such determination can be made. Note that the option to send a read 1104 notification or not can be left to the user. An application may 1105 allow a user to configure such choice. The read notification is 1106 constructed according to Section 7.2.1.2. The message is then placed 1107 as the payload in a SIP MESSAGE request. 1109 12.1.3.2. Delivery Notification 1111 A SIP MESSAGE request is identified as delivery notification by 1112 examining its contents according to Section 9. 1114 12.1.3.3. Read Notification 1116 A SIP MESSAGE request is identified as read notification by examining 1117 its contents according to Section 9. 1119 12.2. Intermediary Behaviour 1121 In this context, application servers (including URI-List servers and 1122 Store-and-Forward server) and gateways are defined as intermediaries. 1123 SIP Proxies MUST NOT generate IMDNs but MUST forward them like any 1124 other sip request. 1126 A SIP MESSAGE request to multiple recipients is forwarded according 1127 to [15]. 1129 If an intermediary generates a SIP 2xx class response to a SIP 1130 MESSAGE request it has received that is an IM, it examines if the 1131 body was of type "message/cpim". If so, it checks if there is the 1132 header field Disposition-Notification with a value "positive- 1133 delivery" and/or "negative-delivery". If so, it MUST send a delivery 1134 notification after receiving a transactional final response for the 1135 IM. 1137 If the Disposition-Notification header field contains a value of 1138 "positive-delivery", the intermediary MUST NOT generate a delivery 1139 notification if it receives a SIP 2xx class response for the sent IM. 1140 This is in anticipation of a failure downstream after a 2xx response 1141 has been generated. 1143 If the Disposition-Notification header field contains a value of 1144 "negative-delivery", the intermediary SHOULD generate a delivery 1145 notification if it receives a SIP 4xx, 5xx or 6xx class final 1146 response for the sent IM or if it has received a SIP 2xx class 1147 response followed by a negative-delivery notification. 1149 If the Disposition-Notification header field contains a value of 1150 "processing", the intermediary MAY generate a processing notification 1151 after it has forwarded or stored the IM. The rest of the procedures 1152 in Section 8.1 apply. 1154 The procedure for generating such IMDN is the same as that of an IM 1155 Recipient (Section 7.2.1.1). 1157 The element of the XML body is populated with the URI 1158 of the IM Recipient. 1160 If an intermediary receives a SIP MESSAGE request carrying a positive 1161 delivery notification or a read notification, it forwards it using 1162 the rules in Section 8. 1164 13. Transporting Messages using MSRP 1166 13.1. Endpoint Behaviour 1168 13.1.1. Sending Requests 1170 MSRP Relays MUST NOT generate IMDNs. 1172 An MSRP SEND request is constructed using [11]. The content-type 1173 header field indicates the MIME type of the request payload. When 1174 using this extension, the content-type header field MUST be of MIME 1175 type "message/cpim" [2] for both IMs and IMDNs. The payload is 1176 constructed according to Section 7. 1178 MSRP has built in delivery reports and therefore does not require 1179 delivery notifications as defined in this specification. Read 1180 notifications and any future defined IMDN dispositions, however, are 1181 still relevant. Therefore, an IM Sender MUST NOT create MSRP SEND 1182 requests requiring a positive-delivery notification or a negative- 1183 delivery notification. 1185 For SEND requests that are IMDNs, the IM Recipient MUST NOT request a 1186 delivery report (an MSRP REPORT to a SEND request). I.e. It MUST 1187 populate the request with a Failure-Report header field with the 1188 value "no" and with a Success-Report header field with value "no" (or 1189 alternatively leave out that header field since it defaults to "no"). 1190 The IM Recipient also MUST NOT request an IMDN for a SEND request 1191 that is an IMDN. 1193 An MSRP SEND request to multiple recipients is constructed in a 1194 similar manner as a SEND request to a single recipient. The 1195 differences are indicated in [14]. 1197 13.1.2. Sending Responses 1199 An endpoint receiving an MSRP SEND request constructs an MSRP 1200 response according to [11] if needed. Section 7.2 of [11] describes 1201 when to send and when not to send an MSRP response. For SEND 1202 requests that are IMDNs, a response MUST NOT be generated. This is 1203 not a special case; for SEND requests that contain a Failure-Report 1204 header field with the value "no" and a Success-Report header field 1205 with value "no" the IM Sender does not need to start a timer and the 1206 IM Recipient does not send a transactional response. 1208 13.1.3. Receiving Requests 1210 13.1.3.1. Instant Message 1212 An MSRP SEND request is identified as an IM by examining its contents 1213 according to Section 9. 1215 13.1.3.2. Read Report 1217 An MSRP SEND request is identified as read notification by examining 1218 its contents according to Section 9. The IM Sender MUST ignore any 1219 requests for read notification, or any kind of IMDNs for an IMDN. 1221 13.2. Intermediary Behaviour 1223 In this context, application servers (including conference servers 1224 and Store-and-Forward server) and gateways are defined as 1225 intermediaries. MSRP Relays MUST NOT generate IMDNs but MUST relay 1226 them. 1228 An MSRP SEND request to multiple recipients is forwarded according to 1229 [14]. 1231 MSRP has built in delivery reports and therefore does not require 1232 delivery notifications as defined in this specification. An MSRP 1233 intermediary MUST NOT generate IMDNs. A Store-and-Forwards server 1234 (the equivalent of a voice-mail server) can send stored session IMs 1235 to their destination and forward the request for read notifications, 1236 if any. The read notification most likely has to be an aggregated 1237 read notification for all the IMs that were stored for that session, 1238 and the aggregation has to be done at the IM Recipient. It is 1239 unknown at this point how a MSRP store-and-forward server 1240 communicates with the recipient in order to send the IMs. This is 1241 outside the scope of this document and is left as a future exercise. 1243 14. Security Considerations 1245 IMDNs provide a fine-grained view of the activity of the IM Recipient 1246 and thus deserves particularly careful confidentiality protection so 1247 that only the intended recipient of the IMDN will receive the IMDN 1248 (in most cases, the intended recipient of the IMDN is the IM Sender). 1250 Since IMDNs are carried by using the IM protocol itself, all security 1251 considerations of the underlying IM protocol also apply to the IMDNs. 1253 The threats in the IMDN system, over and beyond the threats inherent 1254 to IM include the following: 1256 o A malicious endpoint attempts to send messages to a user that 1257 would normally not wish to receive messages from that endpoint by 1258 convincing the IMDN system to "bounce" an IMDN from an 1259 unsuspecting endpoint to the user. 1261 o A malicious endpoint attempts to flood a IM Sender with IMDNs by 1262 convincing a URI-List server to send IMDNs to an unsuspecting IM 1263 Sender. 1265 o A malicious node in the network that attempts to modify an IMDN 1266 from a IM Recipient. 1268 o A malicious intermediary attempts to forward an IMDN from an IM 1269 Recipient to the IM Sender, where the IM Recipient would not 1270 normally forward the IMDN to that IM Sender if the IM Recipient 1271 knew the identity of the IM Sender. 1273 o A malicious endpoint that attempts to fish for a Request-URI of an 1274 endpoint beyond an intermediary , where the endpoint would 1275 normally wish to keep its identity private from the malicious 1276 endpoint. 1278 o A malicious node in the network that attempts to eavesdrop on IMDN 1279 traffic to, for example, learn Request-URI or traffic pattern 1280 information. 1282 o A malicious node in the network attempts to stage a denial of 1283 service attack on an intermediary by requesting a large list 1284 expansion with a request for aggregated IMDN processing. 1286 The protocol cannot protect against attacks that include the 1287 following: 1289 o A malicious intermediary directly revealing the identity of a 1290 downstream endpoint that would not normally wish its identity 1291 revealed. Keeping such information private is an intermediary 1292 implementation issue. 1294 o A malicious IM Recipient that alters the time of the IMDN. There 1295 is no protocol mechanism for ensuring the IM Recipient does not 1296 lie about the time or purposely holds an IMDN for transmission to 1297 make it appear that the user read an IM later than they actually 1298 did. 1300 o A deletion attack on an IMDN. This is a trade-off between privacy 1301 and security. The privacy considerations allow the IM Recipient 1302 to silently ignore an IMDN request. Any mechanism that would 1303 reliably indicate that a malicious node deleted a IM Recipient's 1304 IMDN would also serve the purpose of detecting a IM Recipient that 1305 chose not to issue an IMDN. 1307 To combat eavesdropping, modification, and man-in-the-middle attacks, 1308 we require some level of authentication and integrity protections. 1309 That said, there are circumstances where strong integrity would be 1310 overkill. The presumption is the IM Sender has and sets the 1311 expectation for the level of protection. The procedures for 1312 integrity protection are as follows. 1314 o If the IM Recipient has a certificate, it MUST sign the IMDN. 1316 o If the IM is encrypted, the IM Recipient or intermediary MUST 1317 encrypt the IMDN body, as an attacker may attempt to discern the 1318 user's activity profile and identity from sniffing IMDNs on the 1319 network. 1321 o The two above rules are cumulative. 1323 The IM Recipient or intermediary MUST be capable of loading a user 1324 certificate. 1326 An attacker can mount a distributed denial of service attack on a 1327 node by sending lots of IMs to the node with IMDN requests. Note 1328 that this is the same problem as there is without IMDN; IMDN simply 1329 linearly increases the load on the node under attack. One can 1330 mitigate, but not eliminate this threat by the endpoint immediately 1331 ignoring requests that are not authenticated. 1333 Likewise, an attacker can mount a denial of service attack on an 1334 intermediary by asking the intermediary to explode a large list and 1335 to direct the intermediary to aggregate the IMDNs from the targets of 1336 the list. 1338 The following security considerations apply when using IMDNs: 1340 14.1. Forgery 1342 IMs can be forged. To protect against that, an IM can be signed. An 1343 intermediary that receives a signed message and needs to modify any 1344 part of it that is included in the signature (like adding an 1345 Original-To header to the CPIM headers), MUST consume the IM and 1346 create a new copy of it that the intermediary signs itself. 1348 IMDNs may be forged as easily as ordinary IMs. Endpoints and 1349 intermediaries that wish to make automatic use of IMDNs should take 1350 appropriate precautions to minimize the potential damage from denial- 1351 of-service attacks. Security threats related to forged IMDNs include 1352 the sending of a falsified IMDN when the indicated disposition of the 1353 IM has not actually occurred. For example, read notification could 1354 be forged to indicate that a IM Recipient has read the IM. 1355 Unsolicited IMDNs is also another form of forgery. 1357 14.2. Confidentiality 1359 There may be cases where an IM Recipient does not wish to reveal the 1360 information that he has received or in fact read the IM. In this 1361 situation, it is acceptable for the IM Recipient to silently ignore 1362 requests for an IMDN. It is strongly RECOMMENDED that the IM 1363 Recipient obtain the user's consent before sending an IMDN. 1364 Circumstances where the IM Recipient does not ask for the user's 1365 consent include IM systems that, for regulatory reasons, are required 1366 to issue an IMDN, such as in the health care field or financial 1367 community. 1369 An IM Recipient can obtain such consent by a prompt or dialog box on 1370 a per-IM basis, globally through the user's setting of a preference, 1371 or other, user-configurable mechanism. The user might also indicate 1372 globally that IMDNs are never to be sent or that a "forbidden" IMDN 1373 status is always sent in response to a request for an IMDN. 1375 There are situations where a user sends an IM and requests IMDNs to a 1376 list who's member information is not disclosed. In this situation, 1377 the user will learn of the list members. Therefore, in this case, 1378 the URI-List server MUST remove any information about list members. 1379 If the number of members in the list is also not disclosed, the URL- 1380 List server MUST only deliver one aggregated IMDN. Alternatively, 1381 the URI-list server MAY reject the IM. 1383 An unencrypted IMDN could reveal confidential information about an 1384 encrypted IM. It is a MUST that the same level of security applied 1385 to an IM to be applied to its IMDNs. For example, if an IM is signed 1386 and encrypted, and IMDN must also be signed and encrypted. 1388 14.3. Non-Repudiation 1390 IMDNs cannot be relied on as a guarantee that an IM was or was not 1391 seen by the user. Even if IMDNs are not actively forged, they may be 1392 lost in transit. The IMDN issuing mechanism may be bypassed in some 1393 manner by the IM Recipient. 1395 15. IANA Considerations 1397 15.1. message/imdn+xml MIME TYPE 1399 This document registers a new MIME type "message/imdn+xml", and 1400 registers a new XML namespace. 1402 This specification follows the guidelines of RFC3023 [6]. 1404 MIME media type: message 1406 MIME subtype name: imdn+xml 1408 Mandatory parameters: none 1410 Optional parameters: Same as charset parameter application/xml as 1411 specified in RFC 3023 [6]. 1413 Encoding considerations: Same as encoding considerations of 1414 application/xml as specified in RFC 3023 [6]. 1416 Security considerations: See section 10 of RFC 3023 [6] and 1417 Section 14 of this document. 1419 Interoperability considerations: none. 1421 Published specification: This document. 1423 Applications which use this media type: This document type is used to 1424 support SIP and MSRP based instant messaging. 1426 Additional information: None 1428 Magic number: None 1430 File extension: .cl or .xml 1432 Macintosh file type code: "TEXT" 1434 Personal and email address for further information: Hisham Khartabil 1435 (hisham.khartabil@telio.no) 1437 Intended Usage: COMMON 1439 Author/change controller: The IETF . 1441 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 1443 This section registers a new XML namespace, as per guidelines in the 1444 IETF XML Registry [3]. 1446 URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. 1448 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1449 (hisham.khartabil@telio.no) . 1451 15.3. Schema Registration 1453 This section registers a new XML schema per the procedures in [3]. 1455 URI: urn:ietf:params:xml:ns:imdn 1457 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1458 (hisham.khartabil@telio.no) 1460 The XML for this schema can be found as the sole content of 1461 Section 11.3. 1463 15.4. Message/CPIM Header Field registration 1465 This document registers the following message/cpim header fields in 1466 the cpim-headers registry: 1468 Disposition-Notification - [RFCXXXX] 1470 Message-ID - [RFCXXXX] 1472 Original-To - [RFCXXXX] 1473 IMDN-Record-Route - [RFCXXXX] 1475 IMDN-Route - [RFCXXXX]. 1477 15.5. Content-Disposition: notification 1479 This document registers one new Content-Disposition header 1480 "disposition-types": notification. The authors request that this 1481 values be recorded in the IANA registry for Content-Dispositions. 1482 Descriptions of this "disposition-types", including motivation and 1483 examples, are given in Section 7.2.1.1 and Section 9. Short 1484 descriptions suitable for the IANA registry are: notification the 1485 body of the message is a notification according to an earlier request 1486 for a disposition notification to an instant message 1488 16. Acknowledgements 1490 The authors would like to thank Paul Kyzivat, Ben Campbell, Adam 1491 Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia and 1492 Eric McMurry for their comments and support. 1494 17. References 1496 17.1. Normative References 1498 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1499 Levels", BCP 14, RFC 2119, March 1997. 1501 [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 1502 (CPIM): Message Format", RFC 3862, August 2004. 1504 [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 1506 [4] Moats, R., "The URN Syntax", RFC 2141, May 1997. 1508 [5] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, 1509 August 1999. 1511 [6] Murata, M., "XML Media Types", RFC 3023, March 1997. 1513 [7] Bray, T., "Extensible Markup Language (XML) 1.0 (Second 1514 Edition)", W3C CR CR-xml11-20011006, October 2000. 1516 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", 1517 RFC 2633, June 1999. 1519 17.2. Informative References 1521 [9] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, 1522 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 1523 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1525 [10] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, 1526 December 2002. 1528 [11] Campbell, B., "The Message Session Relay Protocol", 1529 draft-ietf-simple-message-sessions-15, June 2006. 1531 [12] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1532 April 2001. 1534 [13] Fajman, R., "An Extensible Message Format for Message 1535 Disposition Notifications", RFC 2298, March 1998. 1537 [14] Niemi, A., "Multi-part IM Sessions Using MSRP", 1538 draft-niemi-simple-chat-04, February 2006. 1540 [15] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 1541 Requests in SIP", draft-ietf-sip-uri-list-message-00.txt, 1542 September 2006. 1544 Authors' Addresses 1546 Eric Burger 1547 Cantata Technology 1548 18 Keewaydin Dr. 1549 Salem, NH 03079-2839 1550 USA 1552 Phone: +1 603 890 7587 1553 Fax: +1 603 457 5944 1554 Email: eburger@cantata.com 1556 Hisham Khartabil 1557 Telio 1558 P.O. Box 1203 Vika 1559 Oslo 0110 1560 Norway 1562 Phone: +47 2167 3544 1563 Email: hisham.khartabil@telio.no 1565 Full Copyright Statement 1567 Copyright (C) The Internet Society (2006). 1569 This document is subject to the rights, licenses and restrictions 1570 contained in BCP 78, and except as set forth therein, the authors 1571 retain all their rights. 1573 This document and the information contained herein are provided on an 1574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1576 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1577 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1578 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1581 Intellectual Property 1583 The IETF takes no position regarding the validity or scope of any 1584 Intellectual Property Rights or other rights that might be claimed to 1585 pertain to the implementation or use of the technology described in 1586 this document or the extent to which any license under such rights 1587 might or might not be available; nor does it represent that it has 1588 made any independent effort to identify any such rights. Information 1589 on the procedures with respect to rights in RFC documents can be 1590 found in BCP 78 and BCP 79. 1592 Copies of IPR disclosures made to the IETF Secretariat and any 1593 assurances of licenses to be made available, or the result of an 1594 attempt made to obtain a general license or permission for the use of 1595 such proprietary rights by implementers or users of this 1596 specification can be obtained from the IETF on-line IPR repository at 1597 http://www.ietf.org/ipr. 1599 The IETF invites any interested party to bring to its attention any 1600 copyrights, patents or patent applications, or other proprietary 1601 rights that may cover technology that may be required to implement 1602 this standard. Please address the information to the IETF at 1603 ietf-ipr@ietf.org. 1605 Acknowledgment 1607 Funding for the RFC Editor function is provided by the IETF 1608 Administrative Support Activity (IASA).