idnits 2.17.1 draft-ietf-simple-imdn-04.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 1609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1633. 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 (May 15, 2007) is 6191 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1509 ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Duplicate reference: RFC3023, mentioned in '7', was also mentioned in '5'. ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '10') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3798 (ref. '11') (Obsoleted by RFC 8098) == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-01 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 12 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: November 16, 2007 May 15, 2007 7 Instant Message Disposition Notification 8 draft-ietf-simple-imdn-04 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 November 16, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Instant Messaging (IM) refers to the transfer of messages between 42 users in real-time. This document provides a mechanism whereby 43 endpoints can request Instant Message Disposition Notifications 44 (IMDN), including delivery, processing and read notifications, for 45 page-mode instant messages. 47 The Common Profile for Instant Messaging (CPIM) data format specified 48 in RFC 3862 is extended with new header fields that enable endpoints 49 to request IMDNs. A new message format is also defined to convey 50 IMDNs. 52 This document also describes how SIP entities behave using this 53 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 Field Namespace . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 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. Keeping State . . . . . . . . . . . . . . . . . . . . 11 77 7.1.4. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 19 84 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 19 85 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 20 87 11.1.1. The Element . . . . . . . . . . . . . . . 20 88 11.1.2. The Element . . . . . . . . . . . . . . . . 20 89 11.1.3. The Element . . . . . . . . . . . . . 20 90 11.1.4. The Element . . . . . . . . . 21 91 11.1.5. The Element . . . . . . . . . . . . . . . . 21 92 11.1.6. The Element . . . . . . . . . . . . . . 21 93 11.1.7. The Element . . . . . . . . . . . . . . . . . 21 94 11.1.8. The Element . . . . . . . . . . . . . . . . . . 21 95 11.2. MIME Type for IMDN Payload . . . . . . . . . . . . . . . . 21 96 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 21 97 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 25 98 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 25 99 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 25 100 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 26 101 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 26 102 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 103 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 28 104 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 105 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 106 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 107 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 108 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 109 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 32 110 15.2. URN Sub-Namespace Registration for 111 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32 112 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 33 113 15.4. Registration for urn:ietf:params:imdn . . . . . . . . . . 33 114 15.5. Message/CPIM Header Field Registration . . . . . . . . . . 33 115 15.6. Content-Disposition: notification . . . . . . . . . . . . 34 116 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 117 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 118 17.1. Normative References . . . . . . . . . . . . . . . . . . . 34 119 17.2. Informative References . . . . . . . . . . . . . . . . . . 35 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 121 Intellectual Property and Copyright Statements . . . . . . . . . . 37 123 1. Introduction 125 In many user-to-user message exchange systems, message senders often 126 wish to know if the human recipient actually received or read a 127 message. 129 Electronic Mail [10] deals with this situation with Message Delivery 130 Notifications [11]. After the recipient views the message, her mail 131 user agent generates a Message Delivery Notification, or MDN. The 132 MDN is an e-mail that follows the format prescribed by RFC3798 [11]. 133 The fixed format ensures that an automaton can process the message. 135 Message/CPIM [2] is a message format used to generate instant 136 messages. SIP [8] can carry instant messages generated using 137 message/CPIM in SIP MESSAGE requests [9]. 139 This document extends Message/CPIM message format (much like Message 140 Delivery Notifications extends Electronic Mail) to enable Instant 141 Message Senders to request, create and send Instant Message 142 Disposition Notifications (IMDN). This mechanism works for a page- 143 mode as well as session mode instant messages. This document only 144 discusses page-mode. Session mode is left as future standardisation 145 efforts. 147 IMDNs include positive delivery, negative delivery (i.e. a message 148 did not get delivered successfully), read notifications as well as 149 processed notifications. By using CPIM header fields, the IMDN 150 request and delivery are abstracted outside the transport protocol 151 allowing interoperability between 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 [1]. 159 3. Terminology 161 o IM: An Instant Message generated using the Message/CPIM format. 163 o IMDN: An Instant Message Disposition Notification generated using 164 the Message/CPIM format that carries a IMDN XML document. 166 o Message: an IM or an IMDN generated using the Message/CPIM format. 168 o IM Sender: An endpoint (User Agent) generating and sending an IM. 169 It is also the endpoint that requests IMDNs for an IM. Quite 170 often, the IM Sender is the IMDN Recipient, but that is not always 171 true since an IM Sender's Address of Record (AoR) placed in the IM 172 and in turn used in the IMDN may in fact resolve to different User 173 Agents. This is an artifact of the nature of page-mode IMs. 175 o IM Recipient: An endpoint (User Agent) that receives IMs. It is 176 also the endpoint that generates and sends IMDNs to IMs, if 177 requested by the IM Sender. 179 o Endpoint: An IM Sender or an IM Recipient. 181 o Intermediary: An entity in the network that is on the path of an 182 IM to its final destination. 184 o IMDN Payload: An XML document carrying the disposition 185 notification information. In this specification, it is of MIME 186 type "message/imdn+xml". 188 o Disposition type: the type of IMDN that can be requested. This 189 specification defines three, namely "delivery", "processing" and 190 "read" disposition types. 192 o Transport Protocol Message: A SIP or other protocol message that 193 contains an IM or IMDN. 195 4. Overview 197 The basic protocol flow is depicted in the diagram below. An IM 198 Sender creates an IM, adds IMDN request information the IM Sender is 199 interested in receiving, then sends IM. At a certain point in time, 200 the IM Recipient or an intermediary determines that the user or 201 application has received, did not receive, read, or otherwise 202 disposed the IM. The mechanism by which an IM Recipient determines 203 its user has read an IM is beyond the scope of this document. At 204 that point, the IM Recipient or intermediary automatically generates 205 a notification message to the IM Sender. This notification message 206 is the Instant Message Disposition Notification (IMDN). 208 +--------------+ +--------------+ 209 | IM Sender | | IM Recipient | 210 |IMDN Recipient| | IMDN Sender | 211 +--------------+ +--------------+ 212 | | 213 | | 214 | 1. IM requesting IMDN | 215 |-------------------------------------->| 216 | | 217 | | 218 | 2. IMDN (disposition) | 219 |<--------------------------------------| 220 | | 221 | | 223 Note that the recipient of an IMDN, in some instances, may not be the 224 IM Sender. This is specifically true for page-mode IMs where the 225 Address of Record (AOR) of the IM Sender, that is present in the 226 IMDN, resolves to a different location or user agent to where the IM 227 originated. For simplicity, the rest of this document assumes that 228 the IM Sender and the IMDN Recipient are the same and therefore will 229 refer to both as the IM Sender. 231 5. Disposition Types 233 There are three broad categories of disposition states. They are 234 delivery, processing and read. Future extensions may introduce 235 others. 237 5.1. Delivery 239 The delivery notification type indicates whether the IM has been 240 delivered to the IM Recipient or not. The delivery notification type 241 can have the following states: 243 o "delivered" to indicate successful delivery. 245 o "failed" to indicate failure in delivery. 247 o "forbidden" indicate denial for the IM Sender to receive the 248 requested IMDN. The "forbidden" state can be sent by the IM 249 Recipient but is mainly sent by an intermediary that is configured 250 to do so. For example, the administrator has disallowed IMDNs. 252 o "error" to indicate an error in determining the fate of an IM. 254 5.2. Processing 256 The processing notification type indicates that an IM has been 257 processed by an intermediary. The processing notification type can 258 have the following states: 260 o "processed" is a general state of the IM indicating that the 261 intermediary has performed its task on the IM. 263 o "stored" state indicates that the IM has been stored by the 264 intermediary for later delivery. 266 o "forbidden" indicate denial for the IM Sender to receive the 267 requested IMDN. The "forbidden" state is sent by an intermediary 268 that is configured to do so. For example, the administrator has 269 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: 279 o "read" is a state indicating that the IM has been displayed or 280 played to the user. 282 o "forbidden" indicate denial, by the IM Recipient, for the IM 283 Sender to receive the requested IMDN. 285 o "error" to indicate an error in determining the fate of an IM. 287 Some IMs may in fact be audio, video or still images. Therefore, the 288 state "read" includes playing the audio or video file to the user. 290 Since there is no positive acknowledgement from the user, one cannot 291 determine a priori that the user actually read the IM. Thus one 292 cannot use the protocol described here as a non-repudiation service. 294 6. New CPIM Header Fields 296 This specification extends the CPIM data format specified in RFC 3862 297 [2]. A new namespace is created as well as a number of new CPIM 298 header fields. 300 6.1. CPIM Header Field Namespace 302 Per CPIM [2], this specification defines a new namespace for the CPIM 303 extension header fields defined in the following sections. The 304 namespace is: 306 urn:ietf:params:imdn 308 As per CPIM [2] requirements, the new header fields defined in the 309 following sections are prepended, in CPIM messages, by a prefix 310 assigned to the URN through the NS header field of the CPIM message. 311 The remaining of this specification always assumes an NS header field 312 like this one: 314 NS: imdn . 316 6.2. Disposition-Notification 318 The Disposition-Notification header field is used by the IM Sender to 319 indicate the desire to receive IMDNs, from the IM Recipient, for that 320 specific IM. This header field is not needed if the IM Sender does 321 not request an IMDN. The syntax is defined in Section 10. 323 6.3. Message-ID 325 The Message-ID header field contains a globally unique message 326 identifier that is used by the IM Sender to correlate received IMDNs 327 by comparing its value with the value of the element 328 present in the IMDN payload. This header field is MANDATORY when 329 sending an IM and requesting an IMDN. IMDNs also carry this header 330 field. The syntax is defined in Section 10. 332 6.4. Original-To 334 The Original-To header field is sometimes added to an IM by an 335 intermediary and populated with the address of the IM Receiver. It 336 is used by the IM Recipient to indicate in the IMDNs (by populating 337 the element) the original address the IM was 338 sent to. This header field is mandatory if the intermediary changes 339 the CPIM To header field value. The header field MUST NOT appear 340 more than once in an IM. The header field value MUST NOT be changed 341 by an intermediary if it was already present. The syntax is defined 342 in Section 10. 344 6.5. IMDN-Record-Route 346 Intermediaries have the capability of indicating that IMDNs should be 347 sent through it (otherwise, IMDNs will not visit the intermediary). 349 An intermediary that request IMDNs to be sent through itself adds an 350 IMDN-Record-Route header field to the IM. The value of the IMDN- 351 Record-Route header field is set to the address of that intermediary. 352 Multiple IMDN-Record-Route header fields can appear in an IM. The 353 syntax is defined in Section 10. 355 6.6. IMDN-Route 357 The IMDN-Route header field provides routing information by including 358 one or more addresses where an IMDN must be routed through. On 359 creating an IMDN, an IM recipient copies the contents of the IMDN- 360 Record-Route present in the IM into the IMDN-Route of the IMDN. 361 Multiple IMDN-Route header fields can appear in an IMDN. The syntax 362 is defined in Section 10. 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 [2]. 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 32 bits of randomness. This header 378 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 may not implement the concept of "Sent Items" box and 384 therefore no information about an IM is stored. It is therefore 385 necessary to add a time stamp in the IM to indicate when it was sent. 386 This time stamp is returned in the IMDN in order to enable the user 387 to correlate the IM with the IMDN at the human level. The DateTime 388 header field is used for this purpose. The IM MUST contain a 389 DateTime header field if an IMDN is requested. 391 7.1.1.3. Adding a Disposition-Notification Header Field 393 The Disposition-Notification conveys the type of disposition 394 notification requested by the IM sender. There are three types of 395 disposition notification: delivery, processing, and read. The 396 delivery notification is further subdivided into failure and success 397 delivery notifications. An IM Sender requests failure delivery 398 notification by including a Disposition-Notification header field 399 with value "negative-delivery". Similarly, a success notification is 400 requested by including a Disposition-Notification header field with 401 value "positive-delivery". Both types of delivery notifications can 402 be requested for the same IM. 404 The IM Sender can request a processing notification by including a 405 Disposition-Notification header field with value "processing". 407 The IM Sender can also request a read notification. It is requested 408 by including a Disposition-Notification header field with value 409 "read". 411 The absence of this header field or the presence of the header field 412 with empty value indicates that the IM Sender is not requesting any 413 IMDNs. The Disposition-Notification header field values can be comma 414 separated. The IM Sender MAY request more than one type of IMDN for 415 a single IM. 417 Future extension may define other disposition notifications not 418 defined in this document. 420 The formal syntax of the Disposition-Notification header field can be 421 found in Section 10. The following is an example CPIM body of an IM 422 where the IM Sender requests positive and negative delivery 423 notifications, but not read notification nor processing 424 notifications: 426 From: Alice 427 To: Bob 428 NS: imdn 429 imdn.Message-ID: 34jk324j 430 DateTime: 2006-04-04T12:16:49-05:00 431 imdn.Disposition-Notification: positive-delivery, negative-delivery 432 Content-type: text/plain 433 Content-length: 12 435 Hello World 437 7.1.2. Matching IMs with IMDNs 439 An IM Sender matches an IMDN to an IM by matching the Message-ID 440 header field value in the IM with the element value in 441 the body of the IMDN. If the IM was delivered to multiple 442 recipients, the IM Sender uses the element and the 443 element in the XML body of the IMDN it 444 received to determine if the IM was sent to multiple recipients and 445 to identify the IM Recipient that sent the IMDN. 447 7.1.3. Keeping State 449 This specification does not mandate the IM Sender to keep state for a 450 sent IM. 452 Once an IM Sender sends an IM containing an IMDN request, it MAY 453 preserve the IM context, principally the Message-ID, and other user- 454 identifiable information such as the IM subject or content, and date 455 and time it was sent. Without preservation of the IM context, the IM 456 Sender will not be able to correlate the IMDN with the IM it sent. 457 The IM Sender may find it impossible to preserve IM state if it has 458 limited resources or does not have non-volatile memory and then loses 459 power. 461 There is, however, the concept of "Sent Items" box in an application 462 that stores sent IMs. This "Sent Items" box has the necessary 463 information and may have a fancy user interface indicating the state 464 of a sent IM. Unique Message-ID for this purpose proves to be 465 useful. The length of time for items to remain in the "Sent Items" 466 box is a user choice. The user is usually free to keep or delete 467 items from the "Sent Items" box as she pleases or as the memory on 468 the device reaches capacity. 470 Clearly, if an IM Sender loses its sent items state (user deletes 471 items from the "Send Items" box), the client may use a different 472 display strategy in response to apparently unsolicited IMDNs. 474 This specification also does not mandate an IM Sender to run any 475 timers waiting for an IMDN. There are no time limits associated with 476 when IMDNs may be received. 478 IMDNs may legitimately never be received. On the other hand, and 479 IMDN may simply take a very long time. Some clients may choose to 480 purge the state associated with the sent IM. This is the reason for 481 adding the time stamp in the IM and having it returned in the IMDN. 482 This gives the user some opportunity of remembering what IM was sent. 483 For example if the IMDN indicates that the IM the user sent at 2 p.m. 484 last Thursday was delivered, the user has a chance of remembering 485 that they sent an IM at 2 p.m. last Thursday. 487 7.1.4. Aggregation of IMDNs 489 An IM Sender may send an IM to multiple recipients in one Transport 490 Protocol Message (typically using a URI-List server) and request 491 IMDNs. An IM Sender that requested IMDNs MUST be prepared to receive 492 multiple aggregated or non-aggregated IMDNs. See Section 8.2 for 493 details. 495 7.2. IM Recipient 497 7.2.1. Constructing IMDNs 499 IM recipients examine the contents of the Disposition-Notification 500 header field of the CPIM message to determine if an IMDN must be 501 generated for that IM. Disposition-Notification header fields of 502 CPIM messages can include one or more values. This implies that IM 503 recipients may need to generate zero, one, or more IMDNs for that IM, 504 for example a delivery notification as well as a read notification. 505 In this case the IM Recipient MUST be able to construct multiple 506 IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN 507 per disposition type. I.e. It must not, for example, generate a 508 delivery notification indicating "delivered" then followed by a 509 delivery notification indicating "failed" for the same IM. If the IM 510 Sender requested only failure notifications and the IM was 511 successfully delivered, then no IMDNs will be generated. 513 The IM Recipient MUST NOT generate "processing" notifications. 515 Disposition-Notification header field MUST NOT appear in an IMDN 516 since it is forbidden to request an IMDN for an IMDN. IM Sender MUST 517 ignore it if present. The IM Sender MUST NOT send an IMDN to an 518 IMDN. 520 An IMDN MUST contain a Message-ID header field. The same rules of 521 uniqueness for the Message-ID header field that appears in an IM 522 apply to an IMDN. The Message-ID header field in the IMDN is 523 different and unrelated to the one in the IM. 525 An IM may contain a IMDN-Record-Route header field (see Section 8 for 526 details). If IMDN-Record-Route header fields appear in the IM, the 527 IM Recipient constructing the IMDN MUST copy the contents of the 528 IMDN-Record-Route header fields into IMDN-Route header fields in the 529 IMDN and maintain the order. The IMDN is then sent to the URI in the 530 top IMDN-Route header field. IMDN-Record-Route header fields do not 531 make sense in an IMDN and therefore SHOULD NOT be placed in an IMDN. 532 IMDN Recipients SHOULD ignore it if present. 534 The CPIM Content-Disposition header field must be set to the value 535 "notification". This indicates to the IM Sender that the message is 536 an IMDN to an IM it has earlier sent. 538 7.2.1.1. Constructing Delivery Notifications 540 A delivery notification is constructed in a similar fashion as an IM, 541 using a CPIM body [2] that carries a Disposition Notification XML 542 document formatted according to the rules specified in Section 11. 543 The MIME type of the Disposition Notification XML document is 544 "message/imdn+xml". 546 An example CPIM body of IMDN looks like the following: 548 From: Bob 549 To: Alice 550 NS: imdn 551 imdn.Message-ID: d834jied93rf 552 Content-type: message/imdn+xml 553 Content-Disposition: notification 554 Content-length: ... 556 557 558 34jk324j 559 2006-04-04T12:16:49-05:00 560 im:bob@example.com 561 562 im:bob@example.com 563 564 565 566 567 568 569 The IM was successfully Delivered 570 572 7.2.1.2. Constructing Read Notifications 574 A read notification is constructed in a similar fashion as the 575 delivery notification. See Section 7.2.1.1 for details. 577 An example looks like the following: 579 From: Bob 580 To: Alice 581 NS: imdn 582 imdn.Message-ID: dfjkleriou432333 583 Content-type: message/imdn+xml 584 Content-Disposition: notification 585 Content-length: ... 587 588 589 34jk324j 590 2006-04-04T12:16:49-05:00 591 im:bob@example.com 592 593 im:bob@example.com 594 595 596 597 598 599 600 The IM has been read 601 603 There are situations where the IM Recipient cannot determine if or 604 when the IM has been read. The IM Recipient in this case generates a 605 read notification with a value of "error" to indicate an 606 internal error by the server. Note that the IM Recipient may choose 607 to ignore any IMDN requests and not to send any IMDNs. An example of 608 this is when a SIP stack with built in IMDN support is talking to an 609 IM application and the IM application never returned indicating that 610 it has displayed the IM to the user. 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. 616 A gateway is a server the translates between different IM systems 617 that use different protocols. 619 A URI-List server may change the IM Recipient address from its own to 620 the address of the final recipient of that IM for every copy it makes 621 to be sent to the list members (see [13] for details). In this case, 622 if the IM Sender is requesting an IMDN, the intermediary MUST add an 623 Original-To header field to the IM populating it with the address 624 that was in the CPIM To header field before it was changed. I.e. 625 The Original-To header field is populated with the intermediary 626 address. An intermediary MUST NOT add an Original-To header field if 627 one already exists. 629 An intermediary MAY choose to remain on the path of IMDNs for a 630 specific IM. It can do so by adding a CPIM IMDN-Record-Route header 631 field as the top IMDN-Record-Route header field and populating it 632 with its own address. An intermediary that does not support this 633 extension will obviously not add the IMDN-Record-Route header field. 634 This allows IMDNs to traverse directly from the IM Recipient to the 635 IM Sender even if the IM traversed an intermediary not supporting 636 this extension. 638 An intermediary receiving an IMDN checks the top IMDN-Route header 639 field. If that header field carries the intermediary address, the 640 intermediary pops that value and forwards the IMDN to the address 641 indicated in the now top IMDN-Route header field. If no IMDN-Route 642 header fields are present, the IMDN is forwarded to the address in 643 the CPIM To header field. 645 An intermediary MUST remove any information about the final 646 recipients of a list if the list membership is not disclosed. The 647 intermediary does that by removing the element and/or 648 element from the body of the IMDN before 649 forwarding it to the IM Sender. 651 8.1. Constructing Processing Notifications 653 Intermediaries are the only entities that construct processing 654 notifications. They do so only if the IM Sender has requested a 655 "processing" notification by including a Disposition-Notification 656 header field with value "processing". 658 The intermediary can create and send "processing" notifications 659 indicating that an IM has been processed or stored. The intermediary 660 MUST NOT send more than one IMDN for the same disposition type. I.e. 661 It must not send a "processing" notification indicating that an IM is 662 being "processed" followed by another IMDN indicating that the same 663 IM is "stored". 665 A "processing" notification is constructed in a similar fashion as 666 the delivery notification. See Section 7.2.1.1 for details. 668 An example looks like the following: 670 Content-type: Message/CPIM 672 From: Bob 673 To: Alice 674 Content-type: message/imdn+xml 675 Content-Disposition: notification 676 Content-length: ... 678 679 34jk324j 680 2006-04-04T12:16:49-05:00 681 im:bob@example.com 682 683 im:bob@example.com 684 685 686 687 688 689 690 The IM has been processed 691 693 There are situations where the intermediary cannot know the fate of 694 an IM. The intermediary in this case generates a processing 695 notification with a value of "error" to indicate so. 697 8.2. Aggregation of IMDNs 699 In this context, URI-List servers are defined as intermediaries. 701 An intermediary may choose to aggregate IMDNs using local policy for 702 making such a decision or it may send individual IMDNs instead. When 703 a URI-List server receives an IM and decides to aggregate IMDNs, it 704 can wait for a configurable period of time or until all recipients 705 have sent the IMDN (whichever comes first) before the URI-List server 706 sends an aggregated IMDN. Note that some IMDNs, for example read 707 notifications, may never come due to user settings. It is an 708 administrator configuration and an implementation issue how long to 709 wait before sending an aggregated IMDN and before a URI-List server 710 removes state for that IM. 712 A URI-List server MAY choose to send multiple aggregated IMDNs. A 713 timer can be started and when it fires, the URI-List server can 714 aggregate whatever IMDNs it has so far for that IM, send the 715 aggregated IMDN and restart the timer for the next batch. This is 716 needed for scenarios where the IM Sender has requested more than one 717 IMDN for a specific IM, for example, delivery notifications as well 718 as read notifications, or when the URI-List server is short on 719 resources and chooses to prioritise forwarding IMs over IMDNs. 721 A second timer can be running and when it fires, the state of the IM 722 is deleted. In this case, the URI-List server consumes any IMDNs 723 that might arrive after that time. 725 Please note that the references to timers in the above paragraphs are 726 not normative and are only present to help describe one way 727 aggregation might be implemented. 729 A URI-List server MAY aggregate IMDNs for the case where the list 730 membership information is not disclosed. There may be scenarios 731 where the URI-List server starts sending aggregated IMDNs and switch 732 to individual ones or visa versa. A timer firing so often may in 733 fact have that effect. 735 The aggregated IMDN is constructed using the multipart/mixed MIME 736 type and including all the received IMDNs as message/imdn+xml as 737 individual payloads. 739 Below is an example of aggregated IMDNs. 741 From: Bob 742 To: Alice 743 NS: imdn 744 imdn.Message-ID: d834jied93rf 745 Content-type: multipart/mixed; 746 boundary="imdn-boundary" 747 Content-Disposition: notification 748 Content-length: ... 750 --imdn-boundary 751 Content-type: message/imdn+xml 753 754 755 34jk324j 756 2006-04-04T12:16:49-05:00 757 im:bob@example.com 758 759 im:bob@example.com 760 761 762 763 764 765 766 The IM was successfully Delivered 767 769 --imdn-boundary 770 Content-type: message/imdn+xml 772 773 774 34jk324j 775 2006-04-04T12:16:49-05:00 776 im:bob@example.com 777 778 im:bob@example.com 779 780 781 782 783 784 785 The IM was successfully Delivered 786 788 --imdn-boundary 790 9. Identifying Messages 792 Messages are typically carried in a transport protocol like SIP [8]. 793 If the payload carried by the transport protocol does not contain any 794 parts of type Message/CPIM then the message is an IM. If the payload 795 contains any parts of type Message/CPIM, and none of those parts 796 contains a payload that is of type "message/imdn+xml", the message is 797 an IM. It is not valid to attempt to carry both an IM and an IMDN in 798 a multipart payload in a single transport protocol message. 800 A message is identified as a delivery notification by examining its 801 contents. The message is a delivery notification if the Content-type 802 header field present has a value of "message/imdn+xml", the Content- 803 Disposition header field has a value of "notification", and the 804 element in that xml body has a sub-element . 806 A message is identified as a processing notification or read 807 notification in a similar fashion as a delivery notification. The 808 difference is that the element in that xml body has a 809 sub-element of and respectively. 811 10. Header Fields Formal Syntax 813 The following syntax specification uses the message header field 814 syntax as described in Section 3 of RFC3862 [2]. 816 Header field syntax is described without a namespace qualification. 817 Following the rules in RFC3862 [2], header field names and other text 818 are case sensitive and MUST be used as given, using exactly the 819 indicated upper-case and lower-case letters. 821 Disposition-Notification = 822 "Disposition-Notification" ": " 823 [(notify-req *(COMMA notify-req))] 824 notify-req = 825 ("negative-delivery" / "positive-delivery" / 826 "processing" / "read" / Token) *(SEMI disp-notif-params) 828 disp-notify-params = generic-param 830 Message-ID = "Message-ID" ": " Token 832 Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" 834 IMDN-Record-Route = 835 "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" 837 IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 839 11. IMDN Format 841 11.1. Structure of XML-Encoded IMDN Payload 843 An IMDN Payload is an XML document [6] that MUST be well-formed and 844 MUST be valid according to schemas, including extension schemas, 845 available to the validater and applicable to the XML document. The 846 IMDN Payload MUST be based on XML 1.0 and MUST be encoded using 847 UTF-8. 849 The namespace identifier for elements defined by this specification 850 is a URN [4], using the namespace identifier 'ietf' defined by [12] 851 and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. 853 This namespace declaration indicates the namespace on which the IMDN 854 is based. 856 The root element is . The element has sub-elements, 857 namely , , , , , , , and . 859 Those elements are described in details in the following sections. 861 and can be extended in the future to include 862 new sub-elements not defined in this document. Those new elements 863 MUST be defined in an RFC. 865 11.1.1. The Element 867 The element is mandatory according to the XML schema and 868 carries the message id that appeared in the Message-ID header field 869 of the IM. 871 11.1.2. The Element 873 The element is mandatory and carries the date and time the 874 IM was sent (not the IMDN). This information is obtained from the 875 DateTime header field of the IM. 877 11.1.3. The Element 879 The element is optional and carries the URI of the 880 final recipient. This information is obtained from the CPIM To 881 header field of the IM. 883 11.1.4. The Element 885 The element is optional and carries the URI 886 of the original recipient. It MUST be present if the IM carried the 887 Original-To header field. This information is obtained from the 888 Original-To header field of the IM. 890 11.1.5. The Element 892 The element is optional and carries the text that was in 893 the Subject header field, if any. This allows for a human level 894 correlation between an IM and an IMDN. 896 11.1.6. The Element 898 The element is mandatory and carries the disposition 899 type that the IM Sender requested and is being reported. It can 900 carry one of the sub-elements , , or any 901 other future extension. 903 11.1.7. The Element 905 The element is mandatory and carries the result of the 906 disposition request in the element. For disposition 907 type , it can carry one of the sub-elements , 908 , or . For disposition type , it 909 can carry one of the sub-elements , or . 910 For disposition type , it can carry one of the sub- 911 elements , , or . 912 means the disposition was denied. means internal server 913 error. It can also carry any other future extension. 915 11.1.8. The Element 917 The element is optional and carries a human readable text. It 918 has the "lang" attribute that indicates the language the text is 919 written in. 921 11.2. MIME Type for IMDN Payload 923 The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN 924 MUST identify the payload as MIME type "message/imdn+xml" in the 925 Content-type header field. 927 11.3. The RelaxNG Schema 929 930 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 973 974 975 976 977 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1063 1064 1065 1066 1067 1068 lang 1069 1070 1071 1072 1073 1074 1076 1078 1079 1080 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1103 1105 12. Transporting Messages using SIP 1107 12.1. Endpoint Behaviour 1109 12.1.1. Sending Requests 1111 A SIP MESSAGE request is constructed using RFC 3428 [9]. The 1112 Content-type header field indicates the MIME type of the request 1113 payload. When using this extension, the Content-type header field 1114 MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The 1115 payload is constructed according to Section 7. 1117 A SIP MESSAGE request to multiple recipients is constructed in a 1118 similar manner as a SIP MESSAGE request to a single recipient. The 1119 differences are indicated in [13]. 1121 12.1.2. Sending Responses 1123 An endpoint receiving a SIP MESSAGE request constructs a SIP response 1124 according to RFC3428 [9]. Of course, an endpoint will send a 1125 response to the MESSAGE request regardless of they type of message 1126 (IM or IMDN) is has received, or the disposition type it has been 1127 asked for. 1129 12.1.3. Receiving Requests 1131 12.1.3.1. Instant Message 1133 A SIP MESSAGE request is identified as an IM by examining its 1134 contents according to Section 9. 1136 If an IM Recipient received a SIP MESSAGE request that is an IM that 1137 requested a positive-delivery notification, and that IM Recipient has 1138 constructed and sent a SIP 2xx class response, it MAY generate a 1139 positive-delivery notification after making sure that the IM has been 1140 delivered to the user or application (a gateway, for example, can 1141 generate a 2xx response before it has been guaranteed that the final 1142 recipient has actually received the IM). The positive-delivery 1143 notification is constructed according to Section 7.2.1.1. The 1144 message is then placed as the payload in a SIP MESSAGE request. 1146 If an IM Recipient received a SIP MESSAGE request that is an IM that 1147 requested a negative-delivery, and that IM Recipient has constructed 1148 and sent a 2xx class response, it SHOULD generate a negative-delivery 1149 notification if it learnt that the final recipient or application did 1150 not receive the IM (a gateway, for example, can generate a 2xx 1151 response before it has an error response from downstream or before 1152 any internal timers fire waiting for a response). The negative- 1153 delivery notification is constructed according to Section 7.2.1.1. 1154 The message is then placed as the payload in a SIP MESSAGE request. 1156 If an IM Recipient received a SIP MESSAGE request that is an IM that 1157 requested a negative-delivery notification, and the IM Recipient has 1158 constructed and sent an non-2xx final response, it MUST NOT generate 1159 a negative-delivery notification. 1161 If an IM Recipient received a SIP MESSAGE request that is an IM that 1162 requested a read notification, and that IM Recipient has constructed 1163 and sent a SIP 2xx class response, it MAY generate a read 1164 notification after making sure that the IM has been presented to the 1165 user or application. It is outside the scope of this document how 1166 such determination can be made. Note that the option to send a read 1167 notification or not can be left to the user. An application may 1168 allow a user to configure such choice. The read notification is 1169 constructed according to Section 7.2.1.2. The message is then placed 1170 as the payload in a SIP MESSAGE request. 1172 For IMDNs, the SIP Request-URI and the SIP To header field are 1173 populated using the address that appeared in the SIP From header 1174 field in the IM. 1176 12.1.3.2. Delivery Notification 1178 A SIP MESSAGE request is identified as delivery notification by 1179 examining its contents according to Section 9. 1181 12.1.3.3. Read Notification 1183 A SIP MESSAGE request is identified as read notification by examining 1184 its contents according to Section 9. 1186 12.2. Intermediary Behaviour 1188 In this context, application servers (including URI-List servers and 1189 Store-and-Forward server) and gateways are defined as intermediaries. 1190 SIP Proxies MUST NOT generate IMDNs but MUST forward them like any 1191 other sip request. 1193 A SIP MESSAGE request to multiple recipients is forwarded according 1194 to [13]. 1196 If an intermediary generates a SIP 2xx class response to a SIP 1197 MESSAGE request it has received that is an IM, it examines if the 1198 body was of type "message/cpim". If so, it checks the CPIM header to 1199 see if there is the header field Disposition-Notification with a 1200 value "positive-delivery" and/or "negative-delivery". If so, it MUST 1201 send a delivery notification after receiving a transactional final 1202 response for the IM. 1204 If the Disposition-Notification header field contains a value of 1205 "positive-delivery", the intermediary MUST NOT generate a delivery 1206 notification if it receives a SIP 2xx class response for the sent IM. 1207 This is in anticipation of a failure downstream after a 2xx response 1208 has been generated. 1210 If the Disposition-Notification header field contains a value of 1211 "negative-delivery", the intermediary SHOULD generate a delivery 1212 notification if it receives a SIP 4xx, 5xx or 6xx class final 1213 response for the sent IM. If it has received a SIP 2xx class 1214 response followed by a negative-delivery notification, the 1215 intermediary forwards that negative-delivery notification or 1216 aggregates it. 1218 If the Disposition-Notification header field contains a value of 1219 "processing", the intermediary MAY generate a processing notification 1220 after it has forwarded or stored the IM. The rest of the procedures 1221 in Section 8.1 apply. 1223 The procedure for generating such IMDN is the same as that of an IM 1224 Recipient (Section 7.2.1.1). 1226 The element of the XML body is populated with the URI 1227 of the IM Recipient. 1229 If an intermediary receives a SIP MESSAGE request carrying a positive 1230 delivery notification or a read notification, it forwards it using 1231 the rules in Section 8. 1233 13. Transporting Messages using MSRP 1235 MSRP already provides a built-in mechanism to supply positive and 1236 negative delivery reports. 1238 While MSRP does not provide a built-in Read or Processing 1239 notification dispositions, those are generally not considered as 1240 useful information for session IM. This is because the assumption 1241 behind MSRP is that SEND requests do not reach a mailbox where 1242 incoming IMs have to be open, but to an application that renders 1243 sequentially those incoming IMs, providing the session experience. 1244 This kind of applications has no means of identifying when a user has 1245 read the IM and therefore cannot be useful information for the 1246 sender. 1248 IMDN use cases for MSRP have not been fully explored. If new 1249 requirements arise in the future determining the need for IMDN in 1250 MSRP, new specifications can be drafted. 1252 14. Security Considerations 1254 IMDNs provide a fine-grained view of the activity of the IM Recipient 1255 and thus deserves particularly careful confidentiality protection so 1256 that only the intended recipient of the IMDN will receive the IMDN 1257 (in most cases, the intended recipient of the IMDN is the IM Sender). 1259 Since IMDNs are carried by using the IM protocol itself, all security 1260 considerations of the underlying IM protocol also apply to the IMDNs. 1262 The threats in the IMDN system, over and beyond the threats inherent 1263 to IM include the following: 1265 o A malicious endpoint attempts to send messages to a user that 1266 would normally not wish to receive messages from that endpoint by 1267 convincing the IMDN system to "bounce" an IMDN from an 1268 unsuspecting endpoint to the user. 1270 o A malicious endpoint attempts to flood a IM Sender with IMDNs by 1271 convincing a URI-List server to send IMDNs to an unsuspecting IM 1272 Sender. 1274 o A malicious node in the network that attempts to modify an IMDN 1275 from a IM Recipient. 1277 o A malicious intermediary attempts to forward an IMDN from an IM 1278 Recipient to the IM Sender, where the IM Recipient would not 1279 normally forward the IMDN to that IM Sender if the IM Recipient 1280 knew the identity of the IM Sender. 1282 o A malicious endpoint that attempts to fish for a Request-URI of an 1283 endpoint beyond an intermediary , where the endpoint would 1284 normally wish to keep its identity private from the malicious 1285 endpoint. 1287 o A malicious node in the network that attempts to eavesdrop on IMDN 1288 traffic to, for example, learn Request-URI or traffic pattern 1289 information. 1291 o A malicious node in the network attempts to stage a denial of 1292 service attack on an intermediary by requesting a large list 1293 expansion. 1295 The protocol cannot protect against attacks that include the 1296 following: 1298 o A malicious intermediary directly revealing the identity of a 1299 downstream endpoint that would not normally wish its identity 1300 revealed. Keeping such information private is an intermediary 1301 implementation issue. 1303 o A malicious IM Recipient that alters the time of the IMDN. There 1304 is no protocol mechanism for ensuring that the IM Recipient does 1305 not lie about the time or purposely holds an IMDN for transmission 1306 to make it appear that the user read an IM later than they 1307 actually did. 1309 o A deletion attack on an IMDN. This is a trade-off between privacy 1310 and security. The privacy considerations allow the IM Recipient 1311 to silently ignore an IMDN request. Any mechanism that would 1312 reliably indicate that a malicious node deleted a IM Recipient's 1313 IMDN would also serve the purpose of detecting a IM Recipient that 1314 chose not to issue an IMDN. 1316 To combat eavesdropping, modification, and man-in-the-middle attacks, 1317 we require some level of authentication and integrity protections. 1318 That said, there are circumstances where strong integrity would be 1319 overkill. The presumption is the IM Sender has and sets the 1320 expectation for the level of protection. The procedures for 1321 integrity protection are as follows. 1323 o If the IM Recipient has a certificate, it MUST sign the IMDN. 1325 o If the IM is encrypted, the IM Recipient or intermediary MUST 1326 encrypt the IMDN body, as an attacker may attempt to discern the 1327 user's activity profile and identity from sniffing IMDNs on the 1328 network. 1330 o The two above rules are cumulative. 1332 The IM Recipient or intermediary MUST be capable of accessing the IM 1333 Sender's public certificate in order to verify the signature in the 1334 IM. 1336 An attacker can mount a distributed denial of service attack on a 1337 node by sending lots of IMs to the node with IMDN requests. Note 1338 that this is the same problem as there is without IMDN; IMDN simply 1339 linearly increases the load on the node under attack. One can 1340 mitigate, but not eliminate this threat by the endpoint immediately 1341 ignoring requests that are not authenticated. 1343 Likewise, an attacker can mount a denial of service attack on an 1344 intermediary by asking the intermediary to explode a large list. 1346 The following security considerations apply when using IMDNs: 1348 14.1. Forgery 1350 IMs can be forged. To protect against that, an IM can be signed. An 1351 intermediary that receives a signed message and needs to modify any 1352 part of it that is included in the signature (like adding an 1353 Original-To header field to the CPIM header fields), MUST consume the 1354 IM and create a new copy of it that the intermediary signs itself. 1356 IMDNs may be forged as easily as ordinary IMs. Endpoints and 1357 intermediaries that wish to make automatic use of IMDNs should take 1358 appropriate precautions to minimize the potential damage from denial- 1359 of-service attacks. Security threats related to forged IMDNs include 1360 the sending of a falsified IMDN when the indicated disposition of the 1361 IM has not actually occurred. For example, read notification could 1362 be forged to indicate that a IM Recipient has read the IM. 1363 Unsolicited IMDNs is also another form of forgery. 1365 14.2. Confidentiality 1367 There may be cases where an IM Recipient does not wish to reveal the 1368 information that he has received or in fact read the IM. In this 1369 situation, it is acceptable for the IM Recipient to silently ignore 1370 requests for an IMDN. It is strongly RECOMMENDED that the IM 1371 Recipient obtain the user's consent before sending an IMDN. 1372 Circumstances where the IM Recipient does not ask for the user's 1373 consent include IM systems that, for regulatory reasons, are required 1374 to issue an IMDN, such as in the health care field or financial 1375 community. 1377 An IM Recipient can obtain such consent by a prompt or dialog box on 1378 a per-IM basis, globally through the user's setting of a preference, 1379 or other, user-configurable mechanism. The user might also indicate 1380 globally that IMDNs are never to be sent or that a "forbidden" IMDN 1381 status is always sent in response to a request for an IMDN. 1383 There are situations where a user sends an IM and requests IMDNs to a 1384 list who's member information is not disclosed. In this situation, 1385 the user will learn of the list members. Therefore, in this case, 1386 the URI-List server MUST remove any information about list members. 1387 If the number of members in the list is also not disclosed, the URL- 1388 List server MUST only deliver one aggregated IMDN. Alternatively, 1389 the URI-list server MAY reject the IM. 1391 An unencrypted IMDN could reveal confidential information about an 1392 encrypted IM. It is a MUST that the same level of security applied 1393 to an IM to be applied to its IMDNs. For example, if an IM is signed 1394 and encrypted, and IMDN must also be signed and encrypted. 1396 14.3. Non-Repudiation 1398 IMDNs cannot be relied on as a guarantee that an IM was or was not 1399 seen by the user. Even if IMDNs are not actively forged, they may be 1400 lost in transit. The IMDN issuing mechanism may be bypassed in some 1401 manner by the IM Recipient. 1403 15. IANA Considerations 1404 15.1. message/imdn+xml MIME TYPE 1406 This document registers a new MIME type "message/imdn+xml", and 1407 registers a new XML namespace. 1409 This specification follows the guidelines of RFC3023 [5]. 1411 MIME media type: message 1413 MIME subtype name: imdn+xml 1415 Mandatory parameters: none 1417 Optional parameters: Same as charset parameter application/xml as 1418 specified in RFC 3023 [5]. 1420 Encoding considerations: Same as encoding considerations of 1421 application/xml as specified in RFC 3023 [5]. 1423 Security considerations: See section 10 of RFC 3023 [5] and 1424 Section 14 of this document. 1426 Interoperability considerations: none. 1428 Published specification: This document. 1430 Applications which use this media type: This document type is used to 1431 support CPIM based instant messaging. 1433 Additional information: None 1435 Magic number: None 1437 File extension: .cl or .xml 1439 Macintosh file type code: "TEXT" 1441 Personal and email address for further information: Hisham Khartabil 1442 (hisham.khartabil@gmail.com) 1444 Intended Usage: COMMON 1446 Author/change controller: The IETF . 1448 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 1450 This section registers a new XML namespace, as per guidelines in the 1451 IETF XML Registry [3]. 1453 URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. 1455 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1456 (hisham.khartabil@gmail.com) . 1458 15.3. Schema Registration 1460 This section registers a new XML schema per the procedures in [3]. 1462 URI: urn:ietf:params:xml:ns:imdn 1464 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1465 (hisham.khartabil@gmail.com) 1467 The XML for this schema can be found as the sole content of 1468 Section 11.3. 1470 15.4. Registration for urn:ietf:params:imdn 1472 Registry name: imdn 1474 Specification: RFC XXXX. Additional values may be defined by 1475 standards track RFCs that update or obsolete RFC XXXX (Specification 1476 Required). 1478 Repository: http://www.iana.org/assignments/imdn 1480 Index value: The index value is a CPIM message IMDN header name, 1481 which may consist of a sequence from a restricted set of US-ASCII 1482 characters, as defined above. 1484 URN Formation: The URI for a header is formed from its name by: 1486 a) replacing any non-URN characters (as defined by RFC 2141[4]) 1487 with the corresponding '%hh' escape sequence (per RFC 2396 [7]); 1488 and 1490 b) prepending the resulting string with 'urn:ietf:params:imdn:'. 1492 Thus, the URI corresponding to the CPIM message IMDN header 1493 'Disposition-Notification:' would be 1494 'urn:ietf:params:imdn:Disposition-Notification'. 1496 15.5. Message/CPIM Header Field Registration 1498 This document registers the following message/cpim header fields in 1499 the imdn fields registry: 1501 Disposition-Notification - [RFCXXXX] 1503 Message-ID - [RFCXXXX] 1505 Original-To - [RFCXXXX] 1507 IMDN-Record-Route - [RFCXXXX] 1509 IMDN-Route - [RFCXXXX]. 1511 15.6. Content-Disposition: notification 1513 This document registers one new Content-Disposition header field 1514 "disposition-types": notification. The authors request that this 1515 values be recorded in the IANA registry for Content-Dispositions. 1517 Descriptions of this "disposition-types", including motivation and 1518 examples, are given in Section 7.2.1.1 and Section 9. 1520 Short descriptions suitable for the IANA registry are: 1522 notification the body of the message is a notification according to 1523 an earlier request for a disposition notification to an instant 1524 message 1526 16. Acknowledgements 1528 The authors would like to thank Paul Kyzivat, Ben Campbell, Adam 1529 Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, 1530 Eric McMurry, Jari Urpalainen and Robert Sparks for their comments 1531 and support. 1533 17. References 1535 17.1. Normative References 1537 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1538 Levels", BCP 14, RFC 2119, March 1997. 1540 [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 1541 (CPIM): Message Format", RFC 3862, August 2004. 1543 [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 1545 [4] Moats, R., "The URN Syntax", RFC 2141, May 1997. 1547 [5] Murata, M., "XML Media Types", RFC 3023, March 1997. 1549 [6] Bray, T., "Extensible Markup Language (XML) 1.0 (Second 1550 Edition)", W3C CR CR-xml11-20011006, October 2000. 1552 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "URI: Generic 1553 Syntax", RFC 3023, August 1998. 1555 17.2. Informative References 1557 [8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, 1558 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 1559 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1561 [9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, 1562 December 2002. 1564 [10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1565 April 2001. 1567 [11] Hansen, T. and G. Vaudreuil, "Message Disposition 1568 Notification", RFC 3798, May 2004. 1570 [12] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, 1571 August 1999. 1573 [13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 1574 Requests in SIP", draft-ietf-sip-uri-list-message-01.txt, 1575 January 2007. 1577 Authors' Addresses 1579 Eric Burger 1580 BEA Systems, Inc. 1581 4 Van de Graaff Dr. 1582 Burlington, MA 01803 1583 USA 1585 Phone: +1 781 993 7437 1586 Fax: +1 603 457 5933 1587 Email: eric.burger@bea.com 1588 Hisham Khartabil 1589 Melbourne 1590 Australia 1592 Phone: +61 416 108 890 1593 Email: hisham.khartabil@gmail.com 1595 Full Copyright Statement 1597 Copyright (C) The IETF Trust (2007). 1599 This document is subject to the rights, licenses and restrictions 1600 contained in BCP 78, and except as set forth therein, the authors 1601 retain all their rights. 1603 This document and the information contained herein are provided on an 1604 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1605 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1606 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1607 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1608 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1609 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1611 Intellectual Property 1613 The IETF takes no position regarding the validity or scope of any 1614 Intellectual Property Rights or other rights that might be claimed to 1615 pertain to the implementation or use of the technology described in 1616 this document or the extent to which any license under such rights 1617 might or might not be available; nor does it represent that it has 1618 made any independent effort to identify any such rights. Information 1619 on the procedures with respect to rights in RFC documents can be 1620 found in BCP 78 and BCP 79. 1622 Copies of IPR disclosures made to the IETF Secretariat and any 1623 assurances of licenses to be made available, or the result of an 1624 attempt made to obtain a general license or permission for the use of 1625 such proprietary rights by implementers or users of this 1626 specification can be obtained from the IETF on-line IPR repository at 1627 http://www.ietf.org/ipr. 1629 The IETF invites any interested party to bring to its attention any 1630 copyrights, patents or patent applications, or other proprietary 1631 rights that may cover technology that may be required to implement 1632 this standard. Please address the information to the IETF at 1633 ietf-ipr@ietf.org. 1635 Acknowledgment 1637 Funding for the RFC Editor function is provided by the IETF 1638 Administrative Support Activity (IASA).