asciidoctor-rfc 0.2.0 → 0.8.0

data/spec/examples/hoffmanv3.xml.orig

@@ -0,0 +1,346 @@
+<?xml version='1.0' encoding='US-ASCII'?>
+   <!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
+
+
+
+
+   <rfc ipr='trust200902' consensus='no' submissionType='IETF'
+    updates='1234, 5678' xml:lang='en'>
+
+   <front><seriesInfo name='Internet-Draft'
+    value='draft-example-of-xml-00'/>
+   <seriesInfo name='std' value=''/>
+   <title abbrev='XML Example'>
+   An Example of Using XML for an Internet Draft
+   </title>
+
+   <author fullname='Chris Smith' initials='C.' surname='Smith'>
+   <organization abbrev='EC'>ExampleCorp</organization>
+   <address>
+   <postal>
+   <street>123 Exemplar Way</street>
+   <city>Anytown</city>
+   <region>California</region>
+   <code>95060</code>
+   <country>US</country>
+   </postal>
+   <phone>+1 123-456-7890</phone>
+   +1 123-456-7890
+   <email>chrissmith@example.com</email>
+   <uri>http://www.example.com/corporate/</uri>
+   </address>
+   </author>
+
+   <!-- The following author has no organization and no postal or
+        phone information. -->
+   <author fullname='Kim Jones' initials='K.' surname='Jones'>
+   <organization/>
+   <address>
+   <email>jk@lmn.op</email>
+   </address>
+   </author>
+   <date year='2014' month='September'/>
+
+   <area>General</area>
+   <workgroup>Imaginary WG</workgroup>
+   <keyword>XML</keyword>
+   <keyword>Imagination</keyword>
+
+   <abstract>
+   <t>This is an example of an abstract. It is a short paragraph that
+   gives an overview of the document in order to help the
+   reader determine whether or not they are interested in reading
+   further.</t>
+   </abstract>
+
+   <note tile='Disclaimer'>
+   <t>This isn't a real RFC, just an example.</t>
+   </note>
+
+   </front>
+
+   <middle>
+
+   <section anchor='intro'><name>Introduction</name>
+
+   <t>This is the first paragraph of the introduction to this
+   document. This introduction is probably much shorter than it would
+   be for a real Internet Draft.</t>
+
+   <t>Something to note about this paragraph is that it has a
+   pointer to <xref target='protocol'/>, and one to
+   <xref target='haiku'/>, both of which appear later in the
+   document.</t>
+
+   <iref item='Introduction' subitem='verbiage' primary='true'/>
+
+   <!-- This is a comment. Comments in the XML do not appear in the
+   output formats. -->
+
+   <section><name>Terminology</name>
+
+   <t>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
+   <xref target='RFC2119'/>.</t>
+
+   </section>
+
+   </section>
+   <section anchor='protocol'><name>The Protocol Being Described</name>
+
+   <t>This is a reference to <xref target='RFC6949'/>.
+   Actually, the reference itself is not all that interesting, but the
+   way that the reference is incorporated is. Note that the inclusion
+   of RFC 2119 was done at the top of the XML, while the information
+   for RFC 6949 is done directly in the references section.</t>
+
+   <t>The <eref target='http://www.ietf.org'>IETF web site</eref> is
+   <em>quite</em>
+   <strong>nice</strong>,
+   <tt>isn't it</tt>?
+   Unlike other web sites, it doesn't use
+   gratuitous vertical space.</t>
+
+   </section>
+
+   <section><name>Basic Lists</name>
+
+   <t>Bulleted lists are good for items that
+   are not ordered:
+
+   </t><ul>
+
+   <li>This is the first item.</li>
+
+   <li>This is the second item. Here comes a sub-list:
+
+   <ul>
+
+   <li>This is the first sub-item.</li>
+
+   <li><t>This is the second sub-item</t><t>
+   and some more detail on the second sub-item.</t></li>
+
+   </ul></li>
+
+   <li>This is the item after the sub-list.</li>
+
+   </ul><t></t>
+
+   <t>Numbered lists are good for items that are ordered:
+
+   </t><ol style='1'>
+
+   <li>This is the first item.</li>
+
+   <li>This is the second item. Here comes a sub-list, but
+      with letters:
+
+   <ol style='a'>
+
+   <li>This is the first sub-item.</li>
+
+   <li>This is the second sub-item</li>
+
+   </ol></li>
+
+   <li>This is the item after the sub-list.</li>
+
+   </ol><t></t>
+
+   <t>And an example of hanging indent.
+
+   </t><dl hanging='true'>
+
+   <dt>Trees</dt><dd>These are bigger plants</dd>
+
+   <dt>Lichen</dt><dd>These are smaller plants</dd>
+
+   </dl><t></t>
+
+   <t>And the always-interesting "format" for lists.
+
+   </t><ol style='--%d--'>
+
+   <li>An element that gets a funny bullet.</li>
+
+   </ol><t></t>
+
+   </section>
+
+   <section><name>Figures</name>
+
+   <t>The following is a figure with a caption.
+   Also, it uses the ampersand (&amp;) and less than
+   (&lt;) characters in the example text.</t>
+
+   <figure anchor='haiku'><name>This could be haiku</name>
+   <artwork type='haiku' align='left'>
+      The ampersand (&amp;) and
+      less than (&lt;) are two characters
+      that need escaping.
+   </artwork>
+   </figure>
+   <t>Here are two short figures with no titles and with
+   odd alignment.</t>
+
+   <figure><artwork align='center'>
+   This might appear in the center.
+   </artwork></figure>
+
+   <figure><artwork align='right'>
+   This might appear right-aligned.
+   </artwork></figure>
+
+   <t>Here is a figure that is actually pulled from somewhere else.
+   <cref source='cs' anchor='rememberme'>
+   Remember to check whether that file still exists.</cref></t>
+
+   <figure><artwork
+   src='http://www.example.com/~employees/chrissmith/artwork.txt'>
+   </artwork>
+   </figure>
+
+   </section>
+
+   <section><name>Tables</name>
+
+   <t>The following is a table example.</t>
+
+   <t keepWithNext='true'>These are sometimes called "inert"
+   gasses.</t><table title='The Noble Gases'>
+
+     <tr><th>Name</th>
+     <th align='center'>Symbol</th>
+     <th align='center'>Atomic Number</th></tr>
+
+     <tr><td>Helium</td>
+     <td align='center'>He</td>
+     <td align='center'>2</td></tr>
+
+     <tr><td>Neon</td>
+     <td align='center'>Ne</td>
+     <td align='center'>10</td></tr>
+
+     <tr><td>Argon</td>
+     <td align='center'>Ar</td>
+     <td align='center'>18</td></tr>
+
+     <tr><td>Krypton</td>
+     <td align='center'>Kr</td>
+     <td align='center'>36</td></tr>
+     <tr><td>Xenon</td>
+     <td align='center'>Xe</td>
+     <td align='center'>54</td></tr>
+
+     <tr><td>Radon</td>
+     <td align='center'>Rn</td>
+     <td align='center'>86</td></tr>
+
+     </table><t keepWithPrevious='true'>Source: Chemistry 101</t>
+
+
+   <t>The following is a right-aligned table with "full"
+   (but not "all") lines between cells.</t>
+
+   <table align='right' style='full'>
+     <tr><th>Time</th>
+     <th align='right'>Mood</th></tr>
+
+     <tr><td>Morning</td>
+     <td align='right'>Happy!</td></tr>
+
+     <tr><td>Afternoon</td>
+     <td align='right'>Happy!</td></tr>
+
+     <tr><td>Evening</td>
+     <td align='right'>Somber</td></tr>
+
+   </table>
+
+   </section>
+
+   <section anchor='IANA'><name>IANA Considerations</name>
+
+   <t>None.</t>
+
+   </section>
+
+   <section anchor='Security'><name>Security Considerations</name>
+
+   <t>There are no security considerations for an imaginary
+   Internet Draft.</t>
+
+   </section>
+
+   <section anchor='Acknowledgements'><name>Acknowledgements</name>
+
+   <t>Some of the things included in this draft came from
+   Elwyn Davies' templates.</t>
+   </section>
+
+   </middle>
+
+   <back>
+
+   <references><name>Normative References</name>
+
+ <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
+<front>
+<title>
+Key words for use in RFCs to Indicate Requirement Levels
+</title>
+<author initials="S." surname="Bradner" fullname="S. Bradner">
+<organization/>
+</author>
+<date year="1997" month="March"/>
+<abstract>
+<t>
+In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="BCP" value="14"/>
+<seriesInfo name="RFC" value="2119"/>
+<seriesInfo name="DOI" value="10.17487/RFC2119"/>
+</reference>
+   </references>
+
+   <references><name>Informative References</name>
+
+   <reference anchor='RFC6949'>
+   <front>
+   <title>RFC Series Format Requirements and Future Development</title>
+   <author initials='H.' surname='Flanagan' fullname='H. Flanagan'>
+   <organization/></author>
+   <author initials='N.' surname='Brownlee' fullname='N. Brownlee'>
+   <organization/></author>
+   <date year='2013' month='May'/>
+   </front>
+   <seriesInfo name='RFC' value='6949'/>
+   <annotation>This is a primary reference work.</annotation>
+   </reference>
+
+   <reference anchor='RED'
+   target='http://www.aciri.org/floyd/papers/early.pdf'>
+   <front>
+   <title>Random Early Detection (RED) gateways for Congestion
+   Avoidance</title>
+   <author fullname='Sally Floyd' initials='S' surname='Floyd'>
+   <organization>LBL</organization>
+   </author>
+   <author fullname='Van Jacobson' initials='V' surname='Jacobson'>
+   <organization>LBL</organization>
+   </author>
+   <date month='August' year='1993'/>
+   </front>
+   <seriesInfo
+   name='IEEE/ACM Transactions on Networking' value='1(4) 397--413'/>
+
+   </reference>
+
+   </references>
+
+  </back>
+</rfc>

