asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/rfc5841.md.2.xml

@@ -0,0 +1,393 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
+<rfc ipr="trust200902" category="info" docName="rfc-5841">
+<?rfc toc="no"?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc private=""?>
+<?rfc topblock="yes"?>
+<?rfc comments="no"?>
+<front>
+<title abbrev="TCP Option to Denote Packet Mood">TCP Option to Denote Packet Mood</title>
+
+<author initials="R." surname="Hay" fullname="Richard Hay">
+<organization>Google</organization>
+<address>
+<postal>
+<street>1600 Amphitheatre Pkwy</street>
+<city>Mountain View</city>
+<code>CA 94043</code>
+<country></country>
+<region></region>
+</postal>
+<phone></phone>
+<email>rhay@google.com</email>
+<uri></uri>
+</address>
+</author>
+<author initials="W." surname="Turkal" fullname="Warren Turkal">
+<organization>Google</organization>
+<address>
+<postal>
+<street>1600 Amphitheatre Pkwy</street>
+<city>Mountain View</city>
+<code>CA 94043</code>
+<country></country>
+<region></region>
+</postal>
+<phone></phone>
+<email>turkal@google.com</email>
+<uri></uri>
+</address>
+</author>
+<date year="2010" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+
+<abstract>
+<t>This document proposes a new TCP option to denote packet mood.
+</t>
+</abstract>
+
+
+</front>
+
+<middle>
+
+<section anchor="introduction" title="Introduction">
+<t>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 <xref target="DSM-IV"/>.
+</t>
+<t>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 <xref target="RFC0793"/> to the TCP header, using ASCII characters that
+encode commonly used &quot;emoticons&quot; to convey packet mood.
+</t>
+
+<section anchor="terminology" title="Terminology">
+<t>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 <xref target="RFC2119"/>.
+</t>
+</section>
+</section>
+
+<section anchor="syntax" title="Syntax">
+<t>A TCP Option has a 1-byte kind field, followed by a 1-byte length
+field <xref target="RFC0793"/>.  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).
+</t>
+
+<figure align="center" title="TCP Header Format
+"><artwork align="center">
+     Kind     Length     Meaning
+     ----     --------   -------
+      25      Variable   Packet Mood
+</artwork></figure>
+<t>In more detail:
+</t>
+
+<figure align="left"><artwork align="left">
+       +--------+--------+--------+--------+
+       |00011001|00000100|00111010|00101001|
+       +--------+--------+--------+--------+
+        Kind=25  Length=4 ASCII :  ASCII )
+
+       +--------+--------+--------+--------+--------+
+       |00011001|00000101|00111110|00111010|01000000|
+       +--------+--------+--------+--------+--------+
+        Kind=25  Length=5 ASCII &gt;  ACSII :  ASCII @
+</artwork></figure>
+</section>
+
+<section anchor="simple-emotional-representation" title="Simple Emotional Representation">
+<t>It is proposed that common emoticons be used to denote packet mood.
+Packets do not &quot;feel&quot; per se.  The emotions they could be tagged with
+are a reflection of the user mood expressed through packets.
+</t>
+<t>So the humanity expressed in a packet would be entirely sourced from
+humans.
+</t>
+<t>To this end, it is proposed that simple emotions be used convey mood
+as follows.
+</t>
+
+<figure align="left"><artwork align="left">
+  ASCII                Mood
+  =====                ====
+  :)                   Happy
+  :(                   Sad
+  :D                   Amused
+  %(                   Confused
+  :o                   Bored
+  :O                   Surprised
+  :P                   Silly
+  :@                   Frustrated
+  &gt;:@                  Angry
+  :|                   Apathetic
+  ;)                   Sneaky
+  &gt;:)                  Evil
+</artwork></figure>
+<t>Proposed ASCII character encoding
+</t>
+
+<figure align="left"><artwork align="left">
+  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      &gt;
+  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      |
+</artwork></figure>
+<t>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.
+</t>
+</section>
+
+<section anchor="use-cases" title="Use Cases">
+<t>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).
+</t>
+<t>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.
+</t>
+<t>Any packet that exhibits behavior that allows for mood to be inferred
+SHOULD add the TCP OPTION to the packets with the implied mood.
+</t>
+<t>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 <xref target="performance-considerations"/> &quot;Performance Considerations&quot;).
+</t>
+<t>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.
+</t>
+
+<section anchor="happy-packets" title="Happy Packets">
+<t>Healthy packets are happy packets you could say.  If the ACK packets
+return within &lt;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'.
+</t>
+<t>No loss, low-latency packets also makes for happy users.  So the
+packet would be reflecting the end-user experience.
+</t>
+</section>
+
+<section anchor="sad-packets" title="Sad Packets">
+<t>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.
+</t>
+<t>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.
+</t>
+</section>
+
+<section anchor="amused-packets" title="Amused Packets">
+<t>Any packet that is carrying a text joke SHOULD be marked as 'amused'.
+</t>
+<t>Example:
+</t>
+
+<figure align="left"><artwork align="left">
+  1: Knock Knock
+  2: Who's there?
+  1: Impatient chicken
+  2: Impatient chi...
+  1: BAWK!!!!
+</artwork></figure>
+<t>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?
+</t>
+</section>
+
+<section anchor="confused-packets" title="Confused Packets">
+<t>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.
+</t>
+<t>When a receiver host gets out-of-order packets, it SHOULD mark TCP
+ACK packets sent back to the sender as confused.
+</t>
+<t>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.
+</t>
+<t>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.
+</t>
+</section>
+
+<section anchor="bored-packets" title="Bored Packets">
+<t>Packets carrying accounting data with debits, credits, and so on MUST
+be marked as 'bored'.
+</t>
+<t>It could be said that many people consider RFCs boring.  Packets
+containing RFC text MAY be marked as 'bored'.
+</t>
+<t>Packets with phone book listings MUST be marked 'bored'.
+</t>
+<t>Packets containing legal disclaimers and anything in Latin SHOULD be
+marked 'bored'.
+</t>
+</section>
+
+<section anchor="surprised-packets" title="Surprised Packets">
+<t>Who doesn't love when the out-of-order packets in your session
+surprise you while waiting in a congested queue for 20 ms?
+</t>
+<t>Packets do not have birthdays, so packets can be marked as surprised
+when they encounter unexpected error conditions.
+</t>
+<t>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.
+</t>
+</section>
+
+<section anchor="silly-packets" title="Silly Packets">
+<t>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.
+</t>
+</section>
+
+<section anchor="frustrated-packets" title="Frustrated Packets">
+<t>Packets that are retransmitted more than once SHOULD be marked as
+frustrated.
+</t>
+</section>
+
+<section anchor="angry-packets" title="Angry Packets">
+<t>Packets that are retransmitted SHOULD be marked as angry.
+</t>
+</section>
+
+<section anchor="apathetic-packets" title="Apathetic Packets">
+<t>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.
+</t>
+</section>
+
+<section anchor="sneaky-packets" title="Sneaky Packets">
+<t>When a packet is used in a particularly clever way, it SHOULD be
+marked as sneaky.  What is &quot;clever&quot; is rather subjective, so it would
+be prudent to get a few opinions about a particular use to make sure
+that it is clever.
+</t>
+</section>
+
+<section anchor="evil-packets" title="Evil Packets">
+<t>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.
+</t>
+<t>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 <xref target="RFC3514"/> for the same reasons.
+</t>
+</section>
+</section>
+
+<section anchor="performance-considerations" title="Performance Considerations">
+<t>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.
+</t>
+<t>This added per-packet overhead should be considered when using packet
+mood extensions.
+</t>
+</section>
+
+<section anchor="security-considerations" title="Security Considerations">
+<t>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 <spanx style="verb">:)</spanx> could be replaced with a frown by a malicious
+attacker, by using a winking eye <spanx style="verb">;(</spanx>.  This could misrepresent the
+intended mood of the sender to the receiver.
+</t>
+</section>
+
+<section anchor="related-work" title="Related Work">
+<t>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? :)
+</t>
+</section>
+
+<section anchor="iana-considerations" title="IANA Considerations">
+<t>If this work is standardized, IANA is requested to officially assign
+value 25 as described in <xref target="simple-emotional-representation"/>.  Additional moods and emoticon
+representations would require IESG approval or standards action <xref target="RFC5226"/>.
+</t>
+</section>
+
+</middle>
+<back>
+<references title="Informative References">
+<reference anchor='DSM-IV' target='http://www.psychiatryonline.com/resourceTOC.aspx?resourceID=1'>
+  <front>
+   <title>Diagnostic and Statistical Manual of Mental Disorders (DSM)</title>
+   <author></author>
+   <date></date>
+  </front>
+</reference>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3514.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
+</references>
+
+</back>
+</rfc>

