asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/rfc748.md

@@ -0,0 +1,79 @@
+% Title = "TELNET RANDOMLY-LOSE Option"
+% abbrev = "TELNET RANDOMLY-LOSE Option"
+% category = "info"
+% docName = "rfc-748"
+% ipr= "trust200902"
+% area = "Internet"
+% workgroup = "Network Working Group"
+% keyword = [""]
+%
+% date = 1978-04-01T00:00:00Z
+%
+% [[author]]
+% initials="M."
+% surname="Crispin"
+% fullname="M. Crispin"
+% organization="SU-AI"
+
+{mainmatter}
+
+# Command name and code
+
+    RANDOMLY-LOSE    256
+
+# Command meanings
+
+IAC WILL RANDOMLY-LOSE:
+:  The sender of this command REQUESTS permission to, or confirms
+   that it will, randomly lose.
+
+IAC WON'T RANDOMLY-LOSE:
+:   The sender of this command REFUSES to randomly lose.
+
+IAC DO RANDOMLY-LOSE:
+:   The sender of this command REQUESTS that the receiver, or grants
+    the receiver permission to, randomly lose.
+
+IAC DON'T RANDOMLY-LOSE:
+:   The command sender DEMANDS that the receiver not randomly lose.
+
+# Default
+
+{align="left"}
+        WON'T RANDOMLY-LOSE
+
+        DON'T RANDOMLY-LOSE
+
+i.e., random lossage will not happen.
+
+# Motivation for the option
+
+Several hosts appear to provide random lossage, such as system
+crashes, lost data, incorrectly functioning programs, etc., as part
+of their services. These services are often undocumented and are in
+general quite confusing to the novice user.  A general means is
+needed to allow the user to disable these features.
+
+# Description of the option
+
+The normal mode does not allow random lossage; therefore the system
+is not allowed to crash, mung user files, etc. If the server wants
+to provide random lossage, it must first ask for permission from the
+user by sending IAC WILL RANDOMLY-LOSE.
+
+If the user wants to permit the server to randomly lose, it replys
+with IAC DO  RANDOMLY-LOSE. Otherwise it  sends  IAC  DONT
+RANDOMLY-LOSE, and the server is forbidden from randomly losing.
+
+Alternatively, the user could request the server to randomly lose, by
+sending IAC DO RANDOMLY-LOSE, and the server will either reply with
+IAC WILL RANDOMLY-LOSE, meaning that it will then proceed to do some
+random lossage (garbaging disk files is recommended for an initial
+implementation).  Or, it could send IAC WONT RANDOMLY-LOSE, meaning
+that it insists upon being reliable.
+
+Since this is implemented as a TELNET option, it is expected that
+servers which do not implement this option will not randomly lose;
+ie, they will provide 100% reliable uptime.
+
+{backmatter}

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

