RFC 5364 - Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists 日本語訳

URL : https://tools.ietf.org/html/rfc5364
タイトル : RFC 5364 - コピー制御を表現するための拡張マークアップ言語（XML）形式拡張子は、リソースリスト内の属性
翻訳編集 : 自動生成

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

1. Introduction

1. はじめに

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（Uniform Resource Identifier）のリストを搬送するための一般的なフレームワークを記述しています。具体的には、文書は、INVITEリクエスト[RFC5366]または複数の受信者のMESSAGEリクエスト[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リストサービスに共通することは、一般的にXMLリソースリスト[RFC4826]のように表現リソースの集合が含まれているSIPリクエストの存在です。リソースリストを運ぶSIPリクエストは、目的の受信者のリストを示し、URIリストサーバが受信した要求のいずれかで表示される、またはすることができ、同じSIPの受信者のリストを示すURIリストサーバが受信者に送信するリクエスト、それぞれに要求。

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リクエストを受信しているかどうかを決定するために、コピー制御属性が必要とされていますカーボンコピー。これは、送信者が「へ」、「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.

この文書アドレス「へ」、「CC」、または「BCC」受信者として受信者ごとにラベルを付けるコピー制御属性を供給するために、送信者を可能にするXMLリソースリスト[RFC4826]への拡張を提供することにより、この問題。この属性は、受信者がSIPリクエスト、カーボンコピー、またはブラインドカーボンコピーの1次コピーを受信しているかどうかを示します。また、我々はいくつかの受信者のURIは、他の受信者に開示されていないように、1つ以上のリソースは、匿名化されるべきであるとURIのリストに示すの機能を備えた送信者を提供しています。代わりに、これらのURIは、匿名のURIに置き換えられます。

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リストへの拡張を定義します。定義は第5節第6節で提供されたXMLスキーマは、この文書で定義された拡張子を持つURIリストの例を示します。第7節は、SIPメッセージでURIリストを運ぶの意味を説明します。

2. Terminology

2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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リストサービス：SIPアプリケーションサービスURIリストを含むSIP要求を受信し、リスト内の各URIに類似SIP要求を送信します。

Intended recipient: The intended final recipient of the request to be generated by URI-list service.

目的の受信者：URIリストサービスによって生成される要求の意図した最終受信者。

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リストサーバに送信する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リソースリスト：受信者の目に見えるリストを含むXMLリソースリスト（すなわち、それらの非匿名非BCC）。 URIリストサーバは、受信者リストに基づいて、このリストを作成し、それを各受信者に送信するSIPリクエストのそれぞれで、それを含んでいます。

3. Overview of Operation

操作の概要3。

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リストサーバは、特定の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リスト機構は、送信者がSIP要求の本体における受信者XMLリソースリスト[RFC4826]を含むことによって、SIP要求の複数のターゲットを指定することを可能にします。この受信者リストは、SIP要求（実際の手順は、方法特異的であり、この文書の範囲外）のターゲットURIを含みます。 URIはまた、コピー制御でマークすることができる各ターゲットは、受信者がSIPリクエストを受信したコピーのレベルを示すために属性。これは、「コピーコントロールCD」属性を持つURIリスト内の各URIを修飾送信者によって達成されます。「コピーコントロールCD」属性の利用可能な値は、（Eメールに類似）、「CC」「に」が含まれ、「BCC」。 URIリストサーバが各受信者に要求を拡大するとこれは第4節で詳しく説明され、URIリストサーバが送信者から受信した受信者リストに基づいて構築受信者履歴XMLリソースリストを含んでいます。受信者履歴XMLリソースリストは、各受信者に向けてURIリストサーバによって生成されたSIPリクエストに受信者リストを置き換えます。受信者リストからURIリストサーバにコピー「へ」と「CC」のコピー制御レベルでマークされ、受信者履歴リストにそれらを貼り付けているこれらのターゲット。「BCC」のアドレスを保存することができますが、URIリストサーバは、明示的に、それらのURIは、「BCC」のコピー制御でマークされた受信者履歴リストから除外し、それはSIPの受信者のURIと一致した場合にURIをタグ付け要求（これはセクション4で後述します）。受信者が受信者履歴XMLリソースリストを含むSIP要求を受信すると、彼は他の可視の受信者は、SIPリクエストのコピーを取得しているかを判断することができ、それらは「へ」または「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のための「コピーコントロールCD」属性に加えて、我々は「匿名」と呼ばれる第二ブール属性を定義します。 URIは、その属性でマークされたURIリストサーバを示すために、「匿名化」属性が受信者履歴XMLに匿名URIに置き換えられるとSIPリクエストの送信者は受信者のXMLリソースリストにURIをマークすることができますリソースリスト。これは、URIに開示されていない付加的な可視の受信者数の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リストサーバはグループ匿名化そのコピー制御レベル内でURIを匿名化し、単一の中のURI、および匿名化URIの数のカウントを提供することができます。このシナリオをサポートするために、我々は、受信者履歴XMLリソース・リストのURIに新しい「数」属性を定義します。構文的には任意のXMLリソースリスト内の任意のURIに「数」属性を追加することが可能であるものの、「数」属性のみ、匿名の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.

最初は、「匿名化」属性が「コピーコントロールCD」属性の「BCC」の値と重複していると考えてよいです。しかし、それらの間の違いがあります。送信者が受信者のXMLリソースリストの「BCC」の「コピーコントロールCD」属性でURIを修飾する場合は、URIリストサーバは、一般的に削除されます、そのURIの受信者履歴XMLリソースリスト（URIリストサーバがすることを決定しない限り、からそのURIが自身SIPリクエストの受信者）であるとき、「BCC」とマークされたURIを維持します。 SIPリクエストの受信者は、一つ以上の余分は「BCC」URIは、リクエストを受け取ったことを気付くことはありません。送信者が受信者のXMLリソースリストの「匿名化」属性でURIを修飾場合は、URIリストサーバは、受信者、履歴リストに匿名のものとURIに置き換えられます。 SIPリクエストの受信者が同じ要求の1つの以上の追加の受信者となっているが、そのURIは開示されていないことがわかります。

4. Extension to the Resource List Data Format

リソースリストのデータフォーマットへ4.拡張

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>要素に新しい「コピーコントロールCD」属性を定義します。「コピーコントロールCD」属性は、電子メールシステムの宛先アドレスのタイプと同じような意味を持っています。それは、「に」「CC」、および「BCC」の値を取ることができます。「コピーコントロールCD」属性の「へ」の値は、リソースがSIPリクエストの主要な受信者と見なされていることを示しています。「CC」の値は、リソースがSIP要求のカーボンコピーを受信することを示しています。「BCC」の値は、リソースがSIPリクエスト（すなわち、このURIをSIP要求の他の受信者に開示されていない）のブラインドカーボンコピーを受信することを示しています。デフォルトでは、「コピーコントロールCD」の値は、「BCC」です。それは、「コピーコントロールCD」が「BCC」に設定したかのように「コピーコントロールCD」属性が存在しないことは、治療しなければならない、です。

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リストサーバは、「BCC」「コピーコントロールCD」は、ルートのSIPリクエストに属性を使用します。また、URIリストサーバは、これらのURIの治療に関して[RFC2822]のシステムを電子メールで送信するために同じように動作し、彼らは治療の二つの方法を持っているので、「BCC」のURIをマークし、「BCC」のコピーコントロールの付きました。 URIリストサーバは、次の2つのいずれかの方法でこれらの「BCC」とマークされたURIを扱わなければなりません。

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リストサーバは、受信者、履歴リストで「BCC」のコピーコントロールの付いたすべてのURIを削除する必要があります。このメカニズムは、URIリストサーバは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リストサーバは、受信者（もしあれば）を識別し、残りのURIは、「BCC」のコピーコントロールが付いて削除しなければならない受信者履歴リストURIで「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]の<entry>要素に含めることができます。「真」の値に設定した場合、それはすなわち、recipient-でそれが偽作る（受信者に送信されたURIリストにURI自体を開示するが、代わりにURIを匿名化しないためのURIリストサーバに指示を提供します歴史XMLリソースリスト）。 URIリストサーバは、SIPリクエストをルーティングするための「匿名化」属性でタグ付けされたURIを使用することができますが、SIP URIに変換する必要があります：受信者履歴リストで「一口anonymous@anonymous.invalid」。「匿名化」属性のデフォルト値は「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リストサーバが重複URIエントリが「コピーコントロールCD」属性の同じまたは異なる値でタグ付けされているリソースリストで重複同じURIエントリを、遭遇する機会があります。リソースリストの重複URIを正当化する合理的な使用法はありません。したがって、これは誤りであると考えられます。 URIリストサーバは、同じ目的の受信者に同じSIPリクエストの重複コピーを送るべきではありません。ケースでURIリストサーバがリソースリストに重複し、同じURIエントリに遭遇し、その目的の受信者に高々要求の単一のコピーを送信する必要があります。重複URIエントリの各セットについて、URIリストサーバは、同じ目的の受信者のための「コピーコントロールCD」属性の最も高い優先順位値を選択する必要があります。「コピーコントロールCD」属性の値の優先順位は次のとおりです。「へ」、「CC」、および「BCC」。 URIリストサーバが目的の受信者の「コピーコントロールCD」属性の値を選択すると、URIリストサーバは、要求の処理を続行することができます。

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".

