draft-ietf-ecrit-held-routing-05.txt   rfc7840.txt 
ECRIT J. Winterbottom Internet Engineering Task Force (IETF) J. Winterbottom
Internet-Draft Winterb Consulting Services Request for Comments: 7840 Winterb Consulting Services
Updates: 6881, 5985 (if approved) H. Tschofenig Updates: 5985, 6881 H. Tschofenig
Intended status: Standards Track Category: Standards Track
Expires: August 12, 2016 L. Liess ISSN: 2070-1721 L. Liess
Deutsche Telekom Deutsche Telekom
February 9, 2016 May 2016
A Routing Request Extension for the HELD Protocol A Routing Request Extension for
draft-ietf-ecrit-held-routing-05.txt the HTTP-Enabled Location Delivery (HELD) Protocol
Abstract Abstract
For cases where location servers have access to emergency routing For cases where location servers have access to emergency routing
information they are able to return routing information with the information, they are able to return routing information with the
location information if the location request includes a request for location information if the location request includes a request for
the desired routing information. This document specifies an the desired routing information. This document specifies an
extension to the HELD protocol that updates RFC5985, to support this extension to the HTTP-Enabled Location Delivery (HELD) protocol that
funciton. Allowing location and routing information to be acquired updates RFC 5985 to support this function. Allowing location and
in a single request response exchange updates RFC6881, as current routing information to be acquired in a single request response
location acquisition and route determination procedures are separate exchange updates RFC 6881, as current location acquisition and route
operations. determination procedures are separate operations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 12, 2016. 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.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6 3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7 5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7
6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. URN sub-namespace registration for 10.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13
10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13 10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The general ECRIT calling models described in [RFC6443] and The general Emergency Context Resolution with Internet Technology
[RFC6881]require a local LoST server or network of forest guides in (ECRIT) calling models described in [RFC6443] and [RFC6881] require a
order to determine the address of the PSAP in the best position to local Location-to-Service Translation (LoST) server or network of
handle a call. Networks of forest guides have not materialized and forest guides in order to determine the address of the Public Safety
while PSAPs are moving towards IP networks, LoST server deployment is Answering Point (PSAP) in the best position to handle a call.
not ubiquitous. Some regions and countries have expressed reluctance Networks of forest guides have not materialized and while PSAPs are
to deploy LoST servers making aspects of the current ECRIT moving towards IP networks, LoST server deployment is not ubiquitous.
architecture hard to realize. 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, To address regulatory requirements, such as [M493], evolving
such as [M493], couple location and routing information in the access architectures in Europe couple location and routing information in
network whilst using a softswitch-centric approach to emergency call the access network while using a softswitch-centric approach to
processing. This document describes an extension to the HELD emergency call processing. This document describes an extension to
protocol [RFC5985] so that a location information server can provide the HELD protocol [RFC5985], so that a location information server
emergency routing information in the absence of a LoST server or can provide emergency routing information in the absence of a LoST
network of forest guides. server or network of forest guides.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The terms Location Information Server (LIS), Emergency Services The terms "Location Information Server (LIS)", "Emergency Services
Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety Routing Proxy (ESRP)", "Voice Service Provider (VSP)", and "Public
Answering Point (PSAP) are used as defined in [RFC6443]. Safety Answering Point (PSAP)" are used as defined in [RFC6443].
The term "Access Network Provider" is used as defined in [RFC5687] The term "Access Network Provider" is used as defined in [RFC5687]
and incompasses both the Internet Access Provider (IAP) and Internet and encompasses both the Internet Access Provider (IAP) and Internet
Service Provider (ISP). Service Provider (ISP).
The term "Forest Guide" is used as defined in [RFC5582]. The term "forest guide" is used as defined in [RFC5582].
3. Motivation 3. Motivation
The Internet emergency calling architecture specified in [RFC6881] The Internet emergency calling architecture specified in [RFC6881]
describes two main models for emergency call processing. The first describes two main models for emergency call processing. The first
is a device-centric model, where a device obtains location is a device-centric model, where a device obtains location
information using a location configuration protocol, such as HELD information using a location configuration protocol, such as HELD
[RFC5985], and then proceeds to determine the address of the next hop [RFC5985], and then proceeds to determine the address of the next hop
closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this
model in a simplified form. model in a simplified form.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
+------^-+ (3) | +--------+ +------^-+ (3) | +--------+
| | +--------V----+ ^ | | +--------V----+ ^
| +-----Service----| LoST Server | | | +-----Service----| LoST Server | |
| (4) +-------------+ +---+---+ | (4) +-------------+ +---+---+
+-------------Call Initiation------------>| VSP | +-------------Call Initiation------------>| VSP |
(5) +-------+ (5) +-------+
Figure 1: Device-Centric Emergency Services Model Figure 1: Device-Centric Emergency Services Model
The second approach is a softswitch-centric model, where a device The second approach is a softswitch-centric model, where a device
initiates an emergency call and the serving softswitch detects that initiates an emergency call, and the serving softswitch detects that
the call is an emergency and initiates retrieving the caller's the call is an emergency and initiates retrieving the caller's
location from a Location Information Server (LIS) using HELD location from a LIS using HELD [RFC5985] with identity extensions
[RFC5985] with identity extensions [RFC6155] [RFC6915] and then [RFC6155] [RFC6915] and then determines the route to the local PSAP
determining the route to the local PSAP using LoST [RFC5222]. using LoST [RFC5222]. Figure 2 shows the high-level protocol
Figure 2 shows the high-level protocol interactions. interactions.
+---Location Request---+ +---Location Request---+
| (2) | | (2) |
+---V---+ | +---V---+ |
| LIS | | | LIS | |
+----+--+ +----+----+ +----+--+ +----+----+
| | | | | |
+----Location--->| Soft | +----Location--->| Soft- |
+--------+ (3) | Switch | +--------+ (3) | switch |
| Caller |------Call Initiation------------> | | | Caller |------Call Initiation------------> | |
+--------+ (1) +-+-^---+-+ +--------+ (1) +-+-^---+-+
+-------------+ | | | +-------------+ | | |
| LoST Server |<-Find Service--+ | | | LoST Server |<-Find Service--+ | |
+------+------+ (4) | | +------+------+ (4) | |
| | | | | |
+----------Service--------+ | +----------Service--------+ |
(5) | (5) |
+-----------+ | +-----------+ |
| ESRP/PSAP |<------Call----+ | ESRP/PSAP |<------Call----+
+-----------+ (6) +-----------+ (6)
Figure 2: Softswitch-Centric Calling Model Figure 2: Softswitch-Centric Calling Model
In the softswitch-centric model when a VSP receives an emergency call In the softswitch-centric model, when a VSP receives an emergency
it performs two tasks. The first task is to determine the correct call, it performs two tasks. The first task is to determine the
LIS to ask for location information, this is done using a combination correct LIS to ask for location information; this is done using a
of reverse DNS lookup described in [RFC7216] to acquire the serving combination of reverse DNS lookup described in [RFC7216] to acquire
domain name and then using [RFC5986] to determine the LIS URI. Once the serving domain name and then using [RFC5986] to determine the LIS
the location is obtained from the LIS, the VSP determines the LoST URI. Once the location is obtained from the LIS, the VSP determines
server associated with the domain serving the caller and queries it the LoST server associated with the domain serving the caller and
for the correct PSAP address. queries it for the correct PSAP address.
LoST server discovery is a domain based activity, similar to the LIS LoST server discovery is a domain-based activity, similar to the LIS
discovery technique. However, unlike the LIS that is a domain bound discovery technique. However, unlike the LIS that is a domain-bound
service, a LoST server is a geographically bound service. This means service, a LoST server is a geographically bound service. This means
that for a domain that spans multiple geographic regions the LoST that for a domain that spans multiple geographic regions, the LoST
server determined may not be able to provide a route to the necessary server determined may not be able to provide a route to the necessary
PSAP. When this occurs, the contacted LoST server invokes the help PSAP. When this occurs, the contacted LoST server invokes the help
of other LoST servers and this requires the deployment of forest of other LoST servers, and this requires the deployment of forest
guides. guides.
At the time of writing, several countries have expressed a reluctance At the time of writing, several countries have expressed a reluctance
to deploy public LoST servers. In countries amenable to the use of to deploy public LoST servers. In countries amenable to the use of
LoST and forest guides no public forest guides have been deployed. LoST and forest guides, no public forest guides have been deployed.
There appears little interest from the public sector in establishing There appears to be little interest from the public sector in
a global forest guide network. These issues pose threats to both the establishing a global forest-guide network. These issues pose
device-centric and the softswitch-centric calling approaches in terms threats to the ability of both the device-centric and the softswitch-
of them operating everywhere. centric calling approaches to operate everywhere.
The device-centric and softswitch-centric calling models both involve The device-centric and softswitch-centric calling models both involve
the notion of a LIS bound to the serving access network. In many 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 cases, the LIS already knows the destination PSAP URI for any given
location. In [RFC6881] for example, the LIS validates civic location. In [RFC6881], for example, the LIS validates civic
locations using a location validation procedure based on the LoST locations using a location validation procedure based on the LoST
protocol [RFC5222]. The LoST validation request is similar to a LoST protocol [RFC5222]. The LoST validation request is similar to a LoST
routing request and provides the LIS with the same PSAP routing routing request and provides the LIS with the same PSAP routing
information that a routing request would. In other cases, the LIS information that a routing request would. In other cases, the LIS
knows the correct PSAP for a given location at provisioning time, or knows the correct PSAP for a given location at provisioning time, or
the access network might always route to the same emergency provider. 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 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 location, the LIS will, in a great many cases, already have this
information. information.
This document specifies an extension to the HELD protocol so that This document specifies an extension to the HELD protocol, so that
emergency routing information can be requested from the LIS at the emergency routing information can be requested from the LIS at the
same time that location information is requested. The document same time that location information is requested. This document
updates [RFC6881] by requiring devices and softswitches that updates [RFC6881] by requiring devices and softswitches that
understand this specification to always request routing information understand this specification to always request routing information
to avoid the risk of query failure where no LoST server or forest to avoid the risk of query failure where no LoST server or forest-
guide network is deployed. guide network is deployed.
3.1. LoST Reuse Considerations 3.1. LoST Reuse Considerations
The LoST Protocol [RFC5222] defines a <mapping> element that The LoST protocol [RFC5222] defines a <mapping> element that
describes a service region and associated service URLs. Reusing this describes a service region and associated service URLs. Reusing this
element from LoST to provide the routing URIs was considered. element from LoST to provide the routing URIs was considered.
However, this would have meant that several of the mandatory However, this would have meant that several of the mandatory
components in the <mapping> element would have had to contain components in the <mapping> element would have had to contain
ambiguous or misleading values. Specifically, the "source" attribute ambiguous or misleading values. Specifically, the "source" attribute
is required to contain a LoST application unique string for the is required to contain a LoST application-unique string for the
authoritative server. However, in the situations described in this authoritative server. However, in the situations described in this
specification there may not be an authoritative LoST server, so any specification, there may not be an authoritative LoST server, so any
value put into this attribute would be misleading. In addition to value put into this attribute would be misleading. In addition to
this, routing information received in the manner described in this this, routing information received in the manner described in this
specification should not be cached by the receiver, so detailing when specification should not be cached by the receiver, so detailing when
the routing information expires or was last updated is irrelevant. the routing information expires or was last updated is irrelevant.
4. Mechanism 4. Mechanism
The mechanism consists of adding an element to the HELD The mechanism consists of adding an element to the HELD
locationRequest and an element to the locationResponse. locationRequest and an element to the locationResponse.
The request element indicates that the requestor wants the LIS to The request element indicates that the requestor wants the LIS to
provide routing information based on the location of the end-device. provide routing information based on the location of the end device.
If the routing request is sent with no attribute then URIs for If the routing request is sent with no attribute, then URIs for
urn:service:sos are returned. If the requestor wants routing urn:service:sos are returned. If the requestor wants routing
information for a specific service then they may include an optional information for a specific service, then they may include an optional
service URN. If a service is specified, and the LIS does not service URN. This service MUST exist in the IANA "Service URN
understand the requested service then URIs for urn:service:sos are Labels" repository created by [RFC5031]. If a service is specified,
returned. 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 If the LIS understands the routing request and has routing
information for the location then it includes the information in a information for the location, then it includes the information in a
routingInformation element returned in the locationResponse. How the routingInformation element returned in the locationResponse. How the
LIS obtains this information is left to implementation. LIS obtains this information is left to implementation.
Possibilities are described in Section 3. Possibilities are described in Section 3.
A LIS that does not understand the routing request element ignores it A LIS that does not understand the routing request element ignores it
and returns location as normal. and returns the location information in the normal manner.
A LIS that does support the routing request element MUST support A LIS that does support the routing request element MUST support
returning URIs for urn:service:sos and any regionally defined sub- returning URIs for urn:service:sos and any regionally defined sub-
services while following the URN traversal rules defined in services while following the URN traversal rules defined in
[RFC5031]. [RFC5031].
A LIS that does understand the routing request element but can't A LIS that does understand the routing request element but can't
obtain any routing information for the end-device's location MUST set obtain any routing information for the end-device's location MUST set
the defaultRoute attribute to true and return a default PSAP or the defaultRoute attribute to "true" and return a default PSAP or
gateway URI along with the determined location information in the gateway URI along with the determined location information in the
locationResponse. locationResponse.
A LIS that understands the routing request element but not the A LIS that understands the routing request element but not the
specified service URN, MUST follow the URN traversal rules defined in specified service URN MUST follow the URN traversal rules defined in
[RFC5031]. [RFC5031].
A LIS that receives a request for emergency routing information that A LIS that receives a request for emergency routing information that
it understands MUST return the correct emergency routing information it understands MUST return the correct emergency routing information
if it has or is able to acquire the routing information for the if it has or is able to acquire the routing information for the
location of the target device. location of the target device.
The routing information in the location response consists of a The routing information in the location response consists of a
service element identified by a service name. The service name is 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 and might contain a general emergency service URN such as
urn:service:sos or might contain a specific service URN depending on urn:service:sos or a specific service URN depending on what was
what was requested and what the LIS is able to provide. A list of requested and what the LIS is able to provide. A list of one or more
one or more service destinations is provided for the service name. service destinations is provided for the service name. Each
Each destination is expressed as a URI and each URI scheme should destination is expressed as a URI, and each URI scheme should only
only appear once in this list. The routing URIs are intended to be appear once in this list. The routing URIs are intended to be used
used at the time they are received. To avoid any risks of using at the time they are received. To avoid any risks of using stale
stale routing URIs the values MUST NOT be cached by the receiving routing URIs, the values MUST NOT be cached by the receiving entity.
entity.
5. Modification to Phone BCP 5. Modification to Phone BCP
This section describes the normative updates to Phone BCP [RFC6881]. This section describes the normative updates to Phone BCP [RFC6881].
It is important for devices and intermediaries to take all steps It is important for devices and intermediaries to take all steps
possible to ensure that emergency calls are routed to the correct possible to ensure that emergency calls are routed to the correct
PSAP. An alternative to providing routing information via global PSAP. An alternative to providing routing information via global
forest guides or local LoST servers is for local networks to forest guides or local LoST servers is for local networks to
configure the PSAP address information in the network location configure the PSAP address information in the network location
server. This specification updates Phone BCP [RFC6881] to provide server. This specification updates Phone BCP [RFC6881] to provide
this option. The update requires devices and intermediaries using this option. The update requires devices and intermediaries using
the HELD protocol to always include the HELD routing extension. If the HELD protocol to always include the HELD routing extension. If
the LIS is configured with the routing information it can provide it, the LIS is configured with the routing information, it can provide
if it is not then the device or intermediary tries LoST to acquire it; if it is not, then the device or intermediary tries LoST to
the PSAP URI. acquire the PSAP URI.
Section 6.5 of [RFC6881] defines "End System Location Configuration". 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 Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the
LCP such that "the request MUST include the requestRoutingInformation Location Configuration Protocol (LCP) such that "the request MUST
element". The remainder of the requirement remains unchanged. include the requestRoutingInformation element." The remainder of the
requirement remains unchanged.
This document adds a new requirement to Section 7 of [RFC6881]. This document adds a new requirement to Section 7 of [RFC6881].
"ED-51a : Endpoints MUST support the HELD requestRoutingInformation "ED-51a : Endpoints MUST support the HELD requestRoutingInformation
element and be able and be able to interpret and use any routing element and be able to interpret and use any routing information
information returned in the locationResponse." returned in the locationResponse."
This document adds two new requirements to Section 8 of [RFC6881]. This document adds two new requirements to Section 8 of [RFC6881].
"ED-52a : Endpoints that acquire routing information in a HELD "ED-52a : Endpoints that acquire routing information in a HELD
locationResponse SHOULD use this routing information but MAY perform locationResponse SHOULD use this routing information but MAY perform
a LoST findService request if they have a location value." a LoST findService request if they have a location value."
"ED-52b : Endpoints that acquire routing information in a HELD "ED-52b : Endpoints that acquire routing information in a HELD
locationResponse with a defaultRoute attribute of true MUST perform a locationResponse with a defaultRoute attribute of "true" MUST perform
LoST findService request if they have a location value. If a route 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, is provided by the LoST server, then this route MUST be used,
otherwise the routing information provided in the HELD response otherwise the routing information provided in the HELD response
SHOULD be used." SHOULD be used."
This document amends SP-26 from Section 8 of [RFC6881] such that a This document amends SP-26 from Section 8 of [RFC6881] such that a
LoST mapping need not be requested if non-default routing information LoST mapping need not be requested if non-default routing information
is provided in the HELD locationResponse. is provided in the HELD locationResponse.
6. HELD Schema Extension 6. HELD Schema Extension
This section describes the schema extension to HELD. This section describes the schema extension to HELD.
skipping to change at page 10, line 24 skipping to change at page 10, line 29
<address>192.0.2.12</address> <address>192.0.2.12</address>
<port>1024</port> <port>1024</port>
</src> </src>
<dst> <dst>
<address>192.0.2.195</address> <address>192.0.2.195</address>
<port>80</port> <port>80</port>
</dst> </dst>
</flow> </flow>
</locationRequest> </locationRequest>
Figure 3: Example Location Request. Figure 3: Example Location Request
Figure 4 illustrates the <locationResponse> message containing two Figure 4 illustrates the <locationResponse> message containing two
location URIs: a HTTPS and a SIP URI. Additionally, the response location URIs: an HTTPS and a SIP URI. Additionally, the response
contains routing information. contains routing information.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z"> <locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI> <locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI> <locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
skipping to change at page 12, line 26 skipping to change at page 12, line 26
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"> xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
<service defaultRoute="true" serviceUri="urn:service:sos"> <service defaultRoute="true" serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest> <dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest> <dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest> <dest>xmpp:112@example.com</dest>
</service> </service>
</routingInformation> </routingInformation>
</locationResponse> </locationResponse>
Figure 5: Example Location Response with default routing information Figure 5: Example Location Response with Default Routing Information
8. Privacy Considerations 8. Privacy Considerations
This document makes no changes that require privacy considerations This document makes no changes that require privacy considerations
beyond those already described in [RFC5985]. It does however extend beyond those already described in [RFC5985]. It does, however,
those described in [RFC6155]. extend those described in [RFC6155].
[RFC5985] describes the privacy considerations surrounding the HELD [RFC5985] describes the privacy considerations surrounding the HELD
location configuration protocol, and this document makes no specific location configuration protocol, and this document makes no specific
changes to these considerations. changes to these considerations.
[RFC6155] extends HELD beyond a simple location configuration [RFC6155] extends HELD beyond a simple LCP by enabling authorized
protocol (LCP) by enabling authorized third-parties to acquire third parties to acquire location information and describing the
location information and describes the issues in Section 4. The HELD issues in Section 4. The HELD routing extension supports returning
Routing extension supports returning URIs that represent specific URIs that represent specific services operating in the Target's
services operating in the Target's vicinity. This represents vicinity. This represents additional information about the Target;
additional information about the Target, as a consequence it is as a consequence, it is recommended that this option only be used
recommended that this option only be used when the LIS returns a when the LIS returns a location URI, not a location value.
location URI, not a location value.
9. Security Considerations 9. Security Considerations
This document imposes no additional security considerations beyond This document imposes no additional security considerations beyond
those already described in [RFC5985] and [RFC6155]. those already described in [RFC5985] and [RFC6155].
10. IANA Considerations 10. IANA Considerations
10.1. URN sub-namespace registration for 10.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:held:ri' 'urn:ietf:params:xml:ns:geopriv:held:ri'
This document calls for IANA to register a new XML namespace, as per Per this document, IANA has registered a new XML namespace, following
the guidelines in [RFC3688]. the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:ri URI: urn:ietf:params:xml:ns:geopriv:held:ri
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), Registrant Contact: IETF ECRIT working group (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com). James Winterbottom (a.james.winterbottom@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>HELD Routing Information Extensions</title> <title>HELD Routing Information Extensions</title>
</head> </head>
<body> <body>
<h1>Additional Element for HELD Routing Information</h1> <h1>Additional Element for HELD Routing Information</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7840.txt">
with the RFC number for this specification.]] RFC 7840</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
10.2. XML Schema Registration 10.2. XML Schema Registration
This section registers an XML schema as per the procedures in This section registers an XML schema as per the procedures in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:ri URI: urn:ietf:params:xml:schema:geopriv:held:ri
Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), Registrant Contact: IETF ECRIT working group (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com). James Winterbottom (a.james.winterbottom@gmail.com).
The XML for this schema can be found as the entirety of Section 6 XML: The XML for this schema can be found as the entirety of
of this document. Section 6 of this document.
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 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, DOI 10.17487/RFC5985, September 2010, RFC 5985, DOI 10.17487/RFC5985, September 2010,
<http://www.rfc-editor.org/info/rfc5985>. <http://www.rfc-editor.org/info/rfc5985>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<http://www.rfc-editor.org/info/rfc6881>. <http://www.rfc-editor.org/info/rfc6881>.
12.2. Informative References 11.2. Informative References
[M493] European Telecommunications Standards Institute, [M493] European Telecommunications Standards Institute,
"Functional architecture to support European requirements "Functional architecture to support European requirements
on emergency caller location determination and transport", on emergency caller location determination and transport",
ES 203 178, V 1.0.5, December 2014. ES 203 178, V1.1.1, February 2015.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
DOI 10.17487/RFC5031, January 2008, DOI 10.17487/RFC5031, January 2008,
<http://www.rfc-editor.org/info/rfc5031>. <http://www.rfc-editor.org/info/rfc5031>.
skipping to change at page 15, line 38 skipping to change at page 15, line 29
[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled
Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915, Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915,
April 2013, <http://www.rfc-editor.org/info/rfc6915>. April 2013, <http://www.rfc-editor.org/info/rfc6915>.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server [RFC7216] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS", (LIS) Discovery Using IP Addresses and Reverse DNS",
RFC 7216, DOI 10.17487/RFC7216, April 2014, RFC 7216, DOI 10.17487/RFC7216, April 2014,
<http://www.rfc-editor.org/info/rfc7216>. <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.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Winterb Consulting Services Winterb Consulting Services
Gwynneville, NSW 2500 Gwynneville, NSW 2500
AU Australia
Phone: +61 448 266004 Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com Email: a.james.winterbottom@gmail.com
Hannes Tschofenig Hannes Tschofenig
Halls in Tirol 6060 Hall in Tirol 6060
Austria Austria
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Laura Liess Laura Liess
Deutsche Telekom Networks Deutsche Telekom Networks
Deutsche Telekom Allee 7 Deutsche Telekom Allee 7
Darmstadt, Hessen 64295 Darmstadt, Hessen 64295
Germany Germany
 End of changes. 61 change blocks. 
148 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/