RFC4976 日本語訳

4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP).C. Jennings, R. Mahy, A. B. Roach. September 2007. (Format: TXT=84244 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        C. Jennings
Request for Comments: 4976                           Cisco Systems, Inc.
Category: Standards Track                                        R. Mahy
                                                             Plantronics
                                                             A. B. Roach
                                                        Estacado Systems
                                                          September 2007

コメントを求めるワーキンググループC.ジョニングス要求をネットワークでつないでください: 4976年のシスコシステムズInc.カテゴリ: 標準化過程R.マーイPlantronics A.B.ローチエスタカードシステム2007年9月

     Relay Extensions for the Message Session Relay Protocol (MSRP)

メッセージセッションリレープロトコルのためのリレー拡大(MSRP)

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   Two separate models for conveying instant messages have been defined.
   Page-mode messages stand alone and are not part of a Session
   Initiation Protocol (SIP) session, whereas session-mode messages are
   set up as part of a session using SIP.  The Message Session Relay
   Protocol (MSRP) is a protocol for near real-time, peer-to-peer
   exchanges of binary content without intermediaries, which is designed
   to be signaled using a separate rendezvous protocol such as SIP.
   This document introduces the notion of message relay intermediaries
   to MSRP and describes the extensions necessary to use them.

インスタントメッセージを伝えるための2つの別々のモデルが定義されました。 ページモードメッセージは、単独で立って、Session Initiationプロトコル(SIP)セッションの一部ではありませんが、セッションモードメッセージはSIPを使用するセッションの一部として上がっているセットです。 Message Session Relayプロトコル(MSRP)は仲介者のいない2進の内容のリアルタイムの近いピアツーピア交換のためのプロトコルです。(内容は、SIPなどの別々のランデブープロトコルを使用することで合図されるように設計されています)。 このドキュメントは、メッセージリレー仲介者の概念をMSRPに紹介して、それらを使用するのに必要な拡大について説明します。

Jennings, et al.            Standards Track                     [Page 1]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[1ページ]

Table of Contents

目次

   1. Introduction and Requirements ...................................3
   2. Conventions and Definitions .....................................4
   3. Protocol Overview ...............................................4
      3.1. Authorization Overview ....................................11
   4. New Protocol Elements ..........................................11
      4.1. The AUTH Method ...........................................11
      4.2. The Use-Path Header .......................................12
      4.3. The HTTP Authentication "WWW-Authenticate" Header .........12
      4.4. The HTTP Authentication "Authorization" Header ............12
      4.5. The HTTP Authentication "Authentication-Info" Header ......12
      4.6. Time-Related Headers ......................................12
   5. Client Behavior ................................................13
      5.1. Connecting to Relays Acting on Your Behalf ................13
      5.2. Sending Requests ..........................................18
      5.3. Receiving Requests ........................................18
      5.4. Managing Connections ......................................18
   6. Relay Behavior .................................................18
      6.1. Handling Incoming Connections .............................18
      6.2. Generic Request Behavior ..................................19
      6.3. Receiving AUTH Requests ...................................19
      6.4. Forwarding ................................................20
           6.4.1. Forwarding SEND Requests ...........................21
           6.4.2. Forwarding Non-SEND Requests .......................22
           6.4.3. Handling Responses .................................22
      6.5. Managing Connections ......................................23
   7. Formal Syntax ..................................................23
   8. Finding MSRP Relays ............................................24
   9. Security Considerations ........................................25
      9.1. Using HTTP Authentication .................................25
      9.2. Using TLS .................................................26
      9.3. Threat Model ..............................................27
      9.4. Security Mechanism ........................................29
   10. IANA Considerations ...........................................31
      10.1. New MSRP Method ..........................................31
      10.2. New MSRP Headers .........................................31
      10.3. New MSRP Response Codes ..................................31
   11. Example SDP with Multiple Hops ................................31
   12. Acknowledgments ...............................................32
   13. References ....................................................32
      13.1. Normative References .....................................32
      13.2. Informative References ...................................33
   Appendix A.  Implementation Considerations ........................34

1. 序論と要件…3 2. コンベンションと定義…4 3. 概観について議定書の中で述べてください…4 3.1. 認可概観…11 4. 新しいプロトコル要素…11 4.1. AUTH方法…11 4.2. 経路を使用しているヘッダー…12 4.3. HTTP認証はヘッダーを「WWW認証します」…12 4.4. HTTP認証「認可」ヘッダー…12 4.5. HTTP認証「認証インフォメーション」ヘッダー…12 4.6. 時間関連のヘッダー…12 5. クライアントの振舞い…13 5.1. あなたの代理に影響するリレーに接続します…13 5.2. 送付要求…18 5.3. 要求を受け取ります…18 5.4. コネクションズを管理します…18 6. 振舞いをリレーしてください…18 6.1. 取り扱い接続要求…18 6.2. 一般的な要求の振舞い…19 6.3. AUTH要求を受け取ります…19 6.4. 転送します。20 6.4.1. 進めて、要求を送ってください…21 6.4.2. 推進、非、発信、要求…22 6.4.3. 取り扱い応答…22 6.5. コネクションズを管理します…23 7. 正式な構文…23 8. MSRPにリレーを見つけます…24 9. セキュリティ問題…25 9.1. HTTP認証を使用します…25 9.2. TLSを使用します…26 9.3. 脅威モデル…27 9.4. セキュリティメカニズム…29 10. IANA問題…31 10.1. 新しいMSRP方法…31 10.2. 新しいMSRPヘッダー…31 10.3. 新しいMSRP応答コード…31 11. 倍数がある例のSDPは跳びます…31 12. 承認…32 13. 参照…32 13.1. 標準の参照…32 13.2. 有益な参照…33 付録A.実現問題…34

Jennings, et al.            Standards Track                     [Page 2]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[2ページ]

1.  Introduction and Requirements

1. 序論と要件

   There are a number of scenarios in which using a separate protocol
   for bulk messaging is desirable.  In particular, there is a need to
   handle a sequence of messages as a session of media initiated using
   SIP [8], just like any other media type.  The Message Session Relay
   Protocol (MSRP) [11] is used to convey a session of messages directly
   between two end systems with no intermediaries.  With MSRP, messages
   can be arbitrarily large and all traffic is sent over reliable,
   congestion-safe transports.

大量のメッセージングに別々のプロトコルを使用するのが望ましい多くのシナリオがあります。 特に、SIP[8]を使用することで開始されたメディアのセッションとしてメッセージの系列を扱う必要があります、まさしくいかなる他のメディアタイプのようにも。 Message Session Relayプロトコル(MSRP)[11]は、仲介者なしで2台のエンドシステムの直接間にメッセージのセッションを伝えるのに使用されます。 MSRPと共に、メッセージは任意に大きい場合があります、そして、すべての交通が信頼できる移動している混雑安全輸送です。

   This document describes extensions to the core MSRP protocol to
   introduce intermediaries called relays.  With these extensions, MSRP
   clients can communicate directly, or through an arbitrary number of
   relays.  Each client is responsible for identifying any relays acting
   on its behalf and providing appropriate credentials.  Clients that
   can receive new TCP connections directly do not have to implement any
   new functionality to work with these relays.

このドキュメントは、リレーと呼ばれる仲介者を紹介するためにコアMSRPプロトコルに拡大について説明します。 これらの拡大で、MSRPクライアントは直接かリレーの特殊活字の数字を通って交信できます。 それぞれのクライアントは利益に影響して、適切な信任状を提供するどんなリレーも特定するのに責任があります。 新しいTCP接続を受けることができるクライアントは、これらのリレーで働くために直接少しの新しい機能性も実行する必要はありません。

   The goals of the MSRP relay extensions are listed below:

MSRPリレー拡張子の目標は以下に記載されています:

   o  convey arbitrary binary MIME data without modification or transfer
      encoding

o 変更も転送コード化なしで任意の2進のMIMEデータを伝えてください。

   o  continue to support client-to-client operation (no relay servers
      required)

o クライアントからクライアントへの操作を支持し続けてください。(サーバが必要としなかったリレー全く)

   o  operate through an arbitrary number of relays for policy
      enforcement

o 方針実施のためのリレーの特殊活字の数字を通して作動してください。

   o  operate through relays under differing administrative control

o 異なった運営管理コントロールの下におけるリレーで、作動してください。

   o  allow each client to control which relays are traversed on its
      behalf

o どのリレーがそのに代わって横断されるかを各クライアントを制御させてください。

   o  prevent unsolicited messages (spam), "open relays", and Denial of
      Service (DoS) amplification

o お節介なメッセージ(ばらまく)、「オープンリレー」、およびサービス妨害(DoS)増幅を防いでください。

   o  allow relays to use one or a small number of TCP or TLS [2]
      connections to carry messages for multiple sessions, recipients,
      and senders

o リレーに複数のセッション、受取人、および送付者のためにメッセージを伝えるのに1か少ない数のTCPかTLS[2]接続を使用させてください。

   o  allow large messages to be sent over slow connections without
      causing head-of-line blocking problems

o 線のヘッドブロッキングに問題を引き起こさないで遅い接続の上に送られるべき大きいメッセージを許容してください。

   o  allow transmissions of large messages to be interrupted and
      resumed in places where network connectivity is lost and later
      reestablished

o ネットワークの接続性が失われていて、後で回復する場所で中断している、再開するべき大きいメッセージの送信を許してください。

Jennings, et al.            Standards Track                     [Page 3]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[3ページ]

   o  offer notification of message failure at any intermediary

o あらゆる仲介者でメッセージ失敗の通知を提供してください。

   o  allow relays to delete state after a short amount of time

o リレーに短い時間の後に状態を削除させてください。

2.  Conventions and Definitions

2. コンベンションと定義

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [9].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[9]で説明されるように本書では解釈されることであるべきですか?

   Below we list several definitions important to MSRP:

以下では、私たちがMSRPに重要ないくつかの定義を記載します:

   MSRP node: a host that implements the MSRP protocols as a client or a
      relay.

MSRPノード: クライアントかリレーとしてMSRPプロトコルを実行するホスト。

   MSRP client: an MSRP node that is the initial sender or final target
      of messages and delivery status.

MSRPクライアント: メッセージと配送状態の初期の送付者か最終的な目標であるMSRPノード。

   MSRP relay: an MSRP node that forwards messages and delivery status
      and may provide policy enforcement.  Relays can fragment and
      reassemble portions of messages.

MSRPは以下をリレーします。 メッセージと配送状態を転送して、方針実施を備えるかもしれないMSRPノード。 リレーは、メッセージの部分を断片化して、組み立て直すことができます。

   Message: arbitrary MIME [13][14] content that one client wishes to
      send to another.  For the purposes of this specification, a
      complete MIME body as opposed to a portion of a complete message.

メッセージ: 1人のクライアントが別のものに送りたがっている任意のMIME[13][14]内容。 この仕様、完全なメッセージの部分と対照的に完全なMIME本体の目的のために。

   chunk: a portion of a complete message delivered in a SEND request.

塊: 完全なメッセージの部分はSEND要求を果たしました。

   end-to-end: delivery of data from the initiating client to the final
      target client.

終わるには、終わってください: データの開始しているクライアントから最終的な目標クライアントまでの配送。

   hop: delivery of data between one MSRP node and an adjacent node.

以下を飛び越してください。 1つのMSRPノードと隣接しているノードの間のデータの配送。

3.  Protocol Overview

3. プロトコル概観

   With the introduction of this extension, MSRP has the concept of both
   clients and relays.  Clients send messages to relays and/or other
   clients.  Relays forward messages and message delivery status to
   clients and other relays.  Clients that can open TCP connections to
   each other without intervening policy restrictions can communicate
   directly with each other.  Clients who are behind firewalls or who
   need to use intermediaries for policy reasons can use the services of
   a relay.  Each client is responsible for enlisting the assistance of
   one or more relays for its side of the communication.

この拡大の導入によって、MSRPには、クライアントとリレーの両方の概念があります。 クライアントはリレー、そして/または、他のクライアントにメッセージを送ります。 リレーはメッセージとメッセージ配送状態をクライアントと他のリレーに転送します。 介入している方針制限なしでTCP接続を互いに公開できるクライアントは互いと共に直接伝達できます。 ファイアウォールの後ろにいるか、または方針理由に仲介者を使用する必要があるクライアントはリレーのサービスを利用できます。 それぞれのクライアントは1個以上のリレーの支援をコミュニケーションの側に得るのに責任があります。

   Clients that use a relay operate by first opening a TLS connection
   with a relay, authenticating, and retrieving an msrps: URI (from the
   relay) that the client can provide to its peers to receive messages

msrpsを認証して、検索して、リレーを使用するクライアントが最初の始まりのそばでリレーとのTLS接続を手術します: クライアントがメッセージを受け取るために同輩に提供できるURI(リレーからの)

Jennings, et al.            Standards Track                     [Page 4]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[4ページ]

   later.  There are several steps for doing this.  First, the client
   opens a TLS connection to its first relay, and verifies that the name
   in the certificate matches the name of the relay to which it is
   trying to connect.  Such verification is performed according to the
   procedures defined in Section 9.2.  After verifying that it has
   connected to the proper host, the client authenticates itself to the
   relay using an AUTH request containing appropriate authentication
   credentials.  In a successful AUTH response, the relay provides an
   msrps: URI associated with the path back to the client.  The client
   can then give this URI to other clients for end-to-end message
   delivery.

後で。 これをするための数ステップがあります。 まず最初に、クライアントは、最初のリレーにTLS接続を開いて、証明書の名前がそれが接続しようとしているリレーの名前に合っていることを確かめます。 セクション9.2で定義された手順によると、そのような検証は実行されます。 それが適切なホストに接したことを確かめた後に、クライアントは、適切な認証信任状を含むAUTH要求を使用することでリレーにそれ自体を認証します。 うまくいっているAUTH応答に、リレーはmsrpsを提供します: クライアントへの経路に関連しているURI。 そして、クライアントは終わりから終わりへのメッセージ配送のためにこのURIを他のクライアントに与えることができます。

   When clients wish to send a short message, they issue a SEND request
   with the entire contents of the message.  If any relays are required,
   they are included in the To-Path header.  The leftmost URI in the To-
   Path header is the next hop to deliver a request or response.  The
   rightmost URI in the To-Path header is the final target.

クライアントが短いメッセージを送りたがっているとき、彼らはメッセージの全体のコンテンツでSEND要求を出します。 何かリレーが必要であるなら、それらはTo-経路ヘッダーに含まれています。 To経路ヘッダーの一番左URIは要求か応答を提供する次のホップです。 To-経路ヘッダーの一番右のURIは最終的な目標です。

   SEND requests contain headers that indicate how they are acknowledged
   in a hop-by-hop form and in an end-to-end form.  The default is that
   SEND messages are acknowledged hop-by-hop.  (Each relay that receives
   a SEND request acknowledges receipt of the request before forwarding
   the content to the next relay or the final target.)  All other
   requests are acknowledged end-to-end.

SEND要求は彼らがホップごとのフォームと終わりから終わりへの用紙でどう承認されるかを示すヘッダーを含んでいます。 デフォルトはSENDメッセージがホップごとに承認されるということです。 (次のリレーか最終的な目標に内容を転送する前に、SEND要求を受け取る各リレーが要求の領収書を受け取ったことを知らせます。) 他のすべての要求が、承認された終わりから終わりです。

   With the introduction of relays, the subtle semantics of the To-Path
   header and the From-Path header become more relevant.  The To-Path in
   both requests and responses is the list of URIs that need to be
   visited in order to reach the final target of the request or
   response.  The From-Path is the list of URIs that indicate how to get
   back to the original sender of the request or response.  These
   headers differ from the To and From headers in SIP, which do not
   "swap" from request to response.  (Note that sometimes a request is
   sent to or from an intermediary directly.)

リレーの挿入によると、To-経路ヘッダーの微妙な意味論とFrom-経路ヘッダーは、より関連するようになります。 要求と応答の両方のTo-経路は要求か応答の最終的な目標に達するように訪問される必要があるURIのリストです。 From-経路は要求か応答の元の送り主に折り返し連絡する方法を示すURIのリストです。 これらのヘッダーはSIPでToとFromヘッダーと異なっています。(SIPは要求から応答まで「スワップしません」)。 (時々、要求が仲介者か仲介者から直接送られることに注意してください。)

   When a relay forwards a request, it removes its address from the To-
   Path header and inserts it as the first URI in the From-Path header.
   For example, if the path from Alice to Bob is through relays A and B,
   when B receives the request it contains path headers that look like
   the following. (Note that MSRP does not permit line folding.  A "\"
   in the examples shows a line continuation due to limitations in line
   length of this document.  Neither the backslash nor the extra CRLF is
   included in the actual request or response.)

リレーが要求を転送するとき、それは、To経路ヘッダーからアドレスを取り除いて、From-経路ヘッダーにおける最初のURIとしてそれを挿入します。 Bが要求を受け取るとき、例えば、アリスからボブまでの経路がリレーAとBであるなら、それは以下に似ている経路ヘッダーを含んでいます。 (MSRPが線の折り重なりを可能にしないことに注意してください。 例の「\」はこのドキュメントの行長における制限による線継続を示しています。 バックスラッシュも余分なCRLFも実際の要求か応答に含まれていません。)

   To-Path:   msrps://B.example.com/bbb;tcp \
              msrps://Bob.example.com/bob;tcp
   From-Path: msrps://A.example.com/aaa;tcp \
              msrps://Alice.example.com/alice;tcp

経路: msrps://B.example.com/bbb; tcp\msrps://Bob.example.com/ボブ;は経路であることでtcpされます: msrps://A.example.com/aaa; tcp\msrps://Alice.example.com/alice; tcp

Jennings, et al.            Standards Track                     [Page 5]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[5ページ]

   After forwarding the request, the path headers look like this:

要求を転送した後に、経路ヘッダーはこれに似ています:

   To-Path: msrps://Bob.example.com/bob;tcp
   From-Path: msrps://B.example.com/bbb;tcp \
              msrps://A.example.com/aaa;tcp \
              msrps://Alice.example.com/alice;tcp

経路: msrps://Bob.example.com/ボブ; tcpに経路: msrps://B.example.com/bbb; tcp\msrps://A.example.com/aaa; tcp\msrps://Alice.example.com/alice; tcp

   The sending of an acknowledgment for SEND requests is controlled by
   the Success-Report and Failure-Report headers and works the same way
   as in the base MSRP protocol.  When a relay receives a SEND request,
   if the Failure-Report is set to "yes", it means that the previous hop
   is running a timer and the relay needs to send a response to the
   request.  If the final response conveys an error, the previous hop is
   responsible for constructing the error report and sending it back to
   the original sender of the message.  The 200 response acknowledges
   receipt of the request so that the previous hop knows that it is no
   longer responsible for the request.  If the relay knows that it will
   not be able to deliver the request and the Failure-Report is set to
   any value other than "no", then it sends a REPORT to tell the sender
   about the error.  If the Failure-Report is set to "yes", then after
   the relay is done sending the request to the next hop it starts
   running a timer; if the timer expires before a response is received
   from the next hop, the relay assumes that an error has happened and
   sends a REPORT to the sender.  If the Failure-Report is not set to
   "yes", there is no need for the relay to run this timer.

SEND要求のための承認の発信は、Success-レポートとFailure-レポートヘッダーによって制御されて、ずっとベースMSRPプロトコルのように同じように働いています。 Failure-レポートが「はい」に設定されるならリレーがSEND要求を受け取るとき、それは、前のホップがタイマを動かしていて、リレーが、応答を要求に送る必要を意味します。 最終的な応答が誤りを伝えるなら、前のホップはエラー・レポートを構成して、メッセージの元の送り主にそれを送り返すのに原因となります。 200応答が要求の領収書を受け取ったことを知らせるので、前のホップは、それはもう要求に責任がないのを知っています。 リレーが、要求を提供できないのを知って、Failure-レポートが「いいえ」を除いたどんな値にも設定されるなら、それは、誤りに関して送付者に話すためにREPORTを送ります。 Failure-レポートが「はい」に設定されるなら、リレーが次のホップに要求を送り終わった後にタイマを動かし始めます。 次のホップから応答を受ける前にタイマが期限が切れるなら、リレーは、誤りが送付者に起こって、REPORTを送ると仮定します。 Failure-レポートが「はい」に設定されないなら、リレーがこのタイマを動かす必要は全くありません。

   The following example shows a typical MSRP session.  The AUTH
   requests are explained in a later section but left in the example for
   call flow completeness.

以下の例は典型的なMSRPセッションを示しています。 AUTH要求は、後のセクションで説明されますが、呼び出し流れの完全性のための例に残されます。

Jennings, et al.            Standards Track                     [Page 6]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[6ページ]

   Alice              a.example.org       b.example.net             Bob
     |                     |                    |                     |
     |::::::::::::::::::::>| connection opened  |<::::::::::::::::::::|
     |--- AUTH ----------->|                    |<-- AUTH ------------|
     |<-- 200 OK-----------|                    |--- 200 OK---------->|
     |                     |                    |                     |
           ....                time passes           ....
     |                     |                    |                     |
     |--- SEND ----------->|                    |                     |
     |<-- 200 OK ----------|:::::::::::::::::::>|  (slow link)        |
     |                     |--- SEND ---------->|                     |
     |                     |<-- 200 OK ---------|--- SEND ----------->|
     |                     |                    |                ....>|
     |                     |                    |                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT ----------|
     |                     |<-- REPORT ---------|                     |
     |<-- REPORT ----------|                    |                     |
     |                     |                    |                     |

アリスa.example.org b.example.netボブ| | | | |::::::::::::::::::::>| 接続は開きました。|<:、:、:、:、:、:、:、:、:、:、:、:、:、:、:、:、:、:、:、:| |--- AUTH----------->| | <-- AUTH------------| | <-- 200 OK-----------| |--- 200 OK---------->|、|、|、|、| … . 時間が経ってください… | | | | |--- 発信してください。----------->|、|、| | <-- 200 OK----------|:::::::::::::::::::>| (遅いリンク) | | |--- 発信してください。---------->|、|、| | <-- 200 OK---------|--- 発信してください。----------->|、|、|、| ....>|、|、|、| ..>|、|、| | <-- 200 OK----------| | | | <-- レポート----------| | | <-- レポート---------| | | <-- レポート----------| | | | | | |

   The SEND and REPORT messages are shown below to illustrate the To-
   Path and From-Path headers.  (Note that MSRP does not permit line
   folding.  A "\" in the examples shows a line continuation due to
   limitations in line length of this document.  Neither the backslash,
   nor the extra CRLF is included in the actual request or response.)

SENDとREPORTメッセージは、To経路とFrom-経路ヘッダーを例証するために以下で見せられます。 (MSRPが線の折り重なりを可能にしないことに注意してください。 例の「\」はこのドキュメントの行長における制限による線継続を示しています。 バックスラッシュも余分なCRLFも実際の要求か応答に含まれていません。)

    MSRP 6aef SEND
    To-Path: msrps://a.example.org:9000/kjfjan;tcp \
             msrps://b.example.net:9000/aeiug;tcp \
             msrps://bob.example.net:8145/foo;tcp
    From-Path: msrps://alice.example.org:7965/bar;tcp
    Success-Report: yes
    Byte-Range: 1-*/*
    Message-ID: 87652
    Content-Type: text/plain

MSRP 6aefは経路で発信します: msrps://a.example.org: 9000/kjfjan; tcp\msrps://b.example.net: 9000/aeiug; tcp\msrps://bob.example.net: 8145/foo; tcp From-経路: msrps://alice.example.org: tcp Success7965/バー;レポート: はいByte-範囲: 1*/*Message ID: 87652コンテントタイプ: テキスト/平野

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

こんにちは、ボブ、私はfile.mpegをあなたに送ろうとしています。-------6aef$

    MSRP 6aef 200 OK
    To-Path: msrps://alice.example.org:7965/bar;tcp
    From-Path: msrps://a.example.org:9000/kjfjan;tcp
    Message-ID: 87652
    -------6aef$

MSRP 6aef200は経路に以下を承認します。 msrps://alice.example.org: tcp From7965/バー;経路: msrps://a.example.org: 9000/kjfjan; tcp Message-ID、: 87652 -------6aef$

Jennings, et al.            Standards Track                     [Page 7]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[7ページ]

    MSRP juh76 SEND
    To-Path: msrps://b.example.net:9000/aeiug;tcp \
             msrps://bob.example.net:8145/foo;tcp
    From-Path: msrps://a.example.org:9000/kjfjan;tcp \
               msrps://alice.example.org:7965/bar;tcp
    Success-Report: yes
    Message-ID: 87652
    Byte-Range: 1-*/*
    Content-Type: text/plain

MSRP juh76 SEND To-経路: msrps://b.example.net: 9000/aeiug; tcp\msrps://bob.example.net: 8145/foo; tcp From-経路: msrps://a.example.org: 9000/kjfjan; tcp\msrps://alice.example.org: tcp Success7965/バー;レポート: はいMessage-ID: 87652バイト範囲: 1*/*コンテントタイプ: テキスト/平野

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

こんにちは、ボブ、私はfile.mpegをあなたに送ろうとしています。-------juh76$

    MSRP juh76 200 OK
    To-Path: msrps://a.example.org:9000/kjfjan;tcp
    From-Path: msrps://b.example.net:9000/aeiug;tcp
    Message-ID: 87652
    -------juh76$

MSRP juh76 200OK To-経路: msrps://a.example.org: 9000/kjfjan; tcp From-経路、: msrps://b.example.net: 9000/aeiug; tcp Message-ID、: 87652 -------juh76$

    MSRP xght6 SEND
    To-Path: msrps://bob.example.net:8145/foo;tcp
    From-Path: msrps://b.example.net:9000/aeiug;tcp \
               msrps://a.example.org:9000/kjfjan;tcp \
               msrps://alice.example.org:7965/bar;tcp
    Success-Report: yes
    Message-ID: 87652
    Byte-Range: 1-*/*
    Content-Type: text/plain

MSRP xght6 SEND To-経路: msrps://bob.example.net: 8145/foo; tcp From-経路、: msrps://b.example.net: 9000/aeiug; tcp\msrps://a.example.org: 9000/kjfjan; tcp\msrps://alice.example.org: tcp Success7965/バー;レポート: はいMessage-ID: 87652バイト範囲: 1*/*コンテントタイプ: テキスト/平野

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

こんにちは、ボブ、私はfile.mpegをあなたに送ろうとしています。-------xght6$

    MSRP xght6 200 OK
    To-Path: msrps://b.example.net:9000/aeiug;tcp
    From-Path: msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652

MSRP xght6 200OK To-経路: msrps://b.example.net: 9000/aeiug; tcp From-経路、: msrps://bob.example.net: 8145/foo; tcp Message-ID、: 87652

Jennings, et al.            Standards Track                     [Page 8]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[8ページ]

    MSRP yh67 REPORT
    To-Path: msrps://b.example.net:9000/aeiug;tcp \
             msrps://a.example.org:9000/kjfjan;tcp \
             msrps://alice.example.org:7965/bar;tcp
    From-Path: msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652
    Byte-Range: 1-39/39
    Status: 000 200 OK
    -------yh67$

MSRP yh67 REPORT To-経路: msrps://b.example.net: 9000/aeiug; tcp\msrps://a.example.org: 9000/kjfjan; tcp\msrps://alice.example.org: tcp From7965/バー;経路: msrps://bob.example.net: 8145/foo; tcp Message-ID、: 87652バイト範囲: 1-39/39状態: 000 200OK-------yh67$

    MSRP yh67 REPORT
    To-Path: msrps://a.example.org:9000/kjfjan;tcp \
             msrps://alice.example.org:7965/bar;tcp
    From-Path: msrps://b.example.net:9000/aeiug;tcp \
               msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652
    Byte-Range: 1-39/39
    Status: 000 200 OK
    -------yh67$

MSRP yh67 REPORT To-経路: msrps://a.example.org: 9000/kjfjan; tcp\msrps://alice.example.org: tcp From7965/バー;経路: msrps://b.example.net: 9000/aeiug; tcp\msrps://bob.example.net: 8145/foo; tcp Message-ID: 87652バイト範囲: 1-39/39状態: 000 200OK-------yh67$

    MSRP yh67 REPORT
    To-Path: msrps://alice.example.org:7965/bar;tcp
    From-Path: msrps://a.example.org:9000/kjfjan;tcp \
               msrps://b.example.net:9000/aeiug;tcp \
               msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652
    Byte-Range: 1-39/39
    Status: 000 200 OK
    -------yh67$

MSRP yh67 REPORT To-経路: msrps://alice.example.org: tcp From7965/バー;経路: msrps://a.example.org: 9000/kjfjan; tcp\msrps://b.example.net: 9000/aeiug; tcp\msrps://bob.example.net: 8145/foo; tcp Message-ID: 87652バイト範囲: 1-39/39状態: 000 200OK-------yh67$

   When sending large content, the client may split up a message into
   smaller pieces; each SEND request might contain only a portion of the
   complete message.  For example, when Alice sends Bob a 4-GB file
   called "file.mpeg", she sends several SEND requests each with a
   portion of the complete message.  Relays can repack message fragments
   en route.  As individual parts of the complete message arrive at the
   final destination client, the receiving client can optionally send
   REPORT requests indicating delivery status.

大きい内容を送るとき、クライアントはメッセージをより小さい断片に分けるかもしれません。 それぞれのSEND要求は完全なメッセージの部分だけを含むかもしれません。 アリスが"file.mpeg"と呼ばれる4GBのファイルをボブに送るとき、例えば、彼女は完全なメッセージの部分と共にいくつかのSEND要求にそれぞれを送ります。 リレーは途中「再-パック」メッセージ断片をそうすることができます。 完全なメッセージの個々の部分が最終的な目的地クライアントに到着するとき、受信クライアントはREPORT要求に配送状態を任意に示させることができます。

   MSRP nodes can send individual portions of a complete message in
   multiple SEND requests.  As relays receive chunks, they can
   reassemble or re-fragment them as long as they resend the resulting
   chunks in order.  (Receivers still need to be prepared to receive
   out-of-order chunks, however.)  If the sender has set the Success-
   Report header to "yes", once a chunk or complete message arrives at
   the destination client, the destination will send a REPORT request

MSRPノードは複数のSEND要求における完全なメッセージの個々の部分を送ることができます。 リレーが塊を受けるとき、整然とした状態で結果として起こる塊を再送する限り、それらは、それらを組み立て直すか、または再断片化できます。 (受信機は、まだしかしながら、不適切な塊を受けるように準備される必要があります。) 送付者が「はい」にSuccessレポートヘッダーを設定したなら、塊か完全なメッセージがいったん目的地クライアントに到着すると、目的地はREPORT要求を送るでしょう。

Jennings, et al.            Standards Track                     [Page 9]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[9ページ]

   indicating that a chunk arrived end-to-end.  This request travels
   back along the reverse path of the SEND request.  Unlike the SEND
   request, which can be acknowledged along every hop, REPORT requests
   are never acknowledged.

終わるために終わって、塊が到着したのを示してください。 この要求はSEND要求の逆の経路に沿って移動します。 SEND要求と異なって、REPORT要求を決して承諾しません。あらゆるホップに沿って要求を承諾できます。

   The following example shows a message being re-chunked through two
   relays:

以下の例は、メッセージが2個のリレーで再chunkedされるのを示します:

   Alice              a.example.org       b.example.net             Bob
     |                     |                    |                     |
     |--- SEND 1-3 ------->|                    |                     |
     |<-- 200 OK ----------|                    |  (slow link)        |
     |--- SEND 4-7 ------->|--- SEND 1-5 ------>|                     |
     |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
     |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|
     |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT 1-3 ------|
     |                     |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
     |<-- REPORT 1-3 ------|                    |                 ...>|
     |                     |                    |<-- REPORT 4-7 ----->|
     |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
     |<-- REPORT 4-7 ------|                    |                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |<-- REPORT done-----|<-- REPORT done -----|
     |<-- REPORT done -----|                    |                     |
     |                     |                    |                     |

アリスa.example.org b.example.netボブ| | | | |--- 1-3に発信してください。------->|、|、| | <-- 200 OK----------| | (遅いリンク) | |--- 4-7に発信してください。------->|、-、-- 1-5に発信してください。------>|、| | <-- 200 OK----------| <-- 200 OK---------|--- 1-3に発信してください。------->| |--- 8-10に発信してください。------>|、-、-- 6-10に発信してください。----->| ....>| | <-- 200 OK----------| <-- 200 OK---------| ..>|、|、| | <-- 200 OK----------| | | | <-- レポート1-3------| | | <-- レポート1-3-----|--- 4-7に発信してください。------->| | <-- レポート1-3------| | ...>|、|、| | <-- レポート4-7----->|、| | <-- レポート4-7-----|--- 8-10に発信してください。------>| | <-- レポート4-7------| | ..>|、|、| | <-- 200 OK----------| | | <-- 行われたREPORT-----| <-- 行われたREPORT-----| | <-- 行われたREPORT-----| | | | | | |

   Relays only keep transaction states for a short time for each chunk.
   Delivery over each hop should take no more than 30 seconds after the
   last byte of data is sent.  Client applications define their own
   implementation-dependent timers for end-to-end message delivery.

リレーは、各塊のための短い間取引が州であることを保つだけです。 データの最後のバイトを送った30秒未満後に各ホップの上の配送は取るべきです。 クライアントアプリケーションは終わりから終わりへのメッセージ配送のためのそれら自身の実現依存するタイマを定義します。

   For client-to-client communication, the sender of a message typically
   opens a new TCP connection (with or without TLS) if one is needed.
   Relays reuse existing connections first, but can open new connections
   (typically to other relays) to deliver requests such as SEND or
   REPORT.  Responses can only be sent over existing connections.

クライアントからクライアントへのコミュニケーションに関しては、1が必要であるなら、メッセージの送付者は新しいTCP接続(TLSのあるなしにかかわらず)を通常開きます。 リレーは、最初に既存の接続を再利用しますが、SENDかREPORTなどの要求を提供するために、新しい接続(通常他のリレーへの)を開くことができます。 既存の接続の上に応答を送ることができるだけです。

   The relationship between MSRP and signaling protocols (such as SIP)
   is unchanged by this document, and is as described in [11].  An
   example of an SDP exchange for an MSRP session involving relays is
   shown in Section 11.

MSRPとシグナリングプロトコル(SIPなどの)との関係は、このドキュメントで変わりがなく、[11]で説明されるようにあります。 リレーにかかわるMSRPセッションへのSDP交換に関する例はセクション11に示されます。

Jennings, et al.            Standards Track                    [Page 10]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[10ページ]

3.1.  Authorization Overview

3.1. 認可概観

   A key element of this protocol is that it cannot introduce open
   relays, with all the associated problems they create, including DoS
   attacks.  A message is only forwarded by a relay if it is either
   going to or coming from a client that has authenticated to the relay
   and been authorized for relaying messages on that particular session.
   Because of this, clients use an AUTH message to authenticate to a
   relay and get a URI that can be used for forwarding messages.

このプロトコルの主要な原理はオープンリレーを導入できないということです、それらが作成するすべての関連する問題で、DoS攻撃を含んでいて。 その特定のセッションのときにリレーに認証されて、メッセージをリレーするために権限を与えられたクライアントから行くか、または来る場合にだけ、リレーでメッセージを転送します。 これのために、クライアントはリレーに認証して、推進メッセージに使用できるURIを得るAUTHメッセージを使用します。

   If a client wishes to use a relay, it sends an AUTH request to the
   relay.  The client authenticates the relay using the relay's TLS
   certificate.  The client uses HTTP Digest authentication [1] to
   authenticate to the relay.  When the authentication succeeds, the
   relay returns a 200 response that contains the URI that the client
   can use in the MSRP path for the relay.

クライアントがリレーを使用したいと思うなら、それはAUTH要求をリレーに送ります。 クライアントは、リレーのTLS証明書を使用することでリレーを認証します。 クライアントはリレーに認証するHTTP Digest認証[1]を使用します。 認証が成功すると、リレーはクライアントがリレーにMSRP経路で使用できるURIを含む200応答を返します。

   A typical challenge response flow is shown below:

典型的なチャレンジレスポンス流動は以下に示されます:

   Alice              a.example.org
     |                     |
     |::::::::::::::::::::>|
     |--- AUTH ----------->|
     |<- 401 Unauthorized -|
     |--- AUTH ----------->|
     |<-- 200 OK-----------|
     |                     |

アリスa.example.org| | |::::::::::::::::::::>| |--- AUTH----------->| | <、- 401、権限のなさ、-| |--- AUTH----------->| | <-- 200 OK-----------| | |

   The URI that the client should use is returned in the Use-Path header
   of the 200.

200のもののUse-経路ヘッダーでクライアントが使用するべきであるURIを返します。

   Note that URIs returned to the client are effectively secret tokens
   that should be shared only with the other MSRP client in a session.
   For that reason, the client MUST NOT reuse the same URI for multiple
   sessions, and needs to protect these URIs from eavesdropping.

クライアントに返されたURIがセッションのときにもう片方のMSRPクライアントだけと共有されるべきである事実上秘密の象徴であることに注意してください。 その理由で、クライアントは、複数のセッションのために同じURIを再利用してはいけなくて、雨垂れからこれらのURIを保護する必要があります。

4.  New Protocol Elements

4. 新しいプロトコル要素

4.1.  The AUTH Method

4.1. AUTH方法

   AUTH requests are used by clients to create a handle they can use to
   receive incoming requests.  AUTH requests also contain credentials
   used to authenticate a client and authorization policy used to block
   Denial of Service attacks.

AUTH要求は、彼らが入って来る要求を受け取るのに使用できるハンドルを作成するのにクライアントによって使用されます。 また、AUTH要求はサービス妨害攻撃を妨げるのに使用されるクライアントと認可方針を認証するのにおいて中古の信任状を含んでいます。

   In response to an AUTH request, a successful response contains a Use-
   Path header with a list of URIs that the client can give to its peers
   to route responses back to the client.

AUTH要求に対応して、うまくいっている応答はクライアントへの応答を発送するためには同輩へのURIのリストでUse経路ヘッダーを含んでいます。

Jennings, et al.            Standards Track                    [Page 11]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[11ページ]

4.2.  The Use-Path Header

4.2. 経路を使用しているヘッダー

   The Use-Path header is a list of URIs provided by an MSRP relay in
   response to a successful AUTH request.  This list of URIs can be used
   by the MSRP client that sent the AUTH request to receive MSRP
   requests and to advertise this list of URIs, for example, in a
   session description.  URIs in the Use-Path header MUST include a
   fully qualified domain name (as opposed to a numeric IP address) and
   an explicit port number.

Use-経路ヘッダーはMSRPリレーでうまくいっているAUTH要求に対応して提供されたURIのリストです。 MSRP要求を受け取って、例えばセッション記述でURIのこのリストの広告を出すというAUTH要求を送ったMSRPクライアントはURIのこのリストを使用できます。 Use-経路ヘッダーのURIは完全修飾ドメイン名(数値IPアドレスと対照的に)と明白なポートナンバーを含まなければなりません。

   The URIs in the Use-Path header are in the same order that the
   authenticating client uses them in a To-Path header.  Instructions on
   forming To-Path headers and SDP [7] path attributes from information
   in the Use-Path header are provided in Section 5.1.

同次にはUse-経路ヘッダーのURIがあります。認証しているクライアントはTo-経路ヘッダーでそれらを使用します。 Use-経路ヘッダーで情報からTo-経路ヘッダーとSDP[7]経路属性を形成する指示をセクション5.1に提供します。

4.3.  The HTTP Authentication "WWW-Authenticate" Header

4.3. HTTP認証はヘッダーを「WWW認証します」。

   The "WWW-Authenticate" header contains a challenge token used in the
   HTTP Digest authentication procedure (from RFC 2617 [1]).  The usage
   of HTTP Digest authentication in MSRP is described in detail in
   Section 5.1.

挑戦象徴はHTTPでDigest認証手順を用いました。ヘッダーを「WWW認証する」、含有、(RFC2617[1])から。 MSRPでのHTTP Digest認証の用法はセクション5.1で詳細に説明されます。

4.4.  The HTTP Authentication "Authorization" Header

4.4. HTTP認証「認可」ヘッダー

   The "Authorization" header contains authentication credentials for
   HTTP Digest authentication (from RFC 2617 [1]).  The usage of HTTP
   Digest authentication in MSRP is described in detail in Section 5.1.

「認可」ヘッダーはHTTP Digest認証のための認証信任状を含んでいます。(RFC2617[1])から。 MSRPでのHTTP Digest認証の用法はセクション5.1で詳細に説明されます。

4.5.  The HTTP Authentication "Authentication-Info" Header

4.5. HTTP認証「認証インフォメーション」ヘッダー

   The "Authentication-Info" header contains future challenges to be
   used for HTTP Digest authentication (from RFC 2617 [1]).  The usage
   of HTTP Digest authentication in MSRP is described in detail in
   Section 5.1.

「認証インフォメーション」ヘッダーはHTTP Digest認証に使用されるべき未来の挑戦を含んでいます。(RFC2617[1])から。 MSRPでのHTTP Digest認証の用法はセクション5.1で詳細に説明されます。

4.6.  Time-Related Headers

4.6. 時間関連のヘッダー

   The Expires header in a request provides a relative time after which
   the action implied by the method of the request is no longer of
   interest.  In a request, the Expires header indicates how long the
   sender would like the request to remain valid.  In a response, the
   Expires header indicates how long the responder considers this
   information relevant.  Specifically, an Expires header in an AUTH
   request indicates how long the provided URIs will be valid.

要求におけるExpiresヘッダーは要求の方法で含意された行為がもう興味がない相対的な時を提供します。 要求では、Expiresヘッダーは、送付者がどれくらい長い間有効なままで残っているという要求が欲しいかを示します。 応答では、Expiresヘッダーは、応答者が、どれくらい長い間この情報が関連していると考えるかを示します。 明確に、AUTH要求におけるExpiresヘッダーは、提供されたURIがどれくらい長い間有効になるかを示します。

Jennings, et al.            Standards Track                    [Page 12]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[12ページ]

   The Min-Expires header contains the minimum duration a server will
   permit in an Expires header.  It is sent only in 423 "Interval Out-
   of-Bounds" responses.  Likewise, the Max-Expires header contains the
   maximum duration a server will permit in an Expires header.

Min期限が切れる、ヘッダーはサーバがExpiresヘッダーで可能にする最小の持続時間を含んでいます。 423の「領域の間隔アウト」応答だけでそれを送ります。 同様である、ヘッダーをマックスと同じくらい吐き出す、サーバがExpiresヘッダーで可能にする最大の持続時間を含んでいます。

5.  Client Behavior

5. クライアントの振舞い

5.1.  Connecting to Relays Acting on Your Behalf

5.1. あなたの代理に影響するリレーに接続すること。

   Clients that want to use the services of a relay or list of relays
   need to send an AUTH request to each relay that will act on their
   behalf.  (For example, some organizations could deploy an "intra-org"
   relay and an "extra-org" relay.)  The inner relay is used to tunnel
   the AUTH requests to the outer relay.  For example, the client will
   send an AUTH to intra-org and get back a path that can be used for
   forwarding through intra-org.  The client would then send a second
   AUTH destined to extra-org but sent through intra-org.  The intra-org
   relay forwards this to extra-org and extra-org returns a path that
   can be used to forward messages from another destination to extra-org
   to intra-org and then on to this client.  Each relay authenticates
   the client.  The client authenticates the first relay and each relay
   authenticates the next relay.

リレーのリレーかリストのサービスを利用したがっているクライアントは、それらの利益に影響する各リレーにAUTH要求を送る必要があります。 (例えば、いくつかの組織が「イントラ-org」リレーと「余分なorg」リレーを配備できました。) 内側のリレーは、外側のリレーにAUTH要求にトンネルを堀るのに使用されます。 例えば、クライアントは、イントラ-orgにAUTHを送って、イントラ-orgを通して推進に使用できる経路を取り戻すでしょう。 そして、クライアントは余分なorgに運命づけられていますが、イントラ-orgを通して送られた第2のAUTHを送るでしょう。 イントラ-orgリレーは余分なorgにこれを送ります、そして、余分なorgは別の目的地から余分なorgまでイントラ-orgと、そして、そして、このクライアントにメッセージを転送するのに使用できる経路を返します。 各リレーはクライアントを認証します。 クライアントは最初のリレーを認証します、そして、各リレーは次のリレーを認証します。

   Clients can be configured (typically, through discovery or manual
   provisioning) with a list of relays they need to use.  They MUST be
   able to form a connection to the first relay and send an AUTH command
   to get a URI that can be used in a To-Path header.  The client can
   authenticate its first relay by looking at the relay's TLS
   certificate.  The client MUST authenticate itself to each of its
   relays using HTTP Digest authentication [1] (see Section 9.1 for
   details).

クライアントを構成できる、(通常と、通じて、発見か手動の食糧を供給すること) 彼らが使用する必要があるリレーのリストで。 彼らは、最初のリレーに接続を形成して、To-経路ヘッダーで使用できるURIを得るAUTHコマンドを送ることができなければなりません。 クライアントは、リレーのTLS証明書を見ることによって、最初のリレーを認証できます。 HTTP Digest認証[1]を使用して、クライアントはそれぞれのリレーにそれ自体を認証しなければなりません(詳細に関してセクション9.1を見てください)。

   The relay returns a URI, or list of URIs, in the "Use-Path" header of
   a success response.  Each URI SHOULD be used for only one unique
   session.  These URIs are used by the client in the path attribute
   that is sent in the SDP to set up the session, and in the To-Path
   header of outgoing requests.  To form the To-Path header for outgoing
   requests, the client takes the list of URIs in the Use-Path header
   after the outermost authentication and appends the list of URIs
   provided in the path attribute in the peer's session description.  To
   form the SDP path attribute to provide to the peer, the client
   reverses the list of URIs in the Use-Path header (after the outermost
   authentication), and appends the client's own URI.

リレーがURI、またはURI、コネのリストを返す、「経路を使用する、」 ヘッダー、成功応答について。 各URI SHOULD、1つのユニークなセッションだけには、使用されてください。 これらのURIはセッションをセットアップするためにSDPで送られる経路属性、および送信する要求のTo-経路ヘッダーのクライアントによって使用されます。 クライアントは、送信する要求のためのTo-経路ヘッダーを形成するために、一番はずれの認証の後にUse-経路ヘッダーでURIのリストを取って、同輩のセッション記述で経路属性に提供されたURIのリストを追加します。 クライアントは、同輩に提供するためにSDP経路属性を形成するために、Use-経路ヘッダー(一番はずれの認証の後の)でURIのリストを逆にして、クライアントの自己のURIを追加します。

      For example, "A" has to traverse its own relays "B" and "C", and
      then relays "D" and "E" in domain2 to reach "F".  Client "A" will
      authenticate with its relays "B" and "C" and eventually receive a
      Use-Path header containing "B C".  Client "A" reverses the list

例えば、「A」は、それ自身のリレー「B」と「C」を横断しなければならなくて、次に、「F」に達するようにdomain2で「D」と「E」をリレーします。 クライアントウィルは、リレーで「B」と「C」を認証して、結局、「B C」を含む経路を使用しているヘッダーを受け取ります。 クライアント「A」はリストを逆にします。

Jennings, et al.            Standards Track                    [Page 13]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[13ページ]

      (now "C B") and appends its own URI (now "C B A"), and provides
      this list to "F" in a path SDP attribute.  Client "F" sends its
      SDP path list "D E F", which client "A" appends to the Use-Path
      list it received "B C".  The resulting To-Path header is "B C D E
      F".

そして、(現在の「C B」)、それ自身のURI(現在の「C B A」)を追加して、経路SDP属性で「F」にこのリストを提供します。 クライアント「F」はクライアント「A」がそれが受け取った経路を使用しているリストに追加する「D E F」というSDP経路リストに「B C」を送ります。 結果として起こるTo-経路ヘッダーは「B C D E F」です。

     domain 1                    domain 2
   ----------------          -----------------

1つのドメインドメイン2---------------- -----------------

   client    relays          relays     client
     A ----- B -- C -------- D -- E ----- F

クライアントリレーはクライアントAをリレーします。----- B--C-------- D--E----- F

   Use-Path returned by C:           B C
   path: attribute generated by A:   C B A
   path: attribute received from F:  D E F
   To-Path header generated by A:    B C D E F

経路を使用する、Cで戻ります: B C経路: A:で発生する属性 C B A経路: Fから受け取られた属性: 経路へのA:で発生するD E Fヘッダー B C D E F

   The initial AUTH request sent to a relay by a client will generally
   not contain an Authorization header, since the client has no
   challenge to which it can respond.  In response to an AUTH request
   that does not contain an Authorization header, a relay MUST respond
   with a "401 Unauthorized" response containing a WWW-Authenticate
   header.  The WWW-Authenticate header is formed as described in RFC
   2617 [1], with the restrictions and modifications described in
   Section 9.1.  The realm chosen by the MSRP relay in such a challenge
   is a matter of administrative policy.  Because a single relay does
   not have multiple protection spaces in MSRP, it is not unreasonable
   to always use the relay's hostname as the realm.

一般に、クライアントによってリレーに送られた初期のAUTH要求はAuthorizationヘッダーを含まないでしょう、クライアントにはそれが応じることができる挑戦が全くないので。 Authorizationヘッダーを含まないAUTH要求に対応してリレーがaで応じなければならない、「401、権限のなさ、」 応答、含んでいて、aはヘッダーをWWW認証します。 ヘッダーをWWW認証してください、制限と変更がセクション9.1で説明されている状態でRFC2617[1]で説明されるように、形成されます。 そのような挑戦におけるMSRPリレーで選ばれた分野は施政方針の問題です。 ただ一つのリレーがMSRPに多重防護空間を持っていないので、分野としていつもリレーのホスト名を使用するのは無理ではありません。

   Upon receiving a 401 response to a request, the client SHOULD fetch
   the realm from the WWW-Authenticate header in the response and retry
   the request, including an Authorization header with the correct
   credentials for the realm.  The Authorization header is formed as
   described in RFC 2617 [1], with the restrictions and modifications
   described in Section 9.1.

要求、SHOULDが分野をとって来るクライアントへの401応答を受ける、ヘッダーをWWW認証してください、応答と再試行における分野に、正しい信任状でAuthorizationヘッダーを含む要求 Authorizationヘッダーは制限と変更がセクション9.1で説明されている状態でRFC2617[1]で説明されるように形成されます。

   When a client wishes to use more than one relay, it MUST send an AUTH
   request to each relay it wishes to use.  Consider a client A, that
   wishes messages to flow from A to the first relay, R1, then on to a
   second relay, R2.  This client will do a normal AUTH with R1.  It
   will then do an AUTH transaction with R2 that is routed through R1.
   The client will form this AUTH message by setting the To-Path to
   msrps://R1;tcp msrps://R2;tcp.  R1 will forward this request onward
   to R2.

クライアントが1個以上のリレーを使用したがっているとき、それは使用したがっている各リレーにAUTH要求を送らなければなりません。 クライアントAを考えてください、とそれはAから最初のリレーまで流れるメッセージを願っています、R1、そして、2番目のリレーに、R2。 このクライアントはR1と共に正常なAUTHをするでしょう。 そして、それはR1を通して発送されるR2とのAUTH取引をするでしょう。 クライアントは、msrps://R1; tcp msrps://R2; tcpにTo-経路を設定することによって、このAUTHメッセージを形成するでしょう。 R1はこの要求をR2に前方へ転送するでしょう。

   When sending an AUTH request, the client MAY add an Expires header to
   request a MSRP URI that is valid for no longer than the provided
   interval (a whole number of seconds).  The server will include an

AUTH要求を送るとき、クライアントは、もうように有効なMSRP URIを要求するために提供された間隔(秒の整数)よりExpiresヘッダーを加えるかもしれません。 サーバは含むでしょう。

Jennings, et al.            Standards Track                    [Page 14]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[14ページ]

   Expires header in a successful response indicating how long its URI
   from the Use-Path will be valid.  Note that each server can return an
   independent expiration time.

有効であることをUse-経路からのURIがどれくらい長い間なるか示すうまくいっている応答でヘッダーを吐き出します。 各サーバが独立している満了時間を返すことができることに注意してください。

   Note that MSRP does not permit line folding.  A "\" in the examples
   shows a line continuation due to limitations in line length of this
   document.  Neither the backslash nor the extra CRLF is included in
   the actual request or response.

MSRPが線の折り重なりを可能にしないことに注意してください。 例の「\」はこのドキュメントの行長における制限による線継続を示しています。 バックスラッシュも余分なCRLFも実際の要求か応答に含まれていません。

   (Alice opens a TLS connection to intra.example.com and sends an AUTH
   request to initiate the authentication process.)

(アリスは、TLS接続をintra.example.comに開いて、認証過程を開始するというAUTH要求を送ります。)

    MSRP 49fh AUTH
    To-Path: msrps://alice@intra.example.com;tcp
    From-Path: msrps://alice.example.com:9892/98cjs;tcp
    -------49fh$

MSRP 49fh AUTH、経路: msrps: //alice@intra.example.com;tcp From-経路: msrps://alice.example.com: 9892/98cjs; tcp-------49fh$

   (Alice's relay challenges the AUTH request.)

(アリスのリレーはAUTH要求に挑戦します。)

    MSRP 49fh 401 Unauthorized
    To-Path: msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://alice@intra.example.com;tcp
    WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \
                      nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
    -------49fh$

経路に権限のないMSRP 49fh401: msrps://alice.example.com: 9892/98cjs; tcp From-経路、: msrps: //alice@intra.example.com;tcp は以下をWWW認証します。 ダイジェスト分野="intra.example.com"、qop="auth"\一回だけ="dcd98b7102dd2f0e8b11d0f600bfb0c093""-------49fh$

   (Alice responds to the challenge.)

(アリスは挑戦に応じます。)

    MSRP 49fi AUTH
    To-Path: msrps://alice@intra.example.com;tcp
    From-Path: msrps://alice.example.com:9892/98cjs;tcp
    Authorization: Digest username="Alice",
                   realm="intra.example.com", \
                   nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
                   qop=auth, nc=00000001, cnonce="0a4f113b", \
                   response="6629fae49393a05397450978507c4ef1"
    -------49fi$

MSRP 49fi AUTH、経路: msrps: //alice@intra.example.com;tcp From-経路: msrps://alice.example.com: 9892/98cjs; tcp Authorization、: ユーザ名=「アリス」、分野="intra.example.com"\一回だけ=を読みこなしてください、「dcd98b7102dd2f0e8b11d0f600bfb0c093"、\qop=auth、nc=00000001、cnonce="0a4f113b"\応答="6629fae49393a05397450978507c4ef1""-------49fi$

   (Alice's relay confirms that Alice is an authorized user.  As a
   matter of local policy, it includes an "Authentication-Info" header
   with a new nonce value to expedite future AUTH requests.)

(アリスのリレーは、アリスが認定ユーザであると確認します。 ローカルの方針の問題として、それは、今後のAUTH要求を速めるために新しい一回だけの値で「認証インフォメーション」ヘッダーを含んでいます。)

Jennings, et al.            Standards Track                    [Page 15]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[15ページ]

    MSRP 49fi 200 OK
    To-Path: msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://alice@intra.example.com;tcp
    Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp
    Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\
                         rspauth="7327570c586207eca2afae94fc20903d", \
                         cnonce="0a4f113b", nc=00000001, qop=auth
    Expires: 900
    -------49fi$

MSRP 49fi200は経路に以下を承認します。 msrps://alice.example.com: 9892/98cjs; tcp From-経路、: msrps: //alice@intra.example.com;tcp Use-経路: msrps://intra.example.com: 9000/jui787s2f; tcp Authentication-インフォメーション、: nextnonce="40f2e879449675f288476d772627370a"、\rspauth="7327570c586207eca2afae94fc20903d"\cnonceは"0a4f113b"、nc=00000001、qop=auth Expiresと等しいです: 900 -------49fi$

   (Alice now sends an AUTH request to her "external" relay through her
   "internal" relay, using the URI she just obtained; the AUTH request
   is challenged.)

(アリスは現在彼女の「内部」のリレーで彼女の「外部」のリレーにAUTH要求を送ります、彼女がただ得たURIを使用して; AUTH要求は挑戦されます。)

    MSRP mnbvw AUTH
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
             msrps://extra.example.com;tcp
    From-Path: msrps://alice.example.com:9892/98cjs;tcp
    -------mnbvw$

MSRP mnbvw AUTH To-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://extra.example.com; tcp From-経路: msrps://alice.example.com: 9892/98cjs; tcp-------mnbvw$

    MSRP m2nbvw AUTH
    To-Path: msrps://extra.example.com;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
               msrps://alice.example.com:9892/98cjs;tcp
    -------m2nbvw$

MSRP m2nbvw AUTH To-経路: msrps://extra.example.com;、tcp From-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://alice.example.com: 9892/98cjs; tcp-------m2nbvw$

    MSRP m2nbvw 401 Unauthorized
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
             msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://extra.example.com;tcp
    WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
                      nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
    -------m2nbvw$

MSRP m2nbvw401Unauthorized To-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://alice.example.com: 9892/98cjs; tcp From-経路: msrps://extra.example.com; 以下をtcp WWW認証してください。 ダイジェスト分野="extra.example.com"、qop="auth"\一回だけ="Uumu8cAV38FGsEF31VLevIbNXj9HWO"-------m2nbvw$

    MSRP mnbvw 401 Unauthorized
    To-Path: msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
               msrps://extra.example.com;tcp
    WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
                      nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
    -------mnbvw$

MSRP mnbvw401Unauthorized To-経路: msrps://alice.example.com: 9892/98cjs; tcp From-経路、: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://extra.example.com; 以下をtcp WWW認証してください。 ダイジェスト分野="extra.example.com"、qop="auth"\一回だけ="Uumu8cAV38FGsEF31VLevIbNXj9HWO"-------mnbvw$

   (Alice replies to the challenge with her credentials and is then
   authorized to use the "external" relay).

(アリスが彼女の信任状で挑戦に答えて、「外部」を使用するのが認可されたその時がリレーである、)

Jennings, et al.            Standards Track                    [Page 16]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[16ページ]

    MSRP m3nbvx AUTH
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
             msrps://extra.example.com;tcp
    From-Path: msrps://alice.example.com:9892/98cjs;tcp
    Authorization: Digest username="Alice",
                   realm="extra.example.com", \
                   nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
                   qop=auth, nc=00000001, cnonce="85a0dca8", \
                   response="cb06c4a77cd90918cd7914432032e0e6"
    -------m3nbvx$

MSRP m3nbvx AUTH To-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://extra.example.com; tcp From-経路: msrps://alice.example.com: 9892/98cjs; tcp Authorization、: 「アリス」、分野="extra.example.com"、\一回だけ="Uumu8cAV38FGsEF31VLevIbNXj9HWO"というユーザ名=\qop=auth、nc=00000001、cnonce=を読みこなしてください、「85a0dca8"、\応答="cb06c4a77cd90918cd7914432032e0e6""-------m3nbvx$

    MSRP m4nbvx AUTH
    To-Path: msrps://extra.example.com;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
               msrps://alice.example.com:9892/98cjs;tcp
    Authorization: Digest username="Alice",
                   realm="extra.example.com", \
                   nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
                   qop=auth, nc=00000001, cnonce="85a0dca8", \
                   response="cb06c4a77cd90918cd7914432032e0e6"
    -------m4nbvx$

MSRP m4nbvx AUTH To-経路: msrps://extra.example.com;、tcp From-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://alice.example.com: 9892/98cjs; tcp Authorization: 「アリス」、分野="extra.example.com"、\一回だけ="Uumu8cAV38FGsEF31VLevIbNXj9HWO"というユーザ名=\qop=auth、nc=00000001、cnonce=を読みこなしてください、「85a0dca8"、\応答="cb06c4a77cd90918cd7914432032e0e6""-------m4nbvx$

    MSRP m4nbvx 200 OK
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
             msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://extra.example.com;tcp
    Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
              msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
                         rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
                         cnonce="85a0dca8", nc=00000001, qop=auth
    Expires: 1800
    -------m4nbvx$

MSRP m4nbvx200OK To-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://alice.example.com: 9892/98cjs; tcp From-経路: msrps://extra.example.com;、tcp Use-経路: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://extra.example.com: 9000/mywdEe1233; tcp Authentication-インフォメーション: \rspauthが、nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc"を等しい、「72f109ed2755d7ed0d0a213ec653b3f2"、\cnonce=、「85a0dca8"、nc=00000001、qop=auth Expires:」 1800 -------m4nbvx$

    MSRP m3nbvx 200 OK
    To-Path: msrps://alice.example.com:9892/98cjs;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
               msrps://extra.example.com;tcp
    Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
              msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
                         rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
                         cnonce="85a0dca8", nc=00000001, qop=auth
    Expires: 1800
    -------m3nbvx$

MSRP m3nbvx200OK To-経路: msrps://alice.example.com: 9892/98cjs; tcp From-経路、: msrps://intra.example.com: 9000/jui787s2f; tcp\msrps://extra.example.com; tcp Use-経路: msrps://extra.example.com: 9000/mywdEe1233; tcp\msrps://extra.example.com: 9000/mywdEe1233; tcp認証インフォメーション: \rspauthが、nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc"を等しい、「72f109ed2755d7ed0d0a213ec653b3f2"、\cnonce=、「85a0dca8"、nc=00000001、qop=auth Expires:」 1800 -------m3nbvx$

Jennings, et al.            Standards Track                    [Page 17]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[17ページ]

5.2.  Sending Requests

5.2. 送付要求

   The procedure for forming SEND and REPORT requests is identical for
   clients whether or not relays are involved.  The specific procedures
   are described in Section 7 of the core MSRP protocol.

クライアントにとって、リレーがかかわるか否かに関係なく、SENDとREPORT要求を形成するための手順は同じです。 特定の手順はコアMSRPプロトコルのセクション7で説明されます。

   As usual, once the next-hop URI is determined, the client MUST find
   the appropriate address, port, and transport to use and then check if
   there is already a suitable existing connection to the next-hop
   target.  If so, the client MUST send the request over the most
   suitable connection.  Suitability MAY be determined by a variety of
   factors such as measured load and local policy, but in most simple
   implementations a connection will be suitable if it exists and is
   active.

いつものように、次のホップURIがいったん決定するようになると、次のホップ目標との適当な既存の接続が既にあれば、クライアントは使用して、次にチェックする適切なアドレス、ポート、および輸送を見つけなければなりません。 そうだとすれば、クライアントは最も適当な接続の上に要求を送らなければなりません。 適合は測定負荷やローカルの方針などのさまざまな要素で決定するかもしれませんが、ほとんどの簡単な実現では、それが存在していて、アクティブであるなら、接続は適当になるでしょう。

5.3.  Receiving Requests

5.3. 要求を受け取ります。

   The procedure for receiving requests is identical for clients whether
   or not relays are involved.

クライアントにとって、リレーがかかわるか否かに関係なく、要求を受け取るための手順は同じです。

5.4.  Managing Connections

5.4. コネクションズを管理します。

   Clients should open a connection whenever they wish to deliver a
   request and no suitable connection exists.  For connections to
   relays, the client should leave a connection up until no sessions
   have used it for a locally defined period of time, which defaults to
   5 minutes for foreign relays and one hour for the client's relays.

彼らが要求を提供したがっているときはいつも、クライアントは接続を開くべきです、そして、どんな適当な接続も存在していません。 リレーとの接続のために、どんなセッションも局所的に定義された期間(クライアントのリレーのために外国リレーと1時間5分をデフォルトとする)の間、それを使用しないまで、クライアントは接続を掲げるべきです。

6.  Relay Behavior

6. リレーの振舞い

6.1.  Handling Incoming Connections

6.1. 取り扱い接続要求

   When a relay receives an incoming connection on a port configured for
   TLS, it includes a client CertificateRequest in the same record in
   which it sends its ServerHello.  If the TLS client provides a
   certificate, the server verifies it and continues if the certificate
   is valid and rooted in a trusted authority.  If the TLS client does
   not provide a certificate, the server assumes that the client is an
   MSRP endpoint and invokes Digest authentication.  Once a TCP or TLS
   channel is negotiated, the server waits for up to 30 seconds to
   receive an MSRP request over the channel.  If no request is received
   in that time, the server closes the connection.  If no successful
   requests are sent during this probationary period, the server closes
   the connection.  Likewise, if several unsuccessful requests are sent
   during the probation period and no requests are sent successfully,
   the server SHOULD close the connection.

リレーがTLSのために構成されたポートの上で接続要求を受けるとき、それはそれがServerHelloを送るのと同じ記録にクライアントCertificateRequestを含んでいます。 TLSクライアントが証明書を提供するなら、証明書が信じられた権威で有効であって、根づいているなら、サーバは、それについて確かめて、続きます。 TLSクライアントが証明書を提供しないなら、サーバは、クライアントがMSRP終点であり、Digest認証を呼び出すと仮定します。 TCPかTLSチャンネルがいったん交渉されると、サーバは、30秒までMSRP要求をチャンネルの上に受け取るのを待っています。 その時要求を全く受け取らないなら、サーバは接続を終えます。 この試験期間、どんなうまくいっている要求も送らないなら、サーバは接続を終えます。 同様に、執行猶予の期間、いくつかの失敗の要求を送って、首尾よく要求は全く送らないなら、サーバSHOULDが接続を終えます。

Jennings, et al.            Standards Track                    [Page 18]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[18ページ]

6.2.  Generic Request Behavior

6.2. 一般的な要求の振舞い

   Upon receiving a new request, relays first verify the validity of the
   request.  Relays then examine the first URI in the To-Path header and
   remove this URI if it matches a URI corresponding to the relay.  If
   the request is not addressed to the relay, the relay immediately
   drops the corresponding connection over which the request was
   received.

新しい要求を受け取ると、リレーは最初に、要求の正当性について確かめます。 リレーは、次に、To-経路ヘッダーにおける最初のURIを調べて、リレーに対応するURIを合わせるなら、このURIを取り除きます。 要求がリレーに記述されないなら、リレーはすぐに、要求が受け取られた対応する接続を落とします。

6.3.  Receiving AUTH Requests

6.3. AUTH要求を受け取ります。

   When a relay receives an AUTH request, the first thing it does is to
   authenticate and authorize the previous hop and the client at the far
   end.  If there are no other relays between this relay and the client,
   then these are the same thing.

リレーがAUTH要求を受け取るとき、それがする最初のことは、遠端で前のホップとクライアントを認証して、権限を与えることです。 このリレーとクライアントの間には、他のリレーが全くなければ、これらは同じものです。

   When the previous hop is a relay, authentication is done with TLS
   using mutual authentication.  If the TLS client presented a host
   certificate, the relay checks that the subjectAltName in the
   certificate of the TLS client matches the hostname in the first From-
   Path URI.  If the TLS client doesn't provide a host certificate, the
   relay assumes the TLS client is an MSRP client and sends it a
   challenge.

前のホップがリレーであるときに、TLSが互いの認証を使用していて、認証します。 TLSクライアントがホスト証明書を提示したなら、リレーは、TLSクライアントの証明書のsubjectAltNameが最初Fromの経路URIにおけるホスト名に合っているのをチェックします。 TLSクライアントがホスト証明書を提供しないなら、リレーは、TLSクライアントがMSRPクライアントであると仮定して、挑戦をそれに送ります。

   Authorization is a matter of local policy at the relay.  Many relays
   will choose to authorize all relays that can be authenticated,
   possibly in conjunction with a blacklisting mechanism.  Relays
   intended to operate only within a limited federation may choose to
   authorize only those relays whose identity appears in a provisioned
   list.  Other authorization policies may also be applied.

認可はリレーのローカルの方針の問題です。 多くのリレーが、ことによるとブラックリストメカニズムに関連して認証できるすべてのリレーを認可するのを選ぶでしょう。 限られた連邦だけの中で作動することを意図するリレーは、アイデンティティが食糧を供給されたリストに現れるそれらのリレーだけを認可するのを選ぶかもしれません。 また、他の認可方針は適用されるかもしれません。

   When the previous hop is a client, the previous hop is the same as
   the identity of the client.  The relay checks the credentials
   (username and password) provided by the client in the Authorization
   header and checks if this client is allowed to use the relay.  If the
   client is not authorized, the relay returns a 403 response.  If the
   client has requested a particular expiration time in an Expires
   header, the relay needs to check that the time is acceptable to it
   and, if not, return an error containing a Min-Expires or Max-Expires
   header, as appropriate.

前のホップがクライアントであるときに、前のホップはクライアントのアイデンティティと同じです。 リレーは、Authorizationヘッダーというクライアントによって提供された信任状(ユーザ名とパスワード)をチェックして、このクライアントがリレーを使用できるかどうかチェックします。 クライアントが認可されていないなら、リレーは403応答を返します。 クライアントが特定の満了時間を要求したなら、aは、Expiresヘッダー、時間がそれに許容できるのをチェックしてそうでなければ誤り含有を返すリレーの必要性では、ヘッダーをMin吐き出すか、またはマックスと同じくらい吐き出します、適宜。

   Next the relay will generate an MSRP URI that allows messages to be
   forwarded to or from this previous hop.  If the previous hop was a
   relay authenticated by mutual TLS, then the URI MUST be valid to
   route across any connection the relay has to the previous hop relay.
   If the previous hop is a client, then the URI MUST only be valid to

次に、リレーはホップかこの前のホップから進められるべきメッセージを許容するMSRP URIを発生させるでしょう。 前のホップが互いのTLSによって認証されたリレーであったなら、URIは、リレーには前のホップリレーにはあるどんな接続の向こう側にも発送するために有効でなければなりません。 前のホップがクライアント、URIが有効であるだけであるに違いないその時なら

Jennings, et al.            Standards Track                    [Page 19]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[19ページ]

   route across the same connection over which the AUTH request was
   received.  If the client's connection is closed and then reopened,
   the URI MUST be invalidated.

AUTH要求が受け取られたのと同じ接続の向こう側に発送します。 クライアントの接続が閉店して、次に、再開するなら、URIを無効にしなければなりません。

   If the AUTH request contains an Expires header, the relay MUST ensure
   that the URI is invalidated after the expiry time.  The URI MUST
   contain at least 64 bits of cryptographically random material so that
   it is not guessable by attackers.  If a relay is requested to forward
   a message for which the URI is not valid, the relay MUST discard the
   message and MAY send a REPORT indicating that the AUTH URI was bad.

AUTH要求がExpiresヘッダーを含んでいるなら、リレーは、URIが満期時の後に無効にされるのを確実にしなければなりません。 それが無作為の物質的なそうですが、URIが暗号で少なくとも64ビットを含まなければならない、攻撃者で、推測可能です。 リレーがURIが有効でないメッセージを転送するよう要求されるなら、リレーで、メッセージを捨てなければならなくて、REPORTは、AUTH URIが悪かったのを示すかもしれません。

   A successful AUTH response returns a Use-Path header that contains an
   MSRP URI that the client can use.  It also returns an Expires header
   that indicates how long the URI will be valid (expressed as a whole
   number of seconds).

うまくいっているAUTH応答はクライアントが使用できるMSRP URIを含むUse-経路ヘッダーを返します。 また、それは有効であることをURIがどれくらい長い間なるか(秒の整数として、言い表されます)示すExpiresヘッダーを返します。

   If a relay receives several unsuccessful AUTH requests from a client
   that is directly connected to it via TLS, the relay SHOULD terminate
   the corresponding connection.  Similarly, if a relay forwards several
   failed AUTH requests to the same destination that originate from a
   client that is directly connected to it via TLS, the relay SHOULD
   terminate the corresponding connection.  Determination of a remote
   AUTH failure can be made by observing an AUTH request containing an
   Authorization header that triggers a 401 response without a
   "stale=TRUE" indication.  These preventive measures apply only to a
   connection between a relay and a client; a relay SHOULD NOT use
   excessive AUTH request failures as a reason to terminate a connection
   with another relay.

リレーがTLSを通していくつかの直接接されるクライアントからそれまでの失敗のAUTH要求を受け取るなら、リレーSHOULDは対応する接続を終えます。 同様に、リレーが同じ目的地へのTLSを通して直接接されるクライアントからそれまで由来するいくつかの失敗したAUTH要求を転送するなら、リレーSHOULDは対応する接続を終えます。 「= 本当に古くさくなってください」指示なしで401応答の引き金となるAuthorizationヘッダーを含むAUTH要求を観測することによって、リモートAUTHの故障の決断をすることができます。 これらの予防策はリレーとクライアントとの接続だけに適用されます。 リレーSHOULD NOTは別のリレーとの接続を終える理由として過度のAUTH要求の故障を使用します。

6.4.  Forwarding

6.4. 推進

   Before any request is forwarded, the relay MUST check that the first
   URI in the To-Path header corresponds to a URI that this relay has
   created and handed out in the Use-Path header of an AUTH request.
   Next it verifies that either 1) the next hop is the next hop back
   toward the client that obtained this URI, or 2) the previous hop was
   the correct previous hop coming from the client that obtained this
   URI.

