Skip to main content

A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol
draft-ietf-ecrit-held-routing-05

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7840.
Authors James Winterbottom , Hannes Tschofenig , Laura Liess
Last updated 2016-05-09 (Latest revision 2016-02-09)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Roger Marshall
Shepherd write-up Show Last changed 2015-10-29
IESG IESG state Became RFC 7840 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Alissa Cooper
Send notices to "Roger Marshall" <rmarshall@telecomsys.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
draft-ietf-ecrit-held-routing-05
ECRIT                                                    J. Winterbottom
Internet-Draft                               Winterb Consulting Services
Updates: 6881, 5985 (if approved)                          H. Tschofenig
Intended status: Standards Track
Expires: August 12, 2016                                        L. Liess
                                                        Deutsche Telekom
                                                        February 9, 2016

           A Routing Request Extension for the HELD Protocol
                  draft-ietf-ecrit-held-routing-05.txt

Abstract

   For cases where location servers have access to emergency routing
   information they are able to return routing information with the
   location information if the location request includes a request for
   the desired routing information.  This document specifies an
   extension to the HELD protocol that updates RFC5985, to support this
   funciton.  Allowing location and routing information to be acquired
   in a single request response exchange updates RFC6881, as current
   location acquisition and route determination procedures are separate
   operations.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 12, 2016.

Copyright Notice

   Copyright (c) 2016 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

Winterbottom, et al.     Expires August 12, 2016                [Page 1]
Internet-Draft                HELD Routing                 February 2016

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  LoST Reuse Considerations . . . . . . . . . . . . . . . .   6
   4.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Modification to Phone BCP . . . . . . . . . . . . . . . . . .   7
   6.  HELD Schema Extension . . . . . . . . . . . . . . . . . . . .   8
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  URN sub-namespace registration for
            'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . .  13
     10.2.  XML Schema Registration  . . . . . . . . . . . . . . . .  13
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

Winterbottom, et al.     Expires August 12, 2016                [Page 2]
Internet-Draft                HELD Routing                 February 2016

1.  Introduction

   The general ECRIT calling models described in [RFC6443] and
   [RFC6881]require a local LoST server or network of forest guides in
   order to determine the address of the PSAP in the best position to
   handle a call.  Networks of forest guides have not materialized and
   while PSAPs are moving towards IP networks, LoST server deployment is
   not ubiquitous.  Some regions and countries have expressed reluctance
   to deploy LoST servers making aspects of the current ECRIT
   architecture hard to realize.

   Evolving architectures in Europe to address regulatory requirements,
   such as [M493], couple location and routing information in the access
   network whilst using a softswitch-centric approach to emergency call
   processing.  This document describes an extension to the HELD
   protocol [RFC5985] so that a location information server can provide
   emergency routing information in the absence of a LoST server or
   network of forest guides.

2.  Terminology

   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].

   The terms Location Information Server (LIS), Emergency Services
   Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety
   Answering Point (PSAP) are used as defined in [RFC6443].

   The term "Access Network Provider" is used as defined in [RFC5687]
   and incompasses both the Internet Access Provider (IAP) and Internet
   Service Provider (ISP).

   The term "Forest Guide" is used as defined in [RFC5582].

3.  Motivation

   The Internet emergency calling architecture specified in [RFC6881]
   describes two main models for emergency call processing.  The first
   is a device-centric model, where a device obtains location
   information using a location configuration protocol, such as HELD
   [RFC5985], and then proceeds to determine the address of the next hop
   closer to the local PSAP using LoST [RFC5222].  Figure 1 shows this
   model in a simplified form.

