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: <mid:BF9F2D3B-9F95-4C00-B1C5-072666CE16D9@atlanta.com>;
purpose="ref",
<sipcid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@atlanta.com>;
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: <mid:
BF9F2D3B-9F95-4C00-B1C5-072666CE16D9@atlanta.com>; rel="sequel",
<cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@atlanta.com>;
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",
<f81d4fae-7dec-11d0-a765-00a0c91e6bf6@atlanta.com>; type="sip",
<ffd7076498744578d10edabfe7f4a866>; 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]