[要約] RFC 5364は、リソースリスト内のコピー制御属性を表現するためのXML形式の拡張を定義しています。このRFCの目的は、リソースリスト内のコピー制御属性を効果的に表現し、相互運用性を向上させることです。
Network Working Group M. Garcia-Martin
Request for Comments: 5364 G. Camarillo
Category: Standards Track Ericsson
October 2008
Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
リソースリスト内のコピー制御属性を表すための拡張マークアップ言語（XML）形式拡張機能
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
概要
In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems.
特定のタイプのマルチメディア通信では、セッション開始プロトコル（SIP）リクエストがSIPユーザーエージェント（UAS）のグループに配布されます。送信者は、グループにリクエストをさらに配布するサーバーに単一のSIPリクエストを送信します。このSIPリクエストには、SIPリクエストの受信者を識別するユニフォームリソース識別子（URI）のリストが含まれています。このURIリストは、リソースリストXMLドキュメントとして表されます。この仕様では、XMLリソースリスト形式へのXML拡張機能を定義します。これにより、リクエストの送信者が既存の電子メールシステムのコピー制御レベルと同様のコピー制御レベルを持つ受信者を資格を取得できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Extension to the Resource List Data Format . . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
RFC 5363 [RFC5363] describes a generic framework for carrying Uniform Resource Identifier (URI) lists in SIP [RFC3261] messages. Specifically, the document provides a common framework for specific implementations of URI-list services, such as conferences initiated with INVITE requests [RFC5366] or Multiple-recipient MESSAGE requests [RFC5365].
RFC 5363 [RFC5363]は、SIP [RFC3261]メッセージに均一なリソース識別子（URI）リストを運ぶための一般的なフレームワークについて説明しています。具体的には、このドキュメントは、招待リクエスト[RFC5366]や多額のメッセージ要求[RFC5365]で開始された会議など、URIリストサービスの特定の実装のための一般的なフレームワークを提供します。
Common to all URI-list services is the presence of a SIP request that contains a collection of resources, typically expressed as an XML resource list [RFC4826]. SIP requests carrying resource lists can appear either in requests received by the URI-list server, indicating the list of intended recipients, or in each of the requests that the URI-list server sends to recipients, indicating the list of recipients of the same SIP request.
すべてのURI-Listサービスに共通するのは、通常XMLリソースリスト[RFC4826]として表されるリソースのコレクションを含むSIPリクエストの存在です。リソースリストを伝えるSIPリクエストは、URI-Listサーバーが受信したリクエスト、意図した受信者のリストを示す、またはURI-Listサーバーが受信者に送信する各リクエストのいずれかに表示され、同じSIPの受信者のリストを示すことができます。リクエスト。
Although the XML resource list [RFC4826] provides a powerful mechanism for describing a list of resources, there is a need for a copy control attribute to determine whether a resource is receiving a SIP request as a primary recipient, a carbon copy, or a blind carbon copy. This is similar to common email systems, where the sender can categorize each recipient as a "to", "cc", or "bcc" recipient.
XMLリソースリスト[RFC4826]は、リソースのリストを記述するための強力なメカニズムを提供しますが、リソースがプライマリレシピエント、カーボンコピー、またはブラインドとしてSIPリクエストを受信しているかどうかを判断するためのコピー制御属性が必要ですカーボンコピー。これは、送信者が各受信者を「to」、「CC」、または「BCC」受信者に分類できる一般的な電子メールシステムに似ています。
This document addresses this problem by providing an extension to the XML resource list [RFC4826] that enables the sender to supply a copy control attribute that labels each recipient as a "to", "cc", or "bcc" recipient. This attribute indicates whether the recipient is receiving a primary copy of the SIP request, a carbon copy, or a blind carbon copy. Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs.
このドキュメントは、XMLリソースリスト[RFC4826]への拡張機能を提供することにより、この問題に対処します。これにより、送信者が各受信者を「to」、「cc」、または「bcc」レシピエントとしてラベル付けするコピー制御属性を提供できます。この属性は、受信者がSIPリクエストの主要なコピー、カーボンコピー、またはブラインドカーボンコピーを受け取っているかどうかを示します。さらに、一部の受信者が他の受信者に開示されないように、1つ以上のリソースを匿名化する必要があることをURIリストに示す能力を送信者に提供します。代わりに、これらのURIは匿名のurisに置き換えられます。
The remainder of this document is organized as follows: Section 2 introduces the terminology used throughout this specification. Section 3 gives an overview of operation. Section 4 formally defines an extension to URI lists. The XML schema definition is provided in Section 5. Section 6 shows examples of the URI lists with the extensions defined in this document. Section 7 discusses the implications of carrying URI lists in SIP messages.
このドキュメントの残りの部分は、次のように編成されています。セクション2では、この仕様全体で使用される用語を紹介します。セクション3では、操作の概要を示します。セクション4では、URIリストへの拡張機能を正式に定義しています。XMLスキーマ定義はセクション5に記載されています。セクション6は、このドキュメントで定義されている拡張機能を備えたURIリストの例を示しています。セクション7では、SIPメッセージに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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]で説明されているように解釈され、準拠の実装の要件レベルを示します。
URI-list service: SIP application service that receives a SIP request containing a URI list and sends a similar SIP request to each URI in the list.
URI-Listサービス：URIリストを含むSIPリクエストを受信し、リスト内の各URIに同様のSIPリクエストを送信するSIPアプリケーションサービス。
Intended recipient: The intended final recipient of the request to be generated by URI-list service.
意図された受信者：URI-Listサービスによって生成されるリクエストの意図された最終受信者。
Copy control: An attribute assigned by the sender to a URI in an XML resource list. Its purpose is to indicate to the recipient whether he is getting a primary, carbon, or blind carbon copy of the SIP request.
コピーコントロール：送信者によってXMLリソースリストのURIに割り当てられた属性。その目的は、SIPリクエストのプライマリ、カーボン、またはブラインドカーボンコピーを取得しているかどうかを受信者に示すことです。
Recipient list or recipient XML resource list: An XML resource list containing the list of intended recipients. The sender sets this list in the SIP request he sends to the URI-list server.
受信者リストまたは受信者XMLリソースリスト：意図した受信者のリストを含むXMLリソースリスト。送信者は、このリストをURI-Listサーバーに送信するSIPリクエストに設定します。
Recipient-history list or recipient-history XML resource list: An XML resource list containing the visible list of recipients (i.e., those non-anonymous non-bcc). The URI-list server creates this list, based on the recipient list, and includes it in each of the SIP requests it sends to each recipient.
受信者の歴史リストまたは受信者の歴史的なXMLリソースリスト：受信者の可視リスト（つまり、非匿名ではない非BCC）を含むXMLリソースリスト。URI-Listサーバーは、受信者リストに基づいてこのリストを作成し、各受信者に送信する各SIPリクエストにそれを含めます。
Figure 1 depicts a general overview of the operation of a URI-list server. A SIP User Agent Client (UAC) issuer sends a SIP request (F1) to a URI-list server containing a recipient list. The URI-list server generates a SIP request to each recipient, according to the specific SIP method. Each of these SIP requests contains a recipient-history list that indicates the visible list of recipients of the SIP request.
図1は、URIリストサーバーの操作の一般的な概要を示しています。SIPユーザーエージェントクライアント（UAC）発行者は、受信者リストを含むURIリストサーバーにSIPリクエスト（F1）を送信します。URI-Listサーバーは、特定のSIPメソッドに従って、各受信者にSIP要求を生成します。これらの各SIPリクエストには、SIPリクエストの受信者の可視リストを示す受信者の歴史リストが含まれています。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | |
| F2 2xx response | | | |
|<---------------- | F3 SIP request | | |
| | (recp-hist.list)| | |
| | --------------->| | |
| | F4 SIP request | | |
| | (recp-hist.list)| | |
| | -------------------------->| |
| | F5 SIP request | | |
| | (recp-hist.list)| | |
| | ------------------------------------->|
| | F6 200 OK | | |
| |<--------------- | | |
| | F7 200 OK | | |
| |<-------------------------- | |
| | F8 200 OK | | |
| |<------------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operation
図1：操作の例
The URI-list mechanism allows a sender to specify multiple targets for a SIP request by including a recipient XML resource list [RFC4826] in the body of the SIP request. This recipient list includes the target URIs of the SIP request (the actual procedures are method specific and outside the scope of this document). Each target URI may also be marked with a copy control attribute to indicate the copy level in which the recipient is receiving the SIP request. This is achieved by the sender qualifying each URI in the URI list with a 'copyControl' attribute. The available values of the 'copyControl' attribute include "to", "cc", and "bcc" (analogous to email). This is discussed in greater detail in Section 4. When the URI-list server expands the request to each recipient, the URI-list server includes a recipient-history XML resource list built upon the recipient list received from the sender. The recipient-history XML resource list replaces the recipient list in the SIP requests generated by the URI-list server towards each recipient. The URI-list server copies from the recipient list those targets that are marked with the "to" and "cc" copy control level, and pastes them in the recipient-history list. The URI-list server explicitly excludes from the recipient-history list those URIs marked with a "bcc" copy control, although it is able to preserve the address of a "bcc" tagged URI when it matches the URI of the recipient of the SIP request (this is described later in Section 4). When a recipient receives the SIP request containing the recipient-history XML resource list, he is able to determine which other visible recipients are getting a copy of the SIP request, and whether they are marked with the "to" or "cc" copy control level. Later, if needed, the recipient can generate a reply to those visible recipients.
URI-Listメカニズムにより、送信者は、SIPリクエストの本文に受信者XMLリソースリスト[RFC4826]を含めることにより、SIPリクエストの複数のターゲットを指定できます。この受信者リストには、SIP要求のターゲットURIが含まれています（実際の手順は、このドキュメントの範囲外であり、このドキュメントの範囲外です）。各ターゲットURIには、受信者がSIPリクエストを受信しているコピーレベルを示すコピー制御属性をマークすることもできます。これは、「Copycontrol」属性を使用して、URIリストの各URIの資格を持つ送信者によって達成されます。「Copycontrol」属性の利用可能な値には、「cc」、「bcc」（電子メールに類似）が含まれます。これについては、セクション4で詳細に説明します。URI-Listサーバーが各受信者にリクエストを展開すると、URI-Listサーバーには、送信者から受信した受信者リストに基づいた受信者史XMLリソースリストが含まれています。受信者の歴史的なXMLリソースリストは、各受信者に対してURI-Listサーバーによって生成されたSIPリクエストの受信者リストを置き換えます。URI-Listサーバーは、受信者からコピーして、「to」と「CC」コピーコントロールレベルでマークされたターゲットをリストし、受信者の歴史リストに貼り付けます。URI-List Serverは、sipのレシピエントのURIと一致するときに「bcc」タグ付きURIのアドレスを保存することができますが、「bcc」コピーコントロールでマークされたurisを受信者の歴史リストから明示的に除外します。リクエスト（これはセクション4の後半で説明されています）。受信者が受信者の歴史XMLリソースリストを含むSIPリクエストを受信すると、他の目に見える受信者がSIPリクエストのコピーを取得しているか、およびそれらが「to」または「cc」コントロールでマークされているかどうかを判断できます。レベル。後で、必要に応じて、受信者はそれらの目に見える受信者への返信を生成できます。
In addition to the 'copyControl' attribute for a URI in an XML resource list, we define a second boolean attribute called 'anonymize'. The sender of a SIP request can mark a URI in a recipient XML resource list with the 'anonymize' attribute to indicate the URI-list server that the URI marked with that attribute is to be replaced with an anonymous URI in the recipient-history XML resource list. This provides knowledge to the recipients of a SIP request of the number of additional visible recipients whose URIs have not been disclosed.
XMLリソースリストのURIの「Copycontrol」属性に加えて、「匿名」と呼ばれる2番目のブール属性を定義します。SIPリクエストの送信者は、受信者XMLリソースリストのURIを「匿名」属性とマークして、その属性をマークしたURIがレシピエントヒストリーXMLの匿名URIに置き換えることをURIリストサーバーに示すことができます。リソースリスト。これは、URIが開示されていない追加の可視受信者の数のSIPリクエストのSIP要求の知識を提供します。
There are cases when the sender marks several URIs with the 'anonymize' attribute. The URI-list server can group the anonymized URIs in a single anonymized URI within its copy control level, and provide a count of the number of anonymized URIs. To support this scenario, we define a new 'count' attribute to a URI in the recipient-history XML resource list. It is expected that the 'count' attribute is only used with anonymous URIs, although syntactically it is possible to add a 'count' attribute to any URI in any XML resource list.
送信者が「匿名」属性を持ついくつかのURIをマークする場合があります。URI-Listサーバーは、匿名化されたURIをコピー制御レベル内で単一の匿名化されたURIにグループ化し、匿名化されたURIの数のカウントを提供できます。このシナリオをサポートするために、レシピエント史XMLリソースリストのURIに新しい「カウント」属性を定義します。「count」属性は匿名のurisでのみ使用されることが予想されますが、構文的にはXMLリソースリストの任意のURIに「カウント」属性を追加することができます。
Initially, it may be thought that the 'anonymize' attribute overlaps with the "bcc" value of the 'copyControl' attribute. However, there are differences between them. If the sender qualifies a URI with a 'copyControl' attribute of "bcc" in the recipient XML resource list, the URI-list server will typically remove that URI from the recipient-history XML resource list (unless the URI-list server decides to preserve a "bcc" marked URI when that URI is itself the recipient of the SIP request). Recipients of the SIP request will not notice that one or more extra "bcc" URIs also received the request. However, if the sender qualifies a URI with the 'anonymize' attribute in the recipient XML resource list, the URI-list server will replace the URI with an anonymous one in the recipient-history list. Recipients of the SIP request will notice that there have been one or more additional recipients of the same request, but their URIs are not disclosed.
当初、「匿名」属性が「bcc」値の「copycontrol」属性と重複すると考えられるかもしれません。ただし、それらには違いがあります。送信者が受信者XMLリソースリストに「bcc」の「copycontrol」属性を持つURIを適格にする場合、URI-listサーバーは通常、Reciontient-History XMLリソースリストからそのURIを削除します（URI-Listサーバーが決定しない限りURI自体がSIPリクエストの受信者である場合、URIとマークされた「BCC」を保存します）。SIPリクエストの受信者は、1つ以上の追加の「BCC」URIもリクエストを受け取ったことに気付かない。ただし、送信者が受信者XMLリソースリストに「匿名」属性を持つURIを適格にする場合、URI-ListサーバーはURIを受信者歴史リストの匿名のサーバーに置き換えます。SIPリクエストの受信者は、同じリクエストの1つ以上の追加の受信者がいることに気付くでしょうが、彼らのURIは開示されていません。
This document defines an extension to the XML resource list data format [RFC4826] that allows the sender to indicate a copy control attribute that qualifies a recipient with a copy control level. We define a new 'copyControl' attribute to the <entry> element of the resource list document format [RFC4826]. The 'copyControl' attribute has similar semantics to the type of destination address in email systems. It can take the values "to", "cc", and "bcc". A "to" value of the 'copyControl' attribute indicates that the resource is considered a primary recipient of the SIP request. A "cc" value indicates that the resource receives a carbon copy of the SIP request. A "bcc" value indicates that the resource receives a blind carbon copy of the SIP request (i.e., this URI is not disclosed to other recipients of the SIP request). The default 'copyControl' value is "bcc". That is, the absence of a 'copyControl' attribute MUST be treated as if the 'copyControl' was set to "bcc".
このドキュメントでは、XMLリソースリストデータ形式[RFC4826]の拡張機能を定義しているため、送信者はコピー制御レベルの受信者を適格にするコピー制御属性を示すことができます。リソースリストドキュメント形式[RFC4826]の<Entry>要素に新しい「CopyControl」属性を定義します。「CopyControl」属性は、電子メールシステムの宛先アドレスのタイプと同様のセマンティクスを持っています。値「to」、「cc」、および「bcc」を取ることができます。「Copycontrol」属性の「to」値は、リソースがSIP要求の主要な受信者と見なされることを示します。「CC」値は、リソースがSIPリクエストのカーボンコピーを受信することを示します。「BCC」値は、リソースがSIPリクエストのブラインドカーボンコピーを受信することを示します（つまり、このURIはSIPリクエストの他の受信者に開示されていません）。デフォルトの「Copycontrol」値は「BCC」です。つまり、「copycontrol」属性が「copycontrol」が「bcc」に設定されているかのように扱わなければなりません。
When creating a recipient-history list, URI-list servers use "bcc" 'copyControl' attributes to route SIP requests. In addition, URI-list servers behave similarly to email systems [RFC2822] with respect to the treatment of these URIs marked with a "bcc" copy control, because they have two ways of treating "bcc" marked URIs. URI-list servers MUST treat these "bcc" marked URIs in either of the following two ways:
受信者の歴史リストを作成するとき、URI-Listサーバーは「BCC」「CopyControl」属性を使用して、SIPリクエストをルーティングします。さらに、URI-Listサーバーは、「BCC」コピーコントロールでマークされたこれらのURIの処理に関して、電子メールシステム[RFC2822]と同様に動作します。URI-Listサーバーは、これらの「BCC」とマークされたURIを次の2つの方法のいずれかで処理する必要があります。
o URI-list servers MUST remove all URIs marked with a "bcc" copy control in recipient-history lists. This mechanism allows URI-list servers to send the same recipient-history list to each recipient of the SIP request. However, recipients who are tagged with "bcc" values are not explicitly informed about it.
o URI-Listサーバーは、受信者歴史リストに「BCC」コピーコントロールでマークされたすべてのURIを削除する必要があります。このメカニズムにより、URI-Listサーバーは、SIPリクエストの各受信者に同じ受信者歴史リストを送信できます。ただし、「BCC」値でタグ付けされた受信者は、それについて明示的に通知されません。
o URI-list servers MUST preserve with a "bcc" copy control in the recipient-history list the URI that identifies the recipient (if any) and MUST remove the remaining URIs marked with a "bcc" copy control. Consequently, each recipient receives a different recipient-history list. However, recipients who have been marked with a "bcc" copy control are explicitly informed about it.
o URI-Listサーバーは、受信者の歴史リストに「BCC」コピーコントロールで保存する必要があります。その結果、各受信者は異なる受信者史リストを受け取ります。ただし、「BCC」コピーコントロールでマークされた受信者は、それについて明示的に通知されます。
Implementations that are able to receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in the recipient-history list or if it is included but tagged with a "bcc" copy control, then implementations SHOULD prevent the user from replying to all the recipients of the SIP request. This would allow the non-blind recipients to notice the existence of blind recipients of the SIP request.
受信者の歴史リストを受け取ることができる実装は、リストの内容に注意を払う必要があります。受信者のURIが受信者の歴史リストに含まれていない場合、または「BCC」コピーコントロールでタグ付けされている場合、実装はユーザーがSIPリクエストのすべての受信者に返信できないようにする必要があります。これにより、非盲検レシピエントがSIPリクエストの盲目の受信者の存在に気付くことができます。
A new 'anonymize' attribute can be included in a <entry> element of the resource list document format [RFC4826]. If set to a "true" value, it provides an indication to the URI-list server for not disclosing the URI itself in a URI list sent to the recipient, but instead to anonymize the URI (i.e., making it bogus in the recipient-history XML resource list). URI-list servers can use URIs tagged with the 'anonymize' attribute for routing SIP requests, but MUST convert them to the SIP URI "sip:anonymous@anonymous.invalid" in recipient-history lists. The default value of the 'anonymize' attribute is "false".
新しい「匿名」属性は、リソースリストドキュメント形式[RFC4826]の<エントリ>要素に含めることができます。「真の」値に設定されている場合、URI自体を受信者に送信したURIリストで開示せず、代わりにURIを匿名化するためにURI-Listサーバーに兆候を提供します（つまり、受信者に偽物になります - 履歴XMLリソースリスト）。URI-Listサーバーは、SIPリクエストをルーティングするために「Anonymize」属性でタグ付けされたURIを使用できますが、sip uri "sip：anonymous@anonymous.invalid" in Recipient-Historyリストに変換する必要があります。「匿名」属性のデフォルト値は「false」です。
There are occasions where the URI-list server encounters the same URI entry duplicated in a resource list, where duplicated URI entries are tagged with the same or different values of the 'copyControl' attribute. There are no reasonable usages that justify duplicated URIs in resource lists; thus, this is considered an error. URI-list servers should not send duplicated copies of the same SIP request to the same intended recipient. In case the URI-list server encounters the same URI entry duplicated in a resource list, it should send at most a single copy of the request to that intended recipient. For each set of duplicated URI entries, the URI-list server MUST select the highest precedence value of the 'copyControl' attribute for the same intended recipient. The order of precedence of the values of the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI-list server has selected a value for the 'copyControl' attribute of an intended recipient, the URI-list server can continue processing the request.
URI-Listサーバーがリソースリストに複製された同じURIエントリに遭遇する場合があります。この場合、複製されたURIエントリには、「Copycontrol」属性の同じまたは異なる値がタグ付けされます。リソースリストに重複したURIを正当化する合理的な使用法はありません。したがって、これはエラーと見なされます。URI-Listサーバーは、同じSIPリクエストの重複したコピーを同じ意図した受信者に送信してはなりません。URI-Listサーバーがリソースリストに複製された同じURIエントリに遭遇した場合、その要求のコピーを最大で意図した受信者に送信する必要があります。重複したURIエントリの各セットについて、URI-Listサーバーは、同じ意図した受信者に対して「CopyControl」属性の最高の優先順位値を選択する必要があります。「copycontrol」属性の値の優先順位は、「to」、「cc」、および「bcc」です。URI-Listサーバーが、意図した受信者の「Copycontrol」属性の値を選択すると、URI-Listサーバーはリクエストの処理を続けることができます。
Processing of URIs tagged with a 'copyControl' attribute set to a "bcc" value has higher precedence over the 'anonymize' attribute. Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list server MUST remove that URI from the recipient-history list, and the 'anonymize' attribute will be ignored. Therefore, the 'anonymize' attribute is only useful for those URIs tagged with a 'copyControl' of "to" or "cc".
「Copycontrol」属性を「BCC」値に設定したURISの処理は、「匿名」属性よりも優先されます。したがって、URIの「copycontrol」が「BCC」に設定されている場合、URI-ListサーバーはそのURIを受信者の歴史リストから削除する必要があり、「匿名」属性は無視されます。したがって、「匿名」属性は、「copycontrol」または「cc」の「copycontrol」でタグ付けされたurisにのみ役立ちます。
A new 'count' attribute can be also included in an <entry> element of the resource list document format [RFC4826]. It provides the number of equal URIs. Typically, recipient lists created by UACs will not have equal (or duplicate) URI entries; thus, it is not expected to contain URIs tagged with 'count' attributes. However, recipient-history lists can contain duplicated anonymized URIs; therefore, it is expected that recipient-history lists will contain 'count' attributes. The default value of the 'count' attribute is "1".
新しい「カウント」属性は、リソースリストドキュメント形式[RFC4826]の<エントリ>要素にも含めることができます。等しいurisの数を提供します。通常、UACSによって作成された受信者リストには、等しい（または重複）URIエントリがありません。したがって、「カウント」属性でタグ付けされたURIを含めることは期待されていません。ただし、受信者の歴史リストには、重複した匿名化されたURIが含まれている場合があります。したがって、受信者の歴史リストには「カウント」属性が含まれることが予想されます。「カウント」属性のデフォルト値は「1」です。
The 'copyControl', 'anonymize', and 'count' attributes SHOULD be included as modifiers of any of the child elements included in the <list> element of a resource list (e.g., attribute of the <entry> or <external> elements).
「copycontrol」、「匿名」、および「カウント」属性は、リソースリストの<リスト>要素に含まれる子要素のいずれかの修飾子として含める必要があります（例：<intrine>または<extrean>要素の属性）。
Section 5 describes the format of the 'copyControl', 'anonymize', and 'count' attributes. Implementations according to this specification MUST support this XML schema.
セクション5では、「Copycontrol」、「匿名」、および「カウント」属性の形式について説明します。この仕様に従って実装は、このXMLスキーマをサポートする必要があります。
Implementations that receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in recipient-history list or if it is included but tagged with a "bcc" copy control, then they SHOULD prevent the user from replying to all the recipients of the SIP request. This would allow the non-blind recipients to notice the existence of blind recipients in the original SIP request.
受信者の歴史リストを受け取る実装は、リストの内容に注意を払う必要があります。受信者のURIが受信者の歴史リストに含まれていない場合、または「BCC」コピーコントロールが含まれているがタグ付けされている場合、ユーザーがSIPリクエストのすべての受信者に返信できないようにする必要があります。これにより、非盲検の受信者は、元のSIPリクエストに盲目の受信者の存在に気付くことができます。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="copyControl">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
</xs:schema>
Figure 2: XML schema of the extension to the resource list format
図2：リソースリスト形式の拡張機能のXMLスキーマ
This section shows two examples of URI lists that can be included in SIP requests. The first example in Figure 3 shows a recipient list that the UAC sends to the URI-list server. This corresponds to a list that will be included in the flow F2 in Figure 1. The recipient list contains a flat list according to the resource list data format specified in RFC 4826 [RFC4826]. Each resource indicates the copy control of a resource with a 'copyControl' attribute. Some of the resources are also marked with the 'anonymize' attribute. This provides an indication to the URI-list service for not disclosing their URIs in a recipient-history list. The last two <entry> elements are marked with a 'copyControl' attribute of "bcc". This provides an indication to the URI-list server for removing these URIs in the recipient-history list.
このセクションでは、SIPリクエストに含めることができるURIリストの2つの例を示します。図3の最初の例は、UACがURI-Listサーバーに送信する受信者リストを示しています。これは、図1のフローF2に含まれるリストに対応します。受信者リストには、RFC 4826 [RFC4826]で指定されたリソースリストデータ形式に従ってフラットリストが含まれています。各リソースは、「Copycontrol」属性を持つリソースのコピー制御を示します。一部のリソースには、「匿名」属性がマークされています。これにより、URI-Listサービスへの兆候は、受信者の歴史リストにURIを開示しないことを示しています。最後の2つの<Entry>要素には、「BCC」の「コピーコントロール」属性がマークされています。これにより、レシピエント史リストでこれらのURIを削除するためのURI-Listサーバーへの兆候が提供されます。
<?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">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
Figure 3: Recipient list sent from the UAC to the URI-list server
図3：UACからURI-Listサーバーに送信された受信者リスト
Upon receipt of the SIP request containing the recipient list of Figure 3, the URI-list server creates a SIP request to each of the URIs listed in the recipient list (so, in our example, it creates 7 SIP requests). The URI-list server processes the recipient list and creates a recipient-history list that is included in each of the outgoing SIP requests. The process is as follows: the URI-list server creates a new recipient-history list, based on the recipient list, but with changes. First, it copies all the URIs (<entry> elements) marked with the "to" or "cc" 'copyControl' attributes, which do not contain an 'anonymize' attribute (or when the 'anonymize' attribute is set to "false"). Then all the URIs marked with a 'copyControl' attribute set to "to" and 'anonymize' attribute set to "true" are replaced with the SIP anonymous URI "sip:anonymous@anonymous.invalid". In this entry, the URI-list server also adds the original value of the 'copyControl' attribute ("to" in our example), and it adds a 'count' attribute containing the number of anonymous entries in this group ("2" in our example). Then the URI-list server does the same operation to the URIs tagged with the 'copyControl' attribute set to "cc" and 'anonymize' attribute set to "true", adding also the 'count' attribute containing the number of anonymous attributes in this group ("1" in the example). Last, the URI-list server removes all URIs marked with the "bcc" 'copyControl' attribute. The resulting recipient-history list is shown in Figure 4.
図3の受信者リストを含むSIPリクエストを受信すると、URI-Listサーバーは、受信者リストに記載されている各URIにSIPリクエストを作成します（したがって、この例では、7つのSIPリクエストを作成します）。URI-Listサーバーは、受信者リストを処理し、発信する各SIPリクエストに含まれる受信者歴史リストを作成します。プロセスは次のとおりです。URI-Listサーバーは、受信者リストに基づいて新しい受信者歴史リストを作成しますが、変更があります。まず、「to」または「cc」 'copycontrol'属性でマークされたすべてのuris（<intrent>要素）をコピーします。これらの属性は、「匿名」属性を含まない（または「匿名」属性が「fals」に設定されている場合"）。次に、「copycontrol」属性が「to」に設定された「anonymize」属性に「true」に設定されたすべてのurisが、sip anonymous uri "sip：anonymous@anonymous.invalid"に置き換えられます。このエントリでは、URI-Listサーバーは、「CopyControl」属性（「 "to" in eamse）の元の値も追加し、このグループの匿名エントリの数を含む「カウント」属性（ "2"を追加します。私たちの例で）。次に、uri-listサーバーは、「copycontrol」属性を「cc」および「匿名」属性を「true」に設定したurisに対して同じ操作を行い、匿名属性の数を含む「count」属性も追加します。このグループ（例の「1」）。最後に、URI-Listサーバーは、「BCC」「CopyControl」属性でマークされたすべてのURIを削除します。結果の受信者歴史リストを図4に示します。
<?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">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
Figure 4: Recipient-history list sent from the URI-list server to each recipient
図4：URI-Listサーバーから各受信者に送信された受信者の歴史リスト
A SIP UAC (User Agent Client) that composes a SIP request can include a URI list with the extensions specified in this document to indicate the list of intended recipients. On doing so, as specified in RFC 5363 [RFC5363], the UAC adds a Content-Disposition [RFC2183] header field set to the value 'recipient-list'. Typically UACs send these 'recipient-list' bodies to URI-list services (this corresponds to flow F1 in Figure 1). A body whose Content-Disposition type is 'recipient-list' contains a URI list that includes the intended recipients of the SIP request, something known throughout this document as a recipient list. The <entry> element in the URI list MAY also include a 'copyControl' and 'anonymize' attributes, as specified in Section 4.
SIPリクエストを構成するSIP UAC（ユーザーエージェントクライアント）は、このドキュメントで指定された拡張機能を備えたURIリストを含めることができ、意図した受信者のリストを示すことができます。そうすることで、RFC 5363 [RFC5363]で指定されているように、UACはコンテンツ偏見[RFC2183]ヘッダーフィールドを値「受信者リスト」に設定します。通常、UACはこれらの「受信者リスト」ボディをURIリストサービスに送信します（これは図1のフローF1に対応します）。コンテンツ拡張タイプが「受信者リスト」であるボディには、SIP要求の意図した受信者を含むURIリストが含まれています。このドキュメント全体で受信者リストとして知られています。URIリストの<Entry>要素には、セクション4で指定されているように、「Copycontrol」および「匿名」属性も含まれている場合があります。
To be able to inform intended recipients of who else is receiving a copy of the SIP request, we define a new mail disposition type to be included in a Content-Disposition [RFC2183] header field of a SIP request. The value of this new disposition type is 'recipient-list-history' and its purpose is to indicate a list of recipients that a SIP request was sent to, something known throughout this document as a recipient-history list. A body whose Content-Disposition type is 'recipient-list-history' contains a URI list with the visible (including anonymized) recipients of the SIP request. The <entry> element in the URI list MAY also include a 'copyControl' and 'count' attributes, as specified in Section 4.
他の誰がSIP要求のコピーを受け取っているかを意図した受信者に通知できるようにするために、SIPリクエストのコンテンツディスポジション[RFC2183]ヘッダーフィールドに含まれる新しいメール処分タイプを定義します。この新しい処分タイプの価値は「受信者リスト史」であり、その目的は、SIPリクエストが送信された受信者のリストを示すことです。コンテンツ拡張タイプが「レシピエントリストハイスト」であるボディには、SIPリクエストの目に見える（匿名化された）受信者を含むURIリストが含まれています。URIリストの<Entry>要素には、セクション4で指定されているように、「Copycontrol」および「Count」属性も含まれている場合があります。
On sending a SIP request that contains a recipient-history list, if the intended recipient does not support this specification, the SIP request should not fail. In order to ensure successful receipt of the SIP requests that include 'recipient-list-history' bodies, User Agents (such as URI-list servers) that build SIP requests with the Content-Disposition header field set to 'recipient-list-history' SHOULD add a "handling" parameter [RFC3204] set to "optional". Otherwise, the SIP request could fail and never be received by the intended recipient.
受信者の歴史リストを含むSIPリクエストを送信すると、意図した受信者がこの仕様をサポートしていない場合、SIPリクエストは失敗しません。「受信者リスト登録」ボディを含むSIPリクエストを成功させるために、Content-List-Historyに設定されたコンテンツディスポジションヘッダーフィールドを使用してSIPリクエストを構築するユーザーエージェント（URIリストサーバーなど）「オプション」に設定された「処理」パラメーター[RFC3204]を追加する必要があります。それ以外の場合、SIPリクエストが失敗し、意図した受信者が受信することはありません。
Even though "Message Body Handling in SIP" [SIP_BODY] mandates support for multipart bodies, legacy recipients may not support them. In such a case, if the request sent by the relay to the recipient needs to contain another body (e.g., a MESSAGE request carrying a message in its body), the relay will not be able to use this extension because the recipient would not be able to process a multipart body with the original body plus the 'recipient-list-history' body.
「SIPでのメッセージボディの取り扱い」[SIP_BODY]は、マルチパートボディのサポートを義務付けていますが、レガシーの受信者はそれらをサポートしない場合があります。そのような場合、受信者にリレーから送信されたリクエストが別のボディを封じ込める必要がある場合（たとえば、その本体にメッセージを伝えるメッセージ要求）、受信者がそうでないため、リレーはこの拡張機能を使用できません。元のボディと「レシピエントリスト史」ボディでマルチパートボディを処理できます。
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Implementations of this specification 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]は、SIP URIリストサービスに関連する問題について説明しています。この仕様の実装は、RFC 5363 [RFC5363]のセキュリティ関連のルールに従う必要があります。これらのルールには、オプトインリストとクライアントの必須認証と承認が含まれます。
User Agent Clients SHOULD NOT hand SIP requests containing URI-list services to unauthenticated and untrusted parties. This is to avoid man-in-the-middle attacks or acquiring URI lists for performing spam attacks.
ユーザーエージェントのクライアントは、URI-Listサービスを含むSIPリクエストを、無慈悲で信頼できないパーティーに渡すべきではありません。これは、中間の攻撃やスパム攻撃を実行するためのURIリストの取得を避けるためです。
URI lists may contain private information, such as SIP URIs. It is therefore not desirable that these URI lists are known by third parties. Eavesdroppers are able to watch URI lists contained in SIP requests unless the SIP message is sent over a secured channel, by using any of the available SIP mechanisms, such as Transport Layer Security (TLS) [RFC4346], or unless the URI-list body itself is encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED that URI-list bodies are encrypted with S/MIME [RFC3851] or that the SIP request is encrypted with TLS [RFC4346] or any other suitable encryption mechanism.
URIリストには、SIP URIなどの個人情報が含まれている場合があります。したがって、これらのURIリストが第三者によって知られていることは望ましくありません。EavesDroppersは、SIPメッセージがセキュリティで送信されない限り、SIPリクエストに含まれるURIリストを視聴できます。輸送層セキュリティ（TLS）[RFC4346]などの利用可能なSIPメカニズムのいずれかを使用して、またはURIリストの本体がない限り視聴できます。それ自体は、例えばS/MIME [RFC3851]で暗号化されています。したがって、URIリストボディはS/MIME [RFC3851]で暗号化されること、またはSIP要求がTLS [RFC4346]またはその他の適切な暗号化メカニズムで暗号化されることをお勧めします。
Note that this URI list does not indicate the actual participants in the session. It indicates only the URIs invited and that might accept the request. It does not assert that these parties actually exist, that they are reachable at the given URI, or that they have accepted the invitation. No inferences about billing should be made from this information. It is subject to spoofing by loading the list with falsified content.
このURIリストは、セッションの実際の参加者を示していないことに注意してください。招待されたURIのみを示し、リクエストを受け入れる可能性があります。これらの当事者が実際に存在すること、与えられたURIで到達可能であること、または招待状を受け入れたことを断言していません。この情報から請求に関する推論を行うべきではありません。リストに偽造コンテンツをロードすることにより、スプーフィングの対象となります。
Issuers of SIP request use the "bcc" copy control attribute described in Section 4 to facilitate sending SIP requests to recipients without revealing the URIs of one or more of the other recipients. Mishandling this use of "bcc" copy control has implications for confidential information that might be revealed, which could eventually lead to security problems through knowledge of even the existence of a particular URI. For example, if using the first method described in Section 4, where the "bcc" tagged URIs are removed from the recipient-history list, blind recipients have no explicit indication that they have been sent a blind copy of the SIP request, except insofar as their URI does not appear in the recipient-history list. Because of this, one of the blind URIs could potentially send a reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient. When the second method from Section 4 is used, the blind recipient's address appears in the recipient-history list of a separate copy of the list. If the "bcc" tagged URI sent contains all of the "bcc" tagged URIs, all of the "bcc" recipients will be seen by each "bcc" recipient. Even if a separate message is sent to each "bcc" recipient with only the individual's URI, implementations still need to be careful to process replies to the message as per Section 4 so as not to accidentally reveal the blind recipient to other recipients.
SIP要求の発行者は、セクション4で説明されている「BCC」コピー制御属性を使用して、他の1つ以上の受信者のURIを明らかにすることなく、SIPリクエストを受信者に送信することを容易にします。この「BCC」コピー制御の使用を誤って扱うことは、明らかにされる可能性のある機密情報に影響を与えます。たとえば、セクション4で説明されている最初の方法を使用して、「BCC」タグ付きURIが受信者歴史リストから削除されている場合、盲目の受信者は、SIPリクエストのブラインドコピーが送信されたという明示的な兆候はありません。彼らのURIは受信者の歴史リストには表示されないため。このため、盲目のウリスの1つは、表示されているすべての受信者に返信を送信する可能性があり、メッセージが盲目の受信者に送られたことを誤って明らかにすることができます。セクション4の2番目の方法が使用されると、盲目の受信者のアドレスがリストの個別のコピーの受信者歴史リストに表示されます。送信された「BCC」タグ付きURIに「BCC」というタグ付きURIがすべて含まれている場合、「BCC」の受信者はすべて、各「BCC」受信者によって見られます。個人のURIのみを持つ各「BCC」受信者に個別のメッセージが送信された場合でも、視覚障害者を他の受信者に誤って明らかにしないように、セクション4に従ってメッセージへの返信を慎重に処理するように実装する必要があります。
IANA has made registrations according to the following subsections: a new disposition type, a new XML namespace, and a new XML schema.
IANAは、次のサブセクションに従って登録を行いました。新しい処分タイプ、新しいXMLネームスペース、新しいXMLスキーマです。
Section 7 defines a new 'recipient-list-history' value of the Mail Content Disposition Values registry. This value has been registered in the IANA registry of Mail Content Disposition Values with the following registration data:
セクション7では、メールコンテンツ処分値レジストリの新しい「受信者リスト」値を定義します。この値は、次の登録データを使用して、メールコンテンツ処分値のIANAレジストリに登録されています。
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFC5364] |
| | URIs that indicates the | |
| | recipients of the request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Disposition Value
表1：「受信者リスト」の登録 'メールコンテンツ処分値
This section registers a new XML namespace in the IANA XML registry, as per the guidelines in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]のガイドラインに従って、IANA XMLレジストリの新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
登録者の連絡先：IETF Sipping Working Group（sipping@ietf.org）、Miguel Garcia-Martin（miguel.a.garcia@ericsson.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title>
</head>
<body>
<h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
RFC5364</a>.</p>
</body>
</html>
END
This section registers a new XML schema in the IANA XML registry per the procedures in RFC 3688 [RFC3688].
このセクションでは、RFC 3688 [RFC3688]の手順に従って、IANA XMLレジストリに新しいXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
登録者の連絡先：IETF Sipping Working Group（sipping@ietf.org）、Miguel Garcia-Martin（miguel.a.garcia@ericsson.com）。
The XML for this schema can be found as the sole content of Section 5.
このスキーマのXMLは、セクション5の唯一の内容として見つけることができます。
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris Newman for reviewing this document and providing helpful comments.
ディーン・ウィリス、ジャリ・ウルパレーネン、ペッカ・クーレ、佐藤、ブライアン・ローゼン、メアリー・バーンズ、ジェームズ・ポーク、ブライアン・E・カーペンター、クリス・ニューマンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年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.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M。、およびM. Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC3204、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826] Rosenberg、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.Roach、「セッション開始プロトコル（SIP）URI-List Servicesのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[RFC5366] Camarillo、G。およびA. Johnston、「セッション開始プロトコル（SIP）でリクエストコンテン付きリストを使用した会議設立」、RFC 5366、2008年10月。
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", RFC 5365, October 2008.
[RFC5365] Garcia-Martin、M。and G. Camarillo、「セッション開始プロトコル（SIP）の多反心のメッセージ要求」、RFC 5365、2008年10月。
[SIP_BODY] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", Work in Progress, August 2008.
[sip_body] Camarillo、G。、「セッション開始プロトコル（SIP）でのメッセージ本文処理」、2008年8月の作業。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
ミゲル・A・ガルシア・マルティン・エリクソン・デ・ロス・ポブラドス13マドリード28033スペイン
EMail: miguel.a.garcia@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。