どんな要求も転送する前に、リレーは、To-経路ヘッダーにおける最初のURIがこのリレーがAUTH要求のUse-経路ヘッダーで作成して、与えたURIに対応するのをチェックしなければなりません。 次に、それは、次が飛び越す1が)このURIを得たクライアントに向かった次のホップ後部であるか前が飛び越す2が)このURIを得たクライアントから来る前の正しいホップであったことを確かめます。

   Since transact-id values are not allowed to conflict on a given
   connection, a relay will generally need to construct a new transact-
   id value for any request that it forwards.

イドを商取引している値が闘争できないので、当然のことの接続、一般に、意志がそうしなければならないリレーのときに、新しい状態でaを組み立てるために、それが転送するあらゆる要求のためにイド値を商取引してください。

Jennings, et al.            Standards Track                    [Page 20]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[20ページ]

6.4.1.  Forwarding SEND Requests

6.4.1. 進めて、要求を送ってください。

   If an incoming SEND request contains a Failure-Report header with a
   value of "yes", an MSRP relay that receives that SEND request MUST
   respond with a final response immediately.  A 200-class response
   indicates the successful receipt of a message fragment but does not
   mean that the message has been forwarded on to the next hop.  The
   final response to the SEND MUST be sent only to the previous hop,
   which could be an MSRP relay or the original sender of the SEND
   request.