Winterbottom, et al.     Expires August 12, 2016                [Page 3]
Internet-Draft                HELD Routing                 February 2016

        +---Location Request---+
        |         (1)          |
    +---+----+             +---V---+
    |        |<--Location--|  LIS  |
    | Caller |    (2)      +-------+             +--------+
    |        |                                   | ESRP/  |
    |        |----Find Service-------+           |  PSAP  |
    +------^-+     (3)               |           +--------+
       |   |                +--------V----+          ^
       |   +-----Service----| LoST Server |          |
       |         (4)        +-------------+      +---+---+
       +-------------Call Initiation------------>|  VSP  |
                        (5)                      +-------+

             Figure 1: Device-Centric Emergency Services Model

   The second approach is a softswitch-centric model, where a device
   initiates an emergency call and the serving softswitch detects that
   the call is an emergency and initiates retrieving the caller's
   location from a Location Information Server (LIS) using HELD
   [RFC5985] with identity extensions [RFC6155] [RFC6915] and then
   determining the route to the local PSAP using LoST [RFC5222].
   Figure 2 shows the high-level protocol interactions.

                               +---Location Request---+
                               |         (2)          |
                           +---V---+                  |
                           |  LIS  |                  |
                           +----+--+             +----+----+
                                |                |         |
                                +----Location--->|  Soft   |
    +--------+                          (3)      | Switch  |
    | Caller |------Call Initiation------------> |         |
    +--------+          (1)                      +-+-^---+-+
                    +-------------+                | |   |
                    | LoST Server |<-Find Service--+ |   |
                    +------+------+     (4)          |   |
                           |                         |   |
                           +----------Service--------+   |
                                       (5)               |
                             +-----------+               |
                             | ESRP/PSAP |<------Call----+
                             +-----------+       (6)

                Figure 2: Softswitch-Centric Calling Model

Winterbottom, et al.     Expires August 12, 2016                [Page 4]
Internet-Draft                HELD Routing                 February 2016

   In the softswitch-centric model when a VSP receives an emergency call
   it performs two tasks.  The first task is to determine the correct
   LIS to ask for location information, this is done using a combination
   of reverse DNS lookup described in [RFC7216] to acquire the serving
   domain name and then using [RFC5986] to determine the LIS URI.  Once
   the location is obtained from the LIS, the VSP determines the LoST
   server associated with the domain serving the caller and queries it
   for the correct PSAP address.

   LoST server discovery is a domain based activity, similar to the LIS
   discovery technique.  However, unlike the LIS that is a domain bound
   service, a LoST server is a geographically bound service.  This means
   that for a domain that spans multiple geographic regions the LoST
   server determined may not be able to provide a route to the necessary
   PSAP.  When this occurs, the contacted LoST server invokes the help
   of other LoST servers and this requires the deployment of forest
   guides.

   At the time of writing, several countries have expressed a reluctance
   to deploy public LoST servers.  In countries amenable to the use of
   LoST and forest guides no public forest guides have been deployed.
   There appears little interest from the public sector in establishing
   a global forest guide network.  These issues pose threats to both the
   device-centric and the softswitch-centric calling approaches in terms
   of them operating everywhere.

   The device-centric and softswitch-centric calling models both involve
   the notion of a LIS bound to the serving access network.  In many
   cases the LIS already knows the destination PSAP URI for any given
   location.  In [RFC6881] for example, the LIS validates civic
   locations using a location validation procedure based on the LoST
   protocol [RFC5222].  The LoST validation request is similar to a LoST
   routing request and provides the LIS with the same PSAP routing
   information that a routing request would.  In other cases, the LIS
   knows the correct PSAP for a given location at provisioning time, or
   the access network might always route to the same emergency provider.
   Irrespective of the way in which the LIS learns the PSAP URI for a
   location, the LIS will, in a great many cases, already have this
   information.

   This document specifies an extension to the HELD protocol so that
   emergency routing information can be requested from the LIS at the
   same time that location information is requested.  The document
   updates [RFC6881] by requiring devices and softswitches that
   understand this specification to always request routing information
   to avoid the risk of query failure where no LoST server or forest
   guide network is deployed.

Winterbottom, et al.     Expires August 12, 2016                [Page 5]
Internet-Draft                HELD Routing                 February 2016

3.1.  LoST Reuse Considerations

   The LoST Protocol [RFC5222] defines a <mapping> element that
   describes a service region and associated service URLs.  Reusing this
   element from LoST to provide the routing URIs was considered.
   However, this would have meant that several of the mandatory
   components in the <mapping> element would have had to contain
   ambiguous or misleading values.  Specifically, the "source" attribute
   is required to contain a LoST application unique string for the
   authoritative server.  However, in the situations described in this
   specification there may not be an authoritative LoST server, so any
   value put into this attribute would be misleading.  In addition to
   this, routing information received in the manner described in this
   specification should not be cached by the receiver, so detailing when
   the routing information expires or was last updated is irrelevant.

