RFC 6197 - Location-to-Service Translation (LoST) Service List Boundary Extension 日本語訳

URL : https://tools.ietf.org/html/rfc6197
タイトル : RFC 6197 - 場所・ツー・サービス翻訳（LOST）サービスリスト境界拡張
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                           K. Wolf
Request for Comments: 6197                                        nic.at
Category: Experimental                                        April 2011
ISSN: 2070-1721

Location-to-Service Translation (LoST) Service List Boundary Extension

場所・ツー・サービス翻訳（LOST）サービスリスト境界拡張

Abstract

抽象

Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving.

場所・ツー・サービス翻訳（LOST）は、サービス接触URIにサービス識別子と位置情報をマップします。失われたクライアントが特定の場所のために利用可能なサービスを発見したい場合、それが失われたサーバーに<listServicesByLocation>クエリを実行します。しかし、失われたサーバは、その応答では、コンテキスト情報を提供していません。つまり、それはサービスの返されたリストが有効とみなされる範囲内地理的地域に関する追加情報を提供していません。したがって、この文書は、移動する際に利用可能なサービスの変化に欠落していないクライアントを支援するために、返されたサービスのリストとともにローカルコンテキストを返すサービスリスト境界を定義します。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6197.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6197で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. LoST Extensions .................................................4
      3.1. Extensions to <listServicesByLocation> .....................4
      3.2. Retrieving the <serviceListBoundary> via
           <getServiceListBoundary> ...................................7
      3.3. <serviceListBoundary> ......................................8
      3.4. Implementation Considerations ..............................9
           3.4.1. Server Side .........................................9
           3.4.2. Client Side .........................................9
   4. Security and Privacy Considerations ............................10
   5. IANA Considerations ............................................10
      5.1. Relax NG Schema Registration ..............................10
      5.2. Namespace Registration ....................................13
   6. Acknowledgements ...............................................14
   7. References .....................................................14
      7.1. Normative References ......................................14
      7.2. Informative References ....................................15

1. Introduction

1. はじめに

Since the LoST protocol [RFC5222] employs the Service Boundary concept in order to avoid having clients continuously trying to refresh the mapping of a specific service, a Service List Boundary mechanism provides similar advantages for Service Lists.

失われたプロトコル[RFC5222]は、特定のサービスのマッピングを更新しようとして継続的に顧客を持つ避けるために、サービスの境界概念を採用しているため、サービスリスト境界メカニズムは、サービスリストのために同様の利点を提供します。

Location-based service providers, as well as Public Safety Answering Points (PSAPs), only serve a specific geographic region. Therefore, the LoST protocol defines the Service Boundary, which indicates the service region for a specific service URL. However, not all services are available everywhere. Clients can discover available services for a particular location via the <listServicesByLocation> query in LoST. The LoST server returns a list of services that are available at this particular location, but the server does not provide any additional information about the geographical region within which the returned Service List is considered valid. This may lead to the situation where a client initially discovers all available services via the <listServicesByLocation> query, and then moves to a different location (while refreshing the service mappings), but without noticing the availability of other services. The following imaginary example illustrates the problem for emergency calling:

ロケーションベースのサービスプロバイダだけでなく、公共の安全回答ポイント（のPSAP）は、唯一の特定の地域にサービスを提供します。したがって、失われたプロトコルは、特定のサービスURLのサービス領域を示すサービス境界を画定します。ただし、すべてのサービスがどこでも利用できるわけではありません。クライアントは、失われた中に、<listServicesByLocation>クエリを経由して特定の場所のために利用可能なサービスを発見することができます。失われたサーバは、この特定の場所で利用可能なサービスのリストを返しますが、サーバは返さサービスリストが有効とみなされ、その中地理的地域に関する追加情報を提供していません。これは、クライアントが最初に<listServicesByLocation>クエリを経由して、すべての利用可能なサービスを発見し、その後、（サービスのマッピングをリフレッシュしながら）が、他のサービスの可用性を気付かずに別の場所に移動し、状況につながる可能性があります。以下の架空の例では、緊急呼び出しのための問題を示しています。

