asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/rfc1149.md

@@ -0,0 +1,76 @@
+%%%
+
+    Title = "A Standard for the Transmission of IP Datagrams on Avian Carriers"
+    abbrev = "IP Datagrams on Avian Carriers"
+    category = "info"
+    docName = "rfc-1149"
+    ipr= "trust200902"
+    area = "Internet"
+    workgroup = "Network Working Group"
+    keyword = [""]
+
+    date = 1990-04-01T00:00:00Z
+
+    [[author]]
+    initials="D."
+    surname="Waitzman"
+    fullname="David Waitzman"
+    organization = "BBN STC"
+      [author.address]
+      email = "dwaitzman@BBN.COM"
+      phone = "(617) 873-4323"
+      [author.address.postal]
+      street = "10 Moulton Street"
+      city = "Cambridge"
+      code = "MA 02238"
+
+%%%
+
+{mainmatter}
+
+# Overview and Rational
+
+Avian carriers can provide high delay, low throughput, and low
+altitude service.  The connection topology is limited to a single
+point-to-point path for each carrier, used with standard carriers,
+but many carriers can be used without significant interference with
+each other, outside of early spring.  This is because of the 3D ether
+space available to the carriers, in contrast to the 1D ether used by
+IEEE802.3.  The carriers have an intrinsic collision avoidance
+system, which increases availability.  Unlike some network
+technologies, such as packet radio, communication is not limited to
+line-of-sight distance.  Connection oriented service is available in
+some cities, usually based upon a central hub topology.
+
+# Frame Format
+
+The IP datagram is printed, on a small scroll of paper, in
+hexadecimal, with each octet separated by whitestuff and blackstuff.
+The scroll of paper is wrapped around one leg of the avian carrier.
+A band of duct tape is used to secure the datagram's edges.  The
+bandwidth is limited to the leg length.  The MTU is variable, and
+paradoxically, generally increases with increased carrier age.  A
+typical MTU is 256 milligrams.  Some datagram padding may be needed.
+
+Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.
+
+# Discussion
+
+Multiple types of service can be provided with a prioritized pecking
+order.  An additional property is built-in worm detection and
+eradication.  Because IP only guarantees best effort delivery, loss
+of a carrier can be tolerated.  With time, the carriers are self-
+regenerating.  While broadcasting is not specified, storms can cause
+data loss.  There is persistent delivery retry, until the carrier
+drops.  Audit trails are automatically generated, and can often be
+found on logs and cable trays.
+
+# Security Considerations
+
+Security is not generally a problem in normal operation, but special
+measures must be taken (such as data encryption) when avian carriers
+are used in a tactical environment.
+
+{backmatter}

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

