[要約] RFC 5318は、SIPのP-Refused-URI-Listプライベートヘッダー（Pヘッダー）に関する仕様です。 この仕様の目的は、SIPセッションのリクエストに拒否されたURIリストを伝達するためのPヘッダーを定義することです。
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)
セッション開始プロトコル（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.
Copyright（c）2008 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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-Refused-URI-List Private-Header（P-Header）を指定します。このP-Headerは、Open Mobile Alliance（OMA）のプッシュで使用され、Cellular（POC）システムについて話します。これにより、URI-Listサーバーは、URIリストが組み込まれた着信URIリストの処理を拒否できます。また、このP-Headerは、URI-Listサーバーが、拒否を引き起こした埋め込みURIリストとそのようなURIリストを形成する個々のURIについてクライアントに通知することを可能にします。
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]).
Open Mobile Alliance（OMA）は、セッション開始プロトコル（SIP）[3]およびユニフォームリソース識別子（URI）リストサービス[5]を使用するCellular（POC）サービスを通知するプッシュを指定しました（OMAの詳細情報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-Refused-URI-Listと呼ばれる新しいPヘッダーを含むメカニズムの概要を説明します。セクション5では、この新しいP-Headerの構文を定義しています。セクション6では、P-Headerの使用方法を指定します。セクション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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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リストを含む招待リクエストを送信します。
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.
[6]で定義されている手順に従って、POCネットワークは、そのような招待リクエストを受信し、URIリストの各URIに対する個々の招待リクエストを生成します。
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グループセッションの創始者は、初期のURIリストに個々のPOCユーザーを識別する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は、望ましい動作を示しています。Originator（表示なし）は、URIリストfriends@example.orgをuri alice@example.comとともに最初のURIリストに配置します。POCネットワークは、friends@example.orgをメンバーのbob@example.orgとcarol@example.netに解決し、すべての受信者に招待リクエストを送信します。
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ネットワークは、POCサーバーで構成されており、POCサーバーは、プロキシまたはB2BUA（連続したユーザーエージェント）として動作できるSIPエンティティです。論理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.
図2は、図1に示すシナリオでPOCネットワークのPOCサーバーがどのように動作するかを示しています。発信元のPOCユーザーエージェントは、参加しているPOCサーバーにURIリストを含む招待リクエスト（1）を送信します。Originatorの参加POCサーバーは、招待リクエストを受信し、アドホックPOCグループセッションのPOCサーバーの制御の役割を想定し、URIリストの各URIに招待リクエストを送信します。
+-------------+
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リストの2番目のURI、friends@example.orgは、URIリストを識別します。POC用語では、friends@example.comは事前に配置されたPOCグループを特定します。friends@example.comのメンバーシップを知っているexample.orgのPOCサーバーは、そのPOCサーバーがアドホックPOCの制御POCサーバーとして機能しないため、friends@example.orgのメンバーに招待リクエストを送信することはできません。グループセッションが確立されます。代わりに、POCサーバーの制御@example.orgがメンバーがbob@example.orgとcarol@example.netであることを通知します。この情報を受信すると、POCサーバーが制御すると、bob@example.orgおよびcarol@example.netに対する招待リクエストが生成されます。
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の一部のリストのみを含めることができます。さらに、参加しているPOCサーバーが返されるURIは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.
現在、参加しているPOCサーバーが、URIがそのリストとそのリストのメンバーを識別することを制御するPOCサーバーに通知するメカニズムはなく、リストに含まれるURIを示すメカニズムもありません。このドキュメントは、そのようなメカニズムを定義しています：p-Refused-URI-List P-Header。
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リストを含むURIリストを備えた招待リクエストを受信し、サーバーがリクエストを処理できない場合、P-Refused-URI-List P-Headerで403（禁止）応答を返します、図3に示すように、p-Refused-URI-List P-Headerには、リクエストの拒否を引き起こした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:
以下は、P-Refused-URI-List P-Headerの拡張されたBackus-Naurフォーム（BNF）[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-Headerパラメーターには、RFC 2392 [2]で定義されているCID-URLを含める必要があります。
The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are defined in [3].
hcolon、semi、equal、ldquot、rdquot、およびgeneric-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反射-RI-LISTエントリを含めることができます。P-Refused-URI-Listヘッダーフィールドは、他の応答とともに使用してはなりません。P-Refused-URI-List P-Headerには1つ以上の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リストを含む身体部分が含まれている場合があります。これらの身体部分は、コンテンツID [2]を介してP補給-RI-Listエントリによって参照できます。p-Refused-URIリストに定義されたコンテンツIDがある場合、身体部分の1つには同等のコンテンツ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-Listサーバーがその情報を開示する意思がある場合、クライアントはどの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サーバーに招待リクエストを送信します。参加しているPOCサーバーは、403（禁止）応答でリクエストを拒否します。403の応答には、参加しているPOCサーバーがメッセージの本文でこの制御POCサーバーに開示することを決定する拒否されたURIリストのメンバーを運ぶP補給-RI-LIST P-Headerがあります。
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 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
--boundary1
Content-Type: application/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--
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].
uris sip：friends-list@example.net and sip：colleagueslist@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
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
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>
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
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--
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：friendlist@example.netおよびsip：colleagues@example.netのメンバーを決定できます。この制御POCサーバー。さらに、制御するPOCサーバーは、参加するPOCサーバーが通常のURI-Listサーバー手順に従って、発信要求を送信していないと推測できます。
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-Refused-URI-Listヘッダーフィールドは、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.
OMA POCサービスは、特定のセッションで、1つのPOCサーバーのみが着信URIリストを解決し、これらのリストのメンバーに招待状を送信できるように設計されています。この制限は、パブリックインターネットで使用されるように開発されたサービスには存在しません。したがって、P-Refused-URI-List P-Headerは、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-Refused-URI-List P-Headerを使用するには、通常、パブリックインターネットには存在しないサーバー間の特別な信頼関係が必要です。
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-Listサービスの基本的な動作を変更しないことに注意することが重要です。P-Refused-URI-Listは、クライアントにリクエストの拒否に関する追加情報を提供するだけです。
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 refused-URI-List P-Headerを処理するネットワーク要素は信頼されていると想定されています。また、攻撃者は、これらの要素間のプロトコルメッセージにアクセスできるとは思われません。これは、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補給-RI-Listの使用に関連する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.
情報の開示：Rogueエンティティは、URIリストサーバーがこれらのURIリストに関する情報を不正ユーザーに送信した場合、特定のURIリストのメンバーに関する情報を取得できる場合があります。したがって、URI-Listサーバーは、その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.
著者は、この文書の徹底的で献身的なレビューを行ったTom Hillerに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[2] Levinson、E。、「コンテンツIDおよびメッセージ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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[4] Crocker、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] Camarillo、G。およびA. Roach、「セッション開始プロトコル（SIP）URI-List Servicesのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
[6] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[6] Camarillo、G。およびA. Johnston、「セッション開始プロトコル（SIP）のリクエストコンテン付きリストを使用した会議設立」、RFC 5366、2008年10月。
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[7] Rosenberg、J。、「リソースリストを表現するための拡張可能なマークアップ言語（XML）形式」、RFC 4826、2007年5月。
[8] Open Mobile Alliance, "OMA PoC System Description: Draft Version 2.0", April 2007.
[8] オープンモバイルアライアンス、「OMA POCシステム説明：ドラフトバージョン2.0」、2007年4月。
[9] Open Mobile Alliance, "Push to talk over Cellular (PoC) - Architecture: Draft Version 2.0", April 2007.
[9] Open Mobile Alliance、「Push to Talk over Cellular（POC） - アーキテクチャ：ドラフトバージョン2.0」、2007年4月。
Authors' Addresses
著者のアドレス
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com