summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7840.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7840.txt')
-rw-r--r--doc/rfc/rfc7840.txt899
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]
+