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.
この文書は、マッピングサービス識別子及びサービス接触URIに測地または市民の位置情報用の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
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.
そのような権限ポインタ（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.
この文書[6] 1つ以上のサービスURIにプレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）と互換性のあるサービス識別子と位置情報をマッピングするためのプロトコルを記載しています。サービス識別子は、[9]で説明サービスのURNの形をとります。ここで、位置情報は、GML [11]のために定義され、その結果ジオ形状を含む改訂市民の位置情報[10]とPIDF-LOプロファイルの部分集合[13]、[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.
この文書名は、このプロトコルは、場所・ツー・サービス翻訳のために、「失われました」。失われた満たすマッピング・プロトコルのための要件[18]。失われたサービスのURLと関連する情報へのマッピング位置とサービスのURNを中心とした操作の数を、提供します。失われたマッピングクエリは、市民や測地のいずれかの位置情報を含むことができます。市民のアドレスのために、失われたが[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.
この文書で定義されているように、失われたメッセージは、要求と応答の完全性と機密性を保護するためにTLSの使用を容易に、HTTPおよびHTTPSプロトコル交換に運ばれます。
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).
照会メッセージは、位置情報と、失われたサーバーに失われたクライアントから（[9]参照）ユニフォームリソース名（URN）としてエンコードサービス識別子を運びます。失われたサーバは、一つ以上のユニフォームリソース識別子（URIの）への入力値をマッピングするために、そのデータベースを使用して失われたクライアントへの応答メッセージに、そのようなサービス境界に関するヒントとしてオプション情報と共にそれらの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
マッピング：マッピングは、入力として位置及びサービス識別子を受け取り、一つ以上の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.
権威サーバーを失った：認証サーバは、サーバとして機能し、正常URIへの入力位置及びサービス識別子を解決するか、URIセット。
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にマッピング又は与えられたサービスのURIのセットその内部領域を囲みます。サービス境界は、いくつかの非連続的な幾何学的形状からなることができます。
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.
第9章で説明したように、<getServiceBoundary>と<getServiceBoundaryResponse> A失われたクライアントは、この要求と応答で、サービスの境界を取得します。
<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> A失われたクライアントサービスは、特定の場所の領域のために使用可能であり、この要求と応答と判断することができます。セクション11は、詳細を説明します。
LoST clients may initiate any of the above queries at any time. Among the common triggers are:
失われたクライアントは、いつでも上記のクエリのいずれかを開始することができます。共通のトリガー中には：
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;
前記SIPメッセージは、ロケーションベースのコールルーティングを行うSIPプロキシに到達します。
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]など、サービス固有の最も良いCurrent Practice（BCP）の文書は、クライアントは単にサービスを必要とする前に、またはキャッシュされた回答に依存しているかどうかマッピングサービスを起動することが期待されているかどうかを決定します。キャッシュエントリは（5.2節を参照）、その有効期限に期限が切れる、または彼らは、サービス領域の境界を越えて呼び出し側のデバイスに移動する場合は無効になります。サービス固有の最も良いCurrent Practiceドキュメントは、サービスに最も適切な接触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'.
失われたサーバーは、DNS名の形式で、[8]アプリケーションのユニークな文字列（URI-有効NAPTR /ダイナミックな委譲発見サービス）U-NAPTR / DDDSによって識別されます。例では、「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に「example.com」のためのU-NAPTRの解像度を表示します好適。
example.com.
えぁｍｐぇ。こｍ。
IN NAPTR 100 10 "u" "LoST:https" "!.*!https://lostserver.example.com/secure!" ""
NAPTR 100 10 "U" "失われた：https" を "！。！* HTTPS：//lostserver.example.com/secure！" 「」
IN NAPTR 200 10 "u" "LoST:http" "!.*!http://lostserver.example.com!" ""
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>要素は、サービス領域と関連するサービスのURLを記述し、失われたコアデータ要素です。その属性と要素は、以下のサブセクションで説明されています。
5.1. The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated' Attributes
5.1. マッピングデータソース：「ソース」、「ソースID」、および「lastUpdatedの属性
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'.
「ソース」、「ソースID」、および「lastUpdated」は一意に特定のマッピング・レコードを識別する属性。彼らは、マッピングのための信頼できるソースによって作成され、マッピングがキャッシュから提供されたときに変更されることはありません。すべての3つの属性は、すべての<マッピング>要素に必要とされます。受信機は、同じ「ソース」と「ソースID」と「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.
「ソースID」属性は、特定のマッピングを識別し、その特定のサービスの信頼できるソースによって維持されるすべての異なるマッピングの中で一意でなければならない不透明なトークンが含まれています。例えば、汎用一意識別子（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」属性は、「ソース」と「ソースID」の組み合わせによって識別され、マッピングの際に特定のインスタンスを説明し、最後に変更されました。この属性の内容は、タイムゾーンインジケータとして文字「Z」と正規のUTC表現を使用して、そのtimezoned形式のXMLデータDateTime型を持っています。
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.
属性マッピングが無効になるときの絶対時間が含まれている「有効期限が切れ」。この属性の内容は、標準的な表現で、timezoned XMLのDateTime型です。 <mapping>要素は、「期限が切れ」属性を含まなければなりません。
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.
任意に、この属性が「NO-CACHE」と「NO呼気」代わりのdateTime値の値を含んでいてもよいです。値「NO-CACHE」はマッピングがキャッシュされるべきでないことを示します。 「NO呼気」の値は、マッピングが満了しないことを示しています。
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.
「：LANGのxml」属性のテキストのレンダリングを支援するための言語タグが含まれているゼロ以上の<のdisplayName>要素は、人間のユーザ、と注釈を付けた各への表示に適した文字列を使用してサービスを記述します。
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>要素を設定したときに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. <サービス>のサービス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.場合は、しかし、サービスURNによって識別される要求されたサービス、[9]要求内の<service>要素では、場所存在しないサーバが<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要素内で、しかし、添加されている複数の場所があってもよいです。いくつかの<serviceBoundary>領域が容易に単一の形状または市民の位置で表現できなかったため、これは必要です。応答に含まれる場合、<serviceBoundary>要素は、要求と同じプロファイルを使用して少なくとも1つのサービス境界を含まなければなりません。
A service boundary is requested by the client, using the 'serviceBoundary' attribute in the request with the value set to "value".
サービス境界は、「値」に設定した値とのリクエストで「serviceBoundary」属性を使用して、クライアントによって要求されます。
5.6. Service Boundaries by Reference: The <serviceBoundaryReference> Element
5.6. <serviceBoundaryReference>要素：参照によるサービスの境界
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.
サービス境界への参照は、「参照」に設定した値とのリクエストで「serviceBoundary」属性を使用して、クライアントから要求されています。失われたサーバーは、値によって、サービスの境界を返すために、または応答で、<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」や「一口」と「SIPS」の両方などのプロトコルの両方を確保し、定期的なバージョンを含むように許容されます。
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.
ループを防止するために、要求および応答経路のトレースを可能にするために、再帰を許可するすべての要求（セクション4を参照）<経由>一つ以上の要素、失われたアプリケーション固有の文字列を含む属性を有する各が含まの<path>要素を含みます。要素<経由>の順序が失われたサーバ、すなわち、<経由>最初の順序に対応する要素が最初に要求を発行するクライアントからの要求を受信したサーバを識別します。再帰クエリ操作のすべてのサーバーは、それを受けた最初のサーバを含む、<パス>要素に含まれています。
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.
そのような認証サーバとして、それを転送するのではなく、要求に応答するサーバは、コピーレスポンスにそのまま<パス>要素。応答が戻って照会クライアントへのサーバーのチェーンを横断する際に、<パス>要素は、レスポンスに変更されていません。
If a query is answered iteratively, the querier includes all servers that it has already contacted.
クエリが反復的に答えている場合、クエリアは、それがすでに接触したすべてのサーバーが含まれています。
When a cached mapping is returned, then the <path> element cached together with the mapping is returned.
キャッシュされたマッピングが返されると、マッピングと一緒にキャッシュされた<パス>要素が返されます。
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の例では、答えは（権威）から回答を得たpolizei.muenchen.de.exampleのサーバを失っesgw.ueber-110.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>要素を識別する「ID」属性を含まなければなりません。識別子の形式は、クライアントに残されています。それは、例えば、位置情報のハッシュを使用することができます。サーバは、それが<locationUsed>タグで使用される<場所>要素の識別子を返します。
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>クエリは、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).
以下は、警察（：サービス：sos.police URN）に関連付けられたサービスのために、測地座標を使用して、場所にサービスをマッピングする一例です。
<?xml version="1.0" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value" recursive="true">
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/gml > " "serviceBoundary =" 値」再帰=" 真
<location id="6020688f1ce1896d" profile="geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> </location> <service>urn:service:sos.police</service>
<位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <P2：ポイントID = "POINT1" srsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <P2：POS> 37.775 -122.422 < / P2：POS> </ P2：ポイント> </ location>の<サービス> URN：サービス：sos.police </サービス>
</findService>
</ findService>
Figure 1: A <findService> geodetic query
図1：<findService>測地クエリ
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.
上記のクエリを考えると、サーバは、そのサービスに関連するサービス、および情報で応答します。そして「XMPP：以下の例では、サーバはURIの「nypd@example.com一口」を介してそれらを連絡することをクライアントに指示する、ニューヨーク市警察に警察サービスのクライアントによって指定された場所をマッピングしています：nypd@example.com」。また、サーバはクライアントにこのサービスのための測地、二次元の境界を与えています。マッピングは、最後の特定のサービスの境界や有効期限を越えて、クライアントの場所の変更に達した場合は、使用環境によっては、この情報を再クエリすることをお勧めします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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceResponseののxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/gml "> <マッピングの有効期限が切れる=" 2007-01-01T01：44：33Z "lastUpdated = "2006-11-01T01：00：00Z" ソース= "authoritative.example" ソースID = "7e3f40b098c711dbb6060800200c9a66"> <のdisplayNameのxml：langの=" EN ">ニューヨーク市警察</のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロファイル=" 測地-2D "> <P2：ポリゴンsrsName =" 壷：OGC：DEF :: CRS：EPSG :: 4326" > <P2：外装> <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：外観> </ P2：ポリゴン> </ serviceBoundary> <URI> SIP：nypd@example.com </ URI> <URI> XMPP：nypd@example.com </ URI> <serviceNumber> 911 </ serviceNumber> </マッピング> <パス> <ソース= "resolver.example" を介し/> <ソースを介し= "authoritative.example" /> </ path>の<locationUsed ID = "6020688f1ce1896d" /> </フィンdServiceResponse>
Figure 2: A <findServiceResponse> geodetic answer
図2：<findServiceResponse>測地答え
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、ドイツ）と一緒に、この例では、クライアントは、警察（sos.police：サービスURN）に関連したサービスを要求します。
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceのxmlns = "URN：IETF：paramsは：XML：NS：lost1" 再帰= "true" をserviceBoundary = "値"> <位置ID =」 627b8bf819d0bad4d」プロファイル= "市民"> <civicAddressのxmlns = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr"> <国> DE </国> <A1>バイエルン</ A1> <A3>ミュンヘン</ A3> <A6>オットーハーンリング</ A6> <HNO> 6 </ HNO> <PC> 81675 </ PC> </ civicAddress> </場所> <サービス> URN：サービス：sos.police </サービス> </ findService>
Figure 3: A <findService> civic address query
図3：<findService>市民のアドレス問い合わせ
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.
上記のクエリを考えると、サーバは、そのサービスに関連するサービス、および情報で応答します。以下の例では、サーバはURIの一口を経由して、それらを連絡することをクライアントに指示する、ミュンヘンPolizei-Abteilungに警察サービスのクライアントによって指定された場所をマッピングしていますmunich-police@example.comとXMPP：ミュンヘン-police@example.com。また、サーバはクライアントにこのサービスのための市民のアドレス境界（ミュンヘン市）を与えています。マッピングは、最後には、信頼できるソース「polizei.muenchen.de.example」で2006年11月1日に更新され、これは情報のために再クエリにクライアントに指示し、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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceResponseのxmlns = "URN：IETF：paramsは：XML：NS：lost1"> <マッピングの有効期限が切れる= "2007-01-01T01：44：33Z" lastUpdated = "2006-11-01T01：00：00Z" ソース= "esgw.ueber-110.de.example" ソースID = "e8b05a41d8d1415b80f2cdbb96ccf109"> <のdisplayNameのxml：langの= "デ">ミュンヘンPolizei-Abteilung </のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロファイル= "市民"> <civicAddressのxmlns = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr"> <国> DE </国> <A1>バイエルン</ A1> <A3>ミュンヘン</ A3> <PC> 81675 </ PC> </ civicAddress> </ serviceBoundary> <URI> SIP：munich-police@example.com </ URI> <URI> XMPP：munich-police@example.com </ URI> <serviceNumber> 110 </ serviceNumber> </マッピング> <パス> <ソースを介し= "esgw.ueber-110.de.example" /> <介しソース= "polizei.muenchen.de.example" /> </ path>の<locationUsed ID = "627b8bf819d0bad4d" /> </ findServiceResponse>
Figure 4: A <findServiceResponse> civic address answer
図4：<findServiceResponse>市民のアドレスの回答
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
<findService>クエリは、ロケーション・プロファイル（セクション12を参照）に適合しなければならない1つ以上の<場所>要素を使用して位置情報を通信します。複数の場所の要素があってはなりません
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.
各々の別個の位置プロファイルの。位置要素の順序は重要です。サーバは、ロケーション・プロファイルを理解する最初の位置要素を使用します。
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.
失われたことは要求ごとに、再帰的または反復のいずれかのモードで動作させることができます。再帰モードでは、失われたサーバーは、要求者に代わってクエリを開始し、要求元に結果を返します。
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".
この文書で定義されたクエリの場合、唯一の失われた<findService>と<listServicesByLocation>クエリは、「再帰的な」属性によって示されるように、再帰的にすることができます。 「真」の値は、属性が省略されている場合、デフォルトは「偽」であることと、再帰クエリを示します。関係なく、属性の、サーバは常に失われたアプリケーション固有の文字列（セクション4を参照）、すなわち、間接を提供することで、クエリに答えるかもしれません。属性が「偽」である場合しかし、それは再帰てはなりません。
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.
失われた<マッピング>要素は、値または参照のいずれかによって、サービス境界を記述することができます。サービス境界の参照を返すことは、一般的に多くの地理空間のための空間効率（ポリゴン）の境界と境界がほとんど変更されないが、追加の<getServiceBoundary>要求を招くない場合です。クエリアは、一つまたは<findService>要求の「serviceBoundary」属性を有する他のモダリティのための好みを表現することができるが、サーバは、参照または値を返すかどうかの最終決定を行います。
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.
シビックアドレスの検証はtrueに任意の属性「validateLocation」を設定することによって要求されます。属性が省略された場合、偽であると想定されます。応答は、セクション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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceののxmlns = "壷：IETF：のparams：XML：NS：lost1" 再帰= "true" をvalidateLocation = "true" をserviceBoundary = "値"> <位置ID = "627b8bf819d0bad4d" プロフィール= "市民"> <civicAddressのxmlns = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr"> <国> DE </国> <A1>バイエルン</ A1 > <A3>ミュンヘン</ A3> <A6>オットーハーンリング</ A6> <HNO> 6 </ HNO> <PC> 81675 </ PC> </ civicAddress> </場所> <サービス> URN：サービス：sos.police </サービス> </ findService>
Figure 5: A <findService> query with address validation request
図5：アドレスの検証要求に<findService>クエリ
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceResponseのxmlns = "URN：IETF：paramsは：XML：NS：lost1"> <マッピングの有効期限が切れる= "2007-01-01T01：44：33Z" lastUpdated = "2006-11-01T01：00：00Z" ソース= "authoritative.example" ソースID = "4db898df52b84edfa9b6445ea8a0328e"> <のdisplayNameのxml：langの= "デ">ミュンヘンPolizei-Abteilung </のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロファイル= "市民"> <civicAddressのxmlns = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr"> <国> DE </国> <A1>バイエルン州</ A1> <A3>ミュンヘン</ A3> <PC> 81675 </ PC> </ civicAddress> </ serviceBoundary> <URI> SIP：munich-police@example.com </ URI> <URI> XMPP：ミュンヘン-police@example.com </ URI> <serviceNumber> 110 </ serviceNumber> </マッピング> <locationValidation> <有効>国A1 A3 A6 </有効> <無効> PC </無効> <未確認> HNO </未確認> </ locationValidation> <path>は<介してソース= "resolver.example" /> <介してソース= "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.
マッピング応答は、<mapping>要素（セクション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>要素の子要素で使用される市民の位置ラベルを列挙し、空白で区切られたトークンのリストを含みます。 <有効>要素は、失われたサーバーで有効なものとして認識されているとのマッピングを決定するために使用されているもの市民のアドレス要素を列挙します。 <チェックしない>要素は、サーバーがチェックし、その応答を決定する際に使用されなかったしなかったことを市民のアドレス要素を列挙します。 <無効>要素は、サーバーをチェックしようとした市民のアドレス要素を列挙し、それは、<有効>リストで見つかった他の市民のアドレスの要素と一致しませんでした。どちらかの<有効>、<無効>、または<未チェック>要素に記載されていないシビック場所トークンは、未チェックのトークンのクラスに属します。
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>という値で境界を返すよりも、サービスの境界を取得するために使用することができます「serviceBoundary」属性でのグローバル一意識別子を返すことができます。これは、クライアントが、<getServiceBoundary>要求を使用して境界を取り出すことができ、図7及び図8の例に示されており、<getServiceBoundaryResponse>図9及び図10の例に示すクライアントの問題に境界を求めています<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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/gml "再帰=" true "をserviceBoundary = "参照"> <位置ID = "6020688f1ce1896d" プロフィール= "測地-2D"> <P2：ポイントID = "POINT1" srsName =" URN：OGC：DEF：CRS：EPSG :: 4326" > <P2：POS> 37.775 -122.422 </ P2：POS> </ P2：ポイント> </ location>の<サービス> URN：サービス：sos.police </サービス> </ 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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceResponseののxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/gml "> <マッピングの有効期限が切れる=" 2007-01-01T01：44：33Z "lastUpdated = "2006-11-01T01：00：00Z" ソース= "authoritative.example" ソースID = "7e3f40b098c711dbb6060800200c9a66"> <のdisplayNameのxml：langの=" EN ">ニューヨーク市警察</のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryReferenceソース=" authoritative.example」キー= "7214148E0433AFE2FA2D48003D31172E" /> <URI>一口例：@ NYPD .COM </ URI> <URI> XMPP：ソースを介しnypd@example.com </ URI> <serviceNumber> 911 </ serviceNumber> </マッピング> <path>は<介してソース= "resolver.example" /> <= "authoritative.example" /> </ path>の<locationUsed ID = "6020688f1ce1896d" /> </ findServiceResponse>
Figure 8: <findServiceResponse> message with service boundary
reference
<?xml version="1.0" encoding="UTF-8"?> <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" key="7214148E0433AFE2FA2D48003D31172E"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <getServiceBoundaryのxmlns = "壷：IETF：のparams：XML：NS：lost1" キー= "7214148E0433AFE2FA2D48003D31172E" />
Figure 9: Requesting a service boundary with <getServiceBoundary>
図9：<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>
<？xml version = "1.0" エンコード= "UTF-8"？> <getServiceBoundaryResponseのxmlns = "URN：IETF：paramsは：XML：NS：lost1"> <serviceBoundaryプロファイル= "測地-2D"> <P2：ポリゴンsrsName = "壷：OGC：DEF :: CRS：EPSG :: 4326"> <P2：外装> <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：外装> </ P2：ポリゴン> </ serviceBoundary> <パス> <ソース= "resolver.example" /> <介してソース= "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>
<？xml version = "1.0" エンコード= "UTF-8"？> <listServicesののxmlns = "壷：IETF：のparams：XML：NS：lost1"> <サービス> URN：サービス：SOS </サービス> </ listServices >
Figure 11: Example of <ListServices> query
図11：<ListServices>クエリの例
<?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>
<？xmlのバージョンは、= "1.0" エンコード= "UTF-8"？> <listServicesResponseのxmlns = "壷：IETF：のparams：XML：NS：lost1"> <serviceList> URN：サービス：sos.ambulance骨壷：サービス：SOS .animal制御URN：サービス：sos.fire URN：サービス：sos.gas URN：サービス：sos.mountain URN：サービス：sos.marine URN：サービス：sos.physician URN：サービス：sos.poison URN：サービス： sos.police </ serviceList> <path>は<介してソース= "authoritative.example" /> </ path>の</ listServicesResponse>
Figure 12: Example of <ListServicesResponse>
図12の例<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>クエリは、1つ以上の<場所>要素、異なるロケーション・プロファイル（セクション12）からそれぞれを含み、<service>要素を含んでいてもよいです。 <findService>として、サーバは、サーバが理解し、それがいずれかの再帰的又は反復動作することができる輪郭を有する第一の位置要素を選択します。 <経由>要素は、リクエストの進行状況を追跡します。クエリは、サーバがその一部である森林の構造の中から列挙することができるサービスを示します。失われたが、すべての潜在的なサービスタイプのシングル、包括的な組織を想定していないので、他の森林の構造に接続された他の失われたサーバによって説明することができ地理的エリア内で利用可能なサービスがあるかもしれません。一例として、地域の緊急サービスフォレストは、同じ領域内に商用サービスを探し森林から別個であってもよいです。
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>要素が含まれている場合は、失われたサーバーは、提供された位置のために利用可能な照会サービスの唯一の直接の子サービスを返します。 <サービス>要素が存在しない場合は、失われたサービスは、それが知っている提供された位置で使用可能なすべてのトップレベルのサービスを返します。
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>応答して、このクエリに応答します。この応答要素（セクション6を参照）<介し>含むことができ、サービスのURNの空白で区切られたリストからなる、<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>
<？xml version = "1.0" エンコード= "UTF-8"？> <listServicesByLocationののxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/gml "再帰=" 真 "> <位置ID =" 3e19dfb3b9828c3" プロフィール= "測地-2D"> <P2：ポイントsrsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <P2：POS> -34.407 150.883 </ P2：POS> </ P2：ポイント> </場所> <サービス> URN：サービス：SOS </サービス> </ listServicesByLocation>
Figure 13: Example of <ListServicesbyLocation> query
図13：<ListServicesbyLocation>クエリの例
<?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>
<？xmlのバージョンは、= "1.0" エンコード= "UTF-8"？> <listServicesByLocationResponseのxmlns = "壷：IETF：のparams：XML：NS：lost1"> <serviceList> URN：サービス：sos.ambulance骨壷：サービス：SOS .animal制御URN：サービス：sos.fire URN：サービス：sos.gas URN：サービス：sos.mountain URN：サービス：sos.marine URN：サービス：sos.physician URN：サービス：sos.poison URN：サービス： sos.police </ serviceList> <path>は<介してソース= "resolver.example" /> <介してソース= "authoritative.example" /> </ path>の<locationUsed ID = "3e19dfb3b9828c3" /> </ listServicesByLocationResponse>
Figure 14: Example of <ListServicesByLocationResponse> response
図14：<ListServicesByLocationResponse>応答の例
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は、要求と応答で<serviceBoundary>要素内の<場所>要素内の位置情報を使用します。そのような位置情報は、様々な方法で表すことができます。この品種は、要求または応答は、それぞれ、サーバまたはクライアントによって理解されていない形式で位置情報が含まれている相互運用性の問題を引き起こす可能性があります。相互運用性を達成するために、この文書は、位置情報が送信される方法を定義するために2つの必須ツー実装基準位置プロファイルを定義します。将来的には他のプロファイルを標準化することが可能です。ベースラインプロファイルは、次のとおりです。
geodetic-2d: a profile for two-dimensional geodetic location information, as described in Section 12.2;.
測地-2D：12.2項に記載されているように、二次元の測地位置情報のプロファイル、;.
civic: a profile consisting of civic address location information, as described in Section 12.3.
市民：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.
<場所>または<serviceBoundary>要素を含む要求と応答は、ゼロまたはそれ以上の追加のプロファイルに加えて、2つのベースラインプロファイルの正確に一つに位置情報を含まなければなりません。位置情報の順序は、送信者の一部に嗜好を示しています。
Standards action is required for defining new profiles. A location profile MUST define:
標準アクションは、新しいプロファイルを定義するために必要とされます。位置プロファイルは定義する必要があります。
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の正式な定義、すなわち、列挙および<場所>要素の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.測地2D又は市民であるか否かの宣言は、ベースラインプロファイルとして使用されます。将来のプロファイルは測地と市民の位置情報との組み合わせとすることができるように明示的にベースラインプロファイルを宣言する必要があります。
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つ以上の<場所>要素を含みます。 <場所>要素は、子要素の位置のフォーマットを示すオプション「プロファイル」属性を運びます。クライアントは、それが認識したプロファイルに準拠していない、またはそれはプロファイルにXMLをマッピングする機能を持っていない可能性があり、位置情報を得ることができます。その場合、クライアントは、プロファイル属性を省略するかもしれなくて、サーバは、そうすることができない場合は、「locationProfileUnrecognized」エラーを返す、その能力を最大限にXML位置データを解釈する必要があります。
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.
失われたサーバは、位置情報を含む応答を送信すると、クライアントは<場所>要素を使用して多くのように、それは<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.クライアントは、この文書で説明するもの以外の任意の場所のプロファイルに準拠した位置情報を送信する場合、それはまた、同じ要求、ベースラインプロファイルのいずれかに準拠した位置情報に、送らなければなりません。そうしないと、サーバーは要求を理解することができない場合があります。
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.クライアントは、異なるベースラインプロファイルから導出されている複数の<場所>オブジェクトを送ってはいけません。言い換えれば、クライアントは、クエリで同じベースラインプロファイルによる位置オブジェクトを送らなければなりませんが、それは他のいくつかのプロファイルに加えて、ベースラインプロファイル次の場所元素を含んでいてもよいです。
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つのインスタンスが存在する場合があります。
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に位置情報を送信します。クライアントXはまた、測地-2Dベースラインプロファイルを用いて位置情報を送信する場合、サーバYは、依然として、所望ほど正確又は表現ではないかもしれない位置情報にかかわらず、要求を理解し、理解応答を提供することができるであろう。クライアントXとY Serverの両方がベースラインプロファイルを理解するため、これが可能です。
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：GML = "http://www.opengis.net/gml "のxmlns：GS =" http://www.opengis.net/pidflo/1.0" 再帰= "true" をserviceBoundary = "値"> <位置ID = "ABC 123" プロファイルは= "未標準-prism-プロファイル "> <GS：プリズムsrsName =" 壷：OGC：DEF：CRS：EPSG :: 4979" > <GS：ベース> <GML：ポリゴン> <GML：外装> <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：外装> </ GML：ポリゴン> </ GS：ベース> < GS：高さUOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 2.4 </ gsは：高さ> </ GS：プリズム> </位置> <位置ID = "DEF 345" プロファイル= "geodetic- 2D "> <GML：ポイントID =" POINT1" srsName = "URN：OGC：DEF：CRS：EPSG：4326"> <GML：> 42.656844 -73.348157 POS </ GML：POS> </ GML：ポイント> </場所> <サービス> URN：サービス：sos.police </サービス> </ 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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceResponseののxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/" > <マッピングが満了= "2007-01-01T01：44：33Z" lastUpdated = "2006-11-01T01：00：00Z" ソース= "authoritative.example" ソースID = "cf19bbb038fb4ade95852795f045387d"> <のdisplayNameのxml：langの= "EN ">ニューヨーク市警察</のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロファイル=" 測地-2D "> <P2：ポリゴンsrsName =" 壷：OGC：DEF :: CRS ：EPSG :: 4326" > <P2：外装> <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：外観> < / P2：ポリゴン> </ serviceBoundary> <URI> SIP：nypd@example.com </ URI> <serviceNumber> 911 </ serviceNumber> </マッピング> <パス> <ソースを介し= "resolver.example" /> <介してソース= "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」ロケーション・プロファイルは、トークン「測地-2D」によって識別されます。クライアントとサーバーは<serviceBoundary>に次の場所の形状を配置することによって、または、<場所>要素（特に明記しない限り）にこのプロファイルを使用します。
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.
点：<ポイント>要素は、[13]のセクション5.2.1に記載されています。 [13]のセクション5.2.1はまた、いずれかの二次元位置（緯度及び経度）または三次元位置（緯度、経度、および高度）と<ポイント>の仕様を示します。クライアントは、3次元位置を使用することができ、サーバは、高度値を無視することによって、二次元位置と3次元位置を解釈することができます。 <ポイント>要素は、<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].
円：<円>要素は、[13]のセクション5.2.3に記載されています。
Ellipse: The <Ellipse> element is described in Section 5.2.4 of [13].
楕円<楕円>要素は、[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).
クライアントは<場所>要素内の<多角形>、<サークル>、<楕円>、または<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.
サーバは、複数の<マッピング>要素を返さないが、形状は、サービス境界を越えて延びている場合には、失われたサーバによって選択されたマッチングアルゴリズムは、形状の一部に一致するが、一致しない結果を返すことが可能です特定のポイントに固有のものを。クライアントは、常にこの状態を避けるために、形状の中からポイントを選択することができます。それは一般的に、それが唯一の所定の形状の中に、自身の位置を知っているあるものであるしない場合。緊急サービスのユースケースでは、それは失われたが、その近傍のいずれかにコールを転送するために必要されて提供URIで接触PSAPをもたらすことができます。これは、全体的な緊急対応システムの予想される部分です。非緊急サービスのユースケースでは、サービスの展開モデルは、プロビジョニング・モデルの一部として考慮にこの問題を取る必要がありマッピングに使用される失われたサーバ内のデータの組み合わせとアルゴリズムとして形状があるときに返された連絡先のURIを決定します複数のサービスエリアを重複している使用。
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.
サーバーは<serviceBoundary>要素内に、[10]で定義された<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.
応答は、プロファイル「市民」で複数の<serviceBoundary>要素を含むかもしれません。各<serviceBoundary>要素、すなわち、テキストで市民のアドレスエレメントに一致するすべてのアドレスにかかわらず、他のアドレス要素の値に、提供されるサービスの境界内に入る市民アドレスのセットを記述する。それは<serviceBoundary>要素のいずれかに一致する場合の場所は、マッピングのサービス境界内にあります。したがって、応答は、市民及び/又は測地位置プロファイルを有する複数の<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.
リラックス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.
サーバーinternalErrorによる設定ミスや他の業務と非プロトコル関連の理由に要求を満たすことができませんでした。
locationProfileUnrecognized None of the profiles in the request were recognized by the server (see Section 12).
リクエスト内のプロファイルのlocationProfileUnrecognizedどれもがサーバーによって認識されなかった（セクション12を参照）。
locationInvalid The geodetic or civic location in the request was invalid. For example, the longitude or latitude values fall outside the acceptable ranges.
無効たリクエストに測地や市民の場所をlocationInvalid。例えば、経度または緯度の値が許容範囲から外れます。
SRSInvalid The spatial reference system (SRS) contained in the location element was not recognized or does not match the location profile.
位置要素に含まれる空間参照システム（SRS）SRSInvalid認識されなかったか、ロケーション・プロファイルと一致しません。
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.
再帰クエリの間にループが、サーバーは、要求ループを示し、<パス>要素内のサーバリストに既にいたサーバーを訪問しようとしていました。
notFound The server could not find an answer to the query.
サーバーNOTFOUNDクエリに対する答えを見つけることができませんでした。
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.
serviceNotImplemented要求されたサービス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>
<XMLバージョン= "1.0" エンコード= "UTF-8"？> <エラーのxmlns = "壷：IETF：のparams：XML：NS：lost1" ソースは= "resolver.example">に<internalErrorメッセージ= "ソフトウェアのバグ。 " XML：LANG = "EN" /> </エラー>
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.
サーバーが指定されたサービスURNのための<findService>要求を満たすことができなかったときserviceSubstitution <serviceSubstitution>要素が返されることがあります。たとえば、「URN：サービス：sos.police」は<findService>要求ウルグアイの場所のためのサービスURNは、のマッピングを返すために失われたサービスを引き起こす可能性があり「URN：サービス：SOS」サービス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.
サーバーは、指定された場所のために<findService>要求を満たすことができませんでしたが、デフォルトURIで応答できる場合defaultMappingReturned <defaultMappingReturned>要素が返されることがあります。例えば、近くの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>
<？xml version = "1.0" エンコード= "UTF-8"？> <findServiceResponseののxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：P2 = "http://www.opengis.net/" > <マッピングが満了= "2007-01-01T01：44：33Z" lastUpdated = "2006-11-01T01：00：00Z" ソース= "authoritative.example" ソースID = "fb8ed888433343b7b27865aeb38f3a99"> <のdisplayNameのxml：langの= "EN ">ニューヨーク市警察</のdisplayName> <サービス> URN：サービス：sos.police </サービス> <serviceBoundaryプロファイル=" 測地-2D "> <P2：ポリゴンsrsName =" 壷：OGC：DEF :: CRS ：EPSG :: 4326" > <P2：外装> <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：外観> < / P2：ポリゴン> </ serviceBoundary> <URI> SIP：nypd@example.com </ URI> <serviceNumber> 911 </ serviceNumber> </マッピング> <警告ソース= "authoritative.example"> <defaultMappingReturnedメッセージ=」指定された場所のためのPSAPを決定することができません;デフォルトのPSAPを使用して」XML：LANG = "EN" /> </戦争nings> <path>は<介してソース= "resolver.example" /> <介してソース= "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.
失われたサーバーは、<リダイレクト>要素を使用して、クエリアは別のサーバにクエリをリダイレクトする必要があることを示す応答することができます。要素が失われたアプリケーション固有の文字列を示す「ターゲット」属性を含むクライアントは、リダイレクトレスポンスを生成し、サーバと説明「メッセージ」属性を示す「ソース」属性と同様に、次の接触すべきであること（セクション4を参照）リダイレクト応答の理由。再帰クエリ時には、<リダイレクト>応答を受信したサーバーは、それがリダイレクトに従うか、単にその上流のクエリアへの応答を返すように望んでいるかどうかを決定することができます。リダイレクトされたクエリを処理するサーバによって返された応答の値は、新しいクエリが必要になる可能性がある最も早い時間（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"/>
<リダイレクトのxmlns = "URN：IETF：paramsは：XML：NS：lost1" <XMLバージョン= "1.0" エンコード= "UTF-8"？>ターゲット= "eastpsap.example" ソース= "westpsap.example" メッセージ= 「我々は一時的にオーバー失敗しました。」 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上で失われたの使用を定義し、HTTPオーバーTLSを超える失いました。クライアントとサーバーの開発者は、RFC 2616 HTTP施設のフルサポートが期待されていることを思い出しています。クライアントまたはサーバが再実装HTTP失われた場合は、むしろベースとして使用可能なサーバーまたはクライアントコードを使用するよりも、細心の注意は、完全な相互運用性に支払わなければなりません。他のトランスポートメカニズムは将来の文書に残されています。利用可能なトランスポートメカニズムは、失われたU-NAPTRアプリケーションの使用を介して決定されます。コンテンツタイプの表示をサポートするプロトコルでは、失われたメディアタイプapplication /失われた+ 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オーバーTLSを使用する場合、[4]、要求はHTTP POSTメソッドを使用して失われました。 HTTPリクエストにもクライアントの要求に古くなったレスポンスを返すように設定されているキャッシュによるHTTPレベルのキャッシュを無効にするのCache-Control応答指令「キャッシュなし」を使用しなければなりません。
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層のリダイレクトは、一般的であろう場所セクション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"
名前空間A = "http://relaxng.org/ns/compatibility/annotations/1.0" デフォルトの名前空間のNS1 = "壷：IETF：のparams：XML：NS：lost1"
## ## Location-to-Service Translation (LoST) Protocol
## ##場所・ツー・サービス翻訳（LOST）プロトコル
## ## 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
サービス、リストのサービスを、##見つけて、サービスの境界を取得します：## ## Aは、XMLインスタンスが##対応する応答型の3つの要求タイプ、それぞれを持って失いました。 ## = findServiceを開始| listServices | listServicesByLocation | getServiceBoundary | findServiceResponse | listServicesResponse | listServicesByLocationResponse | getServiceBoundaryResponse |エラー|リダイレクト
## ## The queries. ## div {
##クエリ##。 ## 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 } }
findService =エレメントfindService {requestLocation、commonRequestPattern、属性validateLocation {XSD：ブール>> A：はdefaultValue [ "偽"]} ?,属性serviceBoundary {（ "基準" | "値"）>> A：はdefaultValue [ "参照"]ブール>>：} ?,再帰{XSD属性}はdefaultValue [ "偽"]？ } listServices =素子listServices {：ブール>>：commonRequestPattern} listServicesByLocation =素子listServicesByLocation {requestLocation、commonRequestPattern、再帰{XSD属性はdefaultValue [ "真"]}？ } getServiceBoundary =エレメントgetServiceBoundary {serviceBoundaryKey、拡張ポイント}}
## ## 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 } }
【回答】。 ## DIV {findServiceResponse =エレメントfindServiceResponse {マッピング+、locationValidation？commonResponsePattern、locationUsed} listServicesResponse =エレメントlistServicesResponse {serviceList、commonResponsePattern} listServicesByLocationResponse =エレメントlistServicesByLocationResponse {serviceList、commonResponsePattern、locationUsed} getServiceBoundaryResponse =エレメントgetServiceBoundaryResponse {serviceBoundary、commonResponsePattern}}
## ## A pattern common to some of the queries. ## div { commonRequestPattern = service, path?, extensionPoint
## ##クエリの一部に共通するパターン。 ## DIV {commonRequestPattern =サービス、パス拡張ポイント？
}
｝
## ## A pattern common to responses. ## div { commonResponsePattern = warnings*, path, extensionPoint }
回答に共通する## ##パターン。 ## DIV {commonResponsePattern =警告*、パス、拡張ポイント}
## ## Location in Requests ## div { requestLocation = element location { attribute id { xsd:token }, locationInformation }+ }
## ## ## DIV要求にロケーション{requestLocation =要素の位置{属性ID {XSD：トークン}、locationInformation} +}
## ## Location Information ## div { locationInformation = extensionPoint+, attribute profile { xsd:NMTOKEN }? }
## ##場所情報##のdiv {locationInformation =拡張ポイント+、属性プロファイル{のxsd：NMTOKEN}？ }
## ## Service Boundary ## div { serviceBoundary = element serviceBoundary { locationInformation }+ }
## ##サービス境界## DIV {serviceBoundary =エレメントserviceBoundary {locationInformation} +}
## ## Service Boundary Reference ## div { serviceBoundaryReference = element serviceBoundaryReference { source, serviceBoundaryKey, extensionPoint } serviceBoundaryKey = attribute key { xsd:token } }
## ##サービス境界リファレンス## DIV {serviceBoundaryReference =元素serviceBoundaryReference {ソース、serviceBoundaryKey、拡張ポイント} serviceBoundaryKey =属性キー{XSD：トークン}}
##
＃＃
## Path - ## Contains a list of via elements - ## places through which information flowed ## div { path = element path { element via { source, extensionPoint }+ } }
##パス - ##素子を介してのリストが含まれてい - ##情報が## DIV {{ソース、拡張ポイント} +}経由パス=エレメントパス{素子を}流しそこを通って場所を
## ## Location Used ## div { locationUsed = element locationUsed { attribute id { xsd:token } }? }
## ##の場所に使用さ## DIV {locationUsed =要素locationUsed {属性ID {XSD：トークン}}？ }
## ## Expires pattern ## div { expires = attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } }
|のdateTime：## ##パターン##のdivは{期限が切れる=属性は、{XSDを満了した有効期限"NO-CACHE" | "NO呼気"}}
## ## A QName list ## div { qnameList = list { xsd:QName* } }
## ##のQNameリスト## DIV {qnameList = {リストの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 } }
## ##位置・ツー・サービスのマッピング。 ## DIV {マッピング=元素マッピング{要素のdisplayName {のxsd：文字列、XMLの属性：LANG {のxsd：言語}} *、サービス、（serviceBoundary | serviceBoundaryReference）?,要素のURI {のxsd：anyURIタイプ} *、要素serviceNumber {XSDトークン{パターン= "[0-9 *＃] +"}}？拡張ポイント、有効期限が切れ、属性lastUpdated {のxsd：dateTimeを}、ソース、属性ソースID {XSD：トークン}、メッセージ}}
## ## Location validation ## div { locationValidation = element locationValidation { element valid { qnameList }?, element invalid { qnameList }?, element unchecked { qnameList }?, extensionPoint } }
## ##ロケーション検証##のDIV {locationValidation =要素locationValidation {素子有効{qnameList} ?,素子無効{qnameList} ?,素子} qnameList {未確認?,拡張ポイント}}
## ## 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 } }
## ##のエラーと警告のコンテナ。 ## DIV {exceptionContainer =（badRequest？＆internalError？＆serviceSubstitution？＆defaultMappingReturned？＆禁止？＆NOTFOUND？＆ループ？＆serviceNotImplemented？＆serverTimeoutの？＆SERVERERROR？＆locationInvalid？＆locationProfileUnrecognized？）、拡張ポイント、ソースエラー=エレメントエラー{exceptionContainer}警告=エレメント警告{exceptionContainer}}
## ## Basic Exceptions ## div {
## ##基本的な例外##の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 } }
## ##例外パターン。 ## basicException =メッセージ、拡張ポイントbadRequest =エレメントbadRequest {basicException} internalError =エレメントinternalError {basicException} serviceSubstitution =素子serviceSubstitution {basicException} defaultMappingReturned =エレメントdefaultMappingReturned {basicException}禁止=エレメント禁止{basicException} NOTFOUND =エレメントNOTFOUND {basicException}ループ=エレメントループ{basicException} serviceNotImplemented =エレメントserviceNotImplemented {basicException} serverTimeoutの=要素serverTimeoutの{basicException} SERVERERROR =エレメントSERVERERROR {basicException} locationInvalid =エレメントlocationInvalid {basicException} locationValidationUnavailable =エレメントlocationValidationUnavailable {basicException} locationProfileUnrecognized =要素locationProfileUnrecognized {属性unsupportedProfiles {XSD ：NMTOKENS}、basicException}}
## ## Redirect. ## div {
## ##リダイレクト。 ## DIV {
## ## Redirect pattern ## redirect = element redirect { attribute target { appUniqueString }, source, message, extensionPoint } }
## ##パターン##リダイレクト=エレメントリダイレクトリダイレクト{属性ターゲット{appUniqueStringを}、ソース、メッセージ、拡張ポイント}}
## ## 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* } } }
## ##いくつかの一般的なパターン。 ## DIV {メッセージ=（属性メッセージ{XSD：トークン}、属性xml：langの{XSD：言語}）？サービス=エレメントサービス{XSD：anyURIの}？ appUniqueString = XSD：トークン{パターン= "（[-ZA-Z0-9 \ - ] + \。）+ [-ZA-Z0-9] +"}ソース=属性源{appUniqueString} serviceList =素子serviceList {リスト{XSD：anyURIの*}}}
## ## Patterns for inclusion of elements from schemas in ## other namespaces. ## div {
## ## ##他の名前空間内のスキーマの要素を含めるためのパターン。 ## DIV {
## ## Any element not in the LoST namespace. ## notLost = element * - (ns1:* | ns1:*) { anyElement }
## ##失われた名前空間内の任意の要素ではありません。 ## notLost =エレメント* - （NS1：* | NS1：*）{}を除き、anyelement
## ## A wildcard pattern for including any element ## from any other namespace. ## anyElement = (element * { anyElement } | attribute * { text } | text)*
##は、他の名前空間から任意の要素を##などのワイルドカードパターンを##します。 ##を除き、anyelement =（要素* {除き、anyelement} |属性* {テキスト} |テキスト）*
## ## A point where future extensions ## (elements from other namespaces) ## can be added. ## extensionPoint = notLost* }
ここで、将来の拡張## ##点##（他の名前空間からの要素）##を添加することができます。 ##拡張ポイント= 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
アプリケーション・サービス・タグ：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].
この仕様は、[7] RFC 4288の手順に従って新しいMIMEタイプの登録を要求し、RFC 3023のガイドライン[5]。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: lost+xml
MIMEサブタイプ名：失われた+ 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のファイルタイプコード：「TEXT」
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@nsn.com
詳しくは、個人やメールアドレス：ハンネスTschofenig、Hannes.Tschofenig@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>.
著者：この仕様は、メーリングリストのアドレスで、IETF ECRITワーキンググループの作業項目である<ecrit@ietf.org>。
Change controller: The IESG <iesg@ietf.org>
変更コントローラ：IESG <iesg@ietf.org>
URI: urn:ietf:params:xml:schema:lost1
URI：URN：IETF：のparams：XML：スキーマ：lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com).
登録者連絡先：IETF ECRITワーキンググループ、ハンネス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"
デフォルトの名前空間= "壷：IETF：のparams：XML：NS：lost1"
and its last line is
そしてその最後の行があります
}
｝
URI: urn:ietf:params:xml:ns:lost1
URI：URN：IETF：のparams：XML：NS：lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com).
登録者連絡先：IETF ECRITワーキンググループ、ハンネス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
BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml- basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <META HTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル>名前空間を失った。</ TITLE> </ HEAD> <BODY> <H1>失われたために名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：lost1 </ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc5222.txt"> RFC5222 </a>を参照してください。</ P> </ body> </ html>このEND
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.
この文書では、失われたプロトコルのための場所のプロファイル名のレジストリを作成します。プロファイル名は、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を取得することができ、攻撃者はこれらのサービスを妨害しようとするためにそれらのURIを使用することができます。連絡先URIの検索を防ぐことができ、攻撃者はそのようなサービスの到達可能性を損なうことができます。この検索を要求する通信を盗聴することができ、攻撃者は、緊急時や、おそらくその性質の存在を推測することができ、かつ、発信者の物理的な攻撃を開始するためにこれを使用することができるかもしれません。
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.
TLSを使用してサーバーの身元確認の使用は、[4]のセクション3.1に記載されているように、もお勧めです。サーバー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]の証明書ではなく、（URIのホスト名）を出力するNAPTR解像度の入力を比較することをお勧めします。このアプローチが原因で緊急サービスのユースケースに選ばれていなかった、展開が一般的に地元の緊急サービス機関が運営する単一のサーバーに解決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レコードは、攻撃者によって変更することができるように、サーバーのIDの使用は、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があるとして失わサーバのNATPRベースの検出を使用することはできませんせずにDNS解決を信頼するようにDNSSECを使用することができないと不本意ですLOST展開。適切な構成の機構が利用可能である場合、一つの可能性は、直接（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基本とダイジェスト認証などの基礎となるトランスポート・メカニズムの認証を使用することができます。基本認証のみが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)
レスリーDaigle氏（レビュー2006年9月）〇〇ジョナサン・ローゼンバーグ（レビュー2006年7月）
o Shida Schubert (Review November 2006)
志田シューベルト（レビュー2006年11月）O
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パトリックFaltstrom（レビュー2007年1月）
o Shida Schubert (Review January 2007 as a designated expert reviewer)
O志田シューベルト（指定された専門家の審査などレビュー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)
志田シューベルト（レビュー2007年2月）O
o James Winterbottom (Review July 2007)
Oジェームズ・ウィンターボトム（レビュー2007年7月）
o Karl Heinz Wolf (Review May and June 2007)
Oカール・ハインツ・ウルフ（レビュー月と2007年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レスリーDaigle氏とMartinトムソン（DNSベースの失われた発見手順）
o John Schnizlein (authoritive LoST answers)
OジョンSchnizlein（失われた答えをauthoritive）
o Rohan Mahy (display names)
Oローハンマーイ（表示名）
o James Polk (error handling)
Oジェームズ・ポーク（エラー処理）
o Ron Watro and Richard Barnes (expiry of cached data)
OロンWatroとリチャード・バーンズ（キャッシュされたデータの有効期限）
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)
マーティン・トムソン（失われた応答メッセージにおけるサービスURN）O
o Clive D.W. Feather, Martin Thomson (validation functionality) o Roger Marshall (PSAP preference in LoST response)
OクライヴD.W.ロジャー・マーシャル（失われた応答におけるPSAP嗜好）O羽、マーティン・トムソン（検証機能）
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ジェームズ・ウィンターボトム、マルク・Linsner、キース糖剤、トム・テイラー、マーティン・トムソン、ジョンSchnizlein、志田シューベルト、クライヴD.W.羽、リチャードStastny、ジョン・ハーティ、ロジャー・マーシャル、ジャンフランソワラバ、ピア・デジャルダン（位置プロファイル）
o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson, Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list services functionality)
Oマイケル・ハマー、パトリックFaltstrom、リチャードStastny、マーティン・トムソン、ロジャー・マーシャル、トム・テイラー、スペンサードーキンスキース糖剤（リストのサービス機能）
o Martin Thomson, Michael Hammer (mapping of services)
Oマーティン・トムソン、マイケル・ハマー（サービスのマッピング）
o Shida Schubert, James Winterbottom, Keith Drage (default service URN)
O志田シューベルト、ジェームズ・ウィンターボトム、キース糖剤（デフォルトのサービスURN）
o Otmar Lendl (LoST aggregation)
Oオトマールレンドル（LOST集合）
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.
クラウスDarilionとマーク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
アンナMakarowska O
o Krzysztof Rzecki
OクシシュトフRzecki
o Blaszczyk Piotr
ピーターについてBlaszczyk
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レビューコメントをジョン・ピーターソン、ダンRomascanu、リサDusseault、およびティムポークに感謝したいと思います。 IESGのコメントをブロックすることもパシEronen（サム・ハルトマンのレビュー後続）とカレン・ジェニングスから受け取りました。調整は、最も顕著なセキュリティ上の考慮事項にし、カバレッジエリアの重複の存在下でのリダイレクトの議論では、変更のためにこれらの要求を満たすために、テキストのいくつかの部分に行われました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[4]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、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]フリード、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]、RFC 4848、2007年4月 "URIとダイナミックな委譲発見サービス（DDDS）を使用してドメインベースのアプリケーションサービスロケーション" Daigle氏、L.を、。
[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]トムソン、M.及びJ.ウィンター、RFC 5139 "プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）のための改訂シビック場所フォーマット" 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]コックス、S.、Daisey、P.、湖、R.、Portele、C.、およびA.ホワイトサイド、 "地理情報 - 地理マークアップ言語（GML）"、OGC標準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]リード、C.とM.トムソン、候補者のOpenGIS実装仕様、2006年12月 "GMLは、IETF（Internet Engineering Task Force）で使用するためにPIDF-LO形状アプリケーションのスキーマを3.1.1"。
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Work in Progress, February 2008.
[13]ウィンター、J.、トムソン、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[15]サンアンドレ、P.、エド、 "拡張メッセージングおよびプレゼンスプロトコル（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]テイラー、T.、Tschofenig、H.、Schulzrinneと、H.、およびM・シャンミューガム、 "セキュリティの脅威と緊急マーキングコールとマッピングのための要件"、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.マーシャル、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、2008年2月に作業。
[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.とA.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[23]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、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/のRelaxNG>。
[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.
、RFC 5223、2008年8月[25] Schulzrinneと、H.、ポーク、J.、およびH. Tschofenig、 "DHCP（Dynamic Host Configuration Protocol）を使用して発見場所・ツー・サービス翻訳（LOST）サーバー"。
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
付録A.非規範的XML構文でNGスキーマをRELAX
<?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">
<？xml version = "1.0" エンコード= "UTF-8"？> <文法NS = "壷：IETF：のparams：XML：NS：lost1" のxmlns = "http://relaxng.org/ns/structure/1.0 "のxmlns：=" http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary = "http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
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>
サービス、リストのサービスを見つけ、サービスの境界を取得します：失われたXMLインスタンスは3リクエストの種類、対応する応答の種類と、それぞれを持っています。 </：ドキュメント> <選択> <refの名前= "findService" /> <refの名前= "listServices" /> <refの名前= "listServicesByLocation" /> <refの名前= "getServiceBoundary" /> <refの名前=」 findServiceResponse "/> <REF名=" listServicesResponse "/> <REF名=" listServicesByLocationResponse "/> <REF名=" getServiceBoundaryResponse "/> <REF名=" エラー "/> <REF名は=" リダイレクト "/> <を/選択> </スタート>
<div> <a:documentation> The queries. </a:documentation>
<div> <A：ドキュメント>クエリ。 </：ドキュメント>
<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">
<定義名= "findService"> <要素名= "findService"> <REF名= "requestLocation" /> <REF名= "commonRequestPattern" /> <オプション> <属性名= "validateLocation"> <データタイプ=」ブール値 "/> <：はdefaultValue>偽</ A：はdefaultValue> </属性> </オプション> <オプション> <名前=属性" 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>
<選択肢> <値>参照</ value>の<値>値</ value>の</選択> <A：はdefaultValue>参照</ A：はdefaultValue> </属性> </オプション> <オプション> <属性名= "再帰"> <データタイプ= "ブール" /> <A：はdefaultValue>偽</：はdefaultValue> </属性> </オプション> </要素> </定義>
<define name="listServices"> <element name="listServices"> <ref name="commonRequestPattern"/> </element> </define>
<定義名= "listServices"> <要素名= "listServices"> <REF名= "commonRequestPattern" /> </要素> </定義>
<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>
<データタイプ=」<要素名= "listServicesByLocation"> <REF名= "requestLocation" /> <REF名= "commonRequestPattern" /> <オプション> <属性名= "再帰"> <名前= "listServicesByLocation" を定義>ブール値 "/> <：はdefaultValue>真</ A：はdefaultValue> </属性> </オプション> </要素> </定義>
<define name="getServiceBoundary"> <element name="getServiceBoundary"> <ref name="serviceBoundaryKey"/> <ref name="extensionPoint"/> </element> </define> </div>
<定義名= "getServiceBoundary"> <要素名= "getServiceBoundary"> <REF名= "serviceBoundaryKey" /> <REF名= "拡張ポイント" /> </要素> </定義> </ div>
<div> <a:documentation> The responses. </a:documentation>
<div> <A：ドキュメント>回答。 </：ドキュメント>
<define name="findServiceResponse"> <element name="findServiceResponse"> <oneOrMore> <ref name="mapping"/> </oneOrMore> <optional> <ref name="locationValidation"/> </optional> <ref name="commonResponsePattern"/> <ref name="locationUsed"/> </element> </define>
<定義名= "findServiceResponse"> <要素名= "findServiceResponse"> <oneOrMore> <REF名= "マッピング" /> </ oneOrMore> <オプション> <REF名= "locationValidation" /> </オプション> <REF名前= "commonResponsePattern" /> <refの名前= "locationUsed" /> </要素> </定義>
<define name="listServicesResponse"> <element name="listServicesResponse"> <ref name="serviceList"/> <ref name="commonResponsePattern"/> </element> </define>
<定義名= "listServicesResponse"> <要素名= "listServicesResponse"> <REF名= "serviceList" /> <REF名= "commonResponsePattern" /> </要素> </定義>
<define name="listServicesByLocationResponse"> <element name="listServicesByLocationResponse"> <ref name="serviceList"/> <ref name="commonResponsePattern"/> <ref name="locationUsed"/> </element> </define>
</定義<要素名= "listServicesByLocationResponse"> <REF名= "serviceList" /> <REF名= "commonResponsePattern" /> <REF名= "locationUsed" /> </要素> <名前= "listServicesByLocationResponse" を定義> >
<define name="getServiceBoundaryResponse"> <element name="getServiceBoundaryResponse"> <ref name="serviceBoundary"/> <ref name="commonResponsePattern"/> </element> </define> </div>
<定義名= "getServiceBoundaryResponse"> <要素名= "getServiceBoundaryResponse"> <REF名= "serviceBoundary" /> <REF名= "commonResponsePattern" /> </要素> </定義> </ div>
<div> <a:documentation> A pattern common to some of the queries. </a:documentation>
<div> <A：ドキュメント>クエリの一部に共通するパターン。 </：ドキュメント>
<define name="commonRequestPattern"> <ref name="service"/> <optional> <ref name="path"/>
</ REF名= "パス"> <REF NAME = "サービス" /> <オプション> <名前= "commonRequestPattern" を定義>
</optional> <ref name="extensionPoint"/> </define> </div>
</オプション> <refの名前= "拡張ポイント" /> </定義> </ div>
<div> <a:documentation> A pattern common to responses. </a:documentation>
<div> <A：ドキュメント>回答に共通するパターン。 </：ドキュメント>
<define name="commonResponsePattern"> <zeroOrMore> <ref name="warnings"/> </zeroOrMore> <ref name="path"/> <ref name="extensionPoint"/> </define> </div>
<zeroOrMore> <REF名= "警告" /> </ zeroOrMore> <REF名= "パス" /> <REF名= "拡張ポイント" /> </定義> </ div> <名前= "commonResponsePattern" を定義>
<div> <a:documentation> Location in Requests </a:documentation>
<div> <A：ドキュメント>リクエストで場所</：ドキュメント>
<define name="requestLocation"> <oneOrMore> <element name="location"> <attribute name="id"> <data type="token"/> </attribute> <ref name="locationInformation"/> </element> </oneOrMore> </define> </div>
<データタイプ= "トークン" /> </属性> <REF名= "locationInformation" /> <<名前= "ID" を属性> <oneOrMore> <要素名= "位置"> <名前= "requestLocation" を定義> /要素> </ oneOrMore> </定義> </ div>
<div> <a:documentation> Location Information </a:documentation>
<div> <A：ドキュメント>位置情報</ A：ドキュメント>
<define name="locationInformation"> <oneOrMore> <ref name="extensionPoint"/> </oneOrMore> <optional> <attribute name="profile"> <data type="NMTOKEN"/>
<oneOrMore> <REF名= "拡張ポイント" /> </ oneOrMore> <オプション> <名前= "プロファイル" 属性> <データタイプ= "NMTOKEN" /> <名前= "locationInformation" を定義>
</attribute> </optional> </define> </div>
</属性> </オプション> </定義> </ div>
<div> <a:documentation> Service Boundary </a:documentation>
<div> <A：ドキュメント>サービス境界</：ドキュメント>
<define name="serviceBoundary"> <oneOrMore> <element name="serviceBoundary"> <ref name="locationInformation"/> </element> </oneOrMore> </define> </div>
<定義/> </ div> <REF名= "locationInformation" /> </要素> </ oneOrMore> <oneOrMore> <要素名= "serviceBoundary"> <名前= "serviceBoundary" を定義>
<div> <a:documentation> Service Boundary Reference </a:documentation>
<div> <A：ドキュメント>サービス境界リファレンス</：ドキュメント>
<define name="serviceBoundaryReference">
<名前= "serviceBoundaryReference" を定義>
<element name="serviceBoundaryReference"> <ref name="source"/> <ref name="serviceBoundaryKey"/> <ref name="extensionPoint"/> </element> </define>
<要素名= "serviceBoundaryReference"> <REF名= "ソース" /> <REF名= "serviceBoundaryKey" /> <REF名= "拡張ポイント" /> </要素> </定義>
<define name="serviceBoundaryKey"> <attribute name="key"> <data type="token"/> </attribute> </define> </div>
<名前= "serviceBoundaryKey" を定義> <属性名= "キー"> <データタイプ= "トークン" /> </属性> </定義> </ div>
<div> <a:documentation> Path - Contains a list of via elements - places through which information flowed </a:documentation>
<div> <A：ドキュメンテーション> <：ドキュメント/ A>パス - 情報が流されて場所 - 素子を介してのリストが含まれています
<define name="path"> <element name="path"> <oneOrMore> <element name="via"> <ref name="source"/> <ref name="extensionPoint"/> </element> </oneOrMore> </element> </define> </div>
<定義名= "パス"> <要素名= "パス"> <oneOrMore> <要素名= "経由"> <REF名= "ソース" /> <REF名= "拡張ポイント" /> </要素> < / oneOrMore> </要素> </定義> </ div>
<div> <a:documentation> Location Used </a:documentation>
<div> <A：ドキュメンテーション> <：ドキュメント/>中古場所
<define name="locationUsed"> <optional> <element name="locationUsed"> <attribute name="id"> <data type="token"/> </attribute> </element> </optional> </define> </div>
<定義名= "locationUsed"> <オプション> <要素名= "locationUsed"> </要素> </オプション> </ </属性> <= "トークン" /データタイプ> <名前= "ID" を属性> > </ div>の定義
<div> <a:documentation> Expires pattern </a:documentation>
<div> <A：ドキュメント>有効期限パターン</ A：ドキュメント>
<define name="expires"> <attribute name="expires"> <choice> <data type="dateTime"/> <value>NO-CACHE</value> <value>NO-EXPIRATION</value> </choice> </attribute> </define> </div>
<属性名= "期限が切れ"> <選択> <データタイプ= "dateTimeの" /> <値> NO-CACHE </ value>の<値> NO-EXPIRATION </ value>の</を<= "期限が切れ" 名前を定義します>選択肢> </属性> </定義> </ div>
<div> <a:documentation> A QName list </a:documentation>
<div> <A：ドキュメント>のQNameリスト</：ドキュメント>
<define name="qnameList"> <list> <zeroOrMore> <data type="QName"/> </zeroOrMore> </list> </define> </div>
<リスト> <zeroOrMore> <データタイプ= "QNameの" /> </ zeroOrMore> </リスト> </定義> </ div> <= "qnameList" 名前を定義します>
<div> <a:documentation> A location-to-service mapping. </a:documentation>
<div> <A：ドキュメント>場所からサービスへのマッピング。 </：ドキュメント>
<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>
<定義名= "マッピング"> <要素名= "マッピング"> <zeroOrMore> <要素名= "のdisplayName"> <データタイプ= "文字列" /> <属性名= "XML：LANG"> <データ型= "言語" /> </属性> </要素> </ zeroOrMore> <refの名前= "サービス" /> <オプション> <選択> <refの名前= "serviceBoundary" /> <refの名前= "serviceBoundaryReference" /> </選択> </オプション> <zeroOrMore> <要素名= "URI"> <データタイプ= "anyURIの" /> </要素> </ zeroOrMore> <オプション> <要素名= "serviceNumber"> <データ型= "トークン"> <PARAM NAME = "パターン"> [0-9 *＃] + </ param>の</データ> </要素> </オプション> <REF名= "拡張ポイント" /> <REF名= "期限が切れ" /> <属性名= "lastUpdated"> <データタイプ= "dateTimeの" /> </属性>
<ref name="source"/> <attribute name="sourceId"> <data type="token"/> </attribute> <ref name="message"/> </element> </define> </div>
<REF名= "ソース" /> <属性名= "ソースID"> <データタイプ= "トークン" /> </属性> <REF名= "メッセージ" /> </要素> </定義> </ DIV >
<div> <a:documentation> Location validation </a:documentation>
<div> <A：ドキュメント>場所の検証</ A：ドキュメント>
<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>
<定義名= "locationValidation"> <要素名= "locationValidation"> <オプション> <要素名= "有効"> <REF名= "qnameList" /> </要素> </オプション> <オプション> <要素名= "無効"> <REF名= "qnameList" /> </要素> </オプション> <オプション> <要素名= "未チェック"> <REF名= "qnameList" /> </要素> </オプション> <refの名前= "拡張ポイント" /> </要素> </定義> </ div>
<div> <a:documentation> Errors and Warnings Container. </a:documentation>
<div> <A：ドキュメント>エラーと警告コンテナ。 </：ドキュメント>
<define name="exceptionContainer"> <interleave> <optional> <ref name="badRequest"/> </optional> <optional>
<名前を定義= "exceptionContainer"> <インターリーブ> <オプション> <REF名= "badRequest" /> </オプション> <オプション>
<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>
<REF名= "internalError" /> </オプション> <オプション> <REF名= "serviceSubstitution" /> </オプション> <オプション> <REF名= "defaultMappingReturned" /> </オプション> <オプション> <REF名前= "禁じられた" /> </オプション> <オプション> <refの名前= "NOTFOUND" /> </オプション> <オプション> <refの名前は= "ループ" /> </オプション> <オプション> <refの名前= "serviceNotImplemented" /> </オプション> <オプション> <REF名= "serverTimeoutの" /> </オプション> <オプション> <REF名= "SERVERERROR" /> </オプション> <オプション> <REF名= "locationInvalid "/> </オプション> <オプション> <REF名=" locationProfileUnrecognized "/> </オプション> </インターリーブ> <REF名=" 拡張ポイント "/> <REF名=" ソース "/> </>定義
<define name="errors"> <element name="errors"> <ref name="exceptionContainer"/> </element> </define>
<定義名= "エラー"> <要素名= "エラー"> <REF名= "exceptionContainer" /> </要素> </定義>
<define name="warnings"> <element name="warnings"> <ref name="exceptionContainer"/> </element> </define>
<定義名= "警告"> <要素名= "警告"> <REF名= "exceptionContainer" /> </要素> </定義>
</div>
</ div>
<div> <a:documentation> Basic Exceptions </a:documentation>
<div> <A：ドキュメント>基本的な例外</ A：ドキュメント>
<define name="basicException"> <a:documentation> Exception pattern. </a:documentation> <ref name="message"/> <ref name="extensionPoint"/> </define>
例外パターン：<ドキュメント>の<name = "basicException" を定義>。 </：ドキュメント> <refの名前= "メッセージ" /> <refの名前= "拡張ポイント" /> </定義>
<define name="badRequest"> <element name="badRequest"> <ref name="basicException"/> </element> </define>
<定義名= "badRequest"> <要素名= "badRequest"> <REF名= "basicException" /> </要素> </定義>
<define name="internalError"> <element name="internalError"> <ref name="basicException"/> </element> </define>
<定義名= "internalError"> <要素名= "internalError"> <REF名= "basicException" /> </要素> </定義>
<define name="serviceSubstitution"> <element name="serviceSubstitution"> <ref name="basicException"/> </element> </define>
<定義名= "serviceSubstitution"> <要素名= "serviceSubstitution"> <REF名= "basicException" /> </要素> </定義>
<define name="defaultMappingReturned"> <element name="defaultMappingReturned"> <ref name="basicException"/> </element> </define>
<定義名= "defaultMappingReturned"> <要素名= "defaultMappingReturned"> <REF名= "basicException" /> </要素> </定義>
<define name="forbidden"> <element name="forbidden"> <ref name="basicException"/> </element> </define>
<定義名= "禁止"> <要素名= "禁止"> <REF名= "basicException" /> </要素> </定義>
<define name="notFound"> <element name="notFound"> <ref name="basicException"/>
<定義名= "NOTFOUND"> <要素名= "NOTFOUND"> <REF名= "basicException" />
</element> </define>
</要素> </定義>
<define name="loop"> <element name="loop"> <ref name="basicException"/> </element> </define>
<定義名= "ループ"> <要素名= "ループ"> <REF名= "basicException" /> </要素> </定義>
<define name="serviceNotImplemented"> <element name="serviceNotImplemented"> <ref name="basicException"/> </element> </define>
<定義名= "serviceNotImplemented"> <要素名= "serviceNotImplemented"> <REF名= "basicException" /> </要素> </定義>
<define name="serverTimeout"> <element name="serverTimeout"> <ref name="basicException"/> </element> </define>
<定義名= "serverTimeoutの"> <要素名= "serverTimeoutの"> <REF名= "basicException" /> </要素> </定義>
<define name="serverError"> <element name="serverError"> <ref name="basicException"/> </element> </define>
<定義名= "SERVERERROR"> <要素名= "SERVERERROR"> <REF名= "basicException" /> </要素> </定義>
<define name="locationInvalid"> <element name="locationInvalid"> <ref name="basicException"/> </element> </define>
<定義名= "locationInvalid"> <要素名= "locationInvalid"> <REF名= "basicException" /> </要素> </定義>
<define name="locationValidationUnavailable"> <element name="locationValidationUnavailable"> <ref name="basicException"/> </element> </define>
<定義名= "locationValidationUnavailable"> <要素名= "locationValidationUnavailable"> <REF名= "basicException" /> </要素> </定義>
<define name="locationProfileUnrecognized"> <element name="locationProfileUnrecognized"> <attribute name="unsupportedProfiles"> <data type="NMTOKENS"/> </attribute> <ref name="basicException"/> </element> </define> </div>
<定義名= "locationProfileUnrecognized"> <要素名= "locationProfileUnrecognized"> <データタイプ= "NMTOKENS" /> </属性> <REF名= "basicException" /> </要素> <名前= "unsupportedProfilesを" 属性> </定義> </ div>
<div> <a:documentation> Redirect. </a:documentation>
<div> <A：ドキュメント>リダイレクト。 </：ドキュメント>
<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>
<定義名= "リダイレクト"> <：ドキュメント>リダイレクトパターン</ A：文書> <要素名= "リダイレクト"> <属性名= "ターゲット"> <REF名= "appUniqueString" /> </属性> <REF名= "ソース" /> <REF名= "メッセージ" /> <REF名= "拡張ポイント" /> </要素> </定義> </ div>
<div> <a:documentation> Some common patterns. </a:documentation>
<div> <A：ドキュメント>いくつかの一般的なパターン。 </：ドキュメント>
<define name="message"> <optional> <group> <attribute name="message"> <data type="token"/> </attribute> <attribute name="xml:lang"> <data type="language"/> </attribute> </group> </optional> </define>
<規定名= "メッセージ"> <オプション> <グループ> <属性名= "メッセージ"> <データタイプ= "トークン" /> </属性> <属性名= "XML：langの"> <データタイプ=」言語 "/> </属性> </グループ> </オプション> </定義>
<define name="service"> <optional> <element name="service"> <data type="anyURI"/> </element> </optional> </define>
<データタイプ= "anyURIの" /> </要素> </オプション> </定義> <オプション> <要素名= "サービス"> <名前= "サービス" を定義>
<define name="appUniqueString"> <data type="token"> <param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param> </data> </define>
<名前= "appUniqueString" を定義> <データタイプ= "トークン"> <PARAM NAME = "パターン">（[-ZA-Z0-9 \ - ] + \）+ [-ZA-Z0-9] + </ param>の</データ> </定義>
<define name="source"> <attribute name="source"> <ref name="appUniqueString"/> </attribute> </define>
<名前= "ソース" 属性> <名前= "ソース" を定義> <refの名前= "appUniqueString" /> </属性> </定義>
<define name="serviceList"> <element name="serviceList"> <list> <zeroOrMore> <data type="anyURI"/> </zeroOrMore> </list> </element> </define> </div>
<定義名= "serviceList"> <要素名= "serviceList"> <リスト> <zeroOrMore> <データタイプ= "anyURIの" /> </ zeroOrMore> </リスト> </要素> </定義> </ DIV >
<div> <a:documentation> Patterns for inclusion of elements from schemas in other namespaces. </a:documentation>
<DIV> <A：ドキュメント>他の名前空間内のスキーマの要素を含めるためのパターン。 </：ドキュメント>
<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>
失われた名前空間ではありません：<ドキュメント>の任意の要素を<名前=「notLost」を定義>。 </：ドキュメント> <要素> <anyName> <除い> <ますNSname NS = "壷：IETF：のparams：XML：NS：lost1" /> <ますNSname /> </除く> </ anyName> <refの名前= "除き、anyelement" /> </要素> </定義>
<define name="anyElement"> <a:documentation>
<名前= "を除き、anyelement" を定義> <：ドキュメント>
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>
他の名前空間から任意の要素を含むためのワイルドカードパターン。 </：ドキュメント> <zeroOrMore> <選択> <要素> <anyName /> <refの名前= "を除き、anyelement" /> </要素> <属性> <anyName /> </属性> <テキスト/> </選択> </ zeroOrMore> </定義>
<define name="extensionPoint"> <a:documentation> A point where future extensions (elements from other namespaces) can be added. </a:documentation> <zeroOrMore> <ref name="notLost"/> </zeroOrMore> </define> </div>
<：ドキュメント>将来の拡張（他の名前空間からの要素）を添加することができる点、<名前=「拡張ポイント」を定義>。 </：ドキュメント> <zeroOrMore> <refの名前= "notLost" /> </ zeroOrMore> </定義> </ div>
</grammar>
</文法>
Figure 21
図21
Appendix B. Examples Online
オンライン付録B.例
The XML examples and Relax NG schemas may be found online [24].
XMLの例とNGスキーマをリラックスは、[24]オンラインで見つけることができます。
Authors' Addresses
著者のアドレス
Ted Hardie Qualcomm, Inc.
テッドハーディークアルコム社
EMail: hardie@qualcomm.com
メールアドレス：hardie@qualcomm.com
Andrew Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 US
インターネット番号3635コンコルドパークウェイ、スイート200シャンティイ、VA 20151、米国のためのアンドリュー・ニュートンのアメリカのレジストリ
Phone: +1 703 227 9894 EMail: andy@hxr.us
電話：+1 703 227 9894 Eメール：andy@hxr.us
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs+ecrit@cs.columbia.edu URI：http://www.cs.columbia.edu
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@nsn.com URI：http://www.tschofenig.priv.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。