Network Working Group K. Ono Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia University Expires: April 15, 2010 October 12, 2009 Referencing Earlier Communications in SIP Requests draft-ono-earlier-comm-references-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a SIP header extension that refers to earlier SIP or non-SIP communication in SIP requests. For example, this extension allows users to correlate a SIP session with earlier Ono & Schulzrinne Expires April 15, 2010 [Page 1] Internet-Draft Referencing Earlier Communications in SIP October 2009 sessions or email exchanges. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. SIP UA Procedures . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Originator and SIP UAC Procedures . . . . . . . . . . . . . 3 2.2. Recipient and SIP UAS Procedures . . . . . . . . . . . . . 4 3. SIP Header Extension . . . . . . . . . . . . . . . . . . . . . 4 3.1. Option 1: Call-Info . . . . . . . . . . . . . . . . . . . . 4 3.2. Option 2: References . . . . . . . . . . . . . . . . . . . 5 3.3. Option 3: New-References . . . . . . . . . . . . . . . . . 6 4. Relationship to Content Indirection . . . . . . . . . . . . . . 6 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 6 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Ono & Schulzrinne Expires April 15, 2010 [Page 2] Internet-Draft Referencing Earlier Communications in SIP October 2009 1. Introduction SIP [RFC3261] and non-SIP communication are sometimes used for the same communication thread, sharing a common subject. Communication mechanisms alternate for SIP, other real-time communication mechanisms, email messages, instant messages, and web pages, depending on the situation at users. Thus, referencing earlier communications beyond SIP allows users to sort SIP requests by communication thread or to differentiate incoming SIP requests from unsolicited bulk calls [I-D.ono-cross-media-relations]. Furthermore, this reference mechanism allows the originator to remind the recipient of the context. The reference mechanism also allows the recipient to ascertain the context in an incoming SIP session. If the recipient prefers, the related communication log can be retrieved using the identifier of an earlier communication specified in this reference mechanism. This reference mechanism is expected to contribute towards more effective communication across various communication mechanisms. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. SIP UA Procedures This section explains how SIP UAs (User Agents) process references to earlier communications through SIP UAs or other communication applications, both at the originator and at the recipient. 2.1. Originator and SIP UAC Procedures We assume that the originator has contacted the potential recipient of a new session previously through a SIP UA or through another communication application. We also assume that the originator can access the log of an earlier session, such as call detail records including the call identifiers, or an email message received from the potential recipient of a new session. Note that it is not appropriate to refer an email message sent to a potential recipient, since the email message may not yet have reached the recipient. In order to put this reference mechanism into effect, the same communication log needs to be stored at the potential recipient. Ono & Schulzrinne Expires April 15, 2010 [Page 3] Internet-Draft Referencing Earlier Communications in SIP October 2009 This assumption does not require that the originator maintain the log of all communications including received from unknown users, but that the originator maintain the log of communications which are likely to be followed by one or more communications in future. When the originator initiates a session in the same context with the earlier communication which he or she specifies at the log, a SIP UAC (User Agent Client) sends an INVITE request along with the reference to the earlier communication. The reference information is transferred to the SIP UAC automatically or manually. 2.2. Recipient and SIP UAS Procedures We assume that the recipient stores the log of sessions or messages through a SIP or other communication application that are likely to be followed by one or more communications in future. When the recipient receives a SIP INVITE request with the reference to an earlier communication, the SIP UAS (User Agent Server) tries to retrieve the referred information from the communication log corresponding to the communication type specified in the reference. If the referred information is found at the communication log, the SIP UAS MAY add the information retrieved from the communication log into the message of the incoming call notification, which usually contains only the originator information of the From header. Alternatively, the SIP UAS or the inbound proxy on behalf of the SIP UAS MAY screen incoming SIP INVITE requests depending on whether the referred information is found at the communication log. 3. SIP Header Extension We propose to extend the SIP header to convey the reference to earlier communication consisting of the type of the communication mechanism and the identifier. For this initial draft, we are not proposing a particular mechanism, but rather considering three possibilities to illustrate the concept. The three options are: the Call-Info [RFC3261] header, defined for more generic purposes, the References header [I-D.worley-references], proposed for more specific purposes and a new header, New-References, designated for our purposes. We describe how to apply each option to the reference mechanism. 3.1. Option 1: Call-Info The Call-Info header provides additional information about the session via a URI for generic purposes. The purpose of the URI is specified with the predefined value of the "purpose" parameter. Ono & Schulzrinne Expires April 15, 2010 [Page 4] Internet-Draft Referencing Earlier Communications in SIP October 2009 Thus, we need to define a new value of the "purpose" parameter, "ref". For the type of the communication mechanism, we use the scheme name of the URI, instead of defining a new parameter. The "mid" URI scheme [RFC2392] is for the reference to email messages and the "cid" URI scheme [RFC2392] is for the reference to instant messages containing the content identifier [RFC3862]. In contrast, no URI scheme is defined for the call identifier of a SIP session, which is not defined as a globally unique identifier but a unique one at a particular client. Thus, we have an open issue of referring to a SIP session in a URI scheme, although many implementations in practice generate a globally unique identifier for the call identifier. If a SIP UA knows the referred call identifier is globally unique, the value of the call identifier can be set in the URI scheme for a SIP call identifier which needs to be newly defined as "sipcid", for example. For instant messages in the XMPP [RFC3921], the "cid" URI scheme cannot be used since the content identifier is not used. Instead, for tracking purposes, the "thread" element is optionally used as the identifier of an instant messaging session between the originator and the recipient. Thus, another open issue is how to refer to an XMPP instant messaging session in a URI scheme. The following is an example of the Call-Info header referencing an email message and an earlier SIP session. Call-Info: ; purpose="ref", ; purpose="ref" 3.2. Option 2: References The References header has been proposed to refer to earlier dialogs mainly for diagnosis purposes. The current draft [I-D.worley-references] defines the "rel" parameter to indicate how dialogs are related to each other. If we consolidate our reference mechanism into the References header, we will use the existing "sequel" value for the "rel" parameter, indicating the continuation of the conversation. Since the References header field currently limits to a call identifier, we need to expand it to allow a URI. As we described for the Call-Info header above, we have issues of the URIs to refer to a SIP session and to an instant messaging session in the XMPP. The following is an example of the References header referring to an email message and a content in a CPIM instant message [RFC3862] . Ono & Schulzrinne Expires April 15, 2010 [Page 5] Internet-Draft Referencing Earlier Communications in SIP October 2009 References: ; rel="sequel", ; rel="sequel" 3.3. Option 3: New-References The New-References header is a new header designated for our reference mechanism. The type of communication mechanism is described in the "type" parameter. The "email" value indicates that the preceded identifier is the message identifier of an email message. Similarly, the "sip" value is for the call identifier of a SIP session and the "xmpp" value is for the thread element of an XMPP instant messaging session. The structure is compatible neither with the References header in email [RFC5322], nor with the SIP References under discussion [I-D.worley-references], since both specifications limit the type of identifiers to a single communication mechanism. The following is an example of the New-References header referring to an email message, an earlier SIP session and an XMPP instant messaging session New-References: < BF9F2D3B-9F95-4C00-B1C5-072666CE16D9@atlanta.com>; type="email", ; type="sip", ; type="xmpp" 4. Relationship to Content Indirection The reference mechanism is a mechanism for content indirection, but the purpose and the target content are different from the content indirection in SIP [RFC4483]. "The purpose of content indirection is purely to provide an alternative transport mechanism for SIP MIME body parts" while the purpose of the reference mechanism here is to reference the content of earlier communications. 5. Security Consideration Transferring the reference containing the identifiers of previous communications raises privacy concerns of users. For example, the message identifier of an email message [RFC5322] leaks the domain name or the IP address of the host the message was created and the date the message was created, depending on the algorithm of the generator. To prevent a third party from eavesdropping on SIP messages, SIP signaling security like TLS [RFC5246] SHOULD be used. If users need to conceal the identifiers of earlier communications Ono & Schulzrinne Expires April 15, 2010 [Page 6] Internet-Draft Referencing Earlier Communications in SIP October 2009 even from the proxy servers in the SIP signaling path, SIP UA SHOULD set the SIP header containing the identifiers only in a SIP message body encrypted with S/MIME [RFC3851]. 6. IANA Consideration TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 7.2. Informative References [I-D.ono-cross-media-relations] Ono, K. and H. Schulzrinne, "Using Cross-Media Relations to Reduce False Positives during SPIT Filtering", draft-ono-cross-media-relations-00 (work in progress), October 2009. [I-D.worley-references] Worley, D., "The References Header for SIP", draft-worley-references-04 (work in progress), June 2009. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. Ono & Schulzrinne Expires April 15, 2010 [Page 7] Internet-Draft Referencing Earlier Communications in SIP October 2009 [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. Authors' Addresses Kumiko Ono Columbia University Department of Computer Science New York, NY 10027 USA Email: kumiko@cs.columbia.edu Henning Schulzrin ne Columbia University Department of Computer Science New York, NY 10027 USA Email: hgs@cs.columbia.edu Ono & Schulzrinne Expires April 15, 2010 [Page 8]