idnits 2.17.1 draft-burger-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 on line 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1056. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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, 2006) is 6653 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) == Unused Reference: '14' is defined on line 1003, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. '3') (Obsoleted by RFC 5234) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-13 ** Obsolete normative reference: RFC 2298 (ref. '5') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 3850 (ref. '6') (Obsoleted by RFC 5750) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2141 (ref. '8') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '9') -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '12') (Obsoleted by RFC 5321) == Outdated reference: A later version (-10) exists of draft-ietf-simple-msrp-relays-06 -- Obsolete informational reference (is this intentional?): RFC 3798 (ref. '14') (Obsoleted by RFC 8098) == Outdated reference: A later version (-08) exists of draft-ietf-sipping-uri-list-message-06 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE E. Burger 3 Internet-Draft Brooktrout Technology, Inc. 4 Expires: August 9, 2006 February 5, 2006 6 Instant Message Delivery Notification (IMDN) for Common Presence and 7 Instant Messaging (CPIM) 8 draft-burger-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, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes a mechanism for instant message delivery 42 notification (IMDN) in the CPIM (Common Presence and Instant 43 Messaging) environment. The mechanism follows the procedures of 44 ESMTP message delivery notification (MDN). 46 Table of Contents 48 1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 51 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7 52 5. State Sharing . . . . . . . . . . . . . . . . . . . . . . . . 8 53 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 6.1. Data Elements . . . . . . . . . . . . . . . . . . . . . . 9 55 6.2. Disposition States . . . . . . . . . . . . . . . . . . . . 10 56 6.2.1. read . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 6.2.2. processed . . . . . . . . . . . . . . . . . . . . . . 10 58 6.2.3. error . . . . . . . . . . . . . . . . . . . . . . . . 10 59 6.2.4. denied . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6.3. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 8. Requesting UAC Behavior . . . . . . . . . . . . . . . . . . . 12 63 8.1. IMDN Request Generation . . . . . . . . . . . . . . . . . 12 64 8.1.1. Disposition-Notification . . . . . . . . . . . . . . . 12 65 8.1.2. List-Action . . . . . . . . . . . . . . . . . . . . . 13 66 8.1.3. Original-From . . . . . . . . . . . . . . . . . . . . 14 67 8.1.4. Message-ID . . . . . . . . . . . . . . . . . . . . . . 14 68 8.1.5. Original-Message-ID . . . . . . . . . . . . . . . . . 15 69 8.2. IMDN Reception Processing . . . . . . . . . . . . . . . . 15 70 9. Reporting UAS Operation . . . . . . . . . . . . . . . . . . . 15 71 9.1. General Operation . . . . . . . . . . . . . . . . . . . . 16 72 9.2. Recipient is the End User UAS . . . . . . . . . . . . . . 16 73 9.3. Recipient is a B2BUA . . . . . . . . . . . . . . . . . . . 17 74 9.3.1. first-recipient . . . . . . . . . . . . . . . . . . . 17 75 9.3.2. final-recipient . . . . . . . . . . . . . . . . . . . 18 76 9.3.3. No List-Action Specified . . . . . . . . . . . . . . . 18 77 9.3.4. Unknown List-Action Specified . . . . . . . . . . . . 18 78 10. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 10.1. disposition . . . . . . . . . . . . . . . . . . . . . . . 19 80 10.2. original-message-id . . . . . . . . . . . . . . . . . . . 19 81 10.3. original-recipient-uri . . . . . . . . . . . . . . . . . . 19 82 10.4. reporting-uas-uri . . . . . . . . . . . . . . . . . . . . 19 83 10.5. original-recipient . . . . . . . . . . . . . . . . . . . . 19 84 10.6. disposition-time . . . . . . . . . . . . . . . . . . . . . 19 85 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 11.1. Simple End-to-End IMDN Request . . . . . . . . . . . . . . 20 87 11.2. Gateway Endpoint . . . . . . . . . . . . . . . . . . . . . 21 88 11.3. List Exploder - Forward . . . . . . . . . . . . . . . . . 21 89 11.4. List Exploder - Private Forward . . . . . . . . . . . . . 22 90 11.5. List With Lists . . . . . . . . . . . . . . . . . . . . . 22 91 11.6. End-to-End Encryption Forwarded . . . . . . . . . . . . . 22 92 12. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 93 12.1. IMDN CPIM Request . . . . . . . . . . . . . . . . . . . . 22 94 12.2. IMDN Document . . . . . . . . . . . . . . . . . . . . . . 22 95 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 98 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 99 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23 100 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 Intellectual Property and Copyright Statements . . . . . . . . . . 26 104 1. Document Conventions 106 This document refers generically to the sender of a message in the 107 masculine (he/him/his) and the recipient of the message in the 108 feminine (she/her/hers). This convention is purely for convenience 109 and makes no assumption about the gender of a message sender or 110 recipient. 112 In this document, the term "CPIM header" refers to the message 113 metadata headers encapsulated in a Message/CPIM object [1]. 115 The term "IM" refers to Instant Message. 117 The term "Requesting UAC" is the User Agent Client that sends the 118 message the user would like a disposition notification for. 120 The term "Reporting UAS" is the User Agent Server that sends the 121 disposition notification back to the Requesting UAC. 123 The term "B2BUA" refers to a Back-to-Back User Agent. IM B2BUA's 124 implement gateways and list exploders, amongst other functions. 126 If you missed it in the title, the term "IMDN" is an Instant Message 127 Delivery Notification. The IMDN indicates the disposition of the 128 message after the message is available to the recipient. 130 NOTE: Text like this, offset from the margin and starting with the 131 word "NOTE:", is not normative and present only for discussion or 132 explanation purposes. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC2119 [2]. 138 This document uses the augmented Backus-Naur Form (BNF) as described 139 in RFC4234 [3] for all syntax specification uses, other than XML. 141 Examples and discussion of CPIM headers, for clarity, do not include 142 the leading name space identifier. 144 2. Introduction 146 In many user-to-user message exchange systems, message senders often 147 wish to know if the human recipient actually read a message. Most 148 messaging protocols, including CPIM sessions [4], ensure reliable 149 delivery of a message to the recipient. However, they cannot report 150 when a human user actually reads the message. 152 Electronic Mail [12] deals with this situation with message delivery 153 notifications [5]. After the recipient views the message, her mail 154 user agent generates a message delivery notification, or MDN. The 155 MDN is an e-mail that follows the format prescribed by RFC2298 [5]. 156 The fixed format ensures that an automaton can process the message. 157 Even though a MDN is a normal e-mail message, a MDN cannot request a 158 receipt, in order to prevent notification loops. 160 The mechanism described here uses a CPIM header to indicate an IMDN 161 request. By using a CPIM header, we abstract the request outside the 162 transport protocol. This enhances interoperability between different 163 IM systems because the request is at the message level, not transport 164 level. Likewise, the mechanism does not rely on session-mode versus 165 pager-mode or SIP transport or any particular SIP or other response 166 codes. 168 Since the security and privacy considerations have a tremendous 169 influence on a number of design decisions that may at first seem 170 counter-intuitive, the Privacy Considerations (Section 4) and 171 Security Considerations (Section 3) sections appear in the front of 172 this document. 174 The basic protocol flow is as follows. A message sender marks a 175 message for disposition notification. At a certain point in time, 176 the recipient's instant message user agent determines the recipient 177 has read the message or otherwise disposed the message. The 178 mechanism by which an instant message user agent determines its user 179 has read a message is beyond the scope of this document. At that 180 point, the recipient's instant message user agent automatically 181 generates a notification message to the sender. This notification 182 message is the Instant Message Disposition Notification (IMDN). 184 Note there are numerous circumstances under which the instant message 185 user agent may not send a notification. The following sections 186 describe some of these situations. 188 3. Security Considerations 190 All of the security issues raised in RFC2298 [5] apply here. For 191 review, they are forgery and denial of service attacks, 192 confidentiality, and non-repudiation. Note that signing CPIM 193 messages helps in this respect. 195 The threats in the IMDN system, over and beyond the threats inherent 196 to CPIM [4] include the following: 198 o A malicious endpoint attempts to send messages to a user that 199 would normally not wish to receive messages from that endpoint by 200 convincing the IMDN system to "bounce" an IMDN from an 201 unsuspecting endpoint to the user. 202 o A malicious endpoint attempts to flood a user with IMDNs by 203 convincing a B2BUA list exploder to send IMDN responses to an 204 unsuspecting user. 205 o A malicious node in the network that attempts to modify an IMDN 206 from a Reporting UAS. 207 o A malicious B2BUA attempts to forward an IMDN from a Reporting UAS 208 to the Recipient UAC, where the Reporting UAS would not normally 209 forward the IMDN to that Recipient UAC if the identity of the 210 Reporting UAS knew the identity of the Recipient UAC. 211 o A malicious endpoint that attempts to fish for a Request-URI of a 212 UAS beyond a B2BUA, where the UAS would normally wish to keep its 213 identity private from the malicious endpoint. 214 o A malicious node in the network that attempts to eavesdrop on IMDN 215 traffic to, for example, learn Request-URI or traffic pattern 216 information. 217 o A malicious node in the network attempts to stage a denial of 218 service attack on a B2BUA by requesting a large list expansion 219 with a request for consolidated IMDN processing. 221 Attacks the protocol cannot protect against include the following: 222 o A malicious B2BUA directly revealing the identity of a downstream 223 UAS that would not normally wish its identity revealed to such a 224 UAS. Keeping such information private is a B2BUA implementation 225 issue. 226 o A malicious Reporting UAS that alters the time of the report. 227 There is no protocol mechanism for ensuring the UAS does not lie 228 about the time or purposely holds an IMDN for transmission to make 229 it appear the user disposed of a message later than they actually 230 did. 231 o A deletion attack on an IMDN. This is a trade-off between privacy 232 and security. The privacy considerations allow the Reporting UAS 233 to silently ignore an IMDN request. Any mechanism that would 234 reliably indicate that a malicious node deleted a Reporting UAS' 235 message would also serve the purpose of detecting a Reporting UAS 236 that chose not to issue an IMDN. 238 To combat eavesdropping, modification, and man-in-the-middle attacks, 239 we require some level of authentication and integrity protections. 240 That said, there are circumstances where strong integrity would be 241 overkill. The presumption is the sender of the IM has and sets the 242 expectation for the level of protection. The procedures for 243 integrity protection are as follows. 245 o If the Reporting UAS has a certificate, the Reporting UAS MUST 246 sign the IMDN. 247 o If the IM is encrypted, the Reporting UAS MUST encrypt the IMDN 248 body, as an attacker may attempt to discern the user's activity 249 profile and identity from sniffing IMDNs on the network. 250 o The two above rules are cumulative. 251 Reporting UAS' MUST be capable of loading a user certificate. 253 Replay and message insertion attacks are unlikely in an IMDN 254 environment, as the Message-ID cannot be identical within a given 255 session, and the Requesting UAC has the ability to maintain the state 256 of Message-ID's sent for later correlation. Moreover, the instant 257 message itself MUST have the Message-ID sent securely to remove the 258 possibility of an eavesdropper learning the Message-ID. 260 To combat surreptitious delivery of messages by embedding them in 261 IMDN's, as is done today by spammers using MDN's, an IMDN MUST NOT 262 include a copy of the original message. 264 An attacker can mount a distributed denial of service attack on a 265 node by sending lots of messages to the node with IMDN requests. 266 Note that this is the same problem as there is without IMDN; IMDN 267 simply linearly increases the load on the node under attack. One can 268 mitigate, but not eliminate this threat by the UAS immediately 269 ignoring requests that are not authenticated. 271 Likewise, an attacker can mount a denial of service attack on a B2BUA 272 by asking the B2BUA to explode a large list and to direct the B2BUA 273 to consolidate the IMDN's from the targets of the list. 275 4. Privacy Considerations 277 As suggested by RFC2298 [5], it is strongly RECOMMENDED that the user 278 agent obtain the user's consent before sending an IMDN. 279 Circumstances where the user agend does not ask for the user's 280 consent include instant messaging systems that, for regulatory 281 reasons, are required to issue an IMDN, such as in the healthcare 282 field or financial community. 284 A user agent can obtain such consent by a prompt or dialog box on a 285 per-message basis, globally through the user's setting of a 286 preference, or other, user-configurable mechanism. The user might 287 also indicate globally that IMDNs are never to be sent or that a 288 "denied" IMDN is always sent in response to a request for an IMDN. 290 The protocol MUST enable the recipient of the IM to keep the message 291 disposition private. That is, only the sender is able to read the 292 IMDN body text. The transmission of the IMDN SHOULD be end-to-end 293 encrypted, if physically possible. If the Originating UAC encrypted 294 the IM, the Reporting UAS MUST encrypt the IMDN and wrap the result 295 with S/MIME [6]. 297 5. State Sharing 299 One of the design questions for the IMDN design is where to store 300 message state. This becomes a question when we introduce B2BUA's. 301 If there were no B2BUA's, then the Reporting UAS simply sends the 302 IMDN directly to the sender, and the sender retains the state of 303 messages sent that are awaiting IMDN's. However, since we have 304 B2BUA's, we have a choice. One option is for the Requesting UAC to 305 record the state of messages sent and have stateless B2BUA's. 306 Another option is for intermediary B2BUAs to record the state of 307 messages sent and always forward IMDN's back to the immediately 308 preceding message requestor. 310 The trade-offs are as follows: 311 o End-to-End State Sharing 312 * Pro: The actual recipient sends the IMDN directly to the actual 313 sender. It is quite likely the path may be different. For 314 example, while the request may traverse a list exploder 315 (B2BUA), the IMDN's will go directly to the sender. 316 * Pro: With the Reporting UAS sending the report directly to the 317 Requesting UAC, it is possible to keep the disposition private 318 with respect to intermediaries. 319 * Pro: Only the endpoints share state. Network failures do not 320 impact IMDN delivery. Users should know when their user agent 321 fails and can act accordingly. 322 * Pro: No matter what, the Requesting UAC should store state for 323 messages is sends and has an interest in correlating IMDN's. 324 There is no additional burden to the network or user agent. 325 * Pro: The Reporting UAS knows the direct recipient of the IMDN, 326 so it can use more sophisticated algorithms to decide if or 327 what kind of IMDN to generate. Of course, a B2BUA can always 328 hide the true recipient of an IMDN by requesting the report on 329 its own behalf, as it is a full UAC. However, the Reporting 330 UAS can chose not to release information to untrusted B2BUA's. 331 * Con: Slightly more complex protocol, and requires authenticated 332 hop-by-hop transport to combat spam and man-in-the-middle 333 attacks. 334 * Con: Devices with limited resources and a high likelihood of 335 total failure, such as a mobile phone, will lose their IMDN 336 request state on total failure. 338 o Intermediary State Sharing 339 * Pro: Supports endpoints with limited resources or a high 340 likelihood of total failure, so long as all messages go through 341 a B2BUA that records state. 342 * Pro: Simpler protocol: IMDN's always go to the "last" user 343 agent up the relay chain. 344 * Pro: The B2BUA hides a recipient's IMDN reply to address, yet 345 still let the Reporting UAS issue an IMDN the B2BUA will 346 forward to the Requesting UAC. 347 NOTE: Is this important? It is saying that I am sending an 348 IM to someone who I do not want to let talk back to me. 349 That does not really fit the model of IM, does it? 350 * Con: Asking the B2BUA to take the role of IMDN forwarder means 351 the Requesting UAC loses any chance of getting end-to-end 352 IMDN's. 353 * Con: B2BUA's will have a tremendous amount of state to store, 354 especially given their location in the network. 356 The consensus of the work group is to use intermediary state sharing 357 as it results in a simpler protocol. The protocol does leave the 358 potential for future end-to-end state sharing by allowing a token to 359 be the value of the Disposition-Notification header. The most likely 360 value for this token is the URI to send the IMDN directly to. 362 6. Overview 364 6.1. Data Elements 366 The data elements required for IMDN include elements that help 367 correlate notifications with messages, indicate whether or not to 368 generate a notification message, and, of course, the disposition of 369 the message itself. 371 The following list enumerates the data elements of the IMDN in 372 detail. 373 o A protocol data element that indicates an IMDN request 374 o The Original Message Identifier uniquely identifies the original 375 message. Currently there is no unique message identifier in CPIM. 376 Thus we will define one in this document. 377 o The Reporting UAS identifies the UAS generating the IMDN. The 378 reporting UAS might not be the "sender" of the IMDN, as there may 379 be relays [13] between the Reporting UAS and the requesting UAC. 380 o The Original Recipient URI identifies the original URI the 381 requesting UAC sent the message to. This may not be the same as 382 the Reporting UAS, as message delivery to the original URI may 383 have resulted in a list expansion. Section 6.3 describes B2BUA 384 procedures in detail. 386 o An indicator to keep the Original Recipient URI private. 387 o The Message Disposition identifies the eventual disposition of the 388 message, such as read, deleted, and so on. 389 o The Disposition Time indicates when the disposition time at the 390 Reporting UAS. 392 The Requesting UAC needs to indicate to the Reporting UAS to generate 393 an IMDN. The Requesting UAC can indicate whether list exploders or 394 gateways should report on their receipt of the message or report on 395 the actual end recipient's receipt of the message. 397 6.2. Disposition States 399 There are three broad categories of disposition states. They are 400 read, processed, error, and denied. 402 6.2.1. read 404 The "read" state is straightforward. The read state indicates the 405 Recipient's UAS displayed the message to the user. 407 Since there is no positive acknowledgement from the user, one cannot 408 determine a priori the user actually read the message. Thus one MUST 409 NOT use the protocol described here as a non-repudiation service. 411 6.2.2. processed 413 The target URI of the message is a B2BUA. The B2BUA's UAS indicates 414 it successfully received and expanded or relayed the message. 415 However, there MUST NOT be further notifications for this message 416 (see Section 6.3. See Section 8.1.2 for how the Requesting UAS can 417 drive the generation of the processed notification when List-Action 418 is first-recipient. 420 6.2.3. error 422 The error state indicates there was some processing error that makes 423 it impossible or unlikely for the user to get the message. 425 6.2.4. denied 427 The denied state indicates the target URI does not allow 428 notifications. This could be for any reason, including a general 429 policy to not send notifications, denying notifications to the 430 particular sender, or by user direction on a per-message basis. For 431 privacy reasons, the UAS MUST NOT give the reason for denial. 433 6.3. B2BUAs 435 The IMDN framework presented here supports back-to-back user agents 436 (B2BUAs) that forward message requests. This models most approaches 437 for list expansion, including SIP URI lists [16]. It also models 438 most gateway mechanisms. 440 When a user sends a message to a B2BUA URI, there are two options for 441 interpreting "delivery". One option is to consider the message 442 delivered to the list exploder URI itself. This is a strict 443 interpretation of "delivery", as the list exploder URI resolves to 444 the B2BUA UAS. What happens on the other side of the list exploder, 445 namely, the re-origination of a bunch of messages, nominally related 446 to the first message, has no relation in a protocol sense to the 447 original message. 449 The other option is to consider the message delivered to the ultimate 450 recipients of the list. On the one hand, this is what users expect, 451 especially if the list is emulating a chat room. On the other hand, 452 this could result in a storm of responses, which the user does not 453 want. 455 If the B2BUA will be forwarding an IMDN from a downstream endpoint, 456 it will encapsulate the IMDN. This enables signatures over the 457 original message. Moreover, since the end system has the Original 458 From URI, it has the potential to encrypt the IMDN using, for 459 example, S/MIME [6], for the original sender, resulting in end-to-end 460 security. 462 Gateway processing is identical to list exploder processing, in that 463 this mechanism considers a gateway to be a list exploder with a 464 single destination. 466 To ease interpretation of the IMDN at the B2BUA and original 467 Requesting UAC, the B2BUA MUST preserve the original URI the 468 Requesting UAC sent the message to. That is, it must carry the value 469 of the To header in the Original-To CPIM header. 471 7. Namespace 473 Per CPIM [1], IMDN uses a namespace for the CPIM headers. The 474 namespace is 475 urn:ietf:params:cpim-headers:imdn 477 All of the header definitions in this document refer to this 478 namespace. 480 NOTE: If one does not specify the name space in one's CPIM 481 message, YOU WILL NOT GET THE BEHAVIOR DESCRIBED IN THIS DOCUMENT. 483 8. Requesting UAC Behavior 485 8.1. IMDN Request Generation 487 To request the generation of an IMDN, the Requesting UAC MUST include 488 the Disposition-Notification and Message-ID headers. The Requesting 489 UAC MAY also include a List-Action header to provide down-stream 490 B2BUA's with the user's desire for IMDN reporting by the final target 491 of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include the 492 Original-From header, with the value of the inbound From header, 493 unless privacy considerations require the B2BUA to not transmit the 494 Original-From header. Likewise, B2BUA's SHOULD copy the value of the 495 inbound Message-ID into the outbound Original-Message-Id header. 497 If the Requesting UAC insists on the possibility of an IMDN being 498 generated, the UAC MUST include the "Require: imdn.Message- 499 Disposition-To" header, where "imdn" is a reference to the name space 500 (the "NS" header). While this ensures the Reporting UAS is capable 501 of generating an IMDN, there is no guarantee that it actually will 502 generate an IMDN. See the Privacy Considerations (Section 4) section 503 for more discussion on this point. 505 8.1.1. Disposition-Notification 507 To mark a message for disposition notification, the sender MUST 508 include a Disposition-Notification CPIM header in the CPIM part of 509 the request. 511 If the sender requires a notification, the message MUST include a 512 CPIM Require header requiring the processing of the Disposition- 513 Notification CPIM header. Note that if the Recipient UAS does not 514 support IMDN, then the UAS will reject the message. In addition, the 515 Recipient UAS SHOULD NOT display the message. 517 If the sender does not require Disposition-Notification, and the 518 recipient's instant message user agent does not support IMDN, then 519 even though the recipient may read the message, the sender will not 520 receive a notification report. 522 Note that the choice of including a Require header is entirely a 523 local matter to the sender. Some instant messaging user agents may 524 make this a per-receipt request option. Another opinion is the 525 Requesting UAC should never use the Require header to improve 526 interoperability with non-IMDN clients. However, in that case the 527 sender will not know if his message had no report because the 528 recipient did not read it or if the recipient's UAS was simply 529 unaware of IMDN. Thus the decision to use the Require header is 530 entirely outside the scope of this document. 532 The syntax of the Disposition-Notification CPIM header is 533 mdn-request-header = "Disposition-Notification" ":" NULL / token-list 535 token-list = token-list token / token 537 For CPIM conferences, a message with a Disposition-Notification 538 header will result in all recipients performing IMDN processing. If 539 this is not desirable, the sending system MUST send multiple messages 540 with the appropriate requests (IMDN or not). 542 Systems sending an IMDN MUST NOT include a Disposition-Notification 543 header. 545 At this time, there are no Disposition-Notification parameters or 546 tokens defined. Adding Disposition-Notification parameters MUST be 547 by a Standards Track RFC. 549 8.1.2. List-Action 551 If the user sends a message to a B2BUA, such as a list expander or 552 gateway, the Requesting UAC MAY include a List-Action header. The 553 List-Action header indicates how the B2BUA should handle IMDN 554 generation. 556 Values for List-Action are: 557 final-recipient This is a request for the B2BUA to request IMDN's 558 from the subsequent requests and relay the IMDN to 559 the Requesting UAC. 560 first-recipient This is a request for the B2BUA to generate an IMDN 561 for the B2BUA's receipt of the message. That is, 562 the disposition reflects the B2BUA's processing of 563 the message, not any down-stream messages. 564 {other} The Reporting UAS MUST treat unrecognized values for 565 List-Action as "first-recipient". Definitions for 566 new values MUST include optional CPIM REQUIRE tags 567 to ensure interoperability. 569 If the Requesting UAC does not specify List-Action, the default List- 570 Action is first-recipient. 572 The syntax of the List-Action header is as follows. 574 list-action-hdr = "List-Action" ":" SP list-actions 575 list-actions = "final-recipient" 576 / "first-recipient" 577 / token 579 8.1.3. Original-From 581 A Requesting UAC MAY include its From identifier as the value to the 582 Original-From header. If there is no Original-From header, the value 583 of the From header is used. If there is no Original-From header in 584 the message, a B2BUA MUST populate the Original-From value with the 585 From identifier from the inbound message. If there is an Original- 586 From header in the message, a B2BUA MUST pass the Original-From 587 header to the recipient URI(s). This ensures that notifications from 588 lists of lists will work, and that end-to-end encryption of IMDN's 589 will work. 591 If a Requesting UAC wishes to keep her URI private through a B2BUA, 592 then the Reporting UAC includes the Original-From header, but with a 593 NULL value. 595 The syntax of the Original-From is as follows. 596 original-from-header = "Original-From" ":" SP from-whom 598 from-whom = "" / from-address 600 from-address = [ Formal-name ] "<" URI ">" 602 RFC3862 [1] section 4.1 defines "Formal-name". 604 8.1.4. Message-ID 606 A UAC MUST include a globally unique Message-ID. It is necessary for 607 the Message-ID to be unique to the UAC in order for the UAC to be 608 able to exactly correlate IMDN's with the messages they refer to. It 609 will be necessary for the Message-ID to be globally unique in order 610 to support frameworks such as message tracking [15] in the future. 611 Since it is easy enough to make the Message-ID globally unique now, 612 we mandate it here so that message tracking will be easier in the 613 future. 615 A Reporting UAC MUST be prepared to handle a Message-ID token of at 616 least 4095 octets. 618 The syntax of the Message-ID is as follows. 619 message-id-hdr = "Message-ID" ":" SP token 621 A B2BUA generates new messages, and thus the Message-ID will be new. 623 8.1.5. Original-Message-ID 625 Since a B2BUA generates new messages, and thus new Message-ID's, we 626 need a mechanism for the Reporting UAS to insert the appropriate 627 Message-ID in the IMDN. To do this, a B2BUA inserts an Original- 628 Message-ID header with the value of the Message-ID. If there is 629 already an Original-Message-ID header, then the B2BUA MUST preserve 630 the value in the outbound request, unless the request forbids it. 631 The request may forbid it if, for example, the List-Action is first- 632 recipient. If there is no Original-Message-ID present in a message 633 delivered to a B2BUA for subsequent forwarding, the B2BUA MUST copy 634 the value of the Message-ID header of the inbound message to be the 635 value of the Original-Message-ID header of the outbound message(s). 637 The syntax of the Original-Message-ID is as follows. 638 original-message-id-hdr = "Original-Message-ID" ":" SP token 640 8.2. IMDN Reception Processing 642 Once a Requesting UAC sends a message with an IMDN request, it SHOULD 643 preserve the message context, principally the Message-ID, and other 644 user-identifiable information such as the message subject or content. 645 Without preservation of the message context, the Requesting UAC will 646 not be able to correlate the IMDN with the outbound request. The 647 Requesting UAC may find it impossible to preserve message state if it 648 has limited resources or does not have non-volatile memory and then 649 loses power. 651 How long to preserve the state is an implementation choice. However, 652 the Requesting UAC SHOULD keep the state for at least 5 minutes, 653 unless that is physically impossible due to the characteristics of 654 the Requesting UAC. 656 It is RECOMMENDED that a Requesting UAC not notify the user if the 657 Requesting UAC receives an IMDN that does not correlate to a message 658 the Requesting UAC sent. This is to prevent IMDN spoofing. Clearly, 659 if a requesting UAC loses its sent message state, the client may use 660 a different display strategy in response to apparently unsolicited 661 IMDN's. 663 A Requesting UAC MUST NOT issue an IMDN in response to an IMDN, even 664 if that IMDN incorrectly includes a Disposition-Notification header. 666 9. Reporting UAS Operation 667 9.1. General Operation 669 When the Reporting UAS receives a CPIM message with a Disposition- 670 Notification CPIM header, the Reporting UAS SHOULD generate an IMDN. 671 Security Considerations, Privacy Considerations, and local policy all 672 may prevent the generation of an IMDN. 674 The Reporting UAS MUST NOT send more than one IMDN in response to an 675 IMDN request. That is, once an IMDN has been issued on behalf of a 676 recipient, no further IMDNs may be issued on behalf of that 677 recipient, even if another disposition is performed on the message. 678 For example, if the user reads and then deletes the message, the UAS 679 will send a single read notification. The delete operation in this 680 case will not generate an additional IMDN. Likewise, a B2BUA 681 receiving a List-Action of first-recipient MUST NOT relay IMDN's from 682 down-stream UAS's to the original Requesting UAC, as the original 683 Requesting UAC has asked only for an IMDN from the B2BUA. 685 A system receiving an instant message disposition notification MUST 686 NOT generate a message disposition notification in response to that 687 notification, even if the request includes a Disposition-Notification 688 header. 690 A system sending an IMDN MUST NOT include the Disposition- 691 Notification-To header. 693 A CPIM message that requests an IMDN but does not include the 694 required Message-ID header is malformed and the UAS MUST reject the 695 request using the appropriate protocol mechanism for rejecting a 696 malformed request. 697 NOTE: We could be helpful here and create a new SIP result code 698 for this situation. We can do that if needed. 700 The Reporting UAS MUST copy the incoming CPIM Subject: header as the 701 IMDN CPIM Subject: header. 703 9.2. Recipient is the End User UAS 705 If the recipient of a CPIM message with a well-formed IMDN request is 706 the end-user user agent server, then 707 o If the user read the message, then the UAS SHOULD generate a read 708 IMDN, mindful of the privacy considerations enumerated in 709 Section 4. 710 o If the UAS automatically deleted the message, or the user deleted 711 the message without reading it, then the UAS SHOULD generate a 712 processed IMDN, mindful of the privacy considerations enumerated 713 in Section 4. 715 o If the UAS' policy is to deny IMDN to the requestor, or if the 716 user requests a denial report to the UAC, the UAS SHOULD generate 717 a denied IMDN, mindful of the privacy considerations enumerated in 718 Section 4. 719 o If the UAS' policy is to ignore IMDN requests, or the user 720 requests the supression of a given IMDN report, the UAS MUST 721 silently ignore the IMDN request. 723 If the Reporting UAS has a certificate, it MUST sign the IMDN it 724 generates using S/MIME [6]. The Reporting UAS MUST be capable of 725 loading a certificate for signing IMDN's. 727 If the Requesting UAC encrypts the IM, the Reporting UAS MUST encrypt 728 the IMDN. For assistance in this task, the URI of the endpoint 729 requesting the IMDN is in the Original-From header. 731 The Reporting UAS MUST use the format and fill in the content of the 732 IMDN as described in Section 10. 734 9.3. Recipient is a B2BUA 736 If the Recipient UAS is a back-to-back user agent (B2BUA), such as a 737 list exploder or messaging gateway, then the action taken depends on 738 the value of List-Action. If there is no List-Action header, or the 739 UAS does not understand the value of the List-Action header, the UAS 740 takes the "first-recipient" action. 742 9.3.1. first-recipient 744 If the List-Action is "first-recipient" or there is no List-Action 745 specified, then the Recipient UAS issues an IMDN using the following 746 procedures. 747 o If the B2BUA forwards the message, it SHOULD return an "processed" 748 IMDN, mindful of the privacy considerations enumerated in 749 Section 4. 750 o If there was an error processing the message, the B2BUA SHOULD 751 return an "error" IMDN, mindful of the privacy considerations 752 enumerated in Section 4. 754 Including a Disposition-Notification header in the forwarded messages 755 is a matter of local policy. However, if the List-Action is first- 756 recipient or unspecified, the B2BUA MUST NOT relay down-stream IMDN's 757 to the original Requesting UAC. 759 The Reporting UAS MUST use the format and fill in the content of the 760 IMDN as described in Section 10. 762 9.3.2. final-recipient 764 If the List-Action is "final-recipient", then the B2BUA SHOULD 765 forward the Message-Disposition and List-Action headers to down- 766 stream destinations. One condition where the B2BUA might not forward 767 these headers is where the B2BUA knows the down-stream destination 768 will not honor or is not capable of honoring the IMDN request. In 769 the latter case, the B2BUA SHOULD return an "processed" IMDN. In the 770 former case, local policy will decide whether to return a denied 771 IMDN, processed IMDN, or not return an IMDN at all. 773 When the B2BUA receives an IMDN from the Reporting UAS, the B2BUA 774 will encapsulate the IMDN from the downstream UAS and send the 775 response to the UAC that generated the upstream request. The B2BUA 776 MUST verify the Original-Message-ID header matches a Message-ID of a 777 previous incoming request. 779 How long to keep the Message-ID state is a local matter. We 780 RECOMMEND it be at least 5 minutes. 782 If the B2BUA receives an IMDN that does not match an existing 783 Message-ID, the B2BUA MUST discard the IMDN. 785 9.3.3. No List-Action Specified 787 If there is no List-Action header, or there is a List-Action header 788 with no value, the Reporting UAS MUST follow the procedures for 789 first-recipient. 791 9.3.4. Unknown List-Action Specified 793 If there is a List-Action header, but the Reporting UAS does not 794 recognize the value of the List-Action header, the Reporting UAS MUST 795 follow the procedures for first-recipient. 797 10. IMDN Format 799 The IMDN is an XML [7] document. The document MUST be well formed 800 and MUST be valid according to the schema presented in Section 12.2. 801 The namespace identifier for elements defined by this specification 802 is a URN [8], using the namespace identifier 'ietf' as defined by 803 IETF URN Namespace [9] and extended by the IETF XML Registry [11]. 804 The URN is 805 urn:ietf:params:xml:ns:imdn 807 The root element is . The disposition tag takes the value 808 described in Section 6.2. 810 10.1. disposition 812 The Reporting UAS MUST include the message disposition in the 813 disposition tag. 815 We use a string value, rather than an attribute value, to enable 816 future addition of state strings 818 The value of the disposition tag may take the following values: 819 read The message was read. 820 processed The message was processed. 821 error There was an error processing the message. 822 denied The Reporting UAS denies reporting the disposition 823 of the message. 825 10.2. original-message-id 827 The Reporting UAS MUST include the value of the Message-ID of the IM 828 as the value of the original-message-id tag. 830 10.3. original-recipient-uri 832 The Reporting UAS MUST include the value of the original message's 833 Original-From as the value of the original-recipient-uri tag. If the 834 Reporting UAS specified a NULL Original-From, then the Reporting UAS 835 MUST return an empty original-recipient-uri value. 837 10.4. reporting-uas-uri 839 The Reporting UAS SHOULD include its URI in the reporting-uas-uri 840 tag. One condition where the Reporting UAS will not include its URI 841 is if it wants to keep its URI private. In this case the Reporting 842 UAS MUST NOT include this tag in the IMDN. 844 10.5. original-recipient 846 If there is an Original-To header in the IM, the Reporting UAS MUST 847 include the value of the Original-To header as the value to the 848 original-recipient tag. 850 10.6. disposition-time 852 The Reporting UAS MUST include the disposition time reflecting when 853 the reported disposition occured as the value of the disposition-time 854 tag. The format of the time value MUST follow the format specified 855 in RFC 3339 [10], using UTC. 857 11. Examples 859 11.1. Simple End-to-End IMDN Request 861 Request 863 From: Eric Burger 864 To: Hisham Khartabil 865 DateTime: 2005-10-18T09:27:22-5 866 Subject: Did you get this? 867 NS: imdn 868 imdn.Disposition-Notification: 869 imdn.Message-ID: 1542af3e8b@eburger@example.com 871 Content-type: text/xml; charset=utf-8 872 Content-ID: <1542af3e8b-12@eburger@example.com> 874 875 Did you get this message? 876 878 Response 879 From: Hisham Khartabil 880 To: 881 DateTime: 2005-10-18T09:30:18+1 882 Subject: Did you get this? 883 NS: imdn 884 imdn.Message-ID: latida27@stuff@example.net 886 Content-type: multipart/signed; boundary=next; 887 micalg=sha1; 888 protocol=application/pkcs7-signature 890 --next 891 Content-type: application/imdn+xml; charset=utf-8 893 894 read 895 896 im:hisham.khartabil@example.net 897 898 899 im:hisham.khartabil@example.net 900 901 902 1542af3e8b@eburger@example.com 903 904 905 --next 906 Content-type: application/pkcs7-signature 908 {signature stuff} 909 : 910 : 911 --next-- 913 Note the IMDN plaintext would not have the CRLF's in the data 914 elements. We do that here simply for readability. 916 11.2. Gateway Endpoint 918 Happy Path for gateway reporting it forwarded. Same request as 919 above, but with processed response. 921 11.3. List Exploder - Forward 923 Happy Path for forwarding case. Note the different responses, but 924 with same Original-To and Original-Message-Id. 926 11.4. List Exploder - Private Forward 928 Show no Original-Sender 930 11.5. List With Lists 932 Show wrapped, wrapped responses. 934 11.6. End-to-End Encryption Forwarded 936 Gateway scenario where Reporting UAS encrypts IMDN document for read 937 only by Requesting UAC. 939 12. Formal Syntax 941 12.1. IMDN CPIM Request 943 TODO: collect syntax from above. 945 12.2. IMDN Document 947 Coming soon. 949 13. IANA Considerations 951 URN name in IETF namespace: urn:ietf:params:cpim-headers:imdn 953 IMDN schema in Section 12.2. 955 14. References 957 14.1. Normative References 959 [1] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 960 (CPIM): Message Format", RFC 3862, August 2004. 962 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 963 Levels", BCP 14, RFC 2119, March 1997. 965 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 966 Specifications: ABNF", RFC 4234, October 2005. 968 [4] Campbell, B., "The Message Session Relay Protocol", 969 draft-ietf-simple-message-sessions-13 (work in progress), 970 December 2005. 972 [5] Fajman, R., "An Extensible Message Format for Message 973 Disposition Notifications", RFC 2298, March 1998. 975 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 976 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 977 July 2004. 979 [7] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. 980 Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", 981 W3C REC REC-xml-20040204, February 2004. 983 [8] Moats, R., "URN Syntax", RFC 2141, May 1997. 985 [9] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 986 August 1999. 988 [10] Klyne, G. and C. Newman, "Date and Time on the Internet: 989 Timestamps", RFC 3339, July 2002. 991 [11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 992 January 2004. 994 14.2. Informative References 996 [12] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 997 April 2001. 999 [13] Jennings, C., "Relay Extensions for the Message Sessions Relay 1000 Protocol (MSRP)", draft-ietf-simple-msrp-relays-06 (work in 1001 progress), December 2005. 1003 [14] Hansen, T. and G. Vaudreuil, "Message Disposition 1004 Notification", RFC 3798, May 2004. 1006 [15] Hansen, T., "Message Tracking Model and Requirements", 1007 RFC 3888, September 2004. 1009 [16] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 1010 Requests in the Session Initiation Protocol (SIP)", 1011 draft-ietf-sipping-uri-list-message-06 (work in progress), 1012 January 2006. 1014 Appendix A. Contributors 1016 Appendix B. Acknowledgements 1017 Thanks go to Ben Campbell for continuously prodding me. Thanks also 1018 to Hisham for the relay idea and threatening some text to force me 1019 back to the task. Dean kept reminding me that 3GPP really, really 1020 wants this done and to work. 1022 Author's Address 1024 Eric Burger 1025 Brooktrout Technology, Inc. 1026 18 Keewaydin Dr. 1027 Salem, NH 03079-2839 1028 USA 1030 Phone: +1 603 890 7587 1031 Fax: +1 603 457 5944 1032 Email: eburger@brooktrout.com 1034 Intellectual Property Statement 1036 The IETF takes no position regarding the validity or scope of any 1037 Intellectual Property Rights or other rights that might be claimed to 1038 pertain to the implementation or use of the technology described in 1039 this document or the extent to which any license under such rights 1040 might or might not be available; nor does it represent that it has 1041 made any independent effort to identify any such rights. Information 1042 on the procedures with respect to rights in RFC documents can be 1043 found in BCP 78 and BCP 79. 1045 Copies of IPR disclosures made to the IETF Secretariat and any 1046 assurances of licenses to be made available, or the result of an 1047 attempt made to obtain a general license or permission for the use of 1048 such proprietary rights by implementers or users of this 1049 specification can be obtained from the IETF on-line IPR repository at 1050 http://www.ietf.org/ipr. 1052 The IETF invites any interested party to bring to its attention any 1053 copyrights, patents or patent applications, or other proprietary 1054 rights that may cover technology that may be required to implement 1055 this standard. Please address the information to the IETF at 1056 ietf-ipr@ietf.org. 1058 Disclaimer of Validity 1060 This document and the information contained herein are provided on an 1061 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1062 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1063 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1064 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1065 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1066 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1068 Copyright Statement 1070 Copyright (C) The Internet Society (2006). This document is subject 1071 to the rights, licenses and restrictions contained in BCP 78, and 1072 except as set forth therein, the authors retain all their rights. 1074 Acknowledgment 1076 Funding for the RFC Editor function is currently provided by the 1077 Internet Society.