4.  Mechanism

   The mechanism consists of adding an element to the HELD
   locationRequest and an element to the locationResponse.

   The request element indicates that the requestor wants the LIS to
   provide routing information based on the location of the end-device.
   If the routing request is sent with no attribute then URIs for
   urn:service:sos are returned.  If the requestor wants routing
   information for a specific service then they may include an optional
   service URN.  If a service is specified, and the LIS does not
   understand the requested service then URIs for urn:service:sos are
   returned.

   If the LIS understands the routing request and has routing
   information for the location then it includes the information in a
   routingInformation element returned in the locationResponse.  How the
   LIS obtains this information is left to implementation.
   Possibilities are described in Section 3.

   A LIS that does not understand the routing request element ignores it
   and returns location as normal.

   A LIS that does support the routing request element MUST support
   returning URIs for urn:service:sos and any regionally defined sub-
   services while following the URN traversal rules defined in
   [RFC5031].

   A LIS that does understand the routing request element but can't
   obtain any routing information for the end-device's location MUST set
   the defaultRoute attribute to true and return a default PSAP or

Winterbottom, et al.     Expires August 12, 2016                [Page 6]
Internet-Draft                HELD Routing                 February 2016

   gateway URI along with the determined location information in the
   locationResponse.

   A LIS that understands the routing request element but not the
   specified service URN, MUST follow the URN traversal rules defined in
   [RFC5031].

   A LIS that receives a request for emergency routing information that
   it understands MUST return the correct emergency routing information
   if it has or is able to acquire the routing information for the
   location of the target device.

   The routing information in the location response consists of a
   service element identified by a service name.  The service name is a
   URN and might contain a general emergency service URN such as
   urn:service:sos or might contain a specific service URN depending on
   what was requested and what the LIS is able to provide.  A list of
   one or more service destinations is provided for the service name.
   Each destination is expressed as a URI and each URI scheme should
   only appear once in this list.  The routing URIs are intended to be
   used at the time they are received.  To avoid any risks of using
   stale routing URIs the values MUST NOT be cached by the receiving
   entity.

5.  Modification to Phone BCP

   This section describes the normative updates to Phone BCP [RFC6881].

   It is important for devices and intermediaries to take all steps
   possible to ensure that emergency calls are routed to the correct
   PSAP.  An alternative to providing routing information via global
   forest guides or local LoST servers is for local networks to
   configure the PSAP address information in the network location
   server.  This specification updates Phone BCP [RFC6881] to provide
   this option.  The update requires devices and intermediaries using
   the HELD protocol to always include the HELD routing extension.  If
   the LIS is configured with the routing information it can provide it,
   if it is not then the device or intermediary tries LoST to acquire
   the PSAP URI.

   Section 6.5 of [RFC6881] defines "End System Location Configuration".
   Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the
   LCP such that "the request MUST include the requestRoutingInformation
   element".  The remainder of the requirement remains unchanged.

   This document adds a new requirement to Section 7 of [RFC6881].

Winterbottom, et al.     Expires August 12, 2016                [Page 7]
Internet-Draft                HELD Routing                 February 2016

   "ED-51a : Endpoints MUST support the HELD requestRoutingInformation
   element and be able and be able to interpret and use any routing
   information returned in the locationResponse."

   This document adds two new requirements to Section 8 of [RFC6881].

   "ED-52a : Endpoints that acquire routing information in a HELD
   locationResponse SHOULD use this routing information but MAY perform
   a LoST findService request if they have a location value."

   "ED-52b : Endpoints that acquire routing information in a HELD
   locationResponse with a defaultRoute attribute of true MUST perform a
   LoST findService request if they have a location value.  If a route
   is provided by the LoST server then this route MUST be used,
   otherwise the routing information provided in the HELD response
   SHOULD be used."

   This document amends SP-26 from Section 8 of [RFC6881] such that a
   LoST mapping need not be requested if non-default routing information
   is provided in the HELD locationResponse.

