asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/davies-template-bare-06.xml.orig

@@ -0,0 +1,426 @@
+<?xml version="1.0" encoding="US-ASCII"?>
+<!-- This template is for creating an Internet Draft using xml2rfc,
+    which is available here: http://xml.resource.org. -->
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!-- One method to get references from the online citation libraries.
+    There has to be one entity for each item to be referenced. 
+    An alternate method (rfc include) is described in the references. -->
+
+<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
+<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
+<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
+]>
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+<!-- used by XSLT processors -->
+<!-- For a complete list and description of processing instructions (PIs), 
+    please see http://xml.resource.org/authoring/README.html. -->
+<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
+    (Here they are set differently than their defaults in xml2rfc v1.32) -->
+<?rfc strict="yes" ?>
+<!-- give errors regarding ID-nits and DTD validation -->
+<!-- control the table of contents (ToC) -->
+<?rfc toc="yes"?>
+<!-- generate a ToC -->
+<?rfc tocdepth="4"?>
+<!-- the number of levels of subsections in ToC. default: 3 -->
+<!-- control references -->
+<?rfc symrefs="yes"?>
+<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
+<?rfc sortrefs="yes" ?>
+<!-- sort the reference entries alphabetically -->
+<!-- control vertical white space 
+    (using these PIs as follows is recommended by the RFC Editor) -->
+<?rfc compact="yes" ?>
+<!-- do not start each main section on a new page -->
+<?rfc subcompact="no" ?>
+<!-- keep one blank line between list items -->
+<!-- end of list of popular I-D processing instructions -->
+<rfc category="info" docName="draft-ietf-xml2rfc-template-06" ipr="trust200902">
+ <!-- category values: std, bcp, info, exp, and historic
+    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
+       or pre5378Trust200902
+    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
+    they will automatically be output with "(if approved)" -->
+
+ <!-- ***** FRONT MATTER ***** -->
+
+ <front>
+   <!-- The abbreviated title is used in the page header - it is only necessary if the 
+        full title is longer than 39 characters -->
+
+   <title abbrev="Abbreviated Title">Put Your Internet Draft Title
+   Here</title>
+
+   <!-- add 'role="editor"' below for the editors if appropriate -->
+
+   <!-- Another author who claims to be an editor -->
+
+   <author fullname="Elwyn Davies" initials="E.B." role="editor"
+           surname="Davies">
+     <organization>Folly Consulting</organization>
+
+     <address>
+       <postal>
+         <street></street>
+
+         <!-- Reorder these if your country does things differently -->
+
+         <city>Soham</city>
+
+         <region></region>
+
+         <code></code>
+
+         <country>UK</country>
+       </postal>
+
+       <phone>+44 7889 488 335</phone>
+
+       <email>elwynd@dial.pipex.com</email>
+
+       <!-- uri and facsimile elements may also be added -->
+     </address>
+   </author>
+
+   <date year="2010" month="April" day="1"/>
+
+   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
+        in the current day for you. If only the current year is specified, xml2rfc will fill 
+	 in the current day and month for you. If the year is not the current one, it is 
+	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
+	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
+	 specify just the year. -->
+
+   <!-- Meta-data Declarations -->
+
+   <area>General</area>
+
+   <workgroup>Internet Engineering Task Force</workgroup>
+
+   <!-- WG name at the upperleft corner of the doc,
+        IETF is fine for individual submissions.  
+	 If this element is not present, the default is "Network Working Group",
+        which is used by the RFC Editor as a nod to the history of the IETF. -->
+
+   <keyword>template</keyword>
+
+   <!-- Keywords will be incorporated into HTML output
+        files in a meta tag but they have no effect on text or nroff
+        output. If you submit your draft to the RFC Editor, the
+        keywords will be used for the search engine. -->
+
+   <abstract>
+     <t>Insert an abstract: MANDATORY. This template is for creating an
+     Internet Draft.</t>
+   </abstract>
+ </front>
+
+ <middle>
+   <section title="Introduction">
+     <t>The original specification of xml2rfc format is in <xref
+     target="RFC2629">RFC&nbsp;2629</xref>.</t>
+
+     <section title="Requirements Language">
+       <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">RFC 2119</xref>.</t>
+     </section>
+   </section>
+
+   <section anchor="simple_list" title="Simple List">
+     <t>List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging',
+     'format'.</t>
+
+     <t><list style="symbols">
+         <t>First bullet</t>
+
+         <t>Second bullet</t>
+       </list> You can write text here as well.</t>
+   </section>
+
+   <section title="Figures">
+     <t>Figures should not exceed 69 characters wide to allow for the indent
+     of sections.</t>
+
+     <figure align="center" anchor="xml_happy">
+       <preamble>Preamble text - can be omitted or empty.</preamble>
+
+       <artwork align="left"><![CDATA[
++-----------------------+
+| Use XML, be Happy :-) |
+|_______________________|
+           ]]></artwork>
+
+       <postamble>Cross-references allowed in pre- and postamble. <xref
+       target="min_ref" />.</postamble>
+     </figure>
+
+     <t>The CDATA means you don't need to escape meta-characters (especially
+     &lt;&nbsp;(&amp;lt;) and &amp;&nbsp;(&amp;amp;)) but is not essential.
+     Figures may also have a title attribute but it won't be displayed unless
+     there is also an anchor. White space, both horizontal and vertical, is
+     significant in figures even if you don't use CDATA.</t>
+   </section>
+
+   <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
+
+   <?rfc needLines="8" ?>
+
+   <section title="Subsections and Tables">
+     <section title="A Subsection">
+       <t>By default 3 levels of nesting show in table of contents but that
+       can be adjusted with the value of the "tocdepth" processing
+       instruction.</t>
+     </section>
+
+     <section title="Tables">
+       <t>.. are very similar to figures:</t>
+
+       <texttable anchor="table_example" title="A Very Simple Table">
+         <preamble>Tables use ttcol to define column headers and widths.
+         Every cell then has a "c" element for its content.</preamble>
+
+         <ttcol align="center">ttcol #1</ttcol>
+
+         <ttcol align="center">ttcol #2</ttcol>
+
+         <c>c #1</c>
+
+         <c>c #2</c>
+
+         <c>c #3</c>
+
+         <c>c #4</c>
+
+         <c>c #5</c>
+
+         <c>c #6</c>
+
+         <postamble>which is a very simple example.</postamble>
+       </texttable>
+     </section>
+   </section>
+
+   <section anchor="nested_lists" title="More about Lists">
+     <t>Lists with 'hanging labels': the list item is indented the amount of
+     the hangIndent: <list hangIndent="8" style="hanging">
+         <t hangText="short">With a label shorter than the hangIndent.</t>
+
+         <t hangText="fantastically long label">With a label longer than the
+         hangIndent.</t>
+
+         <t hangText="vspace_trick"><vspace blankLines="0" />Forces the new
+         item to start on a new line.</t>
+       </list></t>
+
+     <!-- It would be nice to see the next piece (12 lines) all on one page. -->
+
+     <?rfc needLines="12" ?>
+
+     <t>Simulating more than one paragraph in a list item using
+     &lt;vspace&gt;: <list style="letters">
+         <t>First, a short item.</t>
+
+         <t>Second, a longer list item.<vspace blankLines="1" /> And
+         something that looks like a separate pararaph..</t>
+       </list></t>
+
+     <t>Simple indented paragraph using the "empty" style: <list
+         hangIndent="10" style="empty">
+         <t>The quick, brown fox jumped over the lazy dog and lived to fool
+         many another hunter in the great wood in the west.</t>
+       </list></t>
+
+     <section title="Numbering Lists across Lists and Sections">
+       <t>Numbering items continuously although they are in separate
+       &lt;list&gt; elements, maybe in separate sections using the "format"
+       style and a "counter" variable.</t>
+
+       <t>First list: <list counter="reqs" hangIndent="4" style="format R%d">
+           <t>#1</t>
+
+           <t>#2</t>
+
+           <t>#3</t>
+         </list> Specify the indent explicitly so that all the items line up
+       nicely.</t>
+
+       <t>Second list: <list counter="reqs" hangIndent="4" style="format R%d">
+           <t>#4</t>
+
+           <t>#5</t>
+
+           <t>#6</t>
+         </list></t>
+     </section>
+
+     <section title="Where the List Numbering Continues">
+       <t>List continues here.</t>
+
+       <t>Third list: <list counter="reqs" hangIndent="4" style="format R%d">
+           <t>#7</t>
+
+           <t>#8</t>
+
+           <t>#9</t>
+
+           <t>#10</t>
+         </list> The end of the list.</t>
+     </section>
+   </section>
+
+   <section anchor="codeExample"
+            title="Example of Code or MIB Module To Be Extracted">
+     <figure>
+       <preamble>The &lt;artwork&gt; element has a number of extra attributes
+       that can be used to substitute a more aesthetically pleasing rendition
+       into HTML output while continuing to use the ASCII art version in the
+       text and nroff outputs (see the xml2rfc README for details). It also
+       has a "type" attribute. This is currently ignored except in the case
+       'type="abnf"'. In this case the "artwork" is expected to contain a
+       piece of valid Augmented Backus-Naur Format (ABNF) grammar. This will
+       be syntax checked by xml2rfc and any errors will cause a fatal error
+       if the "strict" processing instruction is set to "yes". The ABNF will
+       also be colorized in HTML output to highlight the syntactic
+       components. Checking of additional "types" may be provided in future
+       versions of xml2rfc.</preamble>
+
+       <artwork><![CDATA[
+
+/**** an example C program */
+
+#include <stdio.h>
+
+void
+main(int argc, char *argv[])
+{
+   int i;
+
+   printf("program arguments are:\n");
+   for (i = 0; i < argc; i++) {
+       printf("%d: \"%s\"\n", i, argv[i]);
+   }
+
+   exit(0);
+} /* main */
+
+/* end of file */
+
+           ]]></artwork>
+     </figure>
+   </section>
+
+   <section anchor="Acknowledgements" title="Acknowledgements">
+     <t>This template was derived from an initial version written by Pekka
+     Savola and contributed by him to the xml2rfc project.</t>
+
+     <t>This document is part of a plan to make xml2rfc indispensable <xref
+     target="DOMINATION"></xref>.</t>
+   </section>
+
+   <!-- Possibly a 'Contributors' section ... -->
+
+   <section anchor="IANA" title="IANA Considerations">
+     <t>This memo includes no request to IANA.</t>
+
+     <t>All drafts are required to have an IANA considerations section (see
+     <xref target="RFC5226">Guidelines for Writing an IANA Considerations Section in RFCs</xref> for a guide). If the draft does not require IANA to do
+     anything, the section contains an explicit statement that this is the
+     case (as above). If there are no requirements for IANA, the section will
+     be removed during conversion into an RFC by the RFC Editor.</t>
+   </section>
+
+   <section anchor="Security" title="Security Considerations">
+     <t>All drafts are required to have a security considerations section.
+     See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
+   </section>
+ </middle>
+
+ <!--  *****BACK MATTER ***** -->
+
+ <back>
+   <!-- References split into informative and normative -->
+
+   <!-- There are 2 ways to insert reference entries from the citation libraries:
+    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
+    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
+       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
+
+    Both are cited textually in the same manner: by using xref elements.
+    If you use the PI option, xml2rfc will, by default, try to find included files in the same
+    directory as the including file. You can also define the XML_LIBRARY environment variable
+    with a value containing a set of directories to search.  These can be either in the local
+    filing system or remote ones accessed by http (http://domain/dir/... ).-->
+
+   <references title="Normative References">
+     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
+     &RFC2119;
+
+     <reference anchor="min_ref">
+       <!-- the following is the minimum to make xml2rfc happy -->
+
+       <front>
+         <title>Minimal Reference</title>
+
+         <author initials="authInitials" surname="authSurName">
+           <organization></organization>
+         </author>
+
+         <date year="2006" />
+       </front>
+     </reference>
+   </references>
+
+   <references title="Informative References">
+     <!-- Here we use entities that we defined at the beginning. -->
+
+     &RFC2629;
+
+     &RFC3552;
+
+     &RFC5226;
+
+     <!-- A reference written by by an organization not a person. -->
+
+     <reference anchor="DOMINATION"
+                target="http://www.example.com/dominator.html">
+       <front>
+         <title>Ultimate Plan for Taking Over the World</title>
+
+         <author>
+           <organization>Mad Dominators, Inc.</organization>
+         </author>
+
+         <date year="1984" />
+       </front>
+     </reference>
+   </references>
+
+   <section anchor="app-additional" title="Additional Stuff">
+     <t>This becomes an Appendix.</t>
+   </section>
+
+   <!-- Change Log
+
+v00 2006-03-15  EBD   Initial version
+
+v01 2006-04-03  EBD   Moved PI location back to position 1 -
+                     v3.1 of XMLmind is better with them at this location.
+v02 2007-03-07  AH    removed extraneous nested_list attribute,
+                     other minor corrections
+v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
+                     Modified comments around figure to reflect non-implementation of
+                     figure indent control.  Put in reference using anchor="DOMINATION".
+                     Fixed up the date specification comments to reflect current truth.
+v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
+                     added discussion of rfc include.
+v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
+                     images. Removed meta-characters from comments (causes problems).
+
+v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
+                     year only, to be consistent with the comments. Updated the 
+                     IANA guidelines reference from the I-D to the finished RFC.  -->
+ </back>
+</rfc>

data/spec/examples/example-v2.adoc

@@ -0,0 +1,181 @@
+= RFC XML v2 Example: A Standard for the Transmission of IP Datagrams on Avian Carriers
+David Waitzman <dwaitzman@BBN.COM>; Nick Nicholas <opoudjis@gmail.com>
+:doctype: rfc
+:abbrev: IP Datagrams on Avian Carriers
+:obsoletes: 10, 120
+:updates: 2010, 2120
+:status: info
+:name: rfc-1149
+:ipr: trust200902
+:area: Internet
+:workgroup: Network Working Group
+:keyword: this, that
+:revdate: 1990-04-01T00:00:00Z
+:organization: BBN STC
+:phone: (617) 873-4323
+:uri: http://bbn.com
+:street: 10 Moulton Street
+:city: Cambridge
+:code: MA 02238
+:organization_2: BBN STC
+:phone_2: (617) 873-4323
+:street_2: 10 Moulton Street
+:city_2: Cambridge
+:code_2: MA 02238
+:uri_2: http://opoudjis.net
+
+[abstract]
+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.
+
+NOTE: Yes, this is an April Fool's RFC.
+
+[[frame]]
+== 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.<<RFC7253,alt>>
+
+Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.<<RFC7253>>
+
+This document extends OpenPGP and its ECC extension to support SM2, SM3 and SM4:
+
+* support the SM3 hash algorithm for data validation purposes
+* support signatures utilizing the combination of SM3 with other digital
+  signing algorithms, such as RSA, ECDSA and SM2
+* support the SM2 asymmetric encryption algorithm for public key
+  operations
+* support usage of SM2 in combination with supported hash algorithms, such as
+  SHA-256 and SM3
+* support the SM4 symmetric encryption algorithm for data protection purposes
+* defines the OpenPGP profile "OSCCA-SM234" to enable usage of OpenPGP
+  in an OSCCA-compliant manner.
+
+Algorithm-Specific Fields for SM2DSA keys:
+
+* a variable-length field containing a curve OID, formatted
+  as follows:
+.. a one-octet size of the following field; values 0 and
+   0xFF are reserved for future extensions
+.. octets representing a curve OID.
+*  MPI of an EC point representing a public key
+
+
+===  Definitions
+
+OSCCA-compliant:: All cryptographic algorithms used are compliant with OSCCA  regulations.
+SM2DSA:: The elliptic curve digital signature algorithm. <<ISO.IEC.10118-3>>
+SM2KEP:: The elliptic curve key exchange protocol.
+SM2PKE:: The public key encryption algorithm.
+
+==== Elliptic Curve Formula
+
+[stem]
+++++
+y^2 = x^3 + ax + b
+++++
+
+==== Curve Parameters
+
+[[curveparam1]]
+.Curve Parameters Listing
+====
+....
+p   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+      FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
+a   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+      FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
+b   = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
+      F39789F5 15AB8F92 DDBCBD41 4D940E93
+n   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+      7203DF6B 21C6052B 53BBF409 39D54123
+x_G = 32C4AE2C 1F198119 5F990446 6A39C994
+      8FE30BBF F2660BE1 715A4589 334C74C7
+y_G = BC3736A2 F4F6779C 59BDCEE3 6B692153
+      D0A9877C C62A4740 02DF32E5 2139F0A0
+....
+====
+
+== Supported Algorithms
+
+=== Public Key Algorithms
+
+The SM2 algorithm is supported with the following extension.
+
+NOTE: ECDH is defined in Section 8 of this document.
+
+The following public key algorithm IDs are added to expand Section
+9.1 of RFC4880, "Public-Key Algorithms":
+
+.Table 2
+|===
+|ID | Description of Algorithm
+
+|TBD | SM2
+|===
+
+
+
+== 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.<<RFC7253>>, <<ISO.IEC.10118-3>>
+
+[bibliography]
+== References
+++++
+<reference anchor='ISO.IEC.10118-3' target='https://www.iso.org/standard/67116.html'>
+  <front>
+    <title>ISO/IEC FDIS 10118-3 -- Information technology -- Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions</title>
+    <author>
+      <organization>International Organization for Standardization</organization>
+      <address>
+        <postal>
+          <street>BIBC II</street>
+          <street>Chemin de Blandonnet 8</street>
+          <street>CP 401</street>
+          <city>Vernier</city>
+          <region>Geneva</region>
+          <code>1214</code>
+          <country>Switzerland</country>
+        </postal>
+        <phone>+41 22 749 01 11</phone>
+        <email>central@iso.org</email>
+        <uri>https://www.iso.org/</uri>
+      </address>
+    </author>
+    <date day='15' month='September' year='2017'/>
+  </front>
+</reference>
+
+<reference anchor='RFC7253' target='https://tools.ietf.org/html/rfc7253'>
+  <front>
+    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
+    <author initials="T." surname="Krovetz">
+      <organization>Sacramento State</organization>
+    </author>
+    <author initials="P." surname="Rogaway">
+      <organization>UC Davis</organization>
+    </author>
+    <date month='May' year='2014'/>
+  </front>
+  <seriesInfo name="RFC" value="7253"/>
+</reference>
+++++