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）プロトコルは、サービス領域に基づいて単一のサービスへのマッピングの場所をサポートしています。この文書は、「距離X以内」、タイプ「最も近いN」のクエリを可能にする拡張機能について説明し、「によって提供さ」。
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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
ロケーション・ツー・サービス翻訳（LOST）プロトコル[RFC5222]は、サービス領域に基づいて、URIをサービスするサービス識別子（のURN）及び市民または地理空間情報をマッピングします。その場所にサービスを提供する公衆安全応答ポイント（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.
我々は、プロトコルにサービス地域のユーザの現在位置を含む特定のサービスのNに最も近いインスタンス、所定の距離内のすべてのサービス、およびすべてのサービスを検索する能力を与える三つの追加<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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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を大量に取得することができますので、上記の定義あたりのサービス領域は、ユーザがサービスのURIの同じセットを取得することになる内の領域になります。設定変更におけるURIの一つ以上の場合は、URIの組、すなわち、サービス領域の変更を変更します。したがって、非緊急サービスのために、[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).
それらのサービスエリアがユーザの現在の場所（例えば、ピザの配達、PSAP）が含まれているか否か、O。
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>クエリタイプ：「距離X内の」「N最寄りの」、および「によって提供さ」
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>クエリの3種類の新しい紹介：「N最寄り」、「距離X内の」、および「によって提供さ」。最初のクエリは、対象のN個の点を返す（ランドマーク）クライアントの物理的な場所に最も近いです。 2番目のクエリは、クライアントの物理的な位置から所定距離内に位置する関心のあるすべてのポイントを発見します。そして第三のクエリは、サービスエリア、クライアントの現在の位置を含み、関心のすべてのポイントを返します。
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>クエリ内の要素。 [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最寄りの」クエリの場合、失われたクライアントは、サーバは、すなわち、サービスのURIの最大数が応答で返される、Nをお知らせする必要があります。これを指定するために、我々は<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.
新しい要素<地域>、<上限>、および<serviceLocation>は、「失われた-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に示されたクエリでは、我々は失われたサーバーを求めていることは、<：POS GML>で指定された当社のおおよその位置から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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われました-ext」のxmlns：GML = "http://www.opengis.net/gml" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" serviceBoundary = "値" 再帰= "真"> <EXT：地域>偽</ EXT：地域> <位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <GS：サークルsrsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML ：POS> 37.775 -122.422 </ GML：POS> <GS：半径UOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 200 </ GS：半径> </ GS：サークル> </場所> <サービス> URN：サービス：food.pizza </サービス> </ 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)
図1：「距離X内の」<findService>円形使用測地クエリ（の仮想的なサービスURN「URNを：サービス：food.pizza」が使用されます）
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われました-ext」のxmlns：GML = "http://www.opengis.net/gml" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" serviceBoundary = "値" 再帰= "真"> <EXT：地域>偽</ EXT：地域> <位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <GS：楕円srsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML ：POS> 42.5463 -73.2512 </ GML：POS> <GS：semiMajorAxisのUOM = "壷：OGCは：DEF：UOM：EPSG :: 9001"> 1235 </ GS：semiMajorAxis> <GS：semiMinorAxisのUOM = "壷：OGC ：DEF：UOM：EPSG :: 9001 "> 660 </ GS：semiMinorAxis> <GS：配向UOM =" URN：OGC：DEF：UOM：EPSG :: 9102" > 41.2 </ gsは：配向> </ GS：楕円形> </ location>の<サービス> URN：サービス：food.pizza </サービス> </ 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)
図2：「距離X以内に」A <findService>楕円形状を使用して測地クエリ（の仮想的なサービスURN「URN：サービス：food.pizza」が使用されます）
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.
第二の範疇に含まクエリアドレスサービス「が提供する」ながらクエリアドレスサービス「距離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 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、およびサービス（「距離X以内」クエリ）の最初のカテゴリーに属するPOI 3た場合、そのサービスエリアは無関係です。彼らは、ユーザーからどのように遠くにどのような事柄です。このようなサービスのために、ユーザの位置を表す形状は、ユーザがサービス（5.1節を参照）を検索したい範囲内の距離を表します。 POI 3は、円で表されるユーザの位置、ユーザはサービスを検索したい範囲内、すなわち、エリア内に入る関心の点のみであるように、図3に示す例では、失われたサーバは、唯一のPOI 3を返します。サービスの3点が（クエリ「がサービスを提供」）第二のカテゴリーに属している一方、そして重要なのは自分のサービスエリアです。ユーザの位置を表す円が3つのすべてのサービスエリアと重複するので、この第2のシナリオでは、すべての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点（POI 1、POI 2、POI 3）の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
サービスが属する二つのカテゴリーのかを指定するためのクライアントのためのために、私たちは、<地域>要素を紹介します。この新しい要素はboolean型です。その値が偽である場合、失われたサーバは、ユーザとサービス（「距離X以内」クエリ）の点の間の距離に基づいて検索を実行しなければなりません。その値は要素が欠落している真または<地域>のいずれかである場合には（セクション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].
要求されたサービスは、第二のカテゴリーに属し、サービスエリアに基づいて検索が（クエリ「がサービスを提供」）失われたサーバで実行しなければなりません。存在する場合、<地域>要素は[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" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われました-ext」のxmlns：GML = "http://www.opengis.net/gml" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" serviceBoundary = "値" 再帰= "真"> <EXT：地域>真</ EXT：地域> <位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <GS：サークルsrsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML ：POS> 37.775 -122.422 </ GML：POS> <GS：半径UOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 200 </ GS：半径> </ GS：サークル> </場所> <サービス> URN：サービス：food.pizza </サービス> </ 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)
図4：A新しい<地域>要素と<findService>測地クエリ「によってサービス」（の仮想的なサービスURN「URN：サービス：food.pizza」が使用されます）
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以内」クエリの例を示し、それぞれのクエリ「によってサービス」。非常に似ていますが、クエリのこれらの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 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「距離X以内」のクエリでは、手動でXへのユーザ位置の不確実性のレベルを設定し、我々は、そのような不確実な位置によって示される領域内のサービスを検索します。クエリ「によって提供さ」を含むクエリの他のすべてのタイプでは、ユーザーの場所の不確実性のレベルは、ユーザが変更することはできず、サービスエリアに基づいて検索が行われます。
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].
「距離X以内」クエリ中のOは、<地域>要素の値がfalseに設定されなければなりません。クエリ「によって提供さ」を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よりも多くを返さないようにサーバに伝えることができる必要があります。そのような制限を指定するために、我々はすなわち、<制限を>新しい要素を導入します。この新しい要素はオプションであるが、存在する場合、それは[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>測地クエリを示しています。特に、図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>クエリに存在しない場合は、サービスの要求されたタイプのための関心の後、すべての利用可能なポイントが失われたサーバーによって返されるべきです。この動作は、[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" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われました-ext」のxmlns：GML = "http://www.opengis.net/gml" serviceBoundary = "値" 再帰= "真"> <EXT：限界> 20 </ EXT：リミット> <位置ID = "6020688f1ce1896d"プロファイル= "測地-2D"> <GML：ポイントID = "POINT1" srsNameは= "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML：POS> 40.7128 -74.0092 </ GML：POS> </ GML：ポイント> </ location>の<サービス> URN：サービス：food.pizza </サービス> </ 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)
図5：新しい<限界>要素と「N最寄り」<findService>測地クエリ（の仮想的なサービスURN「URN：サービス：food.pizza」が使用されます）
<?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" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われました-ext」のxmlns：GML = "http://www.opengis.net/gml" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" serviceBoundary = "値" 再帰= "真"> <EXT：地域>偽</ EXT：地域> <EXT：限界> 20 </ EXT：リミット> <位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <GS：サークルsrsName = "URN：OGC： DEF：CRS：EPSG :: 4326 "> <GML：POS> 37.775 -122.422 </ GML：POS> <GS：半径UOM =" URN：OGC：DEF：UOM：EPSG :: 9001" > 200 </ GS：半径> </ GS：サークル> </場所> <サービス> URN：サービス：food.pizza </サービス> </ 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)
図6：新しい<限界>と<地域>要素と<findService>測地クエリ。このクエリは、クエリ「距離X以内」「Nに最も近い」との組み合わせである（の仮想的なサービスURN「URN：サービス：food.pizza」が使用されます）
<?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" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われました-ext」のxmlns：GML = "http://www.opengis.net/gml" のxmlns：GS = "http://www.opengis.net/pidflo/1.0" serviceBoundary = "値" 再帰= "真"> <EXT：地域>真</ EXT：地域> <EXT：限界> 20 </ EXT：リミット> <位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <GS：サークルsrsName = "URN：OGC： DEF：CRS：EPSG :: 4326 "> <GML：POS> 37.775 -122.422 </ GML：POS> <GS：半径UOM =" URN：OGC：DEF：UOM：EPSG :: 9001" > 100 </ GS：半径> </ GS：サークル> </場所> <サービス> URN：サービス：food.pizza </サービス> </ 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)
図7：新しい<限界>と<地域>要素と<findService>測地クエリ。このクエリは、クエリ「によって提供さ」「N最も近い」との組み合わせである（「：サービス：URN food.pizza」の仮想的なサービスURNを使用しています）
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のリストとして応答で、それ自身の<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>で指定された位置は、<ポイント>要素によって表現されるべきです。 <ポイント>要素は、セクションに記述されています
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.
[RFC5222]及び[RFC5491]のセクション5.2.1で12.2。図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.]
[注：これは、<mapping>要素の外で定義されているように、<locationUsed>要素は、この目的のために拡張することができません。サービスURIの数は、典型的には複数あるが、特に、応答して、<locationUsed>要素は、常に1です。]
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市民のアドレスを指定します。基本的な市民のロケーション・プロファイルは[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のために存在する場合、それらの全ては、同じ<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" エンコード= "UTF-8"？> <findServiceResponse =のxmlns "壷：IETF：のparams：XML：NS：lost1" のxmlns：EXT = "壷：IETF：のparams：XML：NS：失われましたhttp://www.opengis.net/gml "> <マッピングの有効期限が切れる= "2007-01-01T01：44：33Z" lastUpdated = "2006-11-01T01：00：00Z" ソース「GML =のxmlns" -ext = "authoritative.example" ソースID = "7e3f40b098c711dbb6060800200c9a66"> <のdisplayNameのxml：LANG = "それ">チェベラピザEすべての 'アニマダ' ピザダトト」</のdisplayName> <サービス> URN：サービス：food.pizza < /サービス> <URI> SIP：chebella@example.com </ URI> <URI> XMPP：chebella@example.com </ URI> <serviceNumber> 2129397040 </ serviceNumber> <EXT：serviceLocationプロファイル= "測地-2D" > <GML：ポイントID = "POINT1" srsName = "壷：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：ポイント> </ EXT：serviceLocation> <EXT：serviceLocationプロファイル= "市民"> <civicAddressのxmlns = "壷：IETF：のparams：XML：NS ：PIDF：geopriv10：civicAddr "> <国>アメリカ</国> <A1>ニューヨーク</ A1> <A3>ニューヨーク</ A3> <A6>ブロードウェイ</ A6> <HNO> 321 </ HNO> <PC> 10027 </ PC> </ civicAddress> </ EXT：serviceLocation> </マッピング> <マッピングは= "2007-01-01T01：44：33Z" 期限が切れlastUpdated = "2006-11-01T01：00：00Z"ソース= "authoritative.example" ソースID = "7e3f40b098c711dbb6060800200c9b356"> <のdisplayNameのxml：LANG = "EN">王マリオのピザ</のdisplayName> <サービス> URN：サービス：food.pizza </サービス> <URI> SIP：マリオス@ example.com </ URI> <URI> XMPP：marios@example.com </ URI> <serviceNumber> 2129397157 </ serviceNumber> <EXT：serviceLocationプロファイル= "測地-2D"> <GML：ポイントID = "POINT1 "srsName =" 壷：OGC：DEF：CRS：EPSG：4326 "> <GML：POS> 33.683 -112.412 </ GML：POS> </ GML：ポイント> </ EXT：serviceLocation> <EXT：serviceLocationプロファイル="市民 "> <civicAddressのxmlns =" 壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr "> <国>アメリカ</国> <A1>ニューヨーク</ A1> <A3>ニューヨーク</ A3> <A6>アムステルダムアベニュー</ A6> <HNO> 123 </ HNO> <PC> 10027 </ PC> </ civicAddress> < / EXT：serviceLocation> </マッピング> <path>は<介してソース= "resolver.example" /> <介してソース= "authoritative.example" /> </パス>
<locationUsed id="6020688f1ce1896d"/> </findServiceResponse>
<locationUsed ID = "6020688f1ce1896d" /> </ findServiceResponse>
Figure 8: A <findServiceResponse> answer
図8：<findServiceResponse>答え
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.
[RFC5222]で定義されるように、図9は、緊急サービスのための<findService>クエリを示しています。このようなクエリでは、<地域>要素と<限界>要素の両方が欠落しています。 <地域>要素が欠落している。この文書で定義されて失われた機能拡張、trueにその値のデフォルト、およびクエリによるとクエリ「がサービスを提供」（セクション5.3）です。 <リミット>要素が欠落している場合、制限が指定されていない、つまり、失われたサーバーは、結果を任意の数（5.4節を参照）を返すことができます。 PSAPは、そのサービスエリアに応じて選択され、ユーザの位置は、複数のサービスエリアと重なる場合、失われたサーバは、複数のPSAPを返すことができるように、この現象は、[RFC5222]と一致しています。
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" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/gml > " "serviceBoundary =" 値」再帰=" 真
<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
図9：緊急サービスのための<findService>測地クエリ
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 may become inaccurate quickly. Implementers should take this into account when designing applications for non-emergency location-based services.
このようのPSAPや消防署の場所のサービスの境界などの情報があればすべてで、非常に頻繁に変更されない緊急サービスとは異なり、非緊急サービスはすぐに不正確になる可能性のある情報を持っています。非緊急ロケーションベースのサービスのためのアプリケーションを設計するときに実装者は、このことを考慮すべきです。
This section provides the RELAX NG schema of LoST extensions in the compact form. The verbose form is included in Section 9.
このセクションでは、コンパクトな形で失われた機能拡張のRELAX NGスキーマを提供します。冗長な形式は、第9章に含まれています。
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
名前空間A = "http://relaxng.org/ns/compatibility/annotations/1.0" デフォルトの名前空間のNS1 = "壷：IETF：のparams：XML：NS：失われた-EXT"
## ## Extensions to the Location-to-Service Translation (LoST) ## Protocol
場所・ツー・サービス翻訳（LOST）##議定書## ##拡張機能
## ## LoST Extensions define three new elements: limit, region, and ## serviceLocation. ## start = limit | region | serviceLocation
制限、地域、および## serviceLocation：## ##失われた機能拡張3つの新しい要素を定義します。 =制限開始## |地域| serviceLocation
## ## A limit to the number of returned results. ## div { limit= element limit { xsd:positiveInteger } }
##は、返される結果の数に上限を##します。 ## DIV {限界=エレメント制限{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 }
検索##サービスエリアまたは距離のいずれかに基づくを要求する## ##ブール変数。 ## ##注：##「1」または '真の「0」または「false」を対：W3C XML Schemaでは、ブールのための2つの異なる##字句表現を持っています。 ## DIV {領域=素子領域{XSD：ブール}
}
｝
## ## Location Information ## div { locationInformation = extensionPoint+, attribute profile { xsd:NMTOKEN }? }
## ##場所情報##のdiv {locationInformation =拡張ポイント+、属性プロファイル{のxsd：NMTOKEN}？ }
## ## Location Information about the returned point ## of service. ## div { serviceLocation= element serviceLocation { locationInformation }+ }
## ##サービスの返されるポイント##の位置情報。 ## DIV {serviceLocation =素子serviceLocation {locationInformation} +}
## ## Patterns for inclusion of elements from schemas in ## other namespaces. ## div {
## ## ##他の名前空間内のスキーマの要素を含めるためのパターン。 ## DIV {
## ## Any element not in the LoST Extensions ## namespace. ## notLostExt = element * - (ns1:* | ns1:*) { anyElement }
## ##失われた拡張機能##の名前空間ではない任意の要素。 ## notLostExt =エレメント* - （NS1：* | NS1：*）{}を除き、anyelement
## ## A wildcard pattern for including any element ## from any other namespace. ## anyElement = (element * { anyElement } | attribute * { text } | text)*
##は、他の名前空間から任意の要素を##などのワイルドカードパターンを##します。 ##を除き、anyelement =（要素* {除き、anyelement} |属性* {テキスト} |テキスト）*
## ## A point where future extensions ## (elements from other namespaces) ## can be added. ## extensionPoint = notLostExt* }
ここで、将来の拡張## ##点##（他の名前空間からの要素）##を添加することができます。 ##拡張ポイント= 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]を参照してください）。リゾルバは、他の失われたサーバーに接続し、最終的に権威LOSTサーバーが見つかります。応答が戻っシーカーに送信されます。
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）を実装しなければならなくて、セクション1、14に記載されるように使用されるべきであり、[RFC5222]の18。
URI: urn:ietf:params:xml:schema:lost-ext
URI：URN：IETF：のparams：XML：スキーマ：失われた-EXT
Registrant Contact: Andrea G. Forte, forte@att.com; Henning Schulzrinne, hgs@cs.columbia.edu
登録者連絡先：アンドレア・G.フォルテ、forte@att.com。ヘニング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スキーマをRELAX：登録するRELAX NGスキーマは、その最初の行は、セクション7に含まれています
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
デフォルトの名前空間のNS1 = "壷：IETF：のparams：XML：NS：失われた-EXT"
and its last line is
そしてその最後の行があります
}
｝
URI: urn:ietf:params:xml:ns:lost-ext
URI：URN：IETF：のparams：XML：NS：失われた-EXT
Registrant Contact: Andrea G. Forte, forte@att.com; Henning Schulzrinne, hgs@cs.columbia.edu
登録者連絡先：アンドレア・G.フォルテ、forte@att.com。ヘニング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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソIETF：：のparams：XML：NS：失われた-EXT 8859-1" /> <title>は失われた拡張機能の拡張名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URNを失いました</ H2> <P> <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" エンコードは= "UTF-8"？> <文法NS = "壷：IETF：のparams：XML：NS：失われた-EXT" のxmlns = "http://relaxng.org/ns/structure /1.0" のxmlns：= "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>
</スタート>
<div> <a:documentation> A limit to the number of returned results. </a:documentation>
<div> <A：ドキュメント>返される結果の数に制限。 </：ドキュメント>
<define name="limit"> <element name="limit"> <data type="positiveInteger"/> </element> </define> </div>
<定義名= "制限"> <要素名= "制限"> <データタイプ= "POSITIVEINTEGER" /> </要素> </定義> </ div>
<div> <a:documentation> A boolean variable to request a search based on either service areas or distance. </a:documentation>
<div> <A：ドキュメント>ブール変数は、サービスエリアや距離のいずれかに基づいて検索を要求します。 </：ドキュメント>
<define name="region"> <element name="region"> <data type="boolean"/> </element> </define> </div>
<定義名= "領域"> <要素名= "領域"> <データタイプ= "ブール" /> </要素> </定義> </ div>
<div> <a:documentation> Location Information </a:documentation>
<div> <A：ドキュメント>位置情報</ A：ドキュメント>
<define name="locationInformation"> <oneOrMore> <ref name="extensionPoint"/> </oneOrMore> <optional> <attribute name="profile"> <data type="NMTOKEN"/> </attribute> </optional> </define> </div>
<名前= "locationInformation" を定義> <oneOrMore> <REF名= "拡張ポイント" /> </ oneOrMore> <オプション> <データタイプ= "NMTOKEN" /> </属性> </ <名前= "プロファイル" 属性>オプション> </定義> </ div>
<div> <a:documentation> Location Information about the returned point of service. </a:documentation>
<div> <A：ドキュメント>サービスの返されたポイントの位置情報。 </：ドキュメント>
<define name="serviceLocation"> <element name="serviceLocation"> <ref name="locationInformation"/> </element> </define> </div>
<定義名= "serviceLocation"> <要素名= "serviceLocation"> <REF名= "locationInformation" /> </要素> </定義> </ div>
<div> <a:documentation> Patterns for inclusion of elements from schemas in other namespaces. </a:documentation>
<DIV> <A：ドキュメント>他の名前空間内のスキーマの要素を含めるためのパターン。 </：ドキュメント>
<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>
<：ドキュメント>失われた機能拡張の名前空間内の任意の要素ではない<名前=「notLostExt」を定義>。 </：ドキュメント> <要素> <anyName> <ますNSname NS = "壷：IETF：のparams：XML：NS：失われた-EXT" /> <除く> <ますNSname /> </除く> </ anyName> <REF名前= "を除き、anyelement" /> </要素> </定義>
<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>
他の名前空間から任意の要素を含むための<ドキュメント>ワイルドカードパターンの<name =「除き、anyelement」を定義>。 </：ドキュメント> <zeroOrMore> <選択> <要素> <anyName /> <refの名前= "を除き、anyelement" /> </要素> <属性> <anyName /> </属性> <テキスト/> </選択> </ zeroOrMore> </定義>
<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>
<：ドキュメント>将来の拡張（他の名前空間からの要素）を添加することができる点。 </：ドキュメント> <zeroOrMore> <refの名前= "notLostExt" /> </ zeroOrMore> </定義> </ div>
</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.
私たちは、このドキュメントの初期バージョンを見直すため志田シューベルトに感謝したいと思います。また、ECRITワーキンググループのメンバーからの提案を感謝しています。特に、我々は彼らの全体的なフィードバックのための非緊急サービスは、緊急サービスのルックアップのプロビジョニングに影響を与える可能性がどのように彼らのコメントのためのリチャード・L.・バーンズ、ロバートスパークス、そしてマーティン・トムソンに感謝しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ハーディ、T.、ニュートン、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]トムソン、M.及びJ.ウィンター、RFC 5139、2008年2月 "プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）のための改訂シビックロケーションフォーマット"。
[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]ウィンターボトム、J.、トムソン、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トーマス・ストリート、ニューヨーク、NY 10007 USA
EMail: forte@att.com
メールアドレス：forte@att.com
Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスのヘニングSchulzrinneとコロンビア大学学部1214年アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027 USA
EMail: hgs@cs.columbia.edu
メールアドレス：hgs@cs.columbia.edu