Internet Engineering Task Force (IETF) A. Forte
Request for Comments: 6451 AT&T
Category: Experimental H. Schulzrinne
ISSN: 2070-1721 Columbia University
December 2011
Internet Engineering Task Force (IETF) A. Forte
Request for Comments: 6451 AT&T
Category: Experimental H. Schulzrinne
ISSN: 2070-1721 Columbia University
December 2011
Location-to-Service Translation (LoST) Protocol Extensions
位置到服务转换（丢失）协议扩展
Abstract
摘要
An important class of location-based services answers the question, "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by".
一类重要的基于位置的服务回答了这样一个问题：“这种服务的哪些实例离我最近？”例如，查找餐馆、加油站、商店、自动柜员机、无线接入点（热点）或停车位。目前，位置到服务转换（LoST）协议仅支持基于服务区域将位置映射到单个服务。本文档描述了一个扩展，该扩展允许“N最近”、“距离X内”和“服务于”类型的查询。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6451.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6451.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Service Regions . . . . . . . . . . . . . . . . . . . . . . . 3
4. New <findService> Query Types: "N nearest", "within
distance X", and "served by" . . . . . . . . . . . . . . . . . 4
5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5
5.2. Queries Based on Service Regions . . . . . . . . . . . . . 7
5.3. Difference between "within distance X" and "served by"
Queries . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Limiting the Number of Returned Service URIs . . . . . . . 10
5.5. The <serviceLocation> Element in Responses . . . . . . . . 12
6. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 15
7. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. LoST Extensions RELAX NG Schema Registration . . . . . . . 18
9.2. LoST Extensions Namespace Registration . . . . . . . . . . 19
10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. Normative References . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Service Regions . . . . . . . . . . . . . . . . . . . . . . . 3
4. New <findService> Query Types: "N nearest", "within
distance X", and "served by" . . . . . . . . . . . . . . . . . 4
5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5
5.2. Queries Based on Service Regions . . . . . . . . . . . . . 7
5.3. Difference between "within distance X" and "served by"
Queries . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Limiting the Number of Returned Service URIs . . . . . . . 10
5.5. The <serviceLocation> Element in Responses . . . . . . . . 12
6. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 15
7. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. LoST Extensions RELAX NG Schema Registration . . . . . . . 18
9.2. LoST Extensions Namespace Registration . . . . . . . . . . 19
10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. Normative References . . . . . . . . . . . . . . . . . . . . . 22
The Location-to-Service Translation (LoST) protocol [RFC5222] maps service identifiers (URNs) and civic or geospatial information to service URIs, based on service regions. While motivated by mapping locations to the public safety answering point (PSAP) serving that location, the protocol has been designed to generalize to other location-mapping services.
位置到服务转换（丢失）协议[RFC5222]根据服务区域将服务标识符（URN）和城市或地理空间信息映射到服务URI。在将位置映射到服务于该位置的公共安全应答点（PSAP）的同时，该协议被设计为推广到其他位置映射服务。
However, the current LoST query model assumes that each service URI has a service region and that service regions do not overlap. This fits the emergency services model, where the service region of a PSAP is given by jurisdictional boundaries, but does not work as well for other services that do not have clearly defined boundaries. For example, any given location is likely served by a number of different restaurants, depending on how far the prospective customer is willing to travel.
但是，当前的丢失查询模型假设每个服务URI都有一个服务区域，并且服务区域不重叠。这符合应急服务模型，其中PSAP的服务区域由辖区边界给出，但对于没有明确定义边界的其他服务则不起作用。例如，任何给定的地点都可能有许多不同的餐厅提供服务，这取决于潜在客户愿意走多远。
We extend LoST with three additional <findService> query types, giving the protocol the ability to find the N nearest instances of a particular service, all services within a given distance, and all services whose service region includes the user's current location.
我们使用三种额外的<findService>查询类型扩展LoST，使协议能够找到特定服务的N个最近实例、给定距离内的所有服务以及服务区域包括用户当前位置的所有服务。
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]中所述进行解释。
Generally speaking, service regions apply only to a subset of services.
一般来说，服务区域仅适用于服务的子集。
In Section 1 of [RFC5222], a service region is defined as follows:
在[RFC5222]第1节中，服务区域定义如下：
"To minimize round trips and to provide robustness against network failures, LoST supports caching of individual mappings and indicates the region for which the same answer would be returned ("service region")."
“为了最大限度地减少往返并提供对网络故障的鲁棒性，LoST支持缓存单个映射，并指示将返回相同答案的区域（“服务区域”）。”
Section 5.5 of [RFC5222] further defines a service region:
[RFC5222]第5.5节进一步定义了服务区域：
"A response MAY indicate the region for which the service URL returned would be the same as in the actual query, the so-called service region."
响应可能指示返回的服务URL与实际查询中相同的区域，即所谓的服务区域
For emergency services, service region and service area, as defined in [RFC5222], represent the same geographical area. This is due to the fact that each PSAP serves its own area without overlapping with the service area of any other PSAP. For as long as the client is located in the service area of a PSAP, the same PSAP is returned by the LoST server, that is, the service region does not change. A service region is the service area of a PSAP.
对于应急服务，[RFC5222]中定义的服务区域和服务区域代表相同的地理区域。这是因为每个PSAP服务于自己的区域，而不与任何其他PSAP的服务区域重叠。只要客户机位于PSAP的服务区域，丢失的服务器就会返回相同的PSAP，即服务区域不变。服务区域是PSAP的服务区域。
For non-emergency services, different points of service may have different overlapping service areas. This means that one service region will probably include a large number of service areas. Since we can get a large number of service URIs for each query, a service region per the definition above would be the region within which a user would get the same set of service URIs. If one or more of the URIs in the set changes, the set of URIs changes, i.e., the service region changes. Therefore, for non-emergency services, the service region defined in [RFC5222] would change frequently, thus greatly reducing the benefit of caching responses by service region.
对于非紧急服务，不同的服务点可能有不同的重叠服务区域。这意味着一个服务区域可能包括大量的服务区域。由于我们可以为每个查询获取大量服务URI，因此根据上面的定义，一个服务区域将是用户将在其中获取相同服务URI集的区域。如果集合中的一个或多个URI发生更改，则该URI集合将发生更改，即服务区域将发生更改。因此，对于非紧急服务，[RFC5222]中定义的服务区域将频繁更改，从而大大降低了按服务区域缓存响应的好处。
Generally speaking, we can divide location-based services into two main categories based on:
一般来说，我们可以根据以下因素将基于位置的服务分为两大类：
o how far they are from the user (e.g., automatic teller machine, food takeout);
o 他们离用户有多远（例如，自动取款机、食品外卖）；
o whether or not their service area includes the user's current location (e.g., pizza delivery, PSAP).
o 他们的服务区域是否包括用户的当前位置（例如，比萨饼配送、PSAP）。
For services included in the first category, service areas and therefore service regions are not relevant while they are important for services included in the second category. This distinction becomes obvious if we consider, for example, the difference between takeout (first category) and delivery (second category). In the case of takeout, the user wants to go to a particular restaurant and buy dinner, regardless of whether his location falls into the delivery service area of the restaurant or not. For delivery, the user cares about the restaurant service area as the restaurant will deliver food to him only if his location falls within the restaurant service area.
对于包含在第一类中的服务，服务区域和服务区域不相关，而它们对于包含在第二类中的服务很重要。如果我们考虑外卖（第一类）和交货（第二类）之间的差异，这种区别就变得明显了。在外卖的情况下，用户希望去特定的餐厅购买晚餐，不管他的位置是否属于餐厅的送货服务区。对于配送，用户关心餐厅服务区，因为只有当其所在位置位于餐厅服务区内时，餐厅才会向其配送食物。
There is a clear distinction between services that require service areas and services that do not. The LoST extensions defined in this document take this into account by using the service classification mentioned above.
需要服务区域的服务和不需要服务区域的服务之间有明确的区别。本文档中定义的丢失扩展通过使用上述服务分类考虑了这一点。
4. New <findService> Query Types: "N nearest", "within distance X", and "served by"
4. 新的<findService>查询类型：“N个最近的”、“距离X以内”和“服务对象”
We introduce three new types of <findService> queries: "N nearest", "within distance X", and "served by". The first query returns the N points of interest (POIs) closest to the client's physical location; the second query discovers all the points of interest located within a given distance from the client's physical location; and the third query returns all the points of interest whose service area includes the client's current location.
我们介绍了三种新类型的<findService>查询：“N最近的”、“距离X以内的”和“服务对象”。第一个查询返回最接近客户物理位置的N个兴趣点（POI）；第二个查询发现位于客户物理位置给定距离内的所有关注点；第三个查询返回其服务区域包括客户当前位置的所有兴趣点。
For "within distance X" queries, the LoST client needs to specify to the server the range within which instances of a particular service should be searched. In order to do this, we make use of various shapes [RFC5491] in LoST queries.
对于“距离X内”查询，丢失的客户端需要向服务器指定搜索特定服务实例的范围。为了做到这一点，我们在丢失的查询中使用各种形状[RFC5491]。
For "served by" queries, the LoST client needs to let the server know that it MUST return only those services whose service area includes the user's current location. In order to do this, we introduce the
对于“服务对象”查询，丢失的客户端需要让服务器知道它必须只返回那些服务区域包括用户当前位置的服务。为此，我们引入
<region> element in <findService> queries. Service region boundaries MAY be returned in a LoST <findServiceResponse> as described in [RFC5222].
<findService>查询中的<region>元素。如[RFC5222]所述，服务区域边界可以在丢失的<findServiceResponse>中返回。
For "N nearest" queries, the LoST client needs to let the server know N, i.e., the maximum number of service URIs to be returned in a response. In order to specify this, we introduce the <limit> element in <findService> queries.
对于“N个最近的”查询，丢失的客户端需要让服务器知道N，即响应中要返回的服务URI的最大数量。为了说明这一点，我们在<findService>查询中引入<limit>元素。
Also, we introduce a new element in LoST responses, namely <serviceLocation>. This new element is used by the server to indicate to the client the physical location of points of interest. In doing so, the client can compute the distance and other metrics between its current location and the points of interest.
此外，我们在丢失的响应中引入了一个新元素，即<serviceLocation>。服务器使用此新元素向客户端指示感兴趣点的物理位置。这样，客户机可以计算其当前位置和感兴趣点之间的距离和其他度量。
The new elements <region>, <limit>, and <serviceLocation> are defined in the "lost-ext" namespace. This new namespace is defined in Section 7.
新元素<region>、<limit>和<serviceLocation>在“lost ext”命名空间中定义。第7节定义了这个新名称空间。
In [RFC5491], different shapes are defined in order to represent a point and an area of uncertainty within which the user might be situated. While this remains true for "served by" queries, for "within distance X" queries, such shapes can be interpreted as the area within which we want to find a service. In particular, we want to search for points of service within that area because our location is within that area with a certain probability. We can think of the area of uncertainty in a shape as the probability that a user might be within that area, so we want to look for services within that area. Thus, the "within distance X" query manually sets the uncertainty in user location to an uncertainty shape with parameter X.
在[RFC5491]中，定义了不同的形状，以表示用户可能所在的点和不确定区域。虽然这对于“服务对象”查询和“距离X内”查询仍然适用，但此类形状可以解释为我们希望在其中查找服务的区域。特别是，我们希望在该区域内搜索服务点，因为我们的位置以一定的概率位于该区域内。我们可以将形状中的不确定区域视为用户可能在该区域内的概率，因此我们希望在该区域内寻找服务。因此，“距离内X”查询手动将用户位置的不确定性设置为带有参数X的不确定性形状。
For example, Figure 1 shows a "within distance X" <findService> geodetic query using the circular shape. With the query shown in Figure 1, we are asking the LoST server to send us a list of service URIs for pizza places within 200 meters from our approximate position specified in <gml:pos>.
例如，图1显示了使用圆形的“在距离X以内”的<findService>大地测量查询。对于图1所示的查询，我们要求丢失的服务器向我们发送一份比萨饼店的服务URI列表，该列表距离我们在<gml:pos>中指定的大致位置200米以内。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
Figure 1: A "within distance X" <findService> geodetic query using
the circular shape (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figure 1: A "within distance X" <findService> geodetic query using
the circular shape (a hypothetical service URN of
"urn:service:food.pizza" is used)
Aside from the circular shape, other shapes are also useful. In particular, there are situations in which it is useful to query for services in a certain direction of movement rather than in an exact physical location. For example, if a user is driving north from New York City to Boston, it would be useful for this user to be able to query for services north of where he currently is, that is, not at his current physical location nor at his final destination.
除了圆形外，其他形状也很有用。特别是，在某些情况下，查询特定移动方向上的服务而不是精确的物理位置上的服务非常有用。例如，如果用户从纽约市向北行驶到波士顿，则该用户能够查询他当前所在地以北的服务将非常有用，即，不是在他当前的物理位置，也不是在他的最终目的地。
In order to implement such direction-of-travel searches, this document supports the use of shapes such as an ellipse. The ellipse has a major and a minor dimension, thus allowing for defining a "privileged" direction by having the major dimension in the direction of movement. In the present context, the circular shape allows a device to search for services in any direction surrounding its physical location, while shapes such as the ellipse allow the device to search for services in a more specific direction. Figure 2 shows a "within distance X" <findService> geodetic query using the elliptical shape. The ellipse shape is defined in Section 5.2.4 of [RFC5491].
为了实现这种旅行方向搜索，本文档支持使用椭圆等形状。椭圆有一个大尺寸和一个小尺寸，因此允许通过在运动方向上具有大尺寸来定义“特权”方向。在本上下文中，圆形允许设备在围绕其物理位置的任何方向上搜索服务，而诸如椭圆之类的形状允许设备在更特定的方向上搜索服务。图2显示了使用椭圆形状的“距离X以内”大地测量查询。[RFC5491]第5.2.4节定义了椭圆形状。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
1235
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
660
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
41.2
</gs:orientation>
</gs:Ellipse>
</location>
<service>urn:service:food.pizza</service>
</findService>
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
1235
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
660
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
41.2
</gs:orientation>
</gs:Ellipse>
</location>
<service>urn:service:food.pizza</service>
</findService>
Figure 2: A "within distance X" <findService> geodetic query using
the elliptical shape (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figure 2: A "within distance X" <findService> geodetic query using
the elliptical shape (a hypothetical service URN of
"urn:service:food.pizza" is used)
As mentioned in Section 3, we can divide location-based services into two main categories based on:
如第3节所述，我们可以根据以下因素将基于位置的服务分为两大类：
o how far they are from the user;
o 他们离用户有多远；
o whether or not their service area includes the user's current location.
o 他们的服务区域是否包括用户的当前位置。
A "within distance X" query addresses services included in the first category, while a "served by" query addresses services included in the second category.
“距离内X”查询地址包含在第一类中的服务，而“服务者”查询地址包含在第二类中的服务。
When querying LoST regarding a specific service, we need to specify if such service belongs to either the first or the second category. This is necessary since depending on the category to which the
当查询有关特定服务的LoST时，我们需要指定此类服务属于第一类还是第二类。这是必要的，因为这取决于
service belongs, the LoST server has to follow a different metric in selecting the results to include in the response.
如果服务属于，则丢失的服务器在选择要包含在响应中的结果时必须遵循不同的度量。
For example, Figure 3 shows three points of interest with their service areas. The user location (i.e., the LoST client location) is represented by a circular shape (e.g., GPS). If POI 1, POI 2, and POI 3 belong to the first category of service ("within distance X" query), their service area is irrelevant; what matters is how far they are from the user. For such services, the shape representing the user location represents the distance within which the user wants to search for services (see Section 5.1). In the example shown in Figure 3, the LoST server returns only POI 3, as POI 3 is the only point of interest falling within the user location represented by the circle, i.e., the area within which the user wants to search for services. On the other hand, if the three points of service belong to the second category ("served by" query), then what matters is their service area. In this second scenario, since the circle representing the user location overlaps with all three service areas, all three POIs can serve the location of the user, and the LoST server has to return all three POIs, that is, POI 1, POI 2, and POI 3.
例如，图3显示了三个关注点及其服务区域。用户位置（即丢失的客户端位置）由圆形（例如GPS）表示。如果POI 1、POI 2和POI 3属于第一类服务（“距离X内”查询），则其服务区域无关；重要的是他们离用户有多远。对于此类服务，表示用户位置的形状表示用户希望搜索服务的距离（见第5.1节）。在图3所示的示例中，丢失的服务器仅返回POI 3，因为POI 3是由圆圈表示的用户位置内的唯一兴趣点，即用户希望搜索服务的区域。另一方面，如果三个服务点属于第二类（“服务者”查询），那么重要的是它们的服务区域。在第二个场景中，由于表示用户位置的圆圈与所有三个服务区域重叠，因此所有三个POI都可以服务于用户的位置，并且丢失的服务器必须返回所有三个POI，即POI 1、POI 2和POI 3。
__________________________
\ ***** \
,===============***====, *** \
/ ** \ / ** \
/ POI 1 ** \ / ** \
/ o ** X ** \
/ ** / \ USER ** \
/ ** / \ 0 ** \
/ ** / \ POI 3 ** \
/ ** / \ o ** \
/ ,--------**-/---------\----------**--, \
`=====================** \________**___|___________\
| ** ** |
| o *** *** |
| POI 2 ***** |
`------------------------------------'
__________________________
\ ***** \
,===============***====, *** \
/ ** \ / ** \
/ POI 1 ** \ / ** \
/ o ** X ** \
/ ** / \ USER ** \
/ ** / \ 0 ** \
/ ** / \ POI 3 ** \
/ ** / \ o ** \
/ ,--------**-/---------\----------**--, \
`=====================** \________**___|___________\
| ** ** |
| o *** *** |
| POI 2 ***** |
`------------------------------------'
Figure 3: LoST client location (circle) overlapping three service areas of three different points of interest (POI 1, POI 2, POI 3)
图3：丢失的客户位置（圆圈）与三个不同兴趣点（POI 1、POI 2、POI 3）的三个服务区域重叠
In order for the client to specify which of the two categories the service belongs to, we introduce the <region> element. This new element is of type boolean. When its value is false, the LoST server MUST perform a search based on the distance between the user and the points of service ("within distance X" query). When its value is either true or the <region> element is missing (see Section 5.3), the
为了让客户端指定服务属于这两个类别中的哪一个，我们引入<region>元素。此新元素属于布尔类型。当其值为false时，丢失的服务器必须根据用户与服务点之间的距离执行搜索（“距离X内”查询）。当其值为true或<region>元素缺失时（见第5.3节），则
requested service belongs to the second category, and a search based on service areas MUST be performed by the LoST server ("served by" query). When present, the <region> element MUST be conveyed inside the <findService> element defined in [RFC5222].
请求的服务属于第二类，基于服务区域的搜索必须由丢失的服务器执行（“服务者”查询）。存在时，<region>元素必须在[RFC5222]中定义的<findService>元素内传送。
For a search based on service regions, the LoST server MUST return only those services whose service area includes the user's current location. Service region boundaries MAY be returned in a LoST <findServiceResponse> as described in [RFC5222].
对于基于服务区域的搜索，丢失的服务器必须仅返回其服务区域包括用户当前位置的服务。如[RFC5222]所述，服务区域边界可以在丢失的<findServiceResponse>中返回。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value" recursive="true">
<ext:region>true</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value" recursive="true">
<ext:region>true</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
Figure 4: A "served by" <findService> geodetic query with the new
<region> element (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figure 4: A "served by" <findService> geodetic query with the new
<region> element (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figures 1 and 4 show examples of a "within distance X" query and a "served by" query, respectively. Although very similar, these two types of queries have three important differences:
图1和图4分别显示了“距离X内”查询和“服务对象”查询的示例。尽管非常相似，但这两种类型的查询有三个重要区别：
o A "served by" query can support all the shapes a "within distance X" query can support plus the point shape. The point shape does not make sense for a "within distance X" query and SHOULD NOT be used for this query as it would be equivalent to a within-zero-meters search.
o “服务对象”查询可以支持“距离X内”查询可以支持的所有形状以及点形状。点形状对于“距离X以内”查询没有意义，因此不应用于此查询，因为它相当于零米以内的搜索。
o In a "within distance X" query, we manually set the uncertainty level in user location to X, and we search for services within the area represented by such uncertain location. In all other types
o 在“距离内X”查询中，我们手动将用户位置中的不确定性级别设置为X，并在该不确定性位置表示的区域内搜索服务。在所有其他类型中
of queries, including a "served by" query, the level of uncertainty in user location cannot be changed by the user, and a search based on service areas is performed.
对于包括“服务者”查询在内的所有查询，用户不能更改用户位置的不确定性水平，并执行基于服务区域的搜索。
o In a "within distance X" query, the value of the <region> element MUST be set to false. A "served by" query SHALL have the value of the <region> element set to true. If the <region> element is not present, its value MUST be assumed to be equal to true, and the query will be a "served by" query. This behavior is consistent with [RFC5222].
o 在“距离X内”查询中，<region>元素的值必须设置为false。“服务对象”查询应将<region>元素的值设置为true。如果<region>元素不存在，则必须假定其值等于true，并且该查询将是一个“服务者”查询。此行为与[RFC5222]一致。
Limiting the number of results is helpful, particularly for mobile devices with limited bandwidth. For "N nearest" queries, the client needs to be able to tell the server to return no more than N service URIs. In order to specify such a limit, we introduce a new element, namely <limit>. This new element is OPTIONAL, but when present, it MUST be conveyed inside the <findService> element defined in [RFC5222].
限制结果的数量是有帮助的，特别是对于带宽有限的移动设备。对于“N个最近的”查询，客户端需要能够告诉服务器返回不超过N个服务URI。为了指定这样的限制，我们引入了一个新元素，即<limit>。此新元素是可选的，但如果存在，则必须在[RFC5222]中定义的<findService>元素中传递。
Figures 5, 6, and 7 show a <findService> geodetic query where the client asks the server to return no more than 20 service URIs. In particular, Figure 5 shows an "N nearest" query; Figure 6 shows a query that is a combination of "N nearest" and "within distance X"; and Figure 7 shows a query that is a combination of "N nearest" and "served by". When receiving such queries, the LoST server will return a list of no more than 20 points of interest.
图5、6和7显示了<findService>大地测量查询，其中客户端要求服务器返回不超过20个服务URI。特别是，图5显示了一个“N最近的”查询；图6显示了一个查询，它是“N最近”和“在距离X内”的组合；图7显示了一个查询，它是“N最近”和“服务对象”的组合。当收到此类查询时，丢失的服务器将返回不超过20个兴趣点的列表。
If the available points of interest are more than N, the server has to identify, among those, the N points of interest closest to the client's physical location and MUST return those in the response.
如果可用兴趣点超过N个，则服务器必须在这些兴趣点中识别距离客户端物理位置最近的N个兴趣点，并且必须在响应中返回这些兴趣点。
When the <limit> element is not present in a <findService> query, then all available points of interest for the requested type of service SHOULD be returned by the LoST server. This behavior is consistent with [RFC5222].
当<findService>查询中不存在<limit>元素时，丢失的服务器应返回所请求服务类型的所有可用兴趣点。此行为与[RFC5222]一致。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
serviceBoundary="value" recursive="true">
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>40.7128 -74.0092</gml:pos>
</gml:Point>
</location>
<service>urn:service:food.pizza</service>
</findService>
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
serviceBoundary="value" recursive="true">
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>40.7128 -74.0092</gml:pos>
</gml:Point>
</location>
<service>urn:service:food.pizza</service>
</findService>
Figure 5: An "N nearest" <findService> geodetic query with the new
<limit> element (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figure 5: An "N nearest" <findService> geodetic query with the new
<limit> element (a hypothetical service URN of
"urn:service:food.pizza" is used)
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
Figure 6: A <findService> geodetic query with the new <limit> and
<region> elements. This query is a combination of the "N nearest"
and "within distance X" queries (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figure 6: A <findService> geodetic query with the new <limit> and
<region> elements. This query is a combination of the "N nearest"
and "within distance X" queries (a hypothetical service URN of
"urn:service:food.pizza" is used)
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>true</ext:region>
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
100
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>true</ext:region>
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
100
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>
Figure 7: A <findService> geodetic query with the new <limit> and
<region> elements. This query is a combination of the "N nearest"
and "served by" queries (a hypothetical service URN of
"urn:service:food.pizza" is used)
Figure 7: A <findService> geodetic query with the new <limit> and
<region> elements. This query is a combination of the "N nearest"
and "served by" queries (a hypothetical service URN of
"urn:service:food.pizza" is used)
It is important for the LoST client to know the location of a point of interest so that distance, route, and other metrics can be computed. We introduce a new element, namely <serviceLocation>. The <serviceLocation> element contains the location of a point of service. When it is used, it MUST be contained in a <mapping> element. In responses such as <findServiceResponse> [RFC5222], a list of service URIs, each with its own <serviceLocation> element, SHOULD be returned. The order of service URIs in the list is not significant.
对于丢失的客户来说，了解感兴趣点的位置非常重要，这样可以计算距离、路线和其他指标。我们引入一个新元素，即<serviceLocation>。<serviceLocation>元素包含服务点的位置。使用时，它必须包含在<mapping>元素中。在诸如<findServiceResponse>[RFC5222]之类的响应中，应该返回服务URI的列表，每个URI都有自己的<serviceLocation>元素。列表中服务URI的顺序不重要。
The <serviceLocation> element has a single attribute, "profile", that specifies the profile used. Both civic and geodetic profiles can be used. The geodetic profiles SHOULD be used in order to compute distance, route, and other metrics as, at some point, computing such metrics would require geocoding of the civic address in geodetic coordinates. Because of this, the position specified in <serviceLocation> with a geodetic profile SHOULD be represented by the <Point> element. The <Point> element is described in Section
<serviceLocation>元素有一个属性“profile”，用于指定所使用的概要文件。公民和大地剖面均可使用。应使用大地测量剖面来计算距离、路线和其他指标，因为在某些情况下，计算此类指标需要在大地坐标中对市政地址进行地理编码。因此，<serviceLocation>中指定的具有大地测量轮廓的位置应使用<Point>元素表示。第节介绍了<Point>元素
12.2 of [RFC5222] and in Section 5.2.1 of [RFC5491]. Figure 8 shows a <findServiceResponse> answer containing two location-to-service-URI mappings.
12.2 [RFC5222]和[RFC5491]第5.2.1节。图8显示了包含两个位置到服务URI映射的<findServiceResponse>答案。
[NOTE: The <locationUsed> element cannot be extended for this
purpose, as it is defined outside of the <mapping> element. In
particular, in a response, the <locationUsed> element is always one,
while the number of service URIs is typically more than one.]
[NOTE: The <locationUsed> element cannot be extended for this
purpose, as it is defined outside of the <mapping> element. In
particular, in a response, the <locationUsed> element is always one,
while the number of service URIs is typically more than one.]
There are situations, however, in which it is helpful to include a civic address together with the geodetic coordinates of a point of service. Usually, databases already contain the civic address of points of interest, and for devices with limited capabilities, it is not always possible to perform decoding of geocoordinates in order to determine the civic address. Because of this, including the civic address in a response can be useful. In order to do this, we use a civic profile for the <serviceLocation> element and specify the POI civic address in a <civicAddress> element contained in the <serviceLocation> element. The basic civic location profile is defined in Section 12.3 of [RFC5222].
但是，在某些情况下，将市政地址与服务点的大地坐标一起包含是有帮助的。通常，数据库已经包含感兴趣点的公民地址，对于能力有限的设备，并不总是能够执行地理坐标解码以确定公民地址。因此，在回应中包括公民演说可能是有用的。为了做到这一点，我们为<serviceLocation>元素使用civic配置文件，并在<serviceLocation>元素中包含的<civicAddress>元素中指定POI civic address。[RFC5222]第12.3节定义了基本的市政位置概况。
Per [RFC5139], it is RECOMMENDED to use multiple <serviceLocation> elements when multiple forms of service location are available, and it is RECOMMENDED to provide a geodetic form whenever possible. When multiple <serviceLocation> elements are present for one POI, all of them MUST be contained in the same <mapping> element, that is, the <mapping> element for that POI. Figure 8 shows a <findServiceResponse> answer with both geodetic and civic locations.
根据[RFC5139]，当多种形式的服务位置可用时，建议使用多个<serviceLocation>元素，并且建议尽可能提供大地测量形式。当一个POI存在多个<serviceLocation>元素时，所有元素都必须包含在同一<mapping>元素中，即该POI的<mapping>元素中。图8显示了一个<findServiceResponse>答案，包括大地测量和城市位置。
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="it">
Che bella pizza e all' anima da' pizza da Toto'
</displayName>
<service>urn:service:food.pizza</service>
<uri>sip:chebella@example.com</uri>
<uri>xmpp:chebella@example.com</uri>
<serviceNumber>2129397040</serviceNumber>
<ext:serviceLocation profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="it">
Che bella pizza e all' anima da' pizza da Toto'
</displayName>
<service>urn:service:food.pizza</service>
<uri>sip:chebella@example.com</uri>
<uri>xmpp:chebella@example.com</uri>
<serviceNumber>2129397040</serviceNumber>
<ext:serviceLocation profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>33.665 -112.432</gml:pos>
</gml:Point>
</ext:serviceLocation>
<ext:serviceLocation profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
<A6>Broadway</A6>
<HNO>321</HNO>
<PC>10027</PC>
</civicAddress>
</ext:serviceLocation>
</mapping>
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9b356">
<displayName xml:lang="en">
King Mario's Pizza
</displayName>
<service>urn:service:food.pizza</service>
<uri>sip:marios@example.com</uri>
<uri>xmpp:marios@example.com</uri>
<serviceNumber>2129397157</serviceNumber>
<ext:serviceLocation profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>33.683 -112.412</gml:pos>
</gml:Point>
</ext:serviceLocation>
<ext:serviceLocation profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
<A6>Amsterdam Avenue</A6>
<HNO>123</HNO>
<PC>10027</PC>
</civicAddress>
</ext:serviceLocation>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<gml:pos>33.665 -112.432</gml:pos>
</gml:Point>
</ext:serviceLocation>
<ext:serviceLocation profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
<A6>Broadway</A6>
<HNO>321</HNO>
<PC>10027</PC>
</civicAddress>
</ext:serviceLocation>
</mapping>
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9b356">
<displayName xml:lang="en">
King Mario's Pizza
</displayName>
<service>urn:service:food.pizza</service>
<uri>sip:marios@example.com</uri>
<uri>xmpp:marios@example.com</uri>
<serviceNumber>2129397157</serviceNumber>
<ext:serviceLocation profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>33.683 -112.412</gml:pos>
</gml:Point>
</ext:serviceLocation>
<ext:serviceLocation profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
<A6>Amsterdam Avenue</A6>
<HNO>123</HNO>
<PC>10027</PC>
</civicAddress>
</ext:serviceLocation>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
Figure 8: A <findServiceResponse> answer
Figure 8: A <findServiceResponse> answer
The LoST extensions defined in this document SHOULD NOT be used when routing emergency sessions, as there may be LoST servers that do not support these extensions.
在路由紧急会话时，不应使用本文档中定义的丢失的扩展，因为可能存在不支持这些扩展的丢失服务器。
Figure 9 shows a <findService> query for emergency services as defined in [RFC5222]. In such a query, both the <region> element and the <limit> element are missing. According to the LoST extensions defined in this document, when the <region> element is missing, its value defaults to true, and the query is a "served by" query (see Section 5.3). When the <limit> element is missing, no limit is specified, that is, the LoST server can return any number of results (see Section 5.4). This behavior is consistent with [RFC5222] so that PSAPs are selected according to their service area, and when a user's location overlaps multiple service areas, the LoST server MAY return multiple PSAPs.
图9显示了[RFC5222]中定义的紧急服务的<findService>查询。在这样的查询中，<region>元素和<limit>元素都丢失了。根据本文档中定义的丢失扩展，当<region>元素丢失时，其值默认为true，查询为“服务者”查询（参见第5.3节）。当<limit>元素丢失时，不指定限制，即丢失的服务器可以返回任意数量的结果（参见第5.4节）。此行为与[RFC5222]一致，因此PSAP是根据其服务区域选择的，当用户的位置与多个服务区域重叠时，丢失的服务器可能会返回多个PSAP。
The LoST extensions defined in this document are consistent with the behavior defined in [RFC5222], and, as such, they do not modify LoST behavior for emergency services.
本文件中定义的丢失扩展与[RFC5222]中定义的行为一致，因此，它们不会修改紧急服务的丢失行为。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
</findService>
</findService>
Figure 9: A <findService> geodetic query for emergency services
Figure 9: A <findService> geodetic query for emergency services
Unlike emergency services, where information such as service boundaries of PSAPs and locations of fire stations does not change very often, if at all, non-emergency services have information that
与紧急服务不同，在紧急服务中，PSAP的服务边界和消防站的位置等信息不会经常更改（如果有的话），非紧急服务的信息
may become inaccurate quickly. Implementers should take this into account when designing applications for non-emergency location-based services.
可能很快就会变得不准确。在为非紧急位置服务设计应用程序时，实现者应该考虑到这一点。
This section provides the RELAX NG schema of LoST extensions in the compact form. The verbose form is included in Section 9.
本节以紧凑的形式提供丢失扩展的RELAXNG模式。详细表格包含在第9节中。
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
##
## Extensions to the Location-to-Service Translation (LoST)
## Protocol
##
## Extensions to the Location-to-Service Translation (LoST)
## Protocol
##
## LoST Extensions define three new elements: limit, region, and
## serviceLocation.
##
start =
limit
| region
| serviceLocation
##
## LoST Extensions define three new elements: limit, region, and
## serviceLocation.
##
start =
limit
| region
| serviceLocation
##
## A limit to the number of returned results.
##
div {
limit=
element limit {
xsd:positiveInteger
}
}
##
## A limit to the number of returned results.
##
div {
limit=
element limit {
xsd:positiveInteger
}
}
##
## A boolean variable to request a search
## based on either service areas or distance.
##
## NOTE: The W3C XML Schema has two different
## lexical representations for boolean:
## '1' or 'true' vs. '0' or 'false'.
##
div {
region=
element region {
xsd:boolean
}
##
## A boolean variable to request a search
## based on either service areas or distance.
##
## NOTE: The W3C XML Schema has two different
## lexical representations for boolean:
## '1' or 'true' vs. '0' or 'false'.
##
div {
region=
element region {
xsd:boolean
}
}
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Location Information about the returned point
## of service.
##
div {
serviceLocation=
element serviceLocation { locationInformation }+
}
##
## Location Information about the returned point
## of service.
##
div {
serviceLocation=
element serviceLocation { locationInformation }+
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST Extensions
## namespace.
##
notLostExt = element * - (ns1:* | ns1:*) { anyElement }
##
## Any element not in the LoST Extensions
## namespace.
##
notLostExt = element * - (ns1:* | ns1:*) { anyElement }
##
## A wildcard pattern for including any element
## from any other namespace.
##
anyElement =
(element * { anyElement }
| attribute * { text }
| text)*
##
## A wildcard pattern for including any element
## from any other namespace.
##
anyElement =
(element * { anyElement }
| attribute * { text }
| text)*
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLostExt*
}
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLostExt*
}
The overall LoST architecture and framework are defined in [RFC5582]. All LoST queries for both emergency and non-emergency services, if not cached, are sent from the LoST client to a first-hop LoST server. In [RFC5582] terminology, a LoST client is called Seeker, and the first-hop LoST server is called Resolver (for more rigorous definitions, please refer to [RFC5582]). The Resolver will contact other LoST servers, and eventually an authoritative LoST server will be found. A response will then be sent back to the Seeker.
[RFC5582]中定义了总体架构和框架。紧急和非紧急服务的所有丢失查询（如果未缓存）都将从丢失的客户端发送到第一跳丢失服务器。在[RFC5582]术语中，丢失的客户端称为寻道器，第一跳丢失的服务器称为解析器（有关更严格的定义，请参阅[RFC5582]）。解析程序将联系其他丢失的服务器，最终将找到权威的丢失服务器。然后将响应发送回导引头。
When considering both emergency and non-emergency services, there is the possibility of the Resolver getting overloaded by non-emergency-service queries, thus being unable to process emergency-service queries. Such a situation can be addressed in several ways. For example, the service provider could dimension the LoST server to accommodate anticipated combined traffic loads and then give priority to emergency service requests during overload situations, possibly with the help of HTTP load balancers.
当同时考虑紧急和非紧急服务时，解析程序可能因非紧急服务查询而过载，因此无法处理紧急服务查询。这种情况可以通过几种方式解决。例如，服务提供商可以对丢失的服务器进行尺寸调整，以适应预期的组合流量负载，然后在过载情况下优先处理紧急服务请求，可能需要借助HTTP负载平衡器。
The security considerations in [RFC5222] apply. In particular, in order to maintain integrity and confidentiality of requests and responses, Transport Layer Security (TLS) MUST be implemented and SHOULD be used as described in Sections 1, 14, and 18 of [RFC5222].
[RFC5222]中的安全注意事项适用。特别是，为了保持请求和响应的完整性和机密性，必须实施传输层安全（TLS），并应按照[RFC5222]第1、14和18节的说明使用。
URI: urn:ietf:params:xml:schema:lost-ext
URI: urn:ietf:params:xml:schema:lost-ext
Registrant Contact: Andrea G. Forte, forte@att.com;
Henning Schulzrinne, hgs@cs.columbia.edu
Registrant Contact: Andrea G. Forte, forte@att.com;
Henning Schulzrinne, hgs@cs.columbia.edu
RELAX NG Schema: The RELAX NG schema to be registered is contained in Section 7. Its first line is
RELAXNG模式：要注册的RELAXNG模式包含在第7节中。它的第一行是
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
and its last line is
最后一行是
}
}
URI: urn:ietf:params:xml:ns:lost-ext
URI: urn:ietf:params:xml:ns:lost-ext
Registrant Contact: Andrea G. Forte, forte@att.com;
Henning Schulzrinne, hgs@cs.columbia.edu
Registrant Contact: Andrea G. Forte, forte@att.com;
Henning Schulzrinne, hgs@cs.columbia.edu
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Extensions Namespace</title>
</head>
<body>
<h1>Namespace for LoST Extensions</h1>
<h2>urn:ietf:params:xml:ns:lost-ext</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6451.txt">
RFC 6451</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Extensions Namespace</title>
</head>
<body>
<h1>Namespace for LoST Extensions</h1>
<h2>urn:ietf:params:xml:ns:lost-ext</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6451.txt">
RFC 6451</a>.</p>
</body>
</html>
END
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost-ext"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost-ext"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
Extensions to the Location-to-Service Translation (LoST)
Protocol.
LoST Extensions define three new elements: limit, region and
serviceLocation.
</a:documentation>
<choice>
<ref name="limit"/>
<ref name="region"/>
<ref name="serviceLocation"/>
</choice>
<start>
<a:documentation>
Extensions to the Location-to-Service Translation (LoST)
Protocol.
LoST Extensions define three new elements: limit, region and
serviceLocation.
</a:documentation>
<choice>
<ref name="limit"/>
<ref name="region"/>
<ref name="serviceLocation"/>
</choice>
</start>
</start>
<div>
<a:documentation>
A limit to the number of returned results.
</a:documentation>
<div>
<a:documentation>
A limit to the number of returned results.
</a:documentation>
<define name="limit">
<element name="limit">
<data type="positiveInteger"/>
</element>
</define>
</div>
<define name="limit">
<element name="limit">
<data type="positiveInteger"/>
</element>
</define>
</div>
<div>
<a:documentation>
A boolean variable to request a search
based on either service areas or distance.
</a:documentation>
<div>
<a:documentation>
A boolean variable to request a search
based on either service areas or distance.
</a:documentation>
<define name="region">
<element name="region">
<data type="boolean"/>
</element>
</define>
</div>
<define name="region">
<element name="region">
<data type="boolean"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location Information
</a:documentation>
<div>
<a:documentation>
Location Information
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
</attribute>
</optional>
</define>
</div>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
Location Information about the returned point of service.
</a:documentation>
<div>
<a:documentation>
Location Information about the returned point of service.
</a:documentation>
<define name="serviceLocation">
<element name="serviceLocation">
<ref name="locationInformation"/>
</element>
</define>
</div>
<define name="serviceLocation">
<element name="serviceLocation">
<ref name="locationInformation"/>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLostExt">
<a:documentation>
Any element not in the LoST Extensions namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost-ext"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="notLostExt">
<a:documentation>
Any element not in the LoST Extensions namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost-ext"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any element
from any other namespace.
</a:documentation>
<zeroOrMore>
<choice>
<element>
<anyName/>
<ref name="anyElement"/>
</element>
<attribute>
<anyName/>
</attribute>
<text/>
</choice>
</zeroOrMore>
</define>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any element
from any other namespace.
</a:documentation>
<zeroOrMore>
<choice>
<element>
<anyName/>
<ref name="anyElement"/>
</element>
<attribute>
<anyName/>
</attribute>
<text/>
</choice>
</zeroOrMore>
</define>
<define name="extensionPoint">
<define name="extensionPoint">
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="notLostExt"/>
</zeroOrMore>
</define>
</div>
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="notLostExt"/>
</zeroOrMore>
</define>
</div>
</grammar>
</grammar>
We would like to thank Shida Schubert for reviewing an early version of this document. We also appreciate the suggestions from members of the ECRIT working group. In particular, we are grateful to Richard L. Barnes, Robert Sparks, and Martin Thomson for their overall feedback and for their comments on how non-emergency services may affect the provisioning of emergency services lookups.
我们感谢Shida Schubert审阅了本文件的早期版本。我们也赞赏ECRIT工作组成员的建议。我们特别感谢Richard L.Barnes、Robert Sparks和Martin Thomson的全面反馈，以及他们对非紧急服务如何影响紧急服务查找的提供的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139]Thomson，M.和J.Winterbottom，“状态信息数据格式位置对象（PIDF-LO）的修订公民位置格式”，RFC 5139，2008年2月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491]Winterbottom，J.，Thomson，M.，和H.Tschofenig，“GEOPRIV存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，RFC 54912009年3月。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.
[RFC5582]Schulzrinne，H.，“位置到URL映射体系结构和框架”，RFC5822009年9月。
Authors' Addresses
作者地址
Andrea G. Forte AT&T Security Research Center 33 Thomas Street New York, NY 10007 USA
Andrea G.Forte AT&T安全研究中心美国纽约州纽约市托马斯街33号，邮编10007
EMail: forte@att.com
EMail: forte@att.com
Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号亨宁·舒尔兹林内哥伦比亚大学计算机科学系，邮编：10027
EMail: hgs@cs.columbia.edu
EMail: hgs@cs.columbia.edu