@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
+<rfc ipr="trust200902" category="info" docName="rfc-1149">
+<?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="IP Datagrams on Avian Carriers">A Standard for the Transmission of IP Datagrams on Avian Carriers</title>
+
+<author initials="D." surname="Waitzman" fullname="David Waitzman">
+<organization>BBN STC</organization>
+<address>
+<postal>
+<street>10 Moulton Street</street>
+<city>Cambridge</city>
+<code>MA 02238</code>
+<country></country>
+<region></region>
+</postal>
+<phone>(617) 873-4323</phone>
+<email>dwaitzman@BBN.COM</email>
+<uri></uri>
+</address>
+</author>
+<date year="1990" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+
+</front>
+
+<middle>
+
+<section anchor="overview-and-rational" title="Overview and Rational">
+<t>Avian carriers can provide high delay, low throughput, and low
+altitude service.  The connection topology is limited to a single
+point-to-point path for each carrier, used with standard carriers,
+but many carriers can be used without significant interference with
+each other, outside of early spring.  This is because of the 3D ether
+space available to the carriers, in contrast to the 1D ether used by
+IEEE802.3.  The carriers have an intrinsic collision avoidance
+system, which increases availability.  Unlike some network
+technologies, such as packet radio, communication is not limited to
+line-of-sight distance.  Connection oriented service is available in
+some cities, usually based upon a central hub topology.
+</t>
+</section>
+
+<section anchor="frame-format" title="Frame Format">
+<t>The IP datagram is printed, on a small scroll of paper, in
+hexadecimal, with each octet separated by whitestuff and blackstuff.
+The scroll of paper is wrapped around one leg of the avian carrier.
+A band of duct tape is used to secure the datagram's edges.  The
+bandwidth is limited to the leg length.  The MTU is variable, and
+paradoxically, generally increases with increased carrier age.  A
+typical MTU is 256 milligrams.  Some datagram padding may be needed.
+</t>
+<t>Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.
+</t>
+</section>
+
+<section anchor="discussion" title="Discussion">
+<t>Multiple types of service can be provided with a prioritized pecking
+order.  An additional property is built-in worm detection and
+eradication.  Because IP only guarantees best effort delivery, loss
+of a carrier can be tolerated.  With time, the carriers are self-
+regenerating.  While broadcasting is not specified, storms can cause
+data loss.  There is persistent delivery retry, until the carrier
+drops.  Audit trails are automatically generated, and can often be
+found on logs and cable trays.
+</t>
+</section>
+
+<section anchor="security-considerations" title="Security Considerations">
+<t>Security is not generally a problem in normal operation, but special
+measures must be taken (such as data encryption) when avian carriers
+are used in a tactical environment.
+</t>
+</section>
+
+</middle>
+<back>
+
+</back>
+</rfc>

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

@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="rfc-1149">
+<front>
+<title abbrev="IP Datagrams on Avian Carriers">A Standard for the Transmission of IP Datagrams on Avian Carriers</title>
+
+<author initials="D." surname="Waitzman" fullname="David Waitzman">
+<organization>BBN STC</organization>
+<address>
+<postal>
+<street>10 Moulton Street</street>
+<city>Cambridge</city>
+<code>MA 02238</code>
+<country></country>
+<region></region>
+</postal>
+<phone>(617) 873-4323</phone>
+<email>dwaitzman@BBN.COM</email>
+<uri></uri>
+</address>
+</author>
+<date year="1990" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+</front>
+
+<middle>
+
+<section anchor="overview-and-rational">
+<name>Overview and Rational</name>
+<t>
+Avian carriers can provide high delay, low throughput, and low
+altitude service.  The connection topology is limited to a single
+point-to-point path for each carrier, used with standard carriers,
+but many carriers can be used without significant interference with
+each other, outside of early spring.  This is because of the 3D ether
+space available to the carriers, in contrast to the 1D ether used by
+IEEE802.3.  The carriers have an intrinsic collision avoidance
+system, which increases availability.  Unlike some network
+technologies, such as packet radio, communication is not limited to
+line-of-sight distance.  Connection oriented service is available in
+some cities, usually based upon a central hub topology.
+</t>
+</section>
+
+<section anchor="frame-format">
+<name>Frame Format</name>
+<t>
+The IP datagram is printed, on a small scroll of paper, in
+hexadecimal, with each octet separated by whitestuff and blackstuff.
+The scroll of paper is wrapped around one leg of the avian carrier.
+A band of duct tape is used to secure the datagram's edges.  The
+bandwidth is limited to the leg length.  The MTU is variable, and
+paradoxically, generally increases with increased carrier age.  A
+typical MTU is 256 milligrams.  Some datagram padding may be needed.
+</t>
+<t>
+Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.
+</t>
+</section>
+
+<section anchor="discussion">
+<name>Discussion</name>
+<t>
+Multiple types of service can be provided with a prioritized pecking
+order.  An additional property is built-in worm detection and
+eradication.  Because IP only guarantees best effort delivery, loss
+of a carrier can be tolerated.  With time, the carriers are self-
+regenerating.  While broadcasting is not specified, storms can cause
+data loss.  There is persistent delivery retry, until the carrier
+drops.  Audit trails are automatically generated, and can often be
+found on logs and cable trays.
+</t>
+</section>
+
+<section anchor="security-considerations">
+<name>Security Considerations</name>
+<t>
+Security is not generally a problem in normal operation, but special
+measures must be taken (such as data encryption) when avian carriers
+are used in a tactical environment.
+</t>
+</section>
+
+</middle>
+<back>
+
+</back>
+</rfc>

