[要約] RFC 6451は、Location-to-Service Translation (LoST) プロトコルの拡張に関するものであり、位置情報をサービスに変換するための仕組みを提供する。目的は、VoIPやモバイル通信などのアプリケーションで位置情報を使用する際に、正確なサービスの特定とアクセスを可能にすることである。
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".
ロケーションベースのサービスの重要なクラスは、「このサービスのどの例が私に最も近いのか」という質問に答えます。例には、レストラン、ガソリンスタンド、店舗、自動窓口機械、ワイヤレスアクセスポイント（ホットスポット）、または駐車スペースを見つけることが含まれます。現在、場所からサービスへの翻訳（失われた）プロトコルは、サービス地域に基づいた単一のサービスへのマッピングロケーションのみをサポートしています。このドキュメントでは、「最も近く」、「距離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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。あなたの権利と制限を尊重して説明しているので、これらの文書を注意深く確認してください
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で説明されている法的規定のセクション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
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.
3つの追加<findService>クエリタイプで紛失し、プロトコルに特定のサービスの最も近いインスタンス、特定の距離内のすべてのサービス、およびユーザーの現在の場所を含むすべてのサービスをすべてのサービスを見つける機能を提供します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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")."
「ラウンド旅行を最小限に抑え、ネットワークの障害に対する堅牢性を提供するために、失われたものは個々のマッピングのキャッシュをサポートし、同じ答えが返される領域（「サービス領域」）を示します。」
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.
非緊急サービスの場合、さまざまなサービスポイントが異なる重複サービスエリアを持つ場合があります。これは、1つのサービス領域にはおそらく多数のサービスエリアが含まれることを意味します。クエリごとに多数のサービスURIを取得できるため、上記の定義ごとのサービス領域は、ユーザーが同じサービスセットを取得する領域になります。セットの1つ以上のURIが変更された場合、URISのセットが変更されます。つまり、サービス領域が変更されます。したがって、非緊急サービスの場合、[RFC5222]で定義されているサービス領域は頻繁に変化し、したがって、サービス領域ごとのキャッシュ応答の利点を大幅に削減します。
Generally speaking, we can divide location-based services into two main categories based on:
一般的に言えば、次のことに基づいて、ロケーションベースのサービスを2つの主要なカテゴリに分割できます。
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.
最初のカテゴリに含まれるサービスの場合、サービスエリア、したがってサービス領域は関連性がありませんが、2番目のカテゴリに含まれるサービスにとって重要です。この区別は、たとえばテイクアウト（最初のカテゴリ）と配信（2番目のカテゴリ）の違いを考慮すると明らかになります。テイクアウトの場合、ユーザーは特定のレストランに行って夕食を購入したいと考えています。配達のために、ユーザーはレストランがレストランサービスエリア内に収まる場合にのみ、レストランが食事を提供するため、レストランサービスエリアを気にします。
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. new <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.
3つの新しいタイプの<findService>クエリを紹介します：「n最も近い」、「距離x内」、「提供」。最初のクエリは、クライアントの物理的位置に最も近い目的（POI）を返します。2番目のクエリは、クライアントの物理的な場所から特定の距離内にあるすべての関心点を発見します。3番目のクエリは、サービスエリアにクライアントの現在の場所が含まれるすべての関心ポイントを返します。
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内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].
<region> <findservice> queriesの要素。[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、つまり、応答で返されるサービスの最大数を知らせる必要があります。これを指定するために、<sight>要素を<findService>クエリに導入します。
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」クエリは、ユーザーの位置の不確実性をパラメーター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内x」<findService>測地クエリを示しています。図1に示すクエリを使用して、<GML：POS>で指定された近似位置から200メートル以内のピザの場所のサービスURIのリストを送信するように失われたサーバーに求めています。
<?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)
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」<findservice>測地クエリを示しています。楕円形の形状は、[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>
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で述べたように、次のことに基づいて、ロケーションベースのサービスを2つの主要なカテゴリに分割できます。
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.
「distance x内」クエリは、最初のカテゴリに含まれるサービスをアドレス指定しますが、2番目のカテゴリに含まれる「クエリアドレスアドレスサービス」が「提供されます」。
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
特定のサービスに関して紛失した場合、そのようなサービスが最初のカテゴリまたは2番目のカテゴリに属しているかどうかを指定する必要があります。これは、
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は、サービスエリアで3つの関心点を示しています。ユーザーの場所（つまり、失われたクライアントの場所）は、円形の形状（GPSなど）で表されます。 POI 1、POI 2、およびPOI 3が最初のカテゴリのサービス（「距離x内」クエリ）に属している場合、それらのサービスエリアは無関係です。重要なのは、ユーザーからどれだけ離れているかです。このようなサービスの場合、ユーザーの場所を表す形状は、ユーザーがサービスを検索する距離を表します（セクション5.1を参照）。図3に示す例では、失われたサーバーはPOI 3のみを返します。POI3は、円で表されるユーザーの場所、つまりユーザーがサービスを検索したい領域に該当する唯一の関心ポイントです。一方、3つのサービスポイントが2番目のカテゴリ（「提供される」クエリ）に属している場合、重要なのはサービスエリアです。この2番目のシナリオでは、ユーザーの位置を表す円が3つのサービスエリアすべてと重複するため、3つのPOIすべてがユーザーの位置にサービスを提供でき、失われたサーバーは3つのPOIすべて、つまりPOI 1、POI 2を返す必要があります。およびPOI 3。
__________________________
\ ***** \
,===============***====, *** \
/ ** \ / ** \
/ 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：失われたクライアントの場所（円）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
クライアントがサービスが属する2つのカテゴリのどれを指定するために、<リージョン>要素を導入します。この新しい要素はタイプのブール値です。その値が偽の場合、Lost Serverは、ユーザーとサービスのポイント（「距離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].
要求されたサービスは2番目のカテゴリに属し、サービス領域に基づく検索はLost Server（ "by by" query）によって実行される必要があります。存在する場合、[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].
サービス領域に基づいた検索の場合、Lost Serverは、サービスエリアにユーザーの現在の場所が含まれるサービスのみを返す必要があります。[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>
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内x」クエリと「提供」クエリの例の例を示しています。非常に似ていますが、これらの2種類のクエリには3つの重要な違いがあります。
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」クエリでは、ユーザーの場所の不確実性レベルを手動で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内x」クエリでは、<領域>要素の値をfalseに設定する必要があります。「提供される」クエリには、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は、クライアントが20のサービスURI以下を返すようにサーバーに要求する<findService> Geodeticクエリを示しています。特に、図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よりも多い場合、サーバーは、クライアントの物理的位置に最も近い関心のあるポイントを特定する必要があり、応答中のそれらを返す必要があります。
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].
<limit>要素が<findService>クエリに存在しない場合、要求されたタイプのサービスで利用可能なすべての関心ポイントは、失われたサーバーによって返される必要があります。この動作は[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>
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>
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>
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>要素には、サービスのポイントの位置が含まれています。使用する場合は、<マッピング>要素に含める必要があります。<findServiceresponse> [RFC5222]などの応答では、それぞれ独自の<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>要素には、使用されるプロファイルを指定する単一の属性「プロファイル」があります。市民プロファイルと測地プロファイルの両方を使用できます。ある時点で、そのようなメトリックを計算するには、測地座標の市民アドレスのジオコーディングが必要になるため、測定プロファイルを使用するために使用する必要があります。このため、測地プロファイルを使用して<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は、2つの場所からサービス - URIマッピングを含むA <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.]
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>要素のシビックプロファイルを使用し、<ServicElocation>要素に含まれる<CivicAddress>要素でPOI CIVICアドレスを指定します。基本的な市民の位置プロファイルは、[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>要素を使用することをお勧めします。可能な場合は測地形式を提供することをお勧めします。複数の<ServicElocation>要素が1つのPOIに存在する場合、それらはすべて同じ<マッピング>要素、つまりそのPOIの<マッピング>要素に含める必要があります。図8は、測地と市民の両方の場所を使用したA <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">
<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>
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>クエリを示しています。このようなクエリでは、<領域>要素と<rimit>要素の両方が欠落しています。このドキュメントで定義されている失われた拡張機能によると、<領域>要素が欠落している場合、その値はデフォルトであり、クエリは「サービス」クエリです（セクション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">
<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
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.
このセクションでは、コンパクトなフォームのロストエクステンションのリラックスNGスキーマを提供します。冗長形式はセクション9に含まれています。
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
##
## 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 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 about the returned point
## of service.
##
div {
serviceLocation=
element serviceLocation { locationInformation }+
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## 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 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
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
リラックスNGスキーマ：登録するリラックスNGスキーマはセクション7に含まれています。その最初の行は
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
and its last line is
そしてその最後の行はです
}
}
URI: urn:ietf:params:xml:ns:lost-ext
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
<?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>
</start>
<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>
<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>
<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>
<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>
<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="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">
<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、「Lost：A Location-s-Service Translation Protocol」、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 5491、2009年3月。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.
[RFC5582] Schulzrinne、H。、「場所からURLのマッピングアーキテクチャとフレームワーク」、RFC 5582、2009年9月。
Authors' Addresses
著者のアドレス
Andrea G. Forte AT&T Security Research Center 33 Thomas Street New York, NY 10007 USA
アンドレアG.フォルテAT＆Tセキュリティ研究センター33トーマスストリートニューヨーク、ニューヨーク10007 USA
EMail: forte@att.com
Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
ヘニングシュルツリンヌコロンビア大学コンピュータサイエンス学科1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
EMail: hgs@cs.columbia.edu