SIMPLE H. Khartabil Internet-Draft Telio Expires: November 5, 2005 May 4, 2005 Instant Message Delivery and Read Reports draft-khartabil-simple-im-report-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 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Instant Messaging (IM) refers to the transfer of messages between users in near real-time. This document extends Message/CPIM message format to enable endpoints to request, create and send a delivery report as well as a read report for a page-mode as well as session mode instant messages. This document also describes how SIP entities behave using this extension. Khartabil Expires November 5, 2005 [Page 1] Internet-Draft IM Delivery and Read Reports May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Constructing Requests . . . . . . . . . . . . . . . . . . . . 3 3.1 Instant Message . . . . . . . . . . . . . . . . . . . . . 3 3.2 Delivery Report . . . . . . . . . . . . . . . . . . . . . 4 3.3 Read Report . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Identifying Messages . . . . . . . . . . . . . . . . . . . 6 4. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 6 5. Status Report XML Schema . . . . . . . . . . . . . . . . . . . 6 5.1 Structure of XML-Encoded status-report . . . . . . . . . . 6 5.2 MIME Type for status-report Document . . . . . . . . . . . 7 5.3 The XML Schema . . . . . . . . . . . . . . . . . . . . . . 7 6. Transporting Message/CPIM messages using SIP . . . . . . . . . 7 6.1 Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 7 6.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . 7 6.1.2 Sending Responses . . . . . . . . . . . . . . . . . . 7 6.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 8 6.2 Intermediary Behaviour . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Normative References . . . . . . . . . . . . . . . . . . . 9 10.2 Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Khartabil Expires November 5, 2005 [Page 2] Internet-Draft IM Delivery and Read Reports May 2005 1. Introduction 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 a delivery report as well as a read report for a page-mode as well as session mode instant messages. This document also describes how SIP [9] 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. Constructing Requests 3.1 Instant Message A Message/CPIM formatted instant message is contructed using RFC 3862 [2]. The content-type header field indicates the MIME type of the request payload. In this extension, the Message/CPIM MUST contain a Message-ID header if a delivery or read report is requested. The Message-ID field is populated with a value that is random is space and time. This header field enables the message sender to match any delivery and/or read reports and need not be present if the instant message sender is not requesting any reports. The sender can request two types of delivery reports: a failure delivery report and a success delivery report. A failure delivery report is requested by including a Receipt-Request header field with value "negative-delivery". Similarly, a success report is requested by including a Receipt-Request header field with value "positive- delivery". Both types of reports can be requested for the same message. The sender can also request a read report. It is requested by including a Receipt-Request 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 reports. This aids receivers of instant messages that do not support this feature. Khartabil Expires November 5, 2005 [Page 3] Internet-Draft IM Delivery and Read Reports May 2005 The Receipt-Request header fields can be comma separated. The default Content-Disposition of an instant message is "render". Therefore, the absence of such header indicates "render". If an endpoint sending an Instant message and has requested a positive-delivery, negative-delivery and/or read report, it MUST NOT start any timers. The formal syntax of the Request-Receipt header field can be found in Section 4. The following in an example Message/CPIM instant message where the user requests positive and negative delivery reports, but not read report: Content-type: Message/CPIM From: Alice To: Bob Message-ID: 34jk324j Receipt-Request: positive-delivery, negative-delivery Content-type: text/plain Content-length: 12 Hello World 3.2 Delivery Report A delivery report is constructed in a similar fashion as an instant message, using RFC 3862 [2]. For delivery reports, the content-type MUST be of type "message/status-report". It is an XML document. The schema is described Section 5. The delivery report MUST contain a Content-Disposition header field with value "confirm". This indicates to the receiver that the contents of the message are a confirmation according to an earlier request for a report to an instant message. The recipient SHOULD render to the end user a message indicating such confirmation. The delivery report SHOULD NOT contain a Message-ID header field. An example looks like the following: Khartabil Expires November 5, 2005 [Page 4] Internet-Draft IM Delivery and Read Reports May 2005 Content-type: Message/CPIM From: Bob To: Alice Content-type: message/status-report Content-Disposition: confirm Content-length: ... 34jk324j bob@example.com delivery 200 The message was successfully Delivered Request-Receipt header MUST NOT appear in a Message/CPIM messages that represents a delivery report. 3.3 Read Report A read report is constructed in a similar fashion as the delivery report. See Section 3.2 for details. An example looks like the following: Content-type: Message/CPIM From: Bob To: Alice Content-type: message/status-report Content-Disposition: confirm Content-length: ... 34jk324j bob@example.com read 200 The message has been read Request-Receipt header MUST NOT appear in a Message/CPIM messages that represents a read report. 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 report with a value of "485". Khartabil Expires November 5, 2005 [Page 5] Internet-Draft IM Delivery and Read Reports May 2005 This indicates that the result of the read report request cannot be determined or is ambiguous. 3.4 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 "application/status-report+xml". A Message/CPIM message is identified as a delivery report by examining its contents. In the case of a "message/cpim" body, the message is a delivery report if: the content-type header field present in the message/cpim body has a value of "application/ status-report+xml", the Content-Disposition header field has a value of "render", and the element in that xml body has a value of "delivery". An endpoint matches a delivery report to an instant message by matching the Message-ID header field value with the element value in the body of the delivery report. If the message was delivered to multiple recipients, the element in the XML body is used to identify the recipient. A Message/CPIM message request is identified as a read report and is matched to an instant message in a similar fasion as a delivery report. The difference is that the element in that xml body has a value of "read". 4. Header Fields Formal Syntax The following syntax specification uses the message header syntax as described in Section 3 of RFC3862 [2]. Receipt-Request = "Receipt-Request" ": " (receipt-req *(COMMA receipt-req)) receipt-req = "negative-delivery" / "positive-delivery" / "read" Message-ID = "Message-ID" ": " Token 5. Status Report XML Schema 5.1 Structure of XML-Encoded status-report A status-report 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 status-report documents MUST be based on XML 1.0 and MUST be encoded Khartabil Expires November 5, 2005 [Page 6] Internet-Draft IM Delivery and Read Reports May 2005 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:status-report. This namespace declaration indicates the namespace on which the status report is based on. 5.2 MIME Type for status-report Document The MIME type for the status-report document is "application/ status-report+xml". The SIP [9] MESSAGE request [10] that is used to carry the status report that also carries payload type information MUST identify the payload as MIME type "simple-filter+xml" in the Content-Type header field. 5.3 The XML Schema 6. Transporting Message/CPIM messages using SIP 6.1 Endpoint Behaviour 6.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]. The payload is contructed according to Section 3.1. A SIP MESSAGE request to multiple recipients is contracted in a similar manner as SIP MESSAGE request to a single recipient. The differences are indicated in [12]. 6.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 receipt it has been asked for or the type of MESSAGE request it has received (instant message or report). Khartabil Expires November 5, 2005 [Page 7] Internet-Draft IM Delivery and Read Reports May 2005 6.1.3 Receiving Requests 6.1.3.1 Instant Message A SIP MESSAGE request is identified as an instant message by examining its contents according to Section 3.4. If an endpoint received a SIP MESSAGE request that contains a Messge/ CPIM payload that requested a positive-report, and that endpoint has constructed and sent a SIP 2xx class response, it MUST generate a positive-report 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-report is constructed according to Section 3.2. 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-report, and that endpoint has constructed and sent an 2xx class response, it MUST generate a negative-report 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-report is constructed according to Section 3.3. 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-report, and the endpoint has constructed and sent an error response, it MUST NOT generate a negative-report. 6.1.3.2 Delivery Report A SIP MESSAGE request is identified as delivery report by examining its contents according to Section 3.4. 6.1.3.3 Read Report A SIP MESSAGE request is identified as read report by examining its contents according to Section 3.4. 6.2 Intermediary Behaviour An intermediary that behaves as an application server or a gateway needs to conform to this section. A SIP MESSAGE request to multiple recipients is forwarded according to [12]. Khartabil Expires November 5, 2005 [Page 8] Internet-Draft IM Delivery and Read Reports May 2005 If an intermediary generates a SIP 2xx class response to a SIP MESSAGE request it has received that is an instant message, it examines if the body was of type "message/cpim". If so, it checks if there is the header Receipt-Request with a value "positive-delivery" and/or "negative-delivery". If so, it needs to send a delivery report as soon as it receives a transactional response for the instant message. The contruction of a delivery report is performed according to Section 3.2. If the Receipt-Request contains a value of "positive-delivery", the intermediary MUST NOT generate a delivery report 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 Receipt-Request contains a value of "negative-delivery", the intermediary MUST generate a delivery report 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 report. The generation of such report is the same procedure as that for an endpoint (Section 3.2). 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- report, it statelessly forwards that request. 7. Security Considerations 8. IANA Considerations 9. Acknowledgements The author would like to thank Paul Kyzivat, Ben Campbell, Adam Roach and Gonzalo Camarillo for their comments and support. 10. References 10.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. Khartabil Expires November 5, 2005 [Page 9] Internet-Draft IM Delivery and Read Reports May 2005 [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. 10.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. [12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in SIP", draft-ietf-sipping-uri-list-message-02, November 2004. Author's Address Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway Phone: +47 2167 3544 Email: hisham.khartabil@telio.no Khartabil Expires November 5, 2005 [Page 10] Internet-Draft IM Delivery and Read Reports May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Khartabil Expires November 5, 2005 [Page 11]