[要約] RFC 7106は、SIPイベントパッケージのための会議状態における会議とサービスURIのためのグループテキストチャットの目的を定義しています。このRFCの目的は、会議参加者がテキストチャットを使用して会議中にコミュニケーションを行うことを可能にすることです。
Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 7106 Jitsi
Category: Informational January 2014
ISSN: 2070-1721
A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State
会議状態のSIPイベントパッケージの会議URIおよびサービスURIのグループテキストチャットの目的
Abstract
概要
This document defines and registers a value of "grouptextchat" ("Group Text Chat") for the URI <purpose> element of SIP's Conference Event Package.
このドキュメントでは、SIPの会議イベントパッケージのURI <purpose>要素の "grouptextchat"（ "Group Text Chat"）の値を定義して登録します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7106.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7106で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Security Considerations . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Normative References . . . . . . . . . . . . . . . . . . 5
4.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
The Conference Event Package [RFC4575] defines means for a SIP User Agent (UA) to obtain information about the state of the conference, the types of media that are being used, the number and state of current participants, additional sources of information (e.g., web page), availability of recordings, and more.
会議イベントパッケージ[RFC4575]は、SIPユーザーエージェント（UA）が会議の状態、使用されているメディアの種類、現在の参加者の数と状態、追加の情報源（例： 、ウェブページ）、レコーディングの可用性など。
Details describing auxiliary services available for a conference are included within a <service-uris> child element of the <conference-description> element. Such details are presented as a set of <entry> child elements, each containing the URI allowing access the corresponding auxiliary service. In addition to the URI, entries can also contain a descriptive <display-text> element and are expected to have a <purpose> element that specifies their nature as illustrated in the following example:
会議に使用できる補助サービスを説明する詳細は、<conference-description>要素の<service-uris>子要素内に含まれています。このような詳細は、それぞれが対応する補助サービスへのアクセスを許可するURIを含む<entry>子要素のセットとして提示されます。 URIに加えて、エントリには説明的な<display-text>要素を含めることもでき、次の例に示すように、その性質を指定する<purpose>要素が必要です。
<conference-description>
<subject>Agenda: This sprint's goals</subject>
<service-uris>
<entry>
<uri>http://conference.example.com/dev-group/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
</conference-description>
In addition to the "web-page" purpose mentioned above, [RFC4575] also defines several other possible values in the "URI Purposes" sub-registry under the existing "Session Initiation Protocol (SIP) Parameters" registry.
上記の「Webページ」の目的に加えて、[RFC4575]は、既存の「セッション開始プロトコル（SIP）パラメータ」レジストリの下の「URI目的」サブレジストリで他のいくつかの可能な値も定義しています。
This specification adds the "grouptextchat" value to this "URI Purposes" sub-registry. The new value allows conference mixers or focus agents to advertise a multi-user chat location (i.e., a chat room) associated with the current conference.
この仕様は、「grouptextchat」値をこの「URI目的」サブレジストリに追加します。新しい値により、会議のミキサーまたはフォーカスエージェントは、現在の会議に関連付けられているマルチユーザーチャットの場所（つまり、チャットルーム）をアドバタイズできます。
The actual URI carried by the entry with the "grouptextchat" purpose can be of any type as long as the content that it points to allows for instant text communication between participants of the conference. Suitable URI schemes include sip: and sips: [RFC3261] for SIP-signaled Message Session Relay Protocol (MSRP) conferences, xmpp: [RFC5122] for XMPP Multi-User Chat (MUC), irc: for Internet Relay Chat, http: or https: for web-based chat, and others.
「grouptextchat」の目的を持つエントリによって運ばれる実際のURIは、それが指すコンテンツが会議の参加者間のインスタントテキスト通信を可能にする限り、どのようなタイプでもかまいません。適切なURIスキームには、sip：とsips：[RFC3261]のSIPシグナリングメッセージセッションリレープロトコル（MSRP）会議、xmpp：[RFC5122]はXMPPマルチユーザーチャット（MUC）、irc：はインターネットリレーチャット、http：またはhttps：Webベースのチャットなど。
The following example shows one possible use case:
次の例は、考えられる1つの使用例を示しています。
<conference-description>
<subject>Agenda: The goals for this development sprint.</subject>
<service-uris>
<entry>
<uri>xmpp:dev-sprint@conference.example.com</uri>
<purpose>grouptextchat</purpose>
</entry>
</service-uris>
</conference-description>
It is worth pointing out that, in addition to simply adding text messaging capabilities to an audio/video conference, group chats can also be used for defining roles, giving permissions, muting, kicking out and banning participants, etc. A conference mixer or focus agent can mimic these settings within the conference call, actually muting, kicking out, or banning participants on the call as these actions occur in the chat room. Such an approach requires no additional specification and is purely an implementation decision for the conferencing software.
オーディオ/ビデオ会議にテキストメッセージング機能を追加するだけでなく、グループチャットを使用して、役割の定義、権限の付与、ミュート、参加者の追放および参加禁止などを行うこともできます。会議のミキサーまたはフォーカスエージェントは、これらのアクションがチャットルームで発生すると、電話会議内でこれらの設定を模倣して、実際に通話の参加者をミュート、キックアウト、または禁止できます。そのようなアプローチは、追加の仕様を必要とせず、純粋に会議ソフトウェアの実装決定です。
It is also worth mentioning that it is possible for the grouptextchat URI to match the URI of the conference. This would typically be the case in scenarios where the conference focus agent also provides a SIP-signaled MSRP chat service at the same URI.
grouptextchat URIが会議のURIと一致する可能性があることにも言及する価値があります。これは通常、会議フォーカスエージェントが同じURIでSIP信号のMSRPチャットサービスも提供するシナリオの場合です。
Also, in some cases, servers could potentially advertise more than a single chat room for a specific conference. When this happens, clients supporting the "grouptextchat" purpose could either present the user with a choice of joining individual chats or simply opening all of them simultaneously. Either way, there is to be no expectation about any content synchronization between chat rooms. If synchronization exists, such behavior would be entirely implementation specific.
また、場合によっては、サーバーが特定の会議に対して複数のチャットルームをアドバタイズする可能性があります。これが発生すると、「grouptextchat」の目的をサポートするクライアントは、個々のチャットに参加するか、単にすべてのチャットを同時に開くかの選択肢をユーザーに提示できます。どちらの方法でも、チャットルーム間のコンテンツの同期は期待できません。同期が存在する場合、そのような動作は完全に実装固有になります。
Advertising group text chats over SIP could provide malicious entities with the following attack vector: if a malicious entity is capable of intercepting and modifying conference package event notifications, it could trick participants into joining a third-party chat room where the attacker could eavesdrop on the conversation and potentially even impersonate some of the participants.
SIPを介したグループテキストチャットのアドバタイズは、悪意のあるエンティティに次の攻撃ベクトルを提供する可能性があります。悪意のあるエンティティが会議パッケージイベント通知を傍受および変更できる場合、攻撃者が第三者に盗聴可能なチャットルームに参加するように参加者を騙す可能性があります。会話し、参加者の一部になりすます可能性もあります。
Similar attacks are already possible with the "participation" <conference-uris> defined in [RFC4575], which is why it recommends "a strong means for authentication and conference information protection" as well as "comprehensive authorization rules". Clients can integrity protect and encrypt notification messages using end-to-end mechanisms such as S/MIME or hop-by-hop mechanisms such as TLS. When none of these are possible, clients need to clearly display the address of the destination chat room (before and after it has been joined) so that users can notice possible discrepancies.
[RFC4575]で定義されている「参加」<conference-uris>でも同様の攻撃が可能です。そのため、「認証と会議情報の保護のための強力な手段」と「包括的な認可ルール」を推奨しています。クライアントは、S / MIMEなどのエンドツーエンドメカニズムやTLSなどのホップバイホップメカニズムを使用して、通知メッセージの整合性を保護し、暗号化できます。これらのいずれも可能でない場合、クライアントは宛先のチャットルームのアドレスを明確に表示して（参加前と参加後）、ユーザーが不一致に気付くようにする必要があります。
As an example, let's consider a situation in which an attacker tricks participants into joining a conference chat at xmpp:attack@evil.example.com rather than the chat at xmpp:dev-sprint@conference.example.com, which was originally advertised for this conference. In the absence of any SIP-layer security, displaying the full URI of the target chat room to the user would be the only way of actually detecting the problem.
例として、攻撃者が参加者をだまして、元々宣伝されていたxmpp：dev-sprint@conference.example.comでのチャットではなく、xmpp：attack@evil.example.comでの会議チャットに参加させる状況を考えてみましょう。この会議のために。 SIPレイヤーセキュリティがない場合、ターゲットチャットルームの完全なURIをユーザーに表示することが、実際に問題を検出する唯一の方法です。
Obviously, relying on human-performed string comparison is a rather meek form of protection. Therefore, client developers are encouraged to implement additional checks that would allow users to request via configuration that a target chat room satisfy some basic criteria, such as:
明らかに、人間が実行する文字列の比較に依存することは、どちらかと言えば保護の形式です。したがって、クライアント開発者は、ターゲットチャットルームが次のようないくつかの基本的な基準を満たすことを構成を介してユーザーが要求できるようにする追加のチェックを実装することをお勧めします。
o target chat rooms belong to the same domain as the conference service that is advertising them.
o ターゲットチャットルームは、それらを宣伝している会議サービスと同じドメインに属しています。
o chat room names (user part of the chat room URI) match the name of the conference.
o チャットルーム名（チャットルームURIのユーザー部分）は、会議の名前と一致します。
Once again, these conditions are only satisfied if the corresponding deployment conventions have been followed and they cannot be universally required by clients. Therefore, they are suggested configuration options.
繰り返しますが、これらの条件は、対応する展開規則に従っている場合にのみ満たされ、クライアントが普遍的に要求することはできません。したがって、これらは推奨される構成オプションです。
An additional security consideration might be the possibility for using a large-scale conference as leverage to perform a flooding attack on a chat room. To help prevent this, clients could to require an explicit user action before joining chat rooms on behalf of users. In cases where such a constraint could be considered to have a negative impact on usability and where automatic joins are seen as important, clients may still perform the joins but only when they can confirm a relationship between the room and the conference (e.g., they both belong to the same administrative domain, or domains that the client is provisioned to consider as related).
セキュリティに関する追加の考慮事項として、大規模な会議を活用してチャットルームにフラッディング攻撃を実行する可能性があります。これを防ぐために、クライアントは、ユーザーに代わってチャットルームに参加する前に、明示的なユーザーアクションを要求することができます。このような制約がユーザビリティにマイナスの影響を与えると見なされ、自動結合が重要であると見なされる場合、クライアントは部屋と会議の関係を確認できる場合にのみ結合を実行できます（例：両方）同じ管理ドメイン、またはクライアントが関連していると見なすようにプロビジョニングされているドメインに属している）。
Furthermore, an attack on an auxiliary chat room might be easier (or harder) than an attack on the main conference chat room depending on the security policies in effect. Once again, clients would have to make sure that users are appropriately notified about the security levels of each component of the conference and that user-specified privacy restrictions are applied to all of them.
さらに、補助チャットルームへの攻撃は、有効なセキュリティポリシーによっては、メイン会議チャットルームへの攻撃よりも簡単（または困難）になる場合があります。繰り返しになりますが、クライアントは、ユーザーが会議の各コンポーネントのセキュリティレベルについて適切に通知され、ユーザー指定のプライバシー制限がそれらすべてに適用されることを確認する必要があります。
IANA has added the value "grouptextchat" to the "URI Purposes" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry <http://www.iana.org/assignments/sip-parameters> as follows:
IANAは、次のように、「Session Initiation Protocol（SIP）Parameters」レジストリ<http://www.iana.org/assignments/sip-parameters>の「URI Purposes」サブレジストリに値「grouptextchat」を追加しました。
Value: grouptextchat Description: The URI can be used to join a multi-user chat directly associated with the conference Document: [this document]
値：grouptextchat説明：URIを使用して、会議に直接関連付けられているマルチユーザーチャットに参加できますドキュメント：[このドキュメント]
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）の国際化リソース識別子（IRI）およびUniform Resource Identifiers（URIs）」、RFC 5122、2008年2月。
Thanks to Jonathan Lennox, Mary Barnes, Paul Kyzivat, Peter Saint-Andre, Rifaat Shekh-Yusef, and Saul Ibarra Corretge for their input.
Jonathan Lennox、Mary Barnes、Paul Kyzivat、Peter Saint-Andre、Rifaat Shekh-Yusef、Saul Ibarra Corretgeの各氏に感謝します。
Author's Address
著者のアドレス
Emil Ivov Jitsi Strasbourg 67000 France
Emil Ivov Jitsiストラスブール67000フランス
Phone: +33-177-624-330
EMail: emcho@jitsi.org