RFC 7977 - The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7977
タイトル : RFC 7977 - メッセージセッションリレープロトコル（MSRP）のトランスポートとしてのWebSocketプロトコル
翻訳編集 : 自動生成

[要約] 要約：RFC 7977は、WebSocketプロトコルを使用してMSRP（Message Session Relay Protocol）を転送するための方法を提供します。目的：このRFCの目的は、MSRPをWebSocketプロトコルを介して効果的に転送するための標準化とガイドラインを提供することです。

Internet Engineering Task Force (IETF)                        P. Dunkley
Request for Comments: 7977                                  G. Llewellyn
Updates: 4975, 4976                                                 Xura
Category: Standards Track                                     V. Pascual
ISSN: 2070-1721                                                   Oracle
                                                            G. Salgueiro
                                                         R. Ravindranath
                                                                   Cisco
                                                          September 2016

The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)

メッセージセッションリレープロトコル（MSRP）のトランスポートとしてのWebSocketプロトコル

Abstract

概要

The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFCs 4975 and 4976.

WebSocketプロトコルは、TCPとUDPへの直接アクセスが利用できない状況（たとえば、WebブラウザーのJavaScript内から）で、クライアントとサーバー間の双方向のリアルタイム通信を可能にします。このドキュメントでは、新しいシナリオでのMSRPの使用を可能にするために、メッセージセッションリレープロトコル（MSRP）クライアントとリレー間の信頼できるトランスポートメカニズムとして新しいWebSocketサブプロトコルを指定します。このドキュメントは、RFC 4975および4976を規範的に更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7977.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7977で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  WebSocket Protocol Overview . . . . . . . . . . . . . . . . .   5
   4.  The WebSocket MSRP Subprotocol  . . . . . . . . . . . . . . .   6
     4.1.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  MSRP Encoding . . . . . . . . . . . . . . . . . . . . . .   7
   5.  MSRP WebSocket Transport  . . . . . . . . . . . . . . . . . .   7
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Updates to RFC 4975 . . . . . . . . . . . . . . . . . . .   7
       5.2.1.  MSRP URI Transport Parameter  . . . . . . . . . . . .   7
       5.2.2.  SDP Transport Protocol  . . . . . . . . . . . . . . .   8
     5.3.  Updates to RFC 4976 . . . . . . . . . . . . . . . . . . .   8
       5.3.1.  AUTH Request Authentication . . . . . . . . . . . . .   8
   6.  Connection Keepalive  . . . . . . . . . . . . . . . . . . . .   9
   7.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .  10
       8.1.1.  WebSocket Authentication  . . . . . . . . . . . . . .  10
       8.1.2.  MSRP Authentication . . . . . . . . . . . . . . . . .  12
     8.2.  Example Session: MSRP WebSocket Client to MSRP Client . .  14
       8.2.1.  SDP Exchange  . . . . . . . . . . . . . . . . . . . .  14
       8.2.2.  SEND (MSRP WebSocket Client to MSRP Client) . . . . .  15
       8.2.3.  SEND (MSRP Client to MSRP WebSocket Client) . . . . .  16
     8.3.  Example Session: Two MSRP WebSocket Clients . . . . . . .  18
       8.3.1.  SDP Exchange  . . . . . . . . . . . . . . . . . . . .  18
       8.3.2.  SEND  . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.4.  Example Session: MSRP WebSocket Client to MSRP Client
           Using a Relay . . . . . . . . . . . . . . . . . . . . . .  20
       8.4.1.  SDP Exchange  . . . . . . . . . . . . . . . . . . . .  20
       8.4.2.  SEND  . . . . . . . . . . . . . . . . . . . . . . . .  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     11.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Appendix A.  Implementation Guidelines: MSRP WebSocket Client
                Considerations . . . . . . . . . . . . . . . . . . .  27
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1. Introduction

1. はじめに

The WebSocket [RFC6455] protocol enables message exchange between clients and servers on top of a persistent TCP connection (optionally secured with Transport Layer Security (TLS) [RFC5246]). The initial protocol handshake makes use of HTTP [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.

WebSocket [RFC6455]プロトコルを使用すると、永続的なTCP接続（オプションでトランスポート層セキュリティ（TLS）[RFC5246]で保護される）の上にあるクライアントとサーバー間のメッセージ交換が可能になります。初期プロトコルハンドシェイクはHTTP [RFC7230]セマンティクスを利用しており、WebSocketプロトコルが既存のHTTPインフラストラクチャを再利用できるようにします。

Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. The specification in this document enables usage of Message Session Relay Protocol [RFC4975] in these scenarios.

最新のWebブラウザーには、W3Cで指定されているWebSocket API [WS-API]に準拠したWebSocketクライアントスタックが含まれています。他のクライアントアプリケーション（パーソナルコンピューターやスマートフォンなどのデバイスで実行されているもの）でも、WebSocketクライアントスタックを利用できるようになることが期待されます。このドキュメントの仕様により、これらのシナリオでメッセージセッションリレープロトコル[RFC4975]を使用できるようになります。

This specification defines a new WebSocket subprotocol (as defined in Section 1.9 in [RFC6455]) for transporting MSRP messages between a WebSocket client and MSRP relay [RFC4976] containing a WebSocket server, a new transport for MSRP, and procedures for MSRP clients and relays implementing the WebSocket transport.

この仕様は、WebSocketサーバーとMSRPの新しいトランスポート、およびMSRPクライアントとリレーの手順を含むWebSocketクライアントとMSRPリレー[RFC4976]の間でMSRPメッセージをトランスポートするための新しいWebSocketサブプロトコル（[RFC6455]のセクション1.9で定義）を定義しますWebSocketトランスポートの実装。

MSRP over WebSocket is well suited for MSRP interactions between clients and servers. Common use cases for MSRP over WebSocket include:

MSRP over WebSocketは、クライアントとサーバー間のMSRP相互作用に適しています。 MSRP over WebSocketの一般的な使用例は次のとおりです。

o Human-to-machine messaging

o 人からマシンへのメッセージング

o Client-to-server data exchange (for example, application control signaling)

o クライアントからサーバーへのデータ交換（たとえば、アプリケーション制御シグナリング）

o Human-to-human messaging where local policy requires authentication and/or logging

o ローカルポリシーで認証やロギングが必要な人と人とのメッセージング

MSRP Connection Establishment for Media Anchoring (MSRP-CEMA) [RFC6714] is outside of the scope of this document, as this document is intended to describe connecting to a WebSocket server that is an MSRP relay.

このドキュメントは、MSRPリレーであるWebSocketサーバーへの接続について説明することを目的としているため、メディアアンカーのMSRP接続確立（MSRP-CEMA）[RFC6714]はこのドキュメントの範囲外です。

2. Terminology

2. 用語

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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2.1. Definitions

2.1. 定義

MSRP WebSocket Client: An MSRP entity capable of opening outbound connections to MSRP relays that are WebSocket servers and communicating using the WebSocket MSRP subprotocol as defined by this document.

MSRP WebSocketクライアント：WebSocketサーバーであるMSRPリレーへの送信接続を開き、このドキュメントで定義されているWebSocket MSRPサブプロトコルを使用して通信できるMSRPエンティティ。

MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay [RFC4976]) capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket MSRP subprotocol as defined by this document.