data/spec/examples/mib-doc-template-xml-06.adoc

@@ -20,6 +20,11 @@ Editor name <Editor email>
 :workgroup: Internet Engineering Task Force
 :keyword: Network Management,Management Information Base,MIB,SMIv2
 :smart-quotes: false
+:compact: yes
+:subcompact: no
+:rfcedstyle: yes
+:comments: yes
+:inline: yes
 
 [abstract]
 
@@ -343,7 +348,6 @@ Option #3:
 This memo includes no request to IANA.
 
 == Contributors
-NOTE: [TEMPLATE TODO] This optional section can be used to mention contributors to your internet draft.
 
 [bibliography]
 == Normative References

data/spec/examples/rfc2100.md.adoc

@@ -1,6 +1,6 @@
 = The Naming of Hosts
 Jay R. Ashworth <jra@scfn.thpl.lib.fl.us>
-:doctype: rfc
+:doctype: internet-draft
 :abbrev: The Naming of Hosts
 :status: info
 :name: rfc-2100
@@ -89,7 +89,6 @@ 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 Considerations
@@ -99,7 +98,7 @@ Security issues are not discussed in this memo.
 Particularly the cardiac security of certain famous poets.
 
 [bibliography]
-== References
+== Informative References
 ++++
 <reference anchor='libes' target=''>
  <front>