The client is powered-up, does location determination (resulting in location A), and performs an initial <listServicesByLocation> query with location A requesting urn:services:sos.

クライアントは、パワーアップされた位置の決意（位置Aで得られた）を行い、そしてURN要求位置Aとの最初の<listServicesByLocation>クエリ実行：サービス：SOS。

The LoST server returns the following list of services:

失われたサーバーは、サービスの次のリストを返します。

urn:service:sos.police urn:service:sos.ambulance urn:service:sos.fire

URN：サービス：sos.police URN：サービス：sos.ambulance骨壷：サービス：sos.fire

The client does the initial LoST mapping and discovers the dialstrings for each service. Then the client moves, refreshing the individual service mappings when necessary as specified by the Service Boundary. However, when arriving in location B (close to a mountain), service sos.mountainrescue, which was not available in location A, becomes available. Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected. Consequently, the dialstring for the mountain-rescue service is not known by the client. Hence, the client is unable to recognize an emergency call when the user enters the dialstring of the mountain-rescue service, and the emergency call may fail altogether.

クライアントが初期失われたマッピングを行い、各サービスのdialstringsを発見します。そして、クライアントが移動し、サービスの境界で指定されたときに必要に応じて、個々のサービスのマッピングをリフレッシュ。しかし、（山に近い）位置Bに位置Aに利用できなかったサービスsos.mountainrescueを、到着するとき、利用可能になります。クライアントのみ最初に発見されたサービスのためのマッピングをリフレッシュするために必要とされているので、新しいサービスが検出されません。その結果、山岳救助サービスのdialstringと入力はクライアントによって知られていません。したがって、クライアントは、ユーザーが山岳救助サービスのdialstringと入力に入り、緊急コールが完全に失敗することがあり際に、緊急コールを認識することができません。

Note that the Service Boundary (service region for an individual service) cannot be considered as an indicator for the region for which a specific Service List is valid. The Service List may even change within the Service Boundary of another service. For example, the ambulance mapping is valid for a whole state, but for a part of the state there is an additional mountain-rescue service.

サービス境界（個々のサービスのサービス領域）が特定のサービスの一覧が有効である地域の指標とみなすことはできないことに注意してください。サービスリストでも、別のサービスのサービス境界内に変更されることがあります。例えば、救急車のマッピングが全体の状態のために有効ですが、状態の一部のための追加の山岳救助サービスがあります。

Consequently, there are two ways to tackle this issue:

したがって、この問題に取り組むために2つの方法があります。

o Clients continuously poll for the Service List, although it may not have changed.

それは変わっていないかもしれないが、Oクライアントが継続的に、サービスリストをポーリング。

o The server sends a message containing boundary information that tells the client that the Service List does not change inside this area.

Oサーバは、サービスリストは、この領域内で変化していないことをクライアントに伝える境界情報を含むメッセージを送信します。

2. Terminology

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 RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

3. LoST Extensions

3.失われた拡張機能

This section describes the necessary extensions to the LoST protocol in order to support the Service List Boundary in a similar way as the Service Boundary. Extensions defined in this document are declared in the new XML namespace urn:ietf:params:xml:ns:lost1:slb.

このセクションでは、サービスの境界と同様の方法でサービスリスト境界をサポートするために、失われたプロトコルに必要な拡張機能について説明します。この文書で定義された拡張機能は、新しいXML名前空間の壷の中で宣言されている：IETF：のparams：XML：NS：lost1：SLB。

3.1. Extensions to <listServicesByLocation>

3.1. <listServicesByLocation>への拡張

The query <listServicesByLocation> may contain an additional <serviceListBoundaryRequest> element to additionally request the boundary for the Service List based on the location provided, with the resulting location for the list presented either by value or by reference. In the example below, the value of the 'type' attribute of the <serviceListBoundaryRequest> element is set to "value":