入って来るSEND要求が「はい」の値でFailure-レポートヘッダーを含んでいるなら、そのSEND要求を受け取るMSRPリレーはすぐに、最終的な応答で応じなければなりません。 200クラスの応答は、メッセージ断片のうまくいっている領収書を示しますが、メッセージが次のホップに転送されたことを意味しません。 SEND MUSTには、いてください。最終的な応答、前のホップかSEND要求の元の送り主だけに送ります。(ホップはMSRPリレーであるかもしれません)。

   If the Failure-Report header is "yes", then the relay MUST run a
   timer to detect if transmission to the next hop fails.  The timer
   starts when the last byte of the message has been sent to the next
   hop.  If after 30 seconds the next hop has not sent any response,
   then the relay MUST construct a REPORT with a status code of 408 to
   indicate a timeout error happened sending the message, and send the
   REPORT to the original sender of the message.

Failure-レポートヘッダーが「はい」であるなら、リレーは、次のホップへのトランスミッションが失敗するかどうか検出するためにタイマを動かさなければなりません。 メッセージの最後のバイトを次のホップに送ったとき、タイマは始動します。 次のホップが30秒以降少しの応答も送らないなら、リレーは、タイムアウト誤りがメッセージを送りながら起こったのを示して、メッセージの元の送り主にREPORTを送るために408のステータスコードでREPORTを組み立てなければなりません。

   If the Failure-Report header is "yes" or "partial", and if there is a
   problem processing the SEND request or if an error response is
   received for that SEND request, then the relay MUST respond with an
   appropriate error response in a REPORT back to the original source of
   the message.

