RFC5318 日本語訳
5318 The Session Initiation Protocol (SIP) P-Refused-URI-ListPrivate-Header (P-Header). J. Hautakorpi, G. Camarillo. December 2008. (Format: TXT=24589 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Hautakorpi
Request for Comments: 5318 G. Camarillo
Category: Informational Ericsson
December 2008
Hautakorpiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5318年のG.キャマリロカテゴリ: 情報のエリクソン2008年12月
The Session Initiation Protocol (SIP)
P-Refused-URI-List Private-Header (P-Header)
URIリストが拒否された開始プロトコル(一口)Pセッションの個人的なヘッダー(P-ヘッダー)
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)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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.
このドキュメントはSession Initiationプロトコル(SIP)P拒否されたURIリスト兵士ヘッダー(P-ヘッダー)を指定します。 このP-ヘッダーは、Cellular(PoC)システムについて論議するのにオープンのモバイルAlliance(OMA)のプッシュに使用されます。 それは、URIリストサーバがURIリストを埋め込んだ入って来るURIリストの取り扱いを拒否するのを可能にします。 また、このP-ヘッダーはURIリストサーバが拒絶を引き起こした埋め込まれたURIリストとそのようなURIリストを形成する個々のURIに関してクライアントに知らせるのを可能にします。
Hautakorpi & Camarillo Informational [Page 1] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[1ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
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
1. 序論…2 2. 用語…2 3. 用法シナリオ…3 4. 操作の概要…6 5. P拒否されたURIリストヘッダーフィールドの構文…6 6. 応答世代…7 7. メッセージ系列の例…7 8. 適用性…9 9. セキュリティ問題…10 10. IANA問題…11 11. 承認…11 12. 参照…11 12.1. 標準の参照…11 12.2. 有益な参照…12
1. Introduction
1. 序論
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]).
オープンのモバイルAlliance(OMA)はCellular(PoC)サービスについて論議するためにPushを指定しました、Session Initiationプロトコル(SIP)[3]とUniform Resource Identifier(URI)リストサービス[5]を使用するもの。([8])でOMA PoCに関する詳しい情報は見つけることができます。
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.
これらがURIリストを埋め込んだとき、サーバが入って来るURIリストの取り扱いを拒否するように、OMA PoCはメカニズムを必要とします。 臨時の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はメカニズムの概要を提供します。(メカニズムはURIリストが拒否されたPと呼ばれる新しいP-ヘッダーを含んでいます)。 セクション5はこの新しいP-ヘッダーの構文を定義します。 セクション6はP-ヘッダーを使用する方法を指定します。 セクション7は使用例を提供します。 セクション8はP-ヘッダーの適用性について説明します。 セクション9でセキュリティ問題について議論します、そして、最終的に、IANA問題はセクション10に述べられています。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
Hautakorpi & Camarillo Informational [Page 2] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[2ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
3. Usage Scenario
3. 用法シナリオ
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グループセッションの創始者は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は望まれた行動を例証します。 創始者(目立たない)はURI alice@example.com に伴うURIリスト friends@example.org を初期のURIリストに置きます。 PoCネットワークは、メンバー( bob@example.org と carol@example.net )に friends@example.org に変えて、すべての受取人への要求をINVITEに送ります。
Hautakorpi & Camarillo Informational [Page 3] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[3ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
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
2. +を招待してください。------------------>| alice@example.com | | +-------------+ | | 1. 招待| | 3. 招待------------------>| PoCネットワーク|----------------> alice@example.com | | bob@example.org 友人@example.org| | +-------------+ | | | | 4. +を招待してください。------------------> 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サーバから成ります。(サーバはプロキシかB2BUAs(支持するために戻っているUserエージェント)として振る舞うことができるSIP実体です)。 2つのタイプの論理的なPoCサーバがあります: 制御と参加。
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リストを決議して、リストのメンバーにINVITEsを送ります。 また、制御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はPoCネットワークのPoCサーバが図1のシナリオでどう振る舞うかを示しています。 起因しているPoCユーザエージェントはURIリストと共にINVITE要求(1)を参加しているPoCサーバに送ります。創始者の参加しているPoCサーバは、INVITE要求を受け取って、臨時のPoCグループセッションのために制御PoCサーバの役割を引き受けて、URIリストのそれぞれのURIにINVITE要求を送ります。
Hautakorpi & Camarillo Informational [Page 4] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[4ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
+-------------+
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|
+------------+
+-------------+ 2. 招待| Particip。 | +------------------>| PoCサーバ|、-、>、| alice@example.com | example.com| | +-------------+ | +-------------+ 3. +を招待してください。-------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 1. 招待| 制御します。| friends@example.org | Particip。 | ---------------->| PoCサーバ| | PoCサーバ|-> alice@example.com | | 4. 禁じられた403| example.org| friends@example.org | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +-------------+ bob@example.org +-------------+ | | carol@example.net ^| | | | | 5. 招待| | +--------------------------------+ | bob@example.org | | +------------+ | 6. 招待| Particip。 | +------------------>| PoCサーバ|-> 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リストの第2URI( friends@example.org )はURIリストを特定します。 PoC用語で、 friends@example.com は根回しされたPoCグループを特定します。 そのPoCサーバが確立される臨時のPoCグループセッションのための制御PoCサーバとして機能しないので、example.orgのPoCサーバは friends@example.org のメンバーへの要求をINVITEに送ることができません。(example.orgは friends@example.com の会員資格を知っています)。 代わりに、それは、 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の部分的なリストです。 その上、参加しているPoCサーバが返すURIはURIリストであるかもしれません。
Hautakorpi & Camarillo Informational [Page 5] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[5ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
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がリストとそのリストのメンバーを特定して、リストに含まれたURIを示すためにメカニズムがないことを制御PoCサーバに知らせるように、メカニズムはありません。 このドキュメントはそのようなメカニズムを定義します: P拒否されたURIリストP-ヘッダー。
4. Overview of Operation
4. 操作の概要
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に示されるように。 URIリストがPによって拒否されたP-ヘッダーは要求の拒絶を引き起こしたURIリストかリストのメンバーを含みます。 このように、クライアントは直接それらのメンバーURIに要求を送ることができます。
+---------+ INVITE request +----------+
| |------------------------------>| |
| | [URI list in a URI list] | URI-list |
| Client | | server |
| | 403 Forbidden | |
| |<------------------------------| |
| | [Content of refused URI list] | |
+---------+ +----------+
+---------+ INVITE要求+----------+ | |------------------------------>| | | | [URIリストのURIリスト]| URIリスト| | クライアント| | サーバ| | | 禁じられた403| | | |<------------------------------| | | | [拒否されたURIリストの中身]| | +---------+ +----------+
Figure 3: Operational Overview
図3: 操作上の概要
5. Syntax of P-Refused-URI-List Header Field
5. P拒否されたURIリストヘッダーフィールドの構文
The following is the augmented Backus-Naur Form (BNF) [4] syntax of the P-Refused-URI-List P-Header:
↓これはP拒否されたURIリストP-ヘッダーの増大しているBN記法(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
P拒否されたURIリスト=「P拒否されたURIリスト」HCOLON uriリストエントリー*(COMMA uriリストエントリー)uriリストエントリー=(名前addr / addr仕様)*(SEMIの拒否されたparam)拒否されたparamはジェネリック-paramメンバー-param=メンバー-param/「メンバー」EQUAL LDQUOT*(引用されたqdtext/組の)RDQUOTと等しいです。
The members P-Header parameter MUST contain a cid-url, which is defined in RFC 2392 [2].
メンバーP-ヘッダーパラメタはCid-urlを含まなければなりません。(urlはRFC2392[2]で定義されます)。
The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are defined in [3].
HCOLON、SEMI、EQUAL、LDQUOT、RDQUOT、およびジェネリック-paramは[3]で定義されます。
Hautakorpi & Camarillo Informational [Page 6] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[6ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
6. Response Generation
6. 応答世代
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(禁じられる)応答は1つ以上のPで拒否されたURIのリストのエントリーを含むことができます。 いかなる他の応答と共にもP拒否されたURIリストヘッダーフィールドを使用してはいけません。 (URIは入って来る要求におけるURIリストに存在していました)。P拒否されたURIリストP-ヘッダーは、1つ以上の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拒否されたURIリストエントリーでそれらの身体の部分に参照をつけることができます。 P拒否された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がどのURIリストに関連するかを決心しているのを可能にします、URIリストサーバが、その情報を明らかにしても構わないと思っているなら。 その上、URIリストに入れられた情報は、クライアントが拒絶事態を改善するためにさらなる行動を取るのを可能にします(例えば、URIリストのメンバーに個々の要求を送ってください)。
7. Message Sequence Example
7. メッセージ系列の例
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応答には、メッセージ欄で参加しているPoCサーバがこの制御PoCサーバに明らかにすることを決定する拒絶されたURIリストのメンバーを運ぶP拒否されたURIリストP-ヘッダーがあります。
Controlling PoC server Participating PoC server
example.com example.net
PoCサーバParticipating PoCサーバexample.com example.netを制御します。
| |
| INVITE |
|-------------------------------->|
| |
| 403 Forbidden |
|<--------------------------------|
| |
| | | 招待| |-------------------------------->| | | | 禁じられた403| |<--------------------------------| | |
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要求は以下の通りです(ヘッダーを通して、分野は簡単さのために示されません):
Hautakorpi & Camarillo Informational [Page 7] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[7ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
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
INVITE一口: 前方へ poc-service@example.net SIP/2.0マックス: 70 From: PoCが<一口: poc-service@example.com を調整する、gt;、;=4fxaed73sl To:にタグ付けをしてください PoCが<一口: poc-service@example.net を調整する、gt;、呼び出しID: 7xTn9vxNit65XU7p4@example.com CSeq: 1 接触を招いてください: <一口: poc-service@poc-as.example.com 、gt;、必要です: リストが招待する受取人コンテントタイプ: 複合か混ぜられる;、境界=、「boundary1" Content-長さ:」 538
--boundary1
Content-Type: application/sdp
--boundary1コンテントタイプ: アプリケーション/sdp
(SDP not shown)
(見せられなかったSDP)
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
--boundary1コンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リスト
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ> <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].
URI一口: 一口: 上記の例の friends-list@example.net と同僚リスト@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;
一口/2.0 403の禁制のFrom: PoCが<一口: poc-service@example.com を調整する、gt;、;=4fxaed73sl To:にタグ付けをしてください PoCが<一口: poc-service@example.net を調整する、gt;、; タグは814254Call-IDと等しいです: 7xTn9vxNit65XU7p4@example.com CSeq: 1 URIリストが拒否されたPを招待してください: 一口: friends-list@example.net; メンバーが<Cid: an3bt8jf03@example.net と等しい、gt;、PはURIリストを拒否しました: 一口: colleagues-list@example.net;
Hautakorpi & Camarillo Informational [Page 8] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[8ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
members=<cid:bn35n8jf04@example.net>
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 745
メンバーが<Cid: bn35n8jf04@example.net と等しい、gt;、コンテントタイプ: 複合か混ぜられる;、境界=、「boundary1" Content-長さ:」 745
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-ID: <an3bt8jf03@example.net>
--boundary1コンテントタイプ: アプリケーション/リソースリスト+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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsが「つぼ:ietf:params: xml:ナノ秒:リソースリスト「><リスト><エントリーuri=」一口: bill@example.org 」/と等しい、gt;、<エントリーuriが「一口: randy@example.com 」/と等しい、gt;、<エントリーuriが「一口: eddy@example.com 」/と等しい、gt;、</リスト></リソースリスト>。
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-ID: <bn35n8jf04@example.net>
--boundary1コンテントタイプ: アプリケーション/リソースリスト+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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsが「つぼ:ietf:params: xml:ナノ秒:リソースリスト「><リスト><エントリーuri=」一口: joe@example.org 」/と等しい、gt;、<エントリーuriが「一口: carol@example.com 」/と等しい、gt;、</リスト></リソースリスト>--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サーバは一口のメンバー: friend-list@example.net と一口: 参加しているPoCサーバがこの制御PoCサーバに明らかにすることを決定する同僚リスト@example.netを決定できます。その上、制御PoCサーバは、参加しているPoCサーバがどんな送信する要求も送らないと推論できます、通常のURIリストサーバ手順単位で。
8. Applicability
8. 適用性
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.
OMA PoCネットワークにP拒否されたURIリストヘッダーフィールドが使用されることを意図します。 このヘッダーフィールドは、要求を受け取りながら、PoCサーバの間で使用されて、サーバによって拒絶されたそれらのURIリストに関して情報を運びます。
Hautakorpi & Camarillo Informational [Page 9] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[9ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
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リストを決議して、これらのリストのメンバーにINVITEsを送ることができるように、設計されています。 この制限は公共のインターネットで使用されるために開発されたサービスのときに存在していません。 したがって、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リストは要求の拒否に関する追加情報をクライアントに提供するだけです。
9. Security Considerations
9. セキュリティ問題
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-ヘッダーを扱うネットワーク要素が信じられると思われます。 また、攻撃者はそれらの要素の間のプロトコルメッセージに近づく手段を持つべきではありません。 これはOMA PoC環境でP拒否されたURIリストが使用されるつもりであるからです環境はオペレータのコアネットワークで実装されます。 OMA PoCセキュリティ前提での以上に関しては、[9]を見てください。 ネットワーク要素の間のトラフィック保護は、IP Security(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(禁じられる)の応答が暗号化されていないなら、立ち聞きする者はこの情報を取得できます。 したがって、ホップで跳ぶのが、RECOMMENDEDであるか終端間暗号化(例えば、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リストの中身を認可されたクライアントだけに明らかにするのは、RECOMMENDEDです。
Hautakorpi & Camarillo Informational [Page 10] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[10ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
10. IANA Considerations
10. IANA問題
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は2つの追加をSession Initiationプロトコル(SIP)パラメタ登録にしました。 以下のヘッダーフィールドはHeaderフィールズサブ登録に加えられます。
Header Name compact Reference
----------------- ------- ---------
P-Refused-URI-List [RFC5318]
ヘッダーのNameのコンパクトなReference----------------- ------- --------- P拒否されたURIリスト[RFC5318]
The following header field parameter has been added to the Header Field Parameters and Parameter Values sub-registry.
以下のヘッダーフィールドパラメタはHeader Field ParametersとParameter Valuesサブ登録に加えられます。
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
P-Refused-URI-List members No [RFC5318]
事前に定義されたヘッダーフィールドパラメタ名は参照を評価します。---------------------------- --------------- --------- --------- P拒否されたURIリストメンバーノー[RFC5318]
11. Acknowledgements
11. 承認
Authors would like to thank Tom Hiller who did a thorough, dedicated review for this document.
作者はこのドキュメントのために徹底的で、ひたむきなレビューをしたトム・ヒラーに感謝したがっています。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[2] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2392、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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"、STD68、RFC5234、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] キャマリロ、G.、およびA.ローチ、「セッション開始のためのフレームワークとセキュリティ問題は(一口)URIリストサービスについて議定書の中で述べます」、RFC5363、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] キャマリロ、G.、およびA.ジョンストン、「セッション開始に要求で含まれたリストを使用するコンファレンス設立が(一口)について議定書の中で述べます」、RFC5366、2008年10月。
Hautakorpi & Camarillo Informational [Page 11] RFC 5318 The P-Refused-URI-List P-Header December 2008
Hautakorpiとキャマリロの情報[11ページ]のRFC5318P拒否されたURIリストP-ヘッダー2008年12月
12.2. Informative References
12.2. 有益な参照
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", RFC 4826, May 2007.
[7] ローゼンバーグ、J.、「リソースリストを表すための拡張マークアップ言語(XML)形式」(RFC4826)は2007がそうするかもしれません。
[8] Open Mobile Alliance, "OMA PoC System Description: Draft Version
2.0", April 2007.
[8] モバイル同盟を開いてください、「OMA PoCシステム記述:」 2インチと、2007年4月にバージョンを作成してください。
[9] Open Mobile Alliance, "Push to talk over Cellular (PoC) -
Architecture: Draft Version 2.0", April 2007.
[9] モバイルAllianceを開いてください、「Cellular(PoC)の上で押して話してください--、アーキテクチャ:、」 2インチと、2007年4月にバージョンを作成してください。
Authors' Addresses
作者のアドレス
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
ヤニHautakorpiエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
メール: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Hautakorpi & Camarillo Informational [Page 12]
Hautakorpiとキャマリロ情報です。[12ページ]
一覧
スポンサーリンク
