doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7840.txt b/doc/rfc/rfc7840.txt
new file mode 100644
index 0000000..fdf9e9a
--- /dev/null
+++ b/doc/rfc/rfc7840.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Winterbottom
+Request for Comments: 7840                   Winterb Consulting Services
+Updates: 5985, 6881                                        H. Tschofenig
+Category: Standards Track
+ISSN: 2070-1721                                                 L. Liess
+                                                        Deutsche Telekom
+                                                                May 2016
+
+
+                    A Routing Request Extension for
+           the HTTP-Enabled Location Delivery (HELD) Protocol
+
+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 HTTP-Enabled Location Delivery (HELD) protocol that
+   updates RFC 5985 to support this function.  Allowing location and
+   routing information to be acquired in a single request response
+   exchange updates RFC 6881, as current location acquisition and route
+   determination procedures are separate operations.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7840.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 1]
+
+RFC 7840                      HELD Routing                      May 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
+   (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  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   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. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 2]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+1.  Introduction
+
+   The general Emergency Context Resolution with Internet Technology
+   (ECRIT) calling models described in [RFC6443] and [RFC6881] require a
+   local Location-to-Service Translation (LoST) server or network of
+   forest guides in order to determine the address of the Public Safety
+   Answering Point (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.
+
+   To address regulatory requirements, such as [M493], evolving
+   architectures in Europe couple location and routing information in
+   the access network while 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 encompasses 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.         Standards Track                    [Page 3]
+
+RFC 7840                      HELD Routing                      May 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 LIS using HELD [RFC5985] with identity extensions
+   [RFC6155] [RFC6915] and then determines 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.         Standards Track                    [Page 4]
+
+RFC 7840                      HELD Routing                      May 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 to be little interest from the public sector in
+   establishing a global forest-guide network.  These issues pose
+   threats to the ability of both the device-centric and the softswitch-
+   centric calling approaches to operate 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.  This 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.         Standards Track                    [Page 5]
+
+RFC 7840                      HELD Routing                      May 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.  This service MUST exist in the IANA "Service URN
+   Labels" repository created by [RFC5031].  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 the location information in the normal manner.
+
+   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].
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 6]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+   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
+   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 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
+   Location Configuration Protocol (LCP) such that "the request MUST
+   include the requestRoutingInformation element."  The remainder of the
+   requirement remains unchanged.
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 7]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+   This document adds a new requirement to Section 7 of [RFC6881].
+
+   "ED-51a : Endpoints MUST support the HELD requestRoutingInformation
+   element 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">
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 8]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+             <xs:sequence>
+                <xs:element name="dest" type="xs:anyURI"
+                     maxOccurs="unbounded"/>
+                <xs:any namespace="##other" processContents="lax"
+                       minOccurs="0" maxOccurs="unbounded"/>
+             </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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 9]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+7.  Examples
+
+   Figure 3 illustrates a <locationRequest> example that contains IP
+   flow information in the request.
+
+   <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.         Standards Track                   [Page 10]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+   Figure 4 illustrates the <locationResponse> message containing two
+   location URIs: an 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.         Standards Track                   [Page 11]
+
+RFC 7840                      HELD Routing                      May 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 LCP by enabling authorized
+   third parties to acquire location information and describing 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.         Standards Track                   [Page 12]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+10.  IANA Considerations
+
+10.1.  URN Sub-Namespace Registration for
+       'urn:ietf:params:xml:ns:geopriv:held:ri'
+
+   Per this document, IANA has registered a new XML namespace, following
+   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>
+      <p>See <a href="http://www.rfc-editor.org/rfc/rfc7840.txt">
+         RFC 7840</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).
+
+   XML:  The XML for this schema can be found as the entirety of
+      Section 6 of this document.
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 13]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+11.  References
+
+11.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>.
+
+11.2.  Informative References
+
+   [M493]     European Telecommunications Standards Institute,
+              "Functional architecture to support European requirements
+              on emergency caller location determination and transport",
+              ES 203 178,  V1.1.1, February 2015.
+
+   [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>.
+
+   [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>.
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 14]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+   [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>.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 15]
+
+RFC 7840                      HELD Routing                      May 2016
+
+
+Authors' Addresses
+
+   James Winterbottom
+   Winterb Consulting Services
+   Gwynneville, NSW  2500
+   Australia
+
+   Phone: +61 448 266004
+   Email: a.james.winterbottom@gmail.com
+
+
+   Hannes Tschofenig
+   Hall 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.         Standards Track                   [Page 16]
+