data/spec/examples/rfc3514.md.adoc

@@ -15,6 +15,7 @@ Steven M. Bellovin <bellovin@acm.org>
 :city: Florham Park
 :code: NJ 07932
 :smart-quotes: false
+:inline-definition-lists: true
 
 [abstract]
 Firewalls, packet filters, intrusion detection systems, and the like
@@ -59,7 +60,7 @@ The bit field is laid out as follows:
 
 Currently-assigned values are defined as follows:
 
-0x0:: 
+0x0: :: 
 +
 If the bit is set to 0, the packet has no evil intent.  Hosts,
     network elements, etc., **SHOULD** assume that the packet is
@@ -67,7 +68,7 @@ If the bit is set to 0, the packet has no evil intent.  Hosts,
     that this part of the spec is already implemented by many common
     desktop operating systems.)
 
-0x1:: 
+0x1: :: 
 +
 If the bit is set to 1, the packet has evil intent.  Secure
     systems **SHOULD** try to defend themselves against such packets.

data/spec/examples/rfc5841.md.adoc

@@ -155,7 +155,7 @@ 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 <<performance-considerations,Performance Considerations>>).
+performance cost (see <<performance-considerations>> "Performance Considerations").
 
 Each application **MUST** define the preconditions for marking packets as
 happy, sad, bored, confused, angry, apathetic, and so on.  This is a

data/spec/examples/rfc748.md.adoc

@@ -14,36 +14,37 @@ M. Crispin
 
 == Command name and code
 
+[align=center]
 ....
     RANDOMLY-LOSE    256
 ....
 
 == Command meanings
 
-IAC WILL RANDOMLY-LOSE::  
+IAC WILL RANDOMLY-LOSE: ::  
 +
 The sender of this command REQUESTS permission to, or confirms
 that it will, randomly lose.
 
-IAC WON'T RANDOMLY-LOSE::   
+IAC WON'T RANDOMLY-LOSE: ::   
 +
 The sender of this command REFUSES to randomly lose.
 
-IAC DO 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:: 
+IAC DON'T RANDOMLY-LOSE: :: 
 +
 The command sender DEMANDS that the receiver not randomly lose.
 
 == Default
 
 ....
-        WON'T RANDOMLY-LOSE
+    WON'T RANDOMLY-LOSE
 
-        DON'T RANDOMLY-LOSE
+    DON'T RANDOMLY-LOSE
 ....
 
 i.e., random lossage will not happen.