URIの処理は、「BCC」の値に設定「コピーコントロールCD」属性は、「匿名化」属性よりも優先しているとタグ付けされています。 URIの「コピーコントロールCD」が「BCC」に設定されている場合はこのように、URIリストサーバは、受信者、履歴リストから、そのURIを削除する必要がありますし、「匿名」属性は無視されます。そのため、属性が「へ」または「CC」の「コピーコントロールCD」でタグ付けされたそれらのURIに対してのみ有効です「匿名」。

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]の<entry>要素に含めることができます。これは、同じURIの数を提供します。典型的には、求めるUACによって作成された受信者リストは、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).

子要素のいずれかの修飾子がリソースリストの<リスト>要素の<entry>の（例えば、属性または<外部>要素に含まれる「コピーコントロールCD」、「匿名化」、および「カウントが」属性が含まれるべきです）。

Section 5 describes the format of the 'copyControl', 'anonymize', and 'count' attributes. Implementations according to this specification MUST support this XML schema.

第5節では、「コピーコントロールCD」、「匿名化」、および「数」の形式について説明します属性。この仕様に従った実装では、この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リクエストに盲目の受取人の存在に気づくことができるでしょう。

5. XML Schema

5. XMLスキーマ

<?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">

<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：コピーコントロールCD" のxmlns = "壷：IETF：のparams：XML：NS：コピーコントロールCD "のxmlns：RLS =" 壷：IETF：のparams：XML：NS：リソース・リスト」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>

       <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：インポートの名前空間= "壷：IETF：のparams：XML：NS：リソース・リスト" のschemaLocation = "壷：IETF：のparams：XML：スキーマ：リソース・リスト" />

