はじめに
- この文書は RFC5841 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
TCP Option to Denote Packet Mood（パケットのムードを表すTCPオプション）
- Independent Submission
- Request for Comments: 5841
- Category: Informational
- ISSN: 2070-1721
- R. Hay
- W. Turkal
- Google Inc.
- 1 April 2010
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.
この文書は、Internet Standards Track の仕様ではなく、情報提供を目的として公開する。
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エディタは自らの裁量でこの文書を公開することを選択し、その実装や配備に対する価値については一切言及しない。
RFCエディタによって公開が承認された文書は、どのレベルのインターネット標準の候補にもならない。詳細はRFC5741の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.
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.
1. Introduction（はじめに）
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].
世界中の無数の物理層ネットワーク上のビットストリームを擬人化する試みとして、パケットのムードを表すTCPオプション [DSM-IV] を提案する。
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を受信しなかったパケットのデータを再送するために再び伝送させられるパケットは、「怒っている」パケット、あるいは「イライラしている」パケットと表現することができる(たとえば、それが最初の再送でない場合)。
では、このような感情をパケットそのものによって伝えるにはどうすればいいのか。
これは、TCPヘッダーにTCPオプション [RFC793] を追加し、パケットのムードを伝えるために一般的に使用される「顔文字(emoticons)」をエンコードするASCII文字を使用することで対処することができる。
1.1. Terminology（用語解説）
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].
キーワード MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL が本文書に示された場合、[RFC2119] に記述されているように解釈されるべきである。
2. Syntax（文法）
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オプションは、1バイトの種類フィールドと、それに続く1バイトの長さフィールドを持つ [RFC793]。
パケットのムードを定義するためにオプション25(2000-12-18リリース)を使用することを提案する。
このオプションは4バイトまたは5バイトの長さを持つ。
このメカニズムで表現可能な単純な感情はすべて、2つまたは3つの7ビットASCIIエンコード文字で表示することができる。
ここで定義されたものより複雑なムードを表現するために、TCPヘッダに複数のムードオプションが指定できる(たとえば、パケットが「幸せ」で「驚き」だった場合など)。
TCP Header Format
Kind Length Meaning
---- -------- -------
25 Variable Packet Mood
| 種類 | 長さ | 意味 |
|---|---|---|
| 25 | 可変長 | パケットのムード |
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 @
3. Simple Emotional Representation（シンプルな感情表現）
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文字は8ビットバイトで送信されるが、先頭のビットは常に0に設定される。
4. Use Cases（ユースケース）
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).
パケットのムードを表すには、2つの方法がある。
1つは、TCPセッションのイベントに基づいてムードを推測する方法。
もう1つは、より高いレイヤでの高次の動作(例えばペイロードの主題)からムードを導出する方法。
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セッション内の活動から推測されるパケットの場合、「ムード」はトリガーイベントを監視しているホストによって設定されなければならない(MUST)。
クライアントがフレームを送信し、ACKを受信しなかった場合、再送されたフレームはムードを設定したTCP オプションヘッダを含んでもよい(MAY)。
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 オプションを追加するべきである(SHOULD)。
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.
各アプリケーションは、パケットに幸せ、悲しい、退屈、混乱、怒り、無気力などのマークを付けるための前提条件を定義しなければならない(MUST)。
これは、そのようなムードをどのように表現するかを定義するための枠組みであるが、これらの符号化されたラベルをいつ適用するかは開発者次第である。
4.1. Happy Packets（幸せなパケット）
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パケットが送信側スタックから受信側スタックまでエンドツーエンドで10ms未満で戻ってくる場合、これは高速双方向性を反映していると考えられ、再送信が必要なく、すべてのACKを受信した場合、そのセッションの後続パケットはすべて「幸せ」とマークすべきである(SHOULD)。
No loss, low-latency packets also makes for happy users.
So the packet would be reflecting the end-user experience.
ロスのない、低遅延のパケットは、ユーザーにとっても幸せなことだ。
つまり、パケットはエンドユーザーの体験を反映していることになる。
4.2. Sad Packets（悲しいパケット）
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.
このタグはパケットの命の驚異的な損失によって麻痺したセッションのすべてのフレームに適用されるので、これは「怒り」としてマークされた再送信されたパケットと混同してはならない。
4.3. Amused Packets（楽しいパケット）
Any packet that is carrying a text joke SHOULD be marked as 'amused'.
ジョークテキストを運んでいるパケットは、「楽しい」とマークされるべきである(SHOULD)。
Example:
例：
1: Knock Knock
2: Who's there?
1: Impatient chicken
2: Impatient chi...
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年生まで生き残る唯一のノックノック・ジョークの一つを面白がらないわけにはいかないでしょう。
4.4. Confused Packets（混乱しているパケット）
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.
そうは言っても、アプリケーション開発者は、ペイロードに人生の意味や宇宙での自分の位置を考えさせるような複雑な哲学的質問が含まれている場合、パケットを混乱しているとマークすべきである(SHOULD)。
4.5. Bored Packets（退屈しているパケット）
Packets carrying accounting data with debits, credits, and so on MUST be marked as 'bored'.
借方、貸方などの会計データを運ぶパケットは、「退屈」とマークされなければならない(MUST)。
It could be said that many people consider RFCs boring.
Packets containing RFC text MAY be marked as 'bored'.
多くの人がRFCを退屈だと考えていると言えるだろう。
RFC のテキストを含むパケットは「退屈」とマークしてもよい(MAY)。
Packets with phone book listings MUST be marked 'bored'.
電話帳のリストを含むパケットは「退屈」とマークしなければならない(MUST)。
Packets containing legal disclaimers and anything in Latin SHOULD be marked 'bored'.
法的な免責事項やラテン語のものを含むパケットは「退屈」とマークされるべきだ(SHOULD)。
4.6. Surprised Packets（驚いているパケット）
Who doesn't love when the out-of-order packets in your session surprise you while waiting in a congested queue for 20 ms?
混雑したキューで20ミリ秒待っている間に、自分のセッションの順番が狂っているパケットに驚かされるのが嫌いな人はいないだろう。
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 送達不能メッセージを受信すると、そのセッションの後続のすべてのパケットは驚きとしてマークされるべきである(SHOULD)。
4.7. Silly Packets（馬鹿なパケット）
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セッション中のランダムなキープアライブは、クライアントとサーバが接続されたシステム間の応酬として設定されてもよい(MAY)。
このようなランダムで遊び心にあふれたやり取りは、馬鹿な事としてマークされるべきだ(SHOULD)。
4.8. Frustrated Packets（イライラしているパケット）
Packets that are retransmitted more than once SHOULD be marked as frustrated.
1回以上再送されたパケットは、イライラしているとしてマークされるべきである(SHOULD)。
4.9. Angry Packets（怒っているパケット）
Packets that are retransmitted SHOULD be marked as angry.
再送されたパケットは、怒っているとマークされるべきである(SHOULD)。
4.10. Apathetic Packets（無気力なパケット）
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パケットを接続先システムに送信する場合、パケットに無気力とマークすることで、受信者があなたのシステムがその後どうなっても構わないということを知ることができる。
4.11. Sneaky Packets（ズルいパケット）
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.
パケットが特に巧妙な方法で使用されている場合、それは卑劣であるとマークされるべきだ。
何が「巧妙」かはかなり主観的なものなので、特定の使用方法について、それが巧妙であることを確認するために、いくつかの意見を得ることが賢明だろう。
4.12. Evil Packets（悪いパケット）
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パケットでは、人生の意味や「悪」の定義、誰の視点からの特徴づけなど、より高度な道徳的問題を見分けることは困難である。
しかし、TCPベースのアプリケーションの開発者は、ある種の活動を、自分たちの特定のレンズを通して見たときに、悪と見なすことを選択してもよい(MAY)。
その場合、パケットを悪いとしてマークすべきだ(SHOULD)。
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ヘッダのセキュリティフラグの使用も禁止していることになる。
5. Performance Considerations（パフォーマンスに関する考察）
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(注：Maximum Segment Size; TCPヘッダ部を除いた最大サイズ)がその分少なくなる。
TCPヘッダが20バイト以上の場合、その余分なバイトはフレームのペイロードに使用することができなくなる。
This added per-packet overhead should be considered when using packet mood extensions.
パケットごとのオーバーヘッドを追加することは、パケットムード拡張を使用する際に考慮されるべきである。
6. Security Considerations（セキュリティに関する考察）
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.
TCPチェックサムは16ビット値であるため、0と1が同数のASCII文字に置き換えられると誤認される可能性がある。
悪意のある攻撃者が、幸せ :) を、ウインクするような目のしかめっ面 ;( に置き換えることができる。
これは、送信者の意図するムードを受信者に誤認させる可能性がある。
7. Related Work（関連作業）
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?
:)
この文書は、感覚的なネットワークスタックを構築しようとするものではない。
しかし、このフレームワークは感覚を持ったスタックの感情を表現するために使われるかもしれない。
もしそうなれば、ネットワーク心理学者という新しい技術職が誕生するかもしれない。
新しい仕事が嫌いな人はいないだろう。
:)
8. IANA Considerations（IANA の検討事項）
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章で説明したように、値25を公式に割り当てるよう要請される。
追加のムードと顔文字の表現には、IESGの承認または標準化措置 [RFC5226] が必要である。
9. Informative References
[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.
Authors' Addresses
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