クエリは、<listServicesByLocation>リストの結果の位置が値または基準のいずれかによって提示されると、さらに、提供された位置に基づいて、サービスリストのための境界を要求する追加の<serviceListBoundaryRequest>要素を含んでいてもよいです。以下の例では、<serviceListBoundaryRequest>要素の「タイプ」属性の値は、「値」に設定されています。

<?xml version="1.0" encoding="UTF-8"?> <listServicesByLocation xmlns="urn:ietf:params:xml:ns:lost1" xmlns:gml="http://www.opengis.net/gml" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb" recursive="true"> <location id="5415203asdf548" profile="civic"> <civicAddress xml:lang="en" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>AT</country> <A1>Lower Austria</A1> <A2>Bruck an der Leitha</A2> <A3>Wolfsthal</A3> <RD>Hauptplatz</RD> <HNO>1</HNO> <PC>2412</PC> </civicAddress> </location> <service>urn:service:sos</service> <slb:serviceListBoundaryRequest type="value"/> </listServicesByLocation>

<？xml version = "1.0" エンコード= "UTF-8"？> <listServicesByLocationののxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：GML = "http://www.opengis.net/gml "のxmlns：SLB =" URN：IETF：paramsは：XML：NS：lost1：SLB」再帰= "真"> <位置ID = "5415203asdf548" プロフィール= "市民"> <civicAddressのxml：langの= "EN" のxmlns = "URN：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr"> <国> AT </国> <A1>下オーストリア</ A1> <A2>ブルックデア・ライタ川</ A2> <A3> Wolfsthal </ A3> <RD> Hauptplatz </ RD> <HNO> 1 </ HNO> <PC> 2412 </ PC> </ civicAddress> </場所> <サービス> URN：サービス：SOS </サービス> <SLB ：serviceListBoundaryRequestタイプ= "値" /> </ listServicesByLocation>

A <listServicesByLocationResponse> with the addition of one <serviceListBoundary> element is shown below:

<listServicesByLocationResponse> 1 <serviceListBoundary>要素を追加したが、以下に示します。

<?xml version="1.0" encoding="UTF-8"?> <listServicesByLocationResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"> <serviceList> urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.poison urn:service:sos.police </serviceList>

<？xml version = "1.0" エンコード= "UTF-8"？> <listServicesByLocationResponseのxmlns = "壷：IETF：のparams：XML：NS：lost1" のxmlns：SLB = "壷：IETF：のparams：XML：NS：lost1 ：SLB "> <serviceList> URN：サービス：sos.ambulance骨壷：サービス：sos.fire URN：サービス：sos.gas URN：サービス：sos.mountain URN：サービス：sos.poison URN：サービス：sos.police < / serviceList>

<path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="5415203asdf548"/> <slb:serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z"> <civicAddress xml:lang="en" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>AT</country> <A1>Lower Austria</A1> </civicAddress> </slb:serviceListBoundary> </listServicesByLocationResponse>

<path>は<介してソース= "resolver.example" /> <介してソース= "authoritative.example" /> </ path>の<locationUsed ID = "5415203asdf548" /> <SLB：serviceListBoundaryプロファイル= "市民" は、「=満了します2012-01-01T00：00：00Z "> <civicAddressのxml：langは=" EN」のxmlns = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr"> <国> AT </国> <A1 >下オーストリア</ A1> </ civicAddress> </ SLB：serviceListBoundary> </ listServicesByLocationResponse>

The response above indicates that the Service List is valid for Lower Austria. The <listServicesByLocation> request needs to be repeated by the client only when moving out of Lower Austria. However, the mappings of the services themselves may have other service boundaries. Additionally, the 'expires' attribute indicates the absolute time when this Service List becomes invalid.

応答は、上記サービスリストは、下オーストリアに対して有効であることを示しています。 <listServicesByLocation>リクエストは下オーストリアの外に移動した場合にのみ、クライアントによって繰り返される必要があります。しかし、サービスそのもののマッピングは、他のサービスの境界を有することができます。また、属性がこのサービスの一覧が無効になる絶対時間を示して「期限が切れ」。

