idnits 2.17.1 draft-ietf-simple-imdn-03.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 1513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1537. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (February 5, 2007) is 6282 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 1420 ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5') ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '10') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2298 (ref. '11') (Obsoleted by RFC 3798) == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-01 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 Expires: August 9, 2007 H. Khartabil 5 February 5, 2007 7 Instant Message Disposition Notification 8 draft-ietf-simple-imdn-03 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 August 9, 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . 24 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 14. Security Considerations . . . . . . . . . . . . . . . . . . . 27 105 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 29 107 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 30 108 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 109 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 30 110 15.2. URN Sub-Namespace Registration for 111 urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 31 112 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 31 113 15.4. Message/CPIM header field registration . . . . . . . . . . 31 114 15.5. Content-Disposition: notification . . . . . . . . . . . . 32 115 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 116 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 117 17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 118 17.2. Informative References . . . . . . . . . . . . . . . . . . 32 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 120 Intellectual Property and Copyright Statements . . . . . . . . . . 34 122 1. Introduction 124 In many user-to-user message exchange systems, message senders often 125 wish to know if the human recipient actually received or read a 126 message. 128 Electronic Mail [10] deals with this situation with Message Delivery 129 Notifications [11]. After the recipient views the message, her mail 130 user agent generates a Message Delivery Notification, or MDN. The 131 MDN is an e-mail that follows the format prescribed by RFC2298 [11]. 132 The fixed format ensures that an automaton can process the message. 134 Message/CPIM [2] is a message format used to generate instant 135 messages. SIP [8] can carry instant messages generated using 136 message/CPIM in SIP MESSAGE requests [9]. 138 This document extends Message/CPIM message format (much like Message 139 Delivery Notifications [11] extends Electronic Mail [10]) to enable 140 Instant Message Senders to request, create and send Instant Message 141 Disposition Notifications (IMDN) for a page-mode as well as session 142 mode instant messages. IMDNs include positive delivery, negative 143 delivery (i.e. a message did not get delivered successfully), read 144 notifications as well as processed notifications. By using CPIM 145 header fields, the IMDN request and delivery are abstracted outside 146 the transport protocol allowing interoperability between different IM 147 systems. Likewise, the mechanism does not rely on session-mode 148 versus page-mode. 150 2. Conventions 152 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 153 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 154 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and 155 indicate requirement levels for compliant implementations. 157 3. Terminology 159 o IM: An Instant Message generated using the Message/CPIM format. 161 o IMDN: An Instant Message Disposition Notification generated using 162 the Message/CPIM format that carries a IMDN XML document. 164 o Message: an IM or an IMDN generated using the Message/CPIM format. 166 o IM Sender: An endpoint (User Agent) generating and sending an IM. 167 It is also the endpoint that requests IMDNs for an IM. Quite 168 often, the IM Sender is the IMDN Recipient, but that is not always 169 true since an IM Sender's Address of Record (AoR) placed in the IM 170 and in turn used in the IMDN may in fact resolve to different User 171 Agents. This is a limitation due to the nature of page-mode IMs. 173 o IM Recipient: An endpoint (User Agent) that receives IMs. It is 174 also the endpoint that generates and sends IMDNs to IMs, if 175 requested by the IM Sender. 177 o Endpoint: An IM Sender or an IM Recipient. 179 o Intermediary: An entity in the network that is on the path of an 180 IM to its final destination. 182 o IMDN Payload: An XML document carrying the disposition 183 notification information. In this specification, it is of MIME 184 type "message/imdn+xml". 186 o Disposition type: the type of IMDN that can be requested. This 187 specification defines three, namely "delivery", "processing" and 188 "read" disposition types. 190 o Transport Protocol Message: A SIP or other protocol message that 191 contains an IM or IMDN. 193 4. Overview 195 The basic protocol flow is depicted in the diagram below. An IM 196 Sender creates an IM, adds IMDN request information the IM Sender is 197 interested in receiving, then sends IM. At a certain point in time, 198 the IM Recipient or an intermediary determines that the user or 199 application has received, did not receive, read, or otherwise 200 disposed the IM. The mechanism by which an IM Recipient determines 201 its user has read an IM is beyond the scope of this document. At 202 that point, the IM Recipient or intermediary automatically generates 203 a notification message to the IM Sender. This notification message 204 is the Instant Message Disposition Notification (IMDN). 206 +--------------+ +--------------+ 207 | IM Sender | | IM Recipient | 208 |IMDN Recipient| | IMDN Sender | 209 +--------------+ +--------------+ 210 | | 211 | | 212 | 1. IM requesting IMDN | 213 |-------------------------------------->| 214 | | 215 | | 216 | 2. IMDN (disposition) | 217 |<--------------------------------------| 218 | | 219 | | 221 Note that the recipient of an IMDN, in some instances, may not be the 222 IM Sender. This is specifically true for page-mode IMs where the 223 Address of Record (AOR) of the IM Sender, that is present in the 224 IMDN, resolves to a different location or user agent to where the IM 225 originated. For simplicity, the rest of this document assumes that 226 the IM Sender and the IMDN Recipient are the same and therefore will 227 refer to both as the IM Sender. 229 5. Disposition Types 231 There are three broad categories of disposition states. They are 232 delivery, processing and read. Future extensions may introduce 233 others. 235 5.1. Delivery 237 The delivery notification type indicates whether the IM has been 238 delivered to the IM Recipient or not. The delivery notification type 239 can have the following states: 241 o "delivered" to indicate successful delivery. 243 o "failed" to indicate failure in delivery. 245 o "forbidden" indicate denial for the IM Sender to receive the 246 requested IMDN. The "forbidden" state can be sent by the IM 247 Recipient but is mainly sent by an intermediary that is configured 248 to do so. For example, the administrator has disallowed IMDNs. 250 o "error" to indicate an error in determining the fate of an IM. 252 5.2. Processing 254 The processing notification type indicates that an IM has been 255 processed by an intermediary. The processing notification type can 256 have the following states: 258 o "processed" is a general state of the IM indicating that the 259 intermediary has performed its task on the IM. 261 o "stored" state indicates that the IM has been stored by the 262 intermediary for later delivery. 264 o "forbidden" indicate denial for the IM Sender to receive the 265 requested IMDN. The "forbidden" state is sent by an intermediary 266 that is configured to do so. For example, the administrator has 267 disallowed IMDNs. 269 o "error" to indicate an error in determining the fate of an IM. 271 5.3. Read 273 The read notification type indicates whether the IM Recipient 274 rendered the IM to the user or not. The read notification type can 275 have the following states: 277 o "read" is a state indicating that the IM has been displayed or 278 played to the user. 280 o "forbidden" indicate denial, by the IM Recipient, for the IM 281 Sender to receive the requested IMDN. 283 o "error" to indicate an error in determining the fate of an IM. 285 Some IMs may in fact be audio, video or still images. Therefore, the 286 state "read" includes playing the audio or video file to the user. 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 290 cannot 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 header fields. 298 6.1. CPIM header field Namespace 300 Per CPIM [2], this specification defines a new namespace for the CPIM 301 extension header fields defined in the following sections. The 302 namespace is: 304 urn:ietf:params:cpim-header fields:imdn 306 As per CPIM [2] requirements, the new header fields defined in the 307 following sections are prepended, in CPIM messages, by a prefix 308 assigned to the URN through the NS header field field of the CPIM 309 message. The remaining of this specification always assumes an NS 310 header field field like this one: 312 NS: imdn . 314 6.2. Disposition-Notification 316 The Disposition-Notification header field is used by the IM Sender to 317 indicate the desire to receive IMDNs, from the IM Recipient, for that 318 specific IM. This header field is not needed if the IM Sender does 319 not request an IMDN. The syntax is defined in Section 10. 321 6.3. Message-ID 323 The Message-ID header field contains a globally unique message 324 identifier that is used by the IM Sender to correlate received IMDNs 325 by comparing its value with the value of the element 326 present in the IMDN payload. This header field is MANDATORY when 327 sending an IM and requesting an IMDN. IMDNs also carry this header 328 field. The syntax is defined in Section 10. 330 6.4. Original-To 332 The Original-To header field is sometimes added to an IM by an 333 intermediary and populated with the address of the IM Receiver. It 334 is used by the IM Recipient to indicate in the IMDNs (by populating 335 the element) the original address the IM was 336 sent to. This header field is mandatory if the intermediary changes 337 the CPIM To header field value. The header field MUST NOT appear 338 more than once in an IM. The header field value MUST NOT be changed 339 by an intermediary if it was already present. The syntax is defined 340 in Section 10. 342 6.5. IMDN-Record-Route 344 Intermediaries have the capability of indicating that IMDNs should be 345 sent through it (otherwise, IMDNs will not visit the intermediary). 347 An intermediary that request IMDNs to be sent through itself adds an 348 IMDN-Record-Route header field to the IM. The value of the IMDN- 349 Record-Route header field is set to the address of that intermediary. 350 Multiple IMDN-Record-Route header fields can appear in an IM. The 351 syntax is defined in Section 10. 353 6.6. IMDN-Route 355 The IMDN-Route header field provides routing information by including 356 one or more addresses where an IMDN must be routed through. On 357 creating an IMDN, an IM recipient copies the contents of the IMDN- 358 Record-Route present in the IM into the IMDN-Route of the IMDN. 359 Multiple IMDN-Route header fields can appear in an IMDN. The syntax 360 is defined in Section 10. 362 7. Endpoint Behaviour 364 7.1. IM Sender 366 7.1.1. Constructing Instant Messages 368 An IM is constructed using CPIM Message Format defined in RFC 3862 369 [2]. 371 7.1.1.1. Adding a Message-ID header field 373 If the IM sender requests the reception of IMDNs, the IM sender MUST 374 include a Message-ID header field. The Message-ID field is populated 375 with a value that is unique with 32 bits of randomness. This header 376 field enables the IM Sender to match any IMDNs with their 377 corresponding IMs. 379 7.1.1.2. Adding a DateTime header field 381 Some devices may not implement the concept of "Sent Items" box and 382 therefore no information about an IM is stored. It is therefore 383 necessary to add a time stamp in the IM to indicate when it was sent. 384 This time stamp is returned in the IMDN in order to enable the user 385 to correlate the IM with the IMDN at the human level. The DateTime 386 header field is used for this purpose. The IM MUST contain a 387 DateTime header field if an IMDN is requested. 389 7.1.1.3. Adding a Disposition-Notification header field 391 The Disposition-Notification conveys the type of disposition 392 notification requested by the IM sender. There are three types of 393 disposition notification: delivery, processing, and read. The 394 delivery notification is further subdivided into failure and success 395 delivery notifications. An IM Sender requests failure delivery 396 notification by including a Disposition-Notification header field 397 with value "negative-delivery". Similarly, a success notification is 398 requested by including a Disposition-Notification header field with 399 value "positive-delivery". Both types of delivery notifications can 400 be requested for the same IM. 402 The IM Sender can request a processing notification by including a 403 Disposition-Notification header field with value "processing". 405 The IM Sender can also request a read notification. It is requested 406 by including a Disposition-Notification header field with value 407 "read". 409 The absence of this header field or the presence of the header field 410 with empty value indicates that the IM Sender is not requesting any 411 IMDNs. The Disposition-Notification header fields can be comma 412 separated. The IM Sender MAY request more than one type of IMDN for 413 a single IM. 415 Future extension may define other disposition notifications not 416 defined in this document. 418 The formal syntax of the Disposition-Notification header field can be 419 found in Section 10. The following is an example CPIM body of an IM 420 where the IM Sender requests positive and negative delivery 421 notifications, but not read notification nor processing 422 notifications: 424 From: Alice 425 To: Bob 426 NS: imdn 427 imdn.Message-ID: 34jk324j 428 DateTime: 2006-04-04T12:16:49-05:00 429 imdn.Disposition-Notification: positive-delivery, negative-delivery 430 Content-type: text/plain 431 Content-length: 12 433 Hello World 435 7.1.2. Matching IMs with IMDNs 437 An IM Sender matches an IMDN to an IM by matching the Message-ID 438 header field value in the IM with the element value in 439 the body of the IMDN. If the IM was delivered to multiple 440 recipients, the IM Sender uses the element and the 441 element in the XML body of the IMDN it 442 received to determine if the IM was sent to multiple recipients and 443 to identify the IM Recipient that sent the IMDN. 445 7.1.3. Keeping State 447 This specification does not mandate the IM Sender to keep state for a 448 sent IM. 450 Once an IM Sender sends an IM containing an IMDN request, it MAY 451 preserve the IM context, principally the Message-ID, and other user- 452 identifiable information such as the IM subject or content, and date 453 and time it was sent. Without preservation of the IM context, the IM 454 Sender will not be able to correlate the IMDN with the IM it sent. 455 The IM Sender may find it impossible to preserve IM state if it has 456 limited resources or does not have non-volatile memory and then loses 457 power. 459 There is, however, the concept of "Sent Items" box in an application 460 that stores sent IMs. This "Sent Items" box has the necessary 461 information and may have a fancy user interface indicating the state 462 of a sent IM. Unique Message-ID for this purpose proves to be 463 useful. The length of time for items to remain in the "Sent Items" 464 box is a user choice. The user is usually free to keep or delete 465 items from the "Sent Items" box as she pleases or as the memory on 466 the device reaches capacity. 468 Clearly, if an IM Sender loses its sent items state (user deletes 469 items from the "Send Items" box), the client may use a different 470 display strategy in response to apparently unsolicited IMDNs. 472 This specification also does not mandate an IM Sender to run any 473 timers waiting for an IMDN. There are no time limits associated with 474 when IMDNs may be received. 476 IMDNs may legitimately never be received. On the other hand, and 477 IMDN may simply take a very long time. Some clients may choose to 478 purge the state associated with the sent IM. This is the reason for 479 adding the time stamp in the IM and having it returned in the IMDN. 480 This gives the user some opportunity of remembering what IM was sent. 481 For example if the IMDN indicates that the IM the user sent at 2 p.m. 482 last Thursday was delivered, the user has a chance of remembering 483 that they sent an IM at 2 p.m. last Thursday. 485 7.1.4. Aggregation of IMDNs 487 An IM Sender may send an IM to multiple recipients in one Transport 488 Protocol Message (typically using a URI-List server) and request 489 IMDNs. An IM Sender that requested an IMDNs MUST be prepared to 490 receive multiple aggregated or non-aggregated IMDNs. See Section 8.2 491 for details. 493 7.2. IM Recipient 495 7.2.1. Constructing IMDNs 497 IM recipients examine the contents of the Disposition-Notification 498 header field of the CPIM message to determine if an IMDN must be 499 generated for that IM. Disposition-Notification header fields of 500 CPIM messages can include one or more values. This implies that IM 501 recipients may need to generate zero, one, or more IMDNs for that IM, 502 for example a delivery notification as well as a read notification. 503 In this case the IM Recipient MUST be able to construct multiple 504 IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN 505 per disposition type. I.e. It must not, for example, generate a 506 delivery notification indicating "delivered" then followed by a 507 delivery notification indicating "failed" for the same IM. If the IM 508 Sender requested only failure notifications and the IM was 509 successfully delivered, then no IMDNs will be generated. 511 The IM Recipient MUST NOT generate "processing" notifications. 513 Disposition-Notification header field MUST NOT appear in an IMDN 514 since it does not make sense and is therefore forbidden to request an 515 IMDN for an IMDN. IM Sender MUST ignore it if present. The IM 516 Sender MUST NOT send an IMDN to an IMDN. 518 An IMDN MUST contain a Message-ID header field. The same rules of 519 uniqueness for the Message-ID header field that appears in an IM 520 apply to an IMDN. The Message-ID header field in the IMDN is 521 different and unrelated to the one in the IM. 523 An IM may contain a IMDN-Record-Route header field (see Section 8 for 524 details). If IMDN-Record-Route header fields appear in the IM, the 525 IM Recipient constructing the IMDN MUST copy the contents of the 526 IMDN-Record-Route header fields into IMDN-Route header fields in the 527 IMDN and maintain the order. The IMDN is then sent to the URI in the 528 top IMDN-Route header field. IMDN-Record-Route header fields do not 529 make sense in an IMDN and therefore SHOULD NOT be placed in an IMDN. 531 The CPIM Content-Disposition header field must be set to the value 532 "notification". This indicates to the IM Sender that the message is 533 an IMDN to an IM it has earlier sent. 535 7.2.1.1. Constructing Delivery Notifications 537 A delivery notification is constructed in a similar fashion as an IM, 538 using a CPIM body [2] that carries a Disposition Notification XML 539 document formatted according to the rules specified in Section 11. 540 The MIME type of the Disposition Notification XML document is 541 "message/imdn+xml". 543 An example CPIM body of IMDN looks like the following: 545 From: Bob 546 To: Alice 547 NS: imdn 548 imdn.Message-ID: d834jied93rf 549 Content-type: message/imdn+xml 550 Content-Disposition: notification 551 Content-length: ... 553 554 555 34jk324j 556 2006-04-04T12:16:49-05:00 557 im:bob@example.com 558 559 im:bob@example.com 560 561 562 563 564 565 566 The IM was successfully Delivered 567 569 7.2.1.2. Constructing Read Notifications 571 A read notification is constructed in a similar fashion as the 572 delivery notification. See Section 7.2.1.1 for details. 574 An example looks like the following: 576 From: Bob 577 To: Alice 578 NS: imdn 579 imdn.Message-ID: dfjkleriou432333 580 Content-type: message/imdn+xml 581 Content-Disposition: notification 582 Content-length: ... 584 585 586 34jk324j 587 2006-04-04T12:16:49-05:00 588 im:bob@example.com 589 590 im:bob@example.com 591 592 593 594 595 596 597 The IM has been read 598 600 There are situations where the IM Recipient cannot determine if or 601 when the IM has been read. The IM Recipient in this case generates a 602 read notification with a value of "error" to indicate an 603 internal error by the server. An example of this is when a SIP stack 604 with built in IMDN support is talking to an IM application and the IM 605 application never returned indicating that it has displayed the IM to 606 the user. 608 8. Intermediary Behaviour 610 In this context, application servers (including URI-List servers and 611 Store-and-Forward server) and gateways are defined as intermediaries. 612 A gateway is a server the translates between different IM systems 613 that different protocols. 615 A URI-List server may change the IM Recipient address from its own to 616 the address of the final recipient of that IM for every copy it makes 617 to be sent to the list members (see [12] for details). In this case, 618 the intermediary MUST add an Original-To header field to the IM 619 populating it with the address that was in the CPIM To header field 620 before it was changed. I.e. The Original-To header field is 621 populated with the intermediary address. An intermediary MUST NOT 622 add an Original-To header field if one already exists. 624 An intermediary MAY choose to remain on the path of IMDNs for a 625 specific IM. It can do so by adding a CPIM IMDN-Record-Route header 626 field as the top IMDN-Record-Route header field and populating it 627 with its own address. An intermediary that does not support this 628 extension will obviously not add the IMDN-Record-Route header field. 629 This allows IMDNs to traverse directly from the IM Recipient to the 630 IM Sender even if the IM traversed an intermediary not supporting 631 this extension. 633 An intermediary receiving an IMDN checks the top IMDN-Route header 634 field. If that header field carries the intermediary address, the 635 intermediary pops that value and forwards the IMDN to the address 636 indicated in the now top IMDN-Route header field. If no IMDN-Route 637 header fields are present, the IMDN is forwarded to the address in 638 the CPIM To header field. 640 An intermediary MUST remove any information about the final 641 recipients of a list if the list membership is not disclosed. The 642 intermediary does that by removing the element and/or 643 element from the body of the IMDN before 644 forwarding it to the IM Sender. 646 8.1. Constructing Processing Notifications 648 Intermediaries are the only entities that construct processing 649 notifications. They do so only if the IM Sender has requested a 650 "processing" notification by including a Disposition-Notification 651 header field with value "processing". 653 The intermediary can create and send "processing" notifications 654 indicating that an IM has been processed or stored. The intermediary 655 MUST NOT send more than one IMDN for the same disposition type. I.e. 656 It must not send a "processing" notification indicating that an IM is 657 being "processed" followed by another IMDN indicating that the same 658 IM is "stored". 660 A "processing" notification is constructed in a similar fashion as 661 the delivery notification. See Section 7.2.1.1 for details. 663 An example looks like the following: 665 Content-type: Message/CPIM 667 From: Bob 668 To: Alice 669 Content-type: message/imdn+xml 670 Content-Disposition: notification 671 Content-length: ... 673 674 34jk324j 675 2006-04-04T12:16:49-05:00 676 im:bob@example.com 677 678 im:bob@example.com 679 680 681 682 683 684 685 The IM has been processed 686 688 There are situations where the intermediary cannot know the fate of 689 an IM. The intermediary in this case generates a processing 690 notification with a value of "error" to indicate so. 692 8.2. Aggregation of IMDNs 694 In this context, URI-List servers are defined as intermediaries. 696 An intermediary may choose to aggregate IMDNs using local policy for 697 making such a decision or it may send individual IMDNs instead. When 698 a URI-List server receives an IM and decides to aggregate IMDNs, it 699 waits for a configurable period of time or until all recipients have 700 sent the IMDN (whichever comes first) before the URI-List server 701 sends an aggregated IMDN. Note that some IMDNs, for example read 702 notifications, may never come due to user settings. It is an 703 administrator configuration and an implementation issue how long to 704 wait before sending an aggregated IMDN and before a URI-List server 705 removes state for that IM. 707 A URI-List server MAY choose to send multiple aggregated IMDNs. A 708 timer can be started and when it fires, the URI-List server can 709 aggregate whatever IMDNs it has so far for that IM, send the 710 aggregated IMDN and restart the timer for the next batch. This is 711 needed for scenarios where the IM Sender has requested more than one 712 IMDN for a specific IM, for example, delivery notifications as well 713 as read notifications, or when the URI-List server is short on 714 resources and chooses to prioritise forwarding IMs over IMDNs. 716 A second timer can be running and when it fires, the state of the IM 717 is deleted. In this case, the URI-List server consumes any IMDNs 718 that might arrive after that time. 720 A URI-List server MAY aggregate IMDNs for the case where the list 721 membership information is not disclosed. There may be scenarios 722 where the URI-List server starts sending aggregated IMDNs and switch 723 to indivdual ones or visa versa. A timer firing so ofter may in fact 724 have that effect. 726 The aggregated IMDN is constructed using the multipart/mixed MIME 727 type and including all the received IMDNs as message/imdn+xml as 728 individual payloads. 730 There are scenarios where an intermediary needs to generate IMDNs, 731 see Section 12.2 for further details. 733 9. Identifying Messages 735 Messages are typically carried in a transport protocol like SIP [8]. 736 The message is an IM if the content-type header field field present 737 in it has a value that is NOT "message/imdn+xml". 739 A message is identified as a delivery notification by examining its 740 contents. The message is a delivery notification if: the Content- 741 type header field present has a value of "message/imdn+xml", the 742 Content-Disposition header field field has a value of "notification", 743 and the element in that xml body has a sub-element 744 . 746 A message is identified as a processing notification or read 747 notification in a similar fashion as a delivery notification. The 748 difference is that the element in that xml body has a 749 sub-element of and respectively. 751 10. header fields Formal Syntax 753 The following syntax specification uses the message header field 754 syntax as described in Section 3 of RFC3862 [2]. 756 header field syntax is described without a namespace qualification. 757 Following the rules in RFC3862 [2], header field names and other text 758 are case sensitive and MUST be used as given, using exactly the 759 indicated upper-case and lower-case letters. 761 Disposition-Notification = 762 "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))] 763 notify-req = 764 ("negative-delivery" / "positive-delivery" / 765 "processing" / "read" / Token) *(SEMI disp-notif-params) 767 disp-notify-params = generic-param 769 Message-ID = "Message-ID" ": " Token 771 Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" 773 IMDN-Record-Route = 774 "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" 776 IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 778 11. IMDN Format 780 11.1. Structure of XML-Encoded IMDN Payload 782 An IMDN Payload is an XML document [7] that MUST be well-formed and 783 MUST be valid according to schemas, including extension schemas, 784 available to the validater and applicable to the XML document. The 785 IMDN Payload MUST be based on XML 1.0 and MUST be encoded using 786 UTF-8. 788 The namespace identifier for elements defined by this specification 789 is a URN [4], using the namespace identifier 'ietf' defined by [5] 790 and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. 792 This namespace declaration indicates the namespace on which the IMDN 793 is based. 795 The root element is . The element has sub-elements, 796 namely , , , , , , , and . 798 Those elements are described in details in the following sections. 800 and can be extended in the future to include 801 new sub-elements not defined in this document. Those new elements 802 MUST be defined in an RFC. 804 11.1.1. The Element 806 The element is mandatory according to the XML schema and 807 carries the message id that appeared in the Message-ID header field 808 of the IM. 810 11.1.2. The Element 812 The element is mandatory and carries the date and time the 813 IM was sent (not the IMDN). This information is obtained from the 814 DateTime header field of the IM. 816 11.1.3. The Element 818 The element is optional and carries the URI of the 819 final recipient. This information is obtained from the CPIM To 820 header field of the IM. 822 11.1.4. The Element 824 The element is optional and carries the URI 825 of the original recipient. It MUST be present if the IM carried the 826 Original-To header field. This information is obtained from the 827 Original-To header field of the IM. 829 11.1.5. The Element 831 The element is optional and carries the text that was in 832 the Subject header field, if any. This allows for a human level 833 correlation between an IM and an IMDN. 835 11.1.6. The Element 837 The element is mandatory and carries the disposition 838 type that the IM Sender requested and is being reported. It can 839 carry one of the sub-elements , , or any 840 other future extension. 842 11.1.7. The Element 844 The element is mandatory and carries the result of the 845 disposition request in the element. For disposition 846 type , it can carry one of the sub-elements , 847 , or . For disposition type , it 848 can carry one of the sub-elements , or . 849 For disposition type , it can carry one of the sub- 850 elements , , or . 851 means the disposition was denied. means internal server 852 error. It can also carry any other future extension. 854 11.1.8. The Element 856 The element is optional and carries a human readable text. It 857 has the "lang" attribute that indicates the language the text is 858 written in. 860 11.2. MIME Type for IMDN Paylaod 862 The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN 863 MUST identify the payload as MIME type "message/imdn+xml" in the 864 Content-type header field. 866 11.3. The RelaxNG Schema 868 869 875 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 902 903 904 905 906 907 908 909 910 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 937 938 939 940 941 942 943 944 945 946 948 949 950 951 952 953 954 955 956 957 958 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1002 1003 1004 1005 1006 1007 lang 1008 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 1045 12.1. Endpoint Behaviour 1047 12.1.1. Sending Requests 1049 A SIP MESSAGE request is constructed using RFC 3428 [9]. The 1050 Content-type header field indicates the MIME type of the request 1051 payload. When using this extension, the Content-type header field 1052 MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The 1053 payload is constructed according to Section 7. 1055 A SIP MESSAGE request to multiple recipients is constructed in a 1056 similar manner as a SIP MESSAGE request to a single recipient. The 1057 differences are indicated in [12]. 1059 12.1.2. Sending Responses 1061 An endpoint receiving a SIP MESSAGE request constructs a SIP response 1062 according to RFC3428 [9]. Of course, an endpoint will send a 1063 response to the MESSAGE request regardless of they type of message 1064 (IM or IMDN) is has received, or the disposition type it has been 1065 asked for. 1067 12.1.3. Receiving Requests 1069 12.1.3.1. Instant Message 1071 A SIP MESSAGE request is identified as an IM by examining its 1072 contents according to Section 9. 1074 If an IM Recipient received a SIP MESSAGE request that is an IM that 1075 requested a positive-delivery notification, and that IM Recipient has 1076 constructed and sent a SIP 2xx class response, it MAY generate a 1077 positive-delivery notification after making sure that the IM has been 1078 delivered to the user or application (a gateway, for example, can 1079 generate a 2xx response before it has been guaranteed that the final 1080 recipient has actually received the IM). The positive-delivery 1081 notification is constructed according to Section 7.2.1.1. The 1082 message is then placed as the payload in a SIP MESSAGE request. 1084 If an IM Recipient received a SIP MESSAGE request that is an IM that 1085 requested a negative-delivery, and that IM Recipient has constructed 1086 and sent a 2xx class response, it SHOULD generate a negative-delivery 1087 notification if it learnt that the final recipient or application did 1088 not receive the IM (a gateway, for example, can generate a 2xx 1089 response before it has been guaranteed that the final recipient has 1090 actually received the IM). The negative-delivery notification is 1091 constructed according to Section 7.2.1.1. The message is then placed 1092 as the payload in a SIP MESSAGE request. 1094 If an IM Recipient received a SIP MESSAGE request that is an IM that 1095 requested a negative-delivery notification, and the IM Recipient has 1096 constructed and sent an non-2xx final response, it MUST NOT generate 1097 a negative-delivery notification. 1099 If an IM Recipient received a SIP MESSAGE request that is an IM that 1100 requested a read notification, and that IM Recipient has constructed 1101 and sent a SIP 2xx class response, it MAY generate a read 1102 notification after making sure that the IM has been presented to the 1103 user or application. It is outside the scope of this document how 1104 such determination can be made. Note that the option to send a read 1105 notification or not can be left to the user. An application may 1106 allow a user to configure such choice. The read notification is 1107 constructed according to Section 7.2.1.2. The message is then placed 1108 as the payload in a SIP MESSAGE request. 1110 For IMDNs, the SIP Request-URI and the SIP To header field are 1111 populated using the address that appeared in the SIP From header 1112 field field in the IM. 1114 12.1.3.2. Delivery Notification 1116 A SIP MESSAGE request is identified as delivery notification by 1117 examining its contents according to Section 9. 1119 12.1.3.3. Read Notification 1121 A SIP MESSAGE request is identified as read notification by examining 1122 its contents according to Section 9. 1124 12.2. Intermediary Behaviour 1126 In this context, application servers (including URI-List servers and 1127 Store-and-Forward server) and gateways are defined as intermediaries. 1128 SIP Proxies MUST NOT generate IMDNs but MUST forward them like any 1129 other sip request. 1131 A SIP MESSAGE request to multiple recipients is forwarded according 1132 to [12]. 1134 If an intermediary generates a SIP 2xx class response to a SIP 1135 MESSAGE request it has received that is an IM, it examines if the 1136 body was of type "message/cpim". If so, it checks if there is the 1137 header field Disposition-Notification with a value "positive- 1138 delivery" and/or "negative-delivery". If so, it MUST send a delivery 1139 notification after receiving a transactional final response for the 1140 IM. 1142 If the Disposition-Notification header field contains a value of 1143 "positive-delivery", the intermediary MUST NOT generate a delivery 1144 notification if it receives a SIP 2xx class response for the sent IM. 1145 This is in anticipation of a failure downstream after a 2xx response 1146 has been generated. 1148 If the Disposition-Notification header field contains a value of 1149 "negative-delivery", the intermediary SHOULD generate a delivery 1150 notification if it receives a SIP 4xx, 5xx or 6xx class final 1151 response for the sent IM. If it has received a SIP 2xx class 1152 response followed by a negative-delivery notification, the 1153 intermediary forwards that negative-delivery notification or 1154 aggragates it. 1156 If the Disposition-Notification header field contains a value of 1157 "processing", the intermediary MAY generate a processing notification 1158 after it has forwarded or stored the IM. The rest of the procedures 1159 in Section 8.1 apply. 1161 The procedure for generating such IMDN is the same as that of an IM 1162 Recipient (Section 7.2.1.1). 1164 The element of the XML body is populated with the URI 1165 of the IM Recipient. 1167 If an intermediary receives a SIP MESSAGE request carrying a positive 1168 delivery notification or a read notification, it forwards it using 1169 the rules in Section 8. 1171 13. Transporting Messages using MSRP 1173 MSRP already provides a built-in mechanism to supply positive and 1174 negatie delivery reports. 1176 While MSRP does not provide a built-in Read or Processing 1177 notification dispositions, those are generally not considered as 1178 useful information for session IM. This is because the assumption 1179 behind MSRP is that SEND requests do not reach a mailbox where 1180 incoming IMs have to be open, but to an application that renders 1181 sequentially those incoming IMs, providing the session experience. 1182 This kind of applications has no means of identifying when a user has 1183 read the IM and therefore cannot be useful information for the 1184 sender. 1186 IMDN use cases for MSRP have not been fully explored. If new 1187 requirements arise in the future determining the need for IMDN in 1188 MSRP, new specifications can be drafted. 1190 14. Security Considerations 1192 IMDNs provide a fine-grained view of the activity of the IM Recipient 1193 and thus deserves particularly careful confidentiality protection so 1194 that only the intended recipient of the IMDN will receive the IMDN 1195 (in most cases, the intended recipient of the IMDN is the IM Sender). 1197 Since IMDNs are carried by using the IM protocol itself, all security 1198 considerations of the underlying IM protocol also apply to the IMDNs. 1200 The threats in the IMDN system, over and beyond the threats inherent 1201 to IM include the following: 1203 o A malicious endpoint attempts to send messages to a user that 1204 would normally not wish to receive messages from that endpoint by 1205 convincing the IMDN system to "bounce" an IMDN from an 1206 unsuspecting endpoint to the user. 1208 o A malicious endpoint attempts to flood a IM Sender with IMDNs by 1209 convincing a URI-List server to send IMDNs to an unsuspecting IM 1210 Sender. 1212 o A malicious node in the network that attempts to modify an IMDN 1213 from a IM Recipient. 1215 o A malicious intermediary attempts to forward an IMDN from an IM 1216 Recipient to the IM Sender, where the IM Recipient would not 1217 normally forward the IMDN to that IM Sender if the IM Recipient 1218 knew the identity of the IM Sender. 1220 o A malicious endpoint that attempts to fish for a Request-URI of an 1221 endpoint beyond an intermediary , where the endpoint would 1222 normally wish to keep its identity private from the malicious 1223 endpoint. 1225 o A malicious node in the network that attempts to eavesdrop on IMDN 1226 traffic to, for example, learn Request-URI or traffic pattern 1227 information. 1229 o A malicious node in the network attempts to stage a denial of 1230 service attack on an intermediary by requesting a large list 1231 expansion. 1233 The protocol cannot protect against attacks that include the 1234 following: 1236 o A malicious intermediary directly revealing the identity of a 1237 downstream endpoint that would not normally wish its identity 1238 revealed. Keeping such information private is an intermediary 1239 implementation issue. 1241 o A malicious IM Recipient that alters the time of the IMDN. There 1242 is no protocol mechanism for ensuring the IM Recipient does not 1243 lie about the time or purposely holds an IMDN for transmission to 1244 make it appear that the user read an IM later than they actually 1245 did. 1247 o A deletion attack on an IMDN. This is a trade-off between privacy 1248 and security. The privacy considerations allow the IM Recipient 1249 to silently ignore an IMDN request. Any mechanism that would 1250 reliably indicate that a malicious node deleted a IM Recipient's 1251 IMDN would also serve the purpose of detecting a IM Recipient that 1252 chose not to issue an IMDN. 1254 To combat eavesdropping, modification, and man-in-the-middle attacks, 1255 we require some level of authentication and integrity protections. 1256 That said, there are circumstances where strong integrity would be 1257 overkill. The presumption is the IM Sender has and sets the 1258 expectation for the level of protection. The procedures for 1259 integrity protection are as follows. 1261 o If the IM Recipient has a certificate, it MUST sign the IMDN. 1263 o If the IM is encrypted, the IM Recipient or intermediary MUST 1264 encrypt the IMDN body, as an attacker may attempt to discern the 1265 user's activity profile and identity from sniffing IMDNs on the 1266 network. 1268 o The two above rules are cumulative. 1270 The IM Recipient or intermediary MUST be capable of loading a user 1271 certificate. 1273 An attacker can mount a distributed denial of service attack on a 1274 node by sending lots of IMs to the node with IMDN requests. Note 1275 that this is the same problem as there is without IMDN; IMDN simply 1276 linearly increases the load on the node under attack. One can 1277 mitigate, but not eliminate this threat by the endpoint immediately 1278 ignoring requests that are not authenticated. 1280 Likewise, an attacker can mount a denial of service attack on an 1281 intermediary by asking the intermediary to explode a large list. 1283 The following security considerations apply when using IMDNs: 1285 14.1. Forgery 1287 IMs can be forged. To protect against that, an IM can be signed. An 1288 intermediary that receives a signed message and needs to modify any 1289 part of it that is included in the signature (like adding an 1290 Original-To header field to the CPIM header fields), MUST consume the 1291 IM and create a new copy of it that the intermediary signs itself. 1293 IMDNs may be forged as easily as ordinary IMs. Endpoints and 1294 intermediaries that wish to make automatic use of IMDNs should take 1295 appropriate precautions to minimize the potential damage from denial- 1296 of-service attacks. Security threats related to forged IMDNs include 1297 the sending of a falsified IMDN when the indicated disposition of the 1298 IM has not actually occurred. For example, read notification could 1299 be forged to indicate that a IM Recipient has read the IM. 1300 Unsolicited IMDNs is also another form of forgery. 1302 14.2. Confidentiality 1304 There may be cases where an IM Recipient does not wish to reveal the 1305 information that he has received or in fact read the IM. In this 1306 situation, it is acceptable for the IM Recipient to silently ignore 1307 requests for an IMDN. It is strongly RECOMMENDED that the IM 1308 Recipient obtain the user's consent before sending an IMDN. 1309 Circumstances where the IM Recipient does not ask for the user's 1310 consent include IM systems that, for regulatory reasons, are required 1311 to issue an IMDN, such as in the health care field or financial 1312 community. 1314 An IM Recipient can obtain such consent by a prompt or dialog box on 1315 a per-IM basis, globally through the user's setting of a preference, 1316 or other, user-configurable mechanism. The user might also indicate 1317 globally that IMDNs are never to be sent or that a "forbidden" IMDN 1318 status is always sent in response to a request for an IMDN. 1320 There are situations where a user sends an IM and requests IMDNs to a 1321 list who's member information is not disclosed. In this situation, 1322 the user will learn of the list members. Therefore, in this case, 1323 the URI-List server MUST remove any information about list members. 1324 If the number of members in the list is also not disclosed, the URL- 1325 List server MUST only deliver one aggregated IMDN. Alternatively, 1326 the URI-list server MAY reject the IM. 1328 An unencrypted IMDN could reveal confidential information about an 1329 encrypted IM. It is a MUST that the same level of security applied 1330 to an IM to be applied to its IMDNs. For example, if an IM is signed 1331 and encrypted, and IMDN must also be signed and encrypted. 1333 14.3. Non-Repudiation 1335 IMDNs cannot be relied on as a guarantee that an IM was or was not 1336 seen by the user. Even if IMDNs are not actively forged, they may be 1337 lost in transit. The IMDN issuing mechanism may be bypassed in some 1338 manner by the IM Recipient. 1340 15. IANA Considerations 1342 15.1. message/imdn+xml MIME TYPE 1344 This document registers a new MIME type "message/imdn+xml", and 1345 registers a new XML namespace. 1347 This specification follows the guidelines of RFC3023 [6]. 1349 MIME media type: message 1351 MIME subtype name: imdn+xml 1353 Mandatory parameters: none 1355 Optional parameters: Same as charset parameter application/xml as 1356 specified in RFC 3023 [6]. 1358 Encoding considerations: Same as encoding considerations of 1359 application/xml as specified in RFC 3023 [6]. 1361 Security considerations: See section 10 of RFC 3023 [6] and 1362 Section 14 of this document. 1364 Interoperability considerations: none. 1366 Published specification: This document. 1368 Applications which use this media type: This document type is used to 1369 support SIP based instant messaging. 1371 Additional information: None 1373 Magic number: None 1375 File extension: .cl or .xml 1376 Macintosh file type code: "TEXT" 1378 Personal and email address for further information: Hisham Khartabil 1379 (hisham.khartabil@telio.no) 1381 Intended Usage: COMMON 1383 Author/change controller: The IETF . 1385 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn 1387 This section registers a new XML namespace, as per guidelines in the 1388 IETF XML Registry [3]. 1390 URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. 1392 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1393 (hisham.khartabil@telio.no) . 1395 15.3. Schema Registration 1397 This section registers a new XML schema per the procedures in [3]. 1399 URI: urn:ietf:params:xml:ns:imdn 1401 Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil 1402 (hisham.khartabil@telio.no) 1404 The XML for this schema can be found as the sole content of 1405 Section 11.3. 1407 15.4. Message/CPIM header field registration 1409 This document registers the following message/cpim header fields in 1410 the cpim-header fields registry: 1412 Disposition-Notification - [RFCXXXX] 1414 Message-ID - [RFCXXXX] 1416 Original-To - [RFCXXXX] 1418 IMDN-Record-Route - [RFCXXXX] 1420 IMDN-Route - [RFCXXXX]. 1422 15.5. Content-Disposition: notification 1424 This document registers one new Content-Disposition header field 1425 "disposition-types": notification. The authors request that this 1426 values be recorded in the IANA registry for Content-Dispositions. 1427 Descriptions of this "disposition-types", including motivation and 1428 examples, are given in Section 7.2.1.1 and Section 9. Short 1429 descriptions suitable for the IANA registry are: notification the 1430 body of the message is a notification according to an earlier request 1431 for a disposition notification to an instant message 1433 16. Acknowledgements 1435 The authors would like to thank Paul Kyzivat, Ben Campbell, Adam 1436 Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, 1437 Eric McMurry and Jari Urpalainen for their comments and support. 1439 17. References 1441 17.1. Normative References 1443 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1444 Levels", BCP 14, RFC 2119, March 1997. 1446 [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 1447 (CPIM): Message Format", RFC 3862, August 2004. 1449 [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 1451 [4] Moats, R., "The URN Syntax", RFC 2141, May 1997. 1453 [5] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, 1454 August 1999. 1456 [6] Murata, M., "XML Media Types", RFC 3023, March 1997. 1458 [7] Bray, T., "Extensible Markup Language (XML) 1.0 (Second 1459 Edition)", W3C CR CR-xml11-20011006, October 2000. 1461 17.2. Informative References 1463 [8] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, 1464 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 1465 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1467 [9] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, 1468 December 2002. 1470 [10] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1471 April 2001. 1473 [11] Fajman, R., "An Extensible Message Format for Message 1474 Disposition Notifications", RFC 2298, March 1998. 1476 [12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 1477 Requests in SIP", draft-ietf-sip-uri-list-message-01.txt, 1478 January 2007. 1480 Authors' Addresses 1482 Eric Burger 1483 BEA Systems, Inc. 1484 4 Van de Graaff Dr. 1485 Burlington, MA 01803 1486 USA 1488 Phone: +1 781 993 7437 1489 Fax: +1 603 457 5933 1490 Email: eric.burger@bea.com 1492 Hisham Khartabil 1493 Melbourne 1494 Australia 1496 Phone: +61 416 108 890 1497 Email: hisham.khartabil@gmail.com 1499 Full Copyright Statement 1501 Copyright (C) The IETF Trust (2007). 1503 This document is subject to the rights, licenses and restrictions 1504 contained in BCP 78, and except as set forth therein, the authors 1505 retain all their rights. 1507 This document and the information contained herein are provided on an 1508 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1509 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1510 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1511 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1512 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1513 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1515 Intellectual Property 1517 The IETF takes no position regarding the validity or scope of any 1518 Intellectual Property Rights or other rights that might be claimed to 1519 pertain to the implementation or use of the technology described in 1520 this document or the extent to which any license under such rights 1521 might or might not be available; nor does it represent that it has 1522 made any independent effort to identify any such rights. Information 1523 on the procedures with respect to rights in RFC documents can be 1524 found in BCP 78 and BCP 79. 1526 Copies of IPR disclosures made to the IETF Secretariat and any 1527 assurances of licenses to be made available, or the result of an 1528 attempt made to obtain a general license or permission for the use of 1529 such proprietary rights by implementers or users of this 1530 specification can be obtained from the IETF on-line IPR repository at 1531 http://www.ietf.org/ipr. 1533 The IETF invites any interested party to bring to its attention any 1534 copyrights, patents or patent applications, or other proprietary 1535 rights that may cover technology that may be required to implement 1536 this standard. Please address the information to the IETF at 1537 ietf-ipr@ietf.org. 1539 Acknowledgment 1541 Funding for the RFC Editor function is provided by the IETF 1542 Administrative Support Activity (IASA).