Network Working Group G. Camarillo
Request for Comments: 5368 Ericsson
Category: Standards Track A. Niemi
M. Isomaki
Nokia
M. Garcia-Martin
Ericsson
H. Khartabil
Ericsson Australia
October 2008
Referring to Multiple Resources in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）で複数のリソースを参照します
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag.
この文書は、単一の要求で複数のリソースを参照するために使用することができるように、SIPの拡張メソッドを定義REFER。これらの拡張は、参照のために、ヘッダフィールド内のURI（Uniform Resource Identifier）のリストへのポインタを使用すると、「複数参照」SIPオプションタグを含みます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4
5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4
6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5
7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 6
8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 6
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with a REFER method that allows a user agent (UA) to request a second UA to send a SIP request to a third party. For example, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP UA to send a REFER request to Bob's UA providing Carol's SIP Contact information. Assuming Bob has given it permission, Bob's UA will attempt to call Carol using that contact. That is, it will send an INVITE request to that contact.
RFC 3261（SIP）[RFC3261]はユーザエージェント（UA）が第三者にSIPリクエストを送信するために第2のUAに要求することを可能にするREFERメソッドとRFC 3515 [RFC3515]によって拡張されます。アリスはボブと通話中で、ボブはキャロルに話をする必要が決定した場合たとえば、アリスはボブのUAは、キャロルのSIP連絡先情報を提供することにREFERリクエストを送信するために彼女のSIP UAに指示することができます。ボブはそれを許可を与えていると仮定すると、ボブのUAは、その連絡先を使用してキャロルを呼び出そうとします。つまり、その連絡先にINVITEリクエストを送信します、です。
A number of applications need to request this second UA to initiate transactions towards a set of destinations. In one example, the moderator of a conference may want the conference server to send BYE requests to a group of participants. In another example, the same moderator may want the conference server to INVITE a set of new participants.
アプリケーションの数は、目的地の集合に向けて取引を開始するためにこの第二のUAを要求する必要があります。一例では、会議の議長は、会議サーバは、参加者のグループにBYE要求を送信することもできます。別の例では、同じモデレータは、会議サーバは、新たな参加者の集合を招待したいことがあります。
We define an extension to the REFER method so that REFER requests can be used to refer other user agents (such as conference servers) to multiple destinations. In addition, this mechanism uses the suppression of the REFER method implicit subscription specified in RFC 4488 [RFC4488].
そのREFERリクエストが複数の宛先に（例えば会議サーバなど）他のユーザーエージェントを参照するために使用することができるように、我々はREFERメソッドに拡張子を定義します。また、この機構は、RFC 4488 [RFC4488]で指定されたREFERメソッド暗黙的加入の抑制を使用します。
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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載され、対応する実装の要求レベルを示すものと解釈されます。
This document reuses the following terminology defined in RFC 3261 [RFC3261]:
この文書は、RFC 3261 [RFC3261]で定義された以下の用語を再利用します。
o User Agent (UA) o User Agent Client (UAC) o User Agent Server (UAS)
ユーザエージェントサーバ（UAS）Oユーザエージェントクライアント（UAC）〇〇ユーザーエージェント（UA）
This document defines the following new terms:
このドキュメントでは、次の新しい用語を定義しています。
REFER-Issuer: a user agent issuing a REFER request.
REFER発行者：REFER要求を発行するユーザーエージェント。
REFER-Recipient: an entity receiving a REFER request and forwarding a SIP request to a number of REFER-Targets. The REFER-Recipient is typically a network entity, such as a URI-list server, that acts as a UAS for REFER requests and as a UAC for other SIP requests.
REFER受信者：エンティティがREFER要求を受信し、REFER-ターゲットの数にSIPリクエストを転送します。 REFER受信者は、そのような要求を参照してくださいUASとして、および他のSIP要求のUACとして動作するURIリストサーバとして、典型的にはネットワーク・エンティティです。
REFER-Target: a UA of the intended final recipient of a SIP request generated by the REFER-Recipient.
- ターゲットREFER：REFER受信者によって生成されたSIPリクエストの意図された最終的な受信者のUA。
This document describes an application of URI-list services [RFC5363] that allows a URI-list service to receive a SIP REFER request containing a list of targets. The URI-list service invokes the requested SIP method to each of the targets contained in the list. This type of URI-list service is referred to as a REFER-Recipient throughout this document.
この文書では、ターゲットのリストを含むSIP REFER要求を受信するためのURIリストサービスを可能にするURIリストサービスの適用[RFC5363]を説明しています。 URIリストサービスがリストに含まれているターゲットのそれぞれに要求されたSIPメソッドを呼び出します。 URIリストサービスのこのタイプは、この文書全体REFER-受信者と呼ばれています。
This document defines an extension to the SIP REFER method specified in RFC 3515 [RFC3515] that allows a SIP UAC to include a URI list as specified in RFC 4826 [RFC4826] of REFER-Targets in a REFER request and send it to a REFER-Recipient. The REFER-Recipient creates a new SIP request for each entry in the URI list and sends it to each REFER-Recipient.
この文書は、SIPへの拡張は、SIP UACは、REFER要求でREFER-標的のRFC 4826 [RFC4826]で指定されたURIのリストを含み、REFER-に送信することを可能にするRFC 3515 [RFC3515]で指定されたメソッド参照定義します受信者。 REFER-受信者は、URIリスト内の各エントリのための新しいSIPリクエストを作成し、各REFER-受信者に送信します。
The URI list that contains the list of targets is used in conjunction with RFC 5364 [RFC5364] to allow the sender indicate the role (e.g., 'to', 'cc', or anonymous) in which the REFER-Target is involved in the signalling.
ターゲットのリストが含まれているURIリストは、送信者が役割を示す許可するRFC 5364 [RFC5364]と組み合わせて使用されている（例えば、「CC」、または匿名「から」）REFER-Targetはに関与していますシグナリング。
We represent multiple targets of a REFER request using a URI list as specified in RFC 4826 [RFC4826]. A REFER-Issuer that wants to refer a REFER-Recipient to a set of destinations creates a SIP REFER request. The Refer-To header contains a pointer to a URI list, which is included in a body part, and an option-tag in the Require header field: "multiple-refer". This option-tag indicates the requirement to support the functionality described in this specification.
我々は、RFC 4826 [RFC4826]で指定されたURIのリストを使用して、REFERリクエストの複数の標的を表します。目的地のセットを参照-受信者を参照したいREFER発行者は、SIP REFER要求を作成します。参照のために、ヘッダボディ部に含まれるURIリストへのポインタ、およびRequireヘッダーフィールドのオプションタグを含む：「複数参照」。このオプションタグは、この仕様書で説明した機能をサポートするための要件を示します。
When the REFER-Recipient receives such a request, it creates a new request per REFER-Target and sends them, one to each REFER-Target.
REFER-受信者がそのような要求を受信すると、それは、それぞれのREFER-ターゲットに1をREFER-ターゲットごとに新しい要求を作成し、それらを送信します。
This document does not provide any mechanism for REFER-Issuers to find out about the results of a REFER request containing multiple REFER-Targets. Furthermore, it does not provide support for the implicit subscription mechanism that is part of the SIP REFER method. The way REFER-Issuers are kept informed about the results of a REFER is service specific. For example, a REFER-Issuer sending a REFER request to invite a set of participants to a conference can discover which participants were successfully brought into the conference by subscribing to the conference state event package specified in RFC 4575 [RFC4575].
この文書では、複数のREFER - 目標を含むREFERリクエストの結果を知るためにREFER-発行者のための任意のメカニズムを提供しません。さらに、それは方法を、SIP REFERの一部であり、暗黙的なサブスクリプション・メカニズムをサポートしていません。 REFER - 発行者はREFERの結果に関する情報に保たれている方法は、サービス固有のものです。例えば、REFER発行者は、参加者が正常にRFC 4575 [RFC4575]で指定された会議状態イベントパッケージに加入することにより、会議に持ち込まれた発見することができます会議に参加者の集合を招待するREFER要求を送信します。
We define a new SIP option-tag for the Require and Supported header fields: "multiple-refer".
私たちは、必要とSupportedヘッダーフィールドのための新しいSIPオプションタグを定義：「マルチ参照してください」。
A user agent including the "multiple-refer" option-tag in a Supported header field indicates compliance with this specification.
Supportedヘッダーフィールドに「複数参照」オプションタグを含むユーザエージェントは、この仕様に適合することを示します。
A user agent generating a REFER with a pointer to a URI list in its Refer-To header field MUST include the "multiple-refer" option-tag in the Require header field of the REFER.
その参照の-にフィールドをヘッダにURIリストへのポインタでREFER生成するユーザエージェントは、REFERのRequireヘッダーフィールドに「複数参照」オプションタグを含まなければなりません。
REFER requests with a single REFER-Target establish implicitly a subscription to the refer event. The REFER-Issuer is informed about the result of the transaction towards the REFER-Target through this implicit subscription. As described in RFC 3515 [RFC3515], NOTIFY requests sent as a result of an implicit subscription created by a REFER request contain a body of type "message/sipfrag", RFC 3420 [RFC3420], that describes the status of the transaction initiated by the REFER-Recipient.
シングルREFER-ターゲットとREFER要求指すイベントに暗黙的にサブスクリプションを確立します。 REFER発行者は、この暗黙の契約でREFER-ターゲットに向けた取引の結果について通知されます。 RFC 3515に記載されているように[RFC3515]、REFER要求によって作成された暗黙的加入の結果として送信されるNOTIFYリクエストをすることによって開始したトランザクションの状態を記述する「メッセージ/ sipfrag」タイプのボディを含む、RFC 3420 [RFC3420]、 REFER-受信者を。
In the case of a REFER-Issuer that generates a REFER with multiple REFER-targets, the REFER-Issuer is typically already subscribed to other event packages that can provide the information about the result of the transactions towards the REFER-Targets. For example, a moderator instructing a conference server to send a BYE request to a set of participants is usually subscribed to the conference state event package for the conference. Notifications to this event package will keep the moderator and the rest of the subscribers informed of the current list of conference participants.
複数のREFER-標的とREFER生成REFER-発行者の場合には、REFER-発行者は、典型的には、既にREFER-ターゲットに向かってトランザクションの結果に関する情報を提供することができる他のイベントパッケージに加入されています。例えば、参加者の集合にBYE要求を送信するために会議サーバに指示モデレータは、通常、会議のための会議状態イベントパッケージに加入されます。このイベントパッケージへの通知は、モデレータと会議参加者の現在のリストが通知加入者の残りの部分を維持します。
Most of the applications using the multiple REFER technology described in this memo do not need its implicit subscription. Consequently, a SIP REFER-Issuer generating a REFER request with multiple REFER-Targets SHOULD include the "norefersub" option-tag in a Require header field and SHOULD include a Refer-Sub header field set to "false" to indicate that no notifications about the requests should be sent to the REFER-Issuer. The REFER-Recipient SHOULD honor the suggestion and also include a Refer-Sub header field set to "false" in the 200 (OK) response. The "norefersub" SIP option-tag and the Refer-Sub header field are specified in RFC 4488 [RFC4488].
このメモで説明した複数のREFERの技術を使用してアプリケーションのほとんどは、その暗黙のサブスクリプションは必要ありません。したがって、SIP REFER-発行必要なヘッダフィールドに「norefersub」オプションタグを含むべき複数のREFER-標的とREFERリクエストを生成し、「偽」NO通知に関することを示すために設定参照のサブヘッダフィールドを含むべきです要求は、REFER発行者に送信する必要があります。 REFER受信者は、提案を尊重し、また200（OK）応答に「偽」に設定参照のサブヘッダフィールドを含むべきです。 「norefersub」SIPオプションタグと参照のサブヘッダフィールドは、RFC 4488 [RFC4488]で指定されています。
RFC 4488 [RFC4488] indicates that a condition for the REFER-Issuer to include a Refer-Sub header is that the REFER-Issuer is sure that the REFER request will not fork.
RFC 4488 [RFC4488]はREFER-発行するための条件が参照サブヘッダを含めるようにすることを示しREFER-発行者はREFER要求はフォークではないと確信していることです。
At the time of writing, there is no extension that allows to report the status of several transactions over the implicit subscription associated with a REFER dialog. That is the motivation for this document to recommend the usage of the "norefersub" option-tag. If in the future such an extension is defined, REFER-Issuers using it could refrain from using the "norefersub" option-tag and use the new extension instead.
執筆時点では、REFERダイアログに関連付けられた暗黙のサブスクリプションを介して複数のトランザクションの状態を報告することができます拡張子はありません。それは「norefersub」オプションタグの使用をお勧めするには、この文書の動機です。今後、このような拡張が定義されている場合は、-REFER発行者にそれを使用しては、「norefersub」オプションタグの使用を控える、代わりに新しい拡張機能を使用することができます。
As described in RFC 5363 [RFC5363], specifications of individual URI-list services need to specify a default format for 'recipient-list' bodies used within the particular service.
RFC 5363 [RFC5363]で説明したように、個々のURIリストサービスの仕様は、特定のサービス内で使用される「受信者リストの体のデフォルトの形式を指定する必要があります。
The default format for 'recipient-list' bodies for REFER-Issuers and REFER-Recipients is RFC 4826 [RFC4826] extended with RFC 5364 [RFC5364]. REFER-Recipients handling 'recipient-list' bodies MUST support both of these formats. Both REFER-Issuers and REFER-Recipients MAY support other formats.
REFER-発行者のための「受信者リストの体のデフォルトの形式と、受信者のREFER RFC 5364 [RFC5364]で拡張RFC 4826 [RFC4826]です。 「受信者リストの体を扱うREFER-受信者は、これらのフォーマットの両方をサポートしなければなりません。どちらのREFER-発行体やREFER-受信者は、他のフォーマットをサポートするかもしれません。
As described in RFC 5364 [RFC5364], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the target will get the referred SIP request. However, depending on the target SIP method, a 'copyControl' attribute lacks sense. For example, while a 'copyControl' attribute can be applied to INVITE requests, it does not make sense with mid-dialog requests such as BYE requests.
RFC 5364に[RFC5364]を説明したように、各URIは、ターゲットが呼ばれるSIPリクエストを取得するする役割を示し、「に」、「CC」のいずれかに設定「コピーコントロールCD」属性、又は「BCC」でタグ付けすることができます。しかし、ターゲットSIP方法に応じて、「コピーコントロールCD」属性は、感覚を欠いています。 「コピーコントロールCD」属性は、INVITE要求に適用することができるが、例えば、そのようなBYE要求など、ダイアログ中のリクエストと意味がありません。
In addition to the 'copyControl' attribute, URIs can be tagged with the 'anonymize' attribute (also specified in RFC 5364 [RFC5364]) to prevent that the REFER-Recipient discloses the target URI in a URI list.
「コピーコントロールCD」属性に加えて、URIが「匿名」属性でタグ付けすることができる（また、RFC 5364で指定された[RFC5364]）は、REFER受信者はURIリスト内のターゲットURIが記載されていることを防止します。
Additionally, RFC 5364 [RFC5364] defines a 'recipient-list-history' body that contains the list of targets. The default format for 'recipient-list-history' bodies for conference services is also RFC 4826 [RFC4826] extended with RFC 5364 [RFC5364]. REFER-Recipients supporting this specification MUST support both of these formats; REFER-Targets MAY support these formats. Both REFER-Recipients and REFER-Targets MAY support other formats.
また、RFC 5364 [RFC5364]はターゲットのリストが含まれている「受信者リスト履歴の体を定義します。会議サービスのための「受信者リスト履歴の体のデフォルトフォーマットは、RFC 4826 [RFC4826] RFC 5364 [RFC5364]で拡張です。この仕様をサポートするREFER-受信者は、これらのフォーマットの両方をサポートしなければなりません。 REFER-ターゲットは、これらのフォーマットをサポートするかもしれません。どちらも、受信者を参照し、REFER-目標は、他のフォーマットをサポートするかもしれません。
Nevertheless, RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XML Configuration Access Protocol (XCAP) root URI, that are not needed by the multiple REFER service defined in this document.
それにもかかわらず、RFC 4826 [RFC4826]は、このような本文書で定義された複数のREFERサービスによって必要とされない階層リストとXML構成アクセスプロトコル（XCAP）ルートURIに対する基準によってエントリを含む能力、などの機能を提供します。
Figure 1 shows an example of a flat list that follows the resource list document.
図1は、リソースリスト文書を以下のフラットリストの一例を示しています。
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CP = "壷：IETF：のparams：XML ：NS：コピーコントロールCD ">
<list> <entry uri="sip:bill@example.com" cp:copyControl="to" /> <entry uri="sip:joe@example.org" cp:copyControl="cc" /> <entry uri="sip:ted@example.net" cp:copyControl="bcc" /> </list> </resource-lists>
<リスト> <エントリURI = "SIP：bill@example.com" CP：コピーコントロールCD = "へ" /> <エントリURI = "SIP：joe@example.org" CP：コピーコントロールCD = "CC" /> <エントリーのURI = "SIP：ted@example.net" CP：コピーコントロールCD = "BCC" /> </リスト> </資源リスト>
Figure 1: URI list
図1：URIリスト
As indicated in Sections 4 and 5, a SIP REFER-Issuer that creates a REFER request with multiple REFER-Targets includes a "multiple-refer" and "norefersub" option-tags in the Require header field and, if appropriate, a Refer-Sub header field set to "false". The REFER-Issuer includes the set of REFER-Targets in a recipient-list body whose disposition type is 'recipient-list', as defined in RFC 5363 [RFC5363]. The URI-list body is further described in Section 6.
セクション4および5に示されるように、複数のREFER-ターゲットとREFER要求を作成するSIP REFER-発行者「は、参照複数」及び「norefersub」オプションタグRequireヘッダーフィールドであり、適切な場合、Refer-を含みます「偽」に設定されたサブヘッダフィールド。 REFER-発行者は配置タイプRFC 5363 [RFC5363]で定義されるように、「受信者リスト」である受信者リスト本体内REFER-ターゲットのセットを含みます。 URIリスト本体はさらに第6節に記載されています。
The Refer-To header field of a REFER request with multiple REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part that carries the URI list. The REFER-Issuer SHOULD NOT include any particular URI more than once in the URI list.
複数のREFER-標的とREFER要求の参照のために、ヘッダーフィールドは、ポインタを含まなければならない（すなわち、RFC 2392 [RFC2392]の通りのContent-IDのURL（Uniform Resource Locator））URIを搬送する本体部分を指しリスト。 REFER発行者は複数回URIのリストの中よりも、特定のURIを含めるべきではありません。
RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple REFER service defined in this document. Therefore, when using the default resource list document, SIP REFER-Issuers generating REFER requests with multiple REFER-Targets SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
RFC 4826 [RFC4826]はこのような階層リストなどの機能、及びXCAPルートURIに対する基準によってエントリを含めるする能力を提供します。しかし、これらの機能は、この文書で定義された複数のREFERサービスで必要とされていません。デフォルト・リソース・リスト・ドキュメントを使用する場合したがって、SIP REFER - 発行者の発生は、複数のREFER-ターゲットがフラットリスト（すなわち、無階層リスト）を使用する必要があり、<エントリ-REF>要素を使用すべきではないとの要求を参照して下さい。
The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 [RFC3515] to determine the status code of the response to the REFER.
REFER受信者が参照するために、応答のステータスコードを決定するために、RFC 3515 [RFC3515]のセクション2.4.2の規則に従います。
The REFER-Recipient SHOULD not create an implicit subscription, and SHOULD add a Refer-Sub header field set to "false" in the 200 OK response.
REFER-受信者は、暗黙的なサブスクリプションを作成しないでください、と200 OK応答では「偽」を参照してくださいサブヘッダフィールドのセットを追加する必要があります。
The incoming REFER request typically contains a URI-list document or reference with the actual list of targets. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", and if the request is appropriate for the service, e.g., it is not received mid-dialog, the REFER-Recipient SHOULD include a URI list in each of the outgoing requests. This list SHOULD be formatted according to RFC 4826 [RFC4826] and RFC 5364 [RFC5364]. The REFER-Recipient MUST follow the procedures specified in RFC 4826 [RFC4826] with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes.
着信REFER要求は、典型的には、ターゲットの実際のリストをURIリスト文書または参照を含んでいます。このURIのリストは、「へ」または「CC」の値に設定する「コピーコントロールCD」属性でタグ付けされたリソースを含み、その要求は例えば、サービスに適しているならば、それは半ばダイアログを受けていない、REFER、受信者の場合発信要求のそれぞれにおけるURIのリストを含むべきです。このリストは、RFC 4826 [RFC4826]及びRFC 5364 [RFC5364]に従ってフォーマットされるべきです。 REFER-受領者は「匿名」、「回数」の処理に関してRFC 4826 [RFC4826]で指定された手順、および「コピーコントロールCDの属性に従わなければなりません。
Section 4 of RFC 5363 [RFC5363] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, REFER-Recipients MUST take those actions specified in RFC 5363 [RFC5363] into account to avoid sending a duplicated request to the same target.
複製のURIがURIリストに見つかった場合、RFC 5363 [RFC5363]のセクション4は、ケースを説明します。重複した要求を避けるために、REFER-受信者は、同じターゲットに複製された要求を送信することを避けるために、アカウントにRFC 5363 [RFC5363]で指定されたこれらのアクションを取る必要があります。
If the REFER-Recipient includes a URI list in an outgoing request, it MUST include a Content-Disposition header field, specified in RFC 2183 [RFC2183], with the value set to 'recipient-list-history' and a 'handling' parameter, specified in RFC 3204 [RFC3204], set to "optional".
REFER受信者が発信要求にURIのリストが含まれている場合、それは、受信者リスト履歴」および「処理」パラメータの設定値と、RFC 2183に[RFC2183]を指定し、コンテンツの廃棄ヘッダーフィールドを含まなければなりません、RFC 3204 [RFC3204]で指定され、 "オプション" に設定されます。
Since the multiple REFER service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a REFER-Recipient receiving a URI list with more information than what has been described in Section 6 MAY discard all the extra information.
複数のREFERサービスはXCAPルートURIを参照することにより、エントリが含まれる階層リストやリストを使用していないので、第6節に記載されているものよりもより多くの情報をURIのリストを受信するREFER-受信者は、すべての余分な情報を捨てるかもしれ。
The REFER-Recipient follows the rules in RFC 3515 [RFC3515] to generate the necessary requests towards the REFER-Targets, acting as if it had received a regular (no URI list) REFER per each URI in the URI list.
REFER-受信者は、通常の（ないURIのリスト）を受けていなかったかのように機能し、REFER-ターゲットに向けた必要な要求を生成URIリスト内の各URIごとに参照するためにRFC 3515 [RFC3515]の規則に従います。
Figure 2 shows an example flow where a REFER-Issuer sends a multiple-REFER request to the focus of a conference, which acts as the REFER-Recipient. The REFER-Recipient generates a BYE request per REFER-Target. Details for using REFER request to remove participants from a conference are specified in RFC 4579 [RFC4579].
図2は、REFER-発行者は、REFER受信者として働く会議の焦点に複数-REFER要求を送信する一例の流れを示します。 REFER-受信者は、REFER-ターゲットごとにBYE要求を生成します。会議から参加者を削除するREFERリクエストを使用するための詳細については、RFC 4579 [RFC4579]で指定されています。
+--------+ +---------+ +--------+ +--------+ +--------+
| REFER | | REFER | | REFER | | REFER | | REFER |
| issuer | |recipient| |target 1| |target 2| |target 3|
| | | | | | | | | |
| Carol | | (focus) | | Bill | | Joe | | Ted |
+--------+ +---------+ +--------+ +--------+ +--------+
| 1. REFER | | | |
| ---------------->| | | |
| 2. 202 Accepted | | | |
|<---------------- | 3. BYE | | |
| | ----------->| | |
| | 4. BYE | | |
| | ----------------------->| |
| | 5. BYE | | |
| | ----------------------------------->|
| | 6. 200 OK | | |
| |<----------- | | |
| | 7. 200 OK | | |
| |<----------------------- | |
| | 8. 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 2: Example flow of a REFER request containing
multiple REFER-Targets
The REFER request (1) contains a Refer-To header field that includes a pointer to the message body, which carries a list with the URIs of the REFER-Targets. In this example, the URI list does not contain the 'copyControl' attribute extension. The REFER's Require header field carries the "multiple-refer" and "norefersub" option-tags. The Request-URI is set to a Globally Routable User Agent URI (GRUU) [SIP-GRUU] (as a guarantee that the REFER request will not fork). The Refer-Sub header field is set to "false" to request the suppression of the implicit subscription. Figure 3 shows an example of this REFER request. The resource list document contains the list of REFER-Target URIs along with the method of the SIP request that the REFER-Recipient generates.
REFER要求（1）を参照して下さい - を参照して、ターゲットのURIにリストを運ぶメッセージ本文へのポインタを含むフィールドヘッダが含まれています。この例では、URIのリストは、「コピーコントロールCD」属性の拡張機能が含まれていません。 REFERのは、ヘッダフィールドを要求する「を参照してください - 複数の」および「norefersub」オプションタグを運びます。リクエストURIは、グローバルにルーティング可能なユーザエージェントURI（GRUU）[SIP-GRUU（REFER要求フォークないことを保証するような）に設定されています。参照のサブヘッダフィールドは、暗黙的加入の抑制を要求するために「偽」に設定されています。図3は、このREFERリクエストの例を示しています。リソースリスト文書は、REFER-受信者が生成するSIPリクエストの方法と一緒にREFER-ターゲットURIのリストが含まれています。
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: "Conference 123" <sip:conf-123@example.com> From: Carol <sip:carol@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 2 REFER Contact: <sip:carol@client.chicago.example.com> Refer-To: <cid:cn35t8jf02@example.com> Refer-Sub: false Require: multiple-refer, norefersub Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-Length: 362 Content-ID: <cn35t8jf02@example.com>
SIP REFER：; GRUU; conf-123@example.comを不透明= hha9s8d-999a SIP / 2.0経由：SIP / 2.0 / TCP client.chicago.example.com;ブランチ= z9hG4bKhjhs8ass83マックス・フォワード：70： "123会議" <一口：conf-123@example.com>から：キャロル<SIP：carol@chicago.example.com>;タグ= 32331コールID：d432fa84b4c76e66710ののCSeq：2連絡先を参照してください。<SIP：carol@client.chicago.example .COM>参照してください-た：の<cid：cn35t8jf02@example.com>は、参照してください-SUBを：マルチ参照し、norefersub許可：falseが必要、INVITE ACK、CANCEL、OPTIONS、BYE、REFER、SUBSCRIBE、許可 - イベントをNOTIFY：ダイアログアプリケーション/ SDPを、メッセージ/ sipfragのコンテンツタイプ：受け入れるアプリケーション/リソース・リスト+ XMLコンテンツ-処分：受信者リストのContent-Length：362のContent-ID：<cn35t8jf02@example.com>
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <list> <entry uri="sip:bill@example.com?method=BYE" /> <entry uri="sip:joe@example.org?method=BYE" /> <entry uri="sip:ted@example.net?method=BYE" /> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス "> <リスト> <エントリーのURI =" SIP：？bill@example.com方法= BYE」/> <エントリーのURI = "SIP：？joe@example.org方法= BYE" / > <エントリURI = "SIP：？ted@example.net方法= BYE" /> </リスト> </資源リスト>
Figure 3: REFER request with multiple REFER-Targets
図3：複数のREFER-標的とREFER要求
Figure 4 shows an example of the BYE request (3) that the REFER-Recipient sends to the first REFER-Target.
図4は、REFER受信者が最初のREFER-ターゲットに送信するBYEリクエスト（3）の一例を示しています。
BYE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP conference.example.com ;branch=z9hG4bKhjhs8assmm Max-Forwards: 70 From: "Conference 123" <sip:conf-123@example.com>;tag=88734 To: <sip:bill@example.com>;tag=29872 Call-ID: d432fa84b4c34098s812 CSeq: 34 BYE Content-Length: 0
BYEのSIP：bill@example.com SIP / 2.0経由：SIP / 2.0 / TCP conference.example.com;ブランチ= z9hG4bKhjhs8assmmマックス・フォワード：70から： "123会議" <一口：conf-123@example.com>。タグ= 88734宛先：<SIP：bill@example.com>;タグ= 29872コールID：d432fa84b4c34098s812ののCSeq：34 BYEのコンテンツの長さ：0
Figure 4: BYE request
図4：BYE要求
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Given that a REFER-Recipient accepting REFER requests with multiple REFER-targets acts as a URI-list service, implementations of this type of server MUST follow the security-related rules in RFC 5363 [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
RFC 5363 [RFC5363]はURIリストサービスをSIPに関連する問題について説明します。複数のREFER - 目標にREFER要求受諾REFER-受信者はURIリストサービスとして動作していることを考えると、このタイプのサーバの実装は、RFC 5363 [RFC5363]でセキュリティ関連の規則に従わなければなりません。これらのルールは、オプトインリストと必須の認証とクライアントの承認が含まれています。
Additionally, REFER-Recipients SHOULD only accept REFER requests within the context of an application that the REFER-Recipient understands (e.g., a conferencing application). This implies that REFER-Recipients MUST NOT accept REFER requests for methods they do not understand. The idea behind these two rules is that REFER-Recipients are not used as dumb servers whose only function is to fan-out random messages they do not understand.
また、REFER-受信者のみを参照し、受信者が理解するアプリケーション（例えば、会議アプリケーション）のコンテキスト内で要求を受け入れるべきREFER。これはREFER-受信者は、彼らが理解していないメソッドのREFER要求受け入れてはいけませんことを意味しています。これら二つのルールの背後にある考え方は、REFER-受信者は、その唯一の機能、彼らは理解していないファンアウトランダムメッセージにあるダムのサーバーとして使用されていないです。
This document defines a new SIP option-tag: "multiple-refer". This option-tag has been registered in the SIP Parameters registry.
「複数参照してください」：この文書は、新しいSIPオプションタグを定義します。このオプションタグはSIPパラメータレジストリに登録されています。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
次の行は、SIPパラメータレジストリの「オプションタグ」セクションに追加されました。
+-----------------+-------------------------------------+-----------+
| Name | Description | Reference |
+-----------------+-------------------------------------+-----------+
| multiple-refer | This option tag indicates support | [RFC5368] |
| | for REFER requests that contain a | |
| | resource list document describing | |
| | multiple REFER targets. | |
+-----------------+-------------------------------------+-----------+
Table 1: Registration of the 'multiple-refer' option-tag in SIP
表1：SIPの「マルチ参照してください」オプションタグの登録
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、1997年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204] Zimmerer、E.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.、およびM. Zonoun、 "ISUPとQSIGオブジェクトのMIMEメディアタイプ"、RFC 3204、2001年12月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[RFC3420]スパークス、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[RFC4488]レヴィン、O.、RFC 4488、2006年5月 "セッション開始プロトコル（SIP）の抑制は、メソッドの暗黙の契約をREFER"。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]キャマリロ、G.およびA.B.ローチ、RFC 5363、2008年10月「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項」。
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008.
[RFC5364]ガルシア・マーチン、M.およびG.キャマリロ、「コピー制御を表現するための拡張マークアップ言語（XML）形式拡張子リソースリストに属性」、RFC 5364、2008年10月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]ジョンストン、A.、およびO.レヴィン、 "セッション開始プロトコル（SIP）呼制御 - ユーザエージェントのための会議"、BCP 119、RFC 4579、2006年8月。
[SIP-GRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2007.
[SIP-GRUU]ローゼンバーグ、J.、進歩、2007年10月の作業 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用" を参照してください。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland
安芸ニエミNokiaの私書箱ボックス321 NOKIA GROUP、FIN-00045フィンランド
EMail: Aki.Niemi@nokia.com
メールアドレス：Aki.Niemi@nokia.com
Markus Isomaki Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland
まｒくｓ いそまき のきあ Ｐ。お。 ぼｘ １００ のきあ ＧろうＰ、 ふぃん ０００４５ ふぃんぁんｄ
EMail: markus.isomaki@nokia.com
メールアドレス：markus.isomaki@nokia.com
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
ミゲルA.ガルシア・マーティン・エリクソン経由デロスPoblados 13マドリード28033スペイン
EMail: miguel.a.garcia@ericsson.com
メールアドレス：miguel.a.garcia@ericsson.com
Hisham Khartabil Ericsson Australia
ヒシャムKhartabilエリクソンオーストラリア
EMail: hisham.khartabil@gmail.com
メールアドレス：hisham.khartabil@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。