The response MAY contain multiple <serviceListBoundary> elements for alternative representation, each representing the boundary in a specific location profile. However, multiple locations inside a <serviceListBoundary> element are considered to be additive.

応答は、各々が特定の場所プロファイルの境界を表す、代替表現のために複数の<serviceListBoundary>要素を含んでいてもよいです。しかし、<serviceListBoundary>要素内の複数の位置は、添加剤であると考えられます。

The boundary can also be requested by reference when setting the value of the 'type' attribute of the <serviceListBoundaryRequest> element to "reference" (which is the default in case the attribute is omitted). The response will contain a <serviceListBoundaryReference> element with a 'serviceListKey' attribute (described in Section 3.2), as shown below.

（属性が省略された場合のデフォルトである）「参照」に<serviceListBoundaryRequest>要素の「タイプ」属性の値を設定する際に、境界は、参照によって要求することができます。以下に示すように、応答は、（セクション3.2を参照）「serviceListKey」属性と<serviceListBoundaryReference>要素を含むであろう。

3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>

3.2. <getServiceListBoundary>を経由して、<serviceListBoundary>を取得

In order to retrieve the boundary corresponding to a specific 'serviceListKey', the client issues a <getServiceListBoundary> request to the server identified in the 'source' attribute of the <serviceListBoundaryReference> element, similar to the <getServiceBoundary> request.

具体的な「serviceListKey」に対応する境界を取得するためには、クライアントは<getServiceBoundary>リクエストに似<serviceListBoundaryReference>要素の「ソース」属性で識別されるサーバーに<getServiceListBoundary>要求を発行します。

An example is shown below:

例を以下に示します。

<?xml version="1.0" encoding="UTF-8"?> <getServiceListBoundary xmlns="urn:ietf:params:xml:ns:lost1:slb" serviceListKey="123567890123567890123567890"/>

<？xml version = "1.0" エンコード= "UTF-8"？> <getServiceListBoundaryのxmlns = "壷：IETF：のparams：XML：NS：lost1：SLB" serviceListKey = "123567890123567890123567890" />

The LoST server response is shown below:

失われたサーバーの応答を以下に示します。

<?xml version="1.0" encoding="UTF-8"?> <getServiceListBoundaryResponse xmlns="urn:ietf:params:xml:ns:lost1:slb"> <serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z"> <civicAddress xml:lang="en" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>AT</country> <A1>Lower Austria</A1> </civicAddress> </serviceListBoundary> <path xmlns="urn:ietf:params:xml:ns:lost1"> <via source="resolver.example"/> <via source="authoritative.example"/> </path> </getServiceListBoundaryResponse>

<？xml version = "1.0" エンコード= "UTF-8"？> <getServiceListBoundaryResponseののxmlns = "壷：IETF：のparams：XML：NS：lost1：SLB"> <serviceListBoundaryプロファイル= "市民は" = "2012から01を満了しました-01T00：00：00Z "> <civicAddressのxml：LANG =" EN」のxmlns = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr"> <国> AT </国> <A1>下オーストリア</ A1> </ civicAddress> </ serviceListBoundary> <パスのxmlns = "URN：IETF：paramsは：XML：NS：lost1"> <ソース= "resolver.example" を介し/> <ソース= "authoritative.example" を介して/> </ path>の</ getServiceListBoundaryResponse>

The 'serviceListKey' uniquely identifies a Service List Boundary, as the 'key' does for the Service Boundary (see Section 5.6 of RFC 5222). Therefore, the 'serviceListKey' is a random token with at least 128 bits of entropy [RFC4086] and can be assumed globally unique. Whenever the boundary changes, a new 'serviceListKey' MUST be assigned.

「キーは」サービス境界（RFC 5222のセクション5.6を参照）の場合と同様に「serviceListKey」を一意に、サービスリストの境界を識別します。したがって、「serviceListKey」はエントロピーの少なくとも128ビット[RFC4086]とランダムトークンであり、グローバルに一意な仮定することができます。たび境界の変更、新しい「serviceListKey」を割り当てなければなりません。

