[要約] RFC 7701は、MSRPを使用したマルチパーティチャットに関する規格です。その目的は、MSRPを使用して複数の参加者間でリアルタイムのチャットセッションを確立し、メッセージを交換するためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 7701
Category: Standards Track M. Garcia-Martin
ISSN: 2070-1721 Ericsson
G. Sandbakken
Cisco Systems
December 2015
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
メッセージセッションリレープロトコル（MSRP）を使用したマルチパーティチャット
Abstract
概要
The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.
メッセージセッションリレープロトコル（MSRP）は、ピアツーピアセッション内でインスタントメッセージ（IM）を送信するメカニズムを定義し、セッション開始プロトコル（SIP）とセッション記述プロトコル（SDP）を使用してネゴシエートされます。このドキュメントでは、MSRPを使用してマルチパーティチャットセッションまたはチャットルームを確立するために必要なツールを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7701.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7701で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Motivations and Requirements ....................................6
4. Overview of Operation ...........................................7
4.1. Policy Attributes of the Chat Room ........................10
5. Creating, Joining, and Deleting a Chat Room ....................12
5.1. Creating a Chat Room ......................................12
5.2. Joining a Chat Room .......................................12
5.3. Deleting a Chat Room ......................................14
6. Sending and Receiving Instant Messages .........................14
6.1. Regular Messages ..........................................14
6.2. Private Messages ..........................................17
6.3. MSRP Reports and Responses ................................19
6.4. Congestion Avoidance ......................................20
7. Nicknames ......................................................21
7.1. Using Nicknames within a Chat Room ........................22
7.2. Modifying a Nickname ......................................24
7.3. Removing a Nickname .......................................25
7.4. Nicknames in Conference Event Packages ....................25
8. The SDP 'chatroom' Attribute ...................................25
9. Examples .......................................................28
9.1. Joining a Chat Room .......................................28
9.2. Setting Up a Nickname .....................................30
9.3. Sending a Regular Message to the Chat Room ................31
9.4. Sending a Private Message to a Participant ................33
9.5. Chunked Private Message ...................................35
9.6. Nickname in a Conference Information Document .............35
10. IANA Considerations ...........................................37
10.1. New MSRP Method ..........................................37
10.2. New MSRP Header ..........................................37
10.3. New MSRP Status Codes ....................................37
10.4. New SDP Attribute ........................................38
11. Security Considerations .......................................38
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................43
Acknowledgments ...................................................43
Contributors ......................................................43
Authors' Addresses ................................................44
The Message Session Relay Protocol (MSRP) [RFC4975] defines a mechanism for sending a series of instant messages within a session. The Session Initiation Protocol (SIP) [RFC3261] in combination with the Session Description Protocol (SDP) [RFC4566] allows for two peers to establish and manage such sessions.
メッセージセッションリレープロトコル（MSRP）[RFC4975]は、セッション内で一連のインスタントメッセージを送信するメカニズムを定義します。セッション開始プロトコル（SIP）[RFC3261]とセッション記述プロトコル（SDP）[RFC4566]の組み合わせにより、2つのピアがこのようなセッションを確立および管理できるようになります。
In another application of SIP, a User Agent (UA) can join in a multi-party conversation called a "conference" that is hosted by a specialized UA called a "focus" [RFC4353]. Such a conference can naturally involve MSRP sessions. It is the responsibility of an entity handling the media to relay IMs received from one participant to the rest of the participants in the conference.
SIPの別のアプリケーションでは、ユーザーエージェント（UA）は、「フォーカス」[RFC4353]と呼ばれる特殊なUAによってホストされる「会議」と呼ばれるマルチパーティの会話に参加できます。このような会議には、当然ながらMSRPセッションが含まれます。メディアを処理するエンティティは、1人の参加者から受信したIMを会議の残りの参加者に中継する必要があります。
Several such systems already exist in the Internet. Participants in a chat room can be identified with a pseudonym or nickname and can decide whether their real identifier is disclosed to other participants. Participants can also use a rich set of features such as the ability to send private instant messages to other participants.
そのようなシステムのいくつかはすでにインターネットに存在しています。チャットルームの参加者は、仮名またはニックネームで識別でき、実際の識別子を他の参加者に公開するかどうかを決定できます。参加者は、プライベートインスタントメッセージを他の参加者に送信する機能など、豊富な機能を使用することもできます。
Similar conferences supporting chat room functionality are already available today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol (XMPP): Core [RFC6120], as well as many other proprietary systems. Specifying equivalent functionality for MSRP-based systems eases interworking between these systems.
チャットルーム機能をサポートする同様の会議が、今日すでに利用可能です。たとえば、インターネットリレーチャット（IRC）[RFC2810]、Extensible Messaging and Presence Protocol（XMPP）：Core [RFC6120]、および他の多くの独自システム。 MSRPベースのシステムに同等の機能を指定すると、これらのシステム間の相互作用が容易になります。
This document defines requirements, conventions, and extensions for providing private messages and nickname management in centralized chat rooms with MSRP. Participants in a chat room can be identified by a pseudonym and decide if their real identifier should be disclosed to other participants. This memo uses the SIP Conferencing Framework [RFC4353] as a design basis. It also aims to be compatible with "A Framework for Centralized Conferencing" [RFC5239]. Should requirements arise, future mechanisms for providing similar functionality in generic conferences might be developed, for example, where the media is not only restricted to MSRP. The mechanisms described in this document provide a future compatible short-term solution for MSRP centralized chat rooms.
このドキュメントでは、MSRPを使用して集中チャットルームでプライベートメッセージとニックネーム管理を提供するための要件、規則、および拡張機能を定義します。チャットルームの参加者は、仮名で識別でき、実際の識別子を他の参加者に公開するかどうかを決定できます。このメモは、SIP会議フレームワーク[RFC4353]を設計の基礎として使用しています。また、「集中型会議のためのフレームワーク」[RFC5239]との互換性も目指しています。要件が発生した場合、たとえばメディアがMSRPだけに制限されていない場合など、一般的な会議で同様の機能を提供するための将来のメカニズムが開発される可能性があります。このドキュメントで説明するメカニズムは、MSRP集中型チャットルームに将来互換性のある短期的なソリューションを提供します。
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 BCP 14 [RFC2119] and indicate requirement levels for compliant implementations.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。
This memo deals with "Tightly Coupled SIP Conferences" as defined in the SIP Conferencing Framework [RFC4353] and adopts the terminology from that document. In addition, we introduce some new terms:
このメモは、SIP会議フレームワーク[RFC4353]で定義されている「密結合SIP会議」を扱い、そのドキュメントの用語を採用しています。さらに、新しい用語をいくつか紹介します。
Nickname: a pseudonym or descriptive name associated with a participant. See Section 7 for details.
ニックネーム：参加者に関連付けられた仮名または説明的な名前。詳細については、セクション7を参照してください。
Multi-party Chat: an instance of a tightly coupled conference, in which the media exchanged between the participants consist of MSRP-based IMs. Also known as a chat room.
マルチパーティチャット：参加者間で交換されるメディアがMSRPベースのIMで構成される、密結合会議のインスタンス。チャットルームとも呼ばれます。
Chat Room: a synonym for a multi-party chat.
チャットルーム：マルチパーティチャットの同義語。
Chat Room URI: a URI that identifies a particular chat room and that is a synonym of a "Conference URI" as defined in RFC 4353 [RFC4353].
チャットルームURI：特定のチャットルームを識別するURIであり、RFC 4353 [RFC4353]で定義されている「会議URI」の同義語です。
Sender: the chat room participant who originally created an IM and sent it to the chat room server for further delivery.
送信者：最初にIMを作成し、それをチャットルームサーバーに送信してさらに配信するチャットルームの参加者。
Recipient: the destination chat room participant(s). This defaults to the full conference participant list minus the IM Sender.
受信者：送信先のチャットルームの参加者。デフォルトでは、会議参加者リスト全体からIM送信者を差し引いたものになります。
MSRP Switch: a media-level entity that is an MSRP endpoint. It is a special MSRP endpoint that receives MSRP messages and delivers them to the other chat room participants. The MSRP switch has a similar role to a conference mixer with the exception that the MSRP switch does not actually "mix" together different input media streams; it merely relays the messages between chat room participants.
MSRPスイッチ：MSRPエンドポイントであるメディアレベルのエンティティ。これは、MSRPメッセージを受信して他のチャットルームの参加者に配信する特別なMSRPエンドポイントです。 MSRPスイッチは、実際にはさまざまな入力メディアストリームを「混合」しないことを除いて、会議ミキサーと同様の役割を果たします。チャットルームの参加者間でメッセージを中継するだけです。
Private IM: an IM sent in a chat room intended for a single participant. Generally speaking, a private IM is seen by the MSRP switch, in addition to the sender and recipient. A private IM is usually rendered distinctly from the rest of the IMs, indicating that the message was a private communication.
プライベートIM：単一の参加者を対象としたチャットルームで送信されたIM。一般的に言えば、プライベートIMは、送信者と受信者に加えて、MSRPスイッチによって認識されます。プライベートIMは通常、残りのIMとは別にレンダリングされ、メッセージがプライベート通信であることを示します。
Anonymous URI: a URI concealing the participant's SIP address of record (AOR) from the other participants in the chat room. The allocation of such a URI is out of scope of this specification. An anonymous URI must be valid for the length of the chat room session and will be utilized by the MSRP switch to forward messages to and from anonymous participants. Privacy and anonymity are discussed in greater detail in RFC 3323 [RFC3323] and RFC 3325 [RFC3325].
匿名URI：チャットルームの他の参加者から参加者のレコードのSIPアドレス（AOR）を隠すURI。このようなURIの割り当ては、この仕様の範囲外です。匿名URIは、チャットルームセッションの間有効である必要があり、MSRPスイッチが匿名参加者との間でメッセージを転送するために使用されます。プライバシーと匿名性については、RFC 3323 [RFC3323]およびRFC 3325 [RFC3325]で詳細に説明されています。
Conference Event Package: a notification mechanism that allows conference participants to learn conference information including roster and state changes in a conference. This would typically be the mechanisms defined in "A Session Initiation Protocol (SIP) Event Package for Conference State" [RFC4575] or "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)" [RFC6502].
会議イベントパッケージ：会議の参加者が会議の名簿や状態の変更などの会議情報を学習できるようにする通知メカニズム。これは通常、「会議状態のセッション開始プロトコル（SIP）イベントパッケージ」[RFC4575]または「集中型会議（XCON）の会議イベントパッケージデータ形式拡張」[RFC6502]で定義されているメカニズムです。
Identifier: a string used to recognize or establish as being a particular user.
識別子：特定のユーザーであることを認識または確立するために使用される文字列。
To log in: to enter identifying data, as a name or password, into a chat room, so as to be able to do work with the chat room.
ログインするには：チャットルームで作業できるように、名前またはパスワードとして識別データをチャットルームに入力します。
Although conference frameworks describing many types of conferencing applications already exist, such as the one in "A Framework for Centralized Conferencing" [RFC5239] and the SIP Conferencing Framework [RFC4353], the exact details of session-based instant messaging conferences (chat rooms) are not well-defined at the moment.
「集中型会議のためのフレームワーク」[RFC5239]やSIP会議フレームワーク[RFC4353]のような多くのタイプの会議アプリケーションを説明する会議フレームワークはすでに存在しますが、セッションベースのインスタントメッセージング会議（チャットルーム）の正確な詳細現時点では明確に定義されていません。
To allow interoperable chat implementations, for both conference-aware and conference-unaware UAs, certain conventions for MSRP chat rooms need to be defined. It also seems beneficial to provide a set of features that enhance the baseline multi-party MSRP in order to be able to create systems that have functionality on par with existing chat systems as well as to enable the building of interworking gateways to these existing chat systems.
相互運用可能なチャット実装を可能にするには、会議対応UAと会議非対応UAの両方で、MSRPチャットルームの特定の規則を定義する必要があります。既存のチャットシステムと同等の機能を備えたシステムを作成し、これらの既存のチャットシステムへのインターワーキングゲートウェイを構築できるようにするために、ベースラインのマルチパーティMSRPを強化する一連の機能を提供することも有益と思われます。 。
We define the following requirements:
次の要件を定義します。
REQ-1: A basic requirement is the existence of a chat room, where participants can join and leave the chat room and exchange IMs with the rest of the participants.
REQ-1：基本的な要件は、参加者がチャットルームに参加したり退出したり、残りの参加者とIMを交換したりできるチャットルームの存在です。
REQ-2: A recipient of an IM in a chat room must be able to determine the identifier of the sender of the message. Note that the actual identifier depends on the one that was used by the sender when joining the chat room.
REQ-2：チャットルームのIMの受信者は、メッセージの送信者の識別子を特定できる必要があります。実際の識別子は、チャットルームに参加するときに送信者が使用した識別子に依存することに注意してください。
REQ-3: A recipient of an IM in a chat room must be able to determine the identifier of the recipient of received messages. For instance, the recipient of the message might be the entire chat room or a single participant (i.e., a private message). Note that the actual identifier may depend on the one that was used by the recipient when he or she joined the chat room.
REQ-3：チャットルームのIMの受信者は、受信したメッセージの受信者のIDを判別できる必要があります。たとえば、メッセージの受信者は、チャットルーム全体または1人の参加者（つまり、プライベートメッセージ）です。実際の識別子は、受信者がチャットルームに参加したときに使用したものに依存する場合があることに注意してください。
REQ-4: It must be possible to send a message to a single participant within the chat room (i.e., a private IM).
REQ-4：チャットルーム内の1人の参加者（つまり、プライベートIM）にメッセージを送信できる必要があります。
REQ-5: A chat room participant may have a nickname or pseudonym associated with their real identifier.
REQ-5：チャットルームの参加者には、実際の識別子に関連付けられたニックネームまたは仮名がある場合があります。
REQ-6: It must be possible for a participant to change their nickname during the progress of the chat room session.
REQ-6：チャットルームセッションの進行中に、参加者がニックネームを変更できるようにする必要があります。
REQ-7: It must be possible for a participant to be known only by an anonymous identifier and not their real identifier by the rest of the chat room.
REQ-7：参加者が匿名の識別子によってのみ認識され、チャットルームの他の部分からは実際の識別子では認識されないようにする必要があります。
REQ-8: It must be possible for chat room participants to learn the chat room capabilities described in this document.
REQ-8：チャットルームの参加者は、このドキュメントで説明されているチャットルームの機能を学習できる必要があります。
Before a chat room can be entered, it must be created. Users wishing to host a chat room themselves can, of course, do just that; their UA simply morphs from an ordinary UA into a special purpose one called a "Focus UA". Another, commonly used setup is one where a dedicated node in the network functions as a Focus UA.
チャットルームに入る前に、チャットルームを作成する必要があります。自分でチャットルームをホストしたいユーザーは、もちろんそれを行うことができます。それらのUAは、通常のUAから「フォーカスUA」と呼ばれる特別な目的に単純に変化します。別の一般的に使用されるセットアップは、ネットワーク内の専用ノードがフォーカスUAとして機能するセットアップです。
Each chat room has an identifier of its own: a SIP URI that participants use to join the chat room, e.g., by sending an INVITE request to it. The conference focus processes the invitations, and as such, maintains SIP dialogs with each participant. In a multi-party chat, or chat room, MSRP is one of the established media streams. Each chat room participant establishes an MSRP session with the MSRP switch, which is a special purpose MSRP application. The MSRP sessions can be relayed by one or more MSRP relays, which are specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1.
各チャットルームには独自の識別子があります。たとえば、INVITEリクエストをチャットルームに送信するなどして、参加者がチャットルームに参加するために使用するSIP URIです。会議のフォーカスは招待を処理し、そのため、各参加者とのSIPダイアログを維持します。マルチパーティチャットまたはチャットルームでは、MSRPは確立されたメディアストリームの1つです。チャットルームの各参加者は、MSRPスイッチとのMSRPセッションを確立します。これは、特別な目的のMSRPアプリケーションです。 MSRPセッションは、RFC 4976 [RFC4976]で指定されている1つ以上のMSRPリレーによってリレーできます。これを図1に示します。
MSRP Sessions
+--------------------------+
| |
+---+--+ +---+--+ |
| SIP | | SIP | |
| MSRP | | MSRP | +-----+-----+
|Client| |Client| | MSRP |
+---+--+ ++--+--+ | Relay |
| | \ +-----+-----+
SIP Dialogs | / +----+ |
| | \ | MSRP Sessions
+----+------+--+ | |
| | +-+-----+-----+
| Conference | | MSRP |
| Focus UA |........| Switch |
| | | |
+----+-------+-+ +-+-----+-----+
| \ | |
SIP Dialogs | | +------+ | MSRP Sessions
| \ / |
+---+--+ +-+--+-+ +-----+-----+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-----+-----+
+---+--+ +------+ |
| |
+--------------------------+
MSRP Sessions
Figure 1: Multi-party Chat Overview Shown with MSRP Relays and a Conference Focus UA
図1：MSRPリレーとConference Focus UAで表示されるマルチパーティチャットの概要
The MSRP switch is similar to a conference mixer in that it both handles media sessions with each of the participants and bridges these streams together. However, unlike a conference mixer, the MSRP switch merely forwards messages between participants: it doesn't actually mix the streams in any way. The system is illustrated in Figure 2.
MSRPスイッチは、参加者のそれぞれとのメディアセッションを処理し、これらのストリームを一緒にブリッジするという点で、会議ミキサーに似ています。ただし、会議ミキサーとは異なり、MSRPスイッチは参加者間でメッセージを転送するだけです。実際にストリームを混合することはありません。このシステムを図2に示します。
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 2: Multi-party Chat in a Centralized Chat Room
図2：集中型チャットルームでのマルチパーティチャット
Typically, chat room participants also subscribe to a conference event package to gather information about the conference roster in the form of conference state notifications. For example, participants can learn about other participants' identifiers, including their nicknames.
通常、チャットルームの参加者も会議イベントパッケージをサブスクライブして、会議名簿に関する情報を会議状態通知の形式で収集します。たとえば、参加者は、ニックネームを含む他の参加者の識別子について知ることができます。
All messages in the chat room use the Message/CPIM wrapper content type [RFC3862], to distinguish between private and regular messages. When a participant wants to send an instant message to the chat room, it constructs an MSRP SEND request and submits it to the MSRP switch including a regular payload (e.g., a Message/CPIM message that contains text, HTML, an image, etc.). The Message/CPIM To header is set to the chat room URI. The switch then fans out the SEND request to all of the other participants using their existing MSRP sessions.
チャットルーム内のすべてのメッセージは、メッセージ/ CPIMラッパーコンテンツタイプ[RFC3862]を使用して、プライベートメッセージと通常のメッセージを区別します。参加者がインスタントメッセージをチャットルームに送信する場合、MSRP SEND要求を作成し、通常のペイロード（テキスト、HTML、画像などを含むメッセージ/ CPIMメッセージなど）を含むMSRPスイッチに送信します。 ）。 Message / CPIM Toヘッダーは、チャットルームURIに設定されます。次に、スイッチは既存のMSRPセッションを使用して、SEND要求を他のすべての参加者にファンアウトします。
A participant can also send a private IM addressed to a participant whose identifier has been learned, e.g., via a conference event package. In this case, the sender creates an MSRP SEND request with a Message/CPIM wrapper whose To header contains not the chat room URI but the recipient's URI. The MSRP switch then forwards the SEND request to that recipient. This specification supports the sending of private messages to one and only one recipient. However, if the recipient is logged in from different endpoints, the MSRP switch will distribute the private message to each endpoint at which the recipient is logged in.
参加者は、たとえば会議イベントパッケージを介して、識別子が学習された参加者にアドレス指定されたプライベートIMを送信することもできます。この場合、送信者は、メッセージ/ CPIMラッパーを使用してMSRP SEND要求を作成し、そのToヘッダーにチャットルームのURIではなく受信者のURIを含めます。次に、MSRPスイッチはSEND要求をその受信者に転送します。この仕様は、1人の受信者へのプライベートメッセージの送信をサポートしています。ただし、受信者が異なるエンドポイントからログインしている場合、MSRPスイッチは、受信者がログインしている各エンドポイントにプライベートメッセージを配信します。
We extend the current MSRP negotiation that takes place in SDP [RFC4566] to allow participants to learn whether the chat room supports and is willing to accept (e.g., due to local policy restrictions) certain MSRP functions defined in this memo, such as nicknames or private messaging. This is achieved by a new 'chatroom' attribute in SDP (please refer to Section 8 for a detailed description).
SDP [RFC4566]で行われている現在のMSRPネゴシエーションを拡張して、ニックネームやこのメモで定義されている特定のMSRP機能（たとえば、ローカルポリシーの制限により）がチャットルームをサポートし、受け入れる用意があるかどうかを参加者が学習できるようにします。プライベートメッセージング。これは、SDPの新しい「チャットルーム」属性によって実現されます（詳細については、セクション8を参照してください）。
Naturally, when a participant wishes to leave a chat room, it sends a SIP BYE request to the Focus UA and terminates the SIP dialog with the focus and MSRP sessions with the MSRP switch.
当然、参加者がチャットルームを離れたい場合は、SIP BYE要求をフォーカスUAに送信し、フォーカスを使用してSIPダイアログを終了し、MSRPスイッチを使用してMSRPセッションを終了します。
This document assumes that each chat room is allocated its own SIP URI. A user joining a chat room sends an INVITE request to that SIP URI, and, as a result, a new MSRP session is established between the user and the MSRP switch. It is assumed that an MSRP session is mapped to a chat room. If a user wants to join a second chat room, he creates a different INVITE request, through a different SIP dialog, which leads to the creation of a second MSRP session between the user and the MSRP switch. Notice that these two MSRP sessions can still be multiplexed over the same TCP connection as per regular MSRP procedures. However, each chat room is associated with a unique MSRP session and a unique SIP dialog.
このドキュメントでは、各チャットルームに独自のSIP URIが割り当てられていることを前提としています。チャットルームに参加するユーザーは、そのSIP URIにINVITE要求を送信し、その結果、ユーザーとMSRPスイッチの間に新しいMSRPセッションが確立されます。 MSRPセッションがチャットルームにマップされていることを前提としています。ユーザーが2番目のチャットルームに参加したい場合は、別のSIPダイアログを介して別のINVITE要求を作成します。これにより、ユーザーとMSRPスイッチの間に2番目のMSRPセッションが作成されます。これらの2つのMSRPセッションは、通常のMSRP手順と同じように、同じTCP接続で引き続き多重化できることに注意してください。ただし、各チャットルームは、一意のMSRPセッションと一意のSIPダイアログに関連付けられています。
The Conference Framework with SIP [RFC4353] introduces the notion of a Conference Policy as "The complete set of rules governing a particular conference." A chat room is a specialized type of conference, and the conference policy is sometimes extended with new chat-specific rules. This section lists all the Conference Policy attributes used by the present document and refers to sections in the document where the usage of these attributes are described in greater detail.
SIPを使用した会議フレームワーク[RFC4353]では、「特定の会議を管理する一連の完全なルール」として会議ポリシーの概念が導入されています。チャットルームは特別な種類の会議であり、会議ポリシーは新しいチャット固有のルールで拡張される場合があります。このセクションでは、現在のドキュメントで使用されるすべての会議ポリシー属性をリストし、これらの属性の使用法が詳細に説明されているドキュメントのセクションを参照します。
Nicknames: Whether the chat room accepts users to be recognized with a nickname. See Sections 7, 7.1, and 8 for details. Also, the scope of uniqueness of the nickname: the chat room (conference instance), a realm or domain, a server, etc.
ニックネーム：ユーザーがニックネームで認識されることをチャットルームが受け入れるかどうか。詳細については、セクション7、7.1、および8を参照してください。また、ニックネームの一意性の範囲：チャットルーム（会議インスタンス）、レルムまたはドメイン、サーバーなど。
Nickname quarantine: The quarantine to be imposed on a nickname once it is not currently in use (e.g., because the participant holding this nickname abandons the chat room), prior to the wide availability of this nickname to other users. This allows the initial holder of the nickname to join the chat room during the quarantine period and claim the same nickname they were previously using. See Section 11 for details.
ニックネームの検疫：ニックネームが現在使用されていないときに（たとえば、このニックネームを保持している参加者がチャットルームを放棄したため）、このニックネームが他のユーザーに広く利用される前に、ニックネームに課される検疫。これにより、ニックネームの最初の所有者は、検疫期間中にチャットルームに参加し、以前使用していた同じニックネームを要求できます。詳細については、セクション11を参照してください。
Private messaging: Whether the chat room allows users to send private messages to other users of the chat room through the MSRP switch. See Sections 6.2 and 8 for details.
プライベートメッセージング：チャットルームでユーザーがMSRPスイッチを介してチャットルームの他のユーザーにプライベートメッセージを送信できるかどうか。詳細については、セクション6.2および8を参照してください。
Deletion of the chat room: Whether the chat room can be deleted when the creator leaves the chat room or through an out-of-band mechanism. See Section 5.3 for details.
チャットルームの削除：作成者がチャットルームを離れたとき、またはアウトオブバンドメカニズムを介して、チャットルームを削除できるかどうか。詳細については、セクション5.3を参照してください。
Simultaneous access: Whether a user can log in from different endpoints using the same identity. See Sections 6.1 and 6.2 for details.
同時アクセス：ユーザーが同じIDを使用して異なるエンドポイントからログインできるかどうか。詳細については、セクション6.1および6.2を参照してください。
Force TLS transport: Whether the MSRP switch accepts only Transport Layer Security (TLS) as an MSRP transport, in an effort to guarantee confidentiality and privacy. See Section 11 for details.
TLSトランスポートを強制する：機密性とプライバシーを保証するために、MSRPスイッチがトランスポート層セキュリティ（TLS）のみをMSRPトランスポートとして受け入れるかどうか。詳細については、セクション11を参照してください。
Maximum message size in congested MSRP sessions: The maximum size of messages that can be distributed to a user over a congested MSRP session. See Section 6.4 for details.
混雑したMSRPセッションでの最大メッセージサイズ：混雑したMSRPセッションを介してユーザーに配信できるメッセージの最大サイズ。詳細については、セクション6.4を参照してください。
Chunk reception timer: The value of a time that controls the maximum time that the MSRP switch is waiting for the reception of different chunks belonging to the same message. If the timer expires, the MSRP switch will discard the associated message state. See Section 6.1 for details.
チャンク受信タイマー：同じメッセージに属する異なるチャンクの受信をMSRPスイッチが待機する最大時間を制御する時間の値。タイマーの期限が切れると、MSRPスイッチは関連するメッセージの状態を破棄します。詳細については、セクション6.1を参照してください。
Supported wrapped media types: The list of media types that the MSRP switch accepts in Message/CPIM wrappers sent from participants. This list is included in the 'accept-wrapped-types' attribute of the MSRP message media line in SDP. If the MSRP switch accepts additional media types to those explicitly listed, a "*" is added to the list. A single "*" indicates that the chat room accepts any wrapped media type.
サポートされているラップされたメディアタイプ：MSRPスイッチが参加者から送信されたメッセージ/ CPIMラッパーで受け入れるメディアタイプのリスト。このリストは、SDPのMSRPメッセージメディア行の「accept-wrapped-types」属性に含まれています。 MSRPスイッチが明示的にリストされているメディアタイプに追加のメディアタイプを受け入れる場合、リストに「*」が追加されます。単一の「*」は、チャットルームがラップされたメディアタイプを受け入れることを示します。
Since we consider a chat room a particular type of conference having MSRP media, the methods defined by the SIP Conference Framework [RFC4353] for creating conferences are directly applicable to a chat room.
チャットルームはMSRPメディアを使用する特定の種類の会議であると考えているため、会議を作成するためのSIP会議フレームワーク[RFC4353]で定義されている方法は、チャットルームに直接適用できます。
Once a chat room is created, it is identified by a SIP URI, like any other conference.
チャットルームが作成されると、他の会議と同様に、SIP URIによって識別されます。
Participants usually join the chat room by sending an INVITE request to the chat room URI. The chat room then uses regular SIP mechanisms to authenticate the participant. This may include, e.g., client certificates, SIP Digest authentication [RFC3261], asserted network identity [RFC3325], SIP Identity header field [RFC4474], etc. As long as the user is authenticated, the INVITE request is accepted by the focus and the user is brought into the actual chat room.
参加者は通常、チャットルームのURIにINVITEリクエストを送信して、チャットルームに参加します。次に、チャットルームは通常のSIPメカニズムを使用して参加者を認証します。これには、たとえば、クライアント証明書、SIPダイジェスト認証[RFC3261]、アサートされたネットワークID [RFC3325]、SIP Identityヘッダーフィールド[RFC4474]などが含まれます。ユーザーが認証されている限り、INVITEリクエストはフォーカスとユーザーは実際のチャットルームに移動します。
This specification requires all IMs to be wrapped in a Message/CPIM wrapper [RFC3862]. Therefore, the 'accept-types' attribute for the MSRP message media in both the SDP offer and answer need to include at least the value 'Message/CPIM' (notice that RFC 4975 [RFC4975] mandates this 'accept-types' attribute in SDP). If the 'accept-types' attribute does not contain the value 'Message/CPIM', the conference focus will reject the request. The actual instant message payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). There is no default wrapped type. Typical wrapped type values can include text/plain, text/html, image/jpeg, image/png, audio/mp3, etc. It is RECOMMENDED that participant endpoints add an 'accept-wrapped-types' attribute to the MSRP 'message' media line in SDP, where the supported wrapped types are declared, as per RFC 4975 procedures [RFC4975].
この仕様では、すべてのIMをMessage / CPIMラッパー[RFC3862]でラップする必要があります。したがって、SDPオファーとアンサーの両方のMSRPメッセージメディアの「accept-types」属性には、少なくとも「Message / CPIM」という値を含める必要があります（RFC 4975 [RFC4975]では、この「accept-types」属性がSDP）。 「accept-types」属性に値「Message / CPIM」が含まれていない場合、会議のフォーカスは要求を拒否します。実際のインスタントメッセージのペイロードタイプは、SDPの 'accept-wrapped-types'属性でネゴシエートされます（詳細については、RFC 4975 [RFC4975]を参照してください）。デフォルトのラップタイプはありません。一般的なラップされたタイプの値には、text / plain、text / html、image / jpeg、image / png、audio / mp3などを含めることができます。参加者のエンドポイントが「accept-wrapped-types」属性をMSRPの「メッセージ」に追加することをお勧めしますRFC 4975手順[RFC4975]に従って、サポートされているラップされたタイプが宣言されているSDPのメディア行。
The MSRP switch needs to be aware of the URIs of the participant (SIP, tel, or IM URIs) in order to validate messages sent from this participant prior to their forwarding. This information is known to the focus of the conference. Therefore, an interface between the focus and the MSRP switch is assumed. However, the interface between the focus and the MSRP switch is outside the scope of this document.
MSRPスイッチは、転送前にこの参加者から送信されたメッセージを検証するために、参加者のURI（SIP、Tel、またはIM URI）を認識する必要があります。この情報は会議の中心に知られています。したがって、フォーカスとMSRPスイッチ間のインターフェイスが想定されます。ただし、フォーカスとMSRPスイッチ間のインターフェイスは、このドキュメントの範囲外です。
Conference-aware participants will detect that the peer is a focus due to the presence of the "isfocus" feature tag [RFC3840] in the Contact header field of the 200-class response to the INVITE request. Conference-unaware participants will not notice it is a focus, and cannot apply the additional mechanisms defined in this document. Participants are also aware that the mixer is an MSRP switch due to the presence of a 'message' media type and either TCP/MSRP or TCP/TLS/MSRP as the protocol field in the media line of SDP [RFC4566].
会議対応の参加者は、INVITE要求に対する200クラスの応答のContactヘッダーフィールドに「isfocus」機能タグ[RFC3840]が存在するため、ピアがフォーカスされていることを検出します。会議に対応していない参加者は、それがフォーカスされていることに気付かず、このドキュメントで定義されている追加のメカニズムを適用できません。参加者は、「メッセージ」メディアタイプと、SDP [RFC4566]のメディアラインのプロトコルフィールドとしてTCP / MSRPまたはTCP / TLS / MSRPが存在するため、ミキサーがMSRPスイッチであることも認識しています。
The conference focus of a chat room MUST only use a Message/CPIM [RFC3862] top-level wrapper as a payload of MSRP messages, and the focus MUST declare it in the SDP offer or answer as per regular procedures in RFC 4975 [RFC4975]. This implies that if the conference focus receives, from a participant's endpoint, an SDP offer that does not include the value 'Message/CPIM' in the 'accept-types' attribute for the MSRP message media line, the conference focus SHOULD either reject the MSRP message media stream or reject the complete SDP offer by using regular SIP or SDP procedures (e.g., creating an SDP answer that sets to zero the port of the MSRP message media line, responding the INVITE with a 488 response, etc.).
チャットルームの会議フォーカスは、MSRPメッセージのペイロードとしてメッセージ/ CPIM [RFC3862]トップレベルラッパーのみを使用する必要があり、フォーカスは、RFC 4975 [RFC4975]の通常の手順に従って、SDPオファーまたは応答でそれを宣言する必要があります。 。これは、会議のフォーカスが参加者のエンドポイントから、MSRPメッセージメディア行の「accept-types」属性に値「Message / CPIM」を含まないSDPオファーを受信した場合、会議のフォーカスは、 MSRPメッセージメディアストリーム、または通常のSIPまたはSDP手順を使用して完全なSDPオファーを拒否（たとえば、MSRPメッセージメディアラインのポートをゼロに設定するSDP応答の作成、488応答でのINVITEへの応答など）。
If the conference focus accepts the participant's SDP offer, when the conference focus generates the SDP answer, it MUST set the 'accept-types' attribute for the MSRP message media line to a value of 'Message/CPIM'. This specification requires all IMs to be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types' attribute in this SDP body contains a single value of 'Message/CPIM'. The actual IM payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). The conference focus MAY also add an 'accept-wrapped-types' attribute to the MSRP message media line in SDP containing the supported wrapped types, according to the supported wrapped media types policy.
会議のフォーカスが参加者のSDPオファーを受け入れる場合、会議のフォーカスがSDP回答を生成するときに、MSRPメッセージメディア行の「accept-types」属性を「Message / CPIM」の値に設定する必要があります。この仕様では、すべてのIMをMessage / CPIMラッパーでラップする必要があるため、このSDP本体の「accept-types」属性には「Message / CPIM」の単一の値が含まれています。実際のIMペイロードタイプは、SDPの 'accept-wrapped-types'属性でネゴシエートされます（詳細については、RFC 4975 [RFC4975]を参照してください）。会議のフォーカスは、サポートされているラップされたメディアタイプのポリシーに従って、サポートされているラップされたタイプを含むSDPのMSRPメッセージメディア行に「accept-wrapped-types」属性を追加することもできます（MAY）。
Note that the Message/CPIM wrapper is used to carry the sender information that, otherwise, it will not be available to the recipient. Additionally, the Message/CPIM wrapper carries the recipient information (e.g., To and Cc headers).
Message / CPIMラッパーは、送信者情報を運ぶために使用されることに注意してください。そうしないと、受信者は使用できません。さらに、メッセージ/ CPIMラッパーは受信者情報（ToヘッダーやCcヘッダーなど）を伝送します。
If the UA supports anonymous participation and the user chooses to use it, the participant's UA SHOULD do at least one of these options:
UAが匿名参加をサポートし、ユーザーがそれを使用することを選択した場合、参加者のUAはこれらのオプションの少なくとも1つを実行する必要があります。
(a) provide an anonymous URI in SIP headers that otherwise reveal identifiers. Please refer to RFC 3323 [RFC3323] for a detailed description of which headers are subject to reveal identifiers and how to populate them; or
（a）識別子を明らかにするSIPヘッダーで匿名URIを提供します。識別子が明らかになる可能性のあるヘッダーの詳細な説明とそれらの入力方法については、RFC 3323 [RFC3323]を参照してください。または
(b) trust the conference focus and request privacy of their URI, e.g., by means of the SIP Privacy header field [RFC3323], network asserted identity [RFC3325], or a similar privacy mechanism.
（b）会議のフォーカスを信頼し、SIPプライバシーヘッダーフィールド[RFC3323]、ネットワークアサートID [RFC3325]、または同様のプライバシーメカニズムなどを使用して、URIのプライバシーを要求します。
If the participant has requested privacy, the conference focus MUST expose a participant's anonymous URI through the conference event package [RFC4575].
参加者がプライバシーを要求した場合、会議のフォーカスは、会議イベントパッケージ[RFC4575]を通じて参加者の匿名URIを公開する必要があります。
The conference focus of a chat room learns the supported chat room capabilities in the endpoint by means of the 'chatroom' attribute exchanged in the SDP offer/answer (please refer to Section 8 for a detailed description). The conference focus MUST inform the MSRP switch of the chat room capabilities of each participant that joins the chat room (note that the interface defined between the conference focus and the MSRP switch is outside the scope of this specification). This information allows the MSRP switch, e.g., to avoid the distribution of private messages to participants whose endpoints do not support private messaging.
チャットルームの会議の焦点は、SDPオファー/アンサーで交換される 'chatroom'属性によって、エンドポイントでサポートされるチャットルーム機能を学習します（詳細については、セクション8を参照してください）。会議フォーカスは、チャットルームに参加する各参加者のチャットルーム機能をMSRPスイッチに通知する必要があります（会議フォーカスとMSRPスイッチの間に定義されたインターフェイスは、この仕様の範囲外であることに注意してください）。この情報により、MSRPスイッチは、たとえば、エンドポイントがプライベートメッセージングをサポートしていない参加者へのプライベートメッセージの配信を回避できます。
As with creating a conference, the methods defined by the SIP Conference Framework [RFC4353] for deleting a conference are directly applicable to a chat room. The MSRP switch will terminate the MSRP sessions with all the participants.
会議の作成と同様に、会議を削除するためのSIP会議フレームワーク[RFC4353]で定義されているメソッドは、チャットルームに直接適用できます。 MSRPスイッチは、すべての参加者とのMSRPセッションを終了します。
Deleting a chat room is an action that heavily depends on the policy of the chat room. For example, the policy can determine whether the chat room is deleted when the creator leaves the room or whether an out-of-band mechanism is responsible for the deletion.
チャットルームの削除は、チャットルームのポリシーに大きく依存するアクションです。たとえば、ポリシーは、作成者がチャットルームを離れたときにチャットルームが削除されるかどうか、または帯域外メカニズムが削除の原因であるかどうかを決定できます。
This section describes the conventions used to send and receive IMs that are addressed to all the participants in the chat room. These are sent over a regular MSRP SEND request that contains a Message/ CPIM wrapper [RFC3862] that, in turn, contains the desired payload (e.g., text, image, video clip, etc.).
このセクションでは、チャットルームのすべての参加者に宛てられたIMの送受信に使用される規則について説明します。これらは、メッセージ/ CPIMラッパー[RFC3862]を含む通常のMSRP SENDリクエストを介して送信されます。このラッパーには、目的のペイロード（テキスト、画像、ビデオクリップなど）が含まれています。
When a chat room participant wishes to send an instant message to all the other participants in the chat room, it constructs an MSRP SEND request according to the procedures specified in RFC 4975 [RFC4975]. The sender MAY choose the desired MSRP report model (e.g., populate the Success-Report and Failure-Report MSRP header fields).
チャットルームの参加者がチャットルームの他のすべての参加者にインスタントメッセージを送信する場合、RFC 4975 [RFC4975]で指定された手順に従ってMSRP SEND要求を作成します。送信者は、希望のMSRPレポートモデルを選択できます（たとえば、Success-ReportおよびFailure-Report MSRPヘッダーフィールドに入力します）。
On sending a regular message, the sender MUST populate the To header of the Message/CPIM wrapper with the URI of the chat room. The sender MUST also populate the From header of the Message/CPIM wrapper with a proper identifier by which the user is recognized in the chat room. Identifiers that can be used (among others) are: o A SIP URI [RFC3261] representing the participant's address-of-record
通常のメッセージを送信する場合、送信者はMessage / CPIMラッパーのToヘッダーにチャットルームのURIを入力する必要があります。送信者は、メッセージ/ CPIMラッパーのFromヘッダーに、ユーザーがチャットルームで認識される適切な識別子を設定する必要もあります。 （とりわけ）使用できる識別子は次のとおりです。o参加者のレコードのアドレスを表すSIP URI [RFC3261]
o A tel URI [RFC3966] representing the participant's telephone number
o 参加者の電話番号を表すtel URI [RFC3966]
o An IM URI [RFC3860] representing the participant's instant messaging address
o 参加者のインスタントメッセージングアドレスを表すIM URI [RFC3860]
o An anonymous URI representing the participant's anonymous address
o 参加者の匿名アドレスを表す匿名URI
If the participant wants to remain anonymous, the participant's endpoint MUST populate an anonymous URI in the From header of the Message/CPIM wrapper. Other participants of the chat room will use this anonymous URI in the To header of the Message/CPIM wrapper when sending private messages. Notice that in order for the anonymity mechanism to work, the anonymous URI MUST NOT reveal the participant's SIP AOR. The mechanism for acquiring an anonymous URI is outside the scope of this specification.
参加者が匿名のままでいることを望む場合、参加者のエンドポイントは、メッセージ/ CPIMラッパーのFromヘッダーに匿名URIを入力する必要があります。チャットルームの他の参加者は、プライベートメッセージを送信するときに、メッセージ/ CPIMラッパーのToヘッダーでこの匿名URIを使用します。匿名性メカニズムが機能するためには、匿名URIが参加者のSIP AORを公開してはならないことに注意してください。匿名URIを取得するメカニズムは、この仕様の範囲外です。
An MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI of a participant. This imposes a requirement for the focus of the conference to inform the MSRP switch of the URIs by which the participant is known, in order for the MSRP switch to validate messages. Section 6.3 provides further information with the actions to be taken in case this validation fails.
参加者からSEND要求を受信するMSRPスイッチは、最初に、メッセージ/ CPIMラッパーのFromヘッダーフィールドに参加者の有効なURIが正しく入力されていることを確認する必要があります（SHOULD）。これは、MSRPスイッチがメッセージを検証するために、会議の焦点が参加者の既知のURIをMSRPスイッチに通知するための要件を課します。セクション6.3は、この検証が失敗した場合に実行するアクションについての詳細情報を提供します。
Then the MSRP switch should inspect the To header field of the Message/CPIM wrapper. If the MSRP switch receives a message containing several To header fields in the Message/CPIM wrapper the MSRP switch MUST reject the MSRP SEND request with a 403 response, as per procedures in RFC 4975 [RFC4975]. Then, if the To header field of the Message/CPIM wrapper contains the chat room URI and there are no other To header fields, the MSRP switch can generate a copy of the SEND request to each of the participants in the chat room except the sender. The MSRP switch MUST NOT modify the content received in the SEND request. However, the MSRP switch MAY re-chunk any of the outbound MSRP SEND requests.
次に、MSRPスイッチは、メッセージ/ CPIMラッパーのToヘッダーフィールドを検査する必要があります。 MSRPスイッチがメッセージ/ CPIMラッパーに複数のToヘッダーフィールドを含むメッセージを受信する場合、MSRPスイッチは、RFC 4975 [RFC4975]の手順に従って、403応答でMSRP SEND要求を拒否する必要があります。次に、メッセージ/ CPIMラッパーのToヘッダーフィールドにチャットルームURIが含まれていて、他のToヘッダーフィールドがない場合、MSRPスイッチは、送信者以外のチャットルームの各参加者にSEND要求のコピーを生成できます。 。 MSRPスイッチは、SEND要求で受信したコンテンツを変更してはなりません。ただし、MSRPスイッチは任意の発信MSRP SEND要求を再チャンクする場合があります。
When generating a copy of the SEND request to each participant in the chat room, the MSRP switch MUST evaluate the wrapped media types that the recipient is able to accept. This was learned through the 'accept-wrapped-types' attribute of the MSRP message media line in SDP. If the MSRP switch is aware that the media type of the wrapped content is not acceptable to the recipient, the MSRP switch SHOULD NOT forward this message to that endpoint. Note that this version of the specification does not require the MSRP switch to notify the sender about this failure. Extensions to this specification may improve handling of unknown media types.
チャットルームの各参加者へのSEND要求のコピーを生成するとき、MSRPスイッチは、受信者が受け入れることができるラップされたメディアタイプを評価する必要があります。これは、SDPのMSRPメッセージメディア行の「accept-wrapped-types」属性を通じて学習されました。ラップされたコンテンツのメディアタイプが受信者に受け入れられないことをMSRPスイッチが認識している場合、MSRPスイッチはこのメッセージをそのエンドポイントに転送すべきではありません（SHOULD NOT）。このバージョンの仕様では、この失敗について送信者に通知するためにMSRPスイッチは必要ありません。この仕様を拡張すると、不明なメディアタイプの処理が改善される場合があります。
Note that the MSRP switch does not need to wait for the reception of the complete MSRP chunk or MSRP message before it starts the distribution to the rest of the participants. Instead, once the MSRP switch has received the headers of the Message/CPIM wrapper, it SHOULD start the distribution process. But, bear in mind that the MSRP switch SHOULD still implement some sanity checking. Please refer to the security considerations in Section 11 for further details.
MSRPスイッチは、残りの参加者への配信を開始する前に、完全なMSRPチャンクまたはMSRPメッセージの受信を待つ必要がないことに注意してください。代わりに、MSRPスイッチがメッセージ/ CPIMラッパーのヘッダーを受信すると、配布プロセスを開始する必要があります。ただし、MSRPスイッチは、いくつかの健全性チェックを実装する必要があることに注意してください。詳細については、セクション11のセキュリティに関する考慮事項を参照してください。
When forwarding chunked messages as soon as they are received, the Message/CPIM wrapper is only present at the beginning of the message, typically within the first chunk. Subsequent chunks will contain the rest of the message, but not the Message/CPIM headers. Therefore, an MSRP switch that receives a subsequent message may face challenges in determining the correct list of recipients of the message. An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-ID of the MSRP message to correlate the different chunks; it MUST also temporarily store the list of recipients to which the initial chunks were delivered. The MSRP switch SHOULD forward subsequent chunks only to those recipients who were sent the initial chunks, except if the MSRP switch has knowledge that one of the recipients of the initial chunks has dropped from the chat room. This behavior also avoids new participants who had joined the chat room when the first chunk was distributed from receiving subsequent chunks that would otherwise need to be discarded.
チャンクされたメッセージを受信するとすぐに転送する場合、メッセージ/ CPIMラッパーはメッセージの先頭、通常は最初のチャンク内にのみ存在します。後続のチャンクにはメッセージの残りの部分が含まれますが、メッセージ/ CPIMヘッダーは含まれません。したがって、後続のメッセージを受信するMSRPスイッチは、メッセージの受信者の正しいリストを決定する際に課題に直面する可能性があります。この高速転送手順を使用するMSRPスイッチは、さまざまなチャンクを関連付けるために、MSRPメッセージのメッセージIDを一時的に格納する必要があります。また、最初のチャンクが配信された受信者のリストを一時的に保存する必要があります。 MSRPスイッチは、最初のチャンクの受信者の1人がチャットルームからドロップしたことをMSRPスイッチが知っている場合を除いて、最初のチャンクが送信された受信者にのみ後続のチャンクを転送する必要があります（SHOULD）。この動作により、最初のチャンクが配布されたときにチャットルームに参加していた新しい参加者が、破棄する必要がある後続のチャンクを受信することも回避されます。
Once the MSRP switch receives the last chunk of a message, and that chunk is successfully sent to each of the recipients, the MSRP switch discards the temporary storage of MSRP Message-ID and the associated list of recipients.
MSRPスイッチがメッセージの最後のチャンクを受信し、そのチャンクが各受信者に正常に送信されると、MSRPスイッチはMSRPメッセージIDとそれに関連する受信者のリストの一時ストレージを破棄します。
In some occasions, a sender might suffer a transport error condition (such as loss of connectivity or depletion of battery) that makes the sending of a message incomplete, e.g., some chunks were received by the MSRP switch, but not all of them. This is a behavior already considered in the core MSRP specification (see RFC 4975 [RFC4975] Section 5.4). The problem in the context of a chat room lies with the use of temporary storage for fast forwarding. In order to prevent attacks related to the exhaustion of temporary storage of chunked messages, on receiving a first chunk of a message, where the MSRP switch is using the fast forward method, the MSRP switch MUST set a chunk reception timer for controlling the reception of the remaining chunks.
場合によっては、送信者がトランスポートエラー状態（接続の喪失やバッテリーの枯渇など）に悩まされ、メッセージの送信が不完全になることがあります。これは、コアMSRP仕様ですでに考慮されている動作です（RFC 4975 [RFC4975]セクション5.4を参照）。チャットルームのコンテキストでの問題は、高速転送のための一時ストレージの使用にあります。チャンクメッセージの一時ストレージの枯渇に関連する攻撃を防ぐために、MSRPスイッチが早送り方式を使用しているメッセージの最初のチャンクを受信すると、MSRPスイッチはチャンク受信タイマーを設定して、残りのチャンク。
This chunk reception timer can be reset every time a new chunk of the same message is received. When this timer expires, the MSRP switch MUST consider that the sending of the message was aborted, and it MAY discard all the message state associated with it, including the Message-ID and the list of recipients. Additionally, if this chunk reception timer expires, the MSRP switch MAY choose to send an abort chunk (i.e., one with the "#" flag set) to each to the recipients. This is just an optimization, since MSRP endpoints need to be able to handle incomplete messages as per regular MSRP.
このチャンク受信タイマーは、同じメッセージの新しいチャンクが受信されるたびにリセットできます。このタイマーが時間切れになると、MSRPスイッチはメッセージの送信が中止されたことを考慮しなければならず（MUST）、メッセージIDや受信者のリストなど、それに関連付けられているすべてのメッセージの状態を破棄してもよい（MAY）。さらに、このチャンク受信タイマーが期限切れになった場合、MSRPスイッチはアボートチャンク（「＃」フラグが設定されたチャンク）をそれぞれの受信者に送信することを選択できます（MAY）。 MSRPエンドポイントは通常のMSRPと同様に不完全なメッセージを処理できる必要があるため、これは単なる最適化です。
The specific value of this chunk reception timer is not standardized; it is subject of local policy. However, it is recommended not to be a short value. For example, a time interval on the order of a normal TCP timeout (i.e., around 540 seconds) would be reasonable. A value on the order of a few seconds would not.
このチャンク受信タイマーの特定の値は標準化されていません。ローカルポリシーの対象です。ただし、短い値にしないことをお勧めします。たとえば、通常のTCPタイムアウト程度の時間間隔（つまり、約540秒）が妥当です。数秒程度の値ではありません。
An MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM wrapper. If the To header field is set to the chat room URI, it should render it as a regular message that has been distributed to all the participants in the chat room. Then, the MSRP endpoint SHOULD inspect the From header field of the Message/ CPIM wrapper to identify the sender. The From header field will include a URI that identifies the sender. The endpoint might have also received further identifier information through a subscription to a conference event package.
メッセージ/ CPIMラッパーを含むMSRPスイッチからSEND要求を受信するMSRPエンドポイントは、まずメッセージ/ CPIMラッパーのToヘッダーフィールドを検査する必要があります。 ToヘッダーフィールドがチャットルームのURIに設定されている場合は、チャットルームのすべての参加者に配信される通常のメッセージとしてレンダリングする必要があります。次に、MSRPエンドポイントは、メッセージ/ CPIMラッパーのFromヘッダーフィールドを検査して送信者を識別する必要があります（SHOULD）。 Fromヘッダーフィールドには、送信者を識別するURIが含まれます。エンドポイントは、会議イベントパッケージへのサブスクリプションを通じて追加の識別子情報を受信した可能性もあります。
It is possible that a participant, identified by a SIP AoR or other valid URI, joins a chat room simultaneously from two or more different SIP UAs. It is recommended that the MSRP switch implements means to map a URI to two or more MSRP sessions. If the policy of the chat room allows simultaneous access, the MSRP switch MUST copy all regular messages intended to the recipient through each MSRP session mapped to the recipient's URI.
SIP AoRまたはその他の有効なURIによって識別された参加者が、2つ以上の異なるSIP UAから同時にチャットルームに参加する可能性があります。 MSRPスイッチは、URIを2つ以上のMSRPセッションにマップする手段を実装することをお勧めします。チャットルームのポリシーが同時アクセスを許可する場合、MSRPスイッチは、受信者のURIにマッピングされた各MSRPセッションを介して、受信者宛のすべての通常のメッセージをコピーする必要があります。
This section describes the conventions used to send and receive private IMs, i.e., IMs that are addressed to one participant of the chat room rather than to all of them. The chat room has a local policy that determines whether or not private messages are supported. A chat room can signal support for private messages using the 'chatroom' attribute in SDP (please refer to Section 8 for a detailed description).
このセクションでは、プライベートIM、つまりチャットルームのすべての参加者ではなく1人の参加者に宛てられたIMの送受信に使用される規則について説明します。チャットルームには、プライベートメッセージがサポートされるかどうかを決定するローカルポリシーがあります。チャットルームは、SDPの 'chatroom'属性を使用してプライベートメッセージのサポートを通知できます（詳細については、セクション8を参照してください）。
When a chat room participant wishes to send a private IM to a participant in the chat room, it follows the same procedures to create a SEND request as for regular messages (Section 6.1). The
チャットルームの参加者がプライベートIMをチャットルームの参加者に送信する場合、通常のメッセージの場合と同じ手順でSENDリクエストを作成します（セクション6.1）。の
only difference is that the MSRP endpoint MUST populate a single To header of the Message/CPIM wrapper with the identifier of the intended recipient. The identifier can be SIP, tel, and im URIs typically learned from the information received in notifications of a conference event package.
唯一の違いは、MSRPエンドポイントは、メッセージ/ CPIMラッパーの単一のToヘッダーに、目的の受信者の識別子を設定する必要があることです。識別子は、通常、会議イベントパッケージの通知で受信した情報から学習したSIP、tel、im URIです。
This version of the specification does not support sending a private message to multiple recipients, i.e., the presence of multiple To headers in the Message/CPIM wrapper of the MSRP SEND request. This is due to added complexity, for example, with the need to determine whether a message was not delivered to some of the intended recipients. Implementations that still want to recreate this function can send a series of single private messages, one private message per intended recipient. The endpoint can correlate this series of messages and create the effect of a private message addressed to multiple recipients.
このバージョンの仕様では、プライベートメッセージを複数の受信者に送信すること、つまり、MSRP SENDリクエストのメッセージ/ CPIMラッパーに複数のToヘッダーが存在することはサポートされていません。これは、メッセージが意図された受信者の一部に配信されなかったかどうかを判断する必要があるなど、複雑さが増したためです。この機能を再作成したい実装は、一連の単一のプライベートメッセージを送信できます。目的の受信者ごとに1つのプライベートメッセージを送信できます。エンドポイントは、この一連のメッセージを相互に関連付け、複数の受信者宛のプライベートメッセージの効果を作成できます。
As for regular messages, an MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI (i.e., the URI is a participant of this chat room). Section 6.3 provides further information regarding the actions to be taken in case this validation fails.
通常のメッセージの場合と同様に、参加者からSEND要求を受信するMSRPスイッチは、まずメッセージ/ CPIMラッパーのFromヘッダーフィールドに有効なURIが正しく入力されていることを確認する必要があります（つまり、URIはこのチャットルームの参加者です）。 。セクション6.3は、この検証が失敗した場合に実行するアクションに関する詳細情報を提供します。
Then, the MSRP switch inspects the To header field of the Message/ CPIM wrapper. If the MSRP switch receives a message containing several To header fields in the Message/CPIM wrapper, the MSRP switch MUST reject the MSRP SEND request with a 403 response, as per procedures in RFC 4975 [RFC4975]. Then, the MSRP switch verifies that the To header of the Message/CPIM wrapper matches the URI of a participant of the chat room. If this To header field does not contain the URI of a participant of the chat room or if the To header field cannot be resolved (e.g., caused by a mistyped URI), the MSRP switch MUST reject the request with a 404 response. This new 404 status code indicates a failure to resolve the recipient URI in the To header field of the Message/CPIM wrapper.
次に、MSRPスイッチは、Message / CPIMラッパーのToヘッダーフィールドを検査します。 MSRPスイッチがメッセージ/ CPIMラッパーに複数のToヘッダーフィールドを含むメッセージを受信した場合、MSRPスイッチはRFC 4975 [RFC4975]の手順に従って、403応答でMSRP SEND要求を拒否する必要があります。次に、MSRPスイッチは、メッセージ/ CPIMラッパーのToヘッダーがチャットルームの参加者のURIと一致することを確認します。このToヘッダーフィールドにチャットルームの参加者のURIが含まれていない場合、またはToヘッダーフィールドを解決できない場合（URIの入力ミスなどが原因）、MSRPスイッチは404応答でリクエストを拒否する必要があります。この新しい404ステータスコードは、メッセージ/ CPIMラッパーのToヘッダーフィールドの受信者URIを解決できないことを示しています。
Notice the importance of the From and To headers in the Message/ CPIM wrapper. If an intermediary modifies these values, the MSRP switch might not be able to identify the source or intended destination of the message, resulting in a rejection of the message.
Message / CPIMラッパーのFromおよびToヘッダーの重要性に注意してください。仲介者がこれらの値を変更すると、MSRPスイッチがメッセージの送信元または目的の宛先を識別できなくなり、メッセージが拒否される可能性があります。
Finally, the MSRP switch verifies that the recipient supports private messages. If the recipient does not support private messages, the MSRP switch MUST reject the request with a 428 response. This new 428 response indicates that the recipient does not support private messages. Any potential REPORT request that the MSRP switch sends to the sender MUST include a Message/CPIM wrapper containing the original From header field included in the SEND request and the To header field of the original Message/CPIM wrapper. The MSRP switch MUST NOT forward private messages to a recipient that does not support private messaging.
最後に、MSRPスイッチは、受信者がプライベートメッセージをサポートしていることを確認します。受信者がプライベートメッセージをサポートしない場合、MSRPスイッチは428応答で要求を拒否する必要があります。この新しい428応答は、受信者がプライベートメッセージをサポートしていないことを示しています。 MSRPスイッチが送信者に送信する潜在的なREPORT要求には、SEND要求に含まれる元のFromヘッダーフィールドと元のMessage / CPIMラッパーのToヘッダーフィールドを含むMessage / CPIMラッパーを含める必要があります。 MSRPスイッチは、プライベートメッセージをサポートしていない受信者にプライベートメッセージを転送してはなりません。
If successful, the MSRP switch should search its mapping table to find the MSRP sessions established toward the recipient. If a match is found, the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it.
成功した場合、MSRPスイッチはそのマッピングテーブルを検索して、受信者に対して確立されたMSRPセッションを見つける必要があります。一致が見つかった場合、MSRPスイッチはSEND要求を作成する必要があり、送信者のメッセージの内容をそれに送信する必要があります。
An MSRP endpoint that receives a SEND request from the MSRP switch does the same validations as for regular messages (Section 6.1). If the To header field is different from the chat room URI, the MSRP endpoints know that this is a private message. The endpoint should render who it is from based on the value of the From header of the Message/CPIM wrapper. The endpoint can also use the sender's nickname, possibly learned via a conference event package, to render the sender of the message, instead of using the sender's actual URI.
MSRPスイッチからSEND要求を受信するMSRPエンドポイントは、通常のメッセージの場合と同じ検証を行います（セクション6.1）。 ToヘッダーフィールドがチャットルームのURIと異なる場合、MSRPエンドポイントはこれがプライベートメッセージであることを認識しています。エンドポイントは、メッセージ/ CPIMラッパーのFromヘッダーの値に基づいて、それがだれからのものかをレンダリングする必要があります。エンドポイントは、送信者の実際のURIを使用する代わりに、おそらく会議イベントパッケージを介して学習された送信者のニックネームを使用して、メッセージの送信者をレンダリングすることもできます。
As with regular messages, if the policy of the chat room allows simultaneous access, the MSRP switch MUST copy all private messages intended to the recipient through each MSRP session mapped to the recipient's URI.
通常のメッセージと同様に、チャットルームのポリシーで同時アクセスが許可されている場合、MSRPスイッチは、受信者のURIにマッピングされた各MSRPセッションを介して、受信者宛のすべてのプライベートメッセージをコピーする必要があります。
This section discusses the common procedures for regular and private messages with respect to MSRP reports and responses. Any particular procedure affecting only regular messages or only private messages is discussed in the previous sections (Sections 6.1 or 6.2, respectively).
このセクションでは、MSRPレポートと応答に関する通常のプライベートメッセージの一般的な手順について説明します。通常のメッセージまたはプライベートメッセージのみに影響する特定の手順については、前のセクションで説明します（それぞれセクション6.1または6.2）。
MSRP switches MUST follow the success report and failure report handling described in Section 7 of RFC 4975 [RFC4975], complemented with the procedures described in this section. The MSRP switch MUST act as an MSRP endpoint receiver of the request, according to Section 5.3 of RFC 4975 [RFC4975].
MSRPスイッチは、RFC 4975 [RFC4975]のセクション7で説明されている成功レポートと失敗レポートの処理に従い、このセクションで説明されている手順を補足する必要があります。 RFC 4975 [RFC4975]のセクション5.3に従って、MSRPスイッチはリクエストのMSRPエンドポイントレシーバーとして機能する必要があります。
If the MSRP switch receives an MSRP SEND request that does not contain a Message/CPIM wrapper, the MSRP switch MUST reject the request with a 415 response (specified in RFC 4975 [RFC4975]).
MSRPスイッチがメッセージ/ CPIMラッパーを含まないMSRP SEND要求を受信した場合、MSRPスイッチは415応答（RFC 4975 [RFC4975]で指定）で要求を拒否する必要があります。
If the MSRP switch receives an MSRP SEND request where the URI included in the From header field of the Message/CPIM wrapper is not valid, (e.g., because it does not "belong" to the sender of the message or is not a valid participant of the chat room), the MSRP switch MUST reject the request with a 403 response. In cases without error, the MSRP switch MUST construct responses according to Section 7.2 of RFC 4975 [RFC4975].
MSRPスイッチがMSRP SEND要求を受信した場合、メッセージ/ CPIMラッパーのFromヘッダーフィールドに含まれるURIは有効ではありません（たとえば、メッセージの送信者に「属していない」か、有効な参加者ではないため）チャットルームの場合）、MSRPスイッチは403応答で要求を拒否する必要があります。エラーがない場合、MSRPスイッチはRFC 4975 [RFC4975]のセクション7.2に従って応答を構築する必要があります。
When the MSRP switch forwards a SEND request, it MAY use any report model in the copies intended for the recipients. The receiver reports from the recipients MUST NOT be forwarded to the originator of the original SEND request. This could lead to having the sender receiving multiple reports for a single MSRP request.
MSRPスイッチがSEND要求を転送するとき、受信者向けのコピーで任意のレポートモデルを使用できます。受信者からの受信者レポートは、元のSEND要求の発信者に転送してはなりません（MUST NOT）。これにより、送信者が単一のMSRP要求の複数のレポートを受信する可能性があります。
Congestion can occur when multiple heterogeneous interfaces are used by a number of users who are participating in a chat room, and, in particular, when paths become overloaded by any application. Some of these users might have fast paths capable of high throughputs while other users might be slow paths with constrained throughputs. Some paths might become congested only by the chat application; other paths gets congested by other applications. Therefore, it is possible that a subset of the participants of the chat room are able to send and receive a large number of messages in a short time or with large contents (e.g., pictures), whereas others are not able to keep up the pace.
チャットルームに参加している多数のユーザーが複数の異種インターフェースを使用している場合、特に、アプリケーションによってパスが過負荷になると、輻輳が発生する可能性があります。これらのユーザーの一部は、高スループットが可能な高速パスを持っている場合がありますが、他のユーザーは、スループットが制限された低速パスである場合があります。一部のパスは、チャットアプリケーションによってのみ輻輳する可能性があります。他のパスは他のアプリケーションによって混雑します。したがって、チャットルームの参加者のサブセットが大量のメッセージを短時間または大量のコンテンツ（例：画像）で送受信できる一方で、他の人はペースを維持できない可能性があります。 。
Additionally, since MSRP uses a connection-oriented transport protocol such as TCP, it is expected that TCP congestion control mechanisms be activated if congestion occurs. Details on congestion control are specified in RFC 5681 [RFC5681].
さらに、MSRPはTCPなどのコネクション型のトランスポートプロトコルを使用するため、輻輳が発生した場合はTCPの輻輳制御メカニズムがアクティブになることが予想されます。輻輳制御の詳細は、RFC 5681 [RFC5681]で指定されています。
While this document does not mandate a particular MSRP-specific mechanism to avoid congestion in any of the paths, something that is deemed outside the scope of this document, this document provides some recommendations for implementors to consider.
このドキュメントでは、パスの輻輳を回避するために特定のMSRP固有のメカニズムを義務付けていませんが、このドキュメントの範囲外と見なされるものですが、このドキュメントでは、実装者が考慮すべきいくつかの推奨事項を提供します。
It is RECOMMENDED that MSRP switches implement one or more MSRP-specific strategies to detect and avoid congestion. Possible strategies (but definitely not a comprehensive list) include:
MSRPスイッチは、1つ以上のMSRP固有の戦略を実装して、輻輳を検出および回避することをお勧めします。可能な戦略（ただし、完全なリストではありませんが）には、次のものがあります。
o If the MSRP switch is writing data to a send buffer and detects that the send buffer associated with that TCP connection is getting full (e.g., close to 80% of its capacity), the MSRP switch marks the associated MSRP sessions making use of that TCP connection as "congested".
o MSRPスイッチが送信バッファにデータを書き込んでいて、そのTCP接続に関連付けられている送信バッファがいっぱいになっている（たとえば、その容量の80％に近い）ことを検出した場合、MSRPスイッチは、そのTCPを使用して関連するMSRPセッションにマークを付けます「混雑」としての接続。
o Prior to sending a new MSRP message to a user, the MSRP switch verifies the congested flag associated to that MSRP session. If the MSRP session is marked as congested, the MSRP switch can apply a congestion avoidance mechanism, such as:
o 新しいMSRPメッセージをユーザーに送信する前に、MSRPスイッチはそのMSRPセッションに関連付けられた輻輳フラグを確認します。 MSRPセッションが輻輳しているとマークされている場合、MSRPスイッチは次のような輻輳回避メカニズムを適用できます。
* The MSRP switch MAY discard regular MSRP messages sent to that user while the congestion flag is raised for the user's TCP connection. In order to inform the user of the congestion, the MSRP switch MAY send a regular MSRP message to the user whose congestion flag is raised. This message indicates that some other messages are being discarded due to network congestion. However, it should be noted that this message can get stuck at MSRP switch, if the path is fully congested, i.e., it may not be delivered anyhow.
* MSRPスイッチは、ユーザーのTCP接続で輻輳フラグが立てられている間、そのユーザーに送信された通常のMSRPメッセージを破棄してもよい（MAY）。ユーザーに輻輳を通知するために、MSRPスイッチは、輻輳フラグが立っているユーザーに通常のMSRPメッセージを送信する場合があります。このメッセージは、ネットワークの輻輳が原因で他のメッセージが破棄されていることを示しています。ただし、パスが完全に輻輳している場合、つまりメッセージが配信されない場合、このメッセージはMSRPスイッチでスタックする可能性があることに注意してください。
* The MSRP can implement a temporary policy to disallow the distribution of messages larger than a certain size to MSRP sessions marked as congested. Similarly, the user should be informed of this fact by the MSRP switch sending a regular MSRP message indicating this condition.
* MSRPは、一時的なポリシーを実装して、輻輳としてマークされたMSRPセッションへの特定のサイズを超えるメッセージの配信を禁止できます。同様に、MSRPスイッチがこの状態を示す通常のMSRPメッセージを送信することで、ユーザーにこの事実を通知する必要があります。
o If the MSRP switch determines that the congestion flag associated with a given TCP connection has been raised for quite some time (on the order of a few minutes), or if the interface is down, this may be considered an indication that the TCP connection has not been able to recover from a congestion state. The MSRP switch MAY close this congested TCP connection as well as the MSRP session and SIP session.
o 特定のTCP接続に関連付けられている輻輳フラグがかなりの時間（数分程度）発生したとMSRPスイッチが判断した場合、またはインターフェイスがダウンしている場合、これはTCP接続に問題があることを示していると考えられます。輻輳状態から回復できませんでした。 MSRPスイッチは、MSRPセッションとSIPセッションだけでなく、この輻輳したTCP接続を閉じる場合があります。
A common characteristic of existing chat room services is that participants have the ability to present themselves with a nickname to the rest of the participants of the chat room. It is used for easy reference of participants in the chat room and can also provide anonymous participants with a meaningful descriptive name.
既存のチャットルームサービスの共通の特徴は、参加者がチャットルームの他の参加者にニックネームを提示できることです。チャットルームの参加者を簡単に参照するために使用され、匿名の参加者にわかりやすい名前を付けることもできます。
A nickname is a useful construct in many use cases, of which MSRP chat is but one example. A nickname is associated with a URI; the focus knows the participant by its association to this URI. Therefore, if a user joins the chat room under the same URI from multiple devices, he or she may request the same nickname across all these devices.
ニックネームは多くのユースケースで有用な構成要素であり、MSRPチャットはその一例にすぎません。ニックネームはURIに関連付けられています。フォーカスは、このURIへの関連付けによって参加者を認識します。したがって、ユーザーが複数のデバイスから同じURIでチャットルームに参加すると、これらのすべてのデバイスで同じニックネームを要求する可能性があります。
A nickname is a user-selectable moniker by which the participant wants to be known to the other participants. It is not a 'display-name', but it is used somewhat like a display name. A main difference is that a nickname is unique inside a chat room to allow an unambiguous reference to a participant in the chat. Nicknames may be long lived, or they may be temporary. Users also need to reserve a nickname prior to its utilization.
ニックネームは、参加者が他の参加者に知られることを希望するユーザー選択可能なモニカです。これは「表示名」ではありませんが、表示名のように使用されます。主な違いは、ニックネームはチャットルーム内で一意であるため、チャットの参加者を明確に参照できることです。ニックネームは長命かもしれませんし、一時的なものかもしれません。ユーザーは、使用する前にニックネームを予約する必要もあります。
This memo specifies the nickname as a string. The nickname string MUST unambiguously be associated with a single user in the scope of the chat room (conference instance). This scope is similar to having a nickname unique per user inside a chat room from "Extensible Messaging and Presence Protocol (XMPP): Core" [RFC6120]. The chat room may have policies associated with nicknames. It may not accept nickname strings at all, or it may provide a wider unambiguous scope like a domain or server, similar to IRC [RFC2810].
このメモはニックネームを文字列として指定します。ニックネーム文字列は、チャットルーム（会議インスタンス）のスコープで単一のユーザーに明確に関連付けられている必要があります。このスコープは、「Extensible Messaging and Presence Protocol（XMPP）：Core」[RFC6120]のチャットルーム内でユーザーごとに一意のニックネームを持つことに似ています。チャットルームには、ニックネームに関連付けられたポリシーがある場合があります。ニックネーム文字列をまったく受け入れない場合や、IRC [RFC2810]と同様に、ドメインやサーバーのようなより明確なスコープを提供する場合があります。
This memo provides a mechanism to reserve a nickname for a participant for as long as the participant is logged into the chat room. The mechanism is based on a NICKNAME MSRP method (see below) and a new "Use-Nickname" header. Note that other mechanisms may exist (for example, a web page reservation system), although they are outside the scope of this document.
このメモは、参加者がチャットルームにログインしている限り、参加者のニックネームを予約するメカニズムを提供します。このメカニズムは、NICKNAME MSRPメソッド（以下を参照）と新しい "Use-Nickname"ヘッダーに基づいています。他のメカニズムが存在する可能性があることに注意してください（たとえば、Webページ予約システム）。ただし、それらはこのドキュメントの範囲外です。
A chat room participant who has established an MSRP session with the MSRP switch, where the MSRP switch has indicated the support and availability of nicknames with the 'nicknames' token in the 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP switch. The NICKNAME request MUST include a new Use-Nickname header that contains the nickname string that the participant wants to reserve. This nickname string MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length. Finally, MSRP NICKNAME requests MUST NOT include Success-Report or Failure-Report header fields.
MSRPスイッチとのMSRPセッションを確立したチャットルームの参加者。MSRPスイッチは、「チャットルーム」SDP属性の「ニックネーム」トークンでニックネームのサポートと利用可能性を示し、MSRPスイッチにNICKNAMEリクエストを送信できます。 。 NICKNAMEリクエストには、参加者が予約するニックネーム文字列を含む新しいUse-Nicknameヘッダーを含める必要があります。このニックネーム文字列は、長さがゼロオクテットであってはならず、長さが1023オクテットを超えてはなりません。最後に、MSRP NICKNAMEリクエストには、Success-ReportまたはFailure-Reportヘッダーフィールドを含めることはできません。
Bear in mind that nickname strings, like the rest of the MSRP message, use the UTF-8 transformation format [RFC3629]. Therefore, a character may be encoded in more than one octet.
ニックネーム文字列は、残りのMSRPメッセージと同様に、UTF-8変換フォーマット[RFC3629]を使用することに注意してください。したがって、文字は複数のオクテットでエンコードされる場合があります。
An MSRP switch that receives a NICKNAME request containing a Use-Nickname header field SHOULD first verify whether the policy of the chat room allows the nickname functionality. If not allowed, the MSRP switch MUST reject the request with a 403 response, as per RFC 4975 [RFC4975].
Use-Nicknameヘッダーフィールドを含むNICKNAME要求を受信するMSRPスイッチは、最初にチャットルームのポリシーでニックネーム機能が許可されているかどうかを確認する必要があります。許可されない場合、MSRPスイッチは、RFC 4975 [RFC4975]に従って、403応答で要求を拒否する必要があります。
If the policy of the chat room allows the usage of nicknames, any new nickname requested MUST be prepared and compared with nicknames already in use or reserved following the rules defined in "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames" [RFC7700].
チャットルームのポリシーでニックネームの使用が許可されている場合、要求された新しいニックネームは準備され、「ニックネームを表す国際化文字列の準備、施行、比較」で定義されたルールに従って、すでに使用または予約されているニックネームと比較する必要があります[RFC7700]。 。
This mitigates the problem of nickname duplication, but it does not solve a problem whereby users can choose similar (but different) characters to represent two different nicknames. For example, "BOY" and "B0Y" are different nicknames that can mislead users. The former uses the capital letter "O" while the latter uses the number zero "0". In many fonts, the letter "O" and the number zero "0" might be quite similar and difficult to perceive as different characters. Chat rooms MAY provide a mechanism to mitigate confusable nicknames.
これにより、ニックネームの重複の問題が軽減されますが、ユーザーが2つの異なるニックネームを表すために類似した（ただし異なる）文字を選択できるという問題は解決されません。たとえば、「BOY」と「B0Y」は、ユーザーを誤解させる可能性のある異なるニックネームです。前者は大文字の「O」を使用し、後者は数字のゼロ「0」を使用します。多くのフォントでは、文字「O」と数字のゼロ「0」は非常に類似しており、異なる文字として認識するのが難しい場合があります。チャットルームは、紛らわしいニックネームを軽減するメカニズムを提供する場合があります。
In addition to preparing and comparing following the rules above, the MSRP switch SHOULD only allow the reservation of an already-used nickname if the same user (e.g., identified by the SIP AOR) that is currently using the nickname is making this subsequent request. This may include, e.g., allowing the participant's URI to use the same nickname when the participant has joined the chat room from different devices under the same URI. The participant's authenticated identifier can be derived after a successful SIP Digest Authentication [RFC3261], included in a trusted SIP P-Asserted-Identity header field [RFC3325], included in a valid SIP Identity header field [RFC4474], or derived from any other present or future SIP authentication mechanism. Once the MSRP switch has validated that the participant is entitled to reserve the requested nickname, the MSRP switch verifies if the suggested nickname can be accepted (see below).
上記のルールに従って準備および比較することに加えて、MSRPスイッチは、ニックネームを現在使用している同じユーザー（たとえば、SIP AORによって識別される）がこの後続のリクエストを行っている場合にのみ、すでに使用されているニックネームの予約を許可する必要があります（SHOULD）。これには、たとえば、参加者が同じURIで異なるデバイスからチャットルームに参加したときに、参加者のURIが同じニックネームを使用できるようにすることが含まれます。参加者の認証済み識別子は、SIPダイジェスト認証[RFC3261]が成功した後、信頼できるSIP P-Asserted-Identityヘッダーフィールド[RFC3325]に含まれるか、有効なSIP Identityヘッダーフィールド[RFC4474]に含まれるか、または他の任意の現在または将来のSIP認証メカニズム。参加者が要求されたニックネームを予約する資格があることをMSRPスイッチが検証すると、MSRPスイッチは提案されたニックネームを受け入れることができるかどうかを確認します（以下を参照）。
The reservation of a nickname can fail in several cases. If the NICKNAME request contains a malformed value in the Use-Nickname header field, the MSRP switch MUST answer the NICKNAME request with a 424 response code. This can be the case when the value of the Use-Nickname header field does not conform to the syntax.
ニックネームの予約が失敗する場合があります。 NICKNAME要求のUse-Nicknameヘッダーフィールドに不正な値が含まれている場合、MSRPスイッチは424応答コードでNICKNAME要求に応答する必要があります。これは、Use-Nicknameヘッダーフィールドの値が構文に準拠していない場合に発生する可能性があります。
The reservation of a nickname can also fail if the value of the Use-Nickname header field of the NICKNAME request is a reserved word (not to be used as a nickname by any user) or that particular value is already in use by another user. In these cases, the MSRP switch MUST answer the NICKNAME request with a 425 response code.
NICKNAMEリクエストのUse-Nicknameヘッダーフィールドの値が予約語（ユーザーがニックネームとして使用しないでください）である場合、またはその特定の値がすでに別のユーザーによって使用されている場合も、ニックネームの予約が失敗する可能性があります。これらの場合、MSRPスイッチは425応答コードでNICKNAME要求に応答する必要があります。
In both error conditions (receiving a 424 or 425 response code), the nickname usage is considered failed; the nickname is not allocated to this user. The user can select a different nickname and retry another NICKNAME request.
両方のエラー条件（424または425応答コードを受け取る）では、ニックネームの使用が失敗したと見なされます。ニックネームはこのユーザーに割り当てられていません。ユーザーは別のニックネームを選択して、別のNICKNAME要求を再試行できます。
If the MSRP switch is able to accept the suggested nickname to be used by this user, the MSRP switch MUST answer the NICKNAME request with a 200 response as per regular MSRP procedures.
MSRPスイッチがこのユーザーが使用する提案されたニックネームを受け入れることができる場合、MSRPスイッチは通常のMSRP手順に従って200応答でNICKNAME要求に応答する必要があります。
As indicated earlier, this specification defines a new MSRP header field: Use-Nickname. The Use-Nickname header field carries a nickname string. This specification defines the usage of the Use-Nickname header field in NICKNAME requests. If need arises, usages of the Use-Nickname header field in other MSRP methods should be specified separately.
前に示したように、この仕様は新しいMSRPヘッダーフィールドを定義しています：Use-Nickname。 Use-Nicknameヘッダーフィールドには、ニックネーム文字列が含まれています。この仕様では、NICKNAMEリクエストでのUse-Nicknameヘッダーフィールドの使用法を定義しています。必要に応じて、他のMSRPメソッドでのUse-Nicknameヘッダーフィールドの使用法を個別に指定する必要があります。
According to RFC 4975 [RFC4975], MSRP uses the UTF-8 transformation format [RFC3629]. The syntax of the MSRP NICKNAME method and the Use-Nickname header field is built upon the MSRP formal syntax [RFC4975] using the Augmented Backus-Naur Form (ABNF) [RFC5234].
RFC 4975 [RFC4975]によれば、MSRPはUTF-8変換フォーマット[RFC3629]を使用します。 MSRP NICKNAMEメソッドの構文とUse-Nicknameヘッダーフィールドは、拡張バッカスナウアフォーム（ABNF）[RFC5234]を使用したMSRP形式構文[RFC4975]に基づいて構築されています。
other-method =/ NICKNAMEm
; other-method defined in RFC 4975
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = DQUOTE 1*1023(qdtext / qd-esc) DQUOTE
; qdtext and qd-esc defined in RFC 4975
Note that, according to RFC 4975 [RFC4975], "quoted-string" admits a subset of UTF-8 characters [RFC3629]. Please refer to Section 9 of RFC 4975 [RFC4975] for more details.
RFC 4975 [RFC4975]によると、 "quoted-string"はUTF-8文字のサブセット[RFC3629]を許可することに注意してください。詳細については、RFC 4975 [RFC4975]のセクション9を参照してください。
Once the MSRP switch has reserved a nickname and has bound it to a URI (e.g., a SIP AoR), the MSRP server MAY allow the usage of the same nickname by the same user (identified by the same URI, such as a SIP AoR) over a second MSRP session. This might be the case if the user joins the same chat room from a different SIP UA. In this case, the user MAY request a nickname that is the same or different than that used in conjunction with the first MSRP session; the MSRP server MAY accept the usage of the same nickname by the same user. The MSRP switch MUST NOT automatically assign the same nickname to more than one MSRP session established from the same URI, because this can create confusion to the user as whether the same nickname is bound to the second MSRP session.
MSRPスイッチがニックネームを予約し、それをURI（SIP AoRなど）にバインドすると、MSRPサーバーは、同じユーザーによる同じニックネームの使用を許可（MAY）できます（SIP AoRなどの同じURIで識別されます） ）2番目のMSRPセッション。これは、ユーザーが別のSIP UAから同じチャットルームに参加した場合に発生することがあります。この場合、ユーザーは、最初のMSRPセッションで使用されたものと同じまたは異なるニックネームを要求できます（MAY）。 MSRPサーバーは、同じユーザーによる同じニックネームの使用を受け入れることができます。 MSRPスイッチは、同じニックネームが2番目のMSRPセッションにバインドされているかどうかをユーザーに混乱させる可能性があるため、同じURIから確立された複数のMSRPセッションに同じニックネームを自動的に割り当ててはなりません（MUST NOT）。
Typically, a participant will reserve a nickname as soon as the participant joins the chat room. But it is also possible for a participant to modify his/her own nickname and replace it with a new one at any time during the duration of the MSRP session. Modification of the nickname is not different from the initial reservation and usage of a nickname; thus, the NICKNAME method is used as described in Section 7.1.
通常、参加者はチャットルームに参加するとすぐにニックネームを予約します。ただし、参加者が自分のニックネームを変更して、MSRPセッションの期間中いつでも新しいニックネームに置き換えることもできます。ニックネームの変更は、ニックネームの最初の予約および使用と変わりません。したがって、セクション7.1で説明されているようにNICKNAMEメソッドが使用されます。
If a NICKNAME request that attempts to modify the current nickname of the user fails for some reason, the current nickname stays in effect. A new nickname comes into effect and the old one is released only after a NICKNAME request is accepted with a 200 response.
ユーザーの現在のニックネームを変更しようとするNICKNAME要求が何らかの理由で失敗した場合、現在のニックネームは引き続き有効です。新しいニックネームが有効になり、古いニックネームは、NICKNAMEリクエストが200応答で受け入れられた後にのみ解放されます。
If the participant no longer wants to be known by a nickname in the chat room, the participant can follow the method described in Section 7.2. The nickname element of the Use-Nickname header MUST be set to an empty quoted string.
チャットルームのニックネームで参加者が知りたくない場合は、参加者はセクション7.2で説明されている方法に従うことができます。 Use-Nicknameヘッダーのニックネーム要素は、引用符で囲まれた空の文字列に設定する必要があります。
Typically the conference focus acts as a notifier of the conference event package, RFC 4575 [RFC4575]. It is RECOMMENDED that conference foci and endpoints support RFC 6502 [RFC6502] for providing information regarding the conference and, in particular, supplying information of the roster of the conference. It is also RECOMMENDED that conference foci and endpoints support RFC 6501 [RFC6501], which extends the <user> element originally specified in RFC 4575 [RFC4575] with a new 'nickname' attribute. This allows endpoints to learn the nicknames of participants of the chat room.
通常、会議フォーカスは、会議イベントパッケージRFC 4575 [RFC4575]の通知機能として機能します。会議の焦点とエンドポイントは、会議に関する情報を提供するため、特に会議の名簿の情報を提供するためにRFC 6502 [RFC6502]をサポートすることをお勧めします。会議の焦点とエンドポイントがRFC 6501 [RFC6501]をサポートすることもお勧めします。これは、RFC 4575 [RFC4575]で最初に指定された<user>要素を新しい「ニックネーム」属性で拡張します。これにより、エンドポイントはチャットルームの参加者のニックネームを知ることができます。
There are a handful of use cases where a participant would like to learn the chat room capabilities supported by the local policy of the MSRP switch and the chat room. For example, a participant would like to learn if the MSRP switch supports private messaging; otherwise, the participant may send what he believes is a private IM addressed to a participant, but since the MSRP switch does not support the functions specified in this memo, the message would eventually be distributed to all the participants of the chat room.
参加者がMSRPスイッチのローカルポリシーとチャットルームでサポートされているチャットルーム機能を学習したい場合は、いくつかの使用例があります。たとえば、参加者がMSRPスイッチがプライベートメッセージングをサポートしているかどうかを知りたいとします。そうでない場合、参加者は自分が信じているものを参加者宛のプライベートIMとして送信できますが、MSRPスイッチはこのメモで指定された機能をサポートしていないため、メッセージは最終的にチャットルームのすべての参加者に配信されます。
The reverse case also exists. A participant, say Alice, whose UA does not support the extensions defined by this document joins the chat room. The MSRP switch learns that Alice's application does not support private messaging nor nicknames. If another participant, say Bob, sends a private message to Alice, the MSRP switch does not distribute it to Alice, because Alice is not able to differentiate it from a regular message sent to the whole roster. Furthermore, if Alice replied to this message, she would do it to the whole roster. Because of this, the MSRP switch also keeps track of users who do not support the extensions defined in this document.
逆のケースも存在します。このドキュメントで定義されている拡張機能をUAがサポートしていない参加者（アリスなど）がチャットルームに参加します。 MSRPスイッチは、Aliceのアプリケーションがプライベートメッセージングもニックネームもサポートしていないことを学習します。別の参加者、たとえばボブがプライベートメッセージをアリスに送信すると、MSRPスイッチはそれをアリスに配信しません。これは、アリスがそれを名簿全体に送信される通常のメッセージと区別できないためです。さらに、アリスがこのメッセージに返信した場合、彼女は名簿全体に対してそれを行います。このため、MSRPスイッチは、このドキュメントで定義されている拡張機能をサポートしていないユーザーも追跡します。
In another scenario, the policy of a chat room may indicate that certain functions are not allowed. For example, the policy may indicate that nicknames or private messages are forbidden.
別のシナリオでは、チャットルームのポリシーにより、特定の機能が許可されないことが示される場合があります。たとえば、ニックネームやプライベートメッセージが禁止されていることがポリシーで示されている場合があります。
In order to provide the user with a good chat room experience, we define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a media-level value attribute [RFC4566] that MAY be included in conjunction with an MSRP media stream (i.e., when an "m=" line in SDP indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute without further modifiers (e.g., chat-tokens) indicates that the endpoint supports the procedures described in this document for transferring MSRP messages to/from a chat room. The 'chatroom' attribute can be complemented with additional modifiers that further indicate the intersection of support and local policy allowance for a number of functions specified in this document. Specifically, we provide the means to indicate support for the use of nicknames and private messaging.
ユーザーに優れたチャットルームエクスペリエンスを提供するために、新しい「チャットルーム」SDP属性を定義します。 「チャットルーム」属性は、MSRPメディアストリームと一緒に含めることができるメディアレベルの値属性[RFC4566]です（つまり、SDPの「m =」行が「TCP / MSRP」または「TCP / TLS / MSRP」）。追加の修飾子（例：チャットトークン）のない 'chatroom'属性は、エンドポイントがこのドキュメントで説明されている、チャットルームとの間でMSRPメッセージを転送するための手順をサポートしていることを示します。 「チャットルーム」属性は、このドキュメントで指定されているいくつかの機能に対するサポートとローカルポリシーの許容範囲の共通部分をさらに示す追加の修飾子で補完できます。具体的には、ニックネームとプライベートメッセージングの使用のサポートを示す手段を提供します。
The 'chatroom' attribute merely indicates the capabilities supported and allowed by the local policy. This attribute is not a negotiation subject to the SDP offer/answer model [RFC3264], but instead a declaration. Therefore, a 'chatroom' attribute included in an SDP answer does not need to be a subset of the values included in the 'chatroom' attribute of its corresponding SDP offer. Consequently, an SDP answer MAY contain a 'chatroom' attribute even if its corresponding SDP offer did not include it.
「チャットルーム」属性は、ローカルポリシーでサポートおよび許可されている機能を示すだけです。この属性は、SDPオファー/アンサーモデル[RFC3264]の対象となる交渉ではなく、宣言です。したがって、SDP回答に含まれる「チャットルーム」属性は、対応するSDPオファーの「チャットルーム」属性に含まれる値のサブセットである必要はありません。その結果、対応するSDPオファーに含まれていない場合でも、SDP回答には「チャットルーム」属性が含まれる場合があります。
In subsequent SDP offer/answer [RFC3264] exchanges pertaining to the same session, the 'chatroom' attribute MAY be modified with respect to an earlier SDP offer/answer exchange. The new value of this attribute indicates the current support and local policy, meaning that some restrictions can apply now or might have been removed. If the 'chatroom' attribute is not included in a subsequent SDP offer/ answer, but a corresponding MSRP stream is still in place, it indicates that support for the procedures indicated in this document are disabled.
同じセッションに関連する後続のSDPオファー/アンサー[RFC3264]交換では、以前のSDPオファー/アンサー交換に対して「チャットルーム」属性を変更できます。この属性の新しい値は、現在のサポートとローカルポリシーを示します。つまり、いくつかの制限が現在適用できるか、削除されている可能性があります。 'chatroom'属性が後続のSDPオファー/アンサーに含まれていないが、対応するMSRPストリームがまだ存在する場合、このドキュメントに示されている手順のサポートが無効になっていることを示しています。
The 'chatroom' SDP attribute has the following ABNF [RFC5234] syntax:
'chatroom' SDP属性には、次のABNF [RFC5234]構文があります。
attribute =/ chatroom-attr
; attribute defined in RFC 4566
chatroom-attr = chatroom-label [":" chat-token
*(SP chat-token)]
chatroom-label = "chatroom"
chat-token = (nicknames-token / private-msg-token /
ext-token)
nicknames-token = "nickname"
private-msg-token = "private-messages"
ext-token = private-token / standard-token
private-token = toplabel "." *(domainlabel ".") token
; toplabel defined in RFC 3261
; domainlabel defined in RFC 3261
; token defined in RFC 3261
standard-token = token
A given 'chat-token' value MUST NOT appear more than once in a 'chatroom' attribute.
特定の「chat-token」値は、「chatroom」属性に複数回出現してはなりません。
A conference focus that includes the 'nicknames' token in the session description is signaling that the MSRP switch supports and the chat room allows the use of the procedures specified in Section 7. A conference focus that includes the 'private-messages' in the SDP description is signaling that the MSRP switch supports and the chat room allows the use of the procedures specified in Section 6.2.
セッションの説明に「ニックネーム」トークンを含む会議フォーカスは、MSRPスイッチがサポートしていることを通知しており、チャットルームでは、セクション7で指定された手順を使用できます。SDPに「プライベートメッセージ」を含む会議フォーカス説明は、MSRPスイッチがサポートし、チャットルームがセクション6.2で指定された手順の使用を許可することを示しています。
An example of the 'chatroom' attribute for an MSRP media stream that indicates the acceptance of nicknames and private messages:
ニックネームとプライベートメッセージの受け入れを示すMSRPメディアストリームの「チャットルーム」属性の例：
a=chatroom:nickname private-messages
a = chatroom：nickname private-messages
An example of a 'chatroom' attribute for an MSRP media stream where the endpoint, e.g., an MSRP switch, does not allow nicknames or private messages.
MSRPメディアストリームの「チャットルーム」属性の例。MSRPスイッチなどのエンドポイントでは、ニックネームやプライベートメッセージは許可されません。
a=chatroom
a = chatroom
The 'chatroom' attribute allows extensibility with the addition of new tokens. No IANA registry is provided at this time, since no extensions are expected at the time of this writing. Extensions to the 'chatroom' attribute can be defined in IETF documents or as private-vendor extensions.
'chatroom'属性は、新しいトークンの追加による拡張性を可能にします。この記事の執筆時点では拡張機能は想定されていないため、現時点ではIANAレジストリは提供されていません。 'chatroom'属性の拡張は、IETFドキュメントで定義するか、プライベートベンダー拡張として定義できます。
Extensions defined in an IETF document MUST follow the 'standard-token' ABNF previously defined. In this type of extension, care must be taken in the selection of the token to avoid a clash with any of the tokens previously defined.
IETF文書で定義された拡張機能は、以前に定義された「標準トークン」ABNFに従う必要があります。このタイプの拡張では、以前に定義されたトークンとの衝突を避けるために、トークンの選択に注意を払う必要があります。
Private extensions MUST follow the 'private-token' ABNF previously defined. The 'private-token' MUST be included in the DNS name of the vendor. Then, the token is reversed in order to avoid clashes of tokens. The following is an example of an extension named "foo.chat" by a vendor "example.com"
プライベート拡張は、以前に定義された「プライベートトークン」ABNFに従う必要があります。 「プライベートトークン」は、ベンダーのDNS名に含める必要があります。次に、トークンの衝突を回避するために、トークンが反転されます。以下は、ベンダー「example.com」による「foo.chat」という名前の拡張機能の例です。
a=chatroom:nickname private-messages com.example.chat.foo
a = chatroom：nickname private-messages com.example.chat.foo
Note that feature names created by different organizations are not intended to have the same semantics or even interoperate.
異なる組織によって作成された機能名は、同じセマンティクスを持つことや、相互運用することさえ意図されていないことに注意してください。
Figure 3 presents a flow diagram where Alice joins a chat room by sending an INVITE request. This INVITE request contains a session description that includes the chat room extensions defined in this document.
図3は、AliceがINVITEリクエストを送信してチャットルームに参加するフロー図を示しています。このINVITE要求には、このドキュメントで定義されているチャットルーム拡張機能を含むセッションの説明が含まれています。
Alice Conference Focus
| |
|F1: (SIP) INVITE |
|----------------------->|
|F2: (SIP) 200 OK |
|<-----------------------|
|F3: (SIP) ACK |
|----------------------->|
| |
Figure 3: Flow Diagram of a User Joining a Chat Room F1: Alice constructs an SDP description that includes an MSRP media stream. She also indicates her support for the chat room extensions defined in this document. She sends the INVITE request to the chat room server.
図3：チャットルームに参加するユーザーのフロー図F1：アリスは、MSRPメディアストリームを含むSDP記述を作成します。彼女はまた、このドキュメントで定義されているチャットルーム拡張機能に対するサポートを示しています。彼女はINVITE要求をチャットルームサーバーに送信します。
INVITE sip:chatroom22@chat.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 290
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 client.atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messages
F2: The chat room server accepts the session establishment. It includes the 'isfocus' and other relevant feature tags in the Contact header field of the response. The chat room server also builds an SDP answer that forces the reception of messages wrapped in Message/ CPIM wrappers. It also includes the 'chatroom' attribute with the allowed extensions.
F2：チャットルームサーバーがセッションの確立を受け入れます。応答のContactヘッダーフィールドに「isfocus」およびその他の関連機能タグが含まれます。チャットルームサーバーは、Message / CPIMラッパーでラップされたメッセージの受信を強制するSDP応答も作成します。また、許可された拡張子を持つ 'chatroom'属性も含まれます。
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: 290
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messages
F3: The session established is acknowledged (details not shown).
F3：確立されたセッションが確認されます（詳細は表示されません）。
Figure 4 shows an example of Alice setting up a nickname using the chat room as provider. Her first proposal is not accepted because that proposed nickname is already in use. Then, she makes a second proposal with a new nickname. This second proposal is accepted.
図4は、チャットルームをプロバイダーとして使用してニックネームを設定するアリスの例を示しています。提案されたニックネームはすでに使用されているため、彼女の最初の提案は受け入れられません。次に、彼女は新しいニックネームで2番目の提案をします。この2番目の提案は受け入れられます。
Alice MSRP Switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 425 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |
Figure 4: Flow Diagram of a User Setting up Her Nickname
図4：ユーザーがニックネームを設定するフロー図
F1: Alice sends an MSRP NICKNAME request that contains her proposed nicknames in the Use-Nickname header field.
F1：アリスは、提案されたニックネームをUse-Nicknameヘッダーフィールドに含むMSRP NICKNAMEリクエストを送信します。
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice the great"
-------d93kswow$
F2: The MSRP switch analyzes the existing allocation of nicknames and
detects that the nickname "Alice the great" is already provided to
another participant in the chat room. The MSRP switch answers with a
425 response.
MSRP d93kswow 425 Nickname reserved or already in use
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
F3: Alice receives the response. She proposes a new nickname in a second NICKNAME request.
F3：アリスが応答を受け取ります。彼女は2番目のNICKNAMEリクエストで新しいニックネームを提案します。
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice in Wonderland"
-------09swk2d$
F4: The MSRP switch accepts the nickname proposal and answers with a 200 response.
F4：MSRPスイッチはニックネームの提案を受け入れ、200応答で応答します。
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
Figure 5 is a flow diagram where Alice is sending a regular message addressed to the chat room. The MSRP switch distributes the message to the rest of the participants.
図5は、アリスがチャットルーム宛の通常のメッセージを送信しているフロー図です。 MSRPスイッチは、残りの参加者にメッセージを配信します。
Alice MSRP Switch Bob Charlie
| | | |
| F1: (MSRP) SEND | | |
|--------------------->| F3: (MSRP) SEND | |
| F2: (MSRP) 200 |----------------------->| |
|<---------------------| F4: (MSRP) SEND | |
| |------------------------------->|
| | F5: (MSRP) 200 OK | |
| |<-----------------------| |
| | F6: (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
Figure 5: Sending a Regular Message to the Chat Room
図5：チャットルームへの通常のメッセージの送信
F1: Alice builds a text message and wraps it in a Message/CPIM wrapper. She addresses the message to the chat room. She encloses the resulting Message/CPIM wrapper in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
F1：アリスはテキストメッセージを作成し、メッセージ/ CPIMラッパーでラップします。彼女はメッセージをチャットルームに送ります。結果のMessage / CPIMラッパーをMSRP SEND要求で囲み、既存のTCP接続を介してMSRPスイッチに送信します。
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------3490visdm$
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
F2：MSRPスイッチは、SEND要求の受信を200（OK）応答で確認します。
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
-------3490visdm$
F3: The MSRP switch creates a new MSRP SEND request that contains the received Message/CPIM wrapper and sends it to Bob.
F3：MSRPスイッチは、受信したメッセージ/ CPIMラッパーを含む新しいMSRP SEND要求を作成し、それをボブに送信します。
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------490ej23$
Since the received message is addressed to the chat room URI in the
From header of the Message/CPIM header, Bob knows that this is a
regular message distributed to all participants in the chat room
rather than a private message addressed to him.
The rest of the message flows are analogous to the previous. They are not shown here.
残りのメッセージフローは、前のものと類似しています。ここには表示されません。
Figure 6 is a flow diagram where Alice is sending a private message addressed to Bob's SIP AOR. The MSRP switch distributes the message only to Bob.
図6は、アリスがボブのSIP AOR宛てのプライベートメッセージを送信しているフロー図です。 MSRPスイッチはメッセージをボブにのみ配信します。
Alice MSRP Switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
Figure 6: Sending a Private Message to Bob
図6：ボブへのプライベートメッセージの送信
F1: Alice builds a text message and wraps it in a Message/CPIM wrapper. She addresses the message to Bob's URI, which she learned from a notification in the conference event package. She encloses the resulting Message/CPIM wrapper in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
F1：アリスはテキストメッセージを作成し、メッセージ/ CPIMラッパーでラップします。彼女はメッセージをボブのURIに送ります。ボブのURIは、会議イベントパッケージの通知から学びました。結果のMessage / CPIMラッパーをMSRP SEND要求で囲み、既存のTCP接続を介してMSRPスイッチに送信します。
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------6959ssdf$
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
F2：MSRPスイッチは、SEND要求の受信を200（OK）応答で確認します。
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
-------6959ssdfm$
F3: The MSRP switch creates a new MSRP SEND request that contains the received Message/CPIM wrapper and sends it only to Bob. Bob can distinguish the sender in the From header of the Message/CPIM wrapper. He also identifies this as a private message due to the presence of his own SIP AOR in the To header field of the Message/ CPIM wrapper.
F3：MSRPスイッチは、受信したメッセージ/ CPIMラッパーを含む新しいMSRP SEND要求を作成し、ボブにのみ送信します。ボブは、メッセージ/ CPIMラッパーのFromヘッダーで送信者を区別できます。 Message / CPIMラッパーのToヘッダーフィールドに自分のSIP AORが存在するため、彼はこれをプライベートメッセージとして識別します。
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------9v9s2$
F4: Bob acknowledges the reception of the SEND request with a 200 (OK) response.
F4：ボブは200（OK）応答でSEND要求の受信を確認します。
MSRP 9v9s2 200 OK
To-Path: msrp://chat.example.com:5678/jofofo3;tcp
From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
Message-ID: d9fghe982
-------9v9s2$
The MSRP message below is a depiction of the same private message described in Section 9.4, but now the message is split in two chunks. The MSRP switch must wait for the complete set of Message/CPIM headers before distributing the messages.
以下のMSRPメッセージは、セクション9.4で説明されている同じプライベートメッセージを表していますが、メッセージは2つのチャンクに分割されています。 MSRPスイッチは、メッセージを配信する前に、Message / CPIMヘッダーの完全なセットを待つ必要があります。
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 1-*/174
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
-------7443ruls$
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 68-174/174
Content-Type: message/cpim
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob
-------7443ruls$
Figure 7 is a depiction of an XML conference information document received in a SIP NOTIFY request as a notification to the XCON Conference Event Package, RFC 6502 [RFC6502]. The conference information document follows the XCON Data Model specified in RFC 6501 [RFC6501].
図7は、XCON会議イベントパッケージ、RFC 6502 [RFC6502]への通知としてSIP NOTIFY要求で受信されたXML会議情報ドキュメントの図です。会議情報ドキュメントは、RFC 6501 [RFC6501]で指定されているXCONデータモデルに従います。
The conference information document of Figure 7 presents information of two users who are participating in the conference (see each of the <user> elements). Each participant is bound to a nickname, shown in the 'nickname' attribute of the <user> element.
図7の会議情報ドキュメントは、会議に参加している2人のユーザーの情報を示しています（各<user>要素を参照）。各参加者は、<user>要素の「nickname」属性に示されているニックネームにバインドされています。
NOTE: The purpose of Figure 7 is to show the user-to-nickname relationship. It is believed that the example is correct, according to RFC 6501 [RFC6501]. In case of contradictions between this specification and RFC 6501 [RFC6501], the latter has precedence.
注：図7の目的は、ユーザーとニックネームの関係を示すことです。 RFC 6501 [RFC6501]によると、この例は正しいと考えられています。この仕様とRFC 6501 [RFC6501]との間に矛盾がある場合は、後者が優先されます。
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com"
state="full"
xcon:nickname="Dopey Donkey">
<display-text>Bob Hoskins</display-text>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com"
state="full"
xcon:nickname="Alice the great">
<display-text>Alice Kay</display-text>
</user>
</users>
</conference-info>
Figure 7: Nickname in a Conference Information Document
図7：会議情報ドキュメントのニックネーム
This specification defines a new MSRP method that has been added to the "Methods" subregistry of the "Message Session Relay Protocol (MSRP) Parameters" registry:
この仕様は、「メッセージセッションリレープロトコル（MSRP）パラメータ」レジストリの「メソッド」サブレジストリに追加された新しいMSRPメソッドを定義します。
NICKNAME
ニックネーム
See Section 7 for details.
詳細については、セクション7を参照してください。
This specification defines a new MSRP header that has been added to the "Header Fields" subregistry of the "Message Session Relay Protocol (MSRP) Parameters" registry:
この仕様は、「メッセージセッションリレープロトコル（MSRP）パラメータ」レジストリの「ヘッダーフィールド」サブレジストリに追加された新しいMSRPヘッダーを定義します。
Use-Nickname
ニックネームを使用
See Section 7 for details.
詳細については、セクション7を参照してください。
This specification defines four new MSRP status codes that have been added to the "Status Codes" subregistry of the "Message Session Relay Protocol (MSRP) parameters" registry.
この仕様は、「メッセージセッションリレープロトコル（MSRP）パラメータ」レジストリの「ステータスコード」サブレジストリに追加された4つの新しいMSRPステータスコードを定義しています。
The 404 status code indicates the failure to resolve the recipient's URI in the To header field of the Message/CPIM wrapper in the SEND request, e.g., due to an unknown recipient. See Section 6.2 for details.
404ステータスコードは、SENDリクエストのMessage / CPIMラッパーのToヘッダーフィールドで受信者のURIを解決できなかったことを示します。たとえば、受信者が不明なためです。詳細については、セクション6.2を参照してください。
The 424 status code indicates a failure in allocating the requested nickname due to a malformed syntax in the Use-Nickname header field. See Section 7 for details.
424ステータスコードは、Use-Nicknameヘッダーフィールドの形式が正しくないために、要求されたニックネームの割り当てに失敗したことを示します。詳細については、セクション7を参照してください。
The 425 status code indicates a failure in allocating the requested nickname because the requested nickname in the Use-Nickname header field is reserved or is already in use by another user. See Section 7 for details.
425ステータスコードは、Use-Nicknameヘッダーフィールドの要求されたニックネームが予約されているか、別のユーザーがすでに使用しているため、要求されたニックネームの割り当てに失敗したことを示します。詳細については、セクション7を参照してください。
The 428 status code indicates that the recipient of a SEND request does not support private messages. See Section 6.2 for details.
ステータスコード428は、SENDリクエストの受信者がプライベートメッセージをサポートしていないことを示しています。詳細については、セクション6.2を参照してください。
Table 1 summarizes the IANA registration data with respect to new MSRP status codes:
表1は、新しいMSRPステータスコードに関するIANA登録データをまとめたものです。
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 404 | Failure to resolve recipient's URI | RFC 7701 |
| 424 | Malformed nickname | RFC 7701 |
| 425 | Nickname reserved or already in use | RFC 7701 |
| 428 | Private messages not supported | RFC 7701 |
+-------+-------------------------------------+-----------+
Table 1: New Status Codes
表1：新しいステータスコード
This specification defines a new media-level attribute in the "Session Description Protocol (SDP) Parameters" registry. The registration data is as follows:
この仕様は、「Session Description Protocol（SDP）Parameters」レジストリで新しいメディアレベル属性を定義しています。登録データは次のとおりです。
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
電話：+34 91 339 1000
Attribute name: chatroom
属性名：チャットルーム
Long-form attribute name: Chat Room
長い形式の属性名：チャットルーム
Type of attribute: media level only
属性のタイプ：メディアレベルのみ
This attribute is not subject to the charset attribute
この属性は文字セット属性の影響を受けません
Description: This attribute identifies support and local policy allowance for a number of chat room related functions
説明：この属性は、チャットルームに関連するいくつかの機能のサポートとローカルポリシーの許可を識別します
Specification: RFC 7701 (this document)
仕様：RFC 7701（このドキュメント）
See Section 8 for details.
詳細については、セクション8を参照してください。
This document proposes extensions to the Message Session Relay Protocol [RFC4975]. Therefore, the security considerations of that document apply to this document as well.
このドキュメントは、メッセージセッションリレープロトコル[RFC4975]への拡張を提案します。したがって、そのドキュメントのセキュリティに関する考慮事項は、このドキュメントにも適用されます。
A chat room is, by its nature, a potential Denial-of-Service (DoS) accelerator as it takes a message from one entity and sends it to many. Implementers of both UAs and switches need to carefully consider the set of anti-DoS measures that are appropriate for this application, and switch implementations, in particular, ought to include appropriate anti-DoS features. The details of what is appropriate will vary over time and will also depend on the specific needs of the implementation; thus, they cannot be specified here.
チャットルームは、その性質上、1つのエンティティからメッセージを受け取り、それを多数のエンティティに送信する潜在的なサービス拒否（DoS）アクセラレータです。 UAとスイッチの両方の実装者は、このアプリケーションに適切な一連のDoS対策を慎重に検討する必要があり、特にスイッチの実装には、適切なDoS対策機能を含める必要があります。適切なものの詳細は時間とともに変化し、実装の特定のニーズにも依存します。したがって、ここでは指定できません。
If the participant's SIP UA does not understand the "isfocus" feature tag [RFC3840], it will not know that it is connected to a conference instance. The participant might not be notified that its MSRP client will try to send messages having potential multiple recipients to the MSRP switch. If the participant's MSRP client does not support the extensions of this specification, it is unlikely that it will try to send a message using the Message/CPIM wrapper content type [RFC3862], and the MSRP switch will reject the request with a 415 response [RFC4975]. Still, if a participant's MSRP client does create a message with a valid Message/CPIM wrapper content type [RFC3862] having the To header set to the URI of the chat room and the From header set to the URI of which the participant that is known to the chat room, the participant might be unaware that the message can be forwarded to multiple recipients. Equally, if the To header is set to a valid URI of a recipient known to the chat room, the message can be forwarded as a private message without the participant knowing.
参加者のSIP UAが「isfocus」機能タグ[RFC3840]を理解しない場合、会議インスタンスに接続されていることがわかりません。 MSRPクライアントが潜在的な複数の受信者を持つメッセージをMSRPスイッチに送信しようとすることが参加者に通知されない場合があります。参加者のMSRPクライアントがこの仕様の拡張をサポートしていない場合、メッセージ/ CPIMラッパーコンテンツタイプ[RFC3862]を使用してメッセージを送信しようとすることはほとんどなく、MSRPスイッチは415応答で要求を拒否します[ RFC4975]。それでも、参加者のMSRPクライアントが有効なメッセージ/ CPIMラッパーコンテンツタイプ[RFC3862]でメッセージを作成した場合、ToヘッダーはチャットルームのURIに設定され、Fromヘッダーは参加者が知っているURIに設定されます。チャットルームでは、参加者はメッセージが複数の受信者に転送される可能性があることに気付かない可能性があります。同様に、Toヘッダーがチャットルームで認識されている受信者の有効なURIに設定されている場合、メッセージは、参加者が知らなくてもプライベートメッセージとして転送できます。
To mitigate these problems, when the chat room detects that a UA does not support the procedures of this document (i.e., when the SIP UA is not chat room aware), the MSRP switch SHOULD send a regular MSRP message indicating that the SIP UA is actually part of a chat room and that all the messages that the user sends correctly formatted will be distributed to a number of participants. Additionally, the MSRP switch SHOULD also send a regular MSRP text message including the list of participants in the chat room so that the user becomes aware of the roster.
これらの問題を軽減するために、UAがこのドキュメントの手順をサポートしていないことをチャットルームが検出した場合（つまり、SIP UAがチャットルームに対応していない場合）、MSRPスイッチは、SIP UAが実際にはチャットルームの一部であり、ユーザーが送信するすべてのメッセージは正しくフォーマットされており、多数の参加者に配信されます。さらに、MSRPスイッチは、ユーザーが名簿を認識できるように、チャットルームの参加者のリストを含む通常のMSRPテキストメッセージも送信する必要があります（SHOULD）。
If a participant wants to avoid security concerns on the path between himself and the MSRP switch (e.g., eavesdropping, faked packet injection, or packet corruption), the participant's UA can force the usage of MSRP over a TLS [RFC5246] transport connection. This is negotiated in the SDP offer/answer exchange as per the regular procedures of RFC 4975 [RFC4975]. This negotiation will result in both endpoints establishing a TLS [RFC5246] transport connection that is used to exchange MSRP messages. The MSRP switch may also have local policy that forces the usage of TLS transport for all MSRP sessions, something that is also negotiated in SDP as per the regular procedures of RFC 4975 [RFC4975].
参加者が自分とMSRPスイッチ間のパスに関するセキュリティ上の懸念（盗聴、偽のパケットインジェクション、またはパケットの破損など）を回避したい場合、参加者のUAは、TLS [RFC5246]トランスポート接続を介したMSRPの使用を強制できます。これは、RFC 4975 [RFC4975]の通常の手順に従って、SDPオファー/アンサー交換で交渉されます。このネゴシエーションにより、MSRPメッセージの交換に使用されるTLS [RFC5246]トランスポート接続が両方のエンドポイントで確立されます。 MSRPスイッチには、すべてのMSRPセッションでTLSトランスポートの使用を強制するローカルポリシーもある場合があります。これは、RFC 4975 [RFC4975]の通常の手順に従ってSDPでもネゴシエートされるものです。
Nicknames are used to show the appearance of the participants of the chat room. A successful takeover of a nickname from a participant might lead to private messages being sent to the wrong destination. The recipient's URI will be different from the URI associated with the original owner of the nickname, but the sender might not notice this. To avoid takeovers, the MSRP switch MUST make sure that a nickname is unique inside a chat room. Also, the security consideration for any authenticated identity mechanisms used to validate the SIP AOR will apply to this document as well. The chat room has a policy that determines the time that a nickname is still reserved for its holder, once it is no longer being used. This allows, e.g., a user that accidentally loses its connectivity, to reconnect to the chat room and keep on using the same nickname. It depends on the policy of the chat room if a nickname that has been previously used by another participant of the chat room can be reserved or not.
ニックネームは、チャットルームの参加者の外観を示すために使用されます。参加者からのニックネームの乗っ取りが成功すると、プライベートメッセージが間違った宛先に送信される可能性があります。受信者のURIはニックネームの元の所有者に関連付けられたURIとは異なりますが、送信者はこれに気付かない可能性があります。乗っ取りを回避するために、MSRPスイッチは、チャットルーム内でニックネームが一意であることを確認する必要があります。また、SIP AORの検証に使用される認証済みIDメカニズムのセキュリティに関する考慮事項は、このドキュメントにも適用されます。チャットルームには、ニックネームが使用されなくなったときに、その所有者のためにニックネームが予約される時間を決定するポリシーがあります。これにより、たとえば、誤って接続を失ったユーザーがチャットルームに再接続して、同じニックネームを使い続けることができます。チャットルームの別の参加者が以前に使用したニックネームを予約できるかどうかは、チャットルームのポリシーに依存します。
Section 7.1 discusses the problem of similar but different nicknames (e.g., thanks to the use of similar characters), and chat rooms MAY provide a mechanism to mitigate confusable nicknames.
セクション7.1は、類似しているが異なるニックネーム（たとえば、類似した文字を使用しているため）の問題について説明しており、チャットルームは、紛らわしいニックネームを軽減するメカニズムを提供できます（MAY）。
Recipients of IMs should be cautious with the rendering of content, which can be malicious in nature. This includes, but is not limited to, the reception of HTML and JavaScript scripts, executable code, phishing attempts, etc. Endpoints SHOULD always request permission from the user before executing one of these actions.
IMの受信者は、コンテンツのレンダリングに注意する必要があります。これには、HTMLおよびJavaScriptスクリプトの受信、実行可能コード、フィッシングの試みなどが含まれますが、これらに限定されません。エンドポイントは、これらのアクションのいずれかを実行する前に、常にユーザーに許可を要求する必要があります。
It must be noted that endpoints using a TLS client side certificate with real names in the certificates will not be anonymous to the MSRP switch to which they connect. While the name in the certificate might not be used by MSRP, the server will have a certificate with the actual name in it.
証明書に実際の名前が付いたTLSクライアント側の証明書を使用するエンドポイントは、接続先のMSRPスイッチに対して匿名ではないことに注意する必要があります。証明書の名前はMSRPで使用されない場合がありますが、サーバーには実際の名前が入った証明書があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<http://www.rfc-editor.org/info/rfc3323> 。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）でのユーザーエージェント機能の表示」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<http：// www .rfc-editor.org / info / rfc3840>。
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, <http://www.rfc-editor.org/info/rfc3860>.
[RFC3860] Peterson、J。、「Common Profile for Instant Messaging（CPIM）」、RFC 3860、DOI 10.17487 / RFC3860、2004年8月、<http://www.rfc-editor.org/info/rfc3860>。
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <http://www.rfc-editor.org/info/rfc3862>.
[RFC3862] Klyne、G。およびD. Atkins、「Common Presence and Instant Messaging（CPIM）：Message Format」、RFC 3862、DOI 10.17487 / RFC3862、2004年8月、<http://www.rfc-editor.org/ info / rfc3862>。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353] Rosenberg、J。、「Session Initiation Protocol（SIP）による会議のフレームワーク」、RFC 4353、DOI 10.17487 / RFC4353、2006年2月、<http://www.rfc-editor.org/info/rfc4353 >。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、編、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、DOI 10.17487 / RFC4575、2006年8月、<http： //www.rfc-editor.org/info/rfc4575>。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.
[RFC4975] Campbell、B.、Ed。、Mahy、R.、Ed。、and C. Jennings、Ed。、 "The Message Session Relay Protocol（MSRP）"、RFC 4975、DOI 10.17487 / RFC4975、September 2007、< http://www.rfc-editor.org/info/rfc4975>。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <http://www.rfc-editor.org/info/rfc4976>.
[RFC4976] Jennings、C.、Mahy、R。、およびA. Roach、「Relay Extensions for the Message Sessions Relay Protocol（MSRP）」、RFC 4976、DOI 10.17487 / RFC4976、2007年9月、<http：// www。 rfc-editor.org/info/rfc4976>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <http://www.rfc-editor.org/info/rfc5239>.
[RFC5239] Barnes、M.、Boulton、C。、およびO. Levin、「集中型会議のためのフレームワーク」、RFC 5239、DOI 10.17487 / RFC5239、2008年6月、<http://www.rfc-editor.org/ info / rfc5239>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <http://www.rfc-editor.org/info/rfc6501>.
[RFC6501] Novo、O.、Camarillo、G.、Morgan、D。、およびJ. Urpalainen、「集中会議（XCON）の会議情報データモデル」、RFC 6501、DOI 10.17487 / RFC6501、2012年3月、<http： //www.rfc-editor.org/info/rfc6501>。
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, DOI 10.17487/RFC6502, March 2012, <http://www.rfc-editor.org/info/rfc6502>.
[RFC6502] Camarillo、G.、Srinivasan、S.、Even、R。、およびJ. Urpalainen、「集中型会議（XCON）の会議イベントパッケージデータ形式拡張」、RFC 6502、DOI 10.17487 / RFC6502、2012年3月、< http://www.rfc-editor.org/info/rfc6502>。
[RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 7700, DOI 10.17487/RFC7700, December 2015, <http://www.rfc-editor.org/info/rfc7700>.
[RFC7700] Saint-Andre、P。、「ニックネームを表す国際化された文字列の準備、施行、比較」、RFC 7700、DOI 10.17487 / RFC7700、2015年12月、<http://www.rfc-editor.org/info/ rfc7700>。
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, DOI 10.17487/RFC2810, April 2000, <http://www.rfc-editor.org/info/rfc2810>.
[RFC2810] Kalt、C。、「インターネットリレーチャット：アーキテクチャ」、RFC 2810、DOI 10.17487 / RFC2810、2000年4月、<http://www.rfc-editor.org/info/rfc2810>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼できるネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<http ：//www.rfc-editor.org/info/rfc3325>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、DOI 10.17487 / RFC4474、2006年8月、<http：//www.rfc-editor。 org / info / rfc4474>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<http://www.rfc-editor.org/info/rfc6120 >。
Acknowledgments
謝辞
The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian Georgescu, Nancy Greene, Cullen Jennings, Flemming Andreasen, Suresh Krishnan, Christer Holmberg, Saul Ibarra, Enrico Marocco, Alexey Melnikov, Peter Saint-Andre, Stephen Farrell, and Martin Stiemerling for providing comments.
著者は、エヴァ・レパネン、アダム・ハルナ、アダム・ローチ、マット・レピンスキー、メアリー・バーンズ、ベン・キャンベル、ポール・キジバット、アドリアン・ジョルジェスク、ナンシー・グリーン、カレン・ジェニングス、フレミング・アンドレーセン、スレッシュ・クリシュナン、クリスター・ホルムバーグ、ソール・イバラ、エンリコ・マロッコ、コメントを提供してくれたAlexey Melnikov、Peter Saint-Andre、Stephen Farrell、Martin Stiemerling。
Contributors
貢献者
This work would have never been possible without the fruitful discussions on the SIMPLE WG mailing list, especially with Brian Rosen (Neustar) and Paul Kyzivat (Huawei), who provided extensive review and improvements throughout the document.
この作業は、SIMPLE WGメーリングリストでの実りある議論なくしては不可能でした。特に、Brian Rosen（Neustar）とPaul Kyzivat（Huawei）は、ドキュメント全体にわたって広範なレビューと改善を提供しました。
Authors' Addresses
著者のアドレス
Aki Niemi
ニエミアキ
Email: aki.niemi@iki.fi
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain
ミゲルA.ガルシアマルティンエリクソンCalle Via de los Poblados 13マドリード、ES 28033スペイン
Email: miguel.a.garcia@ericsson.com
Geir A. Sandbakken Cisco Systems Philip Pedersensvei 1 1366 Lysaker Norway
Geir A. Sandbakken Cisco Systems Philip Pedersensvei 1 1366 Lysaker Norway
Email: geirsand@cisco.com