Internet Engineering Task Force (IETF) K. Wolf
Request for Comments: 6197 nic.at
Category: Experimental April 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Wolf
Request for Comments: 6197 nic.at
Category: Experimental April 2011
ISSN: 2070-1721
Location-to-Service Translation (LoST) Service List Boundary Extension
位置到服务转换（丢失）服务列表边界扩展
Abstract
摘要
Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving.
位置到服务转换（丢失）将服务标识符和位置信息映射到服务联系人URI。如果丢失的客户端希望发现特定位置的可用服务，它将对丢失的服务器执行<listServicesByLocation>查询。但是，丢失的服务器在其响应中不提供上下文信息；也就是说，它没有提供任何关于返回的服务列表被视为有效的地理区域的额外信息。因此，本文档定义了一个服务列表边界，该边界返回本地上下文和返回的服务列表，以帮助客户端在移动时不丢失可用服务中的更改。
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/rfc6197.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6197.
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 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. LoST Extensions .................................................4
3.1. Extensions to <listServicesByLocation> .....................4
3.2. Retrieving the <serviceListBoundary> via
<getServiceListBoundary> ...................................7
3.3. <serviceListBoundary> ......................................8
3.4. Implementation Considerations ..............................9
3.4.1. Server Side .........................................9
3.4.2. Client Side .........................................9
4. Security and Privacy Considerations ............................10
5. IANA Considerations ............................................10
5.1. Relax NG Schema Registration ..............................10
5.2. Namespace Registration ....................................13
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
1. Introduction ....................................................3
2. Terminology .....................................................4
3. LoST Extensions .................................................4
3.1. Extensions to <listServicesByLocation> .....................4
3.2. Retrieving the <serviceListBoundary> via
<getServiceListBoundary> ...................................7
3.3. <serviceListBoundary> ......................................8
3.4. Implementation Considerations ..............................9
3.4.1. Server Side .........................................9
3.4.2. Client Side .........................................9
4. Security and Privacy Considerations ............................10
5. IANA Considerations ............................................10
5.1. Relax NG Schema Registration ..............................10
5.2. Namespace Registration ....................................13
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Since the LoST protocol [RFC5222] employs the Service Boundary concept in order to avoid having clients continuously trying to refresh the mapping of a specific service, a Service List Boundary mechanism provides similar advantages for Service Lists.
由于丢失协议[RFC5222]采用服务边界概念以避免客户端不断尝试刷新特定服务的映射，因此服务列表边界机制为服务列表提供了类似的优势。
Location-based service providers, as well as Public Safety Answering Points (PSAPs), only serve a specific geographic region. Therefore, the LoST protocol defines the Service Boundary, which indicates the service region for a specific service URL. However, not all services are available everywhere. Clients can discover available services for a particular location via the <listServicesByLocation> query in LoST. The LoST server returns a list of services that are available at this particular location, but the server does not provide any additional information about the geographical region within which the returned Service List is considered valid. This may lead to the situation where a client initially discovers all available services via the <listServicesByLocation> query, and then moves to a different location (while refreshing the service mappings), but without noticing the availability of other services. The following imaginary example illustrates the problem for emergency calling:
基于位置的服务提供商以及公共安全应答点（PSAP）只服务于特定的地理区域。因此，LoST协议定义了服务边界，该边界指示特定服务URL的服务区域。然而，并非所有的服务都可以在任何地方获得。客户端可以通过LoST中的<listServicesByLocation>查询来发现特定位置的可用服务。丢失的服务器返回在此特定位置可用的服务列表，但服务器不提供有关所返回服务列表被视为有效的地理区域的任何其他信息。这可能会导致这样的情况：客户机最初通过<listServicesByLocation>查询发现所有可用服务，然后移动到不同的位置（刷新服务映射时），但没有注意到其他服务的可用性。以下虚构示例说明了紧急呼叫的问题：
The client is powered-up, does location determination (resulting in location A), and performs an initial <listServicesByLocation> query with location A requesting urn:services:sos.
客户端通电，进行位置确定（导致位置A），并对请求urn:services:sos的位置A执行初始<listServicesByLocation>查询。
The LoST server returns the following list of services:
丢失的服务器返回以下服务列表：
urn:service:sos.police
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.police
urn:service:sos.ambulance
urn:service:sos.fire
The client does the initial LoST mapping and discovers the dialstrings for each service. Then the client moves, refreshing the individual service mappings when necessary as specified by the Service Boundary. However, when arriving in location B (close to a mountain), service sos.mountainrescue, which was not available in location A, becomes available. Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected. Consequently, the dialstring for the mountain-rescue service is not known by the client. Hence, the client is unable to recognize an emergency call when the user enters the dialstring of the mountain-rescue service, and the emergency call may fail altogether.
客户端执行初始丢失映射并发现每个服务的拨号字符串。然后，客户端移动，根据服务边界的指定，在必要时刷新各个服务映射。但是，当到达位置B（靠近山区）时，位置a中不可用的sos.mountainrescue服务将可用。由于只需要客户端刷新最初发现的服务的映射，因此不会检测到新服务。因此，客户端不知道山地救援服务的拨号字符串。因此，当用户输入山地救援服务的拨号串时，客户端无法识别紧急呼叫，并且紧急呼叫可能完全失败。
Note that the Service Boundary (service region for an individual service) cannot be considered as an indicator for the region for which a specific Service List is valid. The Service List may even change within the Service Boundary of another service. For example, the ambulance mapping is valid for a whole state, but for a part of the state there is an additional mountain-rescue service.
请注意，服务边界（单个服务的服务区域）不能被视为特定服务列表有效区域的指示器。服务列表甚至可能在另一个服务的服务边界内更改。例如，救护车地图适用于整个州，但对于该州的一部分，有额外的山地救援服务。
Consequently, there are two ways to tackle this issue:
因此，有两种方法来解决这个问题：
o Clients continuously poll for the Service List, although it may not have changed.
o 客户端不断轮询服务列表，尽管它可能没有更改。
o The server sends a message containing boundary information that tells the client that the Service List does not change inside this area.
o 服务器发送一条包含边界信息的消息，告知客户端此区域内的服务列表没有更改。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section describes the necessary extensions to the LoST protocol in order to support the Service List Boundary in a similar way as the Service Boundary. Extensions defined in this document are declared in the new XML namespace urn:ietf:params:xml:ns:lost1:slb.
本节描述丢失协议的必要扩展，以便以与服务边界类似的方式支持服务列表边界。本文档中定义的扩展在新的XML命名空间urn:ietf:params:XML:ns:lost1:slb中声明。
The query <listServicesByLocation> may contain an additional <serviceListBoundaryRequest> element to additionally request the boundary for the Service List based on the location provided, with the resulting location for the list presented either by value or by reference. In the example below, the value of the 'type' attribute of the <serviceListBoundaryRequest> element is set to "value":
查询<listServicesByLocation>可能包含一个额外的<serviceListBoundaryRequest>元素，根据提供的位置额外请求服务列表的边界，列表的结果位置通过值或引用表示。在下面的示例中，<serviceListBoundaryRequest>元素的“type”属性的值设置为“value”：
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"
recursive="true">
<location id="5415203asdf548" profile="civic">
<civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
<A2>Bruck an der Leitha</A2>
<A3>Wolfsthal</A3>
<RD>Hauptplatz</RD>
<HNO>1</HNO>
<PC>2412</PC>
</civicAddress>
</location>
<service>urn:service:sos</service>
<slb:serviceListBoundaryRequest type="value"/>
</listServicesByLocation>
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"
recursive="true">
<location id="5415203asdf548" profile="civic">
<civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
<A2>Bruck an der Leitha</A2>
<A3>Wolfsthal</A3>
<RD>Hauptplatz</RD>
<HNO>1</HNO>
<PC>2412</PC>
</civicAddress>
</location>
<service>urn:service:sos</service>
<slb:serviceListBoundaryRequest type="value"/>
</listServicesByLocation>
A <listServicesByLocationResponse> with the addition of one <serviceListBoundary> element is shown below:
添加了一个<serviceListBoundary>元素的<listServicesByLocationResponse>如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="5415203asdf548"/>
<slb:serviceListBoundary profile="civic"
expires="2012-01-01T00:00:00Z">
<civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
</civicAddress>
</slb:serviceListBoundary>
</listServicesByLocationResponse>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="5415203asdf548"/>
<slb:serviceListBoundary profile="civic"
expires="2012-01-01T00:00:00Z">
<civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
</civicAddress>
</slb:serviceListBoundary>
</listServicesByLocationResponse>
The response above indicates that the Service List is valid for Lower Austria. The <listServicesByLocation> request needs to be repeated by the client only when moving out of Lower Austria. However, the mappings of the services themselves may have other service boundaries. Additionally, the 'expires' attribute indicates the absolute time when this Service List becomes invalid.
上面的响应表明服务列表对较低级别的用户有效。<listServicesByLocation>请求仅在移出下奥地利州时需要由客户端重复。但是，服务本身的映射可能有其他服务边界。此外，“expires”属性表示此服务列表无效的绝对时间。
The response MAY contain multiple <serviceListBoundary> elements for alternative representation, each representing the boundary in a specific location profile. However, multiple locations inside a <serviceListBoundary> element are considered to be additive.
响应可能包含多个用于替代表示的<serviceListBoundary>元素，每个元素表示特定位置配置文件中的边界。但是，<serviceListBoundary>元素内的多个位置被认为是可添加的。
The boundary can also be requested by reference when setting the value of the 'type' attribute of the <serviceListBoundaryRequest> element to "reference" (which is the default in case the attribute is omitted). The response will contain a <serviceListBoundaryReference> element with a 'serviceListKey' attribute (described in Section 3.2), as shown below.
当将<serviceListBoundaryRequest>元素的“type”属性的值设置为“reference”（如果省略该属性，这是默认值）时，也可以通过引用请求边界。响应将包含一个带有“serviceListKey”属性的<serviceListBoundaryReference>元素（如第3.2节所述），如下所示。
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="5415203asdf548"/>
<slb:serviceListBoundaryReference
source="authoritative.example"
serviceListKey="123567890123567890123567890" />
</listServicesByLocationResponse>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="5415203asdf548"/>
<slb:serviceListBoundaryReference
source="authoritative.example"
serviceListKey="123567890123567890123567890" />
</listServicesByLocationResponse>
In order to retrieve the boundary corresponding to a specific 'serviceListKey', the client issues a <getServiceListBoundary> request to the server identified in the 'source' attribute of the <serviceListBoundaryReference> element, similar to the <getServiceBoundary> request.
为了检索对应于特定“serviceListKey”的边界，客户端向<serviceListBoundaryReference>元素的“源”属性中标识的服务器发出<getServiceListBoundary>请求，类似于<getServiceBoundary>请求。
An example is shown below:
示例如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundary
xmlns="urn:ietf:params:xml:ns:lost1:slb"
serviceListKey="123567890123567890123567890"/>
<?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundary
xmlns="urn:ietf:params:xml:ns:lost1:slb"
serviceListKey="123567890123567890123567890"/>
The LoST server response is shown below:
丢失的服务器响应如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1:slb">
<serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z">
<civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
</civicAddress>
</serviceListBoundary>
<path xmlns="urn:ietf:params:xml:ns:lost1">
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</getServiceListBoundaryResponse>
<?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1:slb">
<serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z">
<civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
</civicAddress>
</serviceListBoundary>
<path xmlns="urn:ietf:params:xml:ns:lost1">
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</getServiceListBoundaryResponse>
The 'serviceListKey' uniquely identifies a Service List Boundary, as the 'key' does for the Service Boundary (see Section 5.6 of RFC 5222). Therefore, the 'serviceListKey' is a random token with at least 128 bits of entropy [RFC4086] and can be assumed globally unique. Whenever the boundary changes, a new 'serviceListKey' MUST be assigned.
“serviceListKey”唯一标识服务列表边界，正如“key”对服务边界所做的那样（参见RFC 5222第5.6节）。因此，“serviceListKey”是具有至少128位熵[RFC4086]的随机令牌，并且可以假定其全局唯一。每当边界更改时，必须分配新的“serviceListKey”。
Note: Since LoST does not define an attribute to indicate which location profile the client understands in a <getServiceBoundary> request, this document also does not define one for the <getServiceListBoundary> request.
注意：由于LoST没有定义属性来指示客户端在<getServiceBoundary>请求中理解的位置配置文件，因此本文档也没有为<getServiceListBoundary>请求定义一个属性。
For a particular <listServicesByLocation> query, the Service List Boundary information that gets returned indicates that all the service identifiers returned in the <serviceList> element are the same within this geographic region. A Service List Boundary may consist of geometric shapes (both in civic and geodetic location format), and may be non-contiguous, like the Service Boundary.
对于特定的<listServicesByLocation>查询，返回的服务列表边界信息表明<serviceList>元素中返回的所有服务标识符在此地理区域内是相同的。服务列表边界可以由几何形状（公民和大地位置格式）组成，并且可以是非连续的，就像服务边界一样。
The mapping of the specific services within the Service List Boundary may be different at different locations.
服务列表边界内特定服务的映射在不同位置可能不同。
The server MAY return the boundary information in multiple location profiles, but MUST use at least one profile that the client used in the request in order to ensure that the client is able to process the boundary information.
服务器可以在多个位置配置文件中返回边界信息，但必须使用客户端在请求中使用的至少一个配置文件，以确保客户端能够处理边界信息。
There is no need to include boundary information in a <listServicesResponse>. The <listServices> request is purely for diagnostic purposes and does not contain location information at all, so boundary information cannot be calculated.
无需在<listServicesResponse>中包含边界信息。<listServices>请求纯粹用于诊断目的，根本不包含位置信息，因此无法计算边界信息。
Also note that the Service List Boundary is OPTIONAL, and the LoST server may return it or not, based on its local policy -- as is the case with the Service Boundary. However, especially for emergency services, the Service List Boundary might be crucial to ensure that moving clients do not miss changes in the available services.
还请注意，服务列表边界是可选的，丢失的服务器可能会根据其本地策略返回它，也可能不会返回，服务边界就是这样。但是，特别是对于紧急服务，服务列表边界对于确保移动客户端不会错过可用服务中的更改可能至关重要。
The subsections below discuss implementation issues for the LoST server and client for Service List Boundary support.
下面的小节讨论服务列表边界支持丢失的服务器和客户端的实现问题。
The mapping architecture and framework [RFC5582] states that each tree announces its coverage region (for one type of service, e.g., sos.police) to one or more forest guides. Forest guides peer with each other and synchronize their data. Hence, a forest guide has sufficient knowledge (it knows all the services and their coverage regions) to answer a <listServicesByLocation> query and to add the <serviceListBoundary> or <serviceListBoundaryReference> as well.
映射体系结构和框架[RFC5582]指出，每个树向一个或多个林指南宣布其覆盖区域（对于一种类型的服务，例如sos.police）。林向导彼此对等并同步其数据。因此，林指南有足够的知识（它知道所有服务及其覆盖区域）来回答<listServicesByLocation>查询并添加<serviceListBoundary>或<serviceListBoundaryReference>。
The calculation of the largest possible area for which the Service List stays the same might be a complex task. An alternative would be to return smaller areas that are easier to compute. In such a case, some unnecessary queries to the LoST server will be a consequence, but the main purpose of the Service List Boundary is still achieved: to never miss a change of available services. Thus, the server operator may specify a reasonable trade-off between the effort to generate the boundary information and the saved queries to the LoST server.
计算服务列表保持不变的最大可能区域可能是一项复杂的任务。另一种方法是返回更容易计算的较小区域。在这种情况下，对丢失的服务器进行一些不必要的查询将是一个结果，但服务列表边界的主要目的仍然实现了：永远不要错过可用服务的更改。因此，服务器操作员可以在生成边界信息的努力和保存到丢失服务器的查询之间指定合理的权衡。
For example, in some countries the offered services may differ in adjacent counties (or districts, cantons, states, etc.). Their borders may be suitable as a Service List Boundary as well, even though some adjacent counties offer the same services.
例如，在某些国家，相邻县（或地区、州、州等）提供的服务可能不同。它们的边界可能也适合作为服务列表边界，即使一些相邻的县提供相同的服务。
Other countries might have different structures, and the generation of the Service List Boundary might follow other rules as long as it is ensured that a client is able to notice any change in the Service List when moving.
其他国家可能有不同的结构，服务列表边界的生成可能遵循其他规则，只要确保客户端能够在移动时注意到服务列表中的任何更改。
A mobile client that already implements LoST and evaluates the <serviceBoundary> has almost everything that is needed to make use of the Service List Boundary. Since the integration into LoST follows the concept of the <serviceBoundary> (and also makes use of the same location profiles), only the additional <serviceListBoundary> needs to be evaluated. Whenever moving outside a Service List Boundary, the client performs a new <listServicesByLocation> query with the new location information in order to determine a change in available services.
已经实现LoST并评估<servicebundary>的移动客户端几乎拥有使用服务列表边界所需的一切。由于与LoST的集成遵循了<serviceBoundary>的概念（并且还使用了相同的位置配置文件），因此只需要评估额外的<serviceListBoundary>。每当移动到服务列表边界之外时，客户机都会使用新的位置信息执行新的<listServicesByLocation>查询，以确定可用服务中的更改。
Security considerations for LoST are discussed in [RFC5222]. This document extends LoST to also carry Service List Boundaries (and requests for them). These Service List Boundaries are calculated by the server based on the individual Service Boundaries and sent to clients in case the local policy allows this. Therefore, it is generally considered to have the same level of sensitivity as for the Service Boundary and thus the same access control and confidentiality requirements as the base LoST protocol. As a result, the security measures incorporated in the base LoST specification [RFC5222] provide sufficient protection for LoST messages that use the Service List Boundary extension.
[RFC5222]中讨论了丢失信息的安全注意事项。本文档扩展了LoST，也包含服务列表边界（以及对它们的请求）。这些服务列表边界由服务器根据各个服务边界计算，并在本地策略允许的情况下发送给客户端。因此，一般认为它具有与服务边界相同的灵敏度，因此具有与基本丢失协议相同的访问控制和保密要求。因此，基本丢失规范[RFC5222]中包含的安全措施为使用服务列表边界扩展的丢失消息提供了足够的保护。
IANA has taken two actions: an XML schema registration and a namespace registration, according to the description in the following sections.
根据以下部分的描述，IANA采取了两个操作：XML模式注册和命名空间注册。
IANA has registered the following Relax NG Schema in the IETF XML Registry [RFC3688]:
IANA已在IETF XML注册表[RFC3688]中注册了以下Relax NG模式：
URI: urn:ietf:params:xml:schema:lost1:slb
URI: urn:ietf:params:xml:schema:lost1:slb
Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)
注册人联系人：IETF ECRIT工作组，Karl Heinz Wolf（karlheinz。wolf@nic.at)
Relax NG Schema:
RELAXNG模式：
BEGIN
开始
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"
ns="urn:ietf:params:xml:ns:lost1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="lost.rng">
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"
ns="urn:ietf:params:xml:ns:lost1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="lost.rng">
<!-- redefinition of LoST elements -->
<start>
<choice>
<ref name="findService"/>
<ref name="listServices"/>
<ref name="listServicesByLocation"/>
<ref name="getServiceBoundary"/>
<ref name="findServiceResponse"/>
<ref name="listServicesResponse"/>
<ref name="listServicesByLocationResponse"/>
<ref name="getServiceBoundaryResponse"/>
<ref name="errors"/>
<ref name="redirect"/>
<!-- redefinition of LoST elements -->
<start>
<choice>
<ref name="findService"/>
<ref name="listServices"/>
<ref name="listServicesByLocation"/>
<ref name="getServiceBoundary"/>
<ref name="findServiceResponse"/>
<ref name="listServicesResponse"/>
<ref name="listServicesByLocationResponse"/>
<ref name="getServiceBoundaryResponse"/>
<ref name="errors"/>
<ref name="redirect"/>
<!-- New in RFC 6197 -->
<ref name="getServiceListBoundary"/>
<ref name="getServiceListBoundaryResponse"/>
</choice>
</start>
<!-- New in RFC 6197 -->
<ref name="getServiceListBoundary"/>
<ref name="getServiceListBoundaryResponse"/>
</choice>
</start>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
<!-- New in RFC 6197 -->
<optional>
<ref name="serviceListBoundaryRequest"/>
</optional>
</element>
</define>
<!-- New in RFC 6197 -->
<optional>
<ref name="serviceListBoundaryRequest"/>
</optional>
</element>
</define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
<!-- New in RFC 6197 -->
<optional>
<choice>
<ref name="serviceListBoundary"/>
<ref name="serviceListBoundaryReference"/>
</choice>
</optional>
</element>
</define>
</include>
<!-- New in RFC 6197 -->
<optional>
<choice>
<ref name="serviceListBoundary"/>
<ref name="serviceListBoundaryReference"/>
</choice>
</optional>
</element>
</define>
</include>
<define name="serviceListBoundaryRequest">
<element name="slb:serviceListBoundaryRequest">
<optional>
<attribute name="type">
<choice>
<value>value</value>
<value>reference</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="serviceListBoundaryRequest">
<element name="slb:serviceListBoundaryRequest">
<optional>
<attribute name="type">
<choice>
<value>value</value>
<value>reference</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="serviceListBoundary">
<oneOrMore>
<element name="slb:serviceListBoundary">
<optional>
<ref name="expires"/>
</optional>
<ref name="locationInformation"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</define>
<define name="serviceListBoundary">
<oneOrMore>
<element name="slb:serviceListBoundary">
<optional>
<ref name="expires"/>
</optional>
<ref name="locationInformation"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</define>
<define name="serviceListBoundaryReference">
<element name="slb:serviceListBoundaryReference">
<ref name="source"/>
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="serviceListBoundaryReference">
<element name="slb:serviceListBoundaryReference">
<ref name="source"/>
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getServiceListBoundary">
<element name="slb:getServiceListBoundary">
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getServiceListBoundary">
<element name="slb:getServiceListBoundary">
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getServiceListBoundaryResponse">
<element name="slb:getServiceListBoundaryResponse">
<ref name="serviceListBoundary"/>
<ref name="path"/>
<ref name="extensionPoint"/>
</element>
</define>
</grammar>
<define name="getServiceListBoundaryResponse">
<element name="slb:getServiceListBoundaryResponse">
<ref name="serviceListBoundary"/>
<ref name="path"/>
<ref name="extensionPoint"/>
</element>
</define>
</grammar>
END
终止
IANA has registered the following namespace (below the LoST namespace defined in [RFC5222]) in the IETF XML Registry [RFC3688]:
IANA已在IETF XML注册表[RFC3688]中注册了以下名称空间（位于[RFC5222]中定义的丢失名称空间下方）：
URI: urn:ietf:params:xml:ns:lost1:slb
URI: urn:ietf:params:xml:ns:lost1:slb
Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)
注册人联系人：IETF ECRIT工作组，Karl Heinz Wolf（karlheinz。wolf@nic.at)
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 Service List Boundary Namespace</title>
</head>
<body>
<h1>Namespace for the LoST Service List Boundary</h1>
<h2>urn:ietf:params:xml:ns:lost1:slb</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6197.txt">
RFC 6197</a>.</p>
</body>
</html>
<?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 Service List Boundary Namespace</title>
</head>
<body>
<h1>Namespace for the LoST Service List Boundary</h1>
<h2>urn:ietf:params:xml:ns:lost1:slb</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6197.txt">
RFC 6197</a>.</p>
</body>
</html>
END
终止
The author would like to thank Henning Schulzrinne for discussion of the document, and Martin Thomson, Richard Barnes, and Roger Marshall for their valuable input and text suggestions during the working group Last Call. Further thanks go to Joshua Bell from the Applications Area Review Team for his help with Relax NG.
作者要感谢Henning Schulzrinne对该文件的讨论，以及Martin Thomson、Richard Barnes和Roger Marshall在工作组最后一次电话会议期间提出的宝贵意见和文本建议。进一步感谢应用领域审查团队的Joshua Bell对Relax NG的帮助。
[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月。
[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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.
[RFC5582]Schulzrinne，H.，“位置到URL映射体系结构和框架”，RFC5822009年9月。
Author's Address
作者地址
Karl Heinz Wolf nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria
卡尔·海因茨·沃尔夫nic.at股份有限公司卡尔斯普拉茨1/2/9维也纳A-1010奥地利
Phone: +43 1 5056416 37
EMail: karlheinz.wolf@nic.at
URI: http://www.nic.at/
Phone: +43 1 5056416 37
EMail: karlheinz.wolf@nic.at
URI: http://www.nic.at/