MSRP WebSocketサーバー：WebSocketクライアントからの受信接続をリッスンし、このドキュメントで定義されているWebSocket MSRPサブプロトコルを使用して通信できるMSRPエンティティ（特にMSRPリレー[RFC4976]）。

3. WebSocket Protocol Overview

3. WebSocketプロトコルの概要

The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC5246]) in which both the client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket subprotocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes.

WebSocketプロトコル[RFC6455]は、TCP上のトランスポート層（オプションでTLS [RFC5246]で保護されています）であり、クライアントとサーバーの両方が双方向でメッセージユニットを交換します。このプロトコルは、接続ハンドシェイク、WebSocketサブプロトコルと拡張ネゴシエーション、アプリケーションと制御データを送信するためのフレームフォーマット、マスキングメカニズム、および切断の原因を示すステータスコードを定義します。

The WebSocket connection handshake is based on HTTP [RFC7230] and utilizes the HTTP GET method with an "Upgrade" request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed, the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, client and server agree on the application protocol to use on top of the WebSocket transport. Such application protocol (also known as a "WebSocket subprotocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (such as the WebSocket MSRP subprotocol defined in this document). Once the HTTP 101 response is processed, both client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges.

WebSocket接続ハンドシェイクはHTTP [RFC7230]に基づいており、「アップグレード」リクエストでHTTP GETメソッドを利用します。これはクライアントから送信され、サーバーによって（ネゴシエーションが成功した場合）HTTP 101ステータスコードで応答されます。ハンドシェイクが完了すると、接続はHTTPからWebSocketプロトコルにアップグレードされます。このハンドシェイク手順は、既存のHTTPインフラストラクチャを再利用するように設計されています。接続ハンドシェイク中に、クライアントとサーバーは、WebSocketトランスポート上で使用するアプリケーションプロトコルに同意します。このようなアプリケーションプロトコル（「WebSocketサブプロトコル」とも呼ばれます）は、エンドポイントによって交換されるメッセージの形式とセマンティクスを定義します。これは、カスタムプロトコルまたは標準化されたプロトコル（このドキュメントで定義されているWebSocket MSRPサブプロトコルなど）の場合があります。 HTTP 101応答が処理されると、クライアントとサーバーの両方が基になるTCP接続を再利用して、WebSocketメッセージと制御フレームを相互に送信します。プレーンHTTPとは異なり、この接続は永続的であり、複数のメッセージ交換に使用できます。

WebSocket defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer. These message units can contain either UTF-8 text or binary data and can be split into multiple WebSocket text/binary transport frames as needed by the WebSocket stack.

WebSocketは、アプリケーションがデータ交換に使用するメッセージユニットを定義するため、メッセージ境界を保持するトランスポート層を提供します。これらのメッセージユニットには、UTF-8テキストまたはバイナリデータを含めることができ、WebSocketスタックの必要に応じて、複数のWebSocketテキスト/バイナリトランスポートフレームに分割できます。

The WebSocket API [WS-API] for web browsers only defines callbacks to be invoked upon receipt of an entire message unit regardless of whether it was received in a single WebSocket frame or split across multiple frames.

Webブラウザー用のWebSocket API [WS-API]は、単一のWebSocketフレームで受信されたか複数のフレームに分割されたかに関係なく、メッセージユニット全体の受信時に呼び出されるコールバックのみを定義します。

4. The WebSocket MSRP Subprotocol

4. WebSocket MSRPサブプロトコル

The term WebSocket subprotocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket MSRP subprotocol for carrying MSRP requests and responses through a WebSocket connection.

WebSocketサブプロトコルという用語は、WebSocket接続の上にあるアプリケーションレベルのプロトコルを指します。このドキュメントでは、WebSocket接続を介してMSRP要求と応答を伝送するためのWebSocket MSRPサブプロトコルを指定します。

4.1. Handshake

4.1. ハンドシェーク

The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage of the WebSocket MSRP subprotocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The Client MUST include the value "msrp" in the Sec-WebSocket-Protocol header in its handshake request. The 101 reply from the Server MUST contain "msrp" in its corresponding Sec-WebSocket-Protocol header.

[RFC6455]のセクション1.3で定義されているように、MSRP WebSocketクライアントとMSRP WebSocketサーバーは、WebSocketハンドシェイク手順中にWebSocket MSRPサブプロトコルの使用をネゴシエートします。クライアントは、ハンドシェイク要求のSec-WebSocket-Protocolヘッダーに値「msrp」を含める必要があります。サーバーからの101応答では、対応するSec-WebSocket-Protocolヘッダーに「msrp」が含まれている必要があります。

Below is an example of a WebSocket handshake in which the Client requests the WebSocket MSRP subprotocol support from the Server:

以下は、クライアントがサーバーからWebSocket MSRPサブプロトコルサポートを要求するWebSocketハンドシェイクの例です。

     GET / HTTP/1.1
     Host: a.example.com
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
     Origin: http://www.example.com
     Sec-WebSocket-Protocol: msrp
     Sec-WebSocket-Version: 13

The handshake response from the Server accepting the WebSocket MSRP subprotocol would look as follows:

WebSocket MSRPサブプロトコルを受け入れるサーバーからのハンドシェイク応答は次のようになります。

     HTTP/1.1 101 Switching Protocols
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
     Sec-WebSocket-Protocol: msrp

Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of MSRP requests and responses. The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket subprotocol.

ネゴシエーションが完了すると、WebSocket接続が確立され、MSRP要求と応答の転送に使用できます。この接続を介して送信されるWebSocketメッセージは、ネゴシエートされたWebSocketサブプロトコルに準拠する必要があります。

4.2. MSRP Encoding

4.2. MSRPエンコーディング

WebSocket messages can be transported in either UTF-8 text frames or binary frames. MSRP [RFC4975] allows both text and binary bodies in MSRP requests. Therefore, MSRP WebSocket Clients and Servers MUST accept both text and binary frames.

WebSocketメッセージは、UTF-8テキストフレームまたはバイナリフレームで転送できます。 MSRP [RFC4975]では、MSRPリクエストでテキストとバイナリの両方の本文を使用できます。したがって、MSRP WebSocketクライアントとサーバーは、テキストフレームとバイナリフレームの両方を受け入れる必要があります。

The WebSocket API [WS-API] does not allow developers to choose whether to send UTF-8 text or binary frames but will not send non-UTF-8 characters in a text frame. The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers.

WebSocket API [WS-API]では、開発者がUTF-8テキストまたはバイナリフレームを送信するかどうかを選択できませんが、テキストフレームでUTF-8以外の文字を送信することはできません。テキストフレームのコンテンツは、WebSocketクライアントおよびサーバーによってバイナリとして解釈される必要があります。

5. MSRP WebSocket Transport

5. MSRP WebSocketトランスポート

5.1. General

5.1. 一般的な

WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is challenging for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP-over-WebSocket messages MUST be routed via an MSRP WebSocket Server. MSRP traffic transported over WebSockets MUST be protected by using a Secure WebSocket (WSS) connection (using TLS [RFC5246] over TCP).

WebSocketクライアントは、他のWebSocketクライアントまたはWebSocketサーバーによって開始されたWebSocket接続を受信できません。つまり、MSRPクライアントが他のMSRPクライアントと直接通信することは困難です。したがって、すべてのMSRP-over-WebSocketメッセージは、MSRP WebSocketサーバーを介してルーティングされる必要があります。 WebSocketを介して転送されるMSRPトラフィックは、Secure TCP（WSS）接続を使用して保護する必要があります（TCPを介したTLS [RFC5246]を使用）。

MSRP WebSocket Servers can be used to route MSRP messages between MSRP WebSocket Clients and between MSRP WebSocket Clients and "normal" MSRP clients and relays.

MSRP WebSocketサーバーを使用して、MSRP WebSocketクライアント間、およびMSRP WebSocketクライアントと「通常の」MSRPクライアントおよびリレー間でMSRPメッセージをルーティングできます。

Each MSRP chunk MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one MSRP chunk.

各MSRPチャンクは単一のWebSocketメッセージ内で伝送する必要があり、WebSocketメッセージには複数のMSRPチャンクを含めることはできません。

This simplifies parsing of MSRP messages for both clients and servers. When large messages are sent by a non-WebSocket peer, MSRP chunking (as defined in Section 5.1 of [RFC4975]) MUST be used by the WebSocket MSRP Servers to split the message into several smaller MSRP chunks.

これにより、クライアントとサーバーの両方のMSRPメッセージの解析が簡素化されます。大きなメッセージが非WebSocketピアから送信される場合、MSRPチャンキング（[RFC4975]のセクション5.1で定義）を使用して、メッセージをいくつかの小さなMSRPチャンクに分割する必要があります。

5.2. Updates to RFC 4975

5.2. RFC 4975の更新

5.2.1. MSRP URI Transport Parameter

5.2.1. ＭＳＲＰうりＴらんｓぽｒｔぱらめてｒ

This document defines the value "ws" as the transport parameter value for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket subprotocol as transport.

このドキュメントでは、トランスポートとしてMSRP WebSocketサブプロトコルを使用して接続されるMSRP URI [RFC3986]のトランスポートパラメータ値として値「ws」を定義しています。

The updated ABNF [RFC5234] for this parameter is the following (the original BNF for this parameter can be found in [RFC4975]):

このパラメーターの更新されたABNF [RFC5234]は次のとおりです（このパラメーターの元のBNFは[RFC4975]にあります）。

     transport  =  "tcp" / "ws" / 1*ALPHANUM

5.2.2. SDP Transport Protocol

5.2.2. SDPトランスポートプロトコル

This document does not define a new Session Description Protocol (SDP) transport protocol for MSRP over WebSockets. As all MSRP-over-WebSocket messages MUST be routed via an MSRP WebSocket Server, the MSRP WebSocket Client MUST specify "TCP/TLS/MSRP" protocols in the SDP m-line -- that being the protocol used by non-WebSocket clients and between MSRP relays (see Section 8.1 of [RFC4975]).

このドキュメントでは、WebSocket over MSRPの新しいセッション記述プロトコル（SDP）トランスポートプロトコルを定義していません。すべてのMSRP-over-WebSocketメッセージはMSRP WebSocketサーバーを介してルーティングされる必要があるため、MSRP WebSocketクライアントはSDP m-lineで「TCP / TLS / MSRP」プロトコルを指定する必要があります-これは非WebSocketクライアントによって使用されるプロトコルであり、 MSRPリレー間（[RFC4975]のセクション8.1を参照）。

The "ws" transport parameter will appear in the endpoint URI in the SDP "path" attribute (see Section 8.2 of [RFC4975]). MSRP was designed with the possibility of new transport bindings in mind (see Section 6 of [RFC4975]), so MSRP implementations are expected to allow unrecognized transports, provided that they do not have to establish a direct connection to the resource described by the URI.

「ws」トランスポートパラメータは、SDPの「パス」属性のエンドポイントURIに表示されます（[RFC4975]のセクション8.2を参照）。 MSRPは新しいトランスポートバインディングの可能性を考慮して設計されているため（[RFC4975]のセクション6を参照）、URIで記述されたリソースへの直接接続を確立する必要がない場合、MSRP実装は認識されないトランスポートを許可することが期待されます。

5.3. Updates to RFC 4976

5.3. RFC 4976の更新

5.3.1. AUTH Request Authentication

5.3.1. AUTHリクエスト認証

The MSRP relay specification [RFC4976] states that AUTH requests MUST be authenticated. This document modifies this requirement to state that all connections between MSRP clients and relays MUST be authenticated. In the case of the MSRP WebSocket Clients, there are three possible authentication mechanisms:

MSRPリレー仕様[RFC4976]には、AUTHリクエストを認証する必要があると記載されています。このドキュメントでは、この要件を変更して、MSRPクライアントとリレー間のすべての接続を認証する必要があると述べています。 MSRP WebSocketクライアントの場合、考えられる認証メカニズムは3つあります。

1. HTTP Digest authentication in AUTH (as per [RFC4976]).

1. AUTHでのHTTPダイジェスト認証（[RFC4976]による）。

2. Cookie-based or HTTP Digest authentication in the WebSocket Handshake (see Section 7).

2. WebSocketハンドシェイクでのCookieベースまたはHTTPダイジェスト認証（セクション7を参照）。

3. Mutual TLS between the WebSocket-based MSRP client and the WebSocket server.

3. WebSocketベースのMSRPクライアントとWebSocketサーバー間の相互TLS。

The AUTH request is a required event when authentication occurs at the WebSocket connection level since the "Use-Path:" header required to create the SDP offer is included in the 200 OK response to the AUTH request.

SDPオファーの作成に必要な「Use-Path：」ヘッダーがAUTH要求に対する200 OK応答に含まれているため、認証がWebSocket接続レベルで発生する場合、AUTH要求は必須のイベントです。

6. Connection Keepalive

6. 接続キープアライブ

It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their WebSocket connections open by sending periodic WebSocket "Ping" frames as described in Section 5.5.2 of [RFC6455].

[RFC6455]のセクション5.5.2で説明されているように、定期的なWebSocket「Ping」フレームを送信することにより、MSRP WebSocketクライアントとサーバーがWebSocket接続を開いたままにすることをお勧めします。

The WebSocket API [WS-API] does not provide a mechanism for applications running in a web browser to control whether or not periodic WebSocket "Ping" frames are sent to the server. The implementation of such a keepalive feature is the decision of each web browser manufacturer and may also depend on the configuration of the web browser.

WebSocket API [WS-API]は、Webブラウザーで実行されているアプリケーションが定期的なWebSocket「Ping」フレームをサーバーに送信するかどうかを制御するメカニズムを提供していません。このようなキープアライブ機能の実装は、各Webブラウザーの製造元の決定であり、Webブラウザーの構成にも依存する場合があります。

A future WebSocket protocol extension providing a similar keepalive mechanism could also be used.

同様のキープアライブメカニズムを提供する将来のWebSocketプロトコル拡張も使用できます。

When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping" frames to keep connections open, an MSRP implementation MAY use bodiless SEND requests as described in Section 7.1 of [RFC4975]. MSRP WebSocket Clients or Servers MUST be prepared to receive bodiless SEND requests.

MSRP WebSocketクライアントまたはサーバーがWebSocketの「Ping」フレームを使用して接続を開いたままにできない場合、MSRP実装は、[RFC4975]のセクション7.1で説明されているように、ボディレスSENDリクエストを使用できます。 MSRP WebSocketクライアントまたはサーバーは、ボディレスSENDリクエストを受信できるように準備する必要があります。

7. Authentication

7. 認証

Prior to sending MSRP requests, an MSRP WebSocket Client connects to an MSRP WebSocket Server and performs the connection handshake. As described in Section 3, the handshake procedure involves a HTTP GET method request from the Client and a response from the Server including an HTTP 101 status code.

MSRP要求を送信する前に、MSRP WebSocketクライアントはMSRP WebSocketサーバーに接続し、接続ハンドシェイクを実行します。セクション3で説明したように、ハンドシェイク手順には、クライアントからのHTTP GETメソッド要求と、HTTP 101ステータスコードを含むサーバーからの応答が含まれます。

In order to authorize the WebSocket connection, the MSRP WebSocket Server MAY inspect any HTTP headers present (for example, Cookie [RFC6265], Host [RFC7230], or Origin [RFC6454]) in the HTTP GET request. For many web applications, the value of such a Cookie is provided by the web server once the user has authenticated themselves to the web server, which could be done by many existing mechanisms. As an alternative method, the MSRP WebSocket Server could request HTTP authentication by replying to the Client's GET method request with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers this usage in Section 4.1 and is paraphrased as follows:

WebSocket接続を承認するために、MSRP WebSocketサーバーは、HTTP GETリクエストに存在するHTTPヘッダー（Cookie [RFC6265]、Host [RFC7230]、Origin [RFC6454]など）を検査してもよい（MAY）。多くのWebアプリケーションでは、ユーザーがWebサーバーに対して自分自身を認証すると、そのようなCookieの値がWebサーバーによって提供されます。これは、多くの既存のメカニズムで実行できます。別の方法として、MSRP WebSocketサーバーは、クライアントのGETメソッド要求にHTTP 401ステータスコードで応答することにより、HTTP認証を要求できます。 WebSocketプロトコル[RFC6455]はセクション4.1でこの使用法をカバーしており、次のように言い換えられます。

If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures; in particular, the client might perform authentication if it receives a 401 status code.

サーバーから受信したステータスコードが101でない場合、WebSocketクライアントスタックはHTTP [RFC7230]プロシージャごとに応答を処理します。特に、クライアントは、401ステータスコードを受け取った場合に認証を実行する可能性があります。

If the HTTP GET request contains an Origin header, the MSRP WebSocket Server SHOULD indicate Cross-Origin Resource Sharing [CORS] by adding an Access-Control-Allow-Origin header to the 101 response.

HTTP GET要求にOriginヘッダーが含まれている場合、MSRP WebSocketサーバーは、Access-Control-Allow-Originヘッダーを101応答に追加することにより、Cross-Origin Resource Sharing [CORS]を示す必要があります（SHOULD）。

Regardless of whether the MSRP WebSocket Server requires authentication during the WebSocket handshake, authentication MAY be requested at the MSRP protocol level by an MSRP Server challenging AUTH requests using a 401 response. Therefore, an MSRP WebSocket Client SHOULD support HTTP Digest [RFC7235] authentication as stated in [RFC4976].

MSRP WebSocketサーバーがWebSocketハンドシェイク中に認証を要求するかどうかに関係なく、認証は、401応答を使用してAUTH要求に挑戦するMSRPサーバーによってMSRPプロトコルレベルで要求される場合があります。したがって、MSRP WebSocketクライアントは、[RFC4976]で述べられているように、HTTP Digest [RFC7235]認証をサポートする必要があります（SHOULD）。

8. Examples

8. 例

8.1. Authentication

8.1. 認証

8.1.1. WebSocket Authentication

8.1.1. WebSocket認証

   Alice    (MSRP WSS)    a.example.com
   |                             |
   |HTTP GET (WS handshake) F1   |
   |---------------------------->|
   |101 Switching Protocols F2   |
   |<----------------------------|
   |                             |
   |AUTH F3                      |
   |---------------------------->|
   |200 OK F4                    |
   |<----------------------------|
   |                             |

Alice loads a web page using her web browser and retrieves JavaScript code implementing the WebSocket MSRP subprotocol defined in this document. The JavaScript code (an MSRP WebSocket Client) establishes a secure WebSocket connection with an MSRP relay (an MSRP WebSocket Server) at a.example.com. Upon WebSocket connection, Alice constructs and sends an MSRP AUTH request. Since the JavaScript stack in a browser has no way to determine the local address from which the WebSocket connection was made, this implementation uses a random ".invalid" domain name for the hostpart of the From-Path URI (see Appendix A).

アリスは彼女のWebブラウザーを使用してWebページをロードし、このドキュメントで定義されているWebSocket MSRPサブプロトコルを実装するJavaScriptコードを取得します。 JavaScriptコード（MSRP WebSocketクライアント）は、a.example.comでMSRPリレー（MSRP WebSocketサーバー）との安全なWebSocket接続を確立します。 WebSocket接続時に、AliceはMSRP AUTH要求を作成して送信します。ブラウザーのJavaScriptスタックにはWebSocket接続が行われたローカルアドレスを判別する方法がないため、この実装ではFrom-Path URIのホスト部分にランダムな「.invalid」ドメイン名を使用します（付録Aを参照）。

In this example, it is assumed that authentication is performed at the WebSocket layer (not shown), so no challenge is issued for the MSRP AUTH message:

この例では、認証はWebSocketレイヤー（図示せず）で実行されると想定されているため、MSRP AUTHメッセージに対してチャレンジは発行されません。

F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS)