@@ -0,0 +1,116 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
+<rfc ipr="trust200902" category="info" docName="rfc-748">
+<?rfc toc="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc private=""?>
+<?rfc topblock="yes"?>
+<?rfc comments="no"?>
+<front>
+<title abbrev="TELNET RANDOMLY-LOSE Option">TELNET RANDOMLY-LOSE Option</title>
+
+<author initials="M." surname="Crispin" fullname="M. Crispin">
+<organization>SU-AI</organization>
+<address>
+<postal>
+<street></street>
+<city></city>
+<code></code>
+<country></country>
+<region></region>
+</postal>
+<phone></phone>
+<email></email>
+<uri></uri>
+</address>
+</author>
+<date year="1978" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+
+</front>
+
+<middle>
+
+<section anchor="command-name-and-code" title="Command name and code">
+
+<figure align="center"><artwork align="center">
+RANDOMLY-LOSE    256
+</artwork></figure>
+</section>
+
+<section anchor="command-meanings" title="Command meanings">
+<t>
+<list style="hanging">
+<t hangText="IAC WILL RANDOMLY-LOSE:">
+<vspace />
+The sender of this command REQUESTS permission to, or confirms
+that it will, randomly lose.</t>
+<t hangText="IAC WON'T RANDOMLY-LOSE:">
+<vspace />
+The sender of this command REFUSES to randomly lose.</t>
+<t hangText="IAC DO RANDOMLY-LOSE:">
+<vspace />
+The sender of this command REQUESTS that the receiver, or grants
+the receiver permission to, randomly lose.</t>
+<t hangText="IAC DON'T RANDOMLY-LOSE:">
+<vspace />
+The command sender DEMANDS that the receiver not randomly lose.</t>
+</list>
+</t>
+</section>
+
+<section anchor="default" title="Default">
+
+<figure align="left"><artwork align="left">
+    WON'T RANDOMLY-LOSE
+
+    DON'T RANDOMLY-LOSE
+</artwork></figure>
+<t>i.e., random lossage will not happen.
+</t>
+</section>
+
+<section anchor="motivation-for-the-option" title="Motivation for the option">
+<t>Several hosts appear to provide random lossage, such as system
+crashes, lost data, incorrectly functioning programs, etc., as part
+of their services. These services are often undocumented and are in
+general quite confusing to the novice user.  A general means is
+needed to allow the user to disable these features.
+</t>
+</section>
+
+<section anchor="description-of-the-option" title="Description of the option">
+<t>The normal mode does not allow random lossage; therefore the system
+is not allowed to crash, mung user files, etc. If the server wants
+to provide random lossage, it must first ask for permission from the
+user by sending IAC WILL RANDOMLY-LOSE.
+</t>
+<t>If the user wants to permit the server to randomly lose, it replys
+with IAC DO  RANDOMLY-LOSE. Otherwise it  sends  IAC  DONT
+RANDOMLY-LOSE, and the server is forbidden from randomly losing.
+</t>
+<t>Alternatively, the user could request the server to randomly lose, by
+sending IAC DO RANDOMLY-LOSE, and the server will either reply with
+IAC WILL RANDOMLY-LOSE, meaning that it will then proceed to do some
+random lossage (garbaging disk files is recommended for an initial
+implementation).  Or, it could send IAC WONT RANDOMLY-LOSE, meaning
+that it insists upon being reliable.
+</t>
+<t>Since this is implemented as a TELNET option, it is expected that
+servers which do not implement this option will not randomly lose;
+ie, they will provide 100% reliable uptime.
+</t>
+</section>
+
+</middle>
+<back>
+
+</back>
+</rfc>

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

@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="rfc-748">
+<front>
+<title abbrev="TELNET RANDOMLY-LOSE Option">TELNET RANDOMLY-LOSE Option</title>
+
+<author initials="M." surname="Crispin" fullname="M. Crispin">
+<organization>SU-AI</organization>
+<address>
+<postal>
+<street></street>
+<city></city>
+<code></code>
+<country></country>
+<region></region>
+</postal>
+<phone></phone>
+<email></email>
+<uri></uri>
+</address>
+</author>
+<date year="1978" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+</front>
+
+<middle>
+
+<section anchor="command-name-and-code">
+<name>Command name and code</name>
+<artwork>
+RANDOMLY-LOSE    256
+</artwork>
+</section>
+
+<section anchor="command-meanings">
+<name>Command meanings</name>
+<dl>
+<dt>IAC WILL RANDOMLY-LOSE:</dt>
+<dd>The sender of this command REQUESTS permission to, or confirms
+that it will, randomly lose.</dd>
+<dt>IAC WON'T RANDOMLY-LOSE:</dt>
+<dd>The sender of this command REFUSES to randomly lose.</dd>
+<dt>IAC DO RANDOMLY-LOSE:</dt>
+<dd>The sender of this command REQUESTS that the receiver, or grants
+the receiver permission to, randomly lose.</dd>
+<dt>IAC DON'T RANDOMLY-LOSE:</dt>
+<dd>The command sender DEMANDS that the receiver not randomly lose.</dd>
+</dl>
+</section>
+
+<section anchor="default">
+<name>Default</name>
+<artwork align="left">
+    WON'T RANDOMLY-LOSE
+
+    DON'T RANDOMLY-LOSE
+</artwork>
+<t>
+i.e., random lossage will not happen.
+</t>
+</section>
+
+<section anchor="motivation-for-the-option">
+<name>Motivation for the option</name>
+<t>
+Several hosts appear to provide random lossage, such as system
+crashes, lost data, incorrectly functioning programs, etc., as part
+of their services. These services are often undocumented and are in
+general quite confusing to the novice user.  A general means is
+needed to allow the user to disable these features.
+</t>
+</section>
+
+<section anchor="description-of-the-option">
+<name>Description of the option</name>
+<t>
+The normal mode does not allow random lossage; therefore the system
+is not allowed to crash, mung user files, etc. If the server wants
+to provide random lossage, it must first ask for permission from the
+user by sending IAC WILL RANDOMLY-LOSE.
+</t>
+<t>
+If the user wants to permit the server to randomly lose, it replys
+with IAC DO  RANDOMLY-LOSE. Otherwise it  sends  IAC  DONT
+RANDOMLY-LOSE, and the server is forbidden from randomly losing.
+</t>
+<t>
+Alternatively, the user could request the server to randomly lose, by
+sending IAC DO RANDOMLY-LOSE, and the server will either reply with
+IAC WILL RANDOMLY-LOSE, meaning that it will then proceed to do some
+random lossage (garbaging disk files is recommended for an initial
+implementation).  Or, it could send IAC WONT RANDOMLY-LOSE, meaning
+that it insists upon being reliable.
+</t>
+<t>
+Since this is implemented as a TELNET option, it is expected that
+servers which do not implement this option will not randomly lose;
+ie, they will provide 100% reliable uptime.
+</t>
+</section>
+
+</middle>
+<back>
+
+</back>
+</rfc>

