[要約] RFC 5985は、HTTP-Enabled Location Delivery (HELD)プロトコルに関する仕様です。HELDは、ユーザーの位置情報をHTTP経由で配信するためのプロトコルであり、位置ベースのサービスや緊急通報システムなどで利用されます。このRFCは、HELDの機能と要件を定義し、実装のガイドラインを提供します。
Internet Engineering Task Force (IETF) M. Barnes, Ed.
Request for Comments: 5985 Polycom
Category: Standards Track September 2010
ISSN: 2070-1721
HTTP-Enabled Location Delivery (HELD)
HTTP対応のロケーション配達（開催）
Abstract
概要
This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer.
このドキュメントは、レイヤー7位置構成プロトコル（L7 LCP）を定義し、L7 LCPの輸送としてHTTPおよびHTTP/TLSの使用を説明します。L7 LCPは、アクセスネットワーク内のサーバーから位置情報を取得するために使用されます。これには、2つの形式で位置情報を取得するためのオプションが含まれています。価値と参照によって。このプロトコルは、セッションレイヤーに依存しない拡張可能なアプリケーション層プロトコルです。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5985.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5985で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 6
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 6
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 7
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Response . . . . . . . . . . . . . . . . . . . . 9
5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 10
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 15
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring That the Proper LIS Has Been Contacted . . . . . 23
9.2. Protecting Responses from Modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Examples of HTTPS Messages . . . . . . . . . . . . . . . . 25
10.2. Example of a Simple Location Request . . . . . . . . . . . 26
10.3. An Example of a Location Request for Multiple Location
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. HELD Compliance to IETF LCP Requirements . . . . . . 36
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39
The location of a Device is information that is useful for a number of applications. The L7 Location Configuration Protocol (LCP) problem statement and requirements document [RFC5687] provides some scenarios in which a Device might rely on its access network to provide location information. The Location Information Server (LIS) service applies to access networks employing both wired technology (e.g., DSL, cable) and wireless technology (e.g., WiMAX) with varying degrees of Device mobility. This document describes a protocol that can be used to acquire Location Information (LI) from a LIS within an access network.
デバイスの場所は、多くのアプリケーションに役立つ情報です。L7ロケーション構成プロトコル（LCP）問題ステートメントと要件ドキュメント[RFC5687]は、デバイスがアクセスネットワークに依存して位置情報を提供できるシナリオを提供します。Loacy Information Server（LIS）サービスは、さまざまな程度のデバイスモビリティを備えた有線技術（DSL、ケーブルなど）とワイヤレステクノロジー（WIMAXなど）の両方を採用したアクセスネットワークに適用されます。このドキュメントでは、アクセスネットワーク内のLISから位置情報（LI）を取得するために使用できるプロトコルについて説明します。
This specification identifies two types of location information that may be retrieved from the LIS. Location may be retrieved from the LIS by value; that is, the Device may acquire a literal location object describing the location of the Device. The Device may also request that the LIS provide a location reference in the form of a Location URI or set of Location URIs, allowing the Device to distribute its LI by reference. Both of these methods can be provided concurrently from the same LIS to accommodate application requirements for different types of location information.
この仕様は、LISから取得される可能性のある2種類の位置情報を識別します。場所は、値によってLISから取得できます。つまり、デバイスは、デバイスの場所を説明する文字通りの位置オブジェクトを取得する場合があります。また、デバイスは、LISが位置URIまたはロケーションURISのセットの形式でロケーション参照を提供し、デバイスが参照によってLIを配布できるように要求する場合があります。これらの方法は両方とも、同じタイプの位置情報のアプリケーション要件に対応するために、同じLISから同時に提供できます。
This specification defines an extensible XML-based protocol that enables the retrieval of LI from a LIS by a Device. This protocol can be bound to any session-layer protocol, particularly those capable of MIME transport. This document describes the use of HTTP and HTTP/TLS as transports for the protocol.
この仕様は、デバイスによるLIからLIの取得を可能にする拡張可能なXMLベースのプロトコルを定義します。このプロトコルは、特にMIME輸送が可能なセッション層プロトコルにバインドできます。このドキュメントでは、プロトコルの輸送としてHTTPおよびHTTP/TLSの使用について説明します。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the terms (and their acronym forms): Access Provider (AP), Location Information (LI), Location Object (LO), Device, Target, Location Generator (LG), Location Recipient (LR), and Rule Maker (RM) and Rule Holder (RH) as defined in GEOPRIV Requirements [RFC3693]. The terms Location Information Server (LIS), Access Network, Access Provider (AP), and Access Network Provider are used in the same context as defined in the L7 LCP Problem statement and Requirements document [RFC5687]. The usage of the terms Civic Location/Address and Geodetic Location follows the usage in many of the referenced documents.
このドキュメントでは、用語（およびその頭字語フォーム）を使用します：アクセスプロバイダー（AP）、ロケーション情報（LI）、ロケーションオブジェクト（LO）、デバイス、ターゲット、ロケーションジェネレーター（LG）、ロケーション受信者（LR）、およびルールメーカー（GEOPRIV要件[RFC3693]で定義されているRM）およびルールホルダー（RH）。Location Information Server（LIS）、Access Network、Access Provider（AP）、およびAccess Network Providerという用語は、L7 LCP問題ステートメントと要件ドキュメント[RFC5687]で定義されているのと同じコンテキストで使用されます。市民の場所/住所と測地位置という用語の使用は、参照されたドキュメントの多くの使用に従います。
In describing the protocol, the terms "attribute" and "element" are used according to their context in XML. The term "parameter" is used in a more general protocol context and can refer to either an XML "attribute" or "element".
プロトコルを記述する際に、「属性」と「要素」という用語は、XMLのコンテキストに従って使用されます。「パラメーター」という用語は、より一般的なプロトコルのコンテキストで使用され、XML「属性」または「要素」のいずれかを参照できます。
This document describes an interface between a Device and a Location Information Server (LIS). This document assumes that the LIS is present within the same administrative domain as the Device (e.g., the access network). The LIS exists because not all Devices are capable of determining LI, and because, even if a Device is able to determine its own LI, it may be more efficient with assistance. This document does not specify how LI is determined. An Access Provider (AP) operates the LIS so that Devices (and Targets) can retrieve their LI. This document assumes that the Device and Access Provider have no prior relationship other than what is necessary for the Device to obtain network access.
このドキュメントでは、デバイスと位置情報サーバー（LIS）の間のインターフェイスについて説明します。このドキュメントは、LISがデバイスと同じ管理ドメイン内に存在することを前提としています（たとえば、アクセスネットワーク）。LISは、すべてのデバイスがLIを決定できるわけではなく、デバイスが独自のLIを決定できても、支援により効率的になる可能性があるためです。このドキュメントでは、Liの決定方法を指定しません。アクセスプロバイダー（AP）がLISを操作して、デバイス（およびターゲット）がLIを取得できるようにします。このドキュメントでは、デバイスとアクセスプロバイダーには、デバイスがネットワークアクセスを取得するために必要なもの以外の事前の関係がないことを前提としています。
This document is based on the attribution of the LI to a Device and not specifically a person (end user) or Target, based on the premise that location determination technologies are generally designed to locate a Device and not a person. It is expected that, for most applications, LI for the Device can be used as an adequate substitute for the end user's LI. Since revealing the location of the Device almost invariably reveals some information about the location of the user of the Device, the same level of privacy protection demanded by a user is required for the Device. This approach may require either some additional assurances about the link between Device and target, or an acceptance of the limitation that unless the Device requires active user authentication, there is no guarantee that any particular individual is using the Device at that instant.
このドキュメントは、LIのデバイスへの帰属に基づいており、特に人（エンドユーザー）またはターゲットではなく、場所の決定技術は一般に人ではなくデバイスを見つけるように設計されているという前提に基づいています。ほとんどのアプリケーションでは、デバイスのLIをエンドユーザーのLIの適切な代替として使用できることが期待されています。デバイスの場所を明らかにすると、デバイスのユーザーの場所に関する情報がほぼ常に表示されるため、ユーザーが要求する同じレベルのプライバシー保護がデバイスに必要です。このアプローチには、デバイスとターゲット間のリンクに関するいくつかの追加の保証が必要な場合、またはデバイスがアクティブなユーザー認証を必要としない限り、特定の個人がその瞬間にデバイスを使用しているという保証はないという制限の受け入れが必要になる場合があります。
The following diagram shows the logical configuration of some of the functional elements identified in [RFC3693] and the LIS defined in [RFC5687]. It also shows where this protocol applies, with the Rule Maker and Target represented by the role of the Device. Note that only the interfaces relevant to the Device are identified in the diagram.
次の図は、[RFC3693]で特定された機能要素のいくつかと[RFC5687]で定義されているLISの論理構成を示しています。また、このプロトコルが適用される場所も示し、ルールメーカーとターゲットはデバイスの役割で表されます。デバイスに関連するインターフェイスのみが図で識別されていることに注意してください。
+---------------------------------------------+
| Access Network Provider |
| |
| +--------------------------------------+ |
| | Location Information Server | |
| | | |
| | | |
| | | |
| | | |
| +------|-------------------------------+ |
+----------|----------------------------------+
|
|
HELD
|
Rule Maker - - _ +-----------+ +-----------+
o - - | Device | | Location |
<U\ | | - - - - | Recipient |
/ \ _ - - | | APP | |
Target - - +-----------+ +-----------+
Figure 1: Significant Roles
図1：重要な役割
The interface between the Location Recipient (LR) and the Device and/or LIS is application specific, as indicated by the APP annotation in the diagram and it is outside the scope of the document. An example of an APP interface between a Device and LR can be found in the SIP Location Conveyance document [LOC-CONVEY].
場所の受信者（LR）とデバイスおよび/またはLIの間のインターフェイスは、図のアプリアノテーションで示されているように、ドキュメントの範囲外であるように、アプリケーション固有です。デバイスとLRの間のアプリインターフェイスの例は、SIPロケーションキャンベたドキュメント[Loc Convey]にあります。
A Device uses the HTTP-Enabled Location Delivery (HELD) protocol to retrieve its location either directly in the form of a Presence Information Data Format Location Object (PIDF-LO) document (by value) or indirectly as a Location URI (by reference). The security necessary to ensure the accuracy, privacy, and confidentiality of the Device's location is described in the Security Considerations (Section 9).
デバイスは、HTTP対応の位置配信（保有）プロトコルを使用して、その場所を存在情報データ形式の場所オブジェクト（PIDF-LO）ドキュメント（値で）の形式で直接取得するか、ロケーションURI（参照）として間接的に取得します。。デバイスの位置の正確性、プライバシー、および機密性を確保するために必要なセキュリティは、セキュリティに関する考慮事項（セクション9）に記載されています。
As described in the L7 LCP problem statement and requirements document [RFC5687], the Device MUST first discover the URI for the LIS for sending the HELD protocol requests. The URI for the LIS SHOULD be obtained from an authorized and authenticated entity. The details for ensuring that an appropriate LIS is contacted are provided in Section 9 and in particular Section 9.1. The LIS discovery protocol details are out of scope of this document and are specified in [RFC5986]. The type of URI provided by LIS discovery is RECOMMENDED to be an HTTPS URI.
L7 LCP問題ステートメントと要件文書[RFC5687]で説明されているように、デバイスは最初に、保有プロトコル要求を送信するためにLISのURIを発見する必要があります。LISのURIは、承認された認証されたエンティティから取得する必要があります。適切なLISに連絡することを保証するための詳細は、セクション9、特にセクション9.1で提供されます。LIS発見プロトコルの詳細は、このドキュメントの範囲外であり、[RFC5986]で指定されています。LIS Discoveryによって提供されるURIのタイプは、HTTPS URIであることをお勧めします。
The LIS requires an identifier for the Device in order to determine the appropriate location to include in the location response message. In this document, the IP address of the Device, as reflected by the source IP address in the location request message, is used as the identifier. Other identifiers are possible, but are beyond the scope of this document.
LISには、ロケーション応答メッセージに含める適切な場所を決定するために、デバイスの識別子が必要です。このドキュメントでは、ロケーションリクエストメッセージのソースIPアドレスに反映されるデバイスのIPアドレスが識別子として使用されます。他の識別子は可能ですが、このドキュメントの範囲を超えています。
Use of the HELD protocol is subject to the viability of the identifier used by the LIS to determine location. This document describes the use of the source IP address sent from the Device as the identifier used by the LIS. When Network Address Translation (NAT), a Virtual Private Network (VPN), or other forms of address modification occur between the Device and the LIS, the location returned could be inaccurate.
保有プロトコルの使用は、LISが使用する識別子の実行可能性の影響を受けます。このドキュメントでは、LISが使用する識別子としてデバイスから送信されたソースIPアドレスの使用について説明します。ネットワークアドレス変換（NAT）、仮想プライベートネットワーク（VPN）、またはその他の形式のアドレス変更がデバイスとLISの間に発生する場合、返される場所は不正確である可能性があります。
Not all cases of NATs introduce inaccuracies in the returned location. For example, a NAT used in a residential Local Area Network (LAN) is typically not a problem. The external IP address used on the Wide Area Network (WAN) side of the NAT is an acceptable identifier for all of the Devices in the residence (on the LAN side of the NAT), since the covered geographical area is small.
NATのすべてのケースが返された場所に不正確さを導入するわけではありません。たとえば、住宅用ローカルエリアネットワーク（LAN）で使用されるNATは通常、問題ではありません。NATのワイドエリアネットワーク（WAN）側で使用される外部IPアドレスは、対象の地理的領域が小さいため、居住地のすべてのデバイス（NATのLAN側）の許容可能な識別子です。
On the other hand, if there is a VPN between the Device and the LIS (for example, for a teleworker), then the IP address seen by a LIS inside the enterprise network might not be the right address to identify the location of the Device. Section 4.1.2 provides recommendations to address this issue.
一方、デバイスとLISの間にVPNがある場合（たとえば、テレワーカーの場合）、エンタープライズネットワーク内のLISで見られるIPアドレスは、デバイスの場所を識別するための正しいアドレスではない場合があります。。セクション4.1.2は、この問題に対処するための推奨事項を示します。
To minimize the impact of connections or tunnels setup for security purposes or for traversing middleboxes, Devices that connect to servers such as VPN servers, SOCKS servers, and HTTP proxy servers should perform their HELD query on the LIS prior to establishing a connection to other servers. It is RECOMMENDED that discovery [RFC5986] and an initial query be performed before establishing any connections to other servers. If a Device performs the HELD query after establishing a connection to another server, the Device may receive inaccurate location information.
セキュリティ目的やミドルボックスを通過するための接続またはトンネルのセットアップの影響を最小限に抑えるには、VPNサーバー、ソックスサーバー、HTTPプロキシサーバーなどのサーバーに接続するデバイスは、他のサーバーへの接続を確立する前にLISで保有クエリを実行する必要があります。。他のサーバーへの接続を確立する前に、発見[RFC5986]と初期クエリを実行することをお勧めします。別のサーバーへの接続を確立した後、デバイスが保有クエリを実行すると、デバイスは不正確な位置情報を受信する場合があります。
Devices that establish VPN connections for use by other Devices inside a LAN or other closed network could serve as a LIS, that implements the HELD protocol, for those other Devices. Devices within the closed network are not necessarily able to detect the presence of the VPN. In this case, a VPN Device should provide the address of the LIS server it provides, in response to discovery queries, rather than passing such queries through the VPN tunnel. Otherwise, the other Devices would be totally unaware that they could receive inaccurate location information.
LANまたは他の閉じたネットワーク内の他のデバイスで使用するVPN接続を確立するデバイスは、他のデバイスのために保有プロトコルを実装するLISとして機能する可能性があります。閉じたネットワーク内のデバイスは、必ずしもVPNの存在を検出できるとは限りません。この場合、VPNデバイスは、VPNトンネルにそのようなクエリを渡すのではなく、ディスカバリークエリに応じて提供するLISサーバーのアドレスを提供する必要があります。それ以外の場合、他のデバイスは、不正確な位置情報を受け取ることができることをまったく知らないでしょう。
It could also be useful for a VPN Device to serve as a LIS for other location configuration options such as Dynamic Host Configuration Protocol (DHCP) [RFC3825] or Link Layer Discovery Protocol - Media Endpoint Discovery [LLDP-MED]. For this case, the VPN Device that serves as a LIS may first acquire its own location using HELD.
また、VPNデバイスは、動的ホスト構成プロトコル（DHCP）[RFC3825]やリンクレイヤーディスカバリープロトコル - メディアエンドポイントディスカバリー[LLDP -MED]など、他の位置構成オプションのLISとして機能することも役立ちます。この場合、LISとして機能するVPNデバイスは、最初にHoldを使用して独自の場所を取得できます。
In the cases where the Device connects to the LIS through a VPN or a NAT that serves a large geographic area or multiple geographic locations (for example, a NAT used by an enterprise to connect their private network to the Internet), the LIS might not be able to return accurate LI. If the LIS cannot determine LI for the Device, it should provide an error response to the requesting Device. The LIS needs to be configured to recognize identifiers that represent these conditions.
デバイスがVPNまたは大きな地理的エリアまたは複数の地理的位置にサービスを提供するNATを介してLISに接続する場合（たとえば、プライベートネットワークをインターネットに接続するために企業が使用するNAT）、LISはそうではないかもしれません正確なliを返すことができます。LISがデバイスのLIを決定できない場合、要求デバイスにエラー応答を提供する必要があります。LISは、これらの条件を表す識別子を認識するように構成する必要があります。
LIS operators have a large role in ensuring the best possible environment for location determination. The LIS operator needs to ensure that the LIS is properly configured with identifiers that indicate Devices on the remote side of a NAT or VPN. In order to serve the Devices on the remote side of a NAT or VPN, a LIS needs to have a presence on the side of the NAT or VPN nearest the Device.
LISオペレーターは、場所の決定に最適な環境を確保する上で大きな役割を果たします。LIS演算子は、NATまたはVPNのリモート側のデバイスを示す識別子でLISが適切に構成されていることを確認する必要があります。NATまたはVPNのリモート側にデバイスを提供するには、LISがデバイスに最も近いNATまたはVPNの側面に存在する必要があります。
Where a Device requires LI directly, it can request that the LIS create a PIDF-LO document. This approach fits well with a configuration whereby the Device directly makes use of the provided PIDF-LO document. The details on the information that may be included in the PIDF-LO MUST follow the subset of those rules relating to the construction of the "location-info" element in the PIDF-LO Usage Clarification, Considerations, and Recommendations document [RFC5491]. Further detail is included in "Protocol Parameters" (Section 6).
デバイスがLIを直接必要とする場合、LISがPIDF-LOドキュメントを作成することを要求できます。このアプローチは、デバイスが提供されたPIDF-LOドキュメントを直接使用する構成によく適合します。PIDF-LOに含まれる可能性のある情報の詳細は、PIDF-LO使用の明確化、考慮事項、および推奨文書[RFC5491]の「位置INFO」要素の構築に関連する規則のサブセットに従う必要があります。さらに詳細は、「プロトコルパラメーター」（セクション6）に含まれています。
Requesting location directly does not always address the requirements of an application. A Device can request a Location URI instead of literal location. A Location URI is a URI [RFC3986] of any scheme, which a Location Recipient (LR) can use to retrieve LI. A Location URI provided by a LIS can be assumed to be globally addressable; that is, anyone in possession of the URI can access the LIS.
場所を直接要求すると、常にアプリケーションの要件に対応するとは限りません。デバイスは、文字通りの場所ではなく、ロケーションURIを要求できます。URIの場所は、任意のスキームのURI [RFC3986]であり、Lisの受信者（LR）がLIを取得するために使用できます。LISによって提供されるURIの場所は、グローバルにアドレス指定可能であると想定できます。つまり、URIを所有している人なら誰でもLISにアクセスできます。
However, possession of the URI does not in any way suggest that the LIS indiscriminately reveals the location associated with the Location URI. The specific requirements associated with the dereference of the location are specified in [RFC5808]. The location dereference protocol details are out of scope of this document. As such, many of the requirements in [RFC5808] (e.g., canceling of location references) are not intended to be supported by this specification. It is anticipated that future specifications may address these requirements.
しかし、URIの所有は、LISがURIの位置に関連する場所を無差別に明らかにすることを決して示唆していません。場所の逆方向に関連する特定の要件は、[RFC5808]で指定されています。位置的控訴プロトコルの詳細は、このドキュメントの範囲外です。そのため、[RFC5808]の要件の多く（例えば、場所参照のキャンセル）は、この仕様によってサポートされることを意図していません。将来の仕様がこれらの要件に対処する可能性があることが予想されます。
As discussed in Section 4, the HELD protocol provides for the retrieval of the Device's location in the form of a PIDF-LO document and/or Location URI(s) from a LIS. Three messages are defined to support the location retrieval: locationRequest, locationResponse, and error.
セクション4で説明したように、保有プロトコルは、LISからPIDF-LOドキュメントおよび/または位置URIの形でデバイスの位置を取得することを規定しています。場所の取得をサポートするために3つのメッセージが定義されています：LocationRequest、Location Response、およびエラー。
The Location Request (locationRequest) message is described in Section 5.1. A Location Request message from a Device indicates whether location should be returned in the form of a PIDF-LO document (with specific type(s) of location) and/or Location URI(s). In case of success, the LIS replies with a locationResponse message, including a PIDF-LO document and/or one or more Location URIs. In the case of an error, the LIS replies with an error message.
ロケーションリクエスト（LocationRequest）メッセージについては、セクション5.1で説明しています。デバイスからのロケーションリクエストメッセージは、場所をPIDF-LOドキュメント（特定のタイプの場所）および/またはロケーションURI（s）の形式で返す必要があるかどうかを示します。成功した場合、LISはPIDF-LOドキュメントや1つ以上のロケーションURIを含むLocation Responseメッセージで応答します。エラーの場合、LISはエラーメッセージで応答します。
The HELD protocol messages are defined as XML documents that MUST be encoded in UTF-8. A MIME type "application/held+xml" is registered in Section 11.3 to distinguish HELD messages from other XML document bodies. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. The 'charset' parameter MUST be included with the XML document.
保有プロトコルメッセージは、UTF-8でエンコードする必要があるXMLドキュメントとして定義されます。MIMEタイプ「アプリケーション/保有XML」は、セクション11.3に登録されており、保有メッセージを他のXMLドキュメントボディと区別します。この仕様は、[RFC3023]に記載されている推奨事項と規則に従って、タイプの命名規則（ 'xml'接尾辞）や「charset」パラメーターの使用法を含めます。「charset」パラメーターはXMLドキュメントに含める必要があります。
Section 6 contains a more thorough description of the protocol parameters, valid values, and how each should be handled. Section 7 contains a more specific definition of the structure of these messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
セクション6には、プロトコルパラメーター、有効な値、およびそれぞれの処理方法のより徹底的な説明が含まれています。セクション7には、XMLスキーマの形でこれらのメッセージの構造のより具体的な定義が含まれています[W3C.REC-XMLSCHEMA-1-20041028]。
Section 8 describes the use of a combination of HTTP [RFC2616], TLS [RFC5246], and TCP [RFC0793] for transporting the HELD messages.
セクション8では、保有メッセージを輸送するためのHTTP [RFC2616]、TLS [RFC5246]、およびTCP [RFC0793]の組み合わせの使用について説明します。
A location request message is sent from the Device to the LIS when the Device requires its own LI. The type of LI that a Device requests is determined by the type of LI that is included in the "locationType" element.
デバイスが独自のLIを必要とする場合、ロケーションリクエストメッセージがデバイスからLISに送信されます。デバイスが要求するLiのタイプは、「LocationType」要素に含まれるLiのタイプによって決定されます。
The location request is made by sending a document formed of a "locationRequest" element. The LIS uses the source IP address of the location request message as the primary source of identity for the requesting Device or target. It is anticipated that other Device identities may be provided through schema extensions.
ロケーションリクエストは、「LocationRequest」要素を形成したドキュメントを送信することによって行われます。LISは、要求デバイスまたはターゲットのIDの主要なソースとして、ロケーション要求メッセージのソースIPアドレスを使用します。他のデバイスのアイデンティティは、スキーマエクステンションを通じて提供されることが予想されます。
The LIS MUST ignore any part of a location request message that it does not understand, except the document element. If the document element of a request is not supported, the LIS MUST return an error with the unsupportedMessage error code.
LISは、ドキュメント要素を除いて、それが理解していないロケーションリクエストメッセージの任意の部分を無視する必要があります。要求のドキュメント要素がサポートされていない場合、LISはサポートされていないメッサージエラーコードでエラーを返す必要があります。
A successful response to a location request MUST contain a PIDF-LO and/or Location URI(s). The response SHOULD contain location information of the requested "locationType". The cases whereby a different type of location information MAY be returned are described in Section 6.2.
ロケーションリクエストへの成功した応答には、PIDF-LOおよび/またはロケーションURIが含まれている必要があります。応答には、要求された「LocationType」の位置情報を含める必要があります。異なるタイプの位置情報を返す場合がある場合、セクション6.2に記載されています。
If the LIS is unable to provide location information based on the received locationRequest message, it MUST return an error message. The LIS may return an error message in response to requests for any "locationType".
LISが受信したLocationRequestメッセージに基づいて位置情報を提供できない場合、エラーメッセージを返す必要があります。LISは、「LocationType」のリクエストに応じてエラーメッセージを返す場合があります。
An error indication document consists of an "error" element. The "error" element MUST include a "code" attribute that indicates the type of error. A set of predefined error codes are included in Section 6.3.
エラー表示ドキュメントは、「エラー」要素で構成されています。「エラー」要素には、エラーのタイプを示す「コード」属性を含める必要があります。事前定義されたエラーコードのセットは、セクション6.3に含まれています。
Error responses MAY also include a "message" attribute that can include additional information. This information SHOULD be for diagnostic purposes only and MAY be in any language. The language of the message SHOULD be indicated with an "xml:lang" attribute.
エラー応答には、追加情報を含む「メッセージ」属性も含まれる場合があります。この情報は診断目的でのみである必要があり、任意の言語である場合があります。メッセージの言語は、「XML：Lang」属性で示される必要があります。
This section describes in detail the parameters that are used for this protocol. Table 1 lists the top-level components used within the protocol and where they are mandatory (m) or optional (o) for each of the messages.
このセクションでは、このプロトコルに使用されるパラメーターについて詳しく説明します。表1に、プロトコル内で使用されるトップレベルのコンポーネントと、各メッセージに対して必須（M）またはオプション（O）がある場所を示します。
+----------------+-----------+------------+------------+------------+
| Parameter | Section | Location | Location | Error |
| | | Request | Response | |
+----------------+-----------+------------+------------+------------+
| responseTime | 6.1 | o | | |
| | | | | |
| locationType | 6.2 | o | | |
| | | | | |
| code | 6.3 | | | m |
| | | | | |
| message | 6.4 | | | o |
| | | | | |
| locationUriSet | 6.5 | | o | |
| | | | | |
| Presence | 6.6 | | o | |
| (PIDF-LO) | | | | |
+----------------+-----------+------------+------------+------------+
Table 1: Message Parameter Usage
表1：メッセージパラメーターの使用法
The "responseTime" attribute MAY be included in a location request message. The "responseTime" attribute includes a time value indicating to the LIS how long the Device is prepared to wait for a response or a purpose for which the Device needs the location.
「ResponseTime」属性は、ロケーションリクエストメッセージに含まれる場合があります。「ResponseTime」属性には、デバイスが応答またはデバイスが場所を必要とする目的を待つためにデバイスがどのくらいの期間を準備するかを示す時間値が含まれます。
In the case of emergency services, the purpose of obtaining the LI could be either for routing a call to the appropriate Public Safety Answering Point (PSAP) or indicating the location to which responders should be dispatched. The values defined for the purpose, "emergencyRouting" and "emergencyDispatch", will likely be governed by jurisdictional policies and should be configurable on the LIS.
緊急サービスの場合、LIを取得する目的は、適切な公共安全応答ポイント（PSAP）への呼び出しをルーティングするか、応答者を派遣する必要がある場所を示すことです。目的のために定義された値「EmergencyRouting」と「EmergenceDispatch」は、管轄政策によって支配される可能性が高く、LISで構成可能である必要があります。
The time value in the "responseTime" attribute is expressed as a non-negative integer in units of milliseconds. The time value is indicative only, and the LIS is under no obligation to strictly adhere to the time limit implied; any enforcement of the time limit is left to the requesting Device. The LIS provides the most accurate LI that can be determined within the specified interval for the specific service.
「応答」属性の時間値は、ミリ秒単位の非陰性整数として表されます。時間値は示されており、LISは暗示される時間制限を厳密に付着させる義務がありません。時間制限の施行は、要求デバイスに任されています。LISは、特定のサービスの指定された間隔内で決定できる最も正確なLIを提供します。
The LIS may use the value of the time in the "responseTime" attribute as input when selecting the method of location determination, where multiple such methods exist. If the "responseTime" attribute is absent, then the LIS should return the most precise LI it is capable of determining, with the time interval being implementation dependent.
LISは、複数のそのような方法が存在する場所を選択するときに、「応答」属性の時間の値を入力として使用する場合があります。「応答」属性が存在しない場合、LISは、時間間隔が実装に依存しているため、決定できる最も正確なLIを返す必要があります。
The "locationType" element MAY be included in a location request message. It contains a list of LI types that are requested by the Device. The following list describes the possible values:
「LocationType」要素は、ロケーションリクエストメッセージに含まれる場合があります。デバイスによって要求されるLIタイプのリストが含まれています。次のリストでは、可能な値について説明します。
any: The LIS SHOULD attempt to provide LI in all forms available to it.
ANY：LISは、利用可能なあらゆる形式でLIを提供しようとする必要があります。
geodetic: The LIS SHOULD return a location by value in the form of a geodetic location for the Target.
測地：LISは、ターゲットの測地位置の形式で値で場所を返す必要があります。
civic: The LIS SHOULD return a location by value in the form of a civic address for the Target.
CIVIC：LISは、ターゲットの市民住所の形で価値によって場所を返す必要があります。
locationURI: The LIS SHOULD return a set of Location URIs for the Target.
Locationuri：lisは、ターゲットの場所のurisのセットを返す必要があります。
The LIS SHOULD return the requested location type or types. The location types the LIS returns also depend on the setting of the optional "exact" attribute. If the "exact" attribute is set to "true", then the LIS MUST return either the requested location type or provide an error response. The "exact" attribute does not apply (is ignored) for a request for a location type of "any". Further detail of the "exact" attribute processing is provided in the following Section 6.2.1.
LISは、要求されたロケーションタイプまたはタイプを返す必要があります。LISリターンのタイプは、オプションの「正確な」属性の設定によっても異なります。「正確な」属性が「true」に設定されている場合、LISは要求されたロケーションタイプを返すか、エラー応答を提供する必要があります。「正確な」属性は、「任意」の場所タイプのリクエストには適用されません（無視されます）。「正確な」属性処理の詳細については、次のセクション6.2.1に記載されています。
When there is a request for specific locationType(s) and the "exact" attribute is "false", the LIS MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type. The "SHOULD"-strength requirements on this parameter for specific location types are included to allow for soft-failover. This enables a fixed client configuration that prefers a specific location type without causing location requests to fail when that location type is unavailable. For example, a notebook computer could be configured to retrieve civic addresses, which is usually available from typical home or work situations. However, when using a wireless modem, the LIS might be unable to provide a civic address and thus provides a geodetic address.
特定のLocationType（s）のリクエストがあり、「正確な」属性が「false」である場合、LISは追加のロケーションタイプを提供するか、要求されたロケーションタイプの要求が満たされない場合は代替タイプを提供する場合があります。ソフトフェイルオーバーを可能にするために、特定のロケーションタイプのこのパラメーターの「必要」の強度要件が含まれています。これにより、そのロケーションタイプが利用できないときにロケーションリクエストを失敗させることなく、特定のロケーションタイプを好む固定クライアント構成が可能になります。たとえば、ノートブックコンピューターは、通常、典型的な家庭や仕事の状況から利用できる市民住所を取得するように構成できます。ただし、ワイヤレスモデムを使用する場合、LISはシビックアドレスを提供できないため、測地アドレスを提供する可能性があります。
The LIS SHOULD return location information in a form that is suited for routing and responding to an emergency call in its jurisdiction, specifically by value. The LIS MAY alternatively or additionally return a Location URI. If the "locationType" element is absent, a value of "any" MUST be assumed as the default. A Location URI provided by the LIS is a reference to the most current available LI and is not a stable reference to a specific location.
LISは、ルーティングに適した形式で位置情報を返し、その管轄区域で、特に価値によって緊急コールに応答する必要があります。LISは、場所URIの場所を交代的に、またはさらに返却する場合があります。「LocationType」要素がない場合、「任意の」の値をデフォルトとして想定する必要があります。LISが提供するURIは、利用可能な最新のLIへの参照であり、特定の場所への安定した参照ではありません。
It should be noted that the protocol does not support a request to just receive one of a subset of location types. For example, in the case where a Device has a preference for just "geodetic" or "civic", it is necessary to make the request without an "exact" attribute, including both location types. In this case, if neither is available, a LIS SHOULD return a locationURI if available.
プロトコルは、ロケーションタイプのサブセットの1つだけを受信するというリクエストをサポートしていないことに注意する必要があります。たとえば、デバイスが「測地」または「シビック」のみを優先している場合、両方のロケーションタイプを含む「正確な」属性なしでリクエストを行う必要があります。この場合、どちらも利用できない場合、LISは利用可能な場合はLocationuriを返す必要があります。
The LIS SHOULD provide the locations in the response in the same order in which they were included in the "locationType" element in the request. Indeed, the primary advantage of including specific location types in a request when the "exact" attribute is set to "false" is to ensure that one receives the available locations in a specific order. For example, a locationRequest for "civic" could yield any of the following location types in the response:
LISは、リクエストの「LocationType」要素に含まれていたのと同じ順序で、応答の場所を提供する必要があります。実際、「正確な」属性が「false」に設定されている場合、特定のロケーションタイプをリクエストに含めることの主な利点は、特定の順序で利用可能な場所を受信することを確認することです。たとえば、「シビック」のLocationRequestは、応答内の次のロケーションタイプのいずれかを生成する可能性があります。
o civic
o シビック
o civic, geodetic
o 市民、測地
o civic, locationURI
o Civic、Locationuri
o civic, geodetic, locationURI
o 市民、測地、locationuri
o civic, locationURI, geodetic
o Civic、Locationuri、Geodetic
o geodetic, locationURI (only if civic is not available)
o Geodetic、Locationuri（Civicが利用できない場合のみ）
o locationURI, geodetic (only if civic is not available)
o Locationuri、Geodetic（Civicが利用できない場合のみ）
o geodetic (only if civic is not available)
o 測地（Civicが利用できない場合のみ）
o locationURI (only if civic is not available)
o Locationuri（Civicが利用できない場合のみ）
For the example above, if the "exact" attribute was "true", then the only possible response is either a "civic" location or an error message.
上記の例では、「正確な」属性が「真」である場合、唯一の可能な応答は「市民」の場所またはエラーメッセージのいずれかです。
The "exact" attribute MAY be included in a location request message when the "locationType" element is included. When the "exact" attribute is set to "true", it indicates to the LIS that the contents of the "locationType" parameter MUST be strictly followed. The default value of "false" allows the LIS the option of returning something beyond what is specified, such as a set of Location URIs when only a civic location was requested.
「locationType」要素が含まれている場合、「正確な」属性をロケーションリクエストメッセージに含めることができます。「正確な」属性が「true」に設定されている場合、「LocationType」パラメーターの内容が厳密に従う必要があることをLISに示します。「false」のデフォルト値は、市民の場所のみが要求された場合の場所のセットなど、指定されているものを超えて何かを返すオプションをlisに許可します。
A value of "true" indicates that the LIS MUST provide a location of the requested type or types or MUST provide an error. The LIS MUST provide the requested types only. The LIS MUST handle an exact request that includes a "locationType" element set to "any" as if the "exact" attribute were set to "false".
「true」の値は、LISが要求されたタイプまたはタイプの場所を提供するか、エラーを提供する必要があることを示します。LISは、要求されたタイプのみを提供する必要があります。LISは、「正確な」属性が「false」に設定されているかのように「任意の」に設定された「locationType」要素を含む正確な要求を処理する必要があります。
All "error" responses MUST contain a response code. All errors are application-level errors and MUST only be provided in successfully processed transport-level responses. For example, where HTTP/HTTPS is used as the transport, HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response.
すべての「エラー」応答には、応答コードが含まれている必要があります。すべてのエラーはアプリケーションレベルのエラーであり、正常に処理されたトランスポートレベルの応答でのみ提供する必要があります。たとえば、HTTP/HTTPSがトランスポートとして使用される場合、200 OK HTTP/HTTPS応答によって保持されたエラーメッセージを伝える必要があります。
The value of the response code MUST be an IANA-registered value. The following tokens are registered by this document:
応答コードの値は、IANA登録値でなければなりません。次のトークンは、このドキュメントで登録されています。
requestError: This code indicates that the request was badly formed in some fashion (other than the XML content).
RequestError：このコードは、リクエストが何らかの形で（XMLコンテンツを除く）ひどく形成されたことを示しています。
xmlError: This code indicates that the XML content of the request was either badly formed or invalid.
XMLERROR：このコードは、リクエストのXMLコンテンツがひどく形成されたか無効であることを示しています。
generalLisError: This code indicates that an unspecified error occurred at the LIS.
Generalliserror：このコードは、LISで不特定のエラーが発生したことを示しています。
locationUnknown: This code indicates that the LIS could not determine the location of the Device. The same request can be sent by the Device at a later time. Devices MUST limit any attempts to retry requests.
locationnknown：このコードは、LISがデバイスの位置を決定できなかったことを示しています。同じリクエストは、後でデバイスから送信できます。デバイスは、リクエストを再試行する試みを制限する必要があります。
unsupportedMessage: This code indicates that an element in the XML document for the request was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver.
UnsportedMessage：このコードは、リクエストのXMLドキュメントの要素がLISによってサポートまたは理解されていないことを示しています。このエラーコードは、保有リクエストにレシーバーによってサポートされていないドキュメント要素が含まれている場合に使用されます。
timeout: This code indicates that the LIS could not satisfy the request within the time specified in the "responseTime" parameter.
タイムアウト：このコードは、LISが「応答」パラメーターで指定された時間内にリクエストを満たすことができなかったことを示しています。
cannotProvideLiType: This code indicates that the LIS was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true".
Canible ProvidelityPe：このコードは、LISが要求されたタイプまたはタイプのLIを提供できなかったことを示しています。このコードは、「locationType」パラメーターの「正確な」属性が「true」に設定されている場合に使用されます。
notLocatable: This code indicates that the LIS is unable to locate the Device and that the Device MUST NOT make further attempts to retrieve LI from this LIS. This error code is used to indicate that the Device is outside the access network served by the LIS, for instance, the VPN and NAT scenarios discussed in Section 4.1.2.
locatable：このコードは、LISがデバイスを見つけることができないこと、およびデバイスがこのLIからLIを取得しようとしないことをデバイスがさらに試みてはならないことを示しています。このエラーコードは、デバイスがLISが提供するアクセスネットワークの外側にあることを示すために使用されます。たとえば、セクション4.1.2で説明されているVPNおよびNATシナリオです。
The "error" message MAY include one or more "message" attributes to convey some additional, human-readable information about the result of the request. The message MAY be included in any language, which SHOULD be indicated by the "xml:lang", attribute. The default language is assumed to be English ("en") [RFC5646].
「エラー」メッセージには、リクエストの結果に関するいくつかの追加の人間が読める情報を伝えるために、1つ以上の「メッセージ」属性が含まれている場合があります。メッセージは、「XML：Lang」属性で示される必要がある言語に含まれる場合があります。デフォルト言語は英語（ "en"）[RFC5646]であると想定されています。
The "locationUriSet" element received in a "locationResponse" message MAY contain any number of "locationURI" elements. It is RECOMMENDED that the LIS allocate a Location URI for each scheme that it supports and that each scheme is present only once. URI schemes and their secure variants, such as HTTP and HTTPS, MUST be regarded as two separate schemes.
「location -response」メッセージで受信した「locationuriset」要素には、任意の数の「locationuri」要素が含まれる場合があります。LISは、サポートする各スキームにロケーションURIを割り当て、各スキームが一度だけ存在することをお勧めします。URIスキームとHTTPやHTTPなどの安全なバリアントは、2つの別々のスキームと見なされる必要があります。
If a "locationUriSet" element is received in a "locationResponse" message, it MUST contain an "expires" attribute, which defines the length of time for which the set of "locationURI" elements are valid.
「locationuriset」要素が「locationResponse」メッセージで受信される場合、「locationuri」要素のセットが有効な時間の長さを定義する「有効期限」属性を含める必要があります。
The "locationURI" element includes a single Location URI. In order for a URI of any particular scheme to be included in a response, there MUST be a specification that defines how that URI can be used to retrieve location information. The details of the protocol for dereferencing must meet the location dereference protocol requirements as specified in [RFC5808] and are outside the scope of this base HELD specification.
「Locationuri」要素には、1つの場所URIが含まれています。特定のスキームのURIが応答に含まれるためには、そのURIを使用して位置情報を取得する方法を定義する仕様が必要です。参照のためのプロトコルの詳細は、[RFC5808]で指定されている位置的控訴プロトコル要件を満たし、このベース保有仕様の範囲外である必要があります。
Each Location URI that is allocated by the LIS is unique to the Device that is requesting it. At the time the Location URI is provided in the response, there is no binding to a specific location type and the Location URI is totally independent of the specific type of location it might reference. The specific location type is determined at the time of dereference.
LISによって割り当てられる各ロケーションURIは、それを要求しているデバイスに固有のものです。URIが応答で提供されている場所では、特定のロケーションタイプへの拘束力はなく、URIは参照する可能性のある特定のタイプの場所とは完全に独立しています。特定のロケーションタイプは、控除時に決定されます。
A "locationURI" SHOULD NOT contain any information that could be used to identify the Device or Target. Thus, it is RECOMMENDED that the "locationURI" element contain a public address for the LIS and an anonymous identifier, such as a local identifier or unlinked pseudonym.
「Locationuri」には、デバイスまたはターゲットを識別するために使用できる情報を含めるべきではありません。したがって、「Locationuri」要素には、LISの公開アドレスと、ローカル識別子やリンクされていない仮名などの匿名識別子を含めることが推奨されます。
When a LIS returns a "locationURI" element to a Device, the policy on the "locationURI" is set by the LIS alone. This specification does not include a mechanism for the HELD client to set access control policies on a "locationURI". Conversely, there is no mechanism, in this protocol as defined in this document, for the LIS to provide a Device the access control policy to be applied to a "locationURI". Since the Device is not aware of the access controls to be applied to (subsequent) requests to dereference a "locationURI", the client SHOULD protect a "locationURI" as if it were a Location Object -- i.e., the Device SHOULD send a "locationURI" over encrypted channels and only to entities that are authorized to have access to the location.
LISが「Locationuri」要素をデバイスに返すと、「Locationuri」に関するポリシーはLISだけによって設定されます。この仕様には、「Locationuri」にアクセス制御ポリシーを設定するための保有クライアントがメカニズムを含むものは含まれていません。逆に、このドキュメントで定義されているこのプロトコルには、LISがデバイスに「Locationuri」に適用するアクセス制御ポリシーを提供するメカニズムはありません。デバイスは、「Locationuri」を控除するために（後続の）要求に適用されるアクセス制御を認識していないため、クライアントは「Locationuri」をロケーションオブジェクトであるかのように保護する必要があります。つまり、デバイスは「locationuri "暗号化されたチャネル上で、場所にアクセスすることが許可されているエンティティに対してのみ。
Further guidelines to ensure the privacy and confidentiality of the information contained in the "locationResponse" message, including the "locationURI", are included in Section 9.3.
「Locationuri」を含む「Location Response」メッセージに含まれる情報のプライバシーと機密性を確保するためのさらなるガイドラインは、セクション9.3に含まれています。
The "expires" attribute is only included in a "locationResponse" message when a "locationUriSet" element is included. The "expires" attribute indicates the date/time at which the Location URIs provided by the LIS will expire. The "expires" attribute does not define the length of time a location received by dereferencing the Location URI will be valid. The "expires" attribute is RECOMMENDED not to exceed 24 hours and SHOULD be a minimum of 30 minutes.
「locationuriset」要素が含まれている場合、「expires」属性は「locationResponse」メッセージにのみ含まれます。「期限切れ」属性は、LISによって提供されるURISが期限切れにする日付/時刻を示します。「期限切れ」属性は、URIが有効になる場所を控除することで受け取った場所が有効になる時間を定義しません。「期限切れ」属性は24時間を超えないことをお勧めし、最低30分でなければなりません。
All date-time values used in HELD MUST be expressed in Universal Coordinated Time (UTC) using the Gregorian calendar. The XML schema allows use of time zone identifiers to indicate offsets from the zero meridian, but this option MUST NOT be used with HELD. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values.
保有で使用されるすべての日付値は、グレゴリオカレンダーを使用して、ユニバーサル調整時間（UTC）で表現する必要があります。XMLスキーマでは、タイムゾーン識別子を使用してゼロ子午線からのオフセットを示すことができますが、このオプションは保持されてはいけません。[W3C.REC-XMLSCHEMA-2-20041028]で定義された「T」および「Z」文字を使用した拡張日付時間形式は、日付時間の値を表すために使用する必要があります。
Location responses that contain a "locationUriSet" element MUST include the expiry time in the "expires" attribute. If a Device dereferences a Location URI after the expiry time, the dereference SHOULD fail.
「locationuriset」要素を含む位置応答には、「有効期限」属性の有効期限を含める必要があります。デバイスが有効期限の終了後に位置URIを参照する場合、控除は失敗するはずです。
A single "presence" parameter MAY be included in the "locationResponse" message when specific locationTypes (e.g., "geodetic" or "civic") are requested or a "locationType" of "any" is requested. The LIS MUST follow the subset of the rules relating to the construction of the "location-info" element in the PIDF-LO Usage Clarification, Considerations, and Recommendations document [RFC5491] in generating the PIDF-LO for the presence parameter.
特定のLocationTypes（「Geodetic」または「Civic」など）が要求される場合、または「任意の」の「位置タイプ」が要求された場合、単一の「存在」パラメーターを「locationResponse」メッセージに含めることができます。LISは、存在パラメーターのPIDF-LOを生成する際に、PIDF-LO使用の明確化、考慮事項、および推奨事項ドキュメント[RFC5491]の「PIDF-LOの使用」要素の構築に関連する規則のサブセットに従う必要があります。
The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used.
LISは、識別子が正しく、アイデンティティの包含がルールメーカーによって明示的に許可されていることを確認できない限り、PIDF-LOでデバイスを識別する手段を含めてはなりません。したがって、アイデンティティを含むPIDFパラメーターは省略されるか、リンクされていない仮名を含む[RFC3693]。PIDFドキュメントの必須の存在「エンティティ」属性のために、LISによってユニークでリンクされていないプレゼンティURIを生成する必要があります。「コンタクト」や「DeviceID」要素[RFC4479]などのオプションのパラメーターは使用されていません。
Note that the presence parameter is not explicitly shown in the XML schema in Section 7 for a location response message, due to XML schema constraints, since PIDF is already defined and registered separately. Thus, the "##other" namespace serves as a placeholder for the presence parameter in the schema.
PIDFは既に個別に定義および登録されているため、XMLスキーマの制約により、位置応答メッセージのセクション7のXMLスキーマに存在パラメーターが明示的に示されていないことに注意してください。したがって、「## other」名前空間は、スキーマの存在パラメーターのプレースホルダーとして機能します。
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/held+xml" format. This is presented as a formal definition of the "application/held+xml" format. Note that the XML Schema Definition is not intended to be used with on-the-fly validation of the presence XML document. Whitespaces are included in the schema to conform to the line length restrictions of the RFC format without having a negative impact on the readability of the document. Any conforming processor should remove leading and trailing white spaces.
このセクションでは、XMLスキーマ定義[W3C.REC-XMLSCHEMA-1-20041028] [W3C.REC-XMLSCHEMA-2-20041028] [Application/Held XML]形式を示します。これは、「アプリケーション/保有XML」形式の正式な定義として提示されます。XMLスキーマ定義は、プレゼンスXMLドキュメントのオンザフライ検証で使用することを意図していないことに注意してください。ドキュメントの読みやすさにマイナスの影響を与えることなく、RFC形式のライン長制限に準拠するために、セマにホワイトスペースが含まれています。適合プロセッサは、リーディングとトレーリングの白いスペースを削除する必要があります。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
This document (RFC 5985) defines HELD messages.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<!-- Return Location -->
<xs:complexType name="returnLocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="expires" type="xs:dateTime"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- responseTime Type -->
<xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<!-- Location Type -->
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="held:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
<xs:enumeration value="locationURI"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Message Definitions -->
<xs:complexType name="baseRequestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="errorType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="message" type="held:errorMsgType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="code" type="xs:token"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="errorMsgType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="error" type="held:errorType"/>
<!-- Location Response -->
<xs:complexType name="locationResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationUriSet"
type="held:returnLocationType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationResponse"
type="held:locationResponseType"/>
<!-- Location Request -->
<xs:complexType name="locationRequestType">
<xs:complexContent>
<xs:extension base="held:baseRequestType">
<xs:sequence>
<xs:element name="locationType"
type="held:locationTypeType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationRequest"
type="held:locationRequestType"/>
</xs:schema>
This section describes the use of HTTP [RFC2616] and HTTP over TLS [RFC2818] as transport mechanisms for the HELD protocol, which a conforming LIS and Device MUST support.
このセクションでは、TLS [RFC2818]を介したHTTP [RFC2616]およびHTTPの使用を、適合性のLISとデバイスがサポートする必要があるプロトコルの輸送メカニズムとしての使用について説明します。
Although HELD uses HTTP as a transport, it uses a strict subset of HTTP features, and due to the restrictions of some features, a LIS is not a fully compliant HTTP server. It is intended that a LIS can easily be built using an HTTP server with extensibility mechanisms and that a HELD Device can trivially use existing HTTP libraries. This subset of requirements helps implementors avoid ambiguity with the many options that the full HTTP protocol offers.
HoldはHTTPをトランスポートとして使用していますが、HTTP機能の厳格なサブセットを使用しており、一部の機能の制限により、LISは完全に準拠したHTTPサーバーではありません。拡張性メカニズムを備えたHTTPサーバーを使用してLISを簡単に構築でき、保持されているデバイスは既存のHTTPライブラリを簡単に使用できることを意図しています。この要件のサブセットは、実装者が完全なHTTPプロトコルが提供する多くのオプションで曖昧さを回避するのに役立ちます。
A Device that conforms to this specification MAY choose not to support HTTP authentication [RFC2617] or cookies [RFC2965]. Because the Device and the LIS may not necessarily have a prior relationship, the LIS SHOULD NOT require a Device to authenticate, either using the above HTTP authentication methods or TLS client authentication. Unless all Devices that access a LIS can be expected to be able to authenticate in a certain fashion, denying access to location information could prevent a Device from using location-dependent services, such as emergency calling. Extensions to this protocol might result in the addition of request parameters that a LIS might use to decide to request Device authentication.
この仕様に準拠するデバイスは、HTTP認証[RFC2617]またはCookie [RFC2965]をサポートしないことを選択できます。デバイスとLISには必ずしも事前の関係があるとは限らないため、LISは、上記のHTTP認証方法またはTLSクライアント認証を使用して、デバイスを認証する必要はありません。LISにアクセスするすべてのデバイスが特定の方法で認証できると予想されない限り、位置情報へのアクセスを拒否すると、デバイスが緊急通話などの場所に依存するサービスを使用することを防ぐことができます。このプロトコルの拡張により、LISがデバイス認証を要求するために使用する可能性のある要求パラメーターが追加される可能性があります。
A HELD request is carried in the body of an HTTP POST request. The Device MUST include a Host header in the request.
HTTP POSTリクエストの本文で保留リクエストが掲載されます。デバイスには、リクエストにホストヘッダーを含める必要があります。
The MIME type of HELD request and response bodies is "application/held+xml". LIS and Device MUST provide this value in the HTTP Content-Type and Accept header fields. If the LIS does not receive the appropriate Content-Type and Accept header fields, the LIS SHOULD fail the request, returning a 406 (not acceptable) response. HELD responses SHOULD include a Content-Length header.
保有リクエストと応答団体のMIMEタイプは「アプリケーション/保留XML」です。LISとデバイスは、HTTPコンテンツタイプでこの値を提供し、ヘッダーフィールドを受け入れる必要があります。LISが適切なコンテンツタイプを受け取らず、ヘッダーフィールドを受け入れる場合、LISは要求に失敗し、406（許容されない）応答を返します。保持されている応答には、コンテンツレングスヘッダーを含める必要があります。
Devices MUST NOT use the "Expect" header or the "Range" header in HELD requests. The LIS MAY return 501 (not implemented) errors if either of these HTTP features are used. In the case that the LIS receives a request from the Device containing an If-* (conditional) header, the LIS SHOULD return a 412 (precondition failed) response.
デバイスは、保有リクエストで「予想」ヘッダーまたは「範囲」ヘッダーを使用してはなりません。LISは、これらのHTTP機能のいずれかが使用されている場合、501（実装されていない）エラーを返す場合があります。LISがif-*（条件付き）ヘッダーを含むデバイスからリクエストを受信した場合、LISは412（前提条件に失敗した）応答を返す必要があります。
The POST method is the only method REQUIRED for HELD. If a LIS chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET. Since a HELD Device only uses a POST method, the GET or HEAD MUST be either an escaped URL (e.g., somebody found a URL in protocol traces or log files and fed it into their browser) or somebody doing testing/debugging. The LIS could provide information in the HELD response indicating that the URL corresponds to a LIS server and only responds to HELD POST requests, or the LIS could instead try to avoid any leak of information by returning a very generic HTTP error message such as 404 (not found).
POSTメソッドは、保持に必要な唯一の方法です。LISがGetまたはHeadをサポートすることを選択した場合、アプリケーションの種類がGETを実行することを検討する必要があります。保持されているデバイスはPOSTメソッドのみを使用するため、GETまたはHEADはEscaped URL（たとえば、誰かがプロトコルトレースまたはログファイルでURLを見つけてブラウザに供給する）またはテスト/デバッグをしている必要があります。LISは、URLがLISサーバーに対応し、保有されたPOSTリクエストにのみ応答することを示す保有応答で情報を提供できます。または、LISが404などの非常に一般的なHTTPエラーメッセージを返すことにより、情報のリークを回避しようとすることができます（見つかりません）。
The LIS populates the HTTP headers of responses so that they are consistent with the contents of the message. In particular, the "CacheControl" header SHOULD be set to disable caching of any PIDF-LO document or Location URIs by HTTP intermediaries. Otherwise, there is the risk of stale locations and/or the unauthorized disclosure of the LI. This also allows the LIS to control any caching with the HELD "expires" parameter. The HTTP status code MUST indicate a 2xx series response for all HELD locationResponse and HELD error messages.
LISは、応答のHTTPヘッダーに浸透しているため、メッセージの内容と一致します。特に、「Cachecontrol」ヘッダーは、HTTP仲介者によるPIDF-LOドキュメントまたはロケーションURIのキャッシュを無効にするように設定する必要があります。それ以外の場合、古い場所やLIの不正な開示のリスクがあります。これにより、LISは、保持されている「有効期限」パラメーターでキャッシュを制御できます。HTTPステータスコードは、すべての保有位置Responseと保有エラーメッセージの2xxシリーズ応答を示す必要があります。
The LIS MAY redirect a HELD request. A Device MUST handle redirects by using the Location header provided by the server in a 3xx response. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the server that returns the redirect response before following the redirect, if a Device requires that the server is authenticated. A Device SHOULD authenticate the LIS indicated in a redirect.
LISは、保有リクエストをリダイレクトする場合があります。デバイスは、サーバーが3xx応答で提供しているロケーションヘッダーを使用してリダイレクトを処理する必要があります。リダイレクトするとき、デバイスは再試行後のヘッダーによって示される遅延を観察する必要があります。デバイスがリダイレクトに従う前にリダイレクト応答を返すサーバーを認証する必要があります。デバイスがサーバーが認証されることを要求する場合。デバイスは、リダイレクトで示されたLISを認証する必要があります。
The LIS SHOULD support persistent connections and request pipelining. If pipelining is not supported, the LIS MUST NOT allow persistent connections. The Device MUST support termination of a response by the closing of a connection.
LISは、永続的な接続をサポートし、パイプラインを要求する必要があります。パイプラインがサポートされていない場合、LISは永続的な接続を許可してはなりません。デバイスは、接続を閉じることにより、応答の終了をサポートする必要があります。
Implementations of HELD that implement HTTP transport MUST implement transport over TLS [RFC2818]. TLS provides message integrity and confidentiality between the Device and LIS. The Device MUST implement the server authentication method described in Section 3.1 of [RFC2818], with an exception in how wildcards are handled. The leftmost label MAY contain the wildcard string "*", which matches any single domain name label. Additional characters in this leftmost label are invalid (that is, "f*.example.com" is not a valid name and does not match any domain name).
HTTPトランスポートを実装する保有の実装は、TLS [RFC2818]を介して輸送を実装する必要があります。TLSは、デバイスとLIS間のメッセージの完全性と機密性を提供します。ワイルドカードの処理方法を例外として、デバイスは[RFC2818]のセクション3.1で説明したサーバー認証方法を実装する必要があります。左端のラベルには、ワイルドカード文字列「*」が含まれている場合があります。これには、単一のドメイン名ラベルと一致します。この左端のラベルの追加文字は無効です（つまり、「f*.example.com」は有効な名前ではなく、ドメイン名と一致しません）。
The Device uses the URI obtained during LIS discovery to authenticate the server. The details of this authentication method are provided in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD fail a request if server authentication fails, except in the event of an emergency.
デバイスは、LIS発見中に取得したURIを使用してサーバーを認証します。この認証方法の詳細は、HTTPS [RFC2818]のセクション3.1に記載されています。TLSを使用する場合、緊急事態が発生した場合を除き、サーバー認証が失敗した場合、デバイスは要求に失敗するはずです。
HELD is a location acquisition protocol whereby the client requests its location from a LIS. Specific requirements and security considerations for location acquisition protocols are provided in [RFC5687]. An in-depth discussion of the security considerations applicable to the use of Location URIs and by-reference provision of LI is included in [RFC5808].
保持されているのは、クライアントがLISからその場所を要求するロケーション取得プロトコルです。[RFC5687]では、位置取得プロトコルの特定の要件とセキュリティに関する考慮事項が提供されています。urisの使用に適用されるセキュリティ上の考慮事項に関する詳細な議論と、liのriference rifenceの提供は、[RFC5808]に含まれています。
By using the HELD protocol, the client and the LIS expose themselves to two types of risk:
保有プロトコルを使用することにより、クライアントとLISは2種類のリスクにさらされます。
Accuracy: The client receives incorrect location information.
精度：クライアントは、誤った位置情報を受信します。
Privacy: An unauthorized entity receives location information.
プライバシー：不正なエンティティは位置情報を受け取ります。
The provision of an accurate and privacy- and confidentiality-protected location to the requestor depends on the success of five steps:
要求者に正確でプライバシーおよび機密保護された場所の提供は、5つのステップの成功に依存します。
1. The client must determine the proper LIS.
1. クライアントは、適切なLIを決定する必要があります。
2. The client must connect to the proper LIS.
2. クライアントは、適切なLISに接続する必要があります。
3. The LIS must be able to identify the Device by its identifier (IP address).
3. LISは、その識別子（IPアドレス）によってデバイスを識別できる必要があります。
4. The LIS must be able to return the desired location.
4. LISは、目的の場所を返すことができなければなりません。
5. HELD messages must be transmitted unmodified between the LIS and the client.
5. 保持されたメッセージは、LISとクライアントの間に変更されていない送信されなければなりません。
Of these, only steps 2, 3, and 5 are within the scope of this document. Step 1 is based on either manual configuration or on the LIS discovery defined in [RFC5986], in which appropriate security considerations are already discussed. Step 4 is dependent on the specific positioning capabilities of the LIS and is thus outside the scope of this document.
これらのうち、手順2、3、および5のみがこのドキュメントの範囲内です。ステップ1は、[RFC5986]で定義されている手動構成または[RFC5986]で定義されたLIS発見に基づいています。ステップ4は、LISの特定のポジショニング機能に依存するため、このドキュメントの範囲外です。
This document assumes that the LIS to be contacted is identified either by an IP address or a domain name, as is the case for a LIS discovered as described in LIS Discovery [RFC5986]. When the HELD transaction is conducted using TLS [RFC5246], the LIS can authenticate its identity, either as a domain name or as an IP address, to the client by presenting a certificate containing that identifier as a subjectAltName (i.e., as an iPAddress or dNSName, respectively). In the case of the HTTP binding described above, this is exactly the authentication described by TLS [RFC2818]. If the client has external information as to the expected identity or credentials of the proper LIS (e.g., a certificate fingerprint), these checks MAY be omitted. Any binding of HELD MUST be capable of being transacted over TLS so that the client can request the above authentication, and a LIS implementation for a binding MUST include this feature. Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the LIS certificate itself.
このドキュメントは、接触するLISがIPアドレスまたはドメイン名のいずれかによって識別されることを前提としています。保有トランザクションがTLS [RFC5246]を使用して実行されると、LISは、その識別子を主題として含む証明書を提示することにより、ドメイン名またはIPアドレスとしてのIDを認証できます（つまり、iPaddressまたはまたはそれぞれdnsname）。上記のHTTP結合の場合、これはまさにTLS [RFC2818]によって記述された認証です。クライアントが、適切なLISの予想されるIDまたは資格情報に関する外部情報を持っている場合（例：証明書指紋）、これらのチェックは省略される場合があります。保有の拘束力は、クライアントが上記の認証を要求できるように、TLSを介して取引できる必要があり、バインディングのLIS実装にはこの機能を含める必要があります。提示された証明書がクライアントで有効になるためには、クライアントが証明書を検証できる必要があることに注意してください。特に、証明書の検証パスは、その信頼アンカーがLIS証明書自体であっても、クライアントの信頼アンカーの1つで終了する必要があります。
In order to prevent that response from being modified en route, messages must be transmitted over an integrity-protected channel. When the transaction is being conducted over TLS (a required feature per Section 9.1), the channel will be integrity protected by appropriate ciphersuites. When TLS is not used, this protection will vary depending on the binding; in most cases, without protection from TLS, the response will not be protected from modification en route.
その応答が途中で変更されるのを防ぐために、整合性保護チャネルを介してメッセージを送信する必要があります。トランザクションがTLSを介して実施されている場合（セクション9.1あたりの必要な機能）、チャネルは適切な暗号筋によって整合性が保護されます。TLSが使用されない場合、この保護はバインディングによって異なります。ほとんどの場合、TLSからの保護がなければ、応答は途中の変更から保護されません。
Location information returned by the LIS must be protected from access by unauthorized parties, whether those parties request the location from the LIS or intercept it en route. As in Section 9.2, transactions conducted over TLS with appropriate ciphersuites are protected from access by unauthorized parties en route. Conversely, in most cases, when not conducted over TLS, the response will be accessible while en route from the LIS to the requestor.
LISによって返された位置情報は、不正な当事者によるアクセスから保護されている必要があります。これらの当事者は、LISから場所を要求するか、途中で傍受するかを要求する必要があります。セクション9.2と同様に、適切な衝突物を使用してTLSを介して実施されたトランザクションは、途中で不正な当事者によるアクセスから保護されます。逆に、ほとんどの場合、TLSを介して実行されていない場合、LISからリクエスターへの途中で応答にアクセスできます。
Because HELD is an LCP and identifies clients and targets by IP addresses, a requestor is authorized to access location for an IP address only if it is the holder of that IP address. The LIS MUST verify that the client is the target of the returned location, i.e., the LIS MUST NOT provide location to other entities than the target. Note that this is a necessary, but not sufficient, criterion for authorization. A LIS MAY deny requests according to any local policy.
保持されているのはLCPであり、IPアドレスごとにクライアントとターゲットを識別するため、要求者はIPアドレスの所有者である場合にのみ、IPアドレスの場所にアクセスすることが許可されます。LISは、クライアントが返された場所のターゲットであることを確認する必要があります。つまり、LISはターゲット以外のエンティティに場所を提供してはなりません。これは必要ではあるが、十分ではない許可の基準であることに注意してください。LISは、ローカルポリシーに従ってリクエストを拒否する場合があります。
A prerequisite for meeting this requirement is that the LIS must have some assurance of the identity of the client. Since the target of the returned location is identified by an IP address, simply sending the response to this IP address will provide sufficient assurance in many cases. This is the default mechanism in HELD for assuring that location is given only to authorized clients; LIS implementations MUST support a mode of operation in which this is the only client authentication.
この要件を満たすための前提条件は、LISがクライアントの身元をある程度保証する必要があることです。返された場所のターゲットはIPアドレスによって識別されるため、このIPアドレスに応答を送信するだけで十分な保証が提供されます。これは、場所が認可されたクライアントのみに与えられることを保証するためのデフォルトのメカニズムです。LIS実装は、これが唯一のクライアント認証である操作モードをサポートする必要があります。
Using IP return routability as an authenticator means that location information is vulnerable to exposure through IP address spoofing attacks. A temporary spoofing of an IP address could mean that when a Device requests a Location Object or Location URI, it receives another Device's location because the attacker is able to receive packets sent to the spoofed address. In addition, in cases where a Device drops off the network for various reasons, the re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location. These exposures are limited by the following:
AuthenticatorとしてIP Returnルーティング可能性を使用することは、位置情報がIPアドレスのスプーフィング攻撃を介して露出に対して脆弱であることを意味します。IPアドレスの一時的なスプーフィングは、デバイスがロケーションオブジェクトまたはロケーションURIを要求する場合、攻撃者がスプーフィングされたアドレスに送信されたパケットを受信できるため、別のデバイスの場所を受信することを意味します。さらに、デバイスがさまざまな理由でネットワークを落とす場合、デバイスのIPアドレスの再利用により、独自の場所ではなく、元のデバイスの場所を受信する別のデバイスが得られる可能性があります。これらの露出は以下によって制限されます。
o Location URIs MUST have a limited lifetime, as reflected by the value for the "expires" element in Section 6.5.2. The lifetime of Location URIs necessarily depends on the nature of the access.
o セクション6.5.2の「有効期限」要素の値に反映されているように、urisの位置は限られた寿命を持っている必要があります。urisの場所の寿命は、必然的にアクセスの性質に依存します。
o The LIS and network SHOULD be configured so that the LIS is made aware of Device movement within the network and addressing changes. If the LIS detects a change in the network that results in it no longer being able to determine the location of the Device, then all Location URIs for that Device SHOULD be invalidated.
o LISとネットワークを構成して、LISがネットワーク内のデバイスの動きと対処の変更を認識できるようにする必要があります。LISがネットワークの変更を検出して、デバイスの位置を決定できなくなった場合、そのデバイスのすべての位置URIは無効にする必要があります。
The above measures are dependent on network configuration, which SHOULD be considered. For instance, in a fixed Internet access, providers may be able to restrict the allocation of IP addresses to a single physical line, ensuring that spoofing is not possible; in such an environment, additional measures may not be necessary.
上記の測定値は、ネットワーク構成に依存しており、考慮する必要があります。たとえば、固定されたインターネットアクセスでは、プロバイダーはIPアドレスの割り当てを単一の物理ラインに制限し、スプーフィングが不可能であることを確認できる場合があります。このような環境では、追加の措置は必要ない場合があります。
The following sections provide examples of basic HTTP/HTTPS, a simple location request, and a location request for multiple location types, along with the relevant location responses. To focus on important portions of messages, the examples in Sections 10.2 and 10.3 do not show HTTP/HTTPS headers or the XML prologue. In addition, sections of XML not relevant to the example are replaced with comments.
次のセクションでは、基本的なHTTP/HTTPS、簡単な場所リクエスト、および複数のロケーションタイプのロケーションリクエストと、関連するロケーション応答の例を示します。メッセージの重要な部分に焦点を当てるために、セクション10.2および10.3の例には、HTTP/HTTPSヘッダーまたはXMLプロローグが表示されません。さらに、例に関連しないXMLのセクションはコメントに置き換えられます。
The examples in this section show complete HTTP/HTTPS messages that include the HELD request or response document.
このセクションの例は、保有リクエストまたは応答ドキュメントを含む完全なHTTP/HTTPSメッセージを示しています。
This example shows the most basic request for a LO. The POST includes an empty "locationRequest" element.
この例は、LOの最も基本的な要求を示しています。投稿には、空の「LocationRequest」要素が含まれています。
POST /location HTTP/1.1
Host: lis.example.com:49152
Content-Type: application/held+xml;charset=utf-8
Content-Length: 87
<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Since the above request does not include a "locationType" element, the successful response to the request may contain any type of location. The following shows a response containing a minimal PIDF-LO.
上記のリクエストには「LocationType」要素が含まれていないため、リクエストに対する応答が成功するには、あらゆるタイプの場所が含まれる場合があります。以下は、最小限のPIDF-LOを含む応答を示しています。
HTTP/1.1 200 OK
Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 856
<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<gbp:retention-expiry>2006-01-11T03:42:28+00:00
</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
The error response to the request is an error document. The following response shows an example error response.
リクエストに対するエラー応答はエラードキュメントです。次の応答は、エラー応答の例を示しています。
HTTP/1.1 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 182
<?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Unable to determine location
</message>
</error>
The location request shown below doesn't specify any location types or response time.
以下に示す場所の要求には、ロケーションの種類や応答時間が指定されていません。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of Location URIs.
この場所リクエストに対する例の応答には、urisの場所のリストが含まれています。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
</locationResponse>
An error response to this location request is shown below:
この場所のリクエストに対するエラー応答を以下に示します。
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Location not available
</message>
</error>
The following Location Request message includes a request for geodetic, civic, and any Location URIs.
次のロケーションリクエストメッセージには、測地測定、シビック、および任意のロケーションURIのリクエストが含まれています。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">
geodetic
civic
locationURI
</locationType>
</locationRequest>
The corresponding Location Response message includes the requested location information, including two Location URIs.
対応するロケーション応答メッセージには、2つのロケーションURIを含む要求された位置情報が含まれています。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<gs:Circle xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius>
</gs:Circle>
<ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
<usage-rules
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2007-05-25T12:35:02+10:00
</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</locationResponse>
IANA has made the registrations detailed in the following sections.
IANAは、登録を次のセクションで詳しく説明しました。
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：hold」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、Mary Barnes（mary.ietf.barnes@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Messages</title>
</head>
<body>
<h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2>
<p>See RFC 5985</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、Mary Barnes（mary.ietf.barnes@gmail.com）。
Schema: The XML for this schema can be found as the entirety of Section 7 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション7全体として見つけることができます。
This section registers the "application/held+xml" MIME type.
このセクションでは、「アプリケーション/保有XML」MIMEタイプを登録します。
To: ietf-types@iana.org
宛先：ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: held+xml
MIMEサブタイプ名：XMLを保持します
Required parameters: (none)
必要なパラメーター：（なし）
Optional parameters: charset Same as the charset parameter of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
オプションのパラメーター：RFC 3023 [RFC3023]で指定されている「アプリケーション/XML」のcharsetパラメーターと同じcharset、セクション3.2。
Encoding considerations: Same as the encoding considerations of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
エンコーディングの考慮事項：RFC 3023 [RFC3023]、セクション3.2で指定されている「アプリケーション/XML」のエンコーディングに関する考慮事項と同じ。
Security considerations: This content type is designed to carry protocol data related to the location of an entity, which could include information that is considered private. Appropriate precautions should be taken to limit disclosure of this information.
セキュリティ上の考慮事項：このコンテンツタイプは、プライベートと見なされる情報を含めることができるエンティティの場所に関連するプロトコルデータを携帯するように設計されています。この情報の開示を制限するために適切な予防措置を講じる必要があります。
Interoperability considerations: This content type provides a basis for a protocol. There are multiple interoperable implementations of this protocol.
相互運用性の考慮事項：このコンテンツタイプは、プロトコルの基礎を提供します。このプロトコルには複数の相互運用可能な実装があります。
Published specification: RFC 5985
公開された仕様：RFC 5985
Applications which use this media type: Location information providers and consumers.
このメディアタイプを使用するアプリケーション：位置情報プロバイダーと消費者。
Additional Information:
Magic Number(s): (none)
File extension(s): .heldxml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
Mary Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller: The IETF
著者/変更コントローラー：IETF
Other information: This media type is a specialization of application/xml [RFC3023], and many of the considerations described there also apply to application/held+xml.
その他の情報：このメディアタイプは、アプリケーション/XML [RFC3023]の専門化であり、そこに記載されている考慮事項の多くは、アプリケーション/保有XMLにも適用されます。
As defined in this document, IANA created a new registry for the HELD protocol including an initial registry for error codes. The error codes are included in HELD error messages as described in Section 6.3 and defined in the schema in the 'codeType' token in the XML schema in Section 7.
このドキュメントで定義されているように、IANAは、エラーコードの初期レジストリを含む、保有プロトコルの新しいレジストリを作成しました。エラーコードは、セクション6.3で説明されているように保持されたエラーメッセージに含まれており、セクション7のXMLスキーマの「Codetype」トークンのスキーマで定義されています。
The following is a summary of the registry:
以下は、レジストリの概要です。
Related Registry: Geopriv HELD Registries, Error codes for HELD
関連レジストリ：GEOPRIVが保持しているレジストリ、保有のエラーコード
Defining RFC: RFC 5985 Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the Error codes for HELD is Standards Action: Values are assigned only for Standards Track RFCs approved by the IESG.
RFCの定義：RFC 5985登録/割り当て手順：[RFC5226]で概説されているポリシーに従って、保有のエラーコードの新しい値を割り当てるためのIANAポリシーは標準アクションです。
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、Mary Barnes（mary.ietf.barnes@gmail.com）。
This section registers the following eight initial error codes as described in Section 6.3:
このセクションでは、セクション6.3で説明されている次の8つの初期エラーコードを登録します。
requestError: This code indicates that the request was badly formed in some fashion.
RequestError：このコードは、リクエストが何らかの形でひどく形成されたことを示しています。
xmlError: This code indicates that the XML content of the request was either badly formed or invalid.
XMLERROR：このコードは、リクエストのXMLコンテンツがひどく形成されたか無効であることを示しています。
generalLisError: This code indicates that an unspecified error occurred at the LIS.
Generalliserror：このコードは、LISで不特定のエラーが発生したことを示しています。
locationUnknown: This code indicates that the LIS could not determine the location of the Device.
locationnknown：このコードは、LISがデバイスの位置を決定できなかったことを示しています。
unsupportedMessage: This code indicates that the request was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver.
UnsportedMessage：このコードは、リクエストがLISによってサポートまたは理解されていないことを示しています。このエラーコードは、保有リクエストにレシーバーによってサポートされていないドキュメント要素が含まれている場合に使用されます。
timeout: This code indicates that the LIS could not satisfy the request within the time specified in the "responseTime" parameter.
タイムアウト：このコードは、LISが「応答」パラメーターで指定された時間内にリクエストを満たすことができなかったことを示しています。
cannotProvideLiType: This code indicates that the LIS was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true".
Canible ProvidelityPe：このコードは、LISが要求されたタイプまたはタイプのLIを提供できなかったことを示しています。このコードは、「locationType」パラメーターの「正確な」属性が「true」に設定されている場合に使用されます。
notLocatable: This code indicates that the LIS is unable to locate the Device and that the Device MUST NOT make further attempts to retrieve LI from this LIS. This error code is used to indicate that the Device is outside the access network served by the LIS; for instance, the VPN and NAT scenarios discussed in Section 4.1.2.
locatable：このコードは、LISがデバイスを見つけることができないこと、およびデバイスがこのLIからLIを取得しようとしないことをデバイスがさらに試みてはならないことを示しています。このエラーコードは、デバイスがLISが提供するアクセスネットワークの外側にあることを示すために使用されます。たとえば、セクション4.1.2で説明したVPNおよびNATシナリオ。
James Winterbottom, Martin Thomson and Barbara Stark are the authors of the original document, from which this WG document was derived. Their contact information is included below. They made additional contributions to the WG document, including the XML schema.
James Winterbottom、Martin Thomson、Barbara Starkは、このWGドキュメントが導き出された元の文書の著者です。それらの連絡先情報は以下に含まれています。彼らは、XMLスキーマを含むWGドキュメントに追加の貢献をしました。
James Winterbottom Andrew Andrew Building (39) University of Wollongong Northfields Avenue Wollongong, NSW 2522 AU
ジェームズ・ウィンターボトムアンドリューアンドリュービルディング（39）ウロンゴン大学ノースフィールズアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Martin Thomson Andrew Andrew Building (39) University of Wollongong Northfields Avenue Wollongong, NSW 2522 AU
マーティントムソンアンドリューアンドリュービルディング（39）ウロンゴン大学ノースフィールズアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Barbara Stark BellSouth Room 7A43 725 W Peachtree St. Atlanta, GA 30308 US
バーバラスタークベルサウスルーム7A43 725 Wピーチツリーセントアトランタ、ジョージア州30308米国
EMail: barbara.stark@att.com
The author and contributors would like to thank the participants in the GEOPRIV WG and the following people for their constructive input and feedback on this document (in alphabetical order): Nadine Abbott, Bernard Aboba, Eric Arolick, Richard Barnes (in particular, the security considerations section), Peter Blatherwick, Ben Campbell, Guy Caron, Eddy Corbett, Martin Dawson, Lisa Dusseault, Robins George, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Alexey Melnikov, Roger Marshall, Tim Polk, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Dan Romascanu, Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug Stuard, Hannes Tschofenig, and Karl Heinz Wolf.
著者と貢献者は、Geopriv WGの参加者と、この文書に関する建設的な入力とフィードバックについて（アルファベット順に）参加してくれたことに感謝します。考慮事項セクション）、ピーター・ブラザーウィック、ベン・キャンベル、ガイ・キャロン、エディ・コーベット、マーティン・ドーソン、リサ・デュッセー、ロビンズ・ジョージ、ジェローム・グレニエ、テッド・ハーディ、カレン・ジェニングス、ニール・ジャストソン、タット・ラム、マーク・リンズナー、パティ・マッカルモント、アレクシー・メルニコフ、ロジャーマーシャル、ティム・ポーク、ペリー・プロゼニウク、カール・リード、ジュリアン・レシュケ、エリック・レスカルラ、ダン・ロマスカヌ、ブライアン・ローゼン、ジョン・シューナズレイン、シダ・シューベルト、ヘニング・シュルズリン、エド・シュラム、ダグ・スチュアード、ハンヌ・チョーフェニグ、カール・ハインズ・ウルフ。
[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月。
[RFC2616] 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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965] Kristol、D。およびL. Montulli、「HTTP状態管理メカニズム」、RFC 2965、2000年10月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「Geopriv存在情報データ形式の場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項」、RFC 5491、2009年3月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986] Thomson、M。およびJ. Winterbottom、「Local Location Information Server（LIS）の発見」、RFC 5986、2010年9月。
[W3C.REC-xmlschema-1-20041028] Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-XMLSCHEMA-1-20041028] Thompson、H.、Mendelsohn、N.、Beech、D。、およびM. Maloney、「XML Schema Part 1：Structures Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-1-20041028、2004年10月、<http://www.w3.org/tr/2004/rec-xmlschema-1-20041028>。
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2-20041028] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-20041028、2004年10月、<http：//www.w3.org/tr/2004/rec-xmlschema-2-20041028>。
[LLDP-MED] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint Discovery".
[LLDP-MED] TIA、「ANSI/TIA-1057リンクレイヤーディスカバリープロトコル - メディアエンドポイントディスカバリー」。
[LOC-CONVEY] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", Work in Progress, July 2010.
[Loc Convey] Polk、J.、Rosen、B。、およびJ. Peterson、「セッション開始プロトコルの位置輸送」、2010年7月に進行中の作業。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825] Polk、J.、Schnizlein、J。、およびM. Linsner、「座標ベースの位置構成情報の動的ホスト構成プロトコルオプション」、RFC 3825、2004年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「Geopriv Layer 7位置構成プロトコル：問題ステートメントと要件」、RFC 5687、2010年3月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808] Marshall、R。、「場所ごとのメカニズムの要件」、RFC 5808、2010年5月。
This appendix describes HELD's compliance to the requirements specified in [RFC5687].
この付録では、[RFC5687]で指定された要件に対するHoldのコンプライアンスについて説明しています。
"The L7 LCP MUST be able to carry different identifiers or MUST define an identifier that is mandatory to implement. Regarding the latter aspect, such an identifier is only appropriate if it is from the same realm as the one for which the location information service maintains identifier to location mapping."
「L7 LCPは、異なる識別子を運ぶことができなければなりません。または、実装することが必須の識別子を定義する必要があります。後者の側面に関しては、そのような識別子は、位置情報サービスが維持する領域と同じ領域からの場合にのみ適切です。ロケーションマッピングの識別子。」
COMPLY
準拠
HELD uses the IP address of the location request message as the primary source of identity for the requesting Device or target. This identity can be used with other contextual network information to provide a physical location for the Target for many network deployments. There may be network deployments where an IP address alone is insufficient to identify a Target in a network. However, any necessary identity extensions for these networks is beyond the scope of this document.
Heldは、要求デバイスまたはターゲットのIDリクエストメッセージのIPアドレスを使用します。このIDは、他のコンテキストネットワーク情報とともに使用して、多くのネットワーク展開のターゲットの物理的な位置を提供できます。ネットワーク内のターゲットを識別するには、IPアドレスのみが不十分なネットワーク展開がある場合があります。ただし、これらのネットワークに必要なID拡張は、このドキュメントの範囲を超えています。
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a broad range of mobility from Devices that can only move between reboots, to Devices that can change attachment points with the impact that their IP address is changed, to Devices that do not change their IP address while roaming, to Devices that continuously move by being attached to the same network attachment point."
「GEOPRIVレイヤー7ロケーション構成プロトコルは、再起動間でのみ移動できるデバイス、IPアドレスが変更される影響により添付ファイルポイントを変更できるデバイス、IPアドレスを変更しないデバイスに幅広いモビリティをサポートする必要があります。ローミング中、同じネットワークアタッチメントポイントに接続されて継続的に移動するデバイスに。」
COMPLY
準拠
Mobility support is inherently a characteristic of the access network technology, and HELD is designed to be access network agnostic. Consequently, HELD complies with this requirement. In addition, HELD provides specific support for mobile environments by providing an optional responseTime attribute in location request messages. Wireless networks often have several different mechanisms at their disposal for position determination (e.g., assisted GPS versus determining the location based on the identity of the serving base station), each providing different degrees of accuracy and taking different amounts of time to yield a result. The responseTime parameter provides the LIS with a criterion which it can use to select a location determination technique.
モビリティサポートは本質的にアクセスネットワークテクノロジーの特徴であり、Hellはアクセスネットワーク不可知論者になるように設計されています。その結果、HALDはこの要件に準拠しています。さらに、Holdは、ロケーションリクエストメッセージにオプションの応答属性を提供することにより、モバイル環境に特定のサポートを提供します。ワイヤレスネットワークには、多くの場合、位置決定のためにいくつかの異なるメカニズムが自由に使用されています（たとえば、Assisted GPS対サービングベースステーションのアイデンティティに基づいて位置を決定する）。ResponseTimeパラメーターは、LISに、位置決定手法を選択するために使用できる基準を提供します。
"The design of the L7 LCP MUST NOT assume a business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. Requirements for resolving a reference to location information are not discussed in this document."
「L7 LCPの設計は、アプリケーションサービスプロバイダー（ASP）とアクセスネットワークプロバイダーとの間のビジネスまたは信頼関係を想定してはなりません。位置情報を解決するための要件については、このドキュメントでは説明されていません。」
COMPLY
準拠
HELD describes a location acquisition protocol between a Device and a LIS. In the context of HELD, the LIS is within the Access Network. Thus, HELD is independent of the business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. Location acquisition using HELD is subject to the restrictions described in Section 9.
開催されたのは、デバイスとLIS間のロケーション取得プロトコルについて説明しています。保有のコンテキストでは、LISはアクセスネットワーク内にあります。したがって、保有は、アプリケーションサービスプロバイダー（ASP）とアクセスネットワークプロバイダーとの間のビジネスまたは信頼関係とは無関係です。保留を使用した場所の取得は、セクション9で説明されている制限の対象となります。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that there is a trust and business relationship between the L2 and the L3 provider. The L3 provider operates the LIS and needs to obtain location information from the L2 provider since this one is closest to the end host. If the L2 and L3 provider for the same host are different entities, they cooperate for the purposes needed to determine end system locations."
「Geoprivレイヤー7の設計7位置構成プロトコルは、L2とL3プロバイダーの間に信頼とビジネス関係があると想定する必要があります。L3プロバイダーはLISを動作させ、LISプロバイダーから位置情報を取得する必要があります。エンドホスト。同じホストのL2およびL3プロバイダーが異なるエンティティである場合、エンドシステムの位置を決定するために必要な目的のために協力します。」
COMPLY
準拠
HELD was specifically designed with this model in mind and readily allows itself to chaining requests between operators without a change in protocol being required. HELD is a webservices protocol which can be bound to transports other than HTTP, such as BEEP. Using a protocol such as BEEP offers the option of high request throughput over a dedicated connection between an L3 provider and an L2 provider without incurring the serial restriction imposed by HTTP. This is less easy to do with protocols that do not decouple themselves from the transport.
保持されたものは、このモデルを念頭に置いて特別に設計されており、プロトコルの変更を必要とせずにオペレーター間で要求をチェーンすることを容易に可能にします。Holdは、BeepなどのHTTP以外のトランスポートにバインドできるWebサービスプロトコルです。Beepなどのプロトコルを使用すると、HTTPによって課されるシリアル制限を発生させることなく、L3プロバイダーとL2プロバイダーの間の専用接続を介した高リクエストスループットのオプションが提供されます。これは、輸送から自分自身を切り離さないプロトコルではそれほど簡単ではありません。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST consider legacy residential NAT Devices and Network Termination Equipment (NTE) in an DSL environment that cannot be upgraded to support additional protocols, for example to pass additional information through DHCP." COMPLY
「Geoprivレイヤー7の設計7位置構成プロトコルは、DHCPを通じて追加情報を渡すために、追加のプロトコルをサポートするためにアップグレードできないDSL環境で、Legacy Residential Nat Devicesとネットワーク終了機器（NTE）を考慮する必要があります。」準拠
HELD is an application protocol and operates on top of IP. A HELD request from a host behind a residential NAT will traverse the NAT acquiring the external address of the home router. The location provided to the host therefore will be the address of the home router in this circumstance. No changes are required to the home router in order to support this function, HELD was designed specifically to address this deployment scenario.
保持されているのはアプリケーションプロトコルであり、IPの上で動作します。住宅のNATの背後にあるホストからの保留リクエストは、NATを横断し、ホームルーターの外部アドレスを取得します。したがって、ホストに提供される場所は、この状況ではホームルーターの住所になります。この機能をサポートするために、ホームルーターに変更は必要ありません。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that at least one end of a VPN is aware of the VPN functionality. In an enterprise scenario, the enterprise side will provide the LIS used by the client and can thereby detect whether the LIS request was initiated through a VPN tunnel."
「Geoprivレイヤー7の設計7位置構成プロトコルは、VPNの少なくとも片端がVPN機能を認識していることを想定する必要があります。エンタープライズシナリオでは、エンタープライズ側はクライアントが使用するLIを提供し、それにより、それにより検出できるかどうかを検出できます。LISリクエストは、VPNトンネルを介して開始されました。」
COMPLY
準拠
HELD does not preclude a LIS on the far end of a VPN tunnel from being aware that the client request is occurring over that tunnel. It also does not preclude a client Device from accessing a LIS serving the local physical network and subsequently using the location information with an application that is accessed over a VPN tunnel.
Holdは、VPNトンネルの遠端でのLISを、クライアントの要求がそのトンネルを介して発生していることを認識することを妨げません。また、クライアントデバイスがローカルの物理ネットワークにサービスを提供し、その後VPNトンネルにアクセスされるアプリケーションで位置情報を使用することをクライアントデバイスに排除することはできません。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume prior network access authentication."
「Geoprivレイヤー7位置構成プロトコルの設計は、以前のネットワークアクセス認証を想定してはなりません。」
COMPLY
準拠
HELD makes no assumptions about prior network access authentication. HELD strongly recommends the use of TLS with server-side certificates for communication between the endpoint and the LIS. There is no requirement for the endpoint to authenticate with the LIS.
Heldは、以前のネットワークアクセス認証について仮定しません。HALDは、エンドポイントとLIS間の通信のためにサーバー側の証明書を使用してTLSを使用することを強く推奨しています。エンドポイントがLISで認証するための要件はありません。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume end systems being aware of the access network topology. End systems are, however, able to determine their public IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." COMPLY
「Geoprivレイヤー7位置構成プロトコルの設計は、アクセスネットワークトポロジを認識しているエンドシステムを想定してはなりません。ただし、ENDシステムは、STUNやNSIS NATFW NSLPなどのメカニズムを介してパブリックIPアドレスを決定できます。「準拠
HELD makes no assumption about the network topology. HELD doesn't require that the Device know its external IP address, except where that is required for discovery of the LIS.
開催されたのは、ネットワークトポロジについては想定していません。Holdは、LISの発見に必要な場合を除き、デバイスが外部IPアドレスを知ることを必要としません。
"The L7 LCP MUST define a single mandatory to implement discovery mechanism."
「L7 LCPは、発見メカニズムを実装するために単一の必須を定義する必要があります。」
COMPLY
準拠
HELD uses the discovery mechanism in [RFC5986].
[RFC5986]の発見メカニズムを使用しています。
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the <geopriv> element into the <device> element of the presence document (see RFC 4479). This ensures that the resulting PIDF-LO document, which is subsequently distributed to other entities, conforms to the rules outlined in [now RFC 5941]."
「lisがRFC 4119ごとにpidf-loを作成すると、<geopriv>要素を存在ドキュメントの<device>要素に配置する必要があります（RFC 4479を参照）。これにより、結果のpidf-loドキュメントが保証されます。他のエンティティに分配され、[Now RFC 5941]で概説されているルールに準拠しています。
COMPLY
準拠
HELD protocol overview (Section 4) describes the requirements on the LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated by the LIS MUST conform to [RFC5491].
開催されたプロトコルの概要（セクション4）は、PIDF-LOの作成におけるLISの要件を説明し、LISによって生成されたPIDF-LOが[RFC5491]に適合しなければならないことを規定しています。
Author's Address
著者の連絡先
Mary Barnes (editor) Polycom
メアリーバーンズ（編集者）ポリコム
EMail: mary.ietf.barnes@gmail.com