F1 HTTP GET（WSハンドシェイク）アリス-> a.example.com（TLS）

   GET / HTTP/1.1
   Host: a.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: https://www.example.com
   Sec-WebSocket-Protocol: msrp
   Sec-WebSocket-Version: 13

F2 101 Switching Protocols a.example.com -> Alice (TLS)

F2 101スイッチングプロトコルa.example.com-> Alice（TLS）

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
   Sec-WebSocket-Protocol: msrp

F3 AUTH Alice -> a.example.com (transport WSS)

F3 AUTH Alice-> a.example.com（トランスポートWSS）

   MSRP 49fi AUTH
   To-Path: msrps://alice@a.example.com:443;ws
   From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   -------49fi$

F4 200 OK a.example.com -> Alice (transport WSS)

F4 200 OK a.example.com-> Alice（トランスポートWSS）

   MSRP 49fi 200 OK
   To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://alice@a.example.com:443;ws
   Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
   Expires: 900
   -------49fi$

8.1.2. MSRP Authentication

8.1.2. MSRP認証

   Alice    (MSRP WSS)     a.example.com
   |                             |
   |HTTP GET (WS handshake) F1   |
   |---------------------------->|
   |101 Switching Protocols F2   |
   |<----------------------------|
   |                             |
   |AUTH F3                      |
   |---------------------------->|
   |401 Unauthorized F4                    |
   |<----------------------------|
   |AUTH F5                      |
   |---------------------------->|
   |200 OK F6                    |
   |<----------------------------|
   |                             |

