asciidoctor-rfc 0.8.0 → 0.8.2

data/spec/examples/refs-v2/asciidoctor-rfc.xml

@@ -0,0 +1,18 @@
+<reference  anchor='asciidoctor-rfc' target='https://github.com/riboseinc/asciidoctor-rfc/'>
+<front>
+  <title>asciidoctor-rfc lets you write Internet-Drafts and RFCs in AsciiDoc, the “asciidoctor-way”.</title>
+    <author>
+      <organization>Ribose Inc.</organization>
+      <address>
+        <postal>
+          <street></street>
+          <country>Hong Kong</country>
+        </postal>
+        <email>open.source@ribose.com</email>
+        <uri>https://www.ribose.com</uri>
+      </address>
+    </author>
+<date year='2017' month='November' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/asciidoctor.xml

@@ -0,0 +1,10 @@
+<reference  anchor='Asciidoctor' target='http://asciidoctor.org'>
+<front>
+  <title>Asciidoctor: A fast text processor &amp; publishing toolchain for converting AsciiDoc to HTML5, DocBook &amp; more.</title>
+<author initials='D.' surname='Allen' fullname='Dan Allen'><organization /></author>
+<author initials='R.' surname='Waldron' fullname='Ryan Waldron'><organization /></author>
+<author initials='S.' surname='White' fullname='Sarah White'><organization /></author>
+<date year='2017' month='November' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/draftr.xml

@@ -0,0 +1,8 @@
+<reference  anchor='draftr' target='https://ipv.sx/draftr/'>
+<front>
+<title>draftr: an HTML front-end to pandoc2rfc</title>
+<author initials='R.' surname='Barnes' fullname='Richard Barnes'><organization /></author>
+<date year='2017' month='Nov' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/kramdown-rfc2629.xml

@@ -0,0 +1,8 @@
+<reference  anchor='kramdown-rfc2629' target='https://github.com/cabo/kramdown-rfc2629'>
+<front>
+<title>kramdown-rfc2629: An RFC2629 (XML2RFC) backend for Thomas Leitner's kramdown markdown parser</title>
+<author initials='C.' surname='Bormann' fullname='Carsten Bormann'><organization /></author>
+<date year='2017' month='Nov' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/lyx2rfc.xml

@@ -0,0 +1,8 @@
+<reference  anchor='lyx2rfc' target='https://github.com/nicowilliams/lyx2rfc'>
+<front>
+  <title>LyX to I-D/RFC export by way of Lyx export to XHTML and XSLT conversion to xml2rfc schema</title>
+<author initials='N.' surname='Williams' fullname='Nico Williams'><organization /></author>
+<date year='2014' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/mmark.xml

@@ -0,0 +1,9 @@
+<reference  anchor='mmark' target='https://github.com/miekg/mmark'>
+<front>
+<title>Using mmark to create I-Ds and RFCs</title>
+<author initials='R.' surname='Gieben' fullname='R. (Miek) Gieben'><organization /></author>
+<date year='2015' month='June' />
+<abstract><t>This document describes an markdown variant called mmark [mmark] that can be used to create RFC documents.  The aim of mmark is to make writing document as natural as possible, while providing a lot of power on how to structure and layout the document.</t></abstract>
+</front>
+</reference>
+

data/spec/examples/refs-v2/pandoc2rfc.xml

@@ -0,0 +1,8 @@
+<reference  anchor='pandoc2rfc' target='https://github.com/miekg/pandoc2rfc'>
+<front>
+<title>pandoc2rfc: Use pandoc to create XML suitable for xml2rfc</title>
+<author initials='R.' surname='Gieben' fullname='R. (Miek) Gieben'><organization /></author>
+<date year='2012' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/reference.RFC.2119.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC2119'>
+<front>
+<title>Key words for use in RFCs to Indicate Requirement Levels</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.5385.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC5385'>
+<front>
+<title>Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.7328.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC7328'>
+<front>
+<title>Writing I-Ds and RFCs Using Pandoc and a Bit of XML</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.7749.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC7749'>
+<front>
+<title>The &quot;xml2rfc&quot; Version 2 Vocabulary</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.7763.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC7763'>
+<front>
+<title>The text/markdown Media Type</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.7764.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC7764'>
+<front>
+<title>Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.7990.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC7990'>
+<front>
+<title>RFC Format Framework</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v2/reference.RFC.7991.xml

