Internet Engineering Task Force (IETF) J. Polk
Request for Comments: 6442 Cisco Systems
Category: Standards Track B. Rosen
ISSN: 2070-1721 J. Peterson
NeuStar
December 2011
Location Conveyance for the Session Initiation Protocol
Abstract
抽象
This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target.
この文書は、他のSIPエンティティに1つのSIPエンティティから地理的位置情報を伝達するセッション開始プロトコル（SIP）の拡張を定義します。 SIPの拡張は、SIP仲介場所ターゲットの位置に基づいてルーティング決定を行う位置ベースのルーティング、ならびにエンド・ツー・エンドの搬送を覆っています。
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/rfc6442.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6442で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............4
3. Overview of SIP Location Conveyance .............................4
3.1. Location Conveyed by Value .................................4
3.2. Location Conveyed as a Location URI ........................5
3.3. Location Conveyed though a SIP Intermediary ................6
3.4. SIP Intermediary Replacing Bad Location ....................7
4. SIP Extensions for Geolocation Conveyance .......................8
4.1. The Geolocation Header Field ...............................8
4.2. The Geolocation-Routing Header Field ......................11
4.2.1. Explaining Geolocation-Routing Header-Value
States .............................................12
4.3. 424 (Bad Location Information) Response Code ..............14
4.4. The Geolocation-Error Header Field ........................15
4.5. Location URIs in Message Bodies ...........................19
4.6. Location Profile Negotiation ..............................19
5. Geolocation Examples ...........................................20
5.1. Location-by-Value (in Coordinate Format) ..................20
5.2. Two Locations Composed in Same Location Object Example ....21
6. Geopriv Privacy Considerations .................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................26
8.1. IANA Registration for the SIP Geolocation Header Field ....26
8.2. IANA Registration for the SIP Geolocation-Routing
Header Field ..............................................26
8.3. IANA Registration for Location Profiles ...................27
8.4. IANA Registration for 424 Response Code ...................27
8.5. IANA Registration of New Geolocation-Error Header Field ...28
8.6. IANA Registration for the SIP Geolocation-Error Codes .....28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................31
Appendix A. Requirements for SIP Location Conveyance ..............32
Session Initiation Protocol (SIP) [RFC3261] creates, modifies and terminates multimedia sessions. SIP carries certain information related to a session while establishing or maintaining calls. This document defines how SIP conveys geographic location information of a Target to a Location Recipient (LR). SIP acts as a Using Protocol of location information, as defined in RFC 3693.
セッション開始プロトコル（SIP）[RFC3261]は、修正を作成し、マルチメディアセッションを終了します。 SIPはコールを確立または維持しながら、セッションに関連する特定の情報を運びます。この文書は、SIPロケーション受信者（LR）にターゲットの地理的位置情報を伝達する方法を定義します。 SIPは、RFC 3693で定義されている位置情報の使用プロトコルとして働きます。
In order to convey location information, this document specifies three new SIP header fields, Geolocation, Geolocation-Routing, and Geolocation-Error, which carry a reference to a Location Object (LO), grant permission to route a SIP request based on the location-value and provide error notifications specific to location errors, respectively. The Location Object (LO) may appear in a MIME body attached to the SIP request, or it may be a remote resource in the network.
位置情報を伝達するために、この文書は、位置に基づくルーティングするSIP要求の許可を与える場所オブジェクト（LO）への参照を運ぶつの新しいSIPヘッダフィールド、ジオロケーション、ジオロケーション・ルーティング、およびジオロケーション・エラーを、特定します-valueそれぞれ、位置誤差に固有のエラー通知を提供します。 Locationオブジェクト（LO）は、SIPリクエストに取り付けられたMIME本体に表示されることがあり、またはそれは、ネットワーク内のリモートリソースであってもよいです。
A Target is an entity whose location is being conveyed, per RFC 3693. Thus, a Target could be a SIP user agent (UA), some other IP device (a router or a PC) that does not have a SIP stack, a non-IP device (a person or a black phone), or even a non-communications device (a building or store front). In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location.
ターゲットは、その位置RFC 3693.当たり、搬送されているこのように、ターゲットは、SIPユーザエージェント（UA）、SIPスタックを持っていないいくつかの他のIPデバイス（ルータまたはPC）、非かもしれないエンティティであります-IPデバイス（人又は黒電話）、あるいは非通信デバイス（建物またはストアフロント）。決してこのドキュメントは、場所オブジェクトを含むリクエストを送信するSIPユーザエージェントクライアントは、必ずしもターゲットであることを前提としていません。 SIP内の搬送対象の位置は、典型的には、標的によって制御される装置、例えば、携帯電話のものに対応するが、そのようなデバイスは、その所有者から分離することができ、かつ、いくつかの場合において、ユーザーエージェントは知らないかもしれません自身の位置。
In the SIP context, a location recipient will most likely be a SIP UA, but due to the mediated nature of SIP architectures, location information conveyed by a single SIP request may have multiple recipients, as any SIP proxy server in the signaling path that inspects the location of the Target must also be considered a Location Recipient. In presence-like architectures, an intermediary that receives publications of location information and distributes them to watchers acts as a Location Server per RFC 3693. This location conveyance mechanism can also be used to deliver URIs pointing to such Location Servers where prospective Location Recipients can request Location Objects.
SIPのコンテキストにおいて、位置受信者は、ほとんどのSIP UAであるが、原因SIPアーキテクチャの媒介性のため、単一のSIP要求によって搬送位置情報は、検査信号経路内の任意のSIPプロキシサーバとして、複数の受信者を有することができますターゲットの場所も場所受信者と見なされなければなりません。プレゼンス状アーキテクチャでは、位置情報のパブリケーションを受信し、ウォッチャに配信仲介この位置搬送機構はまた、将来のロケーションの受信者が要求することができ、このようなロケーションサーバを指し示すURIを送達するために使用することができるRFC 3693.あたりロケーションサーバとして機能しますLocationオブジェクト。
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]. Furthermore, this document uses numerous terms defined in [RFC3693], including: Location Object, Location Recipient, Location Server, Target, Rule Maker, and Using Protocol.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。 Locationオブジェクト、場所受信者、ロケーションサーバ、ターゲット、ルールメーカー、およびプロトコルを使用して：さらに、このドキュメントは、以下を含む[RFC3693]で定義された数多くの用語を使用しています。
An operational overview of SIP location conveyance can be shown in four basic diagrams, with most applications falling under one of the following basic use cases. Each is separated into its own subsection here in Section 3.
ほとんどのアプリケーションは、以下の基本的なユースケースのいずれかに該当してSIPロケーション搬送動作の概要は、四つの基本的な図で示すことができます。それぞれ、第3節では、ここで独自のサブセクションに分割されます。
Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob is an LR. A SIP intermediary appears in some of the diagrams. Any SIP entity that receives and inspects location information is an LR; therefore, in any of the diagrams, the SIP intermediary that receives a SIP request is potentially an LR -- though that does not mean such an intermediary necessarily has to route the SIP request based on the location information. In some use cases, location information passes through the LS on the right of each diagram.
各図は、UASとして、アリスとボブがあります。アリスは、ターゲットである、とボブはLRです。 SIP仲介は、図の一部に表示されます。位置情報を受信し、検査する任意のSIPエンティティは、LRです。従って、図のいずれにおいても、SIP要求を受信したSIP仲介は、潜在的にLRである - それは、そのような中間は、必ずしも経路位置情報に基づいて、SIP要求をしなければならないわけではありませんが。いくつかのユースケースでは、位置情報は、各図の右側にLSを通過します。
We start with the simplest diagram of Location Conveyance, Alice to Bob, where no other Layer 7 entities are involved.
私たちは、他のレイヤ7のエンティティが関与していませんボブに場所搬送、アリスの最も簡単な図で始まります。
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location | |
|----------------------------------->| |
| | |
| Response | |
|<-----------------------------------| |
| | | |
Figure 1. Location Conveyed by Value
図1.場所値によって搬送されました
In Figure 1, Alice is both the Target and the LS that is conveying her location directly to Bob, who acts as an LR. This conveyance is point-to-point: it does not pass through any SIP-layer intermediary. A Location Object appears by-value in the initial SIP request as a MIME body, and Bob responds to that SIP request as appropriate. There is a 'Bad Location Information' response code introduced within this document to specifically inform Alice if she conveys bad location to Bob (e.g., Bob "cannot parse the location provided", or "there is not enough location information to determine where Alice is").
図1では、アリスは、標的とLRとして作用直接ボブに自分の位置を、搬送されるLSの両方があります。この搬送は、ポイントツーポイントである：これは、任意のSIP-層の中間を通過しません。 Locationオブジェクトは値によるMIMEボディとして初期SIPリクエストで表示され、ボブは、必要に応じてそのSIPリクエストに応答します。彼女はボブに悪い場所を伝える場合、特にアリスに知らせるために、この文書の中に導入された「悪い場所情報」応答コードが（例えば、ボブは「提供された位置を解析することはできません」があり、あるいは「アリスがどこにあるかを決定するのに十分な位置情報はありません「）。
Here we make Figure 1 a little more complicated by showing a diagram of indirect Location Conveyance from Alice to Bob, where Bob's entity has to retrieve the location object from a third party server.
ここでは、アリスからボブの実体は、サードパーティのサーバーから場所オブジェクトを取得しているボブへの間接的な場所搬送の図を示すことによって、図1は、もう少し複雑になります。
Alice SIP Intermediary Bob LS
| | | |
| Request w/Location URI | |
|----------------------------------->| |
| | Dereference |
| | Request |
| (To: Location URI) |
| |---------------->|
| | |
| | Dereference |
| | Response |
| (includes Location Object) |
| |<----------------|
| Response | |
|<-----------------------------------| |
| | | |
Figure 2. Location Conveyed as a Location URI
図2.場所所在地のURIとして伝え
In Figure 2, location is conveyed indirectly, via a Location URI carried in the SIP request (more of those details later). If Alice sends Bob this Location URI, Bob will need to dereference the URI -- analogous to Content Indirection [RFC4483] -- in order to request the location information. In general, the LS provides the location value to Bob instead of Alice directly for conveyance to Bob. From a user interface perspective, Bob the user won't know that this information was gathered from an LS indirectly rather than culled from the SIP request; practically, this does not impact the operation of location-based applications.
図2において、位置は、URIが（これらの詳細のより後）SIP要求内で運ば場所を介して、間接的に搬送されます。間接[RFC4483]のコンテンツに類似 - - アリスはボブこの場所URIを送信した場合、ボブはURI参照を解除する必要があります位置情報を要求するために。一般に、LSは、ボブへの搬送のために直接代わりに、アリスがボブに位置値を提供します。ユーザインタフェースの観点から、ボブユーザは、この情報は、SIP要求から抜粋ではなく間接的LSから収集されたことを知ることができません。実際に、これは、位置ベースのアプリケーションの動作に影響を与えません。
The example given in this section is only illustrative, not normative. In particular, applications can choose to dereference a location URI at any time, possibly several times, or potentially not at all. Applications receiving a Location URI in a SIP transaction need to be mindful of timers used by different transactions. In particular, if the means of dereferencing the Location URI might take longer than the SIP transaction timeout (Timer C for INVITE transactions, Timer F for non-INVITE transactions), then it needs to rely on mechanisms other than the transaction's response code to convey location errors, if returning such errors are necessary.
このセクションで与えられた例は例示のみではなく、規範的です。具体的には、アプリケーションは、潜在的にすべてではない可能性が、いつでも場所URI間接参照に数回を選択するか、することができます。 SIPトランザクションで場所URIを受信するアプリケーションは、別のトランザクションによって使用されるタイマーに留意する必要があります。具体的には、URIが（非INVITE取引について、取引をINVITEためのタイマCをタイマーF）SIPトランザクションタイムアウトよりも長くかかる可能性がある場所を参照解除する手段ならば、それは伝えるために、トランザクションのレスポンスコード以外のメカニズムに依存する必要があります位置誤差は、このようなエラーを返す場合には必要です。
In Figure 3, we introduce the idea of a SIP intermediary into the example to illustrate the role of proxying in the location architecture. This intermediary can be a SIP proxy or it can be a back-to-back user agent (B2BUA). In this message flow, the SIP intermediary could act as an LR, in addition to Bob. The primary use case for intermediaries consuming location information is location-based routing. In this case, the intermediary chooses a next hop for the SIP request by consulting a specialized location service that selects forwarding destinations based on the geographical location information contained in the SIP request.
図3において、我々は、場所アーキテクチャのプロキシの役割を説明するための例にSIP仲介の概念を紹介します。この仲介者は、SIPプロキシであってもよく、またはそれはバックツーバックユーザエージェント（B2BUA）とすることができます。このメッセージフローでは、SIP仲介ボブに加えて、LRとして作用し得ます。位置情報を消費仲介するための主な使用ケースは、ロケーションベースのルーティングです。この場合、仲介者はSIP要求に含まれる地理的位置情報に基づいて転送先を選択する専門ロケーションサービスを参照することにより、SIP要求の次ホップを選択します。
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | Request | |
| | w/Location | |
| |------------------>| |
| | | |
| | Response | |
| |<------------------| |
| Response | | |
|<---------------| | |
| | | |
Figure 3. Location Conveyed though a SIP Intermediary
SIP仲介かかわら伝え図3.場所
However, the most common case will be one in which the SIP intermediary receives a request with location information (conveyed either by-value or by-reference) and does not know or care about Alice's location, or support this extension, and merely passes it on to Bob. In this case, the intermediary does not act as a Location Recipient. When the intermediary is not an LR, this use case is the same as the one described in Section 3.1.
しかし、最も一般的なケースは、SIP仲介は、位置情報を用いて要求を受信する（価値によって、または副参照のいずれかで搬送）と知っているか、アリスの位置を気に、またはこの拡張をサポートしていない、単にそれを通過するものになりますボブの上。この場合、仲介者は場所受信者として機能していません。仲介はLRない場合、この使用例は、セクション3.1で説明したものと同じです。
Note that an intermediary does not have to perform location-based routing in order to be a Location Recipient. It could be the case that a SIP intermediary that does not perform location-based routing does care when Alice includes her location; for example, it could care that the location information is complete or that it correctly identifies where Alice is. The best example of this is intermediaries that verify location information for emergency calling, but it could also be for any location based routing, e.g., contacting your favorite local pizza delivery service, making sure that organization has Alice's proper location in the initial SIP request.
中間場所受信者であるために位置ベースのルーティングを実行する必要はないことに留意されたいです。これは、アリスが彼女の場所を含む場合、ロケーションベースのルーティングを実行しないSIP仲介がケアを行う場合であってもよいです。例えば、それは、位置情報が完全であることや、アリスがどこにあるか、それが正しく識別することを気にしません。この最良の例は、緊急呼び出しのための位置情報を確認する仲介ですが、それはまた、任意の場所に基づくルーティングのために可能性があり、例えば、お気に入りの地元のピザの配達サービスに連絡組織は、最初のSIPリクエストでアリスの適切な場所を持っていることを確認すること。
There is another scenario in which the SIP intermediary cares about location and is not an LR, one in which the intermediary inserts another location of the Target, Alice in this case, into the request, and forwards it. This secondary insertion is generally not advisable because downstream SIP entities will not be given any guidance about which location to believe is better, more reliable, less prone to error, more granular, worse than the other location or just plain wrong.
SIP仲介場所気及びLR、中間の要求に、この場合の目標の別の位置、アリスを挿入し、それを転送したものではないである別のシナリオがあります。下流SIPエンティティがどの場所について信じるように任意のガイダンスを与え、より良い、より多くの、エラーしにくく、信頼性がより細かく、他の場所よりも悪いか、単純に間違っていることはありませんので、この二次挿入は、一般的にはお勧めできません。
This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4).
この文書では、かかる仲介エンティティによってSIP要求の中に配置された第2の場所に対処するアプローチを「あなたはそれを破る、あなたはそれを買いました」。そのエンティティは、SIPリクエスト（セクション4で、この上に複数）内のすべての場所のために完全に責任になります。
If the SIP intermediary rejects the message due to unsuitable location information, the SIP response will indicate there was 'Bad Location Information' in the SIP request and provide a location-specific error code indicating what Alice needs to do to send an acceptable request (see Figure 4 for this scenario).
SIP仲介が原因不適位置情報にメッセージを拒否した場合、SIP応答が「悪い位置情報が」SIPリクエストにあった示し、アリスは許容リクエストを送信するために行う必要があるものを示す場所固有のエラーコードを提供します（参照このシナリオについては、図4）。
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | | |
| Rejected | | |
| w/New Location | | |
|<---------------| | |
| | | |
| Request | | |
| w/New Location | | |
|--------------->| | |
| | Request | |
| | w/New Location | |
| |------------------>| |
| | | |
Figure 4. SIP Intermediary Replacing Bad Location
図4. SIP仲介は悪い場所を交換します
In this last use case, the SIP intermediary wishes to include a Location Object indicating where it understands Alice to be. Thus, it needs to inform her user agent of what location it will include in any subsequent SIP request that contains her location. In this case, the intermediary can reject Alice's request and, through the SIP response, convey to her the best way to repair the request in order for the intermediary to accept it.
この最後のユースケースでは、SIP仲介は、アリスがあることが理解示す位置オブジェクトを含めることを望みます。したがって、それは彼女の場所が含まれ、後続のSIPリクエストに含まれていますどのような場所の彼女のユーザーエージェントに通知する必要があります。この場合、仲介者は、アリスの要求を拒否することができると、SIP応答を通じて、彼女にそれを受け入れる仲介ために要求を修復するための最良の方法を伝えます。
Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another.
結局、それはアリスがオンボードのGPSを持っている可能性があり、およびSIP仲介だけで彼女の最も近いセル塔を知っている - ユーザによって提供オーバーライド位置情報は、仲介は必ずしもエンドユーザーより良い知っているの展開が必要です。より正確な位置情報はどれですか？現在では、より正確であるか、そのことについては、間違っているどのエンティティ伝える方法がありません。この文書では、他のよりも正確である場所を示すために、どのように指定されていません。
As an aside, it is not envisioned that any SIP-based emergency services request (i.e., IP-911 or 112 type of call attempt) will receive a corrective 'Bad Location Information' response from an intermediary. Most likely, in that scenario, the SIP intermediary would act as a B2BUA and insert into the request by-value any appropriate location information for the benefit of Public Safety Answering Point (PSAP) call centers to expedite call reception by the emergency services personnel; thereby, minimizing any delay in call establishment time. The implementation of these specialized deployments is, however, outside the scope of this document.
余談として、任意のSIPベースの緊急サービス要求が（すなわち、コール試行のIP-911または112タイプ）が仲介から是正 "悪い場所情報の応答を受信することが想定されていません。ほとんどの場合、そのシナリオでは、SIP仲介は、B2BUAとして作用するであろうと、緊急サービス担当者が着信を促進するポイント（PSAP）コールセンターに答える公安の利益のために、値による要求に任意の適切な位置情報を挿入します。それによって、呼設定時間の遅延を最小限に抑えます。これらの特殊な展開の実装は、この文書の範囲外で、しかし、です。
The following sections detail the extensions to SIP for location conveyance.
以下のセクションで詳細拡張は位置搬送用のSIPします。
This document defines "Geolocation" as a new SIP header field registered by IANA, with the following ABNF [RFC5234]:
この文書は、以下のABNF [RFC5234]を用いて、IANAによって登録された新たなSIPヘッダフィールドとして「ジオロケーション」を定義します。
message-header =/ Geolocation-header ; (message-header from RFC 3261) Geolocation-header = "Geolocation" HCOLON locationValue *( COMMA locationValue ) locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / https-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261)
メッセージヘッダー= /地理位置ヘッダ。 （メッセージヘッダRFC 3261からの）地理位置ヘッダ= "ジオロケーション" HCOLON locationValue *（COMMA locationValue）locationValue = LAQUOT locationURI RAQUOT *（SEMI geoloc-PARAM）locationURI = SIP-URI / SIPS-URI / PRES-URI / HTTP- URI / HTTPS-URI / CID-URL; （RFC 2392から）/ absoluteURIで。 （RFC 3261から）
geoloc-param = generic-param ; (from RFC 3261)
geoloc-PARAM =ジェネリック-PARAM。 （RFC 3261から）
HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in [RFC3261].
HCOLONは、COMMA、LAQUOT、RAQUOT、及びSEMIは[RFC3261]で定義されています。
sip-URI, sips-URI, and absoluteURI are defined according to [RFC3261].
SIP-URI、SIPS-URI、およびabsoluteURIでは[RFC3261]に従って定義されます。
The pres-URI is defined in [RFC3859].
PRES-URIは、[RFC3859]で定義されています。
http-URI and https-URI are defined according to [RFC2616] and [RFC2818], respectively.
-URI HTTPおよびHTTPS-URIは、それぞれ、[RFC2616]及び[RFC2818]に従って定義されます。
The cid-url is defined in [RFC2392] to locate message body parts. This URI type is present in a SIP request when location is conveyed as a MIME body in the SIP message.
CID-URLはメッセージボディ部を配置するために[RFC2392]で定義されています。位置をSIPメッセージ内のMIME本体として搬送されるときに、このURIタイプは、SIP要求内に存在します。
GEO-URIs [RFC5870] are not appropriate for usage in the SIP Geolocation header because it does not include retention and re-transmission flags as part of the location information. Other URI schemes used in the location URI MUST be reviewed against the criteria in [RFC3693] for a Using Protocol. Section 4.6 discusses how URI schemes are communicated using this SIP extension and what to do if a URI scheme is received that cannot be supported.
GEO-のURI [RFC5870]、それが位置情報の一部として保持し、再送信フラグが含まれていないので、SIP地理位置ヘッダ内の使用に適していません。ロケーションURIに使用される他のURIスキームを使用してプロトコルのために[RFC3693]での基準に照らして見直さなければなりません。 4.6節URIスキームは、このSIPの拡張機能を使用して通信する方法について説明し、どのようなURIスキームをサポートすることができない受信された場合に実行します。
The generic-param in the definition of locationValue is included as a mechanism for future extensions that might require parameters. This document defines no parameters for use with locationValue. If a Geolocation header field is received that contains generic-params, each parameter SHOULD be ignored, and SHOULD NOT be removed when forwarding the locationValue. If a need arises to define parameters for use with locationValue, a revision/extension to this document is required.
locationValueの定義における一般的な-PARAMは、パラメータを必要とするかもしれない将来の拡張のためのメカニズムとして含まれています。この文書では、locationValueで使用するためのパラメータを定義していません。地理位置ヘッダフィールドは、汎用-paramsはが含まれて受信された場合、各パラメータは無視されるべきであり、locationValueを転送する際に除去されるべきではありません。必要がlocationValueで使用するためのパラメータを定義する必要が生じた場合は、このドキュメントの改訂/拡張が必要です。
The Geolocation header field MUST have at least one locationValue. A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request.
地理位置ヘッダフィールドは、少なくとも一つのlocationValueがなければなりません。 SIPの仲介者は、すでに位置を含むSIPリクエストに場所を追加しないでください。これはかなり頻繁のLR内の混乱につながります。しかし、SIPの仲介は場所がSIP仲介は、それがこの場所の追加について受け取る任意の424（悪い位置情報）SIP応答の懸念に対処するための完全に責任があることを、あらかじめSIPリクエストには存在しなかったとNOT必要がある場合でも、場所を追加した場合（上流側）424レスポンスを渡します。 locationValueを追加SIP仲介は、SIPリクエストの地理位置ヘッダフィールド内の最後locationValueとして新しいlocationValueを配置しなければなりません。
This document defines the Geolocation header field as valid in the following SIP requests:
このドキュメントでは、次のSIPリクエストのように、有効な地理位置ヘッダフィールドを定義しています。
INVITE [RFC3261] REGISTER [RFC3261] OPTIONS [RFC3261] BYE [RFC3261] UPDATE [RFC3311] INFO [RFC6086] MESSAGE [RFC3428] REFER [RFC3515] SUBSCRIBE [RFC3265] NOTIFY [RFC3265] PUBLISH [RFC3903]
[RFC3261] REGISTER [RFC3261] OPTIONS [RFC3261] BYE [RFC3261] UPDATE [RFC3311] INFO [RFC6086] MESSAGE [RFC3428] REFER [RFC3515]は、[RFC3265] NOTIFY [RFC3265]は、[RFC3903]をPUBLISH SUBSCRIBE、INVITE
The Geolocation header field MAY be included in any one of the above listed requests by a UA and a 424 response to any one of the requests sent above. Fully appreciating the caveats/warnings mentioned above, a SIP intermediary MAY add the Geolocation header field.
地理位置ヘッダフィールドは、UAによって、上記の要求のいずれかと、上記送信されたリクエストのいずれかに424応答に含まれるかもしれません。完全に上記の警告/警報を鑑賞、SIP仲介は、地理位置ヘッダフィールドを加えるかもしれ。
A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3).
（ユーザエージェントは、ジオロケーション・メカニズムをサポートしていない場合、例えば、それらのアウトバウンドプロキシは行い、対象者の位置を知っている、または他のユースケースの数のいずれか - いずれかが存在しない場合、SIP仲介は、地理位置ヘッダフィールドを加えるかもしれ第3節）を参照してください。
The Geolocation header field MAY be present in a SIP request or response without the presence of a Geolocation-Routing header (defined in Section 4.2). As stated in Section 4.2, the default value of Geolocation-Routing header-value is "no", meaning SIP intermediaries MUST NOT view (i.e., process, inspect, or actively dereference) any direct or indirect location within this SIP message. This is for at least two fundamental reasons:
地理位置ヘッダフィールド（セクション4.2で定義される）地理位置ルーティングヘッダが存在しないSIP要求または応答中に存在してもよいです。セクション4.2で述べたように、ジオロケーション・ルーティングヘッダ値のデフォルト値は「NO」を意味するSIP仲介このSIPメッセージ内に（すなわち、プロセス、検査、または積極的に逆参照）は、任意の直接的または間接的な位置を表示してはいけませんです。これは、少なくとも二つの基本的な理由のためであります：
1) to make the possibility of retention of the Target's location moot (because it was not viewed in the first place); and
それが最初の場所で表示されなかったため、1））（ターゲットの位置を議論の余地の保持の可能性を作るために、そして
2) to prevent a different treatment of this SIP request based on the contents of the Location Information in the SIP request.
2）SIP要求における位置情報の内容に基づいて、このSIPリクエストの異なる治療を防止します。
Any locationValue MUST be related to the original Target. This is equally true for the location information in a SIP response, i.e., from a SIP intermediary back to the Target as explained in Section 3.4. SIP intermediaries SHOULD NOT modify or delete any existing locationValue(s). A use case in which this would not apply would be where the SIP intermediary is an anonymizer. The problem with this scenario is that the geolocation included by the Target then becomes useless for the purpose or service for which they wanted to use (include) it. For example, 911/emergency calling or finding the nearest (towing company/pizza delivery/dry cleaning) service(s) will not yield intended results if the Location Information were to be modified or deleted from the SIP request.
どれlocationValueは、当初の目標に関連していなければなりません。セクション3.4で説明したように、これはすなわち、SIP仲介からバックターゲットに、SIP応答に位置情報に対しても同様に真です。 SIPの仲介は、既存のlocationValue（複数可）を修正または削除しないでください。 SIP仲介はアノニマイザであり、これは適用されないれたユースケースは、あろう。このシナリオでの問題は、その後、対象者が含まジオロケーションがそれを（含める）、彼らが使用していた対象の目的やサービスのために無駄になることです。例えば、911 /緊急呼び出しまたは最寄り（曳航会社/ピザの配達/ドライクリーニング）サービス（s）は位置情報が変更またはSIPリクエストから削除されるならば意図した結果が得られませんを見つけます。
This document defines "Geolocation-Routing" as a new SIP header field registered by IANA, with the following ABNF [RFC5234]:
この文書は、以下のABNF [RFC5234]を用いて、IANAによって登録された新たなSIPヘッダフィールドとして「ジオロケーション・ルーティング」を定義します。
message-header =/ Georouting-header ; (message-header from RFC 3261) Georouting-header = "Geolocation-Routing" HCOLON ( "yes" / "no" / generic-value ) generic-value = generic-param; (from RFC 3261)
メッセージヘッダー= / Georoutingヘッダ。 （メッセージヘッダRFC 3261から）Georoutingヘッダー= "ジオロケーションルーティング" HCOLON（ "YES" / "NO" /ジェネリック値）一般的な値= GENERIC-PARAM。 （RFC 3261から）
HCOLON is defined in [RFC3261].
HCOLONは[RFC3261]で定義されています。
The only defined values for the Geolocation-Routing header field are "yes" or "no". When the value is "yes", the locationValue can be used for routing decisions along the downstream signaling path by intermediaries. Values other than "yes" or "no" are permitted for future extensions. Implementations not aware of an extension MUST treat any other received value the same as "no".
ジオロケーションルーティングヘッダフィールドに対してのみ定義された値は、「yes」または「no」です。値が「YES」である場合、locationValueは仲介による下流のシグナル伝達経路に沿って決定をルーティングするために使用することができます。以外の値は、「はい」または「いいえ」は、将来の拡張のために許可されません。拡張子を意識していない実装は、「ノー」と同じ、他の受信値を扱わなければなりません。
If no Geolocation-Routing header field is present in a SIP request, a SIP intermediary MAY insert this header. Without knowledge from a Rule Maker, the SIP intermediary inserting this header-value SHOULD NOT set the value to "yes", as this may be more permissive than the originating party intends. An easy way around this is to have the Target always insert this header-value as "no".
何ジオロケーションルーティングヘッダフィールドは、SIP要求内に存在しない場合、SIP仲介は、このヘッダを挿入することができます。これは、発信側が意図する以上に許容されるように、ルールメーカーからの知識がなくても、このヘッダー値を挿入するSIP仲介は、「はい」に値を設定しないでください。これを回避する簡単な方法は、常に「なし」としてこのヘッダー値を挿入目標を持つことです。
When this Geolocation-Routing header-value is set to "no", this means no locationValue (inserted by the originating User Agent Client (UAC) or any intermediary along the signaling path) can be used by any SIP intermediary to make routing decisions. Intermediaries that attempt to use the location information for routing purposes in spite of this counter indication could end up routing the request improperly as a result. Section 4.4 gives the details on what a routing intermediary does if it determines it needs to use the location in the SIP request in order to process the message further. The practical implication is that when the Geolocation-Routing header-value is set to "no", if a cid:url is present in the SIP request, intermediaries MUST NOT view the location (because it is not for intermediaries to consider when processing the request); if a location URI is present, intermediaries MUST NOT dereference it. UAs are allowed to view location in the SIP request even when the Geolocation-Routing header-value is set to "no". An LR MUST by default consider the Geolocation-Routing header-value as set to "no", with no exceptions, unless the header field value is set to "yes".
このジオロケーションルーティングヘッダの値が「いいえ」に設定されている場合、これは、（発信側ユーザエージェントクライアント（UAC）またはシグナリングパスに沿った任意の仲介によって挿入）はlocationValueがルーティング決定を行うために、任意のSIP仲介によって使用することができないことを意味します。このカウンタの指示にもかかわらず、ルーティングの目的のために位置情報を使用しようと仲介結果として不適切に要求をルーティングするに終わる可能性があります。セクション4.4は、それが更なるメッセージを処理するために、SIP要求内の位置を使用する必要が判断した場合、ルーティング仲介が何をするかについての詳細を与えます。 URLがSIP要求内に存在する処理する際の仲介を検討することがないため、仲介者は、（位置を表示してはいけません：実用的な含意は、地理位置ルーティングヘッダの値が「いいえ」に設定されている場合、CID場合、ということです要求）;場所URIが存在する場合、仲介はそれを間接参照してはなりません。 UAは、ジオロケーションルーティングヘッダの値が「いいえ」に設定されていてもSIP要求内の位置を表示させます。 「なし」に設定されたヘッダフィールドの値が「はい」に設定されていない限り、デフォルトではLRのMUSTは、例外なく、ジオロケーション・ルーティングヘッダ値を検討してください。
A Geolocation-Routing header-value that is set to "no" has no special security properties. At most, it is a request for behavior within SIP intermediaries. That said, if the Geolocation-Routing header-value is set to "no", SIP intermediaries are still to process the SIP request and send it further downstream within the signaling path if there are no errors present in this SIP request.
「いいえ」に設定されている地理位置ルーティングヘッダ値は、特別なセキュリティ特性を有していません。せいぜい、それはSIP仲介内の動作の要求です。ジオロケーションルーティングヘッダの値が「いいえ」に設定されている場合には、前記、SIP仲介は、SIP要求を処理し、このSIPリクエストに存在するエラーがない場合、シグナリング経路内では、さらに下流に送信することがあります。
The Geolocation-Routing header field satisfies the recommendations made in Section 3.5 of RFC 5606 [RFC5606] regarding indication of permission to use location-based routing in SIP.
ジオロケーションルーティングヘッダフィールドは、SIPにロケーションベースのルーティングを使用する許可の表示についてRFC 5606 [RFC5606]のセクション3.5に勧告を満たします。
SIP implementations are advised to pay special attention to the policy elements for location retransmission and retention described in RFC 4119.
SIPの実装は、RFC 4119で説明した位置の再送信と保存のためのポリシー要素に特別な注意を払うことをお勧めします。
The Geolocation-Routing header field cannot appear without a header-value in a SIP request or response (i.e., a null value is not allowed). The absence of a Geolocation-Routing header-value in a SIP request is always the same as the following header field:
ジオロケーションルーティングヘッダフィールドは、SIP要求または応答のヘッダ値なしで表示されることができない（すなわち、ヌル値が許可されていません）。 SIP要求における地理位置情報ルーティングヘッダ値が存在しないことは、常に次のヘッダフィールドと同じです。
Geolocation-Routing: no
ジオロケーション・ルーティング：なし
The Geolocation-Routing header field MAY be present without a Geolocation header field in the same SIP request. This concept is further explored in Section 4.2.1.
ジオロケーションルーティングヘッダフィールドは、同じSIP要求における地理位置ヘッダフィールドなしで存在しているかもしれません。この概念は、さらに、4.2.1節で検討されます。
The Geolocation header field contains a Target's location, and it MUST NOT be present if there is no location information in this SIP request. The location information is contained in one or more locationValues. These locationValues MAY be contained in a single Geolocation header field or distributed among multiple Geolocation header fields. (See Section 7.3.1 of RFC 3261.)
地理位置ヘッダフィールドには、対象者の位置を含む、このSIPリクエストには位置情報が存在しない場合には存在してはなりません。位置情報は、1つまたは複数のlocationValuesに含まれています。これらlocationValuesは、単一の地理位置ヘッダフィールドに含まれる、または複数の地理位置ヘッダフィールドに分散されてもよいです。 （RFC 3261の7.3.1項を参照してください）
The Geolocation-Routing header field indicates whether or not SIP intermediaries can view and then route this SIP request based on the included (directly or indirectly) location information. The Geolocation-Routing header field MUST NOT appear more than once in any SIP request, and MUST NOT lack a header-value. The default or implied policy of a SIP request that does not have a Geolocation-Routing header field is the same as if one were present and the header-value were set to "no".
ジオロケーションルーティングヘッダフィールドは、SIP仲介が含まれる（直接的または間接的に）位置情報に基づいて、このSIPリクエストを表示し、ルートができるか否かを示します。ジオロケーション・ルーティングヘッダフィールドは、一度任意のSIPリクエストでより多く見えてはいけません、とヘッダ値が欠如してはなりません。一方が存在し、ヘッダ値が「NO」に設定されたかのようにデフォルトまたはジオロケーションルーティングヘッダフィールドを持っていないSIP要求の暗黙のポリシーが同じです。
There are only three possible states regarding the Geolocation-Routing header field:
ジオロケーション・ルーティングヘッダフィールドについてのみ、3つの状態があります。
- "no" - "yes" - no header-field present in this SIP request
- 「NO」 - 「はい」 - このSIPリクエストに存在しないヘッダフィールドを
The expected results in each state are as follows:
次のように各状態で予想される結果は次のとおりです。
If the Geolocation-Routing Only possible interpretations:
-------------------------- -----------------------------
"no" SIP intermediaries MUST NOT process
included geolocation information
within this SIP request.
SIP intermediaries inserting a
locationValue into a Geolocation
header field (whether adding to an
existing header-value or inserting the
Geolocation header field for the first
time) MUST NOT modify or delete the
received "no" header-value.
"yes" SIP intermediaries can process included geolocation information within this SIP request and can change the policy to "no" for intermediaries further downstream.
「はい」とSIPの仲介は、このSIPリクエストに含まれるジオロケーション情報を処理することができ、さらに仲介下流のために「いいえ」にポリシーを変更することができます。
Geolocation-Routing absent If a Geolocation header field exists (meaning a locationValue is already present), a SIP intermediary MUST interpret the lack of a Geolocation-Routing header field as if there were one present and the header-value is set to "no".
ジオロケーション・ルーティング不在地理位置ヘッダフィールドは、（locationValueが既に存在していることを意味する）が存在する場合が1本であったとヘッダ値が「NO」に設定されているかのように、SIP仲介は、ジオロケーションルーティングヘッダフィールドの欠如を解釈しなければなりません。
If there is no Geolocation header
field in this SIP request, the default
Geolocation-Routing is open and can be
set by a SIP intermediary or not at
all.
This SIP extension creates a new location-specific response code, defined as follows:
このSIP拡張は、次のように定義され、新たな位置特異的応答コードを作成します。
424 (Bad Location Information)
424（悪い位置情報）
The 424 (Bad Location Information) response code is a rejection of the request due to its location contents, indicating location information that was malformed or not satisfactory for the recipient's purpose or could not be dereferenced.
424（不良位置情報）応答コードは、不正な形式または受信者のために満足のいくものではなかったか、間接参照することができなかった位置情報を示す、その場所の内容に要求の拒否です。
A SIP intermediary can also reject a location it receives from a Target when it understands the Target to be in a different location. The proper handling of this scenario, described in Section 3.4, is for the SIP intermediary to include the proper location in the 424 response. This SHOULD be included in the response as a MIME message body (i.e., a location value) rather than as a URI; however, in cases where the intermediary is willing to share location with recipients but not with a user agent, a reference might be necessary.
SIP仲介はまた、別の場所にあるようにターゲットを理解したときに、それがターゲットから受信する位置を拒否することができます。セクション3.4で説明このシナリオの適切な処理は、424応答して適切な場所を含むようにSIP仲介するためのものです。これはむしろURIとしてよりMIMEメッセージの本文（すなわち、位置の値）として応答に含まれるべきです。しかし、仲介ユーザエージェントと受信者と場所を共有する意思がなく、ある場合には、参照が必要かもしれません。
As mentioned in Section 3.4, it might be the case that the intermediary does not want to chance providing less accurate location information than the user agent; thus, it will compose its understanding of where the user agent is in a separate <geopriv> element of the same Presence Information Data Format Location Object (PIDF-LO) [RFC4119] message body in the SIP response (which also contains the Target's version of where it is). Therefore, both locations are included -- each with different <method> elements. The proper reaction of the user agent is to generate a new SIP request that includes this composed location object, and send it towards the original LR. SIP intermediaries can verify that subsequent requests properly insert the suggested location information before forwarding said requests.
3.4節で述べたように、それは仲介は、ユーザエージェントよりも少ない正確な位置情報を提供する機会を望んでいない場合があります。これにより、ユーザエージェントは、ターゲットのバージョンを含むSIP応答（中の同じプレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）[RFC4119]メッセージ本文の個別の<geopriv>要素である場合、その理解を構成しますそれは）です。したがって、両方の場所が含まれている - 異なる<方法>要素とそれぞれ。ユーザエージェントの適切な反応は、この合成位置オブジェクトを含む新しいSIPリクエストを生成し、元のLRに向けて送信することです。 SIP仲介は、後続の要求が正しく要求を前記転送する前に、提案された位置情報を挿入することを確認することができます。
SIP intermediaries that are forwarding (as opposed to generating) a 424 response MUST NOT add, modify, or delete any location appearing in that response. This specifically applies to intermediaries that are between the 424 response generator and the original UAC. Geolocation and Geolocation-Error header fields and PIDF-LO body parts MUST remain unchanged, never added to or deleted.
424応答は、追加、変更、またはその応答に現れる任意の場所を削除してはいけません（発生とは対照的に）転送されたSIP仲介。これは、具体的に424応答生成とオリジナルUACの間で仲介者に適用されます。ジオロケーションおよびジオロケーション・エラーヘッダフィールドとPIDF-LOの本体部を添加したり、削除ない、不変のままでなければなりません。
Section 4.4 describes a Geolocation-Error header field to provide more detail about what was wrong with the location information in the request. This header field MUST be included in the 424 response.
4.4節では、要求内の位置情報と間違っていたかについての詳細を提供するために、ジオロケーション、エラーヘッダフィールドについて説明します。このヘッダーフィールドは、424応答に含まれなければなりません。
It is only appropriate to generate a 424 response when the responding entity needs a locationValue and there are no values in the request that are usable by the responder, or when the responder has additional location information to provide. The latter case is shown in Figure 4 of Section 3.4. There, a SIP intermediary is informing the upstream UA which location to include in the next SIP request.
応答エンティティはlocationValueを必要とレスポンダによって使用可能な要求には値がない、または応答がある場合、追加の位置情報を提供するときにのみ、424応答を生成することが適切です。後者の場合は、セクション3.4の図4に示されています。そこに、SIP仲介は、次のSIPリクエストに含める位置上流のUAに通知されます。
A 424 response MUST NOT be sent in response to a request that lacks a Geolocation header entirely, as the user agent in that case may not support this extension at all. If a SIP intermediary inserted a locationValue into a SIP request where one was not previously present, it MUST take any and all responsibility for the corrective action if it receives a 424 response to a SIP request it sent.
424応答は、その場合のユーザエージェントは、すべてでこの拡張をサポートしないかもしれないように、完全に地理位置ヘッダを欠く要求に応答して送信されてはいけません。 SIP仲介一つが以前に存在しなかったSIPリクエストにlocationValueを挿入した場合、それが送信されたSIP要求に対する424応答を受信した場合、是正処置のための任意のおよびすべての責任を取らなければなりません。
A 424 (Bad Location Information) response is a final response within a transaction and MUST NOT terminate an existing dialog.
424（悪い位置情報）応答は、トランザクション内の最終応答であり、既存のダイアログを終了してはなりません。
As discussed in Section 4.3, more granular error notifications specific to location errors within a received request are required if the location inserting entity is to know what was wrong within the original request. The Geolocation-Error header field is used for this purpose.
4.3節で説明したようにエンティティを挿入する場所は、元の要求の中に間違っていたかを知るのであれば、受信したリクエスト内の位置エラーに固有の、より詳細なエラー通知が必要とされています。ジオロケーション・エラーヘッダフィールドは、この目的のために使用されています。
The Geolocation-Error header field is used to convey location-specific errors within a response. The Geolocation-Error header field has the following ABNF [RFC5234]:
ジオロケーション・エラーヘッダフィールドは、レスポンス内の場所固有のエラーを伝えるために使用されます。ジオロケーション・エラーヘッダフィールドは以下のABNF [RFC5234]を有します。
message-header =/ Geolocation-Error ; (message-header from RFC 3261) Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue locationErrorValue = location-error-code *(SEMI location-error-params) location-error-code = 1*3DIGIT location-error-params = location-error-code-text / generic-param ; from RFC 3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC 3261
メッセージヘッダー= /ジオロケーション・エラー。 （RFC 3261からのメッセージ・ヘッダ）ジオロケーション・エラー= "ジオロケーション・エラー" HCOLON locationErrorValue locationErrorValue =位置エラーコード*（SEMI位置誤差-paramsは）位置エラーコード= 1 * 3DIGIT位置誤りのparams =場所・エラー・コードテキスト/ジェネリック-PARAM。 RFC 3261位置エラーコードテキストから=「コード」EQUALは、引用符で囲まれた文字列を、 RFC 3261から
HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined in [RFC5234].
HCOLON、SEMI、及びEQUALは[RFC3261]で定義されています。 DIGITは、[RFC5234]で定義されています。
The Geolocation-Error header field MUST contain only one locationErrorValue to indicate what was wrong with the locationValue the Location Recipient determined was bad. The locationErrorValue contains a 3-digit error code indicating what was wrong with the location in the request. This error code has a corresponding quoted error text string that is human understandable. The text string is OPTIONAL, but RECOMMENDED for human readability, similar to the string phrase used for SIP response codes. That said, the strings are complete enough for rendering to the user, if so desired. The strings in this document are recommendations, and are not standardized -- meaning an operator can change the strings -- but MUST NOT change the meaning of the error code. Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code.
ジオロケーション・エラーヘッダフィールドが決定場所受信者が悪かったlocationValueと間違っていたものを示すために一つだけlocationErrorValueを含まなければなりません。 locationErrorValueは、要求内の位置が間違ったものを示す3桁のエラーコードを含みます。このエラーコードは、人間が理解され、対応する引用されたエラーテキスト文字列を持っています。テキスト文字列は任意ですが、人間の読みやすさのために推奨、SIP応答コードのために使用される文字列の句に似ています。それは文字列が必要に応じて、ユーザーにレンダリングするために十分に完了している、と述べました。この文書に記載されている文字列が勧告され、標準化されていない - しかし、エラーコードの意味を変更しないでください - 演算子は文字列を変更することができますを意味します。 RFC 3261が指定する方法と同様に、エラーコードごとに複数の文字列があってはなりません。
The Geolocation-Error header field MAY be included in any response to one of the SIP Methods mentioned in Section 4.1, so long as a locationValue was in the request part of the same transaction. For example, Alice includes her location in an INVITE to Bob. Bob can accept this INVITE, thus creating a dialog, even though his UA determined the location contained in the INVITE was bad. Bob merely includes a Geolocation-Error header value in the 200 OK response to the INVITE informing Alice the INVITE was accepted but the location provided was bad.
ジオロケーション・エラーヘッダフィールドがあればlocationValueが同じトランザクションの要求の一部であったように、セクション4.1で述べたSIP方法の一つに任意の応答に含まれるかもしれません。例えば、アリスはボブにINVITEで彼女の位置を含みます。ボブは、このように彼のUAがINVITEに含まれている場所が悪いと判断したにも関わらず、ダイアログを作成し、これはINVITEを受け入れることができます。ボブは単に、INVITEを受け入れなく提供された位置が悪いとしたアリスに通知INVITEに対する200 OK応答してジオロケーション・エラー・ヘッダ値を含みます。
If, on the other hand, Bob cannot accept Alice's INVITE without a suitable location, a 424 (Bad Location Information) response is sent. This message flow is shown in Figures 1, 2, or 3 in Sections 3.1, 3.2, and 3.3, respectively.
一方、ボブがアリスの適切な場所ずにINVITEを受け入れることができない、場合は、424（悪い位置情報）応答が送信されます。このメッセージ・フローは、それぞれ図1、図2、またはセクション3.1において3、3.2、および3.3に示されています。
If Alice is deliberately leaving location information out of the LO because she does not want Bob to have this additional information, implementations should be aware that Bob could repeatedly error in order to receive more location information about Alice in a subsequent SIP request. Implementations MUST be on guard for this, by not allowing continually more information to be revealed unless it is clear that any LR is permitted by Alice to know all that Alice knows about her location. A limit on the number of such rejections to learn more location information SHOULD be configurable, with a RECOMMENDED maximum of three times for each related transaction.
アリスは故意にLOのうち、位置情報を残している場合、彼女はボブが、この付加的な情報を持っている必要はありませんので、実装はボブが、その後のSIPリクエストにアリスの詳細位置情報を受信するために、繰り返しエラーができることを知っておく必要があります。実装はありません、すべてのLRは、アリスが彼女の場所を知っていることすべてを知るためにアリスによって許可されていることは明らかでない限り、継続的により多くの情報を明らかにすることを可能にすることによって、これを警戒しなければなりません。そのような拒絶の数の制限は、より多くの位置情報は、各関連するトランザクションの三回の推奨最大で、設定可能べきで学習します。
A SIP intermediary that requires Alice's location in order to properly process Alice's INVITE also sends a 424 response with a Geolocation-Error code. This message flow is shown in Figure 4 of Section 3.4.
適切アリスもジオロケーション・エラー・コードと424応答を送信し、INVITE処理するためにアリスの場所を必要とするSIP仲介。このメッセージ・フローは、セクション3.4の図4に示されています。
If more than one locationValue is present in a SIP request and at least one locationValue is determined to be valid by the LR, the location in that SIP request MUST be considered good as far as location is concerned, and no Geolocation-Error is to be sent.
複数locationValueがSIP要求に存在し、少なくとも一つのlocationValueがLRによって有効であると判断された場合に、そのSIPリクエスト内の場所限り場所に関しては良い考えなければならない、とNOジオロケーション・エラーがされるべきではありません送信されました。
Here is an initial list of location-based error code ranges for any SIP response, including provisional responses (other than 100 Trying) and the new 424 (Bad Location Information) response. These error codes are divided into three categories, based on how the response receiver should react to these errors. There MUST be no more than one Geolocation-Error code in a SIP response, regardless of how many locationValues there are in the correlating SIP request. When more than one locationValue is present in a SIP request, this mechanism provides no indication to which one the Geolocation-Error code corresponds. If multiple errors are present, the LR applies local policy to select one.
ここで（100試行以外）暫定応答して、新しい424（不良位置情報）応答を含む任意のSIP応答のためのロケーションベースのエラーコード範囲の最初のリストです。これらのエラーコードは、応答受信機はこれらのエラーに対処する方法に基づいて、3つのカテゴリーに分類されます。かかわらず、相関SIPリクエストにありますどのように多くのlocationValuesの、SIP応答には、複数のジオロケーション・エラー・コードがあってはなりません。複数locationValueがSIPリクエストに存在する場合、このメカニズムは、ジオロケーション・エラー・コードが対応するものへの指示を提供しません。複数のエラーが存在する場合、LRは、1つを選択するローカルポリシーを適用します。
o 1XX errors mean the LR cannot process the location within the request:
O 1XXエラーがLRは、要求内の位置を処理することはできません意味します：
A non-exclusive list of reasons for returning a 1XX is as follows:
次のように1XXを返すための理由の非排他的なリストは以下のとおりです。
- the location was not present or could not be found in the SIP request,
- 場所は、存在しないか、SIPリクエストで見つかりませんでした
- there was not enough location information to determine where the Target was,
- ターゲットがあった場所を決定するのに十分な位置情報がありませんでした、
- the location information was corrupted or known to be inaccurate.
- 位置情報が破損または不正確であることが知られていました。
o 2XX errors mean some specific permission is necessary to process the included location information.
O 2XXエラーは、いくつかの特定の権限が含まれる位置情報を処理するために必要であることを意味します。
o 3XX errors mean there was trouble dereferencing the Location URI sent.
O 3XXエラーはURIが送られた場所を間接参照し、トラブルがあったわけ。
Dereference attempts to the same request SHOULD be limited to 10 attempts within a few minutes. This number SHOULD be configurable, but result in a Geolocation-Error: 300 error once reached.
同じ要求に間接参照の試みは、数分以内に10回に限定されるべきです。この数は、設定可能であってもよいが、ジオロケーション、エラーになる必要があります：300エラーが一度に達しました。
It should be noted that for non-INVITE transactions, the SIP response will likely be sent before the dereference response has been received. This document does not alter that SIP protocol reality. This means the receiver of any non-INVITE response to a request containing location SHOULD NOT consider a 200 OK response to mean the act of dereferencing has concluded and the dereferencer (i.e., the LR) has successfully received and parsed the PIDF-LO for errors and found none. The end of Section 3.2 discusses how transaction timing considerations lead to this requirement.
間接参照の応答が受信される前に非INVITEトランザクションのために、SIP応答の可能性が高い送られることに留意すべきです。この文書では、SIPプロトコルの現実を変えることはありません。これは、位置を含む要求に任意の非INVITE応答の受信が間接参照の行為が終了したと間接参照（すなわち、LR）がエラーをPIDF-LOを正常に受信し、解析されたことを意味する200 OK応答を考慮しないべきであることを意味しますそしてどれも見つかりませんでした。 3.2節の終わりには、トランザクションタイミングの考慮事項は、この要件につながる方法について説明します。
Additionally, if an LR cannot or chooses not to process location from a SIP request, a 500 (Server Internal Error) SHOULD be used with or without a configurable Retry-After header field. There is no special location error code for what already exists within SIP today.
また、LRは、又はSIP要求からロケーション、500（サーバ内部エラー）を処理しないことを選択または設定リトライ後ヘッダーフィールドなしで使用されるべきであることができない場合。すでに今日SIP内に存在する何のために特別な場所のエラー・コードはありません。
Within each of these ranges, there is a top-level error as follows:
次のようにこれらの範囲の各々内に、トップレベルのエラーがあります。
Geolocation-Error: 100 ; code="Cannot Process Location"
ジオロケーション・エラー：100;コードは=「場所を処理できません。」
Geolocation-Error: 200 ; code="Permission To Use Location Information"
ジオロケーション・エラー：200;コード=「位置情報を使用する権限」
Geolocation-Error: 300 ; code="Dereference Failure"
ジオロケーション・エラー：300;コード=「間接参照の失敗」
If an error recipient cannot process a specific error code (such as the 201 or 202 below), perhaps because it does not understand that specific error code, the error recipient SHOULD process the error code as if it originally were a top-level error code where the X in X00 matches the specific error code. If the error recipient cannot process a non-100 error code, for whatever reason, then the error code 100 MUST be processed.
エラー受信者が（例えば下記201または202のような）特定のエラーコードを処理できない場合、それはその特定のエラーコードを理解していないので、それは元々トップレベルのエラーコードであるかのように、おそらく、エラー受信者はエラーコードを処理しますどこX00でのXは、特定のエラーコードと一致します。エラー受信者が何らかの理由で、非100エラーコードを処理できない場合は、エラーコード100が処理しなければなりません。
There are two specific Geolocation-Error codes necessary to include in this document, both have to do with permissions necessary to process the SIP request; they are
この文書に含めるために必要な2つの特定のジオロケーション・エラー・コードは、両方がSIPリクエストを処理するために必要な権限で行う必要があります。彼らです
Geolocation-Error: 201 ; code="Permission To Retransmit Location Information to a Third Party"
ジオロケーション・エラー：201;コード=「第三者への位置情報を再送信するための許可」
This location error is specific to having the PIDF-LO [RFC4119] <retransmission-allowed> element set to "no". This location error is stating it requires permission (i.e., PIDF-LO <retransmission-allowed> element set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request.
この位置誤差は「NO」に設定PIDF-LO [RFC4119] <再送許容>要素を有することに特異的です。この位置誤差は、さらにこのSIPリクエストを処理する（すなわち、PIDF-LO <再送許容>要素が「YES」に設定）、それは許可を必要と述べています。位置情報を送信するLSは、この権限を与えたくない場合は、新しい要求にこの権限は変更されません。 LSは、このメッセージは、「はい」に設定し、<再送許可>要素で処理したい場合は（存在する場合）、このSIPリクエストのために別の論理パスを選択する必要があります。
Geolocation-Error: 202 ; code="Permission to Route based on Location Information"
ジオロケーション・エラー：202;コード=「位置情報に基づいてルートを許可」
This location error is specific to having the Geolocation-Routing header value set to "no". This location error is stating it requires permission (i.e., the Geolocation-Routing header value set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request.
この位置誤差は「NO」に設定ジオロケーションルーティングヘッダの値を有することに特異的です。この位置誤差は、さらにこのSIPリクエストを処理する（すなわち、ジオロケーションルーティングヘッダの値が「YES」に設定）、それは許可を必要と述べています。位置情報を送信するLSは、この権限を与えたくない場合は、新しい要求にこの権限は変更されません。 LSは、このメッセージは、「はい」に設定し、<再送許可>要素で処理したい場合は（存在する場合）、このSIPリクエストのために別の論理パスを選択する必要があります。
In the case where an LR sends a 424 response and wishes to communicate suitable location-by-reference rather than location-by-value, the 424 response MUST include a content-indirection body per RFC 4483.
LRは424応答を送信し、適切な位置・バイ・リファレンスではなく場所によって値を通信することを望む場合には、424応答は、RFC 4483ごとのコンテンツ間接体を含まなければなりません。
The following is part of the discussion started in Section 3, Figure 2, which introduced the concept of sending location indirectly.
以下の議論の一部であり、第3に間接的位置を送信するの概念を導入し、図2を開始しました。
If a location URI is included in a SIP request, the sending user agent MUST also include a Supported header field indicating which location profiles it supports. Two option tags for location profiles are defined by this document: "geolocation-sip" and "geolocation-http". Future specifications MAY define further location profiles per the IANA policy described in Section 8.3.
ロケーションURIをSIP要求に含まれている場合、送信側ユーザエージェントは、それがサポートする場所プロファイルを示すサポートされているヘッダフィールドを含まなければなりません。 「ジオロケーション-SIP」と「ジオロケーション-HTTP」：場所のプロファイルのための二つのオプションタグは、この文書で定義されています。将来の仕様は、8.3節で説明するIANAポリシーごとに、さらに場所のプロファイルを定義することができます。
The "geolocation-sip" option tag signals support for acquiring location information via the presence event package of SIP [RFC3856]. A location recipient who supports this option can send a SUBSCRIBE request and parse a resulting NOTIFY containing a PIDF-LO object. The URI schemes supported by this option include "sip", "sips", and "pres".
「ジオロケーション-SIP」オプションタグ信号は、SIP [RFC3856]のプレゼンスイベントパッケージを介して位置情報を取得するためのサポート。このオプションをサポートしている位置の受信者は、SUBSCRIBEリクエストを送信し、PIDF-LOオブジェクトを含むNOTIFY得解析することができます。このオプションでサポートされているURIスキームは、「SIP」、「SIPS」、および「PRES」が含まれます。
The "geolocation-http" option tag signals support for acquiring location information via HTTP [RFC2616]. A location recipient who supports this option can request location with an HTTP GET and parse a resulting 200 response containing a PIDF-LO object. The URI schemes supported by this option include "http" and "https". A failure to parse the 200 response, for whatever reason, will return a "Dereference Failure" indication to the original location sending user agent to inform it that location was not delivered as intended.
「ジオロケーション-HTTP」オプションタグ信号HTTP [RFC2616]を介して位置情報を取得するためのサポート。このオプションをサポートしている位置の受信者は、HTTP GETと位置を要求し、PIDF-LOのオブジェクトを含む得られた200応答を解析することができます。このオプションでサポートされているURIスキームは、「http」と「httpsの」が含まれます。 200応答を解析するための失敗は、何らかの理由で、意図したとおりの場所が配信されなかったことを知らせるためにユーザーエージェントを送信元の場所に「逆参照の失敗」の表示を返します。
If the location URI receiver does not understand the URI scheme sent to it, it will return an Unsupported header value of the option tag from the SIP request, and include the option tag of the preferred URI scheme in the response's Supported header field.
ロケーションURI受信機がそれに送信されたURIスキームを理解していない場合は、SIP要求からオプションタグのサポートされていないヘッダの値を返し、応答のSupportedヘッダーフィールドにおける好ましいURIスキームのオプションタグを含むであろう。
See [GEO-FILTERS] or [HELD-DEREF] for more details on dereferencing location information.
位置情報を間接参照の詳細については[GEO-FILTERS]または[保有DEREF]参照。
This example shows an INVITE message with a coordinate location. In this example, the SIP request uses a sips-URI [RFC3261], meaning this message is protected using Transport Layer Security (TLS) on a hop-by-hop basis.
この例では、座標位置がINVITEメッセージを示しています。この例では、SIP要求は、このメッセージがホップバイホップに基づいて、トランスポート層セキュリティ（TLS）を使用して保護されている意味、SIPS-URI [RFC3261]を使用します。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
一口にINVITE：bob@biloxi.example.com SIP / 2.0経由：SIPS / 2.0 / TLS pc33.atlanta.example.com;ブランチ= z9hG4bK74bf9マックス・フォワード：70：ボブ<一口：bob@biloxi.example.com> From：アリス<すする：alice@atlanta.example.com>;タグ=コールIDを9fxced76sl：3848276298220188511@atlanta.example.comジオロケーション：の<cid：target123@atlanta.example.com>ジオロケーション・ルーティング：なし受け入れ：アプリケーション/ SDP、アプリケーション/ PIDF +のxmlのCSeq：31862連絡先をINVITE：<一口：alice@atlanta.example.com>のContent-Type：multipart / mixedの。境界= boundary1のコンテンツの長さ：...
--boundary1
--boundary1
Content-Type: application/sdp
コンテンツタイプ：アプリケーション/ SDP
...Session Description Protocol (SDP) goes here
...セッション記述プロトコル（SDP）は、ここに行きます
--boundary1
--boundary1
Content-Type: application/pidf+xml Content-ID: <target123@atlanta.example.com> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" entity="pres:alice@atlanta.example.com"> <dm:device id="target123-1"> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>32.86726 -97.16054</gml:pos>
コンテンツタイプ：アプリケーション/ PIDF + XMLのContent-ID：<target123@atlanta.example.com> <？xmlのバージョンは、= "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "壷：IETF：のparams： XML：NS：PIDF」のxmlns：GP = "壷：IETF：のparams：XML：NS：PIDF：geopriv10" のxmlns：GBP = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：basicPolicy" のxmlns：CL = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" のxmlns：GML = "http://www.opengis.net/gml" のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF ：データモデル」エンティティ= "PRES：alice@atlanta.example.com">の<dm：デバイスID = "target123-1"> <GP：geopriv> <GP：ロケーション情報> <GML：場所> <GML POS>：：ポイントsrsName = "壷：OGC：DEF：CRS：EPSG :: 4326"> <GML：> 32.86726 -97.16054 </ GML POS
</gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gbp:retransmission-allowed>false </gbp:retransmission-allowed> <gbp:retention-expiry>2010-11-14T20:00:00Z </gbp:retention-expiry> </gp:usage-rules> <gp:method>802.11</gp:method> </gp:geopriv> <dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> </dm:device> </presence> --boundary1--
</ GML：ポイント> </ GML：場所> </ GP：場所-インフォメーション> <GP：利用ルール> <GBP：再送許可>偽</ GBP：再送許可> <GBP：保持、有効期限> 2010-11-14T20：00：00Z </ GBP：保持-期限> </ GP：利用ルール> <GP：方法> 802.11 </ GP：方法> </ GP：geopriv>の<dm：のdeviceID> MAC： 1234567890ab </ DM：のdeviceID>の<dm：タイムスタンプ> 2010-11-04T20：57：29Z </ DM：タイムスタンプ> </ DM：デバイス> </プレゼンス> --boundary1--
The Geolocation header field from the above INVITE:
上記から地理位置ヘッダフィールドは、INVITE。
Geolocation: <cid:target123@atlanta.example.com>
ジオロケーション：の<cid：target123@atlanta.example.com>
... indicates the content-ID location [RFC2392] within the multipart message body of where location information is. The other message body part is SDP. The "cid:" eases message body parsing and disambiguates multiple parts of the same type.
...位置情報がどこにあるのマルチパートメッセージ本体内にコンテンツIDの位置[RFC2392]を示しています。他のメッセージボディ部は、SDPです。 「CID：」メッセージ本体の解析を容易にし、同じタイプの複数の部分を曖昧性を除去。
If the Geolocation header field did not contain a "cid:" scheme, for example, it could look like this location URI:
ジオロケーションヘッダーフィールドが「CID：」含まれていなかった場合のスキームを、例えば、それはこの場所URIのようになります。
Geolocation: <sips:target123@server5.atlanta.example.com>
ジオロケーション：<一口：target123@server5.atlanta.example.com>
... the existence of a non-"cid:" scheme indicates this is a location URI, to be dereferenced to learn the Target's location. Any node wanting to know where the target is located would subscribe to the SIP presence event package [RFC3856] at:
...非の存在は、「CID：」スキームは、これはターゲットの位置を学ぶために間接参照されるように、場所URIであることを示します。ターゲットが配置されている場所を知ることを望む任意のノードは、SIPプレゼンス・イベント・パッケージ[RFC3856]でを購読します：
sips:target123@server5.atlanta.example.com
一口：target123@server5.atlanta.example.com
(see Figure 2 in Section 3.2 for this message flow).
（このメッセージ・フローについては、セクション3.2で図2を参照）。
This example shows the INVITE message after a SIP intermediary rejected the original INVITE (say, the one in Section 5.1). This INVITE contains the composed LO sent by the SIP intermediary that includes where the intermediary understands Alice to be. The rules of RFC 5491 [RFC5491] are followed in this construction.
SIP仲介は、元の（セクション5.1中の1つ、例えば）INVITEを拒否した後に、この例では、INVITEメッセージを示しています。このINVITEは、中間にあることがアリスを理解ここ含むSIP仲介によって送信された合成LOを含有します。 RFC 5491 [RFC5491]のルールは、この構造に従います。
This example is here, but ought not be taken as occurring very often. In fact, this example is believed to be a corner case of location conveyance applicability.
この例はここにあるが、非常に頻繁に発生するものとして取られるべきではありません。実際には、この例では、位置搬送適用のコーナーケースであると考えられています。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188512@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31863 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
一口にINVITE：bob@biloxi.example.com SIP / 2.0経由：SIPS / 2.0 / TLS pc33.atlanta.example.com;ブランチ= z9hG4bK74bf0マックス・フォワード：70：ボブ<一口：bob@biloxi.example.com> From：アリス<すする：alice@atlanta.example.com>;タグ=コールIDを9fxced76sl：3848276298220188512@atlanta.example.comジオロケーション：の<cid：target123@atlanta.example.com>ジオロケーション・ルーティング：なし受け入れ：アプリケーション/ SDP、アプリケーション/ PIDF +のxmlのCSeq：31863連絡先をINVITE：<一口：alice@atlanta.example.com>のContent-Type：multipart / mixedの。境界= boundary1のコンテンツの長さ：...
--boundary1
--boundary1
Content-Type: application/sdp
コンテンツタイプ：アプリケーション/ SDP
...SDP goes here
... SDPは、ここに行きます
--boundary1
--boundary1
Content-Type: application/pidf+xml Content-ID: <target123@atlanta.example.com> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:alice@atlanta.example.com"> <dm:device id="target123-1"> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>32.86726 -97.16054</gml:pos> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gbp:retransmission-allowed>false
コンテンツタイプ：アプリケーション/ PIDF + XMLのContent-ID：<target123@atlanta.example.com> <？xmlのバージョンは、= "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "壷：IETF：のparams： XML：NS：PIDF」のxmlns：GP = "壷：IETF：のparams：XML：NS：PIDF：geopriv10" のxmlns：GBP = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：basicPolicy" のxmlns：DM = "URN：IETF：のparams：XML：NS：PIDF：データ・モデル" のxmlns：CL = "壷：IETF：のparams：XML：NS：PIDF：geopriv10：civicAddr" のxmlns：GML = "のhttp：//www.opengis .NET / GML」エンティティ= "PRES：alice@atlanta.example.com">の<dm：デバイスID = "target123-1"> <GP：geopriv> <GP：ロケーション情報> <GML：場所> <GML ：ポイントsrsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML：POS> 32.86726 -97.16054 </ GML：POS> </ GML：ポイント> </ GML：場所> </ GP：位置-info> <GP：利用ルール> <GBP：再送許可>偽
</gbp:retransmission-allowed> <gbp:retention-expiry>2010-11-14T20:00:00Z </gbp:retention-expiry> </gp:usage-rules> <gp:method>802.11</gp:method> </gp:geopriv> <dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> </dm:device> <dm:person id="target123"> <gp:geopriv> <gp:location-info> <cl:civicAddress> <cl:country>US</cl:country> <cl:A1>Texas</cl:A1> <cl:A3>Colleyville</cl:A3> <cl:RD>Treemont</cl:RD> <cl:STS>Circle</cl:STS> <cl:HNO>3913</cl:HNO> <cl:FLR>1</cl:FLR> <cl:NAM>Haley's Place</cl:NAM> <cl:PC>76034</cl:PC> </cl:civicAddress> </gp:location-info> <gp:usage-rules> <gbp:retransmission-allowed>false </gbp:retransmission-allowed> <gbp:retention-expiry>2010-11-14T20:00:00Z </gbp:retention-expiry> </gp:usage-rules> <gp:method>triangulation</gp:method> </gp:geopriv> <dm:timestamp>2010-11-04T12:28:04Z</dm:timestamp> </dm:person> </presence> --boundary1--
</ GBP：再送せ> <GBP：保持-満了> 2010-11-14T20：00：00Z </ GBP：保持-期限> </ GP：利用ルール> <GP：方法> 802.11 </ GP：方法> </ GP：geopriv>の<dm：のdeviceID> MAC：1234567890ab </ DM：のdeviceID>の<dm：タイムスタンプ> 2010-11-04T20：57：29Z </ DM：タイムスタンプ> </ DM：デバイス>の<dm ：人のID = "target123"> <GP：geopriv> <GP：場所-インフォメーション> <CL：civicAddress> <CL：国>アメリカ</ CL：国> <CL：A1>テキサス州</ CL：A1> < CL：A3>コリーヴィル</ CL：A3> <CL：RD> Treemont </ CL：RD> <CL：STS>サークル</ CL：STS> <CL：HNO> 3913 </ CL：HNO> <CL： FLR> 1 </ CL：FLR> <CL：NAM>ヘイリーの場所</ CL：NAM> <CL：PC> 76034 </ CL：PC> </ CL：civicAddress> </ GP：場所-インフォメーション> <GP ：利用ルール> <GBP：再送許可>偽</ GBP：再送許可> <GBP：保持-期限> 2010-11-14T20：00：00Z </ GBP：保持-期限> </ GP：使用方法-rules> <GP：方法>三角測量</ GP：方法> </ GP：geopriv>の<dm：タイムスタンプ> 2010-11-04T12：28：04Z </ DM：タイムスタンプ> </ DM：人> </プレゼンス> --boundary1--
Location information is considered by most to be highly sensitive information, requiring protection from eavesdropping and altering in transit. [RFC3693] originally articulated rules to be followed by any protocol wishing to be considered a "Using Protocol", specifying how a transport protocol meets those rules. [RFC6280] updates the guidance in RFC 3693 to include subsequently introduced entities and concepts in the geolocation architecture.
位置情報が盗聴からの保護を必要とし、輸送中に変更すること、機密性の高い情報であることをほとんどが考えられています。 [RFC3693]は、もともとトランスポートプロトコルは、これらのルールを満たしている方法を指定、「プロトコルを使用した」とみなされることを望むものでは任意のプロトコルによって従うべきルールを連接します。 [RFC6280]はRFC 3693でのガイダンスは地理位置情報アーキテクチャで、その後導入エンティティとコンセプトを含めるように更新されます。
RFC 5606 explores the difficulties inherent in mapping the GEOPRIV architecture onto SIP elements. In particular, the difficulties of defining and identifying recipients of location information are given in that document, along with guidance in Section 3.3.2 on the use of location-by-reference mechanisms to preserve confidentiality of location information from unauthorized recipients.
RFC 5606は、SIP要素にGEOPRIVアーキテクチャをマッピングに固有の難しさを探ります。具体的には、位置情報の受信者を定義し、特定の問題は、不正な受信者から位置情報の機密性を保持する場所ごとの基準機構の使用のセクション3.3.2のガイダンスと一緒に、その文書に記載されています。
In a SIP deployment, location information may be added by any of several elements, including the originating user agent or a proxy server. In all cases, the Rule Maker associated with that location information decides which entity adds location information and what access control rules apply. For example, a SIP user agent that does not support the Geolocation header may rely on a proxy server under the direction of the Rule Maker adding a Geolocation header with a reference to location information. The manner in which the Rule Maker operates on these devices is outside the scope of this document.
SIP展開では、位置情報は、発信ユーザエージェントまたはプロキシ・サーバを含むいくつかの要素、のいずれかで添加することができます。すべての場合において、その位置情報に関連付けられたルールのメーカーは、企業が位置情報とどのようなアクセス制御ルールが適用されますが追加されていることを決定します。例えば、地理位置ヘッダをサポートしていないSIPユーザエージェントは、位置情報を参照して、地理位置ヘッダを追加ルールメーカーの指示の下で、プロキシサーバーに依存してもよいです。ルールのメーカーは、これらのデバイス上で動作する方法は、この文書の範囲外です。
The manner in which SIP implementations honor the Rule Maker's stipulations for access control rules (including retention and retransmission) is application specific and not within the scope of SIP protocol operations. Entities in SIP networks that fulfill the architectural roles of the Location Server or Location Recipient treat the privacy rules associated with location information per the guidance in [RFC6280], Section 4.2.1. In particular, RFC 4119 (especially Section 2.2.2) gives guidance for handling access control rules; SIP implementations should furthermore consult the recommendations in RFC 5606.
SIP実装は（保持及び再送信を含む）アクセス制御ルールのルールメーカーの規定を尊重する方法は、SIPプロトコルの操作の範囲内の特定としないアプリケーションです。ロケーションサーバや場所の受信者の建築役割を果たしSIPネットワークのエンティティは、[RFC6280]のガイダンスあたりの位置情報、4.2.1項に関連したプライバシー規則を扱います。具体的には、RFC 4119（特に2.2.2項）は、アクセス制御ルールを処理するためのガイダンスを提供します。 SIPの実装はさらに、RFC 5606の推奨事項を相談してください。
Conveyance of physical location of a UA raises privacy concerns, and depending on use, there probably will be authentication and integrity concerns. This document calls for conveyance to be accomplished through secure mechanisms, like Secure/Multipurpose Internet Mail Extensions (S/MIME) encrypting message bodies (although this is not widely deployed), TLS protecting the overall signaling or conveyance location-by-reference and requiring all entities that dereference location to authenticate themselves. In location-based routing cases, encrypting the location payload with an end-to-end mechanism such as S/MIME is problematic because one or more proxies on the path need the ability to read the location information to retarget the message to the appropriate new destination User Agent Server (UAS). Data can only be encrypted to a particular, anticipated target, and thus if multiple recipients need to inspect a piece of data, and those recipients cannot be predicted by the sender of data, encryption is not a very feasible choice. Securing the location hop-by-hop, using TLS, protects the message from eavesdropping and modification in transit, but exposes the information to all proxies on the path as well as the endpoint. In most cases, the UA has no trust relationship with the proxy or proxies providing location-based routing services, so such end-to-middle solutions might not be appropriate either.
UAの物理的な場所の搬送は、プライバシーの問題を提起し、用途に応じて、おそらく認証と整合性の問題があるでしょう。搬送が安全な機構を介して達成されるため、この文書は、多目的インターネットメール拡張（S / MIME）メッセージ本文を暗号化する（これは広く展開されていないが）/セキュアなように、TLSは、全体的なシグナリングまたは搬送位置ごとの基準を保護し、必要、呼び出し場所逆参照自分自身を認証するすべてのエンティティ。パス上の1つのまたは複数のプロキシが適切な新しいにメッセージをリターゲットする位置情報を読み取る能力を必要とするので、ロケーションベースのルーティングの場合において、このようなS / MIMEのようなエンド・ツー・エンドの機構と位置ペイロードを暗号化することは問題があります送信先ユーザエージェントサーバ（UAS）。データは、特定の、予想されるターゲットに暗号化することができるので、複数の受信者は、データの一部を検査する必要がある場合は、それらの受信者がデータの送信者が予測できない、暗号化は非常に実現可能な選択肢ではありません。位置ホップバイホップの確保、TLSを使用して、輸送中の盗聴や改変からメッセージを保護するが、経路上の全てのプロキシならびにエンドポイントに情報を公開。ほとんどの場合、UAは、ロケーションベースのルーティングサービスを提供するプロキシまたはプロキシとは信頼関係を持っていないので、そのようなエンド・ツー・ミドル解決策はいずれか適切でないかもしれません。
When location information is conveyed by reference, however, one can properly authenticate and authorize each entity that wishes to inspect location information. This does not require that the sender of data anticipate who will receive data, and it does permit multiple entities to receive it securely; however, it does not obviate the need for pre-association between the sender of data and any prospective recipients. Obviously, in some contexts, this pre-association cannot be presumed; when it is not, effectively unauthenticated access to location information MUST be permitted. In this case, choosing pseudorandom URIs for location-by-reference, coupled with path encryption like Session Initiation Protocol Secure (SIPS), can help to ensure that only entities on the SIP signaling path learn the URI, and thus restores rough parity with sending location-by-value.
位置情報は、参照により搬送されると、ただし、一方が正しく位置情報を検査することを望む各エンティティを認証および承認することができます。これは、データの送信者がデータを受信します誰が予想し、それがしっかりとそれを受け取るために複数のエンティティを許可しないことを必要としません。しかし、それは、データの送信者と受信者のいずれかの将来の間の事前会合の必要性を回避しません。明らかに、いくつかの状況では、この事前会合を推定することはできません。そうでない場合、位置情報を効果的に認証されていないアクセスが許可されなければなりません。この場合には、セッション開始プロトコルセキュア（SIPS）のような経路の暗号化と相まって、場所ごとの参照用擬似乱数URIを選択し、SIPシグナリングパス上のエンティティのみが、URIを学ぶことを確認するのに役立ち、従って送信と粗いパリティを復元することができ場所ごとの値。
Location information is especially sensitive when the identity of its Target is obvious. Note that there is the ability, according to [RFC3693], to have an anonymous identity for the Target's location. This is accomplished by the use of an unlinkable pseudonym in the "entity=" attribute of the <presence> element [RFC4479]. Though, this can be problematic for routing messages based on location (covered in [RFC4479]). Moreover, anyone fishing for information would correlate the identity at the SIP layer with that of the location information referenced by SIP signaling.
位置情報は、そのターゲットの身元が明らかである場合に特に敏感です。ターゲットの場所のための匿名のアイデンティティを持つように、[RFC3693]によると、能力があることに注意してください。これは、<プレゼンス>要素[RFC4479]の「エンティティ=」属性にリンク不可能な仮名を使用することによって達成されます。しかし、これは、（[RFC4479]でカバー）位置に基づいてメッセージをルーティングするために問題となり得ます。また、情報釣り誰でもSIPシグナリングによって参照される位置情報のものとSIPレイヤで同一性を相関するであろう。
When a UA inserts location, the UA sets the policy on whether to reveal its location along the signaling path -- as discussed in Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC implementations MUST make such capabilities conditional on explicit user permission, and MUST alert the user that location is being conveyed.
PIDF-LO [RFC4119]セクション4、ならびにフラグで説明したように - UA場所を挿入すると、UAは、信号経路に沿ってその位置を明らかにするかどうかのポリシーを設定します。 UACの実装では、明示的なユーザー権限で、このような機能を条件付きにしなければならない、と場所が搬送されていることをユーザに警告しなければなりません。
This SIP extension offers the default ability to require permission to process location while the SIP request is in transit. The default for this is set to "no". There is an error explicitly describing how an intermediary asks for permission to view the Target's location, plus a rule stating the user has to be made aware of this permission request.
このSIP拡張は、SIPリクエストが転送している間に場所を処理するための許可を必要とするデフォルトの機能を提供しています。このデフォルトは、「なし」に設定されています。明示的に仲介は、ターゲットの位置を表示する権限を要求し、プラスのユーザーを述べるルールがこの許可要求を認識されなければならどのように説明するエラーがあります。
There is no end-to-end integrity on any locationValue or locationErrorValue header field parameter (or middle-to-end if the value was inserted by a intermediary), so recipients of either header field need to implicitly trust the header field contents, and take whatever precautions each entity deems appropriate given this situation.
そこ（値が中間で挿入された場合、または中間ツーエンド）のいずれかのヘッダフィールドの受信者は、暗黙的にヘッダフィールドの内容を信頼する必要があるので、任意locationValue又はlocationErrorValueヘッダフィールドパラメータには、エンドツーエンドの完全性が、ではない、そして各エンティティは、このような状況与えられた適切と考えるものは何でも予防策取ります。
The following are the IANA considerations made by this SIP extension. Modifications and additions to all these registrations require a Standards Track RFC (Standards Action).
以下、このSIP拡張によって作られたIANAの考慮事項です。すべてのこれらの登録への変更や追加は、標準化過程RFC（標準アクション）が必要です。
The SIP Geolocation header field is created by this document, with its definition and rules in Section 4.1 of this document, and it has been added to the IANA sip-parameters registry as follows:
SIP地理位置ヘッダフィールドは、このドキュメントのセクション4.1におけるその定義とルールを、本文書で作成され、そして次のようにIANA SIPパラメータレジストリに追加されました。
The Header Fields registry has been updated with:
ヘッダフィールドレジストリがで更新されました：
Header Name Compact Reference
----------------- ------- ---------
Geolocation [RFC6442]
The SIP Geolocation-Routing header field is created by this document, with its definition and rules in Section 4.2 of this document, and it has been added to the IANA sip-parameters registry as follows.
SIPジオロケーションルーティングヘッダフィールドは、このドキュメントのセクション4.2におけるその定義とルールを、本文書で作成され、そして次のようにIANA SIPパラメータレジストリに追加されています。
The Header Fields registry has been updated with:
ヘッダフィールドレジストリがで更新されました：
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Routing [RFC6442]
This document defines two new SIP option tags: "geolocation-sip" and "geolocation-http" that have been added to the IANA sip-parameters Options Tags registry as follows.
「ジオロケーション-SIP」と「ジオロケーション-HTTP」、次のようにIANAのSIPパラメータのオプションタグレジストリに追加されました。このドキュメントは、2個の新しいSIPオプションタグを定義します。
Name Description Reference
----------- ------------------------------------------ ---------
geolocation-sip The "geolocation-sip" option tag signals [RFC6442]
support for acquiring location information
via the presence event package of SIP
(RFC 3856). A location recipient who
supports this option can send a SUBSCRIBE
request and parse a resulting NOTIFY
containing a PIDF-LO object. The URI
schemes supported by this option include
"sip", "sips", and "pres".
geolocation-http The "geolocation-http" option tag signals [RFC6442] support for acquiring location information via HTTP (RFC 2616). A location recipient who supports this option can request location with an HTTP GET and parse a resulting 200 response containing a PIDF-LO object. The URI schemes supported by this option include "http" and "https".
ジオロケーション-HTTP HTTP（RFC 2616）を介して位置情報を取得するための "ジオロケーション-HTTP" オプションタグ信号[RFC6442]のサポート。このオプションをサポートしている位置の受信者は、HTTP GETと位置を要求し、PIDF-LOのオブジェクトを含む得られた200応答を解析することができます。このオプションでサポートされているURIスキームは、「http」と「httpsの」が含まれます。
The names of profiles are SIP option tags, and the guidance in this document does not supersede the option tag assignment guidance in [RFC3261] (which requires a Standards Action for the assignment of a new option tag). However, this document does stipulate that option tags included to convey the name of a location profile per this definition MUST begin with the string "geolocation" followed by a dash. All such option tags should describe protocols used to acquire location by reference: these tags have no relevance to location carried in SIP requests by value, which use standard MIME typing and negotiation.
プロファイルの名前は、SIPオプションタグであり、この文書の指針は（新しいオプションタグの割り当てのための標準アクションが必要です）[RFC3261]でオプションタグの割り当て指針に取って代わるものではありません。しかし、この文書では、ダッシュに続く文字列「ジオロケーション」で始まる必要があり、この定義ごとの場所のプロファイルの名前を伝えるために含まそのオプションタグを規定しません。そのようなすべてのオプションタグを参照することにより位置を取得するためのプロトコルを記述するべきである：これらのタグは、標準のMIMEタイプとネゴシエーションを使用値によってSIPリクエストで搬送位置への関連性を有していません。
In the SIP Response Codes registry, the following is added
SIP応答コードレジストリでは、以下が追加されます
Reference: RFC 6442 Response code: 424 (recommended number to assign) Default reason phrase: Bad Location Information
参考：RFC 6442応答コード：424（割り当てることが推奨数）デフォルトの理由フレーズ：悪い位置情報
Registry:
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
424 Bad Location Information [RFC6442]
This SIP Response code is defined in Section 4.3 of this document.
このSIPレスポンスコードは、このドキュメントのセクション4.3で定義されています。
The SIP Geolocation-Error header field is created by this document, with its definition and rules in Section 4.4 of this document, to be added to the IANA sip-parameters registry with two actions
SIPジオロケーション・エラーヘッダフィールドは二つの動作でIANA SIPパラメータのレジストリに追加されるように、このドキュメントのセクション4.4におけるその定義とルールを、本文書で作成され
Registry:
Header Name Compact Reference
----------------- ------- ---------
Geolocation-Error [RFC6442]
2. In the portion titled "Header Field Parameters and Parameter
Values", add:
Predefined
Header Field Parameter Name Values Reference
----------------- ------------------- ---------- ---------
Geolocation-Error code yes [RFC6442]
This document creates a new registry for SIP, called "Geolocation-Error Codes". Geolocation-Error codes provide reason for the error discovered by Location Recipients, categorized by action to be taken by error recipient. The initial values for this registry are shown below.
この文書は、「ジオロケーション・エラーコード」と呼ばれるSIPのための新しいレジストリを作成します。ジオロケーション・エラー・コードは、エラーの受信者がとるべき行動によって分類場所受信者によって発見されたエラー、理由を提供しています。このレジストリの初期値は以下のとおりです。
Registry Name: Geolocation-Error Codes Reference: [RFC6442] Registration Procedures: Specification Required
レジストリ名：ジオロケーション・エラーコードのリファレンス：[RFC6442]登録手順：仕様が必要
Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process Location" [RFC6442]
200 "Permission To Use Location Information" [RFC6442]
[RFC6442] 200「位置情報を使用する権限」
201 "Permission To Retransmit Location Information to a Third Party" [RFC6442]
201「第三者への位置情報を再送信するための許可」[RFC6442]
202 "Permission to Route based on Location Information" [RFC6442]
[RFC6442] 202は、「位置情報に基づいてルートを許可」
300 "Dereference Failure" [RFC6442]
300 "間接参照の失敗" [RFC6442]
Details of these error codes are in Section 4.4 of this document.
これらのエラーコードの詳細は、このドキュメントのセクション4.4です。
To Dave Oran for helping to shape this idea.
デイブ・オランにこのアイデアを形作るために助けるため。
To Dean Willis for guidance of the effort.
ディーンウィリスための努力の指導のために。
To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, Jacqueline Lee, and Adam Roach for constructive feedback and nit checking.
アリソンマンキン、ディック・ナイト、ハンネスTschofenig、ヘニングSchulzrinneと、ジェームズ・ウィンターボトム、イェルーンバンBemmel、ジャン=フランソワラバ、ジョナサン・ローゼンバーグ、キース糖剤、マルク・Linsner、マーティン・トムソン、マイク・ハマー、テッドハーディー、志田シューバート、Umeshシャルマ、リチャードへ建設的なフィードバックとNITチェックのためバーンズ、ダン・ウィング、マット・Lepinski、ジョンエルウェル、トーマスStach、ジャクリーン・リー、そしてアダム・ローチ。
Special thanks to Paul Kyzivat for his help with the ABNF in this document and to Robert Sparks for many helpful comments and the proper construction of the Geolocation-Error header field.
多くの有益なコメントについては、この文書に記載されているとロバート・スパークスにABNFとジオロケーション・エラー・ヘッダフィールドを適切に構成された彼の助けのためのポールKyzivatに感謝します。
And finally, to Spencer Dawkins for giving this document a good scrubbing to make it more readable.
そして最後に、スペンサー・ドーキンスに、この文書にそれを読みやすくするための良いスクラブを与えます。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[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月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]ピーターソン、J.、 "プレゼンスのための共通プロファイル（CPP）"、RFC 3859、2004年8月。
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、編。、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.
[RFC6086] Holmbergの、C.、バーガー、E.、およびH.カプラン、 "セッション開始プロトコル（SIP）INFO方法およびパッケージフレームワーク"、RFC 6086、2011年1月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、A.編、 "セッション開始プロトコル・イベント状態の出版のための（SIP）拡張"、RFC 3903、2004年10月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]ローゼンバーグ、J.、 "プレゼンスのためのAデータモデル"、RFC 4479、2006年7月。
[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]バーガー、E.、エド。、 "セッション開始プロトコル（SIP）におけるコンテンツの間接化の仕組みメッセージ"、RFC 4483、2006年5月。
[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月。
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010.
[RFC5870] Mayrhofer、A.及びC. Spanring、 "地理的場所のためのユニフォームリソース識別子（ 'GEO' URI）"、RFC 5870、2010年6月。
[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月。
[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月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009.
[RFC5606]ピーターソン、J.、ハーディー、T.、およびJ.モリス、RFC 5606 " '再送許容' SIPロケーション搬送用の含意" 2009年8月。
[GEO-FILTERS] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in SIP", Work in Progress, March 2010.
[GEO-FILTERS]マーイ、R.、ローゼン、B.、およびH. Tschofenig、 "SIPでのフィルタリングの場所の通知"、進歩、2010年3月に作業。
[HELD-DEREF] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD", Work in Progress, October 2011.
[保有DEREF]ウィンター、J.、Tschofenig、H.、Schulzrinneと、H.、トムソン、M.、およびM.ドーソンは、進歩、2011年10月作業を "ロケーションプロトコルを保持使用して間接参照します"。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]バーンズ、R.、Lepinski、M.、クーパー、A.、モリス、J.、Tschofenig、H.、およびH. Schulzrinneと、 "インターネットアプリケーションにおける場所と場所のプライバシーのためのアーキテクチャ"、BCP 160、RFC 6280、2011年7月。
Appendix A. Requirements for SIP Location Conveyance
SIP場所搬送付録A.要件
The following subsections address the requirements placed on the UAC, the UAS, as well as SIP proxies when conveying location. This text is from a draft version of the location conveyance requirements that has since evolved into this document (RFC 6442). It has been kept for historical reasons.
以下のサブセクションでは、UAC、UAS上に配置された要件、並びにSIPプロキシ位置搬送対処します。このテキストは、以降、この文書（RFC 6442）に発展した位置の搬送要求のドラフト版からのものです。それは歴史的な理由のために保管されています。
If a requirement is not obvious in intent, a motivational statement is included below it.
要件は意図が明らかにされていない場合、動機付けの文はその下に含まれています。
A.1. Requirements for a UAC Conveying Location
A.1。 UAC搬送場所の要件
UAC-1 The SIP INVITE Method [RFC3261] must support location conveyance.
UAC-1ザ・SIPは、方法[RFC3261]は位置搬送をサポートしなければならないINVITE。
UAC-2 The SIP MESSAGE method [RFC3428] must support location conveyance.
UAC-2ザSIP MESSAGEメソッド[RFC3428]位置搬送をサポートしなければなりません。
UAC-3 SIP Requests within a dialog should support location conveyance.
ダイアログ内UAC-3のSIPリクエストは場所搬送をサポートする必要があります。
UAC-4 Other SIP Requests may support location conveyance.
UAC-4の他のSIP要求は、ロケーション搬送をサポートすることができます。
UAC-5 There must be one, mandatory-to-implement means of transmitting location confidentially.
UAC-5は、実装に必須の内密に場所を送信する手段を1、存在しなければなりません。
Motivation:
To guarantee interoperability.
UAC-6 It must be possible for a UAC to update location conveyed at any time in a dialog, including during dialog establishment.
UAC-6 UACは、場所を更新することが可能でなければならないが、ダイアログ確立中に含む、ダイアログ内の任意の時点で搬送されます。
Motivation:
If a UAC has moved prior to the establishment of a dialog
between UAs, the UAC must be able to send location
information. If location has been conveyed, and the UA moves,
the UAC must be able to update the location previously
conveyed to other parties.
UAC-7 The privacy and security rules established within [RFC3693] that would categorize SIP as a 'Using Protocol' MUST be met.
UAC-7「を使用プロトコル」満たさなければならないようにSIPを分類するであろう[RFC3693]内で確立プライバシー及びセキュリティルール。
UAC-8 The PIDF-LO [RFC4119] is a mandatory-to-implement format for location conveyance within SIP.
UAC-8ザPIDF-LO [RFC4119]はSIP内の位置搬送のために必須ツー実装形式です。
Motivation:
Interoperability with other IETF location protocols and
Mechanisms.
UAC-9 There must be a mechanism for the UAC to request the UAS send its location.
UAC-9その場所を送るUASを要求するUACのためのメカニズムが存在する必要があります。
UAC-9 has been DEPRECATED by the SIP WG, due to the many
problems this requirement would have caused if implemented.
The solution is for the above UAS to send a new request to the
original UAC with the UAS's location.
UAC-10 There must be a mechanism to differentiate the ability of the UAC to convey location from the UACs lack of knowledge of its location.
UAC-10は、その場所の知識の求めるUACの不足から場所を伝えるためにUACの能力を区別するためのメカニズムが存在しなければなりません。
Motivation:
Failure to receive location when it is expected can happen
because the UAC does not implement this extension, or because
the UAC implements the extension, but does not know where the
Target is. This may be, for example, due to the failure of
the access network to provide a location acquisition mechanism
the UAC supports. These cases must be differentiated.
UAC-11 It must be possible to convey location to proxy servers along the path.
UAC-11は、パスに沿って、プロキシサーバーに場所を伝えることが可能でなければなりません。
Motivation:
Location-based routing.
A.2. Requirements for a UAS Receiving Location
A.2。 UAS受信場所の要件
The following are the requirements for location conveyance by a UAS:
UASにより位置搬送するための要件は次のとおりです。
UAS-1 SIP Responses must support location conveyance.
UAS-1 SIP応答は位置搬送をサポートしなければなりません。
The SIPCORE WG reached consensus that this be allowed, but not
to communicate the UAS's location; rather for a SIP
intermediary to inform the UAC which location to include in
its next SIP request (as a matter of correcting what was
originally sent by the UAC).
UAS-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information.
UAS-2には、該当する場所の情報を提供しなかったUACを知らせるユニークな4XX応答がなければなりません。
In addition, requirements UAC-5, 6, 7, and 8 also apply to the UAS.
また、要件UAC-5、6、7、および8はまた、UASに適用します。
A.3. Requirements for SIP Proxies and Intermediaries
A.3。 SIPプロキシおよび仲介するための要件
The following are the requirements for location conveyance by a SIP proxies and intermediaries:
SIPプロキシおよび仲介による位置搬送するための要件は次のとおりです。
Proxy-1 Proxy servers must be capable of adding a Location header field during processing of SIP requests.
プロキシ1のプロキシサーバは、SIPリクエストの処理中Locationヘッダフィールドを追加することができなければなりません。
Motivation:
Provide network assertion of location when UACs are unable
to do so, or when network assertion is more reliable than
UAC assertion of location
Note: Because UACs connected to SIP signaling networks can have widely varying access network arrangements, including VPN tunnels and roaming mechanisms, it can be difficult for a network to reliably know the location of the endpoint. Proxies SHOULD NOT assert location of an endpoint unless the SIP signaling network has reliable knowledge of the actual location of the Targets.
注：求めるUACは、VPNトンネルとローミング機構を含む多種多様なアクセスネットワーク構成を有することができ、ネットワークを確実にエンドポイントの位置を把握することが困難であることができるネットワークSIPシグナリングに接続されているので。 SIPシグナリングネットワークは、ターゲットの実際の位置の信頼性の知識を持っていない限り、プロキシは、エンドポイントの位置を主張すべきではありません。
Proxy-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information.
プロキシ-2には、該当する場所の情報を提供しなかったUACを知らせるユニークな4XX応答がなければなりません。
Authors' Addresses
著者のアドレス
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034
ジェームズ・ポークシスコシステムズ3913 Treemontサークルコリーヴィル、テキサス州76034
33.00111N 96.68142W
33.00111N 96.68142W
Phone: +1-817-271-3552 EMail: jmpolk@cisco.com
電話：+ 1-817-271-3552 Eメール：jmpolk@cisco.com
Brian Rosen NeuStar, Inc. 470 Conrad Dr. Mars, PA 16046
ブライアン・ローゼンNeuStar、Inc.の470コンラッド博士は火星、PA 16046
40.70497N 80.01252W
40.70497N 80.01252と
Phone: +1 724 382 1051 EMail: br@brianrosen.net
電話：+1 724 382 1051 Eメール：br@brianrosen.net
Jon Peterson NeuStar, Inc.
ジョンピーターソンNeuStar株式会社
EMail: jon.peterson@neustar.biz
メールアドレス：jon.peterson@neustar.biz