Failure-レポートヘッダーが「はい」的か「部分的であり」、SENDが要求する問題処理があるか、またはそのSEND要求のために誤り応答を受けるなら、適切な誤り応答がREPORTにある状態で、リレーはメッセージの一次資料まで応じなければなりません。

   The MSRP relay MAY further break up the message fragment received in
   the SEND request into smaller fragments and forward them to the next
   hop in separate SEND requests.  It MAY also combine message fragments
   received before or after this SEND request, and forward them out in a
   single SEND request to the next hop identified in the To-Path header.
   The MSRP relay MUST NOT combine message fragments from SEND requests
   with different values in the Message-ID header.

MSRPリレーは、SEND要求により小さい断片に受け取られたメッセージ断片をさらに壊れさせて、別々のSEND要求における次のホップにそれらを送るかもしれません。 それは、また、このSEND要求の前または後に受け取られたメッセージ断片を結合して、ただ一つのSEND要求でTo-経路ヘッダーで特定された次のホップにそれらを送るかもしれません。 MSRPリレーはMessage-IDヘッダーでメッセージ断片をSEND要求から異価に結合してはいけません。

   The MSRP relay MAY choose whether to further fragment the message, or
   combine message fragments, or send the message as is, based on some
   policy that is administered, or based on the network speed to the
   next hop, or any other mechanism.

