[要約] RFC 5365は、SIPにおける複数の受信者を持つメッセージリクエストに関する仕様です。このRFCの目的は、SIPセッションで複数の受信者にメッセージを送信するための標準化とガイドラインを提供することです。
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)
セッション開始プロトコル（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 URIリスト（ユニフォームリソース識別子リスト）サービスを使用して、SIPユーザーエージェントクライアント（UAC）がSIPメッセージ要求を一連の宛先に送信できるメカニズムを指定します。UACは、Payloadを含むSIPメッセージリクエストとURIリストをメッセージURI-Listサービスに送信します。これは、リストに含まれる各URIにペイロードを含むメッセージ要求を送信します。
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]は、RFC 3248 [RFC3428]によって拡張され、メッセージリクエストにインスタントメッセージを伝達します。RFC 3428 [RFC3428]で説明されているように、SIPベースのメッセージは、複数の受信者に同じリクエストを送信したり、SIPメッセージリクエストのすべての受信者に返信するメカニズムを提供しません。このメモは、これらの関数に対応しています。
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.
上記の要件を満たす可能性の1つは、インスタントメッセージング会議サーバーでインスタントメッセージのセッションを確立し、たとえば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-Listサービスは、リクエストを受信し、リスト内の各URIに受信したペイロードを含むメッセージリクエストを送信します。これらの各メッセージ要求には、元のメッセージリクエストに含まれる本体のコピーが含まれています。
A second requirement addresses the "Reply-To-All" functionality:
2番目の要件は、「すべての返信」機能に対応しています。
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.
この要件を満たすために、メッセージURI-Listサービスには、コンテンツダイズ（RFC 2183）[RFC2183]がRFC 5364で指定されている「レシピエントリスト史」であるボディパーツの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.
メッセージリクエストをメッセージに送信するユーザーエージェントクライアント（UAC）は、機能を提供するサービスのSIP URIで構成する必要があります。このURIをUACに発見してプロビジョニングすることは、このドキュメントの範囲外です。
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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
メッセージURI-Listサービス：URIリストを使用してメッセージ要求を受信し、リスト内の各URIに同様のメッセージリクエストを送信する専門のURIリストサービス。これに関連して、同様のSIPヘッダーフィールドが変更できることを示していますが、メッセージURI-Listサービスはインスタントメッセージペイロードを変更しません。Message URI-List Servicesは、特殊なB2BUA（バックツーバックユーザーエージェント）として効果的に動作します。この機能は、このドキュメントの範囲外ですが、メッセージを提供するURI-Listサービスを提供するサーバーも他の方法にURI-Listサービスを提供できます。このドキュメントでは、メッセージURI-Listサービスについてのみ説明します。
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.
着信メッセージリクエスト：SIPメッセージ要求UACがメッセージURI-Listサービスを作成してアドレス指定することを要求します。通常のインスタントメッセージペイロードに加えて、着信メッセージリクエストには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.
送信メッセージリクエスト：SIPメッセージリクエストメッセージURI-ListサービスがUAS（ユーザーエージェントサーバー）に作成およびアドレス指定することを要求します。通常のインスタントメッセージペイロードが含まれています。
Intended recipient: The intended final recipient of the request to be generated by MESSAGE URI-list service.
意図された受信者：メッセージURI-Listサービスによって生成されるリクエストの意図された最終受信者。
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.
すべての返信：ペイロードと受信者のリストを含むメッセージリクエストを受け取る意図された受信者の能力、および送信者およびその他の受信者にメッセージリクエストを作成して送信します。返信エンティティは、各SIP AORに通常の単一通信メッセージ要求のシーケンスを作成している場合、メッセージURI-Listサービスを使用できます。
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は、URIS（意図された受信者）とインスタントメッセージを含むマルチパート本体を含むメッセージリクエストを作成します。URIのリストは、RFC 4826 [RFC4826]で指定されたリソースリストドキュメント形式に従ってフォーマットされ、RFC 5364 [RFC5364]で定義された属性とともに拡張されます。UACは、このメッセージ要求をメッセージURI-Listサービスに送信します。この着信メッセージ要求を受信すると、メッセージURI-Listサービスは、意図した受信者（URIリストにリストされている）ごとにメッセージ要求を作成し、それらの各メッセージにインスタントメッセージペイロードをコピーします。メッセージURI-Listサービスは、RFC 5364 [RFC5364]に示されている手順に従ってXMLリソースリストを操作し、インスタントメッセージペイロードとともに結果を各メッセージ要求に添付します。次に、メッセージURI-List Serviceは、作成された発信メッセージ要求のそれぞれをそれぞれのレシーバーに送信します。
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.
メッセージURI-Listメカニズムにより、送信者は、RFC 5364 [RFC5364]で定義された属性で拡張されたメッセージ要求の本文にRFC 4826 [RFC4826]に従ってXMLリソースリストドキュメントを含めることにより、メッセージ要求の複数のターゲットを指定できます。このリソースリストは、そのコンテンツ拡散（RFC 2183）[RFC2183]であり、RFC 5363 [RFC5363]で指定されているように、ターゲットのURIが含まれます。また、各ターゲットURIは、URI-Listサービスがターゲット（「To」、「CC」、または「BCC」など）をどのような役割に配置するか、およびターゲットURIが匿名化されると予想されるかどうかを示すようにマークされる場合があります。、RFC 5364 [RFC5364]に記載されている手順によると。メッセージURI-Listサーバーが各受信者にメッセージ要求を展開すると、（インスタントメッセージペイロードとともに）新しいURIリスト（受信したものに基づく）が含まれます。RFC 5364 [RFC5364]で指定されているように、レシピエントリストヒストリー '。この新しいURIリストには、非匿名の「to」および「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リストサービスのように、個々の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.
メッセージURI-Listサービスの「受信者リスト」本体のデフォルト形式は、コピー制御属性[RFC5364]で拡張されたRFC 4826 [RFC4826]で指定されたリソースリストドキュメントです。UACとメッセージURI-Listサービス「受信者リスト」ボディは、これらの形式の両方をサポートし、他の形式をサポートする必要があります。
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は、「Copycontrol」属性を「」、「CC」、または「BCC」に設定してタグ付けでき、受信者がメッセージ要求を取得する役割を示します。さらに、urisに「匿名」属性でタグ付けして、メッセージURI-listサーバーが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]は、意図した受信者のリストを含む「受信者リスト史」本体を定義します。メッセージURI-Listサービスの「受信者リスト登録」ボディのデフォルト形式は、コピー制御属性[RFC5364]で拡張されたRFC 4826 [RFC4826]で指定されたリソースリストドキュメントでもあります。メッセージURI-Listサービスは、これらの両方の形式をサポートする必要があります。UASSはこれらの形式をサポートする場合があります。メッセージURI-ListサーバーとUASSは、他の形式をサポートする場合があります。
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]で指定されたリソースリストドキュメントは、このドキュメントで定義されているメッセージURI-Listサービスでは必要ない多くの機能を提供します。メッセージURI-Listサービスは、UACとメッセージURI-Listサーバーの間、およびメッセージURI-ListサーバーとUAS間でURIの単純なフラットリストを転送する必要があります。このサービスでは、階層的なリストや、拡張可能な構成アクセスプロトコル（XCAP）[RFC4825]ルートURIに対する参照ごとにエントリを含める機能は必要ありません。したがって、ここで指定されたメッセージURI-Listサービスは、相対的な参照を含まないドキュメントのフラットリソースリストのみを使用します。
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.
このオプションタグは、サーバーがメッセージリクエストで使用される「受信者リスト」ボディを処理できるようにするために使用されます。また、オプションリクエストへの応答でサーバーの機能を発見するメカニズムも提供します。
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.
複数の通年メッセージリクエストを作成したいUACは、RFC 3428 [RFC3428]セクション4に従ってフォーマットする必要があるメッセージリクエストを作成します。UACは、メッセージURI-ListサービスのSIPまたはSIPS URIをリクエスト-URIに入力します。。通常のインスタントメッセージ本体に加えて、UACは、RFC 5363 [RFC5363]で指定された、コンテンツ拡張タイプが「レシピエントリスト」であるレシピエントリストボディを追加します。この本体には、メッセージの受信者が付いたURIリストが含まれています。このボディのターゲットURIには、RFC 5364 [RFC5364]で指定された「コピーコントロール」および「匿名」属性のタグ付けもできます。UACには、セクション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.
前のセクションで説明されているように、受信者リストボディを運ぶメッセージリクエストを生成するUACは、このオプションタグを必要ヘッダーフィールドに含める必要があります。前のセクションで説明されているように、受信者リストボディを使用してメッセージを受信および処理できるUASは、オプションリクエストに応答する際にサポートされているヘッダーフィールドにこのオプションタグを含める必要があります。
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]).
多反心のメッセージ要求には、リストを運ぶ本体と実際のインスタントメッセージペイロードを含むマルチパート本体が含まれています。場合によっては、メッセージリクエストには、テキストとリスト本体以外の本体を含めることができます（たとえば、RFC 3851 [RFC3851]に従ってS/MIMEでリクエストが保護されている場合）。
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 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.
通常、メッセージURI-Listサービスは、発信メッセージリクエストのすべての重要なヘッダーフィールドをすべてコピーします。ただし、SIP UAは、UACが送信したメッセージ要求にヘッダーフィールドが存在しなかった場合でも、メッセージURI-Listサービスを特定の値で特定のヘッダーフィールドを追加することを望んでいる場合があります。この場合、UACは「？」を使用できます。RFC 3261 [RFC3261]のセクション19.1.1で説明されているメカニズムは、リスト内の任意のURIに追加の情報をエンコードします。ただし、UACは、メッセージリクエスト自体にボディが存在するため、特別な「ボディ」hName（RFC 3261 [RFC3261]のセクション19.1.1 [RFC3261]を参照）を使用してはいけません。
The following is an example of a URI that uses the "?" mechanism:
以下は、「？」を使用するURIの例です。機構：
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
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は、メッセージURI-Listサービスを要求して、次のヘッダーフィールドをメッセージリクエストに追加してbob@example.comに送信します。
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に関連する参照によってエントリを含める機能などの機能を提供します。ただし、これらの機能は、このドキュメントで定義されている複数のメッセージURI-Listサービスでは必要ありません。したがって、デフォルトのリソースリストドキュメントを使用する場合、UASはフラットリスト（つまり、階層リストなし）を使用する必要があり、<Entre-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リストを含むメッセージリクエストを受信すると、メッセージURI-Listサービスは202（受け入れられた）応答でUACに回答します。
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リストサービスによって生成されたメッセージがリスト内のURISに正常に配信されたかどうかについての情報を提供しないことに注意してください。つまり、202（受け入れられた）応答は、メッセージURI-Listサービスがメッセージを受信し、リスト内の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.
メッセージURI-Listサービスは階層リストを使用しておらず、XCAPルートURIを参照してエントリを含むリストも使用していないため、説明されていることよりも多くの情報を含むURIリストを受信するメッセージ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.
メッセージ要求に「？」を使用するURIを含むリクエスト-URIが含まれている場合メカニズム（RFC 3261 [RFC3261]のセクション19.1.1を参照）およびそのようなURIには、特別な「ボディ」hnameが含まれており、追加のボディを含めることができます。
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リストを含むメッセージリクエストを受信すると、メッセージ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.
RFC 5363 [RFC5363のセクション4.1]は、URIリストに重複したURIが見つかった場合の症例について説明します。複製されたリクエストを回避するために、メッセージURI-Listサービスは、同じ受信者に重複した要求を送信しないように、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:
メッセージURI-Listサービスは、発信メッセージ要求のUACとして動作するため、意図した各受信者について、メッセージURI-Listサービスは、RFC 3428 [RFC3428]のセクション4で説明されている手順に従って新しいメッセージ要求を作成します。さらに、RFC 5363 [RFC5363]のセクション5.3は、発信要求の作成に追加の一般的なガイダンスを提供します。このドキュメントは、次の手順も指定しています。
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.
o メッセージURI-Listサービスには、プライバシー要件を条件として、受信メッセージリクエストに含まれるヘッダーフィールドと同じヘッダーフィールドからのAを含める必要があります（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-Listサービスと共同住宅できます。この場合、プライバシーサービスはURI-Listサービスよりも優先されます。
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 メッセージURI-Listサービスは、意図した受信者のURIに設定された新しいヘッダーフィールド値を生成する必要があります。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.
メッセージURI-Listサービスは、ユーザーエージェントクライアントとして動作します。したがって、ヘッダーへのフィールドには、受信者のURIを入力する必要があります。
o A MESSAGE URI-list service SHOULD create a new Call-ID header field value.
o メッセージURI-Listサービスは、新しいCall-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.
Call-IDヘッダーフィールドには、送信者がプライベートを維持したいというアドレス指定情報が含まれている場合があります。メッセージURI-Listサービスの両側に同じCall-IDを保持する必要がないため、メッセージURI-Listサービスはユーザーエージェントクライアントとして動作するため、新しいCall-IDヘッダーフィールドを作成することをお勧めします通常のSIP手順に従って値。
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 RFC 3325 [RFC3325]で指定されているように、P-Asserted-Identityヘッダーフィールドが着信メッセージリクエストに存在し、リクエストが信頼できるソースから受信され、発信メッセージリクエストの最初のホップも信頼されている場合、メッセージもメッセージです。URI-Listサービスは、同じ受信価値を持つ発信メッセージ要求にP-Asserted-Identityヘッダーフィールドを含める必要があります。ただし、発信メッセージ要求の最初のホップが信頼されておらず、受信メッセージリクエストに「なし」とは異なる値を持つプライバシーヘッダーフィールドが含まれている場合、メッセージURI-Listサービスには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 メッセージURI-ListサービスがユーザーのIDをアサートできる場合（たとえば、RFC 2617 [RFC2617]に従ってHTTP Digest認証スキームを使用し、RFC 3851 [RFC3851]などに従ってS/MIME）およびサービス用具その認証スキームをユーザーのSIPまたはSIP URIにマッピングできるメカニズム、および着信メッセージリクエストで表されるプライバシー要件の対象となります（RFC 3323 [RFC3323]を参照）、メッセージURI-ListサービスにP assertedを挿入する場合があります - ユーザーの主張された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.
o 受信メッセージリクエストに、領域がuri-listサーバーのレルムに設定されている承認またはプロキシ承認ヘッダーフィールドが含まれている場合、メッセージuri-listサービスはそれを発信メッセージリクエストにコピーすべきではありません。それ以外の場合（つまり、着信メッセージリクエストの承認または代理認証ヘッダーフィールドに異なる領域が含まれている場合）、メッセージURI-Listサービスは、送信メッセージリクエストのそれぞれのヘッダーフィールドに値をコピーする必要があります。
o A MESSAGE URI-list service SHOULD create a separate count for the CSeq header field [RFC3261] of the outgoing MESSAGE request.
o メッセージURI-Listサービスは、発信メッセージリクエストのCSEQヘッダーフィールド[RFC3261]の個別のカウントを作成する必要があります。
o A MESSAGE URI-list service SHOULD initialize the value of the Max-Forward header field of the outgoing MESSAGE request.
o メッセージURI-Listサービスは、発信メッセージリクエストのMax-Forwardヘッダーフィールドの値を初期化する必要があります。
o A MESSAGE URI-list service MUST include its own value in the Via header field.
o メッセージURI-Listサービスには、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:
発信メッセージ要求のそれぞれの本文を作成するとき、メッセージURI-Listサービスは、着信メッセージ要求の関連する本体を保持し、それらを発信メッセージ要求にコピーします。次のガイドラインは、一般的な身体の取り扱いの例外を構成します。
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 メッセージURI-Listサービスで受信したメッセージ要求には、1つ以上のセキュリティボディ（S/MIME、RFC 3851 [RFC3851]）を含むことができます。これらのボディは、発信メッセージリクエストの受信者ではなく、URIリストサービスによって読まれているとみなされます（これらを復号化することはできません）。したがって、メッセージURI-Listサービスは、セキュリティ本体（RFC 3851 [RFC3851]が暗号化された本文に従ってS/MIMEなど）をコピーしてはなりません。これには、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.
o 通常、着信メッセージ要求には、RFC 5363 [RFC5363]に示されているように、レシピエントの実際のリストを含む受信者リスト本文または参照が含まれています。このURIリストに「copycontrol」属性が「to」または「cc」の値に設定されたリソースが含まれている場合、URIリストサービスには、各発信メッセージリクエストにURIリストを含める必要があります。このリストは、RFC 4826 [RFC4826]で指定されたリソースリストドキュメント形式と、RFC 5364 [RFC5364]で指定されたコピーコントロール拡張に従ってフォーマットする必要があります。メッセージURI-Listサービスは、「匿名」、「カウント」、および「Copycontrol」属性の処理に関して、RFC 5364 [RFC5364]で指定された手順に従う必要があります。
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".
o メッセージURI-Listサービスに発信メッセージ要求にURIリストが含まれている場合、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.
o メッセージURI-Listサービスに発信メッセージ要求にURIリストが含まれている場合、S/MIME（RFC 3851）[RFC3851]を使用して、URIリストをレシーバーの公開鍵で暗号化する必要があります。
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 メッセージURI-Listサービスは、発信メッセージリクエストに着信メッセージ要求の残りのすべてのメッセージ本文（テキストメッセージ、画像など）をすべてコピーする必要があります。
o If there is only one body left, the MESSAGE URI-list service MUST remove the multipart/mixed wrapper in the outgoing MESSAGE request.
o ボディが1つしか残っていない場合、メッセージURI-Listサービスは、発信メッセージリクエストでマルチパート/混合ラッパーを削除する必要があります。
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に対応する残りのメッセージ要求は、RFC 3261 [RFC3261]のセクション19.1.5の「URIからのリクエストの形成」のルールに従って作成する必要があります。特に、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」属性に「メソッド」パラメーターが含まれていることが合法です。メッセージURI-Listサービスは、リスト内のURIが示す「メソッド」パラメーターに関係なく、メッセージ要求のみを生成する必要があります。効果的に、メッセージURI-Listサービスは、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.
メッセージURI-Listサービスからメッセージ要求を受信するURIS（この仕様、意図されたレシピエントUASとも呼ばれる）は、RFC 3428 [RFC3428]セクション7で指定されているように動作します。
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がこの仕様をサポートし、メッセージリクエストには、RFC 2183 [RFC2183]に従ってコンテンツディスポジションヘッダーフィールドを備えたボディが「レシピエントリストハイストリー」に設定されている場合、UASはSIPアドレスのアドレスを決定できます。 - メッセージ要求の他の受信者のRecord（AOR）。これにより、ユーザーは送信者と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発行者がメッセージリクエストを送信します。メッセージURI-Listサービスは、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.
メッセージ要求F1（図2に示す）には、2つのボディで構成されるマルチパート/混合ボディが含まれています。インスタントメッセージペイロードを含むテキスト/プレーンボディと、受信者のリストを含むアプリケーション/リソースリストXMLボディ。
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
--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--
Figure 2: MESSAGE request received at the MESSAGE URI-list server
図2：メッセージuri-listサーバーで受信したメッセージリクエスト
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.
メッセージの要求F3、F4、およびF5は、本質的に似ています。これらのメッセージ要求には、他の2つのボディで構成されるマルチパート/混合本体が含まれています。インスタントメッセージペイロードを含むテキスト/プレーンボディと、受信者のリストを含むアプリケーション/リソースリストXML。テキスト/プレーン本体とは異なり、アプリケーション/リソースリストXMLメッセージ要求F3、F4、およびF5のボディは、入っているメッセージリクエストF1に含まれるアプリケーション/リソースリストXMLボディに等しくありません。これは、URIリストサービスが「匿名」属性でタグ付けされたURIを匿名化し、「BCC」「CopyControl」属性でタグ付けされたURIを削除したためです。その上、これらの体の内容の処分は異なります。図3は、メッセージ要求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
--boundary1
Content-Type: text/plain
Hello World!
「こんにちは世界」
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
<?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--
Figure 3: MESSAGE request sent by the MESSAGE URI-list server
図3：メッセージuri-listサーバーによって送信されたメッセージリクエスト
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]は、SIP URIリストサービスに関連する問題について説明しています。メッセージURI-Listサービスの実装は、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はコンテンツ暗号化キーをレシーバーの公開キーで暗号化し、メッセージ要求に添付する必要があります。
This document defines the SIP option tag 'recipient-list-message'
このドキュメントでは、SIPオプションタグ「Reciontient-List-Message」を定義します
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.
Duncan Millsは、1〜Nのメッセージを持つというアイデアをサポートしました。ベン・キャンベル、ポール・キジバット、カレン・ジェニングス、ジョナサン・ローゼンバーグ、ディーン・ウィリス、キース・ドレイジは有益なコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の通信：コンテンツ - 分散ヘッダーフィールド」、RFC 2183、1997年8月。
[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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「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.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M。、およびM. Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC3204、2001年12月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（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] Campbell、B.、Rosenberg、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。、「Secure/Multipurpose Internet Mail Extensions（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] Rosenberg、J。、「リソースリストを表すための拡張マークアップ言語（XML）形式」、RFC 4826、2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]カマリロ、G。およびA.B.Roach、「セッション開始プロトコル（SIP）URI-List Servicesのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
[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] Garcia-Martin、M。およびG. Camarillo、「リソースリストでコピー制御属性を表すための拡張マークアップ言語（XML）形式拡張機能」、RFC 5364、2008年10月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、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] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
ミゲル・A・ガルシア・マルティン・エリクソン・デ・ロス・ポブラドス13マドリード28033スペイン
EMail: miguel.a.garcia@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。