<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="std" ipr="trust200902" docName="draft-tschofenig-ecrit-xmpp-es-00.txt">
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc compact="no" ?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <front>
    <title abbrev="XMPP Emergency Services">Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP)</title>
   
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>    
    <date year="2012"/>
    <area>RAI</area>
    <workgroup>ECRIT</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>Emergency Services</keyword>
    <keyword>XMPP</keyword>
    <abstract>
      <t>The Extensible Messaging and Presence Protocol (XMPP) is a technology that enjoys widespread deployment in the instant messaging application domain. While many features for XMPP had been standardized in the IETF as well as in the XMPP Standards Foundation emergency services functionality was not part of it.</t>
      <t>This document aims to initiate a discussion about the necessary emergency services functionality for XMPP.</t>
    </abstract>
  </front>
  <middle>

    <!-- ******************************************************************************* -->
    <section anchor="introduction" title="Introduction">
    
    <t>The Extensible Messaging and Presence Protocol (XMPP) is a technology for real-time communication over the Internet that uses the 
    Extensible Markup Language (XML) as the base format for exchanging information. XMPP provides a way to send small 
    snippets of XML from one communication entity to another one. XMPP has found usage in a variety of protocols, but 
    most people use it primarily for instant messaging.</t> 
    
    <t>With the widespread usage of XMPP on the Internet for instant messaging and the desire to offer multi-media emergency services support, i.e., any form of emergency support that goes beyond voice calling, a frequently asked question is 
    those applications that utilize XMPP today are able to offer emergency services support similar to what had been 
    standardized for the Session Initiation Protocol (SIP) over the last 10 years.</t>
    
    
    <t>XMPP has found widespread usage for instant messaging on the Internet. At the same time there is an increasing interest 
    to add multi-media support to the emergency services portfolio. Consequently, a frequently asked question by emergency services professionals is whether applications utilizing XMPP today will be able to offer emergency services support in the future as well. Standardization activities have so far exclusively focused on the Session Initiation Protocol (SIP).</t>
    

    <t>The author believes that it is time to have a discussion about the desired level of interoperability between XMPP 
    and the standardized, implemented and even deployed IP-based emergency services infrastructure that is based on SIP. This document provides a first discussion input. The main part of the document focuses on the various components of the emergency services functionality.</t> 

        
         </section>

    <!-- ******************************************************************************* -->

    <section title="Terminology">
      <t> 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 <xref target="RFC2119">RFC 2119</xref>.</t>
        
        <t>This document uses the terminology defined in <xref target="RFC5012"/>.</t>
    </section>

    <!-- ******************************************************************************* -->

    <section title="Interoperability Need"> 
       
       <t>When deciding about the required emergency services functionality in XMPP a decision has to be made 
       about where to put the burden for interoperability. There 
       only seem to be two main options, which are graphically shown in <xref target="backend-interop"/> and 
       <xref target="e2e-interop"/>.</t>
              
        <t>In <xref target="backend-interop"/> the XMPP is used between the XMPP client and a XMPP server run by some provider. 
        Whenever the interaction with the emergency services authorities are needed a gateway translates XMPP to SIP very similar to how legacy protocols or proprietary protocols are translated. While the exact placement placement of the XMPP-to-SIP gateway does not matter from a protocol point of view deployment-wise it does. Here we assume that the emergency services 
        infrastructure only supports a single protocol internally, namely SIP. This is also inline with the current standardization situation.</t> 
        <t>
          <figure anchor="backend-interop" title="Backend Interoperability">
            <artwork>
              <![CDATA[
                                         ,-------.
                                       ,'IP-based `.
                 .-----------.        /  Emergency  \
 +------+ XMPP   |  Provider |       |   Services    |
 |XMPP  |------->| .-------  |       |   Network     |
 |Client|        | |XMPP   | |       |               |
 +------+        | |Server | |       |   +------+    |
                 | '-------' |       |   |PSAP  |    |
                 |     |     |       |   +--+---+    |
                 | .---+---. |       |      |        |
                 '-|Gateway|-'       |      |        |
                   '---+---'         |      |SIP     |
                       |             |      |        |
                       |SIP          |      |        |
                       |             |      |        |
                       |             |   +--+---+    |
                       +-------------+-->|ESRP  |    |
                                     |   +------+    |
                                     |               |
                                      \             /
                                       `.         ,'
                                         '-------'           
                                         ]]></artwork>
          </figure>
        </t>
    <t>The interworking between SIP and XMPP had been subject to earlier investigations, as described in <xref target="I-D.saintandre-sip-xmpp-core"/>, <xref target="I-D.saintandre-sip-xmpp-media"/>, and <xref target="I-D.saintandre-sip-xmpp-im"/>.
    </t> 

<t>In <xref target="e2e-interop"/> we show a deployment where XMPP is used 
end-to-end and the emergency services supports XMPP in addition to SIP.</t>
<t>
          <figure anchor="e2e-interop" title="End-to-End Interoperability">
            <artwork>
              <![CDATA[
                                         ,-------.
                                       ,'IP-based `.
                                      /  Emergency  \
                 .-----------.       |   Services    |
                 |  Provider |       |   Network     |
 +------+        | .-------. |       |               |
 |XMPP  | XMPP   | |XMPP   | |       |   +------+    |
 |Client|------->| |Server | |       |   |PSAP  |    |
 +------+        | '-------' |       |   +--+---+    |
                 |    |      |       |      |        |
                 '----+------'       |      |        |
                      |              |      |XMPP    |
                      |              |      |        |
                      |XMPP          |      |        |
                      |              |      |        |
 +------+             |              |   +--+---+    |
 |XMPP  |  XMPP       +--------------+-->|ESRP  |    |
 |Client|----------------------------+-->|      |    |
 +------+                            |   +------+    |
                                      \             /
                                       `.         ,'
                                         '-------'                              
           ]]></artwork>
          </figure>
        </t>
        
    <t>Not shown in the figures above is the ability for combined SIP and XMPP usage. Requirements for 
    such interworking are described in  
    <xref target="I-D.veikkolainen-sip-xmpp-coex-reqs"/> and guidance is provided in <xref target="I-D.veikkolainen-sip-voip-xmpp-im"/>.</t>
    
    </section> 

    <!-- ******************************************************************************* -->

    <section title="Functionality">
      <t>An important aspect in the support of emergency services in XMPP is how far current XMPP features are equivalent to those offered by SIP. For SIP <xref target="I-D.ietf-ecrit-phonebcp"/> describes the necessary functionality for emergency calling on the Internet. A similar specification is needed for XMPP. <xref target="I-D.ietf-ecrit-phonebcp"/>, however, relies on already defined functionality and 'glues' these available building blocks together. The sub-sections below discuss some of the most important building blocks.</t>

      <section title="Emergency Call Marking"> 
      <t>In existing telecommunications systems, there are many well-known
   communication and information services that are characterized by long-term stability of user-
   visible identifiers, decentralized administration of the underlying
   service, and a well-defined resolution or mapping mechanism. <xref target="RFC5031"/> defines a URN namespace that, together with
   resolution protocols, allows us to
   define global, well-known services, while distributing the
   actual implementation across a large number of service-providing
   entities.</t>
   <t><xref target="RFC5031"/> is not only used for marking SIP communication but it is also used by various emergency components, such as the Location-to-Service Translation (LoST) protocol. <xref target="RFC5031"/> also has to be integrated into XMPP.</t> 
   
   <t>Part of the emergency call marking is also the ability to indicate a test emergency call, as described in Section 15 of <xref target="I-D.ietf-ecrit-phonebcp"/>. An equivalent feature is highly likely to be useful for XMPP.</t>
      </section> 

      
      <section title="Location"> 
       <t>The IETF has produced a fairly extensive set of location specifications that are re-used for emergency services. The work falls into various categories, as described in <xref target="RFC6280"/> and in Section 6 of <xref target="RFC6443"/>. The requirements for obtaining high accuracy location information are more complex for emergency services than with commercial location applications due to the life critical nature of the service.</t>
       <t>
         <list style="hanging"> 
         
         <t hangText="Location Formats:"><vspace blankLines="1"/>
         There are two main formats standardized for location information, namely civic and geodetic location information. The core civic location standard can be found in <xref target="RFC5139"/> and the profile for geodetic information is available with <xref target="RFC5491"/>. <xref target="RFC5491"/> supports a large set of location shapes. Various additional extensions have been developed, such as the support for relative location <xref target="I-D.ietf-geopriv-relative-location"/> and location civic addresses <xref target="I-D.ietf-geopriv-local-civic"/>. It is also important to mention that there have been efforts ongoing to map the civic addresses in various countries to the PIDF-LO civic location tokens, based on the recommendations in <xref target="RFC5774"/>.</t>
         

         <t hangText="Location Encoding:"><vspace blankLines="1"/>
         There are mainly two encodings of location information, namely a binary encoding, as for example used by DHCP location extensions, and an XML-based encoding based on PIDF-LO <xref target="RFC4119"/>. Note that the PIDF-LO element contains more than pure location data but also provides information about the entity that constructed the location object (based on the 'provided-by' element) and supplementary data about the utilized location determination technique (based on values from the 'method' token' IANA registry).</t>
         
         <t hangText="Location Configuration Protocols:"> <vspace blankLines="1"/>
         A Location Configuration Protocol (LCP) <xref target="RFC5687"/> is one mechanism that can be used by a device to discover its own location from a LIS.  Several LCPs have been
   developed within Geopriv, such as <xref target="RFC5985"/>. LCPs obtain location information from location servers and are therefore indirectly relevant for location conveyed within XMPP.</t>
   
         <t hangText="Location Derefencing:"><vspace blankLines="1"/>
         For location derefencing two protocols have been defined, namely one based on HTTP <xref target="I-D.ietf-geopriv-deref-protocol"/> and another one based on SIP which may use filters to reduce the number of asynchronous notifications <xref target="RFC6447"/>. A session setup protocol has to support the ability to convey these references. </t>
         
         <t hangText="Location Conveyance:"> <vspace blankLines="1"/>
         The ability to convey a PIDF-LO and a location by reference in SIP had been defined by <xref target="RFC6442"/>. For a single call there may be more than one location object in a call.</t>
         </list> 
     </t>
     
     <t>While there is a location extensions available in XMPP with XEP-0080 <xref target="XEP-0080"/> it is not equivalent to the functionality listed above.  XEP-0080 offers a different civic location format and geodetic location based on a reduced set of loation shapes. It uses an XML encoding and allows this information to be conveyed in XMPP. A table with a mapping to the PIDF-LO semantic is provided in XEP-0080 but unfortunately since the functionality is not equivalent to the list presented above there will be a loss of information during the lifecyle of location handling in most of the scenarios.</t> 
       
      </section> 
      
      <section title="Routing"> 
      <t>The LoST protocol <xref target="RFC5222"/> offers the ability to discover service contact URIs based on provided  service identifiers and location information.  In particular, it can be used to determine the
   location-appropriate Public Safety Answering Point (PSAP) for
   emergency services. During the design of LoST it was already anticipated that service contact URIs based on a variety of different protocols (not only SIP) will be needed. As such, XMPP is seamlessly supported by LoST.</t>
      </section> 
      
      <section title="Voice and Video"> 
       <t>With XEP-0166 <xref target="XEP-0166"/> the ability to initiate and manage peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards had been defined. The protocol enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat).</t>
       
       <t>The ability for voice and video conference bridge as needed by persons with disabilities for sign-language interpretation is, however, not offered by Jingle.</t>
       
       </section> 
      
      <section title="Real-Time Text"> 
        <t>RFC 5194 <xref target="RFC5194"/> defines the framework for Real-Time Text over IP. All
   required functionality is based on SIP and
   the Real-Time Transport Protocol (RTP).</t>
   
   <t>XEP-0301 <xref target="XEP-0301"/> seems to offer functionality that is similar to what had been defined by RFC 5194.</t>
      </section> 
      
      <section title="PSAP Callback"> 
      <t>After an emergency call is completed it is possible
   that the call-taker feels the need for further communication.  For
   example, the call may have been dropped by accident without the call-
   taker having sufficient information about the current situation of a
   wounded person.  A call-taker may trigger a callback towards the
   emergency caller using the contact informationprovided with the
   initial emergency call, which includes the GRUU as well as the Address-of-Record.  
   This callback would be treated like any other call and as a consequence it
   may get blocked by authorization policies or may get forwarded to an
   answering machine.</t>
      <t>The work on PSAP callback <xref target="I-D.ietf-ecrit-psap-callback"/> is an ongoing effort to 
      give these calls preferential treatment so that the callback has a higher success in reaching the 
      original emergency call.</t> 
      
      <t>This functionality does not exist for XMPP yet.</t>
      </section> 
      
      <section title="Additional Data"> 
      <t>The Internet Protocol suite offers a rich information 
   exchange and thereby better situational awareness for call takers and first responders. 
   The richness comes in various forms, including the multi-media
   communication capabilities (via voice, video, instant messaging, and
   real-time text), but also via more additional data made available by various actors 
   of the emergency signaling chain.  Sharing information between various actors will enable more
   intelligent decision making and therefore better response in case of
   an emergency.</t>
   <t>In the SIP environment additional data had been provided in various ways, as described in 
   <xref target="I-D.ietf-ecrit-additional-data"/>, and the same capabilities will have to be provided 
   in XMPP as well.</t>
      </section> 
      
      <section title="Data Only Emergency Calls"> 
      <t>Data-only emergency calls are similar to regular emergency
   calls in the sense that they require emergency call routing
   functionality and may even have the same location requirements.  On
   the other hand, the communication interaction occurs without
   establishment of a voice or video channel.</t>
      
   <t>As a technical mechanism a Common Alert Protocol (CAP) payload is pushed by the 
   SIP User Agent towards the PSAP, as described in <xref target="I-D.ietf-ecrit-data-only-ea"/>. 
   The ability to push CAP payloads is also available in XMPP with XEP-0127 <xref target="XEP-0127"/>.</t>
      </section> 
    </section>


    <!-- ******************************************************************************* -->

    <section title="Security Considerations">
      <t>This document focuses on the integration of emergency services functionality into XMPP. Offering security features for emergency calls is both important but also challenging as security failures (such as expired certificates) may have fatal effects. SIP offers a secure identity mechanism as well as media security. Functionality for these two areas are specified in <xref target="I-D.ietf-ecrit-phonebcp"/>. Offering a solid mechanisms for identification of the persons seeking help is important for the overal security of the emergency services system, as described in <xref target="I-D.ietf-ecrit-trustworthy-location"/>. </t>
    </section>

    <!-- ******************************************************************************* -->

    <section title="Acknowledgements">
      <t>The author would like to thank the members of the European Emergency Number Association (EENA) Next Generation 112 technical committee and the National Emergency Number Association (NENA) Long-Term Definition working group for their discussions around XMPP emergency services support.</t>
    </section>

    <!-- ******************************************************************************* -->

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.5012" ?>
      <?rfc include="reference.RFC.5194" ?>
      <?rfc include="reference.RFC.5222" ?>
      
      <?rfc include="reference.RFC.5031" ?>
      <?rfc include="reference.RFC.6443" ?>
      <?rfc include="reference.RFC.5491" ?>
      <?rfc include="reference.RFC.5139" ?>
      <?rfc include="reference.RFC.5774" ?>
      <?rfc include="reference.RFC.4119" ?>
      <?rfc include="reference.RFC.5687" ?>
      <?rfc include="reference.RFC.5985" ?>
      <?rfc include="reference.RFC.6447" ?>
      <?rfc include="reference.RFC.6442" ?>
      <?rfc include="reference.RFC.6280" ?>

      
           
      <?rfc include="reference.I-D.ietf-ecrit-data-only-ea"?>
      <?rfc include="reference.I-D.ietf-ecrit-phonebcp"?>
      <?rfc include="reference.I-D.ietf-ecrit-additional-data"?>
      <?rfc include="reference.I-D.ietf-ecrit-psap-callback"?>
      <?rfc include="reference.I-D.ietf-geopriv-local-civic"?>
      <?rfc include="reference.I-D.ietf-geopriv-relative-location"?>
      <?rfc include="reference.I-D.ietf-geopriv-deref-protocol"?>
      
      
        
      
           

    </references>
    <references title="Informational References">
      <?rfc include="reference.I-D.ietf-ecrit-trustworthy-location"?>
      <?rfc include="reference.I-D.saintandre-sip-xmpp-core"?>
      <?rfc include="reference.I-D.saintandre-sip-xmpp-media"?>
      <?rfc include="reference.I-D.saintandre-sip-xmpp-im"?>
      
      <?rfc include="reference.I-D.veikkolainen-sip-xmpp-coex-reqs"?>
      <?rfc include="reference.I-D.veikkolainen-sip-voip-xmpp-im"?>
      


<reference anchor="XEP-0166">
  <front>
    <title>Jingle</title>
    <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
      <organization/>
      <address>
        <email>scottlu@google.com</email>
      </address>
    </author>
    <author initials="J." surname="Beda" fullname="Joe Beda">
      <organization/>
      <address>
        <email>jbeda@google.com</email>
      </address>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="R." surname="McQueen" fullname="Robert McQueen">
      <organization/>
      <address>
        <email>robert.mcqueen@collabora.co.uk</email>
      </address>
    </author>
    <author initials="S." surname="Egan" fullname="Sean Egan">
      <organization/>
      <address>
        <email>seanegan@google.com</email>
      </address>
    </author>
    <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
      <organization/>
      <address>
        <email>jhildebr@cisco.com</email>
      </address>
    </author>
    <date day="23" month="December" year="2009"/>
  </front>
  <seriesInfo name="XSF XEP" value="0166"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0166.html"/>
</reference>


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


<reference anchor="XEP-0127">
  <front>
    <title>Common Alerting Protocol (CAP) Over XMPP</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="B." surname="Fletcher" fullname="Boyd Fletcher">
      <organization/>
      <address>
        <email>Boyd.Fletcher@je.jfcom.mil</email>
      </address>
    </author>
    <date day="09" month="December" year="2004"/>
  </front>
  <seriesInfo name="XSF XEP" value="0127"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0127.html"/>
</reference>


<reference anchor="XEP-0301">
  <front>
    <title>In-Band Real Time Text</title>
    <author initials="M." surname="Rejhon" fullname="Mark Rejhon">
      <organization/>
      <address>
        <email>mark@realjabber.org</email>
      </address>
    </author>
    <date day="29" month="June" year="2011"/>
  </front>
  <seriesInfo name="XSF XEP" value="0301"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0301.html"/>
</reference>

      
    </references>
   </back>
</rfc>