This example uses the same scenario as Section 8.1.1 but with authentication performed at the MSRP layer.

この例では、セクション8.1.1と同じシナリオを使用しますが、認証はMSRPレイヤーで実行されます。

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 MSRP message.

MSRPは行折りたたみを許可しないことに注意してください。例の「\」は、このドキュメントの行の長さの制限による行の継続を示しています。バックスラッシュも余分なCRLFも、実際のMSRPメッセージには含まれていません。

F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS)

F1 HTTP GET（WSハンドシェイク）アリス-> a.example.com（TLS）

   GET / HTTP/1.1
   Host: a.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: https://www.example.com
   Sec-WebSocket-Protocol: msrp
   Sec-WebSocket-Version: 13

F2 101 Switching Protocols a.example.com -> Alice (TLS)

F2 101スイッチングプロトコルa.example.com-> Alice（TLS）

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
   Sec-WebSocket-Protocol: msrp
   F3 AUTH  Alice -> a.example.com (transport WSS)

   MSRP 4rsxt9nz AUTH
   To-Path: msrps://alice@a.example.com:443;ws
   From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   -------4rsxt9nz$

F4 401 Unauthorized a.example.com -> Alice (transport WSS)

F4 401 Unauthorized a.example.com-> Alice（transport WSS）

   MSRP 4rsxt9nz 401 Unauthorized
   To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://alice@a.example.com:443;ws
   WWW-Authenticate: Digest realm="example.com", \
    nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", qop="auth"
   -------4rsxt9nz$