MSRPリレーは、さらにメッセージを断片化するか、メッセージ断片を結合する、またはそのままでメッセージを送るかを選ぶかもしれません、管理されるか、または次のホップへのネットワーク速度に基づいている、何らかの方針、またはいかなる他のメカニズムに基づいて。

   If the MSRP relay has knowledge of the byte range that it will
   transmit to the next hop, it SHOULD update the Byte-Range header in
   the SEND request appropriately.

MSRPリレーにバイト範囲に関する知識があるなら、次のホップに伝わって、SHOULDであることはSEND要求で適切にByte-範囲ヘッダーをアップデートします。

   Before forwarding the SEND request to the next hop, the MSRP relay
   MUST inspect the first URI in the To-Path header.  If it indicates
   this relay, the relay removes this URI from the To-Path header and
   inserts this URI in the From-Path header before any other URIs.  If
   it does not indicate this relay, there has been an error in

SEND要求を次のホップに転送する前に、MSRPリレーはTo-経路ヘッダーにおける最初のURIを点検しなければなりません。 このリレーを示すなら、リレーは、To-経路ヘッダーからこのURIを移して、いかなる他のURIの前にもFrom-経路ヘッダーにこのURIを挿入します。 このリレーを示さないなら、中に誤りがありました。

Jennings, et al.            Standards Track                    [Page 21]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[21ページ]

   forwarding at a previous hop.  In this case, the relay SHOULD discard
   the message, and if the Failure-Report header is set to "yes", the
   relay SHOULD generate a failure report.

前のホップでは、進めます。 この場合、リレーSHOULDはメッセージを捨てます、そして、Failure-レポートヘッダーが「はい」に用意ができているなら、リレーSHOULDは異常報告書を作ります。

6.4.2.  Forwarding Non-SEND Requests

6.4.2. 推進、非、発信、要求

   An MSRP relay that receives any request other than a SEND request
   (including new methods unknown to the relay) first follows the
   validation and authorization rules for all requests.  Then the relay
   moves its URI from the beginning of the To-Path headers to the
   beginning of the From-Path header and forwards the request on to the
   next hop.  If it already has a connection to the next hop, it SHOULD
   use this connection and not form a new connection.  If no suitable
   connection exists, the relay opens a new connection.

最初にSEND要求(リレーにおける、未知の新しい方法を含んでいる)以外のどんな要求も受け取るMSRPリレーはすべての要求のための合法化と認可規則に従います。 次に、リレーは、To-経路ヘッダーの始まりからFrom-経路ヘッダーの始まりまでURIを動かして、次のホップに要求を転送します。 次のホップには接続が既にあります、それ。SHOULDはこの接続を使用して、新しい接続を形成しません。 どんな適当な接続も存在していないなら、リレーは新しい接続を開きます。

   Requests with an unknown method are forwarded as if they were REPORT
   requests.  An MSRP node MAY be configured to block unknown methods
   for security reasons.

まるでそれらがREPORT要求であるかのように未知の方法がある要求を転送します。 MSRPノードは、安全保障上の理由で未知の方法を妨げるために構成されるかもしれません。

6.4.3.  Handling Responses

6.4.3. 取り扱い応答

   Relays receiving a response first verify that the first URI in the
   To-Path corresponds to itself; if not, the response SHOULD be
   dropped.  Likewise, if the message cannot be parsed, the relay MUST
   drop the response.  Next the relay determines if there are additional
   URIs in the To-Path.  (For responses to SEND requests there will be
   no additional URIs, whereas responses to AUTH requests have
   additional URIs directing the response back to the client.)

最初に応答を受けるリレーは、To-経路における最初のURIがそれ自体に対応することを確かめます。 そうでなければ、応答SHOULD、落とされてください。 同様に、メッセージを分析できないなら、リレーは応答を落とさなければなりません。 次に、リレーは、追加URIがTo-経路にあるかを決定します。 (SEND要求への応答のために、どんな追加URIもないでしょうが、AUTH要求への応答は応答を指示する追加URIをクライアントに返してもらいます。)

   If the response matches an existing transaction, then that
   transaction is completed and any timers running on it can be removed.
   If the response is a non 200 response, and the original request was a
   SEND request that had a Failure-Report header with a value other than
   "no", then the relay MUST send a REPORT indicating the nature of the
   failure.  The response code received by the relay is used to form the
   status line in the REPORT that the relay sends.

応答が既存の取引に合っているなら、その取引を完了します、そして、それで走るどんなタイマも取り外すことができます。 応答が非200応答であり、オリジナルの要求がFailure-レポートヘッダーが「いいえ」を除いた値と共にあったSEND要求であったなら、リレーで、REPORTは失敗の本質を示さなければなりません。 リレーで受け取られた応答コードは、リレーが送るREPORTの状況表示行を形成するのに使用されます。

   If there are additional URIs in the To-Path header, the relay MUST
   then move its URI from the To-Path header, insert its URI in front of
   any other URIs in the From-Path header, and forward the response to
   the next URI in the To-Path header.  The relay sends the request over
   the best connection that corresponds to the next URI in the To-Path
   header.  If this connection has closed, then the response is silently
   discarded.

追加URIがTo-経路ヘッダーにあれば、リレーは、次に、To-経路ヘッダーからURIを動かして、いかなる他のURIの正面でもFrom-経路ヘッダーにURIを挿入して、To-経路ヘッダーで次のURIへの応答を送らなければなりません。 リレーはTo-経路ヘッダーで次のURIに文通する最も良い接続の上に要求を送ります。 この接続が閉じたなら、応答は静かに捨てられます。

Jennings, et al.            Standards Track                    [Page 22]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[22ページ]

6.5.  Managing Connections

6.5. コネクションズを管理します。

   Relays should keep connections open as long as possible.  If a
   connection has not been used in a significant time (more than one
   hour), it MAY be closed.  If the relay runs out of resources and can
   no longer establish new connections, it SHOULD start closing existing
   connections.  It MAY choose to close the connections based on a least
   recently used basis.

リレーはできるだけ長い間、接続を開くように保つはずです。 接続が重要な時間(1時間以上)使用されていないなら、それは閉じられるかもしれません。 リレーは、リソースを使い果たして、もう新しい接続を確立できないで、それは既存の接続を終えるSHOULD始めです。 それは、最も最近でない中古の基礎に基づく接続を終えるのを選ぶかもしれません。

7.  Formal Syntax

7. 正式な構文

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) as described in RFC 4234 [10].

