Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 7701
Category: Standards Track M. Garcia-Martin
ISSN: 2070-1721 Ericsson
G. Sandbakken
Cisco Systems
December 2015
Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 7701
Category: Standards Track M. Garcia-Martin
ISSN: 2070-1721 Ericsson
G. Sandbakken
Cisco Systems
December 2015
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
使用消息会话中继协议（MSRP）的多方聊天
Abstract
摘要
The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.
消息会话中继协议（MSRP）定义了一种用于在对等会话中发送即时消息（IMs）的机制，使用会话发起协议（SIP）和会话描述协议（SDP）进行协商。本文档定义了使用MSRP建立多方聊天会话或聊天室的必要工具。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7701.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7701.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Motivations and Requirements ....................................6
4. Overview of Operation ...........................................7
4.1. Policy Attributes of the Chat Room ........................10
5. Creating, Joining, and Deleting a Chat Room ....................12
5.1. Creating a Chat Room ......................................12
5.2. Joining a Chat Room .......................................12
5.3. Deleting a Chat Room ......................................14
6. Sending and Receiving Instant Messages .........................14
6.1. Regular Messages ..........................................14
6.2. Private Messages ..........................................17
6.3. MSRP Reports and Responses ................................19
6.4. Congestion Avoidance ......................................20
7. Nicknames ......................................................21
7.1. Using Nicknames within a Chat Room ........................22
7.2. Modifying a Nickname ......................................24
7.3. Removing a Nickname .......................................25
7.4. Nicknames in Conference Event Packages ....................25
8. The SDP 'chatroom' Attribute ...................................25
9. Examples .......................................................28
9.1. Joining a Chat Room .......................................28
9.2. Setting Up a Nickname .....................................30
9.3. Sending a Regular Message to the Chat Room ................31
9.4. Sending a Private Message to a Participant ................33
9.5. Chunked Private Message ...................................35
9.6. Nickname in a Conference Information Document .............35
10. IANA Considerations ...........................................37
10.1. New MSRP Method ..........................................37
10.2. New MSRP Header ..........................................37
10.3. New MSRP Status Codes ....................................37
10.4. New SDP Attribute ........................................38
11. Security Considerations .......................................38
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................43
Acknowledgments ...................................................43
Contributors ......................................................43
Authors' Addresses ................................................44
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Motivations and Requirements ....................................6
4. Overview of Operation ...........................................7
4.1. Policy Attributes of the Chat Room ........................10
5. Creating, Joining, and Deleting a Chat Room ....................12
5.1. Creating a Chat Room ......................................12
5.2. Joining a Chat Room .......................................12
5.3. Deleting a Chat Room ......................................14
6. Sending and Receiving Instant Messages .........................14
6.1. Regular Messages ..........................................14
6.2. Private Messages ..........................................17
6.3. MSRP Reports and Responses ................................19
6.4. Congestion Avoidance ......................................20
7. Nicknames ......................................................21
7.1. Using Nicknames within a Chat Room ........................22
7.2. Modifying a Nickname ......................................24
7.3. Removing a Nickname .......................................25
7.4. Nicknames in Conference Event Packages ....................25
8. The SDP 'chatroom' Attribute ...................................25
9. Examples .......................................................28
9.1. Joining a Chat Room .......................................28
9.2. Setting Up a Nickname .....................................30
9.3. Sending a Regular Message to the Chat Room ................31
9.4. Sending a Private Message to a Participant ................33
9.5. Chunked Private Message ...................................35
9.6. Nickname in a Conference Information Document .............35
10. IANA Considerations ...........................................37
10.1. New MSRP Method ..........................................37
10.2. New MSRP Header ..........................................37
10.3. New MSRP Status Codes ....................................37
10.4. New SDP Attribute ........................................38
11. Security Considerations .......................................38
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................43
Acknowledgments ...................................................43
Contributors ......................................................43
Authors' Addresses ................................................44
The Message Session Relay Protocol (MSRP) [RFC4975] defines a mechanism for sending a series of instant messages within a session. The Session Initiation Protocol (SIP) [RFC3261] in combination with the Session Description Protocol (SDP) [RFC4566] allows for two peers to establish and manage such sessions.
消息会话中继协议（MSRP）[RFC4975]定义了在会话中发送一系列即时消息的机制。会话发起协议（SIP）[RFC3261]结合会话描述协议（SDP）[RFC4566]允许两个对等方建立和管理此类会话。
In another application of SIP, a User Agent (UA) can join in a multi-party conversation called a "conference" that is hosted by a specialized UA called a "focus" [RFC4353]. Such a conference can naturally involve MSRP sessions. It is the responsibility of an entity handling the media to relay IMs received from one participant to the rest of the participants in the conference.
在SIP的另一个应用中，用户代理（UA）可以加入称为“会议”的多方对话，该对话由称为“焦点”的专门UA主持[RFC4353]。这样的会议自然会涉及管理系统更新项目会议。处理媒体的实体有责任将从一名与会者收到的即时消息转发给会议的其他与会者。
Several such systems already exist in the Internet. Participants in a chat room can be identified with a pseudonym or nickname and can decide whether their real identifier is disclosed to other participants. Participants can also use a rich set of features such as the ability to send private instant messages to other participants.
互联网上已经有几个这样的系统。聊天室中的参与者可以用假名或昵称来识别，并可以决定是否向其他参与者透露他们的真实标识符。参与者还可以使用一组丰富的功能，例如向其他参与者发送私人即时消息的能力。
Similar conferences supporting chat room functionality are already available today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol (XMPP): Core [RFC6120], as well as many other proprietary systems. Specifying equivalent functionality for MSRP-based systems eases interworking between these systems.
支持聊天室功能的类似会议今天已经提供。例如，Internet中继聊天（IRC）[RFC2810]、可扩展消息和状态协议（XMPP）：核心[RFC6120]，以及许多其他专有系统。为基于MSRP的系统指定等效功能可以简化这些系统之间的互通。
This document defines requirements, conventions, and extensions for providing private messages and nickname management in centralized chat rooms with MSRP. Participants in a chat room can be identified by a pseudonym and decide if their real identifier should be disclosed to other participants. This memo uses the SIP Conferencing Framework [RFC4353] as a design basis. It also aims to be compatible with "A Framework for Centralized Conferencing" [RFC5239]. Should requirements arise, future mechanisms for providing similar functionality in generic conferences might be developed, for example, where the media is not only restricted to MSRP. The mechanisms described in this document provide a future compatible short-term solution for MSRP centralized chat rooms.
本文档定义了使用MSRP在集中式聊天室中提供私人消息和昵称管理的要求、约定和扩展。聊天室中的参与者可以通过笔名识别，并决定是否应该向其他参与者披露他们的真实标识符。本备忘录使用SIP会议框架[RFC4353]作为设计基础。它还旨在与“集中式会议框架”[RFC5239]兼容。如有需要，可制定今后在一般性会议中提供类似功能的机制，例如，媒体不仅限于管理系统更新项目。本文档中描述的机制为MSRP集中式聊天室提供了一个未来兼容的短期解决方案。
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 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中的描述进行解释，并指明符合性实施的要求级别。
This memo deals with "Tightly Coupled SIP Conferences" as defined in the SIP Conferencing Framework [RFC4353] and adopts the terminology from that document. In addition, we introduce some new terms:
本备忘录涉及SIP会议框架[RFC4353]中定义的“紧密耦合SIP会议”，并采用该文档中的术语。此外，我们还引入了一些新术语：
Nickname: a pseudonym or descriptive name associated with a participant. See Section 7 for details.
昵称：与参与者相关的笔名或描述性名称。详见第7节。
Multi-party Chat: an instance of a tightly coupled conference, in which the media exchanged between the participants consist of MSRP-based IMs. Also known as a chat room.
多方聊天：紧密耦合会议的一个实例，其中参与者之间交换的媒体由基于MSRP的IMs组成。也称为聊天室。
Chat Room: a synonym for a multi-party chat.
聊天室：多方聊天的同义词。
Chat Room URI: a URI that identifies a particular chat room and that is a synonym of a "Conference URI" as defined in RFC 4353 [RFC4353].
聊天室URI：标识特定聊天室的URI，是RFC 4353[RFC4353]中定义的“会议URI”的同义词。
Sender: the chat room participant who originally created an IM and sent it to the chat room server for further delivery.
发送者：最初创建IM并将其发送到聊天室服务器以进一步传递的聊天室参与者。
Recipient: the destination chat room participant(s). This defaults to the full conference participant list minus the IM Sender.
收件人：目标聊天室参与者。这默认为完整的会议参与者列表减去IM发送者。
MSRP Switch: a media-level entity that is an MSRP endpoint. It is a special MSRP endpoint that receives MSRP messages and delivers them to the other chat room participants. The MSRP switch has a similar role to a conference mixer with the exception that the MSRP switch does not actually "mix" together different input media streams; it merely relays the messages between chat room participants.
MSRP交换机：作为MSRP端点的媒体级实体。它是一个特殊的MSRP端点，用于接收MSRP消息并将其发送给其他聊天室参与者。MSRP交换机具有与会议混音器类似的作用，但MSRP交换机实际上不会将不同的输入媒体流“混合”在一起；它只是在聊天室参与者之间传递消息。
Private IM: an IM sent in a chat room intended for a single participant. Generally speaking, a private IM is seen by the MSRP switch, in addition to the sender and recipient. A private IM is usually rendered distinctly from the rest of the IMs, indicating that the message was a private communication.
私人即时通讯：在聊天室中发送给单个参与者的即时通讯。一般来说，除了发送方和接收方之外，MSRP交换机还可以看到私有IM。私有IM通常与IMs的其余部分不同，表明消息是私有通信。
Anonymous URI: a URI concealing the participant's SIP address of record (AOR) from the other participants in the chat room. The allocation of such a URI is out of scope of this specification. An anonymous URI must be valid for the length of the chat room
匿名URI：向聊天室中的其他参与者隐藏参与者SIP记录地址（AOR）的URI。这种URI的分配超出了本规范的范围。匿名URI必须在聊天室的长度内有效
session and will be utilized by the MSRP switch to forward messages to and from anonymous participants. Privacy and anonymity are discussed in greater detail in RFC 3323 [RFC3323] and RFC 3325 [RFC3325].
MSRP交换机将利用会话和向匿名参与者转发消息。RFC 3323[RFC3323]和RFC 3325[RFC3325]对隐私和匿名性进行了更详细的讨论。
Conference Event Package: a notification mechanism that allows conference participants to learn conference information including roster and state changes in a conference. This would typically be the mechanisms defined in "A Session Initiation Protocol (SIP) Event Package for Conference State" [RFC4575] or "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)" [RFC6502].
会议事件包：一种通知机制，允许会议参与者了解会议信息，包括会议中的花名册和状态更改。这通常是“会议状态的会话启动协议（SIP）事件包”[RFC4575]或“集中式会议的会议事件包数据格式扩展（XCON）”[RFC6502]中定义的机制。
Identifier: a string used to recognize or establish as being a particular user.
标识符：用于识别或确定为特定用户的字符串。
To log in: to enter identifying data, as a name or password, into a chat room, so as to be able to do work with the chat room.
登录：在聊天室中输入识别数据，如姓名或密码，以便能够在聊天室中工作。
Although conference frameworks describing many types of conferencing applications already exist, such as the one in "A Framework for Centralized Conferencing" [RFC5239] and the SIP Conferencing Framework [RFC4353], the exact details of session-based instant messaging conferences (chat rooms) are not well-defined at the moment.
尽管描述多种类型会议应用程序的会议框架已经存在，例如“集中式会议框架”[RFC5239]和SIP会议框架[RFC4353]中的会议框架，但基于会话的即时消息会议（聊天室）的确切细节目前尚未明确定义。
To allow interoperable chat implementations, for both conference-aware and conference-unaware UAs, certain conventions for MSRP chat rooms need to be defined. It also seems beneficial to provide a set of features that enhance the baseline multi-party MSRP in order to be able to create systems that have functionality on par with existing chat systems as well as to enable the building of interworking gateways to these existing chat systems.
为了实现可互操作的聊天实施，需要为会议感知和会议不感知的UAs定义MSRP聊天室的某些约定。它也似乎有益于提供一组增强基线多方MSRP的特征，以便能够创建与现有聊天系统具有同等功能的系统，以及能够建立互通网关到这些现有的聊天系统。
We define the following requirements:
我们定义了以下要求：
REQ-1: A basic requirement is the existence of a chat room, where participants can join and leave the chat room and exchange IMs with the rest of the participants.
REQ-1：基本要求是存在聊天室，参与者可以加入和离开聊天室，并与其他参与者交换即时消息。
REQ-2: A recipient of an IM in a chat room must be able to determine the identifier of the sender of the message. Note that the actual identifier depends on the one that was used by the sender when joining the chat room.
REQ-2：聊天室中IM的接收者必须能够确定消息发送者的标识符。请注意，实际标识符取决于发件人在加入聊天室时使用的标识符。
REQ-3: A recipient of an IM in a chat room must be able to determine the identifier of the recipient of received messages. For instance, the recipient of the message might be the entire chat room or a single participant (i.e., a private message). Note that the actual identifier may depend on the one that was used by the recipient when he or she joined the chat room.
REQ-3：聊天室中IM的收件人必须能够确定所接收消息的收件人的标识符。例如，消息的接收者可能是整个聊天室或单个参与者（即私人消息）。请注意，实际标识符可能取决于收件人加入聊天室时使用的标识符。
REQ-4: It must be possible to send a message to a single participant within the chat room (i.e., a private IM).
REQ-4：必须能够向聊天室中的单个参与者发送消息（即，私人IM）。
REQ-5: A chat room participant may have a nickname or pseudonym associated with their real identifier.
REQ-5：聊天室参与者可能有与其真实标识符相关联的昵称或假名。
REQ-6: It must be possible for a participant to change their nickname during the progress of the chat room session.
REQ-6：参与者必须能够在聊天室会话过程中更改其昵称。
REQ-7: It must be possible for a participant to be known only by an anonymous identifier and not their real identifier by the rest of the chat room.
REQ-7：聊天室的其他人必须知道参与者只有匿名标识符，而不是他们的真实标识符。
REQ-8: It must be possible for chat room participants to learn the chat room capabilities described in this document.
REQ-8：聊天室参与者必须能够学习本文档中描述的聊天室功能。
Before a chat room can be entered, it must be created. Users wishing to host a chat room themselves can, of course, do just that; their UA simply morphs from an ordinary UA into a special purpose one called a "Focus UA". Another, commonly used setup is one where a dedicated node in the network functions as a Focus UA.
在进入聊天室之前，必须先创建聊天室。当然，希望自己主持聊天室的用户可以这样做；他们的行动单位只是从普通行动单位转变为一种特殊用途的行动单位，称为“焦点行动单位”。另一种常用设置是网络中的专用节点作为焦点UA。
Each chat room has an identifier of its own: a SIP URI that participants use to join the chat room, e.g., by sending an INVITE request to it. The conference focus processes the invitations, and as such, maintains SIP dialogs with each participant. In a multi-party chat, or chat room, MSRP is one of the established media streams. Each chat room participant establishes an MSRP session with the MSRP switch, which is a special purpose MSRP application. The MSRP sessions can be relayed by one or more MSRP relays, which are specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1.
每个聊天室都有自己的标识符：参与者用来加入聊天室的SIPURI，例如通过向聊天室发送邀请请求。会议焦点处理邀请，并与每个参与者保持SIP对话。在多方聊天室中，MSRP是已建立的媒体流之一。每个聊天室参与者都使用MSRP开关建立MSRP会话，这是一个特殊用途的MSRP应用程序。MSRP会话可以由RFC 4976[RFC4976]中规定的一个或多个MSRP中继进行中继。这如图1所示。
MSRP Sessions
+--------------------------+
| |
+---+--+ +---+--+ |
| SIP | | SIP | |
| MSRP | | MSRP | +-----+-----+
|Client| |Client| | MSRP |
+---+--+ ++--+--+ | Relay |
| | \ +-----+-----+
SIP Dialogs | / +----+ |
| | \ | MSRP Sessions
+----+------+--+ | |
| | +-+-----+-----+
| Conference | | MSRP |
| Focus UA |........| Switch |
| | | |
+----+-------+-+ +-+-----+-----+
| \ | |
SIP Dialogs | | +------+ | MSRP Sessions
| \ / |
+---+--+ +-+--+-+ +-----+-----+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-----+-----+
+---+--+ +------+ |
| |
+--------------------------+
MSRP Sessions
MSRP Sessions
+--------------------------+
| |
+---+--+ +---+--+ |
| SIP | | SIP | |
| MSRP | | MSRP | +-----+-----+
|Client| |Client| | MSRP |
+---+--+ ++--+--+ | Relay |
| | \ +-----+-----+
SIP Dialogs | / +----+ |
| | \ | MSRP Sessions
+----+------+--+ | |
| | +-+-----+-----+
| Conference | | MSRP |
| Focus UA |........| Switch |
| | | |
+----+-------+-+ +-+-----+-----+
| \ | |
SIP Dialogs | | +------+ | MSRP Sessions
| \ / |
+---+--+ +-+--+-+ +-----+-----+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-----+-----+
+---+--+ +------+ |
| |
+--------------------------+
MSRP Sessions
Figure 1: Multi-party Chat Overview Shown with MSRP Relays and a Conference Focus UA
图1：使用MSRP中继和会议焦点UA显示的多方聊天概述
The MSRP switch is similar to a conference mixer in that it both handles media sessions with each of the participants and bridges these streams together. However, unlike a conference mixer, the MSRP switch merely forwards messages between participants: it doesn't actually mix the streams in any way. The system is illustrated in Figure 2.
MSRP交换机类似于会议混合器，它既处理与每个参与者的媒体会话，又将这些流连接在一起。然而，与会议混合器不同，MSRP交换机只是在参与者之间转发消息：它实际上并没有以任何方式混合流。该系统如图2所示。
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 2: Multi-party Chat in a Centralized Chat Room
图2：集中聊天室中的多方聊天
Typically, chat room participants also subscribe to a conference event package to gather information about the conference roster in the form of conference state notifications. For example, participants can learn about other participants' identifiers, including their nicknames.
通常，聊天室参与者还订阅会议事件包，以会议状态通知的形式收集有关会议排班的信息。例如，参与者可以了解其他参与者的标识符，包括他们的昵称。
All messages in the chat room use the Message/CPIM wrapper content type [RFC3862], to distinguish between private and regular messages. When a participant wants to send an instant message to the chat room, it constructs an MSRP SEND request and submits it to the MSRP switch including a regular payload (e.g., a Message/CPIM message that contains text, HTML, an image, etc.). The Message/CPIM To header is set to the chat room URI. The switch then fans out the SEND request to all of the other participants using their existing MSRP sessions.
聊天室中的所有消息都使用Message/CPIM包装内容类型[RFC3862]来区分私人消息和普通消息。当参与者想要向聊天室发送即时消息时，它会构造一个MSRP发送请求，并将其提交给MSRP交换机，包括一个常规负载（例如，包含文本、HTML、图像等的消息/CPIM消息）。消息/CPIM-To标题设置为聊天室URI。然后，交换机使用现有的MSRP会话将发送请求扇出到所有其他参与者。
A participant can also send a private IM addressed to a participant whose identifier has been learned, e.g., via a conference event package. In this case, the sender creates an MSRP SEND request with a Message/CPIM wrapper whose To header contains not the chat room URI but the recipient's URI. The MSRP switch then forwards the SEND request to that recipient. This specification supports the sending of private messages to one and only one recipient. However, if the
参与者还可以向其标识符已被学习的参与者发送专用IM，例如，通过会议事件包。在这种情况下，发送方使用消息/CPIM包装器创建一个MSRP发送请求，其To头不包含聊天室URI，而是包含接收方的URI。然后，MSRP交换机将发送请求转发给该收件人。此规范支持向一个且仅一个收件人发送私人消息。然而，如果
recipient is logged in from different endpoints, the MSRP switch will distribute the private message to each endpoint at which the recipient is logged in.
当收件人从不同的端点登录时，MSRP交换机会将私有消息分发到收件人登录的每个端点。
We extend the current MSRP negotiation that takes place in SDP [RFC4566] to allow participants to learn whether the chat room supports and is willing to accept (e.g., due to local policy restrictions) certain MSRP functions defined in this memo, such as nicknames or private messaging. This is achieved by a new 'chatroom' attribute in SDP (please refer to Section 8 for a detailed description).
我们扩展了SDP[RFC4566]中当前的MSRP协商，以允许参与者了解聊天室是否支持并愿意接受（例如，由于当地政策限制）本备忘录中定义的某些MSRP功能，如昵称或私人消息。这是通过SDP中的一个新的“聊天室”属性实现的（有关详细说明，请参阅第8节）。
Naturally, when a participant wishes to leave a chat room, it sends a SIP BYE request to the Focus UA and terminates the SIP dialog with the focus and MSRP sessions with the MSRP switch.
当然，当参与者希望离开聊天室时，它会向Focus UA发送SIP BYE请求，并使用Focus和MSRP交换机终止SIP对话和MSRP会话。
This document assumes that each chat room is allocated its own SIP URI. A user joining a chat room sends an INVITE request to that SIP URI, and, as a result, a new MSRP session is established between the user and the MSRP switch. It is assumed that an MSRP session is mapped to a chat room. If a user wants to join a second chat room, he creates a different INVITE request, through a different SIP dialog, which leads to the creation of a second MSRP session between the user and the MSRP switch. Notice that these two MSRP sessions can still be multiplexed over the same TCP connection as per regular MSRP procedures. However, each chat room is associated with a unique MSRP session and a unique SIP dialog.
本文档假设每个聊天室都分配了自己的SIPURI。加入聊天室的用户向该SIP URI发送INVITE请求，结果，在用户和MSRP交换机之间建立新的MSRP会话。假设MSRP会话映射到聊天室。如果用户想要加入第二个聊天室，他会通过不同的SIP对话框创建不同的INVITE请求，从而在用户和MSRP交换机之间创建第二个MSRP会话。请注意，这两个MSRP会话仍然可以按照常规MSRP过程通过相同的TCP连接进行多路复用。但是，每个聊天室都与唯一的MSRP会话和唯一的SIP对话框相关联。
The Conference Framework with SIP [RFC4353] introduces the notion of a Conference Policy as "The complete set of rules governing a particular conference." A chat room is a specialized type of conference, and the conference policy is sometimes extended with new chat-specific rules. This section lists all the Conference Policy attributes used by the present document and refers to sections in the document where the usage of these attributes are described in greater detail.
SIP[RFC4353]的会议框架引入了会议策略的概念，即“管理特定会议的完整规则集”。聊天室是一种特殊类型的会议，会议策略有时会通过新的聊天特定规则进行扩展。本节列出了本文档使用的所有会议策略属性，并参考了文档中更详细描述这些属性用法的章节。
Nicknames: Whether the chat room accepts users to be recognized with a nickname. See Sections 7, 7.1, and 8 for details. Also, the scope of uniqueness of the nickname: the chat room (conference instance), a realm or domain, a server, etc.
昵称：聊天室是否接受使用昵称识别的用户。详见第7、7.1和8节。此外，昵称的唯一性范围：聊天室（会议实例）、领域或域、服务器等。
Nickname quarantine: The quarantine to be imposed on a nickname once it is not currently in use (e.g., because the participant holding this nickname abandons the chat room), prior to the wide availability of this nickname to other users. This allows the initial holder of the nickname to join the chat room during the quarantine period and claim the same nickname they were previously using. See Section 11 for details.
昵称隔离：在其他用户广泛使用昵称之前，一旦昵称当前未被使用（例如，因为持有该昵称的参与者放弃了聊天室），就对其进行隔离。这允许昵称的初始持有者在隔离期间加入聊天室，并声明他们以前使用的相同昵称。详情见第11节。
Private messaging: Whether the chat room allows users to send private messages to other users of the chat room through the MSRP switch. See Sections 6.2 and 8 for details.
私人消息：聊天室是否允许用户通过MSRP交换机向聊天室的其他用户发送私人消息。详见第6.2节和第8节。
Deletion of the chat room: Whether the chat room can be deleted when the creator leaves the chat room or through an out-of-band mechanism. See Section 5.3 for details.
删除聊天室：是否可以在创建者离开聊天室时删除聊天室，或通过带外机制删除聊天室。详见第5.3节。
Simultaneous access: Whether a user can log in from different endpoints using the same identity. See Sections 6.1 and 6.2 for details.
同时访问：用户是否可以使用相同的身份从不同的端点登录。详见第6.1节和第6.2节。
Force TLS transport: Whether the MSRP switch accepts only Transport Layer Security (TLS) as an MSRP transport, in an effort to guarantee confidentiality and privacy. See Section 11 for details.
强制TLS传输：MSRP交换机是否仅接受传输层安全性（TLS）作为MSRP传输，以确保机密性和隐私性。详情见第11节。
Maximum message size in congested MSRP sessions: The maximum size of messages that can be distributed to a user over a congested MSRP session. See Section 6.4 for details.
拥挤的MSRP会话中的最大消息大小：在拥挤的MSRP会话中可以分发给用户的消息的最大大小。详见第6.4节。
Chunk reception timer: The value of a time that controls the maximum time that the MSRP switch is waiting for the reception of different chunks belonging to the same message. If the timer expires, the MSRP switch will discard the associated message state. See Section 6.1 for details.
区块接收计时器：控制MSRP开关等待接收属于同一消息的不同区块的最大时间的时间值。如果计时器过期，MSRP开关将放弃相关的消息状态。详见第6.1节。
Supported wrapped media types: The list of media types that the MSRP switch accepts in Message/CPIM wrappers sent from participants. This list is included in the 'accept-wrapped-types' attribute of the MSRP message media line in SDP. If the MSRP switch accepts additional media types to those explicitly listed, a "*" is added to the list. A single "*" indicates that the chat room accepts any wrapped media type.
支持的包装媒体类型：MSRP交换机在参与者发送的消息/CPIM包装中接受的媒体类型列表。此列表包含在SDP中MSRP消息媒体行的“接受包装类型”属性中。如果MSRP交换机接受明确列出的媒体类型之外的其他媒体类型，则会在列表中添加“*”。单个“*”表示聊天室接受任何包装的媒体类型。
Since we consider a chat room a particular type of conference having MSRP media, the methods defined by the SIP Conference Framework [RFC4353] for creating conferences are directly applicable to a chat room.
由于我们认为聊天室是具有MSRP媒体的特定类型的会议，所以由SIP会议框架[RCF4353]定义的用于创建会议的方法可直接应用于聊天室。
Once a chat room is created, it is identified by a SIP URI, like any other conference.
一旦创建了聊天室，它就会像任何其他会议一样由SIPURI标识。
Participants usually join the chat room by sending an INVITE request to the chat room URI. The chat room then uses regular SIP mechanisms to authenticate the participant. This may include, e.g., client certificates, SIP Digest authentication [RFC3261], asserted network identity [RFC3325], SIP Identity header field [RFC4474], etc. As long as the user is authenticated, the INVITE request is accepted by the focus and the user is brought into the actual chat room.
参与者通常通过向聊天室URI发送邀请请求来加入聊天室。然后，聊天室使用常规SIP机制对参与者进行身份验证。这可能包括，例如，客户端证书、SIP摘要认证[RFC3261]、断言的网络标识[RFC3325]、SIP标识头字段[RFC4474]等。只要用户经过认证，焦点就会接受邀请请求，并将用户带入实际的聊天室。
This specification requires all IMs to be wrapped in a Message/CPIM wrapper [RFC3862]. Therefore, the 'accept-types' attribute for the MSRP message media in both the SDP offer and answer need to include at least the value 'Message/CPIM' (notice that RFC 4975 [RFC4975] mandates this 'accept-types' attribute in SDP). If the 'accept-types' attribute does not contain the value 'Message/CPIM', the conference focus will reject the request. The actual instant message payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). There is no default wrapped type. Typical wrapped type values can include text/plain, text/html, image/jpeg, image/png, audio/mp3, etc. It is RECOMMENDED that participant endpoints add an 'accept-wrapped-types' attribute to the MSRP 'message' media line in SDP, where the supported wrapped types are declared, as per RFC 4975 procedures [RFC4975].
本规范要求将所有IMs包装在消息/CPIM包装中[RFC3862]。因此，SDP报价和应答中MSRP消息媒体的“接受类型”属性至少需要包含“消息/CPIM”值（请注意，RFC 4975[RFC4975]在SDP中强制要求此“接受类型”属性）。如果“接受类型”属性不包含值“Message/CPIM”，则会议焦点将拒绝该请求。实际的即时消息有效负载类型在SDP中的“接受包装类型”属性中协商（有关详细信息，请参阅RFC 4975[RFC4975]）。没有默认的包装类型。典型的包装类型值可以包括text/plain、text/html、image/jpeg、image/png、audio/mp3等。建议参与者端点向SDP中的MSRP“message”媒体行添加“accept wrapped types”属性，其中根据RFC 4975过程[RFC4975]声明支持的包装类型。
The MSRP switch needs to be aware of the URIs of the participant (SIP, tel, or IM URIs) in order to validate messages sent from this participant prior to their forwarding. This information is known to the focus of the conference. Therefore, an interface between the focus and the MSRP switch is assumed. However, the interface between the focus and the MSRP switch is outside the scope of this document.
MSRP交换机需要知道参与者的URI（SIP、tel或IM URI），以便在转发之前验证该参与者发送的消息。这一信息为会议的焦点所知。因此，假设焦点和MSRP开关之间存在接口。但是，focus和MSRP交换机之间的接口不在本文件范围内。
Conference-aware participants will detect that the peer is a focus due to the presence of the "isfocus" feature tag [RFC3840] in the Contact header field of the 200-class response to the INVITE request. Conference-unaware participants will not notice it is a focus, and
会议感知参与者将检测到，由于在200类对INVITE请求的响应的Contact header字段中存在“isfocus”功能标签[RFC3840]，因此对等方是焦点。会议参与者不会注意到这是一个焦点，并且
cannot apply the additional mechanisms defined in this document. Participants are also aware that the mixer is an MSRP switch due to the presence of a 'message' media type and either TCP/MSRP or TCP/TLS/MSRP as the protocol field in the media line of SDP [RFC4566].
无法应用此文档中定义的其他机制。参与者还知道，由于存在“消息”媒体类型，且SDP[RFC4566]媒体线路中的协议字段为TCP/MSRP或TCP/TLS/MSRP，因此混音器是MSRP交换机。
The conference focus of a chat room MUST only use a Message/CPIM [RFC3862] top-level wrapper as a payload of MSRP messages, and the focus MUST declare it in the SDP offer or answer as per regular procedures in RFC 4975 [RFC4975]. This implies that if the conference focus receives, from a participant's endpoint, an SDP offer that does not include the value 'Message/CPIM' in the 'accept-types' attribute for the MSRP message media line, the conference focus SHOULD either reject the MSRP message media stream or reject the complete SDP offer by using regular SIP or SDP procedures (e.g., creating an SDP answer that sets to zero the port of the MSRP message media line, responding the INVITE with a 488 response, etc.).
聊天室的会议焦点必须仅使用消息/CPIM[RFC3862]顶级包装器作为MSRP消息的有效负载，并且焦点必须按照RFC 4975[RFC4975]中的常规程序在SDP报价或应答中声明。这意味着，如果会议焦点从参与者的端点接收到SDP报价，该报价不包括MSRP消息媒体行的“接受类型”属性中的值“Message/CPIM”，会议焦点应通过使用常规SIP或SDP程序拒绝MSRP消息媒体流或拒绝完整的SDP提议（例如，创建SDP应答，将MSRP消息媒体线路的端口设置为零，以488响应邀请，等等）。
If the conference focus accepts the participant's SDP offer, when the conference focus generates the SDP answer, it MUST set the 'accept-types' attribute for the MSRP message media line to a value of 'Message/CPIM'. This specification requires all IMs to be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types' attribute in this SDP body contains a single value of 'Message/CPIM'. The actual IM payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). The conference focus MAY also add an 'accept-wrapped-types' attribute to the MSRP message media line in SDP containing the supported wrapped types, according to the supported wrapped media types policy.
如果会议中心接受参与者的SDP报价，当会议中心生成SDP应答时，必须将MSRP消息媒体行的“接受类型”属性设置为“消息/CPIM”值。此规范要求将所有IMs包装在消息/CPIM包装中，因此，此SDP正文中的“accept types”属性包含单个值“Message/CPIM”。实际IM有效负载类型在SDP中的“接受包装类型”属性中协商（有关详细信息，请参阅RFC 4975[RFC4975]）。根据支持的包装媒体类型策略，会议焦点还可以向SDP中包含支持的包装类型的MSRP消息媒体行添加“接受包装类型”属性。
Note that the Message/CPIM wrapper is used to carry the sender information that, otherwise, it will not be available to the recipient. Additionally, the Message/CPIM wrapper carries the recipient information (e.g., To and Cc headers).
请注意，邮件/CPIM包装用于承载发件人信息，否则收件人将无法使用这些信息。此外，消息/CPIM包装器携带收件人信息（例如，收件人和抄送头）。
If the UA supports anonymous participation and the user chooses to use it, the participant's UA SHOULD do at least one of these options:
如果UA支持匿名参与且用户选择使用，则参与者的UA应至少执行以下选项之一：
(a) provide an anonymous URI in SIP headers that otherwise reveal identifiers. Please refer to RFC 3323 [RFC3323] for a detailed description of which headers are subject to reveal identifiers and how to populate them; or
(a) 在SIP头中提供匿名URI，否则会显示标识符。请参考RFC 3323[RFC3323]了解哪些标题会显示标识符以及如何填充这些标识符的详细说明；或
(b) trust the conference focus and request privacy of their URI, e.g., by means of the SIP Privacy header field [RFC3323], network asserted identity [RFC3325], or a similar privacy mechanism.
(b) 信任会议焦点并请求其URI的隐私，例如，通过SIP隐私头字段[RFC3323]、网络断言标识[RFC3325]或类似的隐私机制。
If the participant has requested privacy, the conference focus MUST expose a participant's anonymous URI through the conference event package [RFC4575].
如果参与者请求隐私，会议焦点必须通过会议事件包[RFC4575]公开参与者的匿名URI。
The conference focus of a chat room learns the supported chat room capabilities in the endpoint by means of the 'chatroom' attribute exchanged in the SDP offer/answer (please refer to Section 8 for a detailed description). The conference focus MUST inform the MSRP switch of the chat room capabilities of each participant that joins the chat room (note that the interface defined between the conference focus and the MSRP switch is outside the scope of this specification). This information allows the MSRP switch, e.g., to avoid the distribution of private messages to participants whose endpoints do not support private messaging.
聊天室的会议焦点通过在SDP提供/应答中交换的“聊天室”属性学习端点中支持的聊天室功能（有关详细说明，请参阅第8节）。会议焦点必须通知MSRP交换机加入聊天室的每个参与者的聊天室功能（注意，会议焦点和MSRP交换机之间定义的接口不在本规范的范围内）。该信息允许MSRP交换机避免将私有消息分发给端点不支持私有消息的参与者。
As with creating a conference, the methods defined by the SIP Conference Framework [RFC4353] for deleting a conference are directly applicable to a chat room. The MSRP switch will terminate the MSRP sessions with all the participants.
与创建会议一样，SIP会议框架[RFC4353]定义的用于删除会议的方法直接适用于聊天室。MSRP交换机将终止与所有参与者的MSRP会话。
Deleting a chat room is an action that heavily depends on the policy of the chat room. For example, the policy can determine whether the chat room is deleted when the creator leaves the room or whether an out-of-band mechanism is responsible for the deletion.
删除聊天室在很大程度上取决于聊天室的策略。例如，该策略可以确定是否在创建者离开聊天室时删除聊天室，或者是否由带外机制负责删除。
This section describes the conventions used to send and receive IMs that are addressed to all the participants in the chat room. These are sent over a regular MSRP SEND request that contains a Message/ CPIM wrapper [RFC3862] that, in turn, contains the desired payload (e.g., text, image, video clip, etc.).
本节介绍用于发送和接收发送至聊天室中所有参与者的即时消息的约定。这些信息通过常规MSRP发送请求发送，该请求包含消息/CPIM包装[RFC3862]，该包装又包含所需的有效负载（例如，文本、图像、视频剪辑等）。
When a chat room participant wishes to send an instant message to all the other participants in the chat room, it constructs an MSRP SEND request according to the procedures specified in RFC 4975 [RFC4975]. The sender MAY choose the desired MSRP report model (e.g., populate the Success-Report and Failure-Report MSRP header fields).
当聊天室参与者希望向聊天室中的所有其他参与者发送即时消息时，它将根据RFC 4975[RFC4975]中指定的过程构造MSRP发送请求。发送方可以选择所需的MSRP报告模型（例如，填充成功报告和失败报告MSRP标题字段）。
On sending a regular message, the sender MUST populate the To header of the Message/CPIM wrapper with the URI of the chat room. The sender MUST also populate the From header of the Message/CPIM wrapper with a proper identifier by which the user is recognized in the chat room. Identifiers that can be used (among others) are:
在发送常规邮件时，发件人必须使用聊天室的URI填充邮件/CPIM包装的To标头。发送者还必须使用适当的标识符填充消息/CPIM包装的From标头，通过该标识符可以在聊天室中识别用户。可使用的标识符（除其他外）包括：
o A SIP URI [RFC3261] representing the participant's address-of-record
o 代表参与者记录地址的SIP URI[RFC3261]
o A tel URI [RFC3966] representing the participant's telephone number
o 代表参与者电话号码的电话URI[RFC3966]
o An IM URI [RFC3860] representing the participant's instant messaging address
o 表示参与者即时消息地址的IM URI[RFC3860]
o An anonymous URI representing the participant's anonymous address
o 表示参与者匿名地址的匿名URI
If the participant wants to remain anonymous, the participant's endpoint MUST populate an anonymous URI in the From header of the Message/CPIM wrapper. Other participants of the chat room will use this anonymous URI in the To header of the Message/CPIM wrapper when sending private messages. Notice that in order for the anonymity mechanism to work, the anonymous URI MUST NOT reveal the participant's SIP AOR. The mechanism for acquiring an anonymous URI is outside the scope of this specification.
如果参与者希望保持匿名，则参与者的端点必须在消息/CPIM包装的From头中填充匿名URI。聊天室的其他参与者在发送私人消息时将在Message/CPIM包装的To头中使用此匿名URI。请注意，为了使匿名机制工作，匿名URI不能透露参与者的SIPAOR。获取匿名URI的机制不在本规范的范围内。
An MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI of a participant. This imposes a requirement for the focus of the conference to inform the MSRP switch of the URIs by which the participant is known, in order for the MSRP switch to validate messages. Section 6.3 provides further information with the actions to be taken in case this validation fails.
从参与者接收发送请求的MSRP交换机应首先验证消息/CPIM包装的from标头字段是否正确填充了参与者的有效URI。这就要求会议的焦点通知MSRP交换机参与者已知的URI，以便MSRP交换机验证消息。第6.3节提供了进一步的信息，说明在验证失败时应采取的措施。
Then the MSRP switch should inspect the To header field of the Message/CPIM wrapper. If the MSRP switch receives a message containing several To header fields in the Message/CPIM wrapper the MSRP switch MUST reject the MSRP SEND request with a 403 response, as per procedures in RFC 4975 [RFC4975]. Then, if the To header field of the Message/CPIM wrapper contains the chat room URI and there are no other To header fields, the MSRP switch can generate a copy of the SEND request to each of the participants in the chat room except the sender. The MSRP switch MUST NOT modify the content received in the SEND request. However, the MSRP switch MAY re-chunk any of the outbound MSRP SEND requests.
然后，MSRP开关应该检查消息/CPIM包装的To头字段。如果MSRP交换机接收到消息/CPIM包装中包含多个To报头字段的消息，则MSRP交换机必须根据RFC 4975[RFC4975]中的程序以403响应拒绝MSRP发送请求。然后，如果消息/CPIM包装的To header字段包含聊天室URI，并且没有其他To header字段，则MSRP开关可以向聊天室中除发送者之外的每个参与者生成发送请求的副本。MSRP开关不得修改发送请求中接收的内容。然而，MSRP交换机可以重新分块任何出站MSRP发送请求。
When generating a copy of the SEND request to each participant in the chat room, the MSRP switch MUST evaluate the wrapped media types that the recipient is able to accept. This was learned through the 'accept-wrapped-types' attribute of the MSRP message media line in SDP. If the MSRP switch is aware that the media type of the wrapped content is not acceptable to the recipient, the MSRP switch SHOULD NOT forward this message to that endpoint. Note that this version of
当向聊天室中的每个参与者生成发送请求的副本时，MSRP开关必须评估收件人能够接受的包装媒体类型。这是通过SDP中MSRP消息媒体行的“接受包装类型”属性了解到的。如果MSRP交换机知道收件人不接受包装内容的媒体类型，则MSRP交换机不应将此消息转发给该端点。请注意，此版本的
the specification does not require the MSRP switch to notify the sender about this failure. Extensions to this specification may improve handling of unknown media types.
本规范不要求MSRP交换机将此故障通知发送方。对本规范的扩展可以改进未知媒体类型的处理。
Note that the MSRP switch does not need to wait for the reception of the complete MSRP chunk or MSRP message before it starts the distribution to the rest of the participants. Instead, once the MSRP switch has received the headers of the Message/CPIM wrapper, it SHOULD start the distribution process. But, bear in mind that the MSRP switch SHOULD still implement some sanity checking. Please refer to the security considerations in Section 11 for further details.
请注意，MSRP交换机在开始向其余参与者分发之前，无需等待接收完整的MSRP区块或MSRP消息。相反，一旦MSRP交换机接收到消息/CPIM包装的头，它应该启动分发过程。但是，请记住，MSRP交换机仍应执行一些健全性检查。有关更多详细信息，请参阅第11节中的安全注意事项。
When forwarding chunked messages as soon as they are received, the Message/CPIM wrapper is only present at the beginning of the message, typically within the first chunk. Subsequent chunks will contain the rest of the message, but not the Message/CPIM headers. Therefore, an MSRP switch that receives a subsequent message may face challenges in determining the correct list of recipients of the message. An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-ID of the MSRP message to correlate the different chunks; it MUST also temporarily store the list of recipients to which the initial chunks were delivered. The MSRP switch SHOULD forward subsequent chunks only to those recipients who were sent the initial chunks, except if the MSRP switch has knowledge that one of the recipients of the initial chunks has dropped from the chat room. This behavior also avoids new participants who had joined the chat room when the first chunk was distributed from receiving subsequent chunks that would otherwise need to be discarded.
当收到分块消息后立即转发它们时，消息/CPIM包装器仅出现在消息的开头，通常在第一个分块中。后续块将包含消息的其余部分，但不包含消息/CPIM头。因此，接收后续消息的MSRP交换机在确定消息的正确接收者列表时可能面临挑战。使用此快速转发过程的MSRP交换机必须临时存储MSRP消息的消息ID，以关联不同的块；它还必须临时存储初始块传递到的收件人列表。MSRP开关应仅将后续区块转发给发送初始区块的收件人，除非MSRP开关知道初始区块的其中一个收件人已从聊天室中删除。这种行为还可以避免在分发第一个区块时加入聊天室的新参与者接收后续区块，否则这些区块将需要丢弃。
Once the MSRP switch receives the last chunk of a message, and that chunk is successfully sent to each of the recipients, the MSRP switch discards the temporary storage of MSRP Message-ID and the associated list of recipients.
一旦MSRP交换机接收到消息的最后一个区块，并且该区块成功发送给每个收件人，MSRP交换机将丢弃MSRP消息ID和相关收件人列表的临时存储。
In some occasions, a sender might suffer a transport error condition (such as loss of connectivity or depletion of battery) that makes the sending of a message incomplete, e.g., some chunks were received by the MSRP switch, but not all of them. This is a behavior already considered in the core MSRP specification (see RFC 4975 [RFC4975] Section 5.4). The problem in the context of a chat room lies with the use of temporary storage for fast forwarding. In order to prevent attacks related to the exhaustion of temporary storage of chunked messages, on receiving a first chunk of a message, where the MSRP switch is using the fast forward method, the MSRP switch MUST set a chunk reception timer for controlling the reception of the remaining chunks.
在某些情况下，发送方可能会遇到传输错误情况（如连接中断或电池电量耗尽），从而导致消息发送不完整，例如，MSRP交换机接收到一些数据块，但并非全部数据块。这是核心MSRP规范中已经考虑的行为（参见RFC 4975[RFC4975]第5.4节）。聊天室环境中的问题在于使用临时存储进行快速转发。为了防止与耗尽分块消息的临时存储有关的攻击，在MSRP交换机使用快进方法接收消息的第一个分块时，MSRP交换机必须设置分块接收计时器以控制剩余分块的接收。
This chunk reception timer can be reset every time a new chunk of the same message is received. When this timer expires, the MSRP switch MUST consider that the sending of the message was aborted, and it MAY discard all the message state associated with it, including the Message-ID and the list of recipients. Additionally, if this chunk reception timer expires, the MSRP switch MAY choose to send an abort chunk (i.e., one with the "#" flag set) to each to the recipients. This is just an optimization, since MSRP endpoints need to be able to handle incomplete messages as per regular MSRP.
每次接收到同一消息的新块时，可以重置该块接收计时器。当这个定时器到期时，MSRP交换机必须考虑消息的发送中止，并且它可能丢弃与它相关联的所有消息状态，包括消息ID和接收者列表。此外，如果此区块接收计时器过期，MSRP开关可以选择向每个收件人发送中止区块（即设置了“#”标志的区块）。这只是一个优化，因为MSRP端点需要能够按照常规MSRP处理不完整的消息。
The specific value of this chunk reception timer is not standardized; it is subject of local policy. However, it is recommended not to be a short value. For example, a time interval on the order of a normal TCP timeout (i.e., around 540 seconds) would be reasonable. A value on the order of a few seconds would not.
该区块接收定时器的具体值未标准化；这是当地政策的主题。但是，建议不要为短值。例如，正常TCP超时的时间间隔（即大约540秒）是合理的。几秒钟左右的值将不起作用。
An MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM wrapper. If the To header field is set to the chat room URI, it should render it as a regular message that has been distributed to all the participants in the chat room. Then, the MSRP endpoint SHOULD inspect the From header field of the Message/ CPIM wrapper to identify the sender. The From header field will include a URI that identifies the sender. The endpoint might have also received further identifier information through a subscription to a conference event package.
从包含消息/CPIM包装器的MSRP交换机接收发送请求的MSRP端点应首先检查消息/CPIM包装器的To标头字段。如果To header字段设置为聊天室URI，则应将其呈现为已分发给聊天室中所有参与者的常规消息。然后，MSRP端点应该检查Message/CPIM包装的From header字段，以识别发送者。“发件人标头”字段将包含标识发件人的URI。端点还可能通过对会议事件包的订阅接收到进一步的标识符信息。
It is possible that a participant, identified by a SIP AoR or other valid URI, joins a chat room simultaneously from two or more different SIP UAs. It is recommended that the MSRP switch implements means to map a URI to two or more MSRP sessions. If the policy of the chat room allows simultaneous access, the MSRP switch MUST copy all regular messages intended to the recipient through each MSRP session mapped to the recipient's URI.
由SIP AoR或其他有效URI标识的参与者可能同时从两个或多个不同的SIP ua加入聊天室。建议MSRP交换机实现将URI映射到两个或多个MSRP会话的方法。如果聊天室的策略允许同时访问，则MSRP交换机必须通过映射到收件人URI的每个MSRP会话复制所有发送给收件人的常规邮件。
This section describes the conventions used to send and receive private IMs, i.e., IMs that are addressed to one participant of the chat room rather than to all of them. The chat room has a local policy that determines whether or not private messages are supported. A chat room can signal support for private messages using the 'chatroom' attribute in SDP (please refer to Section 8 for a detailed description).
本节描述了用于发送和接收私人即时消息的约定，即发送给聊天室的一个参与者而不是所有参与者的即时消息。聊天室有一个本地策略，用于确定是否支持私人消息。聊天室可以使用SDP中的“chatroom”属性发出支持私人消息的信号（有关详细说明，请参阅第8节）。
When a chat room participant wishes to send a private IM to a participant in the chat room, it follows the same procedures to create a SEND request as for regular messages (Section 6.1). The
当聊天室参与者希望向聊天室中的参与者发送私人即时消息时，创建发送请求的过程与创建普通消息的过程相同（第6.1节）。这个
only difference is that the MSRP endpoint MUST populate a single To header of the Message/CPIM wrapper with the identifier of the intended recipient. The identifier can be SIP, tel, and im URIs typically learned from the information received in notifications of a conference event package.
唯一的区别是，MSRP端点必须使用预期收件人的标识符填充消息/CPIM包装的单个To头。标识符可以是SIP、tel和imuri，这些uri通常是从会议事件包的通知中接收到的信息中学习到的。
This version of the specification does not support sending a private message to multiple recipients, i.e., the presence of multiple To headers in the Message/CPIM wrapper of the MSRP SEND request. This is due to added complexity, for example, with the need to determine whether a message was not delivered to some of the intended recipients. Implementations that still want to recreate this function can send a series of single private messages, one private message per intended recipient. The endpoint can correlate this series of messages and create the effect of a private message addressed to multiple recipients.
此版本的规范不支持向多个收件人发送私人消息，即MSRP发送请求的消息/CPIM包装中存在多个to头。这是由于增加了复杂性，例如，需要确定邮件是否未送达某些预期收件人。仍然希望重新创建此函数的实现可以发送一系列单独的私有消息，每个预期收件人一条私有消息。端点可以关联这一系列消息，并创建发送给多个收件人的私人消息的效果。
As for regular messages, an MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI (i.e., the URI is a participant of this chat room). Section 6.3 provides further information regarding the actions to be taken in case this validation fails.
对于常规消息，从参与者接收发送请求的MSRP交换机应首先验证消息/CPIM包装的from标头字段是否正确填充了有效URI（即URI是此聊天室的参与者）。第6.3节提供了有关验证失败时应采取的措施的进一步信息。
Then, the MSRP switch inspects the To header field of the Message/ CPIM wrapper. If the MSRP switch receives a message containing several To header fields in the Message/CPIM wrapper, the MSRP switch MUST reject the MSRP SEND request with a 403 response, as per procedures in RFC 4975 [RFC4975]. Then, the MSRP switch verifies that the To header of the Message/CPIM wrapper matches the URI of a participant of the chat room. If this To header field does not contain the URI of a participant of the chat room or if the To header field cannot be resolved (e.g., caused by a mistyped URI), the MSRP switch MUST reject the request with a 404 response. This new 404 status code indicates a failure to resolve the recipient URI in the To header field of the Message/CPIM wrapper.
然后，MSRP开关检查消息/CPIM包装的To头字段。如果MSRP交换机接收到消息/CPIM包装中包含多个To报头字段的消息，则MSRP交换机必须按照RFC 4975[RFC4975]中的程序，以403响应拒绝MSRP发送请求。然后，MSRP开关验证消息/CPIM包装的To头是否与聊天室参与者的URI匹配。如果此To header字段不包含聊天室参与者的URI，或者如果To header字段无法解析（例如，由键入错误的URI引起），则MSRP交换机必须以404响应拒绝请求。这个新的404状态代码表示无法解析消息/CPIM包装的to header字段中的收件人URI。
Notice the importance of the From and To headers in the Message/ CPIM wrapper. If an intermediary modifies these values, the MSRP switch might not be able to identify the source or intended destination of the message, resulting in a rejection of the message.
请注意消息/CPIM包装中From和To头的重要性。如果中介修改这些值，MSRP开关可能无法识别消息的源或预期目标，从而导致消息被拒绝。
Finally, the MSRP switch verifies that the recipient supports private messages. If the recipient does not support private messages, the MSRP switch MUST reject the request with a 428 response. This new 428 response indicates that the recipient does not support private messages. Any potential REPORT request that the MSRP switch sends to
最后，MSRP交换机验证收件人是否支持私人消息。如果收件人不支持私人消息，MSRP交换机必须以428响应拒绝请求。此新的428响应表示收件人不支持私人邮件。MSRP交换机发送到的任何潜在报告请求
the sender MUST include a Message/CPIM wrapper containing the original From header field included in the SEND request and the To header field of the original Message/CPIM wrapper. The MSRP switch MUST NOT forward private messages to a recipient that does not support private messaging.
发送方必须包含一个消息/CPIM包装，其中包含发送请求中包含的原始发件人标头字段和原始消息/CPIM包装的收件人标头字段。MSRP交换机不得将私人消息转发给不支持私人消息的收件人。
If successful, the MSRP switch should search its mapping table to find the MSRP sessions established toward the recipient. If a match is found, the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it.
如果成功，MSRP交换机应搜索其映射表，以查找针对收件人建立的MSRP会话。如果找到匹配项，MSRP开关必须创建一个发送请求，并且必须将发送者消息的内容复制到它。
An MSRP endpoint that receives a SEND request from the MSRP switch does the same validations as for regular messages (Section 6.1). If the To header field is different from the chat room URI, the MSRP endpoints know that this is a private message. The endpoint should render who it is from based on the value of the From header of the Message/CPIM wrapper. The endpoint can also use the sender's nickname, possibly learned via a conference event package, to render the sender of the message, instead of using the sender's actual URI.
从MSRP交换机接收发送请求的MSRP端点执行与常规消息相同的验证（第6.1节）。如果To header字段与聊天室URI不同，则MSRP端点会知道这是一条私人消息。端点应该根据消息/CPIM包装器的from头的值呈现它来自谁。端点还可以使用发送者的昵称（可能通过会议事件包学习）来呈现消息的发送者，而不是使用发送者的实际URI。
As with regular messages, if the policy of the chat room allows simultaneous access, the MSRP switch MUST copy all private messages intended to the recipient through each MSRP session mapped to the recipient's URI.
与普通邮件一样，如果聊天室的策略允许同时访问，MSRP交换机必须通过映射到收件人URI的每个MSRP会话复制所有发送给收件人的私人邮件。
This section discusses the common procedures for regular and private messages with respect to MSRP reports and responses. Any particular procedure affecting only regular messages or only private messages is discussed in the previous sections (Sections 6.1 or 6.2, respectively).
本节讨论与管理系统更新项目报告和回复相关的常规和私人信息的通用程序。在前面的章节（分别为第6.1节或第6.2节）中讨论了仅影响常规消息或仅影响私人消息的任何特定过程。
MSRP switches MUST follow the success report and failure report handling described in Section 7 of RFC 4975 [RFC4975], complemented with the procedures described in this section. The MSRP switch MUST act as an MSRP endpoint receiver of the request, according to Section 5.3 of RFC 4975 [RFC4975].
MSRP交换机必须遵循RFC 4975[RFC4975]第7节所述的成功报告和故障报告处理，并辅以本节所述的程序。根据RFC 4975[RFC4975]第5.3节，MSRP交换机必须充当请求的MSRP端点接收器。
If the MSRP switch receives an MSRP SEND request that does not contain a Message/CPIM wrapper, the MSRP switch MUST reject the request with a 415 response (specified in RFC 4975 [RFC4975]).
如果MSRP交换机接收到不包含消息/CPIM包装的MSRP发送请求，则MSRP交换机必须以415响应拒绝该请求（在RFC 4975[RFC4975]中指定）。
If the MSRP switch receives an MSRP SEND request where the URI included in the From header field of the Message/CPIM wrapper is not valid, (e.g., because it does not "belong" to the sender of the message or is not a valid participant of the chat room), the MSRP
如果MSRP交换机接收到一个MSRP发送请求，其中消息/CPIM包装的From头字段中包含的URI无效（例如，因为它不“属于”消息的发送者或不是聊天室的有效参与者），则MSRP
switch MUST reject the request with a 403 response. In cases without error, the MSRP switch MUST construct responses according to Section 7.2 of RFC 4975 [RFC4975].
交换机必须以403响应拒绝请求。在没有错误的情况下，MSRP开关必须根据RFC 4975[RFC4975]第7.2节构造响应。
When the MSRP switch forwards a SEND request, it MAY use any report model in the copies intended for the recipients. The receiver reports from the recipients MUST NOT be forwarded to the originator of the original SEND request. This could lead to having the sender receiving multiple reports for a single MSRP request.
当MSRP交换机转发发送请求时，它可以在为收件人准备的副本中使用任何报告模型。不得将来自收件人的收件人报告转发给原始发送请求的发起人。这可能导致发送方收到一个MSRP请求的多个报告。
Congestion can occur when multiple heterogeneous interfaces are used by a number of users who are participating in a chat room, and, in particular, when paths become overloaded by any application. Some of these users might have fast paths capable of high throughputs while other users might be slow paths with constrained throughputs. Some paths might become congested only by the chat application; other paths gets congested by other applications. Therefore, it is possible that a subset of the participants of the chat room are able to send and receive a large number of messages in a short time or with large contents (e.g., pictures), whereas others are not able to keep up the pace.
当参与聊天室的许多用户使用多个异构接口时，尤其是当任何应用程序的路径过载时，可能会发生拥塞。其中一些用户可能具有高吞吐量的快速路径，而其他用户可能是吞吐量受限的慢速路径。某些路径可能仅被聊天应用程序阻塞；其他路径被其他应用程序阻塞。因此，聊天室参与者的一个子集可能能够在短时间内发送和接收大量消息或包含大量内容（例如，图片），而其他人则无法跟上进度。
Additionally, since MSRP uses a connection-oriented transport protocol such as TCP, it is expected that TCP congestion control mechanisms be activated if congestion occurs. Details on congestion control are specified in RFC 5681 [RFC5681].
此外，由于MSRP使用面向连接的传输协议（如TCP），因此如果发生拥塞，预计TCP拥塞控制机制将被激活。有关拥塞控制的详细信息，请参见RFC 5681[RFC5681]。
While this document does not mandate a particular MSRP-specific mechanism to avoid congestion in any of the paths, something that is deemed outside the scope of this document, this document provides some recommendations for implementors to consider.
虽然该文档没有授权特定的MSRP特定机制来避免任何路径中的拥塞，但这被认为是在本文档范围之外的内容，该文档为实施者提供了一些考虑的建议。
It is RECOMMENDED that MSRP switches implement one or more MSRP-specific strategies to detect and avoid congestion. Possible strategies (but definitely not a comprehensive list) include:
建议MSRP交换机实施一个或多个MSRP特定策略，以检测和避免拥塞。可能的策略（但绝对不是全面的列表）包括：
o If the MSRP switch is writing data to a send buffer and detects that the send buffer associated with that TCP connection is getting full (e.g., close to 80% of its capacity), the MSRP switch marks the associated MSRP sessions making use of that TCP connection as "congested".
o 如果MSRP交换机正在向发送缓冲区写入数据，并且检测到与该TCP连接相关联的发送缓冲区已满（例如，接近其容量的80%），则MSRP交换机将使用该TCP连接的相关MSRP会话标记为“拥塞”。
o Prior to sending a new MSRP message to a user, the MSRP switch verifies the congested flag associated to that MSRP session. If the MSRP session is marked as congested, the MSRP switch can apply a congestion avoidance mechanism, such as:
o 在向用户发送新的MSRP消息之前，MSRP交换机验证与该MSRP会话相关联的拥塞标志。如果MSRP会话标记为拥塞，则MSRP交换机可以应用拥塞避免机制，例如：
* The MSRP switch MAY discard regular MSRP messages sent to that user while the congestion flag is raised for the user's TCP connection. In order to inform the user of the congestion, the MSRP switch MAY send a regular MSRP message to the user whose congestion flag is raised. This message indicates that some other messages are being discarded due to network congestion. However, it should be noted that this message can get stuck at MSRP switch, if the path is fully congested, i.e., it may not be delivered anyhow.
* 当用户的TCP连接发出拥塞标志时，MSRP交换机可能会丢弃发送给该用户的常规MSRP消息。为了通知用户拥塞，MSRP交换机可以向其拥塞标志被提升的用户发送常规MSRP消息。此消息表示由于网络拥塞，其他一些消息正在被丢弃。然而，应该注意的是，如果路径完全阻塞，该消息可能会卡在MSRP交换机上，也就是说，它可能无论如何都无法传递。
* The MSRP can implement a temporary policy to disallow the distribution of messages larger than a certain size to MSRP sessions marked as congested. Similarly, the user should be informed of this fact by the MSRP switch sending a regular MSRP message indicating this condition.
* MSRP可以实施临时策略，禁止向标记为拥塞的MSRP会话分发大于一定大小的消息。类似地，MSRP开关应通过发送指示该状况的常规MSRP消息来通知用户该事实。
o If the MSRP switch determines that the congestion flag associated with a given TCP connection has been raised for quite some time (on the order of a few minutes), or if the interface is down, this may be considered an indication that the TCP connection has not been able to recover from a congestion state. The MSRP switch MAY close this congested TCP connection as well as the MSRP session and SIP session.
o 如果MSRP交换机确定与给定TCP连接相关联的拥塞标志已发出相当长的时间（大约几分钟），或者如果接口关闭，则这可能被视为TCP连接无法从拥塞状态恢复的指示。MSRP交换机可能会关闭此拥塞的TCP连接以及MSRP会话和SIP会话。
A common characteristic of existing chat room services is that participants have the ability to present themselves with a nickname to the rest of the participants of the chat room. It is used for easy reference of participants in the chat room and can also provide anonymous participants with a meaningful descriptive name.
现有聊天室服务的一个共同特点是，参与者能够向聊天室的其他参与者展示自己的昵称。它用于方便聊天室参与者的参考，还可以为匿名参与者提供有意义的描述性名称。
A nickname is a useful construct in many use cases, of which MSRP chat is but one example. A nickname is associated with a URI; the focus knows the participant by its association to this URI. Therefore, if a user joins the chat room under the same URI from multiple devices, he or she may request the same nickname across all these devices.
昵称在许多用例中是一个有用的构造，MSRP聊天只是其中的一个例子。昵称与URI相关联；焦点通过其与此URI的关联来了解参与者。因此，如果用户从多个设备以相同的URI加入聊天室，他或她可能会在所有这些设备上请求相同的昵称。
A nickname is a user-selectable moniker by which the participant wants to be known to the other participants. It is not a 'display-name', but it is used somewhat like a display name. A main difference is that a nickname is unique inside a chat room to allow an unambiguous reference to a participant in the chat. Nicknames may be long lived, or they may be temporary. Users also need to reserve a nickname prior to its utilization.
昵称是一个用户可选择的名字，参与者希望通过它让其他参与者知道。它不是“显示名称”，但使用起来有点像显示名称。一个主要的区别是，昵称在聊天室中是唯一的，可以明确地引用聊天室中的参与者。昵称可能是长久的，也可能是暂时的。用户还需要在使用昵称之前保留昵称。
This memo specifies the nickname as a string. The nickname string MUST unambiguously be associated with a single user in the scope of the chat room (conference instance). This scope is similar to having a nickname unique per user inside a chat room from "Extensible Messaging and Presence Protocol (XMPP): Core" [RFC6120]. The chat room may have policies associated with nicknames. It may not accept nickname strings at all, or it may provide a wider unambiguous scope like a domain or server, similar to IRC [RFC2810].
此备忘录将昵称指定为字符串。昵称字符串必须明确地与聊天室（会议实例）范围内的单个用户关联。此范围类似于在“可扩展消息和状态协议（XMPP）：核心”[RFC6120]的聊天室中为每个用户提供唯一的昵称。聊天室可能有与昵称关联的策略。它可能根本不接受昵称字符串，也可能提供更广泛的明确范围，如域或服务器，类似于IRC[RFC2810]。
This memo provides a mechanism to reserve a nickname for a participant for as long as the participant is logged into the chat room. The mechanism is based on a NICKNAME MSRP method (see below) and a new "Use-Nickname" header. Note that other mechanisms may exist (for example, a web page reservation system), although they are outside the scope of this document.
此备忘录提供了一种机制，可以在参与者登录聊天室时为其保留昵称。该机制基于昵称MSRP方法（见下文）和新的“使用昵称”头。请注意，可能存在其他机制（例如，网页保留系统），尽管它们不在本文档的范围内。
A chat room participant who has established an MSRP session with the MSRP switch, where the MSRP switch has indicated the support and availability of nicknames with the 'nicknames' token in the 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP switch. The NICKNAME request MUST include a new Use-Nickname header that contains the nickname string that the participant wants to reserve. This nickname string MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length. Finally, MSRP NICKNAME requests MUST NOT include Success-Report or Failure-Report header fields.
已与MSRP交换机建立MSRP会话的聊天室参与者，其中MSRP交换机已使用“聊天室”SDP属性中的“昵称”标记指示昵称的支持和可用性，可向MSRP交换机发送昵称请求。昵称请求必须包含一个新的Use昵称头，其中包含参与者想要保留的昵称字符串。此昵称字符串的长度不得为零个八位字节，且长度不得超过1023个八位字节。最后，MSRP昵称请求不得包含成功报告或失败报告头字段。
Bear in mind that nickname strings, like the rest of the MSRP message, use the UTF-8 transformation format [RFC3629]. Therefore, a character may be encoded in more than one octet.
请记住，昵称字符串与MSRP消息的其余部分一样，使用UTF-8转换格式[RFC3629]。因此，一个字符可以编码在多个八位组中。
An MSRP switch that receives a NICKNAME request containing a Use-Nickname header field SHOULD first verify whether the policy of the chat room allows the nickname functionality. If not allowed, the MSRP switch MUST reject the request with a 403 response, as per RFC 4975 [RFC4975].
接收包含使用昵称标头字段的昵称请求的MSRP交换机应首先验证聊天室的策略是否允许昵称功能。如果不允许，MSRP交换机必须根据RFC 4975[RFC4975]以403响应拒绝请求。
If the policy of the chat room allows the usage of nicknames, any new nickname requested MUST be prepared and compared with nicknames already in use or reserved following the rules defined in "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames" [RFC7700].
如果聊天室的策略允许使用昵称，则必须按照“代表昵称的国际化字符串的准备、实施和比较”[RFC7700]中定义的规则，准备请求的任何新昵称，并与已经使用或保留的昵称进行比较。
This mitigates the problem of nickname duplication, but it does not solve a problem whereby users can choose similar (but different) characters to represent two different nicknames. For example, "BOY"
这缓解了昵称重复的问题，但并不能解决用户可以选择相似（但不同）字符来表示两个不同昵称的问题。例如，“男孩”
and "B0Y" are different nicknames that can mislead users. The former uses the capital letter "O" while the latter uses the number zero "0". In many fonts, the letter "O" and the number zero "0" might be quite similar and difficult to perceive as different characters. Chat rooms MAY provide a mechanism to mitigate confusable nicknames.
和“B0Y”是不同的昵称，可能误导用户。前者使用大写字母“O”，而后者使用数字零“0”。在许多字体中，字母“O”和数字“0”可能非常相似，很难理解为不同的字符。聊天室可以提供一种机制来缓解容易混淆的昵称。
In addition to preparing and comparing following the rules above, the MSRP switch SHOULD only allow the reservation of an already-used nickname if the same user (e.g., identified by the SIP AOR) that is currently using the nickname is making this subsequent request. This may include, e.g., allowing the participant's URI to use the same nickname when the participant has joined the chat room from different devices under the same URI. The participant's authenticated identifier can be derived after a successful SIP Digest Authentication [RFC3261], included in a trusted SIP P-Asserted-Identity header field [RFC3325], included in a valid SIP Identity header field [RFC4474], or derived from any other present or future SIP authentication mechanism. Once the MSRP switch has validated that the participant is entitled to reserve the requested nickname, the MSRP switch verifies if the suggested nickname can be accepted (see below).
除了按照上述规则进行准备和比较外，如果当前正在使用昵称的同一用户（例如，由SIP AOR识别）发出此后续请求，则MSRP交换机应仅允许保留已使用的昵称。这可能包括，例如，当参与者从同一URI下的不同设备加入聊天室时，允许参与者的URI使用相同的昵称。参与者的认证标识符可以在成功的SIP摘要认证[RFC3261]之后派生，包括在可信的SIP P-Asserted-Identity报头字段[RFC3325]中，包括在有效的SIP标识报头字段[RFC4474]中，或者从任何其他现有或未来的SIP认证机制派生。一旦MSRP交换机验证参与者有权保留请求的昵称，MSRP交换机将验证建议的昵称是否可以接受（见下文）。
The reservation of a nickname can fail in several cases. If the NICKNAME request contains a malformed value in the Use-Nickname header field, the MSRP switch MUST answer the NICKNAME request with a 424 response code. This can be the case when the value of the Use-Nickname header field does not conform to the syntax.
在几种情况下，保留昵称可能会失败。如果昵称请求在“使用昵称头”字段中包含格式错误的值，则MSRP交换机必须使用424响应代码响应昵称请求。当“使用昵称头”字段的值不符合语法时，可能会出现这种情况。
The reservation of a nickname can also fail if the value of the Use-Nickname header field of the NICKNAME request is a reserved word (not to be used as a nickname by any user) or that particular value is already in use by another user. In these cases, the MSRP switch MUST answer the NICKNAME request with a 425 response code.
如果昵称请求的“使用昵称头”字段的值是保留字（任何用户都不会将其用作昵称），或者该特定值已被其他用户使用，则昵称的保留也可能失败。在这些情况下，MSRP交换机必须使用425响应代码响应昵称请求。
In both error conditions (receiving a 424 or 425 response code), the nickname usage is considered failed; the nickname is not allocated to this user. The user can select a different nickname and retry another NICKNAME request.
在两种错误情况下（接收424或425响应代码），昵称使用被视为失败；昵称未分配给此用户。用户可以选择不同的昵称，然后重试另一个昵称请求。
If the MSRP switch is able to accept the suggested nickname to be used by this user, the MSRP switch MUST answer the NICKNAME request with a 200 response as per regular MSRP procedures.
如果MSRP交换机能够接受该用户使用的建议昵称，则MSRP交换机必须按照常规MSRP程序以200响应响应响应昵称请求。
As indicated earlier, this specification defines a new MSRP header field: Use-Nickname. The Use-Nickname header field carries a nickname string. This specification defines the usage of the Use-Nickname header field in NICKNAME requests. If need arises, usages of the Use-Nickname header field in other MSRP methods should be specified separately.
如前所述，本规范定义了一个新的MSRP头字段：Use昵称。“使用昵称标题”字段包含昵称字符串。本规范定义了昵称请求中使用昵称头字段的用法。若需要，应单独指定其他MSRP方法中使用昵称标题字段的用法。
According to RFC 4975 [RFC4975], MSRP uses the UTF-8 transformation format [RFC3629]. The syntax of the MSRP NICKNAME method and the Use-Nickname header field is built upon the MSRP formal syntax [RFC4975] using the Augmented Backus-Naur Form (ABNF) [RFC5234].
根据RFC 4975[RFC4975]，MSRP使用UTF-8转换格式[RFC3629]。MSRP昵称方法和使用昵称头字段的语法基于MSRP形式语法[RFC4975]，使用扩展的巴科斯瑙格式（ABNF）[RFC5234]。
other-method =/ NICKNAMEm
; other-method defined in RFC 4975
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = DQUOTE 1*1023(qdtext / qd-esc) DQUOTE
; qdtext and qd-esc defined in RFC 4975
other-method =/ NICKNAMEm
; other-method defined in RFC 4975
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = DQUOTE 1*1023(qdtext / qd-esc) DQUOTE
; qdtext and qd-esc defined in RFC 4975
Note that, according to RFC 4975 [RFC4975], "quoted-string" admits a subset of UTF-8 characters [RFC3629]. Please refer to Section 9 of RFC 4975 [RFC4975] for more details.
请注意，根据RFC 4975[RFC4975]，“带引号的字符串”允许UTF-8字符的子集[RFC3629]。请参考RFC 4975[RFC4975]第9节了解更多详细信息。
Once the MSRP switch has reserved a nickname and has bound it to a URI (e.g., a SIP AoR), the MSRP server MAY allow the usage of the same nickname by the same user (identified by the same URI, such as a SIP AoR) over a second MSRP session. This might be the case if the user joins the same chat room from a different SIP UA. In this case, the user MAY request a nickname that is the same or different than that used in conjunction with the first MSRP session; the MSRP server MAY accept the usage of the same nickname by the same user. The MSRP switch MUST NOT automatically assign the same nickname to more than one MSRP session established from the same URI, because this can create confusion to the user as whether the same nickname is bound to the second MSRP session.
一旦MSRP交换机保留了昵称并将其绑定到URI（例如，SIP AoR），MSRP服务器可允许相同用户（由相同URI标识，例如SIP AoR）在第二MSRP会话上使用相同的昵称。如果用户从不同的SIP UA加入相同的聊天室，则可能会出现这种情况。在这种情况下，用户可以请求与结合第一MSRP会话使用的昵称相同或不同的昵称；MSRP服务器可以接受同一用户使用相同的昵称。MSRP交换机不得自动将同一昵称分配给从同一URI建立的多个MSRP会话，因为这会使用户混淆同一昵称是否绑定到第二个MSRP会话。
Typically, a participant will reserve a nickname as soon as the participant joins the chat room. But it is also possible for a participant to modify his/her own nickname and replace it with a new one at any time during the duration of the MSRP session. Modification of the nickname is not different from the initial reservation and usage of a nickname; thus, the NICKNAME method is used as described in Section 7.1.
通常，参与者在加入聊天室后会保留一个昵称。但在管理系统更新项目会议期间，参与者也可以随时修改自己的昵称，并用新昵称替换。昵称的修改与昵称的初始保留和使用没有区别；因此，如第7.1节所述，使用昵称方法。
If a NICKNAME request that attempts to modify the current nickname of the user fails for some reason, the current nickname stays in effect. A new nickname comes into effect and the old one is released only after a NICKNAME request is accepted with a 200 response.
如果尝试修改用户当前昵称的昵称请求因某种原因失败，则当前昵称将保持有效。新昵称生效，旧昵称只有在昵称请求被200响应接受后才被释放。
If the participant no longer wants to be known by a nickname in the chat room, the participant can follow the method described in Section 7.2. The nickname element of the Use-Nickname header MUST be set to an empty quoted string.
如果参与者不想再在聊天室中用昵称来称呼自己，那么参与者可以按照第7.2节所述的方法。Use昵称标头的昵称元素必须设置为带引号的空字符串。
Typically the conference focus acts as a notifier of the conference event package, RFC 4575 [RFC4575]. It is RECOMMENDED that conference foci and endpoints support RFC 6502 [RFC6502] for providing information regarding the conference and, in particular, supplying information of the roster of the conference. It is also RECOMMENDED that conference foci and endpoints support RFC 6501 [RFC6501], which extends the <user> element originally specified in RFC 4575 [RFC4575] with a new 'nickname' attribute. This allows endpoints to learn the nicknames of participants of the chat room.
通常，会议焦点充当会议事件包RFC 4575[RFC4575]的通知者。建议会议中心和端点支持RFC 6502[RFC6502]提供会议信息，特别是提供会议名册信息。还建议会议中心和端点支持RFC 6501[RFC6501]，它使用新的“昵称”属性扩展RFC 4575[RFC4575]中最初指定的<user>元素。这允许端点了解聊天室参与者的昵称。
There are a handful of use cases where a participant would like to learn the chat room capabilities supported by the local policy of the MSRP switch and the chat room. For example, a participant would like to learn if the MSRP switch supports private messaging; otherwise, the participant may send what he believes is a private IM addressed to a participant, but since the MSRP switch does not support the functions specified in this memo, the message would eventually be distributed to all the participants of the chat room.
在一些用例中，参与者希望了解MSRP交换机和聊天室的本地策略支持的聊天室功能。例如，参与者希望了解MSRP交换机是否支持私人消息传递；否则，参与者可能会向参与者发送他认为是私人IM的消息，但由于MSRP开关不支持此备忘录中指定的功能，因此消息最终将分发给聊天室的所有参与者。
The reverse case also exists. A participant, say Alice, whose UA does not support the extensions defined by this document joins the chat room. The MSRP switch learns that Alice's application does not support private messaging nor nicknames. If another participant, say Bob, sends a private message to Alice, the MSRP switch does not distribute it to Alice, because Alice is not able to differentiate it from a regular message sent to the whole roster. Furthermore, if Alice replied to this message, she would do it to the whole roster. Because of this, the MSRP switch also keeps track of users who do not support the extensions defined in this document.
相反的情况也存在。一个参与者，比如Alice，其UA不支持本文档定义的扩展，加入聊天室。MSRP交换机发现Alice的应用程序不支持私人消息传递或昵称。如果另一个参与者，比如Bob，向Alice发送私人消息，MSRP开关不会将其分发给Alice，因为Alice无法将其与发送给整个名册的常规消息区分开来。此外，如果Alice回复此消息，她会对整个花名册进行回复。因此，MSRP开关还跟踪不支持本文档中定义的扩展的用户。
In another scenario, the policy of a chat room may indicate that certain functions are not allowed. For example, the policy may indicate that nicknames or private messages are forbidden.
在另一种情况下，聊天室的策略可能指示某些功能是不允许的。例如，该策略可能指示禁止使用昵称或私人消息。
In order to provide the user with a good chat room experience, we define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a media-level value attribute [RFC4566] that MAY be included in conjunction with an MSRP media stream (i.e., when an "m=" line in SDP indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute without further modifiers (e.g., chat-tokens) indicates that the endpoint supports the procedures described in this document for transferring MSRP messages to/from a chat room. The 'chatroom' attribute can be complemented with additional modifiers that further indicate the intersection of support and local policy allowance for a number of functions specified in this document. Specifically, we provide the means to indicate support for the use of nicknames and private messaging.
为了给用户提供良好的聊天室体验，我们定义了一个新的“聊天室”SDP属性。“聊天室”属性是媒体级值属性[RFC4566]，可与MSRP媒体流一起包括（即，当SDP中的“m=”行表示“TCP/MSRP”或“TCP/TLS/MSRP”）时）。“chatroom”属性（不含其他修饰符（如聊天令牌））表示端点支持本文档中描述的将MSRP消息传输到聊天室或从聊天室传输MSRP消息的过程。“聊天室”属性可以通过其他修饰符进行补充，这些修饰符进一步指示本文档中指定的许多功能的支持和本地政策补贴的交叉点。具体来说，我们提供了表示支持使用昵称和私有消息的方法。
The 'chatroom' attribute merely indicates the capabilities supported and allowed by the local policy. This attribute is not a negotiation subject to the SDP offer/answer model [RFC3264], but instead a declaration. Therefore, a 'chatroom' attribute included in an SDP answer does not need to be a subset of the values included in the 'chatroom' attribute of its corresponding SDP offer. Consequently, an SDP answer MAY contain a 'chatroom' attribute even if its corresponding SDP offer did not include it.
“聊天室”属性仅表示本地策略支持和允许的功能。此属性不是受SDP提供/应答模型[RFC3264]约束的协商，而是一个声明。因此，SDP答案中包含的“聊天室”属性不需要是其相应SDP服务的“聊天室”属性中包含的值的子集。因此，SDP答案可能包含“聊天室”属性，即使其相应的SDP报价不包含该属性。
In subsequent SDP offer/answer [RFC3264] exchanges pertaining to the same session, the 'chatroom' attribute MAY be modified with respect to an earlier SDP offer/answer exchange. The new value of this attribute indicates the current support and local policy, meaning that some restrictions can apply now or might have been removed. If the 'chatroom' attribute is not included in a subsequent SDP offer/ answer, but a corresponding MSRP stream is still in place, it indicates that support for the procedures indicated in this document are disabled.
在与同一会话相关的后续SDP提供/应答[RFC3264]交换中，“聊天室”属性可以相对于先前的SDP提供/应答交换进行修改。此属性的新值表示当前支持和本地策略，这意味着某些限制现在可以应用或可能已被删除。如果“聊天室”属性未包含在后续SDP报价/应答中，但相应的MSRP流仍然存在，则表示禁用了对本文档中所述过程的支持。
The 'chatroom' SDP attribute has the following ABNF [RFC5234] syntax:
“聊天室”SDP属性具有以下ABNF[RFC5234]语法：
attribute =/ chatroom-attr
; attribute defined in RFC 4566
chatroom-attr = chatroom-label [":" chat-token
*(SP chat-token)]
chatroom-label = "chatroom"
chat-token = (nicknames-token / private-msg-token /
ext-token)
nicknames-token = "nickname"
private-msg-token = "private-messages"
ext-token = private-token / standard-token
private-token = toplabel "." *(domainlabel ".") token
; toplabel defined in RFC 3261
; domainlabel defined in RFC 3261
; token defined in RFC 3261
standard-token = token
attribute =/ chatroom-attr
; attribute defined in RFC 4566
chatroom-attr = chatroom-label [":" chat-token
*(SP chat-token)]
chatroom-label = "chatroom"
chat-token = (nicknames-token / private-msg-token /
ext-token)
nicknames-token = "nickname"
private-msg-token = "private-messages"
ext-token = private-token / standard-token
private-token = toplabel "." *(domainlabel ".") token
; toplabel defined in RFC 3261
; domainlabel defined in RFC 3261
; token defined in RFC 3261
standard-token = token
A given 'chat-token' value MUST NOT appear more than once in a 'chatroom' attribute.
给定的“聊天令牌”值在“聊天室”属性中不得出现多次。
A conference focus that includes the 'nicknames' token in the session description is signaling that the MSRP switch supports and the chat room allows the use of the procedures specified in Section 7. A conference focus that includes the 'private-messages' in the SDP description is signaling that the MSRP switch supports and the chat room allows the use of the procedures specified in Section 6.2.
在会话描述中包含“昵称”标记的会议焦点表示MSRP交换机支持并且聊天室允许使用第7节中指定的过程。SDP描述中包含“私人消息”的会议焦点表示MSRP交换机支持，聊天室允许使用第6.2节中规定的程序。
An example of the 'chatroom' attribute for an MSRP media stream that indicates the acceptance of nicknames and private messages:
MSRP媒体流的“聊天室”属性示例，表示接受昵称和私人消息：
a=chatroom:nickname private-messages
a=聊天室：昵称私人消息
An example of a 'chatroom' attribute for an MSRP media stream where the endpoint, e.g., an MSRP switch, does not allow nicknames or private messages.
MSRP媒体流的“聊天室”属性示例，其中端点（例如MSRP交换机）不允许昵称或私人消息。
a=chatroom
a=聊天室
The 'chatroom' attribute allows extensibility with the addition of new tokens. No IANA registry is provided at this time, since no extensions are expected at the time of this writing. Extensions to the 'chatroom' attribute can be defined in IETF documents or as private-vendor extensions.
“聊天室”属性允许通过添加新令牌进行扩展。目前没有提供IANA注册表，因为在撰写本文时不需要扩展。“聊天室”属性的扩展可以在IETF文档中定义，也可以定义为私有供应商扩展。
Extensions defined in an IETF document MUST follow the 'standard-token' ABNF previously defined. In this type of extension, care must be taken in the selection of the token to avoid a clash with any of the tokens previously defined.
IETF文档中定义的扩展必须遵循先前定义的“标准令牌”ABNF。在这种类型的扩展中，在选择令牌时必须小心，以避免与先前定义的任何令牌发生冲突。
Private extensions MUST follow the 'private-token' ABNF previously defined. The 'private-token' MUST be included in the DNS name of the vendor. Then, the token is reversed in order to avoid clashes of tokens. The following is an example of an extension named "foo.chat" by a vendor "example.com"
专用扩展必须遵循先前定义的“专用令牌”ABNF。“专用令牌”必须包含在供应商的DNS名称中。然后，将令牌反转，以避免令牌冲突。下面是供应商“example.com”提供的名为“foo.chat”的扩展的示例
a=chatroom:nickname private-messages com.example.chat.foo
a=聊天室：昵称private messages com.example.chat.foo
Note that feature names created by different organizations are not intended to have the same semantics or even interoperate.
请注意，不同组织创建的功能名称并不具有相同的语义，甚至不具有互操作性。
Figure 3 presents a flow diagram where Alice joins a chat room by sending an INVITE request. This INVITE request contains a session description that includes the chat room extensions defined in this document.
图3显示了Alice通过发送邀请请求加入聊天室的流程图。此邀请请求包含会话描述，其中包括本文档中定义的聊天室扩展。
Alice Conference Focus
| |
|F1: (SIP) INVITE |
|----------------------->|
|F2: (SIP) 200 OK |
|<-----------------------|
|F3: (SIP) ACK |
|----------------------->|
| |
Alice Conference Focus
| |
|F1: (SIP) INVITE |
|----------------------->|
|F2: (SIP) 200 OK |
|<-----------------------|
|F3: (SIP) ACK |
|----------------------->|
| |
Figure 3: Flow Diagram of a User Joining a Chat Room
图3：用户加入聊天室的流程图
F1: Alice constructs an SDP description that includes an MSRP media stream. She also indicates her support for the chat room extensions defined in this document. She sends the INVITE request to the chat room server.
F1:Alice构造了一个SDP描述，其中包括MSRP媒体流。她还表示支持本文档中定义的聊天室扩展。她将邀请请求发送到聊天室服务器。
INVITE sip:chatroom22@chat.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 290
INVITE sip:chatroom22@chat.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 290
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 client.atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messages
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 client.atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messages
F2: The chat room server accepts the session establishment. It includes the 'isfocus' and other relevant feature tags in the Contact header field of the response. The chat room server also builds an SDP answer that forces the reception of messages wrapped in Message/ CPIM wrappers. It also includes the 'chatroom' attribute with the allowed extensions.
F2：聊天室服务器接受会话建立。它在响应的联系人标题字段中包括“isfocus”和其他相关功能标签。聊天室服务器还构建SDP应答，强制接收消息/CPIM包装中包装的消息。它还包括带有允许扩展名的“聊天室”属性。
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: 290
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: 290
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messages
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messages
F3: The session established is acknowledged (details not shown).
F3：已确认建立的会话（未显示详细信息）。
Figure 4 shows an example of Alice setting up a nickname using the chat room as provider. Her first proposal is not accepted because that proposed nickname is already in use. Then, she makes a second proposal with a new nickname. This second proposal is accepted.
图4显示了Alice使用聊天室作为提供者设置昵称的示例。她的第一个提议没有被接受，因为提议的昵称已经在使用。然后，她用一个新的昵称提出了第二个建议。第二项建议被接受。
Alice MSRP Switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 425 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |
Alice MSRP Switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 425 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |
Figure 4: Flow Diagram of a User Setting up Her Nickname
图4：用户设置昵称的流程图
F1: Alice sends an MSRP NICKNAME request that contains her proposed nicknames in the Use-Nickname header field.
F1:Alice发送一个MSRP昵称请求，该请求在“使用昵称头”字段中包含她建议的昵称。
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice the great"
-------d93kswow$
F2: The MSRP switch analyzes the existing allocation of nicknames and
detects that the nickname "Alice the great" is already provided to
another participant in the chat room. The MSRP switch answers with a
425 response.
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice the great"
-------d93kswow$
F2: The MSRP switch analyzes the existing allocation of nicknames and
detects that the nickname "Alice the great" is already provided to
another participant in the chat room. The MSRP switch answers with a
425 response.
MSRP d93kswow 425 Nickname reserved or already in use
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
MSRP d93kswow 425 Nickname reserved or already in use
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
F3: Alice receives the response. She proposes a new nickname in a second NICKNAME request.
F3：Alice收到响应。她在第二个昵称请求中提出了一个新昵称。
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice in Wonderland"
-------09swk2d$
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice in Wonderland"
-------09swk2d$
F4: The MSRP switch accepts the nickname proposal and answers with a 200 response.
F4:MSRP交换机接受昵称建议，并以200回答。
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
Figure 5 is a flow diagram where Alice is sending a regular message addressed to the chat room. The MSRP switch distributes the message to the rest of the participants.
图5是一个流程图，其中Alice向聊天室发送一条常规消息。MSRP交换机将消息分发给其他参与者。
Alice MSRP Switch Bob Charlie
| | | |
| F1: (MSRP) SEND | | |
|--------------------->| F3: (MSRP) SEND | |
| F2: (MSRP) 200 |----------------------->| |
|<---------------------| F4: (MSRP) SEND | |
| |------------------------------->|
| | F5: (MSRP) 200 OK | |
| |<-----------------------| |
| | F6: (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
Alice MSRP Switch Bob Charlie
| | | |
| F1: (MSRP) SEND | | |
|--------------------->| F3: (MSRP) SEND | |
| F2: (MSRP) 200 |----------------------->| |
|<---------------------| F4: (MSRP) SEND | |
| |------------------------------->|
| | F5: (MSRP) 200 OK | |
| |<-----------------------| |
| | F6: (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
Figure 5: Sending a Regular Message to the Chat Room
图5：向聊天室发送常规消息
F1: Alice builds a text message and wraps it in a Message/CPIM wrapper. She addresses the message to the chat room. She encloses the resulting Message/CPIM wrapper in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
F1:Alice构建文本消息并将其包装在消息/CPIM包装器中。她将信息发送到聊天室。她将生成的消息/CPIM包装封装在MSRP发送请求中，并通过现有TCP连接将其发送到MSRP交换机。
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------3490visdm$
Hello guys, how are you today?
-------3490visdm$
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
F2：MSRP开关通过200（正常）响应确认发送请求的接收。
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
-------3490visdm$
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
-------3490visdm$
F3: The MSRP switch creates a new MSRP SEND request that contains the received Message/CPIM wrapper and sends it to Bob.
F3:MSRP开关创建一个新的MSRP发送请求，该请求包含接收到的消息/CPIM包装，并将其发送给Bob。
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------490ej23$
Hello guys, how are you today?
-------490ej23$
Since the received message is addressed to the chat room URI in the From header of the Message/CPIM header, Bob knows that this is a regular message distributed to all participants in the chat room rather than a private message addressed to him.
由于收到的消息被发送到消息/CPIM头的From头中的聊天室URI，Bob知道这是分发给聊天室中所有参与者的常规消息，而不是发送给他的私人消息。
The rest of the message flows are analogous to the previous. They are not shown here.
其余的消息流与前面的消息流类似。这里没有显示它们。
Figure 6 is a flow diagram where Alice is sending a private message addressed to Bob's SIP AOR. The MSRP switch distributes the message only to Bob.
图6是Alice向Bob的SIPAOR发送私有消息的流程图。MSRP开关仅将消息分发给Bob。
Alice MSRP Switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
Alice MSRP Switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
Figure 6: Sending a Private Message to Bob
图6：向Bob发送私人消息
F1: Alice builds a text message and wraps it in a Message/CPIM wrapper. She addresses the message to Bob's URI, which she learned from a notification in the conference event package. She encloses the resulting Message/CPIM wrapper in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
F1:Alice构建文本消息并将其包装在消息/CPIM包装器中。她将消息发送到Bob的URI，这是她从会议事件包中的通知中了解到的。她将生成的消息/CPIM包装封装在MSRP发送请求中，并通过现有TCP连接将其发送到MSRP交换机。
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
To: <sip:bob@example.com>
From: <sip:alice@example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------6959ssdf$
Hello Bob.
-------6959ssdf$
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
F2：MSRP开关通过200（正常）响应确认发送请求的接收。
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
-------6959ssdfm$
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
-------6959ssdfm$
F3: The MSRP switch creates a new MSRP SEND request that contains the received Message/CPIM wrapper and sends it only to Bob. Bob can distinguish the sender in the From header of the Message/CPIM wrapper. He also identifies this as a private message due to the presence of his own SIP AOR in the To header field of the Message/ CPIM wrapper.
F3:MSRP开关创建一个新的MSRP发送请求，该请求包含接收到的消息/CPIM包装，并仅将其发送给Bob。Bob可以从消息/CPIM包装的头中区分发件人。由于消息/CPIM包装器的to header字段中存在他自己的SIP AOR，他还将其标识为私有消息。
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
To: <sip:bob@example.com>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------9v9s2$
Hello Bob.
-------9v9s2$
F4: Bob acknowledges the reception of the SEND request with a 200 (OK) response.
F4:Bob以200（OK）响应确认发送请求的接收。
MSRP 9v9s2 200 OK
To-Path: msrp://chat.example.com:5678/jofofo3;tcp
From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
Message-ID: d9fghe982
-------9v9s2$
MSRP 9v9s2 200 OK
To-Path: msrp://chat.example.com:5678/jofofo3;tcp
From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
Message-ID: d9fghe982
-------9v9s2$
The MSRP message below is a depiction of the same private message described in Section 9.4, but now the message is split in two chunks. The MSRP switch must wait for the complete set of Message/CPIM headers before distributing the messages.
下面的MSRP消息描述了第9.4节中描述的同一条私人消息，但现在该消息被分为两块。在分发消息之前，MSRP交换机必须等待完整的消息/CPIM头集。
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 1-*/174
Content-Type: message/cpim
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 1-*/174
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
-------7443ruls$
To: <sip:bob@example.com>
From: <sip:alice@example.com>
-------7443ruls$
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 68-174/174
Content-Type: message/cpim
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 68-174/174
Content-Type: message/cpim
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob
-------7443ruls$
Hello Bob
-------7443ruls$
Figure 7 is a depiction of an XML conference information document received in a SIP NOTIFY request as a notification to the XCON Conference Event Package, RFC 6502 [RFC6502]. The conference information document follows the XCON Data Model specified in RFC 6501 [RFC6501].
图7描述了在SIP NOTIFY请求中接收的XML会议信息文档，作为对XCON会议事件包RFC6502[RFC6502]的通知。会议信息文档遵循RFC 6501[RFC6501]中指定的XCON数据模型。
The conference information document of Figure 7 presents information of two users who are participating in the conference (see each of the <user> elements). Each participant is bound to a nickname, shown in the 'nickname' attribute of the <user> element.
图7的会议信息文档显示了参加会议的两个用户的信息（参见<user>元素）。每个参与者都绑定到一个昵称，如<user>元素的“昵称”属性所示。
NOTE: The purpose of Figure 7 is to show the user-to-nickname relationship. It is believed that the example is correct, according to RFC 6501 [RFC6501]. In case of contradictions between this specification and RFC 6501 [RFC6501], the latter has precedence.
注意：图7的目的是显示用户与昵称的关系。根据RFC 6501[RFC6501]，相信该示例是正确的。如果本规范与RFC 6501[RFC6501]之间存在矛盾，则以后者为准。
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com"
state="full"
xcon:nickname="Dopey Donkey">
<display-text>Bob Hoskins</display-text>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com"
state="full"
xcon:nickname="Alice the great">
<display-text>Alice Kay</display-text>
</user>
</users>
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com"
state="full"
xcon:nickname="Dopey Donkey">
<display-text>Bob Hoskins</display-text>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com"
state="full"
xcon:nickname="Alice the great">
<display-text>Alice Kay</display-text>
</user>
</users>
</conference-info>
</conference-info>
Figure 7: Nickname in a Conference Information Document
图7：会议信息文档中的昵称
This specification defines a new MSRP method that has been added to the "Methods" subregistry of the "Message Session Relay Protocol (MSRP) Parameters" registry:
本规范定义了一种新的MSRP方法，该方法已添加到“消息会话中继协议（MSRP）参数”注册表的“方法”子区：
NICKNAME
昵称
See Section 7 for details.
详见第7节。
This specification defines a new MSRP header that has been added to the "Header Fields" subregistry of the "Message Session Relay Protocol (MSRP) Parameters" registry:
本规范定义了一个新的MSRP标头，该标头已添加到“消息会话中继协议（MSRP）参数”注册表的“标头字段”子区：
Use-Nickname
使用昵称
See Section 7 for details.
详见第7节。
This specification defines four new MSRP status codes that have been added to the "Status Codes" subregistry of the "Message Session Relay Protocol (MSRP) parameters" registry.
本规范定义了四个新的MSRP状态代码，这些代码已添加到“消息会话中继协议（MSRP）参数”注册表的“状态代码”子区。
The 404 status code indicates the failure to resolve the recipient's URI in the To header field of the Message/CPIM wrapper in the SEND request, e.g., due to an unknown recipient. See Section 6.2 for details.
404状态代码表示无法解析发送请求中消息/CPIM包装的to header字段中收件人的URI，例如，由于未知收件人。详见第6.2节。
The 424 status code indicates a failure in allocating the requested nickname due to a malformed syntax in the Use-Nickname header field. See Section 7 for details.
424状态代码表示由于“使用昵称头”字段中的语法错误，分配请求的昵称失败。详见第7节。
The 425 status code indicates a failure in allocating the requested nickname because the requested nickname in the Use-Nickname header field is reserved or is already in use by another user. See Section 7 for details.
425状态代码表示分配请求的昵称失败，因为“使用昵称头”字段中请求的昵称已被保留或已被其他用户使用。详见第7节。
The 428 status code indicates that the recipient of a SEND request does not support private messages. See Section 6.2 for details.
428状态代码表示发送请求的收件人不支持私人消息。详见第6.2节。
Table 1 summarizes the IANA registration data with respect to new MSRP status codes:
表1总结了与新MSRP状态代码相关的IANA注册数据：
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 404 | Failure to resolve recipient's URI | RFC 7701 |
| 424 | Malformed nickname | RFC 7701 |
| 425 | Nickname reserved or already in use | RFC 7701 |
| 428 | Private messages not supported | RFC 7701 |
+-------+-------------------------------------+-----------+
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 404 | Failure to resolve recipient's URI | RFC 7701 |
| 424 | Malformed nickname | RFC 7701 |
| 425 | Nickname reserved or already in use | RFC 7701 |
| 428 | Private messages not supported | RFC 7701 |
+-------+-------------------------------------+-----------+
Table 1: New Status Codes
表1：新的状态代码
This specification defines a new media-level attribute in the "Session Description Protocol (SDP) Parameters" registry. The registration data is as follows:
此规范在“会话描述协议（SDP）参数”注册表中定义了一个新的媒体级属性。登记资料如下：
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
电话：+34913391000
Attribute name: chatroom
属性名称：聊天室
Long-form attribute name: Chat Room
长格式属性名称：聊天室
Type of attribute: media level only
属性类型：仅媒体级别
This attribute is not subject to the charset attribute
此属性不受charset属性的约束
Description: This attribute identifies support and local policy allowance for a number of chat room related functions
描述：此属性标识对许多聊天室相关功能的支持和本地策略许可
Specification: RFC 7701 (this document)
规范：RFC 7701（本文件）
See Section 8 for details.
详情见第8节。
This document proposes extensions to the Message Session Relay Protocol [RFC4975]. Therefore, the security considerations of that document apply to this document as well.
本文档建议对消息会话中继协议[RFC4975]进行扩展。因此，该文件的安全考虑也适用于本文件。
A chat room is, by its nature, a potential Denial-of-Service (DoS) accelerator as it takes a message from one entity and sends it to many. Implementers of both UAs and switches need to carefully consider the set of anti-DoS measures that are appropriate for this application, and switch implementations, in particular, ought to
聊天室本质上是一个潜在的拒绝服务（DoS）加速器，因为它从一个实体接收消息并发送给多个实体。UAs和交换机的实现者需要仔细考虑适合这个应用的一组反DOS措施，尤其是交换机的实现应该是
include appropriate anti-DoS features. The details of what is appropriate will vary over time and will also depend on the specific needs of the implementation; thus, they cannot be specified here.
包括适当的防拒绝服务功能。适当的细节将随着时间的推移而变化，还将取决于实施的具体需要；因此，此处无法指定它们。
If the participant's SIP UA does not understand the "isfocus" feature tag [RFC3840], it will not know that it is connected to a conference instance. The participant might not be notified that its MSRP client will try to send messages having potential multiple recipients to the MSRP switch. If the participant's MSRP client does not support the extensions of this specification, it is unlikely that it will try to send a message using the Message/CPIM wrapper content type [RFC3862], and the MSRP switch will reject the request with a 415 response [RFC4975]. Still, if a participant's MSRP client does create a message with a valid Message/CPIM wrapper content type [RFC3862] having the To header set to the URI of the chat room and the From header set to the URI of which the participant that is known to the chat room, the participant might be unaware that the message can be forwarded to multiple recipients. Equally, if the To header is set to a valid URI of a recipient known to the chat room, the message can be forwarded as a private message without the participant knowing.
如果参与者的SIP UA不理解“isfocus”功能标签[RFC3840]，那么它将不知道它已连接到会议实例。参与者可能不会被通知其MSRP客户端将尝试向MSRP交换机发送可能有多个收件人的邮件。如果参与者的MSRP客户端不支持本规范的扩展，则不太可能尝试使用消息/CPIM包装内容类型[RFC3862]发送消息，并且MSRP交换机将以415响应[RFC4975]拒绝请求。尽管如此，如果参与者的MSRP客户端确实创建了一条消息，该消息具有有效的消息/CPIM包装内容类型[RFC3862]，其中To头设置为聊天室的URI，From头设置为聊天室已知的参与者的URI，参与者可能不知道邮件可以转发给多个收件人。同样，如果To头设置为聊天室已知的收件人的有效URI，则可以在参与者不知道的情况下将消息作为私人消息转发。
To mitigate these problems, when the chat room detects that a UA does not support the procedures of this document (i.e., when the SIP UA is not chat room aware), the MSRP switch SHOULD send a regular MSRP message indicating that the SIP UA is actually part of a chat room and that all the messages that the user sends correctly formatted will be distributed to a number of participants. Additionally, the MSRP switch SHOULD also send a regular MSRP text message including the list of participants in the chat room so that the user becomes aware of the roster.
为了缓解这些问题，当聊天室检测到UA不支持本文档的过程时（即，当SIP UA不了解聊天室时），MSRP交换机应发送一条常规MSRP消息，指示SIP UA实际上是聊天室的一部分，并且用户发送的所有格式正确的消息将分发给多个参与者。此外，MSRP开关还应定期发送MSRP文本消息，包括聊天室参与者的列表，以便用户了解名册。
If a participant wants to avoid security concerns on the path between himself and the MSRP switch (e.g., eavesdropping, faked packet injection, or packet corruption), the participant's UA can force the usage of MSRP over a TLS [RFC5246] transport connection. This is negotiated in the SDP offer/answer exchange as per the regular procedures of RFC 4975 [RFC4975]. This negotiation will result in both endpoints establishing a TLS [RFC5246] transport connection that is used to exchange MSRP messages. The MSRP switch may also have local policy that forces the usage of TLS transport for all MSRP sessions, something that is also negotiated in SDP as per the regular procedures of RFC 4975 [RFC4975].
如果参与者希望避免自己与MSRP交换机之间路径上的安全问题（例如，窃听、伪造数据包注入或数据包损坏），则参与者的UA可以通过TLS[RFC5246]传输连接强制使用MSRP。根据RFC 4975[RFC4975]的常规程序，在SDP报价/应答交换中进行协商。此协商将导致两个端点建立用于交换MSRP消息的TLS[RFC5246]传输连接。MSRP交换机还可能具有强制所有MSRP会话使用TLS传输的本地策略，这也是根据RFC 4975[RFC4975]的常规程序在SDP中协商的。
Nicknames are used to show the appearance of the participants of the chat room. A successful takeover of a nickname from a participant might lead to private messages being sent to the wrong destination. The recipient's URI will be different from the URI associated with the original owner of the nickname, but the sender might not notice
昵称用于显示聊天室参与者的外观。从参与者处成功接收昵称可能会导致将私人消息发送到错误的目的地。收件人的URI将不同于与昵称的原始所有者关联的URI，但发件人可能不会注意到
this. To avoid takeovers, the MSRP switch MUST make sure that a nickname is unique inside a chat room. Also, the security consideration for any authenticated identity mechanisms used to validate the SIP AOR will apply to this document as well. The chat room has a policy that determines the time that a nickname is still reserved for its holder, once it is no longer being used. This allows, e.g., a user that accidentally loses its connectivity, to reconnect to the chat room and keep on using the same nickname. It depends on the policy of the chat room if a nickname that has been previously used by another participant of the chat room can be reserved or not.
这为了避免接管，MSRP交换机必须确保聊天室中的昵称是唯一的。此外，用于验证SIP AOR的任何身份验证机制的安全考虑也将适用于本文档。聊天室有一个策略，确定一旦不再使用昵称，昵称仍保留给其持有者的时间。例如，这允许用户意外失去连接，重新连接到聊天室并继续使用相同的昵称。它取决于聊天室的策略，如果一个昵称以前曾被聊天室的另一个参与者使用过，是否可以保留。
Section 7.1 discusses the problem of similar but different nicknames (e.g., thanks to the use of similar characters), and chat rooms MAY provide a mechanism to mitigate confusable nicknames.
第7.1节讨论了相似但不同的昵称的问题（例如，由于使用了相似的字符），聊天室可以提供一种机制来缓解易混淆的昵称。
Recipients of IMs should be cautious with the rendering of content, which can be malicious in nature. This includes, but is not limited to, the reception of HTML and JavaScript scripts, executable code, phishing attempts, etc. Endpoints SHOULD always request permission from the user before executing one of these actions.
IMs的接收者在呈现内容时应该谨慎，因为内容可能是恶意的。这包括但不限于接收HTML和JavaScript脚本、可执行代码、网络钓鱼尝试等。在执行其中一项操作之前，端点应始终请求用户的许可。
It must be noted that endpoints using a TLS client side certificate with real names in the certificates will not be anonymous to the MSRP switch to which they connect. While the name in the certificate might not be used by MSRP, the server will have a certificate with the actual name in it.
必须注意的是，使用TLS客户端证书且证书中包含实名的端点对于它们所连接的MSRP交换机不会是匿名的。虽然MSRP可能不会使用证书中的名称，但服务器将拥有一个包含实际名称的证书。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<http://www.rfc-editor.org/info/rfc3323>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<http://www.rfc-editor.org/info/rfc3840>.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, <http://www.rfc-editor.org/info/rfc3860>.
[RFC3860]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC 3860，DOI 10.17487/RFC3860，2004年8月<http://www.rfc-editor.org/info/rfc3860>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <http://www.rfc-editor.org/info/rfc3862>.
[RFC3862]Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，DOI 10.17487/RFC3862，2004年8月<http://www.rfc-editor.org/info/rfc3862>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，DOI 10.17487/RFC4353，2006年2月<http://www.rfc-editor.org/info/rfc4353>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，Ed.，“会议状态的会话启动协议（SIP）事件包”，RFC 4575，DOI 10.17487/RFC4575，2006年8月<http://www.rfc-editor.org/info/rfc4575>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 4975，DOI 10.17487/RFC4975，2007年9月<http://www.rfc-editor.org/info/rfc4975>.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <http://www.rfc-editor.org/info/rfc4976>.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 4976，DOI 10.17487/RFC4976，2007年9月<http://www.rfc-editor.org/info/rfc4976>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <http://www.rfc-editor.org/info/rfc5239>.
[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，RFC 5239，DOI 10.17487/RFC5239，2008年6月<http://www.rfc-editor.org/info/rfc5239>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681，DOI 10.17487/RFC56812009年9月<http://www.rfc-editor.org/info/rfc5681>.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <http://www.rfc-editor.org/info/rfc6501>.
[RFC6501]Novo，O.，Camarillo，G.，Morgan，D.，和J.Urpalainen，“集中会议的会议信息数据模型（XCON）”，RFC 6501，DOI 10.17487/RFC6501，2012年3月<http://www.rfc-editor.org/info/rfc6501>.
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, DOI 10.17487/RFC6502, March 2012, <http://www.rfc-editor.org/info/rfc6502>.
[RFC6502]Camarillo，G.，Srinivasan，S.，Even，R.，和J.Urpalainen，“集中会议的会议事件包数据格式扩展（XCON）”，RFC 6502，DOI 10.17487/RFC6502，2012年3月<http://www.rfc-editor.org/info/rfc6502>.
[RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 7700, DOI 10.17487/RFC7700, December 2015, <http://www.rfc-editor.org/info/rfc7700>.
[RFC7700]Saint Andre，P.，“代表昵称的国际化字符串的准备、实施和比较”，RFC 7700，DOI 10.17487/RFC7700，2015年12月<http://www.rfc-editor.org/info/rfc7700>.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, DOI 10.17487/RFC2810, April 2000, <http://www.rfc-editor.org/info/rfc2810>.
[RFC2810]Kalt，C.，“互联网中继聊天：架构”，RFC2810，DOI 10.17487/RFC2810，2000年4月<http://www.rfc-editor.org/info/rfc2810>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<http://www.rfc-editor.org/info/rfc3325>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，DOI 10.17487/RFC3966，2004年12月<http://www.rfc-editor.org/info/rfc3966>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，DOI 10.17487/RFC4474，2006年8月<http://www.rfc-editor.org/info/rfc4474>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
Acknowledgments
致谢
The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian Georgescu, Nancy Greene, Cullen Jennings, Flemming Andreasen, Suresh Krishnan, Christer Holmberg, Saul Ibarra, Enrico Marocco, Alexey Melnikov, Peter Saint-Andre, Stephen Farrell, and Martin Stiemerling for providing comments.
作者要感谢伊娃·莱普潘、阿达姆·哈鲁纳、亚当·罗奇、马特·莱宾斯基、玛丽·巴恩斯、本·坎贝尔、保罗·基齐瓦特、阿德里安·乔治斯库、南希·格林、卡伦·詹宁斯、弗莱明·安德里森、苏雷什·克里希南、克里斯特·霍姆伯格、索尔·伊巴拉、恩里科·马罗科、阿列克西·梅尔尼科夫、彼得·圣安德烈、斯蒂芬·法雷尔、，和Martin Stiemerling提供的评论。
Contributors
贡献者
This work would have never been possible without the fruitful discussions on the SIMPLE WG mailing list, especially with Brian Rosen (Neustar) and Paul Kyzivat (Huawei), who provided extensive review and improvements throughout the document.
如果没有关于简单工作组邮件列表的富有成效的讨论，这项工作将永远不可能实现，特别是与Brian Rosen（Neustar）和Paul Kyzivat（华为）的讨论，他们在整个文档中提供了广泛的审查和改进。
Authors' Addresses
作者地址
Aki Niemi
阿基涅米
Email: aki.niemi@iki.fi
Email: aki.niemi@iki.fi
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain
Miguel A.Garcia Martin Ericsson Calle Via de los Poblados 13西班牙东南部马德里28033
Email: miguel.a.garcia@ericsson.com
Email: miguel.a.garcia@ericsson.com
Geir A. Sandbakken Cisco Systems Philip Pedersensvei 1 1366 Lysaker Norway
Geir A.Sandbakken Cisco Systems Philip Pedersensvei 1 1366 Lysaker Norway
Email: geirsand@cisco.com
Email: geirsand@cisco.com