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
Abstract
抽象
This document proposes a new TCP option to denote packet mood.
この文書では、パケットの気分を表すために、新しいTCPオプションを提案しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5841.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5841で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
In an attempt to anthropomorphize the bit streams on countless physical layer networks throughout the world, we propose a TCP option to express packet mood [DSM-IV].
世界中で数え切れないほどの物理層ネットワーク上のビットストリームを擬人化する試みで、我々はパケット気分[DSM-IV]を表現するためのTCPオプションを提案します。
Packets cannot feel. They are created for the purpose of moving data from one system to another. However, it is clear that in specific situations some measure of emotion can be inferred or added. For instance, a packet that is retransmitted to resend data for a packet for which no ACK was received could be described as an 'angry' packet, or a 'frustrated' packet (if it is not the first retransmission for instance). So how can these kinds of feelings be conveyed in the packets themselves. This can be addressed by adding TCP Options [RFC793] to the TCP header, using ASCII characters that encode commonly used "emoticons" to convey packet mood.
パケットは感じることができません。彼らは、あるシステムから別のシステムにデータを移動する目的で作成されます。しかし、特定の状況で感情のいくつかの尺度が推測または追加することができることは明らかです。 （これは、例えば最初の再送信でない場合）、例えば、全くACKを受信しなかったためにパケットのデータを再送するために再送されるパケットは、「怒り」パケットまたは「不満」パケットとして説明することができます。それでは、どのような感情のこれらの種類は、パケット自身に搬送することができます。これは、一般的にパケット気分を伝えるために、「顔文字」を使用してエンコードASCII文字を使用して、TCPヘッダにTCPオプション[RFC793]を追加することによって対処することができます。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
A TCP Option has a 1-byte kind field, followed by a 1-byte length field [RFC793]. It is proposed that option 25 (released 2000-12-18) be used to define packet mood. This option would have a length value of 4 or 5 bytes. All the simple emotions described as expressible via this mechanism can be displayed with two or three 7-bit, ASCII-encoded characters. Multiple mood options may appear in a TCP header, so as to express more complex moods than those defined here (for instance if a packet were happy and surprised).
TCPオプションは、[RFC793] 1バイトの長さフィールドに続く1バイトの種類のフィールドを、有しています。 （2000年12月18日リリース）オプション25は、パケット気分を定義するために使用することが提案されています。このオプションは、4または5バイトの長さの値を持っているでしょう。この機構を介して表現できるように記載された全ての単純な感情は、2つまたは3つの7ビットのASCII符号化された文字で表示することができます。ここで定義されたものよりも複雑な気分を表現するように、（パケットが幸せと驚きであった場合、例えば）複数のムードオプションは、TCPヘッダーに表示されることがあります。
TCP Header Format
TCPヘッダー形式
Kind Length Meaning
---- -------- -------
25 Variable Packet Mood
In more detail:
さらに詳細に：
+--------+--------+--------+--------+
|00011001|00000100|00111010|00101001|
+--------+--------+--------+--------+
Kind=25 Length=4 ASCII : ASCII )
+--------+--------+--------+--------+--------+
|00011001|00000101|00111110|00111010|01000000|
+--------+--------+--------+--------+--------+
Kind=25 Length=5 ASCII > ACSII : ASCII @
It is proposed that common emoticons be used to denote packet mood. Packets do not "feel" per se. The emotions they could be tagged with are a reflection of the user mood expressed through packets.
一般的な顔文字はパケット気分を表すために使用することが提案されています。パケットは、それ自体が「感じる」はありません。彼らはでタグ付けすることができた感情は、パケットを通して表現ユーザーの気分を反映しています。
So the humanity expressed in a packet would be entirely sourced from humans.
だから、パケットで表現人類は完全に人間から供給されるだろう。
To this end, it is proposed that simple emotions be used convey mood as follows.
そのためには、次のように使用することの単純な感情が気分を伝えることが提案されています。
ASCII Mood ===== ==== :) Happy :( Sad :D Amused %( Confused :o Bored :O Surprised :P Silly :@ Frustrated >:@ Angry :| Apathetic ;) Sneaky >:) Evil
ASCIIのムード===== ==== :)ハッピー:(悲しい：D面白がっ％の（混乱：O退屈：O驚い：P愚か：イライラ@>：怒っている@：|無関心;）卑劣> :)悪
Proposed ASCII character encoding
提案されたASCII文字エンコーディング
Binary Dec Hex Character
======== === === =========
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 |
For the purposes of this RFC, 7-bit ASCII encoding is sufficient for representing emoticons. The ASCII characters will be sent in 8-bit bytes with the leading bit always set to 0.
このRFCの目的のために、7ビットのASCII符号化は、顔文字を表現するのに十分です。 ASCII文字は常に0に設定先頭ビットと8ビット・バイトで送信されます。
There are two ways to denote packet mood. One is to infer the mood based on an event in the TCP session. The other is to derive mood from a higher-order action at a higher layer (subject matter of payload for instance).
パケット気分を表すには二つの方法があります。一つは、TCPセッションでのイベントに基づいて気分を推測することです。もう一つは、上位層（例えば、ペイロードの主題）における高次作用から気分を導出することです。
For packets where the 'mood' is inferred from activity within the TCP session, the 'mood' MUST be set by the host that is watching for the trigger event. If a client sends a frame and receives no ACK, then the retransmitted frame MAY contain the TCP OPTION header with a mood set.
「気分」がTCPセッション内のアクティビティから推測されるパケットの場合、「気分は」トリガイベントを監視しているホストで設定しなければなりません。クライアントがフレームを送信し、ACKを受信できない場合には、再送されたフレームは、気分がセットされたTCPオプションヘッダを含むかもしれません。
Any packet that exhibits behavior that allows for mood to be inferred SHOULD add the TCP OPTION to the packets with the implied mood.
推論する気分を可能挙動を示す任意のパケットは暗黙の気分を伴うパケットにTCPオプションを追加する必要があります。
Applications can take advantage of the defined moods by expressing them in the packets. This can be done in the SYN packet sent from the client. All packets in the session can be then tagged with the mood set in the SYN packet, but this would have a per-packet performance cost (see Section 5, "Performance Considerations").
アプリケーションは、パケットでそれらを表現することによって定義された気分を活用することができます。これは、クライアントから送信されたSYNパケットで行うことができます。セッション内のすべてのパケットは、SYNパケットに設定気分でタグ付けすることができますが、これは（第5章、「パフォーマンスの考慮事項」を参照してください）パケットごとのパフォーマンスコストを持っているでしょう。
Each application MUST define the preconditions for marking packets as happy, sad, bored, confused, angry, apathetic, and so on. This is a framework for defining how such moods can be expressed, but it is up to the developers to determine when to apply these encoded labels.
各アプリケーションはように、幸せ、悲しい、退屈、混乱、怒り、無関心、およびとしてパケットをマーキングするための前提条件を定義しなければなりません。これは、気分を表現することができる方法を定義するためのフレームワークであり、それは、これらの符号化されたラベルを適用する時を決定するまで開発することです。
Healthy packets are happy packets you could say. If the ACK packets return within <10 ms end-to-end from a sender's stack to a receiver's stack and back again, this would reflect high-speed bidirectional capability, and if no retransmits are required and all ACKs are received, all subsequent packets in that session SHOULD be marked as 'happy'.
健康的なパケットは、あなたが言うことができる幸せなパケットです。 ACKパケットが<10ミリ秒以内に戻ると再び受信機のスタックに送信者のスタックからのエンドエンドと、これは高速双方向性を反映することになる、と何の再送を必要としないとされている場合は、すべてのACKは、後続のすべてのパケットを受信していますそのセッションで「幸せ」としてマークする必要があります。
No loss, low-latency packets also makes for happy users. So the packet would be reflecting the end-user experience.
いかなる損失、低遅延パケットも幸せなユーザーのために行うものではありません。だから、パケットは、エンドユーザーの体験を反映されるだろう。
If retransmission rates achieve greater than 20% of all packets sent in a session, it is fair to say the session can be in mourning for all of the good packets lost in the senseless wasteland of the wild Internet.
再送率はセッション中に送信されるすべてのパケットの20％以上を達成した場合、セッションが野生のインターネットの無意味な荒れ地で失わ良いのすべてのパケットのために喪にすることができると言うために公平です。
This should not be confused with retransmitted packets marked as 'angry' since this tag would apply to all frames in the session numbed by the staggering loss of packet life.
このタグは、パケットの生活の驚異的損失によって麻痺セッション内のすべてのフレームに適用されるので、これは「怒り」としてマークされ再送パケットと混同してはなりません。
Any packet that is carrying a text joke SHOULD be marked as 'amused'.
テキスト冗談を運んでいる任意のパケットは、「面白がって」としてマークする必要があります。
Example:
例：
1: Knock Knock 2: Who's there? 1: Impatient chicken 2: Impatient chi... 1: BAWK!!!!
1：2をノックノック：誰がそこですか？ 1：せっかち鶏肉2：せっかちカイ... 1：BAWK !!!!
If such a joke is in the packet payload then, honestly, how can you not be amused by one of the only knock-knock jokes that survives the 3rd grade?
そのようなジョークは、パケットのペイロードにある場合は、正直に、あなたはどのように3年生を生き残る唯一のノックノックジョークの一つで楽しませすることはできませんか？
When is a packet confused? There are network elements that perform per-packet load balancing, and if there are asymmetries in the latencies between end-to-end paths, out-of-order packet delivery can occur.
ときにパケットが混乱していますか？そこにパケットごとのロードバランシングを行うネットワーク要素であり、エンドツーエンドのパス間待ち時間に非対称性がある場合、アウトオブオーダーパケット配信が発生する可能性があります。
When a receiver host gets out-of-order packets, it SHOULD mark TCP ACK packets sent back to the sender as confused.
受信ホストは、アウトオブオーダーパケットを受け取ると、それは同様に混乱送信者に返送されたTCP ACKパケットをマークすべきです。
The same can be said for packets that are sent to incorrect VLAN segments or are misdirected. The receivers might be aware that the packet is confused, but there is no way to know at ingress if that will be the fate of the frame.
同じことは、誤ったVLANセグメントに送信されるか、または誤っされているパケットのために言うことができます。受信機は、パケットが混乱していることに注意してくださいかもしれないが、それは、フレームの運命になる場合入口で知る方法はありません。
That being said, application developers SHOULD mark packets as confused if the payload contains complex philosophical questions that make one ponder the meaning of life and one's place in the universe.
ペイロードは1が人生の意味や宇宙での自分の場所を熟考作る複雑な哲学的な質問が含まれている場合、それは言われて、アプリケーション開発者は混乱してパケットをマークすべきです。
Packets carrying accounting data with debits, credits, and so on MUST be marked as 'bored'.
借方と会計データを搬送するパケット、クレジット、というように「退屈」としてマークする必要があります。
It could be said that many people consider RFCs boring. Packets containing RFC text MAY be marked as 'bored'.
多くの人が退屈RFCを検討していると言うことができました。 RFCテキストを含むパケットは、「退屈」としてマークされることがあります。
Packets with phone book listings MUST be marked 'bored'.
電話帳リストを持つパケットは、「退屈」とマークされなければなりません。
Packets containing legal disclaimers and anything in Latin SHOULD be marked 'bored'.
ラテン語で免責と何かを含むパケットは、「退屈」マークする必要があります。
Who doesn't love when the out-of-order packets in your session surprise you while waiting in a congested queue for 20 ms?
20msの混雑キュー内で待機している間は誰があなたのセッション驚きのあなたでアウトオブオーダーパケットを愛していないのですか？
Packets do not have birthdays, so packets can be marked as surprised when they encounter unexpected error conditions.
パケットは、パケットが、彼らが予期しないエラー条件が発生した場合など、びっくりマークすることができるので、誕生日を持っていません。
So when ICMP destination unreachable messages are received (perhaps due to a routing loop or congestion discards), all subsequent packets in that session SHOULD be marked as surprised.
ICMP宛先到達不能メッセージが（おそらくルーティン又は輻輳廃棄に）受信されたときに、そのセッション内のすべての後続のパケットは、のように驚いマークする必要があります。
Not all packets are sent as part of a session. Random keepalives during a TCP session MAY be set up as a repartee between systems connected as client and server. Such random and even playful interchanges SHOULD be marked as silly.
すべてのパケットは、セッションの一部として送信されるわけではありません。 TCPセッション中にランダムキープアライブは、クライアントとサーバと接続されたシステム間の機智として設定することができます。このようにもランダムと遊び心のインターチェンジは愚かとしてマークする必要があります。
Packets that are retransmitted more than once SHOULD be marked as frustrated.
複数回再送信されたパケットは、として不満をマークする必要があります。
Packets that are retransmitted SHOULD be marked as angry.
再送されたパケットは怒ったとしてマークする必要があります。
When sending a RST packet to a connected system, the packet should be marked as apathetic so that the receiver knows that your system does not care what happens after that.
接続されたシステムにRSTパケットを送信すると、受信機が、あなたのシステムが、その後何が起こるか気にしないことを知っているように、パケットは、無関心としてマークする必要があります。
When a packet is used in a particularly clever way, it SHOULD be marked as sneaky. What is "clever" is rather subjective, so it would be prudent to get a few opinions about a particular use to make sure that it is clever.
パケットは特に巧妙な方法で使用される場合、それは卑劣としてマークする必要があります。どのような「賢い」であることはかなり主観的であるので、それが賢いであることを確認するために、特定の使用についていくつかの意見を取得するのが賢明だろう。
It is hard for a TCP packet to discern higher moral quandaries like the meaning of life or what exactly defines 'evil' and from whose perspective such a characterization is being made. However, developers of TCP-based applications MAY choose to see some activities as evil when viewed through their particular lens of the world. At that point, they SHOULD mark packets as evil.
TCPパケットが視点な特性評価がなされている人生の意味や、まさに「悪」を定義してからのような高い道徳的なquandariesを識別することは困難です。しかし、TCPベースのアプリケーションの開発者は、世界の彼らの特定のレンズを通して見たときに悪としていくつかの活動を見るために選ぶかもしれません。その時点で、彼らは悪のようにパケットをマークすべきです。
Some organizations are prohibited from using this mood by mission statement. This would also prohibit using the security flag in the IP header described in [RFC3514] for the same reasons.
一部の組織は、ミッションステートメントによって、このムードを使用してから禁止されています。これはまた、同じ理由から、[RFC3514]に記載のIPヘッダ内のセキュリティフラグを使用禁止になります。
Adding extensions to the TCP header has a cost. Using TCP extensions with the ASCII-encoded mood of the packet would detract from the available MSS usable for data payload. If the TCP header is more than 20 bytes, then the extra bytes would be unavailable for use in the payload of the frame.
TCPヘッダに拡張を追加するとコストがかかります。パケットのASCIIでエンコードされた気分でTCP拡張を使用すると、データペイロードに使用できる利用可能MSSを損なうだろう。 TCPヘッダは、20以上のバイトである場合、余分なバイトは、フレームのペイロードに使用できなくなるであろう。
This added per-packet overhead should be considered when using packet mood extensions.
パケット気分拡張を使用している場合、この追加パケットごとのオーバーヘッドを考慮すべきです。
The TCP checksum, as a 16-bit value, could be mistaken if ASCII characters with the same number of zeros and ones were substituted out. A happy ":)" could be replaced with a frown by a malicious attacker, by using a winking eye ";(". This could misrepresent the intended mood of the sender to the receiver.
0と1の同じ番号のASCII文字が出て置換された場合、TCPチェックサムは、16ビット値として、誤解される可能性があります。 「;（」幸せ「が:)」ウインクアイを使用することにより、悪意のある攻撃者が顔をしかめで置き換えることができる。これは、受信機への送信者の意図したムードが誤って表示されます。
This document does not seek to build a sentient network stack. However, this framework could be used to express the emotions of a sentient stack. If that were to happen, a new technical job class of network psychologists could be created. Who doesn't like new jobs? :)
この文書では、感覚のネットワークスタックを構築しようとしません。しかし、このフレームワークは、感覚のスタックの感情を表現するために使用することができます。それが起こるとしたら、ネットワークの心理学者の新しい技術的なジョブ・クラスを作成することができます。誰が新しい仕事を好きではありませんか？ :)
If this work is standardized, IANA is requested to officially assign value 25 as described in Section 3. Additional moods and emoticon representations would require IESG approval or standards action [RFC5226].
この作業が標準化されている場合は、IANAはセクションで説明したように、正式3.追加の気分や顔文字の表現がIESGの承認または標準アクション[RFC5226]を必要となる値25を割り当てることが要求されています。
[DSM-IV] "Diagnostic and Statistical Manual of Mental Disorders (DSM)", http://www.psychiatryonline.com/ resourceTOC.aspx?resourceID=1.
[DSM-IV] "診断と精神障害の統計マニュアル（DSM）"、http://www.psychiatryonline.com/ resourceTOC.aspx？RESOURCEID = 1。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003.
[RFC3514] Bellovin氏、S.、 "IPv4のヘッダのセキュリティ・フラグ"、RFC 3514、2003年4月1日。
Authors' Addresses
著者のアドレス
Richard Hay Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: rhay@google.com
リチャード・ヘイGoogleの1600アンフィシアターパークウェイマウンテンビュー、CA 94043 Eメール：rhay@google.com
Warren Turkal Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: turkal@google.com
ウォーレンTurkal Googleの1600アンフィシアターパークウェイマウンテンビュー、CA 94043 Eメール：turkal@google.com