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)
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
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.
バルクメッセージングのための別のプロトコルを使用することが所望されるシナリオは多数あります。具体的には、メディアのセッションとして一連のメッセージを処理する必要があるだけで、他のメディアタイプと同様に、[8] SIPを使用して開始。メッセージセッションリレープロトコル（MSRP）[11]は、直接無媒体を有する2つのエンドシステムとの間でメッセージのセッションを伝達するために使用されます。 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リレーは複数のセッション、受信者、および送信者のメッセージを伝えるために、1つまたは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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
チャンク：SEND要求で配信完全なメッセージの一部。
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接続を開くことができるクライアントは、相互に直接通信することができます。ポリシー上の理由仲介を使用する必要があり、ファイアウォールや背後にあるクライアントは、リレーのサービスを使用することができます。各クライアントは通信のその側面に1個のまたは複数のリレーの援助を入隊する責任があります。
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 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接続を開く認証、およびmsrpsを取得することにより動作：URI（リレー）からクライアントが後でメッセージを受信するためにピアに提供できること。これを行うためのいくつかのステップがあります。まず、クライアントは、その第1のリレーへのTLS接続を開き、証明書の名前は、接続しようとされているリレーの名前と一致することを確認します。そのような検証は、セクション9.2で定義された手順に従って行われます。それが適切なホストに接続していることを確認した後、クライアントは適切な認証資格情報を含むAUTH要求を使用してリレーに自身を認証します。成功したAUTH応答では、リレーは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.
クライアントは、ショートメッセージを送りたいとき、彼らはメッセージの内容全体でSEND要求を出します。いずれかのリレーが必要な場合、それらはのパスへのヘッダに含まれています。 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.
要求は、それらがホップバイホップ形でエンドツーエンドの形で認められているかを示すヘッダーが含まれて送信されます。デフォルトでは、メッセージがホップバイホップを認めている送信することです。 （SEND要求を受信する各リレーは、次の中継または最終ターゲットにコンテンツを転送する前に、要求の受信を肯定応答する。）他のすべての要求は、エンドツーエンドで認められています。
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-Pathヘッダの微妙な意味論の導入とより関連するようになるから、パスヘッダー付き。要求と応答の両方でのパスへの要求または応答の最終的な目標に到達するために訪問する必要があるURIのリストです。以下からのパス要求または応答の元の送信者に戻って取得する方法を示しているURIのリストです。これらのヘッダはからと応答へのリクエストから「スワップ」ないSIPヘッダで、異なります。 （時々要求に直接仲介から送信されることに注意してください。）
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-パスヘッダからそのアドレスを削除してから、パスヘッダの最初のURIとしてそれを挿入します。アリスからボブへのパスは、リレーA及びBを介している場合はBが要求を受信した場合、例えば、それは、次のようになりパスヘッダーを含んでいます。 （MSRPはライン折りたたみを許可しないことに注意してください。Aは、「\」の例による、この文書の行の長さの制限により、行の継続を示しています。バックスラッシュも余分な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
//Bob.example.com/bob;からパスTCP：：;：msrps：TCPの\のmsrps //B.example.com/bbbへのパス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-パス：msrps：//Bob.example.com/bob;からパスTCP：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.
SEND要求に対する肯定応答の送信が成功-レポートと失敗、レポートヘッダによって制御され、ベースMSRPプロトコルの場合と同じように動作しています。リレーは、SEND要求を受信すると失敗、報告書は「はい」に設定されている場合、それは前のホップタイマーを実行していると、リレーは、要求に対する応答を送信する必要があることを意味します。最終的な応答がエラーを伝える場合は、前のホップは、エラーレポートを作成し、メッセージの元の送信者に返送する責任があります。前のホップが、それはもはや要求する責任があることを知っているように、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 ----------| | |
| | | |
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.)
SENDとREPORTメッセージはへのパスからパスヘッダを説明するために以下に示します。 （そのMSRPがライン折りたたみを許可していません。Aは、「\」の例ではどちらもバックスラッシュ。これによる文書の行の長さの制限に行継続を示し、また、余分な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
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 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$
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
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
msrps：//b.example.net：200 OKのパスへのxght6 MSRP 9000 / aeiug; TCPからのパス：msrps：//bob.example.net：8145 / FOO; TCPメッセージ-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://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$
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.
大規模なコンテンツを送信する場合、クライアントは小さな断片にメッセージを分割することができます。各SEND要求は完全なメッセージの一部のみが含まれる可能性があります。アリスがボブに呼ばれる4-GBのファイルを送信するときにたとえば、「file.mpeg」、彼女は完全なメッセージの一部といくつかのSEND要求ごとに送信します。リレーは途中でメッセージの断片を再梱包することができます。完全なメッセージの個々の部分は、最終的な宛先クライアントに到着するように、受信クライアントは、必要に応じて配信状況を示すレポート・リクエストを送信することができます。
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 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.
MSRPノードは、複数のSEND要求における完全なメッセージの個々の部分を送信することができます。リレーはチャンクを受信すると、彼らは再組み立てできるか、彼らは順番にその結果チャンクを再送する限り、それらを再断片化します。 （レシーバはまだしかし、アウトオブオーダーチャンクを受け取ることを準備する必要があります。）送信者は、一度チャンクまたは完全なメッセージが宛先クライアントに到着し、先がお送りします「はい」に成功、レポートヘッダーを設定している場合チャンクは、エンドツーエンドに到着したことを示すREPORT要求。この要求は、送信要求の逆の経路に沿って戻って移動します。すべてのホップに沿って認められる可能SEND要求とは異なり、REPORT要求は認めされることはありません。
The following example shows a message being re-chunked through two relays:
次の例では、2つのリレーを介して再チャンク化されたメッセージを示しています。
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.
1が必要な場合、クライアントからクライアントへの通信では、メッセージの送信者は、一般的に（TLSの有無にかかわらず）、新しいTCP接続をオープンします。リレーは、最初に既存の接続を再利用し、そのようなSENDやREPORTなどの要求を実現するために（通常は他のリレーに）新しい接続を開くことができます。応答は唯一の既存の接続を介して送信することができます。
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]に記載されているようです。リレーを含むMSRPセッションのSDP交換の例はセクション11に示されています。
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を取得するためにAUTHメッセージを使用します。
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.
クライアントは、リレーを使用したい場合は、それがリレーにAUTH要求を送信します。クライアントは、リレーのTLS証明書を使用してリレーを認証します。クライアントは、[1]リレーへの認証にHTTPダイジェスト認証を使用しています。認証が成功すると、リレーは、クライアントがリレーのMSRPパスで使用できるURIを含む200応答を返します。
A typical challenge response flow is shown below:
典型的なチャレンジ応答の流れを以下に示します。
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の使用-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.
AUTH要求は、彼らが着信要求を受信するために使用できるハンドルを作成するためにクライアントによって使用されています。 AUTH要求はまた、サービス妨害攻撃をブロックするために使用されるクライアントと認可ポリシーを認証するために使用される資格情報が含まれています。
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.
AUTH要求に応答して、正常な応答は、クライアントがクライアントへのルートバック応答にピアに与えることができますURIのリストで使用-Pathヘッダが含まれています。
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.
使用パスヘッダが成功したAUTH要求に応答してMSRPリレーにより提供されるURIのリストです。 URIのこのリストは、セッション記述には、例えば、MSRP要求を受信すると、URIのリストを宣伝するためにAUTH要求を送信したMSRPクライアントで使用することができます。使用-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.
使用-Pathヘッダ内のURIは、認証クライアントがパスヘッダーでそれらを使用するのと同じ順序です。 TO-パスヘッダとSDP [7]のパスが使用-Pathヘッダの情報から属性を形成する手順は、セクション5.1に提供されます。
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認証」ヘッダがHTTPダイジェスト認証手順で使用されるチャレンジトークンを含む（RFC 2617から[1]）。 MSRPでのHTTPダイジェスト認証の使用はセクション5.1で詳細に記載されています。
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.
「許可」ヘッダがHTTPダイジェスト認証のための認証証明書が含まれている（RFC 2617から[1]）。 MSRPでのHTTPダイジェスト認証の使用はセクション5.1で詳細に記載されています。
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.
「認証-INFO」ヘッダがHTTPダイジェスト認証に使用する将来の課題を含み（RFC 2617から[1]）。 MSRPでのHTTPダイジェスト認証の使用はセクション5.1で詳細に記載されています。
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.
リクエストのヘッダは、要求の方法によって暗示作用に関心がなくなった後の相対的な時間を提供する期限。リクエストでは、ヘッダは、送信者が有効なままにリクエストをご希望の期間を示し有効期限。これに応答して、ヘッダは、応答者がこの情報は、関連する考慮期間を示し期限切れ。具体的には、AUTH要求のヘッダが提供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.
ヘッダはExpiresヘッダにサーバが許容する最小期間を含んでいる分は、有効期限が切れます。これはのみ423「間隔範囲外の」応答で送信されます。同様に、ヘッダは、Expiresヘッダにサーバが許可する最大期間を含んMaxは、有効期限が切れます。
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要求を送信する必要があります。 （例えば、いくつかの組織は、「イントラORG」リレーと「余分-ORG」リレーを展開する可能性がある。）インナーリレーは、外側リレーにAUTH要求トンネルに使用されます。例えば、クライアントは、イントラ組織にAUTHを送信し、内組織を通じて転送するために使用することができるパスを取り戻すだろう。クライアントは、第2 AUTHエクストラ組織に宛てたが、イントラ組織を経由して送信を送信します。内組織リレー転送し、この余分な-ORG、エクストラ組織へのイントラ組織に余分な組織に別の宛先からメッセージを転送し、このクライアントにするために使用することができますパスを返します。各リレーは、クライアントを認証します。クライアントは、第1のリレーを認証し、各リレーは次のリレーを認証します。
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).
クライアントは、彼らが使用する必要がリレーのリストを（発見または手動プロビジョニングによって、一般的に）設定することができます。これらは、第1のリレーとの接続を形成し、TO-パスヘッダで使用することができるURIを取得するためにAUTHコマンドを送信することができなければなりません。クライアントは、リレーのTLS証明書を見て、その第1のリレーを認証することができます。クライアントは、[1]（詳細はセクション9.1を参照）HTTPダイジェスト認証を使用して、そのリレーのそれぞれに自分自身を認証しなければなりません。
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で、および発信要求のTO-Pathヘッダに送信され、パス属性にクライアントによって使用されています。発信要求のためのパスへのヘッダを形成するために、クライアントは、最も外側の認証後に使用-Pathヘッダ内のURIのリストを受け取り、ピアのセッション記述でパス属性で提供URIのリストを追加します。ピアに提供するために、SDPパス属性を形成するために、クライアントは、（最も外側の認証後）使用-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 (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".
例えば、「」「F」を達するためにドメイン2に独自のリレー「B」及び「C」、次いでリレー「D」と「E」を横断しなければなりません。クライアント「」そのリレー「B」及び「C」で認証し、最終的に「B C」を含む使用-Pathヘッダを受信することになります。クライアント「」（現在「C B」）リストを反転し、それ自身のURI（現在「C B A」）を付加し、パスSDP属性で、このリストに「F」を提供します。クライアント「F」は「」は「B C」を受信使用パスリストに追加し、クライアントのSDPパスリスト「D E F」を送信します。得られたTO-パスヘッダは、 "B C D E F" です。
domain 1 domain 2
---------------- -----------------
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
BがCのパス：Cによって返されるパスを使用することによって生成された属性：C Bパス：D E Fによって生成にパスヘッダ：B C D E Fの属性は、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.
クライアントが応答できるいかなる挑戦を持っていないため、クライアントによってリレーに送信された初期のAUTH要求は、一般的に、Authorizationヘッダーは含まれません。 Authorizationヘッダを含まないAUTH要求に応答して、リレーは、WWW-Authenticateヘッダを含む「401不正」応答で応答しなければなりません。 RFC 2617に記載されているようにWWW-Authenticateヘッダが形成されている[1]に、セクション9.1に記載の制限および修飾を有します。このような課題にMSRPリレーで選ばれたレルムは、管理ポリシーの問題です。単一のリレーは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ヘッダから領域をフェッチし、レルムの正しい資格情報でAuthorizationヘッダを含むリクエストを再試行するべきです。 RFC 2617に記載されているようにAuthorizationヘッダが形成されている[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.
クライアントが複数のリレーを使用したい場合は、それが使用することを希望する各リレーにAUTH要求を送らなければなりません。次いで、第2のリレー、R2上に、第1のリレー、R1から流れるようにメッセージを望むクライアントAを考えます。このクライアントは、R1と、通常のAUTHを行います。その後、R1経由でルーティングされたR2とAUTH取引を行います。クライアントはmsrpsへのパスへ設定することでこのAUTHメッセージを形成します：// R1、TCPのmsrps：// 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
AUTH要求を送信すると、クライアントはもはや提供間隔（秒の整数）よりも有効ですMSRP URIを要求するためにExpiresヘッダを追加するかもしれません。サーバが含まれます
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.
使用パスからそのURIが有効になりますどのくらいの時間を示す成功応答にExpiresヘッダ。各サーバが独立した有効期限を返すことができることに注意してください。
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.)
（アリスはintra.example.comにTLS接続を開き、認証プロセスを開始するAUTH要求を送信します。）
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.)
（アリスのリレーがAUTH要求に挑戦します。）
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$
(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.)
（アリスのリレーは、アリスが許可されたユーザであることを確認します。ローカルポリシーの問題として、それは将来のAUTH要求を促進するための新しい一回だけの値を持つ「認証-情報」ヘッダを含みます。）
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.)
（アリスは今、彼女はちょうど得たURIを使用して、彼女の「内部」の中継を通じて彼女の「外部」リレーにAUTH要求を送信し、AUTH要求が挑戦しています。）
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 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$
(Alice replies to the challenge with her credentials and is then authorized to use the "external" relay).
（アリスは彼女の資格情報を使用しての挑戦に応答して、「外部」のリレーを使用することが許可されています）。
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 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$
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.
SENDおよびREPORT要求を形成するための手順は、リレーが関与しているか否かのクライアントのために同じです。具体的な手順は、コアMSRPプロトコルの第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分とクライアントのリレーの一時間がデフォルトのためにそれを使用していないまでリレーへの接続の場合、クライアントはアップ接続のままにする必要があります。
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チャネルがネゴシエートされると、サーバーは、チャネルを介しMSRP要求を受信するように30秒まで待ちます。何の要求がその時間内に受信されない場合、サーバーは接続を閉じます。何も成功した要求は、この試用期間中に送信されていない場合、サーバーは接続を閉じます。いくつかの失敗した要求は、試用期間中に送信され、何の要求が正常に送信されていない場合は同様に、サーバが接続を閉じる必要があります。
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.
新しい要求を受信すると、リレーは最初の要求の妥当性を検証します。リレーはその後にパスヘッダの最初の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.
リレーはAUTH要求を受信すると、それが最初に行うことは、遠端で前のホップとクライアントを認証し、認可することです。このリレーとクライアントの間には、他のリレーが存在しない場合、これらは同じものです。
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は最初からパス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.
前のホップがクライアントである場合は、前のホップは、クライアントのアイデンティティと同じです。リレーは、このクライアントは、リレーを使用することを許可されている場合はAuthorizationヘッダをチェックして、クライアントによって提供された資格情報（ユーザー名とパスワード）をチェックします。クライアントが許可されていない場合、リレーは403応答を返します。クライアントがExpiresヘッダに特定の有効期限を要求した場合、リレーがない場合は、含有するエラーを返し、時間がそれに受け入れられることを確認する必要があるとMin-期限または必要に応じて、ヘッダをMaxは、有効期限が切れます。
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 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.
次のリレーは、メッセージがこの前のホップまたはから転送されることを可能にするMSRP URIを生成します。前のホップが相互TLSによって認証リレーだった場合、そのURIは、リレーは、以前のホップ中継を持つ任意の接続を介してルーティングするために有効である必要があります。前のホップがクライアントである場合、URIはAUTH要求を受信した上で、同じ接続を介してルーティングするために有効である必要があります。クライアントの接続が閉じた後、再度開かれる場合、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.
AUTH要求がExpiresヘッダを含んでいる場合、リレーは、URIが有効期限後に無効化されていることを確認しなければなりません。それは攻撃者によって推測されないようにURIは、暗号ランダム材料の少なくとも64ビットを含まなければなりません。リレーはURIが無効であるため、メッセージを転送するように要求された場合、リレーはメッセージを捨てなければなりませんし、AUTH 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応答は、クライアントが使用できるMSRP URIが含まれている使用-Pathヘッダを返します。それはまた、URIは、（秒の整数として表される）有効となる期間を示しExpiresヘッダを返します。
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経由して、それに接続されたクライアントからのいくつかの失敗したAUTH要求を受信した場合、リレーは、対応する接続を終了する必要があります。リレー転送いくつかの直接TLSを介してそれに接続されているクライアントから発信同じ宛先へAUTH要求を失敗した場合も同様に、リレーは、対応する接続を終了すべきです。リモートAUTH障害の決意は、「古い= TRUE」指示なしに401応答を誘発Authorizationヘッダを含むAUTH要求を観察することによって作製することができます。これらの予防措置は、リレーとクライアント間の接続に適用されます。リレーは、他の中継との接続を終了する理由として、過剰なAUTH要求の失敗を使用しないでください。
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.
すべての要求が転送される前に、リレーは、このリレーが作成され、AUTH要求の使用-Pathヘッダに配ったことにパスヘッダの最初のURIは、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.
入ってくるSEND要求は、「はい」の値が、すぐに最終的な応答で応答しなければならないことSEND要求を受け取るMSRPリレーで失敗-レポートヘッダーが含まれている場合。 200クラスの応答は、メッセージフラグメントの受信に成功したことを示しますが、メッセージは次のホップに転送されたことを意味するものではありません。 SENDに最終応答は、MSRPリレーやSEND要求の元の送信者である可能性が前のホップに送らなければなりません。
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.
失敗-レポートヘッダーは、「はい」または「部分的」である場合、およびSEND要求またはエラー応答がそのSEND要求のために受信された場合、リレーがレポートに適切なエラー応答で応答しなければならないの処理に問題がある場合バックメッセージの元のソースに。
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リレーは、さらに小さな断片にSEND要求で受信したメッセージフラグメントを分割し、別々のSEND要求で次のホップにそれらを転送することができます。また、このSEND要求の前または後に受信したメッセージの断片を組み合わせ、およびTo-パスヘッダーで識別次のホップに単一SEND要求にそれらを転送することができます。 MSRPリレーは、メッセージIDヘッダーの異なる値を有するSEND要求からメッセージフラグメントを結合してはいけません。
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リレーは、それが次のホップに送信するバイト範囲の知識を持っている場合、それは適切SEND要求内のバイト範囲ヘッダーを更新する必要があります。
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 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.
次のホップに送信要求を転送する前に、MSRPリレーは、TO-Pathヘッダの最初のURIを検査しなければなりません。それは、このリレーを示す場合、リレーは、TO-パスヘッダからこのURIを削除し、他のURIの前からパスヘッダにこのURIを挿入します。それは、このリレーを示していない場合、前のホップでの転送中にエラーがありました。この場合、リレーは、メッセージを破棄すべきである、と失敗-レポートヘッダーが「はい」に設定されている場合、リレーは、障害レポートを生成する必要があります。
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.
（リレーへの未知の新しい方法を含む）SEND要求以外の要求を受け取るMSRPリレーは最初にすべての要求の検証と承認の規則に従います。その後リレーからパスヘッダの先頭にパスヘッダの先頭からそのURIを移動し、次のホップ上に要求を転送します。それは、すでに次のホップへの接続を持っている場合は、この接続を使用して新しい接続を形成してはなりません。もし適切な接続が存在しない場合、リレーは新しい接続を開きます。
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.
彼らはREPORT要求であるかのように、未知の方法で要求が転送されます。 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.)
応答を受信したリレーは最初に、パスの最初のURIは、自身に対応することを検証します。ない場合、応答は廃棄されるべきである（SHOULD）。メッセージが解析できない場合同様に、リレーは応答をドロップしなければなりません。リレーが決定隣のパスに追加のURIが存在する場合。 （応答が要求を送信するためにAUTH要求への応答がクライアントに応答を指示する追加の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応答であり、元の要求が「NO」以外の値と障害、レポートヘッダーを持っていたSEND要求であった場合、リレーは、故障の性質を示すレポートを送信しなければなりません。リレーによって受信された応答コードは、リレーが送信するレポートにステータスラインを形成するために使用されます。
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.
追加のURIが対パスヘッダ内に存在する場合、リレーは、次いで、TO-パスヘッダからのURIを移動するからパスヘッダ内の他のURIの前に、そのURIを挿入し、次のURIに応答を転送しなければなりませんパスへのヘッダーインチリレーへのパスヘッダ内の次の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
ヘッダ= /有効期限/分、有効期限/ Maxは、有効期限/使用パス/ WWW認証/認可/認証-INFO。これは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 = / Mauthの。これはRFC 4975でルールに追加されます
WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP digest-param *("," SP digest-param)
WWW認証= "WWW認証：" SP "ダイジェスト" SPダイジェストのparam *（ "" SPダイジェスト-PARAM）
digest-param = ( realm / nonce / [ opaque ] / [ stale ] / [ algorithm ] / qop-options / [auth-param] )
ダイジェストPARAM =（レルム/ナンス/ [不透明] / [失効] / [アルゴリズム] / QOP-オプション/ [AUTH-PARAM]）
realm = "realm=" realm-value realm-value = quoted-string
分野=「分野=」レルム値レルム値=引用符で囲まれた文字列
auth-param = token "=" ( token / quoted-string )
auth-PARAM =トークン "="（トークン/引用符で囲まれた文字列）
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
ナンス=「ナンス=」ナンス値ナンス値=引用符で囲まれた文字列不透明=「不透明=」引用符で囲まれた文字列古い=「陳腐=」（「真」/「偽」）アルゴリズム=「アルゴリズム=」（「MD5」 /トークン）QOP-OPTIONS = "QOP =" DQUOTE QOPリストDQUOTEのQOPリスト= QOP値*（ "" QOP値）QOP値= "認証" /トークン
Authorization = "Authorization:" SP credentials
SP資格：=「認可」認可
credentials = "Digest" SP digest-response *( "," SP digest-response)
資格情報=「ダイジェスト」SPダイジェスト応答*（「」SPダイジェスト・レスポンス）
digest-response = ( username / realm / nonce / response / [ algorithm ] / cnonce / [opaque] / message-qop / [nonce-count] / [auth-param] )
ダイジェスト応答=（ユーザ名/レルム/ナンス/応答/ [アルゴリズム] / cnonce / [不透明] /メッセージQOP / [ナンスカウント] / [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
ユーザ名=「ユーザ名=」ユーザ名値名値=引用符で囲まれた文字列のメッセージQOP =「QOP =」QOP値cnonce =「cnonce =」cnonce値cnonce値=ナンス値ナンスカウント=「NC = 「NC-値NC-値= 8LHEX応答= "応答=" 要求ダイジェスト要求ダイジェスト= DQUOTE 32LHEX DQUOTE LHEX = DIGIT /％x61-66;小文字AF
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
認証情報= "認証-情報：" SPのAINFOの*（ "" AINFO）AINFO = nextnonce /メッセージQOP /応答-AUTH / cnonce /ナンスカウントnextnonce = "nextnonce =" ナンス値応答-AUTH = " rspauth =」レスポンス・ダイジェスト応答ダイジェスト= DQUOTE * LHEX DQUOTE
Expires = "Expires:" SP 1*DIGIT Min-Expires = "Min-Expires:" SP 1*DIGIT Max-Expires = "Max-Expires:" SP 1*DIGIT
SP 1 * DIGIT = "Minは、有効期限：" Minは、有効期限SP 1 * DIGIT = "マックスは、有効期限：" マックスは、有効期限SP 1 * DIGIT：= "有効期限" 有効期限
Use-Path = "Use-Path:" SP MSRP-URI *(SP MSRP-URI)
使用パス= "使用パス：" 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の規則に従います。 MSRP URIは、明示的なポート番号を指定する必要がありSDPに非AUTH要求におけるへのパスからパスヘッダに交換しました。 （明示的なポート番号なしMSRP URIを持つことができ、本明細書でのみメッセージはAUTH要求における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クライアントがAUTH要求で、より簡単にMSRPリレーを発見することができます。権限コンポーネントが含まれている場合は、ドメイン名と明示的なポート番号が提供され、ドメイン名の有効なアドレスレコード（AまたはAAAA）をルックアップするためにしよう。提供ポート番号のデフォルトのトランスポート（TCP）上でTLSを使用して接続します。
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）選択アルゴリズムに従っている場合エントリを選択します。 （AUTH要求はのみTLSを介して送信されるので、「_msrp」サービスは、定義されていません。）何のSRVが見つからない場合は、ドメイン名のアドレス検索（AまたはAAAA）をしてみてください。デフォルトのポート番号（2855）とデフォルトのトランスポート（TCP）上でTLSを使用して接続します。 AUTH要求は唯一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インチSRV 0 1 9000 server1.example.comで[PRI WGHTポートターゲット_msrps._tcp。 2 9000 server2.example.com SRV 0 IN _msrps._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アドレス）を有する場合、これらのアドレスのそれぞれは、単一のターゲットに対応する別個のAまたはAAAAレコードとしてDNSに登録されるべきです。
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:
AUTH要求が認証される必要があります。本明細書に記載された認証メカニズムは、HTTPダイジェスト認証を使用しています。 RFC 2617に記載されているように、HTTPダイジェスト認証は、以下の制限と変更して、[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のauth-int型のQOP値を使用することは、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 MD5-SESのアルゴリズムとnextnonce機構との間の相互作用は、RFC 2617にunderspecifiedされている[1]。その結果、MSRPリレーは、MD5-SESのアルゴリズムを示す挑戦を送ってはいけません。
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認証」ヘッダーに「ドメイン」パラメータを送るべきではありませんし、存在する場合、クライアントはそれを無視しなければなりません。
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認証」ヘッダにおけるQOPパラメータの値が引用されていることに留意されたいが、「許可」ヘッダまたは「認証-INFO」ヘッダにQOPパラメータの値が引用されていません。
o Clients MUST send cnonce and nonce-count parameters in all "Authorization" headers.
Oクライアントは、すべての「認可」ヘッダーにcnonceとナンスカウントパラメータを送らなければなりません。
o The request-URI to be used in calculating H(A2) is the rightmost URI in the To-Path header.
OリクエストURIがH（A2）の算出に使用するには、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リレーはAUTH要求にすべての「200 OK」応答の「認証-INFO」ヘッダに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].
RFC 2617でのBNFは、エラーの数を持っていることに注意してください。具体的には、uriパラメータの値は引用符で囲む必要があります。さらに、認証-Infoヘッダ内のパラメータは、カンマで区切る必要があります。この文書に記載されている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に記載されているようにnextnonceとNCパラメータの使用がサポートされている[1]、それらが使用されるべき方法とタイミングに関するガイダンスを提供します。 RFC 2617のガイダンスにわずかな変形例として、リレーの実装者は、AUTH要求をパイプライン化することができないことに注意すべきです。リレーは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を送信しなければならないクライアントは、RFC 4366に記載されているように、ハローサーバ名表示用の情報を拡張[5]。 TLS_RSA_WITH_AES_128_CBC_SHAのTLS暗号スイート[6]（他の暗号スイートもサポートすることができる）をサポートしなければなりません。リレーはTLSサーバとして動作してのdNSNameの選択肢タイプを使用してのSubjectAltNameにそのアイデンティティと証明書を提示しなければなりません。リレー・ツー・リレー接続は、相互認証とTLSを使用しなければなりません。クライアントとの中継通信がAUTH要求と応答のために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方法を使用して処理されます。その他の仕様は、MSRPクライアントに関連付けられているユーザを認証する目的で、TLS相互認証の使用を定義することもできます。そのような他の規格の下で動作していない限り、（1が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) would likely not be trusted with the contents of the session but would be trusted to correctly forward messages.
メーカー希望小売価格は、2つのピア・ツー・ピアクライアントがメッセージを交換することができます。各ピアは彼らのために特定のポリシー操作を実行するためのリレーのセットを選択することができます。リレーのこの組み合わせセットはルートセットと呼ばれます。 MSRPの外側チャネルは、常に確実MSRPセッションをセットアップ交渉及び両方のクライアントに設定された経路を伝えることができる、そのようなアウトオブバンドプロビジョニングまたはSIPなどの明示的なランデブープロトコルとして、存在する必要があります。クライアントは、ルーティングと政策決定の特定の種類のリレーを信用かもしれないが、それは、またはセッションのすべての内容とリレーを信頼しない場合があります。例えば、ウイルスを探すために、信頼されているリレーはおそらく、セッションのすべての内容を確認するために許可する必要があります。 ISPのネットワークアドレス変換（NAT）のトラバーサルを扱う助けたリレーは、おそらくセッションの内容を信頼することはないだろうが、正しく転送メッセージに信頼されることになります。
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プロトコルの制約の中で、それらのメッセージに示されたルーティングを称えるために、メッセージを受信します。クライアントは、彼らが使用するリレーが自分に代わって新しいメッセージを挿入するか、またはクライアントが送信したメッセージを変更しないことを信頼する必要があります。これは、いくつかのリレーは、クライアントが悪意を持ってチェーンのさらに下のリレーで返される使用パスを変更することで、メッセージをmisrouteさせるための位置にあることは注目に値します。しかし、これは、これらの同じリレーはまた、最初の場所でメッセージをmisrouteすることを決定することができるので、追加のセキュリティ上の脅威ではありません。リレーがメッセージをルーティングするために信頼されている場合、使用-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.
クライアントは、彼らが通信しているリレーは、彼らが信頼一つであることを認証できるようにする必要があります。同様に、リレーは、クライアントがそれらが情報を転送することが許可されている1つであることを認証できるようにする必要があります。クライアントは、リレーとクライアントとの間でその情報を確実にするオプションが完全性を保護し、リレーやクライアント以外の要素に機密である必要があります。オプションの数を単純化するために、リレー間のトラフィックは常に完全性を保護に関係なく、クライアントがそれを要求するか否かの暗号化されています。クライアントは、クライアントがセキュリティの適切なレベルを必要とするために投与されるリレーを選ぶ持っている以外のリレー間で使用する暗号メカニズムのどんな強リレーを伝える方法はありません。
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は、受信信託リレーです。メッセージはRClientにRRelay1にRRelay2にSRelay2にSRelay1にsclientのから行きます。
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を行う必要はありません）。さらに、認証-Infoヘッダにおける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.
リレーは内容を見ることができないように/セキュア多目的インターネットメール拡張（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.
複雑な部分は、リレーが正常にどこがいけない場所にメッセージを送信するように指示することができないことを確認しています。これは、リレーにクライアント認証を有するリレーがトークンを返すことによって行われます。彼らはトークンを持ってクライアントに向けて転送されている場合は、トークンを得たか、クライアントから来る場合は、このトークンを含むメッセージを中継することができます。トークンは使用-Pathヘッダの中継場所のURIです。彼らは攻撃者によって推測されないように、トークンは（セクション6.3で定義された）ランダムな材料を含んでいます。トークンは、彼らが唯一のこれまでの関係者の信頼関係の少なくとも1つのルートセットやその他の要素の要素によって見られるように保護する必要があります。一部のサードパーティがRRelay2がRClientへメッセージを転送するために使用するトークンを発見した場合は、その後、彼らはRRelay2にしたいように、その第三者は、多くのメッセージを送ることができますし、それは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からのメッセージを転送するための唯一の有効なトークンを生成します。 SRelay2は、それが原因で相互TLSの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要求に期限切れヘッダを使用してネゴシエートされるために有効です。クライアントは、トークンの有効期限が切れる前に（例えば、SIP再招待）新しいオファー/アンサー[15]交換を使用してトークンを再交渉する必要があります。
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.
この方式は、それらに認証されたユーザのために行動する、信頼されたノードとしてのリレーに依存していることに注意してください。 、偽造メッセージを挿入するメッセージの内容を操作する、送信者、または第三者にコピーから、指定した以外の第三者にセッションにメッセージを送信することから、パス上のリレーを防ぐためにはセキュリティメカニズムはありません。しかし、セッション識別子とセッションの間の結合は1対1には、唯一のため、偽造または変更メッセージがセッションに関与する2つの当事者に送信できる宛先を制限することにより、不正なリレーによって引き起こされる可能性が損傷を軽減しますセッションの期間。また、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.
クライアントは、悪意のない方法で行動するリレーを信頼する必要があり、ネットワーク内の唯一の俳優ではありません。リレーはその代理として、それが機能している（すなわち、1つまたは複数の介在するリレーがあります）上のクライアントとの直接TLS接続を持っていない場合、それは正確にしてから送信されたメッセージを送信するためにどのような介在リレーの慈悲でありますクライアント。メッセージの本物の起源の強力な保証が（例えば、リレーは法的要件の一部として、メッセージのロギングを実行している）必要がある場合、そのリレーのユーザーは、すべてのデタッチS / MIME署名を使用するように管理者が指示することができます彼らのクライアントから送信されたメッセージ。リレーは、「マルチパート/署名された」以外のトップレベルのMIMEタイプを使用して、任意のSEND要求に対する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.
AUTH：この仕様はMSRPパラメータレジストリの下のメソッドサブレジストリに追加される新しいMSRPメソッドを定義します。 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 WWW認証Oを使用するパスoをマックスには、有効期限oをMinは、有効期限〇〇有効期限
This specification defines one new MSRP status code, to be added to the Status-Code sub-registry under the MSRP Parameters registry:
この仕様はMSRPパラメータレジストリの下でステータスコードのサブレジストリに追加されるように、1つの新しい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応答は、AUTH要求が資格情報、有効期限が切れたノンス値、または無効な認証情報を含まないことを示します。応答は、チャレンジを（他のフィールドのうち）を含有する「WWW認証」ヘッダを含みます。詳細については、セクション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.
次のセクションでは、ボブは、リレーを使用して、アリスとボブの間のMSRPセッションをセットアップするSIPメッセージに発生する可能性例SDPを示します。アリスはアリスへのパスを提供します。
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 =メッセージ1234 TCP / MSRP * A =受け入れる-種類：メッセージ/ CPIMテキスト/プレーンテキスト/ HTML =パス：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.
このオファーでは、アリスはa.example.comでMSRPメッセージを受信したいです。彼女は、MSRPセッションのトランスポートとしてTCPを使用することを望んでいます。彼女は、SEND要求にメッセージ/ CPIM、text / plainで、およびテキスト/ HTML形式のメッセージ本文を受け入れることができます。彼女は、MSRPセッションを設定するリレーを必要としません。
To this offer, Bob's answer could look like:
このオファーには、ボブの答えは次のようになります。
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 =メッセージ1234 TCP / TLS / MSRP * A =受け入れる-種類：メッセージ/ CPIM text / plainの=パス：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.example.comでMSRPメッセージを受信したいです。彼は、SEND要求でのみメッセージ/ CPIMとtext / plainのメッセージ本文を受け入れることができ、アリスが提供するテキスト/ 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フーリー、ヒシャムKhartabil、ロバート・スパークス、ミゲル・ガルシア、ハンスPerssonの、詳細な校正、有用テキストを提供するのoriTレヴィン、に感謝します。クリスボールトン、ベン・キャンベル、Juheeガーグ、ポールKyzivat、アリソンマンキン、アキニエミ、ペッカPessi、ジョンピーターソン、ブライアン・ローゼン、ジョナサン・ローゼンバーグ、およびディーンウィリス：セッションモードで元気な議論のためのSIMPLE WGのメンバーは以下のとおりに感謝します。
[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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[2]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[6]、RFC 3268、2002年6月のchown、P.、 "トランスポート層セキュリティ（TLS）用のAdvanced Encryption Standard（AES）暗号の組み合わせを"。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[10]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[11] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[11]キャンベル、B.、エド。、マーイ、R.、エド。、およびC.ジェニングス、エド。、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[13]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[14]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[15]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
Appendix A. Implementation Considerations
付録A.実装に関する考慮事項
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についてAUTH要求を送信する必要はありません。これは、この文書の範囲外にある実装の詳細です。
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 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.
リレーがどのような状態を保存せずに、ファーム内の転送要件を実装することが可能です。リレーが使用する可能性のある一つの可能な実装は、このセクションの残りの部分に記載されています。リレーは、起動時には、暗号ランダム128ビットのパスワード（K）および128ビットの初期化ベクトル（IV）を選ぶことができます。リレーは、実際に同じDNS名を持つサーバーのファームだった場合AUTH要求を受信すると、ファーム内のすべてのマシンが同じK.を共有する必要があるだろう、リレーは、URIの有効期限を含む文字列を形成し前のホップが相互た場合指示TLSは認証かどうか、そしてそれは、前のホップの名前である場合、それは、AUTH要求を受信し、接続するための識別子でなかった場合。この文字列は、文字列の長さが長い16バイトの倍数になるまでは0x00の値がゼロ以上のバイトを加算し、次に値が0x80のバイトを付加することによりパディングされるであろう。変化する新しいランダムIVが選択される（それは塩を形成するので、それを変更する必要がある）とパディング文字列がKでIVと暗号化されたデータのキーとSPI（セキュリティパラメータインデックス）とAES-CBCを使用して暗号化されるだろう各時間Kの変化は、符号化されたベース64とすることが、要求URIのリソースの一部を形成するであろう。 SPIは、キーを変更し、Kを使用すべきかを知るためのシステムのことを可能にします。リレーはこのURIを受信したときに、後でそれを解読し、現在時刻が有効期限前であったことを確認し、メッセージがから来るか、URIで指定した接続または場所に行っていたことを確認できました。解読されたランダムデータは、メッセージがへたりからルーティングされたものと同じだった有効な位置をもたらすことは極めてまれであるため、完全性保護は必要ありません。このような何かを実装する場合、実装者は、希望が暗号化されたトークンの部分が他のURIにカット＆ペーストすることができますEBEのようなスキームを使用しないように注意する必要があります。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA
カレンジェニングスシスコシステムズ、株式会社170西タスマン博士MS：SJC-2分の21サンノゼ、CA 95134 USA
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
電話：+1 408 421-9990 Eメール：fluffy@cisco.com
Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
ロハンリーヒPlantronicsの345 Encincalストリートサンタクルス、CA 95060 USA
EMail: rohan@ekabal.com
メールアドレス：rohan@ekabal.com
Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 USA
アダムローチEstacadoシステム17210キャンベルRdを。スイート250、ダラス、TX 75252 USA
Phone: sip:adam@estacado.net EMail: adam@estacado.net
電話：SIP：adam@estacado.net Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。