<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：属性名= "コピーコントロールCD"> <XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "と" /> <XS：列挙値= "CC" /> < XS：列挙値= "BCC" /> </ XS：制限> </ XS：単純> </ XS：属性>

<xs:attribute name="anonymize" type="xs:boolean" default="false"/> <xs:attribute name="count" type="xs:nonNegativeInteger" default="1"/>

<XS：属性名= "匿名" タイプ= "XS：ブール" デフォルト= "false" に/> <XS：属性名= "数" タイプ= "XS：NonNegativeIntegerの" デフォルト= "1" />

</xs:schema>

</ XS：スキーマ>

Figure 2: XML schema of the extension to the resource list format

図2：リソース・リスト形式の拡張のXMLスキーマ

6. Examples

6.例

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の第1の例では、UACは、URIリストサーバに送信する受信者のリストを示しています。これは、受信者リストは、RFC 4826 [RFC4826]で指定されたリソースリストデータフォーマットに従ってフラットリストが含まれ、図1のフローF2に含まれるリストに相当します。各リソースには、「コピーコントロールCD」属性を持つリソースのコピー制御を示しています。リソースの一部は、「匿名化」属性でマークされています。これは、受信者、履歴リストにそのURIを開示しないためのURIリストサービスに指示を与えます。最後の二つの<entry>要素は、「BCC」の「コピーコントロールCD」属性でマークされています。これは、受信者、履歴リストにこれらのURIを除去するためのURIリストサーバに指示を提供します。

<?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>

<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CP = "壷：IETF：のparams：XML ：NS：コピーコントロールCD "> <リスト> <エントリーのURI =" SIP：bill@example.com "CP：コピーコントロールCD = "へ"/> <エントリURI = "SIP：randy@example.net" CP：コピーコントロールCD =" へ"CP：匿名=" 真 "/> <エントリURI =" SIP：eddy@example.com "CP：コピーコントロールCD = "と" CP：匿名= "真"/> <エントリURI =" 一口例：@ジョー。 ORG "CP：コピーコントロールCD = "CC"/> <エントリURI = "SIP：carol@example.net" CP：コピーコントロールCD = "CC" CP：匿名= "真"/> <エントリURI =" 一口：テッド例@ .NETの」CP：コピーコントロールCD = "BCC" /> <エントリURI = "SIP：andy@example.com" CP：コピーコントロールCD = "BCC" /> </リスト> </資源リスト>

