One document matched: draft-ono-earlier-comm-references-00.txt

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]