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
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
启用HTTP的位置传递（HOLD）协议的路由请求扩展
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.
对于位置服务器可以访问紧急路由信息的情况，如果位置请求包括对所需路由信息的请求，则位置服务器能够将路由信息与位置信息一起返回。本文档指定了启用HTTP的位置传递（HOLD）协议的扩展，该协议更新RFC 5985以支持此功能。允许在单个请求-响应交换中获取位置和路由信息将更新RFC 6881，因为当前位置获取和路由确定过程是独立的操作。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7840.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.
[RFC6443]和[RFC6881]中描述的具有互联网技术（ECRIT）呼叫模式的通用紧急情况上下文解析需要一个本地位置服务翻译（丢失）服务器或森林指南网络，以确定公共安全应答点（PSAP）的地址，该地址位于处理呼叫的最佳位置。森林指南网络尚未实现，虽然PSAP正在向IP网络发展，但丢失的服务器部署并不普遍。一些地区和国家表示不愿意部署丢失的服务器，这使得当前ECRIT体系结构的某些方面难以实现。
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.
为了满足法规要求，如[M493]，欧洲不断发展的体系结构将接入网络中的位置和路由信息结合起来，同时使用以软交换为中心的方法处理紧急呼叫。本文档描述了HOLD协议[RFC5985]的扩展，以便位置信息服务器可以在没有丢失服务器或林指南网络的情况下提供紧急路由信息。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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].
术语“位置信息服务器（LIS）”、“紧急服务路由代理（ESRP）”、“语音服务提供商（VSP）”和“公共安全应答点（PSAP）”的使用如[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).
术语“接入网络提供商”如[RFC5687]中所定义，包括互联网接入提供商（IAP）和互联网服务提供商（ISP）。
The term "forest guide" is used as defined in [RFC5582].
术语“森林指南”的使用如[RFC5582]中所定义。
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.
[RFC6881]中规定的互联网紧急呼叫体系结构描述了紧急呼叫处理的两种主要模型。第一种是以设备为中心的模型，其中设备使用位置配置协议（如HOLD[RFC5985]）获取位置信息，然后继续使用LoST[RFC5222]确定更靠近本地PSAP的下一跳的地址。图1以简化的形式显示了该模型。
+---Location Request---+
| (1) |
+---+----+ +---V---+
| |<--Location--| LIS |
| Caller | (2) +-------+ +--------+
| | | ESRP/ |
| |----Find Service-------+ | PSAP |
+------^-+ (3) | +--------+
| | +--------V----+ ^
| +-----Service----| LoST Server | |
| (4) +-------------+ +---+---+
+-------------Call Initiation------------>| VSP |
(5) +-------+
+---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
图1：以设备为中心的应急服务模型
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.
第二种方法是以软交换为中心的模型，其中设备发起紧急呼叫，并且服务软交换检测到呼叫是紧急呼叫，并使用带有标识扩展[RFC6155][RFC6915]的保持[RFC5985]从LIS中发起检索呼叫者的位置，然后使用LoST确定到本地PSAP的路由[RFC5222]。图2显示了高级协议交互。
+---Location Request---+
| (2) |
+---V---+ |
| LIS | |
+----+--+ +----+----+
| | |
+----Location--->| Soft- |
+--------+ (3) | switch |
| Caller |------Call Initiation------------> | |
+--------+ (1) +-+-^---+-+
+-------------+ | | |
| LoST Server |<-Find Service--+ | |
+------+------+ (4) | |
| | |
+----------Service--------+ |
(5) |
+-----------+ |
| ESRP/PSAP |<------Call----+
+-----------+ (6)
+---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
图2：以软交换为中心的呼叫模型
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.
在以软交换为中心的模型中，当VSP收到紧急呼叫时，它执行两项任务。第一个任务是确定请求位置信息的正确LIS；这是使用[RFC7216]中描述的反向DNS查找的组合来获取服务域名，然后使用[RFC5986]来确定LIS URI。从LIS获取位置后，VSP将确定与为调用者提供服务的域相关联的丢失服务器，并向其查询正确的PSAP地址。
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.
丢失服务器发现是一种基于域的活动，类似于LIS发现技术。但是，与作为域绑定服务的LIS不同，丢失的服务器是地理绑定服务。这意味着，对于跨多个地理区域的域，丢失的服务器可能无法提供到必要PSAP的路由。发生这种情况时，联系的丢失服务器调用其他丢失服务器的帮助，这需要部署林指南。
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.
以设备为中心和以软交换为中心的呼叫模型都涉及绑定到服务接入网络的LIS的概念。在许多情况下，LIS已经知道任何给定位置的目标PSAP URI。例如，在[RFC6881]中，LIS使用基于丢失协议[RFC5222]的位置验证程序验证市政位置。丢失的验证请求类似于丢失的路由请求，并为LIS提供路由请求所需的相同PSAP路由信息。在其他情况下，LIS在供应时知道给定位置的正确PSAP，或者接入网络可能总是路由到同一个紧急提供商。无论LIS以何种方式学习某个位置的PSAPURI，在很多情况下，LIS都已经拥有此信息。
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.
本文件规定了HOLD协议的扩展，以便在请求位置信息的同时，可以从LIS请求紧急路由信息。本文档更新了[RFC6881]，要求了解本规范的设备和软交换机始终请求路由信息，以避免在未部署丢失的服务器或林指南网络的情况下出现查询失败的风险。
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.
丢失协议[RFC5222]定义了一个描述服务区域和相关服务URL的<mapping>元素。考虑从LoST中重用此元素以提供路由uri。然而，这意味着<mapping>元素中的几个必需组件必须包含模糊或误导性的值。具体来说，“source”属性需要包含权威服务器丢失的应用程序唯一字符串。但是，在本规范中描述的情况下，可能没有权威的丢失服务器，因此输入此属性的任何值都会产生误导。除此之外，接收器不应缓存以本规范中描述的方式接收的路由信息，因此详细说明路由信息何时过期或最后更新是不相关的。
The mechanism consists of adding an element to the HELD locationRequest and an element to the locationResponse.
该机制包括向保持的locationRequest添加一个元素和向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.
请求元素表示请求者希望LIS根据终端设备的位置提供路由信息。如果发送的路由请求没有属性，则返回urn:service:sos的URI。如果请求者需要特定服务的路由信息，那么它们可能包括可选的服务URN。此服务必须存在于[RFC5031]创建的IANA“服务URN标签”存储库中。如果指定了服务，而LIS不理解请求的服务，则返回urn:service:sos的URI。
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.
如果LIS了解路由请求并具有该位置的路由信息，则它将该信息包含在locationResponse中返回的routingInformation元素中。LIS如何获得这些信息由实施部门决定。第3节描述了各种可能性。
A LIS that does not understand the routing request element ignores it and returns the location information in the normal manner.
不理解路由请求元素的LIS将忽略该元素，并以正常方式返回位置信息。
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].
支持路由请求元素的LIS必须支持返回urn:service:sos和任何区域定义的子服务的URI，同时遵循[RFC5031]中定义的urn遍历规则。
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.
理解路由请求元素但无法获取终端设备位置的任何路由信息的LIS必须将defaultRoute属性设置为“true”，并在locationResponse中返回默认PSAP或网关URI以及确定的位置信息。
A LIS that understands the routing request element but not the specified service URN MUST follow the URN traversal rules defined in [RFC5031].
理解路由请求元素但不理解指定服务URN的LIS必须遵循[RFC5031]中定义的URN遍历规则。
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.
接收紧急路由信息请求的LIS，如果已经或能够获取目标设备位置的路由信息，则必须返回正确的紧急路由信息。
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.
位置响应中的路由信息由服务名称标识的服务元素组成。服务名称是URN，可能包含通用应急服务URN，如URN:service:sos或特定服务URN，具体取决于请求的内容和LIS能够提供的内容。为服务名称提供一个或多个服务目的地的列表。每个目的地都表示为一个URI，每个URI方案在此列表中只应出现一次。路由URI旨在在接收时使用。为了避免使用过时路由URI的任何风险，接收实体不得缓存这些值。
This section describes the normative updates to Phone BCP [RFC6881].
本节介绍电话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.
设备和中介机构必须采取一切可能的措施，确保紧急呼叫路由到正确的PSAP。除了通过全局林指南或本地丢失服务器提供路由信息外，本地网络还可以在网络位置服务器中配置PSAP地址信息。本规范更新了电话BCP[RFC6881]以提供此选项。更新要求使用HOLD协议的设备和中介始终包括HOLD路由扩展。如果LIS配置了路由信息，则可以提供路由信息；如果不是，则设备或中介尝试丢失以获取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.
[RFC6881]第6.5节定义了“终端系统位置配置”。当HOLD用作位置配置协议（LCP）时，需求ED-23/INT-18/SP-14将更新，以便“请求必须包括请求路由信息元素”。需求的其余部分保持不变。
This document adds a new requirement to Section 7 of [RFC6881].
本文件在[RFC6881]第7节中增加了一项新要求。
"ED-51a : Endpoints MUST support the HELD requestRoutingInformation element and be able to interpret and use any routing information returned in the locationResponse."
“ED-51a:终结点必须支持保留的requestRoutingInformation元素，并且能够解释和使用locationResponse中返回的任何路由信息。”
This document adds two new requirements to Section 8 of [RFC6881].
本文件在[RFC6881]第8节中增加了两项新要求。
"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-52a:在保留的locationResponse中获取路由信息的端点应使用此路由信息，但如果它们具有位置值，则可能会执行丢失查找服务请求。”
"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."
ED-52b:在保留的locationResponse中获取路由信息且defaultRoute属性为“true”的端点如果具有位置值，则必须执行LoST findService请求。如果路由由丢失的服务器提供，则必须使用此路由，否则应使用保留的响应中提供的路由信息
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.
本文件对[RFC6881]第8节中的SP-26进行了修订，以便在保留位置响应中提供非默认路由信息时，无需请求丢失映射。
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">
<?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:element name="requestRoutingInformation">
<xs:complexType name="empty">
<xs:attribute name="service" type="xs:anyUri"
use="optional" default="urn:service:sos"/>
</xs:complexType>
</xs:element>
<xs:complexType name="service">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:complexType name="service">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="dest" type="xs:anyURI"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</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: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: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: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>
</xs:schema>
Figure 3 illustrates a <locationRequest> example that contains IP flow information in the request.
图3展示了一个<locationRequest>示例，其中包含请求中的IP流信息。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="emergencyRouting">
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="emergencyRouting">
<requestRoutingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>
<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>
<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
图3：位置请求示例
Figure 4 illustrates the <locationResponse> message containing two location URIs: an HTTPS and a SIP URI. Additionally, the response contains routing information.
图4说明了包含两个位置URI的<locationResponse>消息：HTTPS和SIPURI。此外，响应包含路由信息。
<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>
<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>
<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>
</locationResponse>
Figure 4: Example Location Response
图4：位置响应示例
Figure 5 illustrates the <locationResponse> message containing default routing information and an HTTPS location URI.
图5演示了包含默认路由信息和HTTPS位置URI的<locationResponse>消息。
<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>
<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>
<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>
</locationResponse>
Figure 5: Example Location Response with Default Routing Information
图5：带有默认路由信息的位置响应示例
This document makes no changes that require privacy considerations beyond those already described in [RFC5985]. It does, however, extend those described in [RFC6155].
除了[RFC5985]中已经描述的内容外，本文件不做任何需要隐私考虑的更改。但是，它扩展了[RFC6155]中描述的内容。
[RFC5985] describes the privacy considerations surrounding the HELD location configuration protocol, and this document makes no specific changes to these considerations.
[RFC5985]描述了围绕保持位置配置协议的隐私注意事项，本文档对这些注意事项没有具体更改。
[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.
[RFC6155]通过允许授权第三方获取位置信息并描述第4节中的问题，将持有范围扩展到了简单的LCP之外。保留路由扩展支持返回URI，这些URI表示在目标附近运行的特定服务。这表示有关目标的附加信息；因此，建议仅当LIS返回位置URI而不是位置值时才使用此选项。
This document imposes no additional security considerations beyond those already described in [RFC5985] and [RFC6155].
除了[RFC5985]和[RFC6155]中已经描述的安全注意事项外，本文件没有提出其他安全注意事项。
10.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:held:ri'
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].
根据本文档，IANA按照[RFC3688]中的指导原则注册了一个新的XML名称空间。
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), James Winterbottom (a.james.winterbottom@gmail.com).
注册人联系人：IETF ECRIT工作组(ecrit@ietf.org)，詹姆斯·温特巴顿（a.James。winterbottom@gmail.com).
XML:
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
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
This section registers an XML schema as per the procedures in [RFC3688].
本节按照[RFC3688]中的步骤注册XML模式。
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), James Winterbottom (a.james.winterbottom@gmail.com).
注册人联系人：IETF ECRIT工作组(ecrit@ietf.org)，詹姆斯·温特巴顿（a.James。winterbottom@gmail.com).
XML: The XML for this schema can be found as the entirety of Section 6 of this document.
XML：此模式的XML可作为本文档第6节的全部内容找到。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC5985]巴恩斯，M.，编辑，“支持HTTP的位置传递（保留）”，RFC 5985，DOI 10.17487/RFC59852010年9月<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>.
[RFC6881]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务最佳现行实践”，BCP 181，RFC 6881，DOI 10.17487/RFC6881，2013年3月<http://www.rfc-editor.org/info/rfc6881>.
[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.
[M493]欧洲电信标准协会，“支持欧洲紧急呼叫者位置确定和传输要求的功能架构”，ES 203 178，V1.1.12015年2月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<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>.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，DOI 10.17487/RFC5031，2008年1月<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>.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，DOI 10.17487/RFC5222，2008年8月<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>.
[RFC5582]Schulzrinne，H.，“位置到URL映射架构和框架”，RFC 5582，DOI 10.17487/RFC5582，2009年9月<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>.
[RFC5687]Tschofenig，H.和H.Schulzrinne，“GEOPRIV第7层位置配置协议：问题陈述和要求”，RFC 5687，DOI 10.17487/RFC5687，2010年3月<http://www.rfc-editor.org/info/rfc5687>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, DOI 10.17487/RFC5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 5986，DOI 10.17487/RFC5986，2010年9月<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>.
[RFC6155]Winterbottom，J.，Thomson，M.，Tschofenig，H.，和R.Barnes，“在支持HTTP的位置交付（保留）中使用设备标识”，RFC 6155，DOI 10.17487/RFC6155，2011年3月<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>.
[RFC6443]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，RFC 6443，DOI 10.17487/RFC6443，2011年12月<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>.
[RFC6915]Bellis，R.，“支持HTTP的位置传递的流标识扩展（保留）”，RFC 6915，DOI 10.17487/RFC6915，2013年4月<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>.
[RFC7216]Thomson，M.和R.Bellis，“使用IP地址和反向DNS的位置信息服务器（LIS）发现”，RFC 7216，DOI 10.17487/RFC7216，2014年4月<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.
我们要感谢Wilfried Lange与我们分享他的观点。我们还要感谢布鲁诺·查特拉斯（Bruno Chatras）的早期评论，以及基思·德拉格（Keith Drage）更详细的评论。感谢罗杰·马歇尔和兰迪·盖伦斯的建议。
Authors' Addresses
作者地址
James Winterbottom Winterb Consulting Services Gwynneville, NSW 2500 Australia
James Winterbottom Winterb咨询服务公司，新南威尔士州格温内维尔，澳大利亚2500
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com
Hannes Tschofenig Hall in Tirol 6060 Austria
奥地利蒂罗尔的汉内斯·茨霍芬尼大厅6060
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Laura Liess Deutsche Telekom Networks Deutsche Telekom Allee 7 Darmstadt, Hessen 64295 Germany
Laura Liess Deutsche Telekom Networks Deutsche Telekom Allee 7 Darmstadt，Hessen 64295德国
Email: L.Liess@telekom.de
URI: http://www.telekom.de
Email: L.Liess@telekom.de
URI: http://www.telekom.de