asciidoctor-rfc 0.8.0 → 0.8.2

data/spec/examples/draft-ietf-core-block-xx.mkd.adoc

@@ -30,6 +30,8 @@ Carsten Bormann <cabo@tzi.org>; Zach Shelby <zach@sensinode.com>
 :phone_2: +358407796297
 :email_2: zach@sensinode.com
 :inline-definition-lists: true
+:rfc2629xslt: true
+:compact: no
 
 [abstract]
 CoAP is a RESTful transfer protocol for constrained nodes and networks.
@@ -97,8 +99,8 @@ UDP), but the fragmentation/reassembly process loads the lower layers
 with conversation state that is better managed in the application
 layer.
 
-This specification defines a pair of CoAP options to enable *block-wise* access to
-resource representations.
+This specification defines a pair of CoAP options to enable 
+_block-wise_ access to resource representations.
 The Block options provide a minimal way to transfer larger
 resource representations in a block-wise fashion.
 The overriding objective is to avoid
@@ -285,7 +287,7 @@ M: :: More Flag (not last block). For descriptive usage, this flag, if
   below.)
 
 SZX: :: Block Size. The block size is a three-bit unsigned integer indicating the size of a block to
-  the power of two. Thus block size = 2\\**(SZX + 4).  The allowed
+  the power of two. Thus block size = 2&#42;&#42;(SZX + 4).  The allowed
   values of SZX are 0 to 6, i.e., the minimum block size is 2&#42;&#42;(0+4) = 16
   and the maximum is 2&#42;&#42;(6+4) = 1024.
   The value 7 for SZX (which would indicate a block size of 2048) is
@@ -771,8 +773,8 @@ Numbers registry of
 |===
 | Number | Name   | Reference 
 
-|     17 | Block2 | <<RFCXXXX>> 
-|     19 | Block1 | <<RFCXXXX>> 
+|     17 | Block2 | [RFCXXXX]
+|     19 | Block1 | [RFCXXXX]
 |===
 
 This draft adds the following response code to the CoAP Response Codes registry of
@@ -784,7 +786,7 @@ This draft adds the following response code to the CoAP Response Codes registry
 |===
 | Code | Description                    | Reference 
 
-|  136 | 4.08 Request Entity Incomplete | <<RFCXXXX>> 
+|  136 | 4.08 Request Entity Incomplete | [RFCXXXX]
 |===
 
 
@@ -951,33 +953,6 @@ The Constrained Application Protocol (CoAP) is a specialized web transfer protoc
 <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt"/>
 </reference>
 
-<reference anchor="RFCXXXX" target="https://www.rfc-editor.org/info/rfc7959">
-<front>
-<title>
-Block-Wise Transfers in the Constrained Application Protocol (CoAP)
-</title>
-<author initials="C." surname="Bormann" fullname="C. Bormann">
-<organization/>
-</author>
-<author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
-<organization/>
-</author>
-<date year="2016" month="August"/>
-<abstract>
-<t>
-The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
-</t>
-<t>
-Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
-</t>
-<t>
-A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.
-</t>
-</abstract>
-</front>
-<seriesInfo name="RFC" value="7959"/>
-<seriesInfo name="DOI" value="10.17487/RFC7959"/>
-</reference>
 ++++
 
 [bibliography]

data/spec/examples/hoffmanv2.xml.adoc

@@ -28,6 +28,10 @@ Chris Smith <chrissmith@example.com>; Kim Jones <jk@lmn.op>
 :keyword: XML, Imagination
 :inline-definition-lists: true
 :toc-include: false
+:compact: no
+:subcompact: no
+:strict: yes
+:rfc2629xslt: true
 
 [abstract]
 This is an example of an abstract.  It is a short paragraph that

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

@@ -5,10 +5,10 @@ Editor name <Editor email>
 :name: Your MIB Document name here rev07
 :ipr: trust200902
 :abbrev: Your MIB Module document name