data/spec/examples/rfc1149.md.adoc

@@ -0,0 +1,65 @@
+= A Standard for the Transmission of IP Datagrams on Avian Carriers
+David Waitzman <dwaitzman@BBN.COM>
+:abbrev: IP Datagrams on Avian Carriers
+:status: info
+:name: rfc-1149
+:ipr: trust200902
+:area: Internet
+:workgroup: Network Working Group
+:date: 1990-04-01T00:00:00Z
+:forename_initials: D.
+:organization: BBN STC
+:phone: (617) 873-4323
+:street: 10 Moulton Street
+:city: Cambridge
+:code: MA 02238
+:smart-quotes: false
+
+[[overview-and-rational]]
+== Overview and Rational
+
+Avian carriers can provide high delay, low throughput, and low
+altitude service.  The connection topology is limited to a single
+point-to-point path for each carrier, used with standard carriers,
+but many carriers can be used without significant interference with
+each other, outside of early spring.  This is because of the 3D ether
+space available to the carriers, in contrast to the 1D ether used by
+IEEE802.3.  The carriers have an intrinsic collision avoidance
+system, which increases availability.  Unlike some network
+technologies, such as packet radio, communication is not limited to
+line-of-sight distance.  Connection oriented service is available in
+some cities, usually based upon a central hub topology.
+
+[[frame-format]]
+== Frame Format
+
+The IP datagram is printed, on a small scroll of paper, in
+hexadecimal, with each octet separated by whitestuff and blackstuff.
+The scroll of paper is wrapped around one leg of the avian carrier.
+A band of duct tape is used to secure the datagram's edges.  The
+bandwidth is limited to the leg length.  The MTU is variable, and
+paradoxically, generally increases with increased carrier age.  A
+typical MTU is 256 milligrams.  Some datagram padding may be needed.
+
+Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.
+
+[[discussion]]
+== Discussion
+
+Multiple types of service can be provided with a prioritized pecking
+order.  An additional property is built-in worm detection and
+eradication.  Because IP only guarantees best effort delivery, loss
+of a carrier can be tolerated.  With time, the carriers are self-
+regenerating.  While broadcasting is not specified, storms can cause
+data loss.  There is persistent delivery retry, until the carrier
+drops.  Audit trails are automatically generated, and can often be
+found on logs and cable trays.
+
+[[security-considerations]]
+== Security Considerations
+
+Security is not generally a problem in normal operation, but special
+measures must be taken (such as data encryption) when avian carriers
+are used in a tactical environment.

data/spec/examples/rfc2100.md