以下の構文仕様はRFC4234[10]で説明されるようにAugmented BN記法(ABNF)を使用します。

   ; This ABNF imports all the definitions in the ABNF of RFC 4975.

; このABNFはRFC4975のABNFとのすべての定義を輸入します。

   header =/  Expires / Min-Expires / Max-Expires / Use-Path /
              WWW-Authenticate / Authorization / Authentication-Info
              ; this adds to the rule in RFC 4975

ヘッダー=/は、/を吐き出すか、分吐き出す、またはマックスと同じくらい吐き出します。経路を使用している/は/認証認可/インフォメーションをWWW認証します。 これはRFC4975の規則に加えます。

   mAUTH               = %x41.55.54.48           ; AUTH in caps
   method              =/ mAUTH
                         ; this adds to the rule in RFC 4975

mAUTH=%x41.55.54.48。 キャップ方法によるAUTHは/mAUTHと等しいです。 これはRFC4975の規則に加えます。

   WWW-Authenticate    = "WWW-Authenticate:" SP "Digest" SP digest-param
                         *("," SP digest-param)

WWW認証、= 「以下をWWW認証してください」 SP「ダイジェスト」SPダイジェスト-param*(「」、SPダイジェスト-param)

   digest-param        = ( realm / nonce / [ opaque ] / [ stale ] / [
                         algorithm ] / qop-options  / [auth-param] )

ダイジェスト-param=(分野/一回だけ/[不透明な]/[聞き古した]/qop[アルゴリズム]/オプション/[auth-param])

   realm               = "realm=" realm-value
   realm-value         = quoted-string

分野=「分野=」分野価値の分野価値は引用文字列と等しいです。

   auth-param          = token "=" ( token / quoted-string )

auth-paramは象徴「=」と等しいです。(象徴/引用文字列)

   nonce               = "nonce=" nonce-value
   nonce-value         = quoted-string
   opaque              = "opaque=" quoted-string
   stale               = "stale=" ( "true" / "false" )
   algorithm           = "algorithm=" ( "MD5" / token )
   qop-options         = "qop=" DQUOTE qop-list DQUOTE
   qop-list            = qop-value *( "," qop-value )
   qop-value           = "auth" / token

一回だけ..一回だけ..一回だけ..値..一回だけ..値..等しい..引用文字列..不透明なもの..不透明なもの..引用文字列..聞き古した..聞き古した..本当..誤る..アルゴリズム..アルゴリズム..象徴..オプション..等しい..リスト..リスト..値..値..値..等しい..象徴

   Authorization       = "Authorization:" SP credentials

認可が等しい、「認可:」 SP信任状

   credentials         = "Digest" SP digest-response
                         *( "," SP digest-response)

信任状は「ダイジェスト」SPダイジェスト応答*と等しいです。(「」、SPダイジェスト応答)

Jennings, et al.            Standards Track                    [Page 23]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[23ページ]

   digest-response     = ( username / realm / nonce / response / [
                         algorithm ] / cnonce / [opaque] / message-qop /
                         [nonce-count]  / [auth-param] )

ダイジェスト応答=(ユーザ名/分野/一回だけ/応答/[アルゴリズム]/ cnonce /メッセージ[不透明なもの]/qop/[一回だけのカウント]の/[auth-param])

   username            = "username=" username-value
   username-value      = quoted-string
   message-qop         = "qop=" qop-value
   cnonce              = "cnonce=" cnonce-value
   cnonce-value        = nonce-value
   nonce-count         = "nc=" nc-value
   nc-value            = 8LHEX
   response            = "response=" request-digest
   request-digest      = DQUOTE 32LHEX DQUOTE
   LHEX                = DIGIT / %x61-66 ;lowercase a-f

一回だけの値の一回だけの引用文字列メッセージ-qop=「qop=」qop-値のユーザ名=「ユーザ名=」ユーザ名価値のユーザ名価値=cnonce=「cnonce=」cnonce-値のcnonce-価値=カウントはDIGIT/%「応答=」要求ダイジェスト要求8LHEX「nc=」nc-値のnc-価値=応答=ダイジェスト=DQUOTE 32LHEX DQUOTE LHEX=x61-66と等しいです; 1fで、小文字で印刷してください。

   Authentication-Info =  "Authentication-Info:" SP ainfo
                          *("," ainfo)
   ainfo               =  nextnonce / message-qop
                           / response-auth / cnonce
                           / nonce-count
   nextnonce           =  "nextnonce=" nonce-value
   response-auth       =  "rspauth=" response-digest
   response-digest     =  DQUOTE *LHEX DQUOTE

認証インフォメーションが等しい、「認証インフォメーション:」 SP ainfo*、(「」、ainfo) ainfo=一回だけの応答-auth/cnonce/カウントnextnonce=メッセージ-qop/「nextnonce=」一回だけの値の応答-auth=「rspauth=」応答ダイジェスト応答nextnonce/ダイジェスト=DQUOTE*LHEX DQUOTE

   Expires     = "Expires:" SP 1*DIGIT
   Min-Expires = "Min-Expires:" SP 1*DIGIT
   Max-Expires = "Max-Expires:" SP 1*DIGIT

期限が切れる、=は「以下を吐き出します」。 SP1*ケタは分期限が切れます。=は「以下を分吐き出します」。 SP1*ケタはマックスと同じくらい期限が切れます。=は「以下をマックスと同じくらい吐き出します」。 SP1*ケタ

   Use-Path = "Use-Path:" SP MSRP-URI *(SP MSRP-URI)

経路を使用している=、「経路を使用する、:、」 SP MSRP-URI*(SP MSRP-ユリ)

8.  Finding MSRP Relays

8. MSRPにリレーを見つけます。

   When resolving an MSRP URI that contains an explicit port number, an
   MSRP node follows the rules in Section 6 of the MSRP base
   specification.  MSRP URIs exchanged in SDP and in To-Path and From-
   Path headers in non-AUTH requests MUST have an explicit port number.
   (The only message in this specification that can have an MSRP URI
   without an explicit port number is in the To-Path header in an AUTH
   request.)  Similarly, if the authority component of an msrps: URI
   contains an IPv4 address or an IPv6 reference, a port number MUST be
   present.

明白なポートナンバーを含むMSRP URIを決議するとき、MSRPノードはMSRP基礎仕様のセクション6で約束を守ります。 SDPと非AUTH要求におけるTo-経路とFrom経路ヘッダーで交換されたMSRP URIは明白なポートナンバーを持たなければなりません。 (この仕様に基づく明白なポートナンバーなしでMSRP URIを持つことができる唯一のメッセージがAUTH要求におけるTo-経路ヘッダーにあります。) 同様である、msrpsの権威の部品であるなら: URIはIPv4アドレスかIPv6参照を含んでいて、ポートナンバーは存在していなければなりません。

   The following rules allow MSRP clients to discover MSRP relays more
   easily in AUTH requests.  If the authority component contains a
   domain name and an explicit port number is provided, attempt to look
   up a valid address record (A or AAAA) for the domain name.  Connect
   using TLS over the default transport (TCP) with the provided port
   number.

以下の規則はAUTH要求でMSRPリレーで、より容易に発見するクライアントをMSRPに許容します。 権威コンポーネントがドメイン名を含んでいて、明白なポートナンバーを提供するなら、ドメイン名のための有効なアドレス記録(AかAAAA)を調べるのを試みてください。 デフォルト輸送(TCP)の上で提供されたポートナンバーでTLSを使用して、接続してください。

Jennings, et al.            Standards Track                    [Page 24]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[24ページ]

   If a domain name is provided but no port number, perform a DNS SRV
   [4] lookup for the '_msrps' service and '_tcp' transport at the
   domain name, and follow the Service Record (SRV) selection algorithm
   defined in that specification to select the entry.  (An '_msrp'
   service is not defined, since AUTH requests are only sent over TLS.)
   If no SRVs are found, try an address lookup (A or AAAA) for the
   domain name.  Connect using TLS over the default transport (TCP) with
   the default port number (2855).  Note that AUTH requests MUST only be
   sent over a TLS-protected channel.  An SRV lookup in the example.com
   domain might return:

'ドメイン名を提供しますが、いいえなら、数を移植してください、そして、'_msrps'サービスと'_tcp'輸送のためにドメイン名でDNS SRV[4]ルックアップを実行してください、そして、エントリーを選択するためにその仕様に基づき定義されたService Record(SRV)選択アルゴリズムに従ってください。 '('_msrp'サービスはAUTH要求をTLSの上に送るだけであるので、定義されません。) SRVsが全く見つけられないなら、ドメイン名のために、アドレスルックアップ(AかAAAA)を試みてください。 デフォルト輸送(TCP)の上でデフォルトポートナンバー(2855)でTLSを使用して、接続してください。 TLSによって保護されたチャンネルの上にAUTH要求を送るだけでよいことに注意してください。 example.comドメインのSRVルックアップは戻るかもしれません:

   ;; in example.com.      Pri Wght Port Target
   _msrps._tcp   IN SRV    0   1    9000 server1.example.com.
   _msrps._tcp   IN SRV    0   2    9000 server2.example.com.

;; example.comで。 Pri Wght Port Target_msrps_tcp IN SRV0 1 9000server1.example.com。 _msrps_tcp IN SRV0 2 9000server2.example.com。

   If implementing a relay farm, it is RECOMMENDED that each member of
   the relay farm have an SRV entry.  If any members of the farm have
   multiple IP addresses (for example, an IPv4 and an IPv6 address),
   each of these addresses SHOULD be registered in DNS as separate A or
   AAAA records corresponding to a single target.

リレー農場を実行するなら、リレー農場の各メンバーにはSRVエントリーがあるのは、RECOMMENDEDです。 農場のどんなメンバーにも複数のIPアドレス(例えば、IPv4とIPv6アドレス)があるなら、登録されていて、別々のAかAAAAがただ一つの目標に対応しながら記録するようにそれぞれのこれらはDNSにSHOULDを記述します。

9.  Security Considerations

9. セキュリティ問題

   This section first describes the security mechanisms available for
   use in MSRP.  Then the threat model is presented.  Finally, we list
   implementation requirements related to security.

このセクションは最初に、MSRPにおける使用に利用可能なセキュリティー対策について説明します。 そして、脅威モデルは提示されます。 最終的に、私たちはセキュリティに関連する実現要件をリストアップします。

9.1.  Using HTTP Authentication

9.1. HTTP認証を使用します。

   AUTH requests MUST be authenticated.  The authentication mechanism
   described in this specification uses HTTP Digest authentication.
   HTTP Digest authentication is performed as described in RFC 2617 [1],
   with the following restrictions and modifications:

AUTH要求を認証しなければなりません。 この仕様で説明された認証機構はHTTP Digest認証を使用します。 HTTP Digest認証はRFC2617[1]で以下の制限と変更で説明されるように実行されます:

   o  Clients MUST NOT attempt to use Basic authentication, and relays
      MUST NOT request or accept Basic authentication.

o クライアントが、Basic認証を使用するのを試みてはいけなくて、リレーは、Basic認証を要求してはいけませんし、また受け入れてはいけません。

   o  The use of a qop value of auth-int makes no sense for MSRP.
      Integrity protection is provided by the use of TLS.  Consequently,
      MSRP relays MUST NOT indicate a qop of auth-int in a challenge.

o auth-intのqop価値の使用はMSRPのために意味をなさないです。 TLSの使用で保全保護を提供します。 その結果、MSRPリレーは挑戦でauth-intのqopを示してはいけません。

   o  The interaction between the MD5-sess algorithm and the nextnonce
      mechanism is underspecified in RFC 2617 [1]; consequently, MSRP
      relays MUST NOT send challenges indicating the MD5-sess algorithm.

o MD5-sessアルゴリズムとnextnonceメカニズムとの相互作用はRFC2617[1]でunderspecifiedされます。 その結果、MSRPリレーで、挑戦はMD5-sessアルゴリズムを示してはいけません。

   o  Clients SHOULD consider the protection space within a realm to be
      scoped to the authority portion of the URI, without regard to the
      contents of the path portion of the URI.  Accordingly, relays

o クライアントSHOULDは、分野の中の保護スペースがURIの権威部分まで見られると考えます、URIの経路部分のコンテンツへの尊敬なしで。 それに従って、リレー

Jennings, et al.            Standards Track                    [Page 25]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[25ページ]

      SHOULD NOT send the "domain" parameter on the "WWW-Authenticate"
      header, and clients MUST ignore it if present.

SHOULD NOTが「ドメイン」パラメタを送る、ヘッダーを「WWW認証する」、存在しているなら、クライアントはそれを無視しなければなりません。

   o  Clients and relays MUST include a qop parameter in all "WWW-
      Authenticate" and "Authorization" headers.  Note that the value of
      the qop parameter in a "WWW-Authenticate" header is quoted, but
      the value of the qop parameter in an "Authorization" header or
      "Authentication-Info" header is not quoted.

o クライアントとリレーは「WWWは認証する」すべてと「認可」ヘッダーでqopパラメタを入れなければなりません。 それに注意してください、値、中のqopパラメタでは、aがヘッダーを「WWW認証する」、引用されていて、「認可」ヘッダーか「認証インフォメーション」ヘッダーのqopパラメタの値だけが引用されません。

   o  Clients MUST send cnonce and nonce-count parameters in all
      "Authorization" headers.

o クライアントはすべての「認可」ヘッダーでcnonceと一回だけのカウントパラメタを送らなければなりません。

   o  The request-URI to be used in calculating H(A2) is the rightmost
      URI in the To-Path header.

o 計算のH(A2)で使用されるべき要求URIはTo-経路ヘッダーの一番右のURIです。

   o  Relays MUST include rspauth, cnonce, nc, and qop parameters in a
      "Authentication-Info" header for all "200 OK" responses to an AUTH
      request.

o リレーはAUTH要求へのすべての「200OK」応答のための「認証インフォメーション」ヘッダーにrspauth、cnonce、nc、およびqopパラメタを含まなければなりません。

   Note that the BNF in RFC 2617 has a number of errors.  In particular,
   the value of the uri parameter MUST be in quotes; further, the
   parameters in the Authentication-Info header MUST be separated by
   commas.  The BNF in this document is correct, as are the examples in
   RFC 2617 [1].

RFC2617のBNFにはエラー回数があることに注意してください。 特に、uriパラメタの値が引用文にあるに違いありません。 さらに、コンマでAuthentication-インフォメーションヘッダーのパラメタを切り離さなければなりません。 BNFは例のようにRFC2617[1]で本書では正しいです。

   The use of the nextnonce and nc parameters is supported as described
   in RFC 2617 [1], which provides guidance on how and when they should
   be used.  As a slight modification to the guidance provided in RFC
   2617, implementors of relays should note that AUTH requests cannot be
   pipelined; consequently, there is no detrimental impact on throughput
   when relays use the nextnonce mechanism.

nextnonceとncパラメタの使用はRFC2617[1](それらが使用されるべきであるどのように、時指導を提供する)で説明されるように支持されます。 指導へのわずかな変更がRFC2617に供給されたので、リレーの作成者は、AUTH要求をpipelinedされることができないことに注意するべきです。 リレーがnextnonceメカニズムを使用するとき、その結果、スループットへのどんな有害な影響もありません。

   See Section 5.1 for further information on the procedures for client
   authentication.

クライアント認証のための手順の詳細に関してセクション5.1を見てください。

9.2.  Using TLS

9.2. TLSを使用します。

   TLS is used to authenticate relays to senders and to provide
   integrity and confidentiality for the headers being transported.
   MSRP clients and relays MUST implement TLS.  Clients MUST send the
   TLS ClientExtendedHello extended hello information for server name
   indication as described in RFC 4366 [5].  A TLS cipher-suite of
   TLS_RSA_WITH_AES_128_CBC_SHA [6] MUST be supported (other cipher-
   suites MAY also be supported).  A relay MUST act as a TLS server and
   present a certificate with its identity in the SubjectAltName using
   the choice type of dnsName.  Relay-to-relay connections MUST use TLS
   with mutual authentication.  Client-to-relay communications MUST use
   TLS for AUTH requests and responses.

TLSは、送付者にリレーを認証して、保全と秘密性を輸送されるヘッダーに供給するのに使用されます。 MSRPクライアントとリレーはTLSを実行しなければなりません。 クライアントが広げられたTLS ClientExtendedHelloを送らなければならない、こんにちは、RFC4366[5]で説明されるサーバー名指示のための情報。 TLS_RSA_WITH_AES_128_CBC_SHA[6]のTLS暗号スイートを支えなければなりません(また、他の暗号スイートは支えられるかもしれません)。 dnsNameの特選しているタイプを使用して、アイデンティティがSubjectAltNameにある状態で、リレーはTLSサーバとプレゼントとして証明書を機能させなければなりません。 リレーからリレーとの接続は互いの認証があるTLSを使用しなければなりません。 クライアントからリレーへのコミュニケーションはAUTH要求と応答にTLSを使用しなければなりません。