@@ -0,0 +1,7 @@
+<reference  anchor='RFC7991'>
+<front>
+<title>The &quot;xml2rfc&quot; Version 3 Vocabulary</title>
+<author/>
+<date/>
+</front>
+</reference>

data/spec/examples/refs-v3-database.xml

@@ -0,0 +1,137 @@
+<references>
+<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>
+<reference anchor="RFC2629" target="https://www.rfc-editor.org/info/rfc2629">
+<front>
+<title>Writing I-Ds and RFCs using XML</title>
+<author initials="M." surname="Rose" fullname="M. Rose">
+<organization/>
+</author>
+<date year="1999" month="June"/>
+<abstract>
+<t>
+This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="2629"/>
+<seriesInfo name="DOI" value="10.17487/RFC2629"/>
+</reference>
+<reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552">
+<front>
+<title>
+Guidelines for Writing RFC Text on Security Considerations
+</title>
+<author initials="E." surname="Rescorla" fullname="E. Rescorla">
+<organization/>
+</author>
+<author initials="B." surname="Korver" fullname="B. Korver">
+<organization/>
+</author>
+<date year="2003" month="July"/>
+<abstract>
+<t>
+All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. 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="72"/>
+<seriesInfo name="RFC" value="3552"/>
+<seriesInfo name="DOI" value="10.17487/RFC3552"/>
+</reference>
+<reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc5226">
+<front>
+<title>
+Guidelines for Writing an IANA Considerations Section in RFCs
+</title>
+<author initials="T." surname="Narten" fullname="T. Narten">
+<organization/>
+</author>
+<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
+<organization/>
+</author>
+<date year="2008" month="May"/>
+<abstract>
+<t>
+Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
+</t>
+<t>
+In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
+</t>
+<t>
+This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="5226"/>
+<seriesInfo name="DOI" value="10.17487/RFC5226"/>
+</reference>
+<referencegroup anchor="RFC3552_5226">
+  <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552">
+<front>
+<title>
+Guidelines for Writing RFC Text on Security Considerations
+</title>
+<author initials="E." surname="Rescorla" fullname="E. Rescorla">
+<organization/>
+</author>
+<author initials="B." surname="Korver" fullname="B. Korver">
+<organization/>
+</author>
+<date year="2003" month="July"/>
+<abstract>
+<t>
+All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. 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="72"/>
+<seriesInfo name="RFC" value="3552"/>
+<seriesInfo name="DOI" value="10.17487/RFC3552"/>
+</reference>
+<reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc5226">
+<front>
+<title>
+Guidelines for Writing an IANA Considerations Section in RFCs
+</title>
+<author initials="T." surname="Narten" fullname="T. Narten">
+<organization/>
+</author>
+<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
+<organization/>
+</author>
+<date year="2008" month="May"/>
+<abstract>
+<t>
+Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
+</t>
+<t>
+In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
+</t>
+<t>
+This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="5226"/>
+<seriesInfo name="DOI" value="10.17487/RFC5226"/>
+</reference>
+</referencegroup>
+</references>

data/spec/examples/refs-v3.adoc