@@ -0,0 +1,149 @@
+%%%
+
+    title = "The Naming of Hosts"
+    abbrev = "The Naming of Hosts"
+    category = "info"
+    docname = "rfc-2100"
+    ipr= "trust200902"
+    area = "Internet"
+    workgroup = "Network Working Group"
+    keyword = [""]
+
+    date = 1997-04-01T00:00:00Z
+
+    [pi]
+    toc = "no"
+    symrefs = "no"
+
+    [[author]]
+    initials="J. R."
+    surname="Ashworth"
+    fullname="Jay R. Ashworth"
+    abbrev = "Ashworth & Associates"
+    organization = "Advanced Technology Consulting"
+      [author.address]
+      email = "jra@scfn.thpl.lib.fl.us"
+      phone = "+1 813 790 7592"
+      [author.address.postal]
+      city = "St. Petersburg"
+      code = "FL 33709-4819"
+
+%%%
+
+{mainmatter}
+
+# Introduction
+
+This RFC is a commentary on the difficulty of deciding upon an
+acceptably distinctive hostname for one's computer, a problem which
+grows in direct proportion to the logarithmically increasing size of
+the Internet.
+
+Distribution of this memo is unlimited.
+
+Except to TS Eliot.
+
+And, for that matter, to David Addison, who hates iambic pentameter.
+
+# Poetry
+
+{align="left"}
+    The Naming of Hosts is a difficult matter,
+        It isn't just one of your holiday games;
+    You may think at first I'm as mad as a hatter
+        When I tell you, a host must have THREE DIFFERENT NAMES.
+<!-- separator -->
+{align="left"}
+    First of all, there's the name that the users use daily,
+        Such as venus, athena, and cisco, and ames,
+    Such as titan or sirius, hobbes or europa--
+        All of them sensible everyday names.
+<!-- separator -->
+{align="left"}
+    There are fancier names if you think they sound sweeter,
+        Some for the web pages, some for the flames:
+    Such as mercury, phoenix, orion, and charon--
+        But all of them sensible everyday names.
+<!-- separator -->
+{align="left"}
+    But I tell you, a host needs a name that's particular,
+        A name that's peculiar, and more dignified,
+    Else how can it keep its home page perpendicular,
+        And spread out its data, send pages world wide?
+<!-- separator -->
+{align="left"}
+    Of names of this kind, I can give you a quorum,
+        Like lothlorien, pothole, or kobyashi-maru,
+    Such as pearly-gates.vatican, or else diplomatic-
+        Names that never belong to more than one host.
+<!-- separator -->
+{align="left"}
+    But above and beyond there's still one name left over,
+        And that is the name that you never will guess;
+    The name that no human research can discover--
+        But THE NAMESERVER KNOWS, and will us'ually confess.
+<!-- separator -->
+{align="left"}
+    When you notice a client in rapt meditation,
+        The reason, I tell you, is always the same:
+    The code is engaged in a deep consultation
+        On the address, the address, the address of its name:
+<!-- separator -->
+{align="left"}
+                It's ineffable,
+                effable,
+                Effanineffable,
+                Deep and inscrutable,
+                singular
+                Name.
+
+# Credits
+
+Thanks to Don Libes, Mark Lottor, and a host of twisted
+individuals^W^Wcreative sysadmins for providing source material for
+this memo, to Andrew Lloyd-Webber, Cameron Mackintosh, and a cast of
+thousands (particularly including Terrance Mann) who drew my
+attention to the necessity, and of course, to Thomas Stearns Eliot,
+for making this all necessary.
+[-@libes] [-@lottor] [-@wong] [-@ts]
+
+# Security Considerations
+
+Security issues are not discussed in this memo.
+
+Particularly the cardiac security of certain famous poets.
+
+<reference anchor='libes' target=''>
+ <front>
+ <title>Choosing a Name for Your Computer</title>
+  <author initials='D.' surname='Libes' fullname='D. Libes'></author>
+  <date year='1989' month='November'/>
+ </front>
+ <seriesInfo name="Communications of the ACM" value='Vol. 32, No. 11, Pg. 1289' />
+ </reference>
+
+<reference anchor='lottor' target='namedroppers@internic.net'>
+ <front>
+ <title>Domain Name Survey</title>
+  <author initials='M.' surname='Lottor' fullname='M. Lottor'></author>
+  <date year='1997' month='January'/>
+ </front>
+ </reference>
+
+<reference anchor='wong' target='http://www.seas.upenn.edu/~mengwong/coolhosts.html'>
+ <front>
+ <title>Cool Hostnames</title>
+  <author initials='M.' surname='Wong' fullname='M. Wong'></author>
+  <date/>
+ </front>
+ </reference>
+
+<reference anchor='ts' target=''>
+ <front>
+ <title>Old Possum's Book of Practical Cats</title>
+  <author initials='TS' surname='Stearns' fullname='TS. Stearns'></author>
+  <date/>
+ </front>
+ </reference>
+
+{backmatter}