Note: Since LoST does not define an attribute to indicate which location profile the client understands in a <getServiceBoundary> request, this document also does not define one for the <getServiceListBoundary> request.

注意：LOSTは、クライアントが<getServiceBoundary>要求に理解している場所のプロファイルを示すために、属性を定義していないので、この文書はまた、<getServiceListBoundary>要求のための1つを定義していません。

3.3. <serviceListBoundary>

For a particular <listServicesByLocation> query, the Service List Boundary information that gets returned indicates that all the service identifiers returned in the <serviceList> element are the same within this geographic region. A Service List Boundary may consist of geometric shapes (both in civic and geodetic location format), and may be non-contiguous, like the Service Boundary.

特に<listServicesByLocation>クエリの場合、返されるサービスリスト境界情報は、<serviceList>要素で返されるすべてのサービス識別子は、この地理的領域内で同じであることを示しています。サービスリスト境界は、幾何学的形状（両方の市民と測地位置形式）から構成され得る、およびサービス境界のような、非連続的であってもよいです。

The mapping of the specific services within the Service List Boundary may be different at different locations.

サービスリストの境界内の特定のサービスのマッピングは、異なる場所で異なる場合があります。

The server MAY return the boundary information in multiple location profiles, but MUST use at least one profile that the client used in the request in order to ensure that the client is able to process the boundary information.

サーバーは、複数の場所のプロファイルで境界情報を返してもよいが、クライアントは、クライアントが境界情報を処理することが可能であることを保証するために、要求に使用される少なくとも1つのプロファイルを使用しなければなりません。

There is no need to include boundary information in a <listServicesResponse>. The <listServices> request is purely for diagnostic purposes and does not contain location information at all, so boundary information cannot be calculated.

<listServicesResponse>で境界情報を含める必要はありません。 <listServices>要求は、診断目的のために純粋であり、全く位置情報が含まれていないので、境界情報を算出することができません。

Also note that the Service List Boundary is OPTIONAL, and the LoST server may return it or not, based on its local policy -- as is the case with the Service Boundary. However, especially for emergency services, the Service List Boundary might be crucial to ensure that moving clients do not miss changes in the available services.

サービスの境界の場合と同様に - また、ローカルポリシーに基づいて、サービスリスト境界は任意であり、失われたサーバはそれを返すか、ないかもしれないことに注意してください。しかし、特に緊急サービスのために、サービス一覧の境界が移動するクライアントが利用可能なサービスの変化を見逃さないことを保証するために非常に重要であるかもしれません。

3.4. Implementation Considerations

3.4. 実装に関する考慮事項

The subsections below discuss implementation issues for the LoST server and client for Service List Boundary support.

以下のサブセクションでは、サービスリスト境界をサポートするために失われたサーバーとクライアントの実装上の問題を議論します。

3.4.1. Server Side

3.4.1. サーバ側

The mapping architecture and framework [RFC5582] states that each tree announces its coverage region (for one type of service, e.g., sos.police) to one or more forest guides. Forest guides peer with each other and synchronize their data. Hence, a forest guide has sufficient knowledge (it knows all the services and their coverage regions) to answer a <listServicesByLocation> query and to add the <serviceListBoundary> or <serviceListBoundaryReference> as well.

マッピング・アーキテクチャおよびフレームワーク[RFC5582]は各ツリーは、1つのまたは複数森林ガイドを（サービスのタイプ、例えば、sos.policeのために）そのカバレッジ領域を発表することを述べています。森のガイドは、相互にピアとそのデータを同期させます。このため、森林ガイドは、（それはすべてのサービスとそのカバレッジ領域を知っている）<listServicesByLocation>クエリに答えるために、同様<serviceListBoundary>または<serviceListBoundaryReference>を追加するのに十分な知識を持っています。

