[要約] RFC 6197は、Location-to-Service Translation (LoST) Service List Boundary Extensionに関するものであり、位置情報をサービスに変換するための拡張機能を提供します。その目的は、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
場所からサービスへの翻訳（失われた）サービスリストの境界拡張機能
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.
場所からサービスへの翻訳（ロスト）マップサービス識別子と位置情報サービスへの連絡先のURIに連絡します。失われたクライアントが特定の場所で利用可能なサービスを発見したい場合、Lost Serverに<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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6197で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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.
Lost Protocol [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のサービス領域を示すサービス境界を定義します。ただし、すべてのサービスがどこでも利用できるわけではありません。クライアントは、Lostの<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になります）を実行し、ロケーションa要求のurn：services：sosを使用して、初期<listservicesbylocation>クエリを実行します。
The LoST server returns the following list of services:
失われたサーバーは、次のサービスリストを返します。
urn:service:sos.police
urn:service:sos.ambulance
urn:service: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.
クライアントは、最初の失われたマッピングを行い、各サービスのダイヤルストリングを発見します。次に、クライアントが移動し、サービス境界で指定されているように、必要に応じて個々のサービスマッピングを更新します。ただし、ロケーションB（山の近く）に到着すると、ロケーションAで利用できなかったSos.MountainRescueのサービスが利用可能になります。クライアントは、最初に発見されたサービスのマッピングを更新するためにのみ必要であるため、新しいサービスは検出されません。その結果、山とレスキューサービスのダイヤルストリングはクライアントには知られていません。したがって、ユーザーが山岳レスキューサービスのダイヤルストリングを入力すると、クライアントは緊急通話を認識できず、緊急電話が完全に失敗する可能性があります。
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 サーバーは、この領域内でサービスリストが変更されないことをクライアントに伝える境界情報を含むメッセージを送信します。
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]で説明されているように解釈されます。
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 Namespace URN：IETF：PARAMS：XML：NS：LOST1：SLBで宣言されています。
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":
Query <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>
A <listServicesByLocationResponse> with the addition of one <serviceListBoundary> element is shown below:
A <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>
<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>
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>要素の「タイプ」属性の値を「参照」に設定する場合、参照によって要求することもできます（属性が省略された場合にはデフォルトです）。応答には、以下に示すように、「ServicElistKey」属性（セクション3.2で説明）を備えた<ServicElistBoundaryReference>要素が含まれます。
<?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>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="5415203asdf548"/>
<slb:serviceListBoundaryReference
source="authoritative.example"
serviceListKey="123567890123567890123567890" />
</listServicesByLocationResponse>
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」に対応する境界を取得するために、クライアントは<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"/>
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>
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.
「serviceListkey」は、「キー」がサービス境界に対して行うように、サービスリストの境界を一意に識別します（RFC 5222のセクション5.6を参照）。したがって、「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>リクエストのものも定義しません。
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.
また、サービスリストの境界はオプションであり、Lost Serverは、サービス境界の場合のように、ローカルポリシーに基づいて、それを返すかどうかにかかわらず、それを返すかどうかに注意してください。ただし、特に緊急サービスの場合、移動するクライアントが利用可能なサービスの変更を見逃さないようにするために、サービスリストの境界が重要です。
The subsections below discuss implementation issues for the LoST server and client for Service List Boundary support.
以下のサブセクションでは、サービスリストの境界サポートのための失われたサーバーとクライアントの実装の問題について説明します。
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つ以上の森林ガイドに対してカバレッジ領域（1つのタイプのサービスなど、Sos.Policeなど）を発表することを示しています。フォレストガイドは互いに協力して、データを同期させます。したがって、森林ガイドには、<リストServicesbylocation>クエリに応答し、<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.
他の国は異なる構造を持っている可能性があり、サービスリストの境界の生成は、クライアントが移動時にサービスリストの変更に気付くことができる限り、他のルールに従うことがあります。
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>クエリを実行します。
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]に組み込まれたセキュリティ対策は、サービスリストの境界拡張機能を使用する失われたメッセージを十分に保護します。
IANA has taken two actions: an XML schema registration and a namespace registration, according to the description in the following sections.
IANAは、次のセクションの説明に従って、XMLスキーマ登録と名前空間登録の2つのアクションを実行しました。
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
Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)
登録者の連絡先：IETF ECRITワーキンググループ、Karl Heinz Wolf（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">
<!-- redefinition of LoST elements -->
<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"/>
<!-- New in RFC 6197 -->
<ref name="getServiceListBoundary"/>
<ref name="getServiceListBoundaryResponse"/>
</choice>
</start>
<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>
<!-- New in RFC 6197 -->
<optional>
<ref name="serviceListBoundaryRequest"/>
</optional>
</element>
</define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
<!-- New in RFC 6197 -->
<optional>
<choice>
<ref name="serviceListBoundary"/>
<ref name="serviceListBoundaryReference"/>
</choice>
</optional>
</element>
</define>
</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>
<define name="serviceListBoundary">
<oneOrMore>
<element name="slb:serviceListBoundary">
<optional>
<ref name="expires"/>
</optional>
<ref name="locationInformation"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</define>
<define name="serviceListBoundaryReference">
<element name="slb:serviceListBoundaryReference">
<ref name="source"/>
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getServiceListBoundary">
<element name="slb:getServiceListBoundary">
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getServiceListBoundaryResponse">
<element name="slb:getServiceListBoundaryResponse">
<ref name="serviceListBoundary"/>
<ref name="path"/>
<ref name="extensionPoint"/>
</element>
</define>
</grammar>
END
終わり
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
Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at) XML:
登録者の連絡先：IETF ECRITワーキンググループ、Karl Heinz Wolf（Karlheinz.wolf@nic.at）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>
END
終わり
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.
著者は、ドキュメントの議論についてHenning Schulzrinneに感謝し、Martin Thomson、Richard Barnes、およびRoger Marshallがワーキンググループの最後の電話で貴重な入力とテキストの提案をしてくれたことに感謝します。リラックスNGのヘルプについて、Applications Areas Review ReviewチームのJoshua Bellにさらに感謝します。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「Lost：A Location-s-Service Translation Protocol」、RFC 5222、2008年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[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
カールハインツウルフニック。
Phone: +43 1 5056416 37
EMail: karlheinz.wolf@nic.at
URI: http://www.nic.at/