F5 AUTH Alice -> a.example.com (transport WSS)

F5 AUTH Alice-> a.example.com（トランスポートWSS）

   MSRP qy1hsow5 AUTH
   To-Path: msrps://alice@a.example.com:443;ws
   From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   Authorization: Digest username="alice", realm="example.com", \
    nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", \
    uri="msrps://alice@a.example.com:443;ws", \
    response="5011d0d58fe975e0d0cdc007ae26f4b7", \
    qop=auth, cnonce="zic5ml401prb", nc=00000001
   -------qy1hsow5$

F6 200 OK a.example.com -> Alice (transport WSS)

F6 200 OK a.example.com-> Alice（トランスポートWSS）

   MSRP qy1hsow5 200 OK
   To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://alice@a.example.com:443;ws
   Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
   Expires: 900
   -------qy1hsow5$

8.2. Example Session: MSRP WebSocket Client to MSRP Client

8.2. セッション例：MSRP WebSocketクライアントからMSRPクライアント

The following subsections show various message exchanges occurring during the course of an MSRP session between a WebSocket client and a non-WebSocket client.

以下のサブセクションでは、WebSocketクライアントと非WebSocketクライアント間のMSRPセッションの過程で発生するさまざまなメッセージ交換を示します。

8.2.1. SDP Exchange

8.2.1. SDP交換

The following example shows SDP that could be included in a SIP message to set up an MSRP session between Alice and Bob where Alice uses a WebSocket MSRP relay and Bob uses a traditional MSRP client without a relay.

次の例は、AliceとBob間のMSRPセッションを設定するためにSIPメッセージに含めることができるSDPを示しています。AliceはWebSocket MSRPリレーを使用し、Bobはリレーなしの従来のMSRPクライアントを使用します。

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 SDP.

例の「\」は、このドキュメントの行の長さの制限による行の継続を示しています。バックスラッシュも余分なCRLFも実際のSDPには含まれていません。

Alice makes an offer with a path including the relay (having already successfully authenticated with the relay):

アリスは、リレーを含むパスを使用してオファーを作成します（すでにリレーで正常に認証されています）。

   c=IN IP4 a.example.com
   m=message 1234 TCP/TLS/MSRP *
   a=accept-types:message/cpim text/plain text/html
   a=path:msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://df7jal23ls0d.invalid:2855/98cjs;ws

In this offer, Alice wishes to receive MSRP messages via the relay at a.example.com. She wants to use TLS as the transport for the MSRP session (beyond the relay). She can accept message/cpim, text/plain, and text/html message bodies in SEND requests.

このオファーでは、アリスはa.example.comのリレーを介してMSRPメッセージを受信したいと考えています。彼女は、MSRPセッションのトランスポートとして（リレーを超えて）TLSを使用したいと考えています。彼女は、SENDリクエストでメッセージ/ cpim、テキスト/プレーン、テキスト/ htmlメッセージ本文を受け入れることができます。

Bob's answer to this offer 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://bob.example.com:49154/foo;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 does not need a relay to set up the MSRP session.

ここで、ボブはbob.example.comでMSRPメッセージを受信したいと考えています。彼はSENDリクエストでメッセージ/ cpimおよびテキスト/プレーンメッセージの本文のみを受け入れることができ、アリスが提供するテキスト/ htmlコンテンツを拒否しました。 MSRPセッションを設定するためにリレーは必要ありません。

8.2.2. SEND (MSRP WebSocket Client to MSRP Client)

8.2.2. SEND（MSRP WebSocketクライアントからMSRPクライアントへ）

   Alice    (MSRP WSS)     a.example.com      (MSRP TLS)     Bob
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

Later in the session, Alice sends an instant message to Bob. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Bob over TLS.

セッションの後半で、アリスはボブにインスタントメッセージを送信します。 a.example.comにあるMSRP WebSocketサーバーは、MSRPリレーとして機能し、TLSを介してメッセージをボブにルーティングします。

Message details (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):

メッセージの詳細（例の「\」は、このドキュメントの行の長さに制限があるため、行が続くことを示しています。バックスラッシュも余分なCRLFも実際の要求または応答には含まれていません）：

F1 SEND Alice -> a.example.com (transport WSS)

F1 SEND Alice-> a.example.com（トランスポートWSS）

   MSRP 6aef SEND
   To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://bob.example.com:49154/foo;tcp
   From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Hi Bob, I'm about to send you file.mpeg
   -------6aef$

F2 200 OK a.example.com -> Alice (transport WSS)

F2 200 OK a.example.com-> Alice（トランスポートWSS）

   MSRP 6aef 200 OK
   To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://a.example.com:2855/jui787s2f;tcp
   -------6aef$
   F3 SEND  a.example.com -> Bob (transport TLS)

   MSRP juh76 SEND
   To-Path: msrps://bob.example.com:49154/foo;tcp
   From-Path:  msrps://a.example.com:2855/jui787s2f;tcp \
               msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Hi Bob, I'm about to send you file.mpeg
   -------juh76$

F4 200 OK Bob -> a.example.com (transport TLS)

F4 200 OK Bob-> a.example.com（トランスポートTLS）

   MSRP juh76 200 OK
   To-Path: msrps://a.example.com:2855/jui787s2f;tcp
   From-Path: msrps://bob.example.com:49154/foo;tcp
   -------juh76$

8.2.3. SEND (MSRP Client to MSRP WebSocket Client)

8.2.3. SEND（MSRPクライアントからMSRP WebSocketクライアントへ）

   Bob      (MSRP TLS)     a.example.com     (MSRP WSS)    Alice
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

Later in the session, Bob sends an instant message to Alice. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Alice over secure WebSocket.

セッションの後半で、ボブはインスタントメッセージをアリスに送信します。 a.example.comにあるMSRP WebSocketサーバーはMSRPリレーとして機能し、メッセージを安全なWebSocketを介してAliceにルーティングします。

F1 SEND Bob -> a.example.com (transport TLS)

F1 SEND Bob-> a.example.com（トランスポートTLS）

   MSRP xght6 SEND
   To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://bob.example.com:49154/foo;tcp
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Thanks for the file.
   -------xght6$

F2 200 OK a.example.com -> Bob (transport TLS)

F2 200 OK a.example.com-> Bob（トランスポートTLS）

   MSRP xght6 200 OK
   To-Path: msrps://bob.example.com:49154/foo;tcp
   From-Path: msrps://a.example.com:2855/jui787s2f;tcp
   -------xght6$