data/spec/examples/rfc748.md.adoc

@@ -0,0 +1,80 @@
+= TELNET RANDOMLY-LOSE Option
+M. Crispin
+:doctype: internet-draft
+:abbrev: TELNET RANDOMLY-LOSE Option
+:status: info
+:name: rfc-748
+:ipr: trust200902
+:area: Internet
+:workgroup: Network Working Group
+:revdate: 1978-04-01T00:00:00Z
+:forename_initials: M.
+:organization: SU-AI
+:smart-quotes: false
+
+== Command name and code
+
+....
+    RANDOMLY-LOSE    256
+....
+
+== Command meanings
+
+IAC WILL RANDOMLY-LOSE::  
++
+The sender of this command REQUESTS permission to, or confirms
+that it will, randomly lose.
+
+IAC WON'T RANDOMLY-LOSE::   
++
+The sender of this command REFUSES to randomly lose.
+
+IAC DO RANDOMLY-LOSE::  
++
+The sender of this command REQUESTS that the receiver, or grants
+the receiver permission to, randomly lose.
+
+IAC DON'T RANDOMLY-LOSE:: 
++
+The command sender DEMANDS that the receiver not randomly lose.
+
+== Default
+
+....
+        WON'T RANDOMLY-LOSE
+
+        DON'T RANDOMLY-LOSE
+....
+
+i.e., random lossage will not happen.
+
+== Motivation for the option
+
+Several hosts appear to provide random lossage, such as system
+crashes, lost data, incorrectly functioning programs, etc., as part
+of their services. These services are often undocumented and are in
+general quite confusing to the novice user.  A general means is
+needed to allow the user to disable these features.
+
+== Description of the option
+
+The normal mode does not allow random lossage; therefore the system
+is not allowed to crash, mung user files, etc. If the server wants
+to provide random lossage, it must first ask for permission from the
+user by sending IAC WILL RANDOMLY-LOSE.
+
+If the user wants to permit the server to randomly lose, it replys
+with IAC DO  RANDOMLY-LOSE. Otherwise it  sends  IAC  DONT
+RANDOMLY-LOSE, and the server is forbidden from randomly losing.
+
+Alternatively, the user could request the server to randomly lose, by
+sending IAC DO RANDOMLY-LOSE, and the server will either reply with
+IAC WILL RANDOMLY-LOSE, meaning that it will then proceed to do some
+random lossage (garbaging disk files is recommended for an initial
+implementation).  Or, it could send IAC WONT RANDOMLY-LOSE, meaning
+that it insists upon being reliable.
+
+Since this is implemented as a TELNET option, it is expected that
+servers which do not implement this option will not randomly lose;
+ie, they will provide 100% reliable uptime.
+

data/spec/examples/rfc7511.md