6.  HELD Schema Extension

   This section describes the schema extension to HELD.

   <?xml version="1.0"?>
   <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     elementFormDefault="qualified" attributeFormDefault="unqualified">

     <xs:element name="requestRoutingInformation">
        <xs:complexType name="empty">
           <xs:attribute name="service" type="xs:anyUri"
               use="optional" default="urn:service:sos"/>
        </xs:complexType>
     </xs:element>

     <xs:complexType name="service">
        <xs:complexContent>
          <xs:restriction base="xs:anyType">
             <xs:sequence>
                <xs:element name="dest" type="xs:anyURI"
                     maxOccurs="unbounded"/>
                <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>

Winterbottom, et al.     Expires August 12, 2016                [Page 8]
Internet-Draft                HELD Routing                 February 2016

             </xs:sequence>
             <xs:attribute name="defaultRoute" type="xs:boolean"
                           use="optional" default="false"/>
             <xs:attribute name="serviceUri" type="xs:anyURI"
                           use="required"/>
             <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:restriction>
        </xs:complexContent>
     </xs:complexType>

     <xs:element name="routingInformation" type="ri:riType"/>

     <xs:complexType name="riType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="service" type="ri:service"/>
             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

   </xs:schema>

7.  Examples

   Figure 3 illustrates a <locationRequest> example that contains IP
   flow information in the request.

Winterbottom, et al.     Expires August 12, 2016                [Page 9]
Internet-Draft                HELD Routing                 February 2016

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    responseTime="emergencyRouting">

     <requestRoutingInformation
        xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>

     <flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
               layer4="tcp" layer3="ipv4">
       <src>
         <address>192.0.2.12</address>
         <port>1024</port>
       </src>
       <dst>
         <address>192.0.2.195</address>
         <port>80</port>
       </dst>
     </flow>
   </locationRequest>

                    Figure 3: Example Location Request.

Winterbottom, et al.     Expires August 12, 2016               [Page 10]
Internet-Draft                HELD Routing                 February 2016

   Figure 4 illustrates the <locationResponse> message containing two
   location URIs: a HTTPS and a SIP URI.  Additionally, the response
   contains routing information.

   <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
     <locationUriSet expires="2006-01-01T13:00:00.0Z">
       <locationURI>
                   https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
           </locationURI>
       <locationURI>
                   sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
       </locationURI>
     </locationUriSet>

     <routingInformation
         xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
       <service serviceUri="urn:service:sos">
         <dest>sip:112@example.com</dest>
         <dest>sips:112@example.com</dest>
         <dest>xmpp:112@example.com</dest>
       </service>
     </routingInformation>

   </locationResponse>

                    Figure 4: Example Location Response

Winterbottom, et al.     Expires August 12, 2016               [Page 11]
Internet-Draft                HELD Routing                 February 2016

   Figure 5 illustrates the <locationResponse> message containing
   default routing information and an HTTPS location URI.

   <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
      <locationUriSet expires="2016-01-01T13:00:00.0Z">
         <locationURI>
                https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
             </locationURI>
      </locationUriSet>

      <routingInformation
             xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
         <service defaultRoute="true" serviceUri="urn:service:sos">
            <dest>sip:112@example.com</dest>
            <dest>sips:112@example.com</dest>
            <dest>xmpp:112@example.com</dest>
         </service>
      </routingInformation>

   </locationResponse>

   Figure 5: Example Location Response with default routing information

8.  Privacy Considerations

   This document makes no changes that require privacy considerations
   beyond those already described in [RFC5985].  It does however extend
   those described in [RFC6155].

   [RFC5985] describes the privacy considerations surrounding the HELD
   location configuration protocol, and this document makes no specific
   changes to these considerations.

   [RFC6155] extends HELD beyond a simple location configuration
   protocol (LCP) by enabling authorized third-parties to acquire
   location information and describes the issues in Section 4.  The HELD
   Routing extension supports returning URIs that represent specific
   services operating in the Target's vicinity.  This represents
   additional information about the Target, as a consequence it is
   recommended that this option only be used when the LIS returns a
   location URI, not a location value.

9.  Security Considerations

   This document imposes no additional security considerations beyond
   those already described in [RFC5985] and [RFC6155].

Winterbottom, et al.     Expires August 12, 2016               [Page 12]
Internet-Draft                HELD Routing                 February 2016

10.  IANA Considerations

