SIMPLE E. Burger Internet-Draft Cantata Technology Expires: November 27, 2006 H. Khartabil Telio May 26, 2006 Instant Message Disposition Notification draft-ietf-simple-imdn-00 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 November 27, 2006. 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 extends Message/CPIM message format to enable endpoints to request, create and send IM Disposition Notifications (IMDN), including delivery and read notifications, for page-mode as well as session mode instant messages. This document also describes how SIP Burger & Khartabil Expires November 27, 2006 [Page 1] Internet-Draft IM Disposition Notification May 2006 and MSRP entities behave using this extension. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Disposition States . . . . . . . . . . . . . . . . . . . . 5 3.1.1. delivered . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. read . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Endpoints Behaviour . . . . . . . . . . . . . . . . . . . . . 5 4.1. Constructing Instant Messages . . . . . . . . . . . . . . 5 4.2. Constructing IMDNs . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Constructing Delivery Notification . . . . . . . . . . 7 4.2.2. Constructing Read Notification . . . . . . . . . . . . 8 4.3. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 8 4.4. Keeping State . . . . . . . . . . . . . . . . . . . . . . 9 5. Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 9 5.1. Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 10 6. Identifying Messages . . . . . . . . . . . . . . . . . . . . . 11 7. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. CPIM Header Namespace . . . . . . . . . . . . . . . . . . 11 7.2. Disposition-Notification . . . . . . . . . . . . . . . . . 12 7.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Original-To . . . . . . . . . . . . . . . . . . . . . . . 12 7.5. Really-From . . . . . . . . . . . . . . . . . . . . . . . 12 7.6. Really-To . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 12 9. IMDN Format . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Structure of XML-Encoded imdn . . . . . . . . . . . . . . 13 9.1.1. The Element . . . . . . . . . . . . . . . 13 9.1.2. The Element . . . . . . . . . . . . . . . . 13 9.1.3. The ; Element . . . . . . . . . . . . . 14 9.1.4. The ; Element . . . . . . . . 14 9.1.5. The ; Element . . . . . . . . . . . . . . . . 14 9.1.6. The Element . . . . . . . . . . . . . . 14 9.1.7. The Element . . . . . . . . . . . . . . . . . 14 9.1.8. The Element . . . . . . . . . . . . . . . . . . 14 9.2. MIME Type for imdn Document . . . . . . . . . . . . . . . 14 9.3. The XML Schema . . . . . . . . . . . . . . . . . . . . . . 15 10. Transporting Message/CPIM messages using SIP . . . . . . . . . 15 10.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 15 10.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 15 10.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 15 10.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 15 10.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 16 11. Transporting Message/CPIM messages using MSRP . . . . . . . . 17 Burger & Khartabil Expires November 27, 2006 [Page 2] Internet-Draft IM Disposition Notification May 2006 11.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 17 11.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 17 11.1.2. Sending Responses . . . . . . . . . . . . . . . . . . 18 11.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 18 11.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 21 12.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 22 13.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn . . . . . . . . . . . . . . . 23 13.3. Schema Registration . . . . . . . . . . . . . . . . . . . 23 13.4. Message/CPIM Header Field registration . . . . . . . . . . 23 13.5. Content-Disposition: notification . . . . . . . . . . . . 24 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . . 24 15.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Burger & Khartabil Expires November 27, 2006 [Page 3] Internet-Draft IM Disposition Notification May 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 message can also be used to carry Message/CPIM messages. This document extends Message/CPIM message format to enable endpoints 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 and read notifications as well as negative delivery notifications (i.e. a message did not get delivered successfully). By using a 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 pager-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. Overview The basic protocol flow is as follows. A message sender marks a message for disposition notification. At a certain point in time, the recipient user agent or an intermediary determines the recipient has received, did not receive or has read the message or otherwise disposed the message. The mechanism by which an instant message user agent determines its user has read a message is beyond the scope of this document. At that point, the recipient user agent or Burger & Khartabil Expires November 27, 2006 [Page 4] Internet-Draft IM Disposition Notification May 2006 intermediary automatically generates a notification message to the sender. This notification message is the Instant Message Disposition Notification (IMDN). 3.1. Disposition States There are two broad categories of disposition states. They are delivered and read. Future extensions may introduce others 3.1.1. delivered The "delivered" state indicates whether the Recipient has received the instant message or not (positive or negative delivery). 3.1.2. read The "read" state indicates whether the Recipient displayed the instant message to the user or not. 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. 4. Endpoints Behaviour 4.1. Constructing Instant Messages A Message/CPIM formatted instant message is constructed using RFC 3862 [2]. The content-type header field indicates the MIME type of the request payload. In this extension, the Message/CPIM IM MAY contain a Message-ID header field if an IMDN is requested. The Message-ID field is populated with a value that is unique in space and time. This header field enables the message sender to match any notifications with their corresponding IMs. This header need not be present if the instant message sender is not requesting any IMDNs or if no state of any kind is kept for an IM. The recipient on an IMDN may not be the same user agent that sent the instant message. This is specifically true for page-mode instant messages where the Address of Record (AOR) of the IM sender present in the IMDN resolves to a different location to where the IM originated. Also, 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 in order to enable the human user to correlate the Burger & Khartabil Expires November 27, 2006 [Page 5] Internet-Draft IM Disposition Notification May 2006 IM with the IMDN. 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 message/CPIM DateTime header field is used for this purpose. The message/CPIM IM MUST contain a DateTime header field if an IMDN is requested. In this specification, the sender can request two types of delivery notifications: a failure delivery notification and a success delivery notification. A failure delivery notification is requested 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 notifications can be requested for the same message. The 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 sender is not requesting any IMDNs. This aids receivers of instant messages that do not support this feature. The Disposition-Notification header fields can be comma separated. Future extension may define other disposition notifications not defined in this document. The IM sender MAY request more than one kind of IMDN for a single IM. The formal syntax of the Disposition-Notification header field can be found in Section 8. The following in an example Message/CPIM instant message where the user requests positive and negative delivery notifications, but not read notification: Content-type: Message/CPIM From: Alice To: Bob Message-ID: 34jk324j DateTime: 2006-04-04T12:16:49-05:00 Disposition-Notification: positive-delivery, negative-delivery Content-type: text/plain Content-length: 12 Hello World 4.2. Constructing IMDNs As indicated earlier, an endpoint sending an IM may choose to request more than one type of IMDN for a single IM, For example a delivery notification as well as a read notification. In this case the Burger & Khartabil Expires November 27, 2006 [Page 6] Internet-Draft IM Disposition Notification May 2006 endpoint constructing IMDNs MUST be able to construct multiple IMDNs per IM. Disposition-Notification header MUST NOT appear in a Message/CPIM message that represents an IMDN since it does not make sense and is therefore forbidden to request an IMDN for an IMDN. The recipient of the IMDN MUST ignore it if present. An IMDN SHOULD NOT contain a Message-ID header field since it is used for matching an instant message with its IMDNs and no IMDNs are ever requested for IMDNs. The recipient of the IMDN MUST ignore the Message-ID header field if present. If Really-From header fields appear in the IM, the endpoint constructing the IMDN MUST copy the contents of the Really-From header fields into Really-To header fields in the IMDN and maintain the order. The IMDN is then sent to the address in the top Really-To header field. 4.2.1. Constructing Delivery Notification A delivery notification is constructed in a similar fashion as an instant message, using RFC 3862 [2]. For delivery notifications, the content-type MUST be of type "message/imdn+xml". It is an XML document. The schema is described Section 9. The delivery notification MUST contain a Content-Disposition header field with value "notification". This indicates to the receiver that the contents of the message are a notification according to an earlier request for an IMDN to an instant message. An example looks like the following: 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 bob@example.com bob@example.com delivery success The message was successfully Delivered Burger & Khartabil Expires November 27, 2006 [Page 7] Internet-Draft IM Disposition Notification May 2006 4.2.2. Constructing Read Notification A read notification is constructed in a similar fashion as the delivery notification. See Section 4.2.1 for details. An example looks like the following: 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 bob@example.com bob@example.com read success The message has been read There are situations where the recipient user agent cannot determine if or when the message has been read. The recipient user agent in this case generates a read notification with a value of "error" to indicate an internal error by the server. 4.3. Aggregation of IMDNs An endpoint may send an instant message to multiple recipients in one transport protocol message (typically using a URI-List server) and request IMDNs. If it does so, it MAY choose to either get one IMDN from each recipient individually or get an aggregated IMDN (the URI- List server aggregates the IMDNs and send the one aggregated IMDN). The endpoint does so by adding the Disposition-Notification header field parameter "aggregate". The absence of such a parameter indicates that the endpoint does not want IMDNs aggregated. Aggregation can be done per IMDN requested. For example, a IM sender can request delivery notification to be aggregated but read reports to be sent individually. For example: Disposition-Notification: positive-delivery;aggregate, read Burger & Khartabil Expires November 27, 2006 [Page 8] Internet-Draft IM Disposition Notification May 2006 An endpoint that requested an aggregated IMDN MUST be prepared to receive multiple aggregated IMDNs. See Section 5.1 for details. An endpoint MUST be prepared to receive aggregated IMDNs even if it did not request the URI-List server to do so. See again Section 5.1 for details. Note that the "aggregate" parameter is a hint for intermediaries and does not require the intermediaries to aggregate IMDNs. 4.4. Keeping State This specification does not mandate the sender of an IM to keep state for a sent IM. Once an endpoint sends an instant message with an IMDN request, it MAY preserve the message context, principally the Message-ID, and other user-identifiable information such as the message subject or content, and date and time it was sent. Without preservation of the message context, the Requesting endpoint will not be able to correlate the IMDN with the outbound IM. The Requesting endpoint may find it impossible to preserve message 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 messages. This "Sent Items" box has the necessary information and may have a fancy user interface indicating the state of a sent message. Unique Message-ID for this purpose proves to be useful. How long to keep items 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 a requesting endpoint 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 IMDN's. 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 disposition notifications may be received. 5. 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 Burger & Khartabil Expires November 27, 2006 [Page 9] Internet-Draft IM Disposition Notification May 2006 in the CPIM To header field when forwarding (for example, a URI-List server change the recipient address from its own to the address of the final recipient of that message). In this case, the intermediary MUST add a CPIM Original-To header to the CPIM message populating it with the address of the sender. An intermediary MAY choose to remain on the path of IMDNs for a specific IM. It can do so by adding a CPIM Really-From header field as the top Really-From header and populating it with its own address. This works well with intermediaries that don't support this extension in that IMDNs would therefore traverse directly from receiver to sender or to intermediaries that do support the extension. An intermediary receiving an IMDN checks the top Really-To 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 Really-To header. 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 from the body of the IMDN before forwarding it to the IM sender. 5.1. Aggregation of IMDNs In this context, URI-List servers are defined as intermediaries. When a URI-List server receives an instant message, 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 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. Burger & Khartabil Expires November 27, 2006 [Page 10] Internet-Draft IM Disposition Notification May 2006 A URI-List server MAY aggregate IMDNs even if the IM sender did not request from it to do so. This is to handle the case where the list membership information is not disclosed. 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 10.2 for further details. 6. Identifying Messages Message/CPIM messages are typically carried in a transport protocol like SIP [9]. In the case of a "message/cpim" body in the request of the transport protocol, the message is an instant message if the content-type header field present in the message/cpim body has a value that is NOT "message/imdn+xml". A Message/CPIM message is identified as a delivery notification by examining its contents. In the case of a message/cpim body, the message is a delivery notification if: the content-type header field present in the message/cpim body 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 value of "delivery". An endpoint matches a delivery notification to an instant message by matching the Message-ID header field value with the element value in the body of the delivery notification. If the message was delivered to multiple recipients, the element or the element in the XML body is used to identify the recipient. A Message/CPIM message request is identified as a read notification and is matched to an instant message in a similar fashion as a delivery notification. The difference is that the element in that xml body has a value of "read". 7. Header Fields 7.1. CPIM Header Namespace Per CPIM [2], IMDN uses a namespace for the CPIM headers. The namespace is urn:ietf:params:cpim-headers:imdn All of the header definitions in this document refer to this Burger & Khartabil Expires November 27, 2006 [Page 11] Internet-Draft IM Disposition Notification May 2006 namespace. 7.2. Disposition-Notification The Disposition-Notification header field is a Message/CPIM extension that is used by the instant message sender to indicate the request to receive IMDNs for that specific IM. This header field is optional and is not needed if the IM sender does not request an IMDN. The syntax is defined in Section 8. 7.3. Message-ID The Message-ID header field is a Message/CPIM extension that is used by the instant message sender to correlate received IMDNs by comparing its value with the value of the element present in the IMDN payload. This header field is optional. The syntax is defined in Section 8. 7.4. Original-To The Original-To header field is a Message/CPIM extension that is added to an IM by an intermediary. It is used by the instant message 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 syntax is defined in Section 8. 7.5. Really-From The Really-From header field is a Message/CPIM extension that is added to an IM by an intermediary in order to indicate that it wants the IMDN to be sent to it. The syntax is defined in Section 8. Multiple Really-From headers can appear in an IM 7.6. Really-To The Really-To header field is a Message/CPIM extension that is added to an IMDN by an endpoint by copying the contents of te Really- From header that appeared in the IM. This header is used by the endpoint and intermediaries to route IMDNs to the final destination. The syntax is defined in Section 8. Multiple Really-From headers can appear in an IMDN. 8. Header Fields Formal Syntax The following syntax specification uses the message header syntax as described in Section 3 of RFC3862 [2]. Burger & Khartabil Expires November 27, 2006 [Page 12] Internet-Draft IM Disposition Notification May 2006 Disposition-Notification = "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))] notify-req = ("negative-delivery" / "positive-delivery" / "read" / Token) *(SEMI disp-notif-params) disp-notify-params = "aggregate" / generic-param Message-ID = "Message-ID" ": " Token Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">" Really-From = "Really-From" ": " [ Formal-name ] "<" URI ">" Really-From = "Really-To" ": " [ Formal-name ] "<" URI ">" 9. IMDN Format 9.1. Structure of XML-Encoded imdn An IMDN 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 documents 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 on. The root element is . The element has sub-elements, namely , , , , , , , . Those elements are described in details in the following sections. 9.1.1. The Element The element is optional according to the XML schema and carries the message id that appeared in the Message-ID header field of the IM, if any. This element is mandatory if the IM contained a Message-ID header field. 9.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 Message/CPIM DateTime header field of the IM. Burger & Khartabil Expires November 27, 2006 [Page 13] Internet-Draft IM Disposition Notification May 2006 9.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. 9.1.4. The ; Element The element is optional and carries the URI of the final recipient. It MUST be present if the IM carried the CPIM Original-To header field. This information to populate this element is obtained from the Original-To header field of the IM. 9.1.5. The ; Element The element is optional and carries the text that was in the Message/cpim Subject header field. This allows for a human level correlation between an IM and an IMDN. 9.1.6. The Element The is element mandatory and carries the disposition type that the IM sender requested and is being reported. I can carry the values "delivery", "read" and any other future extension. 9.1.7. The Element The element is mandatory and carries the result of the disposition request in the element. It can carry the values "success" to mean the disposition was successful, "failure" to mean the disposition fail, "forbidden" to mean the disposition was denied, "error" to mean internal server error, and any other future extension. 9.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. 9.2. MIME Type for imdn Document The MIME type for the imdn document is "message/imdn+xml". The SIP [9] MESSAGE request [10] or the MSRP SEND request [11] that is used to carry the IMDN that also carries payload type information MUST identify the payload as MIME type "message/imdn+xml" in the Content- Type header field. Burger & Khartabil Expires November 27, 2006 [Page 14] Internet-Draft IM Disposition Notification May 2006 9.3. The XML Schema 10. Transporting Message/CPIM messages using SIP 10.1. Endpoint Behaviour 10.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 Instant Messages and IMDNs. The payload is constructed according to Section 4. 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]. 10.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 the IMDN it has been asked for or the type of MESSAGE request it has received (instant message or IMDN). 10.1.3. Receiving Requests 10.1.3.1. Instant Message A SIP MESSAGE request is identified as an instant message by examining its contents according to Section 6. If an endpoint received a SIP MESSAGE request that is carrying an IM and that contains a Messge/CPIM payload that requested a positive- delivery notification, and that endpoint has constructed and sent a SIP 2xx class response, it MAY generate a positive-delivery notification after making sure that the instant message 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 message). The positive-delivery notification is constructed according to Section 4.2.1. The message/ cpim message is then placed as the payload in a SIP MESSAGE request. If an endpoint received a SIP MESSAGE request that contains a Messge/ CPIM payload that requested a negative-delivery, and that endpoint Burger & Khartabil Expires November 27, 2006 [Page 15] Internet-Draft IM Disposition Notification May 2006 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 instant message (a GW, for example, can generate a 2xx response before it has been guaranteed that the final recipient has actually received the message). The negative-delivery notification is constructed according to Section 4.2.1. The message/cpim message is then placed as the payload in a SIP MESSAGE request. If an endpoint received a SIP MESSAGE request that requested a negative-delivery notification, and the endpoint has constructed and sent an error response, it MUST NOT generate a negative-delivery notification. If an endpoint received a SIP MESSAGE request that is an IM and that contains a Messge/CPIM payload that requested a read notification, and that endpoint has constructed and sent a SIP 2xx class response, it MAY generate a read notification after making sure that the instant message has been presented to the user or application. It is outside the scope of this document how a 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 4.2.2. The message/cpim message is then placed as the payload in a SIP MESSAGE request. 10.1.3.2. Delivery Notification A SIP MESSAGE request is identified as delivery notification by examining its contents according to Section 6. 10.1.3.3. Read Notification A SIP MESSAGE request is identified as read notification by examining its contents according to Section 6. 10.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 then 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 instant message, it Burger & Khartabil Expires November 27, 2006 [Page 16] Internet-Draft IM Disposition Notification May 2006 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 response for the instant message. 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 instant message. This is in anticipation of a failure downstream after a 2xx response has been generated. If the Disposition-Notification header field contains a value of "negative-delivery", the intermediary MUST generate a delivery notification if it receives a SIP 4xx, 5xx or 6xx class final response for the sent instant message or if it has received a SIP 2xx class response followed by a negative-delivery notification. The generation of such IMDN is the same procedure as that for an endpoint (Section 4.2.1). The element of the XML body is populated with the URI of the instant message recipient. If an intermediary receives a SIP MESSAGE request carrying a read notification, it statelessly forwards it. 11. Transporting Message/CPIM messages using MSRP 11.1. Endpoint Behaviour 11.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 Instant Messages and IMDNs. The payload is constructed according to Section 4. 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, as still relevant. Therefore, an endpoint MUST NOT create MSRP SEND requests requiring a positive-delivery notification or a negative- delivery notification. Burger & Khartabil Expires November 27, 2006 [Page 17] Internet-Draft IM Disposition Notification May 2006 For SEND requests that are IMDNs, the sender 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 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 sender also MUST NOT request an IMDN for a SEND request that is an IMDN. An MSRP SEND request to multiple recipients is contracted in a similar manner as a SEND request to a single recipient. The differences are indicated in [14]. 11.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 sender does not need to start a timer and the receiver does not send a transactional response. 11.1.3. Receiving Requests 11.1.3.1. Instant Message An MSRP SEND request is identified as an instant message by examining its contents according to Section 6. 11.1.3.2. Read Report An MSRP SEND request is identified as read notification by examining its contents according to Section 6. The receiver MUST ignore any requests for read notification, or any kind of IMDNs for an IMDN. 11.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 Burger & Khartabil Expires November 27, 2006 [Page 18] Internet-Draft IM Disposition Notification May 2006 intermediary MUST NOT generate IMDNs. A Store-and-Forwards server (the equivalent of a voicemail server) can send stored session IMs to their destination and forward the request for read notifications, 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 endpoint. 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. 12. Security Considerations Instant Message IMDNs provide a fine-grained view of the activity of the entity receiving the IM and thus deserves particularly careful confidentiality protection so that only the intended recipient of the IMDN will receive the IMDN message (in most cases, the intended recipient of the IMDN is the sender of the IM). Since the IMDN messages are carried by using the IM protocol itself, all security considerations of the underlying IM protocol also apply to the IMDN messages. 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 user with IMDNs by convincing a URI-List server to send IMDNs to an unsuspecting user. o A malicious node in the network that attempts to modify an IMDN from a Reporting endpoint. o A malicious intermediary attempts to forward an IMDN from a Reporting endpoint to the Requesting endpoint, where the Reporting endpoint would not normally forward the IMDN to that Requesting endpoint if the Reporting endpoint knew the identity of the Requesting endpoint. 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 Burger & Khartabil Expires November 27, 2006 [Page 19] Internet-Draft IM Disposition Notification May 2006 endpoint. o A malicious node in the network that attempts to eavesdrop on IMDN traffic to, for example, learn Request-URI or traffic pattern information. o A malicious node in the network attempts to stage a denial of service attack on an intermediary by requesting a large list expansion with a request for aggregated IMDN processing. Attacks the protocol cannot protect against 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 issue implementation issue. o A malicious Reporting endpoint that alters the time of the report. There is no protocol mechanism for ensuring the endpoint does not lie about the time or purposely holds an IMDN for transmission to make it appear the user disposed of a message later than they actually did. o A deletion attack on an IMDN. This is a trade-off between privacy and security. The privacy considerations allow the Reporting endpoint to silently ignore an IMDN request. Any mechanism that would reliably indicate that a malicious node deleted a Reporting endpoint's IMDN would also serve the purpose of detecting a Reporting endpoint 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 sender of the IM has and sets the expectation for the level of protection. The procedures for integrity protection are as follows. o If the Reporting endpoint has a certificate, it MUST sign the IMDN. o If the IM is encrypted, the Reporting endpoint 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 reporting endpoint MUST be capable of loading a user certificate. Burger & Khartabil Expires November 27, 2006 [Page 20] Internet-Draft IM Disposition Notification May 2006 An attacker can mount a distributed denial of service attack on a node by sending lots of messages to the node with IMDN requests. Note that this is the same problem as there is without IMDN; IMDN simply linearly increases the load on the node under attack. One can mitigate, but not eliminate this threat by the endpoint immediately ignoring requests that are not authenticated. Likewise, an attacker can mount a denial of service attack on a B2BUA by asking the B2BUA to explode a large list and to direct the B2BUA to consolidate the IMDN's from the targets of the list. The following security considerations apply when using message IMDNs: 12.1. Forgery Message IMDNs may be forged as easily as ordinary Instant Message. User agents 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 message IMDNs include the sending of a falsified IMDN when the indicated disposition of the message has not actually occurred. For example, read notification could be forged to indicate that a IM recipient has read the instant message. Unsolicited IMDNs is also another form of forgery. 12.2. Confidentiality There may be cases where an instant message recipient does not wish to reveal the information that he has received or in fact read the instant message. In this situation, it is acceptable for the UA to silently ignore requests for an IMDN. It is strongly RECOMMENDED that the user agent obtain the user's consent before sending an IMDN. Circumstances where the user agent does not ask for the user's consent include instant messaging systems that, for regulatory reasons, are required to issue an IMDN, such as in the health care field or financial community. A user agent can obtain such consent by a prompt or dialog box on a per-message basis, globally through the user's setting of a preference, or other, user-configurable mechanism. The user might also indicate globally that IMDNs are never to be sent or that a "forbidden" IMDN status is always sent in response to a request for an IMDN. There are situations where a user sends an IM and requesting IMDNs to a list who's member information is not disclosed. In this situation, the sender will learn of the list members. The URI-List server MUST only deliver one aggregated IMDN. Alternatively, the list server MAY Burger & Khartabil Expires November 27, 2006 [Page 21] Internet-Draft IM Disposition Notification May 2006 reject the IM. An unencrypted IMDN could reveal confidential information about an encrypted instant message. 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. 12.3. Non-Repudiation Message IMDNs cannot be relied on as a guarantee that an instant message was or was not seen by the recipient. 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 recipient on the IM. . 13. IANA Considerations 13.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 12 of this document. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to support SIP and MSRP based instant messaging. Burger & Khartabil Expires November 27, 2006 [Page 22] Internet-Draft IM Disposition Notification May 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 . 13.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) . 13.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 9.3. . 13.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 November 27, 2006 [Page 23] Internet-Draft IM Disposition Notification May 2006 13.5. Content-Disposition: notification content-disposition notification . 14. Acknowledgements The author would like to thank Paul Kyzivat, Ben Campbell, Adam Roach and Gonzalo Camarillo for their comments and support. 15. References 15.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., "Exensible 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. 15.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-10, February 2005. Burger & Khartabil Expires November 27, 2006 [Page 24] Internet-Draft IM Disposition Notification May 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-sipping-uri-list-message-02, November 2004. Burger & Khartabil Expires November 27, 2006 [Page 25] Internet-Draft IM Disposition Notification May 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@brooktrout.com Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway Phone: +47 2167 3544 Email: hisham.khartabil@telio.no Burger & Khartabil Expires November 27, 2006 [Page 26] Internet-Draft IM Disposition Notification May 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Burger & Khartabil Expires November 27, 2006 [Page 27]