RFC5222 日本語訳
5222 LoST: A Location-to-Service Translation Protocol. T. Hardie, A.Newton, H. Schulzrinne, H. Tschofenig. August 2008. (Format: TXT=123252 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Hardie
Request for Comments: 5222 Qualcomm, Inc.
Category: Standards Track A. Newton
American Registry for Internet Numbers
H. Schulzrinne
Columbia University
H. Tschofenig
Nokia Siemens Networks
August 2008
コメントを求めるワーキンググループT.ハーディー要求をネットワークでつないでください: 5222年のクアルコムInc.カテゴリ: 規格は2008年8月にインターネット数のH.Schulzrinneコロンビア大学H.TschofenigノキアジーメンスネットワークのためにA.のニュートンのアメリカの登録を追跡します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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ベースのプロトコルについて説明します。 特に、緊急サービスのために、位置の適切なPublic Safety Answering Point(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
1. 序論… 3 2. 用語と要件記法… 4 3. プロトコル用法の概要… 5 4. サーバと彼らの解決を失います… 6 5. <マッピング>要素… 7 5.1. マッピングデータ送信端末: 'ソース'、'sourceId'、および'lastUpdated'属性… 7 5.2. マッピングの正当性: '期限が切れ'属性… 8 5.3. <displayName>要素でサービスについて説明します… 8 5.4. 写像しているサービス: <サービス>要素… 8 5.5. <serviceBoundary>要素でサービス領域を定義します… 9 5.6. 参照で境界を修理してください: <serviceBoundaryReference>要素… 9 5.7. 認識番号: <serviceNumber>要素… 10 5.8. URLを修理してください: <uri>要素… 10
Hardie, et al. Standards Track [Page 1] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[1ページ]RFC5222
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
6. 要求の経路: <経路>要素… 10 7. 以下を写像するのに使用される位置の要素を特定すること。 <は>をlocationUsedしました… 11 8. URLに対する位置とサービスを写像します: <findService>… 11 8.1. 概要… 11 8.2. 例… 11 8.2.1. 測地座標を使用する例… 11 8.2.2. 都市のアドレス・マッピングの例… 13 8.3. <findService>要求の成分… 15 8.3.1. <位置の>要素… 15 8.3.2. サービスを特定します: <サービス>要素… 16 8.3.3. 再帰と繰り返し… 16 8.3.4. 境界を修理してください… 16 8.3.5. 都市の位置の合法化を要求します… 16 8.4. マッピング応答<findServiceResponse>の部品… 18 8.4.1. 概要… 18 8.4.2. 都市のアドレス合法化: <locationValidation>要素… 19 9. <getServiceBoundary>を通してService Boundaryを検索します… 19 10. サービスを記載してください: <listServices>… 21 11. 位置のそばにサービスを記載してください: <listServicesByLocation>… 22 12. 位置のプロフィール… 24 12.1. ロケーション・プロフィール用法… 25 12.2. 二次元測地学のプロフィール… 30 12.3. 基本の都市のプロフィール… 31 13. そして、誤り、警告、向け直します。 32 13.1. 誤り… 32 13.2. 警告… 34 13.3. 向け直します。 36 14. 無くなっている輸送: HTTP… 36 15. NG図式を弛緩してください… 37 16. 国際化問題… 44 17. IANA問題… 44 17.1. U-NAPTR登録証明書… 44 17.2. 'アプリケーション/は+ xmlをなくした'コンテントタイプ登録… 44 17.3. 失われて、NG図式登録を弛緩してください… 46 17.4. 名前空間登録を失います… 46 17.5. ロケーション・プロフィール登録を失います… 47 18. セキュリティ問題… 47 19. 承認… 48 20. 参照… 51 20.1. 標準の参照… 51 20.2. 有益な参照… 52付録A.、非標準、XML構文でNG図式を弛緩してください… オンライン54の付録B.の例… 67
Hardie, et al. Standards Track [Page 2] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[2ページ]RFC5222
1. Introduction
1. 序論
Protocols such as Naming Authority Pointer (NAPTR) records and the Service Location Protocol (SLP) can be used to discover servers offering a particular service. However, for an important class of services the appropriate specific service instance depends both on the identity of the service and the geographic location of the entity that needs to reach it. Emergency telecommunications services are an important example; here, the service instance is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the user making the call. The desired PSAP isn't necessarily the one that is topologically or even line-of-sight closest to the caller; rather, it is the one that serves the caller's location based on jurisdictional boundaries.
サーバが特定のサービスを提供していると発見するのにNaming Authority Pointer(NAPTR)記録やService Locationプロトコル(SLP)などのプロトコルを使用できます。 しかしながら、重要なクラスのサービスのために、適切な特定のサービスインスタンスはそれに達する必要があるサービスのアイデンティティと実体の地理的な位置によります。 非常時の遠距離通信サービスは重要な例です。 ここで、サービスインスタンスは電話をかけているユーザの位置に管轄するPublic Safety Answering Point(PSAP)です。 必要なPSAPは訪問者の最も近くの必ず位相的にそうであるものか照準線になりさえしません。 むしろ、それは司法権の境界に基づく訪問者の位置に役立つものです。
This document describes a protocol for mapping a service identifier and location information compatible with the Presence Information Data Format Location Object (PIDF-LO) [6] to one or more service URIs. Service identifiers take the form of the service URNs described in [9]. Location information here includes revised civic location information [10] and a subset of the PIDF-LO profile [13], which consequently includes the Geo-Shapes [12] defined for GML [11]. Example service URI schemes include sip [14], xmpp [15], and tel [16]. While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to other service URNs. For example, in the United States, the "2-1-1" and "3-1-1" service numbers follow a similar location-to-service behavior as emergency services.
このドキュメントは、1つ以上のサービスURIへのPresence情報Data Format Location Object(PIDF-LO)[6]とのコンパチブルサービス識別子と位置情報を写像するためにプロトコルについて説明します。 サービス識別子は[9]で説明されたサービスURNsの形を取ります。 ここの位置情報は改訂された都市の位置情報[10]とPIDF-LOプロフィール[13]の部分集合を含んでいます。(その結果、それは、GML[11]のために定義されたジオ-形の[12]を含んでいます)。 例のサービスURI体系は一口[14]、xmpp[15]、およびtel[16]を含んでいます。 初期の焦点がマッピング機能を緊急サービスに提供するところにありますが、プロトコルが他のサービスURNsに適切であることは、ありそうです。 そして、例えば合衆国で「2-11インチ、「3-11インチの認識番号は緊急サービスとして同様の位置から使用挙動に続きます」。
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.
このドキュメントはLocationからサービスへのTranslationのために「失われた」このプロトコルを命名します。 LoSTはプロトコルを写像するための要件[18]を満たします。 LoSTは位置を写像するのが中心に置かれた多くの操作とサービスURNsをサービスURLと関連情報に提供します。 質問を写像するLoSTは都市の、または、測地学の位置情報を含むことができます。 都市のアドレスのために、LoSTは、有効であるか、または都市のアドレスのどの部分が無効であることが知られているかを示すことができます、その結果、アドレス合法化を提供します、[18]のセクション3.5で説明されるように。 LoSTはデバッグしていて適切なユーザフィードバックを容易にするために位置のデータにおける誤りを示しますが、ベストエフォート型答えをまた提供します。
LoST queries can be resolved recursively or iteratively. To minimize
round trips and to provide robustness against network failures, LoST
supports caching of individual mappings and indicates the region for
which the same answer would be returned ("service region").
再帰的か繰り返しにLoST質問を決議できます。 LoSTは、周遊旅行を最小にして、ネットワーク失敗に対して丈夫さを提供するために、個々のマッピングのキャッシュをサポートして、同じ答えが返される領域(「サービス領域」)を示します。
Hardie, et al. Standards Track [Page 3] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[3ページ]RFC5222
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.
本書では定義されるように、LoSTメッセージはHTTPとHTTPSプロトコル交換で伝えられます、TLSの保全を保護する使用と要求と応答の秘密性を容易にして。
This document focuses on the description of the protocol between the mapping client and the mapping server. Other functions, such as discovery of mapping servers, data replication and the overall mapping server architecture are described in a separate document [19].
このドキュメントはマッピングクライアントとマッピングサーバの間でプロトコルの記述に焦点を合わせます。サーバ、データ模写、および総合的なマッピングサーバー・アーキテクチャを写像する発見などの他の機能は別々のドキュメント[19]で説明されます。
The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [9]) from the LoST client to the LoST server. The LoST server uses its database to map the input values to one or more Uniform Resource Identifiers (URIs) and returns those URIs along with optional information, such as hints about the service boundary, in a response message to the LoST client. If the server cannot resolve the query itself, it may in turn query another server or return the address of another LoST server, identified by a LoST server name. In addition to the mapping function described in Section 8, the protocol also allows to retrieve the service boundary (see Section 9) and to list the services available for a particular location (see Section 11) or supported by a particular server (see Section 10).
(LoSTサーバは、1つ以上のUniform Resource Identifier(URI)に入力値を写像するのにデータベースを使用して、任意の情報に伴うそれらのURIを返します、サービス境界の周りのヒントなどのように、LoSTクライアントへの応答メッセージで。質問メッセージはUniform Resource Name(URN)としてコード化された位置情報とサービス識別子を運びます。LoSTクライアントからLoSTサーバまでの[9])を見てください。 サーバが質問自体を決議できないなら、それは、順番に別のサーバについて質問するか、またはLoSTサーバー名によって特定された別のLoSTサーバのアドレスを返すかもしれません。 セクション8で説明されたマッピング機能、特定のサーバ(セクション10を見る)によって、また、サービス境界(セクション9を見る)を検索して、特定の位置(セクション11を見る)に利用可能なサービスを記載するのを許容するか、またはサポートされたプロトコルに加えて。
2. Terminology and Requirements Notation
2. 用語と要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
This document uses the following terms:
このドキュメントは次の用語を使用します:
Mapping:
Mapping is a process that takes a location and a service
identifier as inputs and returns one or more URIs. Those URIs can
point either to a host providing that service or to a host that in
turn routes the request to the final destination. This definition
is a generalization of the term "mapping" as used in [18], because
LoST can be used for non-emergency services.
マッピング: マッピングは入力として位置とサービス識別子をみなして、1つ以上のURIを返すプロセスです。 それが順番に最終的な目的地への要求をサービスかホストに発送するなら、それらのURIはホストを示すことができます。 この定義は[18]で使用されるように「写像」という用語の一般化です、非緊急サービスにLoSTを使用できるので。
LoST client:
A host acts as a LoST client if it sends LoST query messages and
receives LoST response messages.
LoSTクライアント: 質問メッセージをLoSTに送って、LoST応答メッセージを受けるなら、ホストはLoSTクライアントとして務めます。
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.
LoSTサーバ: LoST質問メッセージを受け取って、応答メッセージをLoSTに送るなら、ホストはLoSTサーバとして務めます。 再帰的な操作では、同じ実体はクライアントとサーバの両方であるかもしれません。
Hardie, et al. Standards Track [Page 4] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[4ページ]RFC5222
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.
正式のLoSTサーバ: 正式のサーバは、単にサーバとして機能して、首尾よく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]で追加非常時のサービス用語を見つけることができます。
3. Overview of Protocol Usage
3. プロトコル用法の概要
The LoST protocol supports the following types of queries and responses:
LoSTプロトコルは以下のタイプの質問と応答をサポートします:
<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.
LoSTクライアントが検索する<findService>と<findServiceResponse>Aはこの要求と応答で位置情報とサービス識別子に基づくURIに連絡します。 また、同じ質問タイプは位置の合法化を求めるかもしれません、そして、認識番号のために、どちらかが別々にマッピング要求に結合しました。 セクション8で詳細を見つけることができます。
<getServiceBoundary> and <getServiceBoundaryResponse>
A LoST client obtains a service boundary with this request and
response, as described in Section 9.
<getServiceBoundary>と<getServiceBoundaryResponse>A LoSTクライアントはセクション9で説明されるようにこの要求と応答でサービス境界を得ます。
<listServices> and <listServicesResponse>
With this request and response, a LoST client can find out which
services a LoST server supports, as described in Section 10.
<は>とこの要求と応答、LoSTクライアントがLoSTサーバがサポートするどのサービスから見つけることができる<listServicesResponse>WithをlistServicesします、セクション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 LoSTクライアントは、この要求と応答でどのサービスが特定の位置の地域に利用可能であるかを決心できます。 セクション11は詳細について説明します。
LoST clients may initiate any of the above queries at any time. Among the common triggers are:
LoSTクライアントはいつでも、上の質問のいずれも開始するかもしれません。 一般的な引き金の中に、以下があります。
1. when the client initially starts up or attaches to a network;
1. クライアントは初めは、いつ始動するか、そして、ネットワークへの大使館員。
Hardie, et al. Standards Track [Page 5] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[5ページ]RFC5222
2. when the client detects that its location has changed
sufficiently that it is outside the bounds of the service region;
2. クライアントがそれを検出するとき、サービス領域の領域の外にそれがあることができるくらい位置は変化しました。
3. when a SIP message arrives at a SIP proxy performing location-
based call routing;
3. SIPメッセージがSIPプロキシに到着するとき、位置を実行すると、呼び出しルーティングは基づきました。
4. when cached mapping information has expired; and
4. キャッシュされると、マッピング情報は期限が切れました。 そして
5. when invoking a particular service. At that time, a client may
omit requests for service boundaries or other auxiliary
information.
5. 特定のサービスを呼び出すとき。 その時、クライアントはサービス境界を求める要求か他の補助の情報を省略するかもしれません。
A service-specific Best Current Practice (BCP) document, such as [21], governs whether a client is expected to invoke the mapping service just before needing the service or whether to rely on cached answers. Cache entries expire at their expiration time (see Section 5.2), or they become invalid if the caller's device moves beyond the boundaries of the service region. Service-specific Best Current Practice documents may also provide guidance on the contact URI schemes most appropriate to the service. As a general set of guidelines, URI schemes that do not provide mechanisms for actually initiating a contact method should be avoided (examples include data, info, cid, and tag) as transforming those references into contact mechanisms requires a layer of indirection that makes the overall mechanism more fragile. Provisionally registered URI schemes should also be carefully considered before use, because they are subject to change in core semantics.
[21]などのサービス特有のBest Current Practice(BCP)ドキュメントは、サービスを必要とするすぐ前にクライアントがマッピングサービスを呼び出すと予想されるかどうか、またはキャッシュされた答えに依存するかどうかを治めます。 キャッシュエントリーが彼らの満了時に期限が切れるか(セクション5.2を見てください)、または訪問者のデバイスでサービス領域の枠を越えるなら、それらは無効になります。 また、サービス特有のBest Current Practiceドキュメントはサービスに最も適切な接触URI体系で指導を提供するかもしれません。 一般的なマニュアルとして、それらの参照を連絡メカニズムに変えるのが総合的なメカニズムをよりこわれやすくする間接指定の層を必要とするとき、実際に連絡手段に着手するのにメカニズムを提供しないURI体系は避けられるべきです(例はデータ、インフォメーション、Cid、およびタグを含んでいます)。 また、それらは受けることがあるので、使用の前に臨時に登録されたURI体系がコア意味論で変化すると慎重に考えられるべきです。
4. LoST Servers and Their Resolution
4. 無くなっているサーバと彼らの解決
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'.
LoSTサーバはU-NAPTR/DDDS(URIで可能にされたNAPTR/ダイナミックなDelegationディスカバリーService)の[8]のアプリケーションのユニークなストリングによって特定されます、DNS名の形で。 例は'lostserver.example.com'です。
Clients need to use the U-NAPTR [8] specification described below to obtain a URI (indicating host and protocol) for the applicable LoST service. In this document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any valid HTTP URL, including those containing path elements.
クライアントは、URI(ホストを示して、プロトコル)を適用されるLoSTサービスに得るために以下で説明された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エントリーが"example.com"のためにHTTPS URL https://lostserv.example.com/secure かHTTP URL http://lostserver.example.com にU-NAPTR解決を示しています、前者が好まれている状態で。
Hardie, et al. Standards Track [Page 6] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[6ページ]RFC5222
example.com.
example.com。
IN NAPTR 100 10 "u" "LoST:https"
"!.*!https://lostserver.example.com/secure!" ""
「NAPTR100 10では、「u」は「: httpsをなくした!」、*! https://lostserver.example.com/secure! 、」 ""
IN NAPTR 200 10 "u" "LoST:http"
"!.*!http://lostserver.example.com!" ""
「NAPTR200 10では、「u」は「: 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].
クライアントは手段でこの仕様の範囲を超えてLoSTサーバのホスト名を学びます、SIP構成とDHCP[25]などのように。
5. The <mapping> Element
5. <マッピング>要素
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.
サービス領域と関連サービスURLについて説明して、<マッピング>要素はLoSTのコアデータ要素です。 その属性と要素は以下の小区分で説明されます。
5.1. The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated'
Attributes
5.1. マッピングデータ送信端末: 'ソース'、'sourceId'、および'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'.
'ソース'、'sourceId'、および'lastUpdated'属性は唯一特定のマッピング記録を特定します。 それらは、マッピングのために権威筋によって作成されて、マッピングがキャッシュから役立たれているとき、決して変更されません。 すべての3つの属性が>要素を写像するすべての<のためのREQUIREDです。 受信機はマッピングを'lastUpdated'で同じ'ソース'、'sourceId'、および、より最近の時間を過す別の1つに取り替えることができます。
The 'source' attribute contains a LoST application unique string identifying the authoritative generator of the mapping (Section 4).
'ソース'属性はマッピング(セクション4)の正式のジェネレータを特定するLoSTのアプリケーションのユニークなストリングを含んでいます。
The 'sourceId' attribute identifies a particular mapping and contains an opaque token that MUST be unique among all different mappings maintained by the authoritative source for that particular service. For example, a Universally Unique Identifier (UUID) is a suitable format.
'sourceId'属性は、特定のマッピングを特定して、その特定のサービスのために権威筋によって維持されたすべての異なったマッピングの中でユニークであるに違いない不透明なトークンを含んでいます。 例えば、Universally Unique Identifier(UUID)は適当な形式です。
The 'lastUpdated' attribute describes when a specific instance of mapping, identified by the combination of 'source' and 'sourceId', was last changed. The contents of this attribute has the XML data type dateTime in its timezoned form, using the canonical UTC representation with the letter 'Z' as the timezone indicator.
'lastUpdated'属性は、''ソース'sourceId'の組み合わせで特定されたマッピングの特定のインスタンスが最後にいつ変えられたかを説明します。 この属性のコンテンツはtimezonedフォームにXMLデータ型dateTimeを持っています、タイムゾーンインディケータとして文字'Z'による正準なUTC表現を使用して。
Hardie, et al. Standards Track [Page 7] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[7ページ]RFC5222
5.2. Mapping Validity: The 'expires' Attribute
5.2. マッピングの正当性: '期限が切れ'属性
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です。 <マッピング>要素は'期限が切れ'属性を含まなければなりません。
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.
任意に、この属性はdateTime値の代わりに'CACHEがありません'と'EXPIRATIONがありません'の値を含むかもしれません。 値の'CACHEがありません'はマッピングをキャッシュするべきでないという指示です。 'EXPIRATIONがありません'の値はマッピングが期限が切れないという指示です。
On occasion, a server may be forced to return an expired mapping if it cannot reach the authoritative server or the server fails to return a usable answer. Clients and servers MAY cache the mapping so that they have at least some information available. Caching servers that have such stale information SHOULD re-attempt the query each time a client requests a mapping. Since the expired mapping will be returned to the client as a non-error/non-warning response, the client MUST check the 'expires' attribute; if the mapping has expired, local policy at the client determines whether it discards the answer and tries again later or uses the possibly stale response.
時々、正式のサーバに達することができないか、またはサーバが使用可能な答えを返さないなら、サーバはやむを得ず満期のマッピングを返すかもしれません。 クライアントとサーバがマッピングをキャッシュするかもしれないので、それらには、利用可能な少なくとも何らかの情報があります。 そのような聞き古した情報SHOULDがその都度質問を再試みるサーバをキャッシュして、クライアントはマッピングを要求します。 非非誤り/警告応答として満期のマッピングをクライアントに返すので、クライアントは'期限が切れ'属性をチェックしなければなりません。 マッピングが期限が切れたなら、クライアントのローカルの方針は、後でそれが答えを捨てて、再試行するかどうか決定するか、またはことによると聞き古した応答を使用します。
5.3. Describing the Service with the <displayName> Element
5.3. <displayName>要素でサービスについて説明します。
Zero or more <displayName> elements describe the service with a string that is suitable for display to human users, each annotated with the 'xml:lang' attribute that contains a language tag to aid in the rendering of text.
<displayName>要素がテキストのレンダリングで支援するために人間のユーザにとってディスプレイに適して、言語タグを含む'xml: lang'属性でそれぞれ注釈されたひもによるサービスについて説明するゼロか以上。
5.4. The Mapped Service: The <service> Element
5.4. 写像しているサービス: <サービス>要素
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:
義務的な<サービス>要素はこのマッピングが申し込まれるサービスを特定します。 2つのケースが、LoSTサーバが<サービス>要素を応答メッセージにはめ込むとき、区別される必要があります:
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]によって特定された要求されたサービスが示された位置に存在しているなら、LoSTサーバは<サービス>要素にサービス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
2. しかしながら、要求における<サービス>要素のサービスURN[9]によって特定された要求されたサービスが示された位置に存在していないなら、サーバは、<serviceNotImplemented>(セクション13.1)に誤りを返すことができるか、または必要なサービスに近似する代替のサービスをそれに提供できます。
Hardie, et al. Standards Track [Page 8] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[8ページ]RFC5222
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.
位置。 後者の場合では、サーバは代替のサービスURNがある<サービス>要素を含まなければなりません。 サービスURNの選択はローカルの方針に残されますが、代替のサービスはオリジナルのサービスのリクエストを満たすことができるべきです。
5.5. Defining the Service Region with the <serviceBoundary> Element
5.5. <serviceBoundary>要素でサービス領域を定義します。
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を見てください)。 クライアントがサービスエリアの外で移行して、当期の勤務データを得たいなら、それは現在の位置がある新しい質問を送ります。 サービス領域は特定のロケーション・プロフィールによると、それぞれフォーマットされたserviceBoundary>要素が'プロフィール'属性で特定した1<で値によって説明されます(セクション12を見てください)。 別の場所プロフィールによると、フォーマットされた<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>要素の属性としてサービス境界に関する識別子を返します、それを検索できるところからサーバを特定するLoSTのアプリケーションのユニークなストリング(セクション4を見る)と共に。 そして、サービス境界の実価は(セクション9)が要求するgetServiceBoundaryと共に検索されます。
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'属性を「参照」に使用することでクライアントによって要求されています。 LoSTサーバは、ローカルの方針に基づいて値でサービス境界を返すか、または応答で<serviceBoundaryReference>要素を省略すると決めるかもしれません。
Hardie, et al. Standards Track [Page 9] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[9ページ]RFC5222
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の正常な生涯を超えていて、このアプローチは、不必要に境界情報をリフレッシュするのを避けます。
5.7. The Service Number: The <serviceNumber> Element
5.7. 認識番号: <serviceNumber>要素
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主要なダイヤルパッドがあるデバイスの上のユーザがその特定のサービスに達するのに使用できた一連のケタ、*、および#、を含んでいます。
5.8. Service URLs: The <uri> Element
5.8. Service URLs: The <uri> Element
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'.
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'.
6. Path of a Request: The <path> Element
6. Path of a Request: The <path> Element
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.
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.
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.
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.
If a query is answered iteratively, the querier includes all servers that it has already contacted.
Hardie, et al. Standards Track [Page 10] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 10] RFC 5222 LoST August 2008
When a cached mapping is returned, then the <path> element cached together with the mapping is returned.
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.
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.
7. Identifying the Location Element Used for Mapping: <locationUsed>
7. Identifying the Location Element Used for Mapping: <locationUsed>
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.
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.
8. Mapping a Location and Service to URLs: <findService>
8. Mapping a Location and Service to URLs: <findService>
8.1. Overview
8.1. Overview
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.
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.
8.2. Examples
8.2. Examples
8.2.1. Example Using Geodetic Coordinates
8.2.1. Example Using Geodetic Coordinates
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).
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).
Hardie, et al. Standards Track [Page 11] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 11] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value" recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
<location id="6020688f1ce1896d" profile="geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> </location> <service>urn:service:sos.police</service>
</findService>
</findService>
Figure 1: A <findService> geodetic query
Figure 1: A <findService> geodetic query
Given the query above, a server would respond with a service, and information related to that service. In the example below, the server has mapped the location given by the client for a police service to the New York City Police Department, instructing the client that it may contact them via the URIs "sip:nypd@example.com" and "xmpp:nypd@example.com". The server has also given the client a geodetic, two-dimensional boundary for this service. The mapping was last updated on November 1, 2006 and expires on January 1, 2007. If the client's location changes beyond the given service boundary or the expiration time has been reached, it may want to requery for this information, depending on the usage environment of LoST.
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.
Hardie, et al. Standards Track [Page 12] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 12] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="geodetic-2d"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <serviceNumber>911</serviceNumber> </mapping> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="6020688f1ce1896d"/> </findServiceResponse>
Figure 2: A <findServiceResponse> geodetic answer
Figure 2: A <findServiceResponse> geodetic answer
8.2.2. Civic Address Mapping Example
8.2.2. Civic Address Mapping Example
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).
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).
Hardie, et al. Standards Track [Page 13] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 13] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" serviceBoundary="value"> <location id="627b8bf819d0bad4d" profile="civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>DE</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Otto-Hahn-Ring</A6> <HNO>6</HNO> <PC>81675</PC> </civicAddress> </location> <service>urn:service:sos.police</service> </findService>
Figure 3: A <findService> civic address query
Figure 3: A <findService> civic address query
Given the query above, a server would respond with a service, and information related to that service. In the example below, the server has mapped the location given by the client for a police service to the Muenchen Polizei-Abteilung, instructing the client that it may contact them via the URIs sip:munich-police@example.com and xmpp:munich-police@example.com. The server has also given the client a civic address boundary (the city of Munich) for this service. The mapping was last updated on November 1, 2006 by the authoritative source "polizei.muenchen.de.example" and expires on January 1, 2007. This instructs the client to requery for the information if its location changes beyond the given service boundary (i.e., beyond the indicated district of Munich) or after January 1, 2007.
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.
Hardie, et al. Standards Track [Page 14] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 14] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="esgw.ueber-110.de.example" sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> <displayName xml:lang="de"> Muenchen Polizei-Abteilung </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>DE</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </mapping> <path> <via source="esgw.ueber-110.de.example"/> <via source="polizei.muenchen.de.example"/> </path> <locationUsed id="627b8bf819d0bad4d"/> </findServiceResponse>
Figure 4: A <findServiceResponse> civic address answer
Figure 4: A <findServiceResponse> civic address answer
8.3. Components of the <findService> Request
8.3. Components of the <findService> Request
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.
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.
8.3.1. The <location> Element
8.3.1. The <location> Element
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
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
Hardie, et al. Standards Track [Page 15] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 15] RFC 5222 LoST August 2008
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.
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.
8.3.2. Identifying the Service: The <service> Element
8.3.2. Identifying the Service: The <service> Element
The type of service desired is specified by the <service> element. It contains service URNs from the registry established in [9].
The type of service desired is specified by the <service> element. It contains service URNs from the registry established in [9].
8.3.3. Recursion and Iteration
8.3.3. Recursion and Iteration
LoST can operate in either recursive or iterative mode, on a request- by-request basis. In recursive mode, the LoST server initiates queries on behalf of the requester and returns the result to the requester.
LoST 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.
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".
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".
8.3.4. Service Boundary
8.3.4. Service Boundary
LoST <mapping> elements can describe the service boundary either by value or by reference. Returning a service boundary reference is generally more space-efficient for geospatial (polygon) boundaries and if the boundaries change rarely, but does incur an additional <getServiceBoundary> request. The querier can express a preference for one or the other modality with the 'serviceBoundary' attribute in the <findService> request, but the server makes the final decision as to whether to return a reference or a value.
LoST <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.
8.3.5. Requesting Civic Location Validation
8.3.5. Requesting Civic Location Validation
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.
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.
Hardie, et al. Standards Track [Page 16] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 16] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" validateLocation="true" serviceBoundary="value"> <location id="627b8bf819d0bad4d" profile="civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>DE</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Otto-Hahn-Ring</A6> <HNO>6</HNO> <PC>81675</PC> </civicAddress> </location> <service>urn:service:sos.police</service> </findService>
Figure 5: A <findService> query with address validation request
Figure 5: A <findService> query with address validation request
Hardie, et al. Standards Track [Page 17] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 17] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="authoritative.example" sourceId="4db898df52b84edfa9b6445ea8a0328e"> <displayName xml:lang="de"> Muenchen Polizei-Abteilung </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>DE</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </mapping> <locationValidation> <valid>country A1 A3 A6</valid> <invalid>PC</invalid> <unchecked>HNO</unchecked> </locationValidation> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="627b8bf819d0bad4d"/> </findServiceResponse>
Figure 6: A <findServiceResponse> message with address validation
information
Figure 6: A <findServiceResponse> message with address validation information
8.4. Components of the Mapping Response <findServiceResponse>
8.4. Components of the Mapping Response <findServiceResponse>
8.4.1. Overview
8.4.1. Overview
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 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.
Hardie, et al. Standards Track [Page 18] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 18] RFC 5222 LoST August 2008
8.4.2. Civic Address Validation: The <locationValidation> Element
8.4.2. Civic Address Validation: The <locationValidation> Element
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.
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.
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.
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.
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.
9. Retrieving the Service Boundary via <getServiceBoundary>
9. Retrieving the Service Boundary via <getServiceBoundary>
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.
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.
Hardie, et al. Standards Track [Page 19] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 19] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" recursive="true" serviceBoundary="reference"> <location id="6020688f1ce1896d" profile="geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> </location> <service>urn:service:sos.police</service> </findService>
Figure 7: <findService> request and response with service boundary
reference
Figure 7: <findService> request and response with service boundary reference
<?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" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundaryReference source="authoritative.example" key="7214148E0433AFE2FA2D48003D31172E"/> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <serviceNumber>911</serviceNumber> </mapping> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="6020688f1ce1896d"/> </findServiceResponse>
Figure 8: <findServiceResponse> message with service boundary
reference
Figure 8: <findServiceResponse> message with service boundary reference
Hardie, et al. Standards Track [Page 20] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 20] RFC 5222 LoST August 2008
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/>
<?xml version="1.0" encoding="UTF-8"?> <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" key="7214148E0433AFE2FA2D48003D31172E"/>
Figure 9: Requesting a service boundary with <getServiceBoundary>
Figure 9: Requesting a service boundary with <getServiceBoundary>
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</getServiceBoundaryResponse>
<?xml version="1.0" encoding="UTF-8"?> <getServiceBoundaryResponse xmlns="urn:ietf:params:xml:ns:lost1"> <serviceBoundary profile="geodetic-2d"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> </getServiceBoundaryResponse>
Figure 10: Geodetic service boundary response
Figure 10: Geodetic service boundary response
10. List Services: <listServices>
10. List Services: <listServices>
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.
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.
Hardie, et al. Standards Track [Page 21] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 21] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <listServices xmlns="urn:ietf:params:xml:ns:lost1"> <service>urn:service:sos</service> </listServices>
Figure 11: Example of <ListServices> query
Figure 11: Example of <ListServices> query
<?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="authoritative.example"/>
</path>
</listServicesResponse>
<?xml version="1.0" encoding="UTF-8"?> <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> <serviceList> urn:service:sos.ambulance urn:service:sos.animal-control urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.marine urn:service:sos.physician urn:service:sos.poison urn:service:sos.police </serviceList> <path> <via source="authoritative.example"/> </path> </listServicesResponse>
Figure 12: Example of <ListServicesResponse>
Figure 12: Example of <ListServicesResponse>
11. List Services By Location: <listServicesByLocation>
11. List Services By Location: <listServicesByLocation>
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.
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.
Hardie, et al. Standards Track [Page 22] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 22] RFC 5222 LoST August 2008
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.
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.
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.
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.
<?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" encoding="UTF-8"?> <listServicesByLocation xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" recursive="true"> <location id="3e19dfb3b9828c3" profile="geodetic-2d"> <p2:Point srsName="urn:ogc:def:crs:EPSG::4326"> <p2:pos>-34.407 150.883</p2:pos> </p2:Point> </location> <service>urn:service:sos</service> </listServicesByLocation>
Figure 13: Example of <ListServicesbyLocation> query
Figure 13: Example of <ListServicesbyLocation> query
Hardie, et al. Standards Track [Page 23] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 23] RFC 5222 LoST August 2008
<?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 version="1.0" encoding="UTF-8"?> <listServicesByLocationResponse xmlns="urn:ietf:params:xml:ns:lost1"> <serviceList> urn:service:sos.ambulance urn:service:sos.animal-control urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.marine urn:service:sos.physician urn:service:sos.poison urn:service:sos.police </serviceList> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="3e19dfb3b9828c3"/> </listServicesByLocationResponse>
Figure 14: Example of <ListServicesByLocationResponse> response
Figure 14: Example of <ListServicesByLocationResponse> response
12. Location Profiles
12. Location Profiles
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 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:
geodetic-2d:
a profile for two-dimensional geodetic location information, as
described in Section 12.2;.
geodetic-2d: a profile for two-dimensional geodetic location information, as described in Section 12.2;.
civic:
a profile consisting of civic address location information, as
described in Section 12.3.
civic: a profile consisting of civic address location information, as described in Section 12.3.
Hardie, et al. Standards Track [Page 24] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 24] RFC 5222 LoST August 2008
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.
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.
Standards action is required for defining new profiles. A location profile MUST define:
Standards action is required for defining new profiles. A location profile MUST define:
1. The token identifying it in the LoST location profile registry.
1. The token identifying it in the LoST location profile registry.
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. 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.
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. 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.
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. 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.
12.1. Location Profile Usage
12.1. Location Profile Usage
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.
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.
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.
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.
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.
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.
Hardie, et al. Standards Track [Page 25] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 25] RFC 5222 LoST August 2008
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.
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.
Using the location profiles defined in this document, the following rules ensure interoperability between clients and servers:
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. A client MUST be capable of understanding the response for the baseline profiles it used in the request.
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. 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.
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. 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.
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. 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.
5. There can only be one instance of each location profile in a
query.
5. There can only be one instance of each location profile in a query.
6. Servers MUST implement all profiles described in this document.
6. Servers MUST implement all profiles described in this document.
7. A server uses the first-listed location profile that it
understands and ignores the others.
7. A server uses the first-listed location profile that it understands and ignores the others.
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. 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).
Hardie, et al. Standards Track [Page 26] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 26] RFC 5222 LoST August 2008
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. 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.
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.
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.
Hardie, et al. Standards Track [Page 27] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 27] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" recursive="true" serviceBoundary="value"> <location id="ABC 123" profile="not-yet-standardized-prism-profile"> <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> <gs:base> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList> 42.556844 -73.248157 36.6 42.656844 -73.248157 36.6 42.656844 -73.348157 36.6 42.556844 -73.348157 36.6 42.556844 -73.248157 36.6 </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gs:base> <gs:height uom="urn:ogc:def:uom:EPSG::9001"> 2.4 </gs:height> </gs:Prism> </location> <location id="DEF 345" profile="geodetic-2d"> <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <gml:pos>42.656844 -73.348157</gml:pos> </gml:Point> </location> <service>urn:service:sos.police</service> </findService>
Figure 15: Example of a <findServices> query with baseline profile
interoperability
Figure 15: Example of a <findServices> query with baseline profile interoperability
Hardie, et al. Standards Track [Page 28] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 28] RFC 5222 LoST August 2008
<?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" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/"> <mapping expires="2007-01-01T01:44:33Z" lastUpdated="2006-11-01T01:00:00Z" source="authoritative.example" sourceId="cf19bbb038fb4ade95852795f045387d"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="geodetic-2d"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:nypd@example.com</uri> <serviceNumber>911</serviceNumber> </mapping> <path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="DEF 345"/> </findServiceResponse>
Figure 16: Example of a <findServiceResponse> message with baseline
profile interoperability
Figure 16: Example of a <findServiceResponse> message with baseline profile interoperability
Hardie, et al. Standards Track [Page 29] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 29] RFC 5222 LoST August 2008
12.2. Two-Dimensional Geodetic Profile
12.2. Two-Dimensional Geodetic Profile
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):
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):
Point:
The <Point> element is described in Section 5.2.1 of [13].
Section 5.2.1 of [13] shows also the specification of a <Point>
with either a two-dimensional position (latitude and longitude) or
three-dimensional position (latitude, longitude, and altitude). A
client MAY use the three-dimensional position, and servers MAY
interpret a three-dimensional position as a two-dimensional
position by ignoring the altitude value. A <Point> element is not
placed into a <serviceBoundary> element.
Point: 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.
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.
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.
Circle:
The <Circle> element is described in Section 5.2.3 of [13].
Circle: The <Circle> element is described in Section 5.2.3 of [13].
Ellipse:
The <Ellipse> element is described in Section 5.2.4 of [13].
Ellipse: The <Ellipse> element is described in Section 5.2.4 of [13].
ArcBand:
The <ArcBand> element is described in Section 5.2.5 of [13].
ArcBand: The <ArcBand> element is described in Section 5.2.5 of [13].
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).
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).
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
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
Hardie, et al. Standards Track [Page 30] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 30] RFC 5222 LoST August 2008
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.
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.
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.
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.
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.
12.3. Basic Civic Profile
12.3. Basic Civic Profile
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.
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.
Servers use this profile by placing a <civicAddress> element, defined in [10], within the <serviceBoundary> element.
Servers use this profile by placing a <civicAddress> element, defined in [10], within the <serviceBoundary> element.
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.
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.
Hardie, et al. Standards Track [Page 31] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 31] RFC 5222 LoST August 2008
13. Errors, Warnings, and Redirects
13. Errors, Warnings, and Redirects
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.
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.
13.1. Errors
13.1. Errors
LoST defines a pattern for errors, defined as <errors> elements in the Relax NG schema. This pattern defines a 'message' attribute containing human-readable text and an 'xml:lang' attribute denoting the language of the human-readable text. One or more such error elements are contained in the <errors> element.
LoST 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.
The following errors follow this basic pattern:
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 The server could not parse or otherwise understand a request, e.g., because the XML was malformed.
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.
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 The server could not satisfy a request due to misconfiguration or other operational and non-protocol-related reasons.
locationProfileUnrecognized
None of the profiles in the request were recognized by the server
(see Section 12).
locationProfileUnrecognized None of the profiles in the request were recognized by the server (see Section 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 The geodetic or civic location in the request was invalid. For example, the longitude or latitude values fall outside the acceptable ranges.
Hardie, et al. Standards Track [Page 32] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 32] RFC 5222 LoST August 2008
SRSInvalid
The spatial reference system (SRS) contained in the location
element was not recognized or does not match the location profile.
SRSInvalid The spatial reference system (SRS) contained in the location element was not recognized or does not match the location profile.
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.
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 The server could not find an answer to the query.
serverError
An answer was received from another LoST server, but it could not
be parsed or otherwise understood. This error occurs only for
recursive queries.
serverError An answer was received from another LoST server, but it could not be parsed or otherwise understood. This error occurs only for recursive queries.
serverTimeout
A time out occurred before an answer was received.
serverTimeout A time out occurred before an answer was received.
serviceNotImplemented
The requested service URN is not implemented and no substitution
was available.
serviceNotImplemented The requested service URN is not implemented and no substitution was available.
An example is below:
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 version="1.0" encoding="UTF-8"?> <errors xmlns="urn:ietf:params:xml:ns:lost1" source="resolver.example"> <internalError message="Software bug." xml:lang="en"/> </errors>
Figure 17: Example of an error response
Figure 17: Example of an error response
Hardie, et al. Standards Track [Page 33] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 33] RFC 5222 LoST August 2008
13.2. Warnings
13.2. Warnings
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.
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.
This version of the specification defines the following warnings:
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 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.
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.
サーバが<findService>を実現させることができなかったとき、<serviceSubstitution>要素が返されるかもしれないserviceSubstitutionは与えられたサービスのためにURNを要求します。 例えば、ウルグアイの位置への'つぼ:サービス:sos.police'サービスURNとの<findService>要求で、ウルグアイがサブサービス警察、炎、および救急車を利用しないので、LoSTサービスは'つぼ:サービス:sos'サービスURNのためのマッピングを返すかもしれません。 この警告を返すなら、応答における<サービス>要素はマッピングを示すサービスURNの情報を提供します。
defaultMappingReturned
The <defaultMappingReturned> element MAY be returned when a server
was not able to fulfill a <findService> request for a given
location but is able to respond with a default URI. For example,
a nearby PSAP may be returned.
サーバであるときに<defaultMappingReturned>要素が返されるかもしれないdefaultMappingReturnedは与えられた位置を求める<findService>要求を実現させることができませんでしたが、デフォルトURIで応じることができます。 例えば、近くのPSAPを返すかもしれません。
Hardie, et al. Standards Track [Page 34] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[34ページ]RFC5222
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><findServiceResponse xmlnsが等しい、「「「><マッピングは=を吐き出す」という http://www.opengis.net/ 2007-01-01T01:44:33Z」つぼ:ietf:params:xml:ナノ秒:lost1" xmlns:p2=lastUpdatedは「2006-11-01 T01:00:00Z」ソース="authoritative.example"sourceId=「fb8ed888433343b7b27865aeb38f3a99"><displayName xml: lang=」アン「>ニューヨーク市警</displayName><サービス>つぼ:サービス:sos」と等しいです; 警察の</サービス><serviceBoundaryが=の輪郭を描く、「測地学の2d「><p2: 多角形srsName=」つぼ: ogc: クール:、:、」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>一口: nypd@example.com 、lt;、uri/911</serviceNumber></マッピング><警告><serviceNumber>ソース=「正式です」; 与えられた位置にPSAPを決定できない「><defaultMappingReturnedメッセージ=」という例。 「使用デフォルトPSAP」xml: langはソース="authoritative.example"/></経路></findServiceResponse>を通したソース="resolver.example"/><を通して「アン」/></警告><経路><と等しいです。
Figure 18: Example of a warning response
図18: 警告応答に関する例
Hardie, et al. Standards Track [Page 35] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[35ページ]RFC5222
13.3. Redirects
13.3. 向け直します。
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.
<の再直接の>要素を使用して、querierが別のサーバに質問を向け直すはずであるのを示しながら、LoSTサーバは反応できます。 要素は、次に、また、'ソース'として再直接の応答の理由がわかる再直接の応答を生成したサーバを示す属性と'メッセージ'属性に連絡しながら、LoSTのアプリケーションのユニークなストリング(セクション4を見る)を示すクライアントSHOULDがある'目標'属性を含んでいます。 反復クエリーの間、<の再直接の>応答を受けるサーバは、それがリダイレクションに続きたいか、または単に上流のquerierへの応答を返したがっているかどうか決めることができます。 向け直された質問を扱うサーバによって返された応答における「期限が切れ」値は時間を新しい質問が必要であるかもしれない最も前半示します(セクション5.2を見てください)。 指示されていて、同じくらいのための質問はその時以前再直接へのサーバに位置とサービスSHOULD NOTをtupleします。
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"/>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>の<の再直接のxmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:lost1"目標="eastpsap.example"ソース="westpsap.example"メッセージは「私たちは. 」 xmlの上で一時失敗しました: langは「アン」/>と等しいこと」と等しいです。
Figure 19: Example of a redirect response
図19: 再直接の応答に関する例
14. LoST Transport: HTTP
14. 無くなっている輸送: HTTP
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過剰TLSの上でHTTPとLoSTの上でLoSTの使用を定義します。 クライアントとサーバ開発者はRFC2616HTTP施設の全面的な支援が予想されるのを思い出させられています。 LoSTクライアントかサーバがベースとして利用可能なサーバかクライアントコードを使用するよりむしろHTTPを再実装するなら、慎重な注意を最大限のインターオペラビリティに向けなければなりません。 他の移送機構は将来のドキュメントに残されます。 利用可能な移送機構はLoST U-NAPTRアプリケーションの使用目的で決定します。 content type指示をサポートするプロトコルでは、LoSTはメディアタイプアプリケーション/無くなっている+xmlを使用します。
When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP POST method. The HTTP request MUST use the Cache-Control response directive "no-cache" to disable HTTP-level caching even by caches that have been configured to return stale responses to client requests.
HTTP[3]とHTTP過剰TLS[4]を使用するとき、LoST要求はHTTPポストメソッドを使用します。 HTTP要求は、クライアント要求への聞き古した応答を返すために構成されたキャッシュさえによるHTTPレベルキャッシュを無効にするのにCache-操舵応答の指示の「キャッシュがありません」を使用しなければなりません。
Hardie, et al. Standards Track [Page 36] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[36ページ]RFC5222
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.
LoST警告か誤りを示すものを含むすべてのLoST応答が2xx応答、通常200(OK)で運ばれます。 キャッシュ指示を無視するHTTPキャッシュは他の2xx応答(特に203(非信頼できる情報))を返すかもしれません。 3xx、4xx、および5xx HTTP応答コードは、HTTP要求自体が失敗したか、または向け直されたのを示します。 これらの応答はどんなLoST XML要素も含んでいません。 3xx応答が異なっている、向け直す、それはセクション13.3で説明されます。 LoSTサーバが要求を処理した後にセクション13.3における再直接の操作は起こります。 一般、LoSTサーバが再直接であったならHTTP層がセクション13.3で説明されるようにどこで意志を向け直すかは、特定のサービスに特定であるか、LoSTサーバによる他の処理の結果であるかもしれません。
The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed above.
上で議論するようにLoSTサーバー名からU-NAPTRアプリケーションでHTTP URLを得ます。
15. Relax NG Schema
15. NG図式を寛げてください。
This section provides the Relax NG schema used by the LoST protocol in the compact form. The verbose form is included in Appendix A.
このセクションはコンパクト形のLoSTプロトコルによって使用されるRelax NG図式を提供します。 冗長なフォームはAppendix Aに含まれています。
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
名前空間=" http://relaxng.org/ns/compatibility/annotations/1.0 "デフォルト名前空間ns1=「つぼ:ietf:params:xml:ナノ秒: lost1"」
## ## Location-to-Service Translation (LoST) Protocol
## ## 位置からサービスへの翻訳(失われている)プロトコル
## ## A LoST XML instance has three request types, each with ## a corresponding response type: find service, list services, ## and get service boundary. ## start = findService | listServices | listServicesByLocation | getServiceBoundary | findServiceResponse | listServicesResponse | listServicesByLocationResponse | getServiceBoundaryResponse | errors | redirect
## ## 3はLoST XMLインスタンスからタイプを要求して、##、があるそれぞれが対応する応答タイプです: 職に就いてください、そして、サービス、##、を記載してください、そして、サービス境界を得てください。 ## =findServiceを始動してください。| listServices| listServicesByLocation| getServiceBoundary| findServiceResponse| listServicesResponse| listServicesByLocationResponse| getServiceBoundaryResponse| 誤り| 再直接
##
## The queries.
##
div {
## ## 質問。 ## div
Hardie, et al. Standards Track [Page 37] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[37ページ]RFC5222
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が: 論理演算子>>a: defaultValue「偽」をxsdするか、serviceBoundaryを結果と考えてください、(「参照」| 「値」)>>a: defaultValue「参照」(属性リカーシブは: 論理演算子>>a: defaultValue「偽」をxsdします); listServicesが要素listServices commonRequestPatternと等しい、listServicesByLocationが要素listServicesByLocationと等しい、requestLocation、commonRequestPattern、属性リカーシブが: 論理演算子>>a: defaultValue「本当」をxsdするか、getServiceBoundaryが要素getServiceBoundaryと等しい、serviceBoundaryKey、extensionPoint
##
## The responses.
##
div {
findServiceResponse =
element findServiceResponse {
mapping+, locationValidation?, commonResponsePattern, locationUsed
}
listServicesResponse =
element listServicesResponse { serviceList, commonResponsePattern }
listServicesByLocationResponse =
element listServicesByLocationResponse {
serviceList, commonResponsePattern, locationUsed
}
getServiceBoundaryResponse =
element getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern
}
}
## ## 応答。 ## divfindServiceResponseが+、locationValidation?、commonResponsePattern、locationUsedを写像する要素findServiceResponseと等しい、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=経路--、extensionPoint
Hardie, et al. Standards Track [Page 38] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[38ページ]RFC5222
}
}
##
## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
}
## ## 応答に共通のパターン。 ## divextensionPoint、commonResponsePatternは警告*、経路と等しいです。
##
## Location in Requests
##
div {
requestLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
## ## Requests##divの位置requestLocationが要素位置と等しい、locationInformation、属性イドが: トークンをxsdする、+
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
## ## 位置情報##のdivxsd: locationInformation=extensionPoint+、属性プロフィールNMTOKEN?
##
## Service Boundary
##
div {
serviceBoundary = element serviceBoundary { locationInformation }+
}
## ## サービスBoundary##divserviceBoundaryが要素serviceBoundary locationInformationと等しい、+
##
## Service Boundary Reference
##
div {
serviceBoundaryReference =
element serviceBoundaryReference {
source, serviceBoundaryKey, extensionPoint
}
serviceBoundaryKey = attribute key { xsd:token }
}
## ## サービスBoundary Reference##divserviceBoundaryReferenceが要素serviceBoundaryReferenceと等しい、ソース、serviceBoundaryKey、extensionPoint、serviceBoundaryKey=属性はxsd: トークンを合わせます。
##
##
Hardie, et al. Standards Track [Page 39] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[39ページ]RFC5222
## Path -
## Contains a list of via elements -
## places through which information flowed
##
div {
path =
element path {
element via { source, extensionPoint }+
}
}
## 経路--aが要素で記載する##Contains--情報が##divに流れた##場所経路=要素経路、ソース、extensionPointを通した要素、+
##
## Location Used
##
div {
locationUsed =
element locationUsed {
attribute id { xsd:token }
}?
}
## ## 位置Used##のdiv=要素locationUsedをlocationUsedした、属性イドは: トークンをxsdしますか?
##
## Expires pattern
##
div {
expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}
## ## パターン##divを吐き出します。期限が切れる、=属性はxsd: dateTime| 「キャッシュがありません」| 「満了がありません」を吐き出します。
##
## A QName list
##
div {
qnameList = list { xsd:QName* }
}
## ## QNameリスト##divqnameList=はxsd: QName*を記載します。
##
## A location-to-service mapping.
##
div {
mapping =
element mapping {
element displayName {
xsd:string,
attribute xml:lang { xsd:language }
}*,
service,
(serviceBoundary | serviceBoundaryReference)?,
## ## 位置からサービス対応表。 ## div、マッピング=要素マッピング、要素displayName、属性xml: xsd: ストリング、langが: 言語をxsdする、*、サービス、(serviceBoundary| serviceBoundaryReference)?
Hardie, et al. Standards Track [Page 40] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[40ページ]RFC5222
element uri { xsd:anyURI }*,
element serviceNumber {
xsd:token { pattern = "[0-9*#]+" }
}?,
extensionPoint,
expires,
attribute lastUpdated { xsd:dateTime },
source,
attribute sourceId { xsd:token },
message
}
}
要素はxsd: anyURIをuriします。*要素serviceNumberが: トークンパターン=「[0-9*#]+」をxsdするか、extensionPoint、期限が切れる、xsd: ソース、属性lastUpdatedは: dateTimeをxsdして、属性sourceIdはトークンです、メッセージ }
##
## Location validation
##
div {
locationValidation =
element locationValidation {
element valid { qnameList }?,
element invalid { qnameList }?,
element unchecked { qnameList }?,
extensionPoint
}
}
## ## 位置合法化##のdivlocationValidationが要素locationValidationと等しい、要素の有効なqnameList--、要素の無効のqnameList--、要素抑制されないqnameList?、extensionPoint
##
## Errors and Warnings Container.
##
div {
exceptionContainer =
(badRequest?
& internalError?
& serviceSubstitution?
& defaultMappingReturned?
& forbidden?
& notFound?
& loop?
& serviceNotImplemented?
& serverTimeout?
& serverError?
& locationInvalid?
& locationProfileUnrecognized?),
extensionPoint,
source
errors = element errors { exceptionContainer }
warnings = element warnings { exceptionContainer }
}
## ## 誤りと警告コンテナ。 ## div{ exceptionContainer=(最もbadRequest? internalError-- serviceSubstitution-- defaultMappingReturned-- 禁制ですか? notFound-- 輪-- serviceNotImplemented-- serverTimeout-- serverError-- locationInvalid-- locationProfileUnrecognized--), extensionPoint、ソース誤り=要素誤りexceptionContainer、警告は要素警告exceptionContainerと等しいです。
Hardie, et al. Standards Track [Page 41] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[41ページ]RFC5222
##
## Basic Exceptions
##
div {
## ## 基本的なExceptions##div
##
## Exception pattern.
##
basicException = message, extensionPoint
badRequest = element badRequest { basicException }
internalError = element internalError { basicException }
serviceSubstitution = element serviceSubstitution { basicException }
defaultMappingReturned =
element defaultMappingReturned { basicException }
forbidden = element forbidden { basicException }
notFound = element notFound { basicException }
loop = element loop { basicException }
serviceNotImplemented =
element serviceNotImplemented { basicException }
serverTimeout = element serverTimeout { basicException }
serverError = element serverError { basicException }
locationInvalid = element locationInvalid { basicException }
locationValidationUnavailable =
element locationValidationUnavailable { basicException }
locationProfileUnrecognized =
element locationProfileUnrecognized {
attribute unsupportedProfiles { xsd:NMTOKENS },
basicException
}
}
## ## 例外パターン。 ## basicExceptionはメッセージと等しいです; extensionPoint badRequestが要素badRequest basicExceptionと等しい、internalErrorがdefaultMappingReturned=要素defaultMappingReturned basicExceptionが要素と等しいのを禁じるserviceSubstitution=要素serviceSubstitution basicExceptionが要素輪のbasicExceptionと等しいのをnotFound=要素notFound basicExceptionが輪にするbasicExceptionを禁じる要素internalError basicExceptionと等しい、serviceNotImplemented=要素; serviceNotImplemented basicException、serverTimeoutが要素serverTimeout basicExceptionと等しい、serverErrorが要素serverError basicExceptionと等しい、locationInvalidが要素locationInvalid basicExceptionと等しい、locationValidationUnavailableが要素locationValidationUnavailable basicExceptionと等しい、locationProfileUnrecognizedが要素locationProfileUnrecognizedと等しい、属性unsupportedProfilesは: NMTOKENSをxsdします、basicException
##
## Redirect.
##
div {
## ## 向け直します。 ## div
##
## Redirect pattern
##
redirect =
element redirect {
attribute target { appUniqueString },
source,
message,
extensionPoint
}
}
## ## 再直接のパターン##再直接の=要素はappUniqueString(ソース)が通信させる属性目標、extensionPointを向け直します。
Hardie, et al. Standards Track [Page 42] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[42ページ]RFC5222
##
## 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メッセージ=(属性xml: xsd: トークン、langが: 言語をxsdするという属性メッセージ)--xsd: 要素サービス=サービスanyURI--appUniqueStringがxsd: トークンと等しい、=を型に基づいて作ってください、「[1zA-Z0-9の\、-、]、+ \) + [a-zA-Z0-9]+、」、ソース=属性ソースappUniqueString、serviceList=要素serviceListはxsd: anyURI*を記載します。
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
## ## 他の##名前空間におけるschemasからの要素の包含のためのパターン。 ## div
##
## Any element not in the LoST namespace.
##
notLost = element * - (ns1:* | ns1:*) { anyElement }
## ## LoST名前空間でないのにおけるどんな要素。 ## 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* }
## ## 未来拡大##(他の名前空間からの要素)の##、を加えることができるポイント。 ## extensionPointはnotLost*と等しいです。
Figure 20: RelaxNG schema
図20: RelaxNG図式
Hardie, et al. Standards Track [Page 43] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[43ページ]RFC5222
16. Internationalization Considerations
16. 国際化問題
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.
LoSTプロトコルはマシンから機械コミュニケーションのためにほとんど意味されます。 そういうものとして、要素の大部分は直接人間の消費で意味されなかったトークンです。 これらのトークンがエンドユーザに提示されるなら、何らかのローカライズが、起こる必要があるかもしれません。 <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.
LoSTは、XMLを使用することで情報交換します。 すべてのXMLプロセッサがUTF-8とUTF-16 encodingsを理解するのに必要です、そして、したがって、すべてのLoSTクライアントとサーバはUTF-8とUTF-16がXMLをコード化したのを理解しなければなりません。 さらに、LoSTサーバとクライアントはUTF-8かUTF-16以外のencodingsでXMLをコード化してはいけません。
17. IANA Considerations
17. IANA問題
17.1. U-NAPTR Registrations
17.1. U-NAPTR登録証明書
This document registers the following U-NAPTR application service tag:
このドキュメントは以下のU-NAPTRアプリケーション・サービスタグを登録します:
Application Service Tag: LoST
アプリケーション・サービスタグ: 失われています。
Defining Publication: The specification contained within this
document.
公表を定義します: このドキュメントの中に含まれた仕様。
This document registers the following U-NAPTR application protocol tags:
このドキュメントは以下のU-NAPTRアプリケーション・プロトコルタグを登録します:
o Application Protocol Tag: http
o アプリケーション・プロトコルタグ: http
Defining Publication: RFC 2616 [3]
公表を定義します: RFC2616[3]
o Application Protocol Tag: https
o アプリケーション・プロトコルタグ: https
Defining Publication: RFC 2818 [4]
公表を定義します: RFC2818[4]
17.2. Content-Type Registration for 'application/lost+xml'
17.2. 'アプリケーション/は+ xmlをなくした'コンテントタイプ登録
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [7] and guidelines in RFC 3023 [5].
RFC4288[7]とガイドラインの手順によると、この仕様はRFC3023[5]で新しいMIMEの種類の登録を要求します。
Hardie, et al. Standards Track [Page 44] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[44ページ]RFC5222
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: lost+xml
MIME「副-タイプ」は以下を命名します。 無くなっている+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: charset
Indicates the character encoding of enclosed XML.
任意のパラメタ: charset Indicates、同封のXMLの文字符号化。
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [5], Section 3.2.
問題をコード化します: 文字符号化によるXML(8ビットのキャラクタを雇うことができる)が使用した用途。 RFC3023[5]、セクション3.2を見てください。
Security considerations: This content type is designed to carry LoST
protocol payloads.
セキュリティ問題: このcontent typeは、LoSTプロトコルペイロードを運ぶように設計されています。
Interoperability considerations: None
相互運用性問題: なし
Published specification: RFC 5222
広められた仕様: RFC5222
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'
マッキントッシュファイルの種類コード: 'テキスト'
Personal and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@nsn.com
詳細のためのパーソナルとEメールアドレス: ハンネス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>.
以下を書いてください。 この仕様がメーリングリスト address <ecrit@ietf.org があるIETF ECRITワーキンググループの仕事項目である、gt。
Change controller:
The IESG <iesg@ietf.org>
コントローラを変えてください: IESG <iesg@ietf.org 、gt。
Hardie, et al. Standards Track [Page 45] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[45ページ]RFC5222
17.3. LoST Relax NG Schema Registration
17.3. 失われて、NG図式登録を寛げてください。
URI: urn:ietf:params:xml:schema:lost1
URI: つぼ: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図式を弛緩してください: 登録されるべきRelax NG図式はセクション15に含まれています。 最初の系列はそうです。
default namespace = "urn:ietf:params:xml:ns:lost1"
デフォルト名前空間=「つぼ:ietf:params:xml:ナノ秒: lost1"」
and its last line is
そして、最終ラインはそうです。
}
}
17.4. LoST Namespace Registration
17.4. 無くなっている名前空間登録
URI: urn:ietf:params:xml:ns:lost1
URI: つぼ:ietf:params:xml:ナノ秒: 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バージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「><html xmlnsが「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」内容=と等しい、「テキスト/html;、charset=iso8859、1インチ、/><タイトル>は無くなっている</h1><h2>つぼのための名前空間</タイトル></ヘッド><ボディー><h1>名前空間を失いました:、」; ietf:params:xml:ナノ秒:lost1</h2><p>See<a hrefが等しい、「 http://www.rfc-editor.org/rfc/rfc5222.txt 「>RFC5222</a>。」; </p></ボディー></html>エンド
Hardie, et al. Standards Track [Page 46] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[46ページ]RFC5222
17.5. LoST Location Profile Registry
17.5. 無くなっているロケーション・プロフィール登録
This document creates a registry of location profile names for the LoST protocol. Profile names are XML tokens. This registry will operate in accordance with RFC 5226 [2], Standards Action.
このドキュメントはLoSTプロトコルのためにロケーション・プロフィール名の登録を作成します。 プロフィール名はXMLトークンです。 Standards Action、RFC5226[2]によると、この登録は作動するでしょう。
geodetic-2d:
Defined in Section 12.2.
測地学の2d: セクション12.2では、定義されます。
civic:
Defined in Section 12.3.
都市: セクション12.3では、定義されます。
18. Security Considerations
18. セキュリティ問題
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)を実装しなければならないTransport Layer Security、およびSHOULDを避けるには、使用されてください。 使用はサーバへのクライアントの質問とサーバの中の質問のためのRECOMMENDEDです。 この後者の推薦はLoSTサーバをキャッシュするのに与えられた答えを取り替えることによってLoSTキャッシュ中毒攻撃を避けるのを助けることです。
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で説明される使用はRECOMMENDEDです。 潜在的に悪意があるLoSTサーバからさえどんな答えも得るのが接続を終えるより好まれるときだけ(その結果、全くどんな答えも得ません)、攻撃者がサーバ身元確認を省略するのにLoSTサーバのふりをすることができるので、このアプローチは使用されるべきです。 サーバ証明書に対する比較というホスト名はNAPTR解決に入力されるように使用されるDNS名ではなく、URIでホスト名です。
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アルゴリズム決議に多くの入力を見そうであるので、このアプローチは選ばれませんでした。 この場合、LoSTサーバによって提供された証明書に対するNAPTR解決に入力をチェックするのは非実用的でしょう、それを使用する組織のリストが急激な変化を条件として大きくて、LoSTサーバオペレータにとって、未知であるだろうというときに。
Hardie, et al. Standards Track [Page 47] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[47ページ]RFC5222
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.
サーバのアイデンティティの使用はDNSのベースの攻撃の可能性を残しています、NAPTR記録が攻撃者によって変更されるとき。 攻撃は再帰的なネームサーバで例えばクライアントと、再帰的なネームサーバと、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 Security(DNSSEC)[20]を使用できます。 DNSSECが不完全に配布される間、ユーザはリスクを意識しているべきです、特に地方の再帰的なネームサーバ、またはクライアントと地方の再帰的なネームサーバの間のネットワークが信頼できるのは考えられないところで彼らが環境におけるNAPTR記録を要求しているとき。
LoST deployments that are unable to use DNSSEC and unwilling to trust DNS resolution without DNSSEC cannot use the NATPR-based discovery of LoST servers as is. When suitable configuration mechanisms are available, one possibility is to configure the LoST server URIs (instead of the domain name to be used for NAPTR resolution) directly. Future specifications for applying LoST in non-emergency services may also specify additional discovery mechanisms and name matching semantics.
DNSSECを使用できないでDNSSECなしでDNS解決を信じたがっていないLoST展開はそのままでLoSTサーバのNATPRベースの発見を使用できません。 適当な構成メカニズムが利用可能であるときに、1つの可能性は直接、LoSTサーバURI(NAPTR解決に使用されるべきドメイン名の代わりに)を構成することです。 また、非緊急サービスでLoSTを適用するための将来の仕様は追加発見メカニズムと名前マッチング意味論を指定するかもしれません。
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.
一般に、LoSTサーバは、マッピング質問を提示するクライアントに、認証するか、または権限を与える必要はないでしょう。 そうするなら、HTTPなどのように基本的な基本的な移送機構とダイジェスト認証の認証は使用されるかもしれません。 基本認証SHOULD、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の非非常時のサービス用途における脅威とセキュリティ要件はここで説明されたものとかなり異なっているかもしれません。 例えば、攻撃者は特定のサービスプロバイダーにユーザを向けた戻っているサービスマッピング情報で通貨の利益を求めるかもしれません。 新しい関係、脅威、その文脈への詳細が引き受けられるべきであるという要件、および適切な緩和のときにされた決定の徹底的な分析でLoSTを配布する前に。
19. Acknowledgments
19. 承認
We would like to the thank the following working group members for the detailed review of previous LoST document versions:
私たち、詳細のための以下のワーキンググループのメンバーが見直す前のLoSTの感謝はバージョンを記録したがっています:
o Martin Thomson (Review July 2006)
o マーチン・トムソン(レビュー2006年7月)
o Jonathan Rosenberg (Review July 2006)
o ジョナサン・ローゼンバーグ(レビュー2006年7月)
Hardie, et al. Standards Track [Page 48] RFC 5222 LoST August 2008
ハーディー、他 2008年8月になくされた標準化過程[48ページ]RFC5222
o Leslie Daigle (Review September 2006)
o レスリーDaigle(レビュー2006年9月)
o Shida Schubert (Review November 2006)
o 志太シューベルト(レビュー2006年11月)
o Martin Thomson (Review December 2006)
o マーチン・トムソン(レビュー2006年12月)
o Barbara Stark (Review January 2007)
o バーバラ・スターク(レビュー2007年1月)
o Patrik Faltstrom (Review January 2007)
o パトリク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)
o 志太シューベルト(レビュー2007年2月)
o James Winterbottom (Review July 2007)
o James Winterbottom (Review July 2007)
o Karl Heinz Wolf (Review May and June 2007)
o Karl Heinz Wolf (Review May and June 2007)
We would also like to thank the following working group members for their input to selected design aspects of the LoST protocol:
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 Leslie Daigle and Martin Thomson (DNS-based LoST discovery procedure)
o John Schnizlein (authoritive LoST answers)
o John Schnizlein (authoritive LoST answers)
o Rohan Mahy (display names)
o Rohan Mahy (display names)
o James Polk (error handling)
o James Polk (error handling)
o Ron Watro and Richard Barnes (expiry of cached data)
o Ron Watro and Richard Barnes (expiry of cached data)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James
Winterbottom (indication of PSAP confidence level)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James Winterbottom (indication of PSAP confidence level)
o Martin Thomson (service boundary references)
o Martin Thomson (service boundary references)
o Martin Thomson (service URN in LoST response message)
o Martin Thomson (service URN in LoST response message)
o Clive D.W. Feather, Martin Thomson (validation functionality)
o Clive D.W. Feather, Martin Thomson (validation functionality)
Hardie, et al. Standards Track [Page 49] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 49] RFC 5222 LoST August 2008
o Roger Marshall (PSAP preference in LoST response)
o Roger Marshall (PSAP preference in LoST response)
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 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 Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson,
Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list
services functionality)
o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson, Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list services functionality)
o Martin Thomson, Michael Hammer (mapping of services)
o Martin Thomson, Michael Hammer (mapping of services)
o Shida Schubert, James Winterbottom, Keith Drage (default service
URN)
o Shida Schubert, James Winterbottom, Keith Drage (default service URN)
o Otmar Lendl (LoST aggregation)
o Otmar Lendl (LoST aggregation)
o Tom Taylor (terminology)
o Tom Taylor (terminology)
Klaus Darilion and Marc Linsner provided miscellaneous input to the design of the protocol. Finally, we would like to thank Brian Rosen, who participated in almost every discussion thread.
Klaus Darilion 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.
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:
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:
o Wonsang Song
o Wonsang Song
o Jong-Yul Kim
o Jong-Yul Kim
o Anna Makarowska
o Anna Makarowska
o Krzysztof Rzecki
o Krzysztof Rzecki
o Blaszczyk Piotr
o Blaszczyk Piotr
We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault, and Tim Polk for their IESG review comments. Blocking IESG comments were also received from Pasi Eronen (succeeding Sam Hartman's review) and Cullen Jennings. Adjustments have been made to several pieces of text to satisfy these requests for changes, most notably in the Security Considerations and in the discussion of redirection in the presence of overlapping coverage areas.
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.
Hardie, et al. Standards Track [Page 50] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 50] RFC 5222 LoST August 2008
20. References
20. References
20.1. Normative References
20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Daigle, L., "Domain-Based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)",
RFC 4848, April 2007.
[8] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for Presence Information Data Format Location Object
(PIDF-LO)", RFC 5139, February 2008.
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
"Geographic information - Geography Markup Language (GML)", OGC
Standard OpenGIS 03-105r1, April 2004.
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OGC Standard OpenGIS 03-105r1, April 2004.
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification , December 2006.
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification , December 2006.
Hardie, et al. Standards Track [Page 51] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 51] RFC 5222 LoST August 2008
20.2. Informative References
20.2. Informative References
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", Work in Progress, February 2008.
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Work in Progress, February 2008.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008.
[17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012,
January 2008.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", Work in Progress, September 2007.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", Work in Progress, September 2007.
[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[21] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Work
in Progress, February 2008.
[21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, February 2008.
[22] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
[22] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/
RelaxNG>.
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ RelaxNG>.
Hardie, et al. Standards Track [Page 52] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 52] RFC 5222 LoST August 2008
[25] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008.
[25] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
Hardie, et al. Standards Track [Page 53] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 53] RFC 5222 LoST August 2008
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?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" encoding="UTF-8"?> <grammar ns="urn:ietf:params:xml:ns:lost1" xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
Location-to-Service Translation (LoST) Protocol
<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>
A LoST XML instance has three request types, each with a corresponding response type: find service, list services, and get service boundary. </a:documentation> <choice> <ref name="findService"/> <ref name="listServices"/> <ref name="listServicesByLocation"/> <ref name="getServiceBoundary"/> <ref name="findServiceResponse"/> <ref name="listServicesResponse"/> <ref name="listServicesByLocationResponse"/> <ref name="getServiceBoundaryResponse"/> <ref name="errors"/> <ref name="redirect"/> </choice> </start>
<div>
<a:documentation>
The queries.
</a:documentation>
<div> <a:documentation> The queries. </a:documentation>
<define name="findService">
<element name="findService">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="validateLocation">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="serviceBoundary">
<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">
Hardie, et al. Standards Track [Page 54] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 54] RFC 5222 LoST August 2008
<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>
<choice> <value>reference</value> <value>value</value> </choice> <a:defaultValue>reference</a:defaultValue> </attribute> </optional> <optional> <attribute name="recursive"> <data type="boolean"/> <a:defaultValue>false</a:defaultValue> </attribute> </optional> </element> </define>
<define name="listServices">
<element name="listServices">
<ref name="commonRequestPattern"/>
</element>
</define>
<define name="listServices"> <element name="listServices"> <ref name="commonRequestPattern"/> </element> </define>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServicesByLocation"> <element name="listServicesByLocation"> <ref name="requestLocation"/> <ref name="commonRequestPattern"/> <optional> <attribute name="recursive"> <data type="boolean"/> <a:defaultValue>true</a:defaultValue> </attribute> </optional> </element> </define>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<define name="getServiceBoundary"> <element name="getServiceBoundary"> <ref name="serviceBoundaryKey"/> <ref name="extensionPoint"/> </element> </define> </div>
<div>
<a:documentation>
The responses.
</a:documentation>
<div> <a:documentation> The responses. </a:documentation>
Hardie, et al. Standards Track [Page 55] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 55] RFC 5222 LoST August 2008
<define name="findServiceResponse">
<element name="findServiceResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<optional>
<ref name="locationValidation"/>
</optional>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="findServiceResponse"> <element name="findServiceResponse"> <oneOrMore> <ref name="mapping"/> </oneOrMore> <optional> <ref name="locationValidation"/> </optional> <ref name="commonResponsePattern"/> <ref name="locationUsed"/> </element> </define>
<define name="listServicesResponse">
<element name="listServicesResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
</element>
</define>
<define name="listServicesResponse"> <element name="listServicesResponse"> <ref name="serviceList"/> <ref name="commonResponsePattern"/> </element> </define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="listServicesByLocationResponse"> <element name="listServicesByLocationResponse"> <ref name="serviceList"/> <ref name="commonResponsePattern"/> <ref name="locationUsed"/> </element> </define>
<define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse">
<ref name="serviceBoundary"/>
<ref name="commonResponsePattern"/>
</element>
</define>
</div>
<define name="getServiceBoundaryResponse"> <element name="getServiceBoundaryResponse"> <ref name="serviceBoundary"/> <ref name="commonResponsePattern"/> </element> </define> </div>
<div>
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<div> <a:documentation> A pattern common to some of the queries. </a:documentation>
<define name="commonRequestPattern">
<ref name="service"/>
<optional>
<ref name="path"/>
<define name="commonRequestPattern"> <ref name="service"/> <optional> <ref name="path"/>
Hardie, et al. Standards Track [Page 56] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 56] RFC 5222 LoST August 2008
</optional>
<ref name="extensionPoint"/>
</define>
</div>
</optional> <ref name="extensionPoint"/> </define> </div>
<div>
<a:documentation>
A pattern common to responses.
</a:documentation>
<div> <a:documentation> A pattern common to responses. </a:documentation>
<define name="commonResponsePattern">
<zeroOrMore>
<ref name="warnings"/>
</zeroOrMore>
<ref name="path"/>
<ref name="extensionPoint"/>
</define>
</div>
<define name="commonResponsePattern"> <zeroOrMore> <ref name="warnings"/> </zeroOrMore> <ref name="path"/> <ref name="extensionPoint"/> </define> </div>
<div>
<a:documentation>
Location in Requests
</a:documentation>
<div> <a:documentation> Location in Requests </a:documentation>
<define name="requestLocation">
<oneOrMore>
<element name="location">
<attribute name="id">
<data type="token"/>
</attribute>
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<define name="requestLocation"> <oneOrMore> <element name="location"> <attribute name="id"> <data type="token"/> </attribute> <ref name="locationInformation"/> </element> </oneOrMore> </define> </div>
<div>
<a:documentation>
Location Information
</a:documentation>
<div> <a:documentation> Location Information </a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
<define name="locationInformation"> <oneOrMore> <ref name="extensionPoint"/> </oneOrMore> <optional> <attribute name="profile"> <data type="NMTOKEN"/>
Hardie, et al. Standards Track [Page 57] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 57] RFC 5222 LoST August 2008
</attribute>
</optional>
</define>
</div>
</attribute> </optional> </define> </div>
<div>
<a:documentation>
Service Boundary
</a:documentation>
<div> <a:documentation> Service Boundary </a:documentation>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<define name="serviceBoundary"> <oneOrMore> <element name="serviceBoundary"> <ref name="locationInformation"/> </element> </oneOrMore> </define> </div>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<div> <a:documentation> Service Boundary Reference </a:documentation>
<define name="serviceBoundaryReference">
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source"/>
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
<element name="serviceBoundaryReference"> <ref name="source"/> <ref name="serviceBoundaryKey"/> <ref name="extensionPoint"/> </element> </define>
<define name="serviceBoundaryKey">
<attribute name="key">
<data type="token"/>
</attribute>
</define>
</div>
<define name="serviceBoundaryKey"> <attribute name="key"> <data type="token"/> </attribute> </define> </div>
<div>
<a:documentation>
Path -
Contains a list of via elements -
places through which information flowed
</a:documentation>
<div> <a:documentation> Path - Contains a list of via elements - places through which information flowed </a:documentation>
Hardie, et al. Standards Track [Page 58] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 58] RFC 5222 LoST August 2008
<define name="path">
<element name="path">
<oneOrMore>
<element name="via">
<ref name="source"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
</div>
<define name="path"> <element name="path"> <oneOrMore> <element name="via"> <ref name="source"/> <ref name="extensionPoint"/> </element> </oneOrMore> </element> </define> </div>
<div>
<a:documentation>
Location Used
</a:documentation>
<div> <a:documentation> Location Used </a:documentation>
<define name="locationUsed">
<optional>
<element name="locationUsed">
<attribute name="id">
<data type="token"/>
</attribute>
</element>
</optional>
</define>
</div>
<define name="locationUsed"> <optional> <element name="locationUsed"> <attribute name="id"> <data type="token"/> </attribute> </element> </optional> </define> </div>
<div>
<a:documentation>
Expires pattern
</a:documentation>
<div> <a:documentation> Expires pattern </a:documentation>
<define name="expires">
<attribute name="expires">
<choice>
<data type="dateTime"/>
<value>NO-CACHE</value>
<value>NO-EXPIRATION</value>
</choice>
</attribute>
</define>
</div>
<define name="expires"> <attribute name="expires"> <choice> <data type="dateTime"/> <value>NO-CACHE</value> <value>NO-EXPIRATION</value> </choice> </attribute> </define> </div>
<div>
<a:documentation>
A QName list
</a:documentation>
<div> <a:documentation> A QName list </a:documentation>
Hardie, et al. Standards Track [Page 59] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 59] RFC 5222 LoST August 2008
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<define name="qnameList"> <list> <zeroOrMore> <data type="QName"/> </zeroOrMore> </list> </define> </div>
<div>
<a:documentation>
A location-to-service mapping.
</a:documentation>
<div> <a:documentation> A location-to-service mapping. </a:documentation>
<define name="mapping">
<element name="mapping">
<zeroOrMore>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="service"/>
<optional>
<choice>
<ref name="serviceBoundary"/>
<ref name="serviceBoundaryReference"/>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
<data type="token">
<param name="pattern">[0-9*#]+</param>
</data>
</element>
</optional>
<ref name="extensionPoint"/>
<ref name="expires"/>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<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>
Hardie, et al. Standards Track [Page 60] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 60] RFC 5222 LoST August 2008
<ref name="source"/>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<ref name="source"/> <attribute name="sourceId"> <data type="token"/> </attribute> <ref name="message"/> </element> </define> </div>
<div>
<a:documentation>
Location validation
</a:documentation>
<div> <a:documentation> Location validation </a:documentation>
<define name="locationValidation">
<element name="locationValidation">
<optional>
<element name="valid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="invalid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="unchecked">
<ref name="qnameList"/>
</element>
</optional>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<define name="locationValidation"> <element name="locationValidation"> <optional> <element name="valid"> <ref name="qnameList"/> </element> </optional> <optional> <element name="invalid"> <ref name="qnameList"/> </element> </optional> <optional> <element name="unchecked"> <ref name="qnameList"/> </element> </optional> <ref name="extensionPoint"/> </element> </define> </div>
<div>
<a:documentation>
Errors and Warnings Container.
</a:documentation>
<div> <a:documentation> Errors and Warnings Container. </a:documentation>
<define name="exceptionContainer">
<interleave>
<optional>
<ref name="badRequest"/>
</optional>
<optional>
<define name="exceptionContainer"> <interleave> <optional> <ref name="badRequest"/> </optional> <optional>
Hardie, et al. Standards Track [Page 61] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 61] RFC 5222 LoST August 2008
<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 name="internalError"/> </optional> <optional> <ref name="serviceSubstitution"/> </optional> <optional> <ref name="defaultMappingReturned"/> </optional> <optional> <ref name="forbidden"/> </optional> <optional> <ref name="notFound"/> </optional> <optional> <ref name="loop"/> </optional> <optional> <ref name="serviceNotImplemented"/> </optional> <optional> <ref name="serverTimeout"/> </optional> <optional> <ref name="serverError"/> </optional> <optional> <ref name="locationInvalid"/> </optional> <optional> <ref name="locationProfileUnrecognized"/> </optional> </interleave> <ref name="extensionPoint"/> <ref name="source"/> </define>
<define name="errors">
<element name="errors">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="errors"> <element name="errors"> <ref name="exceptionContainer"/> </element> </define>
<define name="warnings">
<element name="warnings">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="warnings"> <element name="warnings"> <ref name="exceptionContainer"/> </element> </define>
Hardie, et al. Standards Track [Page 62] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 62] RFC 5222 LoST August 2008
</div>
</div>
<div>
<a:documentation>
Basic Exceptions
</a:documentation>
<div> <a:documentation> Basic Exceptions </a:documentation>
<define name="basicException">
<a:documentation>
Exception pattern.
</a:documentation>
<ref name="message"/>
<ref name="extensionPoint"/>
</define>
<define name="basicException"> <a:documentation> Exception pattern. </a:documentation> <ref name="message"/> <ref name="extensionPoint"/> </define>
<define name="badRequest">
<element name="badRequest">
<ref name="basicException"/>
</element>
</define>
<define name="badRequest"> <element name="badRequest"> <ref name="basicException"/> </element> </define>
<define name="internalError">
<element name="internalError">
<ref name="basicException"/>
</element>
</define>
<define name="internalError"> <element name="internalError"> <ref name="basicException"/> </element> </define>
<define name="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="basicException"/>
</element>
</define>
<define name="serviceSubstitution"> <element name="serviceSubstitution"> <ref name="basicException"/> </element> </define>
<define name="defaultMappingReturned">
<element name="defaultMappingReturned">
<ref name="basicException"/>
</element>
</define>
<define name="defaultMappingReturned"> <element name="defaultMappingReturned"> <ref name="basicException"/> </element> </define>
<define name="forbidden">
<element name="forbidden">
<ref name="basicException"/>
</element>
</define>
<define name="forbidden"> <element name="forbidden"> <ref name="basicException"/> </element> </define>
<define name="notFound">
<element name="notFound">
<ref name="basicException"/>
<define name="notFound"> <element name="notFound"> <ref name="basicException"/>
Hardie, et al. Standards Track [Page 63] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 63] RFC 5222 LoST August 2008
</element>
</define>
</element> </define>
<define name="loop">
<element name="loop">
<ref name="basicException"/>
</element>
</define>
<define name="loop"> <element name="loop"> <ref name="basicException"/> </element> </define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicException"/>
</element>
</define>
<define name="serviceNotImplemented"> <element name="serviceNotImplemented"> <ref name="basicException"/> </element> </define>
<define name="serverTimeout">
<element name="serverTimeout">
<ref name="basicException"/>
</element>
</define>
<define name="serverTimeout"> <element name="serverTimeout"> <ref name="basicException"/> </element> </define>
<define name="serverError">
<element name="serverError">
<ref name="basicException"/>
</element>
</define>
<define name="serverError"> <element name="serverError"> <ref name="basicException"/> </element> </define>
<define name="locationInvalid">
<element name="locationInvalid">
<ref name="basicException"/>
</element>
</define>
<define name="locationInvalid"> <element name="locationInvalid"> <ref name="basicException"/> </element> </define>
<define name="locationValidationUnavailable">
<element name="locationValidationUnavailable">
<ref name="basicException"/>
</element>
</define>
<define name="locationValidationUnavailable"> <element name="locationValidationUnavailable"> <ref name="basicException"/> </element> </define>
<define name="locationProfileUnrecognized">
<element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles">
<data type="NMTOKENS"/>
</attribute>
<ref name="basicException"/>
</element>
</define>
</div>
<define name="locationProfileUnrecognized"> <element name="locationProfileUnrecognized"> <attribute name="unsupportedProfiles"> <data type="NMTOKENS"/> </attribute> <ref name="basicException"/> </element> </define> </div>
Hardie, et al. Standards Track [Page 64] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 64] RFC 5222 LoST August 2008
<div>
<a:documentation>
Redirect.
</a:documentation>
<div> <a:documentation> Redirect. </a:documentation>
<define name="redirect">
<a:documentation>
Redirect pattern
</a:documentation>
<element name="redirect">
<attribute name="target">
<ref name="appUniqueString"/>
</attribute>
<ref name="source"/>
<ref name="message"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<define name="redirect"> <a:documentation> Redirect pattern </a:documentation> <element name="redirect"> <attribute name="target"> <ref name="appUniqueString"/> </attribute> <ref name="source"/> <ref name="message"/> <ref name="extensionPoint"/> </element> </define> </div>
<div>
<a:documentation>
Some common patterns.
</a:documentation>
<div> <a:documentation> Some common patterns. </a:documentation>
<define name="message">
<optional>
<group>
<attribute name="message">
<data type="token"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
<define name="message"> <optional> <group> <attribute name="message"> <data type="token"/> </attribute> <attribute name="xml:lang"> <data type="language"/> </attribute> </group> </optional> </define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="service"> <optional> <element name="service"> <data type="anyURI"/> </element> </optional> </define>
Hardie, et al. Standards Track [Page 65] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 65] RFC 5222 LoST August 2008
<define name="appUniqueString">
<data type="token">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
<define name="appUniqueString"> <data type="token"> <param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param> </data> </define>
<define name="source">
<attribute name="source">
<ref name="appUniqueString"/>
</attribute>
</define>
<define name="source"> <attribute name="source"> <ref name="appUniqueString"/> </attribute> </define>
<define name="serviceList">
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI"/>
</zeroOrMore>
</list>
</element>
</define>
</div>
<define name="serviceList"> <element name="serviceList"> <list> <zeroOrMore> <data type="anyURI"/> </zeroOrMore> </list> </element> </define> </div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<div> <a:documentation> Patterns for inclusion of elements from schemas in other namespaces. </a:documentation>
<define name="notLost">
<a:documentation>
Any element not in the LoST namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost1"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="notLost"> <a:documentation> Any element not in the LoST namespace. </a:documentation> <element> <anyName> <except> <nsName ns="urn:ietf:params:xml:ns:lost1"/> <nsName/> </except> </anyName> <ref name="anyElement"/> </element> </define>
<define name="anyElement">
<a:documentation>
<define name="anyElement"> <a:documentation>
Hardie, et al. Standards Track [Page 66] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 66] RFC 5222 LoST August 2008
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>
A wildcard pattern for including any element from any other namespace. </a:documentation> <zeroOrMore> <choice> <element> <anyName/> <ref name="anyElement"/> </element> <attribute> <anyName/> </attribute> <text/> </choice> </zeroOrMore> </define>
<define name="extensionPoint">
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="notLost"/>
</zeroOrMore>
</define>
</div>
<define name="extensionPoint"> <a:documentation> A point where future extensions (elements from other namespaces) can be added. </a:documentation> <zeroOrMore> <ref name="notLost"/> </zeroOrMore> </define> </div>
</grammar>
</grammar>
Figure 21
Figure 21
Appendix B. Examples Online
Appendix B. Examples Online
The XML examples and Relax NG schemas may be found online [24].
The XML examples and Relax NG schemas may be found online [24].
Hardie, et al. Standards Track [Page 67] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 67] RFC 5222 LoST August 2008
Authors' Addresses
Authors' Addresses
Ted Hardie Qualcomm, Inc.
Ted Hardie Qualcomm, Inc.
EMail: hardie@qualcomm.com
EMail: hardie@qualcomm.com
Andrew Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 US
Andrew Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 US
Phone: +1 703 227 9894 EMail: andy@hxr.us
Phone: +1 703 227 9894 EMail: andy@hxr.us
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
Hardie, et al. Standards Track [Page 68] RFC 5222 LoST August 2008
Hardie, et al. Standards Track [Page 68] RFC 5222 LoST August 2008
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
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.
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.
Intellectual Property
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.
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.
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.
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.
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.
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.
Hardie, et al. Standards Track [Page 69]
Hardie, et al. Standards Track [Page 69]
一覧
スポンサーリンク