Figure 3: Recipient list sent from the UAC to the URI-list server

図3：URIリストサーバにUACから送信された受信者リスト

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リストサーバは、受信者リストにリストされたURIのそれぞれにSIPリクエストを生成する（したがって、この例では、7つのSIPリクエストを作成します）。 URIリストサーバは、受信者リストを処理し、発信SIP要求のそれぞれに含まれている受信者、履歴リストを作成します。しかし、変更と、URIリストサーバは、受信者リストに基づいて、新しい受信者履歴のリストを作成します。次のようにプロセスがあります。すべてのURI（<エントリー>要素）は「匿名」属性（または時に「匿名化」属性をfalse」に設定されているが含まれていない「と」または「CC」「コピーコントロールCDの属性でマークまず、それをコピー「）。「：anonymous@anonymous.invalid一口」その後、すべてのURIは、と「真」SIP匿名URIに置き換えられるように設定属性を「匿名化」「する」に設定し「コピーコントロールCD」属性でマークされました。このエントリでは、URIリストサーバは、「コピーコントロールCD」属性（「へ」私たちの例では）の元の値を追加し、それが（「2」このグループに匿名のエントリ数を含む「数」属性を追加します私たちの例では）。そして、URIリストサーバは、URIに同じ操作はまた、匿名の属性の数を含む「数」属性を追加し、「CC」と「真」に設定し「匿名化」属性に設定「コピーコントロールCD」属性でタグ付けされませんこのグループ（この例では「1」）。最後に、URIリストサーバは、「BCC」「コピーコントロールCD」属性でマークされたすべての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>

<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CP = "壷：IETF：のparams：XML ：NS：コピーコントロールCD "> <リスト> <エントリーのURI =" SIP：bill@example.com "CP：コピーコントロールCD = "へ：anonymous@anonymous.invalid "コピーコントロールCD = CP""/> <エントリのURIは=" 一口に"CP：カウント=" 2 "/> <エントリURI =" SIP：joe@example.org "CP：コピーコントロールCD = "CC"/> <エントリのURIは= "SIP：anonymous@anonymous.invalid" CP：コピーコントロールCD =" ccの」CP：カウント= "1" /> </リスト> </資源リスト>

Figure 4: Recipient-history list sent from the URI-list server to each recipient

図4：各受信者にURIリストサーバから送信された受信者の履歴リスト

7. Carrying URI Lists in SIP

SIP内のURIリストを運ぶ7

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（これは図1のF1を流れに相当する）URIリストサービスにこれらの「受信者リスト」体を送ります。そのコンテンツディスポジションタイプのボディには、「受信者リスト」は、受信者リストとして、この文書全体で知られている何かをSIPリクエストの受信者が含まれるURIのリストが含まれています。第4節で指定されたURIリスト内の<entry>要素は、「コピーコントロールCD」と「匿名」の属性を含むことができます。

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リストを含んでいます。第4節で指定されたURIリスト内の<entry>要素は、「コピーコントロールCD」と「回数」の属性を含むことができます。

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要求は失敗してはいけません。受信者リスト履歴」へのContent-Dispositionヘッダーフィールドが設定されたSIPリクエストを構築する「受信者リスト履歴の体（例えば、URIリストサーバなど）ユーザエージェントを含め、SIPリクエストの受信に成功したことを確実にするために、 "『オプション』に設定し、『取り扱い』のパラメータ[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]義務がマルチパートの体のサポートにもかかわらず、従来の受信者は、それらをサポートしない場合があります。受信者にリレーによって送信された要求は、別のボディ（例えば、その本体にメッセージを運ぶMESSAGEリクエスト）が含まれてする必要がある場合、受信者はではないので、そのような場合には、リレーはこの拡張機能を使用することができませんオリジナルボディプラス「受信者リスト履歴の体とマルチボディを処理することができます。

8. Security Considerations