F3 SEND a.example.com -> Alice (transport WSS)

F3 SEND a.example.com-> Alice（トランスポートWSS）

   MSRP yh67 SEND
   To-Path:  msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path:  msrps://a.example.com:2855/jui787s2f;tcp \
               msrps://bob.example.com:49154/foo;tcp
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Thanks for the file.
   -------yh67$
   F4 200 OK  Alice -> a.example.com (transport WSS)

   MSRP yh67 200 OK
   To-Path:  msrps://a.example.com:2855/jui787s2f;tcp
   From-Path:  msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   -------yh67$

8.3. Example Session: Two MSRP WebSocket Clients

8.3. セッション例：2つのMSRP WebSocketクライアント

The following subsections show various message exchanges occurring during the course of an MSRP session between two WebSocket clients.

次のサブセクションでは、2つのWebSocketクライアント間のMSRPセッションの過程で発生するさまざまなメッセージ交換を示します。

8.3.1. SDP Exchange

8.3.1. SDP交換

The following example shows SDP that could be included in a SIP message to set up an MSRP session between Alice and Carol where both of them are using the same WebSocket MSRP relay.

次の例は、両方が同じWebSocket MSRPリレーを使用しているアリスとキャロルの間にMSRPセッションをセットアップするためにSIPメッセージに含めることができるSDPを示しています。

Alice makes an offer with a path including the relay (having already successfully authenticated with the relay):

アリスは、リレーを含むパスを使用してオファーを作成します（すでにリレーで正常に認証されています）。

   c=IN IP4 a.example.com
   m=message 1234 TCP/TLS/MSRP *
   a=accept-types:message/cpim text/plain text/html
   a=path:msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://df7jal23ls0d.invalid:2855/98cjs;ws

Carol's answer to this offer could look like:

この提案に対するキャロルの回答は次のようになります。

   c=IN IP4 a.example.com
   m=message 1234 TCP/TLS/MSRP *
   a=accept-types:message/cpim text/plain
   a=path:msrps://a.example.com:2855/iwnslt;tcp \
          msrps://jk9awp14vj8x.invalid:2855/76qwe;ws

Here, Carol also wishes to receive the MSRP messages via a.example.com. She can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice.

ここでは、Carolはa.example.com経由でMSRPメッセージを受信したいと考えています。彼女はSENDリクエストでメッセージ/ cpimおよびテキスト/プレーンメッセージの本文のみを受け入れることができ、アリスが提供するテキスト/ htmlコンテンツを拒否しました。

8.3.2. SEND

8.3.2. 送信

   Alice    (MSRP WSS)     a.example.com     (MSRP WSS)    Carol
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

Later in the session, Alice sends an instant message to Carol. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Carol over secure WebSocket.

セッションの後半で、アリスはインスタントメッセージをキャロルに送信します。 a.example.comにあるMSRP WebSocketサーバーはMSRPリレーとして機能し、メッセージを安全なWebSocket経由でキャロルにルーティングします。

In this example, both Alice and Carol are using MSRP WebSocket Clients and the same MSRP WebSocket Server. This means that a.example.com will appear twice in the To-Path in F1. a.example.com can either handle this internally or loop the MSRP SEND request back to itself as if it were two separate MSRP relays.

この例では、アリスとキャロルの両方がMSRP WebSocketクライアントと同じMSRP WebSocketサーバーを使用しています。これは、a.example.comがF1のTo-Pathに2回現れることを意味します。 a.example.comはこれを内部で処理するか、2つの別個のMSRPリレーであるかのようにMSRP SEND要求をループして自分自身に戻すことができます。

F1 SEND Alice -> a.example.com (transport WSS)

F1 SEND Alice-> a.example.com（トランスポートWSS）

   MSRP kjh6 SEND
   To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://a.example.com:2855/iwnslt;tcp \
            msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
   From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Carol, I sent that file to Bob.
   -------kjh6$
   F2 200 OK  a.example.com -> Alice (transport WSS)

   MSRP kjh6 200 OK
   To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://a.example.com:2855/jui787s2f;tcp
   -------kjh6$

F3 SEND a.example.com -> Carol (transport WSS)

F3 SEND a.example.com-> Carol（トランスポートWSS）

   MSRP re58 SEND
   To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
   From-Path: msrps://a.example.com:2855/iwnslt;tcp \
              msrps://a.example.com:2855/jui787s2f;tcp \
              msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Carol, I sent that file to Bob.
   -------re58$

F4 200 OK Carol -> a.example.com (transport WSS)

F4 200 OK Carol-> a.example.com（トランスポートWSS）

   MSRP re58 200 OK
   To-Path: msrps://a.example.com:2855/iwnslt;tcp
   From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
   -------re58$

8.4. Example Session: MSRP WebSocket Client to MSRP Client Using a Relay

8.4. セッション例：リレーを使用したMSRP WebSocketクライアントからMSRPクライアントへ

The following subsections show various message exchanges occurring during the course of an MSRP session between a WebSocket client and a non-WebSocket client, where the latter is also using an MSRP relay.

次のサブセクションでは、WebSocketクライアントと非WebSocketクライアントの間のMSRPセッションの過程で発生するさまざまなメッセージ交換を示します。非WebSocketクライアントは、MSRPリレーも使用しています。

8.4.1. SDP Exchange

8.4.1. SDP交換

次の例は、AliceとBobの間のMSRPセッションをセットアップするためにSIPメッセージに含めることができるSDPを示しています。AliceはWebSocket MSRPリレーを使用し、Bobは従来のMSRPクライアントと別のリレーを使用します。

Alice makes an offer with a path including the relay (having already successfully authenticated with the relay):

アリスは、リレーを含むパスを使用してオファーを作成します（すでにリレーで正常に認証されています）。

   c=IN IP4 a.example.com
   m=message 1234 TCP/TLS/MSRP *
   a=accept-types:message/cpim text/plain text/html
   a=path:msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://df7jal23ls0d.invalid:2855/98cjs;ws

Bob's answer to this offer 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.net:2855/kwvin5f;tcp \
          msrps://bob.example.com:49154/foo;tcp

Here, Bob wishes to receive the MSRP messages via the relay at relay.example.net. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice.

ここで、ボブはrelay.example.netでリレーを介してMSRPメッセージを受信したいと考えています。彼はSENDリクエストでメッセージ/ cpimおよびテキスト/プレーンメッセージの本文のみを受け入れることができ、アリスが提供するテキスト/ htmlコンテンツを拒否しました。

8.4.2. SEND

8.4.2. 送信

   Alice (MSRP WSS) a.example.com (MSRP) relay.example.net  (MSRP)   Bob
   |                      |                       |                    |
   |SEND F1               |                       |                    |
   |--------------------->|                       |                    |
   |200 OK F2             |                       |                    |
   |<---------------------|                       |                    |
   |                      |SEND F3                |                    |
   |                      |---------------------->|                    |
   |                      |200 OK F4              |                    |
   |                      |<----------------------|                    |
   |                      |                       |SEND F5             |
   |                      |                       |------------------->|
   |                      |                       |200 OK F6           |
   |                      |                       |<-------------------|

Later in the session, Alice sends an instant message to Bob. The MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing the message to Bob via his relay, relay.example.net.

