RFC 5841 - TCP Option to Denote Packet Mood
面白い部分だけを訳した。
概要
このドキュメントは、気分を表現する、新しいTCPオプションを提案するものである。
この文書について
本文書は、インターネットの標準規格ではな、情報提供の目的を持って公開せられる。
説明
パケットというビット列は、気の遠くなるほどのハードウェア上のレイヤーをくぐり抜けて、世界中を駆け巡る。而して、パケットは、気分を有せざるなり。彼らはデータをひとつのシステムから他へ運ぶの目的によりて作られたるものにして、感ずる能わざるものなり。
さりながら、ある特殊の状況においては、気分という情報を付加して可なり。
例えば、いつまでたってもACKが返ってこず、再送を余儀なくされたとき、パケットは、「怒り」の気分情報を付加されべきものである。また、なんども再送が起こるの時は、それ「イライラ」パケットなり。
これらの気分をパケットに付加するためには、TCPヘッダーに、TCPオプションを付け加えて、ASCII文字にて、一般に使われている、気分を表現する文字列を送信するべきである。
単純気分表現
一般的な気分を、パケットの気分として付加する。パケット自体は、気分を感ずることはない。この気分は、ユーザーの気分を反映したものである。
したがって、パケットが人間の気分を表現する場合は、ソースは人間となる。
以下の単純気分が提案されている。
ASCII Mood ===== ==== :) 幸せ :( 悲しい :D 興味津々 %( 混乱 :o もう飽きた :O こりゃ驚いた :P クソ :@ イライラ >:@ 怒り :| 無感情 ;) コソーリ >:) 邪悪利用例
パケットの気分は、二種類の状況で表現される。まず、TCPセッションの状態による気分。それと、もっと高位、高レイヤー上での状況を反映した気分である。
幸せパケット
健康的なパケットは、幸せなパケットである。もしACKパケットが、両者間において、10ミリ秒以内に返された場合、双方向で高速な転送能力があることを意味する。そして、再送が必要なく、すべてのACKが受信されたならば、後続するすべてのパケットは、「幸せ」とマークされるべきである（SHOULD）。
ロスがなく、低レイテンシーのパケットは、ユーザーをも、幸せにするものである。したがって、このパケットは、エンドユーザーエクスペリエンスをも、反映していることになる。
悲しいパケット
もし、あるセッションにおけるパケットの再送率が20%以上である場合、そのセッションは、善良なる一般パケット達にとっては、インターネットにおける世紀末、ヒャッハー状態であるといって差し支えない。
この状態を、「怒り」と混同してはならない。
興味津々パケット
テキストのジョークを運ぶすべてのパケットは、「興味津々」とマークされるべきである（SHOULD）。
例：
パケット「いいか、お前ら送信押すなよ！ 送信押すな！ 絶対に送信押すなよ！」
ユーザー「このデータ誰が運ぶ？」
パケット「いや、それはちょっと」
他のパケット群「俺がやる！」、「いや、俺がやるよ！」、「俺に決まってるだろ！」
パケット「あ、じゃあ俺も・・・」
一同「どうぞどうぞ」このような使い古されたジョークで笑うには、オバサンの笑い声などの、明示的なマークが必要である。
混乱パケット
パケットが混乱しているとはどういうことか。ネットワーク上には、パケットのロードバランスを調整しているハードウェアが存在する。このようなハードウェアを介した、ホスト間の通信には、レイテンシーが定まらず、out-of-orderなパケットが到着することが、起こりうる。
受信ホスト側が、out-of-orderパケットを受信したならば、返信するTCP ACKパケットは、混乱とマークされるべきである（SHOULD）。
また、アプリケーションの開発者は、パケットの送信するデータが、複雑怪奇な哲学上の疑問、例えば、「人生の意味とはなんぞや」であるとか、「宇宙における各人の立ち位置とは如何」、などを含む場合、混乱とマークするべきである（SHOULD）。
もう飽きたパケット
デビットやクレジット番号などのデータを含むパケットは、「もう飽きた」とマークされなければならない。（MUST）
多くの人は、RFCとはつまらないものであると考えている。RFCのテキストを含むパケットも、「もう飽きた」とマークしてもよい（MAY）。
電話帳のデータを送信するパケットは、「もう飽きた」とマークされなければならない（MUST）。
法的文書を含むパケット、あるいは、学術用語やラテン語を含むパケットは何でも、「もう飽きた」とマークされるべきである（SHOULD）。
こりゃ驚いたパケット
20ミリ秒も待ちぼうけたあげく、やってきたパケットが、out-of-orderパケットであったならば、万人の驚くところである。
パケットには誕生日はない。そこで、パケットが良きせぬエラーに見舞われた場合は、こりゃ驚いたとマークできる（can）。
つまり、ICMP到達不能メッセージを受信した場合、（おそらくは、ルーティング・ループや混雑により破棄されたなどの理由で）、後続するパケットはすべて、こりゃ驚いたとマークされるべきである（SHOULD）。
クソパケット
すべてのパケットは、セッションによって送信されるのではない。TCPセッションにおける、クライアント・サーバー間のランダムなkeepaliveなどだ。このようなランダムで遊び要素を含む通信は、クソとマークされるべきである（SHOULD）。
イライラパケット
一度以上再送されたパケットは、イライラとマークされるべきである（SHOULD）。
怒りパケット
再送されたパケットは、怒りとマークされるべきである（SHOULD）。
コソーリパケット
パケットが、とても賢い方法で使われている時、コソーリとマークされるべきである（SHOULD）。「賢い」とはなんであるかという事については、異論が多い。そこで、該当のパケットが賢いかどうか、複数の意見を参考にするべきである。
邪悪なパケット
TCPパケットが、モラルを認識するのは、困難である。例えば、「人生の意味」であるとか、「邪悪の明確な定義」であるとかなどだ。とはいえ、TCPベースのアプリケーションの開発者は、ある種の行動を、邪悪であると考えている。そのようなパケットは、邪悪とマークされるべきである（SHOULD）。
ある団体は、この気分を禁止しているかもしれない。IP ヘッダーのセキュリティフラグである、[RFC 3514]を禁止するのと、同じ理由である。
セキュリティに対する考察
悪意ある攻撃者によって、幸せ":)"パケットの口が、ねじ曲げられ、しかも、ウインクを付加されるかもしれない、";("。これは、送信者の意図した気分をねじ曲げるものである。
RFC4041、モラルに対する考察の項目も、欲しかったところだ。
No comments:
Post a Comment