8.セキュリティの考慮事項

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]はURIリストサービスをSIPに関連する問題について説明します。この仕様の実装は、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リストサービスを含む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のリストが第三者に知られていることが望ましいではありません。 SIPメッセージは、このようなトランスポート層セキュリティ（TLS）として入手可能なSIPメカニズム、[RFC4346]のいずれかを使用することによって、またはURIリスト本体ない限り、セキュアチャネルを介して送信されていない限り、盗聴者は、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リクエストの発行者は、他の受信者の一つ以上のURIを明らかにすることなく受信者にSIPリクエストを送信容易にするために、第4節で説明した「BCC」のコピー制御属性を使用します。「BCC」のコピー制御のこの使用を誤った取り扱いは、最終的には、特定のURIの存在すらの知識によってセキュリティ上の問題につながる可能性が明らかにされるかもしれない機密情報に影響を持っています。例えば、「BCC」URIは受信者履歴リストから削除されタグ付けされたセクション4で説明した第1の方法を使用する場合、ブラインド受信者は、彼らが除き、SIP要求のブラインドコピーを送信されたことを明示的な指示を与えない限りそのURIは、受信者、履歴リストには表示されませんよう。このため、ブラインドのURIの一つは、潜在的に示したすべての受信者に返信すると、誤ったメッセージがブラインド受信者に行ったことを明らかにできました。第4節から第2の方法が使用されている場合は、ブラインド受信者のアドレスは、リストの別のコピーの受信者履歴リストに表示されます。「BCC」タグの付いたURIは、「BCC」のURIをタグ付きのすべてが含まれて送信されている場合、「BCC」のすべての受信者は、それぞれ「BCC」の受信者によって見られます。個別のメッセージは個人のみのURIと、各「BCC」の受信者に送信された場合でも、実装はまだ誤って他の受信者にブラインド受信者を明らかにしないように第4節ごとにメッセージへの返信を処理するのに注意する必要があります。

9. IANA Considerations

9. IANAの考慮事項

IANA has made registrations according to the following subsections: a new disposition type, a new XML namespace, and a new XML schema.

新しい気質のタイプ、新しいXML名前空間、および新しいXMLスキーマ：IANAは以下のサブセクションに従って登録を行っています。

9.1. Disposition Type Registration

9.1. 処分タイプ登録

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：「受信者リスト履歴のメールコンテンツ処分値の登録

9.2. XML Namespace Registration

9.2. XML名前空間の登録

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

URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：コピーコントロールCD

Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).

登録者連絡先：IETF SIPPINGワーキンググループ（sipping@ietf.org）、ミゲル・ガルシア・マーチン（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

<H2> URN：IETF：のparams：XML：NS：コピーコントロールCD </ H2> <P>を参照してください。<a href="http://www.rfc-editor.org/rfc/rfc5364.txt"> RFC5364 </ A >。</ P> </ body> </ html>このEND

9.3. XML Schema Registration

9.3. XML Schemaの登録

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

URI：URN：IETF：のparams：XML：スキーマ：コピーコントロールCD

Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).

登録者連絡先：IETF SIPPINGワーキンググループ（sipping@ietf.org）、ミゲル・ガルシア・マーチン（miguel.a.garcia@ericsson.com）。

The XML for this schema can be found as the sole content of Section 5.

このスキーマのためのXMLは、第5節の唯一の内容として求めることができます。

10. Acknowledgments

10.謝辞

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.

このドキュメントを再検討し、有益なコメントを提供するためのディーン・ウィリス、ヤリUrpalainen、ペッカKuure、敦佐藤、ブライアン・ローゼン、メアリー・バーンズ、ジェームズ・ポーク、ブライアンE.カーペンター、そしてクリス・ニューマンに感謝します。

11. References

11.参考文献

11.1. Normative References

11.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月。

[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月。

[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.、 "/セキュア多目的インターネットメール拡張（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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。

[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リストサービスのためのフレームワークとセキュリティの考慮事項」。

11.2. Informative References

11.2. 参考文献

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[RFC2822]レズニック、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]キャマリロ、G.とA.ジョンストン、 "会議の設立セッション開始プロトコル（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]ガルシア・マーチン、M.およびG.カマリロ、RFC 5365、2008年10月「セッション開始プロトコル（SIP）における複数の受信者のメッセージ要求」。

[SIP_BODY] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", Work in Progress, August 2008.

[SIP_BODY]カマリロ、G.、進歩、2008年8月の作業「メッセージ本文は、セッション開始プロトコル（SIP）での取り扱い」。

Authors' Addresses

著者のアドレス

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

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド

EMail: Gonzalo.Camarillo@ericsson.com

メールアドレス：Gonzalo.Camarillo@ericsson.com

Full Copyright Statement

完全な著作権声明

著作権（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に情報を記述してください。