SIMPLE E. Burger Internet-Draft Brooktrout Technology, Inc. Expires: January 18, 2006 July 17, 2005 Instant Message Delivery Notification (IMDN) for Common Presence and Instant Messaging (CPIM) Messages draft-burger-simple-imdn-01 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 January 18, 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 Expires January 18, 2006 [Page 1] Internet-Draft IMDN July 2005 Table of Contents 1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Data Elements . . . . . . . . . . . . . . . . . . . . . . 4 3.2 B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Disposition States . . . . . . . . . . . . . . . . . . . . 6 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Disposition Notification Marking (Sender) . . . . . . . . 7 4.1.1 Disposition-Notification . . . . . . . . . . . . . . . 7 4.1.2 List-Action . . . . . . . . . . . . . . . . . . . . . 9 4.1.3 Original-From . . . . . . . . . . . . . . . . . . . . 9 4.1.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . 10 4.1.5 Original-Message-ID . . . . . . . . . . . . . . . . . 10 4.2 Disposition Notification Processing (Receiver) . . . . . . 10 4.2.1 Recipient is End User UAS . . . . . . . . . . . . . . 11 4.2.2 Recipient is B2BUA . . . . . . . . . . . . . . . . . . 11 5. Format of an IMDN . . . . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Simple End-to-End Read Request . . . . . . . . . . . . . . 14 8.2 Gateway Endpoint . . . . . . . . . . . . . . . . . . . . . 14 8.3 List Exploder - Forward . . . . . . . . . . . . . . . . . 15 8.4 List Exploder - Consolidate . . . . . . . . . . . . . . . 15 8.5 List With Lists . . . . . . . . . . . . . . . . . . . . . 15 8.6 End-to-End Encryption Forwarded . . . . . . . . . . . . . 15 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 IMDN CPIM Request . . . . . . . . . . . . . . . . . . . . 15 9.2 IMDN Document . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1 Normative References . . . . . . . . . . . . . . . . . . . 16 11.2 Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Burger Expires January 18, 2006 [Page 2] Internet-Draft IMDN July 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. If you missed it in the title, the term "IMDN" is an Instand 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]. 2. Introduction In most any user-to-user message exchange system, message senders often wish to know if the human recipient actually read a message. Most messaging protocols, including CPIM sessions [3], ensure reliable delivery of a message to the recipient. However, they cannot report when a human user actually reads the message. Electronic Mail [5] deals with this situation with message delivery notifications [4]. 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 [4]. 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 Burger Expires January 18, 2006 [Page 3] Internet-Draft IMDN July 2005 user has read a message is beyond the scope of this document. However, there are many issues that are important to consider. An appendix to this document enumerates a number of these issues. The mechansim 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, 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. 3. Overview A message sender marks the message for disposition notification. At a certain point in time, the recipient's instant message user agent determines the recipient has read the message. At that point, the recipient's instant message user agent automatically generates a notification message to the sender. This document calls this notification the Instant Message Disposition Notification (IMDN). Note there are numerous circumstances under which the instant message user agent may not send a notification. See the Security Considerations section below for more information. 3.1 Data Elements There is a small set of data elements that any IMDN system needs. The data elements include some elements that help correlate notifications with messages, indicate whether or not to 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 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 [6] 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 3.2 describes list procedures in detail. Burger Expires January 18, 2006 [Page 4] Internet-Draft IMDN July 2005 o The Original From URI identifies the URI of the sender of the original message. The IMDN machinery needs this information in B2BUA situations such as list expansion and IM gateways. o The Message Disposition identifies the eventual disposition of the message, such as read, deleted, and so on. 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. 3.2 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 [9]. 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 are in the lucky situation that we can specify explicit behavior. This means adding a directive indicating the reporting mode. The reporting mode is either "final- recipient", indicating a report request for every final destination; "consolidate", indicating the list exploder is responsible for consolidating notifications to the user; or "request-URI", indicating the list exploder is the target of the disposition notification request. The default is request-URI. 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 for the original sender, end-to-end. The consolidate request has the B2BUA batch the individual IMDNs and Burger Expires January 18, 2006 [Page 5] Internet-Draft IMDN July 2005 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: The previous version of this draft used the Disposition- Notification-To mechanism from MDN. This enabled the actual recipients to directly notify the sender, reducing the burden on list exploders. Upon reflection, Hisham's thought of having the list exploder service relaying reports has a benefit that could be a drawback. The benefit is the list exploder can decide whether a given recipient in a list is "private". That is, their existence in the list is hidden. If there is a private destination, the list exploder knows not to generate IMDNs for that destination or to hide the destination's URI. The drawback is it is up to the list exploder to keep the information private, not the user agent server in question. Moreover, there cannot be easy end-to-end encryption of the report. Moreover, the list exploder may not be trusted by the UAS, whereas we assume the UAS is under control of the recipient that wishes to remain private. For now, I'll float Hisham's way. We can easily resurrect the Disposition- Notification-To mechanics. 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. Gateway processing is identical to list exploder processing, in that this mechanism considers a gateway to be a list exploder with a single destination. 3.3 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 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. Burger Expires January 18, 2006 [Page 6] Internet-Draft IMDN July 2005 deleted The UAS deleted the message. This could be automatic, based on policy, or manually, done by the user. NOTE: MDN [7] 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 3.2. 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. 4. Operation 4.1 Disposition Notification Marking (Sender) There are two headers the Requesting UAC can include in a CPIM message that he would like an IMDN generated for. They are Disposition-Notification and List-Action. 4.1.1 Disposition-Notification NOTE: Earlier verisons of this draft used the Disposition- Notification-To marking. The "To" is the key difference. MDN [7] 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 [8]. 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. For simplicity, we have taken out this functionality for now. Returning it would be the subject of list discussion. To mark a message for disposition notification, the sender MUST include a Disposition-Notification CPIM header in the CPIM part of the request. If the sender requires a notification, the message MUST include a Burger Expires January 18, 2006 [Page 7] Internet-Draft IMDN July 2005 CPIM Require header requiring the processing of the Disposition- Notification 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, 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 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. NOTE: Having an explicit "don't notify me" request does not make sense. Simply do not include a Disposition-Notification header in the request. NOTE: What is the rationale for having separate error or read reports? I'm having trouble thinking of anything but a set of bizarre corner cases for a message that was successfully delivered to a UAS that then cannot be rendered to the user. Clearly, we're asking for a read receipt, so we will take it. What is the use case for an error report that does NOT report on a read, but only on the delete or failure? That is a MEANINGLESS request. This is because the sender cannot differentiate between a message that was read, is sitting in an inbox, or UAS failure. Because of these issues, there are no parameters to the Disposition-Notification header. The syntax of the Disposition-Notification CPIM header is mdn-request-header = "Disposition-Notification" ":" SP token token = NULL / extension-token extension-token = token Systems sending an IMDN MUST NOT include the Disposition-Notification header. Burger Expires January 18, 2006 [Page 8] Internet-Draft IMDN July 2005 4.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. If the List-Action is "final-recipient", the B2BUA SHOULD request IMDNs from each actual recipient. The B2BUA will then relay the responses to the Requesting UAC. Situations where the lB2BUA will not forward the IMDN request include private list members for list expanders and messaging systems that do not support read receipts for gateways. If the List-Action is "consolidate", the B2BUA is responsible for consolidating notifications into a single IMDN. Each IMDN report gets included in the IMDN report element. If the List-Action is "request-URI", then the list expander or gateway SHOULD return the appropriate status. Note the appropriate status MUST NOT be "read", as the end user will not have read the message at the time the gateway or list exploder receives the message. Situations where the list exploder or gateway will not generate an IMDN include when local policy forbids the generation of an IMDN. The default List-Action is "request-URI". The syntax of the List-Action header is as follows. list-action-hdr = "List-Action" ":" SP list-actions list-actions = "final-recipient" / "consolidate" / "request-URI" / token 4.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. Burger Expires January 18, 2006 [Page 9] Internet-Draft IMDN July 2005 Original-From has the identical syntax as the From header specified in CPIM [1]. 4.1.4 Message-ID A Requesting 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 [8] 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. 4.1.5 Original-Message-ID 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). If there is an Original-Message-ID present in the inbound message, the B2BUA MUST use the same value in the outbound message. The syntax of the Original-Message-ID is identical to the syntax of the Message-ID. 4.2 Disposition Notification Processing (Receiver) The receipt of a CPIM message with a Disposition-Notification CPIM header indicates the request for an IMDN. The Recipient UAS MUST NOT send more than one 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. Burger Expires January 18, 2006 [Page 10] Internet-Draft IMDN July 2005 A system sending an IMDN MUST NOT include the Disposition- Notification header. A CPIM message that requests Disposition-Notification 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. We could be helpful here and create a new SIP result code for this situation. We can do that later. IMDN generation depends on whether the recipient of the IMDN request is the end-user's UAS or if it is a gateway or list exploder UAS. If there is a value to the Disposition-Notification, the UAS MUST ignore it. If a future extension leverages a value and depends on the UAS understanding it, the UAC MUST use a Require CPIM header. 4.2.1 Recipient is End User UAS If the recipient of a CPIM message with a well-formed IMDN request is the end-user user agent server, then o If the user read the message, then the UAS SHOULD generate a read IMDN, mindful of the privacy considerations enumerated in Section 6. 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 6. 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. They UAS MAY encrypt the IMDN, knowing the URI of the endpoint requesting the IMDN is in the Original-From header. 4.2.2 Recipient is 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 "request-URI" action. Burger Expires January 18, 2006 [Page 11] Internet-Draft IMDN July 2005 4.2.2.1 request-URI If the List-Action is "request-URI", 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 6. o If there was an error processing the message, the B2BUA SHOULD return an error IMDN, mindful of the privacy considerations enumerated in Section 6. The IMDN in this case refers to the UAS part of the B2BUA. Thus there is no IMDN encapsulation. Signing and encryption are the same as for a simple UAS. 4.2.2.2 final-recipient If the List-Action is "final-recipient", then the B2BUA SHOULD forward the Message-Disposition and List-Action headers to the 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 with an "expanded" status. In the former case, local policy will decide whether to return a denied IMDN, expanded IMDN, or not return an IMDN at all. NOTE: This is an example of the peril of not having the end system communicate directly with the Requesting UAC. The end system knows the policy for returning an IMDN (denied, expanded, ignore). The situation we have here assumes there is a trust relationship between the end system and the B2BUA. When the B2BUA receives an IMDN from the downstream 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. 4.2.2.3 consolidate If the List-Action is "consolidate", the B2BUA waits a locally defined time period to collect IMDN responses from the downstream Burger Expires January 18, 2006 [Page 12] Internet-Draft IMDN July 2005 UASs. If the time period expires or the B2BUA collects all of the responses, the B2BUA encapsulates all of the responses and forwards the responses to the upstream UAC. 5. Format of an IMDN NOTE: It makes much more sense to have the IMDN document simply be headers. The current fashion is XML, and bending to fashion, I've got an XML definition of the IMDN. Of course, it is the elements that are important; we can work out encoding later. That said, what is the value of the IMDN being in XML? The argument that a CPIM endpoint will have an XML parser is not valid. For example, a gateway does not need an XML parser to operate. However, it does need a header-colon-value parser. Since we are using CPIM, we get namespaces for headers, if that is what you wanted to use XML for. Clearly, this is an object for discussion on the list. In addition, since the possible values of the data elements are pretty well-known, we use attributes to the imdn element, rather than have a bunch of sub-elements. This might be considered abuse, but it does highlight the point. Clearly, if it is the will of the group to stick with XML and to not abuse attributes, I'll fix up the schema. The root element is . The disposition attribute takes the value described above. The Reporting UAS MUST include the Message-ID as the value of the original-message-ID attribute. The Reporting UAS SHOULD include its URI in the reporting-uas-uri attribute. One condition where the Reporting UAS will not include its URI is if it wants to keep its URI private. If the Reporting UAS is a B2BUA, and the UAS is consolidating or forwarding a downstream IMDN, the Reporting UAS includes the forwarded report(s) as the value of the tag. 6. Privacy Considerations As suggested by RFC2298 [4], it is strongly RECOMMENDED that the user agent obtain the user's consent before sending an IMDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that IMDNs are never to be sent or that a "denied" IMDN is always sent in response to a request for an IMDN. Recipient systems SHOULD NOT automatically send IMDNs if the URI in Burger Expires January 18, 2006 [Page 13] Internet-Draft IMDN July 2005 the Disposition-Notification-To header differs from the address of the sender. Recipient systems SHOULD use reliable mechanisms for determining the sender's address, such as from the underlying transport protocol. Recipient systems SHOULD 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. 7. Security Considerations All of the security issues raised in RFC2298 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. To combat eavesdropping, modification, and man-in-the-middle attacks [ ], one SHOULD consider encrypting IMDNs, as an attacker may attempt to discern the user's activity profile from sniffing IMDNs on the network. Replay and message insertion attacks are unlikely in an IMDN environment, as the MsgID cannot be identical within a given session. There is no effective protection for a deletion attack on an IMDN. Probably the greatest network threat is a denial of service attack. An attacker may setup a denial of service attack to a third party by sending lots of messages to many instant message user agents, with notification requests all being forwarded to the attacked node. This is why one SHOULD NOT send IMDNs to a user other than the one that sent the message. Likewise, an attacker could 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. 8. Examples 8.1 Simple End-to-End Read Request The Happy Path. 8.2 Gateway Endpoint Happy Path for gateway reporting it forwarded. Burger Expires January 18, 2006 [Page 14] Internet-Draft IMDN July 2005 8.3 List Exploder - Forward Happy Path for forwarding case 8.4 List Exploder - Consolidate Show Wrapped Responses 8.5 List With Lists Show wrapped, wrapped responses. 8.6 End-to-End Encryption Forwarded Gateway scenario where Reporting UAS encrypts IMDN document for read only by Requesting UAC. 9. Formal Syntax 9.1 IMDN CPIM Request TODO: collect syntax from above. Burger Expires January 18, 2006 [Page 15] Internet-Draft IMDN July 2005 9.2 IMDN Document The range of disposition is "read", "deleted", "expanded", "error", or "denied". We do not do a restriction to make it easy to extend the values in the future. 10. IANA Considerations TODO 11. References 11.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] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-10 (work in progress), February 2005. Burger Expires January 18, 2006 [Page 16] Internet-Draft IMDN July 2005 [4] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. 11.2 Informative References [5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [6] Jennings, C. and R. Mahy, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-04 (work in progress), June 2005. [7] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004. [8] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004. [9] 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. Author's Address 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 Appendix A. Contributors Appendix B. Acknowledgements Thanks go to Ben Campbell for continuously prodding me. Thanks also to Hisham for the relay idea and threating some text to force me back to the task. Dean kept reminding me that 3GPP really, really wants this done and to work. Burger Expires January 18, 2006 [Page 17] Internet-Draft IMDN July 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 Expires January 18, 2006 [Page 18]