SIMPLE E. Burger Internet-Draft Cantata Technology Intended status: Informational H. Khartabil Expires: April 16, 2007 Telio October 13, 2006 Instant Message Disposition Notification draft-ietf-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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing and read notifications, for page-mode as well as session mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified Burger & Khartabil Expires April 16, 2007 [Page 1] Internet-Draft IM Disposition Notification October 2006 in RFC 3862 is extended with new headers that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP and MSRP entities behave using this extension. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. New CPIM Header Fields . . . . . . . . . . . . . . . . . . . . 7 6.1. CPIM Header Namespace . . . . . . . . . . . . . . . . . . 7 6.2. Disposition-Notification . . . . . . . . . . . . . . . . . 8 6.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 8 6.5. IMDN-Record-Route . . . . . . . . . . . . . . . . . . . . 8 6.6. IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IM Sender . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1.1. Constructing Instant Messages . . . . . . . . . . . . 9 7.1.2. Matching IMs with IMDNs . . . . . . . . . . . . . . . 10 7.1.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . 10 7.1.4. Keeping State . . . . . . . . . . . . . . . . . . . . 11 7.2. IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.1. Constructing IMDNs . . . . . . . . . . . . . . . . . . 12 8. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14 8.1. Constructing Processing Notifications . . . . . . . . . . 15 8.2. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16 9. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 17 10. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 17 11. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Structure of XML-Encoded IMDN Payload . . . . . . . . . . 18 11.1.1. The Element . . . . . . . . . . . . . . . 18 11.1.2. The Element . . . . . . . . . . . . . . . . 19 11.1.3. The Element . . . . . . . . . . . . . 19 11.1.4. The Element . . . . . . . . . 19 11.1.5. The Element . . . . . . . . . . . . . . . . 19 11.1.6. The Element . . . . . . . . . . . . . . 19 11.1.7. The Element . . . . . . . . . . . . . . . . . 19 11.1.8. The Element . . . . . . . . . . . . . . . . . . 20 11.2. MIME Type for IMDN Paylaod . . . . . . . . . . . . . . . . 20 Burger & Khartabil Expires April 16, 2007 [Page 2] Internet-Draft IM Disposition Notification October 2006 11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20 12. Transporting Messages using SIP . . . . . . . . . . . . . . . 23 12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24 12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 24 12.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 24 12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 24 12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25 13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 26 13.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 26 13.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 26 13.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 27 13.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 27 13.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 27 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 14.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30 14.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 31 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 32 15.3. Schema Registration . . . . . . . . . . . . . . . . . . . 32 15.4. Message/CPIM Header Field registration . . . . . . . . . . 32 15.5. Content-Disposition: notification . . . . . . . . . . . . 33 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 17.1. Normative References . . . . . . . . . . . . . . . . . . . 33 17.2. Informative References . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Burger & Khartabil Expires April 16, 2007 [Page 3] Internet-Draft IM Disposition Notification October 2006 1. Introduction In many user-to-user message exchange systems, message senders often wish to know if the human recipient actually received or read a message. Electronic Mail [12] deals with this situation with Message Delivery Notifications [13]. 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 [13]. The fixed format ensures that an automaton can process the message. Message/CPIM [2] is a message format used to generate instant messages. SIP [9] can carry instant messages generated using message/CPIM in SIP MESSAGE requests [10]. The MSRP [11] SEND request can also be used to carry Message/CPIM messages. This document extends Message/CPIM message format (much like Message Delivery Notifications [13] extends Electronic Mail [12]) to enable Instant Message Senders to request, create and send Instant Message Disposition Notifications (IMDN) for a page-mode as well as session mode instant messages. IMDNs include positive delivery, negative delivery (i.e. a message did not get delivered successfully), read notifications as well as processed notifications. By using CPIM headers, the IMDN request and delivery are abstracted outside the transport protocol allowing interoperability between different IM systems. Likewise, the mechanism does not rely on session-mode versus page-mode. This document also describes how SIP and MSRP entities behave using this extension. 2. Conventions In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Terminology o IM: An Instant Message generated using the Message/CPIM format. o IMDN: An Instant Message Disposition Notification generated using the Message/CPIM format that carries a IMDN XML document. Burger & Khartabil Expires April 16, 2007 [Page 4] Internet-Draft IM Disposition Notification October 2006 o Message: an IM or an IMDN generated using the Message/CPIM format. o IM Sender: An endpoint (User Agent) generating and sending an IM. It is also the endpoint that requests IMDNs for an IM. Quite often, the IM Sender is the IMDN Recipient, but that is not always true. o IM Recipient: An endpoint (User Agent) that receives IMs. It is also the endpoint that generates and sends IMDNs to IMs, if requested by the IM Sender. o Endpoint: An IM Sender or an IM Recipient. o Intermediary: An entity in the network that is on the path of an IM to its final destination. o IMDN Payload or XML Document: An XML document carrying the disposition notification information. It is always of MIME type "message/imdn+xml". o Disposition type: the type of IMDN that can be requested. This specification defines three, namely "delivery", "processing" and "read" disposition types. o Transport Protocol Message: An IM or an IMDN wrapped in a transport protocol like SIP or MSRP. 4. Overview The basic protocol flow is depicted in the diagram below. An IM Sender creates an IM, adds to it IMDN request information it is interested in receiving, then sends its. At a certain point in time, the IM Recipient or an intermediary determines that the user or application has received, did not receive or has read the IM or otherwise disposed the IM. The mechanism by which an IM Recipient determines its user has read an IM is beyond the scope of this document. At that point, the IM Recipient or intermediary automatically generates a notification message to the IM Sender. This notification message is the Instant Message Disposition Notification (IMDN). Burger & Khartabil Expires April 16, 2007 [Page 5] Internet-Draft IM Disposition Notification October 2006 +--------------+ +--------------+ | IM Sender | | IM Recipient | |IMDN Recipient| | IMDN Sender | +--------------+ +--------------+ | | | | | 1. IM requesting IMDN | |-------------------------------------->| | | | | | 2. IMDN (disposition) | |<--------------------------------------| | | | | Note that the recipient of an IMDN, in some instances, may not be the IM Sender. This is specifically true for page-mode IMs where the Address of Record (AOR) of the IM Sender, that is present in the IMDN, resolves to a different location to where the IM originated. For simplicity, the rest of this document assumes that the IM Sender and the IMDN Recipient are the same and therefore will refer to both as the IM Sender. 5. Disposition Types There are three broad categories of disposition states. They are delivery, processing and read. Future extensions may introduce others. 5.1. Delivery The delivery notification type indicates whether the IM has been delivered to the IM Recipient or not. The delivery notification type can have the following states: o "delivered" to indicate successful delivery. o "failed" to indicate failure in delivery. o "forbidden" indicate denial by the IM Recipient for the IM Sender to receive the requested IMDN. o "error" to indicate an error in determining the fate of an IM. Burger & Khartabil Expires April 16, 2007 [Page 6] Internet-Draft IM Disposition Notification October 2006 5.2. Processing The processing notification type indicates that an IM has been processed by an intermediary. The processing notification type can have the following states: o "processed" is a general state of the IM indicating it has been processed. o "stored" state indicates that the IM has been stored by the intermediary for later delivery. o "forbidden" indicate denial by the IM Recipient for the IM Sender to receive the requested IMDN. o "error" to indicate an error in determining the fate of an IM. 5.3. Read The read notification type indicates whether the IM Recipient displayed the IM to the user or not. The read notification type can have the following states: o "read" is a state indicating that the IM has been read. o "forbidden" indicate denial by the IM Recipient for the IM Sender to receive the requested IMDN. o "error" to indicate an error in determining the fate of an IM. Since there is no positive acknowledgement from the user, one cannot determine a priori that the user actually read the IM. Thus one MUST NOT use the protocol described here as a non-repudiation service. 6. New CPIM Header Fields This specification extends the CPIM data format specified in RFC 3862 [2]. A new namespace is created as well as a number of new CPIM headers. 6.1. CPIM Header Namespace Per CPIM [2], this specification defines a new namespace for the CPIM extension headers defined in the following sections. The namespace is: urn:ietf:params:cpim-headers:imdn As per CPIM [2] requirements, the new headers defined in the following sections are prepended by Burger & Khartabil Expires April 16, 2007 [Page 7] Internet-Draft IM Disposition Notification October 2006 the string "imdn." in CPIM messages. 6.2. Disposition-Notification The Disposition-Notification header field is used by the IM Sender to indicate the desire to receive IMDNs, from the IM Recipient, for that specific IM. This header field is not needed if the IM Sender does not request an IMDN. The syntax is defined in Section 10. 6.3. Message-ID The Message-ID header field contains a globally unique message identifier that is used by the IM Sender to correlate received IMDNs by comparing its value with the value of the element present in the IMDN payload. This header field is mandatory with sending an IM and requesting an IMDN. IMDNs also carry this header field. The syntax is defined in Section 10. 6.4. Original-To The Original-To header field is sometimes added to an IM by an intermediary and populated with of the address of the IM Sender. It is used by the IM Recipient to indicate in the IMDNs (by populating the element) the original address the IM was sent to. This header is mandatory if the intermediary changes the CPIM To header field value. The header MUST NOT appear more than once in an IM. The header field value MUST NOT be changed by an intermediary if it was already present. The syntax is defined in Section 10. 6.5. IMDN-Record-Route Intermediaries have the capability of indicating that IMDNs should be sent through it (otherwise, IMDNs will not visit the intermediary). An intermediary that request IMDNs to be sent through itself adds an IMDN-Record-Route header field to the IM. The value of the IMDN- Record-Route header field is set to the address of that intermediary. Multiple IMDN-Record-Route header fields can appear in an IM. The syntax is defined in Section 10. 6.6. IMDN-Route The IMDN-Route header field provides routing information by including one or more addresses where an IMDN must be routed through. On creating an IMDN, an IM recipient copies the contents of the IMDN- Record-Route present in the IM into the IMDN-Route of the IMDN. Multiple IMDN-Route header fields can appear in an IMDN. The syntax is defined in Section 10. Burger & Khartabil Expires April 16, 2007 [Page 8] Internet-Draft IM Disposition Notification October 2006 7. Endpoint Behaviour 7.1. IM Sender 7.1.1. Constructing Instant Messages An IM is constructed using RFC 3862 [2]. The Content-type header field indicates the MIME type of the request payload. 7.1.1.1. Adding a Message-ID Header Field If the IM sender requests the reception of IMDNs, the IM sender MUST include a Message-ID header field. The Message-ID field is populated with a value that is unique with 32 bits of randomness. This header field enables the IM Sender to match any IMDNs with their corresponding IMs. 7.1.1.2. Adding a DateTime Header Field Some devices may not implement the concept of "Sent Items" box and therefore no information about an IM is stored. It is therefore necessary to add a time stamp in the IM to indicate when it was sent. This time stamp is returned in the IMDN in order to enable the user to correlate the IM with the IMDN at the human level. The DateTime header field is used for this purpose. The IM MUST contain a DateTime header field if an IMDN is requested. 7.1.1.3. Adding a Disposition-Notification Header Field In this specification, the IM Sender can request two types of delivery notifications: a failure delivery notification and a success delivery notification. An IM Sender requests failure delivery notification by including a Disposition-Notification header field with value "negative-delivery". Similarly, a success notification is requested by including a Disposition-Notification header field with value "positive-delivery". Both types of delivery notifications can be requested for the same IM. The IM Sender can request a processing notification by including a Disposition-Notification header field with value "processing". The IM Sender can also request a read notification. It is requested by including a Disposition-Notification header field with value "read". The absence of this header or the presence of the header with empty value indicates that the IM Sender is not requesting any IMDNs. The Disposition-Notification header fields can be comma separated. Burger & Khartabil Expires April 16, 2007 [Page 9] Internet-Draft IM Disposition Notification October 2006 Future extension may define other disposition notifications not defined in this document. The IM Sender MAY request more than one type of IMDN for a single IM. The formal syntax of the Disposition-Notification header field can be found in Section 10. The following in an example IM where the IM Sender requests positive and negative delivery notifications, but not read notification nor processing notifications: Content-type: Message/CPIM From: Alice To: Bob NS: imdn imdn.Message-ID: 34jk324j DateTime: 2006-04-04T12:16:49-05:00 imdn.Disposition-Notification: positive-delivery, negative-delivery Content-type: text/plain Content-length: 12 Hello World 7.1.2. Matching IMs with IMDNs An IM Sender matches an IMDN to an IM by matching the Message-ID header field value in the IM with the element value in the body of the IMDN. If the IM was delivered to multiple recipients, the IM Sender uses the element or the element in the XML body of the IMDN it received to identify the IM Recipient (IMDN Sender). 7.1.3. Aggregation of IMDNs An IM Sender may send an IM to multiple recipients in one Transport Protocol Message (typically using a URI-List server) and request IMDNs. It MAY choose to either get one IMDN from each IM Recipient individually or get an aggregated IMDN (the URI-List server aggregates the IMDNs and send the one or more aggregated IMDNs). The IM Sender requests aggregation by adding the Disposition-Notification header field parameter "aggregate". The absence of such a parameter indicates that the IM Sender does not wish for IMDNs to be aggregated. Aggregation can be requested per disposition type. For example, a IM Sender can request delivery notification to be aggregated but read notifications to be sent individually. For example: Disposition-Notification: positive-delivery;aggregate, read Burger & Khartabil Expires April 16, 2007 [Page 10] Internet-Draft IM Disposition Notification October 2006 The following is an example of an IM Sender requesting aggregation of both positive delivery notifications and read notifications: Disposition-Notification: positive-delivery;aggregate, read;aggregate An IM Sender that requested an aggregated IMDN MUST be prepared to receive multiple aggregated or non-aggregated IMDNs. See Section 8.2 for details. An IM Sender MUST be prepared to receive aggregated IMDNs even if it did not request the URI-List server to do so. See again Section 8.2 for details. Note that the "aggregate" parameter is a hint for intermediaries and does not require the intermediaries to aggregate IMDNs. 7.1.4. Keeping State This specification does not mandate the IM Sender to keep state for a sent IM. Once an IM Sender sends an IM containing an IMDN request, it MAY preserve the IM context, principally the Message-ID, and other user- identifiable information such as the IM subject or content, and date and time it was sent. Without preservation of the IM context, the IM Sender will not be able to correlate the IMDN with the IM it sent. The IM Sender may find it impossible to preserve IM state if it has limited resources or does not have non-volatile memory and then loses power. There is, however, the concept of "Sent Items" box in an application that stores sent IMs. This "Sent Items" box has the necessary information and may have a fancy user interface indicating the state of a sent IM. Unique Message-ID for this purpose proves to be useful. The length of time for items to remain in the "Sent Items" box is a user choice. The user is usually free to keep or delete items from the "Sent Items" box as she pleases or as the memory on the device reaches capacity. Clearly, if an IM Sender loses its sent items state (user deletes items from the "Send Items" box), the client may use a different display strategy in response to apparently unsolicited IMDNs. This specification also does not mandate an IM Sender to run any timers waiting for an IMDN. There are no time limits associated with when IMDNs may be received. IMDNs may legitimately never be received. On the other hand, and IMDN may simply take a very long time. Some clients may choose to Burger & Khartabil Expires April 16, 2007 [Page 11] Internet-Draft IM Disposition Notification October 2006 purge the state associated with the sent IM. This is the reason for adding the time stamp in the IM and having it returned in the IMDN. This gives the user some opportunity of remembering what IM was sent. For example if the IMDN indicates that the IM the user sent at 2 p.m. last Thursday was delivered, the user has a chance of remembering that they sent an IM at 2 p.m. last Thursday. 7.2. IM Recipient 7.2.1. Constructing IMDNs IM recipients examine the contents of the Disposition-Notification header field of the CPIM message to determine if an IMDN must be generated for that IM. Disposition-Notification header fields of CPIM messages can include one or more values. This implies that IM recipients may need to generate zero, one, or more IMDNs for that IM, for example a delivery notification as well as a read notification. In this case the IM Recipient MUST be able to construct multiple IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN per disposition type. I.e. It must not, for example, generate a delivery notification indicating "delivered" then followed by a delivery notification indicating "failed" for the same IM. If the IM Sender requested only failure notifications and the IM was successfully delivered, then no IMDNs will be generated. The IM Recipient MUST NOT generate processing notifications. Disposition-Notification header MUST NOT appear in an IMDN since it does not make sense and is therefore forbidden to request an IMDN for an IMDN. IM Sender MUST ignore it if present. The IM Sender MUST NOT send an IMDN to an IMDN. An IMDN MUST contain a Message-ID header field. The same rules of uniqueness for the Message-ID header field that appears in an IM apply to an IMDN. An IM may contain a IMDN-Record-Route header field (see Section 8 for details). If IMDN-Record-Route header fields appear in the IM, the IM Recipient constructing the IMDN MUST copy the contents of the IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN and maintain the order. The IMDN is then sent to the address in the top IMDN-Route header field. 7.2.1.1. Constructing Delivery Notifications A delivery notification is constructed in a similar fashion as an IM, using RFC 3862 [2]. For delivery notifications, the Content-type MUST be of type "message/imdn+xml". It is an XML document. The Burger & Khartabil Expires April 16, 2007 [Page 12] Internet-Draft IM Disposition Notification October 2006 schema is described Section 11. The delivery notification MUST contain a Content-Disposition header field with value "notification". This indicates to the IM Sender that the message is an IMDN to an IM it has earlier sent. An example looks like the following: Content-type: Message/CPIM From: Bob To: Alice NS: imdn imdn.Message-ID: d834jied93rf Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... 34jk324j 2006-04-04T12:16:49-05:00 im:bob@example.com im:bob@example.com The IM was successfully Delivered 7.2.1.2. Constructing Read Notifications A read notification is constructed in a similar fashion as the delivery notification. See Section 7.2.1.1 for details. An example looks like the following: Burger & Khartabil Expires April 16, 2007 [Page 13] Internet-Draft IM Disposition Notification October 2006 Content-type: Message/CPIM From: Bob To: Alice NS: imdn imdn.Message-ID: dfjkleriou432333 Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... 34jk324j 2006-04-04T12:16:49-05:00 im:bob@example.com im:bob@example.com The IM has been read There are situations where the IM Recipient cannot determine if or when the IM has been read. The IM Recipient in this case generates a read notification with a value of "error" to indicate an internal error by the server. 8. Intermediary Behaviour In this context, application servers (including URI-List servers and Store-and-Forward server) and gateways are defined as intermediaries. An intermediary that forwards an IM MAY change the recipient address in the CPIM To header field when forwarding (for example, a URI-List server changes the IM Recipient address from its own to the address of the final recipient of that IM for every copy it makes to be sent to the list members). In this case, the intermediary MUST add an Original-To header field to the IM populating it with the address that was in the To header field before it was changed. I.e. The Original-To header is populated with the intermediary address. An intermediary MUST NOT add an Original-To header field if one already exists. An intermediary MAY choose to remain on the path of IMDNs for a specific IM. It can do so by adding a CPIM IMDN-Record-Route header Burger & Khartabil Expires April 16, 2007 [Page 14] Internet-Draft IM Disposition Notification October 2006 field as the top IMDN-Record-Route header and populating it with its own address. An intermediary that does not support this extension will obviously not add the IMDN-Record-Route header. This allows IMDNs to traverse directly from the IM Recipient to the IM Sender even if the IM traversed an intermediary not supporting this extension. An intermediary receiving an IMDN checks the top IMDN-Route header field. If that header field carries the intermediary address, the intermediary pops that header and forwards the IMDN to the address indicated in the now top IMDN-Route header. If no IMDN-Route headers are present, the IMDN is forwarded to the address in the To header field. An intermediary MUST remove any information about the final recipients of a list if the list membership is not disclosed. The intermediary does that by removing the element and/or element from the body of the IMDN before forwarding it to the IM Sender. 8.1. Constructing Processing Notifications Intermediaries are the only entities that construct processing notifications. They do so only if the IM Sender has requested a processing notification by including a Disposition-Notification header field with value "processing". The intermediary can create and send processing notifications indicating that an IM has been processed or stored. The intermediary MUST NOT send more than one IMDN for the same disposition type. I.e. It must not send a processing notification indicating that an IM is being "processed" followed by another IMDN indicating that the same IM is "stored". A processing notification is constructed in a similar fashion as the delivery notification. See Section 7.2.1.1 for details. An example looks like the following: Burger & Khartabil Expires April 16, 2007 [Page 15] Internet-Draft IM Disposition Notification October 2006 Content-type: Message/CPIM From: Bob To: Alice Content-type: message/imdn+xml Content-Disposition: notification Content-length: ... 34jk324j 2006-04-04T12:16:49-05:00 im:bob@example.com im:bob@example.com The IM has been processed There are situations where the intermediary cannot know the fate of an IM. The intermediary in this case generates a processing notification with a value of "error" to indicate so. 8.2. Aggregation of IMDNs In this context, URI-List servers are defined as intermediaries. When a URI-List server receives an IM, it needs to examine Disposition-Notification header fields. If an IMDN request contains the "aggregate" parameter, the URI-List server MUST wait for a configurable period of time or until all recipients have sent the IMDN (whichever comes first) before the URI-List server sends an aggregated IMDN. Note that some IMDNs, for example read notifications, may never come due to user settings. It is an administrator configuration and an implementation issue how long to wait before sending an aggregated IMDN and before a URI-List server removes state for that IM. A URI-List server MAY choose to send multiple aggregated IMDNs even if the requester asked for one aggregated IM. A timer can be started and when it fires, the URI-List server can aggregate whatever IMDNs it has so far for that IM, send the aggregated IMDN and restart the timer for the next batch. This is needed for scenarios where the IM Sender has requested more than one IMDN for a specific IM, for example, delivery notifications as well as read notifications, or Burger & Khartabil Expires April 16, 2007 [Page 16] Internet-Draft IM Disposition Notification October 2006 when the URI-List server is short on resources and chooses to prioritise forwarding IMs over IMDNs. A second timer can be running and when it fires, the state of the IM is deleted. In this case, the URI-List server consumes any IMDNs that might arrive after that time. A URI-List server MAY aggregate IMDNs even if the IM Sender did not request it to do so. This is to handle the case where the list membership information is not disclosed. The URI-List server MAY also choose to ignore an aggregation request and send individual IMDNs instead. The aggregated IMDN is constructed using the multipart/mixed MIME type and including all the received IMDNs as message/imdn+xml as individual payloads. There are scenarios where an intermediary needs to generate IMDNs, see Section 12.2 for further details. 9. Identifying Messages Messages are typically carried in a transport protocol like SIP [9]. The message is an IM if the content-type header field present in it has a value that is NOT "message/imdn+xml". A message is identified as a delivery notification by examining its contents. The message is a delivery notification if: the Content- type header field present has a value of "message/imdn+xml", the Content-Disposition header field has a value of "notification", and the element in that xml body has a sub-element . A message is identified as a processing notification or read notification in a similar fashion as a delivery notification. The difference is that the element in that xml body has a sub-element of and respectively. 10. Header Fields Formal Syntax The following syntax specification uses the message header syntax as described in Section 3 of RFC3862 [2]. Header syntax is described without a namespace qualification. Following the rules in RFC3862 [2], header names and other text are case sensitive and MUST be used as given, using exactly the indicated upper-case and lower-case letters. Burger & Khartabil Expires April 16, 2007 [Page 17] Internet-Draft IM Disposition Notification October 2006 Disposition-Notification = "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))] notify-req = ("negative-delivery" / "positive-delivery" / "processing" / "read" / Token) *(SEMI disp-notif-params) disp-notify-params = "aggregate" / generic-param Message-ID = "Message-ID" ": " Token Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" IMDN-Record-Route = "IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">" IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">" 11. IMDN Format 11.1. Structure of XML-Encoded IMDN Payload An IMDN Payload is an XML document [7] that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. The IMDN Payload MUST be based on XML 1.0 and MUST be encoded using UTF-8. The namespace identifier for elements defined by this specification is a URN [4], using the namespace identifier 'ietf' defined by [5] and extended by [3]. This urn is: urn:ietf:params:xml:ns:imdn. This namespace declaration indicates the namespace on which the IMDN is based. The root element is . The element has sub-elements, namely , , , , , , , and . Those elements are described in details in the following sections. and can be extended in the future to include new sub-elements not defined in this document. Those new elements MUST be defined in an RFC. 11.1.1. The Element The element is mandatory according to the XML schema and carries the message id that appeared in the Message-ID header field Burger & Khartabil Expires April 16, 2007 [Page 18] Internet-Draft IM Disposition Notification October 2006 of the IM. 11.1.2. The Element The element is mandatory and carries the date and time the IM was sent (not the IMDN). This information is obtained from the DateTime header field of the IM. 11.1.3. The Element The element is optional and carries the URI of the final recipient. This information is obtained from the To header field of the IM. 11.1.4. The Element The element is optional and carries the URI of the original recipient. It MUST be present if the IM carried the Original-To header field. This information is obtained from the Original-To header field of the IM. 11.1.5. The Element The element is optional and carries the text that was in the Subject header field, if any. This allows for a human level correlation between an IM and an IMDN. 11.1.6. The Element The element is mandatory and carries the disposition type that the IM Sender requested and is being reported. It can carry one of the sub-elements , , or any other future extension. 11.1.7. The Element The element is mandatory and carries the result of the disposition request in the element. For disposition type , it can carry one of the sub-elements , , or . For disposition type , it can carry one of the sub-elements , or . For disposition type , it can carry one of the sub- elements , , or . means the disposition was denied. means internal server error. It can also carry any other future extension. Burger & Khartabil Expires April 16, 2007 [Page 19] Internet-Draft IM Disposition Notification October 2006 11.1.8. The Element The element is optional and carries a human readable text. It has the "lang" attribute that indicates the language the text is written in. 11.2. MIME Type for IMDN Paylaod The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN MUST identify the payload as MIME type "message/imdn+xml" in the Content-type header field. 11.3. The RelaxNG Schema Burger & Khartabil Expires April 16, 2007 [Page 20] Internet-Draft IM Disposition Notification October 2006 Burger & Khartabil Expires April 16, 2007 [Page 21] Internet-Draft IM Disposition Notification October 2006 Burger & Khartabil Expires April 16, 2007 [Page 22] Internet-Draft IM Disposition Notification October 2006 lang 12. Transporting Messages using SIP Burger & Khartabil Expires April 16, 2007 [Page 23] Internet-Draft IM Disposition Notification October 2006 12.1. Endpoint Behaviour 12.1.1. Sending Requests A SIP MESSAGE request is constructed using RFC 3428 [10]. The Content-type header field indicates the MIME type of the request payload. When using this extension, the Content-type header field MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The payload is constructed according to Section 7. A SIP MESSAGE request to multiple recipients is constructed in a similar manner as a SIP MESSAGE request to a single recipient. The differences are indicated in [15]. 12.1.2. Sending Responses An endpoint receiving a SIP MESSAGE request constructs a SIP response according to RFC3428 [10]. Of course, an endpoint will send a response to the MESSAGE request regardless of they type of message (IM or IMDN) is has received, or the disposition type it has been asked for. 12.1.3. Receiving Requests 12.1.3.1. Instant Message A SIP MESSAGE request is identified as an IM by examining its contents according to Section 9. If an IM Recipient received a SIP MESSAGE request that is an IM that requested a positive-delivery notification, and that IM Recipient has constructed and sent a SIP 2xx class response, it MAY generate a positive-delivery notification after making sure that the IM has been delivered to the user or application (a GW, for example, can generate a 2xx response before it has been guaranteed that the final recipient has actually received the IM). The positive-delivery notification is constructed according to Section 7.2.1.1. The message is then placed as the payload in a SIP MESSAGE request. If an IM Recipient received a SIP MESSAGE request that is an IM that requested a negative-delivery, and that IM Recipient has constructed and sent a 2xx class response, it SHOULD generate a negative-delivery notification if it learnt that the final recipient or application did not receive the IM (a GW, for example, can generate a 2xx response before it has been guaranteed that the final recipient has actually received the IM). The negative-delivery notification is constructed according to Section 7.2.1.1. The message is then placed as the payload in a SIP MESSAGE request. Burger & Khartabil Expires April 16, 2007 [Page 24] Internet-Draft IM Disposition Notification October 2006 If an IM Recipient received a SIP MESSAGE request that is an IM that requested a negative-delivery notification, and the IM Recipient has constructed and sent an error response, it MUST NOT generate a negative-delivery notification. If an IM Recipient received a SIP MESSAGE request that is an IM that requested a read notification, and that IM Recipient has constructed and sent a SIP 2xx class response, it MAY generate a read notification after making sure that the IM has been presented to the user or application. It is outside the scope of this document how such determination can be made. Note that the option to send a read notification or not can be left to the user. An application may allow a user to configure such choice. The read notification is constructed according to Section 7.2.1.2. The message is then placed as the payload in a SIP MESSAGE request. 12.1.3.2. Delivery Notification A SIP MESSAGE request is identified as delivery notification by examining its contents according to Section 9. 12.1.3.3. Read Notification A SIP MESSAGE request is identified as read notification by examining its contents according to Section 9. 12.2. Intermediary Behaviour In this context, application servers (including URI-List servers and Store-and-Forward server) and gateways are defined as intermediaries. SIP Proxies MUST NOT generate IMDNs but MUST forward them like any other sip request. A SIP MESSAGE request to multiple recipients is forwarded according to [15]. If an intermediary generates a SIP 2xx class response to a SIP MESSAGE request it has received that is an IM, it examines if the body was of type "message/cpim". If so, it checks if there is the header field Disposition-Notification with a value "positive- delivery" and/or "negative-delivery". If so, it MUST send a delivery notification after receiving a transactional final response for the IM. If the Disposition-Notification header field contains a value of "positive-delivery", the intermediary MUST NOT generate a delivery notification if it receives a SIP 2xx class response for the sent IM. This is in anticipation of a failure downstream after a 2xx response Burger & Khartabil Expires April 16, 2007 [Page 25] Internet-Draft IM Disposition Notification October 2006 has been generated. If the Disposition-Notification header field contains a value of "negative-delivery", the intermediary SHOULD generate a delivery notification if it receives a SIP 4xx, 5xx or 6xx class final response for the sent IM or if it has received a SIP 2xx class response followed by a negative-delivery notification. If the Disposition-Notification header field contains a value of "processing", the intermediary MAY generate a processing notification after it has forwarded or stored the IM. The rest of the procedures in Section 8.1 apply. The procedure for generating such IMDN is the same as that of an IM Recipient (Section 7.2.1.1). The element of the XML body is populated with the URI of the IM Recipient. If an intermediary receives a SIP MESSAGE request carrying a positive delivery notification or a read notification, it forwards it using the rules in Section 8. 13. Transporting Messages using MSRP 13.1. Endpoint Behaviour 13.1.1. Sending Requests MSRP Relays MUST NOT generate IMDNs. An MSRP SEND request is constructed using [11]. The content-type header field indicates the MIME type of the request payload. When using this extension, the content-type header field MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs. The payload is constructed according to Section 7. MSRP has built in delivery reports and therefore does not require delivery notifications as defined in this specification. Read notifications and any future defined IMDN dispositions, however, are still relevant. Therefore, an IM Sender MUST NOT create MSRP SEND requests requiring a positive-delivery notification or a negative- delivery notification. For SEND requests that are IMDNs, the IM Recipient MUST NOT request a delivery report (an MSRP REPORT to a SEND request). I.e. It MUST populate the request with a Failure-Report header field with the Burger & Khartabil Expires April 16, 2007 [Page 26] Internet-Draft IM Disposition Notification October 2006 value "no" and with a Success-Report header field with value "no" (or alternatively leave out that header field since it defaults to "no"). The IM Recipient also MUST NOT request an IMDN for a SEND request that is an IMDN. An MSRP SEND request to multiple recipients is constructed in a similar manner as a SEND request to a single recipient. The differences are indicated in [14]. 13.1.2. Sending Responses An endpoint receiving an MSRP SEND request constructs an MSRP response according to [11] if needed. Section 7.2 of [11] describes when to send and when not to send an MSRP response. For SEND requests that are IMDNs, a response MUST NOT be generated. This is not a special case; for SEND requests that contain a Failure-Report header field with the value "no" and a Success-Report header field with value "no" the IM Sender does not need to start a timer and the IM Recipient does not send a transactional response. 13.1.3. Receiving Requests 13.1.3.1. Instant Message An MSRP SEND request is identified as an IM by examining its contents according to Section 9. 13.1.3.2. Read Report An MSRP SEND request is identified as read notification by examining its contents according to Section 9. The IM Sender MUST ignore any requests for read notification, or any kind of IMDNs for an IMDN. 13.2. Intermediary Behaviour In this context, application servers (including conference servers and Store-and-Forward server) and gateways are defined as intermediaries. MSRP Relays MUST NOT generate IMDNs but MUST relay them. An MSRP SEND request to multiple recipients is forwarded according to [14]. MSRP has built in delivery reports and therefore does not require delivery notifications as defined in this specification. An MSRP intermediary MUST NOT generate IMDNs. A Store-and-Forwards server (the equivalent of a voice-mail server) can send stored session IMs to their destination and forward the request for read notifications, Burger & Khartabil Expires April 16, 2007 [Page 27] Internet-Draft IM Disposition Notification October 2006 if any. The read notification most likely has to be an aggregated read notification for all the IMs that were stored for that session, and the aggregation has to be done at the IM Recipient. It is unknown at this point how a MSRP store-and-forward server communicates with the recipient in order to send the IMs. This is outside the scope of this document and is left as a future exercise. 14. Security Considerations IMDNs provide a fine-grained view of the activity of the IM Recipient and thus deserves particularly careful confidentiality protection so that only the intended recipient of the IMDN will receive the IMDN (in most cases, the intended recipient of the IMDN is the IM Sender). Since IMDNs are carried by using the IM protocol itself, all security considerations of the underlying IM protocol also apply to the IMDNs. The threats in the IMDN system, over and beyond the threats inherent to IM 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 IM Sender with IMDNs by convincing a URI-List server to send IMDNs to an unsuspecting IM Sender. o A malicious node in the network that attempts to modify an IMDN from a IM Recipient. o A malicious intermediary attempts to forward an IMDN from an IM Recipient to the IM Sender, where the IM Recipient would not normally forward the IMDN to that IM Sender if the IM Recipient knew the identity of the IM Sender. o A malicious endpoint that attempts to fish for a Request-URI of an endpoint beyond an intermediary , where the endpoint 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. Burger & Khartabil Expires April 16, 2007 [Page 28] Internet-Draft IM Disposition Notification October 2006 o A malicious node in the network attempts to stage a denial of service attack on an intermediary by requesting a large list expansion with a request for aggregated IMDN processing. The protocol cannot protect against attacks that include the following: o A malicious intermediary directly revealing the identity of a downstream endpoint that would not normally wish its identity revealed. Keeping such information private is an intermediary implementation issue. o A malicious IM Recipient that alters the time of the IMDN. There is no protocol mechanism for ensuring the IM Recipient does not lie about the time or purposely holds an IMDN for transmission to make it appear that the user read an IM 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 IM Recipient to silently ignore an IMDN request. Any mechanism that would reliably indicate that a malicious node deleted a IM Recipient's IMDN would also serve the purpose of detecting a IM Recipient that chose not to issue an IMDN. To combat eavesdropping, modification, and man-in-the-middle attacks, we require some level of authentication and integrity protections. That said, there are circumstances where strong integrity would be overkill. The presumption is the IM Sender has and sets the expectation for the level of protection. The procedures for integrity protection are as follows. o If the IM Recipient has a certificate, it MUST sign the IMDN. o If the IM is encrypted, the IM Recipient or intermediary 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. o The two above rules are cumulative. The IM Recipient or intermediary MUST be capable of loading a user certificate. An attacker can mount a distributed denial of service attack on a node by sending lots of IMs 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 Burger & Khartabil Expires April 16, 2007 [Page 29] Internet-Draft IM Disposition Notification October 2006 mitigate, but not eliminate this threat by the endpoint immediately ignoring requests that are not authenticated. Likewise, an attacker can mount a denial of service attack on an intermediary by asking the intermediary to explode a large list and to direct the intermediary to aggregate the IMDNs from the targets of the list. The following security considerations apply when using IMDNs: 14.1. Forgery IMs can be forged. To protect against that, an IM can be signed. An intermediary that receives a signed message and needs to modify any part of it that is included in the signature (like adding an Original-To header to the CPIM headers), MUST consume the IM and create a new copy of it that the intermediary signs itself. IMDNs may be forged as easily as ordinary IMs. Endpoints and intermediaries that wish to make automatic use of IMDNs should take appropriate precautions to minimize the potential damage from denial- of-service attacks. Security threats related to forged IMDNs include the sending of a falsified IMDN when the indicated disposition of the IM has not actually occurred. For example, read notification could be forged to indicate that a IM Recipient has read the IM. Unsolicited IMDNs is also another form of forgery. 14.2. Confidentiality There may be cases where an IM Recipient does not wish to reveal the information that he has received or in fact read the IM. In this situation, it is acceptable for the IM Recipient to silently ignore requests for an IMDN. It is strongly RECOMMENDED that the IM Recipient obtain the user's consent before sending an IMDN. Circumstances where the IM Recipient does not ask for the user's consent include IM systems that, for regulatory reasons, are required to issue an IMDN, such as in the health care field or financial community. An IM Recipient can obtain such consent by a prompt or dialog box on a per-IM 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 "forbidden" IMDN status is always sent in response to a request for an IMDN. There are situations where a user sends an IM and requests IMDNs to a list who's member information is not disclosed. In this situation, the user will learn of the list members. Therefore, in this case, Burger & Khartabil Expires April 16, 2007 [Page 30] Internet-Draft IM Disposition Notification October 2006 the URI-List server MUST remove any information about list members. If the number of members in the list is also not disclosed, the URL- List server MUST only deliver one aggregated IMDN. Alternatively, the URI-list server MAY reject the IM. An unencrypted IMDN could reveal confidential information about an encrypted IM. It is a MUST that the same level of security applied to an IM to be applied to its IMDNs. For example, if an IM is signed and encrypted, and IMDN must also be signed and encrypted. 14.3. Non-Repudiation IMDNs cannot be relied on as a guarantee that an IM was or was not seen by the user. Even if IMDNs are not actively forged, they may be lost in transit. The IMDN issuing mechanism may be bypassed in some manner by the IM Recipient. 15. IANA Considerations 15.1. message/imdn+xml MIME TYPE This document registers a new MIME type "message/imdn+xml", and registers a new XML namespace. This specification follows the guidelines of RFC3023 [6]. MIME media type: message MIME subtype name: imdn+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [6]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [6]. Security considerations: See section 10 of RFC 3023 [6] and Section 14 of this document. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type is used to support SIP and MSRP based instant messaging. Burger & Khartabil Expires April 16, 2007 [Page 31] Internet-Draft IM Disposition Notification October 2006 Additional information: None Magic number: None File extension: .cl or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Hisham Khartabil (hisham.khartabil@telio.no) Intended Usage: COMMON Author/change controller: The IETF . 15.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn This section registers a new XML namespace, as per guidelines in the IETF XML Registry [3]. URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn. Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no) . 15.3. Schema Registration This section registers a new XML schema per the procedures in [3]. URI: urn:ietf:params:xml:ns:imdn Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no) The XML for this schema can be found as the sole content of Section 11.3. 15.4. Message/CPIM Header Field registration This document registers the following message/cpim header fields in the cpim-headers registry: Disposition-Notification - [RFCXXXX] Message-ID - [RFCXXXX] Original-To - [RFCXXXX] Burger & Khartabil Expires April 16, 2007 [Page 32] Internet-Draft IM Disposition Notification October 2006 IMDN-Record-Route - [RFCXXXX] IMDN-Route - [RFCXXXX]. 15.5. Content-Disposition: notification This document registers one new Content-Disposition header "disposition-types": notification. The authors request that this values be recorded in the IANA registry for Content-Dispositions. Descriptions of this "disposition-types", including motivation and examples, are given in Section 7.2.1.1 and Section 9. Short descriptions suitable for the IANA registry are: notification the body of the message is a notification according to an earlier request for a disposition notification to an instant message 16. Acknowledgements The authors would like to thank Paul Kyzivat, Ben Campbell, Adam Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia and Eric McMurry for their comments and support. 17. References 17.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [4] Moats, R., "The URN Syntax", RFC 2141, May 1997. [5] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, August 1999. [6] Murata, M., "XML Media Types", RFC 3023, March 1997. [7] Bray, T., "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, October 2000. [8] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. Burger & Khartabil Expires April 16, 2007 [Page 33] Internet-Draft IM Disposition Notification October 2006 17.2. Informative References [9] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [10] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, December 2002. [11] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-15, June 2006. [12] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [13] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [14] Niemi, A., "Multi-part IM Sessions Using MSRP", draft-niemi-simple-chat-04, February 2006. [15] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in SIP", draft-ietf-sip-uri-list-message-00.txt, September 2006. Authors' Addresses Eric Burger Cantata Technology 18 Keewaydin Dr. Salem, NH 03079-2839 USA Phone: +1 603 890 7587 Fax: +1 603 457 5944 Email: eburger@cantata.com Hisham Khartabil Telio P.O. Box 1203 Vika Oslo 0110 Norway Phone: +47 2167 3544 Email: hisham.khartabil@telio.no Burger & Khartabil Expires April 16, 2007 [Page 34] Internet-Draft IM Disposition Notification October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Burger & Khartabil Expires April 16, 2007 [Page 35]