-:fullname: Editor name
+:fullname: Editor Name
+:lastname: Name
 :forename_initials: Y
 :role: editor
-:surname: Name
 :organization: Editor affiliation
 :street: Editor affiliation address
 :city: Editor affiliation address
@@ -28,8 +28,6 @@ Editor name <Editor email>
 
 [abstract]
 
-(In RFC XML v2, an absract cannot begin with a note!)
-
 [[CREF1: This template is for authors of IETF specifications containing MIB
   modules.  This template can be used as a starting point to produce
   specifications that comply with the Operations & Management Area
@@ -66,9 +64,9 @@ For updated information on MIB module guidelines and templates, see
 <<RFC4181>> and the OPS Area web page and wiki.
 
 For information on writing internet drafts or RFCs, see
-http://www.ietf.org/ietf/1id-guidelines.txt and 
+\http://www.ietf.org/ietf/1id-guidelines.txt and 
 RFC2223(bis) <<RFC2223>>, and look
-at http://www.ietf.org/ID-Checklist.html for issues to note when writing
+at \http://www.ietf.org/ID-Checklist.html for issues to note when writing
 drafts.
 
 This template is not meant to be a complete list of everything
@@ -85,7 +83,7 @@ and IESG review processes.
 
 An XML2RFC template is also available. For information on XML2RFC, see
 RFC2629 <<RFC2629>>, and documentation available at
-http://xml.resource.org. The XML2RFC version includes
+\http://xml.resource.org. The XML2RFC version includes
 advice describing how to fill in each section of the template. XML2RFC generates the 
 actual internet-draft from your information, and automatically handles getting up-to-date 
 boilerplates, references, and it handles many idnits issues.
@@ -312,7 +310,7 @@ SET (change/create/delete) them.
 
 == IANA Considerations
 [[CREF22: [TEMPLATE TODO] In order to comply with IESG policy as set forth in
-http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is
+\http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is
 submitted to the IESG for publication MUST contain an IANA
 Considerations section. The requirements for this section vary depending
 what actions are required of the IANA. See "Guidelines for Writing an IANA 

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

@@ -0,0 +1,86 @@
+<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>
+</references>

data/spec/examples/refs-v2.adoc

@@ -0,0 +1,49 @@
+= vCard Format Specification
+Simon Perreault <simon.perreault@viagenie.ca>
+:bibliography-database: refs-v2-database.xml
+:bibliography-passthrough: true
+:bibliography-prepend-empty: false
+:bibliography-hyperlinks: false
+:bibliography-style: rfc-v2
+:doctype: rfc
+:obsoletes: 2425, 2426, 4770
+:updates: 2739
+:name: rfc-6350
+:revdate: 20110831
+:submission-type: IETF
+:status: standard
+:intended-series: full-standard 6350
+:fullname: Simon Perreault
+:lastname: Perreault
+:organization: Viagenie
+:email: simon.perreault@viagenie.ca
+:street: 2875 Laurier, suite D2-630
+:region: Quebec, QC  
+:code: G1V 2M2
+:country: Canada
+:phone: +1 418 656 9254
+:uri: http://www.viagenie.ca
+:link: urn:issn:2070-1721 item
+
+== 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>"]
+cite:info[RFC2119, text="<xref format='counter' target='RFC2119'>RFC 2119</xref>"]
+
+[bibliography]
+== Normative References
+
+++++
+bibliography::norm[]
+++++
+
+[bibliography]
+== Informative References
+
+++++
+bibliography::info[]
+++++

data/spec/examples/refs-v2.xml

@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="US-ASCII"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY RFC2629 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
+<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
+]>
+<?rfc strict="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc toc="yes"?>
+<?rfc tocdepth="4"?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes"?>
+<rfc obsoletes="2425, 2426, 4770" updates="2739" category="std" submissionType="IETF" number="rfc-6350">
+<front>
+  <title>vCard Format Specification</title>
+  <author fullname="Simon Perreault" surname="Perreault">
+    <organization>Viagenie</organization>
+    <address>
+      <postal>
+        <street>2875 Laurier, suite D2-630</street>
+        <region>Quebec, QC</region>
+        <code>G1V 2M2</code>
+        <country>Canada</country>
+      </postal>
+      <phone>+1 418 656 9254</phone>
+      <email>simon.perreault@viagenie.ca</email>
+      <uri>http://www.viagenie.ca</uri>
+    </address>
+  </author>
+  <date day="31" month="August" year="2011"/>
+
+</front><middle>
+<section anchor="_introduction" title="Introduction">
+  <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>
+<xref format="counter" target="RFC2119">RFC 2119</xref></t>
+</section>
+</middle><back>
+<references title="Normative References">
+ &RFC2629;
+</references>
+<references title="Informative References">
+ &RFC2119;
+</references>
+</back>
+</rfc>

data/spec/examples/refs-v2/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>
+

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

@@ -0,0 +1,8 @@
+<reference  anchor='AsciiMathML' target='http://asciimath.org'>
+<front>
+  <title>AsciiMath is an easy-to-write markup language for mathematics.</title>
+<author/>
+<date year='2017' month='November' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/IETF-BibXML.xml

@@ -0,0 +1,9 @@
+<reference  anchor='IETF-BibXML' target='http://xml.resource.org/public/rfc/bibxml/'>
+<front>
+<title>IETF BibXML Library</title>
+<author/>
+<date year='2017' month='November' />
+</front>
+</reference>
+
+

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

@@ -0,0 +1,8 @@
+<reference  anchor='MathJax' target='https://www.mathjax.org'>
+<front>
+  <title>MathJax: A JavaScript display engine for mathematics that works in all browsers.</title>
+<author/>
+<date year='2017' month='November' />
+</front>
+</reference>
+

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

@@ -0,0 +1,8 @@
+<reference  anchor='NroffEdit' target='http://aaa-sec.com/nroffedit/'>
+<front>
+<title>WYSIWYG Internet-Draft Nroff Editor</title>
+<author initials='S.' surname='Santesson' fullname='Stefan Santesson'><organization /></author>
+<date year='2011' month='May' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/TeX-LaTeX.xml

@@ -0,0 +1,8 @@
+<reference  anchor='TeX-LaTeX' target='https://www.latex-project.org'>
+<front>
+  <title>LaTeX is document preparation software that runs on top of Donald E. Knuth's TeX typesetting system.</title>
+<author/>
+<date year='2017' month='November' />
+</front>
+</reference>
+

data/spec/examples/refs-v2/abarth

@@ -0,0 +1,17 @@
+<reference anchor="I-D.abarth-cake">
+<front>
+<title>Simple HTTP State Management Mechanism</title>
+<author initials="A" surname="Barth" fullname="Adam Barth">
+<organization/>
+</author>
+<date month="August" day="22" year="2010"/>
+<abstract>
+<t>
+This document describes a simple HTTP state management mechanism, called cake, that lets HTTP servers maintain stateful sessions with HTTP user agents. This mechanism is harmonized with the same-origin security model and provides both confidentiality and integrity protection against active network attackers. In addition, the mechanism is robust to cross-site request forgery attacks.Editorial Note (To be removed by RFC Editor) If you have suggestions for improving this document, please send email to <mailto:http-state@ietf.org>. Further Working Group information is available from <https://tools.ietf.org/wg/httpstate/>.
+</t>
+</abstract>
+</front>
+<seriesInfo name="Internet-Draft" value="draft-abarth-cake-00"/>
+<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-abarth-cake-00.txt"/>
+</reference>
+

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

@@ -0,0 +1,19 @@
+<reference  anchor='asciidoctor-bibliography' target='https://github.com/riboseinc/asciidoctor-bibliography/'>
+<front>
+  <title>Citations and Bibliography 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-manual.xml

@@ -0,0 +1,11 @@
+<reference  anchor='Asciidoctor-Manual' target='http://asciidoctor.org/docs/user-manual/'>
+<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>
+
+