10.1.  URN sub-namespace registration for
       'urn:ietf:params:xml:ns:geopriv:held:ri'

   This document calls for IANA to register a new XML namespace, as per
   the guidelines in [RFC3688].

   URI:  urn:ietf:params:xml:ns:geopriv:held:ri

   Registrant Contact:  IETF, ECRIT working group (ecrit@ietf.org),
      James Winterbottom (a.james.winterbottom@gmail.com).

   XML:

   BEGIN
    <?xml version="1.0"?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
     <head>
       <title>HELD Routing Information Extensions</title>
     </head>
     <body>
      <h1>Additional Element for HELD Routing Information</h1>
      <h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
      [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
        with the RFC number for this specification.]]
      <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
     </body>
    </html>
   END

10.2.  XML Schema Registration

   This section registers an XML schema as per the procedures in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:geopriv:held:ri

   Registrant Contact:  IETF, ECRIT working group, (ecrit@ietf.org),
      James Winterbottom (a.james.winterbottom@gmail.com).

      The XML for this schema can be found as the entirety of Section 6
      of this document.

Winterbottom, et al.     Expires August 12, 2016               [Page 13]
Internet-Draft                HELD Routing                 February 2016

11.  Acknowledgements

   We would like to thank Wilfried Lange for sharing his views with us.
   We would also like to thank Bruno Chatras for his early review
   comments and Keith Drage for his more detailed review.  Thanks to
   Roger Marshall and Randy Gellens for their helpful suggestions.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5985]  Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
              RFC 5985, DOI 10.17487/RFC5985, September 2010,
              <http://www.rfc-editor.org/info/rfc5985>.

   [RFC6881]  Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in Support of Emergency Calling",
              BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
              <http://www.rfc-editor.org/info/rfc6881>.

12.2.  Informative References

   [M493]     European Telecommunications Standards Institute,
              "Functional architecture to support European requirements
              on emergency caller location determination and transport",
              ES 203 178, V 1.0.5, December 2014.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <http://www.rfc-editor.org/info/rfc3688>.

   [RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", RFC 5031,
              DOI 10.17487/RFC5031, January 2008,
              <http://www.rfc-editor.org/info/rfc5031>.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
              <http://www.rfc-editor.org/info/rfc5222>.

Winterbottom, et al.     Expires August 12, 2016               [Page 14]
Internet-Draft                HELD Routing                 February 2016

   [RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
              Framework", RFC 5582, DOI 10.17487/RFC5582, September
              2009, <http://www.rfc-editor.org/info/rfc5582>.

   [RFC5687]  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol: Problem Statement and
              Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010,
              <http://www.rfc-editor.org/info/rfc5687>.

   [RFC5986]  Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)", RFC 5986,
              DOI 10.17487/RFC5986, September 2010,
              <http://www.rfc-editor.org/info/rfc5986>.

   [RFC6155]  Winterbottom, J., Thomson, M., Tschofenig, H., and R.
              Barnes, "Use of Device Identity in HTTP-Enabled Location
              Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March
              2011, <http://www.rfc-editor.org/info/rfc6155>.

   [RFC6443]  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling Using Internet
              Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
              2011, <http://www.rfc-editor.org/info/rfc6443>.

   [RFC6915]  Bellis, R., "Flow Identity Extension for HTTP-Enabled
              Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915,
              April 2013, <http://www.rfc-editor.org/info/rfc6915>.

   [RFC7216]  Thomson, M. and R. Bellis, "Location Information Server
              (LIS) Discovery Using IP Addresses and Reverse DNS",
              RFC 7216, DOI 10.17487/RFC7216, April 2014,
              <http://www.rfc-editor.org/info/rfc7216>.

Authors' Addresses

   James Winterbottom
   Winterb Consulting Services
   Gwynneville, NSW  2500
   AU

   Phone: +61 448 266004
   Email: a.james.winterbottom@gmail.com

Winterbottom, et al.     Expires August 12, 2016               [Page 15]
Internet-Draft                HELD Routing                 February 2016

   Hannes Tschofenig
   Halls in Tirol  6060
   Austria

   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

   Laura Liess
   Deutsche Telekom Networks
   Deutsche Telekom Allee 7
   Darmstadt, Hessen  64295
   Germany

   Email: L.Liess@telekom.de
   URI:   http://www.telekom.de

Winterbottom, et al.     Expires August 12, 2016               [Page 16]