Network Working Group B. Campbell, Ed.
Request for Comments: 4975 Estacado Systems
Category: Standards Track R. Mahy, Ed.
Plantronics
C. Jennings, Ed.
Cisco Systems, Inc.
September 2007
Network Working Group B. Campbell, Ed.
Request for Comments: 4975 Estacado Systems
Category: Standards Track R. Mahy, Ed.
Plantronics
C. Jennings, Ed.
Cisco Systems, Inc.
September 2007
The Message Session Relay Protocol (MSRP)
消息会话中继协议（MSRP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
本文档描述了消息会话中继协议，该协议用于在会话上下文中传输一系列相关即时消息。当通过集合或会话创建协议（如会话启动协议）进行设置时，消息会话被视为与任何其他媒体流一样。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Applicability of MSRP ...........................................5
4. Protocol Overview ...............................................6
5. Key Concepts ....................................................9
5.1. MSRP Framing and Message Chunking ..........................9
5.2. MSRP Addressing ...........................................10
5.3. MSRP Transaction and Report Model .........................11
5.4. MSRP Connection Model .....................................12
6. MSRP URIs ......................................................14
6.1. MSRP URI Comparison .......................................15
6.2. Resolving MSRP Host Device ................................16
7. Method-Specific Behavior .......................................17
7.1. Constructing Requests .....................................17
7.1.1. Sending SEND Requests ..............................18
7.1.2. Sending REPORT Requests ............................21
7.1.3. Generating Success Reports .........................22
7.1.4. Generating Failure Reports .........................23
7.2. Constructing Responses ....................................24
7.3. Receiving Requests ........................................25
7.3.1. Receiving SEND Requests ............................25
7.3.2. Receiving REPORT Requests ..........................27
8. Using MSRP with SIP and SDP ....................................27
8.1. SDP Connection and Media-Lines ............................28
8.2. URI Negotiations ..........................................29
8.3. Path Attributes with Multiple URIs ........................30
8.4. Updated SDP Offers ........................................31
8.5. Connection Negotiation ....................................31
8.6. Content Type Negotiation ..................................32
8.7. Example SDP Exchange ......................................34
8.8. MSRP User Experience with SIP .............................35
8.9. SDP Direction Attribute and MSRP ..........................35
9. Formal Syntax ..................................................36
10. Response Code Descriptions ....................................38
10.1. 200 ......................................................38
10.2. 400 ......................................................38
10.3. 403 ......................................................38
10.4. 408 ......................................................39
10.5. 413 ......................................................39
10.6. 415 ......................................................39
10.7. 423 ......................................................39
10.8. 481 ......................................................39
10.9. 501 ......................................................39
10.10. 506 .....................................................40
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Applicability of MSRP ...........................................5
4. Protocol Overview ...............................................6
5. Key Concepts ....................................................9
5.1. MSRP Framing and Message Chunking ..........................9
5.2. MSRP Addressing ...........................................10
5.3. MSRP Transaction and Report Model .........................11
5.4. MSRP Connection Model .....................................12
6. MSRP URIs ......................................................14
6.1. MSRP URI Comparison .......................................15
6.2. Resolving MSRP Host Device ................................16
7. Method-Specific Behavior .......................................17
7.1. Constructing Requests .....................................17
7.1.1. Sending SEND Requests ..............................18
7.1.2. Sending REPORT Requests ............................21
7.1.3. Generating Success Reports .........................22
7.1.4. Generating Failure Reports .........................23
7.2. Constructing Responses ....................................24
7.3. Receiving Requests ........................................25
7.3.1. Receiving SEND Requests ............................25
7.3.2. Receiving REPORT Requests ..........................27
8. Using MSRP with SIP and SDP ....................................27
8.1. SDP Connection and Media-Lines ............................28
8.2. URI Negotiations ..........................................29
8.3. Path Attributes with Multiple URIs ........................30
8.4. Updated SDP Offers ........................................31
8.5. Connection Negotiation ....................................31
8.6. Content Type Negotiation ..................................32
8.7. Example SDP Exchange ......................................34
8.8. MSRP User Experience with SIP .............................35
8.9. SDP Direction Attribute and MSRP ..........................35
9. Formal Syntax ..................................................36
10. Response Code Descriptions ....................................38
10.1. 200 ......................................................38
10.2. 400 ......................................................38
10.3. 403 ......................................................38
10.4. 408 ......................................................39
10.5. 413 ......................................................39
10.6. 415 ......................................................39
10.7. 423 ......................................................39
10.8. 481 ......................................................39
10.9. 501 ......................................................39
10.10. 506 .....................................................40
11. Examples ......................................................40
11.1. Basic IM Session .........................................40
11.2. Message with XHTML Content ...............................42
11.3. Chunked Message ..........................................43
11.4. Chunked Message with Message/CPIM Payload ................43
11.5. System Message ...........................................44
11.6. Positive Report ..........................................44
11.7. Forked IM ................................................45
12. Extensibility .................................................48
13. CPIM Compatibility ............................................48
14. Security Considerations .......................................49
14.1. Secrecy of the MSRP URI ..................................50
14.2. Transport Level Protection ...............................50
14.3. S/MIME ...................................................51
14.4. Using TLS in Peer-to-Peer Mode ...........................52
14.5. Other Security Concerns ..................................53
15. IANA Considerations ...........................................55
15.1. MSRP Method Names ........................................55
15.2. MSRP Header Fields .......................................55
15.3. MSRP Status Codes ........................................56
15.4. MSRP Port ................................................56
15.5. URI Schema ...............................................56
15.5.1. MSRP Scheme .......................................56
15.5.2. MSRPS Scheme ......................................57
15.6. SDP Transport Protocol ...................................57
15.7. SDP Attribute Names ......................................58
15.7.1. Accept Types ......................................58
15.7.2. Wrapped Types .....................................58
15.7.3. Max Size ..........................................58
15.7.4. Path ..............................................58
16. Contributors and Acknowledgments ..............................59
17. References ....................................................59
17.1. Normative References .....................................59
17.2. Informative References ...................................60
11. Examples ......................................................40
11.1. Basic IM Session .........................................40
11.2. Message with XHTML Content ...............................42
11.3. Chunked Message ..........................................43
11.4. Chunked Message with Message/CPIM Payload ................43
11.5. System Message ...........................................44
11.6. Positive Report ..........................................44
11.7. Forked IM ................................................45
12. Extensibility .................................................48
13. CPIM Compatibility ............................................48
14. Security Considerations .......................................49
14.1. Secrecy of the MSRP URI ..................................50
14.2. Transport Level Protection ...............................50
14.3. S/MIME ...................................................51
14.4. Using TLS in Peer-to-Peer Mode ...........................52
14.5. Other Security Concerns ..................................53
15. IANA Considerations ...........................................55
15.1. MSRP Method Names ........................................55
15.2. MSRP Header Fields .......................................55
15.3. MSRP Status Codes ........................................56
15.4. MSRP Port ................................................56
15.5. URI Schema ...............................................56
15.5.1. MSRP Scheme .......................................56
15.5.2. MSRPS Scheme ......................................57
15.6. SDP Transport Protocol ...................................57
15.7. SDP Attribute Names ......................................58
15.7.1. Accept Types ......................................58
15.7.2. Wrapped Types .....................................58
15.7.3. Max Size ..........................................58
15.7.4. Path ..............................................58
16. Contributors and Acknowledgments ..............................59
17. References ....................................................59
17.1. Normative References .....................................59
17.2. Informative References ...................................60
A series of related instant messages between two or more parties can be viewed as part of a "message session", that is, a conversational exchange of messages with a definite beginning and end. This is in contrast to individual messages each sent independently. Messaging schemes that track only individual messages can be described as "page-mode" messaging, whereas messaging that is part of a "session" with a definite start and end is called "session-mode" messaging.
两方或多方之间的一系列相关即时消息可被视为“消息会话”的一部分，即具有明确开始和结束的消息会话交换。这与单独发送的消息形成对比。仅跟踪单个消息的消息传递方案可以称为“页面模式”消息传递，而作为“会话”一部分且具有明确开始和结束的消息传递称为“会话模式”消息传递。
Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method [22]. Session-mode messaging has a number of benefits over page-mode messaging, however, such as explicit rendezvous, tighter integration with other media-types, direct client-to-client operation, and brokered privacy and security.
通过SIP[4]消息方法[22]在SIP中启用页面模式消息传递。然而，会话模式消息传递比页面模式消息传递有许多好处，例如显式会合、与其他媒体类型的更紧密集成、直接的客户端到客户端操作以及代理隐私和安全性。
This document defines a session-oriented instant message transport protocol called the Message Session Relay Protocol (MSRP), whose sessions can be negotiated with an offer or answer [3] using the Session Description Protocol (SDP) [2]. The exchange is carried by some signaling protocol, such as SIP [4]. This allows a communication user agent to offer a messaging session as one of the possible media-types in a session. For instance, Alice may want to communicate with Bob. Alice doesn't know at the moment whether Bob has his phone or his IM client handy, but she's willing to use either. She sends an invitation to a session to the address of record she has for Bob, sip:bob@example.com. Her invitation offers both voice and an IM session. The SIP services at example.com forward the invitation to Bob at his currently registered clients. Bob accepts the invitation at his IM client, and they begin a threaded chat conversation.
本文档定义了一种面向会话的即时消息传输协议，称为消息会话中继协议（MSRP），其会话可以使用会话描述协议（SDP）[2]与要约或答复[3]协商。交换由一些信令协议进行，如SIP[4]。这允许通信用户代理将消息传递会话作为会话中可能的媒体类型之一提供。例如，爱丽丝可能想和鲍勃交流。Alice目前不知道Bob手边是否有他的手机或即时通讯客户端，但她愿意使用其中任何一个。她将会议邀请发送至她为Bob，sip记录的地址：bob@example.com. 她的邀请提供语音和即时通讯服务。example.com上的SIP服务将邀请转发给Bob当前注册的客户端。Bob在他的IM客户端接受了邀请，他们开始了一个线程式的聊天对话。
When a user uses an Instant Messaging (IM) URL, RFC 3861 [32] defines how DNS can be used to map this to a particular protocol to establish the session such as SIP. SIP can use an offer/answer model to transport the MSRP URIs for the media in SDP. This document defines how the offer/answer exchange works to establish MSRP connections and how messages are sent across the MSRP, but it does not deal with the issues of mapping an IM URL to a session establishment protocol.
当用户使用即时消息（IM）URL时，RFC 3861[32]定义了如何使用DNS将其映射到特定协议以建立会话（如SIP）。SIP可以使用提供/应答模型来传输SDP中媒体的MSRP URI。本文档定义了要约/应答交换如何建立MSRP连接，以及如何在MSRP上发送消息，但未涉及将IM URL映射到会话建立协议的问题。
This session model allows message sessions to be integrated into advanced communications applications with little to no additional protocol development. For example, during the above chat session, Bob decides Alice really needs to be talking to Carol. Bob can transfer [21] Alice to Carol, introducing them into their own messaging session. Messaging sessions can then be easily integrated into call-center and dispatch environments using third-party call control [20] and conferencing [19] applications.
此会话模型允许将消息会话集成到高级通信应用程序中，而几乎不需要额外的协议开发。例如，在上述聊天过程中，Bob认为Alice确实需要与Carol交谈。Bob可以将[21]Alice转给Carol，将他们介绍到自己的消息会话中。然后，可以使用第三方呼叫控制[20]和会议[19]应用程序将消息传递会话轻松集成到呼叫中心和调度环境中。
This document specifies MSRP behavior only for peer-to-peer sessions, that is, sessions crossing only a single hop. MSRP relay devices [23] (referred to herein as "relays") are specified in a separate document. An endpoint that implements this specification, but not the relay specification, will be unable to introduce relays into the message path, but will still be able to interoperate with peers that do use relays.
本文档仅为对等会话指定MSRP行为，即仅跨单个跃点的会话。MSRP继电器装置[23]（此处称为“继电器”）在单独的文件中规定。实现此规范（而非中继规范）的端点将无法将中继引入消息路径，但仍能够与使用中继的对等方进行互操作。
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 RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
This document consistently refers to a "message" as a complete unit of MIME or text content. In some cases, a message is split and delivered in more than one MSRP request. Each of these portions of the complete message is called a "chunk".
本文档始终将“消息”称为MIME或文本内容的完整单元。在某些情况下，在多个MSRP请求中拆分和传递消息。完整消息的每一部分都称为“块”。
MSRP is not designed for use as a standalone protocol. MSRP MUST be used only in the context of a rendezvous mechanism meeting the following requirements:
MSRP不是为用作独立协议而设计的。MSRP只能在满足以下要求的会合机制中使用：
o The rendezvous mechanism MUST provide both MSRP URIs associated with an MSRP session to each of the participating endpoints. The rendezvous mechanism MUST implement mechanisms to protect the confidentiality of these URIs -- they MUST NOT be made available to an untrusted third party or be easily discoverable.
o 集合机制必须向每个参与端点提供与MSRP会话相关联的两个MSRP URI。集合机制必须实现保护这些URI机密性的机制——它们不能提供给不受信任的第三方，也不能轻易被发现。
o The rendezvous mechanism MUST provide mechanisms for the negotiation of any supported MSRP extensions that are not backwards compatible.
o 会合机制必须提供协商任何不向后兼容的受支持MSRP扩展的机制。
o The rendezvous mechanism MUST be able to natively transport im: URIs or automatically translate im: URIs [27] into the addressing identifiers of the rendezvous protocol.
o 集合机制必须能够本机传输im:URI或自动将im:URI[27]转换为集合协议的寻址标识符。
To use a rendezvous mechanism with MSRP, an RFC MUST be prepared that describes how it exchanges MSRP URIs and meets these requirements listed here. This document provides such a description for the use of MSRP in the context of SIP and SDP.
要使用MSRP的会合机制，必须准备一份RFC，说明其如何交换MSRP URI并满足此处列出的这些要求。本文件提供了在SIP和SDP环境中使用MSRP的说明。
SIP meets these requirements for a rendezvous mechanism. The MSRP URIs are exchanged using SDP in an offer/answer exchange via SIP.
SIP满足会合机制的这些要求。MSRP URI通过SIP在提供/应答交换中使用SDP进行交换。
The exchanged SDP can also be used to negotiate MSRP extensions. This SDP can be secured using any of the mechanisms available in SIP, including using the sips mechanism to ensure transport security across intermediaries and Secure/Multipurpose Internet Mail Extensions (S/MIME) for end-to-end protection of the SDP body. SIP can carry arbitrary URIs (including im: URIs) in the Request-URI, and procedures are available to map im: URIs to sip: or sips: URIs. It is expected that initial deployments of MSRP will use SIP as its rendezvous mechanism.
交换的SDP也可用于协商MSRP扩展。可以使用SIP中可用的任何机制保护此SDP，包括使用sips机制确保跨中介的传输安全，以及使用安全/多用途Internet邮件扩展（S/MIME）对SDP主体进行端到端保护。SIP可以在请求URI中携带任意URI（包括im:URI），并且可以使用过程将im:URI映射到SIP:或sips:URI。预计MSRP的初始部署将使用SIP作为其会合机制。
MSRP is a text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME [8] content, especially instant messages. This section is a non-normative overview of how MSRP works and how it is used with SIP.
MSRP是一种基于文本、面向连接的协议，用于交换任意（二进制）MIME[8]内容，尤其是即时消息。本节是关于MSRP如何工作以及如何与SIP一起使用的非规范性概述。
MSRP sessions are typically arranged using SIP the same way a session of audio or video media is set up. One SIP user agent (Alice) sends the other (Bob) a SIP invitation containing an offered session-description that includes a session of MSRP. The receiving SIP user agent can accept the invitation and include an answer session-description that acknowledges the choice of media. Alice's session description contains an MSRP URI that describes where she is willing to receive MSRP requests from Bob, and vice versa. (Note: Some lines in the examples are removed for clarity and brevity.)
MSRP会话通常使用SIP安排，与音频或视频媒体会话的设置方式相同。一个SIP用户代理（Alice）向另一个（Bob）发送一个SIP邀请，其中包含一个包含MSRP会话的会话描述。接收SIP用户代理可以接受邀请并包括应答会话描述，该会话描述确认媒体的选择。Alice的会话描述包含一个MSRP URI，该URI描述了她愿意从Bob接收MSRP请求的位置，反之亦然。（注意：为了清晰和简洁，删除了示例中的一些行。）
Alice sends to Bob:
Alice发送给Bob：
INVITE sip:bob@biloxi.example.com SIP/2.0
To: <sip:bob@biloxi.example.com>
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
INVITE sip:bob@biloxi.example.com SIP/2.0
To: <sip:bob@biloxi.example.com>
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
c=IN IP4 atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp
c=IN IP4 atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp
Bob sends to Alice:
Bob发送给Alice：
SIP/2.0 200 OK
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
SIP/2.0 200 OK
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
c=IN IP4 biloxi.example.com
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
c=IN IP4 biloxi.example.com
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
Alice sends to Bob:
Alice发送给Bob：
ACK sip:bob@biloxi SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
ACK sip:bob@biloxi SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Figure 1: Session Setup
图1：会话设置
MSRP defines two request types, or methods. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message), while REPORT requests report on the status of a previously sent message, or a range of bytes inside a message. When Alice receives Bob's answer, she checks to see if she has an existing connection to Bob. If not, she opens a new connection to Bob using the URI he provided in the SDP. Alice then delivers a SEND request to Bob with her initial message, and Bob replies indicating that Alice's request was received successfully.
MSRP定义了两种请求类型或方法。发送请求用于传递完整消息或区块（完整消息的一部分），而报告请求则报告先前发送的消息的状态或消息中的字节范围。当Alice收到Bob的答案时，她会检查是否与Bob有联系。如果没有，她将使用Bob在SDP中提供的URI打开与Bob的新连接。然后，Alice向Bob发送一个发送请求和她的初始消息，Bob回复表示Alice的请求已成功接收。
MSRP a786hjs2 SEND
To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Content-Type: text/plain
MSRP a786hjs2 SEND
To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Content-Type: text/plain
Hey Bob, are you there?
-------a786hjs2$
Hey Bob, are you there?
-------a786hjs2$
MSRP a786hjs2 200 OK
To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
-------a786hjs2$
MSRP a786hjs2 200 OK
To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
-------a786hjs2$
Figure 2: Example MSRP Exchange
图2：MSRP交换示例
Alice's request begins with the MSRP start line, which contains a transaction identifier that is also used for request framing. Next she includes the path of URIs to the destination in the To-Path header field, and her own URI in the From-Path header field. In this typical case, there is just one "hop", so there is only one URI in each path header field. She also includes a message ID, which she can use to correlate status reports with the original message. Next she puts the actual content. Finally, she closes the request with an end-line of seven hyphens, the transaction identifier, and a "$" to indicate that this request contains the end of a complete message.
Alice的请求以MSRP起始行开始，该行包含一个事务标识符，该标识符也用于请求框架。接下来，她在to path头字段中包含到目标的URI路径，在From path头字段中包含她自己的URI。在这种典型情况下，只有一个“跃点”，因此每个路径头字段中只有一个URI。她还包括一个消息ID，可用于将状态报告与原始消息关联起来。接下来，她把实际的内容。最后，她用七个连字符的结束行、事务标识符和一个“$”来结束请求，以指示此请求包含完整消息的结尾。
If Alice wants to deliver a very large message, she can split the message into chunks and deliver each chunk in a separate SEND request. The message ID corresponds to the whole message, so the receiver can also use it to reassemble the message and tell which chunks belong with which message. Chunking is described in more detail in Section 5.1. The Byte-Range header field identifies the portion of the message carried in this chunk and the total size of the message.
如果Alice想要传递一条非常大的消息，她可以将消息分成多个块，并在单独的发送请求中传递每个块。消息ID对应于整个消息，因此接收方也可以使用它重新组合消息，并告诉哪些块属于哪个消息。分块在第5.1节中有更详细的描述。Byte Range header字段标识此数据块中包含的消息部分以及消息的总大小。
Alice can also specify what type of reporting she would like in response to her request. If Alice requests positive acknowledgments, Bob sends a REPORT request to Alice confirming the delivery of her complete message. This is especially useful if Alice sent a series of SEND requests containing chunks of a single message. More on requesting types of reports and errors is described in Section 5.3.
Alice还可以指定她希望响应其请求的报告类型。如果Alice请求肯定的确认，Bob将向Alice发送报告请求，确认她完整的消息已送达。如果Alice发送了一系列包含单个消息块的发送请求，那么这一点尤其有用。有关请求报告类型和错误的更多信息，请参见第5.3节。
Alice and Bob choose their MSRP URIs in such a way that it is difficult to guess the exact URI. Alice and Bob can reject requests to URIs they are not expecting to service and can correlate the specific URI with the probable sender. Alice and Bob can also use
Alice和Bob选择MSRP URI的方式很难猜出确切的URI。Alice和Bob可以拒绝对他们不希望服务的URI的请求，并且可以将特定URI与可能的发送者关联起来。Alice和Bob也可以使用
TLS [1] to provide channel security over this hop. To receive MSRP requests over a TLS protected connection, Alice or Bob could advertise URIs with the "msrps" scheme instead of "msrp".
TLS[1]提供此跃点上的通道安全性。为了通过受TLS保护的连接接收MSRP请求，Alice或Bob可以使用“msrps”方案而不是“MSRP”来公布URI。
MSRP is designed with the expectation that MSRP can carry URIs for nodes on the far side of relays. For this reason, a URI with the "msrps" scheme makes no assertion about the security properties of other hops, just the next hop. The user agent knows the URI for each hop, so it can verify that each URI has the desired security properties.
MSRP的设计期望MSRP能够为继电器远端的节点承载URI。因此，具有“msrps”方案的URI不会断言其他跃点的安全属性，只会断言下一个跃点。用户代理知道每个跃点的URI，因此可以验证每个URI是否具有所需的安全属性。
MSRP URIs are discussed in more detail in Section 6.
第6节将更详细地讨论MSRP URI。
An adjacent pair of busy MSRP nodes (for example, two relays) can easily have several sessions, and exchange traffic for several simultaneous users. The nodes can use existing connections to carry new traffic with the same destination host, port, transport protocol, and scheme. MSRP nodes can keep track of how many sessions are using a particular connection and close these connections when no sessions have used them for some period of time. Connection management is discussed in more detail in Section 5.4.
相邻一对繁忙的MSRP节点（例如，两个中继）可以轻松地拥有多个会话，并为多个同时的用户交换流量。节点可以使用现有连接承载具有相同目标主机、端口、传输协议和方案的新流量。MSRP节点可以跟踪使用特定连接的会话数，并在一段时间内没有会话使用这些连接时关闭这些连接。第5.4节将更详细地讨论连接管理。
Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the overall message. Long chunks may be interrupted in mid-transmission to ensure fairness across shared transport connections. To support this, MSRP uses a boundary-based framing mechanism. The start line of an MSRP request contains a unique identifier that is also used to indicate the end of the request. Included at the end of the end-line, there is a flag that indicates whether this is the last chunk of data for this message or whether the message will be continued in a subsequent chunk. There is also a Byte-Range header field in the request that indicates the overall position of this chunk inside the complete message.
使用MSRP发送的消息可能非常大，并且可以在多个发送请求中传递，其中每个发送请求包含整个消息的一个区块。长数据块可能在传输过程中中断，以确保共享传输连接的公平性。为了支持这一点，MSRP使用基于边界的框架机制。MSRP请求的起始行包含一个唯一标识符，该标识符也用于指示请求的结束。在结束行的末尾包含一个标志，指示这是此消息的最后一个数据块，还是消息将在后续数据块中继续。请求中还有一个字节范围标头字段，指示该块在完整消息中的总体位置。
For example, the following snippet of two SEND requests demonstrates a message that contains the text "abcdEFGH" being sent as two chunks.
例如，下面两个发送请求的片段演示了一条包含文本“abcdEFGH”的消息，该文本将作为两个块发送。
MSRP dkei38sd SEND
Message-ID: 4564dpWd
Byte-Range: 1-*/8
Content-Type: text/plain
MSRP dkei38sd SEND
Message-ID: 4564dpWd
Byte-Range: 1-*/8
Content-Type: text/plain
abcd
-------dkei38sd+
abcd
-------dkei38sd+
MSRP dkei38ia SEND
Message-ID: 4564dpWd
Byte-Range: 5-8/8
Content-Type: text/plain
MSRP dkei38ia SEND
Message-ID: 4564dpWd
Byte-Range: 5-8/8
Content-Type: text/plain
EFGH
-------dkei38ia$
EFGH
-------dkei38ia$
Figure 3: Breaking a Message into Chunks
图3：将消息分解成块
This chunking mechanism allows a sender to interrupt a chunk part of the way through sending it. The ability to interrupt messages allows multiple sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection, or even the same MSRP session. Any chunk that is larger than 2048 octets MUST be interruptible. While MSRP would be simpler to implement if each MSRP session used its own TCP connection, there are compelling reasons to conserve connections. For example, the TCP peer may be a relay device that connects to many other peers. Such a device will scale better if each peer does not create a large number of connections. (Note that in the above example, the initial chunk was interruptible for the sake of example, even though its size is well below the limit for which interruptibility would be required.)
这种分块机制允许发送方在发送分块的过程中中断部分分块。中断消息的能力允许多个会话共享一个TCP连接，并允许高效发送大型消息，同时不阻止共享同一连接的其他消息，甚至同一MSRP会话。任何大于2048个八位字节的块都必须是可中断的。虽然如果每个MSRP会话都使用自己的TCP连接，MSRP将更容易实现，但有一些令人信服的理由可以保留连接。例如，TCP对等方可以是连接到许多其他对等方的中继设备。如果每个对等方不创建大量连接，这样的设备将具有更好的扩展性。（请注意，在上面的示例中，出于示例的考虑，初始块是可中断的，即使其大小远低于要求可中断性的限制。）
The chunking mechanism only applies to the SEND method, as it is the only method used to transfer message content.
分块机制仅适用于SEND方法，因为它是用于传输消息内容的唯一方法。
MSRP entities are addressed using URIs. The MSRP URI schemes are defined in Section 6. The syntax of the To-Path and From-Path header fields each allows for a list of URIs. This was done to allow the protocol to work with relays, which are defined in a separate document, to provide a complete path to the end recipient. When two MSRP nodes communicate directly, they need only one URI in the To-Path list and one URI in the From-Path list.
MSRP实体使用URI进行处理。MSRP URI方案的定义见第6节。To Path和From Path头字段的语法都允许URI列表。这样做是为了允许协议与中继一起工作，中继在单独的文档中定义，以提供到最终接收者的完整路径。当两个MSRP节点直接通信时，它们只需要To路径列表中的一个URI和From路径列表中的一个URI。
A sender sends MSRP requests to a receiver. The receiver MUST quickly accept or reject the request. If the receiver initially accepted the request, it still may then do things that take significant time to succeed or fail. For example, if the receiver is an MSRP to Extensible Messaging and Presence Protocol (XMPP) [30] gateway, it may forward the message over XMPP. The XMPP side may later indicate that the request did not work. At this point, the MSRP receiver may need to indicate that the request did not succeed. There are two important concepts here: first, the hop-by-hop delivery of the request may succeed or fail; second, the end result of the request may or may not be successfully processed. The first type of status is referred to as "transaction status" and may be returned in response to a request. The second type of status is referred to as "delivery status" and may be returned in a REPORT transaction.
发送方向接收方发送MSRP请求。接收者必须迅速接受或拒绝请求。如果接收者最初接受了请求，那么它仍然可能会做一些需要很长时间才能成功或失败的事情。例如，如果接收器是MSRP到可扩展消息传递和存在协议（XMPP）[30]网关，则它可以通过XMPP转发消息。XMPP端稍后可能会指出请求不起作用。此时，MSRP接收器可能需要指示请求未成功。这里有两个重要的概念：第一，请求的逐跳传递可能成功或失败；其次，请求的最终结果可能会被成功处理，也可能不会被成功处理。第一种类型的状态称为“事务状态”，可在响应请求时返回。第二种状态称为“交付状态”，可以在报告事务中返回。
The original sender of a request can indicate if they wish to receive reports for requests that fail, and can independently indicate if they wish to receive reports for requests that succeed. A receiver only sends a success REPORT if it knows that the request was successfully delivered, and the sender requested a success report. A receiver only sends a failure REPORT if the request failed to be delivered and the sender requested failure reports.
请求的原始发送者可以指示他们是否希望接收失败请求的报告，并且可以独立地指示他们是否希望接收成功请求的报告。只有当接收方知道请求已成功传递，并且发送方请求了成功报告时，才会发送成功报告。只有当请求未能传递且发送方请求失败报告时，接收方才会发送失败报告。
This document describes the behavior of MSRP endpoints. MSRP relays will introduce additional conditions that indicate a failure REPORT should be sent, such as the failure to receive a positive response from the next hop.
本文档描述了MSRP端点的行为。MSRP继电器将引入其他条件，指示应发送故障报告，例如未能从下一跳接收到肯定响应。
Two header fields control the sender's desire to receive reports. The Success-Report header field can have a value of "yes" or "no" and the Failure-Report header field can have a value of "yes", "no", or "partial".
两个标题字段控制发件人接收报告的愿望。成功报告标题字段的值可以是“是”或“否”，失败报告标题字段的值可以是“是”、“否”或“部分”。
The combinations of reporting are needed to meet the various scenarios of currently deployed IM systems. Success-Report might be "no" in many public systems to reduce load, but might be "yes" in certain enterprise systems, such as systems used for securities trading. A Failure-Report value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a response explosion to the sender. A Failure-Report of "yes" is used by many systems that wish to notify the user if the message failed. A Failure-Report of "partial" is a way to report errors other than timeouts. Timeout error reporting requires the sending hop to run a timer and the receiving hop to send an
报告的组合需要满足当前部署的IM系统的各种场景。成功报告在许多公共系统中可能是“否”以减少负载，但在某些企业系统中可能是“是”，例如用于证券交易的系统。故障报告值“否”有助于发送系统消息，例如“系统将在5分钟内停机”，而不会导致发送方响应爆炸。许多希望在消息失败时通知用户的系统使用“是”故障报告。“部分”故障报告是报告超时以外错误的一种方法。超时错误报告要求发送跃点运行计时器，接收跃点发送错误
acknowledgment to stop the timer. Some systems don't want the overhead of doing this. "Partial" allows them to choose not to do so, but still allows error responses to be sent in many cases.
确认停止计时器。有些系统不希望这样做会增加开销。“部分”允许他们选择不这样做，但在许多情况下仍然允许发送错误响应。
The term "partial" denotes that the hop-by-hop acknowledgment mechanism that would be required with a Failure-Report value of "yes" is not invoked. Thus, each device uses only "part" of the set of error detection tools available to them. This allows a compromise between no reporting of failures at all, and reporting every possible failure. For example, with "partial", a sending device does not have to keep transaction state around waiting for a positive acknowledgment. But it still allows devices to report other types of errors. The receiving device could still report a policy violation such as an unacceptable content-type, or an ICMP error trying to connect to a downstream device.
术语“部分”表示未调用故障报告值为“是”时所需的逐跳确认机制。因此，每个设备只使用它们可用的错误检测工具集的“部分”。这允许在根本不报告故障和报告所有可能的故障之间达成折衷。例如，使用“部分”，发送设备不必保持事务状态等待肯定的确认。但它仍然允许设备报告其他类型的错误。接收设备仍可能报告策略冲突，例如不可接受的内容类型，或尝试连接到下游设备时出现ICMP错误。
When an MSRP endpoint wishes to send a request to a peer identified by an MSRP URI, it first needs a transport connection, with the appropriate security properties, to the host specified in the URI. If the sender already has such a connection, that is, one associated with the same host, port, and URI scheme, then it SHOULD reuse that connection.
当MSRP端点希望向MSRP URI标识的对等方发送请求时，它首先需要与URI中指定的主机建立具有适当安全属性的传输连接。如果发送方已经有这样的连接，即与同一主机、端口和URI方案关联的连接，那么它应该重用该连接。
When a new MSRP session is created, the initiating endpoint MUST act as the "active" endpoint, meaning that it is responsible for opening the transport connection to the answerer, if a new connection is required. However, this requirement MAY be weakened if standardized mechanisms for negotiating the connection direction become available and are implemented by both parties to the connection.
创建新的MSRP会话时，发起端点必须充当“活动”端点，这意味着如果需要新连接，它负责打开与应答者的传输连接。但是，如果连接双方都可以使用并实施协商连接方向的标准化机制，则这一要求可能会被削弱。
Likewise, the active endpoint MUST immediately issue a SEND request. This initial SEND request MAY have a body if the sender has content to send, or it MAY have no body at all.
同样，活动端点必须立即发出发送请求。如果发件人有要发送的内容，则此初始发送请求可能有正文，或者根本没有正文。
The first SEND request serves to bind a connection to an MSRP session from the perspective of the passive endpoint. If the connection is not authenticated with TLS, and the active endpoint did not send an immediate request, the passive endpoint would have no way to determine who had connected, and would not be able to safely send any requests towards the active party until after the active party sends its first request.
第一个发送请求用于从被动端点的角度将连接绑定到MSRP会话。如果连接未通过TLS验证，并且主动端点未发送即时请求，则被动端点将无法确定谁已连接，并且在主动方发送其第一个请求之前，将无法安全地向主动方发送任何请求。
When an element needs to form a new connection, it looks at the URI to decide on the type of connection (TLS, TCP, etc.) then connects to the host indicated by the URI, following the URI resolution rules in Section 6.2. Connections using the "msrps" scheme MUST use TLS. The
当一个元素需要形成一个新的连接时，它会查看URI来决定连接的类型（TLS、TCP等），然后按照第6.2节中的URI解析规则连接到URI所指示的主机。使用“msrps”方案的连接必须使用TLS。这个
SubjectAltName in the received certificate MUST match the hostname part of the URI and the certificate MUST be valid according to RFC 3280 [16], including having a date that is valid and being signed by an acceptable certification authority. At this point, the device that initiated the connection can assume that this connection is with the correct host.
根据RFC 3280[16]，接收到的证书中的SubjectAltName必须与URI的主机名部分匹配，并且证书必须有效，包括具有有效日期并由可接受的证书颁发机构签名。此时，启动连接的设备可以假定此连接使用的是正确的主机。
The rules on certificate name matching and CA signing MAY be relaxed when using TLS peer-to-peer. In this case, a mechanism to ensure that the peer used a correct certificate MUST be used. See Section 14.4 for details.
使用TLS对等时，证书名称匹配和CA签名的规则可能会放宽。在这种情况下，必须使用确保对等方使用正确证书的机制。详见第14.4节。
If the connection used mutual TLS authentication, and the TLS client presented a valid certificate, then the element accepting the connection can verify the identity of the connecting device by comparing the hostname part of the target URI in the SDP provided by the peer device against the SubjectAltName in the client certificate.
如果连接使用了相互TLS身份验证，并且TLS客户端提供了有效的证书，那么接受连接的元素可以通过比较对等设备提供的SDP中目标URI的主机名部分与客户端证书中的SubjectAltName来验证连接设备的身份。
When mutual TLS authentication is not used, the listening device MUST wait until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description.
当不使用相互TLS身份验证时，侦听设备必须等待，直到它收到连接上的请求，此时它从关联的会话描述推断连接设备的身份。
When the first request arrives, its To-Path header field should contain a URI that the listening element provided in the SDP for a session. The element that accepted the connection looks up the URI in the received request, and determines which session it matches. If a match exists, the node MUST assume that the host that formed the connection is the host to which this URI was given. If no match exists, the node MUST reject the request with a 481 response. The node MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response.
当第一个请求到达时，其To Path头字段应该包含一个URI，该URI是SDP中为会话提供的侦听元素。接受连接的元素在收到的请求中查找URI，并确定它匹配的会话。如果存在匹配项，则节点必须假定形成连接的主机就是向其提供此URI的主机。如果不存在匹配项，则节点必须以481响应拒绝请求。节点还必须进行检查，以确保会话尚未在其他连接上使用。如果会话已经在使用中，它必须以506响应拒绝请求。
If it were legal to have multiple connections associated with the same session, a security problem would exist. If the initial SEND request is not protected, an eavesdropper might learn the URI, and use it to insert messages into the session via a different connection.
如果将多个连接与同一会话关联是合法的，则会存在安全问题。如果初始发送请求没有受到保护，窃听者可能会了解URI，并使用它通过不同的连接将消息插入会话。
If a connection fails for any reason, then an MSRP endpoint MUST consider any sessions associated with the connection as also having failed. When either endpoint notices such a failure, it MAY attempt to re-create any such sessions. If it chooses to do so, it MUST use a new SDP exchange, for example, in a SIP re-INVITE. If a replacement session is successfully created, endpoints MAY attempt to resend any content for which delivery on the original session could not be confirmed. If it does this, the Message-ID values for the
如果连接因任何原因而失败，那么MSRP端点必须考虑与该连接相关联的任何会话也失败。当任一端点发现此类失败时，它可能会尝试重新创建任何此类会话。如果选择这样做，它必须使用新的SDP交换，例如，在SIP重新邀请中。如果成功创建了替换会话，端点可能会尝试重新发送无法确认原始会话上的传递的任何内容。如果执行此操作，则
resent messages MUST match those used in the initial attempts. If the receiving endpoint receives more than one message with the same Message-ID, it SHOULD assume that the messages are duplicates. The specific action that an endpoint takes when it receives a duplicate message is a matter of local policy, except that it SHOULD NOT present the duplicate messages to the user without warning of the duplication. Note that acknowledgments as needed based on the Failure-Report and Success-Report settings are still necessary even for requests containing duplicate content.
重新发送消息必须与初始尝试中使用的消息匹配。如果接收端点接收到多个具有相同消息ID的消息，则应假定这些消息是重复的。端点在接收到重复消息时所采取的特定操作是本地策略的问题，但它不应在没有重复警告的情况下向用户显示重复消息。请注意，即使对于包含重复内容的请求，仍然需要根据失败报告和成功报告设置进行必要的确认。
When endpoints create a new session in this fashion, the chunks for a given logical message MAY be split across the sessions. However, endpoints SHOULD NOT split chunks between sessions under non-failure circumstances.
当端点以这种方式创建新会话时，给定逻辑消息的区块可能会在会话之间分割。但是，在非故障情况下，端点不应在会话之间分割块。
If an endpoint attempts to re-create a failed session in this manner, it MUST NOT assume that the MSRP URIs in the SDP will be the same as the old ones.
如果端点试图以这种方式重新创建失败的会话，那么它不能假定SDP中的MSRP URI与旧的相同。
A connection SHOULD NOT be closed while there are sessions associated with it.
当存在与其关联的会话时，不应关闭连接。
URIs using the "msrp" and "msrps" schemes are used to identify a session of instant messages at a particular MSRP device, as well as to identify an MSRP relay in general. This document describes the former usage; the latter usage is described in the MSRP relay specification [23]. MSRP URIs that identify sessions are ephemeral; an MSRP device will use a different MSRP URI for each distinct session. An MSRP URI that identifies a session has no meaning outside the scope of that session.
使用“msrp”和“msrps”方案的URI用于识别特定msrp设备上的即时消息会话，以及通常识别msrp中继。本文件描述了前一种用法；MSRP继电器规范[23]中描述了后一种用途。确定会话短暂的MSRP URI；MSRP设备将为每个不同的会话使用不同的MSRP URI。标识会话的MSRP URI在该会话范围之外没有任何意义。
An MSRP URI follows a subset of the URI syntax in Appendix A of RFC 3986 [10], with a scheme of "msrp" or "msrps". The syntax is described in Section 9.
MSRP URI遵循RFC 3986[10]附录a中URI语法的子集，方案为“MSRP”或“msrps”。第9节介绍了语法。
MSRP URIs are primarily expected to be generated and exchanged between systems, and are not intended for "human consumption". Therefore, they are encoded entirely in US-ASCII.
MSRP URI主要预期在系统之间生成和交换，而不是用于“人类消费”。因此，它们完全用US-ASCII编码。
The constructions for "authority", "userinfo", and "unreserved" are detailed in RFC 3986 [10]. URIs designating MSRP over TCP MUST include the "tcp" transport parameter.
RFC 3986[10]中详细说明了“权限”、“用户信息”和“无保留”的构造。通过TCP指定MSRP的URI必须包含“TCP”传输参数。
Since this document only specifies MSRP over TCP, all MSRP URIs herein use the "tcp" transport parameter. Documents that provide bindings on other transports should define respective parameters for those transports.
由于本文档仅指定TCP上的MSRP，因此本文中的所有MSRP URI都使用“TCP”传输参数。在其他传输上提供绑定的文档应该为这些传输定义各自的参数。
The MSRP URI authority field identifies a participant in a particular MSRP session. If the authority field contains a numeric IP address, it MUST also contain a port. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device. A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the "authority" governing a namespace for the session-id.
MSRP URI权限字段标识特定MSRP会话中的参与者。如果授权字段包含数字IP地址，则它还必须包含端口。会话id部分标识参与者的特定会话。缺少会话id部分表示对MSRP主机设备的引用，但不表示该设备上的特定会话。会话id的特定值仅在关联权限的上下文中有意义；因此，可以将authority组件视为标识管理session-id名称空间的“authority”。
A scheme of "msrps" indicates that the underlying connection MUST be protected with TLS.
“msrps”方案表示必须使用TLS保护底层连接。
MSRP has an IANA-registered recommended port defined in Section 15.4. This value is not a default, as the URI negotiation process described herein will always include explicit port numbers. However, the URIs SHOULD be configured so that the recommended port is used whenever appropriate. This makes life easier for network administrators who need to manage firewall policy for MSRP.
MSRP具有第15.4节中定义的IANA注册推荐端口。此值不是默认值，因为本文描述的URI协商过程将始终包括显式端口号。但是，应该配置URI，以便在适当的时候使用推荐的端口。这使得需要为MSRP管理防火墙策略的网络管理员的工作更加轻松。
The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. A userinfo part MUST NOT contain password information.
authority组件通常不包含userinfo组件，但可以这样做以指示会话对其有效的用户帐户。请注意，这与标识会话本身不同。userinfo部分不能包含密码信息。
The following is an example of a typical MSRP URI:
以下是典型的MSRP URI示例：
msrp://host.example.com:8493/asfd34;tcp
msrp://host.example.com:8493/asfd34;tcp
In the context of the MSRP protocol, MSRP URI comparisons MUST be performed according to the following rules:
在MSRP协议的上下文中，必须根据以下规则执行MSRP URI比较：
1. The scheme MUST match. Scheme comparison is case insensitive.
1. 方案必须匹配。方案比较不区分大小写。
2. If the authority component contains an explicit IP address and/or port, these are compared for address and port equivalence. Percent-encoding normalization [10] applies; that is, if any percent-encoded nonreserved characters exist in the authority component, they must be decoded prior to comparison. Userinfo
2. 如果授权组件包含显式IP地址和/或端口，则会比较这些地址和端口的等效性。百分比编码规范化[10]适用；也就是说，如果授权组件中存在任何百分比编码的非重复字符，则必须在比较之前对其进行解码。用户信息
parts are not considered for URI comparison. Otherwise, the authority component is compared as a case-insensitive character string.
URI比较不考虑部件。否则，权限组件将作为不区分大小写的字符串进行比较。
3. If the port exists explicitly in either URI, then it MUST match exactly. A URI with an explicit port is never equivalent to another with no port specified.
3. 如果端口显式存在于任一URI中，则它必须完全匹配。具有显式端口的URI永远不会与未指定端口的URI等效。
4. The session-id part is compared as case sensitive. A URI without a session-id part is never equivalent to one that includes one.
4. 会话id部分比较时区分大小写。没有会话id部分的URI永远不会等同于包含会话id部分的URI。
5. URIs with different "transport" parameters never match. Two URIs that are identical except for transport are not equivalent. The transport parameter is case insensitive.
5. 具有不同“传输”参数的URI永远不匹配。除了传输之外，两个相同的URI是不等价的。transport参数不区分大小写。
Path normalization [10] is not relevant for MSRP URIs.
路径规范化[10]与MSRP URI无关。
An MSRP host device is identified by the authority component of an MSRP URI.
MSRP主机设备由MSRP URI的授权组件标识。
If the authority component contains a numeric IP address and port, they MUST be used as listed.
如果授权组件包含数字IP地址和端口，则必须按所列方式使用它们。
If the authority component contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query and use the port as listed.
如果授权组件包含主机名和端口，则连接设备必须通过执行a或AAAA DNS查询来确定主机地址，并使用列出的端口。
If a connection attempt fails, the device SHOULD attempt to connect to the addresses returned in any additional A or AAAA records, in the order the records were presented.
如果连接尝试失败，设备应按照记录的显示顺序，尝试连接到任何其他a或AAAA记录中返回的地址。
This process assumes that the connection port is always known prior to resolution. This is always true for the MSRP URI uses described in this document, that is, URIs exchanged in the SDP offer and answer. The introduction of relays creates situations where this is not the case. For example, when a user configures her client to use a relay, it is desirable that the relay's MSRP URI is easy to remember and communicate to humans. Often this type of MSRP will omit the port number. Therefore, the relay specification [23] describes additional steps to resolve the port number.
此过程假定在解析之前连接端口总是已知的。对于本文档中描述的MSRP URI使用，也就是SDP提供和应答中交换的URI，这始终是正确的。继电器的引入造成了情况并非如此的情况。例如，当用户将其客户机配置为使用中继时，希望中继的MSRP URI易于记忆并与人通信。这种类型的MSRP通常会忽略端口号。因此，中继规范[23]描述了解析端口号的附加步骤。
MSRP devices MAY use other methods for discovering other such devices, when appropriate. For example, MSRP endpoints may use other mechanisms to discover relays, which are beyond the scope of this document.
适当时，MSRP设备可使用其他方法发现其他此类设备。例如，MSRP端点可以使用其他机制来发现中继，这超出了本文档的范围。
To form a new request, the sender creates a transaction identifier and uses this and the method name to create an MSRP request start line. The transaction identifier MUST NOT collide with that of other transactions that exist at the same time. Therefore, it MUST contain at least 64 bits of randomness.
为了形成一个新的请求，发送方创建一个事务标识符，并使用该标识符和方法名称创建一个MSRP请求起始行。事务标识符不得与同时存在的其他事务的标识符冲突。因此，它必须至少包含64位随机性。
Next, the sender places the target path in a To-Path header field, and the sender's URI in a From-Path header field. If multiple URIs are present in the To-Path, the leftmost is the first URI visited; the rightmost URI is the last URI visited. The processing then becomes method specific. Additional method-specific header fields are added as described in the following sections.
接下来，发送方将目标路径放在To path头字段中，将发送方的URI放在From path头字段中。如果To路径中存在多个URI，则最左边的URI是访问的第一个URI；最右边的URI是最后访问的URI。然后，处理变得特定于方法。如以下各节所述，添加了其他特定于方法的标题字段。
After any method-specific header fields are added, processing continues to handle a body, if present. If the request has a body, it MUST contain a Content-Type header field. It may contain other MIME-specific header fields. The Content-Type header field MUST be the last field in the message header section. The body MUST be separated from the header fields with an extra CRLF.
添加任何特定于方法的头字段后，处理将继续处理主体（如果存在）。如果请求有正文，则必须包含内容类型标头字段。它可能包含其他MIME特定的头字段。内容类型标题字段必须是消息标题部分的最后一个字段。必须使用额外的CRLF将正文与标题字段分开。
Non-SEND requests are not intended to carry message content, and are therefore not interruptible. Non-SEND request bodies MUST NOT be larger than 10240 octets.
非发送请求不打算携带消息内容，因此不可中断。非发送请求正文不得大于10240个八位字节。
Although this document does not discuss any particular usage of bodies in non-SEND requests, they may be useful in the future for carrying security or identity information, information about a message in progress, etc. The 10K size limit was chosen to be large enough for most of such applications, but small enough to avoid the fairness issues caused by sending arbitrarily large content in non-interruptible method bodies.
尽管本文档未讨论非发送请求中实体的任何特定用途，但它们在将来可能有助于承载安全或身份信息、有关正在进行的消息的信息等。选择10K大小的限制对于大多数此类应用来说是足够大的，但是足够小，可以避免在不可中断的方法体中发送任意大的内容所引起的公平性问题。
A request with no body MUST NOT include a Content-Type or any other MIME-specific header fields. A request without a body MUST contain an end-line after the final header field. No extra CRLF will be present between the header section and the end-line.
没有正文的请求不得包含内容类型或任何其他MIME特定的头字段。没有正文的请求必须在最终标题字段后包含结束行。标题部分和结束行之间不存在额外的CRLF。
Requests with no bodies are useful when a client wishes to send "traffic", but does not wish to send content to be rendered to the peer user. For example, the active endpoint sends a SEND request immediately upon establishing a connection. If it has nothing to say at the moment, it can send a request with no body. Bodiless requests may also be used in certain applications to keep Network Address Translation (NAT) bindings alive, etc.
当客户端希望发送“流量”，但不希望发送要呈现给对等用户的内容时，没有正文的请求很有用。例如，活动端点在建立连接后立即发送发送请求。如果它现在没有什么要说的，它可以在没有人的情况下发出请求。在某些应用程序中，也可以使用无体请求来保持网络地址转换（NAT）绑定的活动性等。
Bodiless requests are distinct from requests with empty bodies. A request with an empty body will have a Content-Type header field value and will generally be rendered to the recipient according to the rules for that type.
无实体请求不同于具有空实体的请求。具有空正文的请求将具有内容类型头字段值，并且通常将根据该类型的规则呈现给收件人。
The end-line that terminates the request MUST be composed of seven "-" (minus sign) characters, the transaction ID as used in the start line, and a flag character. If a body is present, the end-line MUST be preceded by a CRLF that is not part of the body. If the chunk represents the data that forms the end of the complete message, the flag value MUST be a "$". If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a "#". Otherwise, the flag MUST be a "+".
终止请求的结束行必须由七个“-”（减号）字符、开始行中使用的事务ID和标志字符组成。如果存在主体，则结束线之前必须有一个CRLF，该CRLF不是主体的一部分。如果区块表示构成完整消息结尾的数据，则标志值必须为“$”。如果发件人正在中止一条不完整的消息，并且不打算在该消息中再发送任何数据块，则标志必须为“#”。否则，标志必须是“+”。
If the request contains a body, the sender MUST ensure that the end-line (seven hyphens, the transaction identifier, and a continuation flag) is not present in the body. If the end-line is present in the body, the sender MUST choose a new transaction identifier that is not present in the body, and add a CRLF if needed, and the end-line, including the "$", "#", or "+" character.
如果请求包含正文，发送方必须确保正文中不存在结束行（七个连字符、事务标识符和延续标志）。如果正文中存在结束行，发送方必须选择正文中不存在的新事务标识符，并根据需要添加CRLF和结束行，包括“$”、“#”或“+”字符。
Some implementations may choose to scan for the closing sequence as they send the body, and if it is encountered, simply interrupt the chunk at that point and start a new transaction with a different transaction identifier to carry the rest of the body. Other implementations may choose to scan the data and ensure that the body does not contain the transaction identifier before they start sending the transaction.
一些实现可能会选择在发送正文时扫描结束序列，如果遇到，只需在该点中断区块，并使用不同的事务标识符启动新事务，以承载正文的其余部分。其他实现可能会选择扫描数据并确保主体在开始发送事务之前不包含事务标识符。
Once a request is ready for delivery, the sender follows the connection management (Section 5.4) rules to forward the request over an existing open connection or create a new connection.
一旦请求准备好交付，发送方将遵循连接管理（第5.4节）规则通过现有打开的连接转发请求或创建新连接。
When an endpoint has a message to deliver, it first generates a new Message-ID. The value MUST be highly unlikely to be repeated by another endpoint instance, or by the same instance in the future. If necessary, the endpoint breaks the message into chunks. It then generates a SEND request for each chunk, following the procedures for constructing requests (Section 7.1).
当一个端点有一条消息要传递时，它首先生成一个新的message-ID。该值不太可能被另一个端点实例重复，或者在将来被同一个实例重复。如果需要，端点会将消息分成块。然后，它按照构造请求的过程（第7.1节）为每个区块生成一个发送请求。
The Message-ID header field provides a unique message identifier that refers to a particular version of a particular message. The term "Message" in this context refers to a unit of content that the sender wishes to convey to the recipient. While such a message may be broken into chunks, the Message-ID refers to the entire message, not a chunk of the message.
Message ID header字段提供一个唯一的消息标识符，该标识符引用特定消息的特定版本。本文中的术语“消息”是指发送方希望传达给接收方的内容单元。虽然这样的消息可以分为多个块，但消息ID指的是整个消息，而不是消息的一个块。
The uniqueness of the message identifier is ensured by the host that generates it. This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one version of a particular message; subsequent revisions to the message each receive new message identifiers. Endpoints can ensure sufficient uniqueness in any number of ways, the selection of which is an implementation choice. For example, an endpoint could concatenate an instance identifier such as a MAC address, its idea of the number of seconds since the epoch, a process ID, and a monotonically increasing 16-bit integer, all base-64 encoded. Alternately, an endpoint without an on-board clock could simply use a 64-bit random number.
消息标识符的唯一性由生成它的主机来确保。该消息标识符是机器可读的，不一定对人类有意义。消息标识符仅与特定消息的一个版本相关；消息的后续修订都会接收新的消息标识符。端点可以以任意数量的方式确保足够的唯一性，其选择是一种实现选择。例如，端点可以连接实例标识符，例如MAC地址、自历元起的秒数、进程ID和单调递增的16位整数，所有这些都是基于64位编码的。或者，没有板载时钟的端点可以简单地使用64位随机数。
Each chunk of a message MUST contain a Message-ID header field containing the Message-ID. If the sender wishes non-default status reporting, it MUST insert a Failure-Report and/or Success-Report header field with an appropriate value. All chunks of the same message MUST use the same Failure-Report and Success-Report values in their SEND requests.
消息的每个区块必须包含包含消息ID的消息ID标头字段。如果发件人希望非默认状态报告，则必须插入具有适当值的失败报告和/或成功报告标头字段。同一消息的所有区块在其发送请求中必须使用相同的失败报告和成功报告值。
If success reports are requested, i.e., the value of the Success-Report header field is "yes", the sending device MAY wish to run a timer of some value that makes sense for its application and take action if a success report is not received in this time. There is no universal value for this timer. For many IM applications, it may be 2 minutes while for some trading systems it may be under a second. Regardless of whether such a timer is used, if the success report has not been received by the time the session is ended, the device SHOULD inform the user.
如果请求成功报告，即成功报告头字段的值为“是”，则发送设备可能希望运行对其应用有意义的某个值的计时器，并在此时未收到成功报告时采取行动。此计时器没有通用值。对于许多IM应用程序，它可能是2分钟，而对于某些交易系统，它可能不到一秒钟。无论是否使用此类计时器，如果在会话结束时尚未收到成功报告，则设备应通知用户。
If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. Regardless of the Failure-Report value, there is no requirement to wait for a response prior to sending the next request.
如果“故障报告”的值设置为“是”，则请求的发送方将运行计时器。如果在发送事务的最后一个字节后的30秒内未收到对事务的200响应，或未将其提交给操作系统进行发送，则元素必须通知用户请求可能失败。如果该值设置为“部分”，则发送事务的元素不必运行计时器，但必须通知用户是否接收到对事务的不可恢复错误响应。无论故障报告值如何，都不需要在发送下一个请求之前等待响应。
The treatment of timers for success reports and failure reports is intentionally inconsistent. An explicit timeout value makes sense for failure reports since such reports will usually refer to a message "chunk" that is acknowledged on a hop-by-hop basis. This
对成功报告和失败报告计时器的处理故意不一致。显式超时值对于故障报告是有意义的，因为此类报告通常引用逐跳确认的消息“块”。这
is not the case for success reports, which are end-to-end and may refer to the entire message content, which can be arbitrarily large.
成功报告不是这样的，它是端到端的，可能引用整个消息内容，可以任意大。
If no Success-Report header field is present in a SEND request, it MUST be treated the same as a Success-Report header field with a value of "no". If no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes". If an MSRP endpoint receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
如果发送请求中不存在成功报告标头字段，则必须将其视为值为“否”的成功报告标头字段。如果不存在故障报告标题字段，则必须将其视为值为“是”的故障报告标题字段。如果MSRP端点接收到一个它无法识别的消息ID的报告，它应该默默地忽略该报告。
The Byte-Range header field value contains a starting value (range-start) followed by a "-", an ending value (range-end) followed by a "/", and finally the total length. The first octet in the message has a position of one, rather than a zero.
字节范围标头字段值包含一个起始值（范围开始），后跟一个“-”，一个结束值（范围结束），后跟一个“/”，最后是总长度。消息中的第一个八位组的位置是1，而不是0。
The first chunk of the message SHOULD, and all subsequent chunks MUST, include a Byte-Range header field. The range-start field MUST indicate the position of the first byte in the body in the overall message (for the first chunk this field will have a value of one). The range-end field SHOULD indicate the position of the last byte in the body, if known. It MUST take the value of "*" if the position is unknown, or if the request needs to be interruptible. The total field SHOULD contain the total size of the message, if known. The total field MAY contain a "*" if the total size of the message is not known in advance. The sender MUST send all chunks in Byte-Range order. (However, the receiver cannot assume that the requests will be delivered in order, as intervening relays may have changed the order.)
消息的第一个区块以及所有后续区块必须包含字节范围标头字段。range start字段必须指示整个消息正文中第一个字节的位置（对于第一个块，此字段的值为1）。如果已知，范围结束字段应指示正文中最后一个字节的位置。如果位置未知，或者请求需要可中断，则必须采用“*”值。total字段应包含消息的总大小（如果已知）。如果事先不知道消息的总大小，则total字段可能包含“*”。发送方必须按字节范围顺序发送所有数据块。（但是，接收方不能假设请求将按顺序发送，因为中间继电器可能已更改顺序。）
There are some circumstances where an endpoint may choose to send an empty SEND request. For the sake of consistency, a Byte-Range header field referring to nonexistent or zero-length content MUST still have a range-start value of 1. For example, "1-0/0".
在某些情况下，端点可以选择发送空的发送请求。为保持一致性，引用不存在或长度为零的内容的字节范围标头字段的范围起始值必须仍然为1。例如，“1-0/0”。
To ensure fairness over a connection, senders MUST NOT send chunks with a body larger than 2048 octets unless they are prepared to interrupt them (meaning that any chunk with a body of greater than 2048 octets will have a "*" character in the range-end field). A sender can use one of the following two strategies to satisfy this requirement. The sender is STRONGLY RECOMMENDED to send messages larger than 2048 octets using as few chunks as possible, interrupting chunks (at least 2048 octets long) only when other traffic is waiting to use the same connection. Alternatively, the sender MAY simply send chunks in 2048-octet increments until the final chunk. Note that the former strategy results in markedly more efficient use of the connection. All MSRP nodes MUST be able to receive chunks of any size from zero octets to the maximum number of octets they can
为确保连接的公平性，发送方不得发送正文大于2048个八位字节的数据块，除非他们准备中断这些数据块（这意味着正文大于2048个八位字节的任何数据块在范围结束字段中将有一个“*”字符）。发送方可以使用以下两种策略之一来满足此要求。强烈建议发送方使用尽可能少的数据块发送大于2048个八位字节的消息，只有在其他流量等待使用相同连接时才中断数据块（至少2048个八位字节长）。或者，发送方可以简单地以2048个八位字节的增量发送块，直到最后一个块。请注意，前一种策略可以显著提高连接的使用效率。所有MSRP节点必须能够接收从零个八位字节到最大八位字节数的任意大小的块
receive for a complete message. Senders SHOULD NOT break messages into chunks smaller than 2048 octets, except for the final chunk of a complete message.
接收完整的消息。发件人不应将邮件分成小于2048个八位字节的块，完整邮件的最后一块除外。
A SEND request is interrupted while a body is in the process of being written to the connection by simply noting how much of the message has already been written to the connection, then writing out the end-line to end the chunk. It can then be resumed in a another chunk with the same Message-ID and a Byte-Range header field range start field containing the position of the first byte after the interruption occurred.
发送请求在主体写入连接的过程中被中断，只需记录有多少消息已写入连接，然后写出结束行以结束区块。然后，可以在另一个具有相同消息ID的块中恢复该消息，并在一个字节范围标头字段Range start字段中包含中断发生后第一个字节的位置。
SEND requests larger than 2048 octets MUST be interrupted if the sender needs to send pending responses or REPORT requests. If multiple SEND requests from different sessions are concurrently being sent over the same connection, the device SHOULD implement some scheme to alternate between them such that each concurrent request gets a chance to send some fair portion of data at regular intervals suitable to the application.
如果发送方需要发送挂起的响应或报告请求，则必须中断大于2048个八位字节的发送请求。如果来自不同会话的多个发送请求在同一连接上同时发送，则设备应实施一些方案以在它们之间交替发送，使得每个并发请求有机会以适合于应用程序的规则间隔发送一些公平的数据部分。
The sender MUST NOT assume that a message is received by the peer with the same chunk allocation with which it was sent. An intervening relay could possibly break SEND requests into smaller chunks, or aggregate multiple chunks into larger ones.
发送方不得假设对等方接收到的消息与发送消息时使用的块分配相同。中间中继可能会将发送请求分解为较小的块，或将多个块聚合为较大的块。
The default disposition of messages is to be rendered to the user. If the sender wants a different disposition, it MAY insert a Content-Disposition [9] header field. Values MAY include any from RFC 2183 [9] or the IANA registry it defines. Since MSRP can carry unencoded binary payloads, transfer encoding is always "binary", and transfer-encoding parameters MUST NOT be present.
消息的默认处置将呈现给用户。如果发送方需要不同的处置，则可以插入内容处置[9]标题字段。值可能包括来自RFC 2183[9]或其定义的IANA注册表的任何值。由于MSRP可携带未编码的二进制有效载荷，因此传输编码始终为“二进制”，且传输编码参数不得存在。
REPORT requests are similar to SEND requests, except that report requests MUST NOT include Success-Report or Failure-Report header fields, and MUST contain a Status header field. REPORT requests MUST contain the Message-ID header field from the original SEND request.
报告请求与发送请求类似，只是报告请求不得包含成功报告或失败报告标题字段，并且必须包含状态标题字段。报告请求必须包含原始发送请求中的消息ID标头字段。
If an MSRP element receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
如果一个MSRP元素收到一个它无法识别的消息ID的报告，它应该默默地忽略该报告。
An MSRP endpoint MUST be able to generate success REPORT requests.
MSRP端点必须能够生成成功报告请求。
REPORT requests will normally not include a body, as the REPORT request header fields can carry sufficient information in most cases. However, REPORT requests MAY include a body containing additional information about the status of the associated SEND request. Such a
报告请求通常不包括正文，因为在大多数情况下，报告请求标题字段可以包含足够的信息。然而，报告请求可以包括包含关于相关发送请求的状态的附加信息的主体。这样的
body is informational only, and the sender of the REPORT request SHOULD NOT assume that the recipient pays any attention to the body. REPORT requests are not interruptible.
正文仅供参考，报告请求的发件人不应假定收件人对正文有任何关注。报告请求不可中断。
Success-Report and Failure-Report header fields MUST NOT be present in REPORT requests. MSRP nodes MUST NOT send REPORT requests in response to REPORT requests. MSRP nodes MUST NOT send MSRP responses to REPORT requests.
报告请求中不得存在成功报告和失败报告标题字段。MSRP节点不得发送报告请求以响应报告请求。MSRP节点不得向报告请求发送MSRP响应。
Endpoints SHOULD NOT send REPORT requests if they have reason to believe the request will not be delivered. For example, they SHOULD NOT send a REPORT request for a session that is no longer valid.
如果端点有理由相信请求不会被传递，则不应发送报告请求。例如，他们不应该为不再有效的会话发送报告请求。
When an endpoint receives a message in one or more chunks that contain a Success-Report value of "yes", it MUST send a success report or reports covering all bytes that are received successfully. The success reports are sent in the form of REPORT requests, following the normal procedures (Section 7.1), with a few additional requirements.
当端点在一个或多个包含成功报告值“yes”的区块中接收到消息时，它必须发送一个或多个成功报告，涵盖成功接收的所有字节。成功报告以报告请求的形式发送，遵循正常程序（第7.1节），并附带一些附加要求。
The receiver MAY wait until it receives the last chunk of a message, and send a success report that covers the complete message. Alternately, it MAY generate incremental success REPORTs as the chunks are received. These can be sent periodically and cover all the bytes that have been received so far, or they can be sent after a chunk arrives and cover just the part from that chunk.
接收者可能会等到收到消息的最后一个区块，然后发送覆盖整个消息的成功报告。或者，它可以在接收到块时生成增量成功报告。它们可以周期性地发送，覆盖到目前为止接收到的所有字节，也可以在块到达后发送，只覆盖该块中的部分。
It is helpful to think of a success REPORT as reporting on a particular range of bytes, rather than on a particular chunk sent by a client. The sending client cannot depend on the Byte-Range header field in a given success report matching that of a particular SEND request. For example, an intervening MSRP relay may break chunks into smaller chunks, or aggregate multiple chunks into larger ones. A side effect of this is, even if no relay is used, the receiving client may report on byte ranges that do not exactly match those in the original chunks sent by the sender. It can wait until all bytes in a message are received and report on the whole, it can report as it receives each chunk, or it can report on any other received range. Reporting on ranges smaller than the entire message contents allows certain improved user experiences for the sender. For example, a sending client could display incremental status information showing which ranges of bytes have been acknowledged by the receiver. However, the choice on whether to report incrementally is entirely up to the receiving client. There is no mechanism for the sender to assert its desire to receive incremental reports or not. Since the presence of a
将成功报告视为对特定字节范围的报告，而不是对客户端发送的特定数据块的报告，这是很有帮助的。发送客户端不能依赖与特定发送请求匹配的给定成功报告中的字节范围标头字段。例如，中间的MSRP中继可能会将块分解为较小的块，或将多个块聚合为较大的块。这样做的一个副作用是，即使没有使用中继，接收客户端也可能报告与发送方发送的原始块中的字节范围不完全匹配的字节范围。它可以等到消息中的所有字节都被接收后再报告，它可以在接收每个数据块时报告，也可以报告任何其他接收范围。报告小于整个邮件内容的范围可以改善发件人的某些用户体验。例如，发送客户端可以显示增量状态信息，显示接收方已确认的字节范围。但是，是否增量报告的选择完全取决于接收客户机。发送方没有任何机制来声明其是否希望接收增量报告。因为有一个
relay can cause the receiver to see a very different chunk allocation than the sender, such a mechanism would be of questionable value.
中继可能导致接收方看到与发送方非常不同的块分配，这种机制的价值值得怀疑。
When generating a REPORT request, the endpoint inserts a To-Path header field containing the From-Path value from the original request, and a From-Path header field containing the URI identifying itself in the session. The endpoint then inserts a Status header field with a namespace of "000", a status-code of "200", and an implementation-defined comment phrase. It also inserts a Message-ID header field containing the value from the original request.
生成报告请求时，端点将插入一个To Path头字段，其中包含来自原始请求的From Path值，以及一个From Path头字段，其中包含在会话中标识自身的URI。然后，端点插入一个名称空间为“000”、状态代码为“200”和实现定义的注释短语的状态头字段。它还插入一个消息ID头字段，其中包含来自原始请求的值。
The namespace field denotes the context of the status-code field. The namespace value of "000" means the status-code should be interpreted in the same way as the matching MSRP transaction response code. If a future specification uses the status-code field for some other purpose, it MUST define a new namespace field value.
名称空间字段表示状态代码字段的上下文。名称空间值“000”表示状态代码的解释方式应与匹配的MSRP事务响应代码相同。如果将来的规范将状态代码字段用于其他目的，则必须定义新的命名空间字段值。
The endpoint MUST NOT send a success report for a SEND request that either contained no Success-Report header field or contained such a field with a value of "no". That is, if no Success-Report header field is present, it is treated identically to one with a value of "no".
对于不包含成功报告标头字段或包含值为“否”的字段的发送请求，终结点不得发送成功报告。也就是说，如果不存在成功报告标题字段，则该字段的处理方式与值为“否”的字段相同。
If an MSRP endpoint receives a SEND request that it cannot process for some reason, and the Failure-Report header field either was not present in the original request or had a value of "yes", it SHOULD simply include the appropriate error code in the transaction response. However, there may be situations where the error cannot be determined quickly, such as when the endpoint is a gateway that waits for a downstream network to indicate an error. In this situation, it MAY send a 200 OK response to the request, and then send a failure REPORT request when the error is detected.
如果某个MSRP端点接收到一个由于某种原因而无法处理的发送请求，并且原始请求中不存在故障报告头字段，或者该字段的值为“是”，那么它只应在事务响应中包含相应的错误代码。然而，可能存在无法快速确定错误的情况，例如当端点是等待下游网络指示错误的网关时。在这种情况下，它可能会向请求发送200 OK响应，然后在检测到错误时发送失败报告请求。
If the endpoint receives a SEND request with a Failure-Report header field value of "no", then it MUST NOT send a failure REPORT request, and MUST NOT send a transaction response. If the value is "partial", it MUST NOT send a 200 transaction response to the request, but SHOULD send an appropriate non-200 class response if a failure occurs.
如果端点接收到失败报告头字段值为“否”的发送请求，则它不得发送失败报告请求，也不得发送事务响应。如果该值为“partial”，则它不得向请求发送200事务响应，但在发生故障时应发送适当的非200类响应。
As stated above, if no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes".
如上所述，如果不存在故障报告标题字段，则必须将其视为值为“是”的故障报告标题字段。
Construction of failure REPORT requests is identical to that for success REPORT requests, except the Status header field code field MUST contain the appropriate error code. Any error response code defined in this specification MAY also be used in failure reports.
失败报告请求的构造与成功报告请求的构造相同，只是状态标头字段代码字段必须包含相应的错误代码。本规范中定义的任何错误响应代码也可用于故障报告中。
If a failure REPORT request is sent in response to a SEND request that contained a chunk, it MUST include a Byte-Range header field indicating the actual range being reported on. It can take the range-start and total values from the original SEND request, but MUST calculate the range-end field from the actual body data.
如果发送失败报告请求是为了响应包含区块的发送请求，则该请求必须包含一个字节范围标头字段，指示报告的实际范围。它可以从原始发送请求中获取范围起始值和总值，但必须从实际正文数据计算范围结束字段。
This section only describes failure report generation behavior for MSRP endpoints. Relay behavior is beyond the scope of this document, and will be considered in a separate document [23]. We expect failure reports to be more commonly generated by relays than by endpoints.
本节仅描述MSRP端点的故障报告生成行为。继电器行为超出了本文件的范围，将在单独的文件[23]中予以考虑。我们预计故障报告通常由继电器生成，而不是由端点生成。
If an MSRP endpoint receives a request that either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header field at all, it MUST immediately generate a response. Likewise, if an MSRP endpoint receives a request that contains a Failure-Report header field value of "partial", and the receiver is unable to process the request, it SHOULD immediately generate a response.
如果MSRP端点接收到包含故障报告标题字段值“是”或根本不包含故障报告标题字段的请求，则必须立即生成响应。同样，如果MSRP端点接收到包含故障报告头字段值“partial”的请求，并且接收方无法处理该请求，则应立即生成响应。
To construct the response, the endpoint first creates the response start line, inserting the appropriate response code and optionally a comment. The transaction identifier in the response start line MUST match the transaction identifier from the original request.
要构造响应，端点首先创建响应起始行，插入适当的响应代码和注释（可选）。响应开始行中的事务标识符必须与原始请求中的事务标识符匹配。
The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the first (leftmost) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by copying the list of URIs from the From-Path of the original request into the To-Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above; however, we expect that extensions for gateways and relays will need such behavior.)
然后，端点插入一个适当的To Path头字段。如果触发响应的请求是发送请求，则通过复制请求的From Path头字段中的第一个（最左侧）URI来形成To Path头字段。（发送请求的响应仅返回到上一个跃点。）对于所有其他请求方法的响应，“到路径头”字段包含返回到原始发件人的完整路径。此完整路径是通过将URI列表从原始请求的from路径复制到响应的To路径生成的。（法律报告请求不请求响应，因此本规范不执行上述行为；但是，我们预计网关和中继的扩展将需要此类行为。）
Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. Since a response is never
最后，端点插入一个From Path头字段，该字段包含在会话上下文中标识它的URI，后跟最后一个头字段后的结束行。因为一个回应永远都不是
chunked, the continuation flag in the end-line will always contain a dollar sign ("$"). The response MUST be transmitted back on the same connection on which the original request arrived.
如果分块，则结束行中的继续标志将始终包含一个美元符号（$）。响应必须在原始请求到达的同一连接上传输回。
The receiving endpoint MUST first check the URI in the To-Path to make sure the request belongs to an existing session. When the request is received, the To-Path will have exactly one URI, which MUST map to an existing session that is associated with the connection on which the request arrived. If this is not true, then the receiver MUST generate a 481 error and ignore the request. Note that if the Failure-Report header field had a value of "no", then no error report would be sent.
接收端点必须首先检查To路径中的URI，以确保请求属于现有会话。当接收到请求时，To路径将正好有一个URI，该URI必须映射到与请求到达的连接关联的现有会话。如果这不是真的，那么接收方必须生成481错误并忽略请求。请注意，如果故障报告标题字段的值为“否”，则不会发送错误报告。
Further request processing by the receiver is method specific.
接收器的进一步请求处理是方法特定的。
When the receiving endpoint receives a SEND request, it first determines if it contains a complete message or a chunk from a larger message. If the request contains no Byte-Range header field, or contains one with a range-start value of "1", and the closing line continuation flag has a value of "$", then the request contained the entire message. Otherwise, the receiver looks at the Message-ID value to associate chunks together into the original message. The receiver forms a virtual buffer to receive the message, keeping track of which bytes have been received and which are missing. The receiver takes the data from the request and places it in the appropriate place in the buffer. The receiver SHOULD determine the actual length of each chunk by inspecting the payload itself; it is possible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly. It is worth noting that the chunk that has a termination character of "$" defines the total length of the message.
当接收端点接收到发送请求时，它首先确定它是包含完整的消息还是来自较大消息的区块。如果请求不包含字节范围标头字段，或包含范围起始值为“1”的字段，且结束行继续标志的值为“$”，则请求包含整个消息。否则，接收方查看消息ID值，将块关联到原始消息中。接收器形成一个虚拟缓冲区来接收消息，跟踪哪些字节已被接收，哪些字节丢失。接收方从请求中获取数据并将其放置在缓冲区中的适当位置。接收器应通过检查有效载荷本身来确定每个区块的实际长度；主体可能比范围结束字段指示的短。如果发送方意外中断了发送请求，则可能发生这种情况。值得注意的是，终止字符为“$”的区块定义了消息的总长度。
It is technically illegal for the sender to prematurely interrupt a request that had anything other than "*" in the last-byte position of the Byte-Range header field. But having the receiver calculate a chunk length based on actual content adds resilience in the face of sender errors. Since this should never happen with compliant senders, this only has a "SHOULD" strength.
从技术上讲，发送方提前中断在字节范围标头字段的最后一个字节位置中除“*”以外的任何内容的请求是非法的。但是，让接收者根据实际内容计算区块长度可以增加在面对发送者错误时的弹性。由于这种情况不应该发生在兼容的发送方身上，因此它只有“应该”的优势。
Receivers MUST not assume that the chunks will be delivered in order or that they will receive all the chunks with "+" flags before they receive the chunk with the "$" flag. In certain cases of connection failure, it is possible for information to be duplicated. If chunk data is received that overlaps already received data for the same
接收者在收到带有“$”标志的区块之前，不得假定区块将按顺序交付，或假定他们将收到带有“+”标志的所有区块。在某些连接失败的情况下，可能会复制信息。如果接收到的区块数据与已接收到的数据重叠
message, the last chunk received SHOULD take precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to 100 were received and a chunk arrives that contains bytes 50 to 150, this second chunk will overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this is the easiest for the receiver and results in consistent behavior between clients.
消息时，接收的最后一个区块应优先（即使这可能不是传输的最后一个区块）。例如，如果接收到字节1到100，并且到达的区块包含字节50到150，则第二个区块将覆盖已经接收到的数据的字节50到100。虽然其他方案也可以工作，但这对于接收方来说是最容易的，并且会导致客户端之间的行为一致。
There are situations in which the receiver may not be able to give precedence to the last chunk received when chunks overlap. For example, the recipient might incrementally render chunks as they arrive. If a new chunk arrives that overlaps with a previously rendered chunk, it would be too late to "take back" any conflicting data from the first chunk. Therefore, the requirement to give precedence to the most recent chunk is specified at a "SHOULD" strength. This requirement is not intended to disallow applications where this behavior does not make sense.
在某些情况下，当数据块重叠时，接收方可能无法优先考虑接收到的最后一个数据块。例如，收件人可能会在块到达时以增量方式呈现它们。如果到达的新块与先前呈现的块重叠，则从第一个块“收回”任何冲突数据将为时已晚。因此，以“应该”强度指定优先于最近的块的要求。此要求并不打算禁止这种行为没有意义的应用程序。
The seven "-" in the end-line are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable
location of the end-line. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the header
fields of the request, but also allows for the interruption of
messages.
The seven "-" in the end-line are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable
location of the end-line. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the header
fields of the request, but also allows for the interruption of
messages.
What is done with the body is outside the scope of MSRP and largely determined by the MIME Content-Type and Content-Disposition. The body MAY be rendered after the whole message is received or partially rendered as it is being received.
对主体的处理超出了MSRP的范围，主要取决于MIME内容类型和内容配置。正文可以在接收到整个消息后呈现，也可以在接收时部分呈现。
If the SEND request contained a Content-Type header field indicating an unsupported media-type, and the Failure-Report value is not "no", the receiver MUST generate a response with a status code of 415. All MSRP endpoints MUST be able to receive the multipart/mixed [15] and multipart/alternative [15] media-types.
如果发送请求包含指示不支持的媒体类型的内容类型报头字段，并且故障报告值不是“否”，则接收器必须生成状态代码为415的响应。所有MSRP端点必须能够接收多部分/混合[15]和多部分/备选[15]媒体类型。
If the Success-Report header field was set to "yes", the receiver must construct and send one or more success reports, as described in Section 7.1.3.
如果成功报告标题字段设置为“是”，则接收方必须构建并发送一个或多个成功报告，如第7.1.3节所述。
When an endpoint receives a REPORT request, it correlates the report to the original SEND request using the Message-ID and the Byte-Range, if present. If it requested success reports, then it SHOULD keep enough state about each outstanding sent message so that it can correlate REPORT requests to the original messages.
当端点接收到报告请求时，它使用消息ID和字节范围（如果存在）将报告与原始发送请求关联起来。如果它请求了成功报告，那么它应该对每个未完成的已发送消息保持足够的状态，以便能够将报告请求与原始消息关联起来。
An endpoint that receives a REPORT request containing a Status header field with a namespace field of "000" MUST interpret the report in exactly the same way it would interpret an MSRP transaction response with a response code matching the status-code field.
接收包含名称空间字段为“000”的状态标头字段的报告请求的端点必须以与解释响应代码与状态代码字段匹配的MSRP事务响应完全相同的方式解释报告。
It is possible to receive a failure report or a failure transaction response for a chunk that is currently being delivered. In this case, the entire message corresponding to that chunk SHOULD be aborted, by including the "#" character in the continuation field of the end-line.
可以接收当前正在交付的区块的故障报告或故障事务响应。在这种情况下，应该通过在结束行的continuation字段中包含“#”字符来中止与该块对应的整个消息。
It is possible that an endpoint will receive a REPORT request on a session that is no longer valid. The endpoint's behavior if this happens is a matter of local policy. The endpoint is not required to take any steps to facilitate such late delivery; i.e., it is not expected to keep a connection active in case late REPORTs might arrive.
端点可能会在不再有效的会话上收到报告请求。如果发生这种情况，端点的行为取决于本地策略。端点无需采取任何措施来促进此类延迟交付；i、 例如，不希望保持连接处于活动状态，以防可能出现延迟报告。
When an endpoint that sent a SEND request receives a failure REPORT indicating that a particular byte range was not received, it MUST treat the session as failed. If it wishes to recover, it MUST first re-negotiate the URIs at the signaling level then resend that range of bytes of the message on the resulting new session.
当发送发送请求的端点收到指示未收到特定字节范围的失败报告时，它必须将会话视为失败。如果它希望恢复，它必须首先在信令级别重新协商URI，然后在生成的新会话上重新发送消息的该字节范围。
MSRP nodes MUST NOT send MSRP REPORT requests in response to other REPORT requests.
MSRP节点不得发送MSRP报告请求以响应其他报告请求。
MSRP sessions will typically be initiated using the Session Description Protocol (SDP) [2] via the SIP offer/answer mechanism [3].
MSRP会话通常使用会话描述协议（SDP）[2]通过SIP提供/应答机制[3]启动。
This document defines a handful of new SDP parameters to set up MSRP sessions. These are detailed below and in the IANA Considerations section.
本文档定义了一些新的SDP参数，用于设置MSRP会话。下面和IANA注意事项部分详细介绍了这些内容。
An MSRP media-line (that is, a media-line proposing MSRP) in the session description is accompanied by a mandatory "path" attribute. This attribute contains a space-separated list of URIs to be visited
会话描述中的MSRP媒体行（即建议MSRP的媒体行）附带一个强制的“路径”属性。此属性包含以空格分隔的要访问的URI列表
to contact the user agent advertising this session description. If more than one URI is present, the leftmost URI is the first URI to be visited to reach the target resource. (The path list can contain multiple URIs to allow for the deployment of gateways or relays in the future.) MSRP implementations that can accept incoming connections without the need for relays will typically only provide a single URI here.
要联系公布此会话说明的用户代理，请执行以下操作。如果存在多个URI，则最左边的URI是访问目标资源的第一个URI。（路径列表可以包含多个URI，以便将来部署网关或中继。）可以接受传入连接而不需要中继的MSRP实现通常只提供一个URI。
An MSRP media line is also accompanied by an "accept-types" attribute, and optionally an "accept-wrapped-types" attribute. These attributes are used to specify the media-types that are acceptable to the endpoint.
MSRP媒体行还附带“接受类型”属性和可选的“接受包装类型”属性。这些属性用于指定端点可接受的媒体类型。
An SDP connection-line takes the following format:
SDP连接线采用以下格式：
c=<network type> <address type> <connection address>
c=<network type> <address type> <connection address>
Figure 4: Standard SDP Connection Line
图4：标准SDP连接线
The network type and address type fields are used as normal for SDP. The connection address field MUST be set to the IP address or fully qualified domain name from the MSRP URI identifying the endpoint in its path attribute.
网络类型和地址类型字段通常用于SDP。必须将连接地址字段设置为MSRP URI中的IP地址或完全限定域名，以在其路径属性中标识端点。
The general format of an SDP media-line is:
SDP媒体行的一般格式为：
m=<media> <port> <protocol> <format list>
m=<media> <port> <protocol> <format list>
Figure 5: Standard SDP Media Line
图5：标准SDP媒体线路
An offered or accepted media-line for MSRP over TCP MUST include a protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The media field value MUST be "message". The format list field MUST be set to "*".
通过TCP为MSRP提供或接受的媒体线路必须包括协议字段值“TCP/MSRP”，或TLS的“TCP/TLS/MSRP”。媒体字段值必须为“消息”。格式列表字段必须设置为“*”。
The port field value MUST match the port value used in the endpoint's MSRP URI in the path attribute, except that, as described in [3], a user agent that wishes to accept an offer, but not a specific media-line, MUST set the port number of that media-line to zero (0) in the response. Since MSRP allows multiple sessions to share the same TCP connection, multiple m-lines in a single SDP document may share the same port field value; MSRP devices MUST NOT assume any particular relationship between m-lines on the sole basis that they have matching port field values.
端口字段值必须与path属性中端点的MSRP URI中使用的端口值相匹配，除非如[3]中所述，希望接受要约而非特定媒体线路的用户代理必须在响应中将该媒体线路的端口号设置为零（0）。由于MSRP允许多个会话共享同一TCP连接，因此单个SDP文档中的多条m线可能共享相同的端口字段值；MSRP设备不得仅基于m线具有匹配的端口字段值而假定它们之间存在任何特定关系。
MSRP devices do not use the c-line address field, or the m-line port and format list fields to determine where to connect. Rather, they use the attributes defined in this specification. The connection information is copied to the c-line and m-line for purposes of backwards compatibility with conventional SDP usages. While MSRP could theoretically carry any media-type, "message" is appropriate.
MSRP设备不使用c-line地址字段或m-line端口和格式列表字段来确定连接位置。相反，它们使用本规范中定义的属性。为了与传统SDP用法向后兼容，连接信息被复制到c线和m线。虽然MSRP理论上可以承载任何媒体类型，“消息”是合适的。
Each endpoint in an MSRP session is identified by a URI. These URIs are negotiated in the SDP exchange. Each SDP offer or answer that proposes MSRP MUST contain a "path" attribute containing one or more MSRP URIs. The path attribute is used in an SDP a-line, and has the following syntax:
MSRP会话中的每个端点都由URI标识。这些URI在SDP交换中协商。提出MSRP的每个SDP提议或回答必须包含一个包含一个或多个MSRP URI的“路径”属性。path属性用于SDP a-line中，具有以下语法：
path = path-label ":" path-list
path-label = "path"
path-list= MSRP-URI *(SP MSRP-URI)
path = path-label ":" path-list
path-label = "path"
path-list= MSRP-URI *(SP MSRP-URI)
Figure 6: Path Attribute
图6：路径属性
where MSRP-URI is an "msrp" or "msrps" URI as defined in Section 6. MSRP URIs included in an SDP offer or answer MUST include explicit port numbers.
其中，MSRP-URI是第6节中定义的“MSRP”或“msrps”URI。SDP报价或应答中包含的MSRP URI必须包含明确的端口号。
An MSRP device uses the URI to determine a host address, port, transport, and protection level when connecting, and to identify the target when sending requests and responses.
MSRP设备在连接时使用URI确定主机地址、端口、传输和保护级别，并在发送请求和响应时识别目标。
The offerer and answerer each selects a URI to represent itself and sends that URI to its peer in the SDP document. Each peer stores the path value received from the other peer and uses that value as the target for requests inside the resulting session. If the path attribute received from the peer contains more than one URI, then the target URI is the rightmost, while the leftmost entry represents the adjacent hop. If only one entry is present, then it is both the peer and adjacent hop URI. The target path is the entire path attribute value received from the peer.
报价人和应答人各自选择一个URI来表示自己，并将该URI发送给SDP文档中的对等方。每个对等方存储从另一个对等方接收的路径值，并将该值用作结果会话内请求的目标。如果从对等方接收的路径属性包含多个URI，则目标URI是最右边的，而最左边的条目表示相邻的跃点。如果只存在一个条目，则它同时是对等和相邻的跃点URI。目标路径是从对等方接收的整个路径属性值。
The following example shows an SDP offer with a session URI of
"msrp://alice.example.com:7394/2s93i9ek2a;tcp"
The following example shows an SDP offer with a session URI of
"msrp://alice.example.com:7394/2s93i9ek2a;tcp"
v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alice.example.com:7394/2s93i9ek2a;tcp
v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alice.example.com:7394/2s93i9ek2a;tcp
Figure 7: Example SDP with Path Attribute
图7：带有路径属性的示例SDP
The rightmost URI in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URI in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14.
path属性中最右边的URI必须标识生成SDP文档的端点，或该端点希望接收与会话关联的请求的其他位置。必须为此特定会话分配它，并且不得复制端点当前参与的任何其他会话所使用的任何URI。这应该是很难猜测的，并且要防止被窃听。第14节对此进行了更详细的讨论。
As mentioned previously, this document describes MSRP for peer-to-peer scenarios, that is, when no relays are used. The use of relays is described in a separate document [23]. In order to allow an MSRP device that only implements the core specification to interoperate with devices that use relays, this document must include a few assumptions about how relays work.
如前所述，本文件描述了点对点方案的MSRP，即不使用继电器的情况。继电器的使用在单独的文件[23]中描述。为了使仅实现核心规范的MSRP设备能够与使用继电器的设备进行互操作，本文档必须包含关于继电器工作方式的一些假设。
An endpoint that uses one or more relays will indicate that by putting a URI for each device in the relay chain into the SDP path attribute. The final entry will point to the endpoint itself. The other entries will indicate each proposed relay, in order. The first entry will point to the first relay in the chain from the perspective of the peer, that is, the relay to which the peer device, or a relay operating on its behalf, should connect.
使用一个或多个中继的端点将通过将中继链中每个设备的URI放入SDP path属性来指示。最后一个条目将指向端点本身。其他条目将按顺序指示每个建议的继电器。第一个条目将从对等设备的角度指向链中的第一个中继器，即对等设备或代表其运行的中继器应连接到的中继器。
Endpoints that do not wish to insert a relay, including those that do not support relays at all, will put exactly one URI into the path attribute. This URI represents both the endpoint for the session and the connection point.
不希望插入中继的端点（包括那些根本不支持中继的端点）将只在路径属性中放入一个URI。此URI表示会话的端点和连接点。
Even though endpoints that implement only this specification will never introduce a relay, they need to be able to interoperate with other endpoints that do use relays. Therefore, they MUST be prepared to receive more than one URI in the SDP path attribute. When an endpoint receives more than one URI in a path attribute, only the
即使只实现此规范的端点永远不会引入中继，它们也需要能够与使用中继的其他端点进行互操作。因此，它们必须准备好接收SDP path属性中的多个URI。当端点在路径属性中接收到多个URI时，只有
first entry is relevant for purposes of resolving the address and port, and establishing the network connection, as it describes the first adjacent hop.
第一个条目与解析地址和端口以及建立网络连接有关，因为它描述了第一个相邻跃点。
If an endpoint puts more than one URI in a path attribute, the final URI in the path attribute (the peer URI) identifies the session, and MUST not duplicate the URI of any other session in which the endpoint is currently participating. Uniqueness requirements for other entries in the path attribute are out of scope for this document.
如果端点在路径属性中放置了多个URI，则路径属性中的最终URI（对等URI）将标识会话，并且不得复制端点当前参与的任何其他会话的URI。路径属性中其他条目的唯一性要求超出了本文档的范围。
MSRP endpoints may sometimes need to send additional SDP exchanges for an existing session. They may need to send periodic exchanges with no change to refresh state in the network, for example, SIP session timers or the SIP UPDATE [24] request. They may need to change some other stream in a session without affecting the MSRP stream, or they may need to change an MSRP stream without affecting some other stream.
MSRP端点有时可能需要为现有会话发送额外的SDP交换。他们可能需要发送定期交换，而不改变网络中的刷新状态，例如SIP会话计时器或SIP更新[24]请求。他们可能需要在会话中更改某些其他流而不影响MSRP流，或者他们可能需要更改MSRP流而不影响某些其他流。
Either peer may initiate an updated exchange at any time. The endpoint that sends the new offer assumes the role of offerer for all purposes. The answerer MUST respond with a path attribute that represents a valid path to itself at the time of the updated exchange. This new path may be the same as its previous path, but may be different. The new offerer MUST NOT assume that the peer will answer with the same path it used previously.
任何一个对等方都可以随时启动更新的交换。发送新要约的端点在所有情况下都承担要约人的角色。应答者必须使用path属性进行响应，该属性表示更新交换时自身的有效路径。此新路径可能与其以前的路径相同，但可能不同。新的发盘方不得假设对方将使用之前使用的相同路径进行应答。
If either party wishes to send an SDP document that changes nothing at all, then it MUST use the same o-line as in the previous exchange.
如果任何一方希望发送一份完全不改变任何内容的SDP文档，则必须使用与先前交换中相同的o型线。
Previous versions of this document included a mechanism to negotiate the direction for any required TCP connection. The mechanism was loosely based on the Connection-Oriented Media (COMEDIA) [26] work done by the MMUSIC working group. The primary motivation was to allow MSRP sessions to succeed in situations where the offerer could not accept connections but the answerer could. For example, the offerer might be behind a NAT, while the answerer might have a globally routable address.
本文档的早期版本包括一种机制，用于协商任何所需TCP连接的方向。该机制松散地基于MMUSIC工作组所做的面向连接的媒体（喜剧）[26]工作。主要动机是允许MSRP会话在报价人无法接受连接但应答人可以接受的情况下成功。例如，报价人可能在NAT后面，而应答人可能有一个全局可路由地址。
The SIMPLE working group chose to remove that mechanism from MSRP, as it added a great deal of complexity to connection management. Instead, MSRP now specifies a default connection direction. The party that sent the original offer is responsible for connecting to its peer.
简单工作组选择从MSRP中删除该机制，因为它给连接管理增加了大量复杂性。相反，MSRP现在指定默认连接方向。发送原始报价的一方负责连接到其对等方。
An SDP media-line proposing MSRP MUST be accompanied by an accept-types attribute.
建议MSRP的SDP媒体行必须附带accept types属性。
An entry of "*" in the accept-types attribute indicates that the sender may attempt to send content with media-types that have not been explicitly listed. Likewise, an entry with an explicit type and a "*" character as the subtype indicates that the sender may attempt to send content with any subtype of that type. If the receiver receives an MSRP request and is able to process the media-type, it does so. If not, it will respond with a 415 response. Note that all explicit entries SHOULD be considered preferred over any non-listed types. This feature is needed as, otherwise, the list of formats for rich IM devices may be prohibitively large.
“接受类型”属性中的“*”项表示发件人可能尝试发送未明确列出的媒体类型的内容。同样，带有显式类型和“*”字符作为子类型的条目表示发送者可以尝试发送包含该类型的任何子类型的内容。如果接收器接收到MSRP请求并且能够处理媒体类型，则它会这样做。如果不是，它将以415响应进行响应。请注意，所有显式条目都应优先于任何未列出的类型。此功能是必需的，否则，丰富IM设备的格式列表可能会非常大。
This specification requires the support of certain data formats. Mandatory formats MUST be signaled like any other, either explicitly or by the use of a "*".
本规范要求支持某些数据格式。强制性格式必须像任何其他格式一样，显式地或通过使用“*”来表示。
The accept-types attribute may include container types, that is, MIME formats that contain other types internally. If compound types are used, the types listed in the accept-types attribute may be used as the root payload or may be wrapped in a listed container type. Any container types MUST also be listed in the accept-types attribute.
“接受类型”属性可能包括容器类型，即内部包含其他类型的MIME格式。如果使用复合类型，则“接受类型”属性中列出的类型可以用作根有效负载，或者可以包装在列出的容器类型中。任何容器类型也必须在“接受类型”属性中列出。
Occasionally, an endpoint will need to specify a MIME media-type that can only be used if wrapped inside a listed container type.
有时，端点将需要指定一个MIME媒体类型，该类型仅在包装在列出的容器类型中时才能使用。
Endpoints MAY specify media-types that are only allowed when wrapped inside compound types using the "accept-wrapped-types" attribute in an SDP a-line.
端点可以指定仅当使用SDP a行中的“接受包装类型”属性包装在复合类型中时才允许的媒体类型。
The semantics for accept-wrapped-types are identical to those of the accept-types attribute, with the exception that the specified types may only be used when wrapped inside container types listed in the accept-types attribute. Only types listed in the accept-types attribute may be used as the "root" type for the entire body. Since any type listed in accept-types may be both used as a root body and wrapped in other bodies, format entries from accept-types SHOULD NOT be repeated in this attribute.
accept-wrapped类型的语义与accept-types属性的语义相同，唯一的例外是指定的类型只能在accept-types属性中列出的容器类型中进行包装时使用。只有“接受类型”属性中列出的类型才能用作整个正文的“根”类型。由于accept types中列出的任何类型都可以用作根主体并包装在其他主体中，因此accept types中的格式条目不应在此属性中重复。
This approach does not allow for specifying distinct lists of acceptable wrapped types for different types of containers. If an endpoint understands a media-type in the context of one wrapper, it is assumed to understand it in the context of any other acceptable wrappers, subject to any constraints defined by the wrapper types themselves.
这种方法不允许为不同类型的容器指定可接受的包装类型的不同列表。如果端点在一个包装器的上下文中理解一个媒体类型，则假定它在任何其他可接受包装器的上下文中理解它，并受包装器类型本身定义的任何约束。
The approach of specifying types that are only allowed inside of containers separately from the primary payload types allows an endpoint to force the use of certain wrappers. For example, a Common Presence and Instant Messaging (CPIM) [12] gateway device may require all messages to be wrapped inside message/cpim bodies, but may allow several content types inside the wrapper. If the gateway were to specify the wrapped types in the accept-types attribute, its peer might attempt to use those types without the wrapper.
指定仅允许在容器内部与主要有效负载类型分开的类型的方法允许端点强制使用某些包装器。例如，公共存在和即时消息传递（CPIM）[12]网关设备可能要求将所有消息包装在消息/CPIM主体内，但可能允许包装内有多种内容类型。如果网关要在accept types属性中指定包装类型，则其对等方可能会尝试在没有包装的情况下使用这些类型。
If the recipient of an offer does not understand any of the payload types indicated in the offered SDP, it SHOULD indicate that using the appropriate mechanism of the rendezvous protocol. For example, in SIP, it SHOULD return a SIP 488 response.
如果要约接收人不了解所提供SDP中指示的任何有效载荷类型，则应使用集合协议的适当机制指示。例如，在SIP中，它应该返回SIP488响应。
An MSRP endpoint MUST NOT send content of a type not signaled by the peer in either an accept-types or an accept-wrapped-types attribute. Furthermore, it MUST NOT send a top-level (i.e., not wrapped) MIME document of a type not signaled in the accept-types attribute. In either case, the signaling could be explicit, or implicit through the use of the "*" character.
MSRP端点不得发送接受类型或接受包装类型属性中未由对等方发出信号的类型的内容。此外，它不能发送接受类型属性中未标记类型的顶级（即未包装）MIME文档。在这两种情况下，通过使用“*”字符，信号可以是显式的，也可以是隐式的。
An endpoint MAY indicate the maximum size message it wishes to receive using the max-size a-line attribute. Max-size refers to the complete message in octets, not the size of any one chunk. Senders SHOULD NOT exceed the max-size limit for any message sent in the resulting session. However, the receiver should consider max-size value as a hint.
端点可以使用“最大大小a行”属性指示它希望接收的最大大小消息。最大大小是指以八位字节表示的完整消息，而不是任何一个块的大小。发件人不应超过结果会话中发送的任何邮件的最大大小限制。然而，接收器应该考虑最大尺寸值作为提示。
Media format entries may include parameters. The interpretation of such parameters varies between media-types. For the purposes of media-type negotiation, a format-entry with one or more parameters is assumed to match the same format-entry with no parameters.
媒体格式条目可以包括参数。这些参数的解释因介质类型而异。出于媒体类型协商的目的，假设具有一个或多个参数的格式条目与没有参数的相同格式条目相匹配。
The formal syntax for these attributes is as follows:
这些属性的形式语法如下所示：
accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry)
format-entry = ( ( (type "/" subtype)
/ (type "/" "*") )
*( ";" type-param ) )
/ ("*")
accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry)
format-entry = ( ( (type "/" subtype)
/ (type "/" "*") )
*( ";" type-param ) )
/ ("*")
type = token
subtype = token
type-param = parm-attribute "=" parm-value
parm-attribute = token
parm-value = token / quoted-string
type = token
subtype = token
type-param = parm-attribute "=" parm-value
parm-attribute = token
parm-value = token / quoted-string
max-size = max-size-label ":" max-size-value
max-size-label = "max-size"
max-size-value = 1*(DIGIT) ; max size in octets
max-size = max-size-label ":" max-size-value
max-size-label = "max-size"
max-size-value = 1*(DIGIT) ; max size in octets
Figure 8: Attribute Syntax
图8：属性语法
Endpoint A wishes to invite Endpoint B to an MSRP session. A offers the following session description:
端点A希望邀请端点B参加MSRP会话。A提供以下会话描述：
v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i93idj;tcp
v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i93idj;tcp
Figure 9: SDP from Endpoint A
图9：来自端点A的SDP
B responds with its own URI:
B使用自己的URI进行响应：
v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8493 TCP/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438dsaodes;tcp
v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8493 TCP/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438dsaodes;tcp
Figure 10: SDP from Endpoint B
图10：端点B的SDP
In typical SIP applications, when an endpoint receives an INVITE request, it alerts the user, and waits for user input before responding. This is analogous to the typical telephone user experience, where the callee "answers" the call.
在典型的SIP应用程序中，当端点接收到INVITE请求时，它会提醒用户，并在响应之前等待用户输入。这类似于典型的电话用户体验，即被叫方“接听”电话。
In contrast, the typical user experience for instant messaging applications is that the initial received message is immediately displayed to the user, without waiting for the user to "join" the conversation. Therefore, the principle of least surprise would suggest that MSRP endpoints using SIP signaling SHOULD allow a mode where the endpoint quietly accepts the session and begins displaying messages.
相比之下，即时消息应用程序的典型用户体验是，最初收到的消息会立即显示给用户，而无需等待用户“加入”对话。因此，最小意外原则建议使用SIP信令的MSRP端点应允许端点安静地接受会话并开始显示消息的模式。
This guideline may not make sense for all situations, such as for mixed-media applications, where both MSRP and audio sessions are offered in the same INVITE. In general, good application design should take precedence.
本指南可能不适用于所有情况，例如混合媒体应用，其中MSRP和音频会话在同一邀请中提供。一般来说，良好的应用程序设计应该优先考虑。
SIP INVITE requests may be forked by a SIP proxy, resulting in more than one endpoint receiving the same INVITE. SIP early media [29] techniques can be used to establish a preliminary session with each endpoint so the initial message(s) are displayed on each endpoint, and canceling the INVITE transaction for any endpoints that do not send MSRP traffic after some period of time, so that they cease receiving MSRP traffic from the inviter.
SIP INVITE请求可能由SIP代理分叉，导致多个端点接收相同的INVITE。SIP early media[29]技术可用于与每个端点建立初步会话，以便在每个端点上显示初始消息，并在一段时间后取消未发送MSRP流量的任何端点的INVITE事务，以便它们停止接收来自邀请方的MSRP流量。
SDP defines a number of attributes that modify the direction of media flows. These are the "sendonly", "recvonly", "inactive", and "sendrecv" attributes.
SDP定义了许多修改媒体流方向的属性。这些是“sendonly”、“RecVoOnly”、“inactive”和“sendrecv”属性。
If a "sendonly" or "recvonly" attribute modifies an MSRP media description line, the attribute indicates the direction of MSRP SEND requests that contain regular message payloads. Unless otherwise specified, these attributes do not affect the direction of other types of requests, such as REPORT. SEND requests that contain some kind of control or reporting protocol rather than regular message payload (e.g., Instant Message Delivery Notification (IMDN) reports) should be generated according to the protocol rules as if no direction attribute were present.
如果“sendonly”或“RecvoOnly”属性修改了MSRP媒体描述行，则该属性指示包含常规消息有效载荷的MSRP发送请求的方向。除非另有规定，否则这些属性不会影响其他类型请求（如报告）的方向。应根据协议规则生成包含某种控制或报告协议而非常规消息有效负载（例如，即时消息传递通知（IMDN）报告）的发送请求，就像不存在方向属性一样。
MSRP is a text protocol that uses the UTF-8 [14] transformation format.
MSRP是一种使用UTF-8[14]转换格式的文本协议。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [6].
以下语法规范使用RFC 4234[6]中所述的增广巴科斯诺尔形式（BNF）。
msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers [content-stuff] end-line msrp-response = resp-start headers end-line
msrp req或resp=msrp请求/msrp响应msrp请求=req开始标头[内容填充]结束行msrp响应=resp开始标头结束行
req-start = pMSRP SP transact-id SP method CRLF resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF comment = utf8text
req start=pMSRP SP事务处理id SP方法CRLF resp start=pMSRP SP事务处理id SP状态代码[SP注释]CRLF注释=utf8text
pMSRP = %x4D.53.52.50 ; MSRP in caps
transact-id = ident
method = mSEND / mREPORT / other-method
mSEND = %x53.45.4e.44 ; SEND in caps
mREPORT = %x52.45.50.4f.52.54; REPORT in caps
pMSRP = %x4D.53.52.50 ; MSRP in caps
transact-id = ident
method = mSEND / mREPORT / other-method
mSEND = %x53.45.4e.44 ; SEND in caps
mREPORT = %x52.45.50.4f.52.54; REPORT in caps
other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document
; or an extension document
other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document
; or an extension document
MSRP-URI = msrp-scheme "://" authority
["/" session-id] ";" transport *( ";" URI-parameter)
; authority as defined in RFC3986
MSRP-URI = msrp-scheme "://" authority
["/" session-id] ";" transport *( ";" URI-parameter)
; authority as defined in RFC3986
msrp-scheme = "msrp" / "msrps"
session-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
transport = "tcp" / 1*ALPHANUM
URI-parameter = token ["=" token]
msrp-scheme = "msrp" / "msrps"
session-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
transport = "tcp" / 1*ALPHANUM
URI-parameter = token ["=" token]
headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header=从路径CRLF 1*到路径CRLF*（header CRLF）
header = Message-ID
/ Success-Report
/ Failure-Report
/ Byte-Range
/ Status
/ ext-header
header = Message-ID
/ Success-Report
/ Failure-Report
/ Byte-Range
/ Status
/ ext-header
To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI )
From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI )
Message-ID = "Message-ID:" SP ident
Success-Report = "Success-Report:" SP ("yes" / "no" )
Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" )
Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
range-start = 1*DIGIT
range-end = 1*DIGIT / "*"
total = 1*DIGIT / "*"
To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI )
From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI )
Message-ID = "Message-ID:" SP ident
Success-Report = "Success-Report:" SP ("yes" / "no" )
Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" )
Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
range-start = 1*DIGIT
range-end = 1*DIGIT / "*"
total = 1*DIGIT / "*"
Status = "Status:" SP namespace SP status-code [SP comment] namespace = 3(DIGIT); "000" for all codes defined in this document.
Status=“Status:”SP名称空间SP状态代码[SP comment]名称空间=3（数字）；“000”表示本文件中定义的所有代码。
ident = ALPHANUM 3*31ident-char
ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="
ident = ALPHANUM 3*31ident-char
ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="
content-stuff = *(Other-Mime-header CRLF)
Content-Type 2CRLF data CRLF
content-stuff = *(Other-Mime-header CRLF)
Content-Type 2CRLF data CRLF
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param )
type = token
subtype = token
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param )
type = token
subtype = token
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
Other-Mime-header = (Content-ID
/ Content-Description
/ Content-Disposition
/ mime-extension-field)
Other-Mime-header = (Content-ID
/ Content-Description
/ Content-Disposition
/ mime-extension-field)
; Content-ID, and Content-Description are defined in RFC2045.
; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension
; header fields as described in RFC2045
; Content-ID, and Content-Description are defined in RFC2045.
; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension
; header fields as described in RFC2045
data = *OCTET
end-line = "-------" transact-id continuation-flag CRLF
continuation-flag = "+" / "$" / "#"
data = *OCTET
end-line = "-------" transact-id continuation-flag CRLF
continuation-flag = "+" / "$" / "#"
ext-header = hname ":" SP hval CRLF
hname = ALPHA *token
hval = utf8text
ext-header = hname ":" SP hval CRLF
hname = ALPHA *token
hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
Figure 11: MSRP ABNF
图11:MSRP ABNF
This section summarizes the semantics of various response codes that may be used in MSRP transaction responses. These codes may also be used in the Status header field in REPORT requests.
本节总结了MSRP事务响应中可能使用的各种响应代码的语义。这些代码也可用于报告请求中的状态标题字段。
The 200 response code indicates a successful transaction.
200响应代码表示交易成功。
A 400 response indicates that a request was unintelligible. The sender may retry the request after correcting the error.
400响应表示请求无法理解。发件人可以在更正错误后重试请求。
A 403 response indicates that the attempted action is not allowed. The sender should not try the request again.
403响应表示不允许尝试的操作。发件人不应再次尝试该请求。
A 408 response indicates that a downstream transaction did not complete in the allotted time. It is never sent by any elements described in this specification. However, 408 is used in the MSRP relay extension; therefore, MSRP endpoints may receive it. An endpoint MUST treat a 408 response in the same manner as it would treat a local timeout.
408响应指示下游事务没有在分配的时间内完成。本规范中所述的任何元素都不会发送。然而，在MSRP中继扩展中使用408；因此，MSRP端点可能会收到它。端点处理408响应的方式必须与处理本地超时的方式相同。
A 413 response indicates that the receiver wishes the sender to stop sending the particular message. Typically, a 413 is sent in response to a chunk of an undesired message.
413响应指示接收方希望发送方停止发送特定消息。通常，发送413以响应不希望的消息块。
If a message sender receives a 413 in a response, or in a REPORT request, it MUST NOT send any further chunks in the message, that is, any further chunks with the same Message-ID value. If the sender receives the 413 while in the process of sending a chunk, and the chunk is interruptible, the sender MUST interrupt it.
如果消息发送方在响应或报告请求中接收到413，则它不得在消息中发送任何其他区块，即具有相同消息ID值的任何其他区块。如果发送方在发送数据块的过程中收到413，并且该数据块是可中断的，则发送方必须中断该数据块。
A 415 response indicates that the SEND request contained a media type that is not understood by the receiver. The sender should not send any further messages with the same content-type for the duration of the session.
415响应指示发送请求包含接收器不理解的媒体类型。在会话期间，发件人不应再发送任何具有相同内容类型的邮件。
A 423 response indicates that one of the requested parameters is out of bounds. It is used by the relay extensions to this document.
423响应表示请求的参数之一超出范围。它由本文件的中继扩展使用。
A 481 response indicates that the indicated session does not exist. The sender should terminate the session.
481响应表示指示的会话不存在。发送方应终止会话。
A 501 response indicates that the recipient does not understand the request method.
501响应表示收件人不理解请求方法。
The 501 response code exists to allow some degree of method extensibility. It is not intended as a license to ignore methods defined in this document; rather, it is a mechanism to report lack of support of extension methods.
501响应代码允许某种程度的方法扩展性。不作为忽略本文档中定义的方法的许可证；相反，它是一种报告缺乏扩展方法支持的机制。
A 506 response indicates that a request arrived on a session that is already bound to another network connection. The sender should cease sending messages for that session on this connection.
506响应指示请求到达已绑定到另一网络连接的会话。发件人应停止在此连接上发送该会话的消息。
This section shows an example flow for the most common scenario. The example assumes SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the example, assume that the offerer is sip:alice@example.com and the answerer is sip:bob@example.com.
本节显示了最常见场景的示例流程。该示例假定SIP用于传输SDP交换。为了简洁起见，省略了SIP消息和SIP代理基础结构的详细信息。在本例中，假设报价人是sip：alice@example.com回答者是sip：bob@example.com.
Alice Bob
| |
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
|(4) (MSRP) SEND |
|----------------------->|
|(5) (MSRP) 200 OK |
|<-----------------------|
|(6) (MSRP) SEND |
|<-----------------------|
|(7) (MSRP) 200 OK |
|----------------------->|
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
Alice Bob
| |
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
|(4) (MSRP) SEND |
|----------------------->|
|(5) (MSRP) 200 OK |
|<-----------------------|
|(6) (MSRP) SEND |
|<-----------------------|
|(7) (MSRP) 200 OK |
|----------------------->|
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
Figure 12: Basic IM Session Example
图12：基本IM会话示例
1. Alice constructs a local URI of msrp://alicepc.example.com:7777/iau39soe2843z;tcp .
1. Alice构造了一个msrp://alicepc.example.com:7777/iau39soe2843z;tcp。
Alice->Bob (SIP): INVITE sip:bob@example.com
Alice->Bob (SIP): INVITE sip:bob@example.com
v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= -
c=IN IP4 alicepc.example.com
t=0 0
m=message 7777 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp
v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= -
c=IN IP4 alicepc.example.com
t=0 0
m=message 7777 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp
2. Bob listens on port 8888, and sends the following response:
2. Bob侦听端口8888，并发送以下响应：
Bob->Alice (SIP): 200 OK
鲍勃->爱丽丝（啜饮）：200好
v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp
v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp
3. Alice->Bob (SIP): ACK sip:bob@example.com
3. Alice->Bob（SIP）：确认SIP:bob@example.com
4. (Alice opens connection to Bob.) Alice->Bob (MSRP):
4. （Alice打开与Bob的连接。）Alice->Bob（MSRP）：
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-16/16
Content-Type: text/plain
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-16/16
Content-Type: text/plain
Hi, I'm Alice!
-------d93kswow$
Hi, I'm Alice!
-------d93kswow$
5. Bob->Alice (MSRP):
5. 鲍勃->爱丽丝（MSRP）：
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$
6. Bob->Alice (MSRP):
6. 鲍勃->爱丽丝（MSRP）：
MSRP dkei38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456s9wlk3
Byte-Range: 1-21/21
Content-Type: text/plain
MSRP dkei38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456s9wlk3
Byte-Range: 1-21/21
Content-Type: text/plain
Hi, Alice! I'm Bob!
-------dkei38sd$
Hi, Alice! I'm Bob!
-------dkei38sd$
7. Alice->Bob (MSRP):
7. Alice->Bob（MSRP）：
MSRP dkei38sd 200 OK
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
-------dkei38sd$
MSRP dkei38sd 200 OK
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
-------dkei38sd$
8. Alice->Bob (SIP): BYE sip:bob@example.com
8. 爱丽丝->鲍勃（小口喝）：再见小口喝：bob@example.com
Alice invalidates local session state.
Alice使本地会话状态无效。
9. Bob invalidates local state for the session.
9. Bob使会话的本地状态无效。
Bob->Alice (SIP): 200 OK
鲍勃->爱丽丝（啜饮）：200好
MSRP dsdfoe38sd SEND
To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-374/374
Content-Type: application/xhtml+xml
MSRP dsdfoe38sd SEND
To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-374/374
Content-Type: application/xhtml+xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>FY2005 Results</title>
</head>
<body>
<p>See the results at <a
href="http://example.org/">example.org</a>.</p>
</body>
</html>
-------dsdfoe38sd$
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>FY2005 Results</title>
</head>
<body>
<p>See the results at <a
href="http://example.org/">example.org</a>.</p>
</body>
</html>
-------dsdfoe38sd$
Figure 13: Example Message with XHTML
图13:XHTML消息示例
For an example of a chunked message, see the example in Section 5.1.
有关分块消息的示例，请参见第5.1节中的示例。
This example shows a chunked message containing a CPIM message that wraps a text/plain payload. It is worth noting that MSRP considers the complete CPIM message before chunking the message; thus, the CPIM headers are included in only the first chunk. The MSRP Content-Type and Byte-Range headers, present in both chunks, refer to the whole CPIM message.
此示例显示了包含包装文本/普通负载的CPIM消息的分块消息。值得注意的是，MSRP在对消息进行分块之前会考虑完整的CPIM消息；因此，CPIM头仅包含在第一个块中。两个区块中的MSRP内容类型和字节范围标头都指向整个CPIM消息。
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-137/148
Content-Type: message/cpim
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-137/148
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Type: text/plain
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Type: text/plain
ABCD
-------d93kswow+
ABCD
-------d93kswow+
Figure 14: First Chunk
图14：第一块
Alice sends the second and last chunk.
Alice发送第二个也是最后一个块。
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 138-148/148
Content-Type: message/cpim
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 138-148/148
Content-Type: message/cpim
1234567890
-------op2nc9a$
1234567890
-------op2nc9a$
Figure 15: Second Chunk
图15：第二块
Sysadmin->Alice (MSRP):
系统管理员->Alice（MSRP）：
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-38/38
Failure-Report: no
Success-Report: no
Content-Type: text/plain
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-38/38
Failure-Report: no
Success-Report: no
Content-Type: text/plain
This conference will end in 5 minutes
-------d93kswow$
This conference will end in 5 minutes
-------d93kswow$
Alice->Bob (MSRP):
Alice->Bob（MSRP）：
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Success-Report: yes
Failure-Report: no
Content-Type: text/html
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Success-Report: yes
Failure-Report: no
Content-Type: text/html
<html><body>
<p>Here is that important link...
<a href="http://www.example.com/foobar">foobar</a>
</p>
</body></html>
-------d93kswow$
<html><body>
<p>Here is that important link...
<a href="http://www.example.com/foobar">foobar</a>
</p>
</body></html>
-------d93kswow$
Figure 16: Initial SEND Request
图16：初始发送请求
Bob->Alice (MSRP):
鲍勃->爱丽丝（MSRP）：
MSRP dkei38sd REPORT
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Status: 000 200 OK
-------dkei38sd$
MSRP dkei38sd REPORT
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Status: 000 200 OK
-------dkei38sd$
Figure 17: Success Report
图17：成功报告
Traditional IM systems generally do a poor job of handling multiple simultaneous IM clients online for the same person. While some do a better job than many existing systems, handling of multiple clients is fairly crude. This becomes a much more significant issue when always-on mobile devices are available, but it is desirable to use them only if another IM client is not available.
传统的即时通讯系统在为同一个人同时在线处理多个即时通讯客户端方面通常做得很差。虽然有些系统比许多现有系统做得更好，但处理多个客户端相当粗糙。当“始终在线”移动设备可用时，这将成为一个更重要的问题，但只有在另一个IM客户端不可用时才需要使用它们。
Using SIP makes rendezvous decisions explicit, deterministic, and very flexible. In contrast, "page-mode" IM systems use implicit implementation-specific decisions that IM clients cannot influence. With SIP session-mode messaging, rendezvous decisions can be under control of the client in a predictable, interoperable way for any host that implements callee capabilities [31]. As a result, rendezvous policy is managed consistently for each address of record.
使用SIP可以使会合决策明确、确定且非常灵活。相反，“页面模式”IM系统使用IM客户端无法影响的隐式实现特定决策。通过SIP会话模式消息传递，对于任何实现被叫方功能的主机，集合决策都可以由客户端以可预测、可互操作的方式进行控制[31]。因此，每个记录地址的集合策略都得到一致的管理。
The following example shows Juliet with several IM clients where she can be reached. Each of these has a unique SIP contact and MSRP session. The example takes advantage of SIP's capability to "fork" an invitation to several contacts in parallel, in sequence, or in combination. Juliet has registered from her chamber, the balcony, her PDA, and as a last resort, you can leave a message with her nurse. Juliet's contacts are listed below. The q-values express relative preference (q=1.0 is the highest preference).
下面的例子显示了Juliet与几个IM客户的联系。每一个都有一个独特的SIP联系人和MSRP会话。该示例利用SIP的功能，将邀请以并行、顺序或组合的方式“分叉”到多个联系人。朱丽叶已经在她的房间、阳台、PDA上注册了，作为最后的手段，你可以给她的护士留言。朱丽叶的联系人如下。q值表示相对偏好（q=1.0为最高偏好）。
When Romeo opens his IM program, he selects Juliet and types the message "art thou hither?" (instead of "you there?"). His client sends a SIP invitation to sip:juliet@thecapulets.example.com. The proxy there tries first the balcony and the chamber simultaneously. A client is running on each of those systems, both of which set up early sessions of MSRP with Romeo's client. The client automatically sends the message over MSRP to the two MSRP URIs involved. After a delay of a several seconds with no reply or activity from Juliet, the proxy cancels the invitation at her first two contacts, and forwards the invitation on to Juliet's PDA. Since her father is talking to her about her wedding, she selects "Do Not Disturb" on her PDA, which sends a "Busy Here" response. The proxy then tries the nurse, who answers and tells Romeo what is going on.
当罗密欧打开他的即时通讯程序时，他选择朱丽叶并输入信息“你在这里吗？”（而不是“你在那里？”）。他的客户向SIP发送SIP邀请：juliet@thecapulets.example.com. 那里的代理首先同时尝试阳台和房间。每个系统上都有一个客户机，这两个系统都与罗密欧的客户机建立了MSRP的早期会话。客户端通过MSRP自动将消息发送到涉及的两个MSRP URI。在几秒钟的延迟后，朱丽叶没有回复或活动，代理在她的前两个联系人处取消邀请，并将邀请转发到朱丽叶的PDA。因为她的父亲正在和她谈论她的婚礼，她在PDA上选择了“请勿打扰”，这会发送一个“忙在这里”的响应。然后，代理人尝试护士，护士回答并告诉罗密欧发生了什么。
Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Proxy balcony chamber PDA
| | | | | |
|--INVITE--->| | | | |
| |--INVITE--->| | | |
| |<----180----| | | |
|<----180----| | | | |
|---PRACK---------------->| | | |
|<----200-----------------| | | |
|<===Early MSRP Session==>| art thou hither? | |
| | | | | |
| |--INVITE---------------->| | |
| |<----180-----------------| | |
|<----180----| | | | |
|---PRACK----------------------------->| | |
|<----200------------------------------| | |
|<========Early MSRP Session==========>| art thou hither? |
| | | | | |
| | | | | |
| | .... Time Passes .... | | |
| | | | | |
| | | | | |
| |--CANCEL--->| | | |
| |<---200-----| | | |
| |<---487-----| | | |
| |----ACK---->| | | |
| |--CANCEL---------------->| | |
| |<---200------------------| | |
| |<---487------------------| | |
| |----ACK----------------->| | |
| |--INVITE---------------------------->| romeo wants
| | | | | to IM w/ you
| |<---486 Busy Here--------------------| |
| |----ACK----------------------------->| |
| | | | | |
| |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------|
|<--200 OK---| | | | |
|---ACK------------------------------------------------------->|
|<================MSRP Session================================>|
| | | | | |
| Hi Romeo, Juliet is |
| with her father now |
| can I take a message?|
| |
| Tell her to go to confession tomorrow.... |
Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Proxy balcony chamber PDA
| | | | | |
|--INVITE--->| | | | |
| |--INVITE--->| | | |
| |<----180----| | | |
|<----180----| | | | |
|---PRACK---------------->| | | |
|<----200-----------------| | | |
|<===Early MSRP Session==>| art thou hither? | |
| | | | | |
| |--INVITE---------------->| | |
| |<----180-----------------| | |
|<----180----| | | | |
|---PRACK----------------------------->| | |
|<----200------------------------------| | |
|<========Early MSRP Session==========>| art thou hither? |
| | | | | |
| | | | | |
| | .... Time Passes .... | | |
| | | | | |
| | | | | |
| |--CANCEL--->| | | |
| |<---200-----| | | |
| |<---487-----| | | |
| |----ACK---->| | | |
| |--CANCEL---------------->| | |
| |<---200------------------| | |
| |<---487------------------| | |
| |----ACK----------------->| | |
| |--INVITE---------------------------->| romeo wants
| | | | | to IM w/ you
| |<---486 Busy Here--------------------| |
| |----ACK----------------------------->| |
| | | | | |
| |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------|
|<--200 OK---| | | | |
|---ACK------------------------------------------------------->|
|<================MSRP Session================================>|
| | | | | |
| Hi Romeo, Juliet is |
| with her father now |
| can I take a message?|
| |
| Tell her to go to confession tomorrow.... |
Figure 18: Forking Example
图18：分叉示例
MSRP was designed to be only minimally extensible. New MSRP methods, header fields, and status codes can be defined in standards-track RFCs. MSRP does not contain a version number or any negotiation mechanism to require or discover new features. If an extension is specified in the future that requires negotiation, the specification will need to describe how the extension is to be negotiated in the encapsulating signaling protocol. If a non-interoperable update or extension occurs in the future, it will be treated as a new protocol, and MUST describe how its use will be signaled.
管理系统更新项目的设计仅具有最低限度的可扩展性。可以在标准跟踪RFC中定义新的MSRP方法、标题字段和状态代码。MSRP不包含要求或发现新功能的版本号或任何协商机制。如果将来指定了需要协商的扩展，则规范将需要描述如何在封装信令协议中协商扩展。如果将来发生不可互操作的更新或扩展，它将被视为一个新协议，并且必须描述如何通知其使用。
In order to allow extension header fields without breaking interoperability, if an MSRP device receives a request or response containing a header field that it does not understand, it MUST ignore the header field and process the request or response as if the header field was not present. If an MSRP device receives a request with an unknown method, it MUST return a 501 response.
为了在不破坏互操作性的情况下允许扩展标头字段，如果MSRP设备接收到包含其不理解的标头字段的请求或响应，则必须忽略标头字段，并像标头字段不存在一样处理请求或响应。如果MSRP设备接收到具有未知方法的请求，则必须返回501响应。
MSRP was designed to use lists of URIs instead of a single URI in the To-Path and From-Path header fields in anticipation of relay or gateway functionality being added. In addition, "msrp" and "msrps" URIs can contain parameters that are extensible.
MSRP被设计为使用URI列表，而不是在to Path和From Path头字段中使用单个URI，以预期将添加中继或网关功能。此外，“msrp”和“msrps”URI可以包含可扩展的参数。
MSRP sessions may go to a gateway to other Common Profile for Instant Messaging (CPIM) [27] compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics, which do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that has included "message/cpim" as the first entry in the accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME[7] features of that format.
MSRP会话可以转到与即时消息传递（CPIM）[27]兼容协议的其他通用配置文件的网关。如果出现这种情况，网关必须保持会话状态，并且必须在MSRP会话语义和CPIM语义之间进行转换，这两种语义不包括会话的概念。此外，当会话的一个端点是CPIM网关时，应将即时消息包装在“message/CPIM”[12]正文中。此类网关必须将“message/cpim”作为其SDP accept types属性中的第一个条目。将即时消息发送到已将“message/cpim”作为接受类型属性的第一个条目的对等方的MSRP端点应将所有即时消息正文封装在“message/cpim”包装器中。所有MSRP端点必须支持message/cpim类型，并应支持该格式的S/MIME[7]功能。
If a message is to be wrapped in a message/cpim envelope, the wrapping MUST be done prior to breaking the message into chunks, if needed.
如果要将消息包装在消息/cpim信封中，则必须在将消息分块之前完成包装（如果需要）。
All MSRP endpoints MUST recognize the From, To, DateTime, and Require header fields as defined in RFC 3862. Such applications SHOULD recognize the CC header field, and MAY recognize the Subject header field. Any MSRP application that recognizes any message/cpim header field MUST understand the NS (name space) header field.
所有MSRP端点必须识别RFC 3862中定义的From、To、DateTime和Require标头字段。此类应用程序应识别CC头字段，并可识别主题头字段。识别任何消息/cpim头字段的任何MSRP应用程序必须理解NS（名称空间）头字段。
All message/cpim body parts sent by an MSRP endpoint MUST include the From and To header fields. If the message/cpim body part is protected using S/MIME, then it MUST also include the DateTime header field.
MSRP端点发送的所有邮件/cpim正文部分必须包含“发件人”和“收件人”标题字段。如果消息/cpim主体部分使用S/MIME进行保护，那么它还必须包含DateTime标头字段。
The NS, To, and CC header fields may occur multiple times. Other header fields defined in RFC 3862 MUST NOT occur more than once in a given message/cpim body part in an MSRP message. The Require header field MAY include multiple values. The NS header field MAY occur zero or more times, depending on how many name spaces are being referenced.
NS、To和CC标头字段可能出现多次。RFC 3862中定义的其他标头字段在MSRP消息的给定消息/cpim正文部分中不得出现一次以上。Require header字段可能包含多个值。NS标头字段可能出现零次或多次，具体取决于引用的名称空间的数量。
Extension header fields MAY occur more than once, depending on the definition of such header fields.
扩展标头字段可能出现多次，具体取决于此类标头字段的定义。
Using message/cpim envelopes is also useful if an MSRP device wishes to send a message on behalf of some other identity. The device may add a message/cpim envelope with the appropriate From header field value.
如果MSRP设备希望代表其他身份发送消息，则使用消息/cpim信封也很有用。该设备可以添加具有适当From报头字段值的消息/cpim信封。
Instant messaging systems are used to exchange a variety of sensitive information ranging from personal conversations, to corporate confidential information, to account numbers and other financial trading information. IM is used by individuals, corporations, and governments for communicating important information. IM systems need to provide the properties of integrity and confidentiality for the exchanged information, and the knowledge that you are communicating with the correct party, and they need to allow the possibility of anonymous communication. MSRP pushes many of the hard problems to SIP when SIP sets up the session, but some of the problems remain. Spam and Denial of Service (DoS) attacks are also very relevant to IM systems.
即时消息系统用于交换各种敏感信息，包括个人对话、公司机密信息、账号和其他金融交易信息。IM被个人、公司和政府用于交流重要信息。IM系统需要为交换的信息提供完整性和保密性，并知道您正在与正确的一方通信，并且需要允许匿名通信的可能性。当SIP建立会话时，MSRP将许多困难的问题推给SIP，但一些问题仍然存在。垃圾邮件和拒绝服务（DoS）攻击也与IM系统密切相关。
MSRP needs to provide confidentiality and integrity for the messages it transfers. It also needs to provide assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked.
管理系统更新项目需要为其传输的信息提供机密性和完整性。它还需要保证连接的主机就是它要连接的主机，并且连接没有被劫持。
When an endpoint sends an MSRP URI to its peer in a rendezvous protocol, that URI is effectively a secret shared between the peers. If an attacker learns or guesses the URI prior to the completion of session setup, it may be able to impersonate one of the peers.
当端点在集合协议中向其对等方发送MSRP URI时，该URI实际上是对等方之间共享的秘密。如果攻击者在会话设置完成之前了解或猜测URI，则可能会模拟其中一个对等方。
Assuming the URI exchange in the rendezvous protocol is sufficiently protected, it is critical that the URI remain difficult to "guess" via brute force methods. Most components of the URI, such as the scheme and the authority components, are common knowledge. The secrecy is entirely provided by the session-id component.
假设集合协议中的URI交换得到了充分的保护，关键是URI仍然难以通过蛮力方法进行“猜测”。URI的大多数组件，如scheme和authority组件，都是公共知识。保密性完全由会话id组件提供。
Therefore, when an MSRP device generates an MSRP URI to be used in the initiation of an MSRP session, the session-id component MUST contain at least 80 bits of randomness.
因此，当MSRP设备生成用于发起MSRP会话的MSRP URI时，会话id组件必须包含至少80位随机性。
When using only TCP connections, MSRP security is fairly weak. If host A is contacting host B, B passes its hostname and a secret to A using a rendezvous protocol. Although MSRP requires the use of a rendezvous protocol with the ability to protect this exchange, there is no guarantee that the protection will be used all the time. If such protection is not used, anyone can see this secret. Host A then connects to the provided hostname and passes the secret in the clear across the connection to B. Host A assumes that it is talking to B based on where it sent the SYN packet and then delivers the secret in plain text across the connections. Host B assumes it is talking to A because the host on the other end of the connection delivered the secret. An attacker that could ACK the SYN packet could insert itself as a man-in-the-middle in the connection.
当只使用TCP连接时，MSRP的安全性相当弱。如果主机A正在联系主机B，则主机B使用会合协议将其主机名和机密传递给A。尽管MSRP要求使用能够保护此交换的会合协议，但不能保证始终使用该保护。如果不使用这种保护，任何人都可以看到这个秘密。然后，主机A连接到提供的主机名，并通过连接将机密以明文形式传递给B。主机A根据发送SYN数据包的位置假定它正在与B对话，然后通过连接以明文形式传递机密。主机B假定它正在与A对话，因为连接另一端的主机传递了秘密。能够确认SYN数据包的攻击者可以在连接的中间插入一个人。
When using TLS connections, the security is significantly improved. We assume that the host accepting the connection has a certificate from a well-known certification authority. Furthermore, we assume that the signaling to set up the session is protected by the rendezvous protocol. In this case, when host A contacts host B, the secret is passed through a confidential channel to A. A connects with TLS to B. B presents a valid certificate, so A knows it really is connected to B. A then delivers the secret provided by B, so that B can verify it is connected to A. In this case, a rogue SIP Proxy can see the secret in the SIP signaling traffic and could potentially insert itself as a man-in-the-middle.
使用TLS连接时，安全性得到了显著提高。我们假设接受连接的主机具有来自知名证书颁发机构的证书。此外，我们假设建立会话的信令受到集合协议的保护。在这种情况下，当主机A与主机B联系时，机密通过保密通道传递给A。A与TLS连接到B。B提供有效证书，因此A知道它确实连接到B。A然后传递B提供的机密，以便B可以验证它是否连接到A。在这种情况下，流氓SIP代理可以看到SIP信令流量中的秘密，并可能以中间人的身份插入自身。
Realistically, using TLS with certificates from well-known certification authorities is difficult for peer-to-peer connections, as the types of hosts that end clients use for sending instant
实际上，对于点对点连接来说，使用TLS和来自知名认证机构的证书是困难的，因为终端客户端用于发送即时消息的主机类型不同
messages are unlikely to have long-term stable IP addresses or DNS names that the certificates can bind to. In addition, the cost of server certificates from well-known certification authorities is currently expensive enough to discourage their use for each client. Using TLS in a peer-to-peer mode without well-known certificates is discussed in Section 14.4.
消息不太可能具有证书可以绑定到的长期稳定的IP地址或DNS名称。此外，来自知名认证机构的服务器证书的成本目前非常昂贵，不利于每个客户机使用这些证书。第14.4节讨论了在没有已知证书的对等模式下使用TLS。
TLS becomes much more practical when some form of relay is introduced. Clients can then form TLS connections to relays, which are much more likely to have TLS certificates. While this specification does not address such relays, they are described by a companion document [23]. That document makes extensive use of TLS to protect traffic between clients and relays, and between one relay and another.
当引入某种形式的继电器时，TLS变得更加实用。然后，客户端可以形成到中继的TLS连接，中继更有可能具有TLS证书。虽然本规范未涉及此类继电器，但相关文件[23]对其进行了描述。该文档广泛使用TLS来保护客户端和中继之间以及一个中继和另一个中继之间的通信量。
TLS is used to authenticate devices and to provide integrity and confidentiality for the header fields being transported. MSRP elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [11]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher-suites MAY also be supported).
TLS用于验证设备，并为传输的报头字段提供完整性和机密性。MSRP元素必须实现TLS，还必须实现TLS ClientExtendedHello扩展hello信息，用于服务器名称指示，如[11]所述。必须支持TLS_RSA_与_AES_128_CBC_SHA[13]的TLS密码套件（也可以支持其他密码套件）。
The only strong security for non-TLS connections is achieved using S/MIME.
非TLS连接的唯一强大安全性是使用S/MIME实现的。
Since MSRP carries arbitrary MIME content, it can trivially carry S/MIME protected messages as well. All MSRP implementations MUST support the multipart/signed media-type even if they do not support S/MIME. Since SIP can carry a session key, S/MIME messages in the context of a session could also be protected using a key-wrapped shared secret [28] provided in the session setup. MSRP can carry unencoded binary payloads. Therefore, MIME bodies MUST be transferred with a transfer encoding of binary. If a message is both signed and encrypted, it SHOULD be signed first, then encrypted. If S/MIME is supported, SHA-1, SHA-256, RSA, and AES-128 MUST be supported. For RSA, implementations MUST support key sizes of at least 1024 bits and SHOULD support key sizes of 2048 bits or more.
由于MSRP承载任意MIME内容，因此它也可以承载受S/MIME保护的消息。所有MSRP实现必须支持多部分/签名媒体类型，即使它们不支持S/MIME。由于SIP可以携带会话密钥，会话上下文中的S/MIME消息也可以使用会话设置中提供的密钥包装共享密钥[28]进行保护。MSRP可以携带未编码的二进制有效载荷。因此，MIME主体必须使用二进制传输编码进行传输。如果消息同时经过签名和加密，则应先签名，然后加密。如果支持S/MIME，则必须支持SHA-1、SHA-256、RSA和AES-128。对于RSA，实现必须支持至少1024位的密钥大小，并且应该支持2048位或更多的密钥大小。
This does not actually require the endpoint to have certificates from a well-known certification authority. When MSRP is used with SIP, the Identity [17] and Certificates [25] mechanisms provide S/MIME-based delivery of a secret between A and B. No SIP intermediary except the explicitly trusted authentication service (one per user) can see the secret. The S/MIME encryption of the SDP can also be used by SIP to exchange keying material that can be used in MSRP.
这实际上并不要求端点具有来自知名证书颁发机构的证书。当MSRP与SIP一起使用时，身份[17]和证书[25]机制在a和B之间提供基于S/MIME的秘密传递。除了显式信任的身份验证服务（每个用户一个）之外，没有任何SIP中介可以看到秘密。SIP还可以使用SDP的S/MIME加密来交换可用于MSRP的密钥材料。
The MSRP session can then use S/MIME with this keying material to sign and encrypt messages sent over MSRP. The connection can still be hijacked since the secret is sent in clear text to the other end of the TCP connection, but the consequences are mitigated if all the MSRP content is signed and encrypted with S/MIME. Although out of scope for this document, the SIP negotiation of an MSRP session can negotiate symmetric keying material to be used with S/MIME for integrity and privacy.
然后，MSRP会话可以将S/MIME与此密钥材料一起使用，对通过MSRP发送的消息进行签名和加密。由于机密以明文形式发送到TCP连接的另一端，连接仍然可能被劫持，但如果所有MSRP内容都使用S/MIME签名和加密，则后果会减轻。虽然超出了本文档的范围，但MSRP会话的SIP协商可以协商对称密钥材料，以便与S/MIME一起使用，以确保完整性和隐私。
TLS can be used with a self-signed certificate as long as there is a mechanism for both sides to ascertain that the other side used the correct certificate. When used with SDP and SIP, the correct certificate can be verified by passing a fingerprint of the certificate in the SDP and ensuring that the SDP has suitable integrity protection. When SIP is used to transport the SDP, the integrity can be provided by the SIP Identity mechanism [17]. The rest of this section describes the details of this approach.
TLS可以与自签名证书一起使用，只要双方都有一种机制来确定另一方使用了正确的证书。当与SDP和SIP一起使用时，可以通过在SDP中传递证书的指纹并确保SDP具有适当的完整性保护来验证正确的证书。当使用SIP传输SDP时，SIP身份机制可以提供完整性[17]。本节其余部分将详细介绍此方法。
If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the URI of the user. In SIP, this URI of the user is the User's Address of Record (AOR). This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. Unlike normal TLS operations in this protocol, when doing peer-to-peer TLS, the subjectAltName is not an important component of the certificate verification. If the endpoint is also able to make anonymous sessions, a distinct, unique certificate MUST be used for this purpose. For a client that works with multiple users, each user SHOULD have its own certificate. Because the generation of public/private key pairs is relatively expensive, endpoints are not required to generate certificates for each session.
如果使用自签名证书，证书中subjectAltName属性的内容可能会使用用户的URI。在SIP中，用户的这个URI是用户的记录地址（AOR）。这仅用于调试目的，不需要将证书绑定到某个通信端点。与此协议中的正常TLS操作不同，在执行对等TLS时，subjectAltName不是证书验证的重要组件。如果端点也能够进行匿名会话，则必须为此使用一个独特的、唯一的证书。对于与多个用户一起工作的客户端，每个用户都应该有自己的证书。由于生成公钥/私钥对的成本相对较高，因此不需要端点为每个会话生成证书。
A certificate fingerprint is the output of a one-way hash function computed over the Distinguished Encoding Rules (DER) form of the certificate. The endpoint MUST use the certificate fingerprint attribute as specified in [18] and MUST include this in the SDP. The certificate presented during the TLS handshake needs to match the fingerprint exchanged via the SDP, and if the fingerprint does not match the hashed certificate then the endpoint MUST tear down the media session immediately.
证书指纹是根据证书的可分辨编码规则（DER）形式计算的单向哈希函数的输出。端点必须使用[18]中指定的证书指纹属性，并且必须将其包含在SDP中。TLS握手期间提供的证书需要与通过SDP交换的指纹匹配，如果指纹与哈希证书不匹配，则端点必须立即中断媒体会话。
When using SIP, the integrity of the fingerprint can be ensured through the SIP Identity mechanism [17]. When a client wishes to use SIP to set up a secure MSRP session with another endpoint, it sends an SDP offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the
使用SIP时，可以通过SIP身份机制确保指纹的完整性[17]。当客户端希望使用SIP与另一个端点建立安全的MSRP会话时，它会将SIP消息中的SDP提供发送到另一个端点。作为SDP有效载荷的一部分，此报价包括
certificate that the endpoint wants to use. The SIP message containing the offer is sent to the offerer's SIP proxy, which will add an Identity header according to the procedures outlined in [17]. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header. Since the Identity header is a digital signature across several SIP headers, in addition to the body or bodies of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was added to the SIP message.
端点要使用的证书。包含要约的SIP消息被发送到要约人的SIP代理，该代理将根据[17]中概述的程序添加标识头。当远端端点接收到SIP消息时，它可以使用identity报头验证发送方的身份。由于标识报头是跨越多个SIP报头的数字签名，因此除了SIP消息的主体之外，接收器还可以确定在将数字签名添加到SIP消息之后消息没有被篡改。
An example of SDP with a fingerprint attribute is shown in the following figure. Note the fingerprint is shown spread over two lines due to formatting consideration but should all be on one line.
下图显示了具有指纹属性的SDP示例。请注意，出于格式考虑，指纹显示为分散在两行上，但应全部位于一行上。
c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;tcp
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;tcp
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 19: SDP with Fingerprint Attribute
图19：具有指纹属性的SDP
MSRP cannot be used as an amplifier for DoS attacks, but it can be used to form a distributed attack to consume TCP connection resources on servers. The attacker, Mallory, sends a SIP INVITE with no offer to Alice. Alice returns a 200 with an offer and Mallory returns an answer with SDP indicating that his MSRP address is the address of Tom. Since Alice sent the offer, Alice will initiate a connection to Tom using up resources on Tom's server. Given the huge number of IM clients, and the relatively few TCP connections that most servers support, this is a fairly straightforward attack.
MSRP不能用作DoS攻击的放大器，但可用于形成分布式攻击，以消耗服务器上的TCP连接资源。攻击者Mallory向Alice发送了一个SIP邀请，但没有提供任何服务。Alice返回带报价的200，Mallory返回带SDP的答案，表明他的MSRP地址是Tom的地址。由于Alice发送了报价，Alice将使用Tom服务器上的资源启动与Tom的连接。鉴于IM客户端数量巨大，且大多数服务器支持的TCP连接相对较少，这是一种相当简单的攻击。
SIP is attempting to address issues in dealing with spam. The spam issue is probably best dealt with at the SIP level when an MSRP session is initiated and not at the MSRP level.
SIP正试图解决处理垃圾邮件的问题。当MSRP会话启动时，最好在SIP级别处理垃圾邮件问题，而不是在MSRP级别。
If a sender chooses to employ S/MIME to protect a message, all S/MIME operations apply to the complete message, prior to any breaking of the message into chunks.
如果发送方选择使用S/MIME来保护消息，则在将消息分成块之前，所有S/MIME操作都将应用于完整的消息。
The signaling will have set up the session to or from some specific URIs that will often have "im:" or "sip:" URI schemes. When the signaling has been set up to a specific end user, and S/MIME is implemented, then the client needs to verify that the name in the SubjectAltName of the certificate contains an entry that matches the
信令将设置与某些特定URI之间的会话，这些URI通常具有“im:”或“sip:”URI方案。当为特定最终用户设置了信令，并且实现了S/MIME时，客户端需要验证证书的SubjectAltName中的名称是否包含与
URI that was used for the other end in the signaling. There are some cases, such as IM conferencing, where the S/MIME certificate name and the signaled identity will not match. In these cases, the client should ensure that the user is informed that the message came from the user identified in the certificate and does not assume that the message came from the party they signaled.
在信令中用于另一端的URI。在某些情况下，例如IM会议，S/MIME证书名称和信号标识将不匹配。在这些情况下，客户端应确保通知用户消息来自证书中标识的用户，并且不假定消息来自他们发出信号的一方。
In some cases, a sending device may need to attribute a message to some other identity, and may use different identities for different messages in the same session. For example, a conference server may send messages on behalf of multiple users on the same session. Rather than add additional header fields to MSRP for this purpose, MSRP relies on the message/cpim format for this purpose. The sender may envelop such a message in a message/cpim body, and place the actual sender identity in the From field. The trustworthiness of such an attribution is affected by the security properties of the session in the same way that the trustworthiness of the identity of the actual peer is affected, with the additional issue of determining whether the recipient trusts the sender to assert the identity.
在某些情况下，发送设备可能需要将消息归属于某个其他标识，并且可能在同一会话中对不同的消息使用不同的标识。例如，会议服务器可以代表同一会话上的多个用户发送消息。为此目的，MSRP不向MSRP添加额外的标题字段，而是依赖消息/cpim格式。发送者可以将这样的消息封装在消息/cpim正文中，并将实际发送者身份放在From字段中。这种属性的可信度受到会话的安全属性的影响，其影响方式与实际对等方的身份的可信度受到影响的方式相同，还有一个问题是确定接收方是否信任发送方声明该身份。
This approach can result in nesting of message/cpim envelopes. For example, a message originates from a CPIM gateway, and is then forwarded by a conference server onto a new session. Both the gateway and the conference server introduce envelopes. In this case, the recipient client SHOULD indicate the chain of identity assertions to the user, rather than allow the user to assume that either the gateway or the conference server originated the message.
这种方法可能导致消息/cpim信封嵌套。例如，消息来自CPIM网关，然后由会议服务器转发到新会话。网关和会议服务器都引入信封。在这种情况下，接收方客户机应该向用户指示标识断言链，而不是允许用户假定是网关或会议服务器发出了消息。
It is possible that a recipient might receive messages that are attributed to the same sender via different MSRP sessions. For example, Alice might be in a conversation with Bob via an MSRP session over a TLS protected channel. Alice might then receive a different message from Bob over a different session, perhaps with a conference server that asserts Bob's identity in a message/cpim envelope signed by the server.
收件人可能通过不同的MSRP会话接收属于同一发件人的邮件。例如，Alice可能通过受TLS保护的通道上的MSRP会话与Bob进行对话。然后，Alice可能会通过不同的会话从Bob接收不同的消息，可能是通过一个会议服务器，该服务器在由服务器签名的消息/cpim信封中声明Bob的身份。
MSRP does not prohibit multiple simultaneous sessions between the same pair of identities. Nor does it prohibit an endpoint sending a message on behalf of another identity, such as may be the case for a conference server. The recipient's endpoint should determine its level of trust of the authenticity of the sender independently for each session. The fact that an endpoint trusts the authenticity of the sender on any given session should not affect the level of trust it assigns for apparently the same sender on a different session.
MSRP不禁止同一对身份之间同时进行多个会话。它也不禁止端点代表另一个身份发送消息，例如会议服务器。对于每个会话，接收方的端点应该独立地确定其对发送方真实性的信任级别。端点在任何给定会话上信任发送方的真实性这一事实不应影响它在不同会话上为显然相同的发送方分配的信任级别。
When MSRP clients form or acquire a certificate, they SHOULD ensure that the subjectAltName has a GeneralName entry of type uniformResourceIdentifier for each URI corresponding to this client and should always include an "im:" URI. It is fine if the certificate contains other URIs such as "sip:" or "xmpp:" URIs.
当MSRP客户端形成或获取证书时，它们应该确保subjectAltName对于与此客户端对应的每个URI都有一个uniformResourceIdentifier类型的GeneralName条目，并且应该始终包含一个“im:”URI。如果证书包含其他URI（如“sip:”或“xmpp:”URI），则可以。
MSRP implementors should be aware of a potential attack on MSRP devices that involves placing very large values in the byte-range header field, potentially causing the device to allocate very large memory buffers to hold the message. Implementations SHOULD apply some degree of sanity checking on byte-range values before allocating such buffers.
MSRP实施者应注意MSRP设备上的潜在攻击，该攻击涉及在字节范围标头字段中放置非常大的值，可能导致设备分配非常大的内存缓冲区来保存消息。在分配此类缓冲区之前，实现应该对字节范围值应用某种程度的健全性检查。
This specification instructs IANA to create a new registry for MSRP parameters. The MSRP Parameter registry is a container for sub-registries. This section further introduces sub-registries for MSRP method names, status codes, and header field names.
本规范指示IANA为MSRP参数创建新的注册表。MSRP参数注册表是子注册表的容器。本节进一步介绍MSRP方法名称、状态代码和头字段名称的子注册表。
Additionally, Section 15.4 through Section 15.7 register new parameters in existing IANA registries.
此外，第15.4节至第15.7节在现有IANA登记册中登记了新参数。
This specification establishes the Methods sub-registry under MSRP Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission).
本规范在MSRP参数下建立方法子注册表，并按如下方式启动其填充。此子注册表中的新参数必须在RFC中发布（作为IETF提交或RFC编辑器提交）。
SEND - [RFC4975] REPORT - [RFC4975]
发送-[RFC4975]报告-[RFC4975]
The following information MUST be provided in an RFC publication in order to register a new MSRP method:
为了注册新的MSRP方法，RFC出版物中必须提供以下信息：
o The method name. o The RFC number in which the method is registered.
o 方法名称。o注册方法的RFC编号。
This specification establishes the header field-Field sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined as follows:
本规范在MSRP参数下建立标题字段子注册表。此子注册表中的新参数必须在RFC中发布（作为IETF提交或RFC编辑器提交）。其初始人口定义如下：
To-Path - [RFC4975]
From-Path - [RFC4975]
Message-ID - [RFC4975]
Success-Report - [RFC4975]
Failure-Report - [RFC4975]
Byte-Range - [RFC4975]
Status - [RFC4975]
To-Path - [RFC4975]
From-Path - [RFC4975]
Message-ID - [RFC4975]
Success-Report - [RFC4975]
Failure-Report - [RFC4975]
Byte-Range - [RFC4975]
Status - [RFC4975]
The following information MUST be provided in an RFC publication in order to register a new MSRP header field:
为了注册新的MSRP标题字段，RFC出版物中必须提供以下信息：
o The header field name. o The RFC number in which the method is registered.
o 标题字段名。o注册方法的RFC编号。
This specification establishes the Status-Code sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined in Section 10. It takes the following format:
本规范在MSRP参数下建立状态代码子注册表。此子注册表中的新参数必须在RFC中发布（作为IETF提交或RFC编辑器提交）。第10节对其初始人口进行了定义。它采用以下格式：
Code [RFC Number]
代码[RFC编号]
The following information MUST be provided in an RFC publication in order to register a new MSRP status code:
为了注册新的MSRP状态代码，RFC出版物中必须提供以下信息：
o The status code number. o The RFC number in which the method is registered.
o 状态代码编号。o注册方法的RFC编号。
MSRP uses TCP port 2855, from the "registered" port range. Usage of this value is described in Section 6.
MSRP使用“注册”端口范围内的TCP端口2855。第6节介绍了该值的用法。
This document requests permanent registration the URI schemes of "msrp" and "msrps".
本文件要求永久注册“msrp”和“msrps”的URI方案。
URI Scheme Name: "msrp" URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in Section 9 of RFC 4975. URI Scheme Semantics: See Section 6 of RFC 4975. Encoding Considerations: See Section 6 of RFC 4975.
URI方案名称：“msrp”URI方案语法：参见RFC 4975第9节中“msrp-URI”的ABNF构造。URI方案语义：参见RFC4975的第6节。编码注意事项：参见RFC 4975第6节。
Applications/Protocols that use this URI Scheme: The Message Session Relay Protocol (MSRP). Interoperability Considerations: MSRP URIs are expected to be used only by implementations of MSRP. No additional interoperability issues are expected. Security Considerations: See Section 14.1 of RFC 4975 for specific security considerations for MSRP URIs, and Section 14 of RFC 4975 for security considerations for MSRP in general. Contact: Ben Campbell (ben@estacado.net). Author/Change Controller: This is a permanent registration request. Change control does not apply.
使用此URI方案的应用程序/协议：消息会话中继协议（MSRP）。互操作性注意事项：MSRP URI预期仅由MSRP的实现使用。预计不会出现其他互操作性问题。安全注意事项：MSRP URI的具体安全注意事项见RFC 4975第14.1节，MSRP的一般安全注意事项见RFC 4975第14节。联系人：本·坎贝尔(ben@estacado.net). 作者/变更控制员：这是一个永久注册请求。更改控制不适用。
URI Scheme Name: "msrps" URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in Section 9 of RFC 4975. URI Scheme Semantics: See Section 6 of RFC 4975. Encoding Considerations: See Section 6 of RFC 4975. Applications/Protocols that use this URI Scheme: The Message Session Relay Protocol (MSRP). Interoperability Considerations: MSRP URIs are expected to be used only by implementations of MSRP. No additional interoperability issues are expected. Security Considerations: See Section 14.1 of RFC 4975 for specific security considerations for MSRP URIs, and Section 14 of RFC 4975 for security considerations for MSRP in general. Contact: Ben Campbell (ben@estacado.net). Author/Change Controller: This is a permanent registration request. Change control does not apply.
URI方案名称：“msrps”URI方案语法：参见RFC 4975第9节中“MSRP-URI”的ABNF构造。URI方案语义：参见RFC4975的第6节。编码注意事项：参见RFC 4975第6节。使用此URI方案的应用程序/协议：消息会话中继协议（MSRP）。互操作性注意事项：MSRP URI预期仅由MSRP的实现使用。预计不会出现其他互操作性问题。安全注意事项：MSRP URI的具体安全注意事项见RFC 4975第14.1节，MSRP的一般安全注意事项见RFC 4975第14节。联系人：本·坎贝尔(ben@estacado.net). 作者/变更控制员：这是一个永久注册请求。更改控制不适用。
MSRP defines the new SDP protocol field values "TCP/MSRP" and "TCP/ TLS/MSRP", which should be registered in the sdp-parameters registry under "proto". This first value indicates the MSRP protocol when TCP is used as an underlying transport. The second indicates that TLS over TCP is used.
MSRP定义了新的SDP协议字段值“TCP/MSRP”和“TCP/TLS/MSRP”，应在SDP参数注册表中的“proto”下注册。当TCP用作底层传输时，第一个值表示MSRP协议。第二个表示使用了TCP上的TLS。
Specifications defining new protocol values must define the rules for the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ MSRP" protocol values allow only one value in the format field (fmt), which is a single occurrence of "*". Actual format determination is made using the "accept-types" and "accept-wrapped-types" attributes.
定义新协议值的规范必须定义关联媒体格式命名空间的规则。“TCP/MSRP”和“TCP/TLS/MSRP”协议值在格式字段（fmt）中只允许一个值，即“*”的一次出现。使用“接受类型”和“接受包装类型”属性确定实际格式。
This document registers the following SDP attribute parameter names in the sdp-parameters registry. These names are to be used in the SDP att-name field.
本文档在SDP参数注册表中注册以下SDP属性参数名称。这些名称将在SDP att name字段中使用。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: accept-types Long-form Attribute Name: Acceptable media types Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "accept-types" attribute contains a list of media types that the endpoint is willing to receive. It may contain zero or more registered media-types, or "*" in a space-delimited string.
联系方式：本·坎贝尔(ben@estacado.net)属性名称：接受类型长格式属性名称：可接受的媒体类型类型：媒体级别取决于字符集属性：无目的和适当的值：“接受类型”属性包含端点愿意接收的媒体类型列表。它可以包含零个或多个已注册的媒体类型，或者在空格分隔的字符串中包含“*”。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: accept-wrapped-types Long-form Attribute Name: Acceptable media types Inside Wrappers Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "accept-wrapped-types" attribute contains a list of media types that the endpoint is willing to receive in an MSRP message with multipart content, but may not be used as the outermost type of the message. It may contain zero or more registered media-types, or "*" in a space-delimited string.
联系方式：本·坎贝尔(ben@estacado.net)属性名称：接受包装类型长格式属性名称：包装内可接受的媒体类型类型：媒体级别受字符集约束属性：无目的和适当的值：“接受包装类型”属性包含端点愿意在包含多部分内容的MSRP消息中接收的媒体类型列表，但不能用作消息的最外层类型。它可以包含零个或多个已注册的媒体类型，或者在空格分隔的字符串中包含“*”。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: max-size Long-form Attribute Name: Maximum message size Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "max-size" attribute indicates the largest message an endpoint wishes to accept. It may take any whole numeric value, specified in octets.
联系方式：本·坎贝尔(ben@estacado.net)属性名称：最大大小长格式属性名称：最大消息大小类型：媒体级别取决于字符集属性：无目的和适当的值：“最大大小”属性表示端点希望接受的最大消息。它可以采用以八位字节为单位的任何整数值。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: path Long-form Attribute Name: MSRP URI Path Type: Media level
联系方式：本·坎贝尔(ben@estacado.net)属性名称：路径长格式属性名称：MSRP URI路径类型：媒体级别
Subject to Charset Attribute: No Purpose and Appropriate Values: The "path" attribute indicates a series of MSRP devices that must be visited by messages sent in the session, including the final endpoint. The attribute contains one or more MSRP URIs, delimited by the space character.
受限于字符集属性：无目的和适当的值：“路径”属性表示会话中发送的消息必须访问的一系列MSRP设备，包括最终端点。该属性包含一个或多个MSRP URI，由空格字符分隔。
In addition to the editors, the following people contributed extensive work to this document: Chris Boulton, Paul Kyzivat, Orit Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert Sparks.
除了编辑之外，以下人员为本文件贡献了大量的工作：克里斯·博尔顿、保罗·基齐瓦特、奥利特·莱文、汉斯·佩尔松、亚当·罗奇、乔纳森·罗森伯格和罗伯特·斯帕克斯。
The following people contributed substantial discussion and feedback to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
以下人员对这项持续努力进行了大量讨论和反馈：埃里克·伯格、埃里森·曼金、乔恩·彼得森、布赖恩·罗森、迪安·威利斯、阿基·尼米、希沙姆·哈塔比尔、佩卡·佩西、米格尔·加西亚、彼得·里德勒、萨姆·哈特曼和让·马奥尼。
[1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[1] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[6] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[8] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[9] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[9] Troost，R.，Dorner，S.，和K.Moore，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[10] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[11] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[12] Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，2004年8月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[13] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[14] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[15] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[16] Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[17] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[18] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[18] Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[19] Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月。
[20] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[20] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, October 2006.
[21] Sparks，R.，Johnston，A.，和D.Petrie，“会话启动协议呼叫控制-传输”，正在进行的工作，2006年10月。
[22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[22] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Session Relay Protocol (MSRP)", RFC 4976, September 2007.
[23] Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 49762007年9月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[24] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[25] Jennings, C., Peterson, J., and J. Fischl, "Certificate Management Service for SIP", Work in Progress, July 2007.
[25] Jennings，C.，Peterson，J.，和J.Fischl，“SIP的证书管理服务”，正在进行的工作，2007年7月。
[26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[26] Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[27] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[27] 彼得森，J.，“即时通讯（CPIM）的通用配置文件”，RFC3860，2004年8月。
[28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[28] Housley，R.，“三重DES和RC2键包装”，RFC 3217，2001年12月。
[29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[29] Camarillo，G.和H.Schulzrinne，“会话启动协议（SIP）中的早期媒体和铃声生成”，RFC 39602004年12月。
[30] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[30] Saint Andre，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 39212004年10月。
[31] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[31] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[32] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[32] Peterson，J.，“即时消息和状态的地址解析”，RFC 38612004年8月。
Authors' Addresses
作者地址
Ben Campbell (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 USA
Ben Campbell（编辑）Estacado Systems 17210 Campbell Road套房250美国德克萨斯州达拉斯75252
EMail: ben@estacado.net
EMail: ben@estacado.net
Rohan Mahy (editor) Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
Rohan Mahy（编辑）Plantronics美国加利福尼亚州圣克鲁斯市Encincal街345号，邮编95060
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Cullen Jennings (editor) Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings（编辑）思科系统有限公司170 West Tasman博士：SJC-21/2美国加利福尼亚州圣何塞95134
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.