RFC4582 日本語訳
4582 The Binary Floor Control Protocol (BFCP). G. Camarillo, J. Ott,K. Drage. November 2006. (Format: TXT=154497 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo
Request for Comments: 4582 Ericsson
Category: Standards Track J. Ott
Helsinki University of Technology
K. Drage
Lucent Technologies
November 2006
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 4582年のエリクソンカテゴリ: 規格はルーセントテクノロジーズ2006年11月に技術K.DrageのJ.オットヘルシンキ大学を追跡します。
The Binary Floor Control Protocol (BFCP)
2進の床の制御プロトコル(BFCP)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
床のコントロールは(「マルチ-パーティー」)会議環境における共用資源への共同しているか排他的なアクセスを管理する手段です。 その結果、床のコントロールは会議やメディアセッションセットアップなどの他の機能、会議方針操作、およびメディアコントロール(他のプロトコルによって実感される)の補足となります。
This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
このドキュメントはBinary Floor Controlプロトコル(BFCP)を指定します。 BFCPは床の関係者と床の制御サーバの間と、そして、床のいす(すなわち、議長)と床の制御サーバの間で使用されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Scope ...........................................................5
3.1. Floor Creation .............................................7
3.2. Obtaining Information to Contact a Floor Control Server ....7
3.3. Obtaining Floor-Resource Associations ......................7
3.4. Privileges of Floor Control ................................8
4. Overview of Operation ...........................................8
4.1. Floor Participant to Floor Control Server Interface ........8
4.2. Floor Chair to Floor Control Server Interface .............13
1. 序論…4 2. 用語…4 3. 範囲…5 3.1. 床の作成…7 3.2. 床に接触するために情報を得て、サーバを制御してください…7 3.3. 床リソース協会を得ます…7 3.4. 床の特権は制御されます…8 4. 操作の概要…8 4.1. 床のコントロールサーバインタフェースへの床の関係者…8 4.2. 床のコントロールサーバインタフェースへの床のいす…13
Camarillo, et al. Standards Track [Page 1] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[1ページ]。
5. Packet Format ..................................................14
5.1. COMMON-HEADER Format ......................................15
5.2. Attribute Format ..........................................16
5.2.1. BENEFICIARY-ID .....................................18
5.2.2. FLOOR-ID ...........................................18
5.2.3. FLOOR-REQUEST-ID ...................................19
5.2.4. PRIORITY ...........................................19
5.2.5. REQUEST-STATUS .....................................20
5.2.6. ERROR-CODE .........................................21
5.2.6.1. Error-Specific Details for Error Code 4 ...22
5.2.7. ERROR-INFO .........................................22
5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
5.2.9. STATUS-INFO ........................................24
5.2.10. SUPPORTED-ATTRIBUTES ..............................24
5.2.11. SUPPORTED-PRIMITIVES ..............................25
5.2.12. USER-DISPLAY-NAME .................................26
5.2.13. USER-URI ..........................................26
5.2.14. BENEFICIARY-INFORMATION ...........................27
5.2.15. FLOOR-REQUEST-INFORMATION .........................27
5.2.16. REQUESTED-BY-INFORMATION ..........................28
5.2.17. FLOOR-REQUEST-STATUS .............................29
5.2.18. OVERALL-REQUEST-STATUS ...........................30
5.3. Message Format ............................................30
5.3.1. FloorRequest .......................................31
5.3.2. FloorRelease .......................................31
5.3.3. FloorRequestQuery ..................................31
5.3.4. FloorRequestStatus .................................31
5.3.5. UserQuery ..........................................32
5.3.6. UserStatus .........................................32
5.3.7. FloorQuery .........................................32
5.3.8. FloorStatus ........................................33
5.3.9. ChairAction ........................................33
5.3.10. ChairActionAck ....................................33
5.3.11. Hello .............................................33
5.3.12. HelloAck ..........................................34
5.3.13. Error .............................................34
6. Transport ......................................................34
7. Lower-Layer Security ...........................................35
8. Protocol Transactions ..........................................35
8.1. Client Behavior ...........................................36
8.2. Server Behavior ...........................................36
9. Authentication and Authorization ...............................36
9.1. TLS-Based Mutual Authentication ...........................37
10. Floor Participant Operations ..................................37
10.1. Requesting a Floor .......................................37
10.1.1. Sending a FloorRequest Message ....................38
10.1.2. Receiving a Response ..............................38
10.2. Cancelling a Floor Request and Releasing a Floor .........40
5. パケット形式…14 5.1. 一般的なヘッダー形式…15 5.2. 形式を結果と考えてください…16 5.2.1. 受益者のID…18 5.2.2. FLOOR ID…18 5.2.3. 床のREQUEST ID…19 5.2.4. 優先権…19 5.2.5. 要求状態…20 5.2.6. 誤りコード…21 5.2.6.1. 誤りのための誤り特有の詳細は4をコード化します…22 5.2.7. 誤りインフォメーション…22 5.2.8. 関係者はインフォメーションを提供しました…23 5.2.9. 状態インフォメーション…24 5.2.10. サポートしている属性…24 5.2.11. サポートしている基関数…25 5.2.12. ユーザディスプレイ名…26 5.2.13. ユーザユリ…26 5.2.14. 受益者の情報…27 5.2.15. 床の要求情報…27 5.2.16. 情報で、要求されます…28 5.2.17. 床の要求状態…29 5.2.18. 総合的な要求状態…30 5.3. メッセージ形式…30 5.3.1. FloorRequest…31 5.3.2. FloorRelease…31 5.3.3. FloorRequestQuery…31 5.3.4. FloorRequestStatus…31 5.3.5. UserQuery…32 5.3.6. UserStatus…32 5.3.7. FloorQuery…32 5.3.8. FloorStatus…33 5.3.9. ChairAction…33 5.3.10. ChairActionAck…33 5.3.11. こんにちは…33 5.3.12. HelloAck…34 5.3.13. 誤り…34 6. 輸送…34 7. 下層セキュリティ…35 8. トランザクションについて議定書の中で述べてください…35 8.1. クライアントの振舞い…36 8.2. サーバの振舞い…36 9. 認証と承認…36 9.1. TLSベースの互いの認証…37 10. 床の関係者操作…37 10.1. 床を要求します…37 10.1.1. FloorRequestメッセージを送ります…38 10.1.2. 応答を受けます…38 10.2. 床の要求を中止して、床をリリースします…40
Camarillo, et al. Standards Track [Page 2] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[2ページ]。
10.2.1. Sending a FloorRelease Message ....................40
10.2.2. Receiving a Response ..............................40
11. Chair Operations ..............................................41
11.1. Sending a ChairAction Message ............................41
11.2. Receiving a Response .....................................42
12. General Client Operations .....................................43
12.1. Requesting Information about Floors ......................43
12.1.1. Sending a FloorQuery Message ......................43
12.1.2. Receiving a Response ..............................43
12.2. Requesting Information about Floor Requests ..............44
12.2.1. Sending a FloorRequestQuery Message ...............45
12.2.2. Receiving a Response ..............................45
12.3. Requesting Information about a User ......................45
12.3.1. Sending a UserQuery Message .......................46
12.3.2. Receiving a Response ..............................46
12.4. Obtaining the Capabilities of a Floor Control Server .....46
12.4.1. Sending a Hello Message ...........................47
12.4.2. Receiving Responses ...............................47
13. Floor Control Server Operations ...............................47
13.1. Reception of a FloorRequest Message ......................48
13.1.1. Generating the First FloorRequestStatus Message ...48
13.1.2. Generation of Subsequent
FloorRequestStatus Messages .......................50
13.2. Reception of a FloorRequestQuery Message .................51
13.3. Reception of a UserQuery Message .........................52
13.4. Reception of a FloorRelease Message ......................53
13.5. Reception of a FloorQuery Message ........................54
13.5.1. Generation of the First FloorStatus Message .......55
13.5.2. Generation of Subsequent FloorStatus Messages .....56
13.6. Reception of a ChairAction Message .......................56
13.7. Reception of a Hello Message .............................57
13.8. Error Message Generation .................................58
14. Security Considerations .......................................58
15. IANA Considerations ...........................................59
15.1. Attribute Subregistry ....................................59
15.2. Primitive Subregistry ....................................60
15.3. Request Status Subregistry ...............................61
15.4. Error Code Subregistry ...................................62
16. Acknowledgements ..............................................62
17. References ....................................................63
17.1. Normative References .....................................63
17.2. Informational References .................................63
10.2.1. FloorReleaseメッセージを送ります…40 10.2.2. 応答を受けます…40 11. 議長Operations…41 11.1. ChairActionメッセージを送ります…41 11.2. 応答を受けます…42 12. 一般クライアント操作…43 12.1. 床に関する情報を要求します…43 12.1.1. FloorQueryメッセージを送ります…43 12.1.2. 応答を受けます…43 12.2. 床の要求に関する情報を要求します…44 12.2.1. FloorRequestQueryメッセージを送ります…45 12.2.2. 応答を受けます…45 12.3. ユーザに関する情報を要求します…45 12.3.1. UserQueryメッセージを送ります…46 12.3.2. 応答を受けます…46 12.4. 床の能力を得て、サーバを制御してください…46 12.4.1. メッセージをこんにちはに送ります…47 12.4.2. 応答を受けます…47 13. 床のコントロールサーバ操作…47 13.1. FloorRequestメッセージのレセプション…48 13.1.1. 最初のFloorRequestStatusメッセージを生成します…48 13.1.2. その後のFloorRequestStatusメッセージの世代…50 13.2. FloorRequestQueryメッセージのレセプション…51 13.3. UserQueryメッセージのレセプション…52 13.4. FloorReleaseメッセージのレセプション…53 13.5. FloorQueryメッセージのレセプション…54 13.5.1. 最初のFloorStatusメッセージの世代…55 13.5.2. その後のFloorStatusメッセージの世代…56 13.6. ChairActionメッセージのレセプション…56 13.7. こんにちはのレセプションは通信します…57 13.8. エラーメッセージ世代…58 14. セキュリティ問題…58 15. IANA問題…59 15.1. Subregistryを結果と考えてください…59 15.2. 原始のSubregistry…60 15.3. 状態Subregistryを要求してください…61 15.4. エラーコードSubregistry…62 16. 承認…62 17. 参照…63 17.1. 標準の参照…63 17.2. 情報の参照…63
Camarillo, et al. Standards Track [Page 3] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[3ページ]。
1. Introduction
1. 序論
Within a conference, some applications need to manage the access to a set of shared resources, such as the right to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources.
会議の中では、いくつかのアプリケーションが、1セットの共用資源へのアクセスを管理する必要があります、特定のメディアセッションにメディアを送る権利などのように。 床のコントロールは、そのようなアプリケーションがこれらのリソースへの連携している(共有されたか排他的な)アクセスをユーザに提供するのを可能にします。
The Requirements for Floor Control Protocol [9] list a set of requirements that need to be met by floor control protocols. The Binary Floor Control Protocol (BFCP), which is specified in this document, meets these requirements.
Floor Controlプロトコル[9]のためのRequirementsは床の制御プロトコルによって会われる必要がある1セットの要件をリストアップします。 Binary Floor Controlプロトコル(BFCP)はこれらの必要条件を満たします。(それは、本書では指定されます)。
In addition, BFCP has been designed so that it can be used in low-bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keeps the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in a significant way.
さらに、BFCPは、低バンド幅環境でそれを使用できるように設計されています。 BFCPによって使用された2進のコード化はわざわざそれが遅れ機密のBFCPメッセージを最小限に送る保つ小さいメッセージサイズ(メッセージ署名が使用されていないとき)を達成します。 遅れ機密のBFCPメッセージはFloorRequest、FloorRelease、FloorRequestStatus、およびChairActionを含んでいます。 これらのメッセージへの今後の拡大が重要な方法でこれらのメッセージのサイズを増強しないと予想されます。
The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms), Section 4 provides a non-normative overview of BFCP operation, and subsequent sections provide the normative specification of BFCP.
このドキュメントの残りは以下の通り組織化されます: セクション2はこのドキュメント中で使用される用語を定義します、そして、セクション3はBFCPの範囲について議論します、そして、(すなわち、どのタスクがBFCPの範囲の中に下がるか、そして、どれが異なったメカニズムを使用することで実行されますか)セクション4はBFCP操作の非標準の概要を提供します、そして、その後のセクションはBFCPの標準の仕様を提供します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
Media Participant: An entity that has access to the media resources of a conference (e.g., it can receive a media stream). In floor- controlled conferences, a given media participant is typically colocated with a floor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. The protocol between a floor participant and a media participant (that are not colocated) is outside the scope of this document.
メディア関係者: 会議(例えば、それはメディアストリームを受けることができる)に関するメディアリソースに近づく手段を持っている実体。 床の関係者と共にcolocatedされて、与えられたメディア関係者は通常、そうですが、床の制御会議では、それはそうする必要はないこと。 それらがcolocatedされないと床の関係者にメディア関係者のために床を要求させるのから第三者床の要求は成ります。 このドキュメントの範囲の外に床の関係者とメディア関係者(それはcolocatedされない)の間のプロトコルがあります。
Client: A floor participant or a floor chair that communicates with a floor control server using BFCP.
クライアント: BFCPを使用することで床の制御サーバとコミュニケートする床の関係者か床のいす。
Camarillo, et al. Standards Track [Page 4] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[4ページ]。
Floor: A temporary permission to access or manipulate a specific shared resource or set of resources.
床: 特定の共用資源か1セットのリソースをアクセスするか、または操る一時的な許可。
Floor Chair: A logical entity that manages one floor (grants, denies, or revokes a floor). An entity that assumes the logical role of a floor chair for a given transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floor chair and floor participant are defined on a transaction-by- transaction basis. BFCP transactions are defined in Section 8.
床のいす: 1階(床を与えるか、否定するか、または取り消す)を管理する論理的な実体。 与えられたトランザクションのために床のいすの論理的な役割を引き受ける実体は、異なったトランザクションのために異なる役割が(例えば、床の関係者)であると仮定するかもしれません。 床のいすと床の関係者の役割は近くトランザクショントランザクションで定義されます。基礎。 BFCPトランザクションはセクション8で定義されます。
Floor Control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource.
床のコントロール: アプリケーションかユーザが共有されたオブジェクトかリソースへの安全で互いに排他的であるか非排他的な入力アクセスを得るのを可能にするメカニズム。
Floor Control Server: A logical entity that maintains the state of the floor(s), including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server. The floor control server of a conference may perform other logical roles (e.g., floor participant) in another conference.
床の制御サーバ: 床のいすが人である、床の状態を維持する論理的な実体、どの床を含んでいるかは存在していて、だれが床などを保持するか。 床の制御サーバは床を操作するという要求に向けられます。会議の床の制御サーバは別の会議における他の論理的な役割(例えば、床の関係者)を実行するかもしれません。
Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server. An entity that assumes the logical role of a floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles of floor participant and floor chair are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8. In floor-controlled conferences, a given floor participant is typically colocated with a media participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated.
床の関係者: 床を要求する論理的な実体、およびことによるとそれらの情報. 与えられたトランザクションのために床の関係者の論理的な役割を引き受ける実体は床の制御サーバと、異なったトランザクションのために異なる役割が(例えば、床のいす)であると仮定するかもしれません。 床の関係者と床のいすの役割はトランザクションごとのベースで定義されます。 BFCPトランザクションはセクション8で定義されます。 メディア関係者と共にcolocatedされて、与えられた床の関係者は通常、そうですが、床で制御された会議では、それはそうする必要はないこと。 それらがcolocatedされないと床の関係者にメディア関係者のために床を要求させるのから第三者床の要求は成ります。
Participant: An entity that acts as a floor participant, as a media participant, or as both.
関係者: 床の関係者として、または、メディア関係者として、または、両方として機能する実体。
3. Scope
3. 範囲
As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [9]. Floor control complements other functions defined in the XCON conferencing framework [10]. The floor control protocol BFCP defined in this document only specifies a means to arbitrate access to floors. The rules and constraints for floor arbitration and the results of floor assignments are outside the scope of this document and are defined by other protocols [10].
より早く述べられるように、BFCPは[9]で定義された要件に続いて、会議で共用資源へのアクセスを調整するプロトコルです。 床のコントロールはXCON会議フレームワーク[10]で定義された他の機能の補足となります。 BFCPが定義した床の制御プロトコルは本書では床へのアクセスを仲裁する手段を指定するだけです。 床の仲裁の規則と規制と床の課題の結果は、このドキュメントの範囲の外にあって、他のプロトコル[10]によって定義されます。
Camarillo, et al. Standards Track [Page 5] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[5ページ]。
Figure 1 shows the tasks that BFCP can perform.
図1は、BFCPが働くことができるのをタスクに示します。
+---------+
| Floor |
| Chair |
| |
+---------+
^ |
| |
Notification | | Decision
| |
| |
Floor | v
+-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant |
| |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+
Denied
+---------+ | 床| | 議長| | | +---------+ ^ | | | 通知| | 決定| | | | 床| +に対して-------------+ 要求+---------+ +-------------+ | 床|、-、-、-、-、-、-、-、-、-、--、>| 床| 通知| 床| | 関係者| | コントロール|、-、-、-、-、-、-、-、-、-、-、-、--、>| 関係者| | | <、-、-、-、-、-、-、-、-、-、--、| サーバ| | | +-------------与えられた+か+---------+ +-------------否定された+
Figure 1: Functionality provided by BFCP
図1: BFCPによって提供された機能性
BFCP provides a means:
BFCPは手段を提供します:
o for floor participants to send floor requests to floor control
servers.
o 床の関係者が床を送るのが床のコントロールにサーバを要求します。
o for floor control servers to grant or deny requests to access a
given resource from floor participants.
o 床に関しては、床の関係者から与えられたリソースにアクセスするという要求をサーバを制御して、承諾するか、または否定してください。
o for floor chairs to send floor control servers decisions regarding
floor requests.
o 床のいすが床を送るには、床の要求に関するサーバ決定を制御してください。
o for floor control servers to keep floor participants and floor
chairs informed about the status of a given floor or a given floor
request.
o 床の制御サーバが床の関係者と床のいすを保つのは与えられた床か与えられた床の要求の状態に関して知らせました。
Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them.
それが果たすタスクは属しませんが、前のリストには、床のコントロールに関連して、床を作成するのに不可欠であり、異なった実体の間でBFCP接続を確立するタスクが範囲の外にBFCPの範囲、これらのいくつか外にあります。 以下の小区分では、私たちは、それらを実行するためにこれらのタスクといくつかのメカニズムについて議論します。
Camarillo, et al. Standards Track [Page 6] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[6ページ]。
3.1. Floor Creation
3.1. 床の作成
The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in [10]. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created).
BFCPの範囲の外にリソースがある与えられた床の協会か1セットのリソース(例えば、メディアストリーム)が[10]で説明されるようにあります。 BFCPの範囲の外にも床の作成と終了があります。 これらの局面は、会議オブジェクトを操作するのに会議制御プロトコルを使用することで扱われます。 その結果、床の制御サーバは、会議オブジェクトへの変化で最新の(例えば、新しい床はいつ作成されますか)ままである必要があります。
3.2. Obtaining Information to Contact a Floor Control Server
3.2. 床の制御サーバに連絡するために情報を得ます。
A client needs a set of data in order to establish a BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and a user identifier.
クライアントは、床の制御サーバにBFCP接続を確立するために1セットのデータを必要とします。これらのデータはサーバの輸送アドレス、会議識別子、およびユーザ識別子を含んでいます。
Clients can obtain this information in different ways. One is to use an SDP offer/answer [8] exchange, which is described in [7]. Other mechanisms are described in the XCON framework [10] (and other related documents).
クライアントは異なった方法でこの情報を得ることができます。 1つはSDP申し出/答え[8]交換を使用することになっています。(それは、[7]で説明されます)。 他のメカニズムはXCONフレームワーク[10](そして、他の関連するドキュメント)で説明されます。
3.3. Obtaining Floor-Resource Associations
3.3. 床リソース協会を得ます。
Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio session as its associated resource. Associations between floors and resources are part of the conference object.
床はリソースに関連しています。 例えば、だれが一時に話すかを制御する床は関連リソースとして特定のオーディオセッションを過します。 床とリソースとの協会は会議オブジェクトの一部です。
Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer [8] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [7].
床の関係者と床のいすは、どのリソースがどの床に関連しているかを知る必要があります。 彼らは、SDP申し出/答え[8]交換などの異なったメカニズムを使用することによって、この情報を得ることができます。 これらの協会を得るのにどうSDP申し出/答え交換を使用するかは[7]で説明されます。
Note that floor participants perform SDP offer/answer exchanges
with the conference focus of the conference. So, the conference
focus needs to obtain information about associations between
floors and resources in order to be able to provide this
information to a floor participant in an SDP offer/answer
exchange.
床の関係者が会議の会議焦点でSDP申し出/答え交換を実行することに注意してください。 それで、会議焦点は、SDP申し出/答え交換の床の関係者にこの情報を提供できるように床とリソースとの協会の情報を得る必要があります。
Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP) Focus, are described in the XCON framework [10] (and other related documents).
(SIP)焦点がどう情報を入手するかに関する議論を含むこの情報を得るための他のメカニズムはXCONフレームワーク[10](そして、他の関連するドキュメント)で説明されます。
Camarillo, et al. Standards Track [Page 7] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[7ページ]。
3.4. Privileges of Floor Control
3.4. 床のコントロールの特権
A participant whose floor request is granted has the right to use (in a certain way) the resource or resources associated with the floor that was requested. For example, the participant may have the right to send media over a particular audio stream.
床の要求が承諾される関係者は要求された床に関連しているリソースかリソースを使用する(ある方法で)権利を持っています。 例えば、関係者には、特定のオーディオストリームの上にメディアを送る権利があるかもしれません。
Nevertheless, holding a floor does not imply that others will not be able to use its associated resources at the same time, even if they do not have the right to do so. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework [10].
それにもかかわらず、床を持っているのは、他のものが同時に関連リソースを使用できないのを含意しません、それらにそうする権利がなくても。 XCON Framework[10]でメディア関係者が実際に会議にリソースを使用できる決断について議論します。
4. Overview of Operation
4. 操作の概要
This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between floor participants and floor control servers, and Section 4.2 describes the interface between floor chairs and floor control servers.
このセクションはBFCP操作の非標準の記述を提供します。 セクション4.1は床の関係者と床の制御サーバとのインタフェースについて説明します、そして、セクション4.2は床のいすと床の制御サーバとのインタフェースについて説明します。
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of a common header followed by a set of attributes. The common header contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers.
BFCPメッセージ(TLV(長さの値をタイプする)の2進のコード化を使用する)は1セットの属性があとに続いた一般的なヘッダーから成ります。 一般的なヘッダーは他の情報の中に32ビットの会議識別子を含んでいます。 床の関係者、メディア関係者、および床のいすは16ビットのユーザ識別子によって特定されます。
BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes.
BFCPは、入れ子にされた属性が(すなわち、属性を含む属性)であるとサポートします。 これらは分類された属性と呼ばれます。
There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a message from a client to the floor control server and a response from the floor control server to the client. Both messages can be related because they carry the same Transaction ID value in their common headers. Server-initiated transactions consist of a single message, whose Transaction ID is 0, from the floor control server to a client.
2つのタイプのトランザクションがBFCPにあります: クライアントによって開始されたトランザクションとサーバで開始しているトランザクション。 クライアントによって開始されたトランザクションはクライアントから床の制御サーバまでのメッセージと床の制御サーバからクライアントまでの応答から成ります。 彼らの一般的なヘッダーで同じTransaction ID価値を運ぶので、両方のメッセージについて話すことができます。 サーバで開始しているトランザクションは床の制御サーバからクライアントまでTransaction IDが0であるただ一つのメッセージから成ります。
4.1. Floor Participant to Floor Control Server Interface
4.1. 床のコントロールサーバインタフェースへの床の関係者
Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be colocated with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the common header, and the identity of the beneficiary of the floor (in third- party floor requests) in a BENEFICIARY-ID attribute.
床の関係者は、床の制御サーバにFloorRequestメッセージを送ることによって、床を要求します。BFCPは床の要求を第三者にサポートします。 すなわち、床の要求を送る床の関係者は床の要求がいったん承諾されると発言権を得るメディア関係者と共にcolocatedされる必要はありません。 FloorRequestメッセージは一般的なヘッダーのUser ID分野のリクエスタのアイデンティティ、およびBENEFICIARY-ID属性における、床(3番目のパーティー床の要求における)の受益者のアイデンティティを運びます。
Camarillo, et al. Standards Track [Page 8] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[8ページ]。
Third-party floor requests can be sent, for example, by floor
participants that have a BFCP connection to the floor control
server but that are not media participants (i.e., they do not
handle any media).
例えば、床の制御サーバにはBFCP接続がありますが、メディア関係者でない床の関係者は第三者床の要求を送ることができます(すなわち、彼らはどんなメディアも扱いません)。
FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message.
FloorRequestメッセージはFLOOR-ID属性におけるそれらの16ビットの床の識別子を運ぶことによって要求されている床か床を特定します。 FloorRequestメッセージが1つ以上の床の識別子を運ぶなら、床の制御サーバはすべての床の要求を原子パッケージとして扱います。 すなわち、床の制御サーバは、FloorRequestメッセージですべての床を与えるか、または否定します。
Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest.
床の制御サーバはFloorRequestStatusメッセージでFloorRequestメッセージに反応します。(メッセージは床の要求の状態の情報を提供します)。 最初のFloorRequestStatusメッセージは、クライアントからのFloorRequestメッセージへの応答であり、したがって、FloorRequestと同じTransaction IDを持っています。
Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request.
さらに、最初のFloorRequestStatusメッセージはFLOOR-REQUEST-情報属性におけるFloor Request IDを運びます。 同じ床の要求に関連するその後のFloorRequestStatusメッセージは同じFloor Request IDを運ぶでしょう。 このように、床の関係者は適切な床の要求にそれらを関連づけることができます。
Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatus Message from the floor control server.
また、特定の床の要求に関連する床の関係者からのメッセージは床の制御サーバから最初のFloorRequestStatus Messageと同じFloor Request IDを使用します。
Figure 2 shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute.
図2は床の関係者がどう床を要求して、それを得て、後でそれをリリースするかを示しています。 この図はTransaction IDとFLOOR-REQUEST-ID属性について使用を特に例証します。
Camarillo, et al. Standards Track [Page 9] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[9ページ]。
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(5) FloorRelease |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
床の関係者床の制御サーバ|(1) FloorRequest| |トランザクションID: 123 | |ユーザID: 234 | |FLOOR ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus| |トランザクションID: 123 | |ユーザID: 234 | |床の要求情報| | 床の要求ID: 789 | | 総合的な要求状態| | 状態を要求してください: 未定| | 床の要求状態| | 床のID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus| |トランザクションID: 0 | |ユーザID: 234 | |床の要求情報| | 床の要求ID: 789 | | 総合的な要求状態| | 状態を要求してください: 受け入れます。| | 位置を列に並ばせてください: 1番目| | 床の要求状態| | 床のID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatus| |トランザクションID: 0 | |ユーザID: 234 | |床の要求情報| | 床の要求ID: 789 | | 総合的な要求状態| | 状態を要求してください: 与えます。| | 床の要求状態| | 床のID: 543 | |<----------------------------------------------| | | |(5) FloorRelease| |トランザクションID: 154 | |ユーザID: 234 | |床のREQUEST ID: 789 | |---------------------------------------------->|
Camarillo, et al. Standards Track [Page 10] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[10ページ]。
| |
|(6) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| | |(6) FloorRequestStatus| |トランザクションID: 154 | |ユーザID: 234 | |床の要求情報| | 床の要求ID: 789 | | 総合的な要求状態| | 状態を要求してください: リリースされます。| | 床の要求状態| | 床のID: 543 | |<----------------------------------------------|
Figure 2: Requesting and releasing a floor
図2: 床を要求して、リリースします。
Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message.
床の関係者が、床の状態で知識があるようどう要求するかを図3は示しています。 床の制御サーバからの最初のFloorStatusメッセージは、FloorQueryメッセージへの応答であり、そういうものとしてFloorQueryメッセージと同じTransaction IDを持っています。
Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted.
その後のFloorStatusメッセージはサーバで開始しているトランザクションから成ります、そして、したがって、それらのTransaction IDは0です。 FloorStatusメッセージ(2)は、Floor IDが543である床を求める2つの床の要求が現在あるのを示します。 FloorStatusメッセージ(3)は、床が、Floor Requestと共にID764が与えられたよう要求するのを示します、そして、Floor Request ID635との床の要求は待ち行列で1番目です。 FloorStatusメッセージ(4)は、Floor Request ID635との床の要求が承諾されたのを示します。
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
床の関係者床の制御サーバ|(1) FloorQuery| |トランザクションID: 257 | |ユーザID: 234 | |FLOOR ID: 543 | |---------------------------------------------->|
Camarillo, et al. Standards Track [Page 11] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[11ページ]。
| |
|(2) FloorStatus |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| | |(2) FloorStatus| |トランザクションID: 257 | |ユーザID: 234 | |FLOOR ID: 543| |床の要求情報| | 床の要求ID: 764 | | 総合的な要求状態| | 状態を要求してください: 受け入れます。| | 位置を列に並ばせてください: 1番目| | 床の要求状態| | 床のID: 543 | | 受益者の情報| | 受益者のID: 124 | |床の要求情報| | 床の要求ID: 635 | | 総合的な要求状態| | 状態を要求してください: 受け入れます。| | 位置を列に並ばせてください: 2番目| | 床の要求状態| | 床のID: 543 | | 受益者の情報| | 受益者のID: 154 | |<----------------------------------------------| | | |(3) FloorStatus| |トランザクションID: 0 | |ユーザID: 234 | |FLOOR ID: 543| |床の要求情報| | 床の要求ID: 764 | | 総合的な要求状態| | 状態を要求してください: 与えます。| | 床の要求状態| | 床のID: 543 | | 受益者の情報| | 受益者のID: 124 | |床の要求情報| | 床の要求ID: 635 | | 総合的な要求状態| | 状態を要求してください: 受け入れます。| | 位置を列に並ばせてください: 1番目| | 床の要求状態| | 床のID: 543 | | 受益者の情報| | 受益者のID: 154 | |<----------------------------------------------|
Camarillo, et al. Standards Track [Page 12] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[12ページ]。
| |
|(4) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| | |(4) FloorStatus| |トランザクションID: 0 | |ユーザID: 234 | |FLOOR ID: 543| |床の要求情報| | 床の要求ID: 635 | | 総合的な要求状態| | 状態を要求してください: 与えます。| | 床の要求状態| | 床のID: 543 | | 受益者の情報| | 受益者のID: 154 | |<----------------------------------------------|
Figure 3: Obtaining status information about a floor
図3: 床の状態情報を得ます。
FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request.
FloorStatusメッセージはそれらが運ぶ床の要求の情報を含んでいます。 例えば、FloorStatusメッセージ(4)は、Floor Request ID635との床の要求には受益者(すなわち、特定の床の要求が承諾されるとき床を持っている関係者)としてUser IDが154である関係者がいるのを示します。 床の要求はFloor IDが543である床だけに適用されます。 すなわち、これはマルチ床の床の要求ではありません。
A multi-floor floor request applies to more than one floor (e.g.,
a participant wants to be able to speak and write on the
whiteboard at the same time). The floor control server treats a
multi-floor floor request as an atomic package. That is, the
floor control server either grants the request for all floors or
denies the request for all floors.
マルチ床の床の要求は1階以上に適用されます(例えば関係者は同時にホワイトボードを話して、書き続けることができるようになりたがっています)。 床の制御サーバはマルチ床の床の要求を原子パッケージとして扱います。 すなわち、床の制御サーバは、すべての床に要求を承諾するか、またはすべての床に対して要求を否定します。
4.2. Floor Chair to Floor Control Server Interface
4.2. 床のコントロールサーバインタフェースへの床のいす
Figure 4 shows a floor chair instructing a floor control server to grant a floor.
図4は、床のいすが、床を与えるよう床の制御サーバに命令するのを示します。
Note, however, that although the floor control server needs to
take into consideration the instructions received in ChairAction
messages (e.g., granting a floor), it does not necessarily need to
perform them exactly as requested by the floor chair. The
operation that the floor control server performs depends on the
ChairAction message and on the internal state of the floor control
server.
しかしながら、床の制御サーバが、ChairActionメッセージ(例えば、床を与える)で受けられた指示を考慮に入れる必要がありますが、必ずまさに要求された通り床のいすでそれらを実行するのが必要であるというわけではないことに注意してください。 床の制御サーバが実行する操作はChairActionメッセージと、そして、床の制御サーバの内部の事情に依存します。
Camarillo, et al. Standards Track [Page 13] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[13ページ]。
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant.
例えば、床のいすはChairActionメッセージにいくつかの床にかかわった原子床の要求操作の一部として要求された床を与えさせるかもしれません。 床の1つに責任があるいすが、床を与えるよう床の制御サーバに命令しても、他の床に責任があるいすが、また、それらを与えるのに同意するまで、床の制御サーバはそれを与えないでしょう。 別の例では、床のいすは、床を関係者に与えるよう床の制御サーバに命令するかもしれません。 床の制御サーバは、それを与える前の現在の所有者から新しい関係者まで床を取り消す必要があります。
So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.
それで、一貫性を持っている床が状態であることをこの状態に入力されるように床のいすから指示を使用することで保つのに床の制御サーバは結局、原因となります。
Floor Chair Floor Control
Server
|(1) ChairAction |
|Transaction ID: 769 |
|User ID: 357 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| Request Status: Granted |
|---------------------------------------------->|
| |
|(2) ChairActionAck |
|Transaction ID: 769 |
|User ID: 357 |
|<----------------------------------------------|
床の議長床の制御サーバ|(1) ChairAction| |トランザクションID: 769 | |ユーザID: 357 | |床の要求情報| | 床の要求ID: 635 | | 床の要求状態| | 床のID: 543 | | 状態を要求してください: 与えます。| |---------------------------------------------->| | | |(2) ChairActionAck| |トランザクションID: 769 | |ユーザID: 357 | |<----------------------------------------------|
Figure 4: Chair instructing the floor control server
図4: 床の制御サーバを命令している議長
5. Packet Format
5. パケット・フォーマット
BFCP packets consist of a 12-octet common header followed by attributes. All the protocol values MUST be sent in network byte order.
BFCPパケットは属性があとに続いた12八重奏の一般的なヘッダーから成ります。 ネットワークバイトオーダーですべてのプロトコル値を送らなければなりません。
Camarillo, et al. Standards Track [Page 14] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[14ページ]。
5.1. COMMON-HEADER Format
5.1. 一般的なヘッダー形式
The following is the format of the common header.
↓これは一般的なヘッダーの形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver|予約されます。| 原始| ペイロード長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コンファレンスID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トランザクションID| ユーザID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format
図5: COMMON-HEADER形式
Ver: The 3-bit version field MUST be set to 1 to indicate this version of BFCP.
Ver: 3ビットのバージョン分野をBFCPのこのバージョンを示すように1に設定しなければなりません。
Reserved: At this point, the 5 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
予約される: ここに、予約された分野SHOULDの5ビットをメッセージ送信者によるゼロに設定されて、受信機で無視しなければなりません。
Primitive: This 8-bit field identifies the main purpose of the message. The following primitive values are defined:
原始: この8ビットの分野はメッセージの主な目的を特定します。 以下の原始の値は定義されます:
+-------+--------------------+------------------+
| Value | Primitive | Direction |
+-------+--------------------+------------------+
| 1 | FloorRequest | P -> S |
| 2 | FloorRelease | P -> S |
| 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorStatus | P <- S ; Ch <- S |
| 9 | ChairAction | Ch -> S |
| 10 | ChairActionAck | Ch <- S |
| 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S |
+-------+--------------------+------------------+
S: Floor Control Server
P: Floor Participant
Ch: Floor Chair
+-------+--------------------+------------------+ | 値| 原始| 方向| +-------+--------------------+------------------+ | 1 | FloorRequest| P->S| | 2 | FloorRelease| P->S| | 3 | FloorRequestQuery| P->S。 Ch->S| | 4 | FloorRequestStatus| P<S。 Ch<S| | 5 | UserQuery| P->S。 Ch->S| | 6 | UserStatus| P<S。 Ch<S| | 7 | FloorQuery| P->S。 Ch->S| | 8 | FloorStatus| P<S。 Ch<S| | 9 | ChairAction| Ch->S| | 10 | ChairActionAck| Ch<S| | 11 | こんにちは| P->S。 Ch->S| | 12 | HelloAck| P<S。 Ch<S| | 13 | 誤り| P<S。 Ch<S| +-------+--------------------+------------------+ S: 床の制御サーバP: 床の関係者Ch: 床のいす
Table 1: BFCP primitives
テーブル1: BFCP基関数
Camarillo, et al. Standards Track [Page 15] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[15ページ]。
Payload Length: This 16-bit field contains the length of the message in 4-octet units, excluding the common header.
ペイロード長: 一般的なヘッダーを除いて、この16ビットの分野は4八重奏のユニットのメッセージの長さを含んでいます。
Conference ID: This 32-bit field identifies the conference the message belongs to.
コンファレンスID: この32ビットの分野はメッセージが属す会議を特定します。
Transaction ID: This field contains a 16-bit value that allows users to match a given message with its response. The value of the Transaction ID in server-initiated transactions is 0 (see Section 8).
トランザクションID: この分野はユーザが与えられたメッセージを応答に合わせることができる16ビットの値を含んでいます。 サーバで開始しているトランザクションにおける、Transaction IDの値は0(セクション8を見る)です。
User ID: This field contains a 16-bit value that uniquely identifies a participant within a conference.
ユーザID: この分野は会議の中で唯一関係者を特定する16ビットの値を含んでいます。
The identity used by a participant in BFCP, which is carried in
the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of
this specification.
一般に、User ID分野で運ばれるBFCPの関係者によって使用されたアイデンティティはセッション設立プロトコル(例えば、SIPの)の同じ関係者によって使用されたアイデンティティに写像されます。 この仕様の範囲の外にこのマッピングが実行される方法があります。
5.2. Attribute Format
5.2. 属性形式
BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned.
BFCP属性はTLV(長さの値をタイプする)形式でコード化されます。 並べられた状態で、属性は32ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Attribute Contents /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|M| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /属性コンテンツ///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Attribute format
図6: 属性形式
Type: This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are:
以下をタイプしてください。 この7ビットの分野は属性のタイプを含んでいます。 タイプによって特定された各属性は特定の形式を持っています。 定義された属性書式は以下の通りです。
Unsigned16: The contents of the attribute consist of a 16-bit
unsigned integer.
Unsigned16: 属性の内容は16ビットの符号のない整数から成ります。
OctetString16: The contents of the attribute consist of 16 bits of
arbitrary data.
OctetString16: 属性の内容は16ビットの任意のデータから成ります。
Camarillo, et al. Standards Track [Page 16] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[16ページ]。
OctetString: The contents of the attribute consist of arbitrary
data of variable length.
OctetString: 属性の内容は可変長の任意のデータから成ります。
Grouped: The contents of the attribute consist of a sequence of
attributes.
分類される: 属性の内容は属性の系列から成ります。
Note that extension attributes defined in the future may define
new attribute formats.
将来定義された拡大属性が新しい属性書式を定義するかもしれないことに注意してください。
The following attribute types are defined:
以下の属性タイプは定義されます:
+------+---------------------------+---------------+
| Type | Attribute | Format |
+------+---------------------------+---------------+
| 1 | BENEFICIARY-ID | Unsigned16 |
| 2 | FLOOR-ID | Unsigned16 |
| 3 | FLOOR-REQUEST-ID | Unsigned16 |
| 4 | PRIORITY | OctetString16 |
| 5 | REQUEST-STATUS | OctetString16 |
| 6 | ERROR-CODE | OctetString |
| 7 | ERROR-INFO | OctetString |
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 9 | STATUS-INFO | OctetString |
| 10 | SUPPORTED-ATTRIBUTES | OctetString |
| 11 | SUPPORTED-PRIMITIVES | OctetString |
| 12 | USER-DISPLAY-NAME | OctetString |
| 13 | USER-URI | OctetString |
| 14 | BENEFICIARY-INFORMATION | Grouped |
| 15 | FLOOR-REQUEST-INFORMATION | Grouped |
| 16 | REQUESTED-BY-INFORMATION | Grouped |
| 17 | FLOOR-REQUEST-STATUS | Grouped |
| 18 | OVERALL-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+
+------+---------------------------+---------------+ | タイプ| 属性| 形式| +------+---------------------------+---------------+ | 1 | 受益者のID| Unsigned16| | 2 | FLOOR ID| Unsigned16| | 3 | 床のREQUEST ID| Unsigned16| | 4 | 優先権| OctetString16| | 5 | 要求状態| OctetString16| | 6 | エラーコード| OctetString| | 7 | 誤りインフォメーション| OctetString| | 8 | 関係者はインフォメーションを提供しました。| OctetString| | 9 | 状態インフォメーション| OctetString| | 10 | サポートしている属性| OctetString| | 11 | サポートしている基関数| OctetString| | 12 | ユーザディスプレイ名| OctetString| | 13 | ユーザユリ| OctetString| | 14 | 受益者の情報| 分類されます。| | 15 | 床の要求情報| 分類されます。| | 16 | 情報で、要求されます。| 分類されます。| | 17 | 床の要求状態| 分類されます。| | 18 | 総合的な要求状態| 分類されます。| +------+---------------------------+---------------+
Table 2: BFCP attributes
テーブル2: BFCP属性
M: The 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required. If an unrecognized attribute with the 'M' bit set is received, the message is rejected. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this document MUST be understood by the receiver so that the setting of the 'M' bit is irrelevant for these. In all other cases, the unrecognised attribute is ignored but the message is processed.
M: Mandatoryビットとして知られている'M'ビットは、属性のサポートが必要であるかどうかを示します。 'M'ビットがセットしたことでの認識されていない属性が受け取られているなら、メッセージは拒絶されます。 他のドキュメントだけで定義された拡大属性に、'M'ビットは重要です。 本書では指定されたすべての属性を受信機に解釈しなければならないので、これらに、'M'ビットの設定は無関係です。 他のすべての場合では、認識されていない属性は無視されますが、メッセージは処理されます。
Length: This 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes. The length of attributes that are not grouped includes the Type, 'M' bit,
長さ: 特定の属性のために定義されたどんな詰め物も除いて、この8ビットの分野は八重奏における、属性の長さを含んでいます。 分類されない属性の長さはType、'M'ビットを含んでいます。
Camarillo, et al. Standards Track [Page 17] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[17ページ]。
and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including Type, 'M' bit, and Length fields) plus the total length (including padding) of all the included attributes.
そして、Length分野。 分類された属性におけるLengthは分類された属性自体の長さ(Type、'M'ビット、およびLength分野を含んでいる)とすべての含まれている属性の全長(そっと歩くのを含んでいる)です。
Attribute Contents: The contents of the different attributes are defined in the following sections.
コンテンツを結果と考えてください: 異なった属性の内容は以下のセクションで定義されます。
5.2.1. BENEFICIARY-ID
5.2.1. 受益者のID
The following is the format of the BENEFICIARY-ID attribute.
↓これはBENEFICIARY-ID属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| 受益者のID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BENEFICIARY-ID format
図7: BENEFICIARY-ID形式
Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
受益者のID: この分野は会議の中で唯一ユーザを特定する16ビットの値を含んでいます。
Note that although the formats of the Beneficiary ID and of the
User ID field in the common header are similar, their semantics
are different. The Beneficiary ID is used in third-party floor
requests and to request information about a particular
participant.
一般的なヘッダーのBeneficiary IDとUser ID分野の形式が同様ですが、それらの意味論が異なっていることに注意してください。 Beneficiary IDは第三者床の要求と特定の関係者の要求情報に使用されます。
5.2.2. FLOOR-ID
5.2.2. FLOOR ID
The following is the format of the FLOOR-ID attribute.
↓これはFLOOR-ID属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| 床のID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FLOOR-ID format
エイト環: FLOOR-ID形式
Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference.
床のID: この分野は会議の中で唯一床を特定する16ビットの値を含んでいます。
Camarillo, et al. Standards Track [Page 18] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[18ページ]。
5.2.3. FLOOR-REQUEST-ID
5.2.3. 床のREQUEST ID
The following is the format of the FLOOR-REQUEST-ID attribute.
↓これはFLOOR-REQUEST-ID属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| 床の要求ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FLOOR-REQUEST-ID format
図9: FLOOR-REQUEST-ID形式
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
床の要求ID: この分野は床の制御サーバで床の要求を特定する16ビットの値を含んでいます。
5.2.4. PRIORITY
5.2.4. 優先権
The following is the format of the PRIORITY attribute.
↓これはPRIORITY属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PRIORITY format
図10: PRIORITY形式
Prio: This field contains a 3-bit priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default priority value when the PRIORITY attribute is missing is 2 (Normal).
Prio: この分野はTable3に示されるように3ビットの優先順位の値を含んでいます。 送付者SHOULD NOTはこの分野の4より高い値を使用します。 受信機はまるで対価領収が4(最も高い)であるかのように値を4より上に扱わなければなりません。 PRIORITY属性がなくなるとき、デフォルト優先順位の値は2(正常な)です。
+-------+----------+
| Value | Priority |
+-------+----------+
| 0 | Lowest |
| 1 | Low |
| 2 | Normal |
| 3 | High |
| 4 | Highest |
+-------+----------+
+-------+----------+ | 値| 優先権| +-------+----------+ | 0 | 最も低い| | 1 | 安値| | 2 | 標準| | 3 | 高値| | 4 | 最も高い| +-------+----------+
Table 3: Priority values
テーブル3: 優先順位の値
Reserved: At this point, the 13 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
予約される: ここに、予約された分野SHOULDの13ビットをメッセージ送信者によるゼロに設定されて、受信機で無視しなければなりません。
Camarillo, et al. Standards Track [Page 19] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[19ページ]。
5.2.5. REQUEST-STATUS
5.2.5. 要求状態
The following is the format of the REQUEST-STATUS attribute.
↓これはREQUEST-STATUS属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|状態を要求してください。|待ち行列位置| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: REQUEST-STATUS format
図11: REQUEST-STATUS形式
Request Status: This 8-bit field contains the status of the request, as described in the following table.
状態を要求してください: この8ビットの分野は以下のテーブルで説明されるように要求の状態を含んでいます。
+-------+-----------+
| Value | Status |
+-------+-----------+
| 1 | Pending |
| 2 | Accepted |
| 3 | Granted |
| 4 | Denied |
| 5 | Cancelled |
| 6 | Released |
| 7 | Revoked |
+-------+-----------+
+-------+-----------+ | 値| 状態| +-------+-----------+ | 1 | 未定| | 2 | 受け入れます。| | 3 | 与えます。| | 4 | 否定されます。| | 5 | 取り消されます。| | 6 | リリースされます。| | 7 | 取り消されます。| +-------+-----------+
Table 4: Request Status values
テーブル4: Status値を要求してください。
Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero.
位置を列に並ばせてください: この8ビットの分野は適切でありサーバにおける床の要求待ち行列における床の要求の位置を含んでいます。Request Status値がAcceptedと異なって、床の制御サーバが床の要求を実装しないなら、列を作るか、または床の制御サーバが欲しくないなら、この情報、この分野SHOULDのすべてのビットをクライアントに提供するために、ゼロに設定されてください。
A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state.
床の要求は、床の制御サーバが、床の要求を受け入れるために床のいすに連絡する必要があるならPending状態にありますが、まだそれをしていません。 床の制御いすがいったん床の要求を受け入れると、床の要求はAccepted状態に動かされます。
Camarillo, et al. Standards Track [Page 20] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[20ページ]。
5.2.6. ERROR-CODE
5.2.6. エラーコード
The following is the format of the ERROR-CODE attribute.
↓これはERROR-CODE属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Error Specific Details |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 0|M| 長さ| エラーコード| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 誤りの特定の詳細| / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ERROR-CODE format
図12: ERROR-CODE形式
Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognised by the receiver, then the receiver MUST assume that an error exists, and therefore that the message is processed, but the nature of the error is unclear.
エラーコード: この8ビットの分野は以下のテーブルからのエラーコードを含んでいます。 エラーコードが受信機によって認識されないなら、受信機は、誤りが存在していて、したがって、メッセージが処理されると仮定しなければなりませんが、誤りの本質は不明瞭です。
+-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 1 | Conference does not Exist | | 2 | User does not Exist | | 3 | Unknown Primitive | | 4 | Unknown Mandatory Attribute | | 5 | Unauthorized Operation | | 6 | Invalid Floor ID | | 7 | Floor Request ID Does Not Exist | | 8 | You have Already Reached the Maximum Number of Ongoing | | | Floor Requests for this Floor | | 9 | Use TLS | +-------+-----------------------------------------------------------+
+-------+-----------------------------------------------------------+ | 値| 意味| +-------+-----------------------------------------------------------+ | 1 | コンファレンスはどんなExistもしません。| | 2 | ユーザはどんなExistもしません。| | 3 | 未知の原始的です。| | 4 | 未知の義務的な属性| | 5 | 権限のない操作| | 6 | 無効のFloor ID| | 7 | 床の要求IDは存在していません。| | 8 | あなたはOngoingのAlready Reached Maximum Numberを持っています。| | | このFloorのための床のRequests| | 9 | TLSを使用してください。| +-------+-----------------------------------------------------------+
Table 5: Error Code meaning
テーブル5: 誤りCode意味
Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition.
誤りの特定の詳細: あるError Codesのためだけに、存在しています。 これに、Error Code4のためだけに(未知のMandatory Attribute)を記録してください。 セクション5.2を見てください。.6 .1 定義のために。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でERROR-CODE属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
Camarillo, et al. Standards Track [Page 21] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[21ページ]。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。
5.2.6.1. Error-Specific Details for Error Code 4
5.2.6.1. エラーコード4のための誤り特有の詳細
The following is the format of the Error-Specific Details field for Error Code 4.
↓これはError Code4のためのError特有のDetails分野の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未知のタイプ|R| 未知のタイプ|R| 未知のタイプ|R| 未知のタイプ|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 未知のタイプ|R| 未知のタイプ|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未知のタイプ|R| 未知のタイプ|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Unknown attributes format
図13: 未知の属性形式
Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver.
未知のタイプ: これらの7ビットの分野は受信機において、未知である属性(Errorメッセージの引き金となったメッセージに存在していた)のTypesを含んでいます。
R: At this point, this bit is reserved. It SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
R: ここに、このビットは予約されています。 それ、SHOULDはメッセージ送信者によるゼロに用意ができて、受信機で無視しなければなりません。
5.2.7. ERROR-INFO
5.2.7. 誤りインフォメーション
The following is the format of the ERROR-INFO attribute.
↓これはERROR-INFO属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1|M| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /テキスト//+++++++++| | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format
図14: ERROR-INFO形式
Text: This field contains UTF-8 [6] encoded text.
テキスト: この分野はUTF-8[6]を含んでいます。テキストをコード化しました。
Camarillo, et al. Standards Track [Page 22] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[22ページ]。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field.
いくつかの状況で、Text分野のコンテンツはオートマトンによって生成されるかもしれません。 このオートマトンに特定のERROR-INFO属性の受信機の都合のよい言語の情報があるなら、それは、Text分野を生成するのにこの言語を使用するかもしれません。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でERROR-INFO属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
5.2.8. PARTICIPANT-PROVIDED-INFO
5.2.8. 関係者はインフォメーションを提供しました。
The following is the format of the PARTICIPANT-PROVIDED-INFO attribute.
↓これはPARTICIPANT-PROVIDED-INFO属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0|M| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /テキスト//+++++++++| | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format
図15: PARTICIPANT-PROVIDED-INFO形式
Text: This field contains UTF-8 [6] encoded text.
テキスト: この分野はUTF-8[6]を含んでいます。テキストをコード化しました。
Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でPARTICIPANT-PROVIDED-INFO属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
Camarillo, et al. Standards Track [Page 23] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[23ページ]。
5.2.9. STATUS-INFO
5.2.9. 状態インフォメーション
The following is the format of the STATUS-INFO attribute.
↓これはSTATUS-INFO属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 1|M| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /テキスト//+++++++++| | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format
図16: STATUS-INFO形式
Text: This field contains UTF-8 [6] encoded text.
テキスト: この分野はUTF-8[6]を含んでいます。テキストをコード化しました。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field.
いくつかの状況で、Text分野のコンテンツはオートマトンによって生成されるかもしれません。 このオートマトンに特定のSTATUS-INFO属性の受信機の都合のよい言語の情報があるなら、それは、Text分野を生成するのにこの言語を使用するかもしれません。
Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でSTATUS-INFO属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
5.2.10. SUPPORTED-ATTRIBUTES
5.2.10. サポートしている属性
The following is the format of the SUPPORTED-ATTRIBUTES attribute.
↓これはSUPPORTED-ATTRIBUTES属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 0|M| 長さ| Supp。 Attr。 |R| Supp。 Attr。 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supp。 Attr。 |R| Supp。 Attr。 |R| Supp。 Attr。 |R| Supp。 Attr。 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SUPPORTED-ATTRIBUTES format
図17: SUPPORTED-ATTRIBUTES形式
Camarillo, et al. Standards Track [Page 24] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[24ページ]。
Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format:
Supp。 Attr、: これらの分野は床の制御サーバによって以下の形式でサポートされる属性のTypesを含んでいます:
R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception.
R: 予約される: このビットをトランスミッションのゼロに設定しなければならなくて、レセプションで無視しなければなりません。
Padding: Two octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: SUPPORTED-ATTRIBUTES属性のコンテンツが32ビットであるように加えられる状態でそっと歩く2つの八重奏が並びました。 既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。
5.2.11. SUPPORTED-PRIMITIVES
5.2.11. サポートしている基関数
The following is the format of the SUPPORTED-PRIMITIVES attribute.
↓これはSUPPORTED-PRIMITIVES属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 1|M| 長さ| 原始| 原始| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原始| 原始| 原始| 原始| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SUPPORTED-PRIMITIVES format
図18: SUPPORTED-PRIMITIVES形式
Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives.
原始: これらの分野は床の制御サーバによってサポートされるBFCPメッセージのタイプを含んでいます。BFCP基関数のリストに関してTable1を見てください。
Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でSUPPORTED-PRIMITIVES属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver.
PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。
Camarillo, et al. Standards Track [Page 25] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[25ページ]。
5.2.12. USER-DISPLAY-NAME
5.2.12. ユーザディスプレイ名
The following is the format of the USER-DISPLAY-NAME attribute.
↓これはUSER-DISPLAY-NAME属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 0|M| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /テキスト//+++++++++| | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: USER-DISPLAY-NAME format
図19: USER-DISPLAY-NAME形式
Text: This field contains the UTF-8 encoded name of the user.
テキスト: この分野はユーザで名義でコード化されたUTF-8を含んでいます。
Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でUSER-DISPLAY-NAME属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
5.2.13. USER-URI
5.2.13. ユーザユリ
The following is the format of the USER-URI attribute.
↓これはUSER-URI属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 1|M| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /テキスト//+++++++++| | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: USER-URI format
図20: USER-URI形式
Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user.
テキスト: この分野はコード化されたユーザの接触URI、すなわち、BFCPによって制御されるリソース(例えば、メディアストリーム)をセットアップするのにユーザによって使用されたUTF-8URIを含んでいます。 例えば、SIPによって設立された会議の文脈では、USER-URI属性はユーザのSIP URIを運ぶでしょう。
Camarillo, et al. Standards Track [Page 26] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[26ページ]。
Messages containing a user's URI in a USER-URI attribute also
contain the user's User ID. This way, a client receiving such a
message can correlate the user's URI (e.g., the SIP URI the user
used to join a conference) with the user's User ID.
また、USER-URI属性におけるユーザのURIを含むメッセージがユーザのUser IDを含んでいます。 この道、そのようなメッセージを受け取るクライアントはユーザのUser IDと共にユーザのURI(例えばユーザが会議に参加するのに使用したSIP URI)を関連させることができます。
Padding: One, two, or three octets of padding added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
詰め物: 1つ、2、または並べられた状態でUSER-URI属性のコンテンツが32ビットであるように加えられる状態でそっと歩く3つの八重奏。 PaddingビットSHOULDを送付者がゼロに用意ができて、受信機で無視しなければなりません。既に並べられた状態で属性が32ビットであるなら、水増しは必要ではありません。
5.2.14. BENEFICIARY-INFORMATION
5.2.14. 受益者の情報
The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER:
BENEFICIARY-情報属性は属性の系列があとに続いたBENEFICIARY情報-HEADERと呼ばれるヘッダーから成る分類された属性です。 ↓これはBENEFICIARY情報HEADERの形式です:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 0|M| 長さ| 受益者のID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BENEFICIARY-INFORMATION-HEADER format
図21: BENEFICIARY情報HEADER形式
Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
受益者のID: この分野は会議の中で唯一ユーザを特定する16ビットの値を含んでいます。
The following is the ABNF (Augmented Backus-Naur Form) [2] of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
↓これはBENEFICIARY-情報の分類された属性のABNF(BN記法を増大させる)[2]です。 (EXTENSION-ATTRIBUTEは将来定義されるかもしれない拡大属性について言及します。)
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
受益者の情報は*と等しいです(受益者の情報ヘッダー)[ユーザディスプレイ名][ユーザユリ]。[拡大属性]
Figure 22: BENEFICIARY-INFORMATION format
図22: BENEFICIARY-情報形式
5.2.15. FLOOR-REQUEST-INFORMATION
5.2.15. 床の要求情報
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
FLOOR-REQUEST-情報属性は属性の系列があとに続いたFLOOR-REQUEST情報-HEADERと呼ばれるヘッダーから成る分類された属性です。 ↓これはFLOOR-REQUEST情報HEADERの形式です:
Camarillo, et al. Standards Track [Page 27] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[27ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 1|M| 長さ| 床の要求ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
図23: FLOOR-REQUEST情報HEADER形式
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
床の要求ID: この分野は床の制御サーバで床の要求を特定する16ビットの値を含んでいます。
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
↓これはFLOOR-REQUEST-情報の分類された属性のABNFです。 (EXTENSION-ATTRIBUTEは将来定義されるかもしれない拡大属性について言及します。)
FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER)
[OVERALL-REQUEST-STATUS]
1*(FLOOR-REQUEST-STATUS)
[BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION]
[PRIORITY]
[PARTICIPANT-PROVIDED-INFO]
*[EXTENSION-ATTRIBUTE]
床の要求情報は[総合的な要求状態]1*(床の要求状態)[受益者の情報][情報で、要求されます][優先権][関係者はインフォメーションを提供した]*と等しいです(床の要求情報ヘッダー)。[拡大属性]
Figure 24: FLOOR-REQUEST-INFORMATION format
図24: FLOOR-REQUEST-情報形式
5.2.16. REQUESTED-BY-INFORMATION
5.2.16. 情報で、要求されます。
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER:
REQUESTED-BY-情報属性は属性の系列があとに続いたREQUESTED-BY情報-HEADERと呼ばれるヘッダーから成る分類された属性です。 ↓これはREQUESTED-BY情報HEADERの形式です:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 0|M| 長さ| 要求されたID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: REQUESTED-BY-INFORMATION-HEADER format
図25: REQUESTED-BY情報HEADER形式
Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
IDを要求します: この分野は会議の中で唯一ユーザを特定する16ビットの値を含んでいます。
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
↓これはREQUESTED-BY-情報の分類された属性のABNFです。 (EXTENSION-ATTRIBUTEは将来定義されるかもしれない拡大属性について言及します。)
Camarillo, et al. Standards Track [Page 28] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[28ページ]。
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
情報によって要求された=(情報ヘッダーによって要求されています)[ユーザディスプレイ名][ユーザユリ]*[拡大属性]
Figure 26: REQUESTED-BY-INFORMATION format
図26: REQUESTED-BY-情報形式
5.2.17. FLOOR-REQUEST-STATUS
5.2.17. 床の要求状態
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-HEADER:
FLOOR-REQUEST-STATUS属性は属性の系列があとに続いたFLOOR-REQUEST-STATUS-HEADERと呼ばれるヘッダーから成る分類された属性です。 ↓これはFLOOR-REQUEST-STATUS-HEADERの形式です:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 1|M| 長さ| 床のID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: FLOOR-REQUEST-STATUS-HEADER format
図27: FLOOR-REQUEST-STATUS-HEADER形式
Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference.
床のID: この分野は会議の中で唯一床を特定する16ビットの値を含んでいます。
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下によるFLOOR-REQUEST-STATUSのABNFが属性を分類したということです。 (EXTENSION-ATTRIBUTEは将来定義されるかもしれない拡大属性について言及します。)
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
床の要求状態は*と等しいです(床の要求状態ヘッダー)[要求状態][状態インフォメーション]。[拡大属性]
Figure 28: FLOOR-REQUEST-STATUS format
図28: FLOOR-REQUEST-STATUS形式
Camarillo, et al. Standards Track [Page 29] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[29ページ]。
5.2.18. OVERALL-REQUEST-STATUS
5.2.18. 総合的な要求状態
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER:
OVERALL-REQUEST-STATUS属性は属性の系列があとに続いたOVERALL-REQUEST-STATUS-HEADERと呼ばれるヘッダーから成る分類された属性です。 ↓これはOVERALL-REQUEST-STATUS-HEADERの形式です:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 1 0|M| 長さ| 床の要求ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OVERALL-REQUEST-STATUS-HEADER format
図29: OVERALL-REQUEST-STATUS-HEADER形式
Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server.
床の要求ID: この分野は床の制御サーバで床の要求を特定する16ビットの値を含んでいます。
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下によるOVERALL-REQUEST-STATUSのABNFが属性を分類したということです。 (EXTENSION-ATTRIBUTEは将来定義されるかもしれない拡大属性について言及します。)
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
総合的な要求状態は*と等しいです(総合的な要求状態ヘッダー)[要求状態][状態インフォメーション]。[拡大属性]
Figure 30: OVERALL-REQUEST-STATUS format
図30: OVERALL-REQUEST-STATUS形式
5.3. Message Format
5.3. メッセージ・フォーマット
This section contains the normative ABNF (Augmented Backus-Naur Form) [2] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
このセクションはBFCPメッセージの標準のABNF(BN記法を増大させる)[2]を含みます。 将来定義されるかもしれない拡大属性はABNFにEXTENSION-ATTRIBUTEと呼ばれます。
Camarillo, et al. Standards Track [Page 30] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[30ページ]。
5.3.1. FloorRequest
5.3.1. FloorRequest
Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message:
床の関係者は、床の制御サーバにFloorRequestメッセージを送ることによって、床を要求します。↓これはFloorRequestメッセージの形式です:
FloorRequest = (COMMON-HEADER)
1*(FLOOR-ID)
[BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY]
*[EXTENSION-ATTRIBUTE]
FloorRequestは(一般的なヘッダーの)1*(FLOOR ID)[受益者のID][関係者はインフォメーションを提供しました][優先権]*と等しいです。[拡大属性]
Figure 31: FloorRequest format
図31: FloorRequest形式
5.3.2. FloorRelease
5.3.2. FloorRelease
Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message:
床の関係者は、床の制御サーバにFloorReleaseメッセージを送ることによって、床をリリースします。また、床の関係者は未定の床の要求を中止するFloorReleaseメッセージを使用します。 ↓これはFloorReleaseメッセージの形式です:
FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
FloorReleaseは(一般的なヘッダー)(床のREQUEST ID)の*と等しいです。[拡大属性]
Figure 32: FloorRelease format
図32: FloorRelease形式
5.3.3. FloorRequestQuery
5.3.3. FloorRequestQuery
Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message:
床の関係者と床のいすは、床の制御サーバにFloorRequestQueryメッセージを送ることによって、床の要求の情報を要求します。↓これはFloorRequestQueryメッセージの形式です:
FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
FloorRequestQueryは(一般的なヘッダー)(床のREQUEST ID)の*と等しいです。[拡大属性]
Figure 33: FloorRequestQuery format
図33: FloorRequestQuery形式
5.3.4. FloorRequestStatus
5.3.4. FloorRequestStatus
The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message:
床の制御サーバは、彼らの床の要求の状態に関してFloorRequestStatusメッセージをそれらに送ることによって、床の関係者と床のいすに知らせます。 ↓これはFloorRequestStatusメッセージの形式です:
Camarillo, et al. Standards Track [Page 31] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[31ページ]。
FloorRequestStatus = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
FloorRequestStatusは(一般的なヘッダー)(床の要求情報)の*と等しいです。[拡大属性]
Figure 34: FloorRequestStatus format
図34: FloorRequestStatus形式
5.3.5. UserQuery
5.3.5. UserQuery
Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message:
床の関係者と床のいすは、床の制御サーバにUserQueryメッセージを送ることによって関係者の情報と床の要求がこの関係者に関連したよう要求します。↓これはUserQueryメッセージの形式です:
UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE]
UserQueryは(一般的なヘッダー)[受益者のID]の*と等しいです。[拡大属性]
Figure 35: UserQuery format
図35: UserQuery形式
5.3.6. UserStatus
5.3.6. UserStatus
The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message:
床の制御サーバは、UserStatusメッセージを彼らに送ることによって、関係者の情報と彼らの関連する床の要求を床の関係者と床のいすに供給します。 ↓これはUserStatusメッセージの形式です:
UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION]
*(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
UserStatusは(一般的なヘッダー)[受益者の情報]の*(床の要求情報)*と等しいです。[拡大属性]
Figure 36: UserStatus format
図36: UserStatus形式
5.3.7. FloorQuery
5.3.7. FloorQuery
Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorRequest message:
床の関係者と床のいすは、床の制御サーバにFloorQueryメッセージを送ることによって、床か床の情報を要求します。↓これはFloorRequestメッセージの形式です:
FloorQuery = (COMMON-HEADER)
*(FLOOR-ID)
*[EXTENSION-ATTRIBUTE]
FloorQueryは(一般的なヘッダー)の*(FLOOR ID)*と等しいです。[拡大属性]
Figure 37: FloorQuery format
図37: FloorQuery形式
Camarillo, et al. Standards Track [Page 32] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[32ページ]。
5.3.8. FloorStatus
5.3.8. FloorStatus
The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message:
床の制御サーバは、床の状態(例えば、現在の所有者)に関してFloorStatusメッセージを彼らに送ることによって、床の関係者と床のいすに知らせます。 ↓これはFloorStatusメッセージの形式です:
FloorStatus = (COMMON-HEADER)
*1(FLOOR-ID)
*[FLOOR-REQUEST-INFORMATION]
*[EXTENSION-ATTRIBUTE]
FloorStatusは(一般的なヘッダー)の*1(FLOOR ID)*[床の要求情報]*と等しいです。[拡大属性]
Figure 38: FloorStatus format
図38: FloorStatus形式
5.3.9. ChairAction
5.3.9. ChairAction
Floor chairs send instructions to floor control servers by sending ChairAction messages. The following is the format of the ChairAction message:
床のいすは、メッセージをChairActionに送ることによって、床の制御サーバに指示を送ります。 ↓これはChairActionメッセージの形式です:
ChairAction = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
ChairActionは(一般的なヘッダー)(床の要求情報)の*と等しいです。[拡大属性]
Figure 39: ChairAction format
図39: ChairAction形式
5.3.10. ChairActionAck
5.3.10. ChairActionAck
Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message:
床の制御サーバは、ChairActionAckメッセージを送ることによってChairActionメッセージを受け入れたと確認します。 ↓これはChairActionAckメッセージの形式です:
ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
ChairActionAckは(一般的なヘッダー)の*と等しいです。[拡大属性]
Figure 40: ChairActionAck format
図40: ChairActionAck形式
5.3.11. Hello
5.3.11. こんにちは
Floor participants and floor chairs check the liveliness of floor control servers by sending a Hello message. The following is the format of the Hello message:
床の関係者と床のいすは、Helloメッセージを送ることによって、床の制御サーバの活気をチェックします。 ↓これはHelloメッセージの形式です:
Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
こんにちは、=(一般的なヘッダーの)*[拡大属性]
Figure 41: Hello format
図41: こんにちは、形式
Camarillo, et al. Standards Track [Page 33] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[33ページ]。
5.3.12. HelloAck
5.3.12. HelloAck
Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message:
床の制御サーバは、それらがHelloメッセージのレセプションでHelloAckメッセージを送ることによって生きていると確認します。 ↓これはHelloAckメッセージの形式です:
HelloAck = (COMMON-HEADER)
(SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES)
*[EXTENSION-ATTRIBUTE]
HelloAckは(一般的なヘッダー)(サポートしている基関数)(サポートしている属性)の*と等しいです。[拡大属性]
Figure 42: HelloAck format
図42: HelloAck形式
5.3.13. Error
5.3.13. 誤り
Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message:
床の制御サーバはErrorメッセージをそれらに送ることによって要求を処理する誤りに関して床の関係者と床のいすに知らせます。 ↓これはErrorメッセージの形式です:
Error = (COMMON-HEADER)
(ERROR-CODE)
[ERROR-INFO]
*[EXTENSION-ATTRIBUTE]
誤り=(一般的なヘッダーの)(エラーコード)[誤りインフォメーション]*[拡大属性]
Figure 43: Error format
図43: 誤り形式
6. Transport
6. 輸送
BFCP entities exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing is implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes.
BFCP実体は、TCP接続を使用することでBFCPメッセージを交換します。 TCPはオーダーにおける、バイトのストリームの信頼できる配信を提供します。 その結果、メッセージ縁どりは応用層の中で実装されます。 BFCPは、応用層が縁どりであるとTLVによってコード化された属性を使用することで実装します。
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed.
クライアントは、会議の中で与えられた床の制御サーバとコミュニケートするのに1つ以上のTCP接続を使用してはいけません。 それにもかかわらず、同じ物理的な箱が異なったクライアント(例えば、床のいすと床の関係者)(異なったUser IDによって特定されます)を扱うなら、1クライアントあたり1つの別々の接続が許されています。
If a BFCP entity (a client or a floor control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out, the TCP connection SHOULD be reestablished.
BFCP実体(クライアントか床の制御サーバ)がデータを受け取るなら、分析されています、実体がTCP接続、および接続SHOULDを終えなければならないということであることができないTCPから、復職してください。 同様に、接続はTCPであるならBFCPメッセージと回を外に提供できないで、TCPは接続SHOULDです。復職します。
Camarillo, et al. Standards Track [Page 34] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[34ページ]。
The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server (e.g., using an SDP offer/answer exchange [7]). Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server.
接続再建が扱われる方法はクライアントがどう床の制御サーバに連絡する情報を得るかによります。(例えば、SDPを使用するのは、交換[7])に提供するか、または答えます。 TCP接続がいったん回復すると、クライアントはそれが床の制御サーバから返事をもらわなかったそれらのメッセージを再送するかもしれません。
If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished.
床の制御サーバがそれを検出するなら床の関係者のひとりに向かったとのTCP接続が迷子になっている、床の制御サーバのローカルの方針までそれはそうです。床の関係者の未定の床の要求でそうするべきこと。 どのような場合でも、TCP接続は回復しますが、床の制御サーバが床の要求を保つのは、RECOMMENDED(すなわち、するのはそれらを取り消さない)です。
If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client.
クライアントが床の制御サーバとのBFCP関係を終わらせたいと思うなら、クライアントは床の制御サーバに向かってTCP接続を終えます(すなわち、優雅な閉鎖)。床の制御サーバがクライアントとのBFCP接続を終わらせたいと思うなら(例えば、会議のFocusは、クライアントが会議からけり出されたことを床の制御サーバに知らせます)、床の制御サーバはTCP接続をクライアントに向かって終えます(すなわち、優雅な閉鎖)。
7. Lower-Layer Security
7. 下層セキュリティ
BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS [3]. Any BFCP entity MAY support other security mechanisms.
BFCPは、再生、保全保護、および秘密性を提供するために下層セキュリティー対策を当てにします。 BFCP床の制御サーバとクライアント(床の関係者と床のいすの両方を含んでいます)は、TLSが[3]であるとサポートしなければなりません。 どんなBFCP実体も、他のセキュリティがメカニズムであるとサポートするかもしれません。
BFCP entities MUST support, at a minimum, the TLS TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].
BFCP実体は、最小限でTLS TLS_RSA_がWITH_AES_128_CBC_SHA ciphersuite[5]であるとサポートしなければなりません。
Which party, the client or the floor control server, acts as the TLS server depends on how the underlying TCP connection is established. For example, when the TCP connection is established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server.
TLSサーバが基本的なTCP接続がどう確立されるかによって、どのパーティー(クライアントか床の制御サーバ)が、行動するか。 TCP接続がSDP申し出/答え交換[7]を使用することで確立されるとき、例えば、answerer(クライアントか床の制御サーバであるかもしれない)はTLSサーバとしていつも作動します。
8. Protocol Transactions
8. プロトコルトランザクション
In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions (notifications). Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. The request carries a Transaction ID in its common header, which the floor control server copies into the response. Clients use Transaction ID values to match responses with previously issued requests.
BFCPに、2つのタイプのトランザクションがあります: クライアントによって開始されたトランザクションとサーバで開始しているトランザクション(通知)。 クライアントによって開始されたトランザクションはクライアントから床の制御サーバまでの要求と床の制御サーバからクライアントまでの応答から成ります。 要求は一般的なヘッダーでTransaction IDを運びます。(床の制御サーバは応答にヘッダーをコピーします)。 クライアントは、以前に発行された要求に応答に合うのにTransaction ID値を使用します。
Camarillo, et al. Standards Track [Page 35] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[35ページ]。
Server-initiated transactions consist of a single message from a floor control server to a client. Since they do not trigger any response, their Transaction ID is set to 0.
サーバで開始しているトランザクションはただ一つの床の制御サーバからクライアントまでのメッセージから成ります。 それらが少しの応答も引き金とならないので、それらのTransaction IDは0に設定されます。
8.1. Client Behavior
8.1. クライアントの振舞い
A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously.
クライアントによって開始されたトランザクションを始めるクライアントはクライアントが以前に得た会議のためにConference IDへのメッセージの一般的なヘッダーにConference IDをはめ込まなければなりません。
The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server.
クライアントはクライアントから0と異なって、別のメッセージで再利用されてはいけない数への一般的なヘッダーにTransaction ID価値をトランザクションのためにサーバからの応答を受けるまではめ込まなければなりません。 クライアントは、このメッセージを床の制御サーバから応答に合わせるのにTransaction ID価値を使用します。
8.2. Server Behavior
8.2. サーバの振舞い
A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0.
クライアントによって開始されたトランザクションの中で応答を送る床の制御サーバはConference Transaction ID(ID)をコピーしなければなりません、そして、要求からのUser IDはクライアントから応答に受信されました。 サーバで開始しているトランザクションは0と等しいTransaction IDを含まなければなりません。
9. Authentication and Authorization
9. 認証と承認
BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it.
どんなBFCPメッセージもそれに送るか、またはそれからどんなBFCPメッセージも受け入れる前に、BFCPクライアントSHOULDは床の制御サーバを認証します。 同様に、それからどんなBFCPメッセージも受け入れるか、またはどんなBFCPメッセージもそれに送る前に、床のコントロールサーバSHOULDはクライアントを認証します。
BFCP supports TLS-based mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP.
BFCPはセクション9.1で指定されるようにクライアントと床のコントロールの間のTLSベースの互いの認証にサーバをサポートします。 これはBFCPのRECOMMENDED認証機構です。
Note that future extensions may define additional authentication
mechanisms.
今後の拡大が追加認証機構を定義するかもしれないことに注意してください。
In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further.
BFCPメッセージを認証することに加えて、床の制御サーバは、それらを認可する必要があります。 認証されたBFCPメッセージを受け取ると、床の制御サーバは、メッセージを送るクライアントが認可されているかどうかチェックします。 クライアントが要求されている操作を実行するのに権限を与えられないなら、床の制御サーバはErrorメッセージを生成します、セクション13.8で説明されるように、5(権限のないOperation)の値があるErrorコードで。 さらに権限を与えることができないクライアントからのメッセージを処理してはいけません。
Camarillo, et al. Standards Track [Page 36] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[36ページ]。
9.1. TLS-Based Mutual Authentication
9.1. TLSベースの互いの認証
BFCP supports TLS-based mutual authentication between clients and floor control servers. BFCP assumes that there is an integrity- protected channel between the client and the floor control server that can be used to exchange their self-signed certificates or, more commonly, the fingerprints of these certificates. These certificates are used at TLS establishment time.
BFCPはクライアントと床のコントロールの間のTLSベースの互いの認証にサーバをサポートします。 BFCPは、それらの自己署名入りの証書か、より一般的にこれらの証明書の指紋を交換するのに使用できるクライアントと床の制御サーバの間には、保全の保護されたチャンネルがあると仮定します。 これらの証明書はTLS設立時間に使用されます。
The implementation of such an integrity-protected channel using
SIP and the SDP offer/answer model is described in [7].
SIPを使用しているそのような保全で保護されたチャンネルとSDP申し出/答えモデルの実装は[7]で説明されます。
BFCP messages received over an authenticated TLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP (no TLS) can request the use of TLS by generating an Error message, as described in Section 13.8, with an Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore unauthenticated messages.
認証されたTLS接続の上に受け取られたBFCPメッセージは認証されていると考えられます。 TCP(TLSがない)の上にBFCPメッセージを受け取る床の制御サーバはErrorメッセージを生成することによって、TLSの使用を要求できます、セクション13.8で説明されるように、9の値があるErrorコードで(TLSを使用してください)。 SHOULDが単に無視するクライアントはメッセージを非認証しました。
Note that future extensions may define additional authentication
mechanisms that may not require an initial integrity-protected
channel (e.g., authentication based on certificates signed by a
certificate authority).
今後の拡大が初期の保全で保護されたチャンネルを必要としないかもしれない追加認証機構を定義するかもしれないことに注意してください(例えば証明書に基づく認証は認証局で署名しました)。
As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server SHOULD check that messages arriving over a given authenticated TLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS connection is allowed to use).
セクション9で説明されるように、床の制御サーバは、どんなメッセージも処理する前に承認を実行する必要があります。 特に、床の制御サーバSHOULDは、与えられた認証されたTLS接続の上で到着するメッセージが認可されたUser ID(すなわち、認証されたTLS接続を確立したユーザが使用できるUser ID)を使用するのをチェックします。
10. Floor Participant Operations
10. 床の関係者操作
This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs).
このセクションは床の関係者がどう異なった操作を実行できるかを指定します、床を要求するのなどように、以前のセクションで説明されたプロトコル要素を使用して。 セクション11は床を与えるか、または取り消すよう床の制御サーバに命令などなどの床のいすに、特定の操作を指定します、そして、セクション12はどんなクライアント(すなわち、床の関係者と床のいすの両方)も実行できる操作を指定します。
10.1. Requesting a Floor
10.1. 床を要求します。
A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.
1階以上を要求したがっている床の関係者は、床の制御サーバにFloorRequestメッセージを送ることによって、そうします。
Camarillo, et al. Standards Track [Page 37] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[37ページ]。
10.1.1. Sending a FloorRequest Message
10.1.1. FloorRequestメッセージを送ります。
The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.1におけるABNFはFloorRequestメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1.
床の関係者は一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。
The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor.
床の関係者は床の関係者の識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。 FloorRequestメッセージ(User IDによって特定される)の送付者が結局発言権を得る関係者(すなわち、第三者床の要求)でないなら、送付者SHOULDはBENEFICIARY-ID属性を床の受益者を特定するメッセージに追加します。
Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a
single 16-bit value that can be used in the User ID in the common
header and in several attributes: BENEFICIARY-ID, BENEFICIARY-
INFORMATION, and REQUESTED-BY-INFORMATION.
User IDとBeneficiary IDの両方のための名前スペースが同じであることに注意してください。 すなわち、与えられた関係者はUser IDで一般的なヘッダーといくつかの属性に使用できるただ一つの16ビットの値によって特定されます: 受益者のIDの、そして、受益者の情報で、情報によって要求されていました。
The floor participant must insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR-ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message.
床の関係者は少なくとも1つのFLOOR-ID属性をFloorRequestメッセージに挿入しなければなりません。 クライアントが1つ以上のFLOOR-ID属性を挿入すると、床の制御サーバはすべての床の要求を原子パッケージとして扱うでしょう。 すなわち、床の制御サーバは、FloorRequestメッセージですべての床を与えるか、または否定するでしょう。
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption.
床の関係者は、床か床が要求されている理由を述べるのにPARTICIPANT-PROVIDED-INFO属性を使用するかもしれません。 PARTICIPANT-PROVIDED-INFO属性におけるText分野は人間の消費で意図します。
The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute.
床の関係者は、サーバが、ある優先でPRIORITY属性を使用することで床の要求を扱うよう要求するかもしれません。
10.1.2. Receiving a Response
10.1.2. 応答を受けます。
A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
床の制御サーバからのメッセージにFloorRequestメッセージとして同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはFloorRequestメッセージへの応答であると考えられます、セクション8.1で説明されるように。 そのような応答を受けると、床の関係者は床のコントロールサーバ証明に関連するセクション9で約束を守ります。
Camarillo, et al. Standards Track [Page 38] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[38ページ]。
The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request.
床の制御サーバにおけるFloorRequestメッセージのうまくいっている処理は、1か数個のFloorRequestStatusがメッセージであると生成することを伴います。 床の関係者は最初のFloorRequestStatusメッセージのFLOOR-REQUEST-情報属性のFloor Request ID分野で床の制御サーバからFloor Request IDを得ます。同じ床の要求に関する床の制御サーバからのその後のFloorRequestStatusメッセージは初期のFloorRequestStatusメッセージとしてFLOOR-REQUEST-情報属性で同じFloor Request IDを運ぶでしょう。 この道と、床の関係者は進行中の床があるメッセージが要求するその後の入って来るFloorRequestStatusを関連づけることができます。
The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request.
床の関係者は床の制御サーバから受け取られたそれぞれに関するFloorRequestStatusメッセージのFLOOR-REQUEST-情報属性における床の要求の状態の情報を得ます。この属性は分類された属性です、そして、そういうものとして、それは床の要求の情報を提供する多くの属性を含んでいます。
The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user.
OVERALL-REQUEST-STATUS属性は床の要求の総合的な状態の情報を提供します。 Request Status値がGrantedであるなら、FloorRequestメッセージで要求されたすべての床を与えました。 Request Status値がDeniedであるなら、FloorRequestメッセージで要求されたすべての床が否定されました。 それがPending、Accepted、またはGranted州にある間、床の要求が進行中であると考えられます。 床の要求価値が未知であるなら、応答はまだ処理されています。 しかしながら、どんな重要な値もユーザに報告できません。
The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.
存在しているなら、STATUS-INFO属性は床の関係者がユーザに表示するかもしれないというその他の情報を提供します。
The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant MAY display to the user.
特定の床に関連するとき、FLOOR-REQUEST-STATUS属性は床の要求の状態の情報を提供します。 存在しているなら、STATUS-INFO属性は床の関係者がユーザに表示するかもしれないというその他の情報を提供します。
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY-INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the common header.
BENEFICIARY-情報属性は第三者床の要求における、床の要求の受益者を特定します。 REQUESTED-BY-情報属性は床を要求した床の関係者によって受け取られたFloorRequestStatusメッセージに存在している必要はありません、この床の関係者が一般的なヘッダーのUser IDによって既に特定されるとき。
The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message.
存在しているとき、PRIORITY属性はFloorRequestメッセージのジェネレータによって要求された優先権を含んでいます。
Camarillo, et al. Standards Track [Page 39] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[39ページ]。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
応答がErrorメッセージであるなら、床の制御サーバはFloorRequestメッセージを処理しないかもしれません。
10.2. Cancelling a Floor Request and Releasing a Floor
10.2. 床の要求を中止して、床をリリースします。
A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it.
進行中の床の要求を中止したがっている床の関係者は、床の制御サーバにFloorReleaseメッセージを送ることによって、そうします。FloorReleaseメッセージは、また、床を持っている床の関係者が使用されて、それをリリースしたがっています。
10.2.1. Sending a FloorRelease Message
10.2.1. FloorReleaseメッセージを送ります。
The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.2におけるABNFはFloorReleaseメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
床の関係者は一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。 床の関係者は床の関係者の識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。
Note that the FloorRelease message is used to release a floor or
floors that were granted and to cancel ongoing floor requests
(from the protocol perspective, both are ongoing floor requests).
Using the same message in both situations helps resolve the race
condition that occurs when the FloorRelease message and the
FloorGrant message cross each other on the wire.
FloorReleaseメッセージが床か与えられた床をリリースして、進行中の床の要求(プロトコル見解から、両方が進行中の床の要求である)を中止するのに使用されることに注意してください。 両方の状況で同じメッセージを使用するのは、FloorReleaseメッセージとFloorGrantメッセージがワイヤの上に互いに交差するとき起こる競合条件を決議するのを助けます。
The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling.
床の関係者はFloorReleaseメッセージが取り消されているというFloorRequestメッセージへの応答で受け取られたFLOOR-REQUEST-IDを使用します。
Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the
floors are released as an atomic operation as well (i.e., all are
released at the same time).
床の関係者が原子操作(すなわち、ただ一つのFloorRequestメッセージの)としていくつかの床を要求したなら、すべての床がまた、原子操作としてリリースされることに注意してください(すなわち、すべてが同時に、リリースされます)。
10.2.2. Receiving a Response
10.2.2. 応答を受けます。
A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
床の制御サーバからのメッセージにFloorRequestメッセージとして同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはFloorReleaseメッセージへの応答であると考えられます、セクション8.1で説明されるように。 そのような応答を受けると、床の関係者は床のコントロールサーバ証明に関連するセクション9で約束を守ります。
Camarillo, et al. Standards Track [Page 40] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[40ページ]。
If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
応答がFloorRequestStatusメッセージであるなら、OVERALL-REQUEST-STATUS属性(FLOOR- REQUEST-情報の分類された属性の中の)におけるRequest Status値は、CancelledかReleasedになるでしょう。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
応答がErrorメッセージであるなら、床の制御サーバはFloorRequestメッセージを処理しないかもしれません。
It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease.
FloorReleaseメッセージがサーバからのFloorRequestStatusメッセージと共にワイヤの上にCancelledかReleasedと異なったRequest Statusで交差するのは、可能です。 どのような場合でも、そのようなFloorRequestStatusメッセージはFloorReleaseメッセージへの応答でなくなるでしょう、Transaction IDがFloorReleaseのものに合わないとき。
11. Chair Operations
11. 議長Operations
This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections.
床のいすが、以前のセクションで説明されたプロトコル要素を使用することで床を与えるか、または取り消すようどう床の制御サーバに命令できるかをこのセクションは指定します。
Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message.
床の制御サーバに指示を送りたがっている床のいすが、ChairActionメッセージを送ることによって、そうします。
11.1. Sending a ChairAction Message
11.1. ChairActionメッセージを送ります。
The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.9におけるABNFはChairActionメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
床のいすは一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。 床のいすは床の関係者の識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。
The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.
ChairActionメッセージは特定の床の要求の中に1階以上に適用される指示を含んでいます。 床か床がFLOOR-REQUEST-STATUS属性によって特定されます、そして、床の要求はFLOOR-REQUEST情報HEADERによって特定されます。(HEADERはChairActionメッセージで運ばれます)。
For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor
例えば、床の要求が異なった床のいすに頼る2階から成ると、それぞれの床のいすは床の要求の中で床を与えるでしょう。 両方のいすがいったん彼らの床を与えると、床の制御サーバは全体で床の要求を承諾するでしょう。 他方では、床床のいすのひとりが床を否定するなら
Camarillo, et al. Standards Track [Page 41] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[41ページ]。
control server will deny the floor request as a whole, regardless of the other floor chair's decision.
制御サーバはもう片方の床のいすの決定にかかわらず全体で床の要求を否定するでしょう。
The floor chair provides the new status of the floor request as it relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position field SHOULD be set to zero. The floor chair SHOULD use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and SHOULD use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted).
FLOOR-REQUEST-STATUS属性を使用することで特定の床に関連するとき、床のいすは床の要求の新しい状態を提供します。 床の要求の新しい状態がAcceptedであるなら、床のいすは、待ち行列位置を床の要求に提供するのにQueue Position分野を使用するかもしれません。 床のいすが、待ち行列位置、すべてのビットのQueue Position分野SHOULDを提供するために、ゼロに設定されるように願わないなら。 床のいすSHOULDは与えられた床(すなわち、Granted状態)を取り消すのにStatus Revokedを使用します、そして、SHOULDはいかなる他の状態(例えば、PendingとAccepted)でも床の要求を拒絶するのにStatus Deniedを使用します。
The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new overall status for the floor request. If the new overall status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request.
床のいすは新しい総合的な状態を床の要求に提供するChairActionメッセージにOVERALL-REQUEST-STATUS属性を追加するかもしれません。 床の要求の新しい総合的な状態がAcceptedであるなら、床のいすは、待ち行列位置を床の要求に提供するのにQueue Position分野を使用するかもしれません。
Note that a particular floor control server may implement a
different queue for each floor containing all the floor requests
that relate to that particular floor, a general queue for all
floor requests, or both. Also note that a floor request may
involve several floors and that a ChairAction message may only
deal with a subset of these floors (e.g., if a single floor chair
is not authorized to manage all the floors). In this case, the
floor control server will combine the instructions received from
the different floor chairs in FLOOR-REQUEST-STATUS attributes to
come up with the overall status of the floor request.
特定の床の制御サーバがその特定の床に関連するすべての床の要求を含む各床のための異なった待ち行列、すべての床の要求のための一般的な待ち行列、または両方を実装するかもしれないことに注意してください。 また、床の要求がいくつかの床にかかわるかもしれなくて、ChairActionメッセージがこれらの床の部分集合に対処するだけであるかもしれないことに注意してください(例えば、独身の床のいすがすべての床を管理するのに権限を与えられないなら)。 この場合、床の制御サーバは床の要求の総合的な状態を思いつくために異なった床のいすからFLOOR-REQUEST-STATUS属性で受けられた指示を結合するでしょう。
Note that, while the action of a floor chair may communicate
information in the OVERALL-REQUEST-STATUS attribute, the floor
control server may override, modify, or ignore this field's
content.
床のいすの動きがOVERALL-REQUEST-STATUS属性における情報を伝えているかもしれない間、床の制御サーバがこのフィールドの内容を優越するか、変更するか、または無視するかもしれないことに注意してください。
The floor chair may use STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption.
床のいすは、床か床を受け入れるか、与えるか、または取り消している理由を述べるのにSTATUS-INFO属性を使用するかもしれません。 STATUS-INFO属性におけるTextは人間の消費で意図します。
11.2. Receiving a Response
11.2. 応答を受けます。
A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication.
サーバからのメッセージにChairActionメッセージとして同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはChairActionメッセージへの応答であると考えられます、セクション8.1で説明されるように。 そのような応答を受けると、床のいすは床のコントロールサーバ証明に関連するセクション9で約束を守ります。
Camarillo, et al. Standards Track [Page 42] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[42ページ]。
A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message.
床の制御サーバからのChairActionAckメッセージは、床の制御サーバがChairActionメッセージを受け入れたと確認します。 Errorメッセージは、床の制御サーバがChairActionメッセージを処理できなかったのを示します。(それは、Errorメッセージに何らかの理由に説明されます)。
12. General Client Operations
12. 一般クライアント操作
This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both.
このセクションはどんなクライアントも実行できる操作を指定します。 床の関係者か床のいすには、すなわち、それらは特定ではありません。 両方でそれらを実行できます。
12.1. Requesting Information about Floors
12.1. 床に関する情報を要求します。
A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは異なった方法で床か床の状態の情報を得ることができます。(方法は、BFCPを使用して、バンドの外でメカニズムを使用するのを含んでいます)。そのような情報を得るのにBFCPを使用しているクライアントがこのセクションで説明された手順を用います。
Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.
クライアントは、床の制御サーバにFloorQueryメッセージを送ることによって、1かいくつかの床の状態の情報を要求します。
12.1.1. Sending a FloorQuery Message
12.1.1. FloorQueryメッセージを送ります。
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.7におけるABNFはFloorQueryメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。 クライアントはクライアントの識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。
The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute.
クライアントはそれが情報を受け取りたがっているすべてのFloor IDをメッセージに挿入します。 床の制御サーバはこれらの床のすべてに関する定期情報を送るでしょう。 クライアントがもう特定の床の情報を受け取りたくないなら、それで、新しいFloorQueryメッセージはこの床のFLOOR-IDを取り除きます。 クライアントがもうどんな床の情報も受け取りたくないなら、それはFLOOR-ID属性なしでFloorQueryメッセージを送ります。
12.1.2. Receiving a Response
12.1.2. 応答を受けます。
A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the
床の制御サーバからのメッセージに同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはFloorQueryメッセージへの応答であると考えられます。
Camarillo, et al. Standards Track [Page 43] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[43ページ]。
FloorRequest message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
セクション8.1で説明されるようなFloorRequestメッセージ。 そのような応答を受けると、クライアントは床のコントロールサーバ証明に関連するセクション9で約束を守ります。
On reception of the FloorQuery message, the floor control server will respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either.
FloorQueryメッセージのレセプションでは、床の制御サーバはFloorStatusメッセージかErrorメッセージで反応するでしょう。 応答がFloorStatusメッセージであるなら、それはクライアントが情報を要求した床の情報およそ1を含むでしょう。 クライアントがFloorQueryメッセージのどんなFLOOR-ID属性も入れなかったなら(すなわち、クライアントはもうどんな床の情報も受け取りたがっていません)、床の制御サーバからのFloorStatusメッセージはどんなFLOOR-ID属性も含まないでしょう。
FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request.
床の情報を運ぶFloorStatusメッセージが床を特定するFLOOR-ID属性を含んでいます。 この属性の後に、FloorStatusメッセージはその床に関連する既存(1以上)の床の要求の情報を含みます。 それぞれの特定の床の要求の情報はFLOOR-REQUEST-情報属性でコード化されます。 この分類された属性は床の要求の情報を提供する1セットの属性があとに続いた床の要求を特定するFloor Request IDを運びます。
After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about.
最初のFloorStatusの後に、床の制御サーバは、メッセージをFloorStatusに送り続けるでしょう、クライアントが情報を要求した床で定期的に変化に関してクライアントに知らせて。
12.2. Requesting Information about Floor Requests
12.2. 床の要求に関する情報を要求します。
A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは異なった方法で1の状態の情報かいくつかの床の要求を得ることができます。(方法は、BFCPを使用して、バンドの外でメカニズムを使用するのを含んでいます)。そのような情報を得るのにBFCPを使用しているクライアントがこのセクションで説明された手順を用います。
Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server.
クライアントは、床の制御サーバにFloorRequestQueryメッセージを送ることによって、床の要求の現在の状態の情報を要求します。
Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request.
特定の床の要求の情報を要求するのは多くの状況で役に立ちます。 床の要求が待ち行列で進まないとき、例えば、FloorRequestメッセージのレセプションでは、床の制御サーバは、床の要求が状態(例えば、AcceptedからGrantedまでの)を変えるときだけ、メッセージをFloorRequestStatusに返すのを選ぶかもしれません。 この状況で、ユーザがそれを要求するなら、床の関係者は床の制御サーバに床の要求の状態に投票するFloorRequestQueryメッセージを使用できます。
Camarillo, et al. Standards Track [Page 44] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[44ページ]。
12.2.1. Sending a FloorRequestQuery Message
12.2.1. FloorRequestQueryメッセージを送ります。
The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.3におけるABNFはFloorRequestQueryメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。 クライアントはクライアントの識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。
The client must insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server.
クライアントは床の制御サーバで床の要求を特定するFLOOR-REQUEST-ID属性を挿入しなければなりません。
12.2.2. Receiving a Response
12.2.2. 応答を受けます。
A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
床の制御サーバからのメッセージにFloorRequestQueryメッセージとして同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはFloorRequestQueryメッセージへの応答であると考えられます、セクション8.1で説明されるように。 そのような応答を受けると、クライアントは床のコントロールサーバ証明に関連するセクション9で約束を守ります。
If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute.
応答がFloorRequestStatusメッセージであるなら、クライアントはクライアントがFLOOR-REQUEST-情報属性で情報を要求したFloorRequestの状態の情報を得ます。
If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message.
応答がErrorメッセージであるなら、床の制御サーバはFloorRequestQueryメッセージを処理しないかもしれません。
12.3. Requesting Information about a User
12.3. ユーザに関する情報を要求します。
A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは、異なった方法でこの関係者と関係があって、バンドの外でメカニズムを使用することで関係者の情報と床の要求を得ることができます。方法はBFCPを使用するのを含んでいます。そのような情報を得るのにBFCPを使用しているクライアントがこのセクションで説明された手順を用います。
Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server.
クライアントは、床の制御サーバにUserQueryメッセージを送ることによって関係者の情報と床の要求がこの関係者に関連したよう要求します。
This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a
この機能性は特定の床の関係者のディスプレイ名とURIに興味を持っている床のいすか床の関係者の役に立つかもしれません。 さらに、床の関係者は、それ自体の情報を要求するのが役に立つのがわかるかもしれません。 例えば、a
Camarillo, et al. Standards Track [Page 45] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[45ページ]。
floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist.
接続性問題(例えば床の制御サーバとのTCP関係は、しばらく下がって、結局、復職した)を経験した後に、床の関係者は、すべての床の情報が、まだそれ自体に関連づけられていて、存在するよう要求するよう要求する必要があるかもしれません。
12.3.1. Sending a UserQuery Message
12.3.1. UserQueryメッセージを送ります。
The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.5におけるABNFはUserQueryメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。 クライアントはクライアントの識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。
If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the common header of the message), the client MUST insert a BENEFICIARY-ID attribute.
クライアントが情報を要求している床の関係者がUserQueryメッセージ(メッセージの一般的なヘッダーのUser IDによって特定される)を発行するクライアントでないなら、クライアントはBENEFICIARY-ID属性を挿入しなければなりません。
12.3.2. Receiving a Response
12.3.2. 応答を受けます。
A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
床の制御サーバからのメッセージにUserQueryメッセージとして同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはUserQueryメッセージへの応答であると考えられます、セクション8.1で説明されるように。 そのような応答を受けると、クライアントは床のコントロールサーバ証明に関連するセクション9で約束を守ります。
If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes.
応答がUserStatusメッセージであるなら、クライアントはBENEFICIARY-情報の分類された属性の床の関係者とFLOOR-REQUEST-情報属性の床の関係者に関連している床の要求の状態の情報を得ます。
If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message.
応答がErrorメッセージであるなら、床の制御サーバはUserQueryメッセージを処理しないかもしれません。
12.4. Obtaining the Capabilities of a Floor Control Server
12.4. 床の制御サーバの能力を得ます。
A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server.
床の制御サーバの能力を得たがっているクライアントは、床の制御サーバにHelloメッセージを送ることによって、そうします。
Camarillo, et al. Standards Track [Page 46] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[46ページ]。
12.4.1. Sending a Hello Message
12.4.1. メッセージをこんにちはに送ります。
The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.11におけるABNFはHelloメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request.
クライアントは一般的なヘッダーのConference IDとTransaction IDをセクション8.1で与えられた規則に従わせます。 クライアントはクライアントの識別子への一般的なヘッダーにUser IDをはめ込みます。 要求をこのUser IDは床の制御サーバによって使用されて、認証して、認可するでしょう。
12.4.2. Receiving Responses
12.4.2. 応答を受けます。
A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
床の制御サーバからのメッセージにHelloメッセージとして同じConference ID、Transaction ID、およびUser IDがあるなら、床の制御サーバからのメッセージはHelloメッセージへの応答であるとクライアントによって考えられます、セクション8.1で説明されるように。 そのような応答を受けると、クライアントは床のコントロールサーバ証明に関連するセクション9で約束を守ります。
If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITVIES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server.
応答がHelloAckメッセージであるなら、床の制御サーバは首尾よくHelloメッセージを処理するかもしれません。 SUPPORTED-PRIMITVIESとSUPPORTED-ATTRIBUTES属性は、どの基関数と属性がサーバによってそれぞれサポートされるかを示します。
If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message.
応答がErrorメッセージであるなら、床の制御サーバはHelloメッセージを処理しないかもしれません。
13. Floor Control Server Operations
13. 床のコントロールサーバ操作
This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections.
このセクションは床の制御サーバがどう異なった操作を実行できるかを指定します、床を与えるのなどように、以前のセクションで説明されたプロトコル要素を使用して。
On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive).
クライアントからのメッセージのレセプションでは、床の制御サーバは、Primitiveの値がサポートされるかどうかチェックしなければなりません。 それがそうしないなら、床の制御サーバSHOULDはErrorメッセージを送ります、セクション13.8で説明されるように、Errorコード3(未知のPrimitive)で。
On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist).
クライアントからのメッセージのレセプションでは、床の制御サーバは、Conference IDの値が既存の会議に合っていたかどうかチェックしなければなりません。 それがそうしないなら、床の制御サーバSHOULDはErrorメッセージを送ります、セクション13.8で説明されるように、Errorコード1で(コンファレンスはどんなExistもしません)。
Camarillo, et al. Standards Track [Page 47] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[47ページ]。
On reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message.
クライアントからのメッセージのレセプションでは、床の制御サーバはメッセージの認証に関連するセクション9で約束を守ります。
On reception of a message from a client, the floor control server
MUST check whether it understands all the mandatory ('M' bit set)
attributes in the message. If the floor control server does not
understand all of them, the floor control server SHOULD send an Error
message, as described in Section 13.8, with Error code 2
(Authentication Failed). The Error message SHOULD list the
attributes that were not understood.
クライアントからのメッセージのレセプションでは、床の制御サーバは、それがメッセージのすべての('M'ビットはセットしました)義務的な属性を理解しているかどうかチェックしなければなりません。 床の制御サーバがそれらを皆、理解していないなら、床の制御サーバSHOULDはErrorメッセージを送ります、セクション13.8で説明されるように、Errorコード2(認証Failed)で。 ErrorメッセージSHOULDは理解されていなかった属性を記載します。
13.1. Reception of a FloorRequest Message
13.1. FloorRequestメッセージのレセプション
On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorRequestメッセージのレセプションでは、床の制御サーバはクライアント認証と承認に関連するセクション9で約束を守ります。 FloorRequestメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
BFCP allows floor participants to have several ongoing floor
requests for the same floor (e.g., the same floor participant can
occupy more than one position in a queue at the same time). A
floor control server that only supports a certain number of
ongoing floor requests per floor participant (e.g., one) can use
Error Code 8 (You have Already Reached the Maximum Number of
Ongoing Floor Requests for this Floor) to inform the floor
participant.
BFCPは床の関係者に同じ床を求めるいくつかの進行中の床の要求を持たせます(例えば、同じ床の関係者は同時に、待ち行列における1つ以上の位置を占めることができます)。 ある数の床の関係者(例えば、1)あたりの進行中の床の要求をサポートするだけである床の制御サーバは、床の関係者に知らせるのに、Error Code8(あなたはこのFloorのためのOngoing Floor RequestsのAlready Reached Maximum Numberを持っています)を使用できます。
13.1.1. Generating the First FloorRequestStatus Message
13.1.1. 最初のFloorRequestStatusメッセージを生成します。
The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates.
床の制御サーバによるFloorRequestメッセージのうまくいっている処理はどのSHOULDについて1か数個のFloorRequestStatusがメッセージであると生成する1番目にかかわるか。できるだけ早く、生成されます。 床が制御されるなら、サーバは、すぐ床の要求を受け入れない場合がありますし、承諾しない場合がありますし、また否定しない場合があって(いすからの例えば決定が必要です)、それはRequest Statusが評価するそれが生成する最初のFloorRequestStatusメッセージのOVERALL-REQUEST- STATUS属性(FLOOR-REQUEST-情報の分類された属性の中の)におけるPendingのSHOULD使用です。
The policy that a floor control server follows to grant or deny
floors is outside the scope of this document. A given floor
control server may perform these decisions automatically while
another may contact a human acting as a chair every time a
decision needs to be made.
このドキュメントの範囲の外に床の制御サーバが床を与えるか、または否定するために従う方針があります。 別のものが決定が、作られている必要があるときはいつも、いすとして務めている人間に連絡しているかもしれない間、与えられた床の制御サーバは自動的にこれらの決定を実行するかもしれません。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the
床の制御サーバはConference Transaction ID(ID)、およびFloorRequestからのUser IDをコピーしなければなりません。
Camarillo, et al. Standards Track [Page 48] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[48ページ]。
FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
セクション8.2で説明されるようなFloorRequestStatus。 さらに、床の制御サーバは、FLOOR-REQUEST-情報が属性をFloorRequestStatusに分類したと言い足さなければなりません。 この分類された属性に含まれた属性は床の要求の情報を運びます。
The floor control server MUST assign an identifier that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future.
床の制御サーバは、会議の中でユニークな識別子をこの床の要求に割り当てなければならなくて、FLOOR-REQUEST-情報属性のFloor Request ID分野にそれを挿入しなければなりません。 この識別子は、将来この特定の床の要求を示すのに床の関係者(またはいすかいすで)によって使用されるでしょう。
The floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request).
床の制御サーバはFLOOR-REQUEST-情報の分類された属性におけるFLOOR-REQUEST-STATUS属性にFloorRequestのFLOOR-ID属性におけるFloor IDをコピーしなければなりません。 これらのFloor IDは要求されている床(すなわち、この特定の床の要求に関連している床)を特定します。
The floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
床の制御サーバSHOULDはFLOOR-REQUEST-情報の分類された属性でBENEFICIARY-ID属性のコンテンツをBENEFICIARY-情報属性にFloorRequestを回避します(存在しているなら)。 さらに、床の制御サーバはこのBENEFICIARY-情報属性にディスプレイ名と受益者のURIを提供するかもしれません。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR-REQUEST-情報の分類された属性でREQUESTED-BY-情報属性に床のリクエスタの情報を提供するかもしれません。
The floor control server MAY copy (if present) the PARTICIPANT- PROVIDED-INFO attribute from the FloorRequest into the FLOOR- REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR- REQUEST-情報の分類された属性にPARTICIPANT- PROVIDED-INFO属性をFloorRequestを回避するかもしれません(存在しているなら)。
Note that this attribute carries the priority requested by the
participant. The priority that the floor control server assigns
to the floor request depends on the priority requested by the
participant and the rights the participant has according to the
policy of the conference. For example, a participant that is only
allowed to use the Normal priority may request Highest priority
for a floor request. In that case, the floor control server would
ignore the priority requested by the participant.
この属性が関係者によって要求された優先権を運ぶことに注意してください。 床の制御サーバが床の要求に割り当てる優先権は会議の方針によると、関係者が持っている権利によります。 例えば、Normal優先権を使用できるだけである関係者は床の要求のためにHighest優先権を要求するかもしれません。 その場合、床の制御サーバは関係者によって要求された優先権を無視するでしょう。
The floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR-REQUEST-情報の分類された属性にPARTICIPANT-PROVIDED-INFO属性をFloorRequestを回避するかもしれません(存在しているなら)。
Camarillo, et al. Standards Track [Page 49] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[49ページ]。
13.1.2. Generation of Subsequent FloorRequestStatus Messages
13.1.2. その後のFloorRequestStatusメッセージの世代
A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages.
それがCancelled、Released、またはRevoked州にない限り、床の要求が進行中であると考えられます。 床の制御サーバによって生成された最初のFloorRequestStatusメッセージのOVERALL-REQUEST- STATUS属性(FLOOR-REQUEST-情報の分類された属性における)がこれらの州のいずれも示さなかったなら、床の制御サーバは、その後のFloorRequestStatusメッセージを送る必要があるでしょう。
When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.)
床の要求の状態が変化するとき、床の制御サーバSHOULDは適切なRequest Statusがある新しいFloorRequestStatusメッセージを送ります。 床の制御サーバは、ものと等しいFloor Request IDがあるFLOOR-REQUEST-情報属性が同じ床の要求に関連するどんな新しいFloorRequestStatusにも最初のFloorRequestStatusメッセージを送ったと言い足さなければなりません。 (Floor Request IDはFloorRequestStatusが適用する床の要求を特定します。)
The floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0.
床の制御サーバはその後のFloorRequestStatusメッセージのTransaction IDを0に設定しなければなりません。
The rate at which the floor control server sends
FloorRequestStatus messages is a matter of local policy. A floor
control server may choose to send a new FloorRequestStatus message
every time the floor request moves in the floor request queue,
while another may choose only to send a new FloorRequestStatus
message when the floor request is Granted or Denied.
床の制御サーバがメッセージをFloorRequestStatusに送るレートはローカルの方針の問題です。 床の制御サーバは、床の要求が床の要求待ち行列に入って来るときはいつも、新しいFloorRequestStatusメッセージを送るのを選ぶかもしれません、別のものが、床の要求がGrantedかDeniedであるときに、単に新しいFloorRequestStatusメッセージを送るのを選ぶかもしれませんが。
The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied).
床の制御サーバはそれが床の要求(例えば、それが否定された理由)に関する決定に関するその他の情報を提供するために生成するFloorRequestStatusメッセージのいずれにもSTATUS-INFO属性を追加するかもしれません。
Floor participants and floor chairs may request to be informed
about the status of a floor following the procedures in
Section 12.1. If the processing of a floor request changes the
status of a floor (e.g., the floor request is granted and
consequently the floor has a new holder), the floor control server
needs to follow the procedures in Section 13.5 to inform the
clients that have requested that information.
関係者と床のいすがセクション12.1で手順に従う床の状態に関して知識があるよう要求するかもしれない床。 床の要求の処理が床の状態を変えるなら(例えば床の要求は承諾されます、そして、その結果、床には、新しい所有者がいます)、床の制御サーバが、その情報を要求したクライアントに知らせるためにセクション13.5で手順に従う必要があります。
The common header and the rest of the attributes are the same as in the first FloorRequestStatus message.
一般的なヘッダーと属性の残りは最初のFloorRequestStatusメッセージと同じです。
The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked.
これがCancelled、Released、またはRevokedの状態に達すると、床の制御サーバは特定の床の要求の州の情報を捨てることができます。
Camarillo, et al. Standards Track [Page 50] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[50ページ]。
13.2. Reception of a FloorRequestQuery Message
13.2. FloorRequestQueryメッセージのレセプション
On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorRequestQueryメッセージのレセプションでは、床の制御サーバはクライアント認証と承認に関連するセクション9で約束を守ります。 FloorRequestQueryメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
床の制御サーバによるFloorRequestQueryメッセージのうまくいっている処理は、FloorRequestStatusメッセージを生成することを伴って、どのSHOULDができるだけ早く、生成されますか?
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.
床の制御サーバはConference ID、Transaction ID、およびUser IDをFloorRequestStatusメッセージにFloorRequestQueryメッセージを回避しなければなりません、セクション8.2で説明されるように。 さらに、床の制御サーバはFLOOR-REQUEST-情報の分類された属性に床の要求の情報をFloorRequestStatusに含まなければなりません。
The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
床の制御サーバはFLOOR-REQUEST-情報属性のFloor Request ID分野にFLOOR-REQUEST-ID属性のコンテンツをFloorRequestQueryメッセージを回避しなければなりません。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
床の制御サーバは要求されている床(すなわち、FLOOR-REQUEST-ID属性によって特定される床の要求に関連している床)を特定するFLOOR-REQUEST-情報の分類された属性にFLOOR-REQUEST-STATUS属性を加えなければなりません。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
床の制御サーバSHOULDは床の要求の受益者を特定するFLOOR-REQUEST-情報の分類された属性にBENEFICIARY-ID属性を加えます。 さらに、床の制御サーバはこのBENEFICIARY-情報属性にディスプレイ名と受益者のURIを提供するかもしれません。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR-REQUEST-情報の分類された属性でREQUESTED-BY-情報属性に床のリクエスタの情報を提供するかもしれません。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
床の制御サーバは床の関係者が要求した理由にPARTICIPANT-PROVIDED-INFOの床を提供するかもしれません。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request.
また、Priority値が床の要求とSTATUS-INFO属性のために床の要求に関するその他の情報で要求されている状態で、床の制御サーバはFLOOR-REQUEST-情報の分類された属性にPRIORITY属性を加えるかもしれません。
Camarillo, et al. Standards Track [Page 51] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[51ページ]。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
床の制御サーバは床の要求の現在の状態でFLOOR-REQUEST-情報の分類された属性にOVERALL-REQUEST-STATUS属性を加えなければなりません。 FLOOR-REQUEST-STATUS属性で要求されているそれぞれの床に関連するとき、床の制御サーバは床の要求の状態の情報を提供するかもしれません。
13.3. Reception of a UserQuery Message
13.3. UserQueryメッセージのレセプション
On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
UserQueryメッセージのレセプションでは、床の制御サーバはクライアント認証と承認に関連するセクション9で約束を守ります。 UserQueryメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible.
床の制御サーバによるUserQueryメッセージのうまくいっている処理は、UserStatusメッセージを生成することを伴って、どのSHOULDができるだけ早く、生成されますか?
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the USerStatus message, as described in Section 8.2.
床の制御サーバはConference ID、Transaction ID、およびUser IDをUSerStatusメッセージにUserQueryメッセージを回避しなければなりません、セクション8.2で説明されるように。
The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message.
UserQueryメッセージの送付者は与えられた関係者(すなわち、関係者が受益者かリクエスタのどちらかである床の要求)に関連しているすべての床の要求の情報を要求しています。 または、この関係者がBENEFICIARY-ID属性によって特定される、BENEFICIARY-ID属性がないときUser ID、UserQueryメッセージの一般的なヘッダーで。
The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute.
床の制御サーバはコピーされなければなりません、存在しているなら、UserStatusメッセージのBENEFICIARY-情報属性へのUserQueryメッセージからのBENEFICIARY-ID属性のコンテンツ。 さらに、床の制御サーバはUserStatusメッセージがこのBENEFICIARY-情報属性に情報を提供する関係者のディスプレイ名とURIを提供するかもしれません。
The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
床の制御サーバSHOULDは、FLOOR-REQUEST-情報がメッセージが情報(すなわち、関係者が受益者かリクエスタのどちらかである床の要求)を提供する関係者に伝えるそれぞれの床の要求のために属性を分類したとUserStatusメッセージに追加します。 それぞれのFLOOR-REQUEST-情報属性のために、床の制御サーバは以下の方法に従います。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
床の制御サーバは、FLOOR-REQUEST-情報属性のFloor Request ID分野をいっぱいにすることによって、FLOOR-REQUEST-情報属性が申し込む床の要求を特定しなければなりません。
Camarillo, et al. Standards Track [Page 52] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[52ページ]。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
床の制御サーバは要求されている床(すなわち、FLOOR-REQUEST-ID属性によって特定される床の要求に関連している床)を特定するFLOOR-REQUEST-情報の分類された属性にFLOOR-REQUEST-STATUS属性を加えなければなりません。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
床の制御サーバSHOULDは床の要求の受益者を特定するFLOOR-REQUEST-情報の分類された属性にBENEFICIARY-ID属性を加えます。 さらに、床の制御サーバはこのBENEFICIARY-情報属性にディスプレイ名と受益者のURIを提供するかもしれません。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR-REQUEST-情報の分類された属性でREQUESTED-BY-情報属性に床のリクエスタの情報を提供するかもしれません。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
床の制御サーバは床の関係者が要求した理由にPARTICIPANT-PROVIDED-INFOの床を提供するかもしれません。
The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.
また、Priority値が床の要求のために要求されている状態で、床の制御サーバはFLOOR-REQUESTの情報の分類された属性にPRIORITY属性を加えるかもしれません。
The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- INFORMATION grouped attribute. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
床の制御サーバはOVERALL-REQUEST-STATUS属性にFLOOR-REQUESTの情報の分類された属性に床の要求の現在の状態を含まなければなりません。 床の制御サーバは床の要求に関するその他の情報でSTATUS-INFO属性を加えるかもしれません。
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
FLOOR-REQUEST-STATUS属性で要求されているそれぞれの床に関連するとき、床の制御サーバは床の要求の状態の情報を提供するかもしれません。
13.4. Reception of a FloorRelease Message
13.4. FloorReleaseメッセージのレセプション
On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorReleaseメッセージのレセプションでは、床の制御サーバはクライアント認証と承認に関連するセクション9で約束を守ります。 FloorReleaseメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
床の制御サーバによるFloorReleaseメッセージのうまくいっている処理は、FloorRequestStatusメッセージを生成することを伴って、どのSHOULDができるだけ早く、生成されますか?
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2.
床の制御サーバはConference ID、Transaction ID、およびUser IDをFloorRequestStatusメッセージにFloorReleaseメッセージを回避しなければなりません、セクション8.2で説明されるように。
Camarillo, et al. Standards Track [Page 53] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[53ページ]。
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
床の制御サーバは、FLOOR-REQUEST-情報が属性をFloorRequestStatusに分類したと言い足さなければなりません。 この分類された属性に含まれた属性は床の要求の情報を運びます。
The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
FloorReleaseメッセージはそれがFLOOR-REQUEST-IDを使用するのに適用する床の要求を特定します。 床の制御サーバはFLOOR-REQUEST-情報属性のFloor Request ID分野にFLOOR-REQUEST-ID属性のコンテンツをFloorReleaseメッセージを回避しなければなりません。
The floor control server MUST identify the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR-REQUEST-STATUS属性で要求されている床(すなわち、FLOOR-REQUEST-ID属性によって特定される床の要求に関連している床)をFLOOR-REQUEST-情報の分類された属性に特定しなければなりません。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS- INFO attribute with extra information about the floor request.
床の制御サーバはFLOOR-REQUEST-情報の分類された属性にOVERALL-REQUEST-STATUS属性を加えなければなりません。 Request StatusはSHOULDを評価します。Released、以前に、床(または、床)を与えたか、そして、またはCancelledになってください、床(床)が以前に与えられていなかったなら。 床の制御サーバは床の要求に関するその他の情報でSTATUS- INFO属性を加えるかもしれません。
13.5. Reception of a FloorQuery Message
13.5. FloorQueryメッセージのレセプション
On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorRelease message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
FloorQueryメッセージのレセプションでは、床の制御サーバはクライアント認証に関連するセクション9で約束を守ります。 FloorReleaseメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages.
SHOULDがこのクライアントであることを保つクライアントからFloorQueryメッセージを受け取る床の制御サーバはFloorQueryメッセージのFLOOR-ID属性によって特定された床の状態に関して知らせました。 床のControl Serversは、FloorStatusメッセージを使用することによってクライアントに知らせ続けます。
An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors.
個々のFloorStatusメッセージは単一の床の情報を運びます。 それで、FloorQueryメッセージが1階以上の情報を要求するとき、床の制御サーバは、異なった床への別々のFloorStatusメッセージを送る必要があります。
The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so.
FloorQueryメッセージが運ぶ情報は情報を要求するユーザに頼るかもしれません。 例えば、いすは未定の要求の情報を受け取ることができるかもしれません、愛用者がそうするのに権限を与えられないかもしれませんが。
Camarillo, et al. Standards Track [Page 54] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[54ページ]。
13.5.1. Generation of the First FloorStatus Message
13.5.1. 最初のFloorStatusメッセージの世代
The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible.
床の制御サーバによるFloorQueryメッセージのうまくいっている処理はどのSHOULDについて1か数個のFloorStatusがメッセージであると生成する1番目にかかわるか。できるだけ早く、生成されます。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2.
床の制御サーバはConference ID、Transaction ID、およびUser IDをFloorStatusメッセージにFloorQueryメッセージを回避しなければなりません、セクション8.2で説明されるように。
If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant.
FloorQueryメッセージがどんなFLOOR-ID属性も含まなかったなら、床の制御サーバは、どんな追加属性も加えないでFloorStatusメッセージを送って、どんなその後のFloorStatusメッセージも床の関係者に送りません。
If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
FloorQueryメッセージが1つ以上のFLOOR-ID属性を含んだなら、床の制御サーバは、FloorStatusメッセージにそれらからの1つを選んで、このFLOOR-ID属性を追加します。 床の制御サーバSHOULDは、FLOOR-REQUEST-情報が床に関連づけられたそれぞれの床の要求のために属性を分類したと言い足します。 それぞれのFLOOR-REQUEST-情報の分類された属性は床の要求の情報を提供する多くの属性を含んでいます。 それぞれのFLOOR-REQUEST-情報属性のために、床の制御サーバは以下の方法に従います。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
床の制御サーバは、FLOOR-REQUEST-情報属性のFloor Request ID分野をいっぱいにすることによって、FLOOR-REQUEST-情報属性が申し込む床の要求を特定しなければなりません。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
床の制御サーバは要求されている床(すなわち、FLOOR-REQUEST-ID属性によって特定される床の要求に関連している床)を特定するFLOOR-REQUEST-情報の分類された属性にFLOOR-REQUEST-STATUS属性を加えなければなりません。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
床の制御サーバSHOULDは床の要求の受益者を特定するFLOOR-REQUEST-情報の分類された属性にBENEFICIARY-ID属性を加えます。 さらに、床の制御サーバはこのBENEFICIARY-情報属性にディスプレイ名と受益者のURIを提供するかもしれません。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
床の制御サーバはFLOOR-REQUEST-情報の分類された属性でREQUESTED-BY-情報属性に床のリクエスタの情報を提供するかもしれません。
Camarillo, et al. Standards Track [Page 55] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[55ページ]。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
床の制御サーバは床の関係者が要求した理由にPARTICIPANT-PROVIDED-INFOの床を提供するかもしれません。
The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.
また、Priority値が床の要求のために要求されている状態で、床の制御サーバはFLOOR-REQUESTの情報の分類された属性にPRIORITY属性を加えるかもしれません。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
床の制御サーバは床の要求の現在の状態でFLOOR-REQUEST-情報の分類された属性にOVERALL-REQUEST-STATUS属性を加えなければなりません。 床の制御サーバは床の要求に関するその他の情報でSTATUS-INFO属性を加えるかもしれません。
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
FLOOR-REQUEST-STATUS属性で要求されているそれぞれの床に関連するとき、床の制御サーバは床の要求の状態の情報を提供するかもしれません。
13.5.2. Generation of Subsequent FloorStatus Messages
13.5.2. その後のFloorStatusメッセージの世代
If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0.
FloorQueryメッセージが1つ以上のFLOOR-ID属性を運んだなら、床の制御サーバSHOULDはできるだけ早く、それぞれの彼ら(最初のFloorStatusメッセージに選ばれたFLOOR-ID属性を除いた)へのFloorStatusメッセージを生成します。 これらのFloorStatusメッセージは最初のFloorStatusメッセージのためのそれらと同じ次の規則であると生成されますが(セクション13.5.1を見てください)、彼らのTransaction IDは0です。
After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0.
これらのメッセージを生成した後に、床の制御サーバはメッセージをFloorStatusに送ります、定期的にクライアントが情報を要求したすべての床に関して知識があるクライアントを保って。 これらのメッセージのTransaction IDは0であるに違いありません。
The rate at which the floor control server sends FloorStatus
messages is a matter of local policy. A floor control server may
choose to send a new FloorStatus message every time a new floor
request arrives, while another may choose to only send a new
FloorStatus message when a new floor request is Granted.
床の制御サーバがメッセージをFloorStatusに送るレートはローカルの方針の問題です。 床の制御サーバは、新しい床の要求が到着するときはいつも、新しいFloorStatusメッセージを送るのを選ぶかもしれません、別のものが、新しい床の要求がGrantedであるときにだけ、新しいFloorStatusメッセージを送るのを選ぶかもしれませんが。
13.6. Reception of a ChairAction Message
13.6. ChairActionメッセージのレセプション
On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
ChairActionメッセージのレセプションでは、床の制御サーバはクライアント認証と承認に関連するセクション9で約束を守ります。 ChairActionメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible.
床の制御サーバによるChairActionメッセージのうまくいっている処理は、ChairActionAckメッセージを生成することを伴って、どのSHOULDができるだけ早く、生成されますか?
Camarillo, et al. Standards Track [Page 56] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[56ページ]。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2.
床の制御サーバはConference ID、Transaction ID、およびUser IDをChairActionAckメッセージにChairActionメッセージを回避しなければなりません、セクション8.2で説明されるように。
The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
床の制御サーバは、ChairActionメッセージ(例えば、床を与える)で要求された操作を考慮に入れるのが必要ですが、必ず要求された通り床のいすでそれを実行する必要があるというわけではありません。 床の制御サーバが実行する操作はChairActionメッセージと、そして、床の制御サーバの内部の事情に依存します。
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well.
例えば、床のいすはChairActionメッセージにいくつかの床にかかわった原子床の要求操作の一部として要求された床を与えさせるかもしれません。 床の1つに責任があるいすが、床を与えるよう床の制御サーバに命令しても、他の床に責任があるいすが、また、それらを与えるのに同意するまで、床の制御サーバはそれを与えないでしょう。
So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.
それで、一貫性を持っている床が状態であることをこの状態に入力されるように床のいすから指示を使用することで保つのに床の制御サーバは結局、原因となります。
If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue.)
ChairActionメッセージの新しいStatusがAcceptedであり、Queue Position分野のすべてのビットがゼロであるなら、床のいすは、床の制御サーバが床の制御サーバのローカルの方針に基づく床の要求に待ち行列位置(例えば、待ち行列における最終)を割り当てるよう要求しています。(もちろん、床の制御サーバが待ち行列を実装する場合にだけ、そのような要求は適用されます。)
13.7. Reception of a Hello Message
13.7. こんにちはのレセプションは通信します。
On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8.
Helloメッセージのレセプションでは、床の制御サーバはクライアント認証に関連するセクション9で約束を守ります。 Helloメッセージ、床が処理している間、制御されるなら、サーバは誤りに遭遇します、それ。SHOULDは、Errorが手順に従うのがセクション13.8で説明した応答であると生成します。
The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2.
床の制御サーバによるHelloメッセージのうまくいっている処理は、HelloAckメッセージを生成することを伴って、どのSHOULDができるだけ早く、生成されますか? 床の制御サーバはConference ID、Transaction ID、およびUser IDをHelloAckにHelloを回避しなければなりません、セクション8.2で説明されるように。
The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server.
床の制御サーバは床の制御サーバによってサポートされたすべての基関数(すなわち、BFCPメッセージ)をリストアップするHelloAckメッセージにSUPPORTED-PRIMITIVES属性を追加しなければなりません。
Camarillo, et al. Standards Track [Page 57] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[57ページ]。
The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server.
床の制御サーバは床の制御サーバによってサポートされたすべての属性を記載するHelloAckメッセージにSUPPORTED-ATTRIBUTES属性を追加しなければなりません。
13.8. Error Message Generation
13.8. エラーメッセージ世代
Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional.
クライアントによって開始されたトランザクションの一部としていつもクライアントからの前のメッセージに対応してエラーメッセージを送ります。 セクション5.3.13におけるABNFはErrorメッセージが含むことができる属性について説明します。 さらに、ABNFはこれらの属性のどれが義務的であるか、そして、どれが任意であるかを標準に指定します。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2.
床の制御サーバはConference ID、Transaction ID、およびUser IDをErrorメッセージにクライアントからのメッセージを回避しなければなりません、セクション8.2で説明されるように。
The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error.
床の制御サーバはERROR-CODE属性をErrorメッセージに追加しなければなりません。 ERROR-CODE属性はTable5からのError Codeを含んでいます。 さらに、床の制御サーバは誤りに関するその他の情報でERROR-INFO属性を加えるかもしれません。
14. Security Considerations
14. セキュリティ問題
BFCP uses TLS to provide mutual authentication between clients and servers. TLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS with non-null encryption always be used. BFCP entities MAY use other security mechanisms as long as they provide similar security properties.
BFCPは、クライアントとサーバの間に互いの認証を提供するのにTLSを使用します。 また、TLSは再生、保全保護、および秘密性を提供します。 非ヌル暗号化があるTLSがいつも使用されるのは、RECOMMENDEDです。 同様のセキュリティ資産を提供する限り、BFCP実体は他のセキュリティー対策を使用するかもしれません。
The remainder of this section analyzes some of the threats against BFCP and how they are addressed.
BFCPとそれらがどう扱われるかに対してこのセクションの残りは脅威のいくつかを分析します。
An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections. The floor control server assumes that attackers cannot highjack the TLS connection and, therefore, that messages over the TLS connection come from the client that was initially authenticated.
攻撃者は、要求か交付金に偽造床を生成するか、または既存の床が要求することを否定するために、クライアント(床の関係者か床のいす)をまねるのを試みるかもしれません。 サーバに認証されたTLS接続の上にBFCPメッセージを受け入れさせるだけによって、クライアントものまねは避けられます。 床の制御サーバは、攻撃者はTLS接続としたがって、TLS接続の上のそのメッセージが初めは認証されたクライアントから来させる乗っ取りをそうすることができないと仮定します。
An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections.
攻撃者は、床の制御サーバをまねるのを試みるかもしれません。うまくいっている攻撃者はクライアントに彼らがそれにアクセスする正当な権利を持っていなくてリソース(例えば、送付メディア)にアクセスしようとするように特定の床を持っていると考えさせることができるでしょう。 サーバに認証されたTLS接続の上にBFCPメッセージを受け入れさせるだけによって、床のコントロールサーバものまねは避けられます。
Camarillo, et al. Standards Track [Page 58] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[58ページ]。
Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS connections prevents this attack.
攻撃者は、クライアントと床の制御サーバによって交換されたメッセージを変更するのを試みるかもしれません。TLS接続によって提供された保全保護はこの攻撃を防ぎます。
An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS connection is allowed to use).
攻撃者は、クライアントによって送られた有効なメッセージを床の制御サーバにとって来て、攻撃者と床の制御サーバとの関係の上でそれを再演するのを試みるかもしれません。床の制御サーバに与えられた認証されたTLS接続の上で到着するメッセージが認定ユーザID(すなわち、認証されたTLS接続を確立したユーザが使用できるユーザID)を使用するのをチェックさせることによって、この攻撃は防がれます。
Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS confidentiality prevents this attack. Therefore, it is RECOMMENDED that TLS be used with a non-null encryption algorithm.
攻撃者は、床の制御サーバとクライアント(例えば、床の要求が否定された理由)の間の秘密情報に近づく手段を得るためにネットワークからのメッセージを選ぶのを試みるかもしれません。 TLS秘密性はこの攻撃を防ぎます。 したがって、TLSが非ヌル暗号化アルゴリズムで使用されるのは、RECOMMENDEDです。
15. IANA Considerations
15. IANA問題
The IANA has created a new registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This new registry has a number of subregistries, which are described in the following sections.
IANAは「2進の床の制御プロトコル(BFCP)パラメタ」と呼ばれるBFCPパラメタのための新しい登録を作成しました。 この新しい登録には多くの副登録があります。(副登録は以下のセクションで説明されます)。
15.1. Attribute Subregistry
15.1. 属性Subregistry
This section establishes the Attribute subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP attributes shall be "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics.
このセクションはBFCP Parameters登録の下のAttribute subregistryを設立します。 RFC2434[4]の用語に従って、BFCP属性のための登録方針は「仕様が必要です」でしょう。 この副登録の目的のために、標準化過程RFCはIANA登録が要求されているBFCP属性を定義しなければなりません。 そのようなRFC MUSTは属性のタイプ、名前、形式、および意味論を指定します。
For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry.
それぞれのBFCP属性のために、IANAは属性が定義されるRFCのタイプ、名前、および参照を示します。 以下のテーブルはこの副登録の初期の値を含んでいます。
Camarillo, et al. Standards Track [Page 59] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[59ページ]。
+------+---------------------------+------------+
| Type | Attribute | Reference |
+------+---------------------------+------------+
| 1 | BENEFICIARY-ID | [RFC 4582] |
| 2 | FLOOR-ID | [RFC 4582] |
| 3 | FLOOR-REQUEST-ID | [RFC 4582] |
| 4 | PRIORITY | [RFC 4582] |
| 5 | REQUEST-STATUS | [RFC 4582] |
| 6 | ERROR-CODE | [RFC 4582] |
| 7 | ERROR-INFO | [RFC 4582] |
| 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
| 9 | STATUS-INFO | [RFC 4582] |
| 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] |
| 11 | SUPPORTED-PRIMITIVES | [RFC 4582] |
| 12 | USER-DISPLAY-NAME | [RFC 4582] |
| 13 | USER-URI | [RFC 4582] |
| 14 | BENEFICIARY-INFORMATION | [RFC 4582] |
| 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
| 16 | REQUESTED-BY-INFORMATION | [RFC 4582] |
| 17 | FLOOR-REQUEST-STATUS | [RFC 4582] |
| 18 | OVERALL-REQUEST-STATUS | [RFC 4582] |
+------+---------------------------+------------+
+------+---------------------------+------------+ | タイプ| 属性| 参照| +------+---------------------------+------------+ | 1 | 受益者のID| [RFC4582]| | 2 | FLOOR ID| [RFC4582]| | 3 | 床のREQUEST ID| [RFC4582]| | 4 | 優先権| [RFC4582]| | 5 | 要求状態| [RFC4582]| | 6 | エラーコード| [RFC4582]| | 7 | 誤りインフォメーション| [RFC4582]| | 8 | 関係者はインフォメーションを提供しました。| [RFC4582]| | 9 | 状態インフォメーション| [RFC4582]| | 10 | サポートしている属性| [RFC4582]| | 11 | サポートしている基関数| [RFC4582]| | 12 | ユーザディスプレイ名| [RFC4582]| | 13 | ユーザユリ| [RFC4582]| | 14 | 受益者の情報| [RFC4582]| | 15 | 床の要求情報| [RFC4582]| | 16 | 情報で、要求されます。| [RFC4582]| | 17 | 床の要求状態| [RFC4582]| | 18 | 総合的な要求状態| [RFC4582]| +------+---------------------------+------------+
Table 6: Initial values of the BFCP Attribute subregistry
テーブル6: BFCP Attribute subregistryの初期の値
15.2. Primitive Subregistry
15.2. 原始のSubregistry
This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics.
このセクションはBFCP Parameters登録の下のPrimitive subregistryを設立します。 RFC2434[4]の用語に従って、BFCP基関数のための登録方針は「仕様が必要です」でしょう。 この副登録の目的のために、標準化過程RFCはIANA登録が要求されているBFCP基関数を定義しなければなりません。 そのようなRFC MUSTは基関数の値、名前、形式、および意味論を指定します。
For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
各BFCPに原始的です、IANAは原始が定義されるRFCの値、名前、および参照を示します。 以下のテーブルはこの副登録の初期の値を含んでいます。
Camarillo, et al. Standards Track [Page 60] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[60ページ]。
+-------+--------------------+------------+
| Value | Primitive | Reference |
+-------+--------------------+------------+
| 1 | FloorRequest | [RFC 4582] |
| 2 | FloorRelease | [RFC 4582] |
| 3 | FloorRequestQuery | [RFC 4582] |
| 4 | FloorRequestStatus | [RFC 4582] |
| 5 | UserQuery | [RFC 4582] |
| 6 | UserStatus | [RFC 4582] |
| 7 | FloorQuery | [RFC 4582] |
| 8 | FloorStatus | [RFC 4582] |
| 9 | ChairAction | [RFC 4582] |
| 10 | ChairActionAck | [RFC 4582] |
| 11 | Hello | [RFC 4582] |
| 12 | HelloAck | [RFC 4582] |
| 13 | Error | [RFC 4582] |
+-------+--------------------+------------+
+-------+--------------------+------------+ | 値| 原始| 参照| +-------+--------------------+------------+ | 1 | FloorRequest| [RFC4582]| | 2 | FloorRelease| [RFC4582]| | 3 | FloorRequestQuery| [RFC4582]| | 4 | FloorRequestStatus| [RFC4582]| | 5 | UserQuery| [RFC4582]| | 6 | UserStatus| [RFC4582]| | 7 | FloorQuery| [RFC4582]| | 8 | FloorStatus| [RFC4582]| | 9 | ChairAction| [RFC4582]| | 10 | ChairActionAck| [RFC4582]| | 11 | こんにちは| [RFC4582]| | 12 | HelloAck| [RFC4582]| | 13 | 誤り| [RFC4582]| +-------+--------------------+------------+
Table 7: Initial values of the BFCP primitive subregistry
テーブル7: BFCPの原始の副登録の初期の値
15.3. Request Status Subregistry
15.3. 状態Subregistryを要求してください。
This section establishes the Request Status subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP request status shall be "Specification Required". For the purposes of this subregistry, the BFCP request status for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the request status.
このセクションはBFCP Parameters登録の下のRequest Status subregistryを設立します。 RFC2434[4]の用語に従って、BFCP要求状態への登録方針は「仕様が必要です」でしょう。 この副登録の目的のために、BFCPは、標準化過程RFCがIANA登録が要求されている状態を定義しなければならないよう要求します。 そのようなRFC MUSTは要求状態の値と意味論を指定します。
For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry.
それぞれのBFCP要求状態に、IANAは要求状態が定義されるRFCの値、意味、および参照を示します。 以下のテーブルはこの副登録の初期の値を含んでいます。
+-------+-----------+------------+
| Value | Status | Reference |
+-------+-----------+------------+
| 1 | Pending | [RFC 4582] |
| 2 | Accepted | [RFC 4582] |
| 3 | Granted | [RFC 4582] |
| 4 | Denied | [RFC 4582] |
| 5 | Cancelled | [RFC 4582] |
| 6 | Released | [RFC 4582] |
| 7 | Revoked | [RFC 4582] |
+-------+-----------+------------+
+-------+-----------+------------+ | 値| 状態| 参照| +-------+-----------+------------+ | 1 | 未定| [RFC4582]| | 2 | 受け入れます。| [RFC4582]| | 3 | 与えます。| [RFC4582]| | 4 | 否定されます。| [RFC4582]| | 5 | 取り消されます。| [RFC4582]| | 6 | リリースされます。| [RFC4582]| | 7 | 取り消されます。| [RFC4582]| +-------+-----------+------------+
Table 8: Initial values of the Request Status subregistry
テーブル8: Request Status subregistryの初期の値
Camarillo, et al. Standards Track [Page 61] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[61ページ]。
15.4. Error Code Subregistry
15.4. エラーコードSubregistry
This section establishes the Error Code subregistry under the BFCP Parameters registry. As per the terminology in RFC 2434 [4], the registration policy for BFCP error codes shall be "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it.
このセクションはBFCP Parameters登録の下のError Code subregistryを設立します。 RFC2434[4]の用語に従って、BFCPエラーコードのための登録方針は「仕様が必要です」でしょう。 この副登録の目的のために、標準化過程RFCはIANA登録が要求されているBFCPエラーコードを定義しなければなりません。 そのようなRFC MUSTはエラーコードの値と意味論、およびそれに当てはまるどんなError Specific Detailsも指定します。
For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
各BFCPに原始的です、IANAは原始が定義されるRFCの値、意味、および参照を示します。 以下のテーブルはこの副登録の初期の値を含んでいます。
+-------+-----------------------------------------------+------------+ | Value | Meaning | Reference | +-------+-----------------------------------------------+------------+ | 1 | Conference does not Exist | [RFC 4582] | | 2 | User does not Exist | [RFC 4582] | | 3 | Unknown Primitive | [RFC 4582] | | 4 | Unknown Mandatory Attribute | [RFC 4582] | | 5 | Unauthorized Operation | [RFC 4582] | | 6 | Invalid Floor ID | [RFC 4582] | | 7 | Floor Request ID Does Not Exist | [RFC 4582] | | 8 | You have Already Reached the Maximum Number | [RFC 4582] | | | of Ongoing Floor Requests for this Floor | | | 9 | Use TLS | [RFC 4582] | +-------+-----------------------------------------------+-----------+
+-------+-----------------------------------------------+------------+ | 値| 意味| 参照| +-------+-----------------------------------------------+------------+ | 1 | コンファレンスはどんなExistもしません。| [RFC4582]| | 2 | ユーザはどんなExistもしません。| [RFC4582]| | 3 | 未知の原始的です。| [RFC4582]| | 4 | 未知の義務的な属性| [RFC4582]| | 5 | 権限のない操作| [RFC4582]| | 6 | 無効のFloor ID| [RFC4582]| | 7 | 床の要求IDは存在していません。| [RFC4582]| | 8 | あなたはAlready Reached Maximum Numberを持っています。| [RFC4582]| | | このFloorのためのOngoing Floor Requestsについて| | | 9 | TLSを使用してください。| [RFC4582]| +-------+-----------------------------------------------+-----------+
Table 9: Initial Values of the Error Code subregistry
テーブル9: Error Code subregistryの初期のValues
16. Acknowledgements
16. 承認
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments.
XCON WGいす(アダム・ローチとアラン・ジョンストン)は、このドキュメントのための役に立つ考えを提供しました。 さらに、Xiaotaoウー、ポールKyzivat、ジョナサン・ローゼンバーグ、ミゲル・A.ガルシア-マーチン、メアリ・バーンズ、ベン・キャンベル、デイヴ・モーガン、およびオスカーノボは役に立つコメントを提供しました。
Camarillo, et al. Standards Track [Page 62] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[62ページ]。
17. References
17. 参照
17.1. Normative References
17.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[3] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[5]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[6]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[7] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
November 2006.
[7] キャマリロ、G.、「2進の床の制御プロトコル(BFCP)の流れのためのセッション記述プロトコル(SDP)形式」、RFC4583、2006年11月。
17.2. Informational References
17.2. 情報の参照
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376, February
2006.
2006年2月の[9]KoskelainenとP.とオットとJ.とSchulzrinne、H.とX.ウー、「床の制御プロトコルのための要件」RFC4376。
[10] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", Work in Progress, February 2005.
[10] 「集結された会議のための枠組みとデータモデル」というバーンズ、M.、およびC.ボールトンは進歩、2005年2月に働いています。
Camarillo, et al. Standards Track [Page 63] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[63ページ]。
Authors' Addresses
作者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Joerg Ott Helsinki University of Technology Department for Electrical and Communications Engineering Networking Laboratory PO Box 3000 02015 TKK Finland
技術部のヨルクオットヘルシンキ大学、電気、研究所私書箱3000 02015TKKフィンランドをネットワークでつなぐコミュニケーション工学
EMail: jo@netlab.hut.fi
メール: jo@netlab.hut.fi
Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK
キース・Drageルーセントテクノロジーズ風車ヒル・ビジネスパークスウィンドンウィルトシャー・SN5 6PPイギリス
EMail: drage@lucent.com
メール: drage@lucent.com
Camarillo, et al. Standards Track [Page 64] RFC 4582 BFCP November 2006
キャマリロ、他 規格はBFCP2006年11月にRFC4582を追跡します[64ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Camarillo, et al. Standards Track [Page 65]
キャマリロ、他 標準化過程[65ページ]
一覧
スポンサーリンク
