Network Working Group M. Garcia-Martin
Request for Comments: 5365 G. Camarillo
Category: Standards Track Ericsson
October 2008
Multiple-Recipient MESSAGE Requests in
the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list.
この文書は、SIPユーザエージェントクライアント（UAC）は、SIP URIリスト（統一資源識別子リスト）サービスを使用することにより、目的地のセットにSIPのMESSAGEリクエストを送信することを可能にするメカニズムを指定します。 UACは、リストに含まれるURIの各々のペイロードを含むMESSAGE要求を送信するMESSAGE URIリストサービスのURIリストとともにペイロードを含むSIPメッセージ要求を送信します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI-List Document . . . . . . . . . . . . . . . . . . . . . . 5
5. Option-Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Procedures at the User Agent Client . . . . . . . . . . . . . 6
7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 7
7.1. Determining the Intended Recipient . . . . . . . . . . . . 8
7.2. Creating an Outgoing MESSAGE Request . . . . . . . . . . . 8
7.3. Composing Bodies in the Outgoing MESSAGE Request . . . . . 10
8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 11
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
RFC 3261 (SIP) [RFC3261] is extended by RFC 3248 [RFC3428] to carry instant messages in MESSAGE requests. SIP-based messaging, as described in RFC 3428 [RFC3428], does not provide a mechanism to send the same request to multiple recipients or replying to all recipients of a SIP MESSAGE request. This memo addresses these functions.
RFC 3261（SIP）[RFC3261]はMESSAGEリクエストにインスタントメッセージを運ぶためにRFC 3248 [RFC3428]によって拡張されます。 RFC 3428 [RFC3428]に記載されているように、メッセージをSIPベースの、同一の複数の受信者への要求またはSIP MESSAGE要求のすべての受信者に返信を送るためのメカニズムを提供しません。このメモは、これらの機能に対応しています。
A first requirement can be expressed as:
最初の要件は、次のように表すことができます。
REQ-1: It must be possible for a user to send an instant message request to an ad hoc group, where the identities of the recipients are carried in the message itself.
REQ-1：ユーザーは、受信者の身元がメッセージ自体に運ばれるアドホックグループにインスタントメッセージリクエストを送信することが可能でなければなりません。
One possibility to fulfill the above requirement is to establish a session of instant messages with an instant messaging conference server, and exchange the messages, for example, using MSRP (Message Session Relay Protocol) [RFC4975]. While this option seems to be reasonable in many cases, in other situations the sending user just wants to send a small pager-mode instant message to an ad hoc group without the burden of setting up a session. This document focuses on sending a pager-mode instant message to a number of intended recipients.
上記の要件を満たすための一つの可能性は、MSRP（メッセージセッションリレープロトコル）[RFC4975]を使用して、例えば、インスタントメッセージング、会議サーバとインスタントメッセージのセッションを確立し、メッセージを交換することです。このオプションは、多くの場合、合理的であるように思われるが、他の状況では、送信者は、単にセッションを設定する負担なしにアドホックグループに小さなポケットベルモードインスタントメッセージを送信したいです。この文書では、目的の受信者の数にページャモードインスタントメッセージを送信することに焦点を当てています。
To meet the requirement with a pager-mode instant message, we allow SIP MESSAGE requests carry recipient-list bodies, i.e., URI lists in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363]. A SIP MESSAGE URI-list service, which is a specialized application service, receives the request and sends a MESSAGE request including the received payload to each of the URIs in the list. Each of these MESSAGE requests contains a copy of the body included in the original MESSAGE request.
指定されたページャモードインスタントメッセージでの要件を満たすために、我々はすなわち、SIPメッセージ要求が受信者リストの遺体を運ぶことができ、コンテンツディスポジション（RFC 2183）[RFC2183]の体の部分でURIリストは、「受信者リスト」ですRFC 5363 [RFC5363]インチ専用アプリケーションサービスであるSIPメッセージURIリストサービスは、要求を受信し、リスト内のURIの各々に受信したペイロードを含むメッセージ要求を送信します。これらMESSAGE要求のそれぞれには、元のメッセージ要求に含まれる体のコピーが含まれています。
A second requirement addresses the "Reply-To-All" functionality:
第二の要件は、「返信対全」機能に対応しています
REQ-2: It MUST be possible for the recipient of a group instant message to send a message to all other participants that received the same group instant message (i.e., Reply-To-All).
REQ-2：それは（すなわち、返信対全）同じグループインスタントメッセージを受信したすべての他の参加者にメッセージを送信するグループインスタントメッセージの受信者のために可能でなければなりません。
To meet this requirement, we provide a mechanism whereby the MESSAGE URI-list service also includes a URI list in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364]. The 'recipient-list-history' body is sent along with the instant message payload in each of the instant messages sent to the recipients.
この要件を満たすために、我々は、[RFC 5364で指定されているようMESSAGE URI - リストサービスはまた、そのコンテンツディスポジション（RFC 2183）[RFC2183]のボディパーツにURIリストを含んするメカニズムは、「受信者リスト履歴」で提供しますRFC5364]。 「受信者リスト履歴の体は、受信者に送信されたインスタントメッセージの各インスタントメッセージペイロードと一緒に送信されます。
The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE URI-list service needs to be configured with the SIP URI of the service that provides the functionality. Discovering and provisioning of this URI to the UAC is outside the scope of this document.
MESSAGE URI - リストサービスへのMESSAGEリクエストを送信するユーザエージェントクライアント（UAC）は、機能を提供するサービスのSIP URIを設定する必要があります。 UACに発見し、この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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載され、対応する実装の要求レベルを示すものと解釈されます。
This document reuses the following terminology defined in RFC 3261 [RFC3261]:
この文書は、RFC 3261 [RFC3261]で定義された以下の用語を再利用します。
o Address-of-Record (AOR)
Oアドレス・オブ・レコード（AOR）
o User Agent (UA)
Oユーザーエージェント（UA）
o User Agent Client (UAC)
Oユーザエージェントクライアント（UAC）
o User Agent Server (UAS)
Oユーザエージェントサーバ（UAS）
This document defines the following new terms:
このドキュメントでは、次の新しい用語を定義しています。
MESSAGE URI-list service: A specialized URI-list service that receives a MESSAGE request with a URI list and sends a similar MESSAGE request to each URI in the list. In this context, similar indicates that some SIP header fields can change, but the MESSAGE URI-list service will not change the instant message payload. MESSAGE URI-list services behave effectively as specialized B2BUAs (Back-to-Back-User-Agents). A server providing MESSAGE URI-list services can also offer URI-list services for other methods, although this functionality is outside the scope of this document. In this document, we only discuss MESSAGE URI-list services.
MESSAGE URI - リストサービス：URIリストとMESSAGE要求を受信して、リスト内の各URIに似MESSAGEリクエストを送信し、特殊なURIリストサービス。この文脈において、同様にいくつかのSIPヘッダフィールドが変更できることを示しているが、メッセージURIリストサービスは、インスタントメッセージのペイロードを変更しないであろう。 MESSAGE URI - リストサービスは、専門型B2BUA（バックツーバック・ユーザ・エージェント）として効果的に振る舞います。この機能は、このドキュメントの範囲外ですが、MESSAGE URI - リストサービスを提供するサーバも、他の方法のためのURIリストサービスを提供することができます。この文書では、我々は唯一のMESSAGE URI - リストサービスを議論します。
Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates and addresses to a MESSAGE URI-list service. Besides the regular instant message payload, an incoming MESSAGE request contains a URI list.
受信メッセージの要求：UACはMESSAGE URI - リストサービスに作成されたアドレスのSIP MESSAGE要求。通常のインスタントメッセージペイロードのほかに、受信メッセージの要求は、URIのリストが含まれています。
Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI-list service creates and addresses to a UAS (User Agent Server). It contains the regular instant message payload.
送信メッセージの要求：MESSAGE URI - リストサービスは、UAS（ユーザエージェントサーバ）に作成され、アドレスのSIP MESSAGE要求。これは、通常のインスタントメッセージのペイロードが含まれています。
Intended recipient: The intended final recipient of the request to be generated by MESSAGE URI-list service.
目的の受信者：MESSAGE URI - リストサービスによって生成される要求の意図した最終受信者。
Reply-To-All: The ability of an intended recipient to receive a MESSAGE request that includes the payload and the list of recipients, and compose and send a MESSAGE request to the sender and the rest of the recipients. The replying entity can use a MESSAGE URI-list service if one is at its disposal or can create a sequence of regular single-recipient MESSAGE requests to each SIP AOR.
返信対全：ペイロードと受信者のリストを含むメッセージ要求を受信し、構成し、送信者と受信者の残りの部分にMESSAGEリクエストを送信するために意図された受信者の能力を。 1は、その処分であるか、各SIP AORへの定期的なシングルの受信者のMESSAGE要求のシーケンスを作成することができれば返信エンティティは、MESSAGE URI - リストサービスを使用することができます。
A UAC creates a MESSAGE request that contains a multipart body including a list of URIs (intended recipients) and an instant message. The list of URIs is formatted according to the resource list document format specified in RFC 4826 [RFC4826] and extended with the attributes defined in RFC 5364 [RFC5364]. The UAC sends this MESSAGE request to the MESSAGE URI-list service. On reception of this incoming MESSAGE request, the MESSAGE URI-list service creates a MESSAGE request per intended recipient (listed in the URI list) and copies the instant message payload to each of those MESSAGES. The MESSAGE URI-list service also manipulates the XML resource list according to the procedures indicated in RFC 5364 [RFC5364], and attaches the result to each of the MESSAGE requests, along with the instant message payload. Then the MESSAGE URI-list service sends each of the created outgoing MESSAGE request to the respective receiver.
UACは、URIのリスト（受信者）およびインスタントメッセージを含むマルチボディを含むメッセージ要求を作成します。 URIのリストは、RFC 4826 [RFC4826]で指定され、RFC 5364 [RFC5364]で定義された属性で拡張リソースリスト文書フォーマットに従ってフォーマットされています。 UACはMESSAGE URI - リストサービスにこのMESSAGEリクエストを送信します。この着信メッセージ要求を受信すると、MESSAGE URIリストサービスは、メッセージ（URIリストに記載されている）意図された受取人あたり要求コピーそれらのメッセージのそれぞれにインスタントメッセージペイロードを作成します。 MESSAGE URIリストサービスは、RFC 5364 [RFC5364]に示されている手順に従ってXMLリソースリストを操作し、そしてインスタントメッセージペイロードと共に、MESSAGEリクエストのそれぞれに結果を付加します。そして、MESSAGE URI - リストサービスは、それぞれの受信機に作成された送信メッセージの要求のそれぞれを送信します。
The MESSAGE URI-list mechanism allows a sender to specify multiple targets for a MESSAGE request by including an XML resource list document according to RFC 4826 [RFC4826] in the body of the MESSAGE request extended with the attributes defined in RFC 5364 [RFC5364]. This resource list, whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363], includes the URIs of the targets. Each target URI may also be marked to indicate in what role the URI-list service will place the target (e.g., "to", "cc", or "bcc"), and whether the target URI is expected to be anonymized or not, according to the procedures described in RFC 5364 [RFC5364]. When the MESSAGE URI-list server expands the MESSAGE request to each recipient, it includes (along with the instant message payload) a new URI list (based on the received one), whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364]. This new URI list includes the list of non-anonymous "to" and "cc" targets, allowing recipients both to get knowledge of other recipients and to reply to them.
MESSAGE URIリスト機構は、送信者は、RFC 5364 [RFC5364]で定義された属性で拡張MESSAGE要求の本体におけるRFC 4826 [RFC4826]に従ってXMLリソースリスト文書を含めることによって、MESSAGEリクエストの複数のターゲットを指定することを可能にします。そのコンテンツの廃棄（RFC 2183）、このリソースリストは、[RFC2183]は、RFC 5363 [RFC5363]で指定されるように、「受信者リスト」であり、ターゲットのURIを含みます。各URIはまた、URIリストサービスは、（例えば、「に」「CC」、または「BCC」）ターゲットが配置されますどのような役割で示すようにマークすることができるターゲット、およびターゲットURIを匿名化することが期待されているかどうか、RFC 5364 [RFC5364]に記載の手順に従って。そのコンテンツの廃棄（RFC 2183）[RFC2183] MESSAGE URIリストサーバは、各受信者にメッセージ要求を展開し、それは（インスタントメッセージ・ペイロードと共に）は、（受信した1つに基づいて）新しいURIリストは、 'の場合受信者リスト履歴」、RFC 5364 [RFC5364]で指定されています。この新しいURIリストには、受信者の両方が、他の受信者の知識を得るために、それらに返信することができ、「への」非匿名と「CC」ターゲットのリストを含んでいます。
As described in RFC 5363 [RFC5363], specifications of individual URI-list services, like the MESSAGE URI-list service described here, need to specify a default format for 'recipient-list' bodies used within the particular service.
RFC 5363 [RFC5363]で説明したように、個々のURIリストサービスの仕様は、ここで説明MESSAGE URI - リストサービスのように、特定のサービス内で使用される「受信者リストの体のデフォルト形式を指定する必要があります。
The default format for 'recipient-list' bodies for MESSAGE URI-list services is the resource list document specified in RFC 4826 [RFC4826] extended with the copy control attributes [RFC5364]. UACs and MESSAGE URI-list services handling 'recipient-list' bodies MUST support both of these formats and MAY support other formats.
MESSAGE URI - リストサービスのための「受信者リストの体のデフォルトの形式は、コピー制御属性[RFC5364]で拡張RFC 4826 [RFC4826]で指定されたリソースリストドキュメントです。 「受信者リストの体を扱う求めるUACとMESSAGE URI - リストサービスは、これらのフォーマットの両方をサポートしなければならないし、他のフォーマットをサポートするかもしれません。
As described in RFC 5364 [RFC5364], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the recipient will get the MESSAGE request. Additionally, URIs can be tagged with the 'anonymize' attribute to prevent that the MESSAGE URI-list server discloses the target URI in a URI list.
RFC 5364に[RFC5364]を説明したように、各URIは受信者がメッセージ要求を取得するする役割を示し、「に」、「CC」のいずれかに設定「コピーコントロールCD」属性、又は「BCC」でタグ付けすることができます。また、URIはMESSAGE URI - リストサーバは、URIリスト内のターゲットURIを開示することを防ぐために、「匿名化」属性でタグ付けすることができます。
Additionally, RFC 5364 [RFC5364] defines a 'recipient-list-history' body that contains the list of intended recipients. The default format for 'recipient-list-history' bodies for MESSAGE URI-list services is also the resource list document specified in RFC 4826 [RFC4826] extended with the copy control attributes [RFC5364]. MESSAGE URI-list services MUST support both of these formats; UASs MAY support these formats. MESSAGE URI-list servers and UASs MAY support other formats.
また、RFC 5364 [RFC5364]は意図した受信者のリストが含まれている「受信者リスト履歴の体を定義します。 MESSAGE URI - リストサービスのための「受信者リスト履歴の体のデフォルトフォーマットは、コピー制御属性[RFC5364]で拡張RFC 4826で指定されたリソースリストドキュメント[RFC4826]です。 MESSAGE URI - リストサービスは、これらのフォーマットの両方をサポートしなければなりません。 UASは、これらのフォーマットをサポートするかもしれません。 MESSAGE URIリストサーバとのUASは、他のフォーマットをサポートするかもしれません。
The resource list document specified in RFC 4826 [RFC4826] provides a number of features that are not needed by the MESSAGE URI-list service defined in this document. The MESSAGE URI-list service needs to transfer a simple flat list of URIs between a UAC and the MESSAGE URI-list server and between the MESSAGE URI-list server and the UAS. The service does not need hierarchical lists or the ability to include entries by reference relative to the Extensible Configuration Access Protocol (XCAP) [RFC4825] root URI. Therefore, the MESSAGE URI-list service specified herein only uses flat resource lists documents that do not contain relative references.
RFC 4826 [RFC4826]で指定されたリソースリスト文書は、この文書で定義されたMESSAGE URI - リストサービスによって必要とされていない機能を多数提供します。 MESSAGE URI - リストサービスは、UACとMESSAGE URI - リストサーバ間とMESSAGE URI - リストサーバとUAS間のURIのシンプルなフラットリストを転送する必要があります。サービスは、階層リストまたは拡張コンフィギュレーションアクセスプロトコル（XCAP）[RFC4825]ルートURIを参照相対でエントリを含める機能を必要としません。したがって、本明細書中にのみ指定MESSAGE URI - リストサービスは、相対参照が含まれていないフラットなリソースリスト文書を使用しています。
This document defines the 'recipient-list-message' option-tag for use in the Require and Supported SIP header fields.
この文書では、必要とし、サポートSIPヘッダフィールドで使用するための「受信者リストメッセージ」オプションタグを定義します。
This option-tag is used to ensure that a server can process the 'recipient-list' body used in a MESSAGE request. It also provides a mechanism to discover the capability of the server in responses to OPTIONS requests.
このオプションタグは、サーバがMESSAGE要求で使用される「受信者リストの体を処理できることを保証するために使用されます。また、OPTIONS要求への応答で、サーバーの機能を発見するためのメカニズムを提供します。
Section 6 provides normative procedures for the usage of this option tag.
第6節では、このオプションタグの使用のための規範的な手順を説明します。
A UAC that wants to create a multiple-recipient MESSAGE request creates a MESSAGE request that MUST be formatted according to RFC 3428 [RFC3428] Section 4. The UAC populates the Request-URI with the SIP or SIPS URI of the MESSAGE URI-list service. In addition to the regular instant message body, the UAC adds a recipient-list body whose Content-Disposition type is 'recipient-list', specified in RFC 5363 [RFC5363]. This body contains a URI list with the recipients of the MESSAGE. Target URIs in this body MAY also be tagged with the 'copyControl' and 'anonymize' attributes specified in RFC 5364 [RFC5364]. The UAC MUST also include the 'recipient-list-message' option-tag, defined in Section 5, in a Require header field.
複数の受信者MESSAGE要求を作成することを望むUACは、[RFC3428]セクション4 UACは、SIPでのRequest-URIを移入またはMESSAGE URIリストサービスのURIをSIPS RFC 3428に従ってフォーマットする必要がありMESSAGE要求を作成します。定期的なインスタントメッセージ本体に加えて、UACは、そのコンテンツの廃棄タイプ「受取人リスト」は、RFC 5363 [RFC5363]で指定された受信者リスト体を追加します。このボディは、メッセージの受信者とURIのリストが含まれています。この体内のターゲットURIはまた、「コピーコントロールCD」と「匿名」でタグ付けすることができるが、RFC 5364 [RFC5364]で指定された属性。 UACはまた、Requireヘッダーフィールドに、セクション5で定義された「受信者リストメッセージ」オプションタグを含める必要があります。
UACs generating MESSAGE requests that carry recipient-list bodies, as described in previous sections, MUST include this option-tag in a Require header field. UAs that are able to receive and process MESSAGEs with a recipient-list body, as described in previous sections, SHOULD include this option-tag in a Supported header field when responding to OPTIONS requests.
受信者リスト体を運ぶMESSAGEリクエストを生成求めるUACは、前のセクションで説明したように、Requireヘッダーフィールドにこのオプションタグを含まなければなりません。 OPTIONS要求に応答する場合、受信者リスト本体とメッセージを受信して処理することが可能であるUAは、前のセクションで説明したように、Supportedヘッダフィールドには、このオプションタグを含むべきです。
Multiple-recipient MESSAGE requests contain a multipart body that contains the body carrying the list and the actual instant message payload. In some cases, the MESSAGE request can contain bodies other than the text and the list bodies (e.g., when the request is protected with S/MIME as per RFC 3851 [RFC3851]).
複数の受信者のMESSAGEリクエストはリストと実際のインスタントメッセージペイロードを運ぶ体が含まれているマルチボディが含まれています。いくつかのケースでは、MESSAGE要求は、テキスト、リスト体（例えば、要求はRFC 3851の通りS / MIME [RFC3851]で保護されている場合）以外の体を含有することができます。
Typically, the MESSAGE URI-list service will copy all the significant header fields in the outgoing MESSAGE request. However, there might be cases where the SIP UA wants the MESSAGE URI-list service to add a particular header field with a particular value, even if the header field wasn't present in the MESSAGE request sent by the UAC. In this case, the UAC MAY use the "?" mechanism described in Section 19.1.1 of RFC 3261 [RFC3261] to encode extra information in any URI in the
一般的に、MESSAGE URI - リストサービスは、送信メッセージの要求のすべての重要なヘッダフィールドをコピーします。しかし、SIP UAは、ヘッダーフィールドはUACによって送信されたメッセージの要求に存在していなかった場合でも、特定の値を持つ特定のヘッダフィールドを追加するMESSAGE URI - リストサービスを望んでいる場合があるかもしれません。この場合、UACは、「？」を使用してもよい（MAY） RFC 3261 [RFC3261]のセクション19.1.1に記載の機構は任意のURIに追加情報を符号化します
list. However, the UAC MUST NOT use the special "body" hname (see Section 19.1.1 of RFC 3261 [RFC3261]) to encode a body, since the body is present in the MESSAGE request itself.
リスト。しかし、UACは、身体がMESSAGE要求自体に存在しているので、体をコードする（RFC 3261のセクション19.1.1 [RFC3261]を参照）特別な「ボディ」hnameを使用してはいけません。
The following is an example of a URI that uses the "?" mechanism:
以下は、「？」を使用してURIの例です。機構：
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
SIP：bob@example.comのAccept-接触= *％3bmobility％3D％22％22mobile？
The previous URI requests the MESSAGE URI-list service to add the following header field to a MESSAGE request to be sent to bob@example.com:
前のURIは、bob@example.comに送信するMESSAGE要求に次のヘッダーフィールドを追加するMESSAGE URI - リストサービスを要求します。
Accept-Contact: *;mobility="mobile"
受け入れ-接触：*;モビリティ= "モバイル"
The resource list document format specified in RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple MESSAGE URI-list service defined in this document. Therefore, when using the default resource list document, UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
RFC 4826 [RFC4826]で指定されたリソース・リスト・ドキュメント・フォーマットは、階層リストとXCAPルートURIに対する基準によってエントリを含める機能などの機能を提供します。しかし、これらの機能は、この文書で定義された複数のMESSAGE URI - リストサービスによって必要とされていません。従ってデフォルトリソースリスト文書を使用する場合、UAは、フラットリスト（すなわち、無階層リスト）を使用する必要があり、<エントリ-REF>要素を使用しないでください。
On reception of a MESSAGE request containing a URI list, the MESSAGE URI-list service answers to the UAC with a 202 (Accepted) response.
URIリストを含むMESSAGE要求の受信に、202（承認）応答でUACへMESSAGE URIリストサービスが応答。
Note that the status code in the response to the MESSAGE does not provide any information about whether or not the MESSAGEs generated by the URI-list service were successfully delivered to the URIs in the list. That is, a 202 (Accepted) response means that the MESSAGE URI-list service has received the MESSAGE and that it will try to send a similar MESSAGE to the URIs in the list. Designing a mechanism to inform a client about the delivery status of an instant message is outside the scope of this document.
メッセージに応答してステータスコードがURIリストサービスによって生成されたメッセージが正常にリスト内のURIに配信されたかどうかについての情報を提供しないことに注意してください。それは202（受理）応答がMESSAGE URI - リストサービスは、メッセージを受信したことを意味し、それは、リスト内のURIのようなメッセージを送信しようとすること、です。インスタントメッセージの配信状態についてクライアントに通知するためのメカニズムを設計すると、この文書の範囲外です。
Since the MESSAGE URI-list service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a MESSAGE URI-list server receiving a URI list with more information than what has just been described MAY discard all the extra information.
MESSAGE URI - リストサービスは、XCAPルートURIを参照することにより、エントリが含まれる階層リストやリストを使用していないので、今説明されたものよりも多くの情報をURIのリストを受信するMESSAGE URI - リストサーバは、すべての余分な情報を捨てるかもしれ。
If a MESSAGE request contains a Request-URI containing a URI that uses the "?" mechanism (see Section 19.1.1 of RFC 3261 [RFC3261]) and such URI contains the special "body" hname to include an additional body, the MESSAGE URI-list server MAY discard the contents of the "body" parameter.
MESSAGEリクエストは、Request-URI URIを含む「？」を使用していますが含まれている場合メカニズム（RFC 3261のセクション19.1.1を参照してください[RFC3261]）と、そのようなURIは、追加のボディを含めるために、特別な「身体」hnameが含まれ、「身体」パラメータの内容を捨てるかもしれMESSAGE URI - リストサーバ。
On reception of a MESSAGE request containing a URI list, a MESSAGE URI-list service determines the list of intended recipients by inspecting the URI list contained in the body.
URIリストを含むMESSAGE要求を受信すると、MESSAGE URIリストサービスは、本体に含まれるURIのリストを検査することにより、目的の受信者のリストを決定します。
Section 4.1 of RFC 5363 [RFC5363] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, MESSAGE URI-list services MUST take those actions specified in RFC 5363 [RFC5363] into account to avoid sending duplicated requests to the same recipient.
重複URIはURIのリストで発見されたときにRFC 5363 [RFC5363]のセクション4.1は、例を説明します。重複した要求を避けるために、MESSAGE URI - リストサービスは、同じ受信者に重複したリクエストを送信することを避けるために、アカウントにRFC 5363 [RFC5363]で指定されたこれらのアクションを取る必要があります。
Since the MESSAGE URI-list service behaves as a UAC for outgoing MESSAGE requests, for each of the intended recipients, the MESSAGE URI-list service creates a new MESSAGE request according to the procedures described in Section 4 of RFC 3428 [RFC3428]. Additionally, Section 5.3 of RFC 5363 [RFC5363] provides additional general guidance in creating outgoing requests. This document also specifies the following procedures:
MESSAGE URIリストサービスは送信メッセージ要求のUACとして動作するので、意図した受信者の各々のために、MESSAGE URIリストサービスは、RFC 3428 [RFC3428]のセクション4に記載された手順に従って、新しいメッセージ要求を作成します。また、RFC 5363のセクション5.3 [RFC5363]は、発信要求を作成する際に、追加の一般的なガイダンスを提供します。また、このドキュメントでは、次の手順を指定します。
o A MESSAGE URI-list service MUST include a From header field whose value is the same as the From header field included in the incoming MESSAGE request, subject to the privacy requirements (see RFC 3323 [RFC3323] and RFC 3325 [RFC3325]) expressed in the incoming MESSAGE request.
MESSAGE URIリストサービスは、プライバシー要件を条件として、その値がヘッダーフィールドからの着信MESSAGEリクエストに含まれるものと同じであるヘッダフィールドから含まなければならないO（RFC 3323 [RFC3323]及びRFC 3325 [RFC3325]を参照）を発現受信メッセージリクエストインチ
Note that this does not apply to the "tag" parameter.
これは、「タグ」パラメータには適用されないことに注意してください。
Failure to copy the From header field of the sender results in unacceptable security and privacy failures. Note also that this requirement does not intend to contradict requirements for additional services running on the same physical node. Specifically, a privacy service (see RFC 3323 [RFC3323]) can be co-located with the MESSAGE URI-list service, in which case, the privacy service has precedence over the MESSAGE URI-list service.
容認できないセキュリティとプライバシーの失敗で、送信者の結果のヘッダフィールドからコピーに失敗しました。この要件は、同じ物理ノード上で実行されている追加のサービスのための要件と矛盾するつもりはないことにも注意してください。具体的には、プライバシーサービスは、（RFC 3323 [RFC3323]を参照）、プライバシーサービスは、メッセージURIリストサービスよりも優先され、その場合、MESSAGE URIリストサービスと同じ場所に配置することができます。
o A MESSAGE URI-list service SHOULD generate a new To header field value set to the intended recipient's URI. According to the procedures of RFC 3261 [RFC3261] Section 8.1.1.1, this value is also expected to be equal to the Request-URI of the outgoing MESSAGE request.
O MESSAGE URI - リストサービスは、受信者のURIに設定新しいToヘッダーフィールド値を生成する必要があります。 RFC 3261 [RFC3261]セクション8.1.1.1の手順に従って、この値は、発信メッセージ要求のリクエストURIに等しいことが予想されます。
The MESSAGE URI-list service behaves as a User Agent Client;
thus, the To header field should be populated with the
recipient's URI.
o A MESSAGE URI-list service SHOULD create a new Call-ID header field value.
O MESSAGE URI - リストサービスは、新しいコール-IDヘッダフィールドの値を作成する必要があります。
A Call-ID header field might contain addressing information
that the sender wants to remain private. Since there is no
need to keep the same Call-ID on both sides of the MESSAGE URI-
list service, and since the MESSAGE URI-list service behaves as
a User Agent Client, it is recommended to create a new Call-ID
header field value according to the regular SIP procedures.
o If a P-Asserted-Identity header field was present in the incoming MESSAGE request and the request was received from a trusted source, as specified in RFC 3325 [RFC3325], and the first hop of the outgoing MESSAGE request is also trusted, a MESSAGE URI-list service MUST include a P-Asserted-Identity header field in the outgoing MESSAGE request with the same received value. However, if the first hop of the outgoing MESSAGE request is not trusted and the incoming MESSAGE request included a Privacy header field with a value different than 'none', the MESSAGE URI-list service MUST NOT include a P-Asserted-Identity header field in the outgoing MESSAGE request.
O P-Asserted-Identityヘッダフィールドは、受信メッセージ要求内に存在し、RFC 3325で指定されるように要求は[RFC3325]、および送信メッセージの要求の最初のホップも信頼され、信頼できるソースから受信された場合、 MESSAGE URIリストサービスは、同一の受信した値を持つ発信メッセージ要求内のP-Asserted-Identityヘッダフィールドを含まなければなりません。しかし、送信メッセージの要求が信頼されていないと、着信MESSAGEリクエストが「なし」とは異なる値とプライバシーヘッダフィールドを含め、MESSAGE URI - リストサービスは、P-Asserted-Identityヘッダフィールドを含めることはできませんの最初のホップの場合送信メッセージの要求インチ
o If a MESSAGE URI-list service is able to assert the identity of a user (e.g., using HTTP Digest authentication scheme as per RFC 2617 [RFC2617], S/MIME as per RFC 3851 [RFC3851], etc.) and the service implements a mechanism where it can map that authentication scheme to a user's SIP or SIPS URI, and subject to the privacy requirements expressed in the incoming MESSAGE request (see RFC 3323 [RFC3323]), the MESSAGE URI-list service MAY insert a P-Asserted-Identity header with the value of the user's asserted URI.
O MESSAGE URIリストサービスは、ユーザーのアイデンティティをアサートすることができる場合（例えば、RFC 2617 [RFC2617]に従ってHTTPダイジェスト認証方式を使用して、S / MIME RFC 3851 [RFC3851]などの通り）とサービス（RFC 3323 [RFC3323]を参照）、それはユーザのSIPへの認証方式をマッピングまたはURIをSIPS、および着信メッセージ要求に発現プライバシー要件に従うことができる機構を実装し、MESSAGE URIリストサービスは、P-を挿入することができますユーザーの値を持つアサート-Identityヘッダは、URIを主張しました。
o If the incoming MESSAGE request contains an Authorization or Proxy-Authorization header field whose realm is set to the MESSAGE URI-list server's realm, then the MESSAGE URI-list service SHOULD NOT copy it to the outgoing MESSAGE request; otherwise (i.e., if the Authorization or Proxy-Authorization header field of incoming MESSAGE request contains a different realm), the MESSAGE URI-list service MUST copy the value to the respective header field of the outgoing MESSAGE request.
受信メッセージの要求がその分野MESSAGE URI - リストサーバのレルムに設定されている認証またはProxy-Authorizationヘッダフィールドが含まれている場合は、O、その後、MESSAGE URI - リストサービスは、送信メッセージの要求にそれをコピーしてはいけません。 （着信メッセージ要求の許可またはプロキシ認証ヘッダフィールドが異なる領域が含まれている場合、すなわち、）それ以外の場合は、MESSAGE URIリストサービスは、送信メッセージの要求のそれぞれのヘッダフィールドへ値をコピーする必要があります。
o A MESSAGE URI-list service SHOULD create a separate count for the CSeq header field [RFC3261] of the outgoing MESSAGE request.
O MESSAGE URIリストサービスは、送信メッセージ要求のCSeqヘッダーフィールド[RFC3261]のための別個のカウントを作成する必要があります。
o A MESSAGE URI-list service SHOULD initialize the value of the Max-Forward header field of the outgoing MESSAGE request.
O MESSAGE URIリストサービスは、送信メッセージ要求の最大転送ヘッダフィールドの値を初期化する必要があります。
o A MESSAGE URI-list service MUST include its own value in the Via header field.
O MESSAGE URI - リストサービスは、Viaヘッダーフィールドに独自の値を含まなければなりません。
When creating the body of each of the outgoing MESSAGE requests, the MESSAGE URI-list service keeps the relevant bodies of the incoming MESSAGE request and copies them to the outgoing MESSAGE request. The following guidelines constitute exceptions to the general body handling:
送信メッセージの要求のそれぞれのボディを作成する場合は、MESSAGE URI - リストサービスは、受信メッセージの要求と送信メッセージの要求にコピーしての関係機関を保持します。次のガイドラインは、一般的な体の取り扱いの例外を構成します：
o A MESSAGE request received at a MESSAGE URI-list service can contain one or more security bodies (e.g., S/MIME, RFC 3851 [RFC3851]) encrypted with the public key of the MESSAGE URI-list service. These bodies are deemed to be read by the URI-list service rather than the recipient of the outgoing MESSAGE request (which will not be able to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT copy any security body (such as an S/MIME as per RFC 3851 [RFC3851] encrypted body) addressed to the MESSAGE URI-list service to the outgoing MESSAGE request. This includes bodies encrypted with the public key of the URI-list service.
O MESSAGE要求は、1人のまたは複数のセキュリティ体を含むことができるMESSAGE URIリストサービスで受信（例えば、S / MIME、RFC 3851 [RFC3851]）MESSAGE URIリストサービスの公開鍵で暗号化されました。これらの団体は、URIリストサービスではなく、（それらを解読することはできません）送信メッセージの要求の受信者によって読まれるとみなされます。したがって、MESSAGE URI - リストサービスは、（RFC 3851 [RFC3851]暗号化されたボディあたりとしてS / MIMEなど）の任意のセキュリティ本体をコピーし、発信MESSAGE要求にMESSAGE URI - リストサービスに宛ててはなりません。これは、URIリストサービスの公開鍵で暗号化されたボディを含んでいます。
o The incoming MESSAGE request typically contains a recipient-list body or reference, as indicated in RFC 5363 [RFC5363] with the actual list of recipients. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", the URI-list service SHOULD include a URI list in each of the outgoing MESSAGE requests. This list SHOULD be formatted according to the resource list document format specified in RFC 4826 [RFC4826] and the copyControl extension specified in RFC 5364 [RFC5364]. The MESSAGE URI-list service MUST follow the procedures specified in RFC 5364 [RFC5364] with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes.
受信者の実際のリストをRFC 5363 [RFC5363]に示されるようにO着信メッセージ要求は、典型的には、受信者リスト体または参照を含んでいます。このURIのリストは、「へ」または「CC」の値に設定する「コピーコントロールCD」属性でタグ付けされたリソースが含まれている場合は、URIリストサービスは、送信メッセージの要求のそれぞれにおけるURIのリストを含むべきです。このリストは、RFC 4826で指定されたリソース・リスト・ドキュメント・フォーマット[RFC4826]及びRFC 5364に指定されたコピーコントロールCD拡張[RFC5364]に従ってフォーマットされるべきです。 MESSAGE URI - リストサービスは、「匿名化」、「回数」の処理に関してRFC 5364 [RFC5364]で指定された手順、および「コピーコントロールCDの属性に従わなければなりません。
o If the MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it MUST include a Content-Disposition header field as per RFC 2183 [RFC2183] with the value set to 'recipient-list-history' and a "handling" parameter as per RFC 3204 [RFC3204] set to "optional".
MESSAGE URIリストサービスは送信メッセージの要求でURIリストを含む場合、Oは、RFC 2183に従ってコンテンツの廃棄ヘッダーフィールドを含まなければならない「受信者リスト履歴」および「取り扱いに設定された値と[RFC2183] 『任意」RFC 3204通りのパラメータ[RFC3204]はに設定しました』。
o If a MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it SHOULD use S/MIME (RFC 3851) [RFC3851] to encrypt the URI list with the public key of the receiver.
MESSAGE URIリストサービスは送信メッセージの要求でURIリストを含む場合、O、それは受信機の公開鍵でURIリストを暗号化するために、S / MIME（RFC 3851）[RFC3851]を使用すべきです。
o The MESSAGE URI-list service SHOULD copy all the remaining message bodies (e.g., text messages, images, etc.) of the incoming MESSAGE request to the outgoing MESSAGE request.
O MESSAGE URIリストサービスは、残りのすべてのメッセージ本文送信メッセージ要求に対する着信メッセージ要求（例えば、テキストメッセージ、画像、等）をコピーする必要があります。
o If there is only one body left, the MESSAGE URI-list service MUST remove the multipart/mixed wrapper in the outgoing MESSAGE request.
残された唯一の1体が存在する場合は、O、MESSAGE URI - リストサービスは、送信メッセージの要求でmultipart / mixedのラッパーを削除する必要があります。
The rest of the MESSAGE request corresponding to a given URI in the URI list MUST be created following the rules in Section 19.1.5, "Forming Requests from a URI", of RFC 3261 [RFC3261]. In particular, Section 19.1.5 of RFC 3261 [RFC3261] states:
URIリスト内の指定されたURIに対応するMESSAGE要求の残りの部分は、RFC 3261 [RFC3261]で、「URIからのリクエストを形成する」、セクション19.1.5のルールを次のように作成する必要があります。具体的には、RFC 3261 [RFC3261]のセクション19.1.5状態：
"An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis."
「実装は、メッセージに含めるための願望として、URI内の任意のヘッダまたは身体部分の存在を治療するため、およびコンポーネントごとのベースで要求を尊重するように選択する必要があります。」
SIP allows to append a "method" parameter to a URI. Therefore, it is legitimate that the 'uri' attribute of the <entry> element in the XML resource list contains a "method" parameter. MESSAGE URI-list services MUST generate only MESSAGE requests, regardless of the "method" parameter that the URIs in the list indicate. Effectively, MESSAGE URI-list services MUST ignore the "method" parameter in each of the URIs present in the URI list.
SIPは、URIに「メソッド」パラメータを追加することができます。そのため、XMLリソースリスト内の<entry>要素の「のuri」属性は、「メソッド」パラメータが含まれていることを正当です。 MESSAGE URI - リストサービスは関係なく、リスト内のURIが示す「メソッド」パラメータの、唯一のMESSAGE要求を発生させなければなりません。効果的に、MESSAGE URI - リストサービスは、URIのリストに存在するURIのそれぞれに「メソッド」パラメータを無視しなければなりません。
A UAS (in this specification, also known as intended recipient UAS) that receives a MESSAGE request from the MESSAGE URI-list service behaves as specified in RFC 3428 [RFC3428] Section 7.
[RFC3428]セクション7 RFC 3428で指定されるようにMESSAGE URIリストサービスからのメッセージ要求の動作受け取るUAS（本明細書ではまた、意図されるレシピエントのUASとして知られています）。
If the UAS supports this specification and the MESSAGE request contains a body with a Content-Disposition header field as per RFC 2183 [RFC2183] set to 'recipient-list-history', then the UAS will be able to determine the SIP Address-of-Record (AOR) of the other intended recipients of the MESSAGE request. This allows the user to create a reply request (e.g., MESSAGE, INVITE) to the sender and the rest of the recipients included in the URI list.
UASは、この仕様をサポートし、MESSAGEリクエストは、RFC 2183あたりとしてContent-Dispositionヘッダーフィールドとボディが含まれている場合は、[RFC2183]「受信者リスト履歴」に設定され、その後、UASは、SIPアドレス-のを決定することができるであろうMESSAGE要求の他の意図した受信者の-record（AOR）。これは、ユーザーが送信者に返信要求（例えば、MESSAGE、INVITE）を作成することを可能にすると、受信者の残りの部分は、URIのリストに含まれています。
Figure 1 shows an example of operation. A SIP UAC issuer sends a MESSAGE request. The MESSAGE URI-list service answers with a 202 (Accepted) response and sends a MESSAGE request to each of the intended recipients.
図1は、動作の一例を示しています。 SIP UACの発行者は、MESSAGE要求を送信します。 MESSAGE URI - リストサービス202（受理）応答で答えとは、受信者ごとにメッセージ要求を送信します。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 MESSAGE | | | |
| ---------------->| | | |
| F2 202 Accepted | | | |
|<---------------- | F3 MESSAGE | | |
| | ------------->| | |
| | F4 MESSAGE | | |
| | ------------------------>| |
| | F5 MESSAGE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operation
図1：動作例
The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed body that is composed of two bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml body containing the list of recipients.
受信者のリストを含むインスタントメッセージペイロードおよびアプリケーション/リソースリスト+ XML本体を含むtext / plainの本体（図2に示されている）MESSAGE要求F1は、二つの物体から構成されて混合/マルチ体を含有します。
MESSAGE sip:list-service.example.com SIP/2.0 Via: SIP/2.0/TCP uac.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: MESSAGE URI-list service <sip:list-service.example.com> From: Alice <sip:alice@example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 1 MESSAGE Require: recipient-list-message Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 501
MESSAGE SIP：list-service.example.com SIP / 2.0経由：SIP / 2.0 / TCP uac.example.com;ブランチ= z9hG4bKhjhs8ass83マックス・フォワード：70：MESSAGE URI - リストサービス<SIP：リスト-service.example。 COM>から：アリス<SIP：alice@example.com>;タグ= 32331コールID：d432fa84b4c76e66710ののCSeq：1 MESSAGEが必要：受信者リスト - メッセージのContent-Type：/マルチパートの混合;境界= "boundary1" のContent-Length ：501
--boundary1 Content-Type: text/plain
--boundary1のContent-Type：text / plainの
Hello World!
"こんにちは世界"
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト
<?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> --boundary1--
<？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" /> </リスト> </リソース・リスト> --boundary1--
Figure 2: MESSAGE request received at the MESSAGE URI-list server
図2：MESSAGE要求は、MESSAGE URI - リストサーバで受信しました
The MESSAGE requests F3, F4, and F5 are similar in nature. All those MESSAGE requests contain a multipart/mixed body that is composed of two other bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml containing the list of recipients. Unlike the text/plain body, the application/ resource-lists+xml bodies of MESSAGE requests F3, F4, and F5 are not equal to the application/resource-lists+xml body included in the incoming MESSAGE request F1. This is because the URI-list service has anonymized those URIs tagged with the 'anonymize' attribute and has removed those URIs tagged with a "bcc" 'copyControl' attribute; besides, the content disposition of these bodies is different. Figure 3 shows an example of the MESSAGE request F3.
MESSAGEは、F3、F4を要求し、F5は、本質的に似ています。インスタントメッセージペイロードおよび受信者のリストを含むアプリケーション/リソース・リスト+ XMLを含むテキスト/平野体：これらすべてのMESSAGEリクエストは他の二つの団体で構成されているmultipart / mixedの体を含んでいます。 text / plainのボディ、アプリケーション/リソース・リストMESSAGEの+ xmlの本体とは異なりF3、F4を要求し、F5は、着信MESSAGEリクエストF1に含まれるアプリケーション/リソース・リスト+ xmlの本体に等しくありません。 URIリストサービスは「匿名化」属性でタグ付けされたそれらのURIを匿名化しており、「BCC」「コピーコントロールCD」属性でタグ付けされたそれらのURIを削除しているためです。加えて、これらの機関の内容の配置が異なっています。図3は、MESSAGE要求F3の例を示しています。
MESSAGE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP list-service.example.com ;branch=z9hG4bKhjhs8as34sc Max-Forwards: 70 To: <sip:bill@example.com> From: Alice <sip:alice@example.com>;tag=210342 Call-ID: 39s02sdsl20d9sj2l CSeq: 1 MESSAGE Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 501
MESSAGEのSIP：bill@example.com SIP / 2.0経由：SIP / 2.0 / TCP list-service.example.com;ブランチ= z9hG4bKhjhs8as34scマックス・フォワード：70：<SIP：bill@example.com>から：アリス<一口：alice@example.com>;タグ= 210342のCall-ID：39s02sdsl20d9sj2lのCSeq：1つのメッセージのContent-Type：/マルチ混合;境界= "boundary1" のContent-Length：501
--boundary1 Content-Type: text/plain
--boundary1のContent-Type：text / plainの
Hello World!
"こんにちは世界"
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト履歴;取り扱い=オプション
<?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> --boundary1--
<？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" /> </リスト> </リソース・リスト> --boundary1--
Figure 3: MESSAGE request sent by the MESSAGE URI-list server
図3：MESSAGE URI - リストサーバによって送信されたメッセージ要求
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Implementations of MESSAGE URI-list services 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に関連する問題について説明します。 MESSAGE URI - リストサービスの実装は、RFC 5363 [RFC5363]でセキュリティ関連の規則に従わなければなりません。これらのルールは、オプトインリストと必須の認証とクライアントの承認が含まれています。
If the contents of the instant message needs to be kept private, the User Agent Client SHOULD use S/MIME as per RFC 3851 [RFC3851] to prevent a third party from viewing this information. In this case, the user agent client SHOULD encrypt the instant message body with a content encryption key. Then, for each receiver in the list, the UAC SHOULD encrypt the content encryption key with the public key of the receiver, and attach it to the MESSAGE request.
インスタントメッセージの内容は非公開にする必要がある場合は、ユーザエージェントクライアントは、この情報を見てから、第三者を防ぐために、RFC 3851 [RFC3851]あたりとしてS / MIMEを使用すべきです。この場合、ユーザエージェントクライアントは、コンテンツ暗号化キーでインスタントメッセージの本文を暗号化する必要があります。その後、リスト内の各受信機のために、UACは、受信者の公開鍵を使用して、コンテンツの暗号化キーを暗号化する必要があり、かつMESSAGE要求に取り付けます。
This document defines the SIP option tag 'recipient-list-message'
この文書では、SIPオプションタグ「受信者リストメッセージ」を定義します
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
次の行は、SIPパラメータレジストリの「オプションタグ」セクションに追加されました。
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-message | The body contains a list of | [RFC5365] |
| | URIs that indicates the | |
| | recipients of the SIP | |
| | MESSAGE request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-message' Option-Tag in SIP
表1：SIPの「受信者リストメッセージ」オプションタグの登録
Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean Willis, and Keith Drage provided helpful comments.
ダンカンミルズは、N個のメッセージに1を持つという考えを支持しました。ベン・キャンベル、ポールKyzivat、カレン・ジェニングス、ジョナサン・ローゼンバーグ、ディーンウィリス、そしてキース糖剤は有益なコメントを提供しました。
[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月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[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月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[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月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]キャマリロ、G.およびA.B.ローチ、RFC 5363、2008年10月「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項」。
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008.
[RFC5364]ガルシア・マーチン、M.およびG.キャマリロ、「コピー制御を表現するための拡張マークアップ言語（XML）形式拡張子リソースリストに属性」、RFC 5364、2008年10月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
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
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。