Jennings, et al.            Standards Track                    [Page 26]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[26ページ]

   The SubjectAltName in the certificate received from a relay MUST
   match the hostname part of the URI, and the certificate MUST be valid
   according to RFC 3280 [12], including having a date that is valid and
   being signed by an acceptable certification authority.  After
   validating that such is the case, the device that initiated the TLS
   connection can assume that it has connected to the correct relay.

リレーから受け取られた証明書のSubjectAltNameはURIのホスト名部分に合わなければなりません、そして、RFC3280[12]によると、証明書は有効であるに違いありません、有効な期日を過して、許容できる証明権威によってサインされるのを含んでいて。 そのそのようなものを有効にするのがケースになった後に、TLS接続を開始した装置は、それが正しいリレーに接続したと仮定できます。

   This document does not define procedures for using mutual
   authentication between an MSRP client and an MSRP relay.
   Authentication of clients is handled using the AUTH method via the
   procedures described in Section 5.1 and Section 6.3.  Other
   specifications may define the use of TLS mutual authentication for
   the purpose of authenticating users associated with MSRP clients.
   Unless operating under such other specifications, MSRP clients SHOULD
   present an empty certificate list (if one is requested by the MSRP
   relay), and MSRP relays SHOULD ignore any certificates presented by
   the client.

このドキュメントはMSRPクライアントとMSRPリレーの間の互いの認証を使用するための手順を定義しません。 クライアントの認証は、セクション5.1とセクション6.3で説明された手順でAUTH方法を使用することで扱われます。 他の仕様はTLSの互いの認証のMSRPクライアントに関連しているユーザを認証する目的の使用を定義するかもしれません。 そのような他の仕様に基づき作動しない場合、リスト(1つがMSRPリレーで要求されるなら)を空の証明書に提示して、MSRPクライアントSHOULDはSHOULDが無視するMSRPリレーにクライアントによって提示されたどんな証明書も提示します。

      This behavior is defined specifically to allow forward-
      compatibility with specifications that define the use of TLS for
      client authentication.

この振舞いは、特に前方にTLSのクライアント認証の使用を定義する仕様との互換性を許容するために定義されます。

   Note: When relays are involved in a session, TCP without TLS is only
   used when a user that does not use relays connects directly to the
   relay of a user that is using relays.  In this case, the client has
   no way to authenticate the relay other than to use the URIs that form
   a shared secret in the same way those URIs are used when no relays
   are involved.

以下に注意してください。 リレーがセッションにかかわるとき、リレーを使用しないユーザが直接リレーを使用しているユーザのリレーに接続すると、TLSのないTCPは使用されるだけです。 この場合、クライアントには、リレーが全くかかわらないとき、それらのURIが使用されている同じように共有秘密キーを形成するURIを使用する以外のリレーを認証する方法が全くありません。

9.3.  Threat Model

9.3. 脅威モデル

   This section discusses the threat model and the broad mechanism that
   needs to be in place to secure the protocol.  The next section
   describes the details of how the protocol mechanism meets the broad
   requirements.

このセクションは脅威モデルとプロトコルを保証するために適所にある必要がある広いメカニズムについて論じます。 次のセクションはプロトコルメカニズムがどう広い必要条件を出迎えるかに関する詳細について説明します。

   MSRP allows two peer-to-peer clients to exchange messages.  Each peer
   can select a set of relays to perform certain policy operations for
   them.  This combined set of relays is referred to as the route set.
   A channel outside of MSRP always needs to exist, such as out-of-band
   provisioning or an explicit rendezvous protocol such as SIP, that can
   securely negotiate setting up the MSRP session and communicate the
   route set to both clients.  A client may trust a relay with certain
   types of routing and policy decisions, but it might or might not
   trust the relay with all the contents of the session.  For example, a
   relay being trusted to look for viruses would probably need to be
   allowed to see all the contents of the session.  A relay that helped
   deal with traversal of the ISP's Network Address Translator (NAT)

MSRPは2人のピアツーピアクライアントにメッセージを交換させます。 各同輩は、それらのためにある政策運営を実行するために1セットのリレーを選択できます。 この合併しているセットのリレーはルートセットと呼ばれます。 MSRPの外部がいつも存在する必要があるチャンネル、バンドの外の食糧を供給することまたは明白なランデブーがSIPなどのように議定書を作って、それは、MSRPセッションをセットアップしながらしっかりと交渉して、ルートセットを両方のクライアントに伝えることができます。 それは、委託するか、クライアントが、あるタイプのルーティングと政策決定をリレーに委託しますが、またはセッションのすべてのコンテンツをリレーに委託しないかもしれません。 例えば、ウイルスを探すと信じられるリレーは、たぶんセッションのすべてのコンテンツを見るのが許容される必要があるでしょう。 ISPのNetwork Address Translatorの縦断に対処するのを助けたリレー(NAT)

Jennings, et al.            Standards Track                    [Page 27]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[27ページ]

   would likely not be trusted with the contents of the session but
   would be trusted to correctly forward messages.

セッションのコンテンツでおそらく信じられないでしょうが、正しく前進のメッセージに任せられるでしょう。

   Clients implicitly trust the relays through which they send and
   receive messages to honor the routing indicated in those messages,
   within the constraints of the MSRP protocol.  Clients also need to
   trust that the relays they use do not insert new messages on their
   behalf or modify messages sent to or by the clients.  It is worth
   noting that some relays are in a position to cause a client to
   misroute a message by maliciously modifying a Use-Path returned by a
   relay further down the chain.  However, this is not an additional
   security threat because these same relays can also decide to misroute
   a message in the first place.  If the relay is trusted to route
   messages, it is reasonable to trust it not to tamper with the Use-
   Path header.  If the relay cannot be trusted to route messages, then
   it cannot be used.

クライアントはそれとなく、彼らがそれらのメッセージで示されたルーティングを光栄に思うメッセージを送って、受け取るリレーを信じます、MSRPプロトコルの規制の中で。 また、クライアントは、それらが使用するリレーがそれらに代わって新しいメッセージを挿入もしませんし、クライアントかクライアントによって送られたメッセージを変更もしないと信じる必要があります。 リレーが陰湿にUse-経路を変更するのによるメッセージがさらにチェーンの下側へのリレーで返したmisrouteにクライアントを引き起こす立場にあることに注意する価値があります。 しかしながら、また、これらの同じリレーが第一にメッセージについてmisrouteに決めることができるので、これは追加担保の脅威ではありません。 リレーがルートメッセージに任せられるなら、Use経路ヘッダーをいじらないようにそれを信じるのは妥当です。 ルートメッセージにリレーを任せることができないなら、それを使用できません。

   Under certain circumstances, relays need to trust other relays not to
   modify information between them and the client they represent.  For
   example, if a client is operating through Relay A to get to Relay B,
   and Relay B is logging messages sent by the client, Relay B may be
   required to authenticate that the messages they logged originate with
   the client, and have not been modified or forged by Relay A.  This
   can be done by having the client sign the message.

ある状況で、リレーは、それらが代理をするそれらとクライアントの間の情報を変更しないように他のリレーを信じる必要があります。 例えば、クライアントがRelay Bを始めるためにRelay Aを通して働いていて、Relay Bがクライアントによって送られたメッセージを登録しているなら、Relay BはクライアントをメッセージにサインさせることによってA.ThisをできるRelayによって必要であることで、それらが登録したメッセージがそれを認証するためには、クライアントの発案であるということであるかもしれなく、変更されるか、または鍛造されていません。

   Clients need to be able to authenticate that the relay they are
   communicating with is the one they trust.  Likewise, relays need to
   be able to authenticate that the client is the one they are
   authorized to forward information to.  Clients need the option of
   ensuring that information between the relay and the client is
   integrity protected and confidential to elements other than the
   relays and clients.  To simplify the number of options, traffic
   between relays is always integrity protected and encrypted regardless
   of whether or not the client requests it.  There is no way for the
   clients to tell the relays what strength of cryptographic mechanisms
   to use between relays other than to have the clients choose relays
   that are administered to require an adequate level of security.

クライアントは、それを認証できる必要があります。彼らが交信する予定であるリレーは彼らが信じるものです。 クライアントは、それを認証できるためには、ものです。同様に、リレーが必要である、それらは前進の情報に認可されます。 クライアントはリレーとクライアントの間の情報がリレーとクライアント以外の要素に保護されて秘密の保全であることを確実にするオプションを必要とします。 オプションの数を簡素化するために、いつもリレーの間の交通はクライアントがそれを要求するかどうかにかかわらず、保護されて、コード化された保全です。 クライアントが、クライアントに施されるリレーを選ばせる以外のリレーの間で使用する暗号のメカニズムのどんな強さが適切なレベルのセキュリティを必要とするかをリレーに言う方法が全くありません。

   The system also needs to stop messages from being directed to relays
   that are not supposed to see them.  To keep the relays from being
   used in Denial of Service (DoS) attacks, the relays never forward
   messages unless they have a trust relationship with either the client
   sending or the client receiving the message; further, they only
   forward a message if it is coming from or going to the client with
   which they have the trust relationship.  If a relay has a trust
   relationship with the client that is the destination of the message,
   it should not send the message anywhere except to the client that is
   the destination.

また、システムは、指示されるのからそれらを見るべきでないリレーにメッセージを止める必要があります。 リレーがサービス妨害(DoS)攻撃に使用されるのを妨げるために、彼らにメッセージを受け取るクライアント発信かクライアントのどちらかとの信用関係がないなら、リレーはメッセージを決して転送しません。 さらに、来るか、または彼らが信用関係を持っているクライアントのものになっている場合にだけ、彼らはメッセージを転送します。 リレーにクライアントとのメッセージの目的地である信用関係があるなら、それは何処にもそれがクライアント以外の目的地であるメッセージを送るべきではありません。

Jennings, et al.            Standards Track                    [Page 28]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[28ページ]

   Some terminology used in this discussion: SClient is the client
   sending a message and RClient is the client receiving a message.
   SRelay is a relay the sender trusts and RRelay is a relay the
   receiver trusts.  The message will go from SClient to SRelay1 to
   SRelay2 to RRelay2 to RRelay1 to RClient.

この議論に使用される何らかの用語: SClientはメッセージを送るクライアントです、そして、RClientはメッセージを受け取るクライアントです。 SRelayは送付者が信じるリレーです、そして、RRelayは受信機が信じるリレーです。 メッセージはSClientからSRelay1までSRelay2にRRelay2にRRelay1にRClientに行くでしょう。

9.4.  Security Mechanism

9.4. セキュリティー対策

   Confidentiality and privacy from elements not in the route set is
   provided by using TLS on all the transports.  Relays always use TLS.
   A client can use unprotected TCP for peer-to-peer MSRP, but any time
   a client communicates with its relay, it MUST use TLS.

要素からの秘密性とプライバシーは、すべての輸送のときにTLSを使用することによって、ルートセットに提供されません。 リレーはいつもTLSを使用します。 クライアントはピアツーピアMSRPに保護のないTCPを使用できますが、クライアントがリレーで交信する何時でも、それはTLSを使用しなければなりません。

   The relays authenticate to the clients using TLS (but don't have to
   do mutual TLS).  Further, the use of the rspauth parameter in the
   Authentication-Info header provides limited authentication of relays
   to which the client is not directly connected.  The clients
   authenticate to the relays using HTTP Digest authentication.  Relays
   authenticate to each other using TLS mutual authentication.

リレーは使用TLS(しかし、互いのTLSをする必要はない)をクライアントに認証します。 さらに、Authentication-インフォメーションヘッダーにおけるrspauthパラメタの使用はクライアントが直接接続されないリレーの限られた認証を提供します。 クライアントは使用しているHTTP Digest認証をリレーに認証します。 リレーは使用TLS互いの認証を互いに認証します。

   By using Secure/Multipurpose Internet Mail Extensions (S/MIME) [3]
   encryption, the clients can protect their actual message contents so
   that the relays cannot see the contents.  End-to-end signing is also
   possible with S/MIME.

Secure/マルチパーパスインターネットメールエクステンション(S/MIME)[3]暗号化を使用することによって、クライアントはリレーがコンテンツを見ることができないように、彼らの実際のメッセージ内容を保護できます。 また、終わりから終わりへの調印もS/MIMEで可能です。

   The complex part is making sure that relays cannot successfully be
   instructed to send messages to a place where they should not.  This
   is done by having the client authenticate to the relay and having the
   relay return a token.  Messages that contain this token can be
   relayed if they come from the client that got the token or if they
   are being forwarded towards the client that got the token.  The
   tokens are the URIs that the relay places in the Use-Path header.
   The tokens contain random material (defined in Section 6.3) so that
   they are not guessable by attackers.  The tokens need to be protected
   so they are only ever seen by elements in the route set or other
   elements that at least one of the parties trusts.  If some third
   party discovers the token that RRelay2 uses to forward messages to
   RClient, then that third party can send as many messages as they want
   to RRelay2 and it will forward them to RClient.  The third party
   cannot cause them to be forwarded anywhere except to RClient,
   eliminating the open relay problems.  SRelay1 will not forward the
   message unless it contains a valid token.

複雑な部分は、リレーがそれらがそうするべきでない場所にメッセージを送るよう首尾よく命令できないのを確実にしています。 クライアントにリレーとリレーリターンを持っているのに認証させることによって、象徴をこれをします。 象徴を手に入れたクライアントから来るか、または象徴を手に入れたクライアントに向かってそれらを送っているなら、この象徴を含むメッセージはリレーできます。 象徴はリレーがUse-経路ヘッダーに置くURIです。 象徴が無作為の材料(セクション6.3では、定義される)を含んでいるので、それらは攻撃者で推測可能ではありません。 それらが今までにルートによる要素によって見られるだけであって、保護されるべき象徴の必要性がセットしたか、または他の要素はそんなに少なくともパーティー受託の1つをセットしました。 第三者が、RRelay2が使用する象徴がメッセージをRClientに転送すると発見するなら、その第三者はRRelay2に好きなだけ多くのメッセージを送ることができます、そして、それはそれらをRClientに送るでしょう。 RClient以外に、第三者はそれらを何処にも送らせることができません、オープンリレー問題を解決して。有効な象徴を含んでいないと、SRelay1はメッセージを転送しないでしょう。

   When SClient goes to get a token from SRelay2, this request is
   relayed through SRelay1.  SRelay2 authenticates that it really is
   SClient requesting the token, but it generates a token that is only
   valid for forwarding messages to or from SRelay1.  SRelay2 knows it
   is connected to SRelay1 because of the mutual TLS.

SClientがSRelay2から象徴を手に入れに行くとき、この要求はSRelay1を通してリレーされます。 SRelay2はそれを認証します。本当に象徴を要求することでのSClientですが、それはSRelay1かSRelay1から推進メッセージだけに、有効な象徴を発生させます。 SRelay2は、それが互いのTLSのためにSRelay1に接続されるのを知っています。

Jennings, et al.            Standards Track                    [Page 29]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[29ページ]

   The tokens are carried in the resource portion of the MSRP URIs.  The
   length of time the tokens are valid for is negotiated using the
   Expire header in the AUTH request.  Clients need to re-negotiate the
   tokens using a new offer/answer [15] exchange (e.g., a SIP re-invite)
   before the tokens expire.

象徴はMSRP URIのリソース部分で運ばれます。 象徴が有効である時の長さは、AUTH要求でExpireヘッダーを使用することで交渉されます。 クライアントは、象徴が期限が切れる前に新しい申し出/答え[15]交換(例えば、SIP再招待)を使用することで象徴を再交渉する必要があります。

   Note that this scheme relies on relays as trusted nodes, acting on
   behalf of the users authenticated to them.  There is no security
   mechanism to prevent relays on the path from inserting forged
   messages, manipulating the contents of messages, sending messages in
   a session to a party other than that specified by the sender, or from
   copying them to a third party.  However, the one-to-one binding
   between session identifiers and sessions helps mitigate any damage
   that can be caused by rogue relays by limiting the destinations to
   which forged or modified messages can be sent to the two parties
   involved in the session, and only for the duration of the session.
   Additionally, the use of S/MIME encryption can be employed to limit
   the utility of redirecting messages.  Finally, clients can employ
   S/MIME signatures to guarantee the authenticity of messages they
   send, making it possible under some circumstances to detect relay
   manipulation or the forging of messages.

