Network Working Group G. Camarillo
Request for Comments: 5363 Ericsson
Category: Standards Track A.B. Roach
Tekelec
October 2008
Framework and Security Considerations for
Session Initiation Protocol (SIP) URI-List Services
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 describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services.
この文書では、SIP URIリストサービスの必要性を説明し、その呼び出しのための要件を提供します。さらに、それは、これらのサービスに適用されるセキュリティ上の考慮事項を含む、SIP URIリストサービスのためのフレームワークを定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Requirements ....................................................2
3.1. Requirements for URI-List Services Using
Request-Contained Lists ....................................3
3.2. General Requirements for URI-List Services .................3
4. Framework .......................................................3
4.1. Carrying URI Lists in SIP ..................................3
4.2. Processing of URI Lists ....................................4
4.3. Results ....................................................5
5. Security Considerations .........................................5
5.1. List Integrity and Confidentiality .........................5
5.2. Amplification Attacks ......................................5
5.3. General Issues .............................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Some applications require that, at a given moment, a SIP [RFC3261] UA (User Agent) performs a similar transaction with a number of remote UAs. For example, an instant messaging application that needs to send a particular message (e.g., "Hello folks") to n receivers needs to send n MESSAGE requests; one to each receiver.
一部のアプリケーションでは、所与の時点で、SIP [RFC3261] UA（ユーザエージェント）は、リモートユーザーエージェントの数と同様の取引を行うことを必要とします。例えば、N個の受信機に特定のメッセージ（例えば、「こんにちは人々」）を送信する必要があるインスタント・メッセージング・アプリケーションは、n個のMESSAGEリクエストを送信する必要があります。各受信機に1。
When the transaction that needs to be repeated consists of a large request, or when the number of recipients is high, or both, the access network of the UA needs to carry a considerable amount of traffic. Completing all the transactions on a low-bandwidth access would require a long time. This is unacceptable for a number of applications.
繰り返される必要があるトランザクションが大きな要求で構成されていた場合、受信者の数が多い、またはその両方とき、または、UAのアクセスネットワークは、トラフィックのかなりの量を運ぶ必要があります。低帯域幅のアクセス上のすべてのトランザクションを完了すると、長い時間を必要とするであろう。これは、アプリケーションの数には受け入れられません。
A solution to this problem consists of introducing URI-list services in the network. The task of a SIP URI-list service is to receive a request that contains or references a URI list (i.e., a list of one or more URIs) and send a number of similar requests to the destinations in this list. Once the requests are sent, the URI-list service typically informs the UA about their status. Effectively, the URI-list service behaves as a B2BUA (Back-to-Back-User-Agent).
この問題を解決するには、ネットワーク内のURIリストサービスを導入することからなります。 SIP URIリストサービスのタスクは、URIリストを含むか、または参照要求（すなわち、一つ以上のURIのリスト）を受信し、このリスト内の目的地と同様の要求の数を送信することです。リクエストが送信されると、URIリストサービスは、典型的には、その状態についてのUAに通知します。効果的に、URIリストサービスは、B2BUA（バックツーバック・ユーザエージェント）として動作します。
A given URI-list service can take as an input a URI list contained in the SIP request sent by the client or an external URI list (e.g., the Request-URI is a SIP URI that is associated with a URI list at the server). External URI lists are typically set up using out-of-band mechanisms (e.g., XML Configuration Access Protocol (XCAP) [RFC4825]). An example of a URI-list service for SUBSCRIBE requests that uses stored URI lists is described in [RFC4662].
与えられたURIリストサービスは、入力として、クライアントまたは外部のURIリストによって送信されたSIP要求に含まれるURIのリストを取ることができる（例えば、リクエストURIは、サーバにURIリストに関連付けられたSIP URIです） 。外部のURIリストは、典型的には、アウトオブバンド機構（例えば、XML構成アクセスプロトコル（XCAP）[RFC4825]）を使用して設定されています。記憶されたURIのリストを使用するSUBSCRIBEリクエストのURIリストサービスの例は、[RFC4662]に記載されています。
The remainder of this document provides requirements and a framework for URI-list services using request-contained URI lists, external URI lists, or both.
この文書の残りの部分は、要件及び要求に含まれるURIリスト、外部URIのリスト、またはその両方を使用して、URIリストサービスのためのフレームワークを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Section 3.1 discusses requirements that only apply to URI-list services that use request-contained lists, and Section 3.2 discusses requirements that also apply to services using external lists.
3.1節は、外部リストを使用してサービスに適用要求に含まれるリストを使用するURIリストサービス、および3.2節を議論要件に適用される要件について説明します。
REQ 1: The URI-list service invocation mechanism MUST allow the invoker to provide a list of destination URIs to the URI-list service.
REQ 1：URIリストサービスの呼び出しメカニズムは、呼び出し元はURIリストサービスに先URIのリストを提供することを可能にしなければなりません。
REQ 2: The invocation mechanism SHOULD NOT require more than one transaction.
REQ 2：呼び出しメカニズムは、複数のトランザクションを必要とすべきではありません。
GEN 1: A URI-list service MAY include services beyond sending requests to the URIs in the URI list. That is, URI-list services can be modeled as application servers. For example, a URI-list service handling INVITE requests may behave as a conference server and perform media mixing for all the participants.
GEN 1：URIリストサービスは、URIリスト内のURIにリクエストを送信するを超えてサービスを含むかもしれません。それはURIリストサービスは、アプリケーションサーバとしてモデル化することが可能です。例えば、URIリストサービスの取扱いは、要求が会議サーバとして動作し、すべての参加者のために、混合メディアを行うことができるINVITE。
GEN 2: The interpretation of the meaning of the URI list sent by the invoker MUST be at the discretion of the application to which the list is sent.
GEN 2：呼び出しによって送られたURIリストの意味の解釈は、リストが送信されたアプリケーションの裁量でなければなりません。
GEN 3: It MUST be possible for the invoker to find out about the result of the operations performed by the URI-list service with the URI list. An invoker may, for instance, be interested in the status of the transactions initiated by the URI-list service.
GEN 3：呼び出しがURIリストでURIリストサービスによって実行される操作の結果を知ることが可能でなければなりません。呼び出し元は、例えば、URIリストサービスによって開始されたトランザクションの状態に興味があるかもしれません。
GEN 4: URI-list services MUST NOT send requests to any destination without authenticating the invoker.
GEN 4：URI - リストサービスは、呼び出し元を認証することなく、任意の宛先に要求を送ってはいけません。
This framework is not restricted to application servers that only provide request fan-out services. Per GEN 1, this framework also deals with application servers that provide a particular service that includes a request fan-out (e.g., a conference server that INVITEs several participants that are chosen by a user agent).
このフレームワークは、リクエストのみファンアウトサービスを提供するアプリケーションサーバに限定されません。当たりGEN 1は、このフレームワークは、要求ファンアウト（ユーザエージェントによって選択される複数の参加者を招待例えば、会議サーバ）を含む特定のサービスを提供するアプリケーションサーバを扱います。
The requirements related to URI-list services that use request-contained lists identify the need for a mechanism to provide a SIP URI-list service with a URI list in a single transaction. We define a new disposition type [RFC2183] for the Content-Disposition header field: recipient-list. Both requests and responses MAY carry recipient-list bodies. Bodies whose disposition type is recipient-list carry a list of URIs that contains the final recipients of the requests to be generated by a URI-list service.
リクエストに含まれるリストを使用するURIリストサービスに関連する要件は、単一のトランザクションでURIリストとSIP URI - リストサービスを提供するためのメカニズムの必要性を識別します。受信者リスト：私たちは、コンテンツDispositionヘッダーフィールドのための新たな処分タイプ[RFC2183]を定義します。要求と応答の両方が受信者リストの遺体を運ぶことができます。その気質タイプで、受信者リストのリクエストの最終受信者はURIリストサービスによって生成されるように含まれているURIのリストを運ぶボディ。
The default format for recipient-list bodies is service specific. So, URI-list services specifications MUST specify a default format for recipient-list bodies used within a particular service. In any case, clients SHOULD NOT include any particular URI more than once in a given URI list.
受信者リストの体のためのデフォルトの形式は、サービス固有のものです。だから、URIリストサービス仕様は、特定のサービス内で使用される受信者リストの体のデフォルトの形式を指定する必要があります。いずれの場合も、クライアントが複数回指定されたURIのリストの中よりも、特定のURIを含めるべきではありません。
A UA server receiving a request with more than one recipient-list body parts (e.g., each body part using a different URI-list format) MUST behave as if it had received a single URI list that contains all the URIs present in the different body parts.
複数の受信者リストの身体部分と要求を受信するUAサーバ（例えば、異なるURIリスト形式を用いて、各身体部分）が異なる体内に存在するすべてのURIを含む単一のURIリストを受信したかのように動作しなければなりません部品。
A UA server receiving a recipient-list URI list that contains a URI more than once MUST behave as if that URI appeared in the URI list only once. The UA server uses the comparison rules specific to the URI scheme of each of the URIs in the URI list to determine if there is any URI that appears more than once. Additionally, Section 4 of "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364] discusses cases where duplicated URI entries are tagged with different values of the 'copyControl' attribute. Naturally, URI-list services using the 'copyControl' attribute defined in [RFC5364] need to follow the recommendations in [RFC5364] with respect to avoiding sending duplicated requests.
そのURIは一度だけURIリストに登場したかのように動作しなければならない複数回URIが含まれている受信者リストURIリストを受信UAサーバー。 UAサーバが複数回表示される任意のURIがあるかどうかを決定するためにURIリスト内のURIの各URIスキームに固有の比較規則を使用しています。さらに、4節[RFC5364]重複URIエントリが「コピーコントロールCD」属性の異なる値でタグ付けされている例を説明し、「コピー制御を表現するための拡張マークアップ言語（XML）形式拡張子は、リソースリストに属性」。当然のことながら、[RFC5364]で定義された「コピーコントロールCD」属性を使用してURIリストサービスは、重複要求を送信回避に関して[RFC5364]の推奨事項に従う必要があります。
The way a UA server interprets a URI list that it has received is service specific, as described in Section 4.2.
セクション4.2で説明したようにUAサーバは、受信したURIのリストを解釈する方法は、サービス固有のものです。
According to GEN 1 and GEN 2, URI-list services can behave as application servers. That is, taking a URI list as an input, they can provide arbitrary services. So, the interpretation of the URI list by the server depends on the service to be provided. For example, for a conference server, the URIs in the list may identify the initial set of participants. On the other hand, for a server dealing with MESSAGEs, the URIs in the list may identify the recipients of an instant message.
GEN 1およびGEN 2によると、URIリストサービスは、アプリケーションサーバとして動作することができます。これは、入力として、URIのリストを取っている、彼らは任意のサービスを提供することができます。だから、サーバーによってURIリストの解釈は、提供されるサービスに依存します。例えば、会議サーバのために、リスト内のURIは、参加者の初期セットを識別することができます。一方、メッセージを扱うサーバに対して、リスト内のURIは、インスタントメッセージの受信者を識別することができます。
At the SIP level, this implies that the behavior of application servers receiving requests with URI lists SHOULD be specified on a per-service basis. Examples of such specifications are [RFC5366] for INVITE, [RFC5365] for MESSAGE, and [RFC5367] for SUBSCRIBE.
SIPレベルでは、これはURIのリストを持つリクエストを受け取るアプリケーション・サーバの動作は、サービスごとに指定する必要があることを意味します。そのような規格の例には、SUBSCRIBEのために、INVITEのために[RFC5366]、メッセージの[RFC5365]及び[RFC5367]です。
According to GEN 3, user agents should have a way to obtain information about the operations performed by the application server. Since these operations are service specific, the way user agents are kept informed is also service specific. For example, a user agent establishing an ad hoc conference with an INVITE with a URI list may discover which participants were successfully brought into the conference by using the conference package [RFC4575].
GEN 3によれば、ユーザエージェントは、アプリケーション・サーバによって実行される操作に関する情報を取得する方法を有していなければなりません。これらの操作は、サービス固有のものですので、ユーザーエージェントが通知保たれている方法は、特定のサービスです。例えば、URIリストにINVITEを持つユーザエージェント確立アドホック会議が成功裏に会議パッケージ[RFC4575]を使用して会議に持ち込まれた参加者を発見します。
Security plays an important role in the implementation of any URI-list service. In fact, it is the most important common area across all types of URI-list services.
セキュリティは、任意のURIリストサービスの実現に重要な役割を果たしています。実際には、URIリストサービスのすべてのタイプの間で最も重要な共通の領域です。
By definition, a URI-list service takes one request in and sends a potentially large number of them out. Attackers may attempt to use URI-list services as traffic amplifiers to launch DoS (denial-of-service) attacks. This section provides guidelines to avoid these attacks.
定義では、URIリストサービスは、1つの要求を受け取り、それらの潜在的に多数を送信します。攻撃者がDoS攻撃（サービス拒否）攻撃を開始するために、トラフィック・アンプとしてURIリストサービスを利用しようとすることができます。このセクションでは、これらの攻撃を回避するためのガイドラインを提供します。
Attackers may attempt to modify URI lists sent from clients to servers. This would cause a different behavior at the server than expected by the client (e.g., requests being sent to different recipients than the ones specified by the client). To prevent this attack, clients SHOULD integrity protect URI lists using end-to-end mechanisms such as S/MIME or, if not available, hop-by-hop mechanisms such as TLS. Both S/MIME and TLS can also provide URI-list confidentiality if needed.
攻撃者は、サーバーへのクライアントから送信されたURIのリストを変更しようとすることができます。これは、クライアントが予想以上のサーバで異なる動作を引き起こす（例えば、要求がクライアントによって指定されたものとは異なる受信者に送信されています）。この攻撃を防ぐために、クライアントは、整合性は、S / MIMEやTLSなど、利用できない場合は、ホップバイホップメカニズムとして、エンドツーエンドのメカニズムを使用してURIリストを保護する必要があります。必要に応じて、どちらのS / MIMEやTLSもURIリストの機密性を提供することができます。
URI-list services take a request in and send a potentially large number of them out. Given that URI-list services are typically implemented on top of powerful servers with high-bandwidth access links, we should be careful to keep attackers from using them as amplification tools to launch DoS attacks.
URIリストサービスは、リクエストを取り、それらの潜在的に大きな数を送り出します。 URIリストサービスは、典型的には、高帯域幅のアクセスリンクを持つ強力なサーバーの上に実装されていることを考えると、我々は、DoS攻撃を起動するために、増幅ツールとしてそれらを使用して、攻撃者を保つために注意する必要があります。
Attackers may attempt to send a URI list containing URIs whose host parts route to the victims of the DoS attack. These victims do not need to be SIP nodes; they can be non-SIP endpoints or even routers. If this attack is successful, the result is that an attacker can flood a set of nodes, or a single node, with traffic without needing to generate a high volume of traffic itself.
攻撃者は、ホスト部品DoS攻撃の犠牲者へのルートURIを含むURIのリストを送信することを試みることができます。これらの犠牲者は、SIPノードである必要はありません。彼らは非SIPエンドポイントまたはルーターにもなることができます。この攻撃が成功した場合、その結果は、攻撃者がトラフィック自体の高音量を発生することなく、トラフィックと、ノードのセット、または単一ノードをあふれさせることができるということです。
In any case, note that this problem is not specific to SIP URI-list services; it also appears in scenarios that relate to multihoming where a server needs to contact a set of IP addresses provided by a client.
いずれにせよ、この問題はURIリストサービスをSIPに固有のものではないことに注意してください。それはまた、サーバは、クライアントが提供するIPアドレスのセットを連絡する必要がある場合マルチホーミングに関連するシナリオに表示されます。
There are several measures that need to be taken to prevent this type of attack. The first one is keeping unauthorized users from using URI-list services. So, URI-list services MUST NOT perform any request explosion for an unauthorized user. URI-list services MUST authenticate users and check whether they are authorized to request the service before performing any request fan-out.
この種の攻撃を防ぐために取られる必要があるいくつかの対策があります。最初のものはURIリストサービスを使用して、権限のないユーザーを保っています。だから、URIリストサービスは、不正利用者のためのすべての要求の爆発を実行してはなりません。 URIリストサービスは、ユーザーを認証し、それらがすべての要求ファンアウトを実行する前にサービスを要求することが許可されているかどうかをチェックしなければなりません。
Note that the risk of this attack also exists when a client uses stored URI lists. Application servers MUST use authentication and authorization mechanisms with equivalent security properties when dealing with stored and request-contained URI lists.
クライアントは、保存されたURIのリストを使用している場合、この攻撃のリスクも存在することに注意してください。保存され、要求に含まれるURIのリストを扱うときに、アプリケーション・サーバーは、同等のセキュリティプロパティでの認証と承認のメカニズムを使用しなければなりません。
Even though the previous rule keeps unauthorized users from using URI-list services, authorized users may still launch attacks using these services. To prevent these attacks, we introduce the concept of opt-in lists. That is, URI-list services should not allow a client to place a user (identified by his or her URI) in a URI list unless the user has previously agreed to be placed in such a URI list. So, URI-list services MUST NOT send a request to a destination that has not agreed to receive requests from the URI-list service beforehand. Users can agree to receive requests from a URI-list service in several ways, such as filling a web page, sending an email, signing a contract, or using "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)" [RFC5360], whose requirements are discussed in [RFC4453]. Additionally, users MUST be able to further describe the requests they are willing to receive. For example, a user may only want to receive requests from a particular URI-list service on behalf of a particular user. Effectively, these rules make URI lists that used by URI-list services into opt-in lists.
以前のルールはURIリストサービスを使用して、権限のないユーザーを保持していても、許可されたユーザーはまだこれらのサービスを利用して攻撃を開始します。これらの攻撃を防ぐために、我々は、オプトインリストの概念を導入します。それはURIリストサービスは、ユーザーが以前に、そのようなURIリストに配置することに合意した場合を除き、クライアントがURIリストに（彼または彼女のURIで識別される）は、ユーザーを配置できるようにするべきではない、です。だから、URIリストサービスは、事前にURIリストサービスからの要求を受信することに同意していない宛先にリクエストを送ってはいけません。ユーザーは、このような、Webページを埋める電子メールを送信して、契約書に署名、または「セッション開始プロトコル（SIP）に同意ベースの通信のためのフレームワーク」を使用するなど、いくつかの方法でURIリストサービスからの要求を受信することに同意することができます[RFC5360]、その要件[RFC4453]に記載されています。さらに、ユーザーはさらに、彼らが受けても構わないと思っているの要求を記述することができなければなりません。例えば、ユーザは、特定のユーザーに代わって特定のURIリストサービスからの要求を受信したいことがあります。実際には、これらのルールは、オプトインリストにURIリストサービスで使用されるURIのリストを作ります。
When a URI-list service receives a request with a URI list from a client, the URI-list service checks whether all the destinations have agreed beforehand to receive requests from the service on behalf of this client. If the URI list has permission to send requests to all of the targets in the request, it does so. If not, it does not send any request at all.
URIリストサービスは、クライアントからのURIのリストで要求を受信すると、すべての宛先が事前に合意しているかどうかをURIリストサービスチェックはこのクライアントの代わりにサービスからの要求を受信します。 URIリストは、要求内のすべてのターゲットに要求を送信する権限を持っている場合、それはそう。そうでない場合、それはまったくのリクエストを送信しません。
The Framework for Consent-Based Communications in SIP [RFC5360] specifies a means for the URI-list service to inform the client that some permissions were missing and how to request them.
SIP [RFC5360]で同意ベースの通信のためのフレームワークでは、URIリストサービスは、いくつかの権限が不足しているとどのようにそれらを要求していたことをクライアントに通知する手段を指定します。
Note that the mechanism used to obtain permissions should not create opportunities to launch DoS amplification attacks. These attacks would be possible if, for instance, the URI-list service automatically contacted the full set of targets for which it did not have permissions in order to request permissions. The URI-list service would be receiving one SIP request and sending out a number of authorization request messages. The Framework for Consent-Based Communications in SIP [RFC5360] avoids this type of attack by having the client generate roughly the same amount of traffic towards the URI-list service as the service generates towards the destinations.
アクセス権を取得するために使用されるメカニズムは、DoS攻撃増幅攻撃を起動するための機会を作成するべきではないことに注意してください。例えば、URIリストサービスが自動的にそれを要求許可するために、権限を持っていなかったため、ターゲットのフルセットを連絡、場合、これらの攻撃は可能であろう。 URIリストサービスは、1つのSIP要求を受信し、認証要求メッセージの数を送信することになります。 SIP [RFC5360]に同意ベースの通信のためのフレームワークは、サービスが宛先に向けて生成、クライアントがURIリストサービスに向けて略トラフィックの同じ量を生成有することにより、この種の攻撃を回避します。
In order to have an interoperable way to meet the requirements related to opt-in lists described in this section, URI-list services MUST implement and SHOULD use "A Framework for Consent-Based Communications in SIP" [RFC5360].
オプトインするには、このセクションで説明するリスト関連の要件を満たすために、相互運用可能な方法を持っているために、URIリストサービスを実装しなければならないと「SIPでの同意ベースの通信のための枠組み」[RFC5360]を使用すべきです。
URI-list services MAY have policies that limit the number of URIs in the lists they accept, as a very long list could be used in a denial-of-service attack to place a large burden on the URI-list service to send a large number of SIP requests.
URIリストサービスは非常に長いリストとして、彼らは受け入れるリストにURIの数を制限する政策は、大きなを送信するためにURIリストサービスに大きな負荷を配置するためにサービス拒否攻撃で使用することができていてもよい（MAY） SIP要求の数。
A URI-list service generates a set of requests from a URI list. Section 19.1.5 of [RFC3261] provides recommendations that need to be taken into consideration when forming a request from a URI. Naturally, those recommendations apply to all SIP URI-list services.
URIリストサービスは、URIのリストからの要求のセットを生成します。 [RFC3261]のセクション19.1.5は、URIから要求を形成する際に考慮される必要がある推奨事項を提供します。当然のことながら、これらの推奨事項は、すべてのSIP URI - リストサービスに適用されます。
The general requirement GEN 4, which states that URI-list services need to authenticate their clients, and the previous rules apply to URI-list services in general. In addition, specifications dealing with individual methods MUST describe the security issues that relate to each particular method.
URIリストサービスはそのクライアントを認証する必要があり、以前のルールは、一般的にはURIリストサービスに適用されると述べている一般的な要件GEN 4、。加えて、個々のメソッドを扱う仕様は、各特定の方法に関連するセキュリティ上の問題を説明しなければなりません。
This document defines a new Content-Disposition header field disposition type (recipient-list) in Section 4.1. This value has been registered in the IANA registry for Mail Content Disposition Values and Parameters with the following description:
この文書は、セクション4.1で新しいコンテンツ-Dispositionヘッダーフィールドの配置タイプ（受信者リスト）を定義します。この値は、以下の説明でメールコンテンツ配置値とパラメータのためのIANAレジストリに登録されています。
recipient-list The body includes a list of URIs to which URI-list services are to be applied.
受信者リストの体はURIリストサービスが適用されるためのURIのリストを含んでいます。
Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n MESSAGE requests. Jon Peterson, Dean Willis, and Jonathan Rosenberg provided useful comments.
ダンカンミルズとミゲルA.ガルシア・マーティンは、n個のMESSAGE要求に1の考え方を支持しました。ジョンピーターソン、ディーンウィリス、とジョナサンローゼンバーグは、有益なコメントを提供しました。
[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月。
[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月。
[RFC5360] Rosenberg, J., Camarillo, G., Ed., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
[RFC5360]ローゼンバーグ、J.、カマリロ、G.編、及びD.ウィリス、RFC 5360、2008年11月 "セッション開始プロトコル（SIP）に同意ベースの通信のためのフレームワーク"。
[RFC4453] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 4453, April 2006.
[RFC4453]ローゼンバーグ、J.、カマリロ、G.、およびD.ウィリス、RFC 4453 "セッション開始プロトコル（SIP）に同意ベースの通信のための要件" 2006年4月。
[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月。
[RFC4662] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]ローチ、A.B.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのためのAセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[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月。
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", RFC 5365, October 2008.
[RFC5365]ガルシア・マーチン、M.およびG.カマリロ、RFC 5365、2008年10月「セッション開始プロトコル（SIP）における複数の受信者のメッセージ要求」。
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[RFC5366]キャマリロ、G.とA.ジョンストン、 "会議の設立セッション開始プロトコル（SIP）に要求-含まれるリストの使用"、RFC 5366、2008年10月。
[RFC5367] Camarillo, G., Roach, A.B., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008.
[RFC5367]キャマリロ、G.、ローチ、A.B.、およびO.レヴィン、RFC 5367、2008年10月 "サブスクリプションは、セッション開始プロトコル（SIP）にリソースリストを-含まれる要求します"。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Adam Roach Tekelec 17210 Campbell Rd Ste 250 Dallas, TX 75252 USA
アダムローチTekelec 17210キャンベルRdのスイート250、ダラス、TX 75252 USA
EMail: Adam.Roach@tekelec.com
メールアドレス：Adam.Roach@tekelec.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に情報を記述してください。