セッションの後半で、アリスはボブにインスタントメッセージを送信します。 a.example.comにあるMSRP WebSocketサーバーは、MSRPリレーとして機能し、リレーrelay.example.netを介してボブにメッセージをルーティングします。

F1 SEND Alice -> a.example.com (transport WSS)

F1 SEND Alice-> a.example.com（トランスポートWSS）

   MSRP Ycwt SEND
   To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://relay.example.net:2855/kwvin5f;tcp \
            msrps://bob.example.com:49154/foo;tcp
   From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Bob, that was the wrong file - don't watch it!
   -------Ycwt$

F2 200 OK a.example.com -> Alice (transport WSS)

F2 200 OK a.example.com-> Alice（トランスポートWSS）

   MSRP Ycwt 200 OK
   To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
   From-Path: msrps://a.example.com:2855/jui787s2f;tcp
   -------Ycwt$

F3 SEND a.example.com -> relay.example.net (transport TLS)

F3 SEND a.example.com-> relay.example.net（トランスポートTLS）

   MSRP 13GA SEND
   To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
            msrps://bob.example.com:49154/foo;tcp
   From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
              msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Bob, that was the wrong file - don't watch it!
   -------13GA$
   F4 200 OK  relay.example.net -> a.example.com (transport TLS)

   MSRP 13GA 200 OK
   To-Path: msrps://a.example.com:2855/iwnslt;tcp
   From-Path: msrps://relay.example.net:2855/kwvin5f;tcp
   -------13GA$

F5 SEND relay.example.net -> bob.example.com (transport TLS)

F5 SEND relay.example.net-> bob.example.com（トランスポートTLS）

   MSRP kXeg SEND
   To-Path: msrps://bob.example.com:49154/foo;tcp
   From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
              msrps://a.example.com:2855/jui787s2f;tcp \
              msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Bob, that was the wrong file - don't watch it!
   -------kXeg$

F6 200 OK bob.example.com -> relay.example.net (transport TLS)

F6 200 OK bob.example.com-> relay.example.net（トランスポートTLS）

   MSRP kXeg 200 OK
   To-Path: msrps://relay.example.net:2855/kwvin5f;tcp
   From-Path: msrps://bob.example.com:49154/foo;tcp
   -------kXeg$

9. Security Considerations

9. セキュリティに関する考慮事項

MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP).

WebSocketを介して転送されるMSRPトラフィックは、セキュアなWebSocket接続を使用して保護する必要があります（TCPを介したTLS [RFC5246]を使用）。

When establishing a connection using MSRP over secure WebSockets, the client MUST authenticate the server using the server's certificate according to the WebSocket validation procedure in [RFC6455].

セキュアなWebSocketを介してMSRPを使用して接続を確立する場合、クライアントは[RFC6455]のWebSocket検証手順に従ってサーバーの証明書を使用してサーバーを認証する必要があります。

Any security considerations specific to the WebSocket protocol are detailed in the relevant specification [RFC6455] and are considered outside the scope of this document. The certificate name matching (described by [RFC6455]) and cryptosuite selection will be handled by the browser, and the browser's procedures will supersede those specified in [RFC4975].

WebSocketプロトコルに固有のセキュリティに関する考慮事項は、関連する仕様[RFC6455]に詳述されており、このドキュメントの範囲外と見なされます。証明書名の照合（[RFC6455]で説明）と暗号スイートの選択はブラウザによって処理され、ブラウザの手順は[RFC4975]で指定されている手順に優先します。

Since the TLS session is always terminated at the MSRP WebSocket Server and the WebSocket server can see the plain text, the MSRP client (browser) SHOULD NOT indicate end-to-end security to user.

TLSセッションは常にMSRP WebSocketサーバーで終了し、WebSocketサーバーはプレーンテキストを表示できるため、MSRPクライアント（ブラウザ）はユーザーにエンドツーエンドのセキュリティを示すべきではありません（SHOULD NOT）。

TLS, as used in this document, should follow the best current practices defined in [RFC7525].

このドキュメントで使用されているTLSは、[RFC7525]で定義されている現在のベストプラクティスに従う必要があります。

10. IANA Considerations

10. IANAに関する考慮事項

Per this specification, IANA has registered the WebSocket MSRP subprotocol in the "WebSocket Subprotocol Name Registry" with the following data:

この仕様に従って、IANAはWebSocket MSRPサブプロトコルを「WebSocketサブプロトコル名レジストリ」に次のデータで登録しました。

Subprotocol Identifier: msrp

サブプロトコル識別子：msrp

Subprotocol Common Name: WebSocket Transport for MSRP (Message Session Relay Protocol)

サブプロトコルの一般名：MSRP（メッセージセッションリレープロトコル）のWebSocketトランスポート

Subprotocol Definition: RFC 7977

サブプロトコル定義：RFC 7977

Reference: RFC 7977

リファレンス：RFC 7977

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.

[RFC4975] Campbell、B.、Ed。、Mahy、R.、Ed。、and C. Jennings、Ed。、 "The Message Session Relay Protocol（MSRP）"、RFC 4975、DOI 10.17487 / RFC4975、September 2007、< http://www.rfc-editor.org/info/rfc4975>。

