[要約] RFC 5222は、LoST（Location-to-Service Translation Protocol）に関する規格であり、位置情報をサービスに変換するためのプロトコルを定義しています。このRFCの目的は、位置情報を使用して特定のサービスを見つけるための標準化と効率化を提供することです。
Network Working Group T. Hardie
Request for Comments: 5222 Qualcomm, Inc.
Category: Standards Track A. Newton
American Registry for Internet Numbers
H. Schulzrinne
Columbia University
H. Tschofenig
Nokia Siemens Networks
August 2008
LoST: A Location-to-Service Translation Protocol
紛失：場所からサービスへの翻訳プロトコル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.
このドキュメントでは、マッピングサービス識別子のためのXMLベースのプロトコルと、測地または市民の位置情報がサービスに連絡するための測地または市民の位置情報について説明します。特に、緊急サービスの場所に適した公共安全回答ポイント（PSAP）を決定するために使用できます。
Table of Contents
目次
1. Introduction .................................................. 3
2. Terminology and Requirements Notation ......................... 4
3. Overview of Protocol Usage .................................... 5
4. LoST Servers and Their Resolution ............................ 6
5. The <mapping> Element ........................................ 7
5.1. The Mapping Data Source: 'source', 'sourceId', and
'lastUpdated' Attributes .................................. 7
5.2. Mapping Validity: The 'expires' Attribute ................ 8
5.3. Describing the Service with the <displayName> Element .... 8
5.4. The Mapped Service: The <service> Element ................. 8
5.5. Defining the Service Region with the <serviceBoundary>
Element .................................................. 9
5.6. Service Boundaries by Reference: The
<serviceBoundaryReference> Element ........................ 9
5.7. The Service Number: The <serviceNumber> Element ......... 10
5.8. Service URLs: The <uri> Element ......................... 10
6. Path of a Request: The <path> Element ....................... 10
7. Identifying the Location Element Used for Mapping:
<locationUsed> ............................................... 11
8. Mapping a Location and Service to URLs: <findService> ....... 11
8.1. Overview ................................................. 11
8.2. Examples ................................................. 11
8.2.1. Example Using Geodetic Coordinates ................... 11
8.2.2. Civic Address Mapping Example ....................... 13
8.3. Components of the <findService> Request ................. 15
8.3.1. The <location> Element ............................... 15
8.3.2. Identifying the Service: The <service> Element ..... 16
8.3.3. Recursion and Iteration ............................. 16
8.3.4. Service Boundary ..................................... 16
8.3.5. Requesting Civic Location Validation ................. 16
8.4. Components of the Mapping Response
<findServiceResponse> ................................... 18
8.4.1. Overview ............................................. 18
8.4.2. Civic Address Validation: The <locationValidation>
Element ............................................. 19
9. Retrieving the Service Boundary via <getServiceBoundary> ..... 19
10. List Services: <listServices> ............................... 21
11. List Services By Location: <listServicesByLocation> ......... 22
12. Location Profiles ........................................... 24
12.1. Location Profile Usage ................................... 25
12.2. Two-Dimensional Geodetic Profile ......................... 30
12.3. Basic Civic Profile ..................................... 31
13. Errors, Warnings, and Redirects ............................. 32
13.1. Errors ................................................... 32
13.2. Warnings ................................................. 34
13.3. Redirects ............................................... 36
14. LoST Transport: HTTP ......................................... 36
15. Relax NG Schema ............................................. 37
16. Internationalization Considerations ......................... 44
17. IANA Considerations ......................................... 44
17.1. U-NAPTR Registrations ................................... 44
17.2. Content-Type Registration for 'application/lost+xml' ..... 44
17.3. LoST Relax NG Schema Registration ....................... 46
17.4. LoST Namespace Registration ............................. 46
17.5. LoST Location Profile Registry ........................... 47
18. Security Considerations ..................................... 47
19. Acknowledgments ............................................. 48
20. References ................................................... 51
20.1. Normative References ..................................... 51
20.2. Informative References ................................... 52
Appendix A. Non-Normative RELAX NG Schema in XML Syntax ......... 54
Appendix B. Examples Online ..................................... 67
1. Introduction
Protocols such as Naming Authority Pointer (NAPTR) records and the Service Location Protocol (SLP) can be used to discover servers offering a particular service. However, for an important class of services the appropriate specific service instance depends both on the identity of the service and the geographic location of the entity that needs to reach it. Emergency telecommunications services are an important example; here, the service instance is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the user making the call. The desired PSAP isn't necessarily the one that is topologically or even line-of-sight closest to the caller; rather, it is the one that serves the caller's location based on jurisdictional boundaries.
Naming Authority Pointer（NAPTR）レコードやサービスロケーションプロトコル（SLP）などのプロトコルを使用して、特定のサービスを提供するサーバーを発見できます。ただし、重要なクラスのサービスの場合、適切な特定のサービスインスタンスは、サービスの身元とそれに到達する必要があるエンティティの地理的位置の両方に依存します。緊急時電子通信サービスは重要な例です。ここでは、サービスインスタンスは、ユーザーの場所を司法権を呼び出している公共の安全回答ポイント（PSAP）です。望ましいPSAPは、必ずしもトポロジー的に、または発信者に最も近い視線でさえあるものではありません。むしろ、管轄権の境界に基づいて発信者の場所にサービスを提供するのはそれです。
This document describes a protocol for mapping a service identifier and location information compatible with the Presence Information Data Format Location Object (PIDF-LO) [6] to one or more service URIs. Service identifiers take the form of the service URNs described in [9]. Location information here includes revised civic location information [10] and a subset of the PIDF-LO profile [13], which consequently includes the Geo-Shapes [12] defined for GML [11]. Example service URI schemes include sip [14], xmpp [15], and tel [16]. While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to other service URNs. For example, in the United States, the "2-1-1" and "3-1-1" service numbers follow a similar location-to-service behavior as emergency services.
このドキュメントでは、1つ以上のサービスURIに存在情報データ形式の場所オブジェクト（PIDF-LO）[6]と互換性のあるサービス識別子と位置情報をマッピングするためのプロトコルについて説明します。サービス識別子は、[9]に記載されているサービスURNの形を取得します。ここでの位置情報には、改訂された市民の位置情報[10]とPIDF-LOプロファイル[13]のサブセットが含まれています。これには、GML [11]で定義されたジオ型[12]が含まれます。サンプルサービスURIスキームには、SIP [14]、XMPP [15]、およびTel [16]が含まれます。最初の焦点は緊急サービスにマッピング機能を提供することにありますが、プロトコルは他のサービスURNに適用できる可能性があります。たとえば、米国では、「2-1-1」および「3-1-1」のサービス番号は、緊急サービスと同様の場所からサービスの動作に従います。
This document names this protocol "LoST", for Location-to-Service Translation. LoST satisfies the requirements [18] for mapping protocols. LoST provides a number of operations, centered around mapping locations and service URNs to service URLs and associated information. LoST mapping queries can contain either civic or geodetic location information. For civic addresses, LoST can indicate which parts of the civic address are known to be valid or invalid, thus providing address validation, as described in Section 3.5 of [18]. LoST indicates errors in the location data to facilitate debugging and proper user feedback, but also provides best-effort answers.
このドキュメントは、場所からサービスへの翻訳のために、このプロトコル「Lost」に名前を付けます。Lostは、マッピングプロトコルの要件[18]を満たします。Lostは、URLと関連情報をサービスするために、場所とサービスURNをマッピングすることを中心とした多くの操作を提供します。失われたマッピングクエリには、市民または測地の位置情報のいずれかが含まれます。市民住所の場合、Lostは、[18]のセクション3.5で説明されているように、市民住所のどの部分が有効または無効であることが知られているかを示すことができるため、住所検証を提供します。Lostは、デバッグと適切なユーザーフィードバックを容易にするためのロケーションデータのエラーを示しますが、最良の回答も提供します。
LoST queries can be resolved recursively or iteratively. 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").
失われたクエリは、再帰的または繰り返し解決できます。往復を最小限に抑え、ネットワークの障害に対する堅牢性を提供するために、失われたものは個々のマッピングのキャッシュをサポートし、同じ答えが返される領域（「サービス領域」）を示します。
As defined in this document, LoST messages are carried in HTTP and HTTPS protocol exchanges, facilitating use of TLS for protecting the integrity and confidentiality of requests and responses.
このドキュメントで定義されているように、失われたメッセージはHTTPおよびHTTPSプロトコル交換で伝達され、リクエストと応答の整合性と機密性を保護するためのTLSの使用を促進します。
This document focuses on the description of the protocol between the mapping client and the mapping server. Other functions, such as discovery of mapping servers, data replication and the overall mapping server architecture are described in a separate document [19].
このドキュメントは、マッピングクライアントとマッピングサーバーの間のプロトコルの説明に焦点を当てています。マッピングサーバーの発見、データレプリケーション、マッピングサーバーアーキテクチャ全体などのその他の機能は、別のドキュメント[19]で説明されています。
The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [9]) from the LoST client to the LoST server. The LoST server uses its database to map the input values to one or more Uniform Resource Identifiers (URIs) and returns those URIs along with optional information, such as hints about the service boundary, in a response message to the LoST client. If the server cannot resolve the query itself, it may in turn query another server or return the address of another LoST server, identified by a LoST server name. In addition to the mapping function described in Section 8, the protocol also allows to retrieve the service boundary (see Section 9) and to list the services available for a particular location (see Section 11) or supported by a particular server (see Section 10).
クエリメッセージには、位置情報と、失われたクライアントから失われたサーバーにユニフォームリソース名（URN）（[9]を参照）としてエンコードされたサービス識別子が含まれます。Lost Serverは、データベースを使用して入力値を1つ以上の均一なリソース識別子（URI）にマッピングし、Lostクライアントへの応答メッセージで、サービス境界に関するヒントなどのオプションの情報とともにそれらのURIを返します。サーバーがクエリ自体を解決できない場合、順番に別のサーバーを照会するか、失われたサーバー名で識別される別の失われたサーバーのアドレスを返すことがあります。セクション8で説明したマッピング関数に加えて、プロトコルでは、サービス境界を取得し（セクション9を参照）、特定の場所で利用可能なサービスをリストするか（セクション11を参照）、特定のサーバーでサポートされています（セクション10を参照してください。）。
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 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[1]に記載されているとおりに解釈される。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
Mapping: Mapping is a process that takes a location and a service identifier as inputs and returns one or more URIs. Those URIs can point either to a host providing that service or to a host that in turn routes the request to the final destination. This definition is a generalization of the term "mapping" as used in [18], because LoST can be used for non-emergency services.
マッピング：マッピングは、場所とサービス識別子を入力として取得し、1つ以上のURIを返すプロセスです。これらのURIは、そのサービスを提供するホストまたはホストを指すことができます。この定義は、[18]で使用される「マッピング」という用語の一般化です。これは、失われたものが非緊急サービスに使用できるためです。
LoST client: A host acts as a LoST client if it sends LoST query messages and receives LoST response messages.
失われたクライアント：失われたクエリメッセージを送信し、失われた応答メッセージを受信した場合、ホストは失われたクライアントとして機能します。
LoST server: A host acts as a LoST server if it receives LoST query messages and sends LoST response messages. In recursive operation, the same entity may be both a client and a server.
失われたサーバー：失われたクエリメッセージを受信し、失われた応答メッセージを送信すると、ホストは失われたサーバーとして機能します。再帰操作では、同じエンティティがクライアントとサーバーの両方である場合があります。
Authoritative LoST server: An authoritative server acts only as a server and successfully resolves the input location and service identifier to a URI or set of URIs.
Service boundary: A service boundary circumscribes the region within which all locations map to the same service URI or set of URIs for a given service. A service boundary may consist of several non-contiguous geometric shapes.
サービス境界：サービス境界は、すべての場所が特定のサービスの同じサービスURIまたはURISセットにマッピングされる地域を囲みます。サービスの境界は、いくつかの非連続的な幾何学的形状で構成されている場合があります。
Validation: The term "validation" describes the behavior defined as "location validation" in Section 3.5 of [18].
検証：「検証」という用語は、[18]のセクション3.5の「位置検証」として定義された動作を説明しています。
Additional emergency service terminology can be found in [18].
追加の緊急サービスの用語は[18]にあります。
The LoST protocol supports the following types of queries and responses:
失われたプロトコルは、次のタイプのクエリと応答をサポートしています。
<findService> and <findServiceResponse> A LoST client retrieves contact URIs based on location information and a service identifier with this request and response. The same query type may also ask for location validation and for service numbers, either combined with a mapping request or separately. The details can be found in Section 8.
<findservice>および<findServiceresponse>失われたクライアントは、この要求と応答を伴う位置情報とサービス識別子に基づいて、連絡先URIを取得します。同じクエリタイプは、場所の検証とサービス番号を要求することもできます。詳細はセクション8にあります。
<getServiceBoundary> and <getServiceBoundaryResponse> A LoST client obtains a service boundary with this request and response, as described in Section 9.
<GetServiceBoundary>および<GetServiceBoundaryResponse>紛失したクライアントは、セクション9で説明されているように、この要求と応答でサービス境界を取得します。
<listServices> and <listServicesResponse> With this request and response, a LoST client can find out which services a LoST server supports, as described in Section 10.
<listservices>および<listservicesResponse>この要求と応答により、失われたクライアントは、セクション10で説明されているように、失われたサーバーがサポートするサービスを見つけることができます。
<listServicesByLocation> and <listServicesByLocationResponse> A LoST client can determine with this request and response which services are available for a specific location region. Section 11 describes the details.
<listservicesbylocation>および<listservicesbylocationResponse>失われたクライアントは、特定の場所領域で利用可能なサービスをこのリクエストと応答で決定できます。セクション11では、詳細について説明します。
LoST clients may initiate any of the above queries at any time. Among the common triggers are:
失われたクライアントは、上記のクエリのいずれかをいつでも開始する場合があります。一般的なトリガーの中には、
1. when the client initially starts up or attaches to a network;
1. クライアントが最初に起動するか、ネットワークに接続するとき。
2. when the client detects that its location has changed sufficiently that it is outside the bounds of the service region;
2. クライアントが、その場所がサービス領域の境界の外側にあるほど十分に変化したことを検出すると。
3. when a SIP message arrives at a SIP proxy performing location-based call routing;
3. SIPメッセージがSIPプロキシに到着したとき、ロケーションベースの通話ルーティングを実行します。
4. when cached mapping information has expired; and
4. キャッシュされたマッピング情報が有効になったとき。と
5. when invoking a particular service. At that time, a client may omit requests for service boundaries or other auxiliary information.
5. 特定のサービスを呼び出すとき。その時点で、クライアントはサービス境界またはその他の補助情報のリクエストを省略する場合があります。
A service-specific Best Current Practice (BCP) document, such as [21], governs whether a client is expected to invoke the mapping service just before needing the service or whether to rely on cached answers. Cache entries expire at their expiration time (see Section 5.2), or they become invalid if the caller's device moves beyond the boundaries of the service region. Service-specific Best Current Practice documents may also provide guidance on the contact URI schemes most appropriate to the service. As a general set of guidelines, URI schemes that do not provide mechanisms for actually initiating a contact method should be avoided (examples include data, info, cid, and tag) as transforming those references into contact mechanisms requires a layer of indirection that makes the overall mechanism more fragile. Provisionally registered URI schemes should also be carefully considered before use, because they are subject to change in core semantics.
[21]などのサービス固有のベストカレントプラクティス（BCP）ドキュメントは、クライアントがサービスを必要とする直前にマッピングサービスを呼び出すことが期待されるかどうか、またはキャッシュされた回答に依存するかどうかを管理します。キャッシュエントリは、有効期限が切れると期限切れになります（セクション5.2を参照）、または発信者のデバイスがサービス領域の境界を超えて移動すると無効になります。サービス固有の最新の実践文書は、サービスに最も適した連絡先URIスキームに関するガイダンスを提供する場合があります。一般的な一連のガイドラインとして、実際に連絡方法を開始するためのメカニズムを提供しないURIスキームは、それらの参照を接触メカニズムに変換するために、データ、情報、CID、タグを含む）を回避する必要があります。全体的なメカニズムはより脆弱です。暫定的に登録されたURIスキームは、コアセマンティクスの変更の対象となるため、使用前に慎重に検討する必要があります。
LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ Dynamic Delegation Discovery Service) [8] application unique strings, in the form of a DNS name. An example is 'lostserver.example.com'.
紛失サーバーは、U-NAPTR/ DDDS（URI対応NAPTR/ダイナミック委任ディスカバリーサービス）[8] DNS名の形のアプリケーションユニークな文字列によって識別されます。例は「LostServer.example.com」です。
Clients need to use the U-NAPTR [8] specification described below to obtain a URI (indicating host and protocol) for the applicable LoST service. In this document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any valid HTTP URL, including those containing path elements.
クライアントは、該当する失われたサービスのためにURI（ホストとプロトコルを示す）を取得するために、以下に説明するU-NAPTR [8]仕様を使用する必要があります。このドキュメントでは、HTTPおよびHTTPS URLスキームのみが定義されています。HTTP URLは、パス要素を含むものを含む有効なHTTP URLにすることができることに注意してください。
The following two DNS entries show the U-NAPTR resolution for "example.com" to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL http://lostserver.example.com, with the former being preferred.
次の2つのDNSエントリは、https url https://lostserv.example.com/secureまたはhttp url http://lostserver.example.comへの「embler.com」のu-naptr解像度を示しています。好ましい。
example.com.
IN NAPTR 100 10 "u" "LoST:https"
"!.*!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http"
"!.*!http://lostserver.example.com!" ""
Clients learn the LoST server's host name by means beyond the scope of this specification, such as SIP configuration and DHCP [25].
クライアントは、SIP構成やDHCP [25]など、この仕様の範囲を超えて、失われたサーバーのホスト名を学習します。
The <mapping> element is the core data element in LoST, describing a service region and the associated service URLs. Its attributes and elements are described in subsections below.
<mapping>要素は、lostのコアデータ要素であり、サービス領域と関連するサービスURLを記述します。その属性と要素は、以下のサブセクションで説明されています。
The 'source', 'sourceId', and 'lastUpdated' attributes uniquely identify a particular mapping record. They are created by the authoritative source for a mapping and are never modified when a mapping is served from a cache. All three attributes are REQUIRED for all <mapping> elements. A receiver can replace a mapping with another one having the same 'source' and 'sourceId' and a more recent time in 'lastUpdated'.
「ソース」、「SourceID」、および「LastUpdated」属性は、特定のマッピングレコードを一意に識別します。それらは、マッピングのために権威あるソースによって作成され、マッピングがキャッシュから提供されるときに変更されることはありません。3つの属性はすべて、すべての<マッピング>要素に必要です。レシーバーは、同じ「ソース」と「SourceID」を持つ別のマッピングに置き換え、「LastUpdated」で最近の時間を置き換えることができます。
The 'source' attribute contains a LoST application unique string identifying the authoritative generator of the mapping (Section 4).
「ソース」属性には、マッピングの権威あるジェネレーターを識別するロストアプリケーションの一意の文字列が含まれています（セクション4）。
The 'sourceId' attribute identifies a particular mapping and contains an opaque token that MUST be unique among all different mappings maintained by the authoritative source for that particular service. For example, a Universally Unique Identifier (UUID) is a suitable format.
「SourceID」属性は特定のマッピングを識別し、その特定のサービスの権威あるソースによって維持されるすべての異なるマッピングの中で一意でなければならない不透明なトークンを含んでいます。たとえば、普遍的に一意の識別子（UUID）が適切な形式です。
The 'lastUpdated' attribute describes when a specific instance of mapping, identified by the combination of 'source' and 'sourceId', was last changed. The contents of this attribute has the XML data type dateTime in its timezoned form, using the canonical UTC representation with the letter 'Z' as the timezone indicator.
「LastUpdated」属性は、「ソース」と「SourceID」の組み合わせによって識別される特定のマッピングのインスタンスが最後に変更されたことを説明します。この属性の内容には、タイムゾーンの形式でXMLデータ型のDateTimeがあり、文字「z」をタイムゾーンインジケーターとして使用して、標準的なUTC表現を使用しています。
The 'expires' attribute contains the absolute time at which the mapping becomes invalid. The contents of this attribute is a timezoned XML type dateTime, in canonical representation. The <mapping> element MUST include the 'expires' attribute.
「有効期限」の属性には、マッピングが無効になる絶対時間が含まれています。この属性の内容は、標準表現におけるタイムゾーンXMLタイプのDateTimeです。<マッピング>要素には、「有効期限」属性を含める必要があります。
Optionally, this attribute may contain the values of 'NO-CACHE' and 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is an indication that the mapping should not be cached. The value of 'NO-EXPIRATION' is an indication that the mapping does not expire.
オプションで、この属性には、データタイム値の代わりに「ノーキャッシュ」と「非expiration」の値が含まれる場合があります。値「ノーキャッシュ」は、マッピングをキャッシュしてはならないことを示しています。「expirationなし」の値は、マッピングが期限切れにならないことを示しています。
On occasion, a server may be forced to return an expired mapping if it cannot reach the authoritative server or the server fails to return a usable answer. Clients and servers MAY cache the mapping so that they have at least some information available. Caching servers that have such stale information SHOULD re-attempt the query each time a client requests a mapping. Since the expired mapping will be returned to the client as a non-error/non-warning response, the client MUST check the 'expires' attribute; if the mapping has expired, local policy at the client determines whether it discards the answer and tries again later or uses the possibly stale response.
場合によっては、信頼できるサーバーに到達できない場合、またはサーバーが使用可能な回答を返すことができない場合、サーバーは期限切れのマッピングを返すことを余儀なくされる場合があります。クライアントとサーバーは、少なくともいくつかの情報が利用可能になるようにマッピングをキャッシュする場合があります。このような古い情報を持っているキャッシュサーバーは、クライアントがマッピングを要求するたびにクエリを再取り付けする必要があります。期限切れのマッピングは、非誤差/非警戒の応答としてクライアントに返されるため、クライアントは「有効期限」属性をチェックする必要があります。マッピングの有効期限が切れた場合、クライアントのローカルポリシーは、回答を破棄して後で再試行するか、時代遅れの応答を使用するかどうかを決定します。
Zero or more <displayName> elements describe the service with a string that is suitable for display to human users, each annotated with the 'xml:lang' attribute that contains a language tag to aid in the rendering of text.
ゼロ以上<displayName>要素は、テキストのレンダリングを支援するための言語タグを含む「XML：LANG」属性が注釈付けされた、人間のユーザーへの表示に適した文字列でサービスを説明します。
The mandatory <service> element identifies the service for which this mapping applies. Two cases need to be distinguished when the LoST server sets the <service> element in the response message:
必須<service>要素は、このマッピングが適用されるサービスを識別します。失われたサーバーが応答メッセージに<service>要素を設定する場合、2つのケースを区別する必要があります。
1. If the requested service, identified by the service URN [9] in the <service> element of the request, exists for the location indicated, then the LoST server copies the service URN from the request into the <service> element.
1. リクエストの<Service>要素のサービスURN [9]によって識別された要求サービスが示されている場所に存在する場合、失われたサーバーはリクエストから<Service>要素にサービスURNをコピーします。
2. If, however, the requested service, identified by the service URN [9] in the <service> element in the request, does not exist for the location indicated, the server either can return a <serviceNotImplemented> (Section 13.1) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a <service> element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request.
2. ただし、リクエストの<Service>要素のサービスURN [9]によって識別された要求されたサービスが、示されている場所に存在しない場合、サーバーは<Servicenotimplemented>（セクション13.1）エラーを返すことができます。その場所の目的のサービスに近似する代替サービスを提供します。後者の場合、サーバーには、代替サービスURNに<Service>要素を含める必要があります。サービスURNの選択はローカルポリシーに任されていますが、代替サービスは元のサービスリクエストを満たすことができるはずです。
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. The service region can be indicated by value or by reference (see Section 5.6). If a client moves outside the service area and wishes to obtain current service data, it sends a new query with its current location. The service region is described by value in one or more <serviceBoundary> elements, each formatted according to a specific location profile, identified by the 'profile' attribute (see Section 12). <serviceBoundary> elements formatted according to different location profiles are alternative representations of the same area, not additive to one another; this allows a client understanding only one of the profile types to be sure it has a complete view of the serviceBoundary. Within a serviceBoundary element there may, however, be multiple locations which are additive; this is necessary because some <serviceBoundary> areas could not be easily expressed with a single shape or civic location. If included in a response, the <serviceBoundary> element MUST contain at least one service boundary that uses the same profile as the request.
応答は、サービスURLが返された領域が、実際のクエリであるいわゆるサービス領域と同じであることを示している場合があります。サービス領域は、値または参照によって示すことができます（セクション5.6を参照）。クライアントがサービスエリアの外側に移動し、現在のサービスデータを取得したい場合、現在の場所で新しいクエリを送信します。サービス領域は、「プロファイル」属性（セクション12を参照）で識別される特定の位置プロファイルに従ってフォーマットされている1つ以上の<ServiceBoundary>要素の値によって説明されます。<ServiceBoundary>さまざまな位置プロファイルに従ってフォーマットされている要素は、同じ領域の代替表現であり、互いに加算されません。これにより、クライアントがプロファイルの1つのみを理解することで、サービスバウンダリの完全なビューがあることを確認できます。ただし、サービス結合要素内には、添加剤の複数の場所がある場合があります。一部の<ServiceBoundary>領域は、単一の形状や市民の場所で簡単に表現できなかったため、これが必要です。応答に含まれている場合、<ServiceBoundary>要素には、要求と同じプロファイルを使用する少なくとも1つのサービス境界を含める必要があります。
A service boundary is requested by the client, using the 'serviceBoundary' attribute in the request with the value set to "value".
クライアントは、「値」に設定された値を使用して、リクエストに「サービスバウンダリー」属性を使用して、クライアントがサービス境界を要求します。
Since geodetic service boundaries may contain thousands of points and can thus be quite large, clients may wish to conserve bandwidth by requesting a reference to the service boundary instead of the value described in Section 5.5. The identifier of the service boundary is returned as an attribute of the <serviceBoundaryReference> element, along with a LoST application unique string (see Section 4) identifying the server from where it can be retrieved. The actual value of the service boundary is then retrieved with the getServiceBoundary (Section 9) request.
測地サービスの境界には数千ポイントが含まれているため、非常に大きくなる可能性があるため、クライアントはセクション5.5で説明されている値ではなく、サービス境界への参照を要求することにより、帯域幅を節約したい場合があります。サービス境界の識別子は、<ServiceBoundaryReference>要素の属性として返され、失われたアプリケーションの一意の文字列（セクション4を参照）とともに、サーバーを取得できる場所から識別します。次に、サービス境界の実際の値は、GetServiceBoundary（セクション9）リクエストで取得されます。
A reference to a service boundary is requested by the client using the 'serviceBoundary' attribute in the request with the value set to "reference". A LoST server may decide, based on local policy, to return the service boundary by value or to omit the <serviceBoundaryReference> element in the response.
サービス境界への参照は、「参照」に設定された値を使用して、リクエストで「サービスバウンダリー」属性を使用してクライアントによって要求されます。失われたサーバーは、ローカルポリシーに基づいて、サービスの境界を値で返すか、応答の<ServiceBoundaryReference>要素を省略することを決定する場合があります。
The identifier is a random token with at least 128 bits of entropy and can be assumed to be globally unique. It uniquely references a particular boundary. If the boundary changes, a new identifier MUST be chosen. Because of these properties, a client receiving a mapping response can simply check if it already has a copy of the boundary with that identifier. If so, it can skip checking with the server whether the boundary has been updated. Since service boundaries are likely to remain unchanged for extended periods of time, possibly exceeding the normal lifetime of the service URL, this approach avoids unnecessarily refreshing the boundary information just because the remainder of the mapping has become invalid.
識別子は、少なくとも128ビットのエントロピーを持つランダムトークンであり、グローバルに一意であると想定できます。特定の境界を独自に参照しています。境界が変更された場合、新しい識別子を選択する必要があります。これらのプロパティのため、マッピング応答を受信するクライアントは、その識別子に境界のコピーが既にあるかどうかを単純に確認できます。その場合、境界が更新されているかどうかをサーバーでチェックすることができます。サービスの境界は長期間にわたって変化しない可能性があり、おそらくサービスURLの通常の寿命を超える可能性があるため、このアプローチは、マッピングの残りが無効になっているため、境界情報を不必要に更新しないようにします。
The service number is returned in the optional <serviceNumber> element. It contains a string of digits, * and # that a user on a device with a 12-key dial pad could use to reach that particular service.
サービス番号は、オプション<ServicEnumber>要素で返されます。12キーのダイヤルパッドを備えたデバイス上のユーザーがその特定のサービスに到達するために使用できる桁の文字列が含まれています。
The response returns the service URLs in one or more <uri> elements. The URLs MUST be absolute URLs. The ordering of the URLs has no particular significance. Each URL scheme MUST only appear at most once, but it is permissible to include both secured and regular versions of a protocol, such as both 'http' and 'https' or 'sip' and 'sips'.
応答は、1つ以上の<uri>要素でサービスURLを返します。URLは絶対URLでなければなりません。URLの順序は特に重要ではありません。各URLスキームは、せいぜい1回しか表示されませんが、「HTTP」と「HTTPS」または「SIP」と「SIP」の両方など、プロトコルの保護されたバージョンと通常のバージョンの両方を含めることができます。
To prevent loops and to allow tracing of request and response paths, all requests that allow recursion include a <path> element that contains one or more <via> elements, each possessing an attribute containing a LoST application unique string (see Section 4). The order of <via> elements corresponds to the order of LoST servers, i.e., the first <via> element identifies the server that initially received the request from the client issuing the request. Every server in a recursive query operation is included in the <path> element, including the first server to receive it.
ループを防ぎ、リクエストと応答パスのトレースを許可するために、再帰を許可するすべてのリクエストには、1つ以上の<via>要素を含む<パス>要素が含まれます。<via>要素の順序は、失われたサーバーの順序に対応しています。つまり、最初の<via>要素は、リクエストを発行するクライアントから最初にリクエストを受信したサーバーを識別します。再帰クエリ操作のすべてのサーバーは、それを受信する最初のサーバーを含む<sath>要素に含まれています。
The server that answers the request instead of forwarding it, such as the authoritative server, copies the <path> element verbatim into the response. The <path> element is not modified in responses as the responses traverses the server chain back to the querying client.
信頼できるサーバーなど、リクエストに転送する代わりにリクエストに応答するサーバーは、<astrad>要素を応答にコピーします。応答がサーバーチェーンをクエリクライアントに戻すため、<パス>要素は応答では変更されていません。
If a query is answered iteratively, the querier includes all servers that it has already contacted.
クエリが繰り返し回答されている場合、Querierには既に連絡しているすべてのサーバーが含まれています。
When a cached mapping is returned, then the <path> element cached together with the mapping is returned.
キャッシュされたマッピングが返されると、マッピングと一緒にキャッシュされた<sath>要素が返されます。
The example in Figure 4 indicates that the answer was given to the client by the LoST server at esgw.ueber-110.de.example, which got the answer from the (authoritative) LoST server at polizei.muenchen.de.example.
図4の例は、ESGW.ueber-10.de.exampleの失われたサーバーによってクライアントに答えが与えられたことを示しています。
Several of the requests can provide one or more <location> elements, among which the server gets to choose. It is useful for the client to be able to determine which one was actually used in producing the result. For that purpose, the <location> tag MUST contain an 'id' attribute that uniquely identifies the <location> element. The format of the identifier is left to the client; it could, for example, use a hash of the location information. The server returns the identifier for the <location> element it used in the <locationUsed> tag.
いくつかのリクエストは、1つ以上の<location>要素を提供でき、その中にサーバーが選択できます。クライアントが結果の生成に実際に使用されたものを決定できることは有用です。そのため、<location>タグには、<location>要素を一意に識別する「ID」属性を含める必要があります。識別子の形式はクライアントに任されています。たとえば、位置情報のハッシュを使用できます。サーバーは、<locationed>タグで使用されている<location>要素の識別子を返します。
The <findService> query constitutes the core of the LoST functionality, mapping civic or geodetic locations to URLs and associated data. After giving an example, we enumerate the elements of the query and response.
<FindService>クエリは、LOST機能のコアを構成し、URLおよび関連データにシビックまたは測地位置をマッピングします。例を示した後、クエリと応答の要素を列挙します。
The following is an example of mapping a service to a location using geodetic coordinates, for the service associated with the police (urn:service:sos.police).
以下は、警察に関連するサービスのために、測地座標を使用して場所にサービスをマッピングする例です（urn：service：sos.police）。
<?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 1: A <findService> geodetic query
Given the query above, a server would respond with a service, and information related to that service. In the example below, the server has mapped the location given by the client for a police service to the New York City Police Department, instructing the client that it may contact them via the URIs "sip:nypd@example.com" and "xmpp:nypd@example.com". The server has also given the client a geodetic, two-dimensional boundary for this service. The mapping was last updated on November 1, 2006 and expires on January 1, 2007. If the client's location changes beyond the given service boundary or the expiration time has been reached, it may want to requery for this information, depending on the usage environment of LoST.
上記のクエリを考えると、サーバーはサービスとそのサービスに関連する情報で応答します。以下の例では、サーバーは、ニューヨーク市警察に警察サービスのためにクライアントが指定した場所をマッピングし、uris「sip：nypd@example.com」および「XMPPを介してそれらに連絡できるようにクライアントに指示しました。：nypd@example.com "。サーバーはまた、このサービスの測地的な2次元の境界をクライアントに提供しています。マッピングは2006年11月1日に最後に更新され、2007年1月1日に期限切れになります。クライアントの場所が特定のサービス境界を超えて変更されたり、有効期限に到達した場合、使用環境に応じてこの情報を補充したい場合があります。失われた。
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="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="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
Figure 2: A <findServiceResponse> geodetic answer
The example below shows how to map a service to a location much like the example in Section 8.2.1, but using civic address location information. In this example, the client requests the service associated with police (urn:service:sos.police) along with a specific civic address (house number 6 on a street named Otto-Hahn-Ring in Munich, Germany).
以下の例は、セクション8.2.1の例とよく似ていますが、市民住所の位置情報を使用する場所にサービスをマッピングする方法を示しています。この例では、クライアントは、特定の市民住所（ドイツのミュンヘンのオットーハーンリングという名前の路上での家番号6）とともに、警察（URN：サービス：SOS.Police）に関連するサービスを要求します。
<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true" serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 3: A <findService> civic address query
Given the query above, a server would respond with a service, and information related to that service. In the example below, the server has mapped the location given by the client for a police service to the Muenchen Polizei-Abteilung, instructing the client that it may contact them via the URIs sip:munich-police@example.com and xmpp:munich-police@example.com. The server has also given the client a civic address boundary (the city of Munich) for this service. The mapping was last updated on November 1, 2006 by the authoritative source "polizei.muenchen.de.example" and expires on January 1, 2007. This instructs the client to requery for the information if its location changes beyond the given service boundary (i.e., beyond the indicated district of Munich) or after January 1, 2007.
上記のクエリを考えると、サーバーはサービスとそのサービスに関連する情報で応答します。以下の例では、サーバーは、警察サービスのためにクライアントがMuenchen Polizei-Abteilungに提供する場所をマッピングし、uris sip：munich-police@example.comおよびxmpp：Munichを介してそれらに連絡することをクライアントに指示しました。-police@example.com。サーバーはまた、このサービスのためにクライアントに市民住所の境界（ミュンヘン市）を与えました。マッピングは、2006年11月1日に権威あるソース「polizei.muenchen.de.example」によって最後に更新され、2007年1月1日に期限切れになりました。すなわち、ミュンヘンの指定された地区を越えて）または2007年1月1日以降。
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="esgw.ueber-110.de.example"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="de">
Muenchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<path>
<via source="esgw.ueber-110.de.example"/>
<via source="polizei.muenchen.de.example"/>
</path>
<locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse>
Figure 4: A <findServiceResponse> civic address answer
The <findService> request includes attributes and elements that govern whether the request is handled iteratively or recursively, whether location validation is performed, and which elements may be contained in the response.
<findService>リクエストには、リクエストが繰り返し処理されるか再帰的に処理されるか、ロケーション検証が実行されるか、応答に含まれる要素が含まれるかどうかを支配する属性と要素が含まれます。
The <findService> query communicates location information using one or more <location> elements, which MUST conform to a location profile (see Section 12). There MUST NOT be more than one location element for each distinct location profile. The order of location elements is significant; the server uses the first location element where it understands the location profile.
<findService>クエリは、1つ以上の<location>要素を使用して位置情報を通知します。これは、ロケーションプロファイルに準拠する必要があります（セクション12を参照）。個別の位置プロファイルごとに、複数の位置要素があることはありません。位置要素の順序は重要です。サーバーは、位置プロファイルを理解する最初の位置要素を使用します。
The type of service desired is specified by the <service> element. It contains service URNs from the registry established in [9].
必要なサービスのタイプは、<service>要素によって指定されます。[9]で確立されたレジストリからのサービスURNが含まれています。
LoST can operate in either recursive or iterative mode, on a request-by-request basis. In recursive mode, the LoST server initiates queries on behalf of the requester and returns the result to the requester.
Lostは、リクエストごとに再帰モードまたは反復モードで動作できます。再帰モードでは、Lost Serverは要求者に代わってクエリを開始し、結果をリクエスターに返します。
In iterative mode, the server contacted returns a redirection response indicating the next server to be queried if the server contacted cannot provide an answer itself.
反復モードでは、サーバーが連絡したリダイヤリセクション応答を返し、接点されたサーバーが回答自体を提供できない場合、次のサーバーが照会されることを示します。
For the queries defined in this document, only the LoST <findService> and <listServicesByLocation> queries can be recursive, as indicated by the 'recursive' attribute. A value of "true" indicates a recursive query, with the default being "false" when the attribute is omitted. Regardless of the attribute, a server MAY always answer a query by providing a LoST application unique string (see Section 4), i.e., indirection; however, it MUST NOT recurse if the attribute is "false".
このドキュメントで定義されているクエリの場合、「再帰」属性で示されるように、Lost <findService>および<ListServicesByLocation>クエリのみが再帰的になる可能性があります。「true」の値は再帰的なクエリを示し、属性が省略されたときにデフォルトは「false」です。属性に関係なく、サーバーは、失われたアプリケーションの一意の文字列（セクション4を参照）、つまり間接を提供することにより、常にクエリに常に回答できます。ただし、属性が「false」であるかどうかを再発してはなりません。
LoST <mapping> elements can describe the service boundary either by value or by reference. Returning a service boundary reference is generally more space-efficient for geospatial (polygon) boundaries and if the boundaries change rarely, but does incur an additional <getServiceBoundary> request. The querier can express a preference for one or the other modality with the 'serviceBoundary' attribute in the <findService> request, but the server makes the final decision as to whether to return a reference or a value.
Lost <マッピング>要素は、値または参照によってサービス境界を記述できます。サービス境界参照を返すことは、一般に、地理空間（ポリゴン）境界と境界がめったに変化しない場合はより空間効率が高くなりますが、追加の<getServiceBoundary>リクエストが発生します。Querierは、<FindService>リクエストで「サービスバウンダリー」属性を使用して、いずれかのモダリティに対する優先を表すことができますが、サーバーはリファレンスまたは値を返すかどうかを最終決定します。
Civic address validation is requested by setting the optional attribute 'validateLocation' to true. If the attribute is omitted, it is assumed to be false. The response is described in Section 8.4.2. The example in Figure 5 demonstrates address validation. If the server chooses a geodetic location among the locations provided in a request, the attribute is ignored.
市民アドレスの検証は、オプションの属性「validAtelocation」をtrueに設定することにより要求されます。属性が省略されている場合、それはfalseであると想定されます。応答については、セクション8.4.2で説明します。図5の例は、アドレス検証を示しています。サーバーがリクエストで提供される場所の間で測地位置を選択した場合、属性は無視されます。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true"
validateLocation="true"
serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 5: A <findService> query with address validation request
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="4db898df52b84edfa9b6445ea8a0328e">
<displayName xml:lang="de">
Muenchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse>
Figure 6: A <findServiceResponse> message with address validation information
図6：アドレス検証情報を含む<findserviceresponse>メッセージ
Mapping responses consist of the <mapping> element (Section 5) describing the mapping itself, possibly followed by warnings (Section 13.2), location validation information (Section 8.4.2), and an indication of the path (Section 6) the response has taken.
マッピング応答は、マッピング自体を記述する<マッピング>要素（セクション5）で構成され、おそらく警告（セクション13.2）、位置検証情報（セクション8.4.2）、およびパスの指標（セクション6）が続きます。取った。
A server can indicate in its response which civic address elements it has recognized as valid, which ones it has ignored, and which ones it has checked and found to be invalid. The server SHOULD include this information if the 'validateLocation' attribute in the request was true, but local policy at the server may allow this information to be omitted. Each element contains a list of tokens separated by whitespace, enumerating the civic location labels used in child elements of the <civicAddress> element. The <valid> element enumerates those civic address elements that have been recognized as valid by the LoST server and that have been used to determine the mapping. The <unchecked> elements enumerates the civic address elements that the server did not check and that were not used in determining the response. The <invalid> element enumerate civic address elements that the server attempted to check, but that did not match the other civic address elements found in the <valid> list. Civic location tokens that are not listed in either the <valid>, <invalid>, or <unchecked> element belong to the class of unchecked tokens.
サーバーは、それが有効であると認識している市民の対処、無視したもの、およびチェックしていないものが無効であることがわかったものをその応答で示すことができます。リクエストの「validAtelocation」属性が真である場合、サーバーにこの情報を含める必要がありますが、サーバーのローカルポリシーでは、この情報を省略することができます。各要素には、<civicAddress>要素の子要素で使用される市民の場所ラベルを列挙して、白人で区切られたトークンのリストが含まれています。<balid>要素は、失われたサーバーによって有効であると認識され、マッピングの決定に使用されている市民アドレス要素を列挙します。<未チェック>要素は、サーバーがチェックしなかった市民アドレス要素を列挙し、応答の決定には使用されませんでした。<invalid>要素は、サーバーがチェックしようとした市民アドレス要素を列挙していますが、<abal>リストにある他のシビックアドレス要素とは一致しませんでした。<balid>、<nivalid>、または<unchecked>要素のいずれにもリストされていないシビックロケーショントークンは、未チェックのトークンのクラスに属します。
Note that the same address can yield different responses if parts of the civic address contradict each other. For example, if the postal code does not match the city, local server policy determines whether the postal code or the city is considered valid. The mapping naturally corresponds to the valid elements.
市民住所の一部が互いに矛盾する場合、同じアドレスが異なる応答をもたらす可能性があることに注意してください。たとえば、郵便番号が都市と一致しない場合、ローカルサーバーポリシーは、郵便番号または都市が有効であると見なされるかどうかを決定します。マッピングは当然有効な要素に対応します。
The example shown in Figure 5 and in Figure 6 indicates that the tokens 'country', 'A1', 'A3', and 'A6' have been validated by the LoST server. The server considered the postal code 81675 in the <PC> element as not valid for this location. The 'HNO' token belongs to the class of unchecked location tokens.
図5および図6に示す例は、トークンの国」、「A1」、「A3」、および「A6」が失われたサーバーによって検証されていることを示しています。サーバーは、この場所に有効ではないと<PC>要素の郵便番号81675を考慮しました。「HNO」トークンは、チェックされていないロケーショントークンのクラスに属します。
As discussed in Section 5.5, the <findServiceResponse> can return a globally unique identifier in the 'serviceBoundary' attribute that can be used to retrieve the service boundary, rather than returning the boundary by value. This is shown in the example in Figure 7 and Figure 8. The client can then retrieve the boundary using the <getServiceBoundary> request and obtains the boundary in the <getServiceBoundaryResponse>, illustrated in the example in Figure 9 and Figure 10. The client issues the request to the server identified in the 'server' attribute of the <serviceBoundaryReference> element. These requests are always directed to the authoritative server and do not recurse.
セクション5.5で説明したように、<findServiceresponse>は、境界を値で返すのではなく、サービス境界の取得に使用できる「サービスバウンダリー」属性のグローバルに一意の識別子を返すことができます。これは、図7と図8の例に示されています。クライアントは、<GetServiceBoundary>リクエストを使用して境界を取得し、図9および図10の例に示す<GetServiceBoundaryResponse>の境界を取得できます。クライアントの問題<ServiceBoundaryReference>要素の「サーバー」属性で識別されたサーバーへの要求。これらのリクエストは常に信頼できるサーバーに向けられており、再発しません。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true"
serviceBoundary="reference">
<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>
Figure 7: <findService> request and response with service boundary reference
図7：<FindService>サービス境界参照によるリクエストと応答
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="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="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundaryReference
source="authoritative.example"
key="7214148E0433AFE2FA2D48003D31172E"/>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
Figure 8: <findServiceResponse> message with service boundary reference
図8：<FindServiceresponse>サービス境界リファレンスを備えたメッセージ
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/>
Figure 9: Requesting a service boundary with <getServiceBoundary>
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</getServiceBoundaryResponse>
Figure 10: Geodetic service boundary response
図10：測地サービスの境界応答
A LoST client can ask a LoST server for the list of services that it understands, primarily for diagnostic purposes. The query does not contain location information, as it simply provides an indication of which services the server can look up, not whether a particular service is offered for a particular area. Typically, only top-level services are included in the answer, implying support for all sub-services. Since the query is answered by the queried server, there is no notion of recursion or indirection. The <listServicesByLocation> (Section 11) query below can be used to find out whether a particular service is offered for a specific location. An example request and response are shown in Figure 11.
失われたクライアントは、主に診断目的で、それが理解しているサービスのリストを失ったサーバーに尋ねることができます。クエリには位置情報が含まれていません。特定の領域に特定のサービスが提供されているかどうかではなく、サーバーがどのサービスを検索できるかを示すことを示しているためです。通常、回答にはトップレベルのサービスのみが含まれており、すべてのサブサービスのサポートを暗示しています。クエリはクエリサーバーによって回答されるため、再帰または間接の概念はありません。<listservicesbylocation>（セクション11）クエリを使用して、特定の場所に特定のサービスが提供されているかどうかを調べることができます。例のリクエストと応答を図11に示します。
<?xml version="1.0" encoding="UTF-8"?>
<listServices
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
Figure 11: Example of <ListServices> query
<?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="authoritative.example"/>
</path>
</listServicesResponse>
Figure 12: Example of <ListServicesResponse>
A LoST client can ask a LoST server for the list of services it knows about for a particular area. The <listServicesByLocation> query contains one or more <location> elements, each from a different location profile (Section 12), and may contain the <service> element. As for <findService>, the server selects the first location element that has a profile the server understands and it can operate either recursively or iteratively; <via> elements track the progress of the request. The query indicates the services that the server can enumerate from within the forest structure of which it is a part. Because LoST does not presume a single, overarching organization of all potential service types, there may be services available within a geographic area that could be described by other LoST servers connected to other forest structures. As an example, the emergency services forest for a region may be distinct from the forests that locate commercial services within the same region.
失われたクライアントは、失われたサーバーに特定の領域について知っているサービスのリストを尋ねることができます。<listservicesbylocation>クエリには、それぞれ異なる位置プロファイル（セクション12）からの1つ以上の<location>要素が含まれており、<service>要素が含まれる場合があります。<findService>については、サーバーはサーバーが理解しているプロファイルを持つ最初の位置要素を選択し、再帰的または繰り返し動作させることができます。<via>要素は、リクエストの進捗を追跡します。クエリは、サーバーが一部である森林構造内から列挙できるサービスを示しています。Lostは、すべての潜在的なサービスタイプの単一の包括的な組織を推定しないため、他の森林構造に接続された他の失われたサーバーが説明できる地理的エリア内で利用可能なサービスがある場合があります。例として、地域の緊急サービス森林は、同じ地域内の商業サービスを見つける森林とは異なる場合があります。
If the query contains the <service> element, the LoST server returns only immediate child services of the queried service that are available for the provided location. If the <service> element is absent, the LoST service returns all top-level services available for the provided location that it knows about.
クエリに<Service>要素が含まれている場合、Lost Serverは、提供された場所で利用可能なクエリサービスの即時の子サービスのみを返します。<service>要素がない場合、Lost Serviceは、提供されている場所で利用可能なすべてのトップレベルサービスを返します。
A server responds to this query with a <listServicesByLocationResponse> response. This response MAY contain <via> elements (see Section 6) and MUST contain a <serviceList> element, consisting of a whitespace-separated list of service URNs. The query and response are illustrated in Figure 13 and in Figure 14, respectively.
サーバーは、このクエリに<listservicesbylocationResponse>応答で応答します。この応答には、<via>要素（セクション6を参照）が含まれている場合があり、<servicelist>要素を含む必要があります。クエリと応答は、それぞれ図13と図14に示されています。
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true">
<location id="3e19dfb3b9828c3" profile="geodetic-2d">
<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>-34.407 150.883</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos</service>
</listServicesByLocation>
Figure 13: Example of <ListServicesbyLocation> query
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="3e19dfb3b9828c3"/>
</listServicesByLocationResponse>
Figure 14: Example of <ListServicesByLocationResponse> response
LoST uses location information in <location> elements in requests and <serviceBoundary> elements in responses. Such location information may be expressed in a variety of ways. This variety can cause interoperability problems where a request or response contains location information in a format not understood by the server or the client, respectively. To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the manner in which location information is transmitted. It is possible to standardize other profiles in the future. The baseline profiles are:
Lostは、リクエストの<location>要素で位置情報を使用し、応答で<ServiceBoundary>要素を使用します。このような位置情報は、さまざまな方法で表現される場合があります。この多様性は、リクエストまたは応答に、それぞれサーバーまたはクライアントが理解していない形式で位置情報を含む相互運用性の問題を引き起こす可能性があります。相互運用性を実現するために、このドキュメントでは、2つの必須のベースラインロケーションプロファイルを定義して、位置情報が送信される方法を定義します。将来、他のプロファイルを標準化することが可能です。ベースラインプロファイルは次のとおりです。
geodetic-2d: a profile for two-dimensional geodetic location information, as described in Section 12.2;.
Geodetic -2D：セクション12.2で説明されているように、2次元測地位置情報のプロファイル。
civic: a profile consisting of civic address location information, as described in Section 12.3.
CIVIC：セクション12.3で説明されているように、市民住所の位置情報で構成されるプロファイル。
Requests and responses containing <location> or <serviceBoundary> elements MUST contain location information in exactly one of the two baseline profiles, in addition to zero or more additional profiles. The ordering of location information indicates a preference on the part of the sender.
<location>または<ServiceBoundary>要素を含むリクエストと応答には、ゼロ以上の追加プロファイルに加えて、2つのベースラインプロファイルの1つに位置情報を含める必要があります。位置情報の順序付けは、送信者側の好みを示します。
Standards action is required for defining new profiles. A location profile MUST define:
新しいプロファイルを定義するには、標準アクションが必要です。ロケーションプロファイルを定義する必要があります。
1. The token identifying it in the LoST location profile registry.
1. 失われたロケーションプロファイルレジストリでそれを識別するトークン。
2. The formal definition of the XML to be used in requests, i.e., an enumeration and definition of the XML child elements of the <location> element.
2. リクエストで使用されるXMLの正式な定義、つまり<location>要素のXML子要素の列挙と定義。
3. The formal definition of the XML to be used in responses, i.e., an enumeration and definition of the XML child elements of the <serviceBoundary> element.
3. 応答で使用されるXMLの正式な定義、つまり<ServiceBoundary>要素のXML子要素の列挙と定義。
4. The declaration of whether geodetic-2d or civic is to be used as the baseline profile. It is necessary to explicitly declare the baseline profile as future profiles may be combinations of geodetic and civic location information.
4. Geodetic -2DまたはCivicがベースラインプロファイルとして使用されるかどうかの宣言。将来のプロファイルが測地測定と市民の位置情報の組み合わせである可能性があるため、ベースラインプロファイルを明示的に宣言する必要があります。
A location profile is identified by a token in an IANA-maintained registry (Section 17.5). Clients send location information compliant with a location profile, and servers respond with location information compliant with that same location profile.
IANAが維持したレジストリ（セクション17.5）のトークンによって位置プロファイルが識別されます。クライアントはロケーションプロファイルに準拠した位置情報を送信し、サーバーは同じ位置プロファイルに準拠した位置情報に応答します。
When a LoST client sends a <findService> request that provides location information, it includes one or more <location> elements. A <location> element carries an optional 'profile' attribute that indicates the location format of the child elements. A client may obtain location information that does not conform to a profile it recognizes, or it may not have the capability to map XML to profiles. In that case, a client MAY omit the profile attribute and the server should interpret the XML location data to the best of its ability, returning a "locationProfileUnrecognized" error if it is unable to do so.
紛失したクライアントが位置情報を提供する<findService>リクエストを送信すると、1つ以上の<location>要素が含まれます。<位置>要素には、子要素の位置形式を示すオプションの「プロファイル」属性が搭載されています。クライアントは、認識しているプロファイルに準拠していない位置情報を取得するか、XMLをプロファイルにマッピングする機能がない場合があります。その場合、クライアントはプロファイル属性を省略する場合があり、サーバーはXMLの位置データをその能力に最適に解釈し、そうすることができない場合は「LocationProfileunが認識した」エラーを返します。
The concept of location profiles is described in Section 12. With the ability to specify more than one <location> element, the client is able to convey location information for multiple location profiles in the same request.
ロケーションプロファイルの概念はセクション12で説明されています。複数の<位置>要素を指定する機能により、クライアントは同じ要求で複数のロケーションプロファイルの位置情報を伝えることができます。
When a LoST server sends a response that contains location information, it uses the <serviceBoundary> elements much like the client uses the <location> elements. Each <serviceBoundary> element contains location information conforming to the location profile specified in the 'profile' attribute. A response MAY contain multiple mappings or boundaries for the different <location> elements, subject to the restrictions below.
失われたサーバーが位置情報を含む応答を送信すると、クライアントが<location>要素を使用するのと同じように、<serviceboundary>要素を使用します。各<ServiceBoundary>要素には、「プロファイル」属性で指定された位置プロファイルに準拠した位置情報が含まれています。応答には、以下の制限を条件として、異なる<位置>要素の複数のマッピングまたは境界が含まれる場合があります。
Using the location profiles defined in this document, the following rules ensure interoperability between clients and servers:
このドキュメントで定義されているロケーションプロファイルを使用すると、次のルールにより、クライアントとサーバー間の相互運用性が保証されます。
1. A client MUST be capable of understanding the response for the baseline profiles it used in the request.
1. クライアントは、リクエストで使用したベースラインプロファイルの応答を理解できる必要があります。
2. If a client sends location information conformant to any location profile other than the ones described in this document, it MUST also send, in the same request, location information conformant to one of the baseline profiles. Otherwise, the server might not be able to understand the request.
2. クライアントが、このドキュメントに記載されているもの以外の場所にコンフォーマルな位置情報を送信する場合、ベースラインプロファイルの1つに適合した位置情報も、同じリクエストで送信する必要があります。それ以外の場合、サーバーはリクエストを理解できない場合があります。
3. A client MUST NOT send multiple <location> objects that are derived from different baseline profiles. In other words, a client MUST only send location objects according to the same baseline profile in a query, but it MAY contain a location element following a baseline profile in addition to some other profile.
3. クライアントは、さまざまなベースラインプロファイルから派生した複数の<location>オブジェクトを送信してはなりません。言い換えれば、クライアントはクエリの同じベースラインプロファイルに従ってロケーションオブジェクトのみを送信する必要がありますが、他のプロファイルに加えてベースラインプロファイルに従って位置要素を含める場合があります。
4. If a client has both location information primarily of geodetic nature and location information primarily of a civic nature, it MUST send separate requests containing each type of location information.
4. クライアントが主に測地の性質と主に市民の性質に関する位置情報の両方の位置情報を持っている場合、各タイプの位置情報を含む個別のリクエストを送信する必要があります。
5. There can only be one instance of each location profile in a query.
5. クエリには、各ロケーションプロファイルのインスタンスが1つしかありません。
6. Servers MUST implement all profiles described in this document.
6. サーバーは、このドキュメントに記載されているすべてのプロファイルを実装する必要があります。
7. A server uses the first-listed location profile that it understands and ignores the others.
7. サーバーは、他のものを理解して無視する最初の上場の場所プロファイルを使用します。
8. If a server receives a request that only contains location information using profiles it does not understand, the server responds with a <locationProfileError> (Section 13.1).
8. サーバーが、理解できないプロファイルを使用して位置情報のみを含むリクエストを受信した場合、サーバーは<locationProfileerror>（セクション13.1）で応答します。
9. The <serviceBoundary> element MUST use the same location profile that was used to retrieve the answer and indicates which profile has been used with the 'profile' attribute.
9. <ServiceBoundary>要素は、答えを取得するために使用された同じ場所プロファイルを使用し、「プロファイル」属性で使用されたプロファイルを示す必要があります。
These rules enable the use of location profiles not yet specified, while ensuring baseline interoperability. Take, for example, this scenario illustrated in Figure 15 and 16. Client X has had its firmware upgraded to support the 'not-yet-standardized-prism-profile' location profile. Client X sends location information to Server Y, which does not understand the 'not-yet-standardized-prism-profile' location profile. If Client X also sends location information using the geodetic-2D baseline profile, then Server Y will still be able to understand the request and provide an understandable response, though with location information that might not be as precise or expressive as desired. This is possible because both Client X and Server Y understand the baseline profile.
これらのルールにより、ベースラインの相互運用性を確保しながら、まだ指定されていないロケーションプロファイルを使用できます。たとえば、図15と16に示すこのシナリオを考えてみましょう。クライアントXは、「まだ標準化されていないプリズムプロファイル」の位置プロファイルをサポートするためにファームウェアをアップグレードしました。クライアントXは、位置情報をサーバーYに送信します。サーバーYは、「まだ標準化されていないプリズムプロファイル」の位置プロファイルを理解していません。クライアントXがGeodetic -2Dベースラインプロファイルを使用して位置情報を送信する場合、サーバーYはリクエストを理解し、理解可能な応答を提供することができますが、必要に応じて正確または表現力豊かではない可能性があります。これは、クライアントXとサーバーYの両方がベースラインプロファイルを理解しているため可能です。
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
recursive="true"
serviceBoundary="value">
<location id="ABC 123"
profile="not-yet-standardized-prism-profile">
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
42.556844 -73.248157 36.6
42.656844 -73.248157 36.6
42.656844 -73.348157 36.6
42.556844 -73.348157 36.6
42.556844 -73.248157 36.6
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
2.4
</gs:height>
</gs:Prism>
</location>
<location id="DEF 345" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>42.656844 -73.348157</gml:pos>
</gml:Point>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 15: Example of a <findServices> query with baseline profile interoperability
図15：ベースラインプロファイルの相互運用性を備えた<findServices>クエリの例
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="DEF 345"/>
</findServiceResponse>
Figure 16: Example of a <findServiceResponse> message with baseline profile interoperability
図16：ベースラインプロファイルの相互運用性を備えた<findserviceresponse>メッセージの例
The "geodetic-2d" location profile is identified by the token "geodetic-2d". Clients and servers use this profile by placing the following location shapes into the <serviceBoundary> or into the <location> element (unless indicated otherwise):
「測地-2D」位置プロファイルは、トークン「Geodetic -2D」によって識別されます。クライアントとサーバーは、次の場所の形状を<ServiceBoundary>または<location>要素に配置することにより、このプロファイルを使用します（特に明記しない限り）：
Point: The <Point> element is described in Section 5.2.1 of [13]. Section 5.2.1 of [13] shows also the specification of a <Point> with either a two-dimensional position (latitude and longitude) or three-dimensional position (latitude, longitude, and altitude). A client MAY use the three-dimensional position, and servers MAY interpret a three-dimensional position as a two-dimensional position by ignoring the altitude value. A <Point> element is not placed into a <serviceBoundary> element.
点：<point>要素は、[13]のセクション5.2.1で説明されています。[13]のセクション5.2.1は、2次元の位置（緯度と経度）または3次元の位置（緯度、経度、高度）のいずれかのA <point>の仕様も示しています。クライアントは3次元位置を使用する場合があり、サーバーは高度値を無視することにより、3次元位置を2次元位置として解釈できます。<point>要素は<serviceboundary>要素に配置されません。
Polygon: The <Polygon> element is described in Section 5.2.2 of [13]. The restriction to 16 points for a polygon contained in Section 7.2.2 of [12] is not applicable to this document.
ポリゴン：<ポリゴン>要素は、[13]のセクション5.2.2で説明されています。[12]のセクション7.2.2に含まれるポリゴンの16ポイントに対する制限は、このドキュメントには適用されません。
Circle: The <Circle> element is described in Section 5.2.3 of [13].
円：<circle>要素は[13]のセクション5.2.3で説明されています。
Ellipse: The <Ellipse> element is described in Section 5.2.4 of [13].
楕円：<ellipse>要素は、[13]のセクション5.2.4で説明されています。
ArcBand: The <ArcBand> element is described in Section 5.2.5 of [13].
arcband：<arcband>要素は、[13]のセクション5.2.5で説明されています。
When a client uses a <Polygon>, <Circle>, <Ellipse>, or <ArcBand> element within the <location> element, it is indicating that it will be satisfied by query results appropriate to any portion of the shape. It is left to the server to select an appropriate matching algorithm. A server MAY return multiple <mapping> elements if the shape extends across multiple service areas. Servers are not required to return all possible <mapping> elements to avoid denial-of-service attacks in which clients present queries that span a very large number of service boundaries (e.g., presenting a shape covering all of the United States).
クライアントが<位置>要素内で<polygon>、<circle>、<ellipse>、または<arcband>要素を使用すると、形状の任意の部分に適したクエリ結果によって満たされることを示しています。適切な一致するアルゴリズムを選択するのはサーバーに任されています。サーバーは、形状が複数のサービス領域に拡張されている場合、複数の<マッピング>要素を返す場合があります。サーバーは、クライアントが非常に多数のサービス境界にまたがるクエリを提示するサービス拒否攻撃を避けるために、可能なすべての<マッピング>要素を返す必要はありません（たとえば、米国のすべてをカバーする形状を提示します）。
In the case where the server does not return multiple <mapping> elements, but the shape extends across a service boundary, it is possible that the matching algorithm selected by the LoST server will return results that match a portion of the shape but do not match those specific to a particular point. A client may always select a point from within the shape to avoid this condition. The cases where it does not are generally those where it knows its own position only within the shape given. In emergency service use cases, that may result in the PSAP contacted at the URI provided by LoST being required to forward a call to one of its neighbors; this is an expected part of the overall emergency response system. In non-emergency service use cases, the service deployment model should take into account this issue as part of the provisioning model, as the combination of the data in the LoST server and the algorithm used for mapping determine which contact URIs are returned when shapes are used that overlap multiple service areas.
サーバーが複数の<マッピング>要素を返さないが、形状がサービス境界全体に伸びている場合、失われたサーバーによって選択された一致するアルゴリズムは、形状の一部に一致するが一致しない結果を返す可能性があります特定のポイントに固有のもの。クライアントは、この状態を回避するために、常に形状内からポイントを選択できます。それがそうでない場合は、一般的に、与えられた形状の中でのみそれ自体の位置を知っている場合です。緊急サービスのユースケースでは、隣人の1人に電話を転送するために必要な存在によって提供されたURIで接触したPSAPにつながる可能性があります。これは、全体的な緊急対応システムの予想される部分です。非緊急サービスのユースケースでは、失われたサーバーのデータの組み合わせとマッピングに使用されるアルゴリズムの組み合わせが、形状の場合にどの連絡先が返されるかを決定するため、サービス展開モデルはプロビジョニングモデルの一部としてこの問題を考慮する必要があります。複数のサービス領域を重複させる使用しました。
As a general guideline, any deployed matching algorithm should ensure that the algorithm used does not needlessly return no results if there are valid results for any portion of the shape. If an authoritative server receives a query for which the area in the query overlaps the area for which the server has mapping information, then it MUST return either a mapping whose coverage area intersects the query area or a redirect to another server whose coverage area is a subset of the server's coverage area.
一般的なガイドラインとして、展開された一致するアルゴリズムは、使用されるアルゴリズムが、形状の一部に有効な結果がある場合、結果の結果を不必要に返さないことを確認する必要があります。権威あるサーバーが、クエリ内の領域がマッピング情報の領域と重複するクエリを受信した場合、カバレッジエリアがクエリエリアと交差するマッピングを返すか、カバレッジ領域がある別のサーバーにリダイレクトを返す必要があります。サーバーのカバレッジエリアのサブセット。
When geodetic location information of this location profile is placed in the <serviceBoundary> element, then the elements with geospatial coordinates are alternative descriptions of the same service region, not additive geometries.
この場所の測地位置情報が<serviceboundary>要素に配置される場合、地理座標を持つ要素は、添加幾何学ではなく、同じサービス領域の代替説明です。
The basic civic location profile is identified by the token 'civic'. Clients use this profile by placing a <civicAddress> element, defined in [10], within the <location> element.
基本的なシビックロケーションプロファイルは、トークン「シビック」によって識別されます。クライアントは、[10]で定義されている<civicaddress>要素を<位置>要素内に配置することにより、このプロファイルを使用します。
Servers use this profile by placing a <civicAddress> element, defined in [10], within the <serviceBoundary> element.
サーバーは、[10]で定義された<serviceboundary>要素内で定義された<civicAddress>要素を配置して、このプロファイルを使用します。
A response MAY contain more than one <serviceBoundary> element with profile 'civic'. Each <serviceBoundary> element describes a set of civic addresses that fall within the service boundary, namely, all addresses that textually match the civic address elements provided, regardless of the value of other address elements. A location falls within the mapping's service boundary if it matches any of the <serviceBoundary> elements. Hence, a response may contain multiple <serviceBoundary> elements with civic and/or geodetic location profiles.
応答には、プロファイル「Civic」を備えた複数の<ServiceBoundary>要素が含まれる場合があります。各<serviceboundary>要素は、サービス境界内に該当する市民アドレスのセット、つまり、他のアドレス要素の価値に関係なく、提供された市民アドレス要素とテキスト的に一致するすべてのアドレスを説明します。場所は、<ServiceBoundary>要素のいずれかと一致する場合、マッピングのサービス境界内に収まります。したがって、応答には、Civicおよび/または測地の位置プロファイルを備えた複数の<ServiceBoundary>要素が含まれる場合があります。
When a LoST server cannot fulfill a request completely, it can return either an error or a warning, depending on the severity of the problem. It returns an <errors> element if no useful response can be returned for the query. It returns a <warnings> element as part of another response element if it was able to respond in part, but the response may not be quite what the client had desired. For both elements, the 'source' attribute names the server that originally generated the error or warning, such as the authoritative server. Unless otherwise noted, all elements below can be either an error or a warning, depending on whether a default response, such as a mapping, is included.
失われたサーバーが要求を完全に満たすことができない場合、問題の重大度に応じて、エラーまたは警告を返すことができます。クエリに対して有用な応答を返すことができない場合、<エラー>要素を返します。部分的に応答できた場合、別の応答要素の一部として<警告>要素を返しますが、応答はクライアントが望んでいたものではない場合があります。両方の要素について、「ソース」属性は、権威あるサーバーなど、元々エラーまたは警告を生成したサーバーに名前を付けます。特に明記しない限り、以下のすべての要素は、マッピングなどのデフォルトの応答が含まれているかどうかに応じて、エラーまたは警告のいずれかにすることができます。
LoST defines a pattern for errors, defined as <errors> elements in the Relax NG schema. This pattern defines a 'message' attribute containing human-readable text and an 'xml:lang' attribute denoting the language of the human-readable text. One or more such error elements are contained in the <errors> element.
Lostは、リラックスNGスキーマの<エラー>要素として定義されるエラーのパターンを定義します。このパターンは、人間の可読テキストと「XML：Lang」属性を含む「メッセージ」属性を定義します。そのようなエラー要素の1つ以上は、<エラー>要素に含まれています。
The following errors follow this basic pattern:
次のエラーは、この基本的なパターンに従います。
badRequest The server could not parse or otherwise understand a request, e.g., because the XML was malformed.
badRequest XMLが奇形であったため、サーバーは要求を解析したり理解したりすることができませんでした。
forbidden The server refused to send an answer. This generally only occurs for recursive queries, namely, if the client tried to contact the authoritative server and was refused.
禁止されているサーバーは、回答の送信を拒否しました。これは通常、再帰的なクエリ、つまり、クライアントが権威あるサーバーに連絡しようとして拒否された場合にのみ発生します。
internalError The server could not satisfy a request due to misconfiguration or other operational and non-protocol-related reasons.
内部侵略サーバーは、誤解やその他の運用上および非プロトコル関連の理由により、リクエストを満たすことができませんでした。
locationProfileUnrecognized None of the profiles in the request were recognized by the server (see Section 12).
LocationProfileunは、リクエストのプロファイルのいずれもサーバーによって認識されていませんでした（セクション12を参照）。
locationInvalid The geodetic or civic location in the request was invalid. For example, the longitude or latitude values fall outside the acceptable ranges.
location -valid要求の測地測定または市民の場所は無効でした。たとえば、経度または緯度の値は許容範囲の外側にあります。
SRSInvalid The spatial reference system (SRS) contained in the location element was not recognized or does not match the location profile.
SRSINVALIDロケーション要素に含まれる空間参照システム（SRS）は、位置プロファイルと一致していないか、一致しません。
loop During a recursive query, the server was about to visit a server that was already in the server list in the <path> element, indicating a request loop.
ループ再帰クエリ中に、サーバーは<Path>要素のサーバーリストに既にあるサーバーにアクセスしようとしており、リクエストループを示しています。
notFound The server could not find an answer to the query.
サーバーはクエリに対する答えを見つけることができませんでした。
serverError An answer was received from another LoST server, but it could not be parsed or otherwise understood. This error occurs only for recursive queries.
ServerError別の失われたサーバーから回答が受信されましたが、解析または理解することはできませんでした。このエラーは、再帰クエリに対してのみ発生します。
serverTimeout A time out occurred before an answer was received.
ServertimeOut回答が受信される前にタイムアウトが発生しました。
serviceNotImplemented The requested service URN is not implemented and no substitution was available.
Servicenotimeded要求されたサービスURNは実装されておらず、代替は利用できませんでした。
An example is below:
例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
source="resolver.example">
<internalError message="Software bug." xml:lang="en"/>
</errors>
Figure 17: Example of an error response
図17：エラー応答の例
A response MAY contain zero or more warnings. This pattern defines a 'message' attribute containing human-readable text and an 'xml:lang' attribute denoting the language of the human-readable text. One or more such warning elements are contained in the <warnings> element. To provide human-readable text in an appropriate language, the HTTP content negotiation capabilities (see Section 14) MAY be utilized by a server.
応答には、ゼロ以上の警告が含まれる場合があります。このパターンは、人間の可読テキストと「XML：Lang」属性を含む「メッセージ」属性を定義します。1つ以上のそのような警告要素は、<警告>要素に含まれています。適切な言語で人間の読み取り可能なテキストを提供するために、HTTPコンテンツネゴシエーション機能（セクション14を参照）は、サーバーによって利用される場合があります。
This version of the specification defines the following warnings:
仕様のこのバージョンは、次の警告を定義しています。
locationValidationUnavailable The <locationValidationUnavailable> element MAY be returned when a server wishes to notify a client that it cannot fulfill a location validation request. This warning allows a server to return mapping information while signaling this exception state.
locationValidationUnavailable <locationValidationUnavailable>要素は、サーバーがロケーション検証リクエストを満たせないことをクライアントに通知したい場合に返される場合があります。この警告により、サーバーはこの例外状態を知らせながらマッピング情報を返すことができます。
serviceSubstitution The <serviceSubstitution> element MAY be returned when a server was not able to fulfill a <findService> request for a given service URN. For example, a <findService> request with the 'urn:service:sos.police' service URN for a location in Uruguay may cause the LoST service to return a mapping for the 'urn:service:sos' service URN since Uruguay does not make use of the sub-services police, fire, and ambulance. If this warning is returned, then the <service> element in the response provides information about the service URN that refers to the mapping.
ServicesUbtitution <ServicesUbstitution>要素は、サーバーが特定のサービスURNのリクエストを満たすことができなかったときに返される場合があります。たとえば、uruguayの場所の「urn：service：sos.police」service urnを使用した<findservice>リクエストは、uruguayがuruguayであるため、「urn：service：surive：sos 'service urn」のマッピングを返すことがあります。サブサービス警察、消防、救急車を利用してください。この警告が返された場合、応答の<Service>要素は、マッピングを指すサービスURNに関する情報を提供します。
defaultMappingReturned The <defaultMappingReturned> element MAY be returned when a server was not able to fulfill a <findService> request for a given location but is able to respond with a default URI. For example, a nearby PSAP may be returned.
DefaultMappingReturned <DefaultMappingReturn>要素は、サーバーが特定の場所の<FindService>リクエストを満たすことができなかったが、デフォルトのURIで応答することができたときに返される場合があります。たとえば、近くのPSAPが返される場合があります。
An example of a warning is shown below:
警告の例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="fb8ed888433343b7b27865aeb38f3a99">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<warnings source="authoritative.example">
<defaultMappingReturned
message="Unable to determine PSAP for the given location;
using default PSAP"
xml:lang="en"/>
</warnings>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</findServiceResponse>
Figure 18: Example of a warning response
図18：警告応答の例
A LoST server can respond indicating that the querier should redirect the query to another server, using the <redirect> element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. During a recursive query, a server receiving a <redirect> response can decide whether it wants to follow the redirection or simply return the response to its upstream querier. The "expires" value in the response returned by the server handling the redirected query indicates the earliest time at which a new query might be needed (see Section 5.2). The query for the same tuple of location and service SHOULD NOT be directed to the server that gave redirect prior to that time.
失われたサーバーは、クエリエが<Redirect>要素を使用してクエリを別のサーバーにリダイレクトする必要があることを示す応答できます。要素には、クライアントが次に連絡する必要があるという失われたアプリケーションの一意の文字列（セクション4を参照）を示す「ターゲット」属性と、リダイレクト応答を生成したサーバーと「メッセージ」属性を示す「ソース」属性を含む。リダイレクト応答の理由。再帰クエリ中に、A <Redirect>応答を受信するサーバーは、リダイレクトに従うか、単にアップストリームクエリエへの応答を返すかどうかを決定できます。リダイレクトクエリを処理するサーバーによって返される応答の「有効期限」値は、新しいクエリが必要になる可能性のある最も早い時期を示しています（セクション5.2を参照）。同じ場所とサービスのタプルのクエリは、その前にリダイレクトを与えたサーバーに向けられないでください。
An example is below:
例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<redirect xmlns="urn:ietf:params:xml:ns:lost1"
target="eastpsap.example"
source="westpsap.example"
message="We have temporarily failed over." xml:lang="en"/>
Figure 19: Example of a redirect response
図19：リダイレクト応答の例
LoST needs an underlying protocol transport mechanism to carry requests and responses. This document defines the use of LoST over HTTP and LoST over HTTP-over-TLS. Client and server developers are reminded that full support of RFC 2616 HTTP facilities is expected. If LoST clients or servers re-implement HTTP, rather than using available servers or client code as a base, careful attention must be paid to full interoperability. Other transport mechanisms are left to future documents. The available transport mechanisms are determined through the use of the LoST U-NAPTR application. In protocols that support content type indication, LoST uses the media type application/lost+xml.
Lostは、リクエストと応答を伝えるために、基礎となるプロトコル輸送メカニズムが必要です。このドキュメントでは、httpを介したLostの使用とhttp-over-tls上でのLostの使用を定義しています。クライアントとサーバーの開発者は、RFC 2616 HTTP機能の完全なサポートが予想されることを思い出します。失われたクライアントまたはサーバーの再実装HTTPの場合、利用可能なサーバーまたはクライアントコードをベースとして使用するのではなく、完全な相互運用性に注意する必要があります。他の輸送メカニズムは、将来の文書に任されています。利用可能な輸送メカニズムは、Lost U-NAPTRアプリケーションを使用することにより決定されます。コンテンツタイプの表示をサポートするプロトコルでは、Lostはメディアタイプアプリケーション/Lost XMLを使用します。
When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP POST method. The HTTP request MUST use the Cache-Control response directive "no-cache" to disable HTTP-level caching even by caches that have been configured to return stale responses to client requests.
HTTP [3]およびHTTP-Over-TLS [4]を使用する場合、失われたリクエストはHTTP POSTメソッドを使用します。HTTPリクエストは、クライアントリクエストに対する古い応答を返すように構成されているキャッシュでさえ、キャッシュコントロール応答ディレクティブ「No-Cache」を使用してHTTPレベルのキャッシュを無効にする必要があります。
All LoST responses, including those indicating a LoST warning or error, are carried in 2xx responses, typically 200 (OK). Other 2xx responses, in particular 203 (Non-authoritative information), may be returned by HTTP caches that disregard the caching instructions. 3xx, 4xx, and 5xx HTTP response codes indicate that the HTTP request itself failed or was redirected; these responses do not contain any LoST XML elements. The 3xx responses are distinct from the redirects that are described in Section 13.3; the redirect operation in Section 13.3 occur after a LoST server processes the request. Where an HTTP-layer redirect will be general, a LoST server redirect as described in Section 13.3 might be specific to a specific service or be the result of other processing by the LoST server.
失われた警告またはエラーを示すものを含むすべての失われた応答は、通常200（OK）の2xx応答で運ばれます。他の2xx応答、特に203（非認証情報）は、キャッシュ指示を無視するHTTPキャッシュによって返される場合があります。3XX、4XX、および5XX HTTP応答コードは、HTTP要求自体が失敗またはリダイレクトされたことを示しています。これらの応答には、失われたXML要素は含まれていません。3XX応答は、セクション13.3で説明されているリダイレクトとは異なります。セクション13.3のリダイレクト操作は、失われたサーバーがリクエストを処理した後に発生します。HTTP-Layer Redirectが一般的になる場合、セクション13.3で説明されているように失われたサーバーリダイレクトは特定のサービスに固有であるか、失われたサーバーによる他の処理の結果である可能性があります。
The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed above.
HTTP URLは、上記で説明したように、U-NAPTRアプリケーションを介して失われたサーバー名から派生しています。
This section provides the Relax NG schema used by the LoST protocol in the compact form. The verbose form is included in Appendix A.
このセクションでは、失われたプロトコルがコンパクト形式で使用するリラックスNGスキーマを提供します。冗長形式は付録Aに含まれています。
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
##
## Location-to-Service Translation (LoST) Protocol
##
## A LoST XML instance has three request types, each with
## a corresponding response type: find service, list services,
## and get service boundary.
##
start =
findService
| listServices
| listServicesByLocation
| getServiceBoundary
| findServiceResponse
| listServicesResponse
| listServicesByLocationResponse
| getServiceBoundaryResponse
| errors
| redirect
##
## The queries.
##
div {
findService =
element findService {
requestLocation,
commonRequestPattern,
attribute validateLocation {
xsd:boolean >> a:defaultValue [ "false" ]
}?,
attribute serviceBoundary {
("reference" | "value") >> a:defaultValue [ "reference" ]
}?,
attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
}
listServices = element listServices { commonRequestPattern }
listServicesByLocation =
element listServicesByLocation {
requestLocation,
commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
}
getServiceBoundary =
element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}
##
## The responses.
##
div {
findServiceResponse =
element findServiceResponse {
mapping+, locationValidation?, commonResponsePattern, locationUsed
}
listServicesResponse =
element listServicesResponse { serviceList, commonResponsePattern }
listServicesByLocationResponse =
element listServicesByLocationResponse {
serviceList, commonResponsePattern, locationUsed
}
getServiceBoundaryResponse =
element getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern
}
}
##
## A pattern common to some of the queries.
##
div {
commonRequestPattern = service, path?, extensionPoint
}
}
##
## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
}
##
## Location in Requests
##
div {
requestLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Service Boundary
##
div {
serviceBoundary = element serviceBoundary { locationInformation }+
}
##
## Service Boundary Reference
##
div {
serviceBoundaryReference =
element serviceBoundaryReference {
source, serviceBoundaryKey, extensionPoint
}
serviceBoundaryKey = attribute key { xsd:token }
}
##
##
## Path -
## Contains a list of via elements -
## places through which information flowed
##
div {
path =
element path {
element via { source, extensionPoint }+
}
}
##
## Location Used
##
div {
locationUsed =
element locationUsed {
attribute id { xsd:token }
}?
}
##
## Expires pattern
##
div {
expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}
##
## A QName list
##
div {
qnameList = list { xsd:QName* }
}
##
## A location-to-service mapping.
##
div {
mapping =
element mapping {
element displayName {
xsd:string,
attribute xml:lang { xsd:language }
}*,
service,
(serviceBoundary | serviceBoundaryReference)?,
element uri { xsd:anyURI }*,
element serviceNumber {
xsd:token { pattern = "[0-9*#]+" }
}?,
extensionPoint,
expires,
attribute lastUpdated { xsd:dateTime },
source,
attribute sourceId { xsd:token },
message
}
}
##
## Location validation
##
div {
locationValidation =
element locationValidation {
element valid { qnameList }?,
element invalid { qnameList }?,
element unchecked { qnameList }?,
extensionPoint
}
}
##
## Errors and Warnings Container.
##
div {
exceptionContainer =
(badRequest?
& internalError?
& serviceSubstitution?
& defaultMappingReturned?
& forbidden?
& notFound?
& loop?
& serviceNotImplemented?
& serverTimeout?
& serverError?
& locationInvalid?
& locationProfileUnrecognized?),
extensionPoint,
source
errors = element errors { exceptionContainer }
warnings = element warnings { exceptionContainer }
}
##
## Basic Exceptions
##
div {
##
## Exception pattern.
##
basicException = message, extensionPoint
badRequest = element badRequest { basicException }
internalError = element internalError { basicException }
serviceSubstitution = element serviceSubstitution { basicException }
defaultMappingReturned =
element defaultMappingReturned { basicException }
forbidden = element forbidden { basicException }
notFound = element notFound { basicException }
loop = element loop { basicException }
serviceNotImplemented =
element serviceNotImplemented { basicException }
serverTimeout = element serverTimeout { basicException }
serverError = element serverError { basicException }
locationInvalid = element locationInvalid { basicException }
locationValidationUnavailable =
element locationValidationUnavailable { basicException }
locationProfileUnrecognized =
element locationProfileUnrecognized {
attribute unsupportedProfiles { xsd:NMTOKENS },
basicException
}
}
##
## Redirect.
##
div {
##
## Redirect pattern
##
redirect =
element redirect {
attribute target { appUniqueString },
source,
message,
extensionPoint
}
}
##
## Some common patterns.
##
div {
message =
(attribute message { xsd:token },
attribute xml:lang { xsd:language })?
service = element service { xsd:anyURI }?
appUniqueString =
xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString }
serviceList =
element serviceList {
list { xsd:anyURI* }
}
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST namespace.
##
notLost = 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 = notLost*
}
Figure 20: RelaxNG schema
図20：Relaxngスキーマ
The LoST protocol is mostly meant for machine-to-machine communications; as such, most of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. The content of the <displayName> element and the 'message' attributes may be displayed to the end user, and they are thus complex types designed for this purpose.
失われたプロトコルは、主に機械間通信を対象としています。そのため、その要素のほとんどは、直接的な人間の消費向けではないトークンです。これらのトークンがエンドユーザーに提示されている場合、いくつかのローカリゼーションが発生する必要がある場合があります。<displayName>要素と「メッセージ」属性のコンテンツがエンドユーザーに表示される可能性があるため、この目的のために設計された複雑なタイプです。
LoST exchanges information using XML. All XML processors are required to understand UTF-8 and UTF-16 encodings, and therefore all LoST clients and servers MUST understand UTF-8 and UTF-16 encoded XML. Additionally, LoST servers and clients MUST NOT encode XML with encodings other than UTF-8 or UTF-16.
XMLを使用して失われた交換情報。すべてのXMLプロセッサは、UTF-8およびUTF-16エンコーディングを理解するために必要であるため、すべての失われたクライアントとサーバーは、UTF-8およびUTF-16エンコードされたXMLを理解する必要があります。さらに、紛失したサーバーとクライアントは、UTF-8またはUTF-16以外のエンコーディングでXMLをエンコードしてはなりません。
This document registers the following U-NAPTR application service tag:
このドキュメントは、次のU-NAPTRアプリケーションサービスタグを登録します。
Application Service Tag: LoST
アプリケーションサービスタグ：紛失
Defining Publication: The specification contained within this document.
公開の定義：このドキュメントに含まれる仕様。
This document registers the following U-NAPTR application protocol tags:
このドキュメントは、次のU-NAPTRアプリケーションプロトコルタグを登録します。
o Application Protocol Tag: http
o アプリケーションプロトコルタグ：http
Defining Publication: RFC 2616 [3]
出版物の定義：RFC 2616 [3]
o Application Protocol Tag: https
o アプリケーションプロトコルタグ：https
Defining Publication: RFC 2818 [4]
出版物の定義：RFC 2818 [4]
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [7] and guidelines in RFC 3023 [5].
この仕様では、RFC 4288 [7]の手順とRFC 3023 [5]のガイドラインに従って、新しいMIMEタイプの登録を要求します。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: lost+xml
MIMEサブタイプ名：Lost XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset Indicates the character encoding of enclosed XML.
オプションのパラメーター：charsetは、囲まれたXMLの文字エンコードを示します。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [5], Section 3.2.
考慮事項のエンコーディング：使用する文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。RFC 3023 [5]、セクション3.2を参照してください。
Security considerations: This content type is designed to carry LoST protocol payloads.
セキュリティ上の考慮事項：このコンテンツタイプは、失われたプロトコルペイロードを運ぶように設計されています。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5222
公開された仕様：RFC 5222
Applications that use this media type: Emergency and location-based systems
このメディアタイプを使用するアプリケーション：緊急および位置ベースのシステム
Additional information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .lostxml
ファイル拡張子：.lostxml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@nsn.com
個人および電子メールアドレス詳細情報：Hannes Tschofenig、hannes.tchofenig@nsn.com
Intended usage: LIMITED USE
意図された使用法：使用されています
Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
著者：この仕様は、メーリングリストアドレス<ecrit@ietf.org>を備えたIETF ECRITワーキンググループの作業項目です。
Change controller:
The IESG <iesg@ietf.org>
URI: urn:ietf:params:xml:schema:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com).
登録者の連絡先：IETF ECRITワーキンググループ、Hannes Tschofenig（hannes.tschofenig@nsn.com）。
Relax NG Schema: The Relax NG schema to be registered is contained in Section 15. Its first line is
リラックスNGスキーマ：登録するリラックスNGスキーマはセクション15に含まれています。その最初の行は
default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is
そしてその最後の行はです
}
}
URI: urn:ietf:params:xml:ns:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com).
登録者の連絡先：IETF ECRITワーキンググループ、Hannes Tschofenig（hannes.tschofenig@nsn.com）。
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 Namespace</title>
</head>
<body>
<h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">
RFC5222</a>.</p>
</body>
</html>
END
17.5. LoST Location Profile Registry
This document creates a registry of location profile names for the LoST protocol. Profile names are XML tokens. This registry will operate in accordance with RFC 5226 [2], Standards Action.
このドキュメントは、Lost Protocolのロケーションプロファイル名のレジストリを作成します。プロファイル名はXMLトークンです。このレジストリは、RFC 5226 [2]、標準アクションに従って動作します。
geodetic-2d: Defined in Section 12.2.
測地-2D：セクション12.2で定義されています。
civic: Defined in Section 12.3.
シビック：セクション12.3で定義されています。
There are several threats to the overall system of which service mapping forms a part. An attacker that can obtain service contact URIs can use those URIs to attempt to disrupt those services. An attacker that can prevent the lookup of contact URIs can impair the reachability of such services. An attacker that can eavesdrop on the communication requesting this lookup can surmise the existence of an emergency and possibly its nature, and may be able to use this to launch a physical attack on the caller.
サービスマッピングがパーツを形成するシステム全体にいくつかの脅威があります。サービスの連絡先を取得できる攻撃者は、これらのURIを使用してそれらのサービスを混乱させようとすることができます。URISの接触の検索を防ぐことができる攻撃者は、そのようなサービスの到達可能性を損なう可能性があります。このルックアップを要求するコミュニケーションを盗聴できる攻撃者は、緊急事態とその性質の存在を推測し、これを使用して発信者に対する物理的な攻撃を開始できる可能性があります。
To avoid an attacker modifying the query or its result, Transport Layer Security (TLS) MUST be implemented and SHOULD be used. Use is RECOMMENDED both for clients' queries to servers and for queries among servers; this latter recommendation is to help avoid LoST cache poisoning attacks by replacing answers given to caching LoST servers.
攻撃者がクエリまたはその結果を変更するのを避けるには、輸送層のセキュリティ（TLS）を実装する必要があり、使用する必要があります。使用は、サーバーへのクライアントのクエリとサーバー間のクエリの両方に推奨されます。この後者の推奨事項は、失われたサーバーに与えられた回答を置き換えることにより、失われたキャッシュ中毒攻撃を避けるのに役立ちます。
The use of server identity checks with TLS, as described in Section 3.1 of [4], is also RECOMMENDED. Omitting the server identity check allows an attacker to masquerade as a LoST server, so this approach should be used only when getting any answer, even from a potentially malicious LoST server, is preferred over closing the connection (and thus not getting any answer at all). The host name compared against the server certificate is the host name in the URI, not the DNS name used as input to NAPTR resolution.
[4]のセクション3.1で説明されているように、TLSによるサーバーIDチェックの使用も推奨されます。サーバーのアイデンティティチェックを省略することで、攻撃者が失われたサーバーを装ったものにすることができるため、このアプローチは、潜在的に悪意のある失われたサーバーからでも回答を得るときにのみ使用する必要があります。）。サーバー証明書に対して比較されたホスト名は、URIのホスト名であり、NAPTR解像度への入力として使用されるDNS名ではありません。
Note that the security considerations in [22] recommend comparing the input of NAPTR resolution to the certificate, not the output (host name in the URI). This approach was not chosen because in emergency service use cases, it is likely that deployments will see a large number of inputs to the U-NAPTR algorithm resolving to a single server, typically run by a local emergency services authority. In this case, checking the input to the NAPTR resolution against the certificates provided by the LoST server would be impractical, as the list of organizations using it would be large, subject to rapid change, and unknown to the LoST server operator.
[22]のセキュリティ上の考慮事項は、NAPTR解像度の入力を出力（URIのホスト名）ではなく証明書と比較することを推奨することに注意してください。このアプローチは選択されていません。なぜなら、緊急サービスのユースケースでは、展開が1つのサーバーに解決するU-NAPTRアルゴリズムへの多数の入力が表示される可能性が高いためです。この場合、失われたサーバーが提供する証明書に対するNAPTR解像度への入力を確認することは非現実的であり、それを使用する組織のリストは大きく、急速な変更の対象であり、失われたサーバーオペレーターには知られていないためです。
The use of server identity does leave open the possibility of DNS-based attacks, as the NAPTR records may be altered by an attacker. The attacks include, for example, interception of DNS packets between the client and the recursive name server, DNS cache poisoning, and intentional modifications by the recursive name server; see [23] for more comprehensive discussion.
サーバーのアイデンティティを使用すると、NAPTRレコードが攻撃者によって変更される可能性があるため、DNSベースの攻撃の可能性が明らかになります。攻撃には、たとえば、クライアントと再帰名サーバー間のDNSパケットの傍受、DNSキャッシュ中毒、再帰名サーバーによる意図的な変更が含まれます。より包括的な議論については、[23]を参照してください。
DNS Security (DNSSEC) [20] can be used to protect against these threats. While DNSSEC is incompletely deployed, users should be aware of the risk, particularly when they are requesting NAPTR records in environments where the local recursive name server, or the network between the client and the local recursive name server, is not considered trustworthy.
DNSセキュリティ（DNSSEC）[20]を使用して、これらの脅威から保護できます。DNSSECは不完全に展開されていますが、特にローカル再帰名サーバー、またはクライアントとローカル再帰名サーバーの間のネットワークが信頼できるとは見なされない環境でNAPTRレコードを要求している場合、ユーザーはリスクに注意する必要があります。
LoST deployments that are unable to use DNSSEC and unwilling to trust DNS resolution without DNSSEC cannot use the NATPR-based discovery of LoST servers as is. When suitable configuration mechanisms are available, one possibility is to configure the LoST server URIs (instead of the domain name to be used for NAPTR resolution) directly. Future specifications for applying LoST in non-emergency services may also specify additional discovery mechanisms and name matching semantics.
DNSSECを使用できず、DNSSECなしでDNS解像度を信頼したくない展開の紛失は、その現状で失われたサーバーのNATPRベースの発見を使用できません。適切な構成メカニズムが利用可能な場合、1つの可能性は、（NAPTR解像度に使用するドメイン名の代わりに）ロストサーバーURIを直接構成することです。非緊急サービスで紛失を適用するための将来の仕様は、追加の発見メカニズムと名前マッチングセマンティクスを指定する場合もあります。
Generally, LoST servers will not need to authenticate or authorize clients presenting mapping queries. If they do, an authentication of the underlying transport mechanism, such as HTTP basic and digest authentication, MAY be used. Basic authentication SHOULD only be used in combination with TLS.
一般に、紛失したサーバーは、マッピングクエリを提示するクライアントを認証または承認する必要はありません。もしそうなら、HTTP BasicおよびDigest認証など、基礎となる輸送メカニズムの認証を使用できます。基本認証は、TLSと組み合わせてのみ使用する必要があります。
A more detailed description of threats and security requirements is provided in [17]. The threats and security requirements in non-emergency service uses of LoST may be considerably different from those described here. For example, an attacker might seek monetary benefit by returning service mapping information that directed users to specific service providers. Before deploying LoST in new contexts, a thorough analysis of the threats and requirements specific to that context should be undertaken and decisions made on the appropriate mitigations.
脅威とセキュリティ要件のより詳細な説明は[17]に記載されています。失われた緊急サービスの使用における脅威とセキュリティ要件は、ここで説明したものとはかなり異なる場合があります。たとえば、攻撃者は、ユーザーを特定のサービスプロバイダーに向けたサービスマッピング情報を返却することにより、金銭的利益を求める場合があります。新しいコンテキストでlostを展開する前に、そのコンテキストに固有の脅威と要件の徹底的な分析を実施し、適切な緩和について決定する必要があります。
We would like to the thank the following working group members for the detailed review of previous LoST document versions:
以前の失われたドキュメントバージョンの詳細なレビューについて、次のワーキンググループメンバーに感謝します。
o Martin Thomson (Review July 2006)
o マーティン・トムソン（2006年7月のレビュー）
o Jonathan Rosenberg (Review July 2006) o Leslie Daigle (Review September 2006)
o ジョナサン・ローゼンバーグ（2006年7月のレビュー）oレスリー・デイグル（2006年9月レビュー）
o Shida Schubert (Review November 2006)
o Shida Schubert（2006年11月のレビュー）
o Martin Thomson (Review December 2006)
o マーティン・トムソン（2006年12月のレビュー）
o Barbara Stark (Review January 2007)
o バーバラ・スターク（2007年1月のレビュー）
o Patrik Faltstrom (Review January 2007)
o Patrik Faltstrom（2007年1月のレビュー）
o Shida Schubert (Review January 2007 as a designated expert reviewer)
o Shida Schubert（2007年1月に指定された専門家レビュアーとしてレビュー）
o Jonathan Rosenberg (Review February 2007)
o ジョナサン・ローゼンバーグ（2007年2月のレビュー）
o Tom Taylor (Review February 2007)
o トム・テイラー（2007年2月のレビュー）
o Theresa Reese (Review February 2007)
o テレサ・リース（2007年2月のレビュー）
o Shida Schubert (Review February 2007)
o Shida Schubert（2007年2月のレビュー）
o James Winterbottom (Review July 2007)
o ジェームズ・ウィンターボトム（2007年7月のレビュー）
o Karl Heinz Wolf (Review May and June 2007)
o カールハインツウルフ（2007年5月と6月のレビュー）
We would also like to thank the following working group members for their input to selected design aspects of the LoST protocol:
また、失われたプロトコルの選択されたデザインの側面への入力について、次のワーキンググループメンバーに感謝します。
o Leslie Daigle and Martin Thomson (DNS-based LoST discovery procedure)
o レスリー・ダイグルとマーティン・トムソン（DNSベースの失われた発見手順）
o John Schnizlein (authoritive LoST answers)
o ジョン・シニズレイン（著者の失われた回答）
o Rohan Mahy (display names)
o Rohan Mahy（ディスプレイ名）
o James Polk (error handling)
o ジェームズ・ポーク（エラー処理）
o Ron Watro and Richard Barnes (expiry of cached data)
o Ron WatroとRichard Barnes（キャッシュデータの有効期限）
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James Winterbottom (indication of PSAP confidence level)
o スティーブン・エッジ、キース・ドレイジ、トム・テイラー、マーティン・トムソン、ジェームズ・ウィンターボトム（PSAP信頼レベルの兆候）
o Martin Thomson (service boundary references)
o
o Martin Thomson (service URN in LoST response message)
o Martin Thomson（失われた応答メッセージのサービスURN）
o Clive D.W. Feather, Martin Thomson (validation functionality) o Roger Marshall (PSAP preference in LoST response)
o Clive D.W.フェザー、マーティントムソン（検証機能）Oロジャーマーシャル（失われた応答のPSAP選好）
o James Winterbottom, Marc Linsner, Keith Drage, Tom Taylor, Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule, Pierre Desjardins (location profiles)
o ジェームズ・ウィンターボトム、マーク・リンナー、キース・ドレイジ、トム・テイラー、マーティン・トムソン、ジョン・シュニズレイン、シダ・シューベルト、クライヴD.W.フェザー、リチャード・スタストニー、ジョン・ハイタル、ロジャー・マーシャル、ジャン・フランソワ・ミュール、ピエール・デヤルディン（場所プロファイル）
o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson, Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list services functionality)
o マイケル・ハンマー、パトリック・ファートストローム、リチャード・スタストニー、マーティン・トムソン、ロジャー・マーシャル、トム・テイラー、スペンサー・ドーキンス、キース・ドレイジ（リストサービス機能）
o Martin Thomson, Michael Hammer (mapping of services)
o マーティン・トムソン、マイケル・ハンマー（サービスのマッピング）
o Shida Schubert, James Winterbottom, Keith Drage (default service URN)
o Shida Schubert、James Winterbottom、Keith Drage（デフォルトのサービスURN）
o Otmar Lendl (LoST aggregation)
o otmar lendl（失われた集約）
o Tom Taylor (terminology)
o トム・テイラー（用語）
Klaus Darilion and Marc Linsner provided miscellaneous input to the design of the protocol. Finally, we would like to thank Brian Rosen, who participated in almost every discussion thread.
Klaus DarilionとMarc Linsnerは、プロトコルの設計にその他の入力を提供しました。最後に、ほぼすべてのディスカッションスレッドに参加したブライアンローゼンに感謝したいと思います。
Early implementation efforts led to good feedback by two open source implementation groups. We would like to thank the implementers for their work and for helping us to improve the quality of the specification:
早期の実装の取り組みにより、2つのオープンソース実装グループによる適切なフィードバックが発生しました。実装者の仕事と仕様の品質の向上を支援してくれたことに感謝します。
o Wonsang Song
o Wonsangの歌
o Jong-Yul Kim
o ジョン・ユル・キム
o Anna Makarowska
o アンナ・マカロウスカ
o Krzysztof Rzecki
o krzysztof rzecki
o Blaszczyk Piotr
o Blaszczyk Piotr
We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault, and Tim Polk for their IESG review comments. Blocking IESG comments were also received from Pasi Eronen (succeeding Sam Hartman's review) and Cullen Jennings. Adjustments have been made to several pieces of text to satisfy these requests for changes, most notably in the Security Considerations and in the discussion of redirection in the presence of overlapping coverage areas.
IESGレビューのコメントをしてくれたJon Peterson、Dan Romascanu、Lisa Dusseault、Tim Polkに感謝します。IESGのコメントのブロックは、Pasi Eronen（Sam Hartmanのレビューの成功）とCullen Jenningsからも受け取られました。これらの変更の要求を満たすために、特にセキュリティの考慮事項と重複するカバレッジ領域の存在下でのリダイレクトの議論において、いくつかのテキストを調整しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[2] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[4] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[6] ピーターソン、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[8] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[8] Daigle、L。、「URISを使用したドメインベースのアプリケーションサービスの場所と動的委任ディスカバリーサービス（DDDS）」、RFC 4848、2007年4月。
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[9] Schulzrinne、H。、「緊急およびその他の有名なサービスのためのユニフォームリソース名（URN）」、RFC 5031、2008年1月。
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[10] Thomson、M。and J. Winterbottom、「存在情報データ形式の市民ロケーション形式の改訂データ形式の場所オブジェクト（PIDF-LO）」、RFC 5139、2008年2月。
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OGC Standard OpenGIS 03-105r1, April 2004.
[11] Cox、S.、Daisey、P.、Lake、R.、Portele、C。、およびA. Whiteside、「地理情報 - 地理的マークアップ言語（GML）」、OGC Standard OpenGis 03-105R1、2004年4月。
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification , December 2006.
[12] Reed、C。and M. Thomson、「GML 3.1.1 Internet Engineering Task Force（IETF）が使用するためのPIDF-LO形状アプリケーションスキーマ」、候補OpenGIS実装仕様、2006年12月。
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Work in Progress, February 2008.
[13] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「Geopriv Pidf-loの使用法の明確化、考慮事項、推奨」、2008年2月、進行中の作業。
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[14] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[15] Saint-Andre、P.、ed。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 3921、2004年10月。
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[16] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[17] Taylor、T.、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「緊急コールマーキングとマッピングのセキュリティの脅威と要件」、RFC 5069、2008年1月。
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[18] Schulzrinne、H。およびR. Marshall、「インターネットテクノロジーとの緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", Work in Progress, September 2007.
[19] Schulzrinne、H。、「場所からURLへのマッピングアーキテクチャとフレームワーク」、2007年9月、進行中の作業。
[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[20] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, February 2008.
[21] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の実践」、2008年2月、Work in Progress。
[22] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[22] Daigle、L。and A. Newton、「SRV RRSおよびDynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[23] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ RelaxNG>.
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ rackng>。
[25] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[25] Schulzrinne、H.、Polk、J。、およびH. Tschofenig、「ダイナミックホスト構成プロトコル（DHCP）を使用した場所からサービスへの翻訳（Lost）サーバーの発見」、RFC 5223、2008年8月。
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1"
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>
Location-to-Service Translation (LoST) Protocol
A LoST XML instance has three request types, each with
a corresponding response type: find service, list services,
and get service boundary.
</a:documentation>
<choice>
<ref name="findService"/>
<ref name="listServices"/>
<ref name="listServicesByLocation"/>
<ref name="getServiceBoundary"/>
<ref name="findServiceResponse"/>
<ref name="listServicesResponse"/>
<ref name="listServicesByLocationResponse"/>
<ref name="getServiceBoundaryResponse"/>
<ref name="errors"/>
<ref name="redirect"/>
</choice>
</start>
<div>
<a:documentation>
The queries.
</a:documentation>
<define name="findService">
<element name="findService">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="validateLocation">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="serviceBoundary">
<choice>
<value>reference</value>
<value>value</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServices">
<element name="listServices">
<ref name="commonRequestPattern"/>
</element>
</define>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
The responses.
</a:documentation>
<define name="findServiceResponse">
<element name="findServiceResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<optional>
<ref name="locationValidation"/>
</optional>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="listServicesResponse">
<element name="listServicesResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
</element>
</define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse">
<ref name="serviceBoundary"/>
<ref name="commonResponsePattern"/>
</element>
</define>
</div>
<div>
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<define name="commonRequestPattern">
<ref name="service"/>
<optional>
<ref name="path"/>
</optional>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
A pattern common to responses.
</a:documentation>
<define name="commonResponsePattern">
<zeroOrMore>
<ref name="warnings"/>
</zeroOrMore>
<ref name="path"/>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
Location in Requests
</a:documentation>
<define name="requestLocation">
<oneOrMore>
<element name="location">
<attribute name="id">
<data type="token"/>
</attribute>
<ref name="locationInformation"/>
</element>
</oneOrMore>
</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>
Service Boundary
</a:documentation>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source"/>
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
<define name="serviceBoundaryKey">
<attribute name="key">
<data type="token"/>
</attribute>
</define>
</div>
<div>
<a:documentation>
Path -
Contains a list of via elements -
places through which information flowed
</a:documentation>
<define name="path">
<element name="path">
<oneOrMore>
<element name="via">
<ref name="source"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
</div>
<div>
<a:documentation>
Location Used
</a:documentation>
<define name="locationUsed">
<optional>
<element name="locationUsed">
<attribute name="id">
<data type="token"/>
</attribute>
</element>
</optional>
</define>
</div>
<div>
<a:documentation>
Expires pattern
</a:documentation>
<define name="expires">
<attribute name="expires">
<choice>
<data type="dateTime"/>
<value>NO-CACHE</value>
<value>NO-EXPIRATION</value>
</choice>
</attribute>
</define>
</div>
<div>
<a:documentation>
A QName list
</a:documentation>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<div>
<a:documentation>
A location-to-service mapping.
</a:documentation>
<define name="mapping">
<element name="mapping">
<zeroOrMore>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="service"/>
<optional>
<choice>
<ref name="serviceBoundary"/>
<ref name="serviceBoundaryReference"/>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
<data type="token">
<param name="pattern">[0-9*#]+</param>
</data>
</element>
</optional>
<ref name="extensionPoint"/>
<ref name="expires"/>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="source"/>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location validation
</a:documentation>
<define name="locationValidation">
<element name="locationValidation">
<optional>
<element name="valid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="invalid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="unchecked">
<ref name="qnameList"/>
</element>
</optional>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
Errors and Warnings Container.
</a:documentation>
<define name="exceptionContainer">
<interleave>
<optional>
<ref name="badRequest"/>
</optional>
<optional>
<ref name="internalError"/>
</optional>
<optional>
<ref name="serviceSubstitution"/>
</optional>
<optional>
<ref name="defaultMappingReturned"/>
</optional>
<optional>
<ref name="forbidden"/>
</optional>
<optional>
<ref name="notFound"/>
</optional>
<optional>
<ref name="loop"/>
</optional>
<optional>
<ref name="serviceNotImplemented"/>
</optional>
<optional>
<ref name="serverTimeout"/>
</optional>
<optional>
<ref name="serverError"/>
</optional>
<optional>
<ref name="locationInvalid"/>
</optional>
<optional>
<ref name="locationProfileUnrecognized"/>
</optional>
</interleave>
<ref name="extensionPoint"/>
<ref name="source"/>
</define>
<define name="errors">
<element name="errors">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="exceptionContainer"/>
</element>
</define>
</div>
</div>
<div>
<a:documentation>
Basic Exceptions
</a:documentation>
<define name="basicException">
<a:documentation>
Exception pattern.
</a:documentation>
<ref name="message"/>
<ref name="extensionPoint"/>
</define>
<define name="badRequest">
<element name="badRequest">
<ref name="basicException"/>
</element>
</define>
<define name="internalError">
<element name="internalError">
<ref name="basicException"/>
</element>
</define>
<define name="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="basicException"/>
</element>
</define>
<define name="defaultMappingReturned">
<element name="defaultMappingReturned">
<ref name="basicException"/>
</element>
</define>
<define name="forbidden">
<element name="forbidden">
<ref name="basicException"/>
</element>
</define>
<define name="notFound">
<element name="notFound">
<ref name="basicException"/>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicException"/>
</element>
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicException"/>
</element>
</define>
<define name="serverTimeout">
<element name="serverTimeout">
<ref name="basicException"/>
</element>
</define>
<define name="serverError">
<element name="serverError">
<ref name="basicException"/>
</element>
</define>
<define name="locationInvalid">
<element name="locationInvalid">
<ref name="basicException"/>
</element>
</define>
<define name="locationValidationUnavailable">
<element name="locationValidationUnavailable">
<ref name="basicException"/>
</element>
</define>
<define name="locationProfileUnrecognized">
<element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles">
<data type="NMTOKENS"/>
</attribute>
<ref name="basicException"/>
</element>
</define>
</div>
<div>
<a:documentation>
Redirect.
</a:documentation>
<define name="redirect">
<a:documentation>
Redirect pattern
</a:documentation>
<element name="redirect">
<attribute name="target">
<ref name="appUniqueString"/>
</attribute>
<ref name="source"/>
<ref name="message"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
Some common patterns.
</a:documentation>
<define name="message">
<optional>
<group>
<attribute name="message">
<data type="token"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="appUniqueString">
<data type="token">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
<define name="source">
<attribute name="source">
<ref name="appUniqueString"/>
</attribute>
</define>
<define name="serviceList">
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI"/>
</zeroOrMore>
</list>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLost">
<a:documentation>
Any element not in the LoST namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost1"/>
<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="notLost"/>
</zeroOrMore>
</define>
</div>
</grammar>
</grammar>
Figure 21
図21
The XML examples and Relax NG schemas may be found online [24].
XMLの例とリラックスNGスキーマは、オンラインで見つけることができます[24]。
Authors' Addresses
著者のアドレス
Ted Hardie Qualcomm, Inc.
Ted Hardie Qualcomm、Inc。
EMail: hardie@qualcomm.com
Andrew Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 US
インターネット番号のためのアンドリューニュートンアメリカンレジストリ3635コンコルドパークウェイ、スイート200シャンティリー、バージニア州20151米国
Phone: +1 703 227 9894
EMail: andy@hxr.us
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。