RFC 3080 The BEEP Core March 2001 Network Working Group M. Rose Request For Comments: 3080 Invisible Worlds, Inc. Category: Standards Track March 2001 ブロック拡張可能プロトコル この文書の状態 本文書はインターネットコミュニティにおけるインターネット標準化過程プロ トコルを定義している。本文書の内容を発展させるための議論および提案を求 める。本プロトコルの標準化段階と状態については、最新版の『インターネッ ト公式プロトコル標準』(STD 1)を参照していただきたい。本文書の配布は 制限されない。 著作権情報 Copyright (C) The Internet Society (2001). All Rights Reserved. あらまし 本文書はBEEP(Blocks Extensible Exchange Protocol) というコネクション指 向・非同期・相互通信の為の総称的なアプリケーションプロトコルの根幹につ いて書かれた物である。BEEPは並列で独立した通信を、単一のアプリケーショ ンでのユーザー識別の範囲内で許可し、テキストとバイナリの両方のメッセー ジをサポートする。 Rose Standard Track [Page 1] RFC 3080 The BEEP Core March 2001 1. はじめに この文書は、BEEPというコネクション指向・非同期式・相互通信の為のアプリ ケーションプロトコルについて書かれた物である。 BEEPの中心となる物は、ピア間に並列に独立して起こるメッセージの交換を許 可するメカニズムの枠組みである。メッセージは任意のMIME [1] コンテンツ であるが、たいていテキスト(XML [2] で構造化されている)のままである。 全てのメッセージの交換はチャンネル―――転送のセキュリティ・ユーザー認 証・データ交換のような、アプリケーションの適切に設計された側面へのバイ ンディング―――の中で行われる。 それぞれのチャンネルは関連づけられた「プロファイル」を持っており、文法 や交換されたメッセージの意味を定義している。BEEPの働きの中には、暗黙の 内にチャンネル管理の概念がある。BEEPのチャンネル管理のプロファイルには また、この文書は以下の事を定義する。 ・TLS [3] 転送セキュリティプロファイル、そして ・SASL [4] プロトコル群 他のデータ交換等に使われるようなプロファイルは、アプリケーションプロト コルの設計者によって定義される。 Rose Standard Track [Page 2] RFC 3080 The BEEP Core March 2001 2. BEEPの中核 BEEPのセッションは、転送サービスを基調とした上に構成される。独立した一 連の文書は、個々の転送がBEEPセッションを実現する方法について述べる。例 えば、[5] はBEEPセッションをTCP [6] の上に実現する方法を述べている。 セッションが確立された時、それぞれのBEEPピアは自身がサポートするプロフ ァイルを互いに通告しあう。その後、チャンネルを作成している間、クライア ントはチャンネルに対して1つかそれ以上の提案されただけのプロファイルを 提供する。もしサーバーがチャンネルを作成したなら、サーバーはプロファイ ルの1つを選んで、応答の中で返送する。他の場合は、サーバーは1つもプロフ ァイルを受領出来ない事を示し、チャンネルの作成を断る。 チャンネルの利用法は、以下の2つに分類される。 最初の調整: これらはBEEPセッションが確立した時の初期化(例: 転送のセキ ュリティを使用する為のネゴシエート)を行うプロファイルによって用いら れる。とはいえ、いくつかの相互通信は初期化の実行を必要とする事があ るので、これらのチャンネルはBEEPセッションの中で早い段階に活動を停 止し、チャンネルが有効な間引き続き留まり続ける。 連続的なチャンネル: これらはデータ交換をサポートするプロファイルによっ て使われる。一般的に、これらのチャンネルは最初の調整の為のチャンネ ルが静かになってから作られる。 ここで注意すべきなのは、特別な性質の為に、唯一の調整の為のチャンネルは いつでも確立されている可能性があるという事である。対照的に、BEEPは複数 のデータ交換のチャンネルが同時に使用される。 Rose Standard Track [Page 3] RFC 3080 The BEEP Core March 2001 2.1 ロール BEEPはP2Pであるが、ロールのコンテキスト(* 文脈?)中でピア同士でラベルを 付け合うのに都合が良い。ラベル付けは一度に行う。 ・BEEPセッションが確立した時、新しい接続を待っているピアはリスニングロ ールに入り、リスナに対して接続を確立している他のピアは初期化ロールに入 る。以下に示す例では、これらをそれぞれ "L:" と "I:" とする。 ・BEEPピアがクライアントを名乗ってデータ交換を始めると、同様に他のBEE Pピアはサーバーを名乗る。以下に示す例では、これらをそれぞれ "C:" と " S:" とする。 典型的に、サーバロールで活動しているBEEPピアはまたリスニングロールとし ても活動する。しかしながら、BEEPは本質的にピア・トゥ・ピアであり、その ような要求は存在しない。 2.1.1 データ交換の形式 BEEPは3種類のデータ交換を可能にしている。 MSG/RPY: クライアントはいくつかのタスクを行う為に "MSG" メッセージをサ ーバに送り、サーバはタスクを処理して "RPY" メッセージを返す。(肯定的な 応答を称する) MSG/ERR: クライアントが "MSG" メッセージを送り、サーバはどのタスクも処 理せずに "ERR" メッセージを返す。 (否定的な応答を称する) MSG/ANS: クライアントが "MSG" メッセージを送り、サーバーは、いくつかの タスクを処理する過程において、0個かそれ以上の "ANS" メッセージを返し、 タスクが完了した時には、返答の終了を示す "NUL" メッセージを送る。 最初の2つの形式は1対1のデータ交換であり、3番目の形式は1対多のデータ交 換である。 Rose Standard Track [Page 4] RFC 3080 The BEEP Core March 2001 2.2 メッセージとフレーム メッセージはMIMEの規則に従って出来ている。それに従って、それぞれのメッ セージは「エンティティヘッダ」で始まるだろう (MIME セクション3参照 [1]) 。もし無い場合、もしくは一部しか無い場合、以下のエンティティヘッダが与 えられる。 ・デフォルトの "Content-Type" は "application/octet-stream" である。 ・デフォルトの "Content-Transfer-Encoding" は "binary" である。 通常、メッセージは単一のフレームとして送信される。しかしながら、メッセ ージを複数のフレームに分割した方が都合が良かったり、それが必要になる事 もあるだろう (例: メッセージの一部を送信する準備が出来ている場合)。 それぞれのフレームはヘッダとペイロードとトレイラから成る。ヘッダとトレ イラは印字可能なASCII文字で表され、CRLFで終端する。ヘッダとトレイラの 間にはペイロードがあり、0以上のオクテットから成る。 例えば、ここに1つのフレームを含んだ、5行の120オクテットのメッセージが ある (各行はCRLFで終わる)。 C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: C: C: C: C: END この例の中で留意すべきは、連続したメッセージが単一のフレームとして表さ れている事である。 Rose Standard Track [Page 5] RFC 3080 The BEEP Core March 2001 2.2.1 フレームの文法 ABNF [7] によるフレームの文法を以下に示す。 frame = data / mapping data = header payload trailer header = msg / rpy / err / ans / nul msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF common = channel SP msgno SP more SP seqno SP size channel = 0..2147483647 msgno = 0..2147483647 more = "." / "*" seqno = 0..4294967295 size = 0..2147483647 ansno = 0..2147483647 payload = *OCTET trailer = "END" CR LF mapping = ;; each transport mapping may define additional frames Rose Standard Track [Page 6] RFC 3080 The BEEP Core March 2001 2.2.1.1 フレームヘッダ フレームのヘッダは3文字のキーワード("MSG", "RPY", "ERR", "ANS", "NUL" のうちのどれか)から成り、その後に0個以上のパラメタが続く。単一のスペ ース文字(10進数で32, " ")は、それぞれの要素を区切る。ヘッダはCRLFで終 わる。 チャンネル番号 ("channel") は非負の整数 (0..2147483647) である。 メッセージ番号 ("msgno") は非負の整数 (0..2147483647) で、同じチャンネ ルの中で応答を完全に受け取っていない、異なる全ての "MSG" メッセージ同 士で違う値を持つ。 連続指示記号 ("more": 10進数で42 "*" 10進数で46 "." のどちらか) は、こ のフレームがメッセージ中の最後のフレームであるかどうかを表す(2.2.1.2参 照)。 中間点("*"): 最低でも後1つのフレームが続く 完成("."): このフレームでメッセージが完成する シークエンス番号 ("seqno") は非負の整数 (0..4294967295) で、チャンネル に対応した、ペイロード中の最初のオクテットのシークエンス番号を示す。 ペイロードサイズ ("size") は非負の整数 (0..2147483647) で、ペイロード 中の正確なオクテット数を表す(ヘッダとトレイラは含まない)。 フレームは、以下に示すような空のペイロードを持つ事がある。 S: RPY 0 1 * 287 20 S: ... S: ... S: END S: RPY 0 1 . 307 0 S: END 応答番号 ("ansno") は非負の整数 (0..4294967295) で、メッセージの返答の 最中で、他の応答との間で一意でなくてはならない。 フレームには2種類のフレームがある。「データ」と「マッピング」である。 それぞれのマッピングの転送(2.5参照)は、独自のフレームを定義する。例え ば、[5] は SEQ フレームを定義している。この章の残りでは、データフレー ムについて議論する。 メッセージが複数のフレームに分割されて送られた時、同じチャンネル上での 他のフレームの介在無しに、これらのフレームは連続に送られなければならな Rose Standard Track [Page 7] RFC 3080 The BEEP Core March 2001 い。しかしながら、2つの例外がある。1つ目は、他のチャンネルのフレームの 割り込みに対する制限は無い。2つ目は、1対多のデータ交換では、複数の応答 が同時に同時に起こる可能性がある。それ故、"ANS" メッセージに対するフレ ームは、同じチャンネル上で交互に現れる可能性がある。応答番号はそのフレ ーム群の照合に使われる。 S: ANS 1 0 * 0 20 0 S: ... S: ... S: END S: ANS 1 0 * 20 20 1 S: ... S: ... S: END S: ANS 1 0 . 40 10 0 S: ... S: END 上に示す通り、2つの "ANS" メッセージが、チャンネル1であるメッセージ番 号0への応答に挟まっている。ここで注意すべきなのは、チャンネル上でそれ ぞれのフレームを送る為にシークエンス番号が上昇しており、シークエンス番 号はフレーム群内でのメッセージの送信から独立している事である。 不完全に形成されたフレームの為に、いくつかの規則がある。 ・ヘッダが "MSG", "RPY", "ERR", "ANS", "NUL" から始まっていない場合 ・ヘッダ中のパラメータが解決出来なかったり、無効である場合(例えば、文 法的に間違っているなど) ・チャンネル番号が既存のチャンネルを指していない場合 ・ヘッダが "MSG" から始まっており、メッセージ番号が、完全に受け取られ ている "MSG" メッセージを指しているが、応答が完全に送られていない場合 ・ヘッダが "MSG" から始まっておらず、メッセージ番号を参照する応答を既 に受け取っている場合(※未完) ・ヘッダが "MSG" から始まっておらず、メッセージ番号を参照するメッセー ジが送られていない場合(セッションを確立している最中は除く。2.3.1.1参照) ・ヘッダが "MSG", "RPY", "ERR", "ANS" から始まっており、参照するメッセ ージ番号のフレームが最低1つ受け取られており、フレームが3文字のキーワー ドから始まっており、直前に受け取ったフレームのメッセージ番号と一致して いない場合 Rose Standard Track [Page 8] RFC 3080 The BEEP Core March 2001 ・ヘッダが "NUL" から始まっており、参照するメッセージ番号のフレームが 最低1つ受け取られており、この応答の為の直前のフレームのキーワードが " ANS" で無い場合 ・同じチャンネルで受け取った直前のフレームの連続指示記号が中間点 ("*") で、そのメッセージ番号が今のフレームのメッセージ番号と一致していない 場合(2.2.1.2参照) ・シークエンス番号が、割り当てられたチャンネルの期待する番号と一致して いない場合 ・ヘッダが "NUL" から始まっており、連続指示記号が中間点 ("*") であるか、 ペイロードサイズが0でない場合 フレームが不完全に形成されている場合、セッションは応答を生成せずに終了 する。また診断事項をログに書き込む事を推奨する。 Rose Standard Track [Page 9] RFC 3080 The BEEP Core March 2001 2.2.1.2 フレームのペイロード フレームのペイロードは、0個以上のオクテットから成る。 全てのペイロード中のオクテットは、シークエンス番号が割り振られたそれぞ れのチャンネルに送られる。フレーム中のペイロード中のオクテットの番号付 けは、最初のペイロード中のオクテットに低い番号付けされ、続くペイロード 中のオクテットは連続して番号付けされる(チャンネルが作られた時、シーク エンス番号は最初のフレーム中の最初のペイロード中のオクテットに0を割り 当てる)。 実際のシークエンス番号の空間は無限大である。しかし非常に大きい 0..429 4967295(2**32 - 1) の範囲である。空間が無限大だというのは、全てのシー クエンス番号に関する計算が 2**32 を法とする計算だからである。この符号 無しの計算は、2**32 - 1 から 0 に再び循環するというシークエンス番号の 関係を維持している。シークエンス番号の算術的な特性についての議論は、[ 8]のセクション2から5までを参考にしてほしい。 フレームを受け取った時、そのフレームのシークエンス番号とペイロードサイ ズの合計は、4294967296(2**32)を法とし、次に受け取るフレームの最初のペ イロード中のオクテットに割り当てられた予測されるシークエンス番号を与え る。それに従って、フレームを受け取る時、シークエンス番号が現在のチャン ネルに対する予想される番号で無かった時、BEEPピアは同期を失っており、セ ッションは応答を生成せずに終了する。また診断事項をログに書き込む事を推 奨する。 Rose Standard Track [Page 10] RFC 3080 The BEEP Core March 2001 2.2.1.3 フレームのトレイラ フレームのトレイラは、"END" とそれに続くCRLFのペアから成る。 フレームを受け取った時、ペイロードの直後に続く文字列がトレイラと一致し ない場合、セッションは応答を生成せずに終了する。また診断事項をログに書 き込む事を推奨する。 Rose Standard Track [Page 11] RFC 3080 The BEEP Core March 2001 2.2.2 フレームの意味 それぞれのメッセージの意味はチャンネルに特有の物である。なのでチャンネ ルに割り当てられたプロファイルは以下に示す事柄を定義しなければならない。 ・初期化メッセージ。もしあれば、チャンネルの作成の間に交換する。 ・チャンネルのペイロード中で交換される可能性のあるメッセージ、及び、 ・これらのメッセージの意味。 プロファイルの登録のテンプレート(セクション5.1)はこの情報を整理してい る。 2.2.2.1 不完全に形成されたメッセージ プロファイルの様式を定義する時、テンプレートは不完全に形成された "MSG " メッセージをいかにして返信するかを明確にしなければならない。例えば、 チャンネル管理のプロファイルはエラーメッセージを含んだ否定的な返信を送 る(セクション2.3.1.5参照)。 不完全に形成された返信をチャンネル0が受け取ったらなら、セッションは応 答を生成せずに終了する。また診断事項をログに書き込む事を推奨する。 不完全に形成された返信を他のチャンネルが受け取ったなら、セクション2.3. 1.3の手続きを用いてチャンネルを閉じなければならない。 Rose Standard Track [Page 12] RFC 3080 The BEEP Core March 2001 2.3 チャンネル管理 BEEPセッションが開始した時は、チャンネル0のみが定義されており、チャン ネルの管理に使われている。セクション6.1にBEEPのチャンネル管理のプロフ ァイルの登録の事が含まれている。 チャンネル管理者はそれぞれのBEEPピアに、それぞれがサポートする物を通告 する事を許可し(セクション2.3.1.1参照)、このプロファイルのうちの一つの 場合をチャンネルに結びつけ(セクション2.3.1.2参照)、その後チャンネルを 閉じるかBEEPセッションを解放する(セクション2.3.1.3参照)。 BEEPピアは最低でも同時に257個のチャンネルを同時に対応すべきである。 Rose Standard Track [Page 13] RFC 3080 The BEEP Core March 2001 2.3.1 メッセージの意味 2.3.1.1 挨拶のメッセージ BEEPセッションが確立した時、それぞれのBEEPピアは自身の能力を知らせる。 その為に、メッセージ番号0の"greeting"要素を含んだ肯定的な応答を直接送 る。以下に例を示す。 L: I: L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END 留意すべきは、この例は、リスニングロール中のBEEPピアが自身の挨拶を送っ ている間、初期化ロール中のBEEPピアが待っている、という点を示していると いう事である --- これは挨拶の発表の影響である。事実上、双方のBEEPピア は独立して互いの返信を送信する。 "greeting"要素は2つの選択可能な属性("features" と "localize")と0個以上 の"profile"要素を持ち、(※以後未訳) ・"features"属性は、与えられたならば、1つ以上の機能のトークンを含み、 それぞれがBEEPピアがサポートするチャンネルが管理するプロファイルの付加 的な機能を示す。 ・"localize"属性は、与えられたならば、1つ以上の言語のトークンを含み、 それぞれが相手のBEEPピアが"close"や"error"要素が診断文を作成する時に使 う為に要求可能な言語タグを認識する。(トークンは最も望まれる物から最も 望まれない順に並べる。) ・"greeting"要素に含まれるおのおのの"profile"要素はプロファイルを認識 し、"profile"要素が"start"要素内に存在する事とは違い、"profile"要素の 内容は付加的な初期化メッセージを含まない可能性がある。 セクション5.2では付加的な機能のテンプレートの登録を定義する。 Rose Standard Track [Page 14] RFC 3080 The BEEP Core March 2001 2.3.1.2 "Start" メッセージ BEEPピアがチャンネルを作る時は、チャンネル0に "start" 要素を送る。以下 に例を示す。 C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: C: C: C: C: END "start" 要素は付加的な "number" 属性、付加的な "serverName" 属性、そし て1つ以上の "profile" 要素を持つ。 ・"number" 属性はチャンネル番号 (1..2147483647) を示し、以後のメッセー ジ内におけるチャンネルの識別に使われる。 ・"serverName" 属性は、任意の文字列で、このBEEPセッションに要求するサ ーバ名を示す。 ・それぞれの "profile" 要素は "start" メッセージを含む。"start" 要素は "uri" 属性と、付加的な "encoding" 属性と、任意の文字データを内容とし て持つ。 ・"uri" 属性は、厳密にプロファイルを識別する。 ・"encoding" 属性は、与えられたなら、"profile" 要素の内容が base64 で符号化された文字列であるかどうかを特定し、そして、 ・"profile" 要素の内容は、与えられたなら、4Kオクテット以下の長さで なければならず、チャンネルが作成され次第チャンネルの初期化メッセー ジを指定する。 チャンネルの作成を要求した時に、チャンネル番号の割り当てが重複する事を 避ける為に、初期化ロールで動作しているBEEPピアは正の奇数のみを使用する。 同様に、リスニングロールで動作しているBEEPピアは正の偶数のみを使用する。 最初に成功した "start" 要素を受け取ったBEEPピアの "serverName" 属性は、 BEEPセッションの存在時間の意味がある。"serverName" 属性が与えられた時、 BEEPピアは "serverName" として動作する事を決める。そうでない場合、"er ror" 要素を否定的な応答として送る。 BEEPピアが "start" 要素をチャンネル0で受け取った時、BEEPピアは提示され たプロファイルを審査し、チャンネルを作成するのにその中の1つを用いるか Rose Standard Track [Page 15] RFC 3080 The BEEP Core March 2001 を決定する。もしそうなれば、適切な "profile" 要素が肯定的な応答として 送られる。 チャンネルを作成している時、最初に成功した "start" 要素の "serverName " 属性の値は、設定情報を提供する為に参考にされる。例えば、TLS転送セキ ュリティプロファイルが開始した時のサーバ側の証明書の要求がある (セクシ ョン3.1)。 例えば、正常なチャンネルの作成はこのようになるであろう。 C: MSG 0 1 . 52 178 C: Content-Type: application/beep+xml C: C: C: C: C: C: END S: RPY 0 1 . 221 87 S: Content-Type: application/beep+xml S: S: S: END 同様に、正常でないチャンネルの作成はこのようになるであろう。 C: MSG 0 1 . 52 120 C: Content-Type: application/beep+xml C: C: C: C: C: END S: ERR 0 1 . 221 127 S: Content-Type: application/beep+xml S: S: number attribute S: in <start> element must be odd-valued 最後に、チャンネル作成中の初期化要素の交換の一例を示す。 C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: C: Rose Standard Track [Page 16] RFC 3080 The BEEP Core March 2001 C: ]]> C: C: C: END S: RPY 0 1 . 110 121 S: Content-Type: application/beep+xml S: S: S: ]]> S: Rose Standard Track [Page 17] RFC 3080 The BEEP Core March 2001 2.3.1.3 "Close" メッセージ BEEPピアがチャンネルを閉じようとする時、"close" 要素をチャンネル0に送 る。例えば、 C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: C: END "close" 要素は1つの "number" 属性、1つの "code" 属性、付加的な "xml:l ang" 属性、付加的な診断文である要素内容を持つ。 ・"number" 属性はチャンネル番号を示す。 ・"code" 属性はプログラムにとって意味がある3桁の数字の応答番号であ る。 ・"xml:lang" 属性は要素内容が書かれている言語を識別し(相手のBEEPピ アから送られてきた "greeting" 要素の "localize" 属性による値は、提 案ではあるが、命令ではない。)、 ・診断文(複数行の事もある)は、実装者、もしかしたら管理者にとって意 味があり、もしかしたら利用者にも意味がある。しかし、プログラムにと っては意味が無い。 ここで留意すべきは、診断文が与えられた時、 相手のBEEPピアが最初に選 択して示された言語が使われた場合に限り、"xml:lang" 属性は存在しない。 "number" 属性の値が0ならば、BEEPピアはBEEPセッションの解放を望む(セ クション2.4を参照)。-- それ以外の場合、"number" 属性の値は存在する チャンネルを参照しており、この節の残りを適用する。 BEEPピアは、全ての "MSG" メッセージを送った事により認識済みのチャン ネルに対して、いつでも "close" メッセージを送ってもよい。(認識は、 "MSG" メッセージを送り、相手のBEEPピアからの応答の最初のフレームを 受信されている事から成る。) "close" メッセージを送った後 "close" メッセージの応答を受け取るまで の間、BEEPピアはそれ以上の "MSG" メッセージを閉じかけているチャンネ ルに対して送ってはいけない。(応答は "error" メッセージで チャンネル を閉じる要求を却下するか、"ok" メッセージに続いてチャンネルが正常に 開始するかのどちらかである。) 重要な注意: チャンネルの閉鎖要求に対する肯定的な応答をが受け取られてい Rose Standard Track [Page 18] RFC 3080 The BEEP Core March 2001 る間は、BEEPピアはチャンネル上におけるどんな "MSG" メッセージでも処理 する用意がなければならない。 BEEPピアがチャンネルに対する "close" メッセージを受け取った時、その可 能性がある時はいつでも否定的な応答として "error" メッセージを送る事に よってチャンネル閉鎖の要求を拒否する。 それ以外の場合、チャンネル閉鎖の要求の承認をし、そして肯定的な応答とし て "ok" メッセージを送る前に: ・溜めているチャンネル上の "MSG" メッセージの送信を終了しなければな らない。 ・チャンネルに送り済みの未解決の "MSG" メッセージに対する完全な応答 を待たなければならない。 ・チャンネルで受け取った未解決の "MSG" メッセージへの完全な応答を送 り、これらの応答の最後のフレームがうまく送られる事を保証する。すな わち、 ・チャンネル間のメッセージの順序が保証される通信の対応付けの為に、 肯定的な応答として "ok" メッセージを送る前に応答を送らなければな らない。それ以外の場合は、 ・応答は送られなければならなく、続いて肯定的な応答として "ok" メ ッセージを送る前に潜在的な通信サービスによって認識される。 Rose Standard Track [Page 19] RFC 3080 The BEEP Core March 2001 簡潔に言えば、成功したチャンネルの閉鎖は以下のようになる。 C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: C: END S: RPY 0 2 . 392 46 S: Content-Type: application/beep+xml S: S: S: END 同様に、失敗したチャンネルの閉鎖は以下のようになる。 C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: C: END S: ERR 0 2 . 392 79 S: Content-Type: application/beep+xml S: S: still working S: END Rose Standard Track [Page 20] RFC 3080 The BEEP Core March 2001 2.3.1.4 "OK" メッセージ BEEPピアがチャンネルを閉じる事(または、BEEPセッションの解放)を了解した 時、肯定的な応答として中で"OK" 要素を返す。 "OK" 要素は属性や内容を持たない。 2.3.1.5 "Error" メッセージ BEEPピアがチャンネルの作成を断った時、否定的な応答の中として "error" 要素を返す。以下に例を示す。 I: MSG 0 1 . 52 115 I: Content-Type: application/beep+xml I: I: I: I: I: END L: ERR 0 1 . 221 105 L: Content-Type: application/beep+xml L: L: all requested profiles are L: unsupported ・"error" 要素は "code" 属性、付加的な "xml:lang" 属性、内容として 付加的な診断文を持つ。 ・"code" 属性は 3桁の数字で、プログラムにとって意味があるコードを返 す。(セクション8を参照) ・"xml:lang" 属性は要素内容が書かれている言語を識別し(相手のBEEPピ アから送られてきた "greeting" 要素の "localize" 属性による値は、提 案ではあるが、命令ではない。)、 ・診断文(複数行の事もある)は、実装者、もしかしたら管理者にとって意 味があり、もしかしたら利用者にも意味がある。しかし、プログラムにと っては意味が無い。 ここで留意すべきは、診断文が与えられた時、 相手のBEEPピアが最初に選択 して示された言語が使われた場合に限り、"xml:lang" 属性は存在しない。 さらに、BEEPピアは以下の時に "error" 要素を送る。 ・不完全に整形されたか、予想外の要素を含む "MSG" メッセージを受け取 った時。 Rose Standard Track [Page 21] RFC 3080 The BEEP Core March 2001 ・BEEPピアがチャンネルを閉じる事(または、BEEPセッションの解放)を尋 ねてきて、それを断る時。 ・BEEPセッションが確率され、BEEPピアがリスニングロールで活動をし、 (接続してきた)BEEPピアが利用できない時。(この場合、リスニングロール で活動しているBEEPは "greeting" 要素を送らない。) 最後に、双方のBEEPピアがセッションを終了し、双方のBEEPピアが診断エント リをログに記録する事が推奨される場合。 Rose Standard Track [Page 22] RFC 3080 The BEEP Core March 2001 2.4 セッションの確立と解放 BEEPセッションが確立された時、互いのBEEPピアはチャンネル0にメッセージ 番号0のメッセージを肯定的な応答として直接自分の可用性を示す。以下に例 を示す。 L: I: L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END 代わりに、リスニングロールで動作しているBEEPピアが利用出来ない場合、否 定的な応答を返す。以下に例を示す。 L: I: L: ERR 0 0 . 0 60 L: Content-Type: application/beep+xml L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END I: L: L: そして、初期化ロールで動作しているBEEPピアによる "greeting" 要素の送信 は無視される。双方のBEEPピアが診断エントリをログに記録する事が推奨され る。 ここで留意すべきは、これら両方の例は暗に初期化ロール中のBEEPピアが、リ スニングロール中のBEEPピアが挨拶(greeting)を送ってくるまで待っていると Rose Standard Track [Page 23] RFC 3080 The BEEP Core March 2001 いう事を含んでいる -- これは提示の結果である。実際には、両方のBEEPピア は独立して応答を送る。 BEEPピアがBEEPセッションを解放しようとする時、BEEPピアは 値が0の "num ber" 属性を伴った "close" 要素をチャンネル0に送る。他方のBEEPピアは肯 定的な応答として "ok" 要素を送信する事で自らの意欲を示す。 C: MSG 0 1 . 52 60 C: Content-Type: application/beep+xml C: C: C: END S: RPY 0 1 . 264 46 S: Content-Type: application/beep+xml S: S: S: END I: L: L: 代わりに、他方のBEEPピアがBEEPセッションの解放を望まない場合、やりとり は以下のようになる。 C: MSG 0 1 . 52 60 C: Content-Type: application/beep+xml C: C: C: END S: ERR 0 1 . 264 79 S: Content-Type: application/beep+xml S: S: still working S: END セッションの解放が辞退された場合、BEEPセッションは、なるべくなら終了し ないべきである。 Rose Standard Track [Page 24] RFC 3080 The BEEP Core March 2001 2.5 通信の対応付け 全ての通信の相互関係はセッションのコンテキスト -- 特定の通信サービス上 の対応付け -- の中で起こる。それに沿って、この文書は特定の通信サービス がいかにしてBEEPセッションを実現するかについて書かれた資料が、満たさな ければならない必須事項を定義する。 2.5.1 セッション管理 BEEPセッションはコネクション型である。割り当ての資料には以下の事が定義 されていなければならない。 ・いかにしてBEEPセッションが確立されるか。 ・いかにしてBEEPピアがリスニングロールで動いている事を識別されるか。 ・いかにしてBEEPピアが初期化ロールで動いている事を識別されるか。 ・いかにしてBEEPセッションが解放されるか。そして、 ・いかにしてBEEPセッションが終了されるか。 2.5.2 メッセージ交換 BEEPセッションはメッセージ型である。割り当ての資料には以下の事が定義さ れていなければならない。 ・いかにしてメッセージが確実に送信され、受信されるか。 ・いかにして同じチャンネル上のメッセージが、送信された物と同じ順番 で受信されるか。 ・いかにして異なるチャンネル上のメッセージが、順序づけ制約無しで送 られるか。 Rose Standard Track [Page 25] RFC 3080 The BEEP Core March 2001 2.6 非同期性 BEEPは、単一のチャンネルや別個のチャンネル間の、非同期的な相互通信に対 応している。この機能は(チャンネル内の)パイプライン通信や、(チャンネル 内の)並列通信を許している。 2.6.1 単一のチャンネル内部 クライアントロールで動作しているBEEPピアは、同一のチャンネル内において、 相手からの応答の受け取りを待たずに複数の "MSG" メッセージを送信しても よい。これは単一のチャンネルにおけるパイプライン通信を提供する。 サーバーロールで動作しているBEEPピアは、指定されたチャンネルに対する全 ての "MSG" メッセージを、受け取った順番で処理しなければならない。結論 として、BEEPピアは指定されたチャンネル上で "MSG" メッセージを受け取っ たら、受け取った順番のままで応答を返さなければならない。 ここで留意すべきは、1対多のデータ交換(セクション2.1.1参照)では、"MSG" メッセージへの返答は0個以上の "ANS" メッセージとそれに続く "NUL" メッ セージから成るという事である。この交換の方法では、"ANS" メッセージと、 それから成る応答は相互的である。サーバーロールで動作しているBEEPピアは "NUL" メッセージを作成する事によって、応答の最後を示す。その後、サー バはチャンネル上で次に受け取った "MSG" メッセージを処理するだろう。 2.6.2 異なるチャンネル間 クライアントロールで動作しているBEEPピアは、複数の "MSG" メッセージを 別々のチャンネルに対して、応答を待たずに送信してよい。それぞれのチャン ネルは独立して並列に処理を行う。 サーバーロールで動作しているBEEPピアは、別々のチャンネルで受け取った "MSG" メッセージをどの順番で選択して処理してもよい。結果として、特定の チャンネルに対する応答は、その応答と対応する "MSG" メッセージを受け取 ったのと同じ順番で生成されるとはいえ、別々のチャンネル上における応答の 順序にはなんら制約は無い。 Rose Standard Track [Page 26] RFC 3080 The BEEP Core March 2001 2.6.3 先制応答 サーバーロールで動作しているBEEPピアは、メッセージ中の最後の "MSG" フ レームを受け取る前に否定的な応答を送ってもよい。そうするならば、相手の BEEPピアは、それに続く "MSG" フレームや、最後までの "MSG" フレームを無 視する事を強いられる。 クライアントロールで動作しているBEEPピアが、メッセージの最後の "MSG" フレームを送信する前に否定的な応答を受け取ったなら、完成の連続指示記号 (".")とペイロードの長さが0の "MSG" フレームを送信する事が必要とされる。 2.6.4 干渉 個々のメッセージの処理が、他のメッセージに連鎖的な影響(チャンネルの内 外を問わず)を持っている場合、対応するプロファイルはこの挙動を定義すべ きである。例えば、プロファイルのメッセージの通信割り当てを変えるなどで ある。(※?) Rose Standard Track [Page 27] RFC 3080 The BEEP Core March 2001 2.7 ピア・トゥ・ピアの挙動 BEEPはピア・トゥ・ピアである。双方のピアは、この文書で定義されている全 てのメッセージをそれなりに受け取る用意をしなければならない。従って、ク ライアントロールでのみ動作する能力がある初期化中のBEEPピアは、上品にふ るまわねばならない。従って、全てのプロファイルは、予期しない "MSG" メ ッセージへの応答の為に、適切なエラーメッセージを提供しなければならない。 BEEPの性質がピア・トゥ・ピアである事の結果として、メッセージ番号は一定 方向に有効である。すなわち、初期化ロール中のBEEPピアによって送られた "MSG" メッセージ中のメッセージ番号は、リスニングロール中のBEEPピアによ って送られた "MSG" メッセージのメッセージ番号と関係が無い。 以下の2つのメッセージを例に示す。 I: MSG 0 1 . 52 120 I: Content-Type: application/beep+xml I: I: I: I: I: END L: MSG 0 1 . 221 116 L: Content-Type: application/beep+xml L: L: L: L: L: END チャンネル0に送った別のメッセージを参照する。 Rose Standard Track [Page 28] RFC 3080 The BEEP Core March 2001 3. 通信の安全保障 BEEPセッションが確立すると、プライバシーの考慮無しの平文通信が提供され る。従って、BEEPにおける通信の安全保障は初期化調整プロファイルを用いる 事によって成し遂げられる。 この文書は1つのプロファイルを定義する。 ・TLS バージョン1 [3] を基調とした、TLS通信安全保障プロファイル。 他のプロファイルが相互原理の上で定義・配置される可能性がある。ここで留 意すべきは、通信サービスと彼等の親密な関係のために、所定の通信安全保障 プロファイルは単一の通信割り当てに関連する傾向がある。(セクション2.5を 参照) チャンネルが通信安全保障付きで割り当てられた時、(※以降未訳) BEEPセッ ション上の全てのチャンネル(チャンネル0も含む)は閉じられる。その結果、 交渉課程の完了時には、その結果に関わらず、双方のBEEPピアによって新たな greeting が発行される。(交渉過程が失敗した場合、どちらかのBEEPピアが 代わりにセッションを終了してもよい。そして診断エントリをログに記録する 事が推奨される。) BEEPピアはプライバシーを使用中かどうかに基づいて異なった greeting を発 行する事を選択してもよい。以下に例を示す。 L: I: L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I: I: I: I: ]]> I: Rose Standard Track [Page 29] RFC 3080 The BEEP Core March 2001 I: I: END L: RPY 0 1 . 110 121 L: Content-Type: application/beep+xml L: L: L: ]]> L: L: END ... 通信の安全保障の交渉は成功した ... L: RPY 0 0 . 0 221 L: Content-Type: application/beep+xml L: L: L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END もちろん全てのBEEPピアが一意専心な訳ではない。 L: I: L: RPY 0 0 . 0 268 L: Content-Type: application/beep+xml L: L: L: L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END Rose Standard Track [Page 30] RFC 3080 The BEEP Core March 2001 I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I: I: I: I: ]]> I: I: I: END L: RPY 0 1 . 268 121 L: Content-Type: application/beep+xml L: L: L: ]]> L: L: END ... 通信の安全保障の交渉は失敗した ... L: RPY 0 0 . 0 268 L: Content-Type: application/beep+xml L: L: L: L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END Rose Standard Track [Page 31] RFC 3080 The BEEP Core March 2001 3.1 TLS 通信安全保障プロファイル セクション6.2にこのプロファイルの登録が入っている。 3.1.1 プロファイルの認識と初期化 TLS通信安全保障プロファイルは、チャンネル作成中の BEEPの "profile" 要 素の中で、以下の様に認識される。 http://iana.org/beep/TLS チャンネルを作成している最中、 "profile" 要素中のBEEPの "start" 要素は "ready" を含んでよい。チャンネルの作成が成功したら、対応する応答を送 る前に、BEEPピアは "ready" 要素を処理し、その応答の結果を応答に返す。 以下に例を示す。 C: MSG 0 1 . 52 158 C: Content-Type: application/beep+xml C: C: C: C: ]]> C: C: C: END S: RPY 0 1 . 110 121 S: Content-Type: application/beep+xml S: S: S: ]]> S: S: END ここで留意すべきは、カプセル化された操作が失敗する事が無ければ、チャン ネルが作成される事は可能だという事である。以下に例を示す。 C: MSG 0 1 . 52 173 C: Content-Type: application/beep+xml C: C: C: C: ]]> C: C: C: END S: RPY 0 1 . 110 193 Rose Standard Track [Page 32] RFC 3080 The BEEP Core March 2001 S: Content-Type: application/beep+xml S: S: S: version attribute S: poorly formed in <ready> element]]> S: S: END この場合、肯定的な応答が送られる(すなわちチャンネルの作成は成功する)が、 カプセル化された応答は何操作が失敗したのかの指摘を含んでいる。 3.1.2 メッセージの記法 セクション7.2にTLS通信安全保障プロファイルで使われるメッセージが定義し てある。 Rose Standard Track [Page 33] RFC 3080 The BEEP Core March 2001 3.1.3 メッセージの意味 3.1.3.1 Ready メッセージ "ready" 要素は付加的な "version" 属性を持ち、内容を持たない。 ・"version" 要素は(※以降未訳) BEEPピアが "ready" 要素を送る時、BEEPピアは対になる応答("proceed" か "error")を受け取るまで、下位の通信サービス上においてさらなるトラフィッ クを送信してはいけない。同様に、受信側のBEEPピアは、"ready" 要素を処理 する前に、未解決の応答が生成・送信されるまで待機しなければならない。 3.1.3.2 Proceed メッセージ "proceed" 要素は属性・内容を持たない。"proceed" 要素は "ready" 要素の 応答として送信される。 BEEPピアが "ready" 要素を受け取る時、BEEPピアは対になる応答を送るまで、 下位の通信サービス上においてさらなるトラフィックを送信してはいけない。 BEEPピアが通信安全保障の交渉を許可する事を決定したなら、BEEPピアは暗黙 のうちに全てのチャンネル(チャンネル0も含む)を閉じ、"proceed" 要素を送 り、通信安全保障の為の下位の交渉過程を待つ。 BEEPピアが "ready" 要素に対する応答の中の "proceed" 要素を受け取った時、 BEEPピアは暗黙のうちに全てのチャンネル(チャンネル0も含む)を閉じ、直接 通信安全保障の為の下位の交渉過程を開始する。 Rose Standard Track [Page 34] RFC 3080 The BEEP Core March 2001 4. ユーザー認証 BEEPセッションが確立した時、トレース情報無しの匿名のアクセスが提供され る。従って、BEEPにおける通信の安全保障は初期化調整プロファイルを用いる 事によって成し遂げられる。 この文書はSASL機構を基にした一連のプロファイルを定義する。 ・IANA SASLレジストリ [15] 中のおのおのの機構に対してプロファイルを 割り当てている。 他のプロファイルが相互原理の上で定義・配置される可能性がある。 どのチャンネル上でいつ認証が成功したとしても、認証の同一性はBEEPセッシ ョン上の全ての既存の、また今後作成されるチャンネルに対して更新する。さ らに、それ以上の認証の試みは許可されない。 ここで留意すべきは、通信の安全保障やユーザー認証にかかわらず、それぞれ のBEEPピアにとって認証は内的な問題である。従って、それぞれのピアは、認 証の証明書に基づく操作を制限する事を選んでもよい。(すなわち、許可され ていない操作はエラーコード530で却下される。)。 Rose Standard Track [Page 35] RFC 3080 The BEEP Core March 2001 4.1. SASLプロファイル群 セクション6.3にこのプロファイルの登録が入っている。 ここで留意すべきは、SASLはユーザー認証と通信の安全保障の両方を提供する 事ができるという事である。一度BEEPセッションの通信の安全保障の交渉が成 功したら、SASL安全保障レイヤーは交渉してはならない。同様に、一度任意の SASLの交渉が成功したなら、通信安全保障プロファイルは下位の交渉過程を開 始してはならない。 SASLの仕様書 [4] の Section 4は以下に示すプロトコルの定義によって提供 される類の情報を要求している。 サービス名: "beep" 初期化シーケンス: SASLメカニズムに対応したBEEPプロファイルを用いてチャ ンネルを作成する事で交換を開始する。クライアントによって送られた「 初期化応答」に対応する付加的なパラメータはチャンネル作成中に "blob " 要素に入れて運ばれる。 交換シーケンス: 「チャレンジ」と「応答」は "blob" 要素の交換の中で届け られる。"blob" 要素の "status" 属性は、サーバーの交換の正常な完了の 指示と、クライアントの交換中止の両方の目的に使われる。サーバーは交 換の失敗を "error" 要素を送る事によって示す。 安全保障レイヤーの交渉: 安全保障レイヤーが交渉を始める時、BEEPセッショ ン上の全てのチャンネル(チャンネル0を含む)は閉じられる。その結果、交 渉課程の完了時には、その結果に関わらず、双方のBEEPピアによって新た な greeting が発行される。 安全保障レイヤーが正常に交渉された場合、その交渉は、サーバーの正常 な完了応答をを終結するメッセージの直後に効力を発する。 認証同一性の使用: BEEPセッションの存続期間中の全てのチャンネルの為に、 この機能は有効にされている。 Rose Standard Track [Page 36] RFC 3080 The BEEP Core March 2001 4.1.1 プロファイルの認識と初期化 それぞれのIANAに登録されたSASLメカニズムは、以下の様に認識される。 http://iana.org/beep/SASL/mechanism "MECHANISM" の位置にはIANAによって割り当てられたメカニズム名のトークン が入る。 ここで留意すべきは、チャンネルの作成中に、BEEPピアは相手のピアに対して 複数のプロファイルを提供してもよいという事である。以下に例を示す。 C: MSG 0 1 . 52 178 C: Content-Type: application/beep+xml C: C: C: C: C: C: END S: RPY 0 1 . 221 87 S: Content-Type: application/beep+xml S: S: S: END チャンネルの作成中、BEEPの "start" 要素の中の対応する "profile" 要素は "blob" 要素を含んでよい。ここで留意すべきは、失敗の為のカプセル化した 操作が無ければ、チャンネルを作成する事は可能である。以下に例を示す。 C: MSG 0 1 . 52 183 C: Content-Type: application/beep+xml C: C: C: C: AGJsb2NrbWFzdGVy]]> C: C: C: END S: RPY 0 1 . 221 178 S: Content-Type: application/beep+xml S: S: S: authentication mechanism is S: too weak]]> S: Rose Standard Track [Page 37] RFC 3080 The BEEP Core March 2001 S: END この場合では、肯定的な応答が送られるが、カプセル化された応答は何故操作 が失敗したかを示唆している。 それ以外の場合、サーバーはチャレンジを送る(もしくは成功を知らせる)。以 下に例を示す。 C: MSG 0 1 . 52 183 C: Content-Type: application/beep+xml C: C: C: C: AGJsb2NrbWFzdGVy]]> C: C: C: END S: RPY 0 1 . 221 171 S: Content-Type: application/beep+xml S: S: S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ= ]]> S: S: END ここで留意すべきは、この例は暗黙の内にサーバーの応答の中の "blob" 要素 が2行に渡って現れている。-- これはRFCの整形の影響である。実際には、1行 で表す。 チャレンジを受け取ったなら、クライアントは応答し、別の応答を待つ。以下 に例を示す。 C: MSG 1 0 . 0 97 C: Content-Type: application/beep+xml C: C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n C: END S: RPY 1 0 . 0 66 S: Content-Type: application/beep+xml S: S: S: END もちろん、クライアントは "" を代わりに送る事に よって、認証過程を中断出来る。 Rose Standard Track [Page 38] RFC 3080 The BEEP Core March 2001 もう一つの方法として、サーバーはエラーとして応答を排除してもよい。以下 に例を示す。 C: MSG 1 0 . 0 97 C: Content-Type: application/beep+xml C: C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n C: END S: ERR 1 0 . 0 60 S: Content-Type: application/beep+xml S: S: S: END 最後に、SASLメカニズムにもよるが、初期化要素はチャンネルの作成中は一方 向的な交換をする可能性がある。以下に例を示す。 C: MSG 0 1 . 52 125 C: Content-Type: application/beep+xml C: C: C: C: C: END S: RPY 0 1 . 221 185 S: Content-Type: application/beep+xml S: S: S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 jaS5uZXQ+]]> S: S: END ここで留意すべきは、この例は暗黙の内にサーバーの応答の中の "blob" 要素 が2行に渡って現れている。-- これはRFCの整形の影響である。実際には、1行 で表す。 4.1.2 メッセージの文法 Section 7.3に、SASLの仲間の中でそれぞれのプロファイルに使われるメッセ ージを定義する。 ここで留意すべきは、多くのSASLメカニズムはバイナリデータを交換する為、 "blob" 要素の内容は常にbase64で符号化された文字列である事である。 Rose Standard Track [Page 39] RFC 3080 The BEEP Core March 2001 4.1.3 メッセージの意味 "blob" 要素は "status" 属性と、任意のオクテットを内容として持つ。 ・ "status" 属性は、与えられるなら、以下の3つのうちの1つの値を取る。 abort: クライアントによって使われ、認証過程を中断している事を示 す。 complete: サーバーによって使われ、交換が完了し、成功している事を 示す。 continue: クライアントとサーバーのどちらかによって使われ、それ以 外の場合を示す。 最後に、ここで留意すべきは「外的な認証」サービスと共に動作するSASLの「 外的な」メカニズムは、以下のうちの1つによって提供される。 ・ユーザー認証を提供出来る通信安全保障プロファイル(例えば、セクション 3.1)が接続の際に動作している。 ・下位で接続している、強力な認証を提供出来る通信サービス。(例えば、IP sec [12]) ・局所的に定義されている安全保障サービス。 認証が成功したら、2つの状態を保持しなければならない。 ・外的な認証サービスを動作状態にしなければならない。そして、 ・もしあるならば、外部の認証サービスによって提供される証明書で認証の同 一性を一貫しなければならない。(認証の同一性が無いならば、認証の同一 性は自動的に、外部の認証サービスによって提供された証明書から派生さ れる。) Rose Standard Track [Page 40] RFC 3080 The BEEP Core March 2001 5. 登録要項 5.1 プロフィールの登録要項 プロフィールが登録される時、以下の情報が提供される。 プロフィールの認識: 厳然にこのプロファイルを認識するURI [10] を記入 する。 チャンネル作成中のメッセージ交換: チャンネル作成中に交換されるであ ろうデータのタイプを記入する。 1対1の交換を開始するメッセージ: 交換が開始する時提供されるであろう データのタイプを記入する。 メッセージ中の肯定的な応答: 肯定的な応答の中で与えるであろうデータ のタイプを記入する。 メッセージ中の否定的な応答: 否定的な応答の中で与えるであろうデータ のタイプを記入する。 メッセージ中の1対多の交換: 1対多の交換の中で与えるであろうデータの タイプを記入する。 メッセージの文法: プロファイルによって交換されるデータのタイプの文 法を記入する。 メッセージの意味: プロファイルによって交換されるデータのタイプの意 味を記入する。 連絡先: プロファイルの著者の郵便と電子的な連絡先を記入する。 5.2 機能の登録事項 チャンネル管理プロファイルの為の機能を登録する時、以下の情報が提供され る。 機能の識別子: この機能を識別する文字列を記入する。機能がIANAに登録 されていなければ、機能の識別子は "x-" で始まらなければならない。 機能の意味: 機能の意味を記入する。 連絡先: 機能の著者の郵便と電子的な連絡先を記入する。 Rose Standard Track [Page 41] RFC 3080 The BEEP Core March 2001 6. 初期の登録要項 6.1. 登録要項: BEEPチャンネルの管理 プロフィールの認識: 規定されていない チャンネル作成中のメッセージ交換: 規定されていない 1対1の交換を開始するメッセージ: "start", "close" メッセージ中の肯定的な応答: "greeting", "profile", "ok" メッセージ中の否定的な応答: "error" メッセージ中の1対多の交換: 無し メッセージの文法: セクション7.1参照 メッセージの意味: セクション2.3.1参照 連絡先: この文書の『著者連絡先』の章を参照 6.2 登録要項: TLS通信安全保障プロファイル プロフィールの認識: http://iana.org/beep/TLS チャンネル作成中のメッセージ交換: "ready" 1対1の交換を開始するメッセージ: "ready" メッセージ中の肯定的な応答: "proceed" メッセージ中の否定的な応答: "error" メッセージ中の1対多の交換: 無し メッセージの文法: セクション7.2参照 メッセージの意味: セクション3.1.3参照 連絡先: この文書の『著者連絡先』の章を参照 6.3 登録要項: SASL系列のプロファイル プロフィールの認識: http://iana.org/beep/SASL/mechanism, "mechanis m" の位置にはIANAで登録されたトークンが入る Rose Standard Track [Page 42] RFC 3080 The BEEP Core March 2001 チャンネル作成中のメッセージ交換: "blob" 1対1の交換を開始するメッセージ: "blob" メッセージ中の肯定的な応答: "blob" メッセージ中の否定的な応答: "error" メッセージ中の1対多の交換: 無し メッセージの文法: セクション7.3参照 メッセージの意味: セクション4.1.3参照 連絡先: この文書の『著者連絡先』の章を参照 6.4 登録要項: application/beep+xml MIME メディアタイプ名: application MIME サブタイプ名: beep+xml 必要なパラメタ: 無し 付加的なパラメタ: charset (デフォルトは "UTF-8" [13]) エンコーディングに関する考察: このメディアタイプはバイナリの内容を 含んでいてもよい。従って、バイナリ転送が許可されていない通信上で 用いる時は、適切な符号化を適用しなければならない セキュリティに関する考察: それ自体には存在しない。しかしながら、こ のメディアタイプを扱うBEEPプロファイルは、関係するセキュリティに 関する考察について書かなければならない。 相互運用性に関する考察: 該当無し 刊行された仕様書: このメディアタイプは、XML 1.0 [2] の適切なサブセ ットである。2つの制限が課せられている。 1つ目に、5つの事前に定義された一般的な実体参照("&", "<", ">", "'", """) 以外の実体参照と、文字参照以外は提 供されない可能性がある。 2つ目に、"XML" 宣言(例えば、)や"DOCTYPE" 宣 言(例えば、)が提供されない可能性がある。(従って、 Rose Standard Track [Page 43] RFC 3080 The BEEP Core March 2001 UTF-8以外の文字セットが要求される場合、"charset" パラメタが提供 されなければならない。) 他の全ての XML 1.0 命令(例えば、CDATAブロック、命令の処理、など) は許可される。 このメディアタイプを使用するアプリケーション: XML 1.0 のサブセット を使う事を望むBEEPプロファイル 追加情報: 無し それ以上の情報への連絡: この文書の『著者連絡先』の章を参照 対象とする用法: 限定された使用 執筆・改変管理者: IESG Rose Standard Track [Page 44] RFC 3080 The BEEP Core March 2001 7. DTD 7.1 BEEPチャンネル管理のDTD Rose Standard Track [Page 45] RFC 3080 The BEEP Core March 2001 Rose Standard Track [Page 46] RFC 3080 The BEEP Core March 2001 7.2 TLS通信安全保障プロファイルのDTD 7.3 SASL系列プロファイルのDTD Rose Standard Track [Page 48] RFC 3080 The BEEP Core March 2001 8. 応答番号 番号 意味 ==== ======= 200 成功 421 サービスは使用出来ない 450 要求された行為は行わなかった (例: 既にロックされていた) 451 要求された行為は中断した 454 一時的な認証の失敗 501 一般的な文法間違い (例: 不完全に整形されたXML) 504 パラメタ中の文法間違い (例: 妥当でないXML) 530 認証が要求された 534 認証メカニズムが不完全である (例: 脆弱すぎる、シーケンスが枯渇した、等) 535 認証が失敗した 537 ユーザに権限が無い行為である 538 認証メカニズムは暗号化を要求している 550 要求された行為は行われなかった (例: 要求されたプロファイルに受け入れられる物が無かった) 553 パラメタが不正 554 処理が失敗した (例: ポリシー違反) Rose Standard Track [Page 49] RFC 3080 The BEEP Core March 2001 9. 安全保障に関する考察 BEEPのフレーム分割の構造は、それ自体攻撃からの防御手段を提供しない。し かしながら、思慮深い初期化調整プロファイルは、様々な度合いの保証を提供 する。 1. SASL系列のプロファイルの一つが使われた場合、[4] のセクション9のセキ ュリティに関する考察の議論を参照せよ。 2. TLS通信安全保障プロファイルが使われた場合(あるいはSASL安全保障レイ ヤーが確立された場合)、 1. 介入者が、安全保障関連のプロファイルをBEEPのgreetingを除去したり、 TLS安全保障プロファイルの "ready" 要素の否定的な応答を生成する可 能性がある。BEEPピアは、プライバシーにアクセス可能なレベルが無け れば、続行する事を拒否するように設定出来てもよい。 2. 介入者が、利用可能な弱い暗号スイートで、接続の切断を引き起こす可 能性がある。BEEPピアは、弱い暗号スイートを拒否するよう設定出来る ようにすべきである。 3. 介入者が、確立が成功する前に、プロトコルの交換を改ざんしてしまう 可能性がある。確立が完了した時には、BEEPピアは直前にキャッシュし ていたBEEPセッションに関する情報を破棄しなければならない。 異なる暗号スイートが、様々な安全保障レベルを提供しているが、管理者 は、どの暗号スイートを提供するかを注意深く選ぶべきである。 BEEPは本質的にピア・トゥ・ピアであるが、メッセージに割り当てられた仕事 を実行する前に、互いのチャンネルが、同一性の証明とBEEPセッションに割り 当てられたプライバシーレベルに基づいた、適切なアクセス権限を適用すべき である。 Rose Standard Track [Page 50] RFC 3080 The BEEP Core March 2001 参考文献 [1] Freed, N. and N. Borenstein, 『汎用インターネットメール拡張(MIM E) 第1部: インターネットメッセージ本体の書式』, RFC 2045, 1996年 11月 [2] World Wide Web Consortium, 『拡張可能なマーク付け言語(XML) 1.0』, W3C XML, 1998年2月, [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., P. Kocher, 『TLSプロトコル バージョン1.0』, RFC2246, 1999年1月 [4] Myers, J., 『シンプル認証とセキュリティ層 (SASL)』, RFC 2222, 1 997年10月 [5] Rose, M., 『TCP上におけるBEEPコアの割り当て』, RFC 3081, 2001年 3月 [6] Postel, J., 『転送制御プロトコル』, STD 7, RFC 793, 1981年9月 [7] Crocker, D. and P. Overell, 『文法仕様書の為の増強されたBNF』, RFC 2234, 1997年11月 [8] Elz, R. and R. Bush, 『シリアル番号演算』, RFC 1982, 1996年8月 [9] Alvestrand, H., 『言語識別の為のタグ』, RFC BCP 47, RFC 3066, 2 001年1月 [10] Berners-Lee, T., Fielding, R. and L. Masinter, 『統一書式資源識 別子(URI): 一般的構文』, RFC2396, 1998年8月 [11] Newman, C., 『使い捨てパスワード方式SASLメカニズム』, RFC 2444, 1998年10月 [12] Kent, S. and R. Atkinson, 『インターネットプロトコルの為の安全保 障構造』, RFC 2401, 1998年11月 [13] Yergeau, F., 『UTF-8, ISO 10646 を変換したフォーマット』, RFC 2 279, 1998年1月 [14] Linn, J., 『汎用的安全保障サービスAPI, バージョン2』, RFC 2078, 1997年1月 [15] Rose Standard Track [Page 51] RFC 3080 The BEEP Core March 2001 著者連絡先 Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US 電話番号: +1 707 789 3700 電子メール: mrose@invisible.net URI: http://invisible.net/ Rose Standard Track [Page 52] RFC 3080 The BEEP Core March 2001 附記A. 謝辞 著者は以下の方々に感謝の念を示す: David Clark, Dave Crocker, Steve De ering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Go odman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Lau rie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetr is, RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touc h, Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt。とりわ け、Dave Crockerはフレームを分割する機構について有用な提案を提供してく れた。 Rose Standard Track [Page 53] RFC 3080 The BEEP Core March 2001 附記B. IANAに関する考察 IANAは "beep" をGSSAPIサービス名として登録し、またその事をセクション4. 1にて述べた。 IANAは、以下のリストを維持している。 ・標準化過程にあるBEEPプロファイル、セクション5.1参照 ・標準化過程にあるチャンネル管理プロファイルの為の機能、セクション5.2 参照 それぞれのリストの為に、IESGはIANAが割り当てを行う前に規格書を批評する、 指名された専門家を割り当てる責任がある。標準化過程に無いBEEPプロファイ ルやチャンネル管理機能の開発者を尊重する為に、bxxpwg@invisible.netのメ ーリングリストがコメントを求める事に使われる事がある。 IANAはセクション6.2とセクション6.3に明示した登録要項を作成する。IANAが これらのプロファイルを登録する際には、URIの接頭辞としてIANAを使用し、 それぞれのプロファイルの登録要項と共にそれらのURIを関連させる事を推奨 する。(※?) Rose Standard Track [Page 54] RFC 3080 The BEEP Core March 2001 著作権表記全文 Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to o thers, and derivative works that comment on or otherwise explain it o r assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, p rovided that the above copyright notice and this paragraph are includ ed on all such copies and derivative works. However, this document i tself may not be modified in any way, such as by removing the copyrig ht notice or references to the Internet Society or other Internet org anizations, except as needed for the purpose of developing Internet s tandards in which case the procedures for copyrights defined in the I nternet Standards process must be followed, or as required to transla te it into languages other than English. The limited permissions granted above are perpetual and will not be r evoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING T ASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN W ILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABIL ITY OR FITNESS FOR A PARTICULAR PURPOSE. 謝辞 RFCの編集者の為の資金は現在Internet Societyによって提供されている。 Rose Standard Track [Page 55]