Network Working Group J. Hautakorpi
Request for Comments: 5318 G. Camarillo
Category: Informational Ericsson
December 2008
The Session Initiation Protocol (SIP)
P-Refused-URI-List Private-Header (P-Header)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list.
この文書では、セッション開始プロトコル（SIP）P-拒否-URI-一覧プライベートヘッダ（P-ヘッダ）を指定します。このP-ヘッダーは、トークオーバーセルラー（PoC）システムするオープン・モバイル・アライアンスの（OMA）のプッシュに使用されています。これは、URIリストが埋め込まれているの着信URIリストの取り扱いを拒否するURIリストサーバを可能にします。 URIリストサーバが拒否して、そのようなURIのリストを形成する個々のURIを引き起こし、埋め込みURIのリストについてクライアントに通知するためにこのP-ヘッダーもことが可能となります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Usage Scenario ..................................................3
4. Overview of Operation ...........................................6
5. Syntax of P-Refused-URI-List Header Field .......................6
6. Response Generation .............................................7
7. Message Sequence Example ........................................7
8. Applicability ...................................................9
9. Security Considerations ........................................10
10. IANA Considerations ...........................................11
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................12
The Open Mobile Alliance (OMA) has specified the Push to talk over Cellular (PoC) service, which uses the Session Initiation Protocol (SIP) [3] and Uniform Resource Identifier (URI)-list services [5] (more information about OMA PoC can be found at [8]).
オープン・モバイル・アライアンス（OMA）は、セッション開始プロトコル（SIP）OMAについて[3]とのURI（Uniform Resource Identifier）-listサービス[5]（より多くの情報を使用して携帯電話（POC）サービス、上の話をするプッシュを指定しましたPOCが[8]）に見出すことができます。
OMA PoC needs a mechanism for servers to refuse the handling of incoming URI lists when these have embedded URI lists. Such a mechanism is intended to be used to establish a particular type of PoC session called an ad-hoc PoC group session.
OMAのPoCは、これらがURIリストが埋め込まれているときのサーバーが着信URIリストの取り扱いを拒否するための仕組みが必要です。そのような機構は、PoCセッションの特定のタイプを確立するために使用されることが意図されているアドホックPoCグループセッションと呼ばれます。
The remainder of this document is organized as follows. Section 3 describes the scenario where the mechanism will be used. Section 4 provides an overview of the mechanism, which includes a new P-Header called P-Refused-URI-List. Section 5 defines the syntax of this new P-Header. Section 6 specifies how to use the P-Header. Section 7 provides a usage example. Section 8 describes the applicability of the P-Header. Security considerations are discussed in Section 9 and, finally, the IANA considerations are stated in Section 10.
このドキュメントの残りは以下の通り構成されています。第3節ではメカニズムが使用されるシナリオについて説明します。セクション4は、P-拒否-URI-リストと呼ばれる新しいP-ヘッダを含む機構の概要を提供します。第5節では、この新しいP-ヘッダーの構文を定義します。第6節は、P-ヘッダーを使用する方法を指定します。セクション7は、使用例を提供します。第8節は、P-ヘッダーの適用可能性を説明しています。セキュリティの考慮事項は、第9章で議論されていると、最終的には、IANAの考慮事項は、セクション10に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
An ad-hoc PoC group session is a type of multi-party PoC session. The originator of a particular ad-hoc PoC group session chooses in an ad-hoc manner (e.g., selecting from an address book) the set of desired participants. In order to establish the ad-hoc PoC group session, the originator sends an INVITE request with a URI list that contains the URIs of those participants.
アドホックPoCグループセッションは、マルチパーティPoCセッションのタイプです。特定のアドホックPoCグループセッションの発信者は、アドホックな方法で選択する（例えば、アドレス帳から選択）所望の参加者の集合。アドホックPoCグループセッションを確立するために、発信者は、これらの参加者のURIを含んでいるURIリストとのINVITEリクエストを送信します。
The PoC network, following the procedures defined in [6], receives such an INVITE request and generates an individual INVITE request towards each of the URIs in the URI list.
前記PoCネットワークは、[6]で定義された手順に従って、このようなINVITE要求を受信し、個人がURIリスト内のURIのそれぞれに向かってINVITE要求を生成します。
In previous versions of the OMA PoC service, the originator of an ad-hoc PoC group session was only allowed to populate the initial URI list with URIs identifying individual PoC users. Later versions of the service allow the originator to also include URI lists whose entries represent URI lists. That is, the initial URI list contains entries that are URI lists themselves. The expected service behavior then is that the members of the embedded URI lists are invited to join the ad-hoc PoC group session.
OMA PoCサービスの以前のバージョンでは、アドホックPoCグループセッションの創始者は、個人だけPoCユーザを特定するURIで初期のURIリストを移入させました。サービスの後のバージョンは、発信者がまた、そのエントリURIのリストを表すURIのリストを含めることができます。これは最初のURIリストはURIが自分自身を一覧表示しているエントリが含まれています。期待されるサービスの振る舞いは、埋め込まれたURIリストのメンバーは、アドホックPoCグループセッションに招待されていることです。
Figure 1 illustrates the desired behavior. The originator (not shown) places the URI list friends@example.org, along with the URI alice@example.com, in the initial URI list. The PoC network resolves friends@example.org into its members, bob@example.org and carol@example.net, and sends INVITE requests to all the recipients.
図1は、所望の挙動を示します。発信元（図示せず）は、最初のURIのリストで、URIのalice@example.comとともに、URIリストfriends@example.orgを配置します。 PoCネットワークは、そのメンバー、bob@example.orgとcarol@example.netにfriends@example.orgを解決し、すべての受信者にINVITE要求を送信します。
2. INVITE
+------------------>
| alice@example.com
|
|
+-------------+
| |
1. INVITE | | 3. INVITE
------------------>| PoC Network |---------------->
alice@example.com | | bob@example.org
friends@example.org | |
+-------------+
|
|
|
| 4. INVITE
+------------------>
carol@example.net
Figure 1: PoC Expected Behavior
図1：のPoC予想される動作
The PoC network in Figure 1 consists of PoC servers, which are SIP entities that can behave as proxies or B2BUAs (Back-to-Back User Agents). There are two types of logical PoC servers: controlling and participating.
図1でのPoCネットワークは、プロキシまたは型B2BUA（バックツーバックユーザエージェント）として振る舞うことができるSIPエンティティでのPoCサーバ、から成ります。制御および参加：論理のPoCサーバの2種類があります。
In an ad-hoc PoC group session, there is always exactly one controlling PoC server. The controlling PoC server of an ad-hoc PoC group session resolves an incoming URI list and sends INVITEs to the members of the list. The controlling PoC server also functions as the focus of the session. Every participant in an ad-hoc PoC group has an associated participating PoC server, which resides in the home domain of the participant.
アドホックPoCグループセッションでは、1台の制御PoCサーバは正確に常にあります。アドホックPoCグループセッションの制御PoCサーバは、着信URIリストを解決し、リストのメンバーに招待を送信します。制御PoCサーバは、セッションの焦点として機能します。アドホックPoCグループ内のすべての参加者は、参加者のホームドメインに存在する関連する参加PoCサーバを、持っています。
Figure 2 shows how the PoC servers of the PoC network behave in the scenario shown in Figure 1. An originating PoC user agent sends an INVITE request (1) with a URI list to its participating PoC server. The participating PoC server of the originator receives the INVITE request, assumes the role of controlling PoC server for the ad-hoc PoC group session, and sends an INVITE request to each of the URIs in the URI list.
発信PoCユーザエージェント、図1に示したシナリオでのPoCネットワーク挙動の前記PoCサーバは、その参加PoCサーバにURIリストとINVITE要求（1）を送信する方法を図2に示します。発信者の参加PoCサーバは、INVITEリクエストを受信し、アドホックPoCグループセッションのためのPoCサーバを制御する役割を担い、そしてURIリスト内のURIのそれぞれにINVITEリクエストを送信します。
+-------------+
2. INVITE | Particip. |
+------------------>| PoC server |->
| alice@example.com | example.com |
| +-------------+
|
+-------------+ 3. INVITE +-------------+
| |-------------------->| |
1. INVITE | Controlling | friends@example.org | Particip. |
---------------->| PoC server | | PoC server |->
alice@example.com | | 4. 403 Forbidden | example.org |
friends@example.org| |<--------------------| |
+-------------+ bob@example.org +-------------+
| | carol@example.net ^
| | |
| | 5. INVITE |
| +--------------------------------+
| bob@example.org
|
| +------------+
| 6. INVITE | Particip. |
+------------------>| PoC server |->
carol@example.net | example.net|
+------------+
Figure 2: PoC Network Behavior
図2：のPoCネットワークの動作
The first URI of the list, alice@example.com, identifies a single user. The second URI of the URI list, friends@example.org, identifies a URI list. In PoC terminology, friends@example.com identifies a pre-arranged PoC group. The PoC server at example.org, which knows the membership of friends@example.com, cannot send INVITE requests to the members of friends@example.org because that PoC server does not act as a controlling PoC server for the ad-hoc PoC group session being established. Instead, it informs the controlling PoC server that friends@example.org is a list whose members are bob@example.org and carol@example.net. Upon receiving this information, the controlling PoC server generates INVITE requests towards bob@example.org and carol@example.net.
リストの最初のURI、alice@example.comは、単一のユーザを識別する。 URIリストの第二のURIは、friends@example.org、URIのリストを識別する。前記PoC用語では、friends@example.comは、予め配置されたPoCグループを識別する。 friends@example.comのメンバーシップを知っているexample.orgでPoCサーバは、そのPoCサーバがアドホックのPoC用制御PoCサーバとして機能していないため、friends@example.orgのメンバーにINVITE要求を送信することはできません。グループセッションが確立されています。その代わりに、friends@example.orgメンバーbob@example.orgとcarol@example.netあるリストである制御PoCサーバに通知します。この情報を受信すると、制御PoCサーバはbob@example.orgとcarol@example.net向かってINVITE要求を生成します。
Although not shown in the above example, the participating PoC server (example.org) can include -- based on policy, presence of the members, etc. -- just a partial list of URIs of the URI list. Furthermore, a URI that the participating PoC server returns can be a URI list.
上記の例では示していないが、参加PoCサーバは、（example.org）を含むことができる - URIリストのURIのちょうど部分的なリスト - ポリシー、メンバーの存在、等に基づきます。さらに、URI参加PoCサーバのリターンはURIリストすることができます。
At present, there is not a mechanism for a participating PoC server to inform a controlling PoC server that a URI identifies a list and the members of that list, nor is there a mechanism to indicate the URIs contained in the list. This document defines such a mechanism: the P-Refused-URI-List P-Header.
現時点では、URIはリストと、そのリストのメンバーを特定する制御PoCサーバに通知するために、参加PoCサーバのためのメカニズムがなく、また、リストに含まれるURIを示すためのメカニズムがあります。 P-拒否-URIリストP-ヘッダ：この文書では、そのようなメカニズムを定義します。
When a URI-list server receives an INVITE request with a URI list containing entries that are URI lists themselves, and the server cannot handle the request, it returns a 403 (Forbidden) response with a P-Refused-URI-List P-Header, as shown in Figure 3. The P-Refused-URI-List P-Header contains the members of the URI list or lists that caused the rejection of the request. This way, the client can send requests directly to those member URIs.
URIリストサーバが、URIが自分自身をリストしているエントリを含むURIリストにINVITEリクエストを受信し、サーバーが要求を処理できない場合は、P-拒否-URIリストP-ヘッダーで403（禁止）応答を返します図3に示すように、P-拒否-URI-リストP-ヘッダは、要求の拒否を引き起こしURIリスト又はリストのメンバーを含みます。この方法では、クライアントはそれらのメンバーのURIに直接リクエストを送信することができます。
+---------+ INVITE request +----------+
| |------------------------------>| |
| | [URI list in a URI list] | URI-list |
| Client | | server |
| | 403 Forbidden | |
| |<------------------------------| |
| | [Content of refused URI list] | |
+---------+ +----------+
Figure 3: Operational Overview
図3：動作概要
The following is the augmented Backus-Naur Form (BNF) [4] syntax of the P-Refused-URI-List P-Header:
拡張バッカスナウア記法（BNF）P-拒否-URI-リストP-ヘッダの[4]構文は次のとおり
P-Refused-URI-List = "P-Refused-URI-List" HCOLON
uri-list-entry
*(COMMA uri-list-entry)
uri-list-entry = ( name-addr / addr-spec )
*( SEMI refused-param )
refused-param = members-param / generic-param
members-param = "members" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT
The members P-Header parameter MUST contain a cid-url, which is defined in RFC 2392 [2].
部材P-ヘッダパラメータは、RFC 2392で定義されているCID-URLを含まなければならない[2]。
The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are defined in [3].
HCOLON、SEMI、EQUAL、LDQUOT、RDQUOT、および汎用-PARAM [3]で定義されています。
A 403 (Forbidden) response can contain more than one P-Refused-URI-List entries. The P-Refused-URI-List header field MUST NOT be used with any other response. The P-Refused-URI-List P-Header contains one or more URIs, which were present in the URI list in the incoming request and could not be handled by the server. Additionally, the P-Refused-URI-List can optionally carry some or all of the members of the URI lists identified by those URIs.
403（禁止）応答は、複数のP-拒否-URIリストエントリを含むことができます。 P-拒否-URIリストヘッダーフィールドは、他の応答に使用してはいけません。 P-拒否-URI-リストP-ヘッダは、着信要求にURIリストに存在し、サーバによって処理することができなかった一つ以上のURIを含んでいます。また、P-拒否-URI-リストは、必要に応じてそれらのURIで識別されるURIリストのメンバーの一部またはすべてを運ぶことができます。
The 403 (Forbidden) response MAY contain body parts which contain URI lists. Those body parts can be referenced by the P-Refused-URI-List entries through their Content-IDs [2]. If there is a Content-ID defined in the P-Refused-URI-List, one of the body parts MUST have an equivalent Content-ID. The format of a URI list is service specific.
403（禁止）応答は、URIのリストが含まれている身体の部分を含むかもしれません。これらの体の部分は、それらのContent-IDを介してP-拒否-URIリストエントリによって参照することができる[2]。コンテンツIDはP-拒否-URI-Listに定義されている場合は、体の部分の一つは、同等のContent-IDを持っていなければなりません。 URIリストの形式は、サービス固有のものです。
This kind of message structure enables clients to determine which URI relates to which URI list, if the URI-list server is willing to disclose that information. Furthermore, the information enclosed in the URI lists enable clients to take further actions to remedy the rejection situation (e.g., send individual requests to the members of the URI list).
URIリストサーバはその情報を開示する意思がある場合、メッセージ構造のこの種は、URIがどのURIリストに関係するかを決定するためにクライアントを可能にします。さらに、URIリストに囲まれた情報（例えば、URIリストのメンバーに個別のリクエストを送信する）拒絶状況を改善するために更なる行動をとるようにクライアントを有効にしてください。
In the following message sequence example, a controlling PoC server sends an INVITE request to a participating PoC server. The participating PoC server rejects the request with a 403 (Forbidden) response. The 403 response has a P-Refused-URI-List P-Header that carries the members of the rejected URI lists that the participating PoC server determines to disclose to this controlling PoC server in the body of the message.
次のメッセージシーケンス例では、制御PoCサーバは、参加PoCサーバにINVITEリクエストを送信します。参加PoCサーバは403（禁止）応答で要求を拒否します。 403応答は拒否URIのメンバーを運ぶ、参加PoCサーバは、メッセージの本文に、この制御PoCサーバに開示することを決定することを示していますP-拒否-URIリストP-ヘッダーを持っています。
Controlling PoC server Participating PoC server
example.com example.net
| |
| INVITE |
|-------------------------------->|
| |
| 403 Forbidden |
|<--------------------------------|
| |
Figure 4: Message Sequence Example
図4：メッセージシーケンスの例
The INVITE request shown in Figure 4 is as follows (Via header fields are not shown for simplicity):
（簡略化のため図示されていないヘッダフィールドを介して）次のように、図4に示すINVITE要求です。
INVITE sip:poc-service@example.net SIP/2.0 Max-Forwards: 70 From: PoC service <sip:poc-service@example.com>;tag=4fxaed73sl To: PoC service <sip:poc-service@example.net> Call-ID: 7xTn9vxNit65XU7p4@example.com CSeq: 1 INVITE Contact: <sip:poc-service@poc-as.example.com> Require: recipient-list-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 538
SIPのINVITE：poc-service@example.net SIP / 2.0マックスフォワード：5,441：PoCサービス<SIP：poc-service@example.com>;タグ= 4fxaed73sl：をPoCサービス<SIP：POCサービス@例。ネット>コール-IDを：7xTn9vxNit65XU7p4@example.comのCSeq：連絡先を1 INVITE：<SIP：poc-service@poc-as.example.com>要求：受信者リスト - 招待のContent-Typeを：混合/マルチパート;境界=」 boundary1" コンテンツの長さ：538
--boundary1 Content-Type: application/sdp
--boundary1のContent-Type：アプリケーション/ SDP
(SDP not shown)
（SDP図示せず）
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="sip:bob@example.net"/> <entry uri="sip:friends-list@example.net"/> <entry uri="sip:colleagues-list@example.net"/> </list> </resource-lists> --boundary1--
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト"> <リスト> <エントリーのURI =「SIP：ボブ@ example.net "/> <エントリURI =" SIP：friends-list@example.net "/> <エントリURI =" SIP：colleagues-list@example.net "/> </リスト> </リソースリスト> --boundary1--
The URIs sip:friends-list@example.net and sip:colleagues-list@example.net in the example above are actually references to URI lists (i.e., pre-arranged PoC groups). In the following response, the URI lists are in the XML resource list format [7].
URIをSIP：friends-list@example.netとSIP：上記の例でcolleagues-list@example.netは、実際にはURIリスト（すなわち、事前に配置されたPoCグループ）への参照です。次の応答では、URIリストはXMLリソースリスト形式である[7]。
The content of the 403 (Forbidden) response in Figure 4 is as follows (Via header fields are not shown for simplicity):
（簡略化のため図示されていないヘッダフィールドを介して）次のように図4の403（禁止）応答の内容です。
SIP/2.0 403 Forbidden
From: PoC service <sip:poc-service@example.com>;tag=4fxaed73sl
To: PoC service <sip:poc-service@example.net>;tag=814254
Call-ID: 7xTn9vxNit65XU7p4@example.com
CSeq: 1 INVITE
P-Refused-URI-List: sip:friends-list@example.net;
members=<cid:an3bt8jf03@example.net>
P-Refused-URI-List: sip:colleagues-list@example.net;
members=<cid:bn35n8jf04@example.net> Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 745
メンバー= <CID：bn35n8jf04@example.net>のContent-Type：multipart / mixedの;境界= "boundary1" のContent-Length：745
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-ID: <an3bt8jf03@example.net>
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リストのContent-ID：<an3bt8jf03@example.net>
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="sip:bill@example.org"/> <entry uri="sip:randy@example.com"/> <entry uri="sip:eddy@example.com"/> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト"> <リスト> <エントリーのURI =「SIP：法案@ example.org "/> <エントリURI =" SIP：randy@example.com "/> <エントリURI =" SIP：eddy@example.com "/> </リスト> </資源リスト>
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-ID: <bn35n8jf04@example.net>
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リストのContent-ID：<bn35n8jf04@example.net>
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="sip:joe@example.org"/> <entry uri="sip:carol@example.com"/> </list> </resource-lists> --boundary1--
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト"> <リスト> <エントリーのURI =「SIP：ジョー@ example.org "/> <エントリURI =" SIP：carol@example.com "/> </リスト> </リソース・リスト> --boundary1--
Using the message body of the 403 (Forbidden) response above, the controlling PoC server can determine the members of sip:friend-list@example.net and sip:colleagues-list@example.net that the participating PoC server determines to disclose to this controlling PoC server. Furthermore, the controlling PoC server can deduce that the participating PoC server has not sent any outgoing requests, per regular URI-list server procedures.
上記403（禁止）応答のメッセージ本体を使用して、制御PoCサーバは、SIPのメンバーを決定することができる：friend-list@example.netとSIP：colleagues-list@example.net参加PoCサーバは、に開示されていることを決定することこの制御PoCサーバ。さらに、制御PoCサーバは、参加PoCサーバは、通常のURIリストサーバの手順ごとに、任意の発信要求を送信していないことを推測することができます。
The P-Refused-URI-List header field is intended to be used in OMA PoC networks. This header field is used between PoC servers and carries information about those URI lists that were rejected by the server receiving the request.
P-拒否-URIリストヘッダフィールドは、OMAののPoCネットワークで使用されることが意図されます。このヘッダーフィールドは、PoCサーバ間で使用すると、要求を受信するサーバによって拒否されたそれらのURIリストについての情報を運びます。
The OMA PoC services is designed so that, in a given session, only one PoC server can resolve incoming URI lists and send INVITEs to members of these lists. This restriction is not present on services developed to be used on the public Internet. Therefore, the P-Refused-URI-List P-Header does not seem to have general applicability outside the OMA PoC service.
特定のセッションでは、唯一のPoCサーバが着信URIリストを解決することができ、これらのリストのメンバーに招待を送信する、ようにOMAのPoCサービスは設計されています。この制限は、公共のインターネット上で使用されるように開発されたサービス上に存在しません。したがって、P-拒否-URI-一覧P-ヘッダーは、OMA PoCサービス外の一般的な適用可能性を有していないようです。
Additionally, the use of the P-Refused-URI-List P-Header requires special trust relationships between servers that do not typically exist on the public Internet.
また、P-拒否-URI-一覧P-ヘッダーの使用は、典型的には、公共のインターネット上に存在しないサーバ間の特別な信頼関係が必要です。
It is important to note that the P-Refused-URI-List is optional and does not change the basic behavior of a SIP URI-list service. The P-Refused-URI-List only provides clients with additional information about the refusal of the request.
P-拒否-URI-リストはオプションであり、SIP URI - リストサービスの基本的な動作を変更しないことに注意することが重要です。 P-拒否-URI-リストは、要求の拒否に関する追加情報をクライアントに提供します。
It is assumed that the network elements handling the P-Refused-URI-List P-Header are trusted. Also, attackers are not supposed to have access to the protocol messages between those elements. This is because the P-Refused-URI-List is intended to be used in the OMA PoC environment, which is implemented in the operators' core network; for more on OMA PoC security assumptions, see [9]. Traffic protection between network elements is achieved by using IP Security (IPsec) and sometimes by physically protecting the network.
P-拒否-URI-一覧P-ヘッダーを扱うネットワーク要素が信頼されているものとします。また、攻撃者は、これらの要素間のプロトコルメッセージにアクセスすることが想定されていません。 P-拒否-URI-リストがオペレータのコアネットワークに実装されたOMAのPoC環境で使用されることが意図されるからです。 OMAのPoCセキュリティの前提条件の詳細については、[9]を参照してください。ネットワーク要素間のトラフィックの保護は、物理的にネットワークを保護することにより、時にはIPセキュリティ（IPSec）とを使用することによって達成されます。
However, implementors and administrators should be aware of two special security considerations related to the use of P-Refused-URI-List:
しかし、実装者と管理者は、P-拒否-URI-リストの使用に関連する2つの特別なセキュリティの考慮事項に注意する必要があります：
Eavesdropping: 403 (Forbidden) responses may contain information about the members of a given URI list. Eavesdroppers can acquire this information if the 403 (Forbidden) responses are not encrypted. Therefore, it is RECOMMENDED that either hop-by-hop or end-to-end encryption (e.g., using TLS or S/MIME, respectively) is used.
盗聴：403（禁止）応答が与えられたURIリストのメンバーについての情報が含まれていてもよいです。 403（禁止）応答は暗号化されていない場合、盗聴者は、この情報を取得することができます。したがって、いずれかのホップバイホップ又はエンドツーエンド暗号化（例えば、TLSまたはS / MIMEを使用して、それぞれ）を使用することが推奨されます。
Disclosing information: A rogue entity may be able to acquire information about the members of a given URI list if the URI-list server sends information about those URI lists to unauthorized users. Therefore, it is RECOMMENDED that a URI-list server discloses the content of that URI-list only to authorized clients.
情報開示：URIリストサーバは、権限のないユーザーにそれらのURIリストについての情報を送信した場合、不正なエンティティは、与えられたURIリストのメンバーについての情報を取得できる可能性があります。したがって、URIリストサーバが唯一承認されたクライアントへのURIリストの内容を開示していることが推奨されます。
The IANA has made two additions to the Session Initiation Protocol (SIP) Parameters registry. The following header field has been added to the Header Fields sub-registry.
IANAは、セッション開始プロトコル（SIP）パラメータレジストリに2件の追加を行いました。次のヘッダフィールドは、ヘッダフィールドのサブレジストリに追加されました。
Header Name compact Reference
----------------- ------- ---------
P-Refused-URI-List [RFC5318]
The following header field parameter has been added to the Header Field Parameters and Parameter Values sub-registry.
次ヘッダフィールドパラメータは、ヘッダフィールドパラメータおよびパラメータのサブレジストリの値に追加されています。
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
P-Refused-URI-List members No [RFC5318]
Authors would like to thank Tom Hiller who did a thorough, dedicated review for this document.
著者は、この文書の徹底、専用のレビューをしたトム・ヒラーに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[2]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[3] 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.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[4]クロッカー、D.、およびP. Overell、 "増補BNF構文仕様のため：ABNF"、STD 68、RFC 5234、2008年1月。
[5] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[5]、RFC 5363、2008年10月カマリロ、G.およびA.ローチ、 "セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークおよびセキュリティに関する注意事項" を。
[6] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[6]キャマリロ、G.、およびA.ジョンストン、「セッション開始プロトコルで（SIP）を要求含有リストを使用して会議の確立」、RFC 5366、2008年10月。
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[7]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）リソースリストを表現するための形式"、RFC 4826、2007年5月。
[8] Open Mobile Alliance, "OMA PoC System Description: Draft Version 2.0", April 2007.
[8]オープン・モバイル・アライアンス、：2007年4月 "OMAのPoCシステムの説明は、バージョン2.0のドラフト"。
[9] Open Mobile Alliance, "Push to talk over Cellular (PoC) - Architecture: Draft Version 2.0", April 2007.
[9]オープン・モバイル・アライアンス、 "セルラー（POC）以上の話をプッシュ - アーキテクチャ：バージョン2.0草案"、2007年4月。
Authors' Addresses
著者のアドレス
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
ヤニHautakorpiエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
メールアドレス：Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com