Network Working Group C. Jennings
Request for Comments: 4976 Cisco Systems, Inc.
Category: Standards Track R. Mahy
Plantronics
A. B. Roach
Estacado Systems
September 2007
Network Working Group C. Jennings
Request for Comments: 4976 Cisco Systems, Inc.
Category: Standards Track R. Mahy
Plantronics
A. B. Roach
Estacado Systems
September 2007
Relay Extensions for 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
摘要
Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.
已经定义了两种用于传递即时消息的独立模型。页面模式消息是独立的，不是会话启动协议（SIP）会话的一部分，而会话模式消息是使用SIP作为会话的一部分设置的。消息会话中继协议（MSRP）是一种用于无中介的二进制内容的近实时对等交换的协议，设计用于使用单独的集合协议（如SIP）发送信号。本文档向MSRP介绍了消息中继中介的概念，并描述了使用它们所需的扩展。
Table of Contents
目录
1. Introduction and Requirements ...................................3
2. Conventions and Definitions .....................................4
3. Protocol Overview ...............................................4
3.1. Authorization Overview ....................................11
4. New Protocol Elements ..........................................11
4.1. The AUTH Method ...........................................11
4.2. The Use-Path Header .......................................12
4.3. The HTTP Authentication "WWW-Authenticate" Header .........12
4.4. The HTTP Authentication "Authorization" Header ............12
4.5. The HTTP Authentication "Authentication-Info" Header ......12
4.6. Time-Related Headers ......................................12
5. Client Behavior ................................................13
5.1. Connecting to Relays Acting on Your Behalf ................13
5.2. Sending Requests ..........................................18
5.3. Receiving Requests ........................................18
5.4. Managing Connections ......................................18
6. Relay Behavior .................................................18
6.1. Handling Incoming Connections .............................18
6.2. Generic Request Behavior ..................................19
6.3. Receiving AUTH Requests ...................................19
6.4. Forwarding ................................................20
6.4.1. Forwarding SEND Requests ...........................21
6.4.2. Forwarding Non-SEND Requests .......................22
6.4.3. Handling Responses .................................22
6.5. Managing Connections ......................................23
7. Formal Syntax ..................................................23
8. Finding MSRP Relays ............................................24
9. Security Considerations ........................................25
9.1. Using HTTP Authentication .................................25
9.2. Using TLS .................................................26
9.3. Threat Model ..............................................27
9.4. Security Mechanism ........................................29
10. IANA Considerations ...........................................31
10.1. New MSRP Method ..........................................31
10.2. New MSRP Headers .........................................31
10.3. New MSRP Response Codes ..................................31
11. Example SDP with Multiple Hops ................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
Appendix A. Implementation Considerations ........................34
1. Introduction and Requirements ...................................3
2. Conventions and Definitions .....................................4
3. Protocol Overview ...............................................4
3.1. Authorization Overview ....................................11
4. New Protocol Elements ..........................................11
4.1. The AUTH Method ...........................................11
4.2. The Use-Path Header .......................................12
4.3. The HTTP Authentication "WWW-Authenticate" Header .........12
4.4. The HTTP Authentication "Authorization" Header ............12
4.5. The HTTP Authentication "Authentication-Info" Header ......12
4.6. Time-Related Headers ......................................12
5. Client Behavior ................................................13
5.1. Connecting to Relays Acting on Your Behalf ................13
5.2. Sending Requests ..........................................18
5.3. Receiving Requests ........................................18
5.4. Managing Connections ......................................18
6. Relay Behavior .................................................18
6.1. Handling Incoming Connections .............................18
6.2. Generic Request Behavior ..................................19
6.3. Receiving AUTH Requests ...................................19
6.4. Forwarding ................................................20
6.4.1. Forwarding SEND Requests ...........................21
6.4.2. Forwarding Non-SEND Requests .......................22
6.4.3. Handling Responses .................................22
6.5. Managing Connections ......................................23
7. Formal Syntax ..................................................23
8. Finding MSRP Relays ............................................24
9. Security Considerations ........................................25
9.1. Using HTTP Authentication .................................25
9.2. Using TLS .................................................26
9.3. Threat Model ..............................................27
9.4. Security Mechanism ........................................29
10. IANA Considerations ...........................................31
10.1. New MSRP Method ..........................................31
10.2. New MSRP Headers .........................................31
10.3. New MSRP Response Codes ..................................31
11. Example SDP with Multiple Hops ................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
Appendix A. Implementation Considerations ........................34
There are a number of scenarios in which using a separate protocol for bulk messaging is desirable. In particular, there is a need to handle a sequence of messages as a session of media initiated using SIP [8], just like any other media type. The Message Session Relay Protocol (MSRP) [11] is used to convey a session of messages directly between two end systems with no intermediaries. With MSRP, messages can be arbitrarily large and all traffic is sent over reliable, congestion-safe transports.
在许多情况下，需要使用单独的协议进行批量消息传递。特别是，需要像处理任何其他媒体类型一样，将消息序列作为使用SIP[8]启动的媒体会话来处理。消息会话中继协议（MSRP）[11]用于在没有中间层的两个终端系统之间直接传输消息会话。有了MSRP，消息可以任意大，所有流量都通过可靠、拥塞安全的传输发送。
This document describes extensions to the core MSRP protocol to introduce intermediaries called relays. With these extensions, MSRP clients can communicate directly, or through an arbitrary number of relays. Each client is responsible for identifying any relays acting on its behalf and providing appropriate credentials. Clients that can receive new TCP connections directly do not have to implement any new functionality to work with these relays.
本文档描述了核心MSRP协议的扩展，以引入称为中继的中介。通过这些扩展，MSRP客户端可以直接通信，或者通过任意数量的中继进行通信。每个客户负责识别代表其行事的任何继电器，并提供适当的凭证。可以直接接收新TCP连接的客户端不必实现任何新功能即可使用这些中继。
The goals of the MSRP relay extensions are listed below:
MSRP中继扩展的目标如下所示：
o convey arbitrary binary MIME data without modification or transfer encoding
o 无需修改或传输编码即可传输任意二进制MIME数据
o continue to support client-to-client operation (no relay servers required)
o 继续支持客户端到客户端操作（不需要中继服务器）
o operate through an arbitrary number of relays for policy enforcement
o 通过任意数量的继电器进行操作以执行策略
o operate through relays under differing administrative control
o 通过不同管理控制下的继电器进行操作
o allow each client to control which relays are traversed on its behalf
o 允许每个客户端控制代表其遍历哪些中继
o prevent unsolicited messages (spam), "open relays", and Denial of Service (DoS) amplification
o 防止未经请求的邮件（垃圾邮件）、“开放式中继”和拒绝服务（DoS）放大
o allow relays to use one or a small number of TCP or TLS [2] connections to carry messages for multiple sessions, recipients, and senders
o 允许中继使用一个或少量TCP或TLS[2]连接来传输多个会话、收件人和发件人的消息
o allow large messages to be sent over slow connections without causing head-of-line blocking problems
o 允许通过慢速连接发送大型消息，而不会导致线路阻塞问题
o allow transmissions of large messages to be interrupted and resumed in places where network connectivity is lost and later reestablished
o 允许在网络连接丢失的地方中断和恢复大型消息的传输，然后重新建立
o offer notification of message failure at any intermediary
o 在任何中间层提供消息失败通知
o allow relays to delete state after a short amount of time
o 允许继电器在短时间后删除状态
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 [9].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[9]中所述进行解释。
Below we list several definitions important to MSRP:
下面我们列出了对MSRP很重要的几个定义：
MSRP node: a host that implements the MSRP protocols as a client or a relay.
MSRP节点：作为客户端或中继实现MSRP协议的主机。
MSRP client: an MSRP node that is the initial sender or final target of messages and delivery status.
MSRP客户端：作为消息和传递状态的初始发件人或最终目标的MSRP节点。
MSRP relay: an MSRP node that forwards messages and delivery status and may provide policy enforcement. Relays can fragment and reassemble portions of messages.
MSRP中继：转发消息和传递状态的MSRP节点，可提供策略执行。中继可以分割和重新组合部分消息。
Message: arbitrary MIME [13][14] content that one client wishes to send to another. For the purposes of this specification, a complete MIME body as opposed to a portion of a complete message.
消息：一个客户端希望发送给另一个客户端的任意MIME[13][14]内容。在本规范中，指完整的MIME正文，而不是完整消息的一部分。
chunk: a portion of a complete message delivered in a SEND request.
区块：发送请求中传递的完整消息的一部分。
end-to-end: delivery of data from the initiating client to the final target client.
端到端：从发起客户端向最终目标客户端交付数据。
hop: delivery of data between one MSRP node and an adjacent node.
跃点：在一个MSRP节点和相邻节点之间传递数据。
With the introduction of this extension, MSRP has the concept of both clients and relays. Clients send messages to relays and/or other clients. Relays forward messages and message delivery status to clients and other relays. Clients that can open TCP connections to each other without intervening policy restrictions can communicate directly with each other. Clients who are behind firewalls or who need to use intermediaries for policy reasons can use the services of a relay. Each client is responsible for enlisting the assistance of one or more relays for its side of the communication.
随着这一扩展的引入，MSRP同时具有客户端和中继的概念。客户端向中继和/或其他客户端发送消息。中继将消息和消息传递状态转发给客户端和其他中继。可以在不干预策略限制的情况下彼此打开TCP连接的客户端可以彼此直接通信。防火墙后面的客户端或出于策略原因需要使用中介的客户端可以使用中继的服务。每个客户机负责为其通信侧争取一个或多个中继的协助。
Clients that use a relay operate by first opening a TLS connection with a relay, authenticating, and retrieving an msrps: URI (from the relay) that the client can provide to its peers to receive messages
使用中继的客户端通过首先打开与中继的TLS连接、验证和检索msrps:URI（从中继）来操作，该msrps:URI是客户端可以提供给其对等方以接收消息的
later. There are several steps for doing this. First, the client opens a TLS connection to its first relay, and verifies that the name in the certificate matches the name of the relay to which it is trying to connect. Such verification is performed according to the procedures defined in Section 9.2. After verifying that it has connected to the proper host, the client authenticates itself to the relay using an AUTH request containing appropriate authentication credentials. In a successful AUTH response, the relay provides an msrps: URI associated with the path back to the client. The client can then give this URI to other clients for end-to-end message delivery.
后来执行此操作有几个步骤。首先，客户端打开到其第一个中继的TLS连接，并验证证书中的名称是否与其尝试连接的中继的名称匹配。根据第9.2节规定的程序进行此类验证。在验证是否已连接到适当的主机后，客户端使用包含适当身份验证凭据的身份验证请求向中继进行身份验证。在成功的身份验证响应中，中继提供与返回到客户端的路径相关联的msrps:URI。然后，客户机可以将此URI提供给其他客户机以进行端到端消息传递。
When clients wish to send a short message, they issue a SEND request with the entire contents of the message. If any relays are required, they are included in the To-Path header. The leftmost URI in the To-Path header is the next hop to deliver a request or response. The rightmost URI in the To-Path header is the final target.
当客户端希望发送短消息时，会发出包含消息全部内容的发送请求。如果需要任何继电器，它们将包含在To Path标头中。To路径头中最左边的URI是传递请求或响应的下一个跃点。To路径头中最右边的URI是最终目标。
SEND requests contain headers that indicate how they are acknowledged in a hop-by-hop form and in an end-to-end form. The default is that SEND messages are acknowledged hop-by-hop. (Each relay that receives a SEND request acknowledges receipt of the request before forwarding the content to the next relay or the final target.) All other requests are acknowledged end-to-end.
发送请求包含的标头指示如何以逐跳形式和端到端形式确认请求。默认情况下，发送消息是逐跳确认的。（接收发送请求的每个中继在将内容转发到下一个中继或最终目标之前确认接收到请求。）所有其他请求都是端到端确认的。
With the introduction of relays, the subtle semantics of the To-Path header and the From-Path header become more relevant. The To-Path in both requests and responses is the list of URIs that need to be visited in order to reach the final target of the request or response. The From-Path is the list of URIs that indicate how to get back to the original sender of the request or response. These headers differ from the To and From headers in SIP, which do not "swap" from request to response. (Note that sometimes a request is sent to or from an intermediary directly.)
随着中继的引入，To路径头和From路径头的微妙语义变得更加相关。请求和响应中的To路径都是需要访问的URI列表，以便达到请求或响应的最终目标。From路径是URI列表，指示如何返回到请求或响应的原始发件人。这些头与SIP中的To头和from头不同，后者不从请求到响应进行“交换”。（请注意，有时请求会直接发送到中介机构或从中介机构发送。）
When a relay forwards a request, it removes its address from the To-Path header and inserts it as the first URI in the From-Path header. For example, if the path from Alice to Bob is through relays A and B, when B receives the request it contains path headers that look like the following. (Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response.)
当中继转发请求时，它会从To路径头中删除其地址，并将其作为from路径头中的第一个URI插入。例如，如果从Alice到Bob的路径是通过中继器A和B，那么当B接收到请求时，它包含如下所示的路径头。（请注意，MSRP不允许行折叠。示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中不包括反斜杠或额外的CRLF。）
To-Path: msrps://B.example.com/bbb;tcp \
msrps://Bob.example.com/bob;tcp
From-Path: msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
To-Path: msrps://B.example.com/bbb;tcp \
msrps://Bob.example.com/bob;tcp
From-Path: msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
After forwarding the request, the path headers look like this:
转发请求后，路径头如下所示：
To-Path: msrps://Bob.example.com/bob;tcp
From-Path: msrps://B.example.com/bbb;tcp \
msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
To-Path: msrps://Bob.example.com/bob;tcp
From-Path: msrps://B.example.com/bbb;tcp \
msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
The sending of an acknowledgment for SEND requests is controlled by the Success-Report and Failure-Report headers and works the same way as in the base MSRP protocol. When a relay receives a SEND request, if the Failure-Report is set to "yes", it means that the previous hop is running a timer and the relay needs to send a response to the request. If the final response conveys an error, the previous hop is responsible for constructing the error report and sending it back to the original sender of the message. The 200 response acknowledges receipt of the request so that the previous hop knows that it is no longer responsible for the request. If the relay knows that it will not be able to deliver the request and the Failure-Report is set to any value other than "no", then it sends a REPORT to tell the sender about the error. If the Failure-Report is set to "yes", then after the relay is done sending the request to the next hop it starts running a timer; if the timer expires before a response is received from the next hop, the relay assumes that an error has happened and sends a REPORT to the sender. If the Failure-Report is not set to "yes", there is no need for the relay to run this timer.
发送请求确认的发送由成功报告和失败报告头控制，其工作方式与基本MSRP协议中的工作方式相同。当中继接收到发送请求时，如果故障报告设置为“是”，则表示前一跳正在运行计时器，中继需要发送对请求的响应。如果最终响应传递错误，则前一个跃点负责构造错误报告并将其发送回消息的原始发送者。200响应确认收到请求，以便前一跳知道它不再负责该请求。如果中继知道它将无法发送请求，并且故障报告被设置为除“否”以外的任何值，那么它将发送一个报告，告知发送方错误。如果故障报告设置为“是”，则在中继完成向下一跳发送请求后，它开始运行计时器；如果计时器在从下一跳接收响应之前过期，则中继将假定发生错误并向发送方发送报告。如果故障报告未设置为“是”，则继电器无需运行此计时器。
The following example shows a typical MSRP session. The AUTH requests are explained in a later section but left in the example for call flow completeness.
以下示例显示了一个典型的MSRP会话。AUTH请求将在后面的一节中解释，但为了保证调用流的完整性，将其留在示例中。
Alice a.example.org b.example.net Bob
| | | |
|::::::::::::::::::::>| connection opened |<::::::::::::::::::::|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 200 OK-----------| |--- 200 OK---------->|
| | | |
.... time passes ....
| | | |
|--- SEND ----------->| | |
|<-- 200 OK ----------|:::::::::::::::::::>| (slow link) |
| |--- SEND ---------->| |
| |<-- 200 OK ---------|--- SEND ----------->|
| | | ....>|
| | | ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT ----------|
| |<-- REPORT ---------| |
|<-- REPORT ----------| | |
| | | |
Alice a.example.org b.example.net Bob
| | | |
|::::::::::::::::::::>| connection opened |<::::::::::::::::::::|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 200 OK-----------| |--- 200 OK---------->|
| | | |
.... time passes ....
| | | |
|--- SEND ----------->| | |
|<-- 200 OK ----------|:::::::::::::::::::>| (slow link) |
| |--- SEND ---------->| |
| |<-- 200 OK ---------|--- SEND ----------->|
| | | ....>|
| | | ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT ----------|
| |<-- REPORT ---------| |
|<-- REPORT ----------| | |
| | | |
The SEND and REPORT messages are shown below to illustrate the To-Path and From-Path headers. (Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash, nor the extra CRLF is included in the actual request or response.)
下面显示了发送和报告消息，以说明to路径和From路径头。（请注意，MSRP不允许行折叠。示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中既不包含反斜杠，也不包含额外的CRLF。）
MSRP 6aef SEND
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
MSRP 6aef SEND
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------6aef$
Hi Bob, I'm about to send you file.mpeg
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp
Message-ID: 87652
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp
Message-ID: 87652
-------6aef$
MSRP juh76 SEND
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
MSRP juh76 SEND
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------juh76$
Hi Bob, I'm about to send you file.mpeg
-------juh76$
MSRP juh76 200 OK
To-Path: msrps://a.example.org:9000/kjfjan;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp
Message-ID: 87652
-------juh76$
MSRP juh76 200 OK
To-Path: msrps://a.example.org:9000/kjfjan;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp
Message-ID: 87652
-------juh76$
MSRP xght6 SEND
To-Path: msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
MSRP xght6 SEND
To-Path: msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------xght6$
Hi Bob, I'm about to send you file.mpeg
-------xght6$
MSRP xght6 200 OK
To-Path: msrps://b.example.net:9000/aeiug;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
MSRP xght6 200 OK
To-Path: msrps://b.example.net:9000/aeiug;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
MSRP yh67 REPORT
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
When sending large content, the client may split up a message into smaller pieces; each SEND request might contain only a portion of the complete message. For example, when Alice sends Bob a 4-GB file called "file.mpeg", she sends several SEND requests each with a portion of the complete message. Relays can repack message fragments en route. As individual parts of the complete message arrive at the final destination client, the receiving client can optionally send REPORT requests indicating delivery status.
当发送大内容时，客户端可能会将消息拆分为较小的部分；每个发送请求可能只包含完整消息的一部分。例如，当Alice向Bob发送一个名为“file.mpeg”的4-GB文件时，她会发送几个发送请求，每个请求都包含完整消息的一部分。中继可以在路由中重新打包消息片段。当完整消息的各个部分到达最终目标客户机时，接收客户机可以选择发送指示交付状态的报告请求。
MSRP nodes can send individual portions of a complete message in multiple SEND requests. As relays receive chunks, they can reassemble or re-fragment them as long as they resend the resulting chunks in order. (Receivers still need to be prepared to receive out-of-order chunks, however.) If the sender has set the Success-Report header to "yes", once a chunk or complete message arrives at the destination client, the destination will send a REPORT request
MSRP节点可以在多个发送请求中发送完整消息的各个部分。中继接收块时，只要按顺序重新发送生成的块，就可以重新组合或重新分割它们。（但是，接收者仍然需要准备好接收无序区块。）如果发送者已将成功报告头设置为“是”，则一旦区块或完整消息到达目标客户端，目标将发送报告请求
indicating that a chunk arrived end-to-end. This request travels back along the reverse path of the SEND request. Unlike the SEND request, which can be acknowledged along every hop, REPORT requests are never acknowledged.
表示块端到端到达。该请求沿着发送请求的反向路径返回。与发送请求不同（发送请求可以在每个跃点上确认），报告请求从不被确认。
The following example shows a message being re-chunked through two relays:
以下示例显示通过两个中继重新分块的消息：
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 1-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 1-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 1-3 ------|
| |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 1-3 ------| | ...>|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 1-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 1-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 1-3 ------|
| |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 1-3 ------| | ...>|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
Relays only keep transaction states for a short time for each chunk. Delivery over each hop should take no more than 30 seconds after the last byte of data is sent. Client applications define their own implementation-dependent timers for end-to-end message delivery.
对于每个区块，中继仅在短时间内保持事务状态。在发送数据的最后一个字节后，每个跃点上的传递应不超过30秒。客户端应用程序为端到端消息传递定义自己的依赖于实现的计时器。
For client-to-client communication, the sender of a message typically opens a new TCP connection (with or without TLS) if one is needed. Relays reuse existing connections first, but can open new connections (typically to other relays) to deliver requests such as SEND or REPORT. Responses can only be sent over existing connections.
对于客户端到客户端的通信，如果需要，消息的发送方通常会打开一个新的TCP连接（带或不带TLS）。中继首先重用现有的连接，但可以打开新的连接（通常是到其他中继）来传递请求，如发送或报告。只能通过现有连接发送响应。
The relationship between MSRP and signaling protocols (such as SIP) is unchanged by this document, and is as described in [11]. An example of an SDP exchange for an MSRP session involving relays is shown in Section 11.
MSRP和信令协议（如SIP）之间的关系在本文件中没有改变，如[11]所述。第11节显示了涉及继电器的MSRP会话的SDP交换示例。
A key element of this protocol is that it cannot introduce open relays, with all the associated problems they create, including DoS attacks. A message is only forwarded by a relay if it is either going to or coming from a client that has authenticated to the relay and been authorized for relaying messages on that particular session. Because of this, clients use an AUTH message to authenticate to a relay and get a URI that can be used for forwarding messages.
该协议的一个关键要素是它不能引入开放式中继，以及由此产生的所有相关问题，包括DoS攻击。只有当消息发送到或来自已通过中继身份验证并被授权在该特定会话上中继消息的客户端时，才会由中继转发消息。因此，客户端使用身份验证消息对中继进行身份验证，并获取可用于转发消息的URI。
If a client wishes to use a relay, it sends an AUTH request to the relay. The client authenticates the relay using the relay's TLS certificate. The client uses HTTP Digest authentication [1] to authenticate to the relay. When the authentication succeeds, the relay returns a 200 response that contains the URI that the client can use in the MSRP path for the relay.
如果客户端希望使用中继，它将向中继发送身份验证请求。客户端使用中继的TLS证书对中继进行身份验证。客户端使用HTTP摘要身份验证[1]对中继进行身份验证。当身份验证成功时，中继返回一个200响应，其中包含客户端可以在中继的MSRP路径中使用的URI。
A typical challenge response flow is shown below:
典型的挑战响应流程如下所示：
Alice a.example.org
| |
|::::::::::::::::::::>|
|--- AUTH ----------->|
|<- 401 Unauthorized -|
|--- AUTH ----------->|
|<-- 200 OK-----------|
| |
Alice a.example.org
| |
|::::::::::::::::::::>|
|--- AUTH ----------->|
|<- 401 Unauthorized -|
|--- AUTH ----------->|
|<-- 200 OK-----------|
| |
The URI that the client should use is returned in the Use-Path header of the 200.
客户端应该使用的URI在200的use Path头中返回。
Note that URIs returned to the client are effectively secret tokens that should be shared only with the other MSRP client in a session. For that reason, the client MUST NOT reuse the same URI for multiple sessions, and needs to protect these URIs from eavesdropping.
请注意，返回到客户端的URI实际上是秘密令牌，在会话中只能与其他MSRP客户端共享。因此，客户机不能在多个会话中重复使用相同的URI，并且需要保护这些URI不被窃听。
AUTH requests are used by clients to create a handle they can use to receive incoming requests. AUTH requests also contain credentials used to authenticate a client and authorization policy used to block Denial of Service attacks.
客户端使用身份验证请求创建一个句柄，用于接收传入请求。身份验证请求还包含用于验证客户端的凭据和用于阻止拒绝服务攻击的授权策略。
In response to an AUTH request, a successful response contains a Use-Path header with a list of URIs that the client can give to its peers to route responses back to the client.
为了响应身份验证请求，成功的响应包含一个Use Path头，其中包含一个URI列表，客户端可以将该列表提供给其对等方，以将响应路由回客户端。
The Use-Path header is a list of URIs provided by an MSRP relay in response to a successful AUTH request. This list of URIs can be used by the MSRP client that sent the AUTH request to receive MSRP requests and to advertise this list of URIs, for example, in a session description. URIs in the Use-Path header MUST include a fully qualified domain name (as opposed to a numeric IP address) and an explicit port number.
Use Path header是MSRP中继响应成功的身份验证请求而提供的URI列表。发送身份验证请求的MSRP客户端可以使用此URI列表来接收MSRP请求，并在会话描述中公布此URI列表。Use Path头中的URI必须包括完全限定的域名（与数字IP地址相反）和显式端口号。
The URIs in the Use-Path header are in the same order that the authenticating client uses them in a To-Path header. Instructions on forming To-Path headers and SDP [7] path attributes from information in the Use-Path header are provided in Section 5.1.
使用路径头中的URI与身份验证客户端在To路径头中使用它们的顺序相同。第5.1节提供了关于根据使用路径头中的信息形成路径头和SDP[7]路径属性的说明。
The "WWW-Authenticate" header contains a challenge token used in the HTTP Digest authentication procedure (from RFC 2617 [1]). The usage of HTTP Digest authentication in MSRP is described in detail in Section 5.1.
“WWW-Authenticate”标头包含HTTP摘要身份验证过程中使用的质询令牌（来自RFC 2617[1]）。第5.1节详细描述了MSRP中HTTP摘要身份验证的用法。
The "Authorization" header contains authentication credentials for HTTP Digest authentication (from RFC 2617 [1]). The usage of HTTP Digest authentication in MSRP is described in detail in Section 5.1.
“Authorization”标头包含HTTP摘要身份验证的身份验证凭据（来自RFC 2617[1]）。第5.1节详细描述了MSRP中HTTP摘要身份验证的用法。
The "Authentication-Info" header contains future challenges to be used for HTTP Digest authentication (from RFC 2617 [1]). The usage of HTTP Digest authentication in MSRP is described in detail in Section 5.1.
“Authentication Info”标头包含用于HTTP摘要身份验证的未来挑战（来自RFC 2617[1]）。第5.1节详细描述了MSRP中HTTP摘要身份验证的用法。
The Expires header in a request provides a relative time after which the action implied by the method of the request is no longer of interest. In a request, the Expires header indicates how long the sender would like the request to remain valid. In a response, the Expires header indicates how long the responder considers this information relevant. Specifically, an Expires header in an AUTH request indicates how long the provided URIs will be valid.
请求中的Expires报头提供了一个相对时间，在该相对时间之后，请求方法所隐含的操作不再受关注。在请求中，Expires标头指示发送方希望请求保持有效的时间。在响应中，Expires标头指示响应者认为此信息相关的时间。具体来说，身份验证请求中的Expires标头指示所提供的URI的有效期。
The Min-Expires header contains the minimum duration a server will permit in an Expires header. It is sent only in 423 "Interval Out-of-Bounds" responses. Likewise, the Max-Expires header contains the maximum duration a server will permit in an Expires header.
Min Expires标头包含服务器在Expires标头中允许的最短持续时间。它仅在423个“间隔超出界限”响应中发送。同样，Max Expires报头包含服务器在Expires报头中允许的最大持续时间。
Clients that want to use the services of a relay or list of relays need to send an AUTH request to each relay that will act on their behalf. (For example, some organizations could deploy an "intra-org" relay and an "extra-org" relay.) The inner relay is used to tunnel the AUTH requests to the outer relay. For example, the client will send an AUTH to intra-org and get back a path that can be used for forwarding through intra-org. The client would then send a second AUTH destined to extra-org but sent through intra-org. The intra-org relay forwards this to extra-org and extra-org returns a path that can be used to forward messages from another destination to extra-org to intra-org and then on to this client. Each relay authenticates the client. The client authenticates the first relay and each relay authenticates the next relay.
想要使用中继或中继列表服务的客户端需要向将代表其行事的每个中继发送身份验证请求。（例如，一些组织可以部署一个“内部组织”中继和一个“额外组织”中继。）内部中继用于将身份验证请求通过隧道传输到外部中继。例如，客户端将向组织内发送一个AUTH，并返回一个可用于通过组织内转发的路径。然后，客户机将向额外组织发送第二个认证，但通过组织内发送。组织内中继将此转发到额外组织，额外组织返回一条路径，该路径可用于将消息从另一个目的地转发到额外组织，再转发到组织内，然后转发到此客户端。每个中继都对客户端进行身份验证。客户端对第一个中继进行身份验证，每个中继对下一个中继进行身份验证。
Clients can be configured (typically, through discovery or manual provisioning) with a list of relays they need to use. They MUST be able to form a connection to the first relay and send an AUTH command to get a URI that can be used in a To-Path header. The client can authenticate its first relay by looking at the relay's TLS certificate. The client MUST authenticate itself to each of its relays using HTTP Digest authentication [1] (see Section 9.1 for details).
可以使用需要使用的中继列表配置客户端（通常通过发现或手动配置）。它们必须能够与第一个中继建立连接，并发送AUTH命令以获取可在to路径头中使用的URI。客户端可以通过查看中继的TLS证书对其第一个中继进行身份验证。客户端必须使用HTTP摘要身份验证[1]对其每个中继进行身份验证（有关详细信息，请参阅第9.1节）。
The relay returns a URI, or list of URIs, in the "Use-Path" header of a success response. Each URI SHOULD be used for only one unique session. These URIs are used by the client in the path attribute that is sent in the SDP to set up the session, and in the To-Path header of outgoing requests. To form the To-Path header for outgoing requests, the client takes the list of URIs in the Use-Path header after the outermost authentication and appends the list of URIs provided in the path attribute in the peer's session description. To form the SDP path attribute to provide to the peer, the client reverses the list of URIs in the Use-Path header (after the outermost authentication), and appends the client's own URI.
中继在成功响应的“使用路径”头中返回URI或URI列表。每个URI只能用于一个唯一的会话。这些URI由客户端在SDP中发送以设置会话的path属性中使用，并在传出请求的to path头中使用。要为传出请求形成To Path头，客户端在最外层身份验证之后获取Use Path头中的URI列表，并将Path属性中提供的URI列表附加到对等方的会话描述中。要形成要提供给对等方的SDP path属性，客户端将反转Use path头中的URI列表（在最外层的身份验证之后），并附加客户端自己的URI。
For example, "A" has to traverse its own relays "B" and "C", and then relays "D" and "E" in domain2 to reach "F". Client "A" will authenticate with its relays "B" and "C" and eventually receive a Use-Path header containing "B C". Client "A" reverses the list
例如，“A”必须穿过它自己的中继器“B”和“C”，然后在域2中通过中继器“D”和“E”到达“F”。客户端“A”将通过其中继“B”和“C”进行身份验证，并最终收到包含“B C”的使用路径头。客户端“A”反转列表
(now "C B") and appends its own URI (now "C B A"), and provides this list to "F" in a path SDP attribute. Client "F" sends its SDP path list "D E F", which client "A" appends to the Use-Path list it received "B C". The resulting To-Path header is "B C D E F".
（现在是“cb”）并附加其自己的URI（现在是“cba”），并在路径SDP属性中将此列表提供给“F”。客户端“F”发送其SDP路径列表“def”，客户端“A”将其附加到它接收到的“bc”的使用路径列表中。生成的To路径头是“B C D E F”。
domain 1 domain 2
---------------- -----------------
domain 1 domain 2
---------------- -----------------
client relays relays client
A ----- B -- C -------- D -- E ----- F
client relays relays client
A ----- B -- C -------- D -- E ----- F
Use-Path returned by C: B C
path: attribute generated by A: C B A
path: attribute received from F: D E F
To-Path header generated by A: B C D E F
Use-Path returned by C: B C
path: attribute generated by A: C B A
path: attribute received from F: D E F
To-Path header generated by A: B C D E F
The initial AUTH request sent to a relay by a client will generally not contain an Authorization header, since the client has no challenge to which it can respond. In response to an AUTH request that does not contain an Authorization header, a relay MUST respond with a "401 Unauthorized" response containing a WWW-Authenticate header. The WWW-Authenticate header is formed as described in RFC 2617 [1], with the restrictions and modifications described in Section 9.1. The realm chosen by the MSRP relay in such a challenge is a matter of administrative policy. Because a single relay does not have multiple protection spaces in MSRP, it is not unreasonable to always use the relay's hostname as the realm.
客户端发送到中继的初始身份验证请求通常不包含授权标头，因为客户端没有可以响应的质询。为了响应不包含授权标头的身份验证请求，中继必须使用包含WWW Authenticate标头的“401 Unauthorized”响应进行响应。WWW Authenticate标头按照RFC 2617[1]中所述的方式形成，并进行第9.1节中所述的限制和修改。管理系统更新项目在这种挑战中选择的领域是一个行政政策问题。因为单个继电器在MSRP中没有多个保护空间，所以始终使用继电器的主机名作为域并非不合理。
Upon receiving a 401 response to a request, the client SHOULD fetch the realm from the WWW-Authenticate header in the response and retry the request, including an Authorization header with the correct credentials for the realm. The Authorization header is formed as described in RFC 2617 [1], with the restrictions and modifications described in Section 9.1.
在收到对请求的401响应后，客户端应该从响应中的WWW Authenticate头获取域，然后重试该请求，包括具有域的正确凭据的授权头。授权标头的形成如RFC 2617[1]中所述，并带有第9.1节中所述的限制和修改。
When a client wishes to use more than one relay, it MUST send an AUTH request to each relay it wishes to use. Consider a client A, that wishes messages to flow from A to the first relay, R1, then on to a second relay, R2. This client will do a normal AUTH with R1. It will then do an AUTH transaction with R2 that is routed through R1. The client will form this AUTH message by setting the To-Path to msrps://R1;tcp msrps://R2;tcp. R1 will forward this request onward to R2.
当客户端希望使用多个中继时，它必须向希望使用的每个中继发送一个身份验证请求。考虑一个客户端A，它希望消息从A到第一中继，R1，然后到第二中继，R2。此客户端将对R1执行正常身份验证。然后，它将与通过R1路由的R2进行身份验证事务。客户端将通过将To路径设置为来形成此身份验证消息msrps://R1;tcpmsrps://R2;tcp。R1将此请求转发给R2。
When sending an AUTH request, the client MAY add an Expires header to request a MSRP URI that is valid for no longer than the provided interval (a whole number of seconds). The server will include an
当发送身份验证请求时，客户端可能会添加Expires标头以请求有效期不超过提供的间隔（整数秒）的MSRP URI。服务器将包括一个
Expires header in a successful response indicating how long its URI from the Use-Path will be valid. Note that each server can return an independent expiration time.
Expires标头在成功响应中指示其URI在使用路径中的有效时间。请注意，每个服务器都可以返回一个独立的过期时间。
Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response.
请注意，MSRP不允许折线。示例中的“\”表示由于本文档行长度的限制而导致的行延续。实际请求或响应中既不包含反斜杠也不包含额外的CRLF。
(Alice opens a TLS connection to intra.example.com and sends an AUTH request to initiate the authentication process.)
（Alice打开到intra.example.com的TLS连接，并发送身份验证请求以启动身份验证过程。）
MSRP 49fh AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------49fh$
MSRP 49fh AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------49fh$
(Alice's relay challenges the AUTH request.)
（Alice的中继对身份验证请求提出质疑。）
MSRP 49fh 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
-------49fh$
MSRP 49fh 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
-------49fh$
(Alice responds to the challenge.)
（爱丽丝回应了挑战。）
MSRP 49fi AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="intra.example.com", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
qop=auth, nc=00000001, cnonce="0a4f113b", \
response="6629fae49393a05397450978507c4ef1"
-------49fi$
MSRP 49fi AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="intra.example.com", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
qop=auth, nc=00000001, cnonce="0a4f113b", \
response="6629fae49393a05397450978507c4ef1"
-------49fi$
(Alice's relay confirms that Alice is an authorized user. As a matter of local policy, it includes an "Authentication-Info" header with a new nonce value to expedite future AUTH requests.)
（Alice的中继确认Alice是授权用户。根据本地策略，它包括一个带有新nonce值的“Authentication Info”标头，以加快未来的身份验证请求。）
MSRP 49fi 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp
Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\
rspauth="7327570c586207eca2afae94fc20903d", \
cnonce="0a4f113b", nc=00000001, qop=auth
Expires: 900
-------49fi$
MSRP 49fi 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp
Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\
rspauth="7327570c586207eca2afae94fc20903d", \
cnonce="0a4f113b", nc=00000001, qop=auth
Expires: 900
-------49fi$
(Alice now sends an AUTH request to her "external" relay through her "internal" relay, using the URI she just obtained; the AUTH request is challenged.)
（Alice现在使用刚获得的URI，通过她的“内部”中继向她的“外部”中继发送身份验证请求；身份验证请求受到质疑。）
MSRP mnbvw AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------mnbvw$
MSRP mnbvw AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------mnbvw$
MSRP m2nbvw AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
-------m2nbvw$
MSRP m2nbvw AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
-------m2nbvw$
MSRP m2nbvw 401 Unauthorized
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------m2nbvw$
MSRP m2nbvw 401 Unauthorized
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------m2nbvw$
MSRP mnbvw 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------mnbvw$
MSRP mnbvw 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------mnbvw$
(Alice replies to the challenge with her credentials and is then authorized to use the "external" relay).
（Alice用她的凭证回答质询，然后被授权使用“外部”中继）。
MSRP m3nbvx AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m3nbvx$
MSRP m3nbvx AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m3nbvx$
MSRP m4nbvx AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m4nbvx$
MSRP m4nbvx AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m4nbvx$
MSRP m4nbvx 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m4nbvx$
MSRP m4nbvx 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m4nbvx$
MSRP m3nbvx 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m3nbvx$
MSRP m3nbvx 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m3nbvx$
The procedure for forming SEND and REPORT requests is identical for clients whether or not relays are involved. The specific procedures are described in Section 7 of the core MSRP protocol.
无论是否涉及中继，形成发送和报告请求的过程对于客户端都是相同的。具体程序见核心管理系统更新项目协议第7节。
As usual, once the next-hop URI is determined, the client MUST find the appropriate address, port, and transport to use and then check if there is already a suitable existing connection to the next-hop target. If so, the client MUST send the request over the most suitable connection. Suitability MAY be determined by a variety of factors such as measured load and local policy, but in most simple implementations a connection will be suitable if it exists and is active.
通常，一旦确定下一个跃点URI，客户端必须找到要使用的适当地址、端口和传输，然后检查是否已经存在到下一个跃点目标的适当连接。如果是这样，客户端必须通过最合适的连接发送请求。适用性可能由各种因素决定，例如测量的负载和本地策略，但在大多数简单的实现中，如果连接存在且处于活动状态，则连接将是合适的。
The procedure for receiving requests is identical for clients whether or not relays are involved.
无论是否涉及中继，客户端接收请求的过程都是相同的。
Clients should open a connection whenever they wish to deliver a request and no suitable connection exists. For connections to relays, the client should leave a connection up until no sessions have used it for a locally defined period of time, which defaults to 5 minutes for foreign relays and one hour for the client's relays.
只要客户端希望传递请求，并且不存在合适的连接，就应该打开连接。对于与继电器的连接，客户端应保持连接，直到本地定义的时间段内没有会话使用它为止，对于外部继电器，默认为5分钟，对于客户端继电器，默认为1小时。
When a relay receives an incoming connection on a port configured for TLS, it includes a client CertificateRequest in the same record in which it sends its ServerHello. If the TLS client provides a certificate, the server verifies it and continues if the certificate is valid and rooted in a trusted authority. If the TLS client does not provide a certificate, the server assumes that the client is an MSRP endpoint and invokes Digest authentication. Once a TCP or TLS channel is negotiated, the server waits for up to 30 seconds to receive an MSRP request over the channel. If no request is received in that time, the server closes the connection. If no successful requests are sent during this probationary period, the server closes the connection. Likewise, if several unsuccessful requests are sent during the probation period and no requests are sent successfully, the server SHOULD close the connection.
当中继在为TLS配置的端口上接收到传入连接时，它在发送其ServerHello的同一记录中包含客户端CertificateRequest。如果TLS客户端提供证书，则服务器将验证该证书，并继续验证该证书是否有效以及是否以受信任的机构为根。如果TLS客户端不提供证书，服务器将假定该客户端是MSRP端点，并调用摘要身份验证。一旦协商TCP或TLS通道，服务器将等待30秒，以通过该通道接收MSRP请求。如果在此期间未收到任何请求，服务器将关闭连接。如果在此试用期内未发送成功的请求，服务器将关闭连接。同样，如果在试用期内发送了几个不成功的请求，但没有成功发送任何请求，则服务器应关闭连接。
Upon receiving a new request, relays first verify the validity of the request. Relays then examine the first URI in the To-Path header and remove this URI if it matches a URI corresponding to the relay. If the request is not addressed to the relay, the relay immediately drops the corresponding connection over which the request was received.
在收到新请求后，中继首先验证请求的有效性。中继然后检查To路径头中的第一个URI，如果该URI与中继对应的URI匹配，则删除该URI。如果请求没有发送到继电器，继电器会立即断开接收请求的相应连接。
When a relay receives an AUTH request, the first thing it does is to authenticate and authorize the previous hop and the client at the far end. If there are no other relays between this relay and the client, then these are the same thing.
当中继接收到身份验证请求时，它要做的第一件事是对前一个跃点和远端的客户端进行身份验证和授权。如果此继电器和客户端之间没有其他继电器，则这些继电器是相同的。
When the previous hop is a relay, authentication is done with TLS using mutual authentication. If the TLS client presented a host certificate, the relay checks that the subjectAltName in the certificate of the TLS client matches the hostname in the first From-Path URI. If the TLS client doesn't provide a host certificate, the relay assumes the TLS client is an MSRP client and sends it a challenge.
当前一个跃点是中继时，使用相互身份验证使用TLS进行身份验证。如果TLS客户端提供了主机证书，则中继将检查TLS客户端证书中的subjectAltName是否与第一个From路径URI中的主机名匹配。如果TLS客户端不提供主机证书，则中继将假定TLS客户端是MSRP客户端并向其发送质询。
Authorization is a matter of local policy at the relay. Many relays will choose to authorize all relays that can be authenticated, possibly in conjunction with a blacklisting mechanism. Relays intended to operate only within a limited federation may choose to authorize only those relays whose identity appears in a provisioned list. Other authorization policies may also be applied.
授权是中继的本地策略问题。许多中继将选择授权所有可通过身份验证的中继，可能与黑名单机制结合使用。仅在有限联邦内运行的继电器可选择仅授权其标识出现在供应列表中的继电器。还可以应用其他授权策略。
When the previous hop is a client, the previous hop is the same as the identity of the client. The relay checks the credentials (username and password) provided by the client in the Authorization header and checks if this client is allowed to use the relay. If the client is not authorized, the relay returns a 403 response. If the client has requested a particular expiration time in an Expires header, the relay needs to check that the time is acceptable to it and, if not, return an error containing a Min-Expires or Max-Expires header, as appropriate.
当上一个跃点是客户端时，上一个跃点与客户端的标识相同。中继检查客户端在授权标头中提供的凭据（用户名和密码），并检查是否允许该客户端使用中继。如果客户端未经授权，则中继返回403响应。如果客户端在Expires标头中请求了特定的过期时间，则中继需要检查该时间是否可接受，如果不可接受，则返回包含Min Expires或Max Expires标头（视情况而定）的错误。
Next the relay will generate an MSRP URI that allows messages to be forwarded to or from this previous hop. If the previous hop was a relay authenticated by mutual TLS, then the URI MUST be valid to route across any connection the relay has to the previous hop relay. If the previous hop is a client, then the URI MUST only be valid to
接下来，中继将生成一个MSRP URI，该URI允许将消息转发到上一跳或从上一跳转发消息。如果前一个跃点是由双方TLS认证的中继，则URI必须有效，才能通过中继与前一个跃点中继的任何连接进行路由。如果上一个跃点是客户端，则URI必须仅对客户端有效
route across the same connection over which the AUTH request was received. If the client's connection is closed and then reopened, the URI MUST be invalidated.
通过接收身份验证请求的同一连接进行路由。如果客户端的连接关闭然后重新打开，则URI必须无效。
If the AUTH request contains an Expires header, the relay MUST ensure that the URI is invalidated after the expiry time. The URI MUST contain at least 64 bits of cryptographically random material so that it is not guessable by attackers. If a relay is requested to forward a message for which the URI is not valid, the relay MUST discard the message and MAY send a REPORT indicating that the AUTH URI was bad.
如果身份验证请求包含Expires标头，则中继必须确保URI在过期时间后失效。URI必须至少包含64位加密随机材料，以便攻击者无法猜测。如果请求中继器转发URI无效的消息，中继器必须丢弃该消息，并可能发送一份报告，指出验证URI不正确。
A successful AUTH response returns a Use-Path header that contains an MSRP URI that the client can use. It also returns an Expires header that indicates how long the URI will be valid (expressed as a whole number of seconds).
成功的AUTH响应返回一个Use Path头，该头包含客户端可以使用的MSRP URI。它还返回一个Expires报头，该报头指示URI有效的时间（以秒的整数表示）。
If a relay receives several unsuccessful AUTH requests from a client that is directly connected to it via TLS, the relay SHOULD terminate the corresponding connection. Similarly, if a relay forwards several failed AUTH requests to the same destination that originate from a client that is directly connected to it via TLS, the relay SHOULD terminate the corresponding connection. Determination of a remote AUTH failure can be made by observing an AUTH request containing an Authorization header that triggers a 401 response without a "stale=TRUE" indication. These preventive measures apply only to a connection between a relay and a client; a relay SHOULD NOT use excessive AUTH request failures as a reason to terminate a connection with another relay.
如果中继从通过TLS直接连接到它的客户端接收到多个不成功的身份验证请求，则中继应终止相应的连接。类似地，如果中继将多个失败的身份验证请求转发到源于通过TLS直接连接到它的客户端的同一目标，则中继应终止相应的连接。可以通过观察包含授权标头的授权请求来确定远程身份验证失败，该授权标头在没有“stale=TRUE”指示的情况下触发401响应。这些预防措施仅适用于继电器和客户机之间的连接；中继不应使用过多的身份验证请求失败作为终止与另一个中继的连接的原因。
Before any request is forwarded, the relay MUST check that the first URI in the To-Path header corresponds to a URI that this relay has created and handed out in the Use-Path header of an AUTH request. Next it verifies that either 1) the next hop is the next hop back toward the client that obtained this URI, or 2) the previous hop was the correct previous hop coming from the client that obtained this URI.
在转发任何请求之前，中继必须检查To Path头中的第一个URI是否与该中继在AUTH请求的Use Path头中创建并分发的URI相对应。接下来，它验证1）下一个跃点是返回到获取此URI的客户端的下一个跃点，或者2）上一个跃点是来自获取此URI的客户端的正确上一个跃点。
Since transact-id values are not allowed to conflict on a given connection, a relay will generally need to construct a new transact-id value for any request that it forwards.
由于在给定连接上不允许transact-id值发生冲突，因此中继通常需要为其转发的任何请求构造新的transact-id值。
If an incoming SEND request contains a Failure-Report header with a value of "yes", an MSRP relay that receives that SEND request MUST respond with a final response immediately. A 200-class response indicates the successful receipt of a message fragment but does not mean that the message has been forwarded on to the next hop. The final response to the SEND MUST be sent only to the previous hop, which could be an MSRP relay or the original sender of the SEND request.
如果传入的发送请求包含值为“是”的故障报告标头，则接收该发送请求的MSRP中继必须立即以最终响应进行响应。200类响应表示成功接收到消息片段，但并不意味着消息已转发到下一跳。发送的最终响应必须仅发送到前一跳，前一跳可以是MSRP中继或发送请求的原始发送方。
If the Failure-Report header is "yes", then the relay MUST run a timer to detect if transmission to the next hop fails. The timer starts when the last byte of the message has been sent to the next hop. If after 30 seconds the next hop has not sent any response, then the relay MUST construct a REPORT with a status code of 408 to indicate a timeout error happened sending the message, and send the REPORT to the original sender of the message.
如果故障报告标题为“是”，则中继必须运行计时器以检测到下一跳的传输是否失败。当消息的最后一个字节被发送到下一个跃点时，计时器启动。如果在30秒后下一跳未发送任何响应，则中继必须构造状态代码为408的报告，以指示发送消息时发生超时错误，并将报告发送给消息的原始发送者。
If the Failure-Report header is "yes" or "partial", and if there is a problem processing the SEND request or if an error response is received for that SEND request, then the relay MUST respond with an appropriate error response in a REPORT back to the original source of the message.
如果故障报告标题为“是”或“部分”，并且如果处理发送请求时出现问题，或者如果接收到该发送请求的错误响应，则中继必须在返回消息原始源的报告中以适当的错误响应进行响应。
The MSRP relay MAY further break up the message fragment received in the SEND request into smaller fragments and forward them to the next hop in separate SEND requests. It MAY also combine message fragments received before or after this SEND request, and forward them out in a single SEND request to the next hop identified in the To-Path header. The MSRP relay MUST NOT combine message fragments from SEND requests with different values in the Message-ID header.
MSRP中继可以进一步将发送请求中接收的消息片段分解成更小的片段，并在单独的发送请求中将它们转发到下一跳。它还可以组合在此发送请求之前或之后收到的消息片段，并在单个发送请求中将它们转发到to Path标头中标识的下一个跃点。MSRP中继不得将来自发送请求的消息片段与消息ID标头中的不同值组合在一起。
The MSRP relay MAY choose whether to further fragment the message, or combine message fragments, or send the message as is, based on some policy that is administered, or based on the network speed to the next hop, or any other mechanism.
MSRP中继可以基于所管理的某个策略，或者基于到下一跳的网络速度，或者任何其他机制，选择是否进一步分割消息，或者组合消息片段，或者按原样发送消息。
If the MSRP relay has knowledge of the byte range that it will transmit to the next hop, it SHOULD update the Byte-Range header in the SEND request appropriately.
如果MSRP中继知道它将传输到下一跳的字节范围，它应该适当地更新发送请求中的字节范围头。
Before forwarding the SEND request to the next hop, the MSRP relay MUST inspect the first URI in the To-Path header. If it indicates this relay, the relay removes this URI from the To-Path header and inserts this URI in the From-Path header before any other URIs. If it does not indicate this relay, there has been an error in
在将发送请求转发到下一跳之前，MSRP中继必须检查to Path头中的第一个URI。如果指示此中继，则中继将从To路径头中删除此URI，并在任何其他URI之前将此URI插入from路径头中。如果未指示此继电器，则表示继电器中存在错误
forwarding at a previous hop. In this case, the relay SHOULD discard the message, and if the Failure-Report header is set to "yes", the relay SHOULD generate a failure report.
在前一跳转发。在这种情况下，继电器应丢弃消息，如果故障报告标题设置为“是”，则继电器应生成故障报告。
An MSRP relay that receives any request other than a SEND request (including new methods unknown to the relay) first follows the validation and authorization rules for all requests. Then the relay moves its URI from the beginning of the To-Path headers to the beginning of the From-Path header and forwards the request on to the next hop. If it already has a connection to the next hop, it SHOULD use this connection and not form a new connection. If no suitable connection exists, the relay opens a new connection.
接收除发送请求以外的任何请求（包括中继未知的新方法）的MSRP中继首先遵循所有请求的验证和授权规则。然后，中继将其URI从To路径头的开头移动到from路径头的开头，并将请求转发到下一个跃点。如果它已经连接到下一个跃点，则应该使用此连接，而不是形成新连接。如果不存在合适的连接，继电器将打开一个新的连接。
Requests with an unknown method are forwarded as if they were REPORT requests. An MSRP node MAY be configured to block unknown methods for security reasons.
具有未知方法的请求被转发，就像它们是报告请求一样。出于安全原因，MSRP节点可配置为阻止未知方法。
Relays receiving a response first verify that the first URI in the To-Path corresponds to itself; if not, the response SHOULD be dropped. Likewise, if the message cannot be parsed, the relay MUST drop the response. Next the relay determines if there are additional URIs in the To-Path. (For responses to SEND requests there will be no additional URIs, whereas responses to AUTH requests have additional URIs directing the response back to the client.)
接收响应的中继器首先验证To路径中的第一URI对应于自身；如果没有，则应删除响应。同样，如果无法解析消息，则中继必须丢弃响应。接下来，中继确定To路径中是否有其他URI。（对于发送请求的响应，将不会有额外的URI，而对身份验证请求的响应有额外的URI将响应定向回客户端。）
If the response matches an existing transaction, then that transaction is completed and any timers running on it can be removed. If the response is a non 200 response, and the original request was a SEND request that had a Failure-Report header with a value other than "no", then the relay MUST send a REPORT indicating the nature of the failure. The response code received by the relay is used to form the status line in the REPORT that the relay sends.
如果响应与现有事务匹配，则该事务将完成，并且可以删除在其上运行的任何计时器。如果响应是非200响应，并且原始请求是一个发送请求，其故障报告头的值不是“否”，则中继必须发送指示故障性质的报告。继电器接收到的响应代码用于在继电器发送的报告中形成状态行。
If there are additional URIs in the To-Path header, the relay MUST then move its URI from the To-Path header, insert its URI in front of any other URIs in the From-Path header, and forward the response to the next URI in the To-Path header. The relay sends the request over the best connection that corresponds to the next URI in the To-Path header. If this connection has closed, then the response is silently discarded.
如果To Path头中有其他URI，则中继必须将其URI从To Path头移动，将其URI插入from Path头中任何其他URI的前面，并将响应转发到To Path头中的下一个URI。中继通过与to Path头中的下一个URI对应的最佳连接发送请求。如果此连接已关闭，则响应将自动放弃。
Relays should keep connections open as long as possible. If a connection has not been used in a significant time (more than one hour), it MAY be closed. If the relay runs out of resources and can no longer establish new connections, it SHOULD start closing existing connections. It MAY choose to close the connections based on a least recently used basis.
继电器应尽可能长时间保持连接打开。如果某个连接在相当长的时间内（超过一小时）未使用，则可能会关闭该连接。如果中继耗尽资源，无法再建立新连接，则应开始关闭现有连接。它可以根据最近使用最少的情况选择关闭连接。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 4234 [10].
以下语法规范使用RFC 4234[10]中所述的增广巴科斯诺尔形式（ABNF）。
; This ABNF imports all the definitions in the ABNF of RFC 4975.
; 此ABNF导入RFC 4975 ABNF中的所有定义。
header =/ Expires / Min-Expires / Max-Expires / Use-Path /
WWW-Authenticate / Authorization / Authentication-Info
; this adds to the rule in RFC 4975
header =/ Expires / Min-Expires / Max-Expires / Use-Path /
WWW-Authenticate / Authorization / Authentication-Info
; this adds to the rule in RFC 4975
mAUTH = %x41.55.54.48 ; AUTH in caps
method =/ mAUTH
; this adds to the rule in RFC 4975
mAUTH = %x41.55.54.48 ; AUTH in caps
method =/ mAUTH
; this adds to the rule in RFC 4975
WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP digest-param *("," SP digest-param)
WWW Authenticate=“WWW Authenticate:”SP“Digest”SP Digest param*（“，”SP Digest param）
digest-param = ( realm / nonce / [ opaque ] / [ stale ] / [
algorithm ] / qop-options / [auth-param] )
digest-param = ( realm / nonce / [ opaque ] / [ stale ] / [
algorithm ] / qop-options / [auth-param] )
realm = "realm=" realm-value realm-value = quoted-string
realm=“realm=”realm value realm value=带引号的字符串
auth-param = token "=" ( token / quoted-string )
auth-param = token "=" ( token / quoted-string )
nonce = "nonce=" nonce-value
nonce-value = quoted-string
opaque = "opaque=" quoted-string
stale = "stale=" ( "true" / "false" )
algorithm = "algorithm=" ( "MD5" / token )
qop-options = "qop=" DQUOTE qop-list DQUOTE
qop-list = qop-value *( "," qop-value )
qop-value = "auth" / token
nonce = "nonce=" nonce-value
nonce-value = quoted-string
opaque = "opaque=" quoted-string
stale = "stale=" ( "true" / "false" )
algorithm = "algorithm=" ( "MD5" / token )
qop-options = "qop=" DQUOTE qop-list DQUOTE
qop-list = qop-value *( "," qop-value )
qop-value = "auth" / token
Authorization = "Authorization:" SP credentials
Authorization=“Authorization:”SP凭据
credentials = "Digest" SP digest-response *( "," SP digest-response)
credentials=“Digest”SP摘要响应*（“，”SP摘要响应）
digest-response = ( username / realm / nonce / response / [
algorithm ] / cnonce / [opaque] / message-qop /
[nonce-count] / [auth-param] )
digest-response = ( username / realm / nonce / response / [
algorithm ] / cnonce / [opaque] / message-qop /
[nonce-count] / [auth-param] )
username = "username=" username-value
username-value = quoted-string
message-qop = "qop=" qop-value
cnonce = "cnonce=" cnonce-value
cnonce-value = nonce-value
nonce-count = "nc=" nc-value
nc-value = 8LHEX
response = "response=" request-digest
request-digest = DQUOTE 32LHEX DQUOTE
LHEX = DIGIT / %x61-66 ;lowercase a-f
username = "username=" username-value
username-value = quoted-string
message-qop = "qop=" qop-value
cnonce = "cnonce=" cnonce-value
cnonce-value = nonce-value
nonce-count = "nc=" nc-value
nc-value = 8LHEX
response = "response=" request-digest
request-digest = DQUOTE 32LHEX DQUOTE
LHEX = DIGIT / %x61-66 ;lowercase a-f
Authentication-Info = "Authentication-Info:" SP ainfo
*("," ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce=" nonce-value
response-auth = "rspauth=" response-digest
response-digest = DQUOTE *LHEX DQUOTE
Authentication-Info = "Authentication-Info:" SP ainfo
*("," ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce=" nonce-value
response-auth = "rspauth=" response-digest
response-digest = DQUOTE *LHEX DQUOTE
Expires = "Expires:" SP 1*DIGIT
Min-Expires = "Min-Expires:" SP 1*DIGIT
Max-Expires = "Max-Expires:" SP 1*DIGIT
Expires = "Expires:" SP 1*DIGIT
Min-Expires = "Min-Expires:" SP 1*DIGIT
Max-Expires = "Max-Expires:" SP 1*DIGIT
Use-Path = "Use-Path:" SP MSRP-URI *(SP MSRP-URI)
Use-Path = "Use-Path:" SP MSRP-URI *(SP MSRP-URI)
When resolving an MSRP URI that contains an explicit port number, an MSRP node follows the rules in Section 6 of the MSRP base specification. MSRP URIs exchanged in SDP and in To-Path and From-Path headers in non-AUTH requests MUST have an explicit port number. (The only message in this specification that can have an MSRP URI without an explicit port number is in the To-Path header in an AUTH request.) Similarly, if the authority component of an msrps: URI contains an IPv4 address or an IPv6 reference, a port number MUST be present.
解析包含显式端口号的MSRP URI时，MSRP节点遵循MSRP基本规范第6节中的规则。在非身份验证请求的SDP和To Path以及From Path头中交换的MSRP URI必须具有明确的端口号。（本规范中唯一一条没有显式端口号的MSRP URI消息位于身份验证请求的To Path头中。）类似地，如果msrps:URI的授权组件包含IPv4地址或IPv6引用，则必须存在端口号。
The following rules allow MSRP clients to discover MSRP relays more easily in AUTH requests. If the authority component contains a domain name and an explicit port number is provided, attempt to look up a valid address record (A or AAAA) for the domain name. Connect using TLS over the default transport (TCP) with the provided port number.
以下规则允许MSRP客户端在身份验证请求中更容易地发现MSRP中继。如果授权组件包含域名并且提供了显式端口号，请尝试查找该域名的有效地址记录（a或AAAA）。使用TLS通过提供端口号的默认传输（TCP）进行连接。
If a domain name is provided but no port number, perform a DNS SRV [4] lookup for the '_msrps' service and '_tcp' transport at the domain name, and follow the Service Record (SRV) selection algorithm defined in that specification to select the entry. (An '_msrp' service is not defined, since AUTH requests are only sent over TLS.) If no SRVs are found, try an address lookup (A or AAAA) for the domain name. Connect using TLS over the default transport (TCP) with the default port number (2855). Note that AUTH requests MUST only be sent over a TLS-protected channel. An SRV lookup in the example.com domain might return:
如果提供了域名但没有端口号，请在域名处对“_msrps”服务和“_tcp”传输执行DNS SRV[4]查找，并按照该规范中定义的服务记录（SRV）选择算法选择条目。（未定义“_msrp”服务，因为身份验证请求仅通过TLS发送。）如果未找到SRV，请尝试域名的地址查找（A或AAAA）。使用TLS通过默认端口号（2855）的默认传输（TCP）进行连接。请注意，身份验证请求只能通过受TLS保护的通道发送。example.com域中的SRV查找可能返回：
;; in example.com. Pri Wght Port Target _msrps._tcp IN SRV 0 1 9000 server1.example.com. _msrps._tcp IN SRV 0 2 9000 server2.example.com.
;; 在example.com。Pri Wght端口目标\u msrps.\u SRV 0 1 9000 server1.example.com中的tcp_msrps.\u SRV 0 2 9000 server2.example.com中的tcp。
If implementing a relay farm, it is RECOMMENDED that each member of the relay farm have an SRV entry. If any members of the farm have multiple IP addresses (for example, an IPv4 and an IPv6 address), each of these addresses SHOULD be registered in DNS as separate A or AAAA records corresponding to a single target.
如果实施中继场，建议中继场的每个成员都有一个SRV条目。如果场的任何成员具有多个IP地址（例如，IPv4和IPv6地址），则这些地址中的每一个都应在DNS中注册为对应于单个目标的单独A或AAAA记录。
This section first describes the security mechanisms available for use in MSRP. Then the threat model is presented. Finally, we list implementation requirements related to security.
本节首先介绍MSRP中可用的安全机制。然后给出了威胁模型。最后，我们列出了与安全性相关的实现需求。
AUTH requests MUST be authenticated. The authentication mechanism described in this specification uses HTTP Digest authentication. HTTP Digest authentication is performed as described in RFC 2617 [1], with the following restrictions and modifications:
身份验证请求必须经过身份验证。本规范中描述的身份验证机制使用HTTP摘要身份验证。HTTP摘要身份验证按照RFC 2617[1]中的描述执行，但有以下限制和修改：
o Clients MUST NOT attempt to use Basic authentication, and relays MUST NOT request or accept Basic authentication.
o 客户端不得尝试使用基本身份验证，中继不得请求或接受基本身份验证。
o The use of a qop value of auth-int makes no sense for MSRP. Integrity protection is provided by the use of TLS. Consequently, MSRP relays MUST NOT indicate a qop of auth-int in a challenge.
o 使用qop值auth int对MSRP没有任何意义。通过使用TLS提供完整性保护。因此，MSRP中继不得在质询中指示auth int的qop。
o The interaction between the MD5-sess algorithm and the nextnonce mechanism is underspecified in RFC 2617 [1]; consequently, MSRP relays MUST NOT send challenges indicating the MD5-sess algorithm.
o RFC 2617[1]中未明确说明MD5 sess算法与NextOnce机制之间的相互作用；因此，MSRP继电器不得发送指示MD5 sess算法的挑战。
o Clients SHOULD consider the protection space within a realm to be scoped to the authority portion of the URI, without regard to the contents of the path portion of the URI. Accordingly, relays
o 客户端应该考虑域内的保护空间被限制到URI的权限部分，而不考虑URI的路径部分的内容。因此，继电器
SHOULD NOT send the "domain" parameter on the "WWW-Authenticate" header, and clients MUST ignore it if present.
不应在“WWW-Authenticate”头上发送“domain”参数，客户端必须忽略它（如果存在）。
o Clients and relays MUST include a qop parameter in all "WWW-Authenticate" and "Authorization" headers. Note that the value of the qop parameter in a "WWW-Authenticate" header is quoted, but the value of the qop parameter in an "Authorization" header or "Authentication-Info" header is not quoted.
o 客户端和中继必须在所有“WWW认证”和“授权”头中包含qop参数。注意，引用了“WWW-Authenticate”头中的qop参数值，但没有引用“Authentication”头或“Authentication-Info”头中的qop参数值。
o Clients MUST send cnonce and nonce-count parameters in all "Authorization" headers.
o 客户端必须在所有“授权”头中发送cnonce和nonce count参数。
o The request-URI to be used in calculating H(A2) is the rightmost URI in the To-Path header.
o 用于计算H（A2）的请求URI是to路径头中最右边的URI。
o Relays MUST include rspauth, cnonce, nc, and qop parameters in a "Authentication-Info" header for all "200 OK" responses to an AUTH request.
o 对于对身份验证请求的所有“200 OK”响应，中继器必须在“身份验证信息”标题中包含rspauth、cnonce、nc和qop参数。
Note that the BNF in RFC 2617 has a number of errors. In particular, the value of the uri parameter MUST be in quotes; further, the parameters in the Authentication-Info header MUST be separated by commas. The BNF in this document is correct, as are the examples in RFC 2617 [1].
请注意，RFC2617中的BNF有许多错误。特别是，uri参数的值必须用引号括起来；此外，身份验证信息标头中的参数必须用逗号分隔。本文件中的BNF是正确的，RFC 2617[1]中的示例也是正确的。
The use of the nextnonce and nc parameters is supported as described in RFC 2617 [1], which provides guidance on how and when they should be used. As a slight modification to the guidance provided in RFC 2617, implementors of relays should note that AUTH requests cannot be pipelined; consequently, there is no detrimental impact on throughput when relays use the nextnonce mechanism.
如RFC 2617[1]所述，支持使用NextOnce和nc参数，这为如何以及何时使用这些参数提供了指导。作为对RFC 2617中提供的指南的轻微修改，中继的实施者应注意，身份验证请求不能管道化；因此，当中继使用nextnonce机制时，不会对吞吐量产生不利影响。
See Section 5.1 for further information on the procedures for client authentication.
有关客户端身份验证程序的更多信息，请参见第5.1节。
TLS is used to authenticate relays to senders and to provide integrity and confidentiality for the headers being transported. MSRP clients and relays MUST implement TLS. Clients MUST send the TLS ClientExtendedHello extended hello information for server name indication as described in RFC 4366 [5]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [6] MUST be supported (other cipher-suites MAY also be supported). A relay MUST act as a TLS server and present a certificate with its identity in the SubjectAltName using the choice type of dnsName. Relay-to-relay connections MUST use TLS with mutual authentication. Client-to-relay communications MUST use TLS for AUTH requests and responses.
TLS用于向发送方验证中继，并为传输的报头提供完整性和机密性。MSRP客户端和中继必须实现TLS。客户机必须发送TLS ClientExtendedHello扩展hello信息以指示服务器名称，如RFC 4366[5]所述。必须支持TLS_RSA_和_AES_128_CBC_SHA[6]的TLS密码套件（也可以支持其他密码套件）。中继必须充当TLS服务器，并使用dnsName的选择类型在SubjectAltName中提供其标识的证书。中继到中继连接必须使用具有相互身份验证的TLS。客户端到中继通信必须使用TLS进行身份验证请求和响应。
The SubjectAltName in the certificate received from a relay MUST match the hostname part of the URI, and the certificate MUST be valid according to RFC 3280 [12], including having a date that is valid and being signed by an acceptable certification authority. After validating that such is the case, the device that initiated the TLS connection can assume that it has connected to the correct relay.
从中继接收的证书中的SubjectAltName必须与URI的主机名部分匹配，并且根据RFC 3280[12]，证书必须有效，包括具有有效日期并由可接受的证书颁发机构签名。在确认情况属实后，启动TLS连接的设备可以假定其已连接到正确的继电器。
This document does not define procedures for using mutual authentication between an MSRP client and an MSRP relay. Authentication of clients is handled using the AUTH method via the procedures described in Section 5.1 and Section 6.3. Other specifications may define the use of TLS mutual authentication for the purpose of authenticating users associated with MSRP clients. Unless operating under such other specifications, MSRP clients SHOULD present an empty certificate list (if one is requested by the MSRP relay), and MSRP relays SHOULD ignore any certificates presented by the client.
本文档未定义在MSRP客户端和MSRP中继之间使用相互身份验证的过程。通过第5.1节和第6.3节中描述的程序，使用AUTH方法处理客户端的身份验证。其他规范可定义TLS相互认证的使用，以认证与MSRP客户端相关联的用户。除非按照此类其他规范操作，否则MSRP客户机应提供空证书列表（如果MSRP中继请求提供），MSRP中继机应忽略客户机提供的任何证书。
This behavior is defined specifically to allow forward-compatibility with specifications that define the use of TLS for client authentication.
此行为专门定义为允许与定义使用TLS进行客户端身份验证的规范向前兼容。
Note: When relays are involved in a session, TCP without TLS is only used when a user that does not use relays connects directly to the relay of a user that is using relays. In this case, the client has no way to authenticate the relay other than to use the URIs that form a shared secret in the same way those URIs are used when no relays are involved.
注意：当会话中涉及中继时，只有当不使用中继的用户直接连接到使用中继的用户的中继时，才使用不带TLS的TCP。在这种情况下，客户机无法对中继进行身份验证，只能使用构成共享机密的URI，就像在不涉及中继时使用这些URI一样。
This section discusses the threat model and the broad mechanism that needs to be in place to secure the protocol. The next section describes the details of how the protocol mechanism meets the broad requirements.
本节讨论威胁模型和保护协议所需的广泛机制。下一节将详细介绍协议机制如何满足广泛需求。
MSRP allows two peer-to-peer clients to exchange messages. Each peer can select a set of relays to perform certain policy operations for them. This combined set of relays is referred to as the route set. A channel outside of MSRP always needs to exist, such as out-of-band provisioning or an explicit rendezvous protocol such as SIP, that can securely negotiate setting up the MSRP session and communicate the route set to both clients. A client may trust a relay with certain types of routing and policy decisions, but it might or might not trust the relay with all the contents of the session. For example, a relay being trusted to look for viruses would probably need to be allowed to see all the contents of the session. A relay that helped deal with traversal of the ISP's Network Address Translator (NAT)
MSRP允许两个对等客户端交换消息。每个对等方都可以选择一组中继器来执行特定的策略操作。该继电器组合组称为路由组。MSRP之外的通道始终需要存在，例如带外供应或显式集合协议（如SIP），该协议可以安全地协商设置MSRP会话并将路由集传递给两个客户端。客户机可以信任具有某些类型的路由和策略决策的中继，但是它可能信任也可能不信任具有会话所有内容的中继。例如，可能需要允许受信任的用于查找病毒的中继查看会话的所有内容。帮助处理ISP网络地址转换器（NAT）遍历的中继
would likely not be trusted with the contents of the session but would be trusted to correctly forward messages.
会话的内容可能不受信任，但会被信任以正确转发消息。
Clients implicitly trust the relays through which they send and receive messages to honor the routing indicated in those messages, within the constraints of the MSRP protocol. Clients also need to trust that the relays they use do not insert new messages on their behalf or modify messages sent to or by the clients. It is worth noting that some relays are in a position to cause a client to misroute a message by maliciously modifying a Use-Path returned by a relay further down the chain. However, this is not an additional security threat because these same relays can also decide to misroute a message in the first place. If the relay is trusted to route messages, it is reasonable to trust it not to tamper with the Use-Path header. If the relay cannot be trusted to route messages, then it cannot be used.
在MSRP协议的约束范围内，客户端隐式地信任它们发送和接收消息所通过的中继，以遵守这些消息中指示的路由。客户机还需要相信，他们使用的中继不会代表他们插入新消息，也不会修改发送给客户机或由客户机发送的消息。值得注意的是，某些中继可能会通过恶意修改中继返回的使用路径而导致客户端错误路由消息。然而，这不是一个额外的安全威胁，因为这些相同的中继也可以在第一时间决定错误路由消息。如果信任该中继路由消息，则有理由相信它不会篡改Use Path头。如果无法信任中继路由消息，则无法使用它。
Under certain circumstances, relays need to trust other relays not to modify information between them and the client they represent. For example, if a client is operating through Relay A to get to Relay B, and Relay B is logging messages sent by the client, Relay B may be required to authenticate that the messages they logged originate with the client, and have not been modified or forged by Relay A. This can be done by having the client sign the message.
在某些情况下，中继需要信任其他中继，而不是修改它们与它们所代表的客户机之间的信息。例如，如果客户机通过中继器a运行以到达中继器B，并且中继器B正在记录客户机发送的消息，则中继器B可能需要验证其记录的消息是否源自客户机，并且中继器a未对其进行修改或伪造。这可以通过让客户机在消息上签名来完成。
Clients need to be able to authenticate that the relay they are communicating with is the one they trust. Likewise, relays need to be able to authenticate that the client is the one they are authorized to forward information to. Clients need the option of ensuring that information between the relay and the client is integrity protected and confidential to elements other than the relays and clients. To simplify the number of options, traffic between relays is always integrity protected and encrypted regardless of whether or not the client requests it. There is no way for the clients to tell the relays what strength of cryptographic mechanisms to use between relays other than to have the clients choose relays that are administered to require an adequate level of security.
客户端需要能够验证他们正在与之通信的中继是他们信任的中继。同样，中继器需要能够验证客户机是否是他们被授权转发信息的客户机。客户需要选择确保继电器和客户之间的信息受到完整性保护，并对继电器和客户以外的元件保密。为了简化选项的数量，中继之间的通信始终受到完整性保护和加密，而不管客户端是否请求它。客户机无法告诉中继器在中继器之间使用何种加密机制，只能让客户机选择需要适当安全级别的管理中继器。
The system also needs to stop messages from being directed to relays that are not supposed to see them. To keep the relays from being used in Denial of Service (DoS) attacks, the relays never forward messages unless they have a trust relationship with either the client sending or the client receiving the message; further, they only forward a message if it is coming from or going to the client with which they have the trust relationship. If a relay has a trust relationship with the client that is the destination of the message, it should not send the message anywhere except to the client that is the destination.
系统还需要阻止消息被定向到不应该看到它们的继电器。为了防止中继器被用于拒绝服务（DoS）攻击，中继器从不转发消息，除非它们与发送或接收消息的客户端具有信任关系；此外，他们仅在消息来自或前往与他们有信任关系的客户机时转发消息。如果中继与作为消息目的地的客户端具有信任关系，则它不应将消息发送到除作为目的地的客户端之外的任何位置。
Some terminology used in this discussion: SClient is the client sending a message and RClient is the client receiving a message. SRelay is a relay the sender trusts and RRelay is a relay the receiver trusts. The message will go from SClient to SRelay1 to SRelay2 to RRelay2 to RRelay1 to RClient.
本讨论中使用的一些术语：SClient是发送消息的客户端，RClient是接收消息的客户端。SRelay是发送方信任的中继，而RRelay是接收方信任的中继。消息将从SClient到SRelay1到SRelay2再到RRelay2再到RRelay1再到RClient。
Confidentiality and privacy from elements not in the route set is provided by using TLS on all the transports. Relays always use TLS. A client can use unprotected TCP for peer-to-peer MSRP, but any time a client communicates with its relay, it MUST use TLS.
通过在所有传输上使用TLS，可以提供来自不在路由集中的元素的机密性和隐私性。继电器始终使用TLS。客户端可以对对等MSRP使用不受保护的TCP，但任何时候客户端与其中继通信时，都必须使用TLS。
The relays authenticate to the clients using TLS (but don't have to do mutual TLS). Further, the use of the rspauth parameter in the Authentication-Info header provides limited authentication of relays to which the client is not directly connected. The clients authenticate to the relays using HTTP Digest authentication. Relays authenticate to each other using TLS mutual authentication.
中继使用TLS向客户端进行身份验证（但不必执行相互TLS）。此外，在认证信息报头中使用rspauth参数提供了对客户端未直接连接到的中继的有限认证。客户端使用HTTP摘要身份验证对中继进行身份验证。中继使用TLS相互身份验证相互进行身份验证。
By using Secure/Multipurpose Internet Mail Extensions (S/MIME) [3] encryption, the clients can protect their actual message contents so that the relays cannot see the contents. End-to-end signing is also possible with S/MIME.
通过使用安全/多用途Internet邮件扩展（S/MIME）[3]加密，客户端可以保护其实际邮件内容，以便中继无法看到内容。使用S/MIME也可以进行端到端签名。
The complex part is making sure that relays cannot successfully be instructed to send messages to a place where they should not. This is done by having the client authenticate to the relay and having the relay return a token. Messages that contain this token can be relayed if they come from the client that got the token or if they are being forwarded towards the client that got the token. The tokens are the URIs that the relay places in the Use-Path header. The tokens contain random material (defined in Section 6.3) so that they are not guessable by attackers. The tokens need to be protected so they are only ever seen by elements in the route set or other elements that at least one of the parties trusts. If some third party discovers the token that RRelay2 uses to forward messages to RClient, then that third party can send as many messages as they want to RRelay2 and it will forward them to RClient. The third party cannot cause them to be forwarded anywhere except to RClient, eliminating the open relay problems. SRelay1 will not forward the message unless it contains a valid token.
复杂的部分是确保继电器不能成功地被指示将消息发送到不应该发送的地方。这是通过让客户端向中继进行身份验证并让中继返回令牌来完成的。如果包含该令牌的消息来自获得该令牌的客户端，或者如果它们正向获得该令牌的客户端转发，则可以中继这些消息。令牌是中继放在使用路径头中的URI。令牌包含随机材料（定义见第6.3节），因此攻击者无法猜测。令牌需要受到保护，以便它们只被路由集中的元素或至少一方信任的其他元素看到。如果某第三方发现RRelay2用于将消息转发给RClient的令牌，则该第三方可以发送任意数量的消息，并将其转发给RClient。第三方不能将它们转发到RClient之外的任何地方，从而消除了开路继电器问题。SRelay1将不会转发消息，除非它包含有效的令牌。
When SClient goes to get a token from SRelay2, this request is relayed through SRelay1. SRelay2 authenticates that it really is SClient requesting the token, but it generates a token that is only valid for forwarding messages to or from SRelay1. SRelay2 knows it is connected to SRelay1 because of the mutual TLS.
当SClient从SRelay2获取令牌时，该请求通过SRelay1中继。SRelay2验证它确实是SClient请求令牌，但它生成的令牌仅对向SRelay1转发消息或从SRelay1转发消息有效。由于相互TLS，SRelay2知道它已连接到SRelay1。
The tokens are carried in the resource portion of the MSRP URIs. The length of time the tokens are valid for is negotiated using the Expire header in the AUTH request. Clients need to re-negotiate the tokens using a new offer/answer [15] exchange (e.g., a SIP re-invite) before the tokens expire.
令牌携带在MSRP URI的资源部分。令牌的有效时间长度是使用AUTH请求中的Expire头协商的。在令牌到期之前，客户需要使用新的要约/应答[15]交换（例如SIP重新邀请）重新协商令牌。
Note that this scheme relies on relays as trusted nodes, acting on behalf of the users authenticated to them. There is no security mechanism to prevent relays on the path from inserting forged messages, manipulating the contents of messages, sending messages in a session to a party other than that specified by the sender, or from copying them to a third party. However, the one-to-one binding between session identifiers and sessions helps mitigate any damage that can be caused by rogue relays by limiting the destinations to which forged or modified messages can be sent to the two parties involved in the session, and only for the duration of the session. Additionally, the use of S/MIME encryption can be employed to limit the utility of redirecting messages. Finally, clients can employ S/MIME signatures to guarantee the authenticity of messages they send, making it possible under some circumstances to detect relay manipulation or the forging of messages.
请注意，此方案依赖于作为可信节点的中继，代表经过身份验证的用户行事。没有任何安全机制可防止路径上的中继插入伪造消息、操纵消息内容、在会话中将消息发送给发送方指定以外的另一方或将消息复制给第三方。但是，会话标识符和会话之间的一对一绑定通过限制伪造或修改的消息可以发送到会话中涉及的双方的目的地，并且仅在会话期间，有助于减轻恶意中继可能造成的任何损害。此外，可以使用S/MIME加密来限制重定向消息的效用。最后，客户端可以使用S/MIME签名来保证他们发送的消息的真实性，从而在某些情况下可以检测到中继操作或消息伪造。
Clients are not the only actors in the network who need to trust relays to act in non-malicious ways. If a relay does not have a direct TLS connection with the client on whose behalf it is acting (i.e. There are one or more intervening relays), it is at the mercy of any such intervening relays to accurately transmit the messages sent to and from the client. If a stronger guarantee of the authentic origin of a message is necessary (e.g. The relay is performing logging of messages as part of a legal requirement), then users of that relay can be instructed by their administrators to use detached S/MIME signatures on all messages sent by their client. The relay can enforce such a policy by returning a 415 response to any SEND requests using a top-level MIME type other than "multipart/ signed". Such relays may choose to make policy decisions (such as terminating sessions and/or suspending user authorization) if such signatures fail to match the contents of the message.
客户端不是网络中需要信任中继以非恶意方式进行操作的唯一参与者。如果中继器与其代表的客户机没有直接TLS连接（即有一个或多个中间中继器），则由任何此类中间中继器负责准确传输发送至客户机和从客户机发送的消息。如果需要更有力地保证消息的真实来源（例如，作为法律要求的一部分，中继正在执行消息日志记录），则其管理员可以指示该中继的用户在其客户端发送的所有消息上使用分离的S/MIME签名。中继可以通过使用除“多部分/签名”之外的顶级MIME类型对任何发送请求返回415响应来实施这样的策略。如果此类签名与消息内容不匹配，则此类中继可选择作出策略决策（例如终止会话和/或暂停用户授权）。
This specification defines a new MSRP method, to be added to the Methods sub-registry under the MSRP Parameters registry: AUTH. See Section 5.1 for details on the AUTH method.
本规范定义了一个新的MSRP方法，该方法将添加到MSRP参数注册表下的方法子注册表：AUTH。有关AUTH方法的详细信息，请参见第5.1节。
This specification defines several new MSRP header fields, to be added to the header-field sub-registry under the MSRP Parameters registry:
本规范定义了几个新的MSRP标题字段，这些字段将添加到MSRP参数注册表下的标题字段子注册表中：
o Expires o Min-Expires o Max-Expires o Use-Path o WWW-Authenticate o Authorization o Authentication-Info
o 过期o最小过期o最大过期o使用路径o WWW验证o授权o验证信息
This specification defines one new MSRP status code, to be added to the Status-Code sub-registry under the MSRP Parameters registry:
本规范定义了一个新的MSRP状态代码，将添加到MSRP参数注册表下的状态代码子注册表中：
The 401 response indicates that an AUTH request contained no credentials, an expired nonce value, or invalid credentials. The response includes a "WWW-Authenticate" header containing a challenge (among other fields); see Section 9.1 for further details. The default response phrase for this response is "Unauthorized".
401响应表示身份验证请求不包含凭据、过期的nonce值或无效凭据。响应包括包含质询的“WWW-Authenticate”报头（除其他字段外）；详见第9.1节。此响应的默认响应短语为“未经授权”。
The following section shows an example SDP that could occur in a SIP message to set up an MSRP session between Alice and Bob where Bob uses a relay. Alice makes an offer with a path to Alice.
下一节显示了一个示例SDP，它可能出现在SIP消息中，用于在Alice和Bob之间建立MSRP会话，Bob在其中使用中继。爱丽丝提出了一条通往爱丽丝的路。
c=IN IP4 a.example.com
m=message 1234 TCP/MSRP *
a=accept-types: message/cpim text/plain text/html
a=path:msrp://a.example.com:1234/agic456;tcp
c=IN IP4 a.example.com
m=message 1234 TCP/MSRP *
a=accept-types: message/cpim text/plain text/html
a=path:msrp://a.example.com:1234/agic456;tcp
In this offer, Alice wishes to receive MSRP messages at a.example.com. She wants to use TCP as the transport for the MSRP session. She can accept message/cpim, text/plain, and text/html message bodies in SEND requests. She does not need a relay to set up the MSRP session.
在此优惠中，Alice希望通过a.example.com接收MSRP消息。她希望使用TCP作为MSRP会话的传输。她可以接受SEND请求中的message/cpim、text/plain和text/html消息体。她不需要中继来设置MSRP会话。
To this offer, Bob's answer could look like:
对于这个提议，Bob的答案可能是：
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types: message/cpim text/plain
a=path:msrps://relay.example.com:9000/hjdhfha;tcp \
msrps://bob.example.com:1234/fuige;tcp
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types: message/cpim text/plain
a=path:msrps://relay.example.com:9000/hjdhfha;tcp \
msrps://bob.example.com:1234/fuige;tcp
Here Bob wishes to receive the MSRP messages at bob.example.com. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice. He wishes to use a relay called relay.example.com for the MSRP session.
这里，Bob希望通过Bob.example.com接收MSRP消息。他只能接受SEND请求中的message/cpim和text/plain消息体，并拒绝了Alice提供的text/html内容。他希望在MSRP会话中使用名为relay.example.com的中继。
Many thanks to Avshalom Houri, Hisham Khartabil, Robert Sparks, Miguel Garcia, Hans Persson, and Orit Levin, who provided detailed proofreading and helpful text. Thanks to the following members of the SIMPLE WG for spirited discussions on session mode: Chris Boulton, Ben Campbell, Juhee Garg, Paul Kyzivat, Allison Mankin, Aki Niemi, Pekka Pessi, Jon Peterson, Brian Rosen, Jonathan Rosenberg, and Dean Willis.
非常感谢Avshalom Houri、Hisham Khartabil、Robert Sparks、Miguel Garcia、Hans Persson和Orit Levin，他们提供了详细的校对和有用的文本。感谢简单工作组的以下成员就会议模式进行了积极的讨论：克里斯·博尔顿、本·坎贝尔、朱希·加格、保罗·基齐瓦特、埃里森·曼金、阿基·尼米、佩卡·佩西、乔恩·彼得森、布赖恩·罗森、乔纳森·罗森博格和迪安·威利斯。
[1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[1] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[2] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[3] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[4] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[5] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[6] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[8] 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.
[8] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[10] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[11] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[11] Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[12] 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.
[12] Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[13] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[14] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[15] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
This text is not necessary in order to implement MSRP in an interoperable way, but is still useful as an implementation discussion for the community. It is purely an implementation detail.
为了以可互操作的方式实现MSRP，本文不是必需的，但作为社区的实现讨论仍然有用。这纯粹是一个实现细节。
Note: The idea has been proposed of having a relay return a base URI that the client can use to construct more URIs, but this allows third parties that have had a session with the client to know URIs that the relay will use for forwarding after the session with the third party has ended. Effectively, this reveals the secret URIs to third parties, which compromises the security of the solution, so this approach is not used.
注意：有人提议让中继返回一个基本URI，客户端可以使用它来构造更多的URI，但这允许与客户端进行会话的第三方知道中继将在与第三方的会话结束后用于转发的URI。实际上，这会向第三方泄露机密URI，这会损害解决方案的安全性，因此不使用这种方法。
An alternative to this approach causes the relays to return a URI that is divided into an index portion and a secret portion. The client can encrypt its identifier and its own opaque data with the secret portion, and concatenate this with the index portion to create a plurality of valid URIs. When the relay receives one of these URIs, it could use the index to look up the appropriate secret, decrypt the client portion, and verify that it contains the client identifier. The relay can then forward the request. The client does not need to send an AUTH request for each URI it uses. This is an implementation detail that is out of the scope of this document.
这种方法的一种替代方法是使中继器返回一个URI，该URI分为索引部分和秘密部分。客户机可以用秘密部分加密其标识符及其自身的不透明数据，并将其与索引部分连接以创建多个有效uri。当中继接收到这些URI中的一个时，它可以使用索引查找适当的机密，解密客户端部分，并验证它是否包含客户端标识符。然后，继电器可以转发请求。客户端不需要为其使用的每个URI发送身份验证请求。这是一个不在本文档范围内的实施细节。
It is possible to implement forwarding requirements in a farm without the relay saving any state. One possible implementation that a relay might use is described in the rest of this section. When a relay starts up, it could pick a cryptographically random 128-bit password (K) and 128-bit initialization vector (IV). If the relay was actually a farm of servers with the same DNS name, all the machines in the farm would need to share the same K. When an AUTH request is received, the relay forms a string that contains the expiry time of the URI, an indication if the previous hop was mutual TLS authenticated or not, and if it was, the name of the previous hop, and if it was not, the identifier for the connection that received the AUTH request. This string would be padded by appending a byte with the value 0x80 then adding zero or more bytes with the value of 0x00 until the string length is a multiple of 16 bytes long. A new random IV would be selected (it needs to change because it forms the salt) and the padded string would be encrypted using AES-CBC with a key of K. The IV and encrypted data and an SPI (security parameter index) that changes each time K changes would be base 64 encoded and form the resource portion of the request URI. The SPI allows the key to be changed and for the system to know which K should be used. Later when the relay receives this URI, it could decrypt it and check that the current time was before the expiry time and check that the message was coming from or going to the connection or location
可以在不保存任何状态的中继的情况下在服务器场中实现转发要求。中继可能使用的一种可能的实现在本节的其余部分中描述。当中继器启动时，它可以选择加密随机的128位密码（K）和128位初始化向量（IV）。如果中继实际上是具有相同DNS名称的服务器场，则场中的所有计算机都需要共享相同的K。当接收到身份验证请求时，中继形成一个字符串，其中包含URI的过期时间，指示前一个跃点是否经过相互TLS身份验证，如果是，则指示前一个跃点的名称，如果不是，则为接收身份验证请求的连接的标识符。该字符串将通过添加一个值为0x80的字节，然后添加零个或多个值为0x00的字节来填充，直到字符串长度为16字节长的倍数。将选择一个新的随机IV（它需要更改，因为它形成了salt），填充字符串将使用密钥为K的AES-CBC进行加密。IV和加密数据以及每次K更改时都会更改的SPI（安全参数索引）将以64进制编码，并形成请求URI的资源部分。SPI允许更改密钥并让系统知道应该使用哪个K。稍后，当中继接收到此URI时，它可以对其进行解密，检查当前时间是否早于到期时间，并检查消息是否来自或前往连接或位置
specified in the URI. Integrity protection is not required because it is extremely unlikely that random data that was decrypted would result in a valid location that was the same as the one the message was routing to or from. When implementing something like this, implementors should be careful not to use a scheme like EBE that would allows portions of encrypted tokens to be cut and pasted into other URIs.
在URI中指定。不需要完整性保护，因为解密的随机数据不太可能产生与消息路由到或来自的位置相同的有效位置。当实现类似的东西时，实现者应该小心不要使用像EBE这样的方案，该方案允许将加密令牌的一部分剪切并粘贴到其他URI中。
Authors' Addresses
作者地址
Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems，Inc.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
Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
Rohan Mahy Plantronics美国加利福尼亚州圣克鲁斯Encincal街345号，邮编95060
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 USA
Adam Roach Estacado Systems美国德克萨斯州达拉斯坎贝尔路17210号250室，邮编75252
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
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.