SIMPLE E. Burger Internet-Draft Brooktrout Technology, Inc. Expires: April 26, 2006 H. Khartabil Telio October 23, 2005 Instant Message Delivery Notification (IMDN) for Common Presence and Instant Messaging (CPIM) Messages draft-burger-simple-imdn-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a mechanism for instant message delivery notification (IMDN) in the CPIM (Common Presence and Instant Messaging) environment. The mechanism follows the procedures of ESMTP message delivery notification (MDN). Burger & Khartabil Expires April 26, 2006 [Page 1] Internet-Draft IMDN October 2005 Table of Contents 1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6 5. State Sharing . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Data Elements . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Disposition States . . . . . . . . . . . . . . . . . . . . 9 6.3. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Requesting UAC Behavior . . . . . . . . . . . . . . . . . . . 12 8.1. IMDN Request Generation . . . . . . . . . . . . . . . . . 12 8.1.1. Disposition-Notification-To . . . . . . . . . . . . . 12 8.1.2. List-Action . . . . . . . . . . . . . . . . . . . . . 14 8.1.3. Original-From . . . . . . . . . . . . . . . . . . . . 14 8.1.4. Message-ID . . . . . . . . . . . . . . . . . . . . . . 15 8.1.5. Original-Message-ID . . . . . . . . . . . . . . . . . 15 8.2. IMDN Reception Processing . . . . . . . . . . . . . . . . 15 9. Reporting UAS Operation . . . . . . . . . . . . . . . . . . . 16 9.1. General Operation . . . . . . . . . . . . . . . . . . . . 16 9.2. Recipient is the End User UAS . . . . . . . . . . . . . . 16 9.3. Recipient is a B2BUA . . . . . . . . . . . . . . . . . . . 17 9.3.1. No List-Action or first-recipient . . . . . . . . . . 17 9.3.2. final-recipient . . . . . . . . . . . . . . . . . . . 18 10. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Simple End-to-End Read Request . . . . . . . . . . . . . . 19 11.2. Gateway Endpoint . . . . . . . . . . . . . . . . . . . . . 20 11.3. List Exploder - Forward . . . . . . . . . . . . . . . . . 20 11.4. List Exploder - Consolidate . . . . . . . . . . . . . . . 21 11.5. List With Lists . . . . . . . . . . . . . . . . . . . . . 21 11.6. End-to-End Encryption Forwarded . . . . . . . . . . . . . 21 12. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. IMDN CPIM Request . . . . . . . . . . . . . . . . . . . . 21 12.2. IMDN Document . . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Burger & Khartabil Expires April 26, 2006 [Page 2] Internet-Draft IMDN October 2005 1. Document Conventions This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. In this document, the term "CPIM header" refers to the message metadata headers encapsulated in a Message/CPIM object [1]. The term "IM" refers to Instant Message. The term "Requesting UAC" is the User Agent Client that sends the message the user would like a disposition notification for. The term "Reporting UAS" is the User Agent Server that sends the disposition notification back to the Requesting UAC. The term "B2BUA" refers to a Back-to-Back User Agent. IM B2BUA's implement gateways and list exploders, amongst other functions. If you missed it in the title, the term "IMDN" is an Instant Message Delivery Notification. The IMDN indicates the disposition of the message after the message is available to the recipient. NOTE: Text like this, offset from the margin and starting with the word "NOTE:", is not normative and present only for discussion or explanation purposes. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2]. This document uses the augmented Backus-Naur Form (BNF) as described in RFC2234 [3] for all syntax specification uses, other than XML. Examples and discussion of CPIM headers, for clarity, do not include the leading name space identifer. 2. Introduction In many user-to-user message exchange systems, message senders often wish to know if the human recipient actually read a message. Most messaging protocols, including CPIM sessions [4], ensure reliable delivery of a message to the recipient. However, they cannot report when a human user actually reads the message. Burger & Khartabil Expires April 26, 2006 [Page 3] Internet-Draft IMDN October 2005 Electronic Mail [11] deals with this situation with message delivery notifications [5]. After the recipient views the message, her mail user agent generates a message delivery notification, or MDN. The MDN is an e-mail that follows the format prescribed by RFC2298 [5]. The fixed format ensures that an automaton can process the message. Even though a MDN is a normal e-mail message, a MDN cannot request a receipt, in order to prevent notification loops. The mechanism by which an instant message user agent determines its user has read a message is beyond the scope of this document. However, there are many problems that are important to consider. An appendix to this document enumerates a number of these issues. The mechanism described here uses a CPIM header to indicate an IMDN request. By using a CPIM header, we abstract the request outside the transport protocol. This enhances interoperability between different IM systems because the request is at the message level, not transport level. Likewise, the mechanism does not rely on session-mode versus pager-mode or SIP transport or any particular SIP or other response codes. Since the security and privacy considerations have a tremendous influence on a number of design decisions that may at first seem counter-intuitive, the Privacy Considerations (Section 4) and Security Considerations (Section 3) sections appear in the front of this document. The basic protocol flow is as follows. A message sender marks a message for disposition notification. At a certain point in time, the recipient's instant message user agent determines the recipient has read the message, deleted the message, or otherwise disposed the message. At that point, the recipient's instant message user agent automatically generates a notification message to the sender. This notification message is the Instant Message Disposition Notification (IMDN). Note there are numerous circumstances under which the instant message user agent may not send a notification. The following sections describe some of these situations. 3. Security Considerations All of the security issues raised in RFC2298 [5] apply here. For review, they are forgery and denial of service attacks, confidentiality, and non-repudiation. Note that signing CPIM messages helps in this respect. Burger & Khartabil Expires April 26, 2006 [Page 4] Internet-Draft IMDN October 2005 The threats in the IMDN system, over and beyond the threats inherent to CPIM [4] include the following: o A malicious endpoint attempts to send messages to a user that would normally not wish to receive messages from that endpoint by convincing the IMDN system to "bounce" an IMDN from an unsuspecting endpoint to the user. o A malicious endpoint attempts to flood a user with IMDNs by convincing a B2BUA list exploder to send IMDN responses to an unsuspecting user. o A malicious node in the network that attempts to modify an IMDN from a Reporting UAS. o A malicious B2BUA attempts to forward an IMDN from a Reporting UAS to the Recipient UAC, where the Reporting UAS would not normally forward the IMDN to that Recipient UAC if the identity of the Reporting UAS knew the identity of the Recipient UAC. o A malicious endpoint that attempts to fish for a Request-URI of a UAS beyond a B2BUA, where the UAS would normally wish to keep its identity private from the malicious endpoint. o A malicious node in the network that attempts to eavesdrop on IMDN traffic to, for example, learn Request-URI or traffic pattern information. o A malicious node in the network attempts to stage a denial of service attack on a B2BUA by requesting a large list expansion with a request for consolidated for IMDN processing. Attacks the protocol cannot protect against include the following: o A malicious B2BUA directly revealing the identity of a downstream UAS that would not normally wish its identity revealed to such a UAS. Keeping such information private is a B2BUA implementation issue. o A malicious Reporting UAS that alters the time of the report. There is no protocol mechanism for ensuring the UAS does not lie about the time or purposely holds an IMDN for transmission to make it appear the user disposed of a message later than they actually did. o A deletion attack on an IMDN. This is a trade-off between privacy and security. The privacy considerations allow the Reporting UAS to silently ignore an IMDN request. Any mechanism that would reliably indicate that a malicious node deleted a Reporting UAS' message would also serve the purpose of detecting a Reporting UAS that chose not to issue an IMDN. To combat eavesdropping, modification, and man-in-the-middle attacks, one MUST encrypt the IMDN body, as an attacker may attempt to discern the user's activity profile and identity from sniffing IMDNs on the network. Replay and message insertion attacks are unlikely in an IMDN Burger & Khartabil Expires April 26, 2006 [Page 5] Internet-Draft IMDN October 2005 environment, as the Message-ID cannot be identical within a given session, and the Requesting UAC has the ability to maintain the state of Message-ID's sent for later correlation. Moreover, the instant message itself MUST have the Message-ID sent securely to remove the possibility of an eavesdropper learning the Message-ID. Probably the greatest network threat is a denial of service attack. An attacker may setup a denial of service attack to an unsuspecting endpoint by sending lots of messages to many instant message user agents, requesting those user agents to send their IMDNs to the attacked node. This is why one SHOULD NOT send IMDNs to a user other than the one that sent the message. Moreover, the Reporting UAS MUST authenticate the node that made the IMDN request (either the Requesting UAC or a B2BUA) to enable reliable tracing of attacks. In addition, this holds true for B2BUA's the forward requests. Namely, the B2BUA MUST authenticate the UAC making the request, as well as provide authentication to the UAS. It is important to note the text mentions UAC and UAS, as one can have cascading B2BUAs. To combat surreptitious delivery of messages by embedding them in IMDN's, as is done today by spammers using MDN's, an IMDN MUST NOT include a copy of the original message. An attacker can mount a distributed denial of service attack on a node by sending lots of messages to the node with IMDN requests. Note that this is the same problem as there is without IMDN; IMDN simply linearly increases the load on the node under attack. One can mitigate, but not eliminate this threat by the UAS immediately ignoring requests that are not authenticated. Likewise, an attacker can mount a denial of service attack on a B2BUA by asking the B2BUA to explode a large list and to direct the B2BUA to consolidate the IMDN's from the targets of the list. 4. Privacy Considerations As suggested by RFC2298 [5], it is strongly RECOMMENDED that the user agent obtain the user's consent before sending an IMDN. Circumstances where the user agend does not ask for the user's consent include instant messaging systems that, for regulatory reasons, are required to issue an IMDN, such as in the healthcare field. A user agent can obtain such consent by a prompt or dialog box on a per-message basis, globally through the user's setting of a preference, or other, user-configurable mechanism. The user might also indicate globally that IMDNs are never to be sent or that a Burger & Khartabil Expires April 26, 2006 [Page 6] Internet-Draft IMDN October 2005 "denied" IMDN is always sent in response to a request for an IMDN. A user sending a message through a B2BUA may not wish to have their address revealed, yet still wish to receive IMDNs. In this case the Requesting UAC indicates to the B2BUA to keep the Requesting UAC's address private. In this case, the B2BUA MUST remove all references to the Requesting UAC and, as well, MUST indicate to the Reporting UAS that the Requesting UAC's address is private. THIS IS WHY B2BUA'S MUST RELAY RESPONSES. Recipient systems SHOULD NOT automatically send IMDNs if the URI in the Disposition-Notification-To header differs from the address of the sender. Recipient systems MUST use reliable mechanisms for authenticating the sender, such as from the underlying transport protocol. Recipient systems MUST NOT rely on unsigned information in the CPIM message, such as the From header. Recipient systems SHOULD obtain confirmation from the user, or not send an IMDN, if it cannot reliably determine the sender's address. The reason for not automatically sending an IMDN is to reduce the possibility of IMDN bombing a third party. On a related note, the protocol MUST enable the recipient of the IM to keep the message disposition private. That is, only the sender is able to read the IMDN body text. Thus either the transmission of the IMDN MUST be end-to-end encrypted or the body of the IMDN MUST be encrypted with, for example, S/MIME [6]. 5. State Sharing One of the design questions for the IMDN design is where to store message state. This becomes a question when we introduce B2BUA's. If there were no B2BUA's, then the Reporting UAS simply sends the IMDN directly to the sender, and the sender retains the state of messages sent that are awaiting IMDN's. However, since we have B2BUA's, we have a choice. One option is for the Requesting UAC to record the state of messages sent and have stateless B2BUA's. Another option is for intermediary B2BUAs to record the state of messages sent, and simply always forwarding IMDN's back to the immediately preceding message requestor. The trade-offs are as follows: o End-to-End State Sharing * Pro: The actual recipient sends the IMDN directly to the actual sender. It is quite likely the path may be different. For example, while the request may traverse a list exploder Burger & Khartabil Expires April 26, 2006 [Page 7] Internet-Draft IMDN October 2005 (B2BUA), the IMDN's will go directly to the sender. * Pro: With the Reporting UAS sending the report directly to the Requesting UAC, it is possible to keep the disposition private with respect to intermediaries. * Pro: Only the endpoints share state. Network failures do not impact IMDN delivery. Users should know when their user agent fails and can act accordingly. * Pro: No matter what, the Requesting UAC should store state for messages is sends and has an interest in correlating IMDN's. There is no additional burden to the network or user agent. * Pro: The Reporting UAS knows the direct recipient of the IMDN, so it can use more sophisticated algorithms to decide if or what kind of IMDN to generate. Of course, a B2BUA can always hide the true recipient of an IMDN by requesting the report on its own behalf, as it is a full UAC. However, the Reporting UAS can chose not to release information to untrusted B2BUA's. * Con: Slightly more complex protocol, and requires authenticated hop-by-hop transport to combat spam and man-in-the-middle attacks. * Con: Devices with limited resources and a high likelihood of total failure, such as a mobile phone, will lose their IMDN request state on total failure. o Intermediary State Sharing * Pro: Supports endpoints with limited resources or a high likelihood of total failure, so long as all messages go through a B2BUA that records state. * Pro: Simpler protocol: IMDN's always go to the "last" user agent up the relay chain. * Pro: The B2BUA can chose to hide a recipient's IMDN reply to address, yet still let the Reporting UAS issue an IMDN the B2BUA will forward to the Requesting UAC. NOTE: Is this important? It is saying that I am sending an IM to someone who I do not want to let talk back to me. That does not really fit the model of IM, does it? * Con: Asking the B2BUA to take the role of IMDN forwarder means the Requesting UAC loses any chance of getting end-to-end IMDN's. * Con: B2BUA's will have a tremendous amount of state to store, especially given their location in the network. NOTE: There are probably others, but I can't think of them now. 6. Overview 6.1. Data Elements The data elements required for IMDN include elements that help correlate notifications with messages, indicate whether or not to Burger & Khartabil Expires April 26, 2006 [Page 8] Internet-Draft IMDN October 2005 generate a notification message, and, of course, the disposition of the message itself. The following list enumerates the data elements of the IMDN in detail. o A protocol data element that indicates an IMDN request, and where to send the IMDN to. Allowing the IMDN to go to a different address than the sender enables, for example in SIMPLE, the From: to be "sip:info@example.com" but have the IMDN to go to "sip:agent23@example.com". o The Original Message Identifier uniquely identifies the original message. Currently there is no unique message identifier in CPIM. Thus we will define one in this document. o The Reporting UAS identifies the UAS generating the IMDN. The reporting UAS might not be the "sender" of the IMDN, as there may be relays [12] between the Reporting UAS and the requesting UAC. o The Original Recipient URI identifies the original URI the requesting UAC sent the message to. This may not be the same as the Reporting UAS, as message delivery to the original URI may have resulted in a list expansion. Section 6.3 describes list procedures in detail. o The Message Disposition identifies the eventual disposition of the message, such as read, deleted, and so on. NOTE: There is no Date or Delivered element, as that would be a totally content-free, because of the lack of accuracy and veracity of the data. First, the accuracy of the date / time stamp would depend on the Reporting UAS' clock being synchronized. Second, there is absolutely no way to ensure the veracity of the reported time. The user can always hack their clock to change the reported time. Moreover, most of the IM transport protocols have a concept of tranmit time. Lastly, CPIM itself has a message time stamp. Thus the recipient has some clue as to when the Reporting UAS sent the IMDN. The Requesting UAC needs to indicate to the Reporting UAS to generate an IMDN. The Requesting UAC can indicate whether list exploders or gateways should report on their receipt of the message or report on the actual end recipients receipt of the message. 6.2. Disposition States There are three broad categories of disposition states. They are read, successfully processed, and failed. The "read" state is straightforward. The read state indicates the Recipient's UAS displayed the message to the user. Since there is no positive acknowledgement from the user, one cannot Burger & Khartabil Expires April 26, 2006 [Page 9] Internet-Draft IMDN October 2005 determine a priori the user actually read the message. Thus one MUST NOT use the protocol described here as a non-repudiation service. The successfully processed states are as follows. deleted The UAS deleted the message. This could be automatic, based on policy, or manually done by the user. NOTE: MDN [13] additionally indicated whether the deletion was manual or automatic. Is this of use for us in the IMDN case? expanded The target URI of the message is a list exploder or gateway. The UAS is indicating it successfully received and expanded or relayed the message. However, there MUST NOT be further notifications for this message (see Section 6.3. Error states are "error" and "denied". error There was some processing error that makes it impossible or unlikely for the user to get the message. denied The target URI does not allow notifications. This could be for any reason, including a general policy to not send notifications, denying notifications to the particular sender, or by user direction on a per-message basis. For privacy reasons, the UAS MUST NOT give the reason for denial. 6.3. B2BUAs The IMDN framework presented here supports back-to-back user agents (B2BUAs) that forward message requests. This models most approaches for list expansion, including SIP URI lists [15]. It also models most gateway mechanisms. When a user sends a message to a B2BUA URI, there are two options for interpreting "delivery". One option is to consider the message delivered to the list exploder URI itself. This is a strict interpretation of "delivery", as the list exploder URI is a UAS in itself. What happens on the other side of the list exploder, namely, the re-origination of a bunch of messages related to the first message, has no relation in a protocol sense to the original message. The other option is to consider the message delivered to the ultimate recipients of the list. On the one hand, this is what users expect, especially if the list is emulating a chat room. On the other hand, this could result in a storm of responses, which the user does not want. Unlike the e-mail situation, we can specify explicit behavior. This means adding a directive indicating the reporting mode. The reporting mode is either "final-recipient", indicating a report Burger & Khartabil Expires April 26, 2006 [Page 10] Internet-Draft IMDN October 2005 request for every final destination or "consolidate". The default is final-recipient. If the B2BUA will consolidate responses, it simply originates a new (set of) message(s), setting the recipient of the report to itself. The IMDN protocol machinery described here encourages end-to-end taransmission of the IMDN. However, a B2BUA is free to receive IMDN reports instead of the Requesting UAC. By definition, the B2BUA can terminate the Requesting UAC's IMDN request and generate a new IMDN request, in the B2BUA's role as a UAC. If the B2BUA will be forwarding an IMDN from a downstream endpoint, it will encapsulate the IMDN. This enables signatures over the original message. Moreover, since the end system has the Original From URI, it has the potential to encrypt the IMDN using, for example, S/MIME [6], for the original sender, resulting in end-to-end security. The consolidate request has the B2BUA batch the individual IMDNs and passes them in a single IMDN. The final system request forwards the IMDNs as the B2BUA receives them. How long to wait for batching is a local matter at the B2BUA. NOTE TO SELF: For the case where we have Message-Disposition-To, since the Message-Id is globally unique, and should be cryptographically random, the sending UAC at least has the possibility of discriminating between IMDN that relate to a real message request and just random or mis-directed (storm) messages. The decision to honor the "consolidate" directive is a local matter. The B2BUA reject the request if local policy prevents IMDN consolidation. The B2BUA MUST reject the request in the same manner it would reject a list expansion request. NOTE: Should consolidation, if we keep it in the protocol, be a negotiable entity? Maybe a Requires: in the UAC request? Gateway processing is identical to list exploder processing, in that this mechanism considers a gateway to be a list exploder with a single destination. 7. Namespace Per CPIM [1], IMDN uses a namespace for the CPIM headers. The namespace is urn:ietf:params:cpim-headers:imdn All of the header definitions in this document refer to this Burger & Khartabil Expires April 26, 2006 [Page 11] Internet-Draft IMDN October 2005 namespace. NOTE: If one does not specify the name space in one's CPIM message, YOU WILL NOT GET THE BEHAVIOR DESCRIBED IN THIS DOCUMENT. 8. Requesting UAC Behavior 8.1. IMDN Request Generation To request the generation of an IMDN, the Requesting UAC MUST include the Disposition-Notification-To and Message-ID headers. The Requesting UAC MAY also include a List-Action header to provide down- stream B2BUA's with the user's desire for IMDN reporting by the final target of B2BUA expansion or the B2BUA itself. B2BUA's SHOULD include the Original-From header, with the value of the inbound From header, unless privacy considerations require the B2BUA to not transmit the Original-From header. Likewise, B2BUA's SHOULD copy the value of the inbound Message-ID into the outbound Original-Message-Id header. If the Requesting UAC insists on the possibility of an IMDN being generated, the UAC MUST include the "Require: imdn.Message- Disposition-To" header, where "imdn" is a reference to the name space (the "NS" header). While this ensures the Reporting UAS is capable of generating an IMDN, there is no guarantee that it actually will generate an IMDN. See the Privacy Considerations (Section 4) section for more discussion on this point. 8.1.1. Disposition-Notification-To To mark a message for disposition notification, the sender MUST include a Disposition-Notification-To CPIM header in the CPIM part of the request. If the sender requires a notification, the message MUST include a CPIM Require header requiring the processing of the Disposition- Notification-To CPIM header. Note that if the Recipient UAS does not support IMDN, then the UAS will reject the message. In addition, the Recipient UAS SHOULD NOT display the message. If the sender does not require Disposition-Notification-To, and the recipient's instant message user agent does not support IMDN, then even though the recipient may read the message, the sender will not receive a notification report. Note that the choice of including a Require header is entirely a local matter to the sender. Some instant messaging user agents may Burger & Khartabil Expires April 26, 2006 [Page 12] Internet-Draft IMDN October 2005 make this a per-receipt request option. Another opinion is the Requesting UAC should never use the Require header to improve interoperability with non-IMDN clients. However, in that case the sender will not know if his message had no report because the recipient did not read it or if the recipient's UAS was simply unaware of IMDN. Thus the decision to use the Require header is entirely outside the scope of this document. The sender can request a delivery notification or a failure notification. The sender indicates where the Reporting UAS is to send the IMDN as a URI value to the Disposition-Notification-To header. NOTE: MDN [13] in the e-mail world allows for the disposition reports to go to a destination other than the sending UAC. One reason for this is that SMTP re-writing could obscure the sender and list exploders, acting as back-to-back mail user agents, also obscure the sender address. Moreover, it is quite useful for message tracking [14]. On the other hand, specifying an arbitrary address to get messages, especially in the case of a list exploder, is a major opportunity for a distributed attack on a host. See the Security Considerations (Section 3) section for more discussion on this topic. The syntax of the Disposition-Notification-To CPIM header is mdn-request-header = "Disposition-Notification-To" ":" SP notify-URI [ param-list ] param-list = param-list param / param param = ";" token notify-URI = URI The notify-URI is the destination URI for the IMDN. Typically, this will be the reverse path for the instant message session. Another sensible value is a session at the sender's terminal that collects disposition notifications. See the Security Considerations section for other permissible values of the notify-URI. For CPIM conferences, a message with a Disposition-Notification-To header will result in all recipients performing IMDN processing. If this is not desirable, the sending system MUST send multiple messages with the appropriate requests (IMDN or not). Systems sending an IMDN MUST NOT include the Disposition- Notification-To header. Burger & Khartabil Expires April 26, 2006 [Page 13] Internet-Draft IMDN October 2005 At this time, there are no Disposition-Notification-To parameters defined. 8.1.2. List-Action If the user sends a message to a B2BUA, such as a list expander or gateway, the Requesting UAC MAY include a List-Action header. The List-Action header indicates how the B2BUA should handle IMDN generation. Values for List-Action are: final-recipient This is a request for the B2BUA to have the Reporting UAS send the IMDN directly to the Requesting UAC (the Disposition-Notification-To URI). first-recipient This is a request for the B2BUA to generate an IMDN for the B2BUA's receipt of the message. That is, the disposition reflects the B2BUA's processing of the message, not any down-stream messages. NOTE: The last version of this document had a "consolidate" request. This request had the B2BUA consolidate IMDN's from the exploded list and then have the B2BUA send a single IMDN to the Requesting UAC. However, this introduces a lot of protocol complexity, such as how long the B2BUA waits for responses. For now, I've punted this capability. I can bring back the text if this is an important function. If the Requesting UAC does not specify List-Action, the default List- Action is first-recipient. The syntax of the List-Action header is as follows. list-action-hdr = "List-Action" ":" SP list-actions list-actions = "final-recipient" / "first-recipient" / token 8.1.3. Original-From A Requesting UAC MAY include its From identifier as the value to the Original-From header. If there is no Original-From header, the value of the From header is used. If there is no Original-From header in the message, a B2BUA MUST use the From identifier from the inbound message. If there is an Original-From header in the message, a B2BUA MUST pass the Original-From header to the recipient URI(s). This ensures that notifications from lists of lists will work. The syntax of the Original-From is as follows. Burger & Khartabil Expires April 26, 2006 [Page 14] Internet-Draft IMDN October 2005 original-from-header = "Original-From" ":" SP [ Formal-name ] "<" URI ">" RFC3862 [1] section 4.1 defines "Formal-name". 8.1.4. Message-ID A UAC MUST include a globally unique Message-ID. It is necessary for the Message-ID to be unique to the UAC in order for the UAC to be able to exactly correlate IMDN's with the messages they refer to. It will be necessary for the Message-ID to be globally unique in order to support frameworks such as message tracking [14] in the future. Since it is easy enough to make the Message-ID globally unique now, we mandate it here so that message tracking will be easier in the future. The syntax of the Message-ID is as follows. message-id-hdr = "Message-ID" ":" SP token A B2BUA generates new messages, and thus the Message-ID will be new. 8.1.5. Original-Message-ID Since a B2BUA generates new messages, and thus new Message-ID's, we need a mechanism for the Reporting UAS to insert the appropriate Message-ID in the IMDN. To do this, a B2BUA inserts an Original- Message-ID header with the value of the Message-ID. If there is already an Original-Message-ID header, then the B2BUA MUST preserve the value in the outbound request, unless the request forbids it. The request may forbid it if, for example, the List-Action is first- recipient. If there is no Original-Message-ID present in a message delivered to a B2BUA for subsequent forwarding, the B2BUA MUST copy the value of the Message-ID header of the inbound message to be the value of the Original-Message-ID header of the outbound message(s). The syntax of the Original-Message-ID is identical to the syntax of the Message-ID. 8.2. IMDN Reception Processing Once a Requesting UAC sends a message with an IMDN request, it SHOULD preserve the message context, principally the Message-ID, and other user-identifiable information, such as the message subject or content. Without preservation of the message context, the Requesting UAC will not be able to correlate the IMDN with the outbound request. How long to preserve the state is an implementation choice. However, the Requesting UAC SHOULD keep the state for at least 5 minutes. Burger & Khartabil Expires April 26, 2006 [Page 15] Internet-Draft IMDN October 2005 It is RECOMMENDED that a Requesting UAC not notify the user if the Requesting UAC receives an IMDN that does not correlate to a message the Requesting UAC sent. If a first IMDN has a Disposition-Notification-To header, the Requesting UAC MUST NOT issue a second IMDN in response to the first IMDN. 9. Reporting UAS Operation 9.1. General Operation When the Reporting UAS receives a CPIM message with a Disposition- Notification-To CPIM header, the Reporting UAS SHOULD generate an IMDN. Security Considerations, Privacy Considerations, and local policy may prevent the generation of an IMDN. The Reporting UAS MUST NOT send more than one final IMDN in response to an IMDN request. That is, once an IMDN has been issued on behalf of a recipient, no further IMDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. For example, if the user reads and then deletes the message, the UAS will send a single read notification. The delete operation in this case will not generate an additional IMDN. A system receiving an instant message disposition notification MUST NOT generate a message disposition notification in response to that notification, even if the request includes a Disposition- Notification-To header. A system sending an IMDN MUST NOT include the Disposition- Notification-To header. A CPIM message that requests an IMDN but does not include the required Message-ID header is malformed and the UAS MUST reject the request using the appropriate protocol mechanism for rejecting a malformed request. NOTE: We could be helpful here and create a new SIP result code for this situation. We can do that if needed. The Reporting UAS MUST copy the incoming CPIM Subject: header as the IMDN CPIM Subject: header. 9.2. Recipient is the End User UAS If the recipient of a CPIM message with a well-formed IMDN request is the end-user user agent server, then Burger & Khartabil Expires April 26, 2006 [Page 16] Internet-Draft IMDN October 2005 o If the user read the message, then the UAS SHOULD generate a read IMDN, mindful of the privacy considerations enumerated in Section 4. o If the UAS automatically deleted the message, or the user deleted the message without reading it, then the UAS SHOULD generate a deleted IMDN, mindful of the privacy considerations enumerated in Section 4. o If the UAS' policy is to deny IMDN to the requestor, or if the user requests a denial report to the UAC, the UAS MUST generate a denied IMDN. o If the UAS' policy is to ignore IMDN requests, or the user requests the supression of a given IMDN report, the UAS MUST silently ignore the IMDN request. The UAS SHOULD sign the IMDN it generates using S/MIME [6]. The UAS MAY encrypt the IMDN, knowing the URI of the endpoint requesting the IMDN is in the Original-From header. The Reporting UAS MUST use the format and fill in the content of the IMDN as described in Section 10. 9.3. Recipient is a B2BUA If the Recipient UAS is a back-to-back user agent (B2BUA), such as a list exploder or messaging gateway, then the action taken depends on the value of List-Action. If there is no List-Action header, or the UAS does not understand the value of the List-Action header, the UAS takes the "first-recipient" action. 9.3.1. No List-Action or first-recipient If the List-Action is "first-recipient" or there is no List-Action specified, then the Recipient UAS issues an IMDN using the following procedures. o If the B2BUA forwards the message, it SHOULD return an "expanded" IMDN, mindful of the privacy considerations enumerated in Section 4. o If there was an error processing the message, the B2BUA SHOULD return an "error" IMDN, mindful of the privacy considerations enumerated in Section 4. When forwarding the message, the B2BUA MUST NOT use the Disposition- Notification-To value of the inbound request. Including a Disposition-Notification-To header in the forwarded messages is a matter of local policy. The Reporting UAS MUST use the format and fill in the content of the IMDN as described in Section 10. Burger & Khartabil Expires April 26, 2006 [Page 17] Internet-Draft IMDN October 2005 9.3.2. final-recipient If the List-Action is "final-recipient", then the B2BUA SHOULD forward the Message-Disposition-To and List-Action headers to down- stream destinations. One condition where the B2BUA might not forward these headers is where the B2BUA knows the down-stream destination will not honor or is not capable of honoring the IMDN request. In the latter case, the B2BUA SHOULD return an "expanded" IMDN. In the former case, local policy will decide whether to return a denied IMDN, expanded IMDN, or not return an IMDN at all. Likewise, if the B2BUA knows it needs to keep the identity of the Requesting UAC private, it will insert its own address for the Disposition- Notification-To header, and regenerate a new IMDN to the Requesting UAC. When the B2BUA receives an IMDN from the Reporting UAS, the B2BUA will encapsulate the IMDN from the downstream UAS and send the response to the UAC that generated the upstream request. The B2BUA MUST verify the Original-Message-ID header matches a Message-ID of a previous incoming request. How long to keep the Message-ID state is a local matter. We RECOMMEND it be at least 5 minutes. If the B2BUA receives an IMDN that does not match an existing Message-ID, the B2BUA MUST discard the IMDN. 10. IMDN Format The IMDN is an XML [7] document. The document MUST be well formed and MUST be valid according to the schema presented in Section 12.2. The namespace identifier for elements defined by this specification is a URN [8], using the namespace identifier 'ietf' as defined by IETF URN Namespace [9] and extended by the IETF XML Registry [10]. The URN is urn:ietf:params:xml:ns:imdn The root element is . The disposition tag takes the value described in Section 6.2. The Reporting UAS MUST include the value of the original message's Message-ID as the value of the message-id tag. The Reporting UAS SHOULD include its URI in the reporting-uas-uri tag. One condition where the Reporting UAS will not include its URI is if it wants to keep its URI private. Burger & Khartabil Expires April 26, 2006 [Page 18] Internet-Draft IMDN October 2005 The Reporting UAS SHOULD include the original recipient as the value of the original-recipient tag. The Reporting UAS MUST include the message disposition in the disposition tag. 11. Examples 11.1. Simple End-to-End Read Request Request From: Eric Burger To: Hisham Khartabil DateTime: 2005-10-18T09:27:22-5 Subject: Did you get this? NS: imdn imdn.Disposition-Notification-To: eburger@example.com imdn.Message-ID: 1542af3e8b@eburger@example.com Content-type: text/xml; charset=utf-8 Content-ID: <1542af3e8b-12@eburger@example.com> Did you get this message? Response Burger & Khartabil Expires April 26, 2006 [Page 19] Internet-Draft IMDN October 2005 From: Hisham Khartabil To: DateTime: 2005-10-18T09:30:18+1 Subject: Did you get this? NS: imdn imdn.Message-ID: latida27@stuff@example.net Content-type: multipart/signed; boundary=next; micalg=sha1; protocol=application/pkcs7-signature --next Content-type: application/imdn+xml; charset=utf-8 read im:hisham.khartabil@example.net im:hisham.khartabil@example.net 1542af3e8b@eburger@example.com --next Content-type: application/pkcs7-signature {signature stuff} : : --next-- Note the IMDN plaintext would not have the CRLF's in the data elements. We do that here simply for readability. Likewise, the IMDN plaintext would be encrypted. NOTE TO SELF: Put in real encryption parameters soon. 11.2. Gateway Endpoint Happy Path for gateway reporting it forwarded. 11.3. List Exploder - Forward Happy Path for forwarding case Burger & Khartabil Expires April 26, 2006 [Page 20] Internet-Draft IMDN October 2005 11.4. List Exploder - Consolidate Show Wrapped Responses 11.5. List With Lists Show wrapped, wrapped responses. 11.6. End-to-End Encryption Forwarded Gateway scenario where Reporting UAS encrypts IMDN document for read only by Requesting UAC. 12. Formal Syntax 12.1. IMDN CPIM Request TODO: collect syntax from above. 12.2. IMDN Document Coming soon. 13. IANA Considerations URN name in IETF namespace: urn:ietf:params:cpim-headers:imdn IMDN schema 14. References 14.1. Normative References [1] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-12 (work in progress), October 2005. Burger & Khartabil Expires April 26, 2006 [Page 21] Internet-Draft IMDN October 2005 [5] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. [7] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004. [8] Moats, R., "URN Syntax", RFC 2141, May 1997. [9] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 14.2. Informative References [11] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [12] Jennings, C., "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-05 (work in progress), July 2005. [13] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004. [14] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004. [15] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-message-03 (work in progress), April 2005. Appendix A. Contributors Appendix B. Acknowledgements Thanks go to Ben Campbell for continuously prodding me. Thanks also to Hisham for the relay idea and threatening some text to force me back to the task. Dean kept reminding me that 3GPP really, really Burger & Khartabil Expires April 26, 2006 [Page 22] Internet-Draft IMDN October 2005 wants this done and to work. Burger & Khartabil Expires April 26, 2006 [Page 23] Internet-Draft IMDN October 2005 Authors' Addresses Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079-2839 USA Phone: +1 603 890 7587 Fax: +1 603 457 5944 Email: eburger@brooktrout.com Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway Phone: +47 2167 3544 Email: hisham.khartabil@telio.no Burger & Khartabil Expires April 26, 2006 [Page 24] Internet-Draft IMDN October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Burger & Khartabil Expires April 26, 2006 [Page 25]