<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--xml2rfcv2-->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>

<rfc category="info" ipr="trust200902" number="6993" submissionType="IETF" consensus="yes">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <front>

    <title abbrev="Call-Info Purpose: IMPP">Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)</title>

    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1899 Wynkoop Street, Suite 600</street>
          <city>Denver</city>
          <region>CO</region>
          <code>80202</code>
          <country>USA</country>
        </postal>
        <phone>+1-303-308-3282</phone>
        <email>psaintan@cisco.com</email>
      </address>
    </author>

    <date month="July" year="2013"/>

    <keyword>SIP</keyword>
    <keyword>Call-Info</keyword>
    <keyword>header field</keyword>
    <keyword>Instant Messaging</keyword>
    <keyword>Presence</keyword>
    
<!-- [rfced] FYI, we have used xml2rfc v2 
(available from http://xml.resource.org) to convert this document to text.                        
-->

    <abstract>
      <t>This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).</t>
    </abstract>

  </front>

  <middle>

    <section title="Introduction" anchor="intro">
      <t>Some real-time communication endpoints support the combined use of the
Session Initiation Protocol (SIP) [RFC3261] and the Extensible Messaging and
Presence Protocol (XMPP) [RFC6120]. To improve interoperability among such
"CUSAX" endpoints [CUSAX], it can be helpful to advertise each endpoint's SIP
address over XMPP and each endpoint's XMPP address over SIP, thus providing
hints about the communication capabilities of the endpoints.
The former feature is enabled by an XMPP
extension protocol called Reachability Addresses <xref target='XEP-0152'/>.  As
to the latter feature, discussion in the SIP community led to the conclusion
that it would be best to use the Call-Info header field <xref
target='RFC3261'/> with a value of "impp" ("instant messaging and presence
protocol") for the "purpose" header field parameter.  An example follows.
</t> 
      <figure>
        <artwork><![CDATA[
Call-Info: <xmpp:juliet@example.com> ;purpose=impp
        ]]></artwork>
      </figure>
      <t>Although CUSAX endpoints constitute the primary use case for the "impp" purpose, a Uniform Resource Identifier (URI) <xref target='RFC3986'/> for an instant messaging and presence protocol other than XMPP could be included in the Call-Info header field.</t>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>Advertising an endpoint's XMPP address over SIP could inform malicious
entities about an alternative attack vector.  Because the "purpose" header
field parameter could be spoofed, the receiving endpoint ought to check the
value against an authoritative source such as a user directory.  Clients can
integrity protect and encrypt this header field using end-to-end mechanisms
such as S/MIME or hop-by-hop mechanisms such as Transport Layer Security (TLS).</t>
      <t>This specification provides a new way to correlate otherwise possibly unconnected identifiers.  Because such correlations can be privacy sensitive, user agents ought to provide a means for users to control whether or not these values are sent.</t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document defines and registers a new predefined value "impp" for
the "purpose" header field parameter of the Call-Info header field.  The IANA
has completed this action by adding this RFC as a reference to the line for the
header field "Call-Info" and parameter name "purpose" in the "Header Field
Parameters and Parameter Values" section of the "Session Initiation Protocol
(SIP) Parameters" registry as follows:</t> 

      <figure>
        <artwork><![CDATA[
  Header Field: Call-Info
  Parameter Name: purpose
  Predefined Values: Yes
  Reference: [RFC3261][RFC5367][RFC6910][RFC6993]
        ]]></artwork>
      </figure>
    </section>

  </middle>

  <back>

    <references title="Normative References">

<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.6120" ?>
    </references>

    <references title="Informative References">

<!--I-D.ivov-xmpp-cusax ID exists-->

<reference anchor="CUSAX"><front><title>CUSAX: Combined Use of
the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence
Protocol (XMPP)</title><author initials="E" surname="Ivov" fullname="Emil
			 Ivov"><organization/></author><author initials="P"
							 surname="Saint-Andre"
							 fullname="Peter
							 Saint-Andre"><organization/></author><author
												initials="E"
												surname="Marocco"
												fullname="Enrico
												Marocco"><organization/></author><date
																   month="June"
																   day="5"
																   year="2013"/><abstract><t>This
document describes suggested practices for combined use of the Session
Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol
(XMPP).  Such practices aim to provide a single fully featured real-time
communication service by using complementary subsets of features from each of
the protocols.  Typically such subsets would include telephony capabilities
from SIP and instant messaging and presence capabilities from XMPP.  This
specification does not define any new protocols or syntax for either SIP or
XMPP. However, implementing the practices outlined in this document may require
modifying or at least reconfiguring existing client and server-side software.
Also, it is not the purpose of this document to make recommendations as to
whether or not such combined use should be preferred to the mechanisms provided
natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle).  It
merely aims to provide guidance to those who are interested in such a combined
use.</t></abstract></front><seriesInfo name="Work in"
			     value="Progress"/><format
								 type="TXT" target="http://www.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-06.txt"/></reference>

<reference anchor="XEP-0152">
  <front>
    <title>Reachability Addresses</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
      <organization/>
      <address>
        <email>jhildebr@cisco.com</email>
      </address>
    </author>
    <date day="05" month="February" year="2013"/>
  </front>
  <seriesInfo name="XSF XEP" value="0152"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0152.html"/>
</reference>

    </references>

    <section title="Acknowledgements" anchor="acks">
      <t>Thanks to Gonzalo Camarillo, Keith Drage, Saul Ibarra, Emil Ivov, Cullen Jennings, Olle Johanssen, Paul Kyzivat, Gonzalo Salgueiro, Dean Willis, and Dale Worley for their input.  Elwyn Davies, Salvatore Loreto, Glen Zorn, and Mehmet Ersue completed reviews on behalf of the General Area Review Team, Applications Area Directorate, Security Directorate, and Operations and Management Directorate, respectively.  Stephen Farrell and Pete Resnick provided substantive feedback during IESG review.  Thanks to Yana Stamcheva for her helpful comments and for shepherding the document.</t>
    </section>

  </back>

</rfc>