The calculation of the largest possible area for which the Service List stays the same might be a complex task. An alternative would be to return smaller areas that are easier to compute. In such a case, some unnecessary queries to the LoST server will be a consequence, but the main purpose of the Service List Boundary is still achieved: to never miss a change of available services. Thus, the server operator may specify a reasonable trade-off between the effort to generate the boundary information and the saved queries to the LoST server.

サービスリストは、同じ滞在するために可能な限り最大の面積の計算は複雑な作業かもしれません。代替は、計算が容易な小さな領域を返すようになります。そのような場合には、失われたサーバーにはいくつかの不要なクエリが結果になりますが、サービスリスト境界の主な目的は、まだ達成されています。利用可能なサービスの変更を逃さないように。したがって、サーバオペレータは、境界情報、失われたサーバーに保存されたクエリを生成するための努力の間に合理的なトレードオフを指定することができます。

For example, in some countries the offered services may differ in adjacent counties (or districts, cantons, states, etc.). Their borders may be suitable as a Service List Boundary as well, even though some adjacent counties offer the same services.

例えば、いくつかの国で提供されるサービスは、隣接する郡（または地域、州、国、等）が異なっていてもよいです。その境界線は、いくつかの隣接する郡が同じサービスを提供していても、同様にサービス一覧を境界として適当です。

Other countries might have different structures, and the generation of the Service List Boundary might follow other rules as long as it is ensured that a client is able to notice any change in the Service List when moving.

他の国は異なる構造を持っているかもしれない、とサービスのリスト境界の世代は、クライアントが移動するときに、サービス一覧の変更に気付くことが可能であることが保証される限り、他のルールに従ってください可能性があります。

3.4.2. Client Side

3.4.2. クライアント側

A mobile client that already implements LoST and evaluates the <serviceBoundary> has almost everything that is needed to make use of the Service List Boundary. Since the integration into LoST follows the concept of the <serviceBoundary> (and also makes use of the same location profiles), only the additional <serviceListBoundary> needs to be evaluated. Whenever moving outside a Service List Boundary, the client performs a new <listServicesByLocation> query with the new location information in order to determine a change in available services.

すでに失わを実装し、評価し、モバイルクライアント<serviceBoundary>サービス一覧境界を利用するために必要とされるほとんどすべてを持っています。 LOSTへの統合は、<serviceBoundary>の概念を以下（および同じ場所のプロファイルを利用する）ため、唯一の追加<serviceListBoundary>を評価する必要があります。サービスリスト境界の外側に移動するたびに、クライアントが利用可能なサービスの変化を決定するために、新しい位置情報を使用して新しい<listServicesByLocation>クエリを実行します。

4. Security and Privacy Considerations

4.セキュリティとプライバシーの考慮事項

Security considerations for LoST are discussed in [RFC5222]. This document extends LoST to also carry Service List Boundaries (and requests for them). These Service List Boundaries are calculated by the server based on the individual Service Boundaries and sent to clients in case the local policy allows this. Therefore, it is generally considered to have the same level of sensitivity as for the Service Boundary and thus the same access control and confidentiality requirements as the base LoST protocol. As a result, the security measures incorporated in the base LoST specification [RFC5222] provide sufficient protection for LoST messages that use the Service List Boundary extension.

失われたため、セキュリティ上の考慮事項は、[RFC5222]で議論されています。また、このドキュメントでは、サービスリストの境界（およびそれらの要求を）運ぶために失わを拡張します。これらのサービスリストの境界は、個々のサービスの境界に基づいて、サーバによって計算され、ローカルポリシーがこれを可能にする場合は、クライアントに送信されます。したがって、一般的にサービス境界のような感度の同じレベルを有すると考えられるので、基部と同じアクセス制御と機密性の要件は、プロトコルを失いました。その結果、ベース失われた仕様[RFC5222]に組み込まれたセキュリティ対策は、サービスリスト境界拡張を使用失われたメッセージのための十分な保護を提供します。

5. IANA Considerations

5. IANAの考慮事項

IANA has taken two actions: an XML schema registration and a namespace registration, according to the description in the following sections.

