TCP Option to Denote Packet Mood
RFC 5841
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.
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.
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.
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.
Hay & Turkal Informational [Page 1]
RFC 5841 TCP Option to Denote Packet Mood 1 April 2010
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].
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.
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].
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 Header Format
Kind Length Meaning
---- -------- -------
25 Variable Packet Mood
Hay & Turkal Informational [Page 2]
RFC 5841 TCP Option to Denote Packet Mood 1 April 2010
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
Show full document text