@@ -0,0 +1,257 @@
+% Title = "Scenic Routing for IPv6"
+% abbrev = "Scenic Routing for IPv6"
+% category = "info"
+% docName = "rfc-7511"
+% ipr= "trust200902"
+% area = "Internet"
+% workgroup = "Network Working Group"
+%
+% date = 2015-04-01T00:00:00Z
+%
+% [[author]]
+% initials="M."
+% surname="Wilhelm"
+% fullname="Maximilian Wilhelm"
+%  [author.address]
+%  email = "max@rfc2324.org"
+%  phone = "+49 176 62 05 94 27"
+%   [author.address.postal]
+%   city = "Paderborn, NRW"
+%   country = "Germany"
+
+.# Abstract
+
+This document specifies a new routing scheme for the current version
+of the Internet Protocol version 6 (IPv6) in the spirit of "Green
+IT", whereby packets will be routed to get as much fresh-air time as
+possible.
+
+{mainmatter}
+
+#  Introduction
+
+In times of Green IT, a lot of effort is put into reducing the energy
+consumption of routers, switches, servers, hosts, etc., to preserve
+our environment.  This document looks at Green IT from a different
+angle and focuses on network packets being routed and switched around
+the world.
+
+Most likely, no one ever thought about the millions of packets being
+disassembled into bits every second and forced through copper wires
+or being shot through dark fiber lines by powerful lasers at
+continuously increasing speeds.  Although RFC 5841 [@!RFC5841] provided
+some thoughts about Packet Moods and began to represent them as a TCP
+option, this doesn't help the packets escape their torturous routine.
+
+This document defines another way to deal with Green IT for traffic
+and network engineers and will hopefully aid the wellbeing of a
+myriad of network packets around the world.  It proposes Scenic
+Routing, which incorporates the green-ness of a network path into the
+routing decision.  A routing engine implementing Scenic Routing
+should therefore choose paths based on Avian IP Carriers [@?RFC1149]
+and/or wireless technologies so the packets will get out of the
+miles/kilometers of dark fibers that are in the ground and get as
+much fresh-air time and sunlight as possible.
+
+As of the widely known acceptance of the current version of the
+Internet Protocol (IPv6), this document only focuses on version 6 and
+ignores communication still based on Vintage IP [@?RFC0791].
+
+##  Conventions and Terminology
+
+The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
+"**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
+document are to be interpreted as described in RFC 2119 [@!RFC2119].
+
+Additionally, the key words "**MIGHT**", "**COULD**", "**MAY WISH TO**", "**WOULD
+PROBABLY**", "**SHOULD CONSIDER**", and "**MUST (BUT WE KNOW YOU WON'T)**" in
+this document are to interpreted as described in RFC 6919 [@!RFC6919].
+
+#  Scenic Routing
+
+Scenic Routing can be enabled with a new option for IPv6 datagrams.
+
+##  Scenic Routing Option (SRO)
+
+The Scenic Routing Option (SRO) is placed in the IPv6 Hop-by-Hop
+Options Header that must be examined by every node along a packet's
+delivery path [@!RFC2460].
+
+The SRO can be included in any IPv6 datagram, but multiple SROs **MUST
+NOT** be present in the same IPv6 datagram.  The SRO has no alignment
+requirement.
+
+If the SRO is set for a packet, every node en route from the packet
+source to the packet's final destination **MUST** preserve the option.
+
+The following Hop-by-Hop Option is proposed according to the
+specification in Section 4.2 of RFC 2460 [@!RFC2460].
+
+{#fig-scenic-routing-option-layout}
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                |  Option Type  | Option Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|   SRO Param   |                                               |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+Figure: Scenic Routing Option Layout
+
+Option Type
+: <br/>8-bit identifier of the type of option.  The option identifier
+    0x0A (On Air) is proposed for Scenic Routing.
+
+    {#fig-option-type}
+    ~~~~~
+    HEX         act  chg  rest
+    ---         ---  ---  -----
+    0A           00   0   01010     Scenic Routing
+    ~~~~~
+    Figure: Scenic Routing Option Type
+
+    The highest-order two bits are set to 00 so any node not
+    implementing Scenic Routing will skip over this option and
+    continue processing the header.  The third-highest-order bit
+    indicates that the SRO does not change en route to the packet's
+    final destination.
+
+Option Length
+: <br/>8-bit unsigned integer.  The length of the option in octets
+    (excluding the Option Type and Option Length fields).  The value
+    **MUST** be greater than 0.
+
+SRO Param
+: <br/>8-bit identifier indicating Scenic Routing parameters encoded as a bit string.
+
+    {#fig-bit-string-layout}
+    ~~~~~
+    +-+-+-+-+-+-+-+-+
+    | SR A W AA X Y |
+    +-+-+-+-+-+-+-+-+
+    ~~~~~
+    Figure: SRO Param Bit String Layout
+
+    The highest-order two bits (SR) define the urgency of Scenic
+    Routing:
+
+    {style="empty"}
+    - 00 - Scenic Routing **MUST NOT** be used for this packet.
+    - 01 - Scenic Routing **MIGHT** be used for this packet.
+    - 10 - Scenic Routing **SHOULD** be used for this packet.
+    - 11 - Scenic Routing **MUST** be used for this packet.
+
+    The following BIT (A) defines if Avian IP Carriers should be used:
+
+    {style="empty"}
+    - 0 - Don't use Avian IP Carrier links (maybe the packet is
+      afraid of pigeons).
+    - 1 - Avian IP Carrier links may be used.
+
+    The following BIT (W) defines if wireless links should be used:
+
+    {style="empty"}
+    - 0 - Don't use wireless links (maybe the packet is afraid of
+      radiation).
+    - 1 - Wireless links may be used.
+
+    The following two bits (AA) define the affinity for link types:
+
+    {style="empty"}
+    - 00 - No affinity.
+    - 01 - Avian IP Carriers **SHOULD** be preferred.
+    - 10 - Wireless links **SHOULD** be preferred.
+    - 11 - RESERVED
+
+    The lowest-order two bits (XY) are currently unused and reserved
+    for future use.
+
+# Implications
+
+## Routing Implications
+
+If Scenic Routing is requested for a packet, the path with the known
+longest Avian IP Carrier and/or wireless portion **MUST** be used.
+
+Backbone operators who desire to be fully compliant with Scenic
+Routing **MAY WISH TO** -- well, they **SHOULD** -- have separate MPLS paths
+ready that provide the most fresh-air time for a given path and are
+to be used when Scenic Routing is requested by a packet.  If such a
+path exists, the path MUST be used in favor of any other path, even
+if another path is considered cheaper according to the path costs
+used regularly, without taking Scenic Routing into account.
+
+## Implications for Hosts
+
+Host systems implementing this option of receiving packets with
+Scenic Routing requested **MUST** honor this request and **MUST** activate
+Scenic Routing for any packets sent back to the originating host for
+the current connection.
+
+If Scenic Routing is requested for connections of local origin, the
+host MUST obey the request and route the packet(s) over a wireless
+link or use Avian IP Carriers (if available and as requested within
+the SRO Params).
+
+System administrators **MIGHT** want to configure sensible default
+parameters for Scenic Routing, when Scenic Routing has been widely
+adopted by operating systems.  System administrators **SHOULD** deploy
+Scenic Routing information where applicable.
+
+##  Proxy Servers
+
+If a host is running a proxy server or any other packet-relaying
+application, an application implementing Scenic Routing **MUST** set the
+same SRO Params on the outgoing packet as seen on the incoming
+packet.
+
+Developers **SHOULD CONSIDER** Scenic Routing when designing and
+implementing any network service.
+
+#  Security Considerations
+
+The security considerations of RFC 6214 [@!RFC6214] apply for links
+provided by Avian IP Carriers.
+
+General security considerations of wireless communication apply for
+links using wireless technologies.
+
+As the user is able to influence where flows and packets are being
+routed within the network, this **MIGHT** influence traffic-engineering
+considerations and network operators **MAY WISH TO** take this into
+account before enabling Scenic Routing on their devices.
+
+#  IANA Considerations
+
+This document defines a new IPv6 Hop-by-Hop Option, the Scenic
+Routing Option, described in (#scenic-routing-option-sro).
+If this work is standardized, IANA is requested to assign a value from the "Destination Options and
+Hop-by-Hop Options" registry for the purpose of Scenic Routing.
+
+There are no IANA actions requested at this time.
+
+#  Related Work
+
+As Scenic Routing is heavily dependent on network paths and routing
+information, it might be worth looking at designing extensions for
+popular routing protocols like BGP or OSPF to leverage the full
+potential of Scenic Routing in large networks built upon lots of
+wireless links and/or Avian IP Carriers.  When incorporating
+information about links compatible with Scenic Routing, the routing
+algorithms could easily calculate the optimal paths providing the
+most fresh-air time for a packet for any given destination.
+
+This would even allow preference for wireless paths going alongside
+popular or culturally important places.  This way, the packets don't
+only avoid the dark fibers, but they get to see the world outside of
+the Internet and are exposed to different cultures around the globe,
+which may help build an understanding of cultural differences and
+promote acceptance of these differences.
+
+{backmatter}
+
+# Acknowledgements
+
+The author wishes to thank all those poor friends who were kindly
+forced to read this document and that provided some nifty comments.