UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 開始 2010年 4月 2日 / translation 02 April 2010 翻訳 2010年 4月 3日 / translation 03 April 2010 修正 2010年 4月 4日 / correction 04 April 2010 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc5841 を訳者( marimo@wdic.org )が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 Independent Submission R. Hay Request for Comments: 5841 W. Turkal Category: Informational Google Inc. ISSN: 2070-1721 1 April 2010 TCP Option to Denote Packet Mood [TCPオプションでのパケット気分の表現] 要約 この文書は、パケット気分を表現する新しいTCPオプションを提案する。 このメモの位置づけ この文書はインターネット標準化過程仕様ではない; 情報提供を目的として 公開されている。 これは、全ての他のRFCの流れから独立した、RFCシリーズに対する貢献であ る。RFC Editorはその裁量により、この文書の公開を選択し、実装や開発のた めの価値について声明を出すことはない。RFC Editorにより発行された文書 は、どのようなレベルのインターネット標準候補でもない; RFC 5741のセク ション2を参照せよ。 この文書の現在の状態、何らかの正誤表、及びどのようにフィードバックす るかについての情報は http://www.rfc-editor.org/info/rfc5841 で得られる 可能性がある。 著作権表示 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. この文書は、この文書の発行日について、BCP 78と、IFTF文書に関連する IETFの信頼の法的な規定 (http://trustee.ietf.org/license-info) の影響を 受けている。あなたは、この文書に関する権利や制限について述べる際、慎重 にこれらの文書を検証するべきである。 1. イントロダクション 世界中の無数の物理層ネットワーク上のビットストリームを人格化する試み で、我々はパケット気分を表わすためのTCPオプションを提案する [DSM-IV]。 パケットは感じることができない。それらはデータを一つのシステムからも う一つへ移す目的のために作成される。しかし、特定の状況で感情のいくつか の尺度が推測あるいは追加できることは明らかである。例えば、受信に対する ACKパケットが無い場合に再送される再送パケットは、「怒っている」パケット である、あるいは「イライラしている」パケットである、と説明することがで きる(例えばもしそれが最初の再送信でなければ)。どのようにしたらパケット 自身でこれらの感情を伝えることができるか。これはよく使われる「顔文字」 をASCII文字で符号化し、TCPヘッダーにTCPオプション[RFC793] を追加して対 処することで、パケット気分を伝送することができる。 1.1. 用語 この文書内のキーワード、MUST(必須)、MUST NOT(禁止)、REQUIRED(必要)、 SHALL(すること)、SHALL NOT(しない)、SHOULD(すべき)、SHOULD NOT(すべきで ない)、RECOMMENDED(推奨)、MAY(推定)、そしてOPTIONAL(オプション)は、 [RFC2119]で説明されるよう解釈される必要がある。 2. 構文 TCPのオプションは、1バイトの種類のフィールドがあり、続いて1バイトの長 さのフィールドがある[RFC793]。オプションが25(2000-12-18に開放された)を パケット気分を定義するために使用することが提案される。このオプションは 4または5バイトの長さの値を持つだろう。全ての単純な感情は、このメカニズ ムを介して2ないし3の7ビットのASCIIによって符号化されたキャラクターで表 現することができる。ここで定義されたものより複雑な気分を表現するために (例えば、パケットが幸せ、且つ驚いた場合)、複数の気分オプションがTCPヘッ ダーに出現することがある。 TCPヘッダーフォーマット 種類 長さ 意味 ---- -------- ------- 25 可変長 パケット気分 より詳しく: +--------+--------+--------+--------+ |00011001|00000100|00111010|00101001| +--------+--------+--------+--------+ 種類=25 長さ=4 ASCII : ASCII ) +--------+--------+--------+--------+--------+ |00011001|00000101|00111110|00111010|01000000| +--------+--------+--------+--------+--------+ 種類=25 長さ=5 ASCII > ACSII : ASCII @ 3. 単純な感情表現 パケット気分を表現するために、共通の顔文字が使用されることが提案され る。 パケットは、それ自体は「感じていない」。それらがタグ付け可能な感情 は、パケットを通して表現されたユーザーの気分の反映である。 パケットで表現される人間性は、完全に人間から供給される。 このためには、気分を伝える際に使われる単純な感情は、次のとおり提案さ れる。 ASCII 気分 ===== ==== :) 幸せ(Happy) :( 悲しい(Sad) :D 楽しんでいる(Amused) %( 混乱している(Confused) :o 退屈(Bored) :O 驚いている(Surprised) :P お馬鹿(Silly) :@ 欲求不満(Frustrated) >:@ 怒っている(Angry) :| 無関心(Apathetic) ;) 卑劣(Sneaky) >:) 悪意がある(Evil) 提案されたASCII文字符号化 バイナリー 10進 16進 文字 ========== ==== ==== ==== 010 0101 37 25 % 010 1000 40 28 ( 010 1001 41 29 ) 011 1010 58 3A : 011 1011 59 3B ; 011 1110 62 3E > 100 0000 64 40 @ 100 0100 68 44 D 100 1111 79 4F O 101 0000 80 50 P 110 1111 111 6F o 111 1100 124 7C | このRFCの目的のためには、7ビットのASCII符号化は顔文字を表現するのに充 分である。ASCII文字は、8ビットバイト単位で先頭ビットは常に0に設定して送 信される。 4. 使用時 パケット気分を表現するために二つの方法がある。一つは、TCPセッションの イベントに基づいて気分を推測することである。他の上位層の高位アクション (例えばペイロードの内容)から気分を得ることになる。 TCPセッション内の活動で推定されるパケットの'気分'は、トリガーイベント を監視しているホストで'気分'を設定【しなければならない】(MUST)。クライ アントは、フレームを送信する場合とACKを受信しない場合、再送フレームに気 分のTCP OPTIONのヘッダーを含むことができる【だろう】(MAY)。 気分を考慮する行動を示す全てのパケットには、推測されたTCP OPTIONを暗 黙の気分をパケットに加える【べきである】(SHOULD)。 アプリケーションは、パケットで表現されることによって定義された気分を 活用することができる。これは、クライアントから送信されるSYNパケットで表 現することができる。セッション内の全てのパケットは、気分のSYNパケットに 設定されたタグを付けることができる。しかし、これらはパケットごとのパ フォーマンスに対するコストとなる(5章「パフォーマンス考慮事項」を参照)。 各アプリケーションは、幸せ、悲しい、退屈、混乱している、 怒っている、 無関心、のように、パケットをマークするための前提条件を定義【しなければ ならない】(MUST)。これは、、そのような気分がどのように表現することがで きるかを定義し、これらの符号化されたラベルをいつ用いるかを開発者が決定 するための枠組みである。 4.1. 幸せなパケット 健康的なパケットは幸せなパケットであるとあなたは言うことができる。 もし、エンドトゥーエンドで、送信者から受信者のスタックまで10ミリ秒未 満でACKパケットが戻れば、これは、高速な双方向の能力を反映し、かつもし 再送が必要なく、かつ全てのACKが受信されれば、そのセッション内の全ての 後続のパケットは'幸せ'をマーク【するべきである】(SHOULD)。 損失がなく、低遅延パケットもまた、幸せなユーザーのためになる。パケッ トは、エンドユーザーの経験が反映される。 4.2. 悲しいパケット もし、すべてのパケットのセッションで送信される再送信が20%以上となった 場合、そのセッションは、全ての良いパケットが荒廃したインターネットの荒 れ地で迷って失われて悲しんでいると言っても差し支えない。 これは、再送パケットの「怒っている」のマークと混同すべきではない。こ のタグはパケット生命の驚異的な損失が発生したセッションで全てのフレーム に適用されるからである。 4.3. 楽しんでいるパケット ジョーク文書を運んでいるすべてのパケットは「楽しんでいる」とマークす る必要がある。 例: 1: Knock Knock 2: Who's there? 1: Impatient chicken 2: Impatient chi... 1: BAWK!!!! このような冗談がパケットペイロード内である場合、正直なところ、3年生を 存続する一つのノックノックジョークのみで楽しむことができるだろうか? 4.4. 混乱しているパケット パケットはいつ混乱するのか? 一つのパケットにつきロードバランシングを 遂行するネットワーク要素があって、もしエンドトゥーエンドで接しているパ スの間に非対称があれば、アウトオブオーダーパケットの配達が生じることに なる。 受信者ホストがアウトオブオーダーパケットを受け取った場合、混乱してい ることを、TCP ACKパケットにマークして送信者に送り返す【べきである】 (SHOULD)。 同様のことは、正しくない仮想LANセグメントに送られるか、あるいは宛先 を間違えられるパケットでも言える。受信者はパケットが混乱すると分かって いるかもしれないが、しかしもしそれがフレームの運命ならば、進入を知る術 はない。 それは言うものの、もしペイロードに一つの人生の意味や宇宙の中で一つの 場所を熟考するかのような複雑で哲学的な質問が含まれる場合などは、アプリ ケーション開発者は混乱しているとパケットをマーク【するべきである】 (SHOULD)。 4.5. 退屈なパケット パケットが、貸方、借方、等々の経理情報を運ぶような場合、'退屈'をマー ク【しなければならない】(MUST)。 多くの人々にとって、RFCは退屈だと言うことができる。RFCの文書を含むパ ケットは、'退屈'とマークされることが【あるだろう】(MAY)。 電話帳一覧表を含むパケットは、'退屈'をマーク【しなければならない】 (MUST)。 法的な注意書きやラテン語で何かを含むパケットは、'退屈'をマーク【するべ きである】(SHOULD)。 4.6. 驚いているパケット 誰が、20ミリ秒の混雑待ち行列で待っている間、セッションにおけるアウト オブオーダーパケットが驚かせることを愛するだろうか? パケットは誕生日を持っていないので、予期せぬエラー状態に遭遇する際、 驚いているようにパケットをマークできる。 それで、ICMP宛先到着不能メッセージが受信されている時(恐らくルーティン グループまたは混雑破棄による)、そのセッションにおける全ての以降のパケッ トが、驚いているようにマーク【されるべきである】(SHOULD)。 4.7. お馬鹿なパケット 全てのパケットがセッションの一部として送られるわけではない。システム 間の機知の応答がクライアントとサーバーとして接続したように、TCPセッショ ン中のランダムなキープアライブが設置される【かもしれない】(MAY)。このよ うな、ランダムにも遊び心がある交換には、お馬鹿さんとしてマーク【される べきである】(SHOULD)。 4.8. 欲求不満なパケット 二回以上再送信されるパケットは、欲求不満をマーク【するべきである】 (SHOULD)。 4.9. 怒っているパケット 再送信されるパケットは、怒っているとしてマーク【するべきである】 (SHOULD)。 4.10. 無関心なパケット 接続されたシステムにRSTパケットを送る時、受信者が自分のシステムが以降 何が起きても気にしないことを知るせるため、パケットは無関心であるとマー クされるべきである。 4.11. 卑劣なパケット パケットが特に巧妙な方法で使用されるとき、それは卑劣であるとしてマー ク【されるべきである】(SHOULD)。「巧妙な」ことはかなり主観的なため、そ れが巧妙であるということを確認するためには、いくつかの意見を得ることが 賢明である。 4.12. 悪意があるパケット 人生の意義のような、より高度に道徳的な困惑について明察する時や、また は、何が「悪」を定義し、そしてそのような性格描写が誰の遠近画法から作ら れているのか、といった難しいTCPパケットのために。しかし、それらの世界の 特定のレンズ越しに見られると、TCPベースのアプリケーション開発者は、いく つかの活動は悪意があるとみなすことを選ぶ【かもしれない】(MAY)。その時、 パケットは悪意があるとマーク【すべきである】(SHOULD)。 一部の組織では、ミッションステートメントにおいて、この気分の使用が禁 じられている。これはまた、同様の理由で [RFC3514] で説明されたIPヘッダー の中のセキュリティフラグを使用するのを禁止するだろう。 5. パフォーマンス考慮事項 TCPヘッダーに拡張を追加するにおいて、コストがある。TCP拡張を使用する と、ASCII符号化された気分の分だけ、データペイロードにおいてパケットで利 用可能なMSS(最大セグメントサイズ)は損なわれるだろう。もしTCPヘッダーが 20バイト以上なら、拡張バイトをフレームのペイロードで使うことは出来ない だろう。 パケット気分拡張を使用する際は、この1パケットあたりに増加するオーバー ヘッドを考慮するべきである。 6. セキュリティ対策 0と1の数が同じASCII文字を置換した場合、16ビットの値としてのTCPチェッ クサムは、誤解される恐れがある。幸せ ":)" は、悪意のある攻撃者が顔をし かめて、ウインク ";(" を使用して置き換えることができる。これは送信者の 意図した気分を受信者に誤って伝えるかもしれない。 7. 関連する作業 このドキュメントは、感覚のあるネットワークスタックを造ろうとしない。 ただしこのフレームワークは、感覚のあるスタックの感情を表現するのに使用 できる。もしそれが起こるなら、ネットワーク心理学者という新しい技術職階 が生まれるだろう。誰か、新しい仕事は好きじゃない? :) 8. IANAの考慮 この作業が標準化される場合、IANAは3章で説明されるとおり正式に25の値を 割り当てることが要求される。追加の気分や絵文字の表現は、IESGの承認また は標準化過程が必要になる [RFC5226]。 9. 参考資料 [DSM-IV] "Diagnostic and Statistical Manual of Mental Disorders (DSM)", http://www.psychiatryonline.com/ resourceTOC.aspx?resourceID=1. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. 著者のアドレス Richard Hay Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: rhay@google.com Warren Turkal Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: turkal@google.com Hay & Turkal Informational