@@ -0,0 +1,57 @@
+= vCard Format Specification
+Simon Perreault <simon.perreault@viagenie.ca>
+:bibliography-database: refs-v3-database.xml
+:bibliography-passthrough: true
+:bibliography-prepend-empty: false
+:bibliography-hyperlinks: false
+:bibliography-style: rfc-v3
+:doctype: rfc
+:abbrev: IP Datagrams on Avian Carriers
+:obsoletes: 10, 120
+:updates: 2010, 2120
+:name: rfc-1149
+:status: full-standard 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
+:link: http://example1.com,http://example2.com author
+
+== Introduction
+The authors would like to thank Tim Howes, Mark Smith, and Frank
+Dawson, the original authors of cite:info[RFC2119] and cite:norm[RFC2629], Pete
+Resnick, who got this effort started and provided help along the way,
+as well as the following individuals who have participated in the
+drafting, review, and discussion of this memo:
+cite:info[RFC2119, text="<xref target='RFC2119'>RFC 2119</xref>"] 0
+cite:info[RFC2119, text="<xref format='counter' target='RFC2119'>RFC 2119</xref>"] 1
+cite:info[RFC2119, text="<relref displayFormat='comma' section='2.4' target='RFC2119'/>"] 2
+cite:info[RFC2119, text="<relref relative='section2_4' displayFormat='comma' section='2.4' target='RFC2119'/>"] 3
+cite:info[RFC3552_5226]
+
+[bibliography]
+== Normative References
+
+++++
+bibliography::norm[]
+++++
+
+[bibliography]
+== Informative References
+
+++++
+bibliography::info[]
+++++

data/spec/examples/refs-v3.xml

@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="US-ASCII"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+<?rfc strict="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc toc="yes"?>
+<?rfc tocdepth="4"?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes"?>
+<rfc ipr="trust200902" obsoletes="10, 120" updates="2010, 2120" submissionType="IETF" prepTime="2017-11-23T09:52:58Z" version="3">
+<link href="http://example1.com"/><link href="http://example2.com" rel="author"/>
+<front>
+  <title abbrev="IP Datagrams on Avian Carriers">vCard Format Specification</title>
+  <seriesInfo name="RFC" status="full-standard 1149" stream="IETF" value="1149"/>
+  <author fullname="Simon Perreault" surname="Perreault">
+    <organization>BBN STC</organization>
+    <address>
+      <postal>
+        <street>10 Moulton Street</street>
+        <city>Cambridge</city>
+        <code>MA 02238</code>
+      </postal>
+      <phone>(617) 873-4323</phone>
+      <email>simon.perreault@viagenie.ca</email>
+      <uri>http://bbn.com</uri>
+    </address>
+  </author>
+  <date day="1" month="April" year="1990"/>
+  <area>Internet</area>
+  <workgroup>Network Working Group</workgroup>
+  <keyword>this</keyword>
+  <keyword>that</keyword>
+
+</front><middle>
+<section anchor="_introduction" numbered="false">
+  <name>Introduction</name>
+  <t>The authors would like to thank Tim Howes, Mark Smith, and Frank
+Dawson, the original authors of <xref target="RFC2119"/> and <xref target="RFC2629"/>, Pete
+Resnick, who got this effort started and provided help along the way,
+as well as the following individuals who have participated in the
+drafting, review, and discussion of this memo:
+<xref target="RFC2119">RFC 2119</xref> 0
+<xref format="counter" target="RFC2119">RFC 2119</xref> 1
+<relref displayFormat="comma" section="2.4" target="RFC2119"/> 2
+<relref relative="section2_4" displayFormat="comma" section="2.4" target="RFC2119"/> 3</t>
+</section>
+</middle><back>
+<references anchor="_normative_references">
+  <name>Normative References</name>
+  <reference anchor="RFC2629" target="https://www.rfc-editor.org/info/rfc2629">
+<front>
+<title>Writing I-Ds and RFCs using XML</title>
+<author initials="M." surname="Rose" fullname="M. Rose">
+<organization/>
+</author>
+<date year="1999" month="June"/>
+<abstract>
+<t>
+This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="2629"/>
+<seriesInfo name="DOI" value="10.17487/RFC2629"/>
+</reference>
+</references>
+<references anchor="_informative_references">
+  <name>Informative 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>
+</back>
+</rfc>

data/spec/examples/refs-v3/AsciiDoc.xml

@@ -0,0 +1,8 @@
+<reference  anchor='AsciiDoc' target='http://www.methods.co.nz/asciidoc/'>
+<front>
+<title>AsciiDoc: Text based document generation</title>
+<author initials='S.' surname='Rackham' fullname='Stuart Rackham'><organization /></author>
+<date year='2013' month='November' />
+</front>
+</reference>
+