Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 7106 Jitsi
Category: Informational January 2014
ISSN: 2070-1721
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的组文本聊天
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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>子元素中。这些细节以一组<entry>子元素的形式呈现，每个子元素都包含允许访问相应辅助服务的URI。除了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>
<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.
除了上述“网页”用途外，[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:用于Internet中继聊天，http:或https:用于基于web的聊天等。
The following example shows one possible use case:
以下示例显示了一个可能的用例：
<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>
<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 URI>中已经存在类似的攻击，这就是为什么它推荐“一种强有力的身份验证和会议信息保护手段”以及“综合授权规则”。客户端可以使用端到端机制（如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中的会议聊天：attack@evil.example.com而不是在xmpp:dev上聊天-sprint@conference.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已将值“grouptextchat”添加到“会话启动协议（SIP）参数”注册表的“URI用途”子注册表中<http://www.iana.org/assignments/sip-parameters>详情如下:
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，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年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.，“可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，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.
感谢乔纳森·伦诺克斯、玛丽·巴恩斯、保罗·基齐瓦特、彼得·圣安德烈、里法特·谢赫·尤塞夫和索尔·伊巴拉·科雷奇的投入。
Author's Address
作者地址
Emil Ivov Jitsi Strasbourg 67000 France
埃米尔·伊沃夫·吉茨·斯特拉斯堡67000法国
Phone: +33-177-624-330
EMail: emcho@jitsi.org
Phone: +33-177-624-330
EMail: emcho@jitsi.org