GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7840

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7840.txt · Last modified: 2016/05/09 23:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki