[要約] RFC 6442は、セッション開始プロトコル（SIP）のための位置情報伝達に関する規格です。このRFCの目的は、SIPセッション中に位置情報を伝達するための方法を提供することです。
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）の拡張機能を定義して、ある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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. 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.
位置情報を伝えるために、このドキュメントは、3つの新しいSIPヘッダーフィールド、ジオロケーション、ジオロケーションルーティング、および地理配分エラーを指定します。-valueと、それぞれロケーションエラーに固有のエラー通知を提供します。位置オブジェクト（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）、Nonのないものです。-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要求によって伝えられる位置情報が複数の受信者を持つ場合があります。ターゲットの位置も、場所の受信者と見なされる必要があります。プレゼンスのようなアーキテクチャでは、位置情報の出版物を受け取り、ウォッチャーに配布する仲介者であるRFC 3693。ロケーションオブジェクト。
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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。さらに、このドキュメントでは、[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ロケーションキャベサンスの動作概要は、4つの基本図に示すことができ、ほとんどのアプリケーションは以下の基本的なユースケースのいずれかに該当します。それぞれがセクション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.
私たちは、ロケーションキャベサンスの最も単純な図、アリスからボブから始めます。
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
図1では、アリスはターゲットであり、LSであり、LRとして行動するボブに直接彼女の場所を伝えています。この伝達はポイントツーポイントです。SIP層の仲介を通過しません。ロケーションオブジェクトは、最初のSIPリクエストでMIMEボディとしてバリューが表示され、ボブは必要に応じてそのSIPリクエストに応答します。このドキュメント内に導入された「悪い位置情報」応答コードがあり、アリスが悪いと伝えているかどうかを具体的に通知します
location to Bob (e.g., Bob "cannot parse the location provided", or "there is not enough location information to determine where Alice is").
ボブへの場所（たとえば、ボブは「提供された場所を解析できません」、または「アリスがどこにあるかを決定するのに十分な位置情報がありません」）。
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では、SIPリクエストでURIが運ばれた場所を介して、場所が間接的に伝達されます（詳細の詳細は後で）。アリスがボブをこの場所URIに送信する場合、ボブは位置情報をリクエストするために、URI（コンテンツの間接に類似している[RFC4483]に類似している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
このセクションで示されている例は、実例のみであり、規範ではありません。特に、アプリケーションは、いつでも、おそらく数回、または潜在的にまったくない場所のURIを再参照することを選択できます。SIPトランザクションでURIを受信するアプリケーションは、異なるトランザクションで使用されるタイマーに注意する必要があります。特に、URIの位置を参照する手段がSIPトランザクションタイムアウトよりも時間がかかる場合がある場合（招待のためのタイマーC
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.
トランザクション、非インバイトトランザクションのタイマーF）、そのようなエラーを返す必要がある場合は、トランザクションの応答コード以外のメカニズムに依存する必要があります。
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仲介者はBOBに加えてLRとして機能する可能性があります。位置情報を消費する仲介業者の主なユースケースは、ロケーションベースのルーティングです。この場合、仲介者は、SIPリクエストに含まれる地理的位置情報に基づいて転送宛先を選択する専門的なロケーションサービスに相談することにより、SIPリクエストの次のホップを選択します。
Alice SIP Intermediary Bob LS
| | | |
| Request | | |
| w/Location | | |
|--------------->| | |
| | Request | |
| | w/Location | |
| |------------------>| |
| | | |
| | Response | |
| |<------------------| |
| Response | | |
|<---------------| | |
| | | |
Figure 3. Location Conveyed though a SIP Intermediary
図3. SIP仲介者を介して伝えられる場所
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
仲介者は、ロケーションの受信者になるためにロケーションベースのルーティングを実行する必要がないことに注意してください。Aliceが彼女の場所を含めたときに、ロケーションベースのルーティングを実行しないSIP仲介者が気にする場合があります。たとえば、位置情報が完了していること、またはアリスがどこにあるかを正しく識別していることを気にすることができます。これの最良の例はです
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リクエストでアリスの適切な場所を持っていることを確認することもできます。
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ではない別のシナリオがあります。これは、この場合、ターゲットの別の場所、アリスをリクエストに挿入し、それを転送する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リクエスト内のすべての場所に対して完全に責任を負います（詳細については、セクション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リクエストに「悪い位置情報」があることを示し、Aliceが許容可能なリクエストを送信するために何をする必要があるかを示す場所固有のエラーコードを提供します（参照このシナリオの図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]:
このドキュメントでは、「Geolocation」は、次の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)
geoloc-param = generic-param ; (from RFC 3261)
geoloc-param = generic-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.
HTTP-URIと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]で定義されており、メッセージボディの部分を見つけます。このURIタイプは、SIPメッセージのMIMEボディとして場所が伝達される場合、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-uris [RFC5870]は、位置情報の一部として保持フラグと再送信フラグが含まれていないため、SIPジオロケーションヘッダーでの使用には適していません。URIの場所で使用される他のURIスキームは、プロトコルを使用するために[RFC3693]の基準に対してレビューする必要があります。セクション4.6では、このSIP拡張機能を使用してURIスキームがどのように伝達されるか、およびサポートできない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の定義の汎用パラムは、パラメーターを必要とする可能性のある将来の拡張機能のメカニズムとして含まれています。このドキュメントでは、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.
Geolocation Headerフィールドには、少なくとも1つのLocationValueが必要です。SIP仲介者は、すでに場所が含まれているSIPリクエストに場所を追加しないでください。これは、LRS内での混乱につながることがよくあります。ただし、SIP仲介者がSIPリクエストに以前に存在していなくても場所を追加する場合、そのSIP仲介者は、この場所の追加について受け取る424（悪い場所情報）の懸念に対処するために完全に責任を負います。424応答を渡します（上流）。LocationValueを追加するSIP仲介者は、SIPリクエストのGeolocationヘッダーフィールド内の最後の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]
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.
Geolocation Headerフィールドは、上記のリクエストのいずれかに、上記のリクエストのいずれかに対する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:
ジオロケーションヘッダーフィールドは、Geolocation-Routingヘッダー（セクション4.2で定義）の存在なしに、SIPリクエストまたは応答に存在する場合があります。セクション4.2で述べたように、ジオロケーションルーティングヘッダー値のデフォルト値は「いいえ」です。つまり、SIP仲介者は、このSIPメッセージ内の直接的または間接的な場所を表示（つまり、プロセス、検査、またはアクティブに控除）してはなりません。これは、少なくとも2つの基本的な理由です。
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は、元のターゲットに関連する必要があります。これは、SIP応答の位置情報、つまりSIP仲介者からセクション3.4で説明されているようにターゲットに戻ることに等しく当てはまります。SIP仲介者は、既存のLocationValue（s）を変更または削除しないでください。これが適用されないユースケースは、SIP仲介者が匿名である場所です。このシナリオの問題は、ターゲットに含まれるジオロケーションが、使用したい（含める）目的またはサービスに対して役に立たないことです。たとえば、911/緊急時の呼び出しまたは最寄りの（けん引会社/ピザ配達/ドライクリーニング）サービスを見つけても、SIPリクエストから位置情報を変更または削除する場合、意図された結果が得られません。
This document defines "Geolocation-Routing" as a new SIP header field registered by IANA, with the following ABNF [RFC5234]:
このドキュメントでは、「Geolocation-Routing」を、次の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)
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".
ジオロケーションルーティングヘッダーフィールドの唯一の定義値は、「はい」または「いいえ」です。値が「はい」の場合、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".
このジオロケーションルーティングヘッダー値が「いいえ」に設定されている場合、これは、SIP仲介者がルーティング決定を行うために、No locationvalue（発信ユーザーエージェントクライアント（UAC）またはシグナリングパスに沿った中間）を使用できないことを意味します。このカウンター表示にもかかわらず、ルーティングの目的で位置情報を使用しようとする仲介者は、結果としてリクエストを不適切にルーティングする可能性があります。セクション4.4では、メッセージをさらに処理するために、SIPリクエストの場所を使用する必要があると判断した場合、ルーティング仲介者が何をするかについての詳細を示します。実際的な意味は、Geolocation-Routingヘッダー値が「いいえ」に設定されている場合、CID：URLがSIPリクエストに存在する場合、仲介者は場所を表示してはならないということです（仲介者が処理する際に仲介者が考慮しないため、リクエスト）; URIが存在する場合、仲介者はそれを拒否してはなりません。 Geolocation-Routingヘッダー値が「いいえ」に設定されている場合でも、UASはSIPリクエストの場所を表示できます。 LRは、デフォルトでは、ヘッダーフィールド値が「はい」に設定されていない限り、例外はありませんが、Geolocation-Routingヘッダー値を「いいえ」に設定していると考慮する必要があります。
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.
Geolocation-Routing Headerフィールドは、SIPでロケーションベースのルーティングを使用する許可を示していることに関して、RFC 5606 [RFC5606]のセクション3.5 [RFC5606]で行われた推奨事項を満たしています。
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:
Geolocation-Routingヘッダーフィールドは、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.)
Geolocation Headerフィールドにはターゲットの位置が含まれており、このSIPリクエストに位置情報がない場合は存在しないでください。位置情報は、1つ以上の位置価値に含まれています。これらの位置価値は、単一のジオロケーションヘッダーフィールドに含まれているか、複数のジオロケーションヘッダーフィールドに分布する場合があります。（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".
Geolocation-Routingヘッダーフィールドは、SIP仲介者が含まれる（直接的または間接的に）位置情報に基づいてこのSIP要求を表示し、ルーティングできるかどうかを示します。Geolocation-Routing Headerフィールドは、SIPリクエストで複数回表示されてはならず、ヘッダー価値がないようにしてはなりません。ジオロケーションルーティングヘッダーフィールドを持たないSIPリクエストのデフォルトまたは暗黙のポリシーは、存在し、ヘッダー値が「いいえ」に設定されているかどうかと同じです。
There are only three possible states regarding the Geolocation-Routing header field:
ジオロケーションルーティングヘッダーフィールドに関して、可能な状態は3つしかありません。
- "no" - "yes" - no header-field present in this SIP request
- 「いいえ」 - 「はい」 - この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.
位置差をジオロケーションヘッダーフィールドに挿入するSIP仲介者（既存のヘッダー値に追加するか、ジオロケーションヘッダーフィールドを初めて挿入するか）は、受信した「NO」ヘッダー価値を変更または削除してはなりません。
"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".
ジオロケーションルーティングの不在（Geolocationヘッダーフィールドが存在する場合（LocationValueが既に存在していることを意味します）、SIP仲介者は、Geolocation-Routingヘッダーフィールドの欠如を1つ存在し、ヘッダー値が「いいえ」に設定されているかのように解釈する必要があります。。
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.
このSIPリクエストにジオロケーションヘッダーフィールドがない場合、デフォルトのジオロケーションルーティングは開いており、SIP仲介者によって設定できます。
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で説明されているこのシナリオの適切な処理は、SIP仲介者が424の応答に適切な場所を含めることです。これは、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で述べたように、仲介者がユーザーエージェントよりも正確な位置情報を提供する機会を与えたくない場合があります。したがって、ユーザーエージェントが同じ存在情報データ形式の位置オブジェクト（PIDF-LO）[RFC4119]メッセージ本文の別の<geopriv>要素がSIP応答（ターゲットのバージョンも含まれている」という別の<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を必要とし、リクエストにResponderが使用できる値がない場合、またはResponderが提供する追加の位置情報がある場合にのみ、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リクエストに位置差をSIPリクエストに挿入した場合、送信した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]:
Geolocation-Errorヘッダーフィールドは、応答内の位置固有のエラーを伝えるために使用されます。Geolocation-Errorヘッダーフィールドには、次の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
message-header =/ geolocation-error;（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;RFCから3261 from location-error-code-text = "code"等しい引用されたストリング。RFC 3261から
HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined in [RFC5234].
hcolon、semi、および等は[RFC3261]で定義されています。数字は[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
Geolocation-Errorヘッダーフィールドには、受信者が悪いと判断した場所の値が悪いことを示すために、1つのLocationErrorValueのみを含める必要があります。LocationErrorValueには、何が悪いのかを示す3桁のエラーコードが含まれています
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.
リクエストの場所。このエラーコードには、人間が理解できる対応する引用エラーテキスト文字列があります。テキスト文字列はオプションですが、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.
Geolocation-Errorヘッダーフィールドは、同じトランザクションのリクエスト部分に位置する値がある限り、セクション4.1で言及されたSIPメソッドのいずれかに対する任意の応答に含めることができます。たとえば、アリスはボブへの招待状に彼女の場所を含めています。ボブはこの招待状を受け入れることができ、招待状に含まれる場所が悪いと判断したにもかかわらず、ダイアログを作成することができます。ボブは、アリスに招待状が受け入れられたことを知らせる招待への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.
一方、ボブが適切な場所なしでアリスの招待を受け入れることができない場合、424（悪い位置情報）応答が送信されます。このメッセージの流れは、それぞれ図1、2、または3にセクション3.1、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リクエストでアリスに関するより多くの位置情報を受け取るために、ボブが繰り返しエラーが発生する可能性があることに注意する必要があります。アリスがアリスが彼女の場所について知っていることをすべて知ることが許可されていることが明確でない限り、継続的に多くの情報を明らかにすることを許可しないことにより、実装はこれを警戒する必要があります。より多くの位置情報を学習するためのそのような拒否の数の制限は、関連するトランザクションごとに推奨される最大3倍で構成可能である必要があります。
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.
アリスの招待を適切に処理するためにアリスの位置を必要とするSIP仲介者は、ジオロケーションエラーコードで424の応答も送信します。このメッセージの流れは、セクション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.
SIPリクエストに複数のLocationValueが存在し、少なくとも1つのLocationValueがLRによって有効であると判断された場合、そのSIPリクエストの場所は場所に関する限り良いと見なされ、Geolocation-Errorは送信済。
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応答には、相関SIPリクエストにいくつの位置価値があるかに関係なく、SIP応答には1つのジオロケーションエラーコードが1つしかない必要があります。SIPリクエストに複数のLocationValueが存在する場合、このメカニズムは、Geolocation-Errorコードが対応するものを示すことを提供しません。複数のエラーが存在する場合、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回の試行に制限する必要があります。この数値は構成可能である必要がありますが、Geolocation-Error：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.
非インバイトトランザクションでは、SIP応答が抑制対応の応答を受信する前に送信される可能性が高いことに注意する必要があります。このドキュメントは、そのSIPプロトコルの現実を変更しません。これは、ロケーションを含む要求に対する非インバイト応答の受信者が、控除の行為が終了したことを意味する200のOK応答を考慮してはならず、命令者（つまり、LR）がエラーのPIDF-LOを正常に受信し、解析したことを意味します。そして何も見つかりませんでした。セクション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"
Geolocation-Error: 200 ; code="Permission To Use Location Information"
ジオロケーションエラー：200;code = "位置情報を使用する許可"
Geolocation-Error: 300 ; code="Dereference Failure"
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"
Geolocation-Error：201;code = "位置情報をサードパーティに再送信する許可"
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.
この位置エラーは、PIDF-LO [RFC4119] <再送信-Allowed>要素を「いいえ」に設定することに固有です。この場所エラーは、このSIPリクエストをさらに処理するために許可（つまり、「はい」に設定されたPIDF-LO <再送信-Allowed>要素）が必要であると述べています。LSが位置情報を送信してもこの許可を与えたくない場合、新しいリクエストでこの許可は変更されません。LSがこのメッセージを「はい」に設定した<再送信-Allowed>要素で処理したい場合、このSIPリクエストに対して別の論理パス（存在する場合）を選択する必要があります。
Geolocation-Error: 202 ; code="Permission to Route based on Location Information"
ジオロケーションエラー：202;code = "位置情報に基づいてルーティングする許可」
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
この場所エラーは、ジオロケーションルーティングヘッダー値を「いいえ」に設定することに固有です。この場所エラーは、このSIPリクエストをさらに処理するために許可（つまり、「はい」に設定されたジオロケーションルーティングヘッダー値）が必要であると述べています。LSが位置情報を送信してもこの許可を与えたくない場合、新しいリクエストでこの許可は変更されません。LSがこのメッセージを望んでいる場合
processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request.
「はい」に設定された<再送信-Allowed>要素で処理され、この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リクエストに含まれている場合、送信ユーザーエージェントには、サポートする場所プロファイルを示すサポートされているヘッダーフィールドも含める必要があります。ロケーションプロファイルの2つのオプションタグは、このドキュメントで定義されています：「Geolocation-Sip」と「Geolocation-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 [RFC3856]のプレゼンスイベントパッケージを介して位置情報を取得するためのサポートをサポートしています。このオプションをサポートする場所の受信者は、購読要求を送信し、PIDF-LOオブジェクトを含む結果のNotifyを解析できます。このオプションでサポートされているURIスキームには、「SIP」、「SIP」、および「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.
「Geolocation-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スキームに送信されたURIスキームを理解していない場合、SIPリクエストからオプションタグのサポートされていないヘッダー値を返し、応答のサポートされているヘッダーフィールドに優先URIスキームのオプションタグを含めます。
See [GEO-FILTERS] or [HELD-DEREF] for more details on dereferencing location information.
参照の位置情報の詳細については、[Geo-Filters]または[Held-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.
この例は、座標場所の招待メッセージを示しています。この例では、SIP要求はSIPS-URI [RFC3261]を使用します。つまり、このメッセージは、ホップバイホップベースでトランスポートレイヤーセキュリティ（TLS）を使用して保護されています。
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: ...
--boundary1
-boundary1
Content-Type: application/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>
</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--
The Geolocation header field from the above INVITE:
上記の招待からのジオロケーションヘッダーフィールド：
Geolocation: <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]を示します。もう1つのメッセージ本文の部分はSDPです。「cid：」はメッセージ本文を容易に解析し、同じタイプの複数の部分を分解します。
If the Geolocation header field did not contain a "cid:" scheme, for example, it could look like this location URI:
Geolocation Headerフィールドに「CID：」スキームが含まれていなかった場合、たとえば、この場所URIのように見える可能性があります。
Geolocation: <sips: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
sips：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のもの）。この招待には、仲介者がアリスを理解している場所を含む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: ...
--boundary1
-boundary1
Content-Type: application/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
</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--
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の展開では、発信元のユーザーエージェントやプロキシサーバーなど、いくつかの要素のいずれかによって位置情報が追加される場合があります。すべての場合において、その位置情報に関連付けられたルールメーカーは、どのエンティティが位置情報を追加し、どのアクセス制御ルールが適用されるかを決定します。たとえば、Geolocationヘッダーをサポートしていない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プロトコル操作の範囲内ではなく、アプリケーション固有です。[RFC6280]、セクション4.2.1のガイダンスごとに、位置情報に関連するプライバシールールを、ロケーションサーバーまたはロケーションレシピエントのアーキテクチャロールを満たすSIPネットワークのエンティティ。特に、RFC 4119（特にセクション2.2.2）は、アクセス制御ルールを処理するためのガイダンスを提供します。さらに、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
UAの物理的位置の伝達はプライバシーの懸念を引き起こし、使用に応じて、おそらく認証と整合性の懸念があります。このドキュメントでは、セキュア/多目的インターネットメールエクステンション（S/MIME）のメッセージ本文を暗号化する（これは広く展開されていない）、参照ごとのシグナリングまたは伝達の場所を保護し、必要とするTLSなど、安全なメカニズムを通じて伝達を実現する必要があります。非難のすべてのエンティティは、自分自身を認証するために位置します。ロケーションベースのルーティングケースでは、パス上の1つ以上のプロキシが適切な新しい新しいものにメッセージをリターゲットするために位置情報を読み取る機能が必要であるため、S/MIMEなどのエンドツーエンドのメカニズムでロケーションペイロードを暗号化することは問題があります。宛先ユーザーエージェントサーバー（UAS）。データは特定の予想されるターゲットにのみ暗号化できます。したがって、複数の受信者がデータを検査する必要があり、それらの受信者をデータの送信者によって予測できない場合、暗号化は非常に実行可能な選択ではありません。 TLSを使用してロケーションホップバイホップを確保すると、メッセージが盗聴から保護され、
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はロケーションベースのルーティングサービスを提供するプロキシまたはプロキシとの信頼関係がないため、このようなエンドツーミドルソリューションも適切ではないかもしれません。
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.
ただし、参照により位置情報が伝達される場合、位置情報を検査したい各エンティティを適切に認証および承認することができます。これは、データの送信者が誰がデータを受信するかを予測する必要はなく、複数のエンティティが安全にそれを受信することを許可します。ただし、データの送信者と将来の受信者との間の事前関連付けの必要性はなくなりません。明らかに、いくつかの文脈では、この事前分類を推定することはできません。そうでない場合、事実上、位置情報への認識されていないアクセスを許可する必要があります。この場合、セッション開始プロトコルセキュア（SIP）などのパス暗号化と組み合わせて、参照ごとに擬似ランダム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]によると、ターゲットの位置に匿名のアイデンティティを持つ能力があることに注意してください。これは、「entity =」属性の<pesconis>要素[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.
UAが位置を挿入すると、UAは、セクション4で説明されているように、PIDF-LO [RFC4119]のフラグと同様に、シグナリングパスに沿ってその場所を明らかにするかどうかについてのポリシーを設定します。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 Geolocation Headerフィールドは、このドキュメントによって作成され、このドキュメントのセクション4.1にその定義とルールが作成され、次のようにIANA SIP-Parametersレジストリに追加されました。
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 Geolocation-Routing Headerフィールドは、このドキュメントのセクション4.2に定義とルールを使用して、このドキュメントによって作成され、次のようにIANA SIP-Parametersレジストリに追加されました。
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.
このドキュメントでは、2つの新しいSIPオプションタグを定義します。「Geolocation-Sip」と「Geolocation-HTTP」は、次のようにiana SIP-Parametersオプションタグレジストリに追加されました。
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".
Geolocation-HTTP「Geolocation-HTTP」オプションタグ信号[RFC6442]は、HTTP（RFC 2616）を介して位置情報を取得するためのサポートをサポートしています。このオプションをサポートする場所の受信者は、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 Geolocation-Errorヘッダーフィールドは、このドキュメントによって作成され、このドキュメントのセクション4.4の定義とルールを使用して、2つのアクションでIANA SIP-Parametersレジストリに追加されます。
1. Update the Header Fields registry with:
1. ：でヘッダーフィールドレジストリを更新してください。
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]
2. 「ヘッダーフィールドパラメーターとパラメーター値」というタイトルの部分で、追加：事前定義されたヘッダーフィールドパラメーター名値リファレンス----------------------------------------------------- ---------- --------ジオロケーションエラーコードはい[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の新しいレジストリを作成します。Geolocation-Errorコードは、エラー受信者によって実行されるアクションによって分類される場所の受信者によって発見されたエラーの理由を提供します。このレジストリの初期値を以下に示します。
Registry Name: Geolocation-Error Codes Reference: [RFC6442] Registration Procedures: Specification Required
レジストリ名：Geolocation-Errorコードリファレンス：[RFC6442]登録手順：仕様が必要
Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process Location" [RFC6442]
200 "Permission To Use Location Information" [RFC6442]
200「位置情報を使用する許可」[RFC6442]
201 "Permission To Retransmit Location Information to a Third Party" [RFC6442]
201「位置情報を第三者に再送信する許可」[RFC6442]
202 "Permission to Route based on Location Information" [RFC6442]
202「位置情報に基づいてルーティングする許可」[RFC6442]
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.
アリソン・マンキン、ディック・ナイト、ハンネス・ツェルズリン、ヘニング・シュルツリン、ジェームズ・ウィンターボトム、ジェロエン・ヴァン・ベンメル、ジャン・フランコイス・ミュール、ジョナサン・ローゼンバーグ、キース・ドレイジ、マーク・リンスナー、マルティン・トムソン、マイク・ハンマー、テッド・ハーディBarnes、Dan Wing、Matt Lepinski、John Elwell、Thomas Stach、Jacqueline Lee、Adam Roachの建設的なフィードバックとNITチェック。
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を助けてくれたPaul Kyzivatと、多くの有用なコメントとGeolocation-Errorヘッダーフィールドの適切な構築についてRobert Sparksに感謝します。
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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E。、「コンテンツIDおよびメッセージIDユニフォームリソースロケーター」、RFC 2392、1998年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、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] Campbell、B.、Ed。、Ed。、Rosenberg、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] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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.、Burger、E。、およびH. Kaplan、「セッション開始プロトコル（SIP）情報方法とパッケージフレームワーク」、RFC 6086、2011年1月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903] Niemi、A.、ed。、「セッション開始プロトコル（SIP）イベント州の出版物の拡張」、RFC 3903、2004年10月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483] Burger、E.、ed。、「セッション開始プロトコル（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] Winterbottom、J.、Thomson、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、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] Peterson、J.、Hardie、T。、およびJ. Morris、「SIPロケーション運搬に対する「再送信」の意味」、RFC 5606、2009年8月。
[GEO-FILTERS] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in SIP", Work in Progress, March 2010.
[Geo-Filters] Mahy、R.、Rosen、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.
[Helld-Deref] Winterbottom、J.、Tschofenig、H.、Schulzrinne、H.、Thomson、M。、およびM. Dawson、「Holdを使用した場所の逆方向のプロトコル」、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] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「インターネットアプリケーションの場所と場所のプライバシーのアーキテクチャ」、BCP 160、RFC6280、2011年7月。
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.
要件が意図的に明らかでない場合、その下に動機付けの声明が含まれています。
UAC-1 The SIP INVITE Method [RFC3261] must support location conveyance.
UAC-1 SIP Invite Method [RFC3261]は、位置輸送をサポートする必要があります。
UAC-2 The SIP MESSAGE method [RFC3428] must support location conveyance.
UAC-2 SIPメッセージメソッド[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.
動機：UAS間のダイアログが確立される前にUACが移動した場合、UACは位置情報を送信できる必要があります。場所が伝達され、UAが移動した場合、UACは以前に運ばれた場所を他の関係者に更新できる必要があります。
UAC-7 The privacy and security rules established within [RFC3693] that would categorize SIP as a 'Using Protocol' MUST be met.
UAC-7 [RFC3693]内に確立されたプライバシーおよびセキュリティルールは、SIPを「プロトコルを使用する」と分類する必要があります。
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.
動機：他のIETFロケーションプロトコルとメカニズムとの相互運用性。
UAC-9 There must be a mechanism for the UAC to request the UAS send its location.
UAC-9 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-9は、この要件が実装された場合に引き起こされた多くの問題のために、SIP WGによって非難されています。解決策は、上記のUASがUASの場所で元のUACに新しいリクエストを送信することです。
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がこの拡張機能を実装していないため、またはUACが拡張機能を実装していないが、ターゲットがどこにあるかがわからないため、予想される場合に位置を受け取らないことが発生する可能性があります。これは、たとえば、AccessネットワークがUACがサポートしているロケーション取得メカニズムを提供できなかったためかもしれません。これらのケースは区別する必要があります。
UAC-11 It must be possible to convey location to proxy servers along the path.
UAC-11パスに沿ってプロキシサーバーに場所を伝えることができる必要があります。
Motivation: Location-based routing.
モチベーション：ロケーションベースのルーティング。
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).
Sipcore WGは、これが許可されるが、UASの場所を伝えないというコンセンサスに達しました。むしろ、SIP仲介者がUACに次のSIPリクエストにどの場所を含めるかを通知するために（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に適用されます。
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.
Proxy-1プロキシサーバーは、SIPリクエストの処理中にロケーションヘッダーフィールドを追加できる必要があります。
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
動機：UACがそうすることができない場合、またはネットワークアサーションがUACの場所の信頼性が高い場合の場所のネットワークアサーションを提供する
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.
注：SIPシグナリングネットワークに接続されているUACは、VPNトンネルやローミングメカニズムなど、アクセスネットワーク配置を大きく変化させる可能性があるため、ネットワークがエンドポイントの位置を確実に知ることは困難です。SIPシグナリングネットワークにターゲットの実際の位置に関する信頼できる知識がない限り、プロキシはエンドポイントの位置を主張するべきではありません。
Proxy-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information.
Proxy-2該当する位置情報を提供しなかったUACに通知する一意の4xx応答がなければなりません。
Authors' Addresses
著者のアドレス
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034
ジェームズ・ポーク・シスコ・システム3913 Treemont Circle Colleyville、Texas 76034
33.00111N 96.68142W
33.00111N 96.68142W
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Brian Rosen NeuStar, Inc. 470 Conrad Dr. Mars, PA 16046
ブライアン・ローゼン・ノイスター・インク470コンラッド・博士・マーズ、ペンシルベニア州16046
40.70497N 80.01252W
40.70497N 80.01252W
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Jon Peterson NeuStar, Inc.
Jon Peterson Neustar、Inc。
EMail: jon.peterson@neustar.biz