[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <http://www.rfc-editor.org/info/rfc4976>.

[RFC4976] Jennings、C.、Mahy、R。、およびA. Roach、「Relay Extensions for the Message Sessions Relay Protocol（MSRP）」、RFC 4976、DOI 10.17487 / RFC4976、2007年9月、<http：// www。 rfc-editor.org/info/rfc4976>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。

[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <http://www.rfc-editor.org/info/rfc6455>.

[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<http://www.rfc-editor.org/info/rfc6455>。

11.2. Informative References

11.2. 参考引用

[CORS] van Kesteren, A., Ed., "Cross-Origin Resource Sharing", W3C Recommendation, January 2014, <http://www.w3.org/TR/2014/REC-cors-20140116/>.

[CORS] van Kesteren、A。、編、「Cross-Origin Resource Sharing」、W3C勧告、2014年1月、<http://www.w3.org/TR/2014/REC-cors-20140116/>。

[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <http://www.rfc-editor.org/info/rfc2606>.

[RFC2606] Eastlake 3rd、D。およびA. Panitz、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、DOI 10.17487 / RFC2606、1999年6月、<http://www.rfc-editor.org/info/ rfc2606>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.

[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<http://www.rfc-editor.org/info/rfc6265>。

[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.

[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<http://www.rfc-editor.org/info/rfc6454>。

[RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/RFC6714, August 2012, <http://www.rfc-editor.org/info/rfc6714>.

[RFC6714] Holmberg、C.、Blau、S。、およびE. Burger、「メッセージセッションリレープロトコル（MSRP）のMedia Anchoring（CEMA）の接続確立」、RFC 6714、DOI 10.17487 / RFC6714、2012年8月、< http://www.rfc-editor.org/info/rfc6714>。

[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", RFC 7118, DOI 10.17487/RFC7118, January 2014, <http://www.rfc-editor.org/info/rfc7118>.

[RFC7118] Baz Castillo、I.、Millan Villegas、J。、およびV. Pascual、「Session Initiation Protocol（SIP）のトランスポートとしてのWebSocketプロトコル」、RFC 7118、DOI 10.17487 / RFC7118、2014年1月、<http ：//www.rfc-editor.org/info/rfc7118>。

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.

[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。

[WS-API] Hickson, I., Ed., "The WebSocket API", W3C Candidate Recommendation, September 2012, <https://www.w3.org/TR/2012/CR-websockets-20120920/>.

[WS-API] Hickson、I.、Ed。、 "The WebSocket API"、W3C Candidate Recommendation、September 2012、<https://www.w3.org/TR/2012/CR-websockets-20120920/>。

Appendix A. Implementation Guidelines: MSRP WebSocket Client Considerations

付録A.実装ガイドライン：MSRP WebSocketクライアントの考慮事項

The JavaScript stack in web browsers does not have the ability to discover the local transport address used for originating WebSocket connections. Therefore, the MSRP WebSocket Client constructs a domain name consisting of a random token followed by the ".invalid" top-level domain name, as stated in [RFC2606], and uses it within its From-Path headers.

WebブラウザーのJavaScriptスタックには、発信元のWebSocket接続に使用されるローカルトランスポートアドレスを検出する機能がありません。したがって、MSRP WebSocketクライアントは、[RFC2606]に記載されているように、ランダムトークンと「.invalid」トップレベルドメイン名が続くドメイン名を作成し、それをFrom-Pathヘッダー内で使用します。

The From-Path URI provided by MSRP clients that use an MSRP relay is not used for routing MSRP messages, thus, it is safe to set a random domain in the hostpart of the From-Path URI.

MSRPリレーを使用するMSRPクライアントによって提供されるFrom-Path URIはMSRPメッセージのルーティングに使用されないため、From-Path URIのホスト部分にランダムドメインを設定しても安全です。

Acknowledgements

謝辞

Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and Victor Pascual, the authors of [RFC7118], which has inspired this document.

[RFC7118]の著者であるInaki Baz Castillo、Jose Luis Millan Villegas、およびVictor Pascualに特に感謝します。

Additional thanks to Inaki Baz Castillo, who pointed out that "web browser" shouldn't be used all the time, as this specification should be valid for smartphones and apps other than browsers and suggested clarifications to the SDP handling for MSRP over WebSocket.

さらに、この仕様はブラウザ以外のスマートフォンやアプリで有効であり、WebSocket over MSRPのSDP処理の明確化が提案されているため、「Webブラウザ」は常に使用するべきではないと指摘したInaki Baz Castilloに感謝します。

Special thanks to James Wyatt from Crocodile RCS Ltd for helping with the JavaScript MSRP-over-WebSockets prototyping.

JavaScript MSRP-over-WebSocketsプロトタイピングを支援してくれたCrocodile RCS LtdのJames Wyattに特に感謝します。

Special thanks to Anton Roman who has contributed to this document.

この文書に貢献してくれたAnton Romanに特に感謝します。

Thanks to Saul Ibarra Corretge for suggesting that the existing MSRP keepalive mechanism may be used when WebSocket pings are not available.

WebSocket pingが使用できない場合に既存のMSRPキープアライブメカニズムを使用できることを示唆してくれたSaul Ibarra Corretgeに感謝します。

Thanks to Ben Campbell, Inaki Baz Castillo, Keith Drage, Olle Johansson, and Christer Holmberg for their thoughtful discussion comments and review feedback that led to the improvement of this document. Special thanks to Mary Barnes for both her technical review and for offering to act as Document Shepherd. Thanks also to Stephen Farrell, Alissa Cooper, Mirja Kuehlewind, Allison Mankin, Alexey Melnikov, and Kathleen Moriarty for their review comments.

このドキュメントの改善につながる思慮深いディスカッションコメントとレビューフィードバックを提供してくれたBen Campbell、Inaki Baz Castillo、Keith Drage、Olle Johansson、Christer Holmbergに感謝します。メアリーバーンズの技術レビューとドキュメントシェパードとしての機能の提供の両方に特に感謝します。レビューコメントを提供してくれたStephen Farrell、Alissa Cooper、Mirja Kuehlewind、Allison Mankin、Alexey Melnikov、Kathleen Moriartyにも感謝します。

Authors' Addresses

著者のアドレス

Peter Dunkley Xura Lancaster Court 8 Barnes Wallis Road Fareham PO15 5TU United Kingdom

Peter Dunkley Xura Lancaster Court 8 Barnes Wallis Road Fareham PO15 5TUイギリス

   Email: peter.dunkley@xura.com

Gavin Llewellyn Xura Lancaster Court 8 Barnes Wallis Road Fareham PO15 5TU United Kingdom

Gavin Llewellyn Xura Lancaster Court 8 Barnes Wallis Road Fareham PO15 5TUイギリス

   Email: gavin.llewellyn@xura.com

Victor Pascual Oracle

ビクターパスクアルオラクル

   Email: victor.pascual.avila@oracle.com

Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America

Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国

   Email: gsalguei@cisco.com

Ram Mohan Ravindranath Cisco Systems, Inc.

Ram Mohan Rabindranath Cisco Systems、vol。

   Email: rmohanr@cisco.com

RFC 7977 - The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) 日本語訳

1. Introduction

1. はじめに

2. Terminology

2. 用語

2.1. Definitions

2.1. 定義

3. WebSocket Protocol Overview

3. WebSocketプロトコルの概要

4. The WebSocket MSRP Subprotocol

4. WebSocket MSRPサブプロトコル

4.1. Handshake

4.1. ハンドシェーク

4.2. MSRP Encoding

4.2. MSRPエンコーディング

5. MSRP WebSocket Transport

5. MSRP WebSocketトランスポート

5.1. General

5.1. 一般的な

5.2. Updates to RFC 4975

5.2. RFC 4975の更新

5.2.1. MSRP URI Transport Parameter

5.2.1. ＭＳＲＰ うり Ｔらんｓぽｒｔ ぱらめてｒ

5.2.2. SDP Transport Protocol

5.2.2. SDPトランスポートプロトコル

5.3. Updates to RFC 4976

5.3. RFC 4976の更新

5.3.1. AUTH Request Authentication

5.3.1. AUTHリクエスト認証

6. Connection Keepalive

6. 接続キープアライブ

7. Authentication

7. 認証

8. Examples

8. 例

8.1. Authentication

8.1. 認証

8.1.1. WebSocket Authentication

8.1.1. WebSocket認証

8.1.2. MSRP Authentication

8.1.2. MSRP認証

8.2. Example Session: MSRP WebSocket Client to MSRP Client

8.2. セッション例：MSRP WebSocketクライアントからMSRPクライアント

8.2.1. SDP Exchange

8.2.1. SDP交換

8.2.2. SEND (MSRP WebSocket Client to MSRP Client)

8.2.2. SEND（MSRP WebSocketクライアントからMSRPクライアントへ）

8.2.3. SEND (MSRP Client to MSRP WebSocket Client)

8.2.3. SEND（MSRPクライアントからMSRP WebSocketクライアントへ）

8.3. Example Session: Two MSRP WebSocket Clients

8.3. セッション例：2つのMSRP WebSocketクライアント

8.3.1. SDP Exchange

8.3.1. SDP交換

8.3.2. SEND

8.3.2. 送信

8.4.1. SDP Exchange

8.4.1. SDP交換

8.4.2. SEND

8.4.2. 送信

9. Security Considerations

9. セキュリティに関する考慮事項

10. IANA Considerations

10. IANAに関する考慮事項

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

11.2. Informative References

11.2. 参考引用

5.2.1. ＭＳＲＰうりＴらんｓぽｒｔぱらめてｒ