彼らに認証されたユーザを代表して行動して、この計画が信じられたノードとしてリレーに依存することに注意してください。 送付者か、それらをコピーすることので指定される以外に、セッションのときにメッセージをパーティーに送って、メッセージのコンテンツを操って、経路におけるリレーが偽造メッセージを挿入するのを防ぐために、第三者にはセキュリティー対策が全くありません。 しかしながら、セッション識別子とセッションの間の1〜1つの結合が、セッションにかかわる2回のパーティー、およびセッションの持続時間のためだけに偽造しているか変更されたメッセージを送ることができる目的地を制限することによって凶暴なリレーでもたらすことができるどんな損害も緩和するのを助けます。 さらに、向け直すメッセージに関するユーティリティを制限するのにS/MIME暗号化の使用を使うことができます。 最終的に、クライアントは発信するのをメッセージの信憑性に保証するのにS/MIME署名を使うことができます、リレー操作かメッセージの鍛造物を検出するのをいくつかの状況で可能にして。

   Clients are not the only actors in the network who need to trust
   relays to act in non-malicious ways.  If a relay does not have a
   direct TLS connection with the client on whose behalf it is acting
   (i.e.  There are one or more intervening relays), it is at the mercy
   of any such intervening relays to accurately transmit the messages
   sent to and from the client.  If a stronger guarantee of the
   authentic origin of a message is necessary (e.g.  The relay is
   performing logging of messages as part of a legal requirement), then
   users of that relay can be instructed by their administrators to use
   detached S/MIME signatures on all messages sent by their client.  The
   relay can enforce such a policy by returning a 415 response to any
   SEND requests using a top-level MIME type other than "multipart/
   signed".  Such relays may choose to make policy decisions (such as
   terminating sessions and/or suspending user authorization) if such
   signatures fail to match the contents of the message.

クライアントは非悪意がある方法で行動するためにリレーを信じる必要があるネットワークの唯一の俳優ではありません。 リレーにそれがだれの代理を行動させているかときのクライアントとのダイレクトTLS接続がないなら(すなわち、Thereは1歳であるか、より多くの介入がリレーです)、リレーに正確にクライアントとクライアントから送られたメッセージを送るためにどんなそのような介入であることの思うままにそれはあります。 メッセージの正統の起源の、より強い保証が必要であるなら(例えば、リレーは法的必要条件の一部としてメッセージの伐採を実行しています)、彼らの管理者は、そのリレーのユーザが彼らのクライアントによって送られたすべてのメッセージで離れているS/MIME署名を使用するよう命令できます。 リレーは、「複合かサインされること」を除いたトップレベルMIMEの種類を使用することでどんなSEND要求への415応答も返すことによって、そのような方針を実施できます。 そのような署名がメッセージのコンテンツに合っていないなら、そのようなリレーは、政策決定(セッション、そして/または、中断ユーザ認可を終えなどなどの)をするのを選ぶかもしれません。

Jennings, et al.            Standards Track                    [Page 30]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[30ページ]

10.  IANA Considerations

10. IANA問題

10.1.  New MSRP Method

10.1. 新しいMSRP方法

   This specification defines a new MSRP method, to be added to the
   Methods sub-registry under the MSRP Parameters registry: AUTH.  See
   Section 5.1 for details on the AUTH method.

この仕様はMSRP Parameters登録の下にサブ登録しているMethodsに加えられるために新しいMSRP方法を定義します: AUTH。 AUTH方法に関する詳細に関してセクション5.1を見てください。

10.2.  New MSRP Headers

10.2. 新しいMSRPヘッダー

   This specification defines several new MSRP header fields, to be
   added to the header-field sub-registry under the MSRP Parameters
   registry:

この仕様はMSRP Parameters登録の下にサブ登録しているヘッダーフィールドに加えられるためにいくつかの新しいMSRPヘッダーフィールドを定義します:

   o  Expires
   o  Min-Expires
   o  Max-Expires
   o  Use-Path
   o  WWW-Authenticate
   o  Authorization
   o  Authentication-Info

o 期限が切れる、oがMin期限が切れる、oはoがWWW認証するo Use-経路o Authorization o Authentication-インフォメーションをマックスと同じくらい吐き出します。

10.3.  New MSRP Response Codes

10.3. 新しいMSRP応答コード

   This specification defines one new MSRP status code, to be added to
   the Status-Code sub-registry under the MSRP Parameters registry:

この仕様はMSRP Parameters登録の下にサブ登録しているStatus-コードに追加されるために1つの新しいMSRPステータスコードを定義します:

   The 401 response indicates that an AUTH request contained no
   credentials, an expired nonce value, or invalid credentials.  The
   response includes a "WWW-Authenticate" header containing a challenge
   (among other fields); see Section 9.1 for further details.  The
   default response phrase for this response is "Unauthorized".

401応答は、AUTH要求がどんな信任状も、満期の一回だけの値、または無効の信任状も含まなかったのを示します。 応答、インクルードaは挑戦(他の分野の中の)を含むヘッダーを「WWW認証します」。 さらに詳しい明細についてはセクション9.1を見てください。 この応答のためのデフォルト応答句は「権限がありません」。

11.  Example SDP with Multiple Hops

11. 複数のホップスがある例のSDP

   The following section shows an example SDP that could occur in a SIP
   message to set up an MSRP session between Alice and Bob where Bob
   uses a relay.  Alice makes an offer with a path to Alice.

以下のセクションは、ボブがどこでリレーを使用するかをアリスとボブとのMSRPセッションをセットアップするSIPメッセージに起こることができた例のSDPに示します。 アリスは経路でアリスに申し出ます。

    c=IN IP4 a.example.com
    m=message 1234 TCP/MSRP *
    a=accept-types: message/cpim text/plain text/html
    a=path:msrp://a.example.com:1234/agic456;tcp

メッセージ1234TCP/MSRP*a IN IP4a.example.com c=m==が受け入れる、-、タイプ: メッセージ/cpimテキスト/プレーンテキスト/html aはtcpにexample.com: 経路: msrp://a.1234/agic456と等しいです。

Jennings, et al.            Standards Track                    [Page 31]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[31ページ]

   In this offer, Alice wishes to receive MSRP messages at
   a.example.com.  She wants to use TCP as the transport for the MSRP
   session.  She can accept message/cpim, text/plain, and text/html
   message bodies in SEND requests.  She does not need a relay to set up
   the MSRP session.

この申し出では、アリスはa.example.comにMSRPメッセージを受け取りたがっています。 彼女はMSRPセッションに輸送としてTCPを使用したがっています。 彼女はSEND要求でメッセージ/cpim、テキスト/平野、およびテキスト/htmlメッセージボディーを受け入れることができます。 彼女は、MSRPセッションをセットアップするためにリレーを必要としません。

   To this offer, Bob's answer could look like:

この申し出に、ボブの答えは似ることができました:

    c=IN IP4 bob.example.com
    m=message 1234 TCP/TLS/MSRP *
    a=accept-types: message/cpim text/plain
    a=path:msrps://relay.example.com:9000/hjdhfha;tcp  \
           msrps://bob.example.com:1234/fuige;tcp

メッセージ1234TCP/TLS/MSRP*a IN IP4 bob.example.com c=m==が受け入れる、-、タイプ: =経路: msrps://relay.example.com: メッセージ/cpimテキスト/平野9000/hjdhfha; tcp\msrps://bob.example.com: 1234/fuige; tcp

   Here Bob wishes to receive the MSRP messages at bob.example.com.  He
   can accept only message/cpim and text/plain message bodies in SEND
   requests and has rejected the text/html content offered by Alice.  He
   wishes to use a relay called relay.example.com for the MSRP session.

ここに、ボブはbob.example.comにMSRPメッセージを受け取りたがっています。 彼は、SEND要求でメッセージ/cpimとテキスト/明瞭なメッセージ本体しか受け入れることができないで、アリスによって提供されたテキスト/html内容を拒絶しました。 彼はMSRPセッションにrelay.example.comと呼ばれるリレーを使用したがっています。

12.  Acknowledgments

12. 承認

   Many thanks to Avshalom Houri, Hisham Khartabil, Robert Sparks,
   Miguel Garcia, Hans Persson, and Orit Levin, who provided detailed
   proofreading and helpful text.  Thanks to the following members of
   the SIMPLE WG for spirited discussions on session mode: Chris
   Boulton, Ben Campbell, Juhee Garg, Paul Kyzivat, Allison Mankin, Aki
   Niemi, Pekka Pessi, Jon Peterson, Brian Rosen, Jonathan Rosenberg,
   and Dean Willis.

詳細な校正していて役立っているテキストを提供したAvshalom Houri、Hisham Khartabil、ロバート・スパークス、ミゲル・ガルシア、ハンス・ペルソン、およびOritレヴィンをありがとうございます。 セッションモードについての活発な議論をSIMPLE WGの以下のメンバーをありがとうございます: クリス・ボールトン、ベン・キャンベル、Juhee Garg、ポールKyzivat、アリソン・マンキン、アキNiemi、ペッカPessi、ジョン・ピーターソン、ブライアン・ローゼン、ジョナサン・ローゼンバーグ、およびディーン・ウィリス。

13.  References

13. 参照

13.1.  Normative References

13.1. 引用規格

   [1]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

[1] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。

   [2]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

[2] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [3]   Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851, July
         2004.

[3]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。

   [4]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

[4]Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。

Jennings, et al.            Standards Track                    [Page 32]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[32ページ]

   [5]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
         4366, April 2006.

[5] ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。

   [6]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
         Transport Layer Security (TLS)", RFC 3268, June 2002.

[6]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。

   [7]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

[7] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

   [8]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

[8] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [10]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

[10] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [11]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
         Message Session Relay Protocol (MSRP)", RFC 4975, September
         2007.

[11] キャンベル、B.(エド)、マーイ、R.(エド)、およびC.ジョニングス(エド)、「メッセージセッションはプロトコル(MSRP)をリレーします」、RFC4975、2007年9月。

   [12]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

[12]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。

13.2.  Informative References

13.2. 有益な参照

   [13]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

解放された[13]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [14]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November
         1996.

解放された[14]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。

   [15]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

[15] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

Jennings, et al.            Standards Track                    [Page 33]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[33ページ]

Appendix A.  Implementation Considerations

付録A.実現問題

   This text is not necessary in order to implement MSRP in an
   interoperable way, but is still useful as an implementation
   discussion for the community.  It is purely an implementation detail.

本稿は、共同利用できる方法でMSRPを実行するのに必要ではありませんが、共同体との実現議論としてまだ役に立っています。 それは純粋に実現の詳細です。

   Note: The idea has been proposed of having a relay return a base URI
   that the client can use to construct more URIs, but this allows third
   parties that have had a session with the client to know URIs that the
   relay will use for forwarding after the session with the third party
   has ended.  Effectively, this reveals the secret URIs to third
   parties, which compromises the security of the solution, so this
   approach is not used.

以下に注意してください。 リレーにクライアントが、より多くのURIを構成するのに使用できるベースURIを返させるのについて考えは提案されましたが、これで、第三者とのセッションが終わった後にクライアントと共に会合を開いた第三者はリレーが推進に使用するURIを知ることができます。 事実上、これが秘密のURIを第三者に明らかにして、どの妥協が解決策の保証であるかので、このアプローチは使用されていません。

   An alternative to this approach causes the relays to return a URI
   that is divided into an index portion and a secret portion.  The
   client can encrypt its identifier and its own opaque data with the
   secret portion, and concatenate this with the index portion to create
   a plurality of valid URIs.  When the relay receives one of these
   URIs, it could use the index to look up the appropriate secret,
   decrypt the client portion, and verify that it contains the client
   identifier.  The relay can then forward the request.  The client does
   not need to send an AUTH request for each URI it uses.  This is an
   implementation detail that is out of the scope of this document.

このアプローチへの代替手段で、リレーはインデックス部分と秘密の部分に分割されるURIを返します。 クライアントは、秘密の部分で識別子とそれ自身の不明瞭なデータをコード化して、多くの有効なURIを作成するためにインデックス部分でこれを連結できます。 リレーがこれらのURIの1つを受け取るとき、それは、適切な秘密を調べて、クライアント部分を解読して、クライアント識別子を含むことを確かめるのにインデックスを使用するかもしれません。 そして、リレーは要求を転送できます。 クライアントはそれが使用する各URIを求めるAUTH要求を送る必要はありません。 これはこのドキュメントの範囲の外にある実現の詳細です。

   It is possible to implement forwarding requirements in a farm without
   the relay saving any state.  One possible implementation that a relay
   might use is described in the rest of this section.  When a relay
   starts up, it could pick a cryptographically random 128-bit password
   (K) and 128-bit initialization vector (IV).  If the relay was
   actually a farm of servers with the same DNS name, all the machines
   in the farm would need to share the same K.  When an AUTH request is
   received, the relay forms a string that contains the expiry time of
   the URI, an indication if the previous hop was mutual TLS
   authenticated or not, and if it was, the name of the previous hop,
   and if it was not, the identifier for the connection that received
   the AUTH request.  This string would be padded by appending a byte
   with the value 0x80 then adding zero or more bytes with the value of
   0x00 until the string length is a multiple of 16 bytes long.  A new
   random IV would be selected (it needs to change because it forms the
   salt) and the padded string would be encrypted using AES-CBC with a
   key of K.  The IV and encrypted data and an SPI (security parameter
   index) that changes each time K changes would be base 64 encoded and
   form the resource portion of the request URI.  The SPI allows the key
   to be changed and for the system to know which K should be used.
   Later when the relay receives this URI, it could decrypt it and check
   that the current time was before the expiry time and check that the
   message was coming from or going to the connection or location

それは、どんな状態も節約しながら農場でリレーなしで要件を転送しながら、実行するのにおいて可能です。 リレーが使用するかもしれない1つの可能な実現がこのセクションの残りで説明されます。 リレーが始動すると、それは暗号で無作為の128ビットのパスワード(K)と128ビットでaを選ぶかもしれません。初期化ベクトル(IV)。 同じK.Whenを共有するために、名前、農場のすべてのマシンがそうするDNSがそうしなければならない同じくらいでAUTH要求がリレーが実際にサーバの農場であったなら受信されている、前のホップが認証された互いのTLSであり、前の名前がそれがそうであったなら、跳んで、それが形成しなかったなら、リレーはURI、指示の満期時間を含むストリングを形成します、AUTH要求を受け取った接続への識別子。 このストリングはゼロを加えながら、その時値0x80に従った1バイトを追加することによって、水増しされるだろうか、ストリング長までの0×00の値に従った、より多くのバイトが16バイト長の倍数です。 新しい無作為のIVが選択されて(それは、塩を形成するので変化する必要があります)、そっと歩いているストリングがK. IVとコード化されたデータのキーがあるAES-CBCを使用することでコード化されて、その都度K変化を変えるSPI(セキュリティパラメタインデックス)は64がコード化したベースであり、要求URIのリソース部分を形成するでしょう。 変えられて、システムが、どのKが使用されるべきであるかを知るように、SPIはキーを許容します。 リレーがその後このURIを受けるとき、それは、それを解読して、現在の時間が満期時の前にあったのをチェックして、メッセージが接続か位置まで来たか、または行っていたのをチェックするかもしれません。

Jennings, et al.            Standards Track                    [Page 34]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[34ページ]

   specified in the URI.  Integrity protection is not required because
   it is extremely unlikely that random data that was decrypted would
   result in a valid location that was the same as the one the message
   was routing to or from.  When implementing something like this,
   implementors should be careful not to use a scheme like EBE that
   would allows portions of encrypted tokens to be cut and pasted into
   other URIs.

URIでは、指定されています。 または解読された無作為のデータがメッセージが掘っていたものと同じであった有効な位置をもたらすのが、非常にありそうもないので保全保護は必要でない。 何かこのようなものを実行するとき、作成者は、そうするEBEが、コード化された象徴の一部が他のURIに切られて、貼られるのを許容するように計画を使用しないように慎重であるはずです。

Authors' Addresses

作者のアドレス

   Cullen Jennings
   Cisco Systems, Inc.
   170 West Tasman Dr.
   MS: SJC-21/2
   San Jose, CA  95134
   USA

カレンジョニングスシスコシステムズInc.170の西タスマン博士MS: SJC-21/2カリフォルニア95134サンノゼ(米国)

   Phone: +1 408 421-9990
   EMail: fluffy@cisco.com

以下に電話をしてください。 +1 408 421-9990 メールしてください: fluffy@cisco.com

   Rohan Mahy
   Plantronics
   345 Encincal Street
   Santa Cruz, CA  95060
   USA

RohanマーイPlantronics345Encincal通りカリフォルニア95060サンタクルス(米国)

   EMail: rohan@ekabal.com

メール: rohan@ekabal.com

   Adam Roach
   Estacado Systems
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   USA

アダムローチエスタカードSystems17210キャンベル通り Suite250テキサス75252ダラス(米国)

   Phone: sip:adam@estacado.net
   EMail: adam@estacado.net

以下に電話をしてください。 一口: adam@estacado.net EMail: adam@estacado.net

Jennings, et al.            Standards Track                    [Page 35]

RFC 4976                      MSRP Relays                 September 2007

ジョニングス、他 RFC4976MSRPが2007年9月にリレーする標準化過程[35ページ]

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Jennings, et al.            Standards Track                    [Page 36]

ジョニングス、他 標準化過程[36ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

em単位で指定した字間をbody要素の文字サイズを基準に算出する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る