[要約] RFC 4975は、メッセージセッションリレープロトコル（MSRP）に関する仕様であり、メッセージのセッションベースのリレーを提供することを目的としています。MSRPは、リアルタイムのメッセージングアプリケーションで使用され、メッセージの送信と受信を効率的に行うためのプロトコルです。
Network Working Group B. Campbell, Ed.
Request for Comments: 4975 Estacado Systems
Category: Standards Track R. Mahy, Ed.
Plantronics
C. Jennings, Ed.
Cisco Systems, Inc.
September 2007
The Message Session Relay Protocol (MSRP)
メッセージセッションリレープロトコル（MSRP）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
このドキュメントでは、セッションのコンテキストで一連の関連するインスタントメッセージを送信するためのプロトコルであるメッセージセッションリレープロトコルについて説明します。メッセージセッションは、セッション開始プロトコルなどのランデブーまたはセッション作成プロトコルを介して設定された場合、他のメディアストリームと同様に扱われます。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Applicability of MSRP ...........................................5
4. Protocol Overview ...............................................6
5. Key Concepts ....................................................9
5.1. MSRP Framing and Message Chunking ..........................9
5.2. MSRP Addressing ...........................................10
5.3. MSRP Transaction and Report Model .........................11
5.4. MSRP Connection Model .....................................12
6. MSRP URIs ......................................................14
6.1. MSRP URI Comparison .......................................15
6.2. Resolving MSRP Host Device ................................16
7. Method-Specific Behavior .......................................17
7.1. Constructing Requests .....................................17
7.1.1. Sending SEND Requests ..............................18
7.1.2. Sending REPORT Requests ............................21
7.1.3. Generating Success Reports .........................22
7.1.4. Generating Failure Reports .........................23
7.2. Constructing Responses ....................................24
7.3. Receiving Requests ........................................25
7.3.1. Receiving SEND Requests ............................25
7.3.2. Receiving REPORT Requests ..........................27
8. Using MSRP with SIP and SDP ....................................27
8.1. SDP Connection and Media-Lines ............................28
8.2. URI Negotiations ..........................................29
8.3. Path Attributes with Multiple URIs ........................30
8.4. Updated SDP Offers ........................................31
8.5. Connection Negotiation ....................................31
8.6. Content Type Negotiation ..................................32
8.7. Example SDP Exchange ......................................34
8.8. MSRP User Experience with SIP .............................35
8.9. SDP Direction Attribute and MSRP ..........................35
9. Formal Syntax ..................................................36
10. Response Code Descriptions ....................................38
10.1. 200 ......................................................38
10.2. 400 ......................................................38
10.3. 403 ......................................................38
10.4. 408 ......................................................39
10.5. 413 ......................................................39
10.6. 415 ......................................................39
10.7. 423 ......................................................39
10.8. 481 ......................................................39
10.9. 501 ......................................................39
10.10. 506 .....................................................40
11. Examples ......................................................40
11.1. Basic IM Session .........................................40
11.2. Message with XHTML Content ...............................42
11.3. Chunked Message ..........................................43
11.4. Chunked Message with Message/CPIM Payload ................43
11.5. System Message ...........................................44
11.6. Positive Report ..........................................44
11.7. Forked IM ................................................45
12. Extensibility .................................................48
13. CPIM Compatibility ............................................48
14. Security Considerations .......................................49
14.1. Secrecy of the MSRP URI ..................................50
14.2. Transport Level Protection ...............................50
14.3. S/MIME ...................................................51
14.4. Using TLS in Peer-to-Peer Mode ...........................52
14.5. Other Security Concerns ..................................53
15. IANA Considerations ...........................................55
15.1. MSRP Method Names ........................................55
15.2. MSRP Header Fields .......................................55
15.3. MSRP Status Codes ........................................56
15.4. MSRP Port ................................................56
15.5. URI Schema ...............................................56
15.5.1. MSRP Scheme .......................................56
15.5.2. MSRPS Scheme ......................................57
15.6. SDP Transport Protocol ...................................57
15.7. SDP Attribute Names ......................................58
15.7.1. Accept Types ......................................58
15.7.2. Wrapped Types .....................................58
15.7.3. Max Size ..........................................58
15.7.4. Path ..............................................58
16. Contributors and Acknowledgments ..............................59
17. References ....................................................59
17.1. Normative References .....................................59
17.2. Informative References ...................................60
A series of related instant messages between two or more parties can be viewed as part of a "message session", that is, a conversational exchange of messages with a definite beginning and end. This is in contrast to individual messages each sent independently. Messaging schemes that track only individual messages can be described as "page-mode" messaging, whereas messaging that is part of a "session" with a definite start and end is called "session-mode" messaging.
2つ以上のパーティー間の一連の関連するインスタントメッセージは、「メッセージセッション」の一部、つまり、明確な始まりと終わりを備えた会話のメッセージの交換です。これは、それぞれ独立して送信された個々のメッセージとは対照的です。個々のメッセージのみを追跡するメッセージングスキームは「ページモード」メッセージングとして説明できますが、明確な開始と終了を持つ「セッション」の一部であるメッセージは「セッションモード」メッセージングと呼ばれます。
Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method [22]. Session-mode messaging has a number of benefits over page-mode messaging, however, such as explicit rendezvous, tighter integration with other media-types, direct client-to-client operation, and brokered privacy and security.
SIP [4]メッセージメソッド[22]を介して、SIPでページモードメッセージングが有効になります。セッションモードメッセージングには、明示的なランデブー、他のメディアタイプとのより緊密な統合、直接クライアントからクライアントへの操作、ブローカープライバシーとセキュリティなど、ページモードメッセージングよりも多くの利点があります。
This document defines a session-oriented instant message transport protocol called the Message Session Relay Protocol (MSRP), whose sessions can be negotiated with an offer or answer [3] using the Session Description Protocol (SDP) [2]. The exchange is carried by some signaling protocol, such as SIP [4]. This allows a communication user agent to offer a messaging session as one of the possible media-types in a session. For instance, Alice may want to communicate with Bob. Alice doesn't know at the moment whether Bob has his phone or his IM client handy, but she's willing to use either. She sends an invitation to a session to the address of record she has for Bob, sip:bob@example.com. Her invitation offers both voice and an IM session. The SIP services at example.com forward the invitation to Bob at his currently registered clients. Bob accepts the invitation at his IM client, and they begin a threaded chat conversation.
このドキュメントでは、メッセージセッションリレープロトコル（MSRP）と呼ばれるセッション指向のインスタントメッセージトランスポートプロトコルを定義します。セッション説明プロトコル（SDP）[2]を使用して、セッションをオファーまたは回答[3]と交渉できます。交換は、SIP [4]などのいくつかのシグナル伝達プロトコルによって運ばれます。これにより、通信ユーザーエージェントは、セッションで可能なメディアタイプの1つとしてメッセージングセッションを提供できます。たとえば、アリスはボブとコミュニケーションをとりたいと思うかもしれません。アリスは現時点では、ボブが彼の電話を持っているのか、それとも彼のIMクライアントが手元にあるのかを知りませんが、彼女はどちらも喜んで使用しています。彼女は、ボブ、sip：bob@example.comのために持っているレコードの住所にセッションへの招待状を送ります。彼女の招待状は、声とIMセッションの両方を提供します。Example.comのSIPサービスは、現在登録されているクライアントにBobへの招待を転送します。ボブは彼のIMクライアントへの招待状を受け入れ、彼らはスレッドチャットの会話を始めます。
When a user uses an Instant Messaging (IM) URL, RFC 3861 [32] defines how DNS can be used to map this to a particular protocol to establish the session such as SIP. SIP can use an offer/answer model to transport the MSRP URIs for the media in SDP. This document defines how the offer/answer exchange works to establish MSRP connections and how messages are sent across the MSRP, but it does not deal with the issues of mapping an IM URL to a session establishment protocol.
ユーザーがインスタントメッセージング（IM）URLを使用すると、RFC 3861 [32]は、DNSを使用してこれを特定のプロトコルにマッピングする方法を定義して、SIPなどのセッションを確立する方法を定義します。SIPは、SDPのメディア用にMSRP URIを輸送するために、オファー/回答モデルを使用できます。このドキュメントでは、MSRP接続を確立するためのオファー/回答の交換がどのように機能し、MSRP全体でメッセージが送信される方法を定義しますが、IM URLをセッション確立プロトコルにマッピングする問題を扱っていません。
This session model allows message sessions to be integrated into advanced communications applications with little to no additional protocol development. For example, during the above chat session, Bob decides Alice really needs to be talking to Carol. Bob can transfer [21] Alice to Carol, introducing them into their own messaging session. Messaging sessions can then be easily integrated into call-center and dispatch environments using third-party call control [20] and conferencing [19] applications.
このセッションモデルにより、メッセージセッションを、追加のプロトコル開発をほとんどまたはまったくない高度な通信アプリケーションに統合できます。たとえば、上記のチャットセッションで、ボブはアリスが本当にキャロルと話す必要があると判断します。ボブは[21]アリスをキャロルに転送し、それらを自分のメッセージングセッションに紹介できます。メッセージングセッションは、サードパーティのコールコントロール[20]および会議[19]アプリケーションを使用して、コールセンターおよびディスパッチ環境に簡単に統合できます。
This document specifies MSRP behavior only for peer-to-peer sessions, that is, sessions crossing only a single hop. MSRP relay devices [23] (referred to herein as "relays") are specified in a separate document. An endpoint that implements this specification, but not the relay specification, will be unable to introduce relays into the message path, but will still be able to interoperate with peers that do use relays.
このドキュメントは、ピアツーピアセッションのみ、つまり1つのホップのみを越えるセッションに対してMSRPの動作を指定します。MSRPリレーデバイス[23]（ここでは「リレー」と呼ばれる）は、別のドキュメントで指定されています。リレー仕様ではなく、この仕様を実装するエンドポイントは、リレーをメッセージパスに導入することはできませんが、リレーを使用するピアと相互運用することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [5]に記載されているように解釈される。
This document consistently refers to a "message" as a complete unit of MIME or text content. In some cases, a message is split and delivered in more than one MSRP request. Each of these portions of the complete message is called a "chunk".
このドキュメントは、一貫して「メッセージ」をmimeまたはテキストコンテンツの完全な単位と呼んでいます。場合によっては、メッセージが分割され、複数のMSRPリクエストで配信されます。完全なメッセージのこれらの各部分は、「チャンク」と呼ばれます。
MSRP is not designed for use as a standalone protocol. MSRP MUST be used only in the context of a rendezvous mechanism meeting the following requirements:
MSRPは、スタンドアロンプロトコルとして使用するようには設計されていません。MSRPは、次の要件を満たすランデブーメカニズムのコンテキストでのみ使用する必要があります。
o The rendezvous mechanism MUST provide both MSRP URIs associated with an MSRP session to each of the participating endpoints. The rendezvous mechanism MUST implement mechanisms to protect the confidentiality of these URIs -- they MUST NOT be made available to an untrusted third party or be easily discoverable.
o ランデブーメカニズムは、参加している各エンドポイントにMSRPセッションに関連付けられたMSRP URIの両方を提供する必要があります。ランデブーメカニズムは、これらのURIの機密性を保護するためのメカニズムを実装する必要があります。信頼されていない第三者が利用できるようにするか、簡単に発見できるようにしてはなりません。
o The rendezvous mechanism MUST provide mechanisms for the negotiation of any supported MSRP extensions that are not backwards compatible.
o ランデブーメカニズムは、後方互換ではないサポートされているMSRP拡張機能の交渉のメカニズムを提供する必要があります。
o The rendezvous mechanism MUST be able to natively transport im: URIs or automatically translate im: URIs [27] into the addressing identifiers of the rendezvous protocol.
o ランデブーのメカニズムは、im：urisをネイティブに輸送するか、自動的にim：uris [27]をランデブープロトコルのアドレス指定識別子に変換できる必要があります。
To use a rendezvous mechanism with MSRP, an RFC MUST be prepared that describes how it exchanges MSRP URIs and meets these requirements listed here. This document provides such a description for the use of MSRP in the context of SIP and SDP.
MSRPを使用したランデブーメカニズムを使用するには、MSRP URIを交換し、ここにリストされているこれらの要件を満たす方法を説明するRFCを準備する必要があります。このドキュメントは、SIPとSDPのコンテキストでMSRPを使用するためのこのような説明を提供します。
SIP meets these requirements for a rendezvous mechanism. The MSRP URIs are exchanged using SDP in an offer/answer exchange via SIP.
SIPは、ランデブーメカニズムのこれらの要件を満たしています。MSRP URIは、SIPを介してオファー/回答交換でSDPを使用して交換されます。
The exchanged SDP can also be used to negotiate MSRP extensions. This SDP can be secured using any of the mechanisms available in SIP, including using the sips mechanism to ensure transport security across intermediaries and Secure/Multipurpose Internet Mail Extensions (S/MIME) for end-to-end protection of the SDP body. SIP can carry arbitrary URIs (including im: URIs) in the Request-URI, and procedures are available to map im: URIs to sip: or sips: URIs. It is expected that initial deployments of MSRP will use SIP as its rendezvous mechanism.
交換されたSDPを使用して、MSRP拡張機能をネゴシエートすることもできます。このSDPは、SIPメカニズムを使用して仲介者間のセキュリティを保証し、SDPボディのエンドツーエンドの保護のためにインターネットメールエクステンション（S/MIME）を安全/多目的に保護するなど、SIPで利用可能なメカニズムのいずれかを使用して保護できます。SIPは、リクエスト-URIで任意のuris（im：urisを含む）を運ぶことができ、手順を使用できます。MSRPの初期展開は、そのランデブーメカニズムとしてSIPを使用することが予想されます。
MSRP is a text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME [8] content, especially instant messages. This section is a non-normative overview of how MSRP works and how it is used with SIP.
MSRPは、任意の（バイナリ）MIME [8]コンテンツ、特にインスタントメッセージを交換するためのテキストベースの接続指向プロトコルです。このセクションは、MSRPの仕組みとSIPで使用する方法の非規範的な概要です。
MSRP sessions are typically arranged using SIP the same way a session of audio or video media is set up. One SIP user agent (Alice) sends the other (Bob) a SIP invitation containing an offered session-description that includes a session of MSRP. The receiving SIP user agent can accept the invitation and include an answer session-description that acknowledges the choice of media. Alice's session description contains an MSRP URI that describes where she is willing to receive MSRP requests from Bob, and vice versa. (Note: Some lines in the examples are removed for clarity and brevity.)
通常、MSRPセッションは、オーディオまたはビデオメディアのセッションが設定されているのと同じように、SIPを使用して配置されます。1つのSIPユーザーエージェント（Alice）は、MSRPのセッションを含む提供されているセッションデスプレイションを含むSIP招待状を他のSIP（ボブ）に送信します。受信SIPユーザーエージェントは、招待状を受け入れ、メディアの選択を認める回答セッション説明を含めることができます。Aliceのセッションの説明には、BobからMSRPリクエストを受け取る場所を説明するMSRP URIが含まれています。（注：例のいくつかの行は、明確さと簡潔さのために削除されます。）
Alice sends to Bob:
アリスはボブに送ります：
INVITE sip:bob@biloxi.example.com SIP/2.0
To: <sip:bob@biloxi.example.com>
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
c=IN IP4 atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp
Bob sends to Alice:
ボブはアリスに送ります：
SIP/2.0 200 OK
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp
c=IN IP4 biloxi.example.com
m=message 12763 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
Alice sends to Bob:
アリスはボブに送ります：
ACK sip:bob@biloxi SIP/2.0
To: <sip:bob@biloxi.example.com>;tag=087js
From: <sip:alice@atlanta.example.com>;tag=786
Call-ID: 3413an89KU
Figure 1: Session Setup
図1：セッションのセットアップ
MSRP defines two request types, or methods. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message), while REPORT requests report on the status of a previously sent message, or a range of bytes inside a message. When Alice receives Bob's answer, she checks to see if she has an existing connection to Bob. If not, she opens a new connection to Bob using the URI he provided in the SDP. Alice then delivers a SEND request to Bob with her initial message, and Bob replies indicating that Alice's request was received successfully.
MSRPは、2つの要求タイプまたはメソッドを定義します。送信リクエストは、完全なメッセージまたはチャンク（完全なメッセージの一部）を配信するために使用され、レポートは以前に送信されたメッセージのステータス、またはメッセージ内のバイトの範囲に関するレポートをリクエストします。アリスがボブの答えを受け取ると、彼女はボブとの既存のつながりがあるかどうかを確認します。そうでない場合、彼女はSDPで提供されたURIを使用してBOBへの新しいつながりを開きます。その後、アリスは最初のメッセージでボブに送信要求を届け、ボブはアリスの要求が正常に受信されたことを示すと答えます。
MSRP a786hjs2 SEND
To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 87652491
Byte-Range: 1-25/25
Content-Type: text/plain
Hey Bob, are you there?
-------a786hjs2$
MSRP a786hjs2 200 OK
To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
-------a786hjs2$
Figure 2: Example MSRP Exchange
図2：MSRP交換の例
Alice's request begins with the MSRP start line, which contains a transaction identifier that is also used for request framing. Next she includes the path of URIs to the destination in the To-Path header field, and her own URI in the From-Path header field. In this typical case, there is just one "hop", so there is only one URI in each path header field. She also includes a message ID, which she can use to correlate status reports with the original message. Next she puts the actual content. Finally, she closes the request with an end-line of seven hyphens, the transaction identifier, and a "$" to indicate that this request contains the end of a complete message.
アリスの要求は、リクエストフレーミングにも使用されるトランザクション識別子を含むMSRPスタートラインから始まります。次に、彼女は、トーパスヘッダーフィールドの目的地へのウリスの道と、フロマスからのヘッダーフィールドに彼女自身のURIを含めます。この典型的なケースでは、「ホップ」が1つだけあるため、各パスヘッダーフィールドにURIが1つだけです。また、メッセージIDも含まれており、ステータスレポートを元のメッセージと相関させるために使用できます。次に、彼女は実際のコンテンツを置きます。最後に、彼女は7つのハイフン、トランザクション識別子、および「$」のエンドラインでリクエストを閉じ、この要求に完全なメッセージの終わりを含むことを示します。
If Alice wants to deliver a very large message, she can split the message into chunks and deliver each chunk in a separate SEND request. The message ID corresponds to the whole message, so the receiver can also use it to reassemble the message and tell which chunks belong with which message. Chunking is described in more detail in Section 5.1. The Byte-Range header field identifies the portion of the message carried in this chunk and the total size of the message.
アリスが非常に大きなメッセージを配信したい場合、彼女はメッセージをチャンクに分割し、各チャンクを別の送信要求で配信できます。メッセージIDはメッセージ全体に対応するため、受信者はそれを使用してメッセージを再組み立てし、どのチャンクがどのメッセージに属しているかを伝えることもできます。チャンキングについては、セクション5.1で詳しく説明します。バイト範囲のヘッダーフィールドは、このチャンクに掲載されたメッセージの部分とメッセージの合計サイズを識別します。
Alice can also specify what type of reporting she would like in response to her request. If Alice requests positive acknowledgments, Bob sends a REPORT request to Alice confirming the delivery of her complete message. This is especially useful if Alice sent a series of SEND requests containing chunks of a single message. More on requesting types of reports and errors is described in Section 5.3.
アリスは、彼女の要求に応じて、どのタイプのレポートを必要とするかを指定することもできます。アリスが肯定的な謝辞を要求した場合、ボブはアリスにレポートリクエストを送信し、完全なメッセージの配信を確認します。これは、アリスが単一のメッセージのチャンクを含む一連の送信要求を送信した場合に特に便利です。レポートとエラーの種類とエラーを要求するために、セクション5.3で説明します。
Alice and Bob choose their MSRP URIs in such a way that it is difficult to guess the exact URI. Alice and Bob can reject requests to URIs they are not expecting to service and can correlate the specific URI with the probable sender. Alice and Bob can also use TLS [1] to provide channel security over this hop. To receive MSRP requests over a TLS protected connection, Alice or Bob could advertise URIs with the "msrps" scheme instead of "msrp".
アリスとボブは、正確なURIを推測するのが難しいような方法でMSRP URIを選択します。アリスとボブは、サービスを期待していないURIへのリクエストを拒否することができ、特定のURIを可能性のある送信者と相関させることができます。アリスとボブは、TLS [1]を使用して、このホップでチャネルセキュリティを提供することもできます。TLS保護された接続でMSRP要求を受信するために、アリスまたはボブは「MSRP」ではなく「MSRP」スキームでURIを宣伝できます。
MSRP is designed with the expectation that MSRP can carry URIs for nodes on the far side of relays. For this reason, a URI with the "msrps" scheme makes no assertion about the security properties of other hops, just the next hop. The user agent knows the URI for each hop, so it can verify that each URI has the desired security properties.
MSRPは、MSRPがリレーの向こう側にノードにURIを運ぶことができるという期待を込めて設計されています。このため、「MSRPS」スキームを備えたURIは、他のホップのセキュリティプロパティ、次のホップについての主張をしません。ユーザーエージェントは、各ホップのURIを知っているため、各URIに目的のセキュリティプロパティがあることを確認できます。
MSRP URIs are discussed in more detail in Section 6.
MSRP URIについては、セクション6で詳しく説明します。
An adjacent pair of busy MSRP nodes (for example, two relays) can easily have several sessions, and exchange traffic for several simultaneous users. The nodes can use existing connections to carry new traffic with the same destination host, port, transport protocol, and scheme. MSRP nodes can keep track of how many sessions are using a particular connection and close these connections when no sessions have used them for some period of time. Connection management is discussed in more detail in Section 5.4.
隣接する忙しいMSRPノード（たとえば、2つのリレー）は、複数のセッションを簡単に行うことができ、複数の同時ユーザーとトラフィックを交換できます。ノードは、既存の接続を使用して、同じ宛先ホスト、ポート、輸送プロトコル、およびスキームを備えた新しいトラフィックを運ぶことができます。MSRPノードは、特定の接続を使用しているセッションの数を追跡し、セッションが一定期間使用されていない場合にこれらの接続を閉じます。接続管理については、セクション5.4で詳しく説明します。
Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the overall message. Long chunks may be interrupted in mid-transmission to ensure fairness across shared transport connections. To support this, MSRP uses a boundary-based framing mechanism. The start line of an MSRP request contains a unique identifier that is also used to indicate the end of the request. Included at the end of the end-line, there is a flag that indicates whether this is the last chunk of data for this message or whether the message will be continued in a subsequent chunk. There is also a Byte-Range header field in the request that indicates the overall position of this chunk inside the complete message.
MSRPを使用して送信されるメッセージは非常に大きく、いくつかの送信リクエストで配信できます。各送信リクエストには、メッセージ全体の1つのチャンクが含まれています。共有された輸送接続全体の公平性を確保するために、移行中の長いチャンクが中断される可能性があります。これをサポートするために、MSRPは境界ベースのフレーミングメカニズムを使用します。MSRPリクエストのスタート行には、リクエストの終了を示すためにも使用される一意の識別子が含まれています。エンドラインの終わりに含まれているため、これがこのメッセージの最後のデータの塊であるかどうか、またはその後のチャンクでメッセージが継続されるかどうかを示すフラグがあります。また、完全なメッセージ内部のこのチャンクの全体的な位置を示すバイトレンジヘッダーフィールドもリクエストにあります。
For example, the following snippet of two SEND requests demonstrates a message that contains the text "abcdEFGH" being sent as two chunks.
たとえば、次の2つの送信リクエストのスニペットは、2つのチャンクとして送信されているテキスト「abcdefgh」を含むメッセージを示しています。
MSRP dkei38sd SEND
Message-ID: 4564dpWd
Byte-Range: 1-*/8
Content-Type: text/plain
abcd
-------dkei38sd+
MSRP dkei38ia SEND
Message-ID: 4564dpWd
Byte-Range: 5-8/8
Content-Type: text/plain
EFGH
-------dkei38ia$
Figure 3: Breaking a Message into Chunks
図3：メッセージをチャンクに壊します
This chunking mechanism allows a sender to interrupt a chunk part of the way through sending it. The ability to interrupt messages allows multiple sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection, or even the same MSRP session. Any chunk that is larger than 2048 octets MUST be interruptible. While MSRP would be simpler to implement if each MSRP session used its own TCP connection, there are compelling reasons to conserve connections. For example, the TCP peer may be a relay device that connects to many other peers. Such a device will scale better if each peer does not create a large number of connections. (Note that in the above example, the initial chunk was interruptible for the sake of example, even though its size is well below the limit for which interruptibility would be required.)
このチャンキングメカニズムにより、送信者はそれを送信して塊の部分を中断することができます。メッセージを中断する機能により、複数のセッションがTCP接続を共有できるようになり、同じ接続、または同じMSRPセッションを共有する他のメッセージをブロックしないように、大きなメッセージを効率的に送信できます。2048オクテットを超えるチャンクは、中断可能でなければなりません。各MSRPセッションが独自のTCP接続を使用した場合、MSRPの実装は簡単ですが、接続を節約する説得力のある理由があります。たとえば、TCPピアは、他の多くのピアに接続するリレーデバイスである場合があります。このようなデバイスは、各ピアが多数の接続を作成しない場合、より良く縮小します。（上記の例では、そのサイズが中断性が必要な制限を大きく下回っているにもかかわらず、例のために初期チャンクは中断可能であったことに注意してください。）
The chunking mechanism only applies to the SEND method, as it is the only method used to transfer message content.
チャンキングメカニズムは、メッセージコンテンツを転送するために使用される唯一の方法であるため、送信方法にのみ適用されます。
MSRP entities are addressed using URIs. The MSRP URI schemes are defined in Section 6. The syntax of the To-Path and From-Path header fields each allows for a list of URIs. This was done to allow the protocol to work with relays, which are defined in a separate document, to provide a complete path to the end recipient. When two MSRP nodes communicate directly, they need only one URI in the To-Path list and one URI in the From-Path list.
MSRPエンティティは、URIを使用してアドレス指定されます。MSRP URIスキームは、セクション6で定義されています。To-PathおよびFrom-Pathヘッダーフィールドの構文は、それぞれURIのリストを許可します。これは、プロトコルが別のドキュメントで定義されているリレーで動作し、最終レシピエントへの完全なパスを提供できるようにするために行われました。2つのMSRPノードが直接通信する場合、To-Pathリストに1つのURIとPath From Pathリストに1つのURIのみが必要です。
A sender sends MSRP requests to a receiver. The receiver MUST quickly accept or reject the request. If the receiver initially accepted the request, it still may then do things that take significant time to succeed or fail. For example, if the receiver is an MSRP to Extensible Messaging and Presence Protocol (XMPP) [30] gateway, it may forward the message over XMPP. The XMPP side may later indicate that the request did not work. At this point, the MSRP receiver may need to indicate that the request did not succeed. There are two important concepts here: first, the hop-by-hop delivery of the request may succeed or fail; second, the end result of the request may or may not be successfully processed. The first type of status is referred to as "transaction status" and may be returned in response to a request. The second type of status is referred to as "delivery status" and may be returned in a REPORT transaction.
送信者は、MSRPリクエストをレシーバーに送信します。受信者は、リクエストを迅速に受け入れるか拒否する必要があります。受信者が最初にリクエストを受け入れた場合、それでも成功または失敗にかなりの時間がかかることを行う可能性があります。たとえば、受信機が拡張可能なメッセージと存在プロトコル（XMPP）[30]ゲートウェイのMSRPである場合、メッセージをXMPPに転送する場合があります。XMPP側は、後にリクエストが機能しなかったことを示している可能性があります。この時点で、MSRPレシーバーは、リクエストが成功しなかったことを示す必要がある場合があります。ここには2つの重要な概念があります。まず、リクエストのホップバイホップ配信が成功または失敗する可能性があります。第二に、リクエストの最終結果は、処理に正常に処理される場合とできない場合があります。最初のタイプのステータスは「トランザクションステータス」と呼ばれ、リクエストに応じて返される場合があります。2番目のタイプのステータスは「配信ステータス」と呼ばれ、レポートトランザクションで返される場合があります。
The original sender of a request can indicate if they wish to receive reports for requests that fail, and can independently indicate if they wish to receive reports for requests that succeed. A receiver only sends a success REPORT if it knows that the request was successfully delivered, and the sender requested a success report. A receiver only sends a failure REPORT if the request failed to be delivered and the sender requested failure reports.
リクエストの元の送信者は、失敗するリクエストのレポートを受け取りたいかどうかを示すことができ、成功したリクエストのレポートを受け取りたいかどうかを独立して示すことができます。レシーバーは、リクエストが正常に配信されたことを知っている場合にのみ成功レポートを送信し、送信者は成功レポートを要求しました。レシーバーは、リクエストの配信に失敗し、送信者が失敗レポートを要求した場合にのみ、失敗レポートを送信します。
This document describes the behavior of MSRP endpoints. MSRP relays will introduce additional conditions that indicate a failure REPORT should be sent, such as the failure to receive a positive response from the next hop.
このドキュメントでは、MSRPエンドポイントの動作について説明します。MSRPリレーは、次のホップから肯定的な応答を受け取らないなど、障害レポートを送信する必要があることを示す追加の条件を導入します。
Two header fields control the sender's desire to receive reports. The Success-Report header field can have a value of "yes" or "no" and the Failure-Report header field can have a value of "yes", "no", or "partial".
2つのヘッダーフィールドは、レポートを受信したい送信者の欲求を制御します。サクセスレポートヘッダーフィールドには「はい」または「いいえ」の値を持つことができ、失敗レポートヘッダーフィールドは「はい」、「いいえ」、または「部分的」の値を持つことができます。
The combinations of reporting are needed to meet the various scenarios of currently deployed IM systems. Success-Report might be "no" in many public systems to reduce load, but might be "yes" in certain enterprise systems, such as systems used for securities trading. A Failure-Report value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a response explosion to the sender. A Failure-Report of "yes" is used by many systems that wish to notify the user if the message failed. A Failure-Report of "partial" is a way to report errors other than timeouts. Timeout error reporting requires the sending hop to run a timer and the receiving hop to send an acknowledgment to stop the timer. Some systems don't want the overhead of doing this. "Partial" allows them to choose not to do so, but still allows error responses to be sent in many cases.
レポートの組み合わせは、現在展開されているIMシステムのさまざまなシナリオを満たすために必要です。多くのパブリックシステムでは、負荷を削減するための多くのパブリックシステムでは「いいえ」になる可能性がありますが、証券取引に使用されるシステムなど、特定のエンタープライズシステムでは「はい」かもしれません。「no」の故障レポート値は、送信者への応答爆発を引き起こすことなく「システムが5分でダウンする」などのシステムメッセージを送信するのに役立ちます。「はい」の障害レポートは、メッセージが失敗した場合にユーザーに通知したい多くのシステムで使用されます。「部分的」の失敗レポートは、タイムアウト以外のエラーを報告する方法です。タイムアウトエラーレポートには、送信ホップがタイマーを実行する必要があり、受信ホップは、タイマーを停止するための確認を送信する必要があります。一部のシステムは、これを行うオーバーヘッドを望んでいません。「部分的」により、彼らがそうしないことを選択することができますが、それでも多くの場合にエラー応答を送信することができます。
The term "partial" denotes that the hop-by-hop acknowledgment mechanism that would be required with a Failure-Report value of "yes" is not invoked. Thus, each device uses only "part" of the set of error detection tools available to them. This allows a compromise between no reporting of failures at all, and reporting every possible failure. For example, with "partial", a sending device does not have to keep transaction state around waiting for a positive acknowledgment. But it still allows devices to report other types of errors. The receiving device could still report a policy violation such as an unacceptable content-type, or an ICMP error trying to connect to a downstream device.
「部分的」という用語は、「はい」の故障レポート値で必要とされるホップバイホップの確認メカニズムが呼び出されないことを示します。したがって、各デバイスは、利用可能なエラー検出ツールのセットの「部分」のみを使用します。これにより、障害の報告なしとすべての可能な障害を報告する間の妥協が可能になります。たとえば、「部分的」では、送信デバイスでは、肯定的な承認を待つことをトランザクション状態に保つ必要はありません。しかし、それでもデバイスが他のタイプのエラーを報告することができます。受信デバイスは、容認できないコンテンツタイプや、ダウンストリームデバイスに接続しようとするICMPエラーなどのポリシー違反を報告できます。
When an MSRP endpoint wishes to send a request to a peer identified by an MSRP URI, it first needs a transport connection, with the appropriate security properties, to the host specified in the URI. If the sender already has such a connection, that is, one associated with the same host, port, and URI scheme, then it SHOULD reuse that connection.
MSRPエンドポイントがMSRP URIによって識別されたピアにリクエストを送信したい場合、最初にURIで指定されたホストに適切なセキュリティプロパティを備えた輸送接続が必要です。送信者が既にそのような接続、つまり同じホスト、ポート、およびURIスキームに関連付けられている場合、その接続を再利用する必要があります。
When a new MSRP session is created, the initiating endpoint MUST act as the "active" endpoint, meaning that it is responsible for opening the transport connection to the answerer, if a new connection is required. However, this requirement MAY be weakened if standardized mechanisms for negotiating the connection direction become available and are implemented by both parties to the connection.
新しいMSRPセッションが作成された場合、開始エンドポイントは「アクティブな」エンドポイントとして機能する必要があります。つまり、新しい接続が必要な場合は、回答者への輸送接続を開く責任があります。ただし、接続方向を交渉するための標準化されたメカニズムが利用可能になり、両当事者によって接続に実装されると、この要件が弱体化する場合があります。
Likewise, the active endpoint MUST immediately issue a SEND request. This initial SEND request MAY have a body if the sender has content to send, or it MAY have no body at all.
同様に、Active Endpointはすぐに送信要求を発行する必要があります。送信者が送信するコンテンツを持っている場合、またはボディがまったくない場合、この最初の送信要求にはボディがある場合があります。
The first SEND request serves to bind a connection to an MSRP session from the perspective of the passive endpoint. If the connection is not authenticated with TLS, and the active endpoint did not send an immediate request, the passive endpoint would have no way to determine who had connected, and would not be able to safely send any requests towards the active party until after the active party sends its first request.
最初の送信要求は、パッシブエンドポイントの観点からMSRPセッションに接続をバインドするのに役立ちます。接続がTLSで認証されておらず、アクティブエンドポイントが即時リクエストを送信しなかった場合、パッシブエンドポイントは誰が接続したかを判断する方法がなく、アクティブパーティにリクエストを安全に送信することができません。アクティブパーティーは最初のリクエストを送信します。
When an element needs to form a new connection, it looks at the URI to decide on the type of connection (TLS, TCP, etc.) then connects to the host indicated by the URI, following the URI resolution rules in Section 6.2. Connections using the "msrps" scheme MUST use TLS. The SubjectAltName in the received certificate MUST match the hostname part of the URI and the certificate MUST be valid according to RFC 3280 [16], including having a date that is valid and being signed by an acceptable certification authority. At this point, the device that initiated the connection can assume that this connection is with the correct host.
要素が新しい接続を形成する必要がある場合、URIを調べて接続の種類（TLS、TCPなど）を決定し、セクション6.2のURI解像度ルールに従って、URIで示されたホストに接続します。「MSRPS」スキームを使用した接続は、TLSを使用する必要があります。受信した証明書のsubjectaltnameは、URIのホスト名部分と一致する必要があり、証明書はRFC 3280 [16]に従って有効でなければなりません。この時点で、接続を開始したデバイスは、この接続が正しいホストにあると想定できます。
The rules on certificate name matching and CA signing MAY be relaxed when using TLS peer-to-peer. In this case, a mechanism to ensure that the peer used a correct certificate MUST be used. See Section 14.4 for details.
TLSピアツーピアを使用すると、証明書名のマッチングとCAの署名に関するルールが緩和される場合があります。この場合、ピアが正しい証明書を使用したことを確認するメカニズムを使用する必要があります。詳細については、セクション14.4を参照してください。
If the connection used mutual TLS authentication, and the TLS client presented a valid certificate, then the element accepting the connection can verify the identity of the connecting device by comparing the hostname part of the target URI in the SDP provided by the peer device against the SubjectAltName in the client certificate.
接続が相互TLS認証を使用し、TLSクライアントが有効な証明書を提示した場合、接続を受け入れる要素は、ピアデバイスによって提供されるSDPのターゲットURIのホスト名部分を比較することにより、接続デバイスのIDを検証できます。クライアント証明書のsubjectaltname。
When mutual TLS authentication is not used, the listening device MUST wait until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description.
相互TLS認証が使用されない場合、リスニングデバイスは、接続のリクエストを受信するまで待機する必要があります。
When the first request arrives, its To-Path header field should contain a URI that the listening element provided in the SDP for a session. The element that accepted the connection looks up the URI in the received request, and determines which session it matches. If a match exists, the node MUST assume that the host that formed the connection is the host to which this URI was given. If no match exists, the node MUST reject the request with a 481 response. The node MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response.
最初のリクエストが到着すると、そのトーパスヘッダーフィールドには、セッションのためにSDPで提供されたリスニング要素が提供するURIが含まれている必要があります。接続を受け入れた要素は、受信した要求でURIを調べ、一致するセッションを決定します。一致が存在する場合、ノードは、接続を形成したホストがこのURIに与えられたホストであると想定する必要があります。一致が存在しない場合、ノードは481の応答でリクエストを拒否する必要があります。また、ノードは、セッションが別の接続でまだ使用されていないことを確認する必要があります。セッションがすでに使用されている場合、506の応答でリクエストを拒否する必要があります。
If it were legal to have multiple connections associated with the same session, a security problem would exist. If the initial SEND request is not protected, an eavesdropper might learn the URI, and use it to insert messages into the session via a different connection.
同じセッションに複数の接続を関連付けることが合法であれば、セキュリティの問題が存在します。初期送信要求が保護されていない場合、盗聴者はURIを学習し、それを使用して別の接続を介してセッションにメッセージを挿入する可能性があります。
If a connection fails for any reason, then an MSRP endpoint MUST consider any sessions associated with the connection as also having failed. When either endpoint notices such a failure, it MAY attempt to re-create any such sessions. If it chooses to do so, it MUST use a new SDP exchange, for example, in a SIP re-INVITE. If a replacement session is successfully created, endpoints MAY attempt to resend any content for which delivery on the original session could not be confirmed. If it does this, the Message-ID values for the resent messages MUST match those used in the initial attempts. If the receiving endpoint receives more than one message with the same Message-ID, it SHOULD assume that the messages are duplicates. The specific action that an endpoint takes when it receives a duplicate message is a matter of local policy, except that it SHOULD NOT present the duplicate messages to the user without warning of the duplication. Note that acknowledgments as needed based on the Failure-Report and Success-Report settings are still necessary even for requests containing duplicate content.
何らかの理由で接続が失敗した場合、MSRPエンドポイントは、接続に関連付けられたセッションも失敗したことを考慮する必要があります。いずれかのエンドポイントがそのような障害に気付いた場合、そのようなセッションを再作成しようとする場合があります。そうすることを選択した場合、たとえばSIP Re Inviteで新しいSDP Exchangeを使用する必要があります。交換セッションが正常に作成された場合、エンドポイントは、元のセッションでの配信が確認できなかったコンテンツを再送信しようとする場合があります。これを行う場合、Resentメッセージのメッセージ-ID値は、最初の試みで使用されたメッセージと一致する必要があります。受信エンドポイントが同じメッセージIDで複数のメッセージを受信する場合、メッセージが複製されていると仮定する必要があります。エンドポイントが複製メッセージを受信したときに実行する特定のアクションは、複製を警告することなく、重複したメッセージをユーザーに提示してはならないことを除いて、ローカルポリシーの問題です。障害レポートとサクセスレポートの設定に基づいて必要に応じて、重複したコンテンツを含むリクエストにも承認が必要であることに注意してください。
When endpoints create a new session in this fashion, the chunks for a given logical message MAY be split across the sessions. However, endpoints SHOULD NOT split chunks between sessions under non-failure circumstances.
エンドポイントがこの方法で新しいセッションを作成すると、特定の論理メッセージのチャンクがセッション全体に分割される場合があります。ただし、エンドポイントは、非失敗状況下でのセッション間にチャンクを分割するべきではありません。
If an endpoint attempts to re-create a failed session in this manner, it MUST NOT assume that the MSRP URIs in the SDP will be the same as the old ones.
エンドポイントがこの方法で失敗したセッションを再作成しようとする場合、SDPのMSRP URIが古いものと同じであると仮定してはなりません。
A connection SHOULD NOT be closed while there are sessions associated with it.
それに関連するセッションがある間は、接続を閉じないでください。
URIs using the "msrp" and "msrps" schemes are used to identify a session of instant messages at a particular MSRP device, as well as to identify an MSRP relay in general. This document describes the former usage; the latter usage is described in the MSRP relay specification [23]. MSRP URIs that identify sessions are ephemeral; an MSRP device will use a different MSRP URI for each distinct session. An MSRP URI that identifies a session has no meaning outside the scope of that session.
「MSRP」および「MSRPS」スキームを使用したURIは、特定のMSRPデバイスでのインスタントメッセージのセッションを識別し、一般的にMSRPリレーを識別するために使用されます。このドキュメントでは、以前の使用法について説明しています。後者の使用法は、MSRPリレー仕様[23]で説明されています。セッションを特定するMSRP URIは短命です。MSRPデバイスは、異なるセッションごとに異なるMSRP URIを使用します。セッションを識別するMSRP URIには、そのセッションの範囲外の意味はありません。
An MSRP URI follows a subset of the URI syntax in Appendix A of RFC 3986 [10], with a scheme of "msrp" or "msrps". The syntax is described in Section 9.
MSRP URIは、「MSRP」または「MSRP」のスキームを使用して、RFC 3986 [10]の付録AのURI構文のサブセットに従います。構文については、セクション9で説明します。
MSRP URIs are primarily expected to be generated and exchanged between systems, and are not intended for "human consumption". Therefore, they are encoded entirely in US-ASCII.
MSRP URIは、主にシステム間で生成および交換されることが期待されており、「人間の消費」を意図していません。したがって、それらは完全にus-asciiでエンコードされています。
The constructions for "authority", "userinfo", and "unreserved" are detailed in RFC 3986 [10]. URIs designating MSRP over TCP MUST include the "tcp" transport parameter.
「権威」、「userinfo」、および「unsulversed」の構造は、RFC 3986 [10]で詳しく説明されています。TCPを介してMSRPを指定するURISには、「TCP」輸送パラメーターを含める必要があります。
Since this document only specifies MSRP over TCP, all MSRP URIs herein use the "tcp" transport parameter. Documents that provide bindings on other transports should define respective parameters for those transports.
このドキュメントはTCPを介してMSRPのみを指定するため、ここではすべてのMSRP URIが「TCP」輸送パラメーターを使用します。他の輸送機でバインディングを提供するドキュメントは、それらの輸送機のそれぞれのパラメーターを定義する必要があります。
The MSRP URI authority field identifies a participant in a particular MSRP session. If the authority field contains a numeric IP address, it MUST also contain a port. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device. A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the "authority" governing a namespace for the session-id.
MSRP URI Authorityフィールドは、特定のMSRPセッションの参加者を特定します。機関フィールドに数値IPアドレスが含まれている場合、ポートも含める必要があります。セッションIDパーツは、参加者の特定のセッションを識別します。セッションIDパーツがないことは、MSRPホストデバイスへの参照を示しますが、そのデバイスでの特定のセッションを参照しません。Session-IDの特定の価値は、関連する権限のコンテキストでのみ意味があります。したがって、当局のコンポーネントは、セッションIDの名前空間を支配する「権限」を特定すると考えることができます。
A scheme of "msrps" indicates that the underlying connection MUST be protected with TLS.
「MSRP」のスキームは、基礎となる接続をTLSで保護する必要があることを示します。
MSRP has an IANA-registered recommended port defined in Section 15.4. This value is not a default, as the URI negotiation process described herein will always include explicit port numbers. However, the URIs SHOULD be configured so that the recommended port is used whenever appropriate. This makes life easier for network administrators who need to manage firewall policy for MSRP.
MSRPには、セクション15.4で定義されたIANA登録の推奨ポートがあります。本明細書に記載されているURI交渉プロセスには常に明示的なポート番号が含まれるため、この値はデフォルトではありません。ただし、urisは、適切な場合はいつでも推奨ポートが使用されるように構成する必要があります。これにより、MSRPのファイアウォールポリシーを管理する必要があるネットワーク管理者にとって生活が容易になります。
The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. A userinfo part MUST NOT contain password information.
機関コンポーネントには通常、userInfoコンポーネントは含まれませんが、セッションが有効なユーザーアカウントを示すためにそうする場合があります。これは、セッション自体を識別するのと同じではないことに注意してください。userInfo部品には、パスワード情報を含めてはなりません。
The following is an example of a typical MSRP URI:
以下は、典型的なMSRP URIの例です。
msrp://host.example.com:8493/asfd34;tcp
In the context of the MSRP protocol, MSRP URI comparisons MUST be performed according to the following rules:
MSRPプロトコルのコンテキストでは、MSRP URI比較は次のルールに従って実行する必要があります。
1. The scheme MUST match. Scheme comparison is case insensitive.
1. スキームは一致する必要があります。スキームの比較は、症例の鈍感です。
2. If the authority component contains an explicit IP address and/or port, these are compared for address and port equivalence. Percent-encoding normalization [10] applies; that is, if any percent-encoded nonreserved characters exist in the authority component, they must be decoded prior to comparison. Userinfo parts are not considered for URI comparison. Otherwise, the authority component is compared as a case-insensitive character string.
2. 当局コンポーネントに明示的なIPアドレスおよび/またはポートが含まれている場合、これらはアドレスとポートの等価性と比較されます。パーセントエンコード正規化[10]が適用されます。つまり、当局コンポーネントにエンコードされていない非予定されていない文字が存在する場合、比較前にデコードする必要があります。URIの比較では、userInfoパーツは考慮されていません。それ以外の場合、権限コンポーネントは、ケースに依存しない文字列として比較されます。
3. If the port exists explicitly in either URI, then it MUST match exactly. A URI with an explicit port is never equivalent to another with no port specified.
3. ポートがいずれかのURIに明示的に存在する場合、正確に一致する必要があります。明示的なポートを備えたURIは、ポートが指定されていない別のポートとは決して同等ではありません。
4. The session-id part is compared as case sensitive. A URI without a session-id part is never equivalent to one that includes one.
4. セッションIDパーツは、ケースに敏感であると比較されます。セッションIDパーツのないURIは、それを含むものとは決して同等ではありません。
5. URIs with different "transport" parameters never match. Two URIs that are identical except for transport are not equivalent. The transport parameter is case insensitive.
5. 異なる「輸送」パラメーターを持つURIは決して一致しません。輸送を除いて同一の2つのURIは同等ではありません。輸送パラメーターは、ケースの鈍感です。
Path normalization [10] is not relevant for MSRP URIs.
PATH正規化[10]は、MSRP URIには関係ありません。
An MSRP host device is identified by the authority component of an MSRP URI.
MSRPホストデバイスは、MSRP URIの権限コンポーネントによって識別されます。
If the authority component contains a numeric IP address and port, they MUST be used as listed.
機関コンポーネントに数値IPアドレスとポートが含まれている場合、それらはリストされているように使用する必要があります。
If the authority component contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query and use the port as listed.
権限コンポーネントにホスト名とポートが含まれている場合、接続デバイスはAまたはAAAA DNSクエリを実行してホストアドレスを決定し、リストに従ってポートを使用する必要があります。
If a connection attempt fails, the device SHOULD attempt to connect to the addresses returned in any additional A or AAAA records, in the order the records were presented.
接続試行が失敗した場合、デバイスは、追加のAまたはAAAAレコードで返されたアドレスに接続しようとする必要があります。
This process assumes that the connection port is always known prior to resolution. This is always true for the MSRP URI uses described in this document, that is, URIs exchanged in the SDP offer and answer. The introduction of relays creates situations where this is not the case. For example, when a user configures her client to use a relay, it is desirable that the relay's MSRP URI is easy to remember and communicate to humans. Often this type of MSRP will omit the port number. Therefore, the relay specification [23] describes additional steps to resolve the port number.
このプロセスでは、接続ポートが解決前に常にわかっていると想定しています。これは、このドキュメントで説明されているMSRP URIの使用、つまりSDPのオファーと回答で交換されたURISに常に当てはまります。リレーの導入は、そうでない状況を作成します。たとえば、ユーザーがクライアントにリレーを使用するように構成する場合、リレーのMSRP URIが人間を覚えやすく通信しやすいことが望ましいです。多くの場合、このタイプのMSRPはポート番号を省略します。したがって、リレー仕様[23]は、ポート番号を解決するための追加の手順を説明します。
MSRP devices MAY use other methods for discovering other such devices, when appropriate. For example, MSRP endpoints may use other mechanisms to discover relays, which are beyond the scope of this document.
MSRPデバイスは、必要に応じて他のそのようなデバイスを発見するために他の方法を使用する場合があります。たとえば、MSRPエンドポイントは、他のメカニズムを使用して、このドキュメントの範囲を超えたリレーを発見する場合があります。
To form a new request, the sender creates a transaction identifier and uses this and the method name to create an MSRP request start line. The transaction identifier MUST NOT collide with that of other transactions that exist at the same time. Therefore, it MUST contain at least 64 bits of randomness.
新しいリクエストを形成するために、送信者はトランザクション識別子を作成し、これとメソッド名を使用してMSRPリクエスト開始行を作成します。トランザクション識別子は、同時に存在する他のトランザクションの識別子と衝突してはなりません。したがって、少なくとも64ビットのランダム性を含める必要があります。
Next, the sender places the target path in a To-Path header field, and the sender's URI in a From-Path header field. If multiple URIs are present in the To-Path, the leftmost is the first URI visited; the rightmost URI is the last URI visited. The processing then becomes method specific. Additional method-specific header fields are added as described in the following sections.
次に、送信者はターゲットパスをトーパスヘッダーフィールドに配置し、送信者のURIをPath From Pathヘッダーフィールドに配置します。To-Pathに複数のURIが存在する場合、左端は最初のURIが訪れたものです。右端のURIは、訪問した最後のURIです。処理はメソッド固有になります。次のセクションで説明されているように、追加のメソッド固有のヘッダーフィールドが追加されます。
After any method-specific header fields are added, processing continues to handle a body, if present. If the request has a body, it MUST contain a Content-Type header field. It may contain other MIME-specific header fields. The Content-Type header field MUST be the last field in the message header section. The body MUST be separated from the header fields with an extra CRLF.
メソッド固有のヘッダーフィールドが追加された後、存在する場合、処理はボディを処理し続けます。リクエストに本文がある場合、コンテンツタイプのヘッダーフィールドを含める必要があります。他のMIME固有のヘッダーフィールドが含まれる場合があります。コンテンツタイプのヘッダーフィールドは、メッセージヘッダーセクションの最後のフィールドでなければなりません。ボディは、余分なCRLFでヘッダーフィールドから分離する必要があります。
Non-SEND requests are not intended to carry message content, and are therefore not interruptible. Non-SEND request bodies MUST NOT be larger than 10240 octets.
非センドリクエストはメッセージコンテンツを携帯することを意図していないため、中断することはできません。非センドリクエストボディは、10240オクテットよりも大きくなければなりません。
Although this document does not discuss any particular usage of bodies in non-SEND requests, they may be useful in the future for carrying security or identity information, information about a message in progress, etc. The 10K size limit was chosen to be large enough for most of such applications, but small enough to avoid the fairness issues caused by sending arbitrarily large content in non-interruptible method bodies.
このドキュメントでは、非センドリクエストでの特定のボディの使用については説明していませんが、セキュリティまたは身元情報、進行中のメッセージなどの情報を運ぶために将来的に役立つかもしれません。そのようなアプリケーションのほとんどについては、断続的に大きなメソッドボディに任意に大きなコンテンツを送信することによって引き起こされる公平性の問題を回避するのに十分なほど小さい。
A request with no body MUST NOT include a Content-Type or any other MIME-specific header fields. A request without a body MUST contain an end-line after the final header field. No extra CRLF will be present between the header section and the end-line.
ボディがないリクエストには、コンテンツタイプまたはその他のMIME固有のヘッダーフィールドを含めてはなりません。ボディのないリクエストには、最終ヘッダーフィールドの後にエンドラインが含まれている必要があります。ヘッダーセクションとエンドラインの間に追加のCRLFは存在しません。
Requests with no bodies are useful when a client wishes to send "traffic", but does not wish to send content to be rendered to the peer user. For example, the active endpoint sends a SEND request immediately upon establishing a connection. If it has nothing to say at the moment, it can send a request with no body. Bodiless requests may also be used in certain applications to keep Network Address Translation (NAT) bindings alive, etc.
ボディのないリクエストは、クライアントが「トラフィック」を送信したい場合に役立ちますが、ピアユーザーにレンダリングされるコンテンツを送信することを希望しません。たとえば、アクティブエンドポイントは、接続を確立するとすぐに送信要求を送信します。現時点で何も言うことがない場合、ボディのないリクエストを送信できます。特定のアプリケーションでは、ネットワークアドレスの変換（NAT）バインディングなどを維持するために、特定のアプリケーションでもボディレスリクエストを使用できます。
Bodiless requests are distinct from requests with empty bodies. A request with an empty body will have a Content-Type header field value and will generally be rendered to the recipient according to the rules for that type.
ボディレスリクエストは、空のボディを持つリクエストとは異なります。空のボディを持つリクエストは、コンテンツタイプのヘッダーフィールド値を持ち、通常、そのタイプのルールに従って受信者にレンダリングされます。
The end-line that terminates the request MUST be composed of seven "-" (minus sign) characters, the transaction ID as used in the start line, and a flag character. If a body is present, the end-line MUST be preceded by a CRLF that is not part of the body. If the chunk represents the data that forms the end of the complete message, the flag value MUST be a "$". If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a "#". Otherwise, the flag MUST be a "+".
リクエストを終了するエンドラインは、7つの「 - 」（マイナスサイン）文字、スタート行で使用されるトランザクションID、およびフラグ文字で構成されている必要があります。ボディが存在する場合、エンドラインの前に体の一部ではないCRLFが先行する必要があります。チャンクが完全なメッセージの終わりを形成するデータを表す場合、フラグ値は「$」でなければなりません。送信者が不完全なメッセージを中止しており、そのメッセージにそれ以上のチャンクを送らないことを意図している場合、フラグは「＃」でなければなりません。それ以外の場合、フラグは「」でなければなりません。
If the request contains a body, the sender MUST ensure that the end-line (seven hyphens, the transaction identifier, and a continuation flag) is not present in the body. If the end-line is present in the body, the sender MUST choose a new transaction identifier that is not present in the body, and add a CRLF if needed, and the end-line, including the "$", "#", or "+" character.
リクエストに本体が含まれている場合、送信者は、エンドライン（7つのハイフン、トランザクション識別子、および継続フラグ）がボディに存在しないことを確認する必要があります。エンドラインが体内に存在する場合、送信者は体内に存在しない新しいトランザクション識別子を選択し、必要に応じてCRLFを追加する必要があります。または ""キャラクター。
Some implementations may choose to scan for the closing sequence as they send the body, and if it is encountered, simply interrupt the chunk at that point and start a new transaction with a different transaction identifier to carry the rest of the body. Other implementations may choose to scan the data and ensure that the body does not contain the transaction identifier before they start sending the transaction.
いくつかの実装は、ボディを送信するときにクロージングシーケンスをスキャンすることを選択する場合があります。遭遇した場合は、その時点でチャンクを中断し、異なるトランザクション識別子で新しいトランザクションを開始して体の残りを運ぶことができます。他の実装は、データをスキャンし、トランザクションの送信を開始する前にボディにトランザクション識別子が含まれていないことを確認することができます。
Once a request is ready for delivery, the sender follows the connection management (Section 5.4) rules to forward the request over an existing open connection or create a new connection.
リクエストが配信の準備ができたら、送信者は接続管理（セクション5.4）ルールに従って、既存のオープン接続を介してリクエストを転送するか、新しい接続を作成します。
When an endpoint has a message to deliver, it first generates a new Message-ID. The value MUST be highly unlikely to be repeated by another endpoint instance, or by the same instance in the future. If necessary, the endpoint breaks the message into chunks. It then generates a SEND request for each chunk, following the procedures for constructing requests (Section 7.1).
エンドポイントに配信するメッセージがある場合、最初に新しいメッセージIDを生成します。この値は、別のエンドポイントインスタンス、または将来同じインスタンスによって繰り返される可能性が非常に低い必要があります。必要に応じて、エンドポイントはメッセージをチャンクに分割します。次に、要求を作成する手順に従って、各チャンクの送信要求を生成します（セクション7.1）。
The Message-ID header field provides a unique message identifier that refers to a particular version of a particular message. The term "Message" in this context refers to a unit of content that the sender wishes to convey to the recipient. While such a message may be broken into chunks, the Message-ID refers to the entire message, not a chunk of the message.
Message-IDヘッダーフィールドは、特定のメッセージの特定のバージョンを指す一意のメッセージ識別子を提供します。この文脈での「メッセージ」という用語は、送信者が受信者に伝えたいコンテンツの単位を指します。そのようなメッセージはチャンクに分割される可能性がありますが、メッセージIDはメッセージのチャンクではなく、メッセージ全体を参照します。
The uniqueness of the message identifier is ensured by the host that generates it. This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one version of a particular message; subsequent revisions to the message each receive new message identifiers. Endpoints can ensure sufficient uniqueness in any number of ways, the selection of which is an implementation choice. For example, an endpoint could concatenate an instance identifier such as a MAC address, its idea of the number of seconds since the epoch, a process ID, and a monotonically increasing 16-bit integer, all base-64 encoded. Alternately, an endpoint without an on-board clock could simply use a 64-bit random number.
メッセージ識別子の一意性は、それを生成するホストによって保証されます。このメッセージ識別子は、機械が読みやすく、必ずしも人間にとって意味のあるものではないことを目的としています。メッセージ識別子は、特定のメッセージの正確な1つのバージョンに関係しています。メッセージの後続の改訂は、それぞれ新しいメッセージ識別子を受信します。エンドポイントは、あらゆる方法で十分な一意性を確保することができ、その選択は実装の選択です。たとえば、エンドポイントは、MACアドレスなどのインスタンス識別子、エポック以来の秒数、プロセスID、および単調に増加する16ビット整数のアイデアを連結することができます。あるいは、オンボードクロックのないエンドポイントは、単に64ビットの乱数を使用できます。
Each chunk of a message MUST contain a Message-ID header field containing the Message-ID. If the sender wishes non-default status reporting, it MUST insert a Failure-Report and/or Success-Report header field with an appropriate value. All chunks of the same message MUST use the same Failure-Report and Success-Report values in their SEND requests.
メッセージの各チャンクには、メッセージ-IDを含むメッセージIDヘッダーフィールドを含める必要があります。送信者が非デフォルトステータスのレポートを希望する場合、適切な値で失敗レポートおよび/またはサクセスレポートヘッダーフィールドを挿入する必要があります。同じメッセージのすべてのチャンクは、送信リクエストで同じ失敗レポートとサクセスレポート値を使用する必要があります。
If success reports are requested, i.e., the value of the Success-Report header field is "yes", the sending device MAY wish to run a timer of some value that makes sense for its application and take action if a success report is not received in this time. There is no universal value for this timer. For many IM applications, it may be 2 minutes while for some trading systems it may be under a second. Regardless of whether such a timer is used, if the success report has not been received by the time the session is ended, the device SHOULD inform the user.
成功レポートが要求された場合、つまりサクセスレポートヘッダーフィールドの値は「はい」です。送信デバイスは、アプリケーションにとって意味のある価値のあるタイマーを実行し、成功レポートが受信されない場合にアクションを実行することを希望する場合があります。この間。このタイマーには普遍的な価値はありません。多くのIMアプリケーションでは、2分間になる場合がありますが、一部の取引システムでは1秒未満である可能性があります。このようなタイマーが使用されているかどうかに関係なく、セッションが終了するまでに成功レポートが受信されていない場合、デバイスはユーザーに通知する必要があります。
If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. Regardless of the Failure-Report value, there is no requirement to wait for a response prior to sending the next request.
「失敗レポート」の値が「はい」に設定されている場合、リクエストの送信者はタイマーを実行します。トランザクションに対する200の応答が、トランザクションの最後のバイトが送信されるまでに30秒以内に受信されない場合、または送信のためにオペレーティングシステムに送信された場合、要素はリクエストがおそらく失敗したことをユーザーに通知する必要があります。値が「部分的」に設定されている場合、トランザクションを送信する要素はタイマーを実行する必要はありませんが、トランザクションに対する回復不可能なエラー応答を受信した場合、ユーザーに通知する必要があります。失敗レポートの値に関係なく、次のリクエストを送信する前に応答を待つ必要はありません。
The treatment of timers for success reports and failure reports is intentionally inconsistent. An explicit timeout value makes sense for failure reports since such reports will usually refer to a message "chunk" that is acknowledged on a hop-by-hop basis. This is not the case for success reports, which are end-to-end and may refer to the entire message content, which can be arbitrarily large.
成功レポートと失敗報告のためのタイマーの扱いは意図的に一貫性がありません。通常、そのようなレポートはホップバイホップベースで認められるメッセージ「チャンク」を参照するため、明示的なタイムアウト値は失敗レポートに対して理にかなっています。これは、エンドツーエンドであり、メッセージコンテンツ全体をarbitrarily意的に大きくする可能性がある成功レポートの場合は当てはまりません。
If no Success-Report header field is present in a SEND request, it MUST be treated the same as a Success-Report header field with a value of "no". If no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes". If an MSRP endpoint receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
送信要求に成功レポートヘッダーフィールドが存在しない場合、「いいえ」の値で成功レポートヘッダーフィールドと同じように扱う必要があります。故障レポートヘッダーフィールドが存在しない場合、「はい」の値で障害レポートヘッダーフィールドと同じように扱う必要があります。MSRPエンドポイントが、認識されないメッセージIDのレポートを受け取った場合、レポートを静かに無視する必要があります。
The Byte-Range header field value contains a starting value (range-start) followed by a "-", an ending value (range-end) followed by a "/", and finally the total length. The first octet in the message has a position of one, rather than a zero.
バイト範囲のヘッダーフィールド値には、開始値（range-start）に続いて「 - 」、終了値（範囲エンド）に続く「/」、最後に合計長が含まれます。メッセージの最初のオクテットには、ゼロではなく1つの位置があります。
The first chunk of the message SHOULD, and all subsequent chunks MUST, include a Byte-Range header field. The range-start field MUST indicate the position of the first byte in the body in the overall message (for the first chunk this field will have a value of one). The range-end field SHOULD indicate the position of the last byte in the body, if known. It MUST take the value of "*" if the position is unknown, or if the request needs to be interruptible. The total field SHOULD contain the total size of the message, if known. The total field MAY contain a "*" if the total size of the message is not known in advance. The sender MUST send all chunks in Byte-Range order. (However, the receiver cannot assume that the requests will be delivered in order, as intervening relays may have changed the order.)
メッセージの最初のチャンクには、その後のすべてのチャンクには、バイトレンジヘッダーフィールドを含める必要があります。レンジスタートフィールドは、メッセージ全体のボディの最初のバイトの位置を示す必要があります（最初のチャンクでは、このフィールドには1つの値があります）。レンジエンドフィールドは、わかっている場合、ボディの最後のバイトの位置を示す必要があります。位置が不明な場合、またはリクエストを中断できる場合は「*」の値を取る必要があります。総フィールドには、既知の場合、メッセージの合計サイズが含まれている必要があります。総フィールドには、メッセージの合計サイズが事前に不明な場合は「*」を含む場合があります。送信者は、すべてのチャンクをバイト範囲の順序で送信する必要があります。（ただし、介入リレーが順序を変更した可能性があるため、レシーバーはリクエストが順番に配信されると想定できません。）
There are some circumstances where an endpoint may choose to send an empty SEND request. For the sake of consistency, a Byte-Range header field referring to nonexistent or zero-length content MUST still have a range-start value of 1. For example, "1-0/0".
エンドポイントが空の送信リクエストを送信することを選択できる状況がいくつかあります。一貫性のために、存在しないまたはゼロの長さのコンテンツを参照するバイト範囲のヘッダーフィールドには、範囲スタート値が1である必要があります。たとえば、「1-0/0」。
To ensure fairness over a connection, senders MUST NOT send chunks with a body larger than 2048 octets unless they are prepared to interrupt them (meaning that any chunk with a body of greater than 2048 octets will have a "*" character in the range-end field). A sender can use one of the following two strategies to satisfy this requirement. The sender is STRONGLY RECOMMENDED to send messages larger than 2048 octets using as few chunks as possible, interrupting chunks (at least 2048 octets long) only when other traffic is waiting to use the same connection. Alternatively, the sender MAY simply send chunks in 2048-octet increments until the final chunk. Note that the former strategy results in markedly more efficient use of the connection. All MSRP nodes MUST be able to receive chunks of any size from zero octets to the maximum number of octets they can receive for a complete message. Senders SHOULD NOT break messages into chunks smaller than 2048 octets, except for the final chunk of a complete message.
接続に対する公平性を確保するために、送信者は、2048オクテットを超えるボディが遮断する準備ができていない場合を除き、2048年以上のオクテットの塊を送信してはなりません（2048オクテットを超える塊が範囲に「*」文字があることを意味します。エンドフィールド）。送信者は、次の2つの戦略のいずれかを使用して、この要件を満たすことができます。送信者は、他のトラフィックが同じ接続を使用するのを待っている場合にのみ（少なくとも2048オクテットの長さ）、チャンク（少なくとも2048オクテット）を中断する可能性のあるチャンクを可能な限り少ないチャンクを使用して2048オクテットを超えるメッセージを送信することを強くお勧めします。あるいは、送信者は、2048年からオクテットの増分にチャンクを最終的なチャンクまで送信することができます。以前の戦略により、接続のより効率的な使用が著しく使用されることに注意してください。すべてのMSRPノードは、ゼロオクテットから完全なメッセージのために受け取ることができるオクテットの最大数まで、あらゆるサイズのチャンクを受信できる必要があります。送信者は、完全なメッセージの最後のチャンクを除き、2048年のオクテットよりも小さいチャンクにメッセージを分割してはなりません。
A SEND request is interrupted while a body is in the process of being written to the connection by simply noting how much of the message has already been written to the connection, then writing out the end-line to end the chunk. It can then be resumed in a another chunk with the same Message-ID and a Byte-Range header field range start field containing the position of the first byte after the interruption occurred.
送信リクエストは、ボディが接続に書き込まれている間に中断されます。メッセージのどれだけが接続に書かれているかを確認し、エンドラインを書き留めてチャンクを終了します。その後、中断が発生した後の最初のバイトの位置を含む、同じメッセージIDとバイト範囲のヘッダーフィールド範囲の開始フィールドを持つ別のチャンクで再開できます。
SEND requests larger than 2048 octets MUST be interrupted if the sender needs to send pending responses or REPORT requests. If multiple SEND requests from different sessions are concurrently being sent over the same connection, the device SHOULD implement some scheme to alternate between them such that each concurrent request gets a chance to send some fair portion of data at regular intervals suitable to the application.
送信者が保留中の応答またはレポートリクエストを送信する必要がある場合、2048を超えるオクテットを中断する必要があります。異なるセッションからの複数の送信リクエストが同時に同じ接続で送信されている場合、デバイスはそれらの間を交互に交互に実装する必要があります。
The sender MUST NOT assume that a message is received by the peer with the same chunk allocation with which it was sent. An intervening relay could possibly break SEND requests into smaller chunks, or aggregate multiple chunks into larger ones.
送信者は、送信された同じチャンク割り当てでピアがメッセージを受信すると想定してはなりません。介在するリレーは、送信リクエストを小さなチャンクに分割したり、複数のチャンクを大きなチャンクに集約したりする可能性があります。
The default disposition of messages is to be rendered to the user. If the sender wants a different disposition, it MAY insert a Content-Disposition [9] header field. Values MAY include any from RFC 2183 [9] or the IANA registry it defines. Since MSRP can carry unencoded binary payloads, transfer encoding is always "binary", and transfer-encoding parameters MUST NOT be present.
メッセージのデフォルトの処分は、ユーザーにレンダリングされます。送信者が別の処分を望んでいる場合、コンテンツ偏差[9]ヘッダーフィールドを挿入する場合があります。値には、RFC 2183 [9]またはそれが定義するIANAレジストリからの任意のものが含まれる場合があります。MSRPはエンコードされていないバイナリペイロードを運ぶことができるため、転送エンコードは常に「バイナリ」であり、転送エンコードパラメーターが存在してはなりません。
REPORT requests are similar to SEND requests, except that report requests MUST NOT include Success-Report or Failure-Report header fields, and MUST contain a Status header field. REPORT requests MUST contain the Message-ID header field from the original SEND request.
レポートリクエストは、送信リクエストに似ていますが、レポートリクエストにはサクセスレポートまたは失敗レポートヘッダーフィールドが含まれていない場合があり、ステータスヘッダーフィールドを含める必要があります。レポートリクエストには、元の送信リクエストからMessage-IDヘッダーフィールドを含める必要があります。
If an MSRP element receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
MSRP要素が認識されないメッセージIDのレポートを受け取った場合、レポートを静かに無視する必要があります。
An MSRP endpoint MUST be able to generate success REPORT requests.
MSRPエンドポイントは、サクセスレポートリクエストを生成できる必要があります。
REPORT requests will normally not include a body, as the REPORT request header fields can carry sufficient information in most cases. However, REPORT requests MAY include a body containing additional information about the status of the associated SEND request. Such a body is informational only, and the sender of the REPORT request SHOULD NOT assume that the recipient pays any attention to the body. REPORT requests are not interruptible.
レポートリクエストは、レポートリクエストヘッダーフィールドがほとんどの場合、十分な情報を運ぶことができるため、通常はボディを含めません。ただし、レポートリクエストには、関連する送信要求のステータスに関する追加情報を含むボディが含まれる場合があります。そのような本体は情報のみであり、レポート要求の送信者は、受信者が身体に注意を払うと想定すべきではありません。レポートリクエストは中断できません。
Success-Report and Failure-Report header fields MUST NOT be present in REPORT requests. MSRP nodes MUST NOT send REPORT requests in response to REPORT requests. MSRP nodes MUST NOT send MSRP responses to REPORT requests.
サクセスレポートと失敗レポートヘッダーフィールドがレポートリクエストに存在してはなりません。MSRPノードは、レポートリクエストに応じてレポートリクエストを送信してはなりません。MSRPノードは、レポートリクエストにMSRP応答を送信してはなりません。
Endpoints SHOULD NOT send REPORT requests if they have reason to believe the request will not be delivered. For example, they SHOULD NOT send a REPORT request for a session that is no longer valid.
エンドポイントは、リクエストが配信されないと信じる理由がある場合、レポート要求を送信してはなりません。たとえば、有効でないセッションのレポートリクエストを送信しないでください。
When an endpoint receives a message in one or more chunks that contain a Success-Report value of "yes", it MUST send a success report or reports covering all bytes that are received successfully. The success reports are sent in the form of REPORT requests, following the normal procedures (Section 7.1), with a few additional requirements.
エンドポイントが「はい」の成功レポート値を含む1つ以上のチャンクでメッセージを受信した場合、正常に受信されたすべてのバイトをカバーする成功レポートまたはレポートを送信する必要があります。成功レポートは、通常の手順（セクション7.1）に従って、いくつかの追加要件を伴うレポート要求の形式で送信されます。
The receiver MAY wait until it receives the last chunk of a message, and send a success report that covers the complete message. Alternately, it MAY generate incremental success REPORTs as the chunks are received. These can be sent periodically and cover all the bytes that have been received so far, or they can be sent after a chunk arrives and cover just the part from that chunk.
受信者は、メッセージの最後のチャンクを受信するまで待機し、完全なメッセージをカバーする成功レポートを送信できます。あるいは、チャンクを受信するにつれて、増分成功レポートを生成する可能性があります。これらは定期的に送信し、これまでに受信されたすべてのバイトをカバーすることができます。または、チャンクが到着してそのチャンクからの部分をカバーした後に送信することができます。
It is helpful to think of a success REPORT as reporting on a particular range of bytes, rather than on a particular chunk sent by a client. The sending client cannot depend on the Byte-Range header field in a given success report matching that of a particular SEND request. For example, an intervening MSRP relay may break chunks into smaller chunks, or aggregate multiple chunks into larger ones. A side effect of this is, even if no relay is used, the receiving client may report on byte ranges that do not exactly match those in the original chunks sent by the sender. It can wait until all bytes in a message are received and report on the whole, it can report as it receives each chunk, or it can report on any other received range. Reporting on ranges smaller than the entire message contents allows certain improved user experiences for the sender. For example, a sending client could display incremental status information showing which ranges of bytes have been acknowledged by the receiver. However, the choice on whether to report incrementally is entirely up to the receiving client. There is no mechanism for the sender to assert its desire to receive incremental reports or not. Since the presence of a relay can cause the receiver to see a very different chunk allocation than the sender, such a mechanism would be of questionable value.
クライアントから送信された特定のチャンクではなく、特定のバイトの範囲のレポートを成功レポートと考えることは役立ちます。送信クライアントは、特定の送信リクエストのそれと一致する特定の成功レポートでバイト範囲のヘッダーフィールドに依存することはできません。たとえば、介在するMSRPリレーは、チャンクをより小さなチャンクに分割したり、複数のチャンクを大きなチャンクに集約したりする可能性があります。これの副作用は、リレーが使用されていなくても、受信クライアントは、送信者が送信した元のチャンクのものと正確に一致しないバイト範囲について報告することができます。メッセージ内のすべてのバイトが受信され、全体に報告されるまで待つことができます。各チャンクを受信したときに報告するか、他の受信範囲についてレポートできます。メッセージの内容全体よりも小さい範囲のレポートは、送信者の特定の改善されたユーザーエクスペリエンスを可能にします。たとえば、送信クライアントは、受信者によって確認されたバイトの範囲を示す増分ステータス情報を表示できます。ただし、段階的に報告するかどうかの選択は、完全に受信クライアント次第です。送信者が増分レポートを受け取るかどうかを断言するメカニズムはありません。リレーの存在により、受信機が送信者とは非常に異なるチャンク割り当てを確認する可能性があるため、そのようなメカニズムは疑わしい価値があります。
When generating a REPORT request, the endpoint inserts a To-Path header field containing the From-Path value from the original request, and a From-Path header field containing the URI identifying itself in the session. The endpoint then inserts a Status header field with a namespace of "000", a status-code of "200", and an implementation-defined comment phrase. It also inserts a Message-ID header field containing the value from the original request.
レポートリクエストを生成するとき、エンドポイントは、元のリクエストからのパス値を含むトーパスヘッダーフィールドと、セッションでURIを識別するパスフロームヘッダーフィールドを挿入します。エンドポイントは、「000」の名前空間、「200」のステータスコード、および実装定義のコメントフレーズを備えたステータスヘッダーフィールドを挿入します。また、元のリクエストから値を含むメッセージ-IDヘッダーフィールドも挿入します。
The namespace field denotes the context of the status-code field. The namespace value of "000" means the status-code should be interpreted in the same way as the matching MSRP transaction response code. If a future specification uses the status-code field for some other purpose, it MUST define a new namespace field value.
名前空間フィールドは、ステータスコードフィールドのコンテキストを示します。「000」の名前空間値は、ステータスコードが一致するMSRPトランザクション応答コードと同じ方法で解釈する必要があることを意味します。将来の仕様が他の目的でステータスコードフィールドを使用する場合、新しい名前空間フィールド値を定義する必要があります。
The endpoint MUST NOT send a success report for a SEND request that either contained no Success-Report header field or contained such a field with a value of "no". That is, if no Success-Report header field is present, it is treated identically to one with a value of "no".
エンドポイントは、成功レポートヘッダーフィールドを含まないか、「いいえ」の値でそのようなフィールドを含む送信要求の成功レポートを送信してはなりません。つまり、成功レポートのヘッダーフィールドが存在しない場合、「いいえ」の値を持つものと同じように扱われます。
If an MSRP endpoint receives a SEND request that it cannot process for some reason, and the Failure-Report header field either was not present in the original request or had a value of "yes", it SHOULD simply include the appropriate error code in the transaction response. However, there may be situations where the error cannot be determined quickly, such as when the endpoint is a gateway that waits for a downstream network to indicate an error. In this situation, it MAY send a 200 OK response to the request, and then send a failure REPORT request when the error is detected.
MSRPエンドポイントが何らかの理由で処理できないという送信要求を受信し、失敗レポートヘッダーフィールドが元のリクエストに存在しないか、「はい」の値を持っていた場合、単に適切なエラーコードを含める必要があります。トランザクション応答。ただし、エンドポイントが下流ネットワークがエラーを示すのを待つゲートウェイである場合など、エラーを迅速に決定できない状況がある場合があります。この状況では、リクエストに200のOK応答を送信し、エラーが検出されたときに障害レポートリクエストを送信する場合があります。
If the endpoint receives a SEND request with a Failure-Report header field value of "no", then it MUST NOT send a failure REPORT request, and MUST NOT send a transaction response. If the value is "partial", it MUST NOT send a 200 transaction response to the request, but SHOULD send an appropriate non-200 class response if a failure occurs.
エンドポイントが「no」の失敗レポートヘッダーフィールド値を持つ送信要求を受信した場合、障害レポートリクエストを送信してはならず、トランザクション応答を送信してはなりません。値が「部分的」である場合、リクエストに200のトランザクション応答を送信してはなりませんが、障害が発生した場合は適切な非200クラスの応答を送信する必要があります。
As stated above, if no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes".
上記のように、障害レポートヘッダーフィールドが存在しない場合、「はい」の値を持つ故障レポートヘッダーフィールドと同じように扱う必要があります。
Construction of failure REPORT requests is identical to that for success REPORT requests, except the Status header field code field MUST contain the appropriate error code. Any error response code defined in this specification MAY also be used in failure reports.
障害レポートリクエストの構築は、ステータスヘッダーフィールドコードフィールドに適切なエラーコードを含める必要がある場合を除き、成功レポートリクエストと同一です。この仕様で定義されているエラー応答コードは、障害レポートでも使用できます。
If a failure REPORT request is sent in response to a SEND request that contained a chunk, it MUST include a Byte-Range header field indicating the actual range being reported on. It can take the range-start and total values from the original SEND request, but MUST calculate the range-end field from the actual body data.
チャンクを含む送信要求に応じて障害レポートリクエストが送信される場合、実際の範囲が報告されていることを示すバイト範囲のヘッダーフィールドを含める必要があります。元の送信要求から範囲スタートと合計値をとることができますが、実際のボディデータからレンジエンドフィールドを計算する必要があります。
This section only describes failure report generation behavior for MSRP endpoints. Relay behavior is beyond the scope of this document, and will be considered in a separate document [23]. We expect failure reports to be more commonly generated by relays than by endpoints.
このセクションでは、MSRPエンドポイントの障害レポート生成動作についてのみについて説明します。リレーの動作はこのドキュメントの範囲を超えており、別のドキュメント[23]で考慮されます。故障レポートは、エンドポイントよりもリレーの方が一般的に生成されると予想されます。
If an MSRP endpoint receives a request that either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header field at all, it MUST immediately generate a response. Likewise, if an MSRP endpoint receives a request that contains a Failure-Report header field value of "partial", and the receiver is unable to process the request, it SHOULD immediately generate a response.
MSRPエンドポイントが、「はい」の故障レポートヘッダーフィールド値を含むか、障害レポートヘッダーフィールドをまったく含めていないリクエストを受信した場合、すぐに応答を生成する必要があります。同様に、MSRPエンドポイントが「部分的」の故障レポートヘッダーフィールド値を含むリクエストを受信し、レシーバーがリクエストを処理できない場合、すぐに応答を生成する必要があります。
To construct the response, the endpoint first creates the response start line, inserting the appropriate response code and optionally a comment. The transaction identifier in the response start line MUST match the transaction identifier from the original request.
応答を構築するために、エンドポイントは最初に応答スタート行を作成し、適切な応答コードとオプションでコメントを挿入します。応答開始行のトランザクション識別子は、元のリクエストからトランザクション識別子と一致する必要があります。
The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the first (leftmost) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by copying the list of URIs from the From-Path of the original request into the To-Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above; however, we expect that extensions for gateways and relays will need such behavior.)
エンドポイントは、適切なトーパスヘッダーフィールドを挿入します。応答をトリガーするリクエストが送信要求である場合、リクエストの最初の（左端の）URIをコピーすることにより、トゥパスヘッダーフィールドが形成されます。（送信リクエストへの応答は前のホップにのみ返されます。）他のすべてのリクエスト方法への応答については、トーパスヘッダーフィールドには元の送信者に戻るフルパスが含まれています。このフルパスは、元のリクエストのパスからURIのリストを応答のパスにコピーすることによって生成されます。（法的報告書のリクエストは応答を要求しないため、この仕様では上記の動作を行使しませんが、ゲートウェイとリレーの拡張にはそのような動作が必要になると予想されます。）
Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. Since a response is never chunked, the continuation flag in the end-line will always contain a dollar sign ("$"). The response MUST be transmitted back on the same connection on which the original request arrived.
最後に、エンドポイントは、セッションのコンテキストでそれを識別するURIを含むパスフロートヘッダーフィールドを挿入し、最後のヘッダーフィールドの後にエンドラインが続きます。応答が充電されないため、エンドラインの継続フラグには常にドル記号（ "$"）が含まれます。応答は、元のリクエストが到着したのと同じ接続に送信する必要があります。
The receiving endpoint MUST first check the URI in the To-Path to make sure the request belongs to an existing session. When the request is received, the To-Path will have exactly one URI, which MUST map to an existing session that is associated with the connection on which the request arrived. If this is not true, then the receiver MUST generate a 481 error and ignore the request. Note that if the Failure-Report header field had a value of "no", then no error report would be sent.
受信エンドポイントは、最初にトーパスのURIをチェックして、リクエストが既存のセッションに属していることを確認する必要があります。リクエストが受信されると、To-Pathには1つのURIが1つあります。これは、リクエストが届く接続に関連付けられている既存のセッションにマッピングする必要があります。これが真でない場合、レシーバーは481エラーを生成し、リクエストを無視する必要があります。故障レポートヘッダーフィールドに「いいえ」の値がある場合、エラーレポートは送信されないことに注意してください。
Further request processing by the receiver is method specific.
受信機によるさらなる要求処理は、方法固有のものです。
When the receiving endpoint receives a SEND request, it first determines if it contains a complete message or a chunk from a larger message. If the request contains no Byte-Range header field, or contains one with a range-start value of "1", and the closing line continuation flag has a value of "$", then the request contained the entire message. Otherwise, the receiver looks at the Message-ID value to associate chunks together into the original message. The receiver forms a virtual buffer to receive the message, keeping track of which bytes have been received and which are missing. The receiver takes the data from the request and places it in the appropriate place in the buffer. The receiver SHOULD determine the actual length of each chunk by inspecting the payload itself; it is possible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly. It is worth noting that the chunk that has a termination character of "$" defines the total length of the message.
受信エンドポイントが送信要求を受信すると、最初に、より大きなメッセージから完全なメッセージまたはチャンクが含まれているかどうかを判断します。リクエストにバイトレンジヘッダーフィールドが含まれていない場合、または「1」のレンジスタート値を持つものが含まれている場合、最後のラインの継続フラグには「$」の値がある場合、リクエストにはメッセージ全体が含まれています。それ以外の場合、受信者はメッセージ-ID値を調べて、チャンクを元のメッセージに関連付けます。受信機は、メッセージを受信するために仮想バッファーを形成し、どのバイトが受信され、どちらが欠落しているかを追跡します。受信者は、リクエストからデータを取得し、バッファ内の適切な場所に配置します。受信機は、ペイロード自体を検査することにより、各チャンクの実際の長さを決定する必要があります。ボディがレンジエンドフィールドが示すよりも短い可能性があります。これは、送信者が予期せず送信要求を中断した場合に発生する可能性があります。「$」の終端文字を持つチャンクがメッセージの全長を定義することは注目に値します。
It is technically illegal for the sender to prematurely interrupt a request that had anything other than "*" in the last-byte position of the Byte-Range header field. But having the receiver calculate a chunk length based on actual content adds resilience in the face of sender errors. Since this should never happen with compliant senders, this only has a "SHOULD" strength.
送信者が、バイトレンジヘッダーフィールドの最後の位置に「*」以外のものを持っていた要求を早期に中断することは技術的に違法です。ただし、レシーバーに実際のコンテンツに基づいてチャンク長を計算すると、送信者エラーに直面して回復力が追加されます。これは準拠した送信者では決して起こらないはずなので、これには「必要な」強度しかありません。
Receivers MUST not assume that the chunks will be delivered in order or that they will receive all the chunks with "+" flags before they receive the chunk with the "$" flag. In certain cases of connection failure, it is possible for information to be duplicated. If chunk data is received that overlaps already received data for the same message, the last chunk received SHOULD take precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to 100 were received and a chunk arrives that contains bytes 50 to 150, this second chunk will overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this is the easiest for the receiver and results in consistent behavior between clients.
レシーバーは、チャンクが順番に配達されること、または「$」フラグでチャンクを受け取る前に「フラグですべてのチャンクを受け取る」と想定してはなりません。接続障害の特定の場合、情報を複製する可能性があります。同じメッセージの重複が既に受信されたチャンクデータを受信した場合、受信した最後のチャンクは優先されるはずです（これは最後のチャンクが送信されなかったとしても）。たとえば、バイト1〜100が受信され、バイト50〜150を含むチャンクが到着した場合、この2番目のチャンクは、すでに受信されたデータのバイト50〜100を上書きします。他のスキームは機能しますが、これは受信機にとって最も簡単であり、クライアント間で一貫した動作をもたらします。
There are situations in which the receiver may not be able to give precedence to the last chunk received when chunks overlap. For example, the recipient might incrementally render chunks as they arrive. If a new chunk arrives that overlaps with a previously rendered chunk, it would be too late to "take back" any conflicting data from the first chunk. Therefore, the requirement to give precedence to the most recent chunk is specified at a "SHOULD" strength. This requirement is not intended to disallow applications where this behavior does not make sense.
チャンクが重複したときに受信した最後のチャンクに優先順位を付けることができない状況があります。たとえば、受信者は到着時に徐々にチャンクをレンダリングする場合があります。以前にレンダリングされたチャンクと重複する新しいチャンクが到着すると、最初のチャンクから競合するデータを「取り戻す」のに遅すぎます。したがって、最新のチャンクに優先されるための要件は、「必要な」強度で指定されます。この要件は、この動作が意味をなさないアプリケーションを禁止することを意図したものではありません。
The seven "-" in the end-line are used so that the receiver can
search for the value "----", 32 bits at a time to find the probable
location of the end-line. This allows most processors to locate the
boundaries and copy the memory at the same rate that a normal memory
copy could be done. This approach results in a system that is as
fast as framing based on specifying the body length in the header
fields of the request, but also allows for the interruption of
messages.
What is done with the body is outside the scope of MSRP and largely determined by the MIME Content-Type and Content-Disposition. The body MAY be rendered after the whole message is received or partially rendered as it is being received.
ボディで行われることは、MSRPの範囲外であり、MIMEコンテンツタイプとコンテンツディスポジションによって大きく決定されます。メッセージ全体が受信されるか、受信されているときに部分的にレンダリングされた後、ボディはレンダリングされる場合があります。
If the SEND request contained a Content-Type header field indicating an unsupported media-type, and the Failure-Report value is not "no", the receiver MUST generate a response with a status code of 415. All MSRP endpoints MUST be able to receive the multipart/mixed [15] and multipart/alternative [15] media-types.
送信要求に、サポートされていないメディアタイプを示すコンテンツタイプのヘッダーフィールドが含まれていて、故障レポート値が「いいえ」ではない場合、受信者は415のステータスコードで応答を生成する必要があります。MultiPart/Mixed [15]およびMultiPart/Alternative [15] Media-Typesを受信します。
If the Success-Report header field was set to "yes", the receiver must construct and send one or more success reports, as described in Section 7.1.3.
成功レポートヘッダーフィールドが「はい」に設定されている場合、セクション7.1.3で説明されているように、受信者は1つ以上の成功レポートを構築して送信する必要があります。
When an endpoint receives a REPORT request, it correlates the report to the original SEND request using the Message-ID and the Byte-Range, if present. If it requested success reports, then it SHOULD keep enough state about each outstanding sent message so that it can correlate REPORT requests to the original messages.
エンドポイントがレポートリクエストを受信すると、レポートをメッセージIDとバイトレンジを使用して元の送信要求と関連付けます（存在する場合）。サクセスレポートを要求した場合、レポートリクエストを元のメッセージに相関させることができるように、各未払いの送信メッセージについて十分な状態を維持する必要があります。
An endpoint that receives a REPORT request containing a Status header field with a namespace field of "000" MUST interpret the report in exactly the same way it would interpret an MSRP transaction response with a response code matching the status-code field.
「000」の名前空間フィールドを持つステータスヘッダーフィールドを含むレポートリクエストを受信するエンドポイントは、レポートを正確に同じ方法で解釈する必要があります。これは、MSRPトランザクション応答をステータスコードフィールドに一致させる応答コードで解釈する必要があります。
It is possible to receive a failure report or a failure transaction response for a chunk that is currently being delivered. In this case, the entire message corresponding to that chunk SHOULD be aborted, by including the "#" character in the continuation field of the end-line.
現在配信されているチャンクの失敗報告書または障害トランザクション応答を受け取ることができます。この場合、エンドラインの継続フィールドに「＃」文字を含めることにより、そのチャンクに対応するメッセージ全体を中止する必要があります。
It is possible that an endpoint will receive a REPORT request on a session that is no longer valid. The endpoint's behavior if this happens is a matter of local policy. The endpoint is not required to take any steps to facilitate such late delivery; i.e., it is not expected to keep a connection active in case late REPORTs might arrive.
エンドポイントが、もはや有効でないセッションのレポートリクエストを受信する可能性があります。これが発生した場合のエンドポイントの動作は、ローカルポリシーの問題です。エンドポイントは、このような遅い配達を促進するための措置を講じる必要はありません。つまり、遅いレポートが到着する可能性がある場合に、接続をアクティブに保つことは期待されていません。
When an endpoint that sent a SEND request receives a failure REPORT indicating that a particular byte range was not received, it MUST treat the session as failed. If it wishes to recover, it MUST first re-negotiate the URIs at the signaling level then resend that range of bytes of the message on the resulting new session.
送信要求を送信したエンドポイントが、特定のバイト範囲が受信されていないことを示す障害レポートを受信した場合、セッションを失敗したと扱う必要があります。回復を希望する場合は、まずシグナリングレベルでURIを再交渉し、その結果、結果の新しいセッションでメッセージのバイトの範囲を再送信する必要があります。
MSRP nodes MUST NOT send MSRP REPORT requests in response to other REPORT requests.
MSRPノードは、他のレポートリクエストに応じてMSRPレポートリクエストを送信してはなりません。
MSRP sessions will typically be initiated using the Session Description Protocol (SDP) [2] via the SIP offer/answer mechanism [3].
MSRPセッションは通常、SIPオファー/回答メカニズム[3]を介してセッション説明プロトコル（SDP）[2]を使用して開始されます。
This document defines a handful of new SDP parameters to set up MSRP sessions. These are detailed below and in the IANA Considerations section.
このドキュメントでは、MSRPセッションをセットアップするためのいくつかの新しいSDPパラメーターを定義します。これらは、以下とIANAの考慮事項セクションで詳しく説明しています。
An MSRP media-line (that is, a media-line proposing MSRP) in the session description is accompanied by a mandatory "path" attribute. This attribute contains a space-separated list of URIs to be visited to contact the user agent advertising this session description. If more than one URI is present, the leftmost URI is the first URI to be visited to reach the target resource. (The path list can contain multiple URIs to allow for the deployment of gateways or relays in the future.) MSRP implementations that can accept incoming connections without the need for relays will typically only provide a single URI here.
セッション説明のMSRPメディアライン（つまり、MSRPを提案するメディアライン）には、必須の「パス」属性が伴います。この属性には、このセッションの説明を宣伝するユーザーエージェントに連絡するために、訪問するURIのスペース分離されたリストが含まれています。複数のURIが存在する場合、左端のURIは、ターゲットリソースに到達した最初のURIです。（パスリストには、将来のゲートウェイまたはリレーの展開を可能にするために複数のURIを含めることができます。）リレーを必要とせずに着信接続を受け入れることができるMSRP実装は、通常、1つのURIのみを提供します。
An MSRP media line is also accompanied by an "accept-types" attribute, and optionally an "accept-wrapped-types" attribute. These attributes are used to specify the media-types that are acceptable to the endpoint.
MSRPメディアラインには、「Accept-Types」属性と、オプションで「Accept-wrapped-Types」属性も伴います。これらの属性は、エンドポイントに受け入れられるメディアタイプを指定するために使用されます。
An SDP connection-line takes the following format:
SDP接続ラインは、次の形式を取得します。
c=<network type> <address type> <connection address>
Figure 4: Standard SDP Connection Line
図4：標準のSDP接続線
The network type and address type fields are used as normal for SDP. The connection address field MUST be set to the IP address or fully qualified domain name from the MSRP URI identifying the endpoint in its path attribute.
ネットワークタイプとアドレスタイプフィールドは、SDPに対して通常として使用されます。接続アドレスフィールドは、PATH属性のエンドポイントを識別するMSRP URIのIPアドレスまたは完全に適格なドメイン名に設定する必要があります。
The general format of an SDP media-line is:
SDPメディアラインの一般的な形式は次のとおりです。
m=<media> <port> <protocol> <format list>
Figure 5: Standard SDP Media Line
図5：標準のSDPメディアライン
An offered or accepted media-line for MSRP over TCP MUST include a protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The media field value MUST be "message". The format list field MUST be set to "*".
TCPを介したMSRPの提供または受け入れられたメディアラインには、TLSの「TCP/MSRP」または「TCP/TLS/MSRP」のプロトコルフィールド値を含める必要があります。メディアフィールド値は「メッセージ」でなければなりません。フォーマットリストフィールドは「*」に設定する必要があります。
The port field value MUST match the port value used in the endpoint's MSRP URI in the path attribute, except that, as described in [3], a user agent that wishes to accept an offer, but not a specific media-line, MUST set the port number of that media-line to zero (0) in the response. Since MSRP allows multiple sessions to share the same TCP connection, multiple m-lines in a single SDP document may share the same port field value; MSRP devices MUST NOT assume any particular relationship between m-lines on the sole basis that they have matching port field values.
[3]で説明されているように、特定のメディアラインではなくオファーを受け入れたいユーザーエージェントであることを除いて、ポートフィールド値はパス属性のエンドポイントのMSRP URIで使用されるポート値と一致する必要があります。そのメディアラインのポート番号は、応答のゼロ（0）までです。MSRPは複数のセッションが同じTCP接続を共有できるようにするため、単一のSDPドキュメントの複数のMラインが同じポートフィールド値を共有する場合があります。MSRPデバイスは、ポートフィールドの値が一致するという単独で、Mライン間の特定の関係を想定してはなりません。
MSRP devices do not use the c-line address field, or the m-line port and format list fields to determine where to connect. Rather, they use the attributes defined in this specification. The connection information is copied to the c-line and m-line for purposes of backwards compatibility with conventional SDP usages. While MSRP could theoretically carry any media-type, "message" is appropriate.
MSRPデバイスは、C-Lineアドレスフィールド、またはM-Lineポートとフォーマットリストフィールドを使用して、接続する場所を決定しません。むしろ、この仕様で定義されている属性を使用します。接続情報は、従来のSDP使用との逆方向の互換性を目的として、CラインとMラインにコピーされます。MSRPは理論的には任意のメディアタイプを運ぶことができますが、「メッセージ」が適切です。
Each endpoint in an MSRP session is identified by a URI. These URIs are negotiated in the SDP exchange. Each SDP offer or answer that proposes MSRP MUST contain a "path" attribute containing one or more MSRP URIs. The path attribute is used in an SDP a-line, and has the following syntax:
MSRPセッションの各エンドポイントは、URIによって識別されます。これらのURIは、SDP交換で交渉されています。MSRPを提案する各SDPオファーまたは回答は、1つ以上のMSRP URIを含む「パス」属性を含める必要があります。パス属性はSDP Aラインで使用され、次の構文があります。
path = path-label ":" path-list
path-label = "path"
path-list= MSRP-URI *(SP MSRP-URI)
Figure 6: Path Attribute
図6：パス属性
where MSRP-URI is an "msrp" or "msrps" URI as defined in Section 6. MSRP URIs included in an SDP offer or answer MUST include explicit port numbers.
ここで、MSRP-URIはセクション6で定義されている「MSRP」または「MSRPS」URIです。SDPオファーまたは回答に含まれるMSRP URIは、明示的なポート番号を含める必要があります。
An MSRP device uses the URI to determine a host address, port, transport, and protection level when connecting, and to identify the target when sending requests and responses.
MSRPデバイスは、URIを使用して、接続時にホストアドレス、ポート、トランスポート、および保護レベルを決定し、リクエストと応答を送信するときにターゲットを特定します。
The offerer and answerer each selects a URI to represent itself and sends that URI to its peer in the SDP document. Each peer stores the path value received from the other peer and uses that value as the target for requests inside the resulting session. If the path attribute received from the peer contains more than one URI, then the target URI is the rightmost, while the leftmost entry represents the adjacent hop. If only one entry is present, then it is both the peer and adjacent hop URI. The target path is the entire path attribute value received from the peer.
オファーと応答者はそれぞれURIを選択して自分自身を表現し、そのURIをSDPドキュメントでその仲間に送信します。各ピアは、他のピアから受信したパス値を保存し、結果セッション内のリクエストのターゲットとしてその値を使用します。ピアから受信したパス属性に複数のURIが含まれている場合、ターゲットURIは右端です。一方、左端のエントリは隣接するホップを表します。エントリが1つしかない場合、それはピアと隣接するホップウリの両方です。ターゲットパスは、ピアから受信したパス属性値全体です。
The following example shows an SDP offer with a session URI of "msrp://alice.example.com:7394/2s93i9ek2a;tcp"
次の例は、「msrp：//alice.example.com：7394/2S93I9EK2A; TCP」のセッションURIを含むSDPオファーを示しています。
v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alice.example.com:7394/2s93i9ek2a;tcp
Figure 7: Example SDP with Path Attribute
図7：パス属性を備えたSDPの例
The rightmost URI in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URI in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14.
パス属性の右端のURIは、SDPドキュメントを生成したエンドポイント、またはそのエンドポイントがセッションに関連付けられたリクエストを受信したい他の場所を識別する必要があります。この特定のセッションに割り当てる必要があり、エンドポイントが現在参加している他のセッションに使用されているURIを複製してはなりません。推測するのは難しいはずであり、盗聴者から保護されています。これについては、セクション14で詳しく説明します。
As mentioned previously, this document describes MSRP for peer-to-peer scenarios, that is, when no relays are used. The use of relays is described in a separate document [23]. In order to allow an MSRP device that only implements the core specification to interoperate with devices that use relays, this document must include a few assumptions about how relays work.
前述のように、このドキュメントでは、ピアツーピアシナリオのMSRPについて説明します。つまり、リレーが使用されない場合です。リレーの使用は、別のドキュメント[23]で説明されています。コア仕様のみを実装するMSRPデバイスがリレーを使用するデバイスと相互運用することを許可するには、このドキュメントにリレーの仕組みに関するいくつかの仮定を含める必要があります。
An endpoint that uses one or more relays will indicate that by putting a URI for each device in the relay chain into the SDP path attribute. The final entry will point to the endpoint itself. The other entries will indicate each proposed relay, in order. The first entry will point to the first relay in the chain from the perspective of the peer, that is, the relay to which the peer device, or a relay operating on its behalf, should connect.
1つ以上のリレーを使用するエンドポイントは、リレーチェーン内の各デバイスにURIをSDPパス属性に配置することにより、それを示します。最終エントリは、エンドポイント自体を指します。他のエントリは、提案された各リレーを順番に示します。最初のエントリは、ピアの観点からチェーン内の最初のリレーを指します。つまり、ピアデバイス、またはその代わりに動作するリレーが接続するリレーを指します。
Endpoints that do not wish to insert a relay, including those that do not support relays at all, will put exactly one URI into the path attribute. This URI represents both the endpoint for the session and the connection point.
リレーをまったくサポートしていないリレーを含むリレーを挿入したくないエンドポイントは、正確に1つのURIをパス属性に入れます。このURIは、セッションのエンドポイントと接続ポイントの両方を表します。
Even though endpoints that implement only this specification will never introduce a relay, they need to be able to interoperate with other endpoints that do use relays. Therefore, they MUST be prepared to receive more than one URI in the SDP path attribute. When an endpoint receives more than one URI in a path attribute, only the first entry is relevant for purposes of resolving the address and port, and establishing the network connection, as it describes the first adjacent hop.
この仕様のみを実装するエンドポイントは、リレーを導入することはありませんが、リレーを使用する他のエンドポイントと相互運用できる必要があります。したがって、SDPパス属性で複数のURIを受け取る準備をする必要があります。エンドポイントがパス属性で複数のURIを受信する場合、最初の隣接ホップを説明するため、アドレスとポートを解決し、ネットワーク接続を確立する目的で最初のエントリのみが関連します。
If an endpoint puts more than one URI in a path attribute, the final URI in the path attribute (the peer URI) identifies the session, and MUST not duplicate the URI of any other session in which the endpoint is currently participating. Uniqueness requirements for other entries in the path attribute are out of scope for this document.
エンドポイントがパス属性に複数のURIを配置する場合、パス属性（ピアURI）の最終URIがセッションを識別し、エンドポイントが現在参加している他のセッションのURIを複製してはなりません。パス属性の他のエントリの一意性要件は、このドキュメントの範囲外です。
MSRP endpoints may sometimes need to send additional SDP exchanges for an existing session. They may need to send periodic exchanges with no change to refresh state in the network, for example, SIP session timers or the SIP UPDATE [24] request. They may need to change some other stream in a session without affecting the MSRP stream, or they may need to change an MSRP stream without affecting some other stream.
MSRPエンドポイントは、既存のセッションのために追加のSDP交換を送信する必要がある場合があります。SIPセッションタイマーやSIPアップデート[24]リクエストなど、ネットワーク内の状態を更新するために変更なしで定期的な交換を送信する必要がある場合があります。MSRPストリームに影響を与えることなくセッションで他のストリームを変更する必要がある場合や、他のストリームに影響を与えることなくMSRPストリームを変更する必要がある場合があります。
Either peer may initiate an updated exchange at any time. The endpoint that sends the new offer assumes the role of offerer for all purposes. The answerer MUST respond with a path attribute that represents a valid path to itself at the time of the updated exchange. This new path may be the same as its previous path, but may be different. The new offerer MUST NOT assume that the peer will answer with the same path it used previously.
どちらのピアも、いつでも更新された交換を開始する場合があります。新しいオファーを送信するエンドポイントは、あらゆる目的でオファーの役割を想定しています。応答者は、更新された交換時にそれ自体への有効なパスを表すパス属性で応答する必要があります。この新しいパスは、以前のパスと同じかもしれませんが、異なる場合があります。新しい提供者は、ピアが以前に使用したのと同じパスで答えると想定してはなりません。
If either party wishes to send an SDP document that changes nothing at all, then it MUST use the same o-line as in the previous exchange.
いずれかの当事者が、何も変更しないSDPドキュメントを送信したい場合は、以前の交換と同じOラインを使用する必要があります。
Previous versions of this document included a mechanism to negotiate the direction for any required TCP connection. The mechanism was loosely based on the Connection-Oriented Media (COMEDIA) [26] work done by the MMUSIC working group. The primary motivation was to allow MSRP sessions to succeed in situations where the offerer could not accept connections but the answerer could. For example, the offerer might be behind a NAT, while the answerer might have a globally routable address.
このドキュメントの以前のバージョンには、必要なTCP接続の方向を交渉するメカニズムが含まれていました。このメカニズムは、MMUSICワーキンググループによって行われた接続指向のメディア（コメディア）[26]作業に大まかに基づいていました。主な動機は、申し出人が接続を受け入れることができない状況でMSRPセッションを成功させることを許可することでした。たとえば、提供者はNATの後ろにいる可能性がありますが、応答者にはグローバルにルーティング可能なアドレスがある場合があります。
The SIMPLE working group chose to remove that mechanism from MSRP, as it added a great deal of complexity to connection management. Instead, MSRP now specifies a default connection direction. The party that sent the original offer is responsible for connecting to its peer.
シンプルなワーキンググループは、MSRPからそのメカニズムを削除することを選択しました。これは、接続管理に多大な複雑さを追加しました。代わりに、MSRPがデフォルトの接続方向を指定するようになりました。元のオファーを送ったパーティーは、その仲間に接続する責任があります。
An SDP media-line proposing MSRP MUST be accompanied by an accept-types attribute.
MSRPを提案するSDPメディアラインには、Accept-Types属性を添付する必要があります。
An entry of "*" in the accept-types attribute indicates that the sender may attempt to send content with media-types that have not been explicitly listed. Likewise, an entry with an explicit type and a "*" character as the subtype indicates that the sender may attempt to send content with any subtype of that type. If the receiver receives an MSRP request and is able to process the media-type, it does so. If not, it will respond with a 415 response. Note that all explicit entries SHOULD be considered preferred over any non-listed types. This feature is needed as, otherwise, the list of formats for rich IM devices may be prohibitively large.
Accept-Types属性の「*」のエントリは、送信者が明示的にリストされていないメディアタイプでコンテンツを送信しようとすることを示します。同様に、サブタイプとしての明示的なタイプと「*」文字を持つエントリは、送信者がそのタイプのサブタイプでコンテンツを送信しようとすることを示します。受信者がMSRPリクエストを受信し、メディアタイプを処理できる場合、そうします。そうでない場合は、415の応答で応答します。すべての明示的なエントリは、リストされていないタイプよりも優先されると見なされるべきであることに注意してください。そうしないと、リッチIMデバイスのフォーマットのリストが非常に大きい場合があるため、この機能が必要です。
This specification requires the support of certain data formats. Mandatory formats MUST be signaled like any other, either explicitly or by the use of a "*".
この仕様には、特定のデータ形式のサポートが必要です。必須の形式は、明示的に、または「*」の使用により、他の形式と同様に信号を送信する必要があります。
The accept-types attribute may include container types, that is, MIME formats that contain other types internally. If compound types are used, the types listed in the accept-types attribute may be used as the root payload or may be wrapped in a listed container type. Any container types MUST also be listed in the accept-types attribute.
Accept-Types属性には、コンテナタイプ、つまり内部に他のタイプを含むMIME形式が含まれる場合があります。化合物タイプを使用すると、Accept-Types属性にリストされているタイプは、ルートペイロードとして使用されるか、リストされているコンテナタイプに包まれてもよいです。任意のコンテナタイプは、Accept-Types属性にもリストする必要があります。
Occasionally, an endpoint will need to specify a MIME media-type that can only be used if wrapped inside a listed container type.
場合によっては、エンドポイントでは、リストされたコンテナタイプに包まれた場合にのみ使用できるMIMEメディアタイプを指定する必要があります。
Endpoints MAY specify media-types that are only allowed when wrapped inside compound types using the "accept-wrapped-types" attribute in an SDP a-line.
エンドポイントは、SDP A-Lineの「Accept-wrapped-Types」属性を使用して、化合物の型を包むときにのみ許可されるメディアタイプを指定できます。
The semantics for accept-wrapped-types are identical to those of the accept-types attribute, with the exception that the specified types may only be used when wrapped inside container types listed in the accept-types attribute. Only types listed in the accept-types attribute may be used as the "root" type for the entire body. Since any type listed in accept-types may be both used as a root body and wrapped in other bodies, format entries from accept-types SHOULD NOT be repeated in this attribute.
受け入れられたタイプのセマンティクスは、accept-types属性にリストされているコンテナタイプ内にラップされた場合にのみ使用できることを除いて、Accept-types属性のセマンティクスと同一です。Accept-Types属性にリストされているタイプのみを、全身の「ルート」タイプとして使用できます。Accept-Typesにリストされている任意のタイプは、ルートボディとして使用され、他のボディに包まれている可能性があるため、この属性では、容認タイプのフォーマットエントリを繰り返さないでください。
This approach does not allow for specifying distinct lists of acceptable wrapped types for different types of containers. If an endpoint understands a media-type in the context of one wrapper, it is assumed to understand it in the context of any other acceptable wrappers, subject to any constraints defined by the wrapper types themselves.
このアプローチでは、さまざまなタイプのコンテナに対して許容可能なラップタイプの異なるリストを指定することはできません。エンドポイントが1つのラッパーのコンテキストでメディア型を理解している場合、ラッパータイプ自体によって定義された制約を条件として、他の許容可能なラッパーのコンテキストでそれを理解することが想定されます。
The approach of specifying types that are only allowed inside of containers separately from the primary payload types allows an endpoint to force the use of certain wrappers. For example, a Common Presence and Instant Messaging (CPIM) [12] gateway device may require all messages to be wrapped inside message/cpim bodies, but may allow several content types inside the wrapper. If the gateway were to specify the wrapped types in the accept-types attribute, its peer might attempt to use those types without the wrapper.
プライマリペイロードタイプとは別にコンテナの内部でのみ許可されるタイプを指定するアプローチにより、エンドポイントは特定のラッパーの使用を強制することができます。たとえば、一般的な存在感とインスタントメッセージング（CPIM）[12]ゲートウェイデバイスでは、すべてのメッセージをメッセージ/CPIMボディ内にラップする必要がありますが、ラッパー内に複数のコンテンツタイプを許可する場合があります。ゲートウェイがaccept-types属性にラップされたタイプを指定する場合、そのピアはラッパーなしでこれらのタイプを使用しようとする場合があります。
If the recipient of an offer does not understand any of the payload types indicated in the offered SDP, it SHOULD indicate that using the appropriate mechanism of the rendezvous protocol. For example, in SIP, it SHOULD return a SIP 488 response.
オファーの受信者が提供されたSDPに示されているペイロードタイプのいずれを理解していない場合、ランデブープロトコルの適切なメカニズムを使用することを示す必要があります。たとえば、SIPでは、SIP 488応答を返す必要があります。
An MSRP endpoint MUST NOT send content of a type not signaled by the peer in either an accept-types or an accept-wrapped-types attribute. Furthermore, it MUST NOT send a top-level (i.e., not wrapped) MIME document of a type not signaled in the accept-types attribute. In either case, the signaling could be explicit, or implicit through the use of the "*" character.
MSRPエンドポイントは、受け入れ型または受け入れ型タイプの属性のいずれでもピアによって信号されていないタイプのコンテンツを送信してはなりません。さらに、Accept-Types属性で信号されていないタイプのトップレベルの（つまり、ラップされていない）MIMEドキュメントを送信してはなりません。どちらの場合でも、「*」文字を使用することにより、シグナル伝達が明示的であるか、暗黙的である可能性があります。
An endpoint MAY indicate the maximum size message it wishes to receive using the max-size a-line attribute. Max-size refers to the complete message in octets, not the size of any one chunk. Senders SHOULD NOT exceed the max-size limit for any message sent in the resulting session. However, the receiver should consider max-size value as a hint.
エンドポイントは、最大サイズのAライン属性を使用して受信したい最大サイズのメッセージを示す場合があります。Max-Sizeは、1つのチャンクのサイズではなく、オクテットの完全なメッセージを指します。送信者は、結果のセッションで送信されたメッセージの最大サイズの制限を超えてはなりません。ただし、受信者はマックスサイズの値をヒントと見なす必要があります。
Media format entries may include parameters. The interpretation of such parameters varies between media-types. For the purposes of media-type negotiation, a format-entry with one or more parameters is assumed to match the same format-entry with no parameters.
メディア形式のエントリにはパラメーターが含まれる場合があります。このようなパラメーターの解釈は、メディアタイプ間で異なります。メディアタイプのネゴシエーションの目的のために、1つ以上のパラメーターを持つ形式のエントリは、同じ形式の入力をパラメーターなしで一致させると想定されています。
The formal syntax for these attributes is as follows:
これらの属性の正式な構文は次のとおりです。
accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry)
format-entry = ( ( (type "/" subtype)
/ (type "/" "*") )
*( ";" type-param ) )
/ ("*")
type = token
subtype = token
type-param = parm-attribute "=" parm-value
parm-attribute = token
parm-value = token / quoted-string
max-size = max-size-label ":" max-size-value
max-size-label = "max-size"
max-size-value = 1*(DIGIT) ; max size in octets
Figure 8: Attribute Syntax
図8：属性構文
Endpoint A wishes to invite Endpoint B to an MSRP session. A offers the following session description:
エンドポイントAは、EndPoint BをMSRPセッションに招待したいと考えています。Aは次のセッションの説明を提供します。
v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i93idj;tcp
Figure 9: SDP from Endpoint A
図9：エンドポイントaからのSDP
B responds with its own URI:
Bは独自のURIで応答します：
v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8493 TCP/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438dsaodes;tcp
Figure 10: SDP from Endpoint B
図10：エンドポイントbからのSDP
In typical SIP applications, when an endpoint receives an INVITE request, it alerts the user, and waits for user input before responding. This is analogous to the typical telephone user experience, where the callee "answers" the call.
典型的なSIPアプリケーションでは、エンドポイントが招待リクエストを受信すると、ユーザーにアラートし、応答する前にユーザーの入力を待ちます。これは、Calleeがコールに「回答」する典型的な電話ユーザーエクスペリエンスに類似しています。
In contrast, the typical user experience for instant messaging applications is that the initial received message is immediately displayed to the user, without waiting for the user to "join" the conversation. Therefore, the principle of least surprise would suggest that MSRP endpoints using SIP signaling SHOULD allow a mode where the endpoint quietly accepts the session and begins displaying messages.
対照的に、インスタントメッセージングアプリケーションの典型的なユーザーエクスペリエンスは、ユーザーが会話に「参加」するのを待つことなく、最初の受信メッセージがすぐにユーザーに表示されることです。したがって、最も驚きの原則は、SIPシグナル伝達を使用したMSRPエンドポイントがセッションを静かに受け入れ、メッセージの表示を開始するモードを可能にする必要があることを示唆しています。
This guideline may not make sense for all situations, such as for mixed-media applications, where both MSRP and audio sessions are offered in the same INVITE. In general, good application design should take precedence.
このガイドラインは、MSRPとオーディオセッションの両方が同じ招待状で提供される混合メディアアプリケーションなど、すべての状況について意味がない場合があります。一般に、適切なアプリケーション設計が優先されるはずです。
SIP INVITE requests may be forked by a SIP proxy, resulting in more than one endpoint receiving the same INVITE. SIP early media [29] techniques can be used to establish a preliminary session with each endpoint so the initial message(s) are displayed on each endpoint, and canceling the INVITE transaction for any endpoints that do not send MSRP traffic after some period of time, so that they cease receiving MSRP traffic from the inviter.
SIP Inviteリクエストは、SIPプロキシによって分岐する可能性があり、その結果、複数のエンドポイントが同じ招待状を受信します。SIP Early Media [29]手法を使用して、各エンドポイントとの予備セッションを確立することができ、最初のメッセージが各エンドポイントに表示され、ある期間後にMSRPトラフィックを送信しないエンドポイントのInviteトランザクションをキャンセルします。、彼らがInviterからMSRPトラフィックの受信をやめるようにします。
SDP defines a number of attributes that modify the direction of media flows. These are the "sendonly", "recvonly", "inactive", and "sendrecv" attributes.
SDPは、メディアフローの方向を変更する多くの属性を定義します。これらは、「Sendonly」、「Recvonly」、「非アクティブ」、および「SendRecv」属性です。
If a "sendonly" or "recvonly" attribute modifies an MSRP media description line, the attribute indicates the direction of MSRP SEND requests that contain regular message payloads. Unless otherwise specified, these attributes do not affect the direction of other types of requests, such as REPORT. SEND requests that contain some kind of control or reporting protocol rather than regular message payload (e.g., Instant Message Delivery Notification (IMDN) reports) should be generated according to the protocol rules as if no direction attribute were present.
「sendonly」または「recvonly」属性がMSRPメディアの説明行を変更する場合、属性は通常のメッセージペイロードを含むMSRP送信要求の方向を示します。特に指定されていない限り、これらの属性は、レポートなど、他のタイプのリクエストの方向に影響しません。通常のメッセージペイロードではなく、何らかの種類のコントロールまたはレポートプロトコルを含むリクエストを送信します（たとえば、インスタントメッセージ配信通知（IMDN）レポート）は、方向属性が存在しないかのようにプロトコルルールに従って生成する必要があります。
MSRP is a text protocol that uses the UTF-8 [14] transformation format.
MSRPは、UTF-8 [14]変換形式を使用するテキストプロトコルです。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [6].
次の構文仕様では、RFC 4234 [6]に記載されているように、拡張されたバックナウル形式（BNF）を使用しています。
msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers [content-stuff] end-line msrp-response = resp-start headers end-line
msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-startヘッダー[コンテンツスタッフ]エンドラインmsrp-response = resp-startヘッダーエンドライン
req-start = pMSRP SP transact-id SP method CRLF resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF comment = utf8text
req-start = pmsrp sp transact-id sp method crlf resp-start = pmsrp transact-id spステータスコード[SPコメント] CRLFコメント= utf8text
pMSRP = %x4D.53.52.50 ; MSRP in caps
transact-id = ident
method = mSEND / mREPORT / other-method
mSEND = %x53.45.4e.44 ; SEND in caps
mREPORT = %x52.45.50.4f.52.54; REPORT in caps
other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document
; or an extension document
MSRP-URI = msrp-scheme "://" authority
["/" session-id] ";" transport *( ";" URI-parameter)
; authority as defined in RFC3986
msrp-scheme = "msrp" / "msrps"
session-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
transport = "tcp" / 1*ALPHANUM
URI-parameter = token ["=" token]
headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header = Message-ID
/ Success-Report
/ Failure-Report
/ Byte-Range
/ Status
/ ext-header
To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI )
From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI )
Message-ID = "Message-ID:" SP ident
Success-Report = "Success-Report:" SP ("yes" / "no" )
Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" )
Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
range-start = 1*DIGIT
range-end = 1*DIGIT / "*"
total = 1*DIGIT / "*"
Status = "Status:" SP namespace SP status-code [SP comment] namespace = 3(DIGIT); "000" for all codes defined in this document.
status = "status：" sp namespace sp status-code [sp comment] namespace = 3（digit）;このドキュメントで定義されているすべてのコードの「000」。
ident = ALPHANUM 3*31ident-char
ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="
content-stuff = *(Other-Mime-header CRLF)
Content-Type 2CRLF data CRLF
Content-Type = "Content-Type:" SP media-type
media-type = type "/" subtype *( ";" gen-param )
type = token
subtype = token
gen-param = pname [ "=" pval ]
pname = token
pval = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
Other-Mime-header = (Content-ID
/ Content-Description
/ Content-Disposition
/ mime-extension-field)
; Content-ID, and Content-Description are defined in RFC2045.
; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension
; header fields as described in RFC2045
data = *OCTET
end-line = "-------" transact-id continuation-flag CRLF
continuation-flag = "+" / "$" / "#"
ext-header = hname ":" SP hval CRLF
hname = ALPHA *token
hval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
Figure 11: MSRP ABNF
図11：MSRP ABNF
This section summarizes the semantics of various response codes that may be used in MSRP transaction responses. These codes may also be used in the Status header field in REPORT requests.
このセクションでは、MSRPトランザクション応答で使用できるさまざまな応答コードのセマンティクスをまとめたものです。これらのコードは、レポートリクエストのステータスヘッダーフィールドでも使用できます。
The 200 response code indicates a successful transaction.
200の応答コードは、トランザクションが成功したことを示しています。
A 400 response indicates that a request was unintelligible. The sender may retry the request after correcting the error.
400の応答は、リクエストが理解できないことを示します。送信者は、エラーを修正した後、リクエストを再試行する場合があります。
A 403 response indicates that the attempted action is not allowed. The sender should not try the request again.
403の応答は、試行されたアクションが許可されていないことを示します。送信者は、再度リクエストを試してはいけません。
A 408 response indicates that a downstream transaction did not complete in the allotted time. It is never sent by any elements described in this specification. However, 408 is used in the MSRP relay extension; therefore, MSRP endpoints may receive it. An endpoint MUST treat a 408 response in the same manner as it would treat a local timeout.
408の応答は、割り当てられた時間に下流のトランザクションが完了しなかったことを示しています。この仕様に記載されている要素によって送信されることはありません。ただし、408はMSRPリレーエクステンションで使用されます。したがって、MSRPエンドポイントはそれを受信する場合があります。エンドポイントは、ローカルタイムアウトを扱うのと同じ方法で408の応答を扱う必要があります。
A 413 response indicates that the receiver wishes the sender to stop sending the particular message. Typically, a 413 is sent in response to a chunk of an undesired message.
413の応答は、受信者が送信者に特定のメッセージの送信を停止することを望んでいることを示しています。通常、413は、望ましくないメッセージの塊に応じて送信されます。
If a message sender receives a 413 in a response, or in a REPORT request, it MUST NOT send any further chunks in the message, that is, any further chunks with the same Message-ID value. If the sender receives the 413 while in the process of sending a chunk, and the chunk is interruptible, the sender MUST interrupt it.
メッセージ送信者が応答で413を受信したり、レポートリクエストで受信した場合、メッセージにさらにチャンクを送信してはなりません。つまり、同じメッセージID値を持つさらにチャンクを送信してはなりません。送信者がチャンクを送信する過程で413を受信し、チャンクが中断可能である場合、送信者はそれを中断する必要があります。
A 415 response indicates that the SEND request contained a media type that is not understood by the receiver. The sender should not send any further messages with the same content-type for the duration of the session.
415の応答は、送信要求に、受信者が理解していないメディアタイプが含まれていることを示しています。送信者は、セッションの期間中、同じコンテンツタイプのメッセージをさらに送信してはなりません。
A 423 response indicates that one of the requested parameters is out of bounds. It is used by the relay extensions to this document.
423の応答は、要求されたパラメーターの1つが範囲外であることを示しています。リレー拡張機能によってこのドキュメントに使用されます。
A 481 response indicates that the indicated session does not exist. The sender should terminate the session.
481の応答は、示されたセッションが存在しないことを示します。送信者はセッションを終了する必要があります。
A 501 response indicates that the recipient does not understand the request method.
501応答は、受信者がリクエスト方法を理解していないことを示します。
The 501 response code exists to allow some degree of method extensibility. It is not intended as a license to ignore methods defined in this document; rather, it is a mechanism to report lack of support of extension methods.
501の応答コードは、ある程度のメソッドの拡張性を可能にするために存在します。このドキュメントで定義されている方法を無視するライセンスとして意図されていません。むしろ、拡張方法のサポートの欠如を報告するメカニズムです。
A 506 response indicates that a request arrived on a session that is already bound to another network connection. The sender should cease sending messages for that session on this connection.
506の応答は、すでに別のネットワーク接続に拘束されているセッションにリクエストが届いたことを示しています。送信者は、この接続でそのセッションのメッセージの送信をやめる必要があります。
This section shows an example flow for the most common scenario. The example assumes SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the example, assume that the offerer is sip:alice@example.com and the answerer is sip:bob@example.com.
このセクションでは、最も一般的なシナリオのフローの例を示しています。この例は、SIPがSDP交換の輸送に使用されると仮定しています。SIPメッセージとSIPプロキシインフラストラクチャの詳細は、簡潔にするために省略されています。この例では、提供者がsip：alice@example.comであり、回答者がsip：bob@example.comであると仮定します。
Alice Bob
| |
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
|(4) (MSRP) SEND |
|----------------------->|
|(5) (MSRP) 200 OK |
|<-----------------------|
|(6) (MSRP) SEND |
|<-----------------------|
|(7) (MSRP) 200 OK |
|----------------------->|
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
Figure 12: Basic IM Session Example
図12：基本的なIMセッションの例
1. Alice constructs a local URI of msrp://alicepc.example.com:7777/iau39soe2843z;tcp .
1. アリスは、MSRP：//Alicepc.example.comのローカルURIを構築します：7777/IAU39SOE2843Z; TCP。
Alice->Bob (SIP): INVITE sip:bob@example.com
v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= -
c=IN IP4 alicepc.example.com
t=0 0
m=message 7777 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp
2. Bob listens on port 8888, and sends the following response:
2. ボブはポート8888に耳を傾け、次の回答を送信します。
Bob->Alice (SIP): 200 OK
ボブ - >アリス（SIP）：200 OK
v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp
3. Alice->Bob (SIP): ACK sip:bob@example.com
3. Alice-> Bob（SIP）：ACK SIP：bob@example.com
4. (Alice opens connection to Bob.) Alice->Bob (MSRP):
4. （アリスはボブとのつながりを開きます。）アリス - >ボブ（MSRP）：
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-16/16
Content-Type: text/plain
Hi, I'm Alice!
-------d93kswow$
5. Bob->Alice (MSRP):
5. ボブ - >アリス（MSRP）：
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$
6. Bob->Alice (MSRP):
6. ボブ - >アリス（MSRP）：
MSRP dkei38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456s9wlk3
Byte-Range: 1-21/21
Content-Type: text/plain
Hi, Alice! I'm Bob!
-------dkei38sd$
7. Alice->Bob (MSRP):
7. アリス - >ボブ（MSRP）：
MSRP dkei38sd 200 OK
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
-------dkei38sd$
8. Alice->Bob (SIP): BYE sip:bob@example.com
8. アリス - >ボブ（SIP）：さようならsip：bob@example.com
Alice invalidates local session state.
アリスはローカルセッションの状態を無効にします。
9. Bob invalidates local state for the session.
9. ボブはセッションのために地方の状態を無効にします。
Bob->Alice (SIP): 200 OK
ボブ - >アリス（SIP）：200 OK
MSRP dsdfoe38sd SEND
To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-374/374
Content-Type: application/xhtml+xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>FY2005 Results</title>
</head>
<body>
<p>See the results at <a
href="http://example.org/">example.org</a>.</p>
</body>
</html>
-------dsdfoe38sd$
Figure 13: Example Message with XHTML
図13：XHTMLを使用したメッセージの例
For an example of a chunked message, see the example in Section 5.1.
チャンクされたメッセージの例については、セクション5.1の例を参照してください。
This example shows a chunked message containing a CPIM message that wraps a text/plain payload. It is worth noting that MSRP considers the complete CPIM message before chunking the message; thus, the CPIM headers are included in only the first chunk. The MSRP Content-Type and Byte-Range headers, present in both chunks, refer to the whole CPIM message.
この例は、テキスト/プレーンペイロードをラップするCPIMメッセージを含むチャンクメッセージを示しています。MSRPがメッセージをチャンキングする前に完全なCPIMメッセージを考慮していることは注目に値します。したがって、CPIMヘッダーは最初のチャンクのみに含まれています。両方のチャンクに存在するMSRPコンテンツタイプとバイト範囲のヘッダーは、CPIMメッセージ全体を参照しています。
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-137/148
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Type: text/plain
ABCD
-------d93kswow+
Figure 14: First Chunk
図14：最初のチャンク
Alice sends the second and last chunk.
アリスは2番目と最後のチャンクを送ります。
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 138-148/148
Content-Type: message/cpim
1234567890
-------op2nc9a$
Figure 15: Second Chunk
図15：2番目のチャンク
Sysadmin->Alice (MSRP):
sysadmin-> alice（msrp）：
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-38/38
Failure-Report: no
Success-Report: no
Content-Type: text/plain
This conference will end in 5 minutes
-------d93kswow$
Alice->Bob (MSRP):
アリス - >ボブ（MSRP）：
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Success-Report: yes
Failure-Report: no
Content-Type: text/html
<html><body>
<p>Here is that important link...
<a href="http://www.example.com/foobar">foobar</a>
</p>
</body></html>
-------d93kswow$
Figure 16: Initial SEND Request
図16：初期送信リクエスト
Bob->Alice (MSRP):
ボブ - >アリス（MSRP）：
MSRP dkei38sd REPORT
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-106/106
Status: 000 200 OK
-------dkei38sd$
Figure 17: Success Report
図17：成功レポート
Traditional IM systems generally do a poor job of handling multiple simultaneous IM clients online for the same person. While some do a better job than many existing systems, handling of multiple clients is fairly crude. This becomes a much more significant issue when always-on mobile devices are available, but it is desirable to use them only if another IM client is not available.
従来のIMシステムは一般に、同じ人のためにオンラインで複数の同時のIMクライアントを処理するという貧弱な仕事をしています。多くの既存のシステムよりも良い仕事をする人もいますが、複数のクライアントの処理はかなり粗雑です。これは、常にオンになっているモバイルデバイスが利用可能な場合、はるかに重要な問題になりますが、別のIMクライアントが利用できない場合にのみ使用することが望ましいです。
Using SIP makes rendezvous decisions explicit, deterministic, and very flexible. In contrast, "page-mode" IM systems use implicit implementation-specific decisions that IM clients cannot influence. With SIP session-mode messaging, rendezvous decisions can be under control of the client in a predictable, interoperable way for any host that implements callee capabilities [31]. As a result, rendezvous policy is managed consistently for each address of record.
SIPを使用すると、ランデブーの決定が明示的、決定論的、非常に柔軟になります。対照的に、「Page-Mode」IMシステムは、IMクライアントが影響を与えることができない暗黙の実装固有の決定を使用します。SIPセッションモードメッセージングにより、ランデブーの決定は、Callee機能を実装するホストにとって予測可能で相互運用可能な方法でクライアントの制御下にある可能性があります[31]。その結果、Rendezvousポリシーは、記録のアドレスごとに一貫して管理されます。
The following example shows Juliet with several IM clients where she can be reached. Each of these has a unique SIP contact and MSRP session. The example takes advantage of SIP's capability to "fork" an invitation to several contacts in parallel, in sequence, or in combination. Juliet has registered from her chamber, the balcony, her PDA, and as a last resort, you can leave a message with her nurse. Juliet's contacts are listed below. The q-values express relative preference (q=1.0 is the highest preference).
次の例は、ジュリエットがいくつかのIMクライアントを抱えていることを示しています。これらのそれぞれには、一意のSIP連絡先とMSRPセッションがあります。この例は、SIPの機能を利用して、並行、順番、または組み合わせて、複数の連絡先への招待を「フォーク」します。ジュリエットは彼女の部屋、バルコニー、彼女のPDAから登録し、最後の手段として、あなたは彼女の看護師にメッセージを残すことができます。ジュリエットの連絡先は以下にリストされています。Q値は相対的な好みを表します（Q = 1.0が最高の好みです）。
When Romeo opens his IM program, he selects Juliet and types the message "art thou hither?" (instead of "you there?"). His client sends a SIP invitation to sip:juliet@thecapulets.example.com. The proxy there tries first the balcony and the chamber simultaneously. A client is running on each of those systems, both of which set up early sessions of MSRP with Romeo's client. The client automatically sends the message over MSRP to the two MSRP URIs involved. After a delay of a several seconds with no reply or activity from Juliet, the proxy cancels the invitation at her first two contacts, and forwards the invitation on to Juliet's PDA. Since her father is talking to her about her wedding, she selects "Do Not Disturb" on her PDA, which sends a "Busy Here" response. The proxy then tries the nurse, who answers and tells Romeo what is going on.
ロミオが彼のIMプログラムを開くと、彼はジュリエットを選択し、「アートあなたはあなたが？」というメッセージをタイプします。（「そこにいる？」の代わりに）。彼のクライアントは、sipにsip招待状を送信します：juliet@thecapulets.example.com。そこのプロキシは、最初にバルコニーとチャンバーを同時に試します。クライアントはこれらの各システムで実行されており、どちらもRomeoのクライアントとMSRPの初期のセッションを設定しています。クライアントは、MSRPを介してメッセージを自動的に送信します。ジュリエットからの返信や活動なしで数秒遅れた後、プロキシは彼女の最初の2つの連絡先で招待をキャンセルし、ジュリエットのPDAに招待を転送します。彼女の父親は彼女の結婚式について彼女に話しているので、彼女は彼女のPDAで「邪魔しないでください」を選択します。その後、プロキシは看護師を試みます。看護師は、ロミオに何が起こっているのかを答えて伝えます。
Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Proxy balcony chamber PDA
| | | | | |
|--INVITE--->| | | | |
| |--INVITE--->| | | |
| |<----180----| | | |
|<----180----| | | | |
|---PRACK---------------->| | | |
|<----200-----------------| | | |
|<===Early MSRP Session==>| art thou hither? | |
| | | | | |
| |--INVITE---------------->| | |
| |<----180-----------------| | |
|<----180----| | | | |
|---PRACK----------------------------->| | |
|<----200------------------------------| | |
|<========Early MSRP Session==========>| art thou hither? |
| | | | | |
| | | | | |
| | .... Time Passes .... | | |
| | | | | |
| | | | | |
| |--CANCEL--->| | | |
| |<---200-----| | | |
| |<---487-----| | | |
| |----ACK---->| | | |
| |--CANCEL---------------->| | |
| |<---200------------------| | |
| |<---487------------------| | |
| |----ACK----------------->| | |
| |--INVITE---------------------------->| romeo wants
| | | | | to IM w/ you
| |<---486 Busy Here--------------------| |
| |----ACK----------------------------->| |
| | | | | |
| |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------|
|<--200 OK---| | | | |
|---ACK------------------------------------------------------->|
|<================MSRP Session================================>|
| | | | | |
| Hi Romeo, Juliet is |
| with her father now |
| can I take a message?|
| |
| Tell her to go to confession tomorrow.... |
Figure 18: Forking Example
図18：フォーキングの例
MSRP was designed to be only minimally extensible. New MSRP methods, header fields, and status codes can be defined in standards-track RFCs. MSRP does not contain a version number or any negotiation mechanism to require or discover new features. If an extension is specified in the future that requires negotiation, the specification will need to describe how the extension is to be negotiated in the encapsulating signaling protocol. If a non-interoperable update or extension occurs in the future, it will be treated as a new protocol, and MUST describe how its use will be signaled.
MSRPは、最小限の拡張のみになるように設計されています。新しいMSRPメソッド、ヘッダーフィールド、およびステータスコードは、標準トラックRFCで定義できます。MSRPには、新機能を要求または発見するためのバージョン番号または交渉メカニズムは含まれていません。将来、交渉を必要とする拡張機能が指定されている場合、仕様は、カプセル化シグナリングプロトコルで拡張機能をどのようにネゴシエートするかを説明する必要があります。将来的には挿入できない更新または拡張が発生した場合、新しいプロトコルとして扱われ、その使用がどのようにシグナルになるかを説明する必要があります。
In order to allow extension header fields without breaking interoperability, if an MSRP device receives a request or response containing a header field that it does not understand, it MUST ignore the header field and process the request or response as if the header field was not present. If an MSRP device receives a request with an unknown method, it MUST return a 501 response.
相互運用性を破ることなく拡張ヘッダーフィールドを許可するために、MSRPデバイスが理解できないヘッダーフィールドを含むリクエストまたは応答を受信した場合、ヘッダーフィールドを無視し、ヘッダーフィールドが存在しないかのようにリクエストまたは応答を処理する必要があります。MSRPデバイスが不明な方法でリクエストを受信した場合、501応答を返す必要があります。
MSRP was designed to use lists of URIs instead of a single URI in the To-Path and From-Path header fields in anticipation of relay or gateway functionality being added. In addition, "msrp" and "msrps" URIs can contain parameters that are extensible.
MSRPは、リレーまたはゲートウェイの機能性が追加されていることを見越して、To-PathおよびFrom-Pathヘッダーフィールドの単一のURIの代わりにURIのリストを使用するように設計されています。さらに、「MSRP」および「MSRPS」URISには、拡張可能なパラメーターを含めることができます。
MSRP sessions may go to a gateway to other Common Profile for Instant Messaging (CPIM) [27] compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics, which do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that has included "message/cpim" as the first entry in the accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME[7] features of that format.
MSRPセッションは、インスタントメッセージング（CPIM）[27]互換性のあるプロトコルのために、他の共通プロファイルへのゲートウェイに移動する場合があります。これが発生した場合、ゲートウェイはセッション状態を維持する必要があり、MSRPセッションセマンティクスとセッションの概念を含まないCPIMセマンティクスの間に翻訳する必要があります。さらに、セッションの1つのエンドポイントがCPIMゲートウェイである場合、インスタントメッセージは「メッセージ/CPIM」[12]ボディにラップする必要があります。このようなゲートウェイには、SDP Accept-Types属性の最初のエントリとして「メッセージ/CPIM」を含める必要があります。MSRPエンドポイントは、「メッセージ/ CPIM」ラッパーのすべてのインスタントメッセージ本文をカプセル化するために、「メッセージ/ CPIM」を含む「メッセージ/ CPIM」を含むピアにインスタントメッセージを送信します。すべてのMSRPエンドポイントは、メッセージ/CPIMタイプをサポートする必要があり、その形式のS/MIME [7]機能をサポートする必要があります。
If a message is to be wrapped in a message/cpim envelope, the wrapping MUST be done prior to breaking the message into chunks, if needed.
メッセージをメッセージ/CPIMエンベロープにラップする場合、必要に応じてメッセージをチャンクに分割する前に、ラッピングを実行する必要があります。
All MSRP endpoints MUST recognize the From, To, DateTime, and Require header fields as defined in RFC 3862. Such applications SHOULD recognize the CC header field, and MAY recognize the Subject header field. Any MSRP application that recognizes any message/cpim header field MUST understand the NS (name space) header field.
すべてのMSRPエンドポイントは、from、to、datetimeを認識し、RFC 3862で定義されているヘッダーフィールドを必要とする必要があります。このようなアプリケーションは、CCヘッダーフィールドを認識し、サブジェクトヘッダーフィールドを認識する必要があります。メッセージ/CPIMヘッダーフィールドを認識するMSRPアプリケーションは、NS（名前スペース）ヘッダーフィールドを理解する必要があります。
All message/cpim body parts sent by an MSRP endpoint MUST include the From and To header fields. If the message/cpim body part is protected using S/MIME, then it MUST also include the DateTime header field.
MSRPエンドポイントによって送信されたすべてのメッセージ/CPIMボディパーツには、FromとHeaderフィールドを含める必要があります。メッセージ/CPIMボディの部分がS/MIMEを使用して保護されている場合、DateTimeヘッダーフィールドも含める必要があります。
The NS, To, and CC header fields may occur multiple times. Other header fields defined in RFC 3862 MUST NOT occur more than once in a given message/cpim body part in an MSRP message. The Require header field MAY include multiple values. The NS header field MAY occur zero or more times, depending on how many name spaces are being referenced.
NS、TO、およびCCヘッダーフィールドは複数回発生する場合があります。RFC 3862で定義されている他のヘッダーフィールドは、MSRPメッセージで特定のメッセージ/CPIMボディパーツで1回以上発生してはなりません。要求ヘッダーフィールドには複数の値が含まれる場合があります。NSヘッダーフィールドは、参照されている名前スペースの数に応じて、ゼロ以上に発生する場合があります。
Extension header fields MAY occur more than once, depending on the definition of such header fields.
拡張ヘッダーフィールドは、このようなヘッダーフィールドの定義に応じて、複数回発生する場合があります。
Using message/cpim envelopes is also useful if an MSRP device wishes to send a message on behalf of some other identity. The device may add a message/cpim envelope with the appropriate From header field value.
メッセージ/CPIMエンベロープを使用することは、MSRPデバイスが他のIDに代わってメッセージを送信したい場合にも便利です。デバイスは、ヘッダーフィールド値から適切なメッセージ/CPIMエンベロープを追加する場合があります。
Instant messaging systems are used to exchange a variety of sensitive information ranging from personal conversations, to corporate confidential information, to account numbers and other financial trading information. IM is used by individuals, corporations, and governments for communicating important information. IM systems need to provide the properties of integrity and confidentiality for the exchanged information, and the knowledge that you are communicating with the correct party, and they need to allow the possibility of anonymous communication. MSRP pushes many of the hard problems to SIP when SIP sets up the session, but some of the problems remain. Spam and Denial of Service (DoS) attacks are also very relevant to IM systems.
インスタントメッセージングシステムは、個人的な会話から企業の機密情報、アカウント番号やその他の金融取引情報に至るまで、さまざまな機密情報を交換するために使用されます。IMは、重要な情報を伝えるために個人、企業、政府によって使用されています。IMシステムは、交換された情報の整合性と機密性の特性と、あなたが正しい当事者と通信しているという知識を提供する必要があり、匿名のコミュニケーションの可能性を可能にする必要があります。MSRPは、SIPがセッションをセットアップすると、多くの難しい問題をSIPに押し上げますが、いくつかの問題は残っています。スパムおよびサービス拒否（DOS）攻撃もIMシステムに非常に関連しています。
MSRP needs to provide confidentiality and integrity for the messages it transfers. It also needs to provide assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked.
MSRPは、転送するメッセージに機密性と整合性を提供する必要があります。また、接続されたホストが接続することを意図したホストであり、接続がハイジャックされていないことを保証する必要があります。
When an endpoint sends an MSRP URI to its peer in a rendezvous protocol, that URI is effectively a secret shared between the peers. If an attacker learns or guesses the URI prior to the completion of session setup, it may be able to impersonate one of the peers.
エンドポイントがランデブープロトコルでMSRP URIを同業者に送信すると、URIは事実上ピア間で共有されている秘密です。攻撃者がセッションのセットアップを完了する前にURIを学習または推測した場合、ピアの1人になりすましてもらうことができます。
Assuming the URI exchange in the rendezvous protocol is sufficiently protected, it is critical that the URI remain difficult to "guess" via brute force methods. Most components of the URI, such as the scheme and the authority components, are common knowledge. The secrecy is entirely provided by the session-id component.
ランデブープロトコルのURI交換が十分に保護されていると仮定すると、URIをブルートフォースの方法で「推測」することは依然として困難であることが重要です。スキームや権限コンポーネントなど、URIのほとんどのコンポーネントは一般的な知識です。秘密は、セッションIDコンポーネントによって完全に提供されます。
Therefore, when an MSRP device generates an MSRP URI to be used in the initiation of an MSRP session, the session-id component MUST contain at least 80 bits of randomness.
したがって、MSRPデバイスがMSRPセッションの開始に使用されるMSRP URIを生成する場合、セッションIDコンポーネントには少なくとも80ビットのランダム性を含める必要があります。
When using only TCP connections, MSRP security is fairly weak. If host A is contacting host B, B passes its hostname and a secret to A using a rendezvous protocol. Although MSRP requires the use of a rendezvous protocol with the ability to protect this exchange, there is no guarantee that the protection will be used all the time. If such protection is not used, anyone can see this secret. Host A then connects to the provided hostname and passes the secret in the clear across the connection to B. Host A assumes that it is talking to B based on where it sent the SYN packet and then delivers the secret in plain text across the connections. Host B assumes it is talking to A because the host on the other end of the connection delivered the secret. An attacker that could ACK the SYN packet could insert itself as a man-in-the-middle in the connection.
TCP接続のみを使用する場合、MSRPセキュリティはかなり弱いです。ホストAがホストBに接触している場合、Bはホスト名とa秘密を通過し、ランデブープロトコルを使用します。MSRPは、この交換を保護する能力を備えたランデブープロトコルの使用を必要としますが、保護が常に使用されるという保証はありません。そのような保護が使用されない場合、誰もがこの秘密を見ることができます。ホストAは、提供されたホスト名に接続し、接続全体にクリアの秘密を渡します。ホストAは、synパケットを送信した場所に基づいてBに話しかけていると仮定し、接続全体に秘密をプレーンテキストで配信します。ホストBは、接続のもう一方の端にあるホストが秘密を提供したため、Aと話していると仮定します。SynパケットをACKする可能性のある攻撃者は、接続中の中間の男として自分自身を挿入できます。
When using TLS connections, the security is significantly improved. We assume that the host accepting the connection has a certificate from a well-known certification authority. Furthermore, we assume that the signaling to set up the session is protected by the rendezvous protocol. In this case, when host A contacts host B, the secret is passed through a confidential channel to A. A connects with TLS to B. B presents a valid certificate, so A knows it really is connected to B. A then delivers the secret provided by B, so that B can verify it is connected to A. In this case, a rogue SIP Proxy can see the secret in the SIP signaling traffic and could potentially insert itself as a man-in-the-middle.
TLS接続を使用する場合、セキュリティは大幅に改善されます。接続を受け入れるホストには、有名な認証機関からの証明書があると仮定します。さらに、セッションをセットアップするためのシグナル伝達がランデブープロトコルによって保護されていると想定しています。この場合、ホストAの連絡先ホストB Bの場合、秘密はA。Aへの機密チャネルを通過します。AはTLSとB. Bに接続します。Bによって提供されるため、BはAに接続されていることを確認できます。この場合、Rogue SIPプロキシはSIPシグナリングトラフィックの秘密を見ることができ、潜在的に中間の男として挿入する可能性があります。
Realistically, using TLS with certificates from well-known certification authorities is difficult for peer-to-peer connections, as the types of hosts that end clients use for sending instant messages are unlikely to have long-term stable IP addresses or DNS names that the certificates can bind to. In addition, the cost of server certificates from well-known certification authorities is currently expensive enough to discourage their use for each client. Using TLS in a peer-to-peer mode without well-known certificates is discussed in Section 14.4.
現実的には、有名な認証当局からの証明書を使用してTLSを使用することは、ピアツーピア接続にとっては困難です。インスタントメッセージの送信にクライアントが使用するホストのタイプは、長期的な安定したIPアドレスまたはDNS名を持つ可能性は低いためです。証明書はバインドできます。さらに、有名な認証当局からのサーバー証明書のコストは、現在、各クライアントの使用を阻止するのに十分な費用がかかります。よく知られている証明書なしでピアツーピアモードでTLSを使用することについては、セクション14.4で説明します。
TLS becomes much more practical when some form of relay is introduced. Clients can then form TLS connections to relays, which are much more likely to have TLS certificates. While this specification does not address such relays, they are described by a companion document [23]. That document makes extensive use of TLS to protect traffic between clients and relays, and between one relay and another.
何らかの形のリレーが導入されると、TLSははるかに実用的になります。その後、クライアントはTLS接続をリレーに形成できます。リレーは、TLS証明書を持っている可能性がはるかに高くなります。この仕様にはそのようなリレーには対処されていませんが、コンパニオンドキュメント[23]で説明されています。このドキュメントは、クライアントとリレー間のトラフィックを保護するためにTLSを広範囲に使用しています。
TLS is used to authenticate devices and to provide integrity and confidentiality for the header fields being transported. MSRP elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [11]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher-suites MAY also be supported).
TLSは、デバイスを認証し、輸送中のヘッダーフィールドに整合性と機密性を提供するために使用されます。MSRP要素はTLSを実装する必要があり、[11]で説明されているように、サーバー名表示のTLS clientextededhello拡張ハロー情報も実装する必要があります。TLS_RSA_WITH_AES_128_CBC_SHA [13]のTLS cipher-suiteをサポートする必要があります（他の暗号スイーツもサポートされる場合があります）。
The only strong security for non-TLS connections is achieved using S/MIME.
非TLS接続の唯一の強力なセキュリティは、S/MIMEを使用して達成されます。
Since MSRP carries arbitrary MIME content, it can trivially carry S/MIME protected messages as well. All MSRP implementations MUST support the multipart/signed media-type even if they do not support S/MIME. Since SIP can carry a session key, S/MIME messages in the context of a session could also be protected using a key-wrapped shared secret [28] provided in the session setup. MSRP can carry unencoded binary payloads. Therefore, MIME bodies MUST be transferred with a transfer encoding of binary. If a message is both signed and encrypted, it SHOULD be signed first, then encrypted. If S/MIME is supported, SHA-1, SHA-256, RSA, and AES-128 MUST be supported. For RSA, implementations MUST support key sizes of at least 1024 bits and SHOULD support key sizes of 2048 bits or more.
MSRPには任意のMIMEコンテンツが含まれているため、S/MIMEで保護されたメッセージも運ぶことができます。すべてのMSRP実装は、S/MIMEをサポートしていなくても、MultiPart/署名されたメディアタイプをサポートする必要があります。SIPはセッションキーを伝えることができるため、セッションのコンテキストでS/MIMEメッセージは、セッションのセットアップで提供されるキーラップされた共有秘密[28]を使用して保護することもできます。MSRPは、エンコードされていないバイナリペイロードを運ぶことができます。したがって、MIME体はバイナリの転送エンコードで転送する必要があります。メッセージが署名され、暗号化されている場合、最初に署名してから暗号化する必要があります。S/MIMEがサポートされている場合、SHA-1、SHA-256、RSA、およびAES-128をサポートする必要があります。RSAの場合、実装は少なくとも1024ビットのキーサイズをサポートする必要があり、2048ビット以上のキーサイズをサポートする必要があります。
This does not actually require the endpoint to have certificates from a well-known certification authority. When MSRP is used with SIP, the Identity [17] and Certificates [25] mechanisms provide S/MIME-based delivery of a secret between A and B. No SIP intermediary except the explicitly trusted authentication service (one per user) can see the secret. The S/MIME encryption of the SDP can also be used by SIP to exchange keying material that can be used in MSRP.
これは、実際には、有名な認証機関からの証明書を持つためのエンドポイントを必要としません。MSRPがSIPで使用される場合、ID [17]および証明書[25]メカニズムは、AとBの間の秘密のS/MIMEベースの配信を提供します。ひみつ。SDPのS/MIME暗号化は、SIPでMSRPで使用できるキーイング材料を交換するために使用することもできます。
The MSRP session can then use S/MIME with this keying material to sign and encrypt messages sent over MSRP. The connection can still be hijacked since the secret is sent in clear text to the other end of the TCP connection, but the consequences are mitigated if all the MSRP content is signed and encrypted with S/MIME. Although out of scope for this document, the SIP negotiation of an MSRP session can negotiate symmetric keying material to be used with S/MIME for integrity and privacy.
MSRPセッションでは、このキーイング素材を使用してS/MIMEを使用して、MSRPを介して送信されたメッセージに署名および暗号化できます。秘密がTCP接続の反対側に明確なテキストで送信されるため、接続をハイジャックすることができますが、すべてのMSRPコンテンツが署名されてS/MIMEで暗号化された場合、結果は軽減されます。このドキュメントの範囲外ですが、MSRPセッションのSIP交渉は、整合性とプライバシーのためにS/MIMEで使用する対称キーイング材料と交渉することができます。
TLS can be used with a self-signed certificate as long as there is a mechanism for both sides to ascertain that the other side used the correct certificate. When used with SDP and SIP, the correct certificate can be verified by passing a fingerprint of the certificate in the SDP and ensuring that the SDP has suitable integrity protection. When SIP is used to transport the SDP, the integrity can be provided by the SIP Identity mechanism [17]. The rest of this section describes the details of this approach.
TLSは、反対側が正しい証明書を使用していることを確認するメカニズムがある限り、自己署名証明書で使用できます。SDPとSIPで使用する場合、SDPの証明書の指紋を渡し、SDPに適切な完全性保護があることを確認することにより、正しい証明書を検証できます。SIPを使用してSDPを輸送する場合、SIP IDメカニズム[17]によって完全性を提供できます。このセクションの残りの部分では、このアプローチの詳細について説明します。
If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the URI of the user. In SIP, this URI of the user is the User's Address of Record (AOR). This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. Unlike normal TLS operations in this protocol, when doing peer-to-peer TLS, the subjectAltName is not an important component of the certificate verification. If the endpoint is also able to make anonymous sessions, a distinct, unique certificate MUST be used for this purpose. For a client that works with multiple users, each user SHOULD have its own certificate. Because the generation of public/private key pairs is relatively expensive, endpoints are not required to generate certificates for each session.
自己署名証明書が使用されている場合、証明書内のsumbercaltname属性のコンテンツは、ユーザーのURIを使用する場合があります。SIPでは、ユーザーのこのURIはユーザーのレコードアドレス（AOR）です。これは、デバッグ目的のみに役立ち、証明書を通信エンドポイントの1つにバインドする必要はありません。このプロトコルでの通常のTLS操作とは異なり、ピアツーピアTLSを実行する場合、件名は証明書検証の重要なコンポーネントではありません。エンドポイントが匿名のセッションを作成できる場合、この目的のために明確で一意の証明書を使用する必要があります。複数のユーザーと連携するクライアントの場合、各ユーザーには独自の証明書が必要です。パブリック/プライベートキーペアの生成は比較的高価であるため、各セッションの証明書を生成するためにエンドポイントは必要ありません。
A certificate fingerprint is the output of a one-way hash function computed over the Distinguished Encoding Rules (DER) form of the certificate. The endpoint MUST use the certificate fingerprint attribute as specified in [18] and MUST include this in the SDP. The certificate presented during the TLS handshake needs to match the fingerprint exchanged via the SDP, and if the fingerprint does not match the hashed certificate then the endpoint MUST tear down the media session immediately.
証明書指紋とは、証明書の識別されたエンコードルール（DER）形式で計算された一方向ハッシュ関数の出力です。エンドポイントは、[18]で指定されているように証明書指紋属性を使用し、これをSDPに含める必要があります。TLSの握手中に提示された証明書は、SDPを介して交換される指紋と一致する必要があり、指紋がハッシュされた証明書と一致しない場合、エンドポイントはメディアセッションを直ちに取り壊す必要があります。
When using SIP, the integrity of the fingerprint can be ensured through the SIP Identity mechanism [17]. When a client wishes to use SIP to set up a secure MSRP session with another endpoint, it sends an SDP offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the certificate that the endpoint wants to use. The SIP message containing the offer is sent to the offerer's SIP proxy, which will add an Identity header according to the procedures outlined in [17]. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header. Since the Identity header is a digital signature across several SIP headers, in addition to the body or bodies of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was added to the SIP message.
SIPを使用する場合、SIP IDメカニズム[17]を通じて指紋の完全性を確保できます。クライアントがSIPを使用して別のエンドポイントを使用して安全なMSRPセッションを設定したい場合、SIPメッセージでSDPオファーを他のエンドポイントに送信します。このオファーには、SDPペイロードの一部として、エンドポイントが使用したい証明書の指紋が含まれます。オファーを含むSIPメッセージは、[17]で概説されている手順に従ってアイデンティティヘッダーを追加するオファーのSIPプロキシに送信されます。Far EndpointがSIPメッセージを受信すると、IDヘッダーを使用して送信者のIDを確認できます。IDヘッダーは、SIPメッセージのボディまたはボディに加えて、いくつかのSIPヘッダーにわたるデジタル署名であるため、受信者は、デジタル署名がSIPメッセージに追加された後にメッセージが改ざんされていないことも確実にすることができます。
An example of SDP with a fingerprint attribute is shown in the following figure. Note the fingerprint is shown spread over two lines due to formatting consideration but should all be on one line.
指紋属性を持つSDPの例を次の図に示します。注指数は、考慮事項のフォーマットのために2行に広がっていることが示されていますが、すべて1行にあるはずです。
c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;tcp
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 19: SDP with Fingerprint Attribute
図19：指紋属性を備えたSDP
MSRP cannot be used as an amplifier for DoS attacks, but it can be used to form a distributed attack to consume TCP connection resources on servers. The attacker, Mallory, sends a SIP INVITE with no offer to Alice. Alice returns a 200 with an offer and Mallory returns an answer with SDP indicating that his MSRP address is the address of Tom. Since Alice sent the offer, Alice will initiate a connection to Tom using up resources on Tom's server. Given the huge number of IM clients, and the relatively few TCP connections that most servers support, this is a fairly straightforward attack.
MSRPは、DOS攻撃のアンプとして使用することはできませんが、分散攻撃を形成してサーバーでTCP接続リソースを消費するために使用できます。攻撃者のマロリーは、アリスに申し出をせずにSIP招待状を送ります。アリスはオファーで200を返し、マロリーはSDPで答えを返し、彼のMSRPアドレスがTOMのアドレスであることを示しています。アリスがオファーを送信して以来、アリスはトムのサーバーでリソースを使用してトムとの接続を開始します。膨大な数のIMクライアントと、ほとんどのサーバーがサポートする比較的少数のTCP接続を考えると、これはかなり簡単な攻撃です。
SIP is attempting to address issues in dealing with spam. The spam issue is probably best dealt with at the SIP level when an MSRP session is initiated and not at the MSRP level.
SIPは、スパムに対処する際に問題に対処しようとしています。SPAMの問題は、MSRPレベルではなくMSRPセッションが開始される場合、おそらくSIPレベルで最もよく扱われます。
If a sender chooses to employ S/MIME to protect a message, all S/MIME operations apply to the complete message, prior to any breaking of the message into chunks.
送信者がメッセージを保護するためにS/MIMEを使用することを選択した場合、すべてのS/MIME操作は、メッセージをチャンクに壊す前に、完全なメッセージに適用されます。
The signaling will have set up the session to or from some specific URIs that will often have "im:" or "sip:" URI schemes. When the signaling has been set up to a specific end user, and S/MIME is implemented, then the client needs to verify that the name in the SubjectAltName of the certificate contains an entry that matches the URI that was used for the other end in the signaling. There are some cases, such as IM conferencing, where the S/MIME certificate name and the signaled identity will not match. In these cases, the client should ensure that the user is informed that the message came from the user identified in the certificate and does not assume that the message came from the party they signaled.
シグナリングは、しばしば「im：」または「sip：」URIスキームを持つ特定のURIとの間でセッションを設定します。シグナリングが特定のエンドユーザーに設定され、S/MIMEが実装された場合、クライアントは、証明書のsumbertaltnameの名前に、反対側に使用されたURIに一致するエントリが含まれていることを確認する必要があります。シグナリング。IM会議など、S/MIME証明書名と信号されたIDが一致しない場合など、いくつかのケースがあります。これらの場合、クライアントは、メッセージが証明書で識別されたユーザーからメッセージが届いていることをユーザーに通知され、メッセージが彼らが合図した当事者から来たと想定していないことを確認する必要があります。
In some cases, a sending device may need to attribute a message to some other identity, and may use different identities for different messages in the same session. For example, a conference server may send messages on behalf of multiple users on the same session. Rather than add additional header fields to MSRP for this purpose, MSRP relies on the message/cpim format for this purpose. The sender may envelop such a message in a message/cpim body, and place the actual sender identity in the From field. The trustworthiness of such an attribution is affected by the security properties of the session in the same way that the trustworthiness of the identity of the actual peer is affected, with the additional issue of determining whether the recipient trusts the sender to assert the identity.
場合によっては、送信デバイスがメッセージを他のアイデンティティに起因する必要がある場合があり、同じセッションで異なるメッセージに対して異なるIDを使用する場合があります。たとえば、会議サーバーは、同じセッションで複数のユーザーに代わってメッセージを送信する場合があります。この目的のためにMSRPにヘッダーフィールドを追加するのではなく、MSRPはこの目的のためにメッセージ/CPIM形式に依存しています。送信者は、そのようなメッセージをメッセージ/cpim本体に包み込み、実際の送信者のアイデンティティをFromフィールドに配置することができます。そのような帰属の信頼性は、実際のピアのアイデンティティの信頼性が影響を受けるのと同じように、セッションのセキュリティプロパティの影響を受けます。
This approach can result in nesting of message/cpim envelopes. For example, a message originates from a CPIM gateway, and is then forwarded by a conference server onto a new session. Both the gateway and the conference server introduce envelopes. In this case, the recipient client SHOULD indicate the chain of identity assertions to the user, rather than allow the user to assume that either the gateway or the conference server originated the message.
このアプローチは、メッセージ/CPIMエンベロープのネストをもたらす可能性があります。たとえば、メッセージはCPIMゲートウェイから発生し、会議サーバーによって新しいセッションに転送されます。ゲートウェイと会議サーバーの両方が封筒を導入します。この場合、受信者のクライアントは、ユーザーがゲートウェイまたは会議サーバーがメッセージを発信したと想定できるようにするのではなく、ユーザーにIDのチェーンアサーションを示す必要があります。
It is possible that a recipient might receive messages that are attributed to the same sender via different MSRP sessions. For example, Alice might be in a conversation with Bob via an MSRP session over a TLS protected channel. Alice might then receive a different message from Bob over a different session, perhaps with a conference server that asserts Bob's identity in a message/cpim envelope signed by the server.
受信者は、異なるMSRPセッションを介して同じ送信者に起因するメッセージを受信する可能性があります。たとえば、アリスはTLS保護チャネルを介したMSRPセッションを介してボブと会話している可能性があります。アリスは、おそらくサーバーが署名したメッセージ/CPIMエンベロープでボブの身元を主張する会議サーバーを使用して、別のセッションでボブから別のメッセージを受信する可能性があります。
MSRP does not prohibit multiple simultaneous sessions between the same pair of identities. Nor does it prohibit an endpoint sending a message on behalf of another identity, such as may be the case for a conference server. The recipient's endpoint should determine its level of trust of the authenticity of the sender independently for each session. The fact that an endpoint trusts the authenticity of the sender on any given session should not affect the level of trust it assigns for apparently the same sender on a different session.
MSRPは、同じアイデンティティのペア間の複数の同時セッションを禁止していません。また、会議サーバーの場合のような別のアイデンティティに代わってメッセージを送信するエンドポイントを禁止していません。受信者のエンドポイントは、セッションごとに送信者の信頼性の信頼レベルを独立して決定する必要があります。エンドポイントが特定のセッションで送信者の信頼性を信頼するという事実は、異なるセッションで明らかに同じ送信者に割り当てる信頼のレベルに影響を与えるべきではありません。
When MSRP clients form or acquire a certificate, they SHOULD ensure that the subjectAltName has a GeneralName entry of type uniformResourceIdentifier for each URI corresponding to this client and should always include an "im:" URI. It is fine if the certificate contains other URIs such as "sip:" or "xmpp:" URIs.
MSRPクライアントが証明書を形成または取得する場合、subjectaltnameがこのクライアントに対応する各URIのタイプの均一なruceidentifierの一般名を確保する必要があり、常に「im：」を含める必要があります。証明書に「SIP：」または「XMPP：」などの他のURIが含まれている場合は問題ありません。
MSRP implementors should be aware of a potential attack on MSRP devices that involves placing very large values in the byte-range header field, potentially causing the device to allocate very large memory buffers to hold the message. Implementations SHOULD apply some degree of sanity checking on byte-range values before allocating such buffers.
MSRP実装者は、バイト範囲のヘッダーフィールドに非常に大きな値を配置することを伴うMSRPデバイスに対する潜在的な攻撃を認識し、デバイスが非常に大きなメモリバッファーを割り当ててメッセージを保持する可能性があります。実装は、そのようなバッファーを割り当てる前に、バイト範囲の値をある程度の正気確認を適用する必要があります。
This specification instructs IANA to create a new registry for MSRP parameters. The MSRP Parameter registry is a container for sub-registries. This section further introduces sub-registries for MSRP method names, status codes, and header field names.
この仕様は、IANAにMSRPパラメーターの新しいレジストリを作成するように指示します。MSRPパラメーターレジストリは、サブレジストリ用のコンテナです。このセクションでは、MSRPメソッド名、ステータスコード、およびヘッダーフィールド名のサブレジストリをさらに紹介します。
Additionally, Section 15.4 through Section 15.7 register new parameters in existing IANA registries.
さらに、セクション15.4からセクション15.7から、既存のIANAレジストリに新しいパラメーターを登録します。
This specification establishes the Methods sub-registry under MSRP Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission).
この仕様は、MSRPパラメーターの下でメソッドサブレジストリを確立し、次のようにその母集団を開始します。このサブレジストリの新しいパラメーターは、RFC（IETF提出またはRFCエディターの提出のいずれか）に公開する必要があります。
SEND - [RFC4975] REPORT - [RFC4975]
送信 - [RFC4975]レポート - [RFC4975]
The following information MUST be provided in an RFC publication in order to register a new MSRP method:
新しいMSRPメソッドを登録するには、次の情報をRFCの出版物で提供する必要があります。
o The method name. o The RFC number in which the method is registered.
o メソッド名。oメソッドが登録されているRFC番号。
This specification establishes the header field-Field sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined as follows:
この仕様は、MSRPパラメーターの下でヘッダーフィールドフィールドサブレジストリを確立します。このサブレジストリの新しいパラメーターは、RFC（IETF提出またはRFCエディターの提出のいずれか）に公開する必要があります。その初期母集団は次のように定義されています。
To-Path - [RFC4975]
From-Path - [RFC4975]
Message-ID - [RFC4975]
Success-Report - [RFC4975]
Failure-Report - [RFC4975]
Byte-Range - [RFC4975]
Status - [RFC4975]
The following information MUST be provided in an RFC publication in order to register a new MSRP header field:
新しいMSRPヘッダーフィールドを登録するには、次の情報をRFCの出版物で提供する必要があります。
o The header field name. o The RFC number in which the method is registered.
o ヘッダーフィールド名。oメソッドが登録されているRFC番号。
This specification establishes the Status-Code sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined in Section 10. It takes the following format:
この仕様は、MSRPパラメーターの下でステータスコードサブレジストリを確立します。このサブレジストリの新しいパラメーターは、RFC（IETF提出またはRFCエディターの提出のいずれか）に公開する必要があります。その初期母集団はセクション10で定義されています。次の形式を取得します。
Code [RFC Number]
コード[RFC番号]
The following information MUST be provided in an RFC publication in order to register a new MSRP status code:
新しいMSRPステータスコードを登録するには、次の情報をRFCの出版物で提供する必要があります。
o The status code number. o The RFC number in which the method is registered.
o ステータスコード番号。メソッドが登録されているRFC番号の。
MSRP uses TCP port 2855, from the "registered" port range. Usage of this value is described in Section 6.
MSRPは、「登録された」ポート範囲からTCPポート2855を使用します。この値の使用については、セクション6で説明されています。
This document requests permanent registration the URI schemes of "msrp" and "msrps".
このドキュメントでは、「MSRP」と「MSRPS」のURIスキームを恒久的に登録します。
URI Scheme Name: "msrp" URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in Section 9 of RFC 4975. URI Scheme Semantics: See Section 6 of RFC 4975. Encoding Considerations: See Section 6 of RFC 4975.
URIスキーム名： "MSRP" URIスキーム構文：RFC 4975のセクション9の「MSRP-URI」のABNF構造を参照してください。URIスキームセマンティクス：RFC 4975のセクション6を参照してください。
Applications/Protocols that use this URI Scheme: The Message Session Relay Protocol (MSRP). Interoperability Considerations: MSRP URIs are expected to be used only by implementations of MSRP. No additional interoperability issues are expected. Security Considerations: See Section 14.1 of RFC 4975 for specific security considerations for MSRP URIs, and Section 14 of RFC 4975 for security considerations for MSRP in general. Contact: Ben Campbell (ben@estacado.net). Author/Change Controller: This is a permanent registration request. Change control does not apply.
このURIスキームを使用するアプリケーション/プロトコル：メッセージセッションリレープロトコル（MSRP）。相互運用性の考慮事項：MSRP URIは、MSRPの実装によってのみ使用されると予想されます。追加の相互運用性の問題は予想されません。セキュリティ上の考慮事項：MSRP URIの特定のセキュリティに関する考慮事項については、RFC 4975のセクション14.1を参照し、MSRPのセキュリティに関する考慮事項については、RFC 4975のセクション14を参照してください。連絡先：Ben Campbell（ben@estacado.net）。著者/変更コントローラー：これは恒久的な登録リクエストです。変更制御は適用されません。
URI Scheme Name: "msrps" URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in Section 9 of RFC 4975. URI Scheme Semantics: See Section 6 of RFC 4975. Encoding Considerations: See Section 6 of RFC 4975. Applications/Protocols that use this URI Scheme: The Message Session Relay Protocol (MSRP). Interoperability Considerations: MSRP URIs are expected to be used only by implementations of MSRP. No additional interoperability issues are expected. Security Considerations: See Section 14.1 of RFC 4975 for specific security considerations for MSRP URIs, and Section 14 of RFC 4975 for security considerations for MSRP in general. Contact: Ben Campbell (ben@estacado.net). Author/Change Controller: This is a permanent registration request. Change control does not apply.
URIスキーム名： "MSRPS" URIスキーム構文：RFC 4975のセクション9の「MSRP-URI」のABNF構造を参照してください。URIスキームセマンティクス：RFC 4975のセクション6を参照してください。/このURIスキームを使用するプロトコル：メッセージセッションリレープロトコル（MSRP）。相互運用性の考慮事項：MSRP URIは、MSRPの実装によってのみ使用されると予想されます。追加の相互運用性の問題は予想されません。セキュリティ上の考慮事項：MSRP URIの特定のセキュリティに関する考慮事項については、RFC 4975のセクション14.1を参照し、MSRPのセキュリティに関する考慮事項については、RFC 4975のセクション14を参照してください。連絡先：Ben Campbell（ben@estacado.net）。著者/変更コントローラー：これは恒久的な登録リクエストです。変更制御は適用されません。
MSRP defines the new SDP protocol field values "TCP/MSRP" and "TCP/ TLS/MSRP", which should be registered in the sdp-parameters registry under "proto". This first value indicates the MSRP protocol when TCP is used as an underlying transport. The second indicates that TLS over TCP is used.
MSRPは、新しいSDPプロトコルフィールド値「TCP/MSRP」および「TCP/TLS/MSRP」を定義します。これは、「Proto」に基づくSDP-Parametersレジストリに登録する必要があります。この最初の値は、TCPが基礎となる輸送として使用される場合のMSRPプロトコルを示します。2番目は、TCPを超えるTLSが使用されていることを示しています。
Specifications defining new protocol values must define the rules for the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ MSRP" protocol values allow only one value in the format field (fmt), which is a single occurrence of "*". Actual format determination is made using the "accept-types" and "accept-wrapped-types" attributes.
新しいプロトコル値を定義する仕様は、関連するメディア形式の名前空間のルールを定義する必要があります。「TCP/MSRP」および「TCP/TLS/MSRP」プロトコル値は、「*」の単一の発生であるフォーマットフィールド（FMT）で1つの値のみを許可します。実際のフォーマットの決定は、「Accept-Types」および「Accept-Wrapped-Types」属性を使用して行われます。
This document registers the following SDP attribute parameter names in the sdp-parameters registry. These names are to be used in the SDP att-name field.
このドキュメントは、SDP-Parametersレジストリの次のSDP属性パラメーター名を登録します。これらの名前は、SDP att-nameフィールドで使用されます。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: accept-types Long-form Attribute Name: Acceptable media types Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "accept-types" attribute contains a list of media types that the endpoint is willing to receive. It may contain zero or more registered media-types, or "*" in a space-delimited string.
連絡先情報：Ben Campbell（ben@estacado.net）属性名：Accept-Types長型属性名：許容可能なメディアタイプタイプ：charset属性の対象となるメディアレベル：目的と適切な値なし：「accept-types」属性エンドポイントが受信する意思があるメディアタイプのリストが含まれています。ゼロ以上の登録されたメディアタイプ、またはスペース設定文字列に「*」が含まれる場合があります。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: accept-wrapped-types Long-form Attribute Name: Acceptable media types Inside Wrappers Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "accept-wrapped-types" attribute contains a list of media types that the endpoint is willing to receive in an MSRP message with multipart content, but may not be used as the outermost type of the message. It may contain zero or more registered media-types, or "*" in a space-delimited string.
連絡先情報：Ben Campbell（ben@estacado.net）属性名：Accept-wrapp-types long-form属性名：ラッパー内の受け入れ可能なメディアタイプタイプ：メディアレベルcharset属性：目的と適切な値なし：「受け入れ」-Rapped-Types "属性には、エンドポイントがマルチパートコンテンツを含むMSRPメッセージで受信する意思があるメディアタイプのリストが含まれていますが、メッセージの最も外側のタイプとして使用できない場合があります。ゼロ以上の登録されたメディアタイプ、またはスペース設定文字列に「*」が含まれる場合があります。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: max-size Long-form Attribute Name: Maximum message size Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "max-size" attribute indicates the largest message an endpoint wishes to accept. It may take any whole numeric value, specified in octets.
連絡先情報：Ben Campbell（ben@estacado.net）属性名：最大サイズの長型属性名：最大メッセージサイズタイプ：charset属性の対象：目的と適切な値なし：「最大サイズ」属性エンドポイントが受け入れたい最大のメッセージを示します。オクテットで指定された全体の数値を必要とする場合があります。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: path Long-form Attribute Name: MSRP URI Path Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "path" attribute indicates a series of MSRP devices that must be visited by messages sent in the session, including the final endpoint. The attribute contains one or more MSRP URIs, delimited by the space character.
連絡先情報：Ben Campbell（ben@estacado.net）属性名：PATHロングフォーム属性名：MSRP URIパスタイプ：charset属性の対象となるメディアレベル：目的と適切な値なし：「パス」属性は一連の一連を示します最終エンドポイントを含むセッションで送信されたメッセージによってアクセスする必要があるMSRPデバイス。属性には、スペース文字によって区切られた1つ以上のMSRP URIが含まれています。
In addition to the editors, the following people contributed extensive work to this document: Chris Boulton, Paul Kyzivat, Orit Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert Sparks.
編集者に加えて、次の人々はこの文書に広範な研究を提供しました：クリス・ボールトン、ポール・キジバット、オリット・レビン、ハンス・ペルソン、アダム・ローチ、ジョナサン・ローゼンバーグ、ロバート・スパークス。
The following people contributed substantial discussion and feedback to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
次の人々は、この継続的な努力にかなりの議論とフィードバックを提供しました：エリック・バーガー、アリソン・マンキン、ジョン・ピーターソン、ブライアン・ローゼン、ディーン・ウィリス、アキ・ニーミ、ヒシャム・ハルタビル、ペッカ・ペッシ、ミゲル・ガルシア、ピーター・リドラー、サム・ハートマン、ジーン・マホニー。
[1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[1] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[6] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[8] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[9] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[9] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の伝達：コンテンツ - 分散ヘッダーフィールド」、RFC 2183、1997年8月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[10] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[11] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[12] Klyne、G。およびD. Atkins、「共通の存在とインスタントメッセージング（CPIM）：メッセージ形式」、RFC 3862、2004年8月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[13] Chown、P。、「輸送層のセキュリティ（TLS）のための高度な暗号化標準（AES）ciphersuites」、RFC 3268、2002年6月。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[14] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[15] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[16] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[17] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[18] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[18] Lennox、J。、「セッション説明プロトコル（SDP）の輸送層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[19] Johnston、A。およびO. Levin、「セッション開始プロトコル（SIP）コールコントロール - ユーザーエージェントの会議」、BCP 119、RFC 4579、2006年8月。
[20] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[20] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, October 2006.
[21] Sparks、R.、Johnston、A。、およびD. Petrie、「セッション開始プロトコルコールコントロール - 転送」、2006年10月の作業。
[22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[22] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Session Relay Protocol (MSRP)", RFC 4976, September 2007.
[23] Jennings、C.、Mahy、R。、およびA. Roach、「メッセージセッションリレープロトコル（MSRP）のリレー拡張機能」、RFC 4976、2007年9月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[24] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[25] Jennings, C., Peterson, J., and J. Fischl, "Certificate Management Service for SIP", Work in Progress, July 2007.
[25] Jennings、C.、Peterson、J。、およびJ. Fischl、「SIPの証明書管理サービス」、2007年7月の作業。
[26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[26] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[27] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[27] ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、2004年8月。
[28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[28] Housley、R。、「Triple-Des and RC2 Key Lapping」、RFC 3217、2001年12月。
[29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[29] Camarillo、G。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における初期のメディアとリンギングトーン生成」、RFC 3960、2004年12月。
[30] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[30] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 3921、2004年10月。
[31] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[31] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[32] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[32] ピーターソン、J。、「インスタントメッセージングと存在のアドレス解像度」、RFC 3861、2004年8月。
Authors' Addresses
著者のアドレス
Ben Campbell (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 USA
ベンキャンベル（編集者）エスタカドシステム17210キャンベルロードスイート250ダラス、テキサス75252 USA
EMail: ben@estacado.net
Rohan Mahy (editor) Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
Rohan Mahy（編集者）Plantronics 345 Encincal Street Santa Cruz、CA 95060 USA
EMail: rohan@ekabal.com
Cullen Jennings (editor) Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings（編集者）Cisco Systems、Inc。170 West Tasman Dr. MS：SJC-21/2 San Jose、CA 95134 USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。