data/spec/examples/rfc5841.md.3.xml

@@ -0,0 +1,449 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="rfc-5841">
+<front>
+<title abbrev="TCP Option to Denote Packet Mood">TCP Option to Denote Packet Mood</title>
+
+<author initials="R." surname="Hay" fullname="Richard Hay">
+<organization>Google</organization>
+<address>
+<postal>
+<street>1600 Amphitheatre Pkwy</street>
+<city>Mountain View</city>
+<code>CA 94043</code>
+<country></country>
+<region></region>
+</postal>
+<phone></phone>
+<email>rhay@google.com</email>
+<uri></uri>
+</address>
+</author>
+<author initials="W." surname="Turkal" fullname="Warren Turkal">
+<organization>Google</organization>
+<address>
+<postal>
+<street>1600 Amphitheatre Pkwy</street>
+<city>Mountain View</city>
+<code>CA 94043</code>
+<country></country>
+<region></region>
+</postal>
+<phone></phone>
+<email>turkal@google.com</email>
+<uri></uri>
+</address>
+</author>
+<date year="2010" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+
+<abstract>
+<t>
+This document proposes a new TCP option to denote packet mood.
+</t>
+</abstract>
+
+</front>
+
+<middle>
+
+<section anchor="introduction">
+<name>Introduction</name>
+<t>
+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 <xref target="DSM-IV"/>.
+</t>
+<t>
+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 <xref target="RFC0793"/> to the TCP header, using ASCII characters that
+encode commonly used &quot;emoticons&quot; to convey packet mood.
+</t>
+
+<section anchor="terminology">
+<name>Terminology</name>
+<t>
+The keywords <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>, <bcp14>SHALL</bcp14>, <bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>,
+<bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14>, when they appear in this
+document, are to be interpreted as described in <xref target="RFC2119"/>.
+</t>
+</section>
+</section>
+
+<section anchor="syntax">
+<name>Syntax</name>
+<t>
+A TCP Option has a 1-byte kind field, followed by a 1-byte length
+field <xref target="RFC0793"/>.  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).
+</t>
+<figure align="center">
+<name>TCP Header Format
+</name>
+<artwork>
+     Kind     Length     Meaning
+     ----     --------   -------
+      25      Variable   Packet Mood
+</artwork>
+</figure>
+<t>
+In more detail:
+</t>
+<artwork align="left">
+       +--------+--------+--------+--------+
+       |00011001|00000100|00111010|00101001|
+       +--------+--------+--------+--------+
+        Kind=25  Length=4 ASCII :  ASCII )
+
+       +--------+--------+--------+--------+--------+
+       |00011001|00000101|00111110|00111010|01000000|
+       +--------+--------+--------+--------+--------+
+        Kind=25  Length=5 ASCII &gt;  ACSII :  ASCII @
+</artwork>
+</section>
+
+<section anchor="simple-emotional-representation">
+<name>Simple Emotional Representation</name>
+<t>
+It is proposed that common emoticons be used to denote packet mood.
+Packets do not &quot;feel&quot; per se.  The emotions they could be tagged with
+are a reflection of the user mood expressed through packets.
+</t>
+<t>
+So the humanity expressed in a packet would be entirely sourced from
+humans.
+</t>
+<t>
+To this end, it is proposed that simple emotions be used convey mood
+as follows.
+</t>
+<artwork align="left">
+  ASCII                Mood
+  =====                ====
+  :)                   Happy
+  :(                   Sad
+  :D                   Amused
+  %(                   Confused
+  :o                   Bored
+  :O                   Surprised
+  :P                   Silly
+  :@                   Frustrated
+  &gt;:@                  Angry
+  :|                   Apathetic
+  ;)                   Sneaky
+  &gt;:)                  Evil
+</artwork>
+<t>
+Proposed ASCII character encoding
+</t>
+<artwork align="left">
+  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      &gt;
+  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      |
+</artwork>
+<t>
+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.
+</t>
+</section>
+
+<section anchor="use-cases">
+<name>Use Cases</name>
+<t>
+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).
+</t>
+<t>
+For packets where the 'mood' is inferred from activity within the TCP
+session, the 'mood' <bcp14>MUST</bcp14> 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 <bcp14>MAY</bcp14> contain the TCP OPTION header with a mood
+set.
+</t>
+<t>
+Any packet that exhibits behavior that allows for mood to be inferred
+<bcp14>SHOULD</bcp14> add the TCP OPTION to the packets with the implied mood.
+</t>
+<t>
+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 <xref target="performance-considerations"/> &quot;Performance Considerations&quot;).
+</t>
+<t>
+Each application <bcp14>MUST</bcp14> 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.
+</t>
+
+<section anchor="happy-packets">
+<name>Happy Packets</name>
+<t>
+Healthy packets are happy packets you could say.  If the ACK packets
+return within &lt;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 <bcp14>SHOULD</bcp14> be marked as
+'happy'.
+</t>
+<t>
+No loss, low-latency packets also makes for happy users.  So the
+packet would be reflecting the end-user experience.
+</t>
+</section>
+
+<section anchor="sad-packets">
+<name>Sad Packets</name>
+<t>
+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.
+</t>
+<t>
+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.
+</t>
+</section>
+
+<section anchor="amused-packets">
+<name>Amused Packets</name>
+<t>
+Any packet that is carrying a text joke <bcp14>SHOULD</bcp14> be marked as 'amused'.
+</t>
+<t>
+Example:
+</t>
+<artwork align="left">
+  1: Knock Knock
+  2: Who's there?
+  1: Impatient chicken
+  2: Impatient chi...
+  1: BAWK!!!!
+</artwork>
+<t>
+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?
+</t>
+</section>
+
+<section anchor="confused-packets">
+<name>Confused Packets</name>
+<t>
+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.
+</t>
+<t>
+When a receiver host gets out-of-order packets, it <bcp14>SHOULD</bcp14> mark TCP
+ACK packets sent back to the sender as confused.
+</t>
+<t>
+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.
+</t>
+<t>
+That being said, application developers <bcp14>SHOULD</bcp14> 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.
+</t>
+</section>
+
+<section anchor="bored-packets">
+<name>Bored Packets</name>
+<t>
+Packets carrying accounting data with debits, credits, and so on <bcp14>MUST</bcp14>
+be marked as 'bored'.
+</t>
+<t>
+It could be said that many people consider RFCs boring.  Packets
+containing RFC text <bcp14>MAY</bcp14> be marked as 'bored'.
+</t>
+<t>
+Packets with phone book listings <bcp14>MUST</bcp14> be marked 'bored'.
+</t>
+<t>
+Packets containing legal disclaimers and anything in Latin <bcp14>SHOULD</bcp14> be
+marked 'bored'.
+</t>
+</section>
+
+<section anchor="surprised-packets">
+<name>Surprised Packets</name>
+<t>
+Who doesn't love when the out-of-order packets in your session
+surprise you while waiting in a congested queue for 20 ms?
+</t>
+<t>
+Packets do not have birthdays, so packets can be marked as surprised
+when they encounter unexpected error conditions.
+</t>
+<t>
+So when ICMP destination unreachable messages are received (perhaps
+due to a routing loop or congestion discards), all subsequent packets
+in that session <bcp14>SHOULD</bcp14> be marked as surprised.
+</t>
+</section>
+
+<section anchor="silly-packets">
+<name>Silly Packets</name>
+<t>
+Not all packets are sent as part of a session.  Random keepalives
+during a TCP session <bcp14>MAY</bcp14> be set up as a repartee between systems
+connected as client and server.  Such random and even playful
+interchanges <bcp14>SHOULD</bcp14> be marked as silly.
+</t>
+</section>
+
+<section anchor="frustrated-packets">
+<name>Frustrated Packets</name>
+<t>
+Packets that are retransmitted more than once <bcp14>SHOULD</bcp14> be marked as
+frustrated.
+</t>
+</section>
+
+<section anchor="angry-packets">
+<name>Angry Packets</name>
+<t>
+Packets that are retransmitted <bcp14>SHOULD</bcp14> be marked as angry.
+</t>
+</section>
+
+<section anchor="apathetic-packets">
+<name>Apathetic Packets</name>
+<t>
+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.
+</t>
+</section>
+
+<section anchor="sneaky-packets">
+<name>Sneaky Packets</name>
+<t>
+When a packet is used in a particularly clever way, it <bcp14>SHOULD</bcp14> be
+marked as sneaky.  What is &quot;clever&quot; is rather subjective, so it would
+be prudent to get a few opinions about a particular use to make sure
+that it is clever.
+</t>
+</section>
+
+<section anchor="evil-packets">
+<name>Evil Packets</name>
+<t>
+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 <bcp14>MAY</bcp14> choose to see some
+activities as evil when viewed through their particular lens of the
+world.  At that point, they <bcp14>SHOULD</bcp14> mark packets as evil.
+</t>
+<t>
+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 <xref target="RFC3514"/> for the same reasons.
+</t>
+</section>
+</section>
+
+<section anchor="performance-considerations">
+<name>Performance Considerations</name>
+<t>
+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.
+</t>
+<t>
+This added per-packet overhead should be considered when using packet
+mood extensions.
+</t>
+</section>
+
+<section anchor="security-considerations">
+<name>Security Considerations</name>
+<t>
+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 <tt>:)</tt> could be replaced with a frown by a malicious
+attacker, by using a winking eye <tt>;(</tt>.  This could misrepresent the
+intended mood of the sender to the receiver.
+</t>
+</section>
+
+<section anchor="related-work">
+<name>Related Work</name>
+<t>
+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? :)
+</t>
+</section>
+
+<section anchor="iana-considerations">
+<name>IANA Considerations</name>
+<t>
+If this work is standardized, IANA is requested to officially assign
+value 25 as described in <xref target="simple-emotional-representation"/>.  Additional moods and emoticon
+representations would require IESG approval or standards action <xref target="RFC5226"/>.
+</t>
+</section>
+
+</middle>
+<back>
+<references>
+<name>Informative References</name>
+<reference anchor='DSM-IV' target='http://www.psychiatryonline.com/resourceTOC.aspx?resourceID=1'>
+  <front>
+   <title>Diagnostic and Statistical Manual of Mental Disorders (DSM)</title>
+   <author></author>
+   <date></date>
+  </front>
+</reference>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3514.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml"/>
+</references>
+
+</back>
+</rfc>