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)
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場所構成プロトコル（LCP L7）を定義し、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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]は、デバイスが位置情報を提供するために、そのアクセスネットワークに依存している可能性のあるいくつかのシナリオを提供します。位置情報サーバ（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は、デバイスは、参照によりそのLIを配布することができ、ロケーションURIまたは場所のURIのセットの形で位置参照を提供することを要求してもよいです。これらの方法の両方は、位置情報の異なるタイプのアプリケーションの要件に対応するために、同じ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.
この仕様は、デバイスによってLISからの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）。 L7 LCP問題の声明と要件文書[RFC5687]で定義されている用語の場所情報サーバー（LIS）、アクセスネットワーク、アクセスプロバイダ（AP）、およびアクセスネットワークプロバイダは、同じ文脈で使用されています。用語シビック所在地/住所や測地場所の使用は、参照文書の多くで使用法に従っています。
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が決定される方法を指定しません。デバイス（およびターゲット）が彼らのLIを取得できるように、アクセスプロバイダ（AP）は、LISを運営しています。この文書では、デバイスとアクセスプロバイダは、デバイスがネットワークへのアクセスを取得するために必要なもの以外の前に関係を持っていないことを前提としています。
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
次の図は、[RFC5687]で定義された[RFC3693]で識別された機能要素とLISの一部の論理的な構成を示しています。このプロトコルは、規則で、適用される場合、それはまた、表示さ
Maker and Target represented by the role of the Device. Note that only the interfaces relevant to the Device are identified in the diagram.
デバイスの役割で表さメーカーとターゲット。デバイスに関連する唯一のインタフェースは図において識別されることに留意されたいです。
+---------------------------------------------+
| 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].
図中のAPPアノテーションで示され、それは文書の範囲外であるとして、ロケーションの宛先（LR）とデバイス及び/又はLISとの間のインターフェースは、アプリケーション固有です。デバイスとの間のLR APPインターフェースの例は、[LOC-伝える] SIPロケーション搬送文書に見出すことができます。
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]に記載されているように、装置は、第一HELDプロトコル要求を送信するためのLISのURIを発見しなければなりません。 LISのURIは、許可および認証エンティティから得られるべきです。適切なLISが接触されることを確保するための詳細は、セクション9および特定のセクション9.1に提供されます。 LIS発見プロトコルの詳細は、この文書の範囲外であり、[RFC5986]に規定されています。 LISの発見により提供される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.
HELDプロトコルの使用は、位置を決定するために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.
VPNは、（例えば、在宅勤務者のための）デバイスとLISとの間に存在する一方、その後、企業ネットワーク内の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.
セキュリティ目的のために、またはこのような従来の他のサーバーへの接続を確立するにLISに自分のHELDクエリを実行する必要がありVPNサーバ、SOCKSサーバ、およびHTTPプロキシサーバとしてサーバに接続するミドルボックスを横断、デバイスの接続またはトンネルセットアップの影響を最小限に抑えるために、 。発見[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.
メディアエンドポイント発見[LLDP-MED] - VPNデバイスは、動的ホスト構成プロトコル（DHCP）[RFC3825]またはリンク層検出プロトコルなどの他の場所の設定オプションについては、LISとして機能することも有用である可能性があります。この場合、LISとしてのVPN装置は、第1のHELD用いて自身の位置を取得することができます。
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オペレータは、LISが正しくNATまたはVPNのリモート側のデバイスを示す識別子が設定されていることを確認する必要があります。 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]における「位置情報」要素の構造に関連するこれらの規則の部分集合に従わなければなりません。さらなる詳細は、「プロトコル・パラメータ」（第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ロケーション受信者（LR）はLIを取得するために使用できる任意のスキームのURI [RFC3986]です。 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で説明したように、HELDプロトコルがLISからPIDF-LOのドキュメント及び/又はロケーションURI（S）の形でデバイスの位置の検索を提供します。なLocationRequest、locationResponse、及びエラー：3つのメッセージは、ロケーション検索をサポートするために定義されています。
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に記載されています。デバイスからロケーション要求メッセージは、位置及び/又は場所URI（S）（特定の場所のタイプ（複数可）を有する）PIDF-LOの文書の形式で返されるべきかどうかを示します。成功の場合、LISは、PIDF-LOの文書および/または1つ以上の場所のURIを含むlocationResponseメッセージで応答します。エラーの場合、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.
HELDプロトコルメッセージはUTF-8でエンコードされなければならないXML文書として定義されています。 「アプリケーション/開催+ xmlの」MIMEタイプは、他のXML文書本体に開催されたメッセージを区別するために、セクション11.3に登録されています。この仕様は、タイプの命名規則（「+ XML」サフィックス）と「文字セット」パラメータの使用を含む、[RFC3023]に記載お薦めや規則に従います。 「文字セット」パラメータは、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] HELDメッセージを輸送します。
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へのデバイスから送信されます。デバイスの要求は「locationType」要素に含まれるLIの種類によって決定されること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はunsupportedMessageエラーコードでエラーを返さなければなりません。
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.
エラー応答はまた、追加の情報を含めることができる「メッセージ」属性を含むかもしれません。この情報は、診断目的のためにする必要があり、任意の言語であってもよいです。属性：メッセージの言語は、「LANG XML」で示されるべきです。
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」属性は、デバイスが応答またはデバイスが場所を必要とする目的のために待機する準備がどのくらいLISに示す時間値を含みます。
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」と「emergencyDispatch」に定義されている値は、おそらく管轄ポリシーによって管理され、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.
「RESPONSETIME」属性の時間値をミリ秒単位で負でない整数として表現されます。時間値は唯一の指標である、と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は、入力として「RESPONSETIME」属性の時間の値を使用することができます。 「RESPONSETIME」属性が存在しない場合は、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.
いかなる：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.
市民：LISは、標的のための市民のアドレスの形式で値によって位置を返すべきです。
locationURI: The LIS SHOULD return a set of Location URIs for the Target.
locationURI：LISは、ターゲットの場所のURIのセットを返すべきです。
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は、オプションの「正確な」属性の設定に依存して返します。 「正確な」属性が「真」に設定されている場合、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）と「正確な」属性の要求が「偽」である場合は、LISは、追加の場所の種類を提供したり、要求は要求された場所の種類について満足できない場合には、代替の種類を提供することができます。特定の場所の種類については、このパラメータに「SHOULD」-Strength要件は、ソフトのフェールオーバーを可能にするために含まれています。これは、その場所の種類が使用できない場合、ロケーション要求が失敗することなく、特定の場所の種類を好む固定のクライアント構成を可能にします。例えば、ノートブックコンピュータは、典型的な家庭や仕事の状況から通常入手可能である、市民のアドレスを取得するように構成することができます。無線モデムを使用した場合しかし、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.
プロトコルはちょうど場所の種類のサブセットのいずれかを受信するための要求をサポートしていないことに留意すべきです。例えば、装置は単に「測地」または「市民」の優先度を有する場合には、両方の場所のタイプを含む、「正確な」属性なしで要求する必要があります。どちらも利用可能である場合に利用可能な場合この場合は、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」要素に含まれていたのと同じ順序で応答して場所を提供すべきです。実際に、「正確な」属性が「偽」に設定されている要求内の特定の場所の種類を含めての主な利点は、1つの特定のために利用可能な場所を受け取る保証することです。例えば、「市民」のなLocationRequestは、応答内の次の場所の種類のいずれかをもたらし得ます。
o civic
市民O
o civic, geodetic
O市民、測地
o civic, locationURI
O市民、locationURI
o civic, geodetic, locationURI
O市民、測地、locationURI
o civic, locationURI, geodetic
O市民、locationURI、測地
o geodetic, locationURI (only if civic is not available)
測地O、locationURI（市民が利用できない場合のみ）
o locationURI, geodetic (only if civic is not available)
O locationURI、測地（市民が利用できない場合のみ）
o geodetic (only if civic is not available)
O測地（市民が利用できない場合のみ）
o locationURI (only if civic is not available)
O locationURI（市民が利用できない場合のみ）
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」要素が含まれている場合、「厳密な」属性は、位置要求メッセージに含まれるかもしれません。 「正確な」属性が「真」に設定されている場合、それは「locationType」パラメータの内容は厳密に従わなければなりませんことをLISに示します。 「偽」のデフォルト値はLISにのみ市民の場所が要求されたときにそのような場所のURIのセットとして指定されているものを超えた何かを、返却のオプションを可能にします。
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".
「真」の値は、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をトランスポートとして使用される場合、例えば、HELDエラーメッセージは、HTTP / HTTPS応答200 OKによって実行されなければなりません。
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.
locationUnknown：このコードは、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.
unsupportedMessage：このコードは、要求のためのXML文書内の要素は、LISによってサポートまたは理解されなかったことを示しています。 HELD要求が受信機によってサポートされていない文書要素が含まれている場合、このエラーコードが使用されます。
timeout: This code indicates that the LIS could not satisfy the request within the time specified in the "responseTime" parameter.
タイムアウト：このコードは、LISは「RESPONSETIME」パラメータで指定した時間内に要求を満たすことができなかったことを示しています。
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".
cannotProvideLiType：このコードは、LISが要求された種類のLIを提供できなかったことを示します。 「locationType」パラメータの「正確な」属性が「真」に設定されている場合は、このコードが使用されています。
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.
notLocatable：このコードは、LISは、デバイスの位置を特定することができないことを示し、デバイスは、このLISからLIを取得するための更なる試みをしてはなりませんことを。このエラーコードは、デバイスは、セクション4.1.2で説明したLIS、例えば、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つまたは複数の「メッセージ」は、リクエストの結果に関するいくつかの追加、人間が読み取り可能な情報を伝えるために属性を含むかもしれません。属性：メッセージは、「LANG XML」で示されるべきで任意の言語に含まれていてもよいです。デフォルトの言語は英語（「エン」）[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.
「locationResponse」メッセージで受信した「locationUriSet」要素「locationURI」任意の数の要素を含むかもしれません。 LISは、それがサポートする各スキームのために、それぞれのスキームは一度だけ存在していること場所URIを割り当てることが推奨されます。 URIスキームや、HTTPやHTTPSなどして安全な変異体は、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」要素は、単一の場所のURIを含んでいます。応答に含まれる任意の特定のスキームのURIのために、そのURIは、位置情報を取得するために使用することができる方法を定義する仕様が存在していなければなりません。 [RFC5808]で指定し、このベースHELD明細書の範囲外であるように逆参照するためのプロトコルの詳細は、位置参照解除プロトコル要件を満たさなければなりません。
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と匿名IDのためのパブリックアドレスが含まれていることが推奨されます。
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」を含む「locationResponse」メッセージに含まれる情報のプライバシーと機密性を確保するために、セクション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」要素が含まれている場合、属性が「locationResponse」メッセージにのみ含まれている「期限が切れます」。属性は、LISが提供する場所のURIが期限切れになる日付/時刻を示し、「期限が切れます」。属性は、時間の長さに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.
HELDで使用されるすべての日付時刻値はグレゴリオ暦を使用して、協定世界時（UTC）で表現されなければなりません。 XMLスキーマは、時間帯識別子の使用はゼロ子午線からのオフセットを示すことができますが、このオプションを開催して使用してはいけません。大文字「T」とで定義される「Z」の文字を使用して拡張された日付時刻形式は、[W3C.REC-XMLSCHEMA-2から20041028]日時値を表すために使用されなければなりません。
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（例えば、「測地」または「市民」）が要求され、または「任意」の「locationType」が要求されたときに単一の「プレゼンス」パラメータが「locationResponse」メッセージに含まれるかもしれません。 LISは、プレゼンスパラメータにPIDF-LOを生成する際にPIDF-LOの使用において、「位置情報」要素解明、考慮事項、および推奨事項文書[RFC5491]の構築に関連するルールのサブセットに従わなければなりません。
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]を含んでいます。ユニークな、リンクされていないプレゼンURIはPIDF文書の義務的存在「実体」属性のLISによって生成されるべきです。そのような「接触」及び「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スキーマには示されていないことに留意されたいです。したがって、「##その他」の名前空間は、スキーマ内のプレゼンス・パラメータのプレースホルダとして機能します。
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]の "アプリケーション/開催+ 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">
<？xml version = "1.0"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：geopriv：開催" のxmlns：XS = "http://www.w3.org/2001/XMLSchema" xmlns：開催= "壷：IETF：のparams：XML：NS：geopriv：開催" のxmlns：XML = "http://www.w3.org/XML/1998/namespace" のelementFormDefault = "資格" attributeFormDefault = "修飾されていません" >
<xs:annotation> <xs:documentation> This document (RFC 5985) defines HELD messages. </xs:documentation> </xs:annotation>
<XSは：注釈> <XS：ドキュメント>この文書（RFC 5985）は、保留メッセージを定義します。 </ XS：ドキュメンテーション> </ XS：注釈>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<XS：インポートの名前空間= "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>
<！ - リターン場所 - > <XS：complexTypeの名= "returnLocationType"> <XS：complexContentを> <XS：制限ベース= "XS：anyTypeの"> <XS：シーケンス> <XS：要素名= "locationURI"タイプ= "XS：anyURIの" maxOccursの= "無制限" /> </ XS：シーケンス> <XS：属性名=タイプ= "XS：dateTimeの" "期限が切れ" 使用= "必要なの" /> </ XS：制限> < / 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>
<！ - RESPONSETIMEタイプ - > <XS：単純型名= "responseTimeType"> <XS：組合> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：列挙値= "emergencyRouting" /> <XS：列挙値= "emergencyDispatch" /> </ XS：制限> </ XS：単純> <XS：単純> <XS：制限ベース= "XS：NonNegativeIntegerの"> <XS：のminInclusive値= "0 「/> </ XS：制限> </ XS：単純> </ XS：組合> </ XS：単純>
<!-- 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：単純型名= "locationTypeBase"> <XS：組合> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：列挙値= "あらゆる" /> </ XS：制限> </ XS：単純> <XS：単純> <XS：制限基地= "開催：locationTypeList"> <XS：はminLength値= "1" /> </ XS：制限> </ XS：単純> </ XS：組合> </ XS：単純>
<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：単純型名= "locationTypeList"> <XS：リスト> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：列挙値= "市民" /> <XS：列挙値=」測地 "/> <XS：列挙値=" locationURI "/> </ XS：制限> </ XS：単純> </ XS：リスト> </ 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>
<XS：complexTypeの名= "locationTypeType"> <XS：simpleContentを> <XS：増設ベース= "開催：locationTypeBaseを"> <XS：属性名= "正確な" タイプ= "XS：ブール" 使用= "オプションの" デフォルト= "偽" /> </ XS：拡張> </ 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の名= "baseRequestType"> <XS：complexContentを> <XS：制限ベース= "XS：anyTypeの"> <XS：シーケンス/> <XS：属性名= "RESPONSETIME "TYPE =" 開催：responseTimeType」使用= "オプション" /> <XS：anyAttributeは名前空間= "##いずれか" のprocessContents = "緩い" /> </ XS：制限> </ 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の名= "ERRORTYPE"> <XS：complexContentを> <XS：制限ベース= "XS：anyType型"> <XS：配列> <XS：要素名= "メッセージ" "開催：errorMsgType" タイプ=のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "コード" タイプ= "XS：トークン" XS = "必須" /> <使用：anyAttributeは名前空間= "##いずれか" のprocessContents = "緩い" /> </ XS：制限> </ 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：complexTypeの名前= "errorMsgType"> <XS：simpleContentを> <XS：増設ベース= "XS：トークン"> <XS：属性REF = "XML：LANG" /> <XS：anyAttributeは名前空間= "##任意の"のprocessContents =" 緩い "/> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの>
<xs:element name="error" type="held:errorType"/>
<XS：要素名= "エラー" "開催：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：complexTypeの名= "locationResponseType"> <XS：complexContentを> <XS：制限ベース= "XS：anyTypeの"> <XS：シーケンス> <XS：要素名= "locationUriSet" minOccurs = "0" /> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ = "returnLocationType保持" と入力XS：制限> </ XS：complexContentを> </ XS：complexTypeの>
<xs:element name="locationResponse" type="held:locationResponseType"/>
<XS： "開催：locationResponseType" 要素名= "locationResponse" タイプ= />
<!-- Location Request --> <xs:complexType name="locationRequestType"> <xs:complexContent>
<！ - 場所要求 - > <XS：complexTypeの名= "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：増設ベース= "開催：baseRequestType"> <XS：配列> <XS：要素名= "locationType" タイプ= "開催：locationTypeType" のminOccurs = "0" /> <XS：任意の名前空間= "##他"のprocessContents =" 緩い」のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの>
<xs:element name="locationRequest" type="held:locationRequestType"/>
<XS：要素名= "なLocationRequest" タイプ= "開催：locationRequestTypeの" />
</xs:schema>
</ XS：スキーマ>
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.
このセクションでは、適合LIS、デバイスがサポートしなければならないHELDプロトコルのトランスポートメカニズムなどのTLS [RFC2818]上HTTP [RFC2616]とHTTPの使用を記載しています。
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.
HELDは、トランスポートとしてHTTPを使用していますが、それはHTTPの機能の厳密なサブセットを使用し、何らかの機能の制限のために、LISは完全に準拠HTTPサーバではありません。 LISが簡単に自明既存のHTTPライブラリを使用することができます保持するデバイス拡張メカニズムとしていることを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]やクッキー[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.
HELDリクエストは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.
HELDリクエストとレスポンスボディのMIMEタイプが「アプリケーション/開催+ xml」です。 LISおよびデバイスは、HTTPのContent-Typeこの値を提供し、ヘッダフィールドを受け入れなければなりません。 LISは、適切なコンテンツタイプを受信し、ヘッダフィールドを受け入れない場合、LISは406（許容できない）応答を返し、要求が失敗します。 HELD応答はContent-Lengthヘッダを含めるべきです。
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.
デバイスを開催リクエストで「期待」ヘッダーまたは「範囲」ヘッダを使用してはなりません。これらのHTTPの機能のいずれかが使用されている場合LISは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はエスケープURL（例えば、誰かがプロトコルトレースにURLが見つからないか、ファイルを記録し、そのブラウザにそれを供給）、または誰かのテスト/デバッグを行うことのいずれかでなければなりません。 LISは、URLがLISサーバに対応してのみHELD POSTリクエストに応答する、又はLISはなく例えば404のような非常に一般的なHTTPエラーメッセージを（返すことによって、情報の漏洩を回避するために試みることができることを示すHELD応じて情報を提供することができます見つかりません）。
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ステータスコードは、すべてのHELD locationResponse保持されたエラーメッセージの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応答でサーバによって提供されるLocationヘッダを使用して、リダイレクトを処理する必要があります。リダイレクトする場合、デバイスは、再試行の後ヘッダが示す遅延を観察しなければなりません。デバイスは、デバイスがサーバーが認証されていることを必要とする場合は、リダイレクトを次の前にリダイレクト応答を返すサーバーを認証する必要があります。デバイスがリダイレクトに示さ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トランスポートを実装HELDの実装は、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.
デバイスは、URIがサーバを認証するためにLISディスカバリー中に得られた使用しています。この認証方法の詳細は、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]で提供されています。ロケーションURIの使用に適用し、LIの参照による提供セキュリティ問題の詳細な議論は[RFC5808]に含まれています。
By using the HELD protocol, the client and the LIS expose themselves to two types of risk:
HELDプロトコルを使用することにより、クライアントとLISは、リスクの二つのタイプに自分自身を公開します：
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:
要求者への正確かつprivacy-と機密保護された場所の提供は、5つのステップの成功に依存します。
3. The LIS must be able to identify the Device by its identifier (IP address).
3. LISは、その識別子（IPアドレス）によってデバイスを識別することができなければなりません。
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]で定義された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ディスカバリー[RFC5986]に記載されているようにLISのためのケースが発見されると、この文書では、IPアドレスまたはドメイン名のいずれかによって接触されるLISが識別されることを想定しています。 HELDトランザクションがTLS [RFC5246]を使用して行われた場合、LISは、IPアドレスとして、すなわち（のsubjectAltNameとして、その識別子を含む証明書を提示することによって、クライアントに、ドメイン名またはIPアドレスのいずれかとして、そのIDを認証することができますかそれぞれのdNSName、）。結合は、上述したHTTPの場合、これは正確TLS [RFC2818]で説明した認証です。クライアントが適切なLIS（例えば、証明書のフィンガープリント）の予想身元や資格情報のような外部の情報を持っている場合は、これらのチェックを省略することができます。任意HELDの結合は、クライアントが上記の認証を要求することができるようにTLS上に取引することができなければならない、との結合のためのLISの実装では、この機能を含まなければなりません。提示された証明書がクライアントで有効になるようにするためには、クライアントが証明書を検証できなければならないことに注意してください。具体的には、証明書の検証パスは、そのトラストアンカーがLIS証明書自体であっても、クライアントのトラストアンカーの一つで終わらなければなりません。
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.
HELDは、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:
オーセンティケータとしてIPリターンルータビリティを使用すると、位置情報は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ロケーションURIは、セクション6.5.2に要素を「満了する」の値によって反映されるように、限られた寿命を持たなければなりません。場所のURIの寿命は必ずしもアクセスの性質に依存します。
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.
LISは、ネットワーク内で、変更をアドレッシング装置の動きを認識されるようにO 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.
HELD要求または応答文書が含まれ、このセクションのショーの完全なHTTP / HTTPSメッセージの例。
This example shows the most basic request for a LO. The POST includes an empty "locationRequest" element.
この例では、LOのための最も基本的な要求を示しています。 POSTは、空「な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"/>
<？xml version = "1.0"？> <なLocationRequestのxmlns = "壷：IETF：のparams：XML：NS：geopriv：開催" />
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
HTTP / 1.1 200 OKサーバー：例LIS日：火、2006年1月10日午前3時42分29秒GMTの有効期限：火、2006年1月10日午前3時42分29秒GMTキャッシュ制御：プライベートのContent-Type：アプリケーション/開催+ XMLを。文字セット= 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">
<？xml version = "1.0"？> <locationResponse =のxmlns "壷：IETF：のparams：XML：NS：geopriv：開催"> <プレゼンスのxmlns =エンティティ "壷：IETF：のparams：XML：：NS PIDF" =」 PRES：3650n87934c@ls.example.com "> <タプルID =" b650sf789nd "> <状態> <geoprivのxmlns =" URN：IETF：paramsは：XML：NS：PIDF：geopriv10" > <位置情報> <ポイントのxmlns = "http://www.opengis.net/gml" srsName = "壷：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>
<POS> -34.407 150.88001 </ POS> </ポイント> </位置情報> <用法・ルールのxmlns：GBP = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：basicPolicy"> <GBP：保持-expiry> 2006-01-11T03：42：28 + 00：00 </ GBP：保持-期限> </利用ルール> <方法>ワイヤーマップ</方法> </ geopriv> </状態> <タイムスタンプ> 2006 -01-10T03：42：28 + 00：00 </タイムスタンプ> </タプル> </プレゼンス> </ 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>
<？xml version = "1.0"？> <エラーのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：開催された" コード= "locationUnknown"> <メッセージXML：LANG = "EN"> <位置を決定することができません。 /メッセージ> </エラー>
The location request shown below doesn't specify any location types or response time.
以下に示すロケーション要求は、任意の場所の種類や応答時間を指定していません。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
<なLocationRequestのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持" />
The example response to this location request contains a list of Location URIs.
この位置要求に例応答は、場所の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
<locationResponseのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持"> <locationUriSet満了し= "2006-01-01T13：00：00.0Z"> <locationURI> https://ls.example.com。 9768 / 357yc6s64ceyoiuy5ax3o </ locationURI> <locationURI> SIP：9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationUriSet> </locationResponse>
</ 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.
対応するロケーション応答メッセージは、二つの場所の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>
<locationResponseのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持"> <locationUriSet満了し= "2006-01-01T13：00：00.0Z"> <locationURI> https://ls.example.com。 9768 / 357yc6s64ceyoiuy5ax3o </ locationURI> <locationURI> SIP：9769+357yc6s64ceyoiuy5ax3o@ls.example.com </ locationURI> </ locationUriSet> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" エンティティ=」 PRES：ae3be8585902e2253ce2@10.102.23.9 "> <タプルID =" lisLocation "> <状態> <geoprivのxmlns =" URN：IETF：paramsは：XML：NS：PIDF：geopriv10" > <位置情報> <GS：サークルのxmlns ：GS = "http://www.opengis.net/pidflo/1.0" のxmlns：GML = "http://www.opengis.net/gml" srsName = "壷：OGC：DEF：CRS：EPSG :: 4326 "> <GML：POS> -34.407242 150.882518 </ GML：POS> <GS：半径UOM =" URN：OGC：DEF：UOM：EPSG :: 9001" > 30 </ gsは：半径> </ GS：サークル>
<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>
<CA：civicAddressののxmlns：CA = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr" XML：LANG = "EN-AU"> <CA：国> AU </ CA：国> <CA： A1> NSW </ CA：A1> <CA：A3>ウロンゴン</ CA：A3> <CA：A4> Gwynneville </ CA：A4> <CA：STS>ノースフィールド・アベニュー</ CA：STS> <CA：LMK >ウロンゴン大学</ CA：LMK> <CA：FLR> 2 </ CA：FLR> <CA：NAM>アンドリュー・コーポレーション</ 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> </位置情報> <usage-ルールのxmlns：GBP = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：basicPolicy"> <GBP：再送許可>偽</ GBP：再送許可> <GBP：保持-期限> 2007-05- 25T12：35：02 + 10：00 </ GBP：保持-期限> </利用ルール> <方法>ワイヤーマップ</方法> </ geopriv> </状態> <タイムスタンプ> 2007-05-24T12：35： 02 + 10：00 </タイムスタンプ> </タプル> </プレゼンス> </ locationResponse>
IANA has made the registrations detailed in the following sections.
IANAは、次のセクションで詳述登録を行っています。
11.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held
11.1. 骨壷のためのURNサブ名前空間の登録：IETF：のparams：XML：NS：geopriv：開催
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [RFC3688].
[RFC3688]のガイドラインにつき、 "開催：IETF：のparams：XML：NS：geopriv壷" このセクションでは、新しいXML名前空間を、登録します。
URI: urn:ietf:params:xml:ns:geopriv:held
URI：URN：IETF：のparams：XML：NS：geopriv：開催
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、メアリー・バーンズ（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
BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1- strict.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml」のxml：langは= "EN"> <HEAD> <TITLE>保留メッセージ</ TITLE> </ HEAD> <BODY > <H1> HELDメッセージの名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：geopriv：開催</ H2> <P> RFC 5985を参照してください。</ P> </ body> </ html>この終わり
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:held
URI：URN：IETF：のparams：XML：スキーマ：geopriv：開催
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、メアリー・バーンズ（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
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of MIME media type application/held+xml
件名：MIMEメディアタイプアプリケーションの登録/ + XMLを開催しました
MIME media type name: application
MIMEメディアタイプ名：application
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に指定されている "アプリケーション/ XML" のcharsetパラメータと同じ文字セット[RFC3023]、セクション3.2。
Encoding considerations: Same as the encoding considerations of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
エンコードの考慮事項：「アプリケーション/ xml」でのエンコーディングの考慮事項と同じRFC 3023 [RFC3023]で指定されるように、3.2節。
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"
追加情報：マジックナンバー（S）：（なし）ファイルの拡張子（S）：.heldxmlマッキントッシュファイルタイプコード（S）： "TEXT"
Person & email address to contact for further information: Mary Barnes <mary.ietf.barnes@gmail.com>
人とEメールアドレスは、詳細のために連絡する：メアリー・バーンズ<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は、エラーコードの最初のレジストリを含むHELDプロトコルのための新しいレジストリを作成しました。セクション6.3で説明した第7のXMLスキーマの「CODETYPE」トークンのスキーマで定義されているエラーコードを保持エラーメッセージに含まれています。
The following is a summary of the registry:
次は、レジストリの要約です：
Related Registry: Geopriv HELD Registries, Error codes for HELD
関連レジストリ：HELDためGeopriv HELDレジストリ、エラーコード
Defining RFC: RFC 5985
定義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.
登録/割り当て手順：[RFC5226]に概説された方針に従い、HELDのエラーコードのための新しい値を割り当てるためのIANAポリシーは標準アクションである：値だけIESGによって承認された標準化過程のRFCのために割り当てられています。
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
登録者連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、メアリー・バーンズ（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.
locationUnknown：このコードは、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.
unsupportedMessage：このコードは、要求がサポートされているか、LISによって理解されなかったことを示しています。 HELD要求が受信機によってサポートされていない文書要素が含まれている場合、このエラーコードが使用されます。
timeout: This code indicates that the LIS could not satisfy the request within the time specified in the "responseTime" parameter.
タイムアウト：このコードは、LISは「RESPONSETIME」パラメータで指定した時間内に要求を満たすことができなかったことを示しています。
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".
cannotProvideLiType：このコードは、LISが要求された種類のLIを提供できなかったことを示します。 「locationType」パラメータの「正確な」属性が「真」に設定されている場合は、このコードが使用されています。
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.
notLocatable：このコードは、LISは、デバイスの位置を特定することができないことを示し、デバイスは、このLISからLIを取得するための更なる試みをしてはなりませんことを。このエラーコードは、デバイスは、LISによってサービスされるアクセスネットワークの外にあることを示すために使用されます。たとえば、VPNとNATのシナリオは、4.1.2項で述べました。
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.
ジェームズ・ウィンターボトム、マーティン・トムソンとバーバラ・スタークは、このWG文書が導出された元の文書の作者です。彼らの連絡先情報は、以下が含まれます。彼らは、XMLスキーマを含むWG文書への追加拠出を行いました。
James Winterbottom Andrew Andrew Building (39) University of Wollongong Northfields Avenue Wollongong, NSW 2522 AU
ジェームズ・ウィンターボトムアンドリューアンドリュービル（39）大学ウロンゴンのNorthfieldsアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2938 EMail: james.winterbottom@andrew.com URI: http://www.andrew.com/
電話：+61 2 4221 2938 Eメール：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）大学ウロンゴンのNorthfieldsアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2915 EMail: martin.thomson@andrew.com URI: http://www.andrew.com/
電話：+61 2 4221 2915 Eメール：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ピーチセントアトランタ、GA 30308米国
EMail: barbara.stark@att.com
メールアドレス：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,
著者と貢献者は（アルファベット順）このドキュメント上での建設的な入力とフィードバックのためのGEOPRIV WGと、次の人の参加者に感謝したいと思います：ナディーヌ・アボット、バーナードAboba、エリックArolick、リチャード・バーンズ（特に、セキュリティ注意事項セクション）、ピーター・Blatherwick、ベン・キャンベル、
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.
ガイ・キャノン、エディコルベット、マーティン・ドーソン、リサDusseault、ロビン・ジョージ、ジェローム・グルニエ、テッドハーディー、カレン・ジェニングス、ニールJustusson、タット・ラム、マルク・Linsner、パティMcCalmont、アレクセイ・メルニコフ、ロジャー・マーシャル、ティムポーク、ペリーProzeniuk、カール・リードジュリアンReschke、エリックレスコラ、ダンRomascanu、ブライアン・ローゼン、ジョンSchnizlein、志田シューベルト、ヘニングSchulzrinneと、エドShrum、ダグStuard、ハンネスTschofenig、そしてカール・ハインツ・ウルフ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965]クリストル、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ウィンターボトム、J.、トムソン、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]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986]トムソン、M.とJ.ウィンターボトム、 "ローカル位置情報サーバー（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]トンプソン、H.、メンデルゾーン、N.、ブナ、D.、およびM.マロニー、 "XMLスキーマパート1：構造第二版"、ワールドワイドウェブコンソーシアム勧告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]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型第二版"、World Wide Web Consortium（W3C）の勧告REC-XMLSCHEMA-2から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-伝える]ポーク、J.、ローゼン、B.、およびJ.ピーターソン、「セッション開始プロトコルのための場所の搬送」、進歩、2010年7月ワーク。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、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]ポーク、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]ローゼンバーグ、J.、 "プレゼンスのためのAデータモデル"、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レイヤ7場所構成プロトコル：問題文と要件"、RFC 5687、2010年3月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808]マーシャル、R.、 "場所・バイ・リファレンス・メカニズムのための要件"、RFC 5808、2010年5月。
Appendix A. HELD Compliance to IETF LCP Requirements
IETF LCPの要件に付録A. HELDコンプライアンス
This appendix describes HELD's compliance to the requirements specified in [RFC5687].
この付録では、[RFC5687]で指定された要件への準拠HELDを説明しています。
A.1. L7-1: Identifier Choice
A.1。 L7-1：識別子の選択
"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.
要求デバイスまたはターゲットのIDの一次ソースとして位置要求メッセージのIPアドレスを使用しました。このIDは、多くのネットワーク展開のための目標のための物理的な場所を提供するために、他のコンテキストのネットワーク情報を使用することができます。単独のIPアドレスは、ネットワーク内のターゲットを特定するには不十分であるネットワーク展開があるかもしれません。しかし、これらのネットワークのために必要なすべてのアイデンティティの拡張子は、このドキュメントの範囲を超えています。
A.2. L7-2: Mobility Support
A.2。 L7-2：モビリティサポート
"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.
モビリティサポートは、本質的にアクセスネットワーク技術の特徴である、保持されたアクセスネットワークにとらわれないように設計されています。そのため、この要件に準拠を開催しました。また、位置要求メッセージに任意RESPONSETIME属性を提供することにより、モバイル環境に特異的なサポートを提供しました。無線ネットワークは、多くの場合、位置決定のためのそれらの処分で、いくつかの異なる機構を有している（例えば、サービング基地局のIDに基づいて位置決定対アシストGPS）、精度の各提供異なる程度を、結果を得るために時間の異なる量を取ります。 RESPONSETIMEパラメータは、それが位置決意技術を選択するために使用できる基準とLISを提供します。
A.3. L7-3: ASP and Access Network Provider Relationship
A.3。 L7-3：ASPとアクセスネットワークプロバイダーの関係
"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との間の位置取得プロトコルを記載しています。 HELDの文脈では、LISは、アクセスネットワーク内にあります。このように、保持されたアプリケーション・サービス・プロバイダ（ASP）とアクセスネットワークプロバイダ間のビジネスや信頼関係とは無関係です。 HELD使用して場所の取得は、第9章で説明制限の対象です。
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
A.4。 L7-4：レイヤ2およびレイヤ3プロバイダーの関係
"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場所の設計は、構成プロトコルは、L2とL3プロバイダ間の信頼とビジネスの関係があると仮定しなければなりません。L3プロバイダはLIS動作し、この1つは最も近いので、L2プロバイダから位置情報を取得する必要があります同じホストの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.
HELDは、特に念頭に置いて、このモデルを用いて設計されており、容易に必要とされるプロトコルを変更することなくオペレータ間の要求をチェーンに自分自身を可能にしました。 HELDは、BEEPとして、HTTP以外を搬送するため結合することができるWebサービスプロトコルです。 BEEPはL3プロバイダとHTTPによって課さシリアル制限を招くことなくL2プロバイダとの間の専用の接続を介して高い要求スループットのオプションを提供するようなプロトコルを使用して。これは、トランスポートから身を分離しないプロトコルで行うのはあまり簡単です。
A.5. L7-5: Legacy Device Considerations
A.5。 L7-5：レガシーデバイスの考慮事項
"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."
「GEOPRIVレイヤ7場所構成プロトコルの設計は、DHCPを介して追加情報を渡すために、たとえば、追加のプロトコルをサポートするようにアップグレードすることはできませんDSL環境でレガシー住宅NATデバイスとネットワーク終端装置（NTE）を考慮しなければなりません。」
COMPLY
遵守
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の背後にあるホストからのHELD要求はホームルータの外部アドレスを取得するNATを横断します。したがって、ホストに提供される場所は、この状況ではホームルータのアドレスになります。変更はこの展開シナリオに対処するために特別に設計されたHELD、この機能をサポートするために、家庭用ルータに必要ありません。
A.6. L7-6: VPN Awareness
A.6。 L7-6：VPN意識
"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ロケーション・コンフィギュレーション・プロトコルの設計は、VPNの少なくとも一端は、VPN機能を認識していると仮定しなければならない。企業のシナリオでは、企業側はクライアントによって使用されるLISを提供し、それによってかどうかを検出することができます。 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.
クライアントの要求は、そのトンネルの上に発生していることを認識しているから、VPNトンネルの遠端にLISを排除するものではありません開催しました。また、ローカル物理ネットワークにサービスを提供するLISにアクセスし、続いて、VPNトンネルを介してアクセスされるアプリケーションと位置情報を使用してから、クライアントデバイスを排除するものではありません。
A.7. L7-7: Network Access Authentication
A.7。 L7-7：ネットワークアクセス認証
"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は前にネットワークアクセス認証に関する仮定を行いません。 HELD強くエンドポイントとLIS間の通信のためのサーバー側の証明書でTLSを使用することを推奨しています。 LISで認証するエンドポイントの要件はありません。
A.8. L7-8: Network Topology Unawareness
A.8。 L7-8：ネットワークトポロジ無自覚
"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."
「GEOPRIVレイヤ7場所構成プロトコルの設計は、エンドシステムは、アクセスネットワークトポロジーを意識すると仮定してはいけません。エンド・システムは、しかし、そのようなSTUNやNSIS NATFW NSLPなどのメカニズムを経由して自分のパブリックIPアドレスを決定することができます。 "
COMPLY
遵守
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.
HELDは、ネットワークトポロジについての仮定を行いません。それはLISの発見のために必要とされる場合を除いて、デバイスは、その外部IPアドレスを知っている必要はありません開催しました。
A.9. L7-9: Discovery Mechanism
A.9。 L7-9：ディスカバリーメカニズム
"The L7 LCP MUST define a single mandatory to implement discovery mechanism."
「L7 LCPは、検出メカニズムを実装するために、単一の義務を定義しなければなりません。」
COMPLY
遵守
HELD uses the discovery mechanism in [RFC5986].
HELD [RFC5986]で検出メカニズムを使用しています。
A.10. L7-10: PIDF-LO Creation
10 B。 Li710：pidiphインの作成
"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を作成するとき、それは、プレゼンス文書の<デバイス>要素（RFC 4479を参照）に<geopriv>要素を挿入する必要があります。これは、その後で、その結果として生じるPIDF-LOの文書を、保証します他のエンティティに配信、[今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].
HELDプロトコルの概要（セクション4）はPIDF-LOの作成にLIS上の要件を説明し、LISによって生成PIDF-LOは、[RFC5491]に準拠しなければならないことを規定しています。
Author's Address
著者のアドレス
Mary Barnes (editor) Polycom
メアリー・バーンズ（編集者）ポリコム
EMail: mary.ietf.barnes@gmail.com
メールアドレス：mary.ietf.barnes@gmail.com