次のセクションの記述に従って、XMLスキーマの登録と名前空間の登録：IANAは、二つの措置を取りました。

5.1. Relax NG Schema Registration

5.1. NG Schemaの登録をリラックス

IANA has registered the following Relax NG Schema in the IETF XML Registry [RFC3688]:

IANAは、次のIETF XMLレジストリ[RFC3688]でNGスキーマをリラックス登録しています：

URI: urn:ietf:params:xml:schema:lost1:slb

URI：URN：IETF：のparams：XML：スキーマ：lost1：SLB

Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)

登録者連絡先：IETF ECRITワーキンググループ、カール・ハインツ・ウルフ（karlheinz.wolf@nic.at）

Relax NG Schema:

NGスキーマをリラックス：

BEGIN

ベギン

<?xml version="1.0" encoding="UTF-8"?> <grammar xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb" ns="urn:ietf:params:xml:ns:lost1" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <include href="lost.rng">

<？xml version = "1.0" エンコード= "UTF-8"？>は<文法のxmlns = "http://relaxng.org/ns/structure/1.0" のxmlns：A = "http://relaxng.org/ns /compatibility/annotations/1.0" のxmlns：SLB = "壷：IETF：のparams：XML：NS：lost1：SLB" NS = "壷：IETF：のparams：XML：NS：lost1" datatypeLibrary = "のhttp：// WWW。 w3.org/2001/XMLSchema-datatypes "> <HREF =含める"> "lost.rngを

<start> <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"/>

<！ - 失われた要素の再定義 - > <スタート> <選択> <refの名前= "findService" /> <refの名前= "listServices" /> <refの名前= "listServicesByLocation" /> <refの名前= "getServiceBoundary "/> <REF名=" findServiceResponse "/> <REF名=" listServicesResponse "/> <REF名=" listServicesByLocationResponse "/> <REF名=" getServiceBoundaryResponse "/> <REF名=" エラー "/> <REF NAME = "リダイレクト" />

<ref name="getServiceListBoundary"/> <ref name="getServiceListBoundaryResponse"/> </choice> </start>

<！ - 新しいRFCで6197 - > <refの名前= "getServiceListBoundary" /> <refの名前= "getServiceListBoundaryResponse" /> </選択> </スタート>

<データタイプ=」<要素名= "listServicesByLocation"> <REF名= "requestLocation" /> <REF名= "commonRequestPattern" /> <オプション> <属性名= "再帰"> <名前= "listServicesByLocation" を定義>ブール値 "/> <：はdefaultValue>真</：はdefaultValue> </属性> </オプション>

<optional> <ref name="serviceListBoundaryRequest"/> </optional> </element> </define>

<！ - 新しいRFC 6197で - > <オプション> <refの名前= "serviceListBoundaryRequest" /> </オプション> </要素> </定義>

<定義名= "listServicesByLocationResponse"> <要素名= "listServicesByLocationResponse"> <REF名= "serviceList" /> <REF名= "commonResponsePattern" /> <REF名= "locationUsed" />

<optional> <choice> <ref name="serviceListBoundary"/> <ref name="serviceListBoundaryReference"/> </choice> </optional> </element> </define> </include>

<！ - 新しいRFCで6197 - > <オプション> <選択> <refの名前= "serviceListBoundary" /> <refの名前= "serviceListBoundaryReference" /> </選択> </オプション> </要素> </定義> </ include>の

<define name="serviceListBoundaryRequest"> <element name="slb:serviceListBoundaryRequest"> <optional> <attribute name="type"> <choice> <value>value</value> <value>reference</value> </choice> <a:defaultValue>reference</a:defaultValue> </attribute> </optional> </element> </define>

<定義名= "serviceListBoundaryRequest"> <要素名= "SLB：serviceListBoundaryRequest"> <オプション> <属性名= "タイプ"> <選択> <値>値</値> <値>参照</ value>の</選択肢> <A：はdefaultValue>参照</ A：はdefaultValue> </属性> </オプション> </要素> </定義>

= <オプション> <REF名= "期限切れに" /> </オプション> <REF名= "locationInformation" /> <REF名：<oneOrMore> <要素名= "serviceListBoundary SLB"> <名前= "serviceListBoundary" を定義> "拡張ポイント" /> </要素> </ oneOrMore> </定義>

<定義名= "serviceListBoundaryReference"> <要素名= "SLB：serviceListBoundaryReference"> <REF名= "ソース" /> <属性名= "serviceListKey"> <データタイプ= "トークン" /> </属性> <REF名前= "拡張ポイント" /> </要素> </定義>

<定義名= "getServiceListBoundary"> <要素名= "SLB：getServiceListBoundary"> <データタイプ= "トークン" /> <名前= "serviceListKeyを" 属性> </属性> <REF名= "拡張ポイント" /> </要素> </定義>

<定義名= "getServiceListBoundaryResponse"> <要素名= "SLB：getServiceListBoundaryResponse"> <REF名= "serviceListBoundary" /> <REF名= "パス" /> <REF名= "拡張ポイント" /> </要素> < /> </文法を定義します>

END

終わり

5.2. Namespace Registration

5.2. 名前空間の登録

IANA has registered the following namespace (below the LoST namespace defined in [RFC5222]) in the IETF XML Registry [RFC3688]:

IANAはIETF XMLレジストリ[RFC3688]に（[RFC5222]で定義された失われた名前空間下の）次の名前空間を登録しました。

URI: urn:ietf:params:xml:ns:lost1:slb

URI：URN：IETF：のparams：XML：NS：lost1：SLB

Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)

登録者連絡先：IETF ECRITワーキンググループ、カール・ハインツ・ウルフ（karlheinz.wolf@nic.at）

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 Service List Boundary Namespace</title> </head> <body> <h1>Namespace for the LoST Service List Boundary</h1> <h2>urn:ietf:params:xml:ns:lost1:slb</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6197.txt"> RFC 6197</a>.</p> </body> </html>

！<？xmlのバージョン= "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> <メタHTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = ISO-8859 -1" /> <タイトル>失われたサービスリスト境界名前空間</タイトル>失われたサービス一覧バウンダリ</ H1> <H2>壷のための</ HEAD> <BODY> <H1>名前空間：IETF：のparams：XML：NS ：lost1：SLB </ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc6197.txt"> RFC 6197 </a>のを参照してください。</ P> </ボディ> </ HTML>

END

終わり

6. Acknowledgements

6.謝辞

The author would like to thank Henning Schulzrinne for discussion of the document, and Martin Thomson, Richard Barnes, and Roger Marshall for their valuable input and text suggestions during the working group Last Call. Further thanks go to Joshua Bell from the Applications Area Review Team for his help with Relax NG.

著者は、ワーキンググループラストコール中に貴重な入力とテキスト提案を文書の議論のためのヘニングSchulzrinneと、そしてマーティン・トムソン、リチャード・バーンズ、とロジャー・マーシャルに感謝したいと思います。さらにおかげでNGをリラックスして彼の助けのためのアプリケーションエリア審査チームからのジョシュア・ベルに行きます。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.

[RFC5222]ハーディ、T.、ニュートン、A.、Schulzrinneと、H.、およびH. Tschofenig、 "失われた：場所・ツー・サービス翻訳・プロトコル"、RFC 5222、2008年8月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4086]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。

7.2. Informative References

7.2. 参考文献

[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.

[RFC5582] Schulzrinneと、H.、 "場所・ツー・URLのマッピングのアーキテクチャとフレームワーク"、RFC 5582、2009年9月。

Author's Address

著者のアドレス

Karl Heinz Wolf nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria

カール・ハインツ・ウルフnic.at社カールス1/2/9ウィーンオーストリア

Phone: +43 1 5056416 37 EMail: karlheinz.wolf@nic.at URI: http://www.nic.at/

電話：+43 1 5056416 37電子メール：URI karlheinz.wolf@nic.at：http://www.nic.at/