GitHub - metanorma/asciidoctor-rfc: AsciiRFC: an AsciiDoc/asciidoctor backend to produce RFC XML v3 (RFC 7991) and v2 (RFC 7749) (original) (raw)

The converter follows native AsciiDoc/asciidoctor syntax as much as possible, including built-in attributes and styles.

Extension commands are provided to fully support writing an Internet-Draft/RFC in AsciiDoc/asciidoctor syntax.

Document Type: rfc or internet-draft (Mandatory)

Set the doctype attribute to set status of this document:

:doctype: internet-draft sets the document as an Internet-Draft (default value):

• rfc/front/seriesInfo@name attribute will be set to Internet-Draft (in v3)
• rfc/front/seriesInfo@value will be set to the 📛 attribute, stripping any file suffixes, but including any draft number; e.g. draft-ietf-somewg-someprotocol-07 (in v3)
• rfc@docName will be set to the 📛 attribute (in v2)

:doctype: rfc sets the document as an RFC:

• rfc/front/seriesInfo@name attribute will be set to RFC (in v3)
• rfc/front/seriesInfo@value will be set to the 📛 attribute, stripping the initial rfc- prefix and any file suffixes (in v3)
• rfc@number will be set to the 📛 attribute (in v2)

Global Options

Any of these global options can also be included in the command line call, for either the asciidoctor executable or the local bin-stubs, through the command line option -a; e.g.

$ asciidoctor -a flush-biblio=true -b rfc3 -r 'asciidoctor-rfc' a.adoc $ ./bin/asciidoctor-rfc2 -a smart-quotes=false draft-example-00.adoc

Basic Document Attributes

asciidoctor-rfc allows setting the RFC XML document header using the following document attributes. Complying with AsciiDoc syntax, no blank lines are permitted between the title, listing of authors, and the document attributes. Also following AsciiDoc syntax, character entities will be ignored in the document header: `` in the header for example will be rendered as  .

Shared RFC XML v3/v2 syntax:

Processing Instructions

The xml2rfc tool accepts processing instructions of the form <?rfc keyword='value'?>: see https://xml2rfc.tools.ietf.org/authoring/README.html#processing.instructions . (Of these, sort-refs, sym-refs and toc-include are also present in the v3 RFC XML specifcation, as attributes of the root rfc element: v3-specific document attributes.) Those processing instructions which apply to the entire document can also be specified for this gem as document options.

keyword	meaning
artworkdelimiter	when producing txt or nroff files, use this string to delimit artwork
artworklines	when producing txt or nroff files, add this many blank lines around artwork
authorship	render author information
autobreaks	automatically force page breaks to avoid widows and orphans (not perfect)
background	when producing a html file, use this image
colonspace	put two spaces instead of one after each colon (":") in txt or nroff files
comments	render information
compact	when producing a txt/nroff file, try to conserve vertical whitespace (the default value is the current value of the rfcedstyle PI)
docmapping	use hierarchical tags (e.g., , , etc.) for (sub)section titles
editing	insert editing marks for ease of discussing draft versions
emoticonic	automatically replaces input sequences such as |*text
footer	override the center footer string
header	override the leftmost header string
inline	if comments is "yes", then render comments inline; otherwise render them in an "Editorial Comments" section
iprnotified	include boilerplate from Section 10.4(d) of http://tools.ietf.org/html/rfc2026
linkmailto	generate mailto: URL, as appropriate
linefile	a string like "35:file.xml" or just "35" (file name then defaults to the containing file’s real name or to the latest linefile specification that changed it) that will be used to override xml2rfc’s reckoning of the current input position (right after this PI) for warning and error reporting purposes (line numbers are 1-based)
notedraftinprogress	generates "(work in progress)", as appropriate
private	produce a private memo rather than an RFC or Internet-Draft
refparent	title of the top-level section containing all references
rfcedstyle	attempt to closely follow finer details from the latest observable RFC-Editor style so as to minimize the probability of being sent back corrections after submission; this directive is a kludge whose exact behavior is likely to change on a regular basis to match the current flavor of the month; presently, it will capitalize the adjective "This" in automatically generated headings, use the variant "acknowledgement" spelling instead of Merriam Webster’s main "acknowledgment" dictionary entry, use the "eMail" spelling instead of Knuth’s more modern "email" spelling, only put one blank line instead of two before top sections, omit "Intellectual Property and Copyright Statements" and "Author’s Address" from the table of content, and not limit the indentation to a maximum tag length in sections.
rfcprocack	if there already is an automatically generated Acknowledg(e)ment section, pluralize its title and add a short sentence acknowledging that xml2rfc was used in the document’s production to process an input XML source file in RFC-2629 format
slides	when producing a html file, produce multiple files for a slide show
sort-refs	(sortrefs) sort references
strict	try to enforce the ID-nits conventions and DTD validity
subcompact	if compact is "yes", then you can make things a little less compact by setting this to "no" (the default value is the current value of the compact PI)
sym-refs	(symrefs) use anchors rather than numbers for references
text-list-symbols	modify the list of symbols used (when generated text) for list type="symbols". For example, specifying "abcde" will cause "a" to be used for 1st level, "b" for the 2nd level, etc, cycling back to the first character "a" at the 6th level. Specifying "o*" will cause the characters "o" and "*" to be alternated for each successive level.
toc-include	(toc) generate a table-of-contents
tocappendix	control whether the word "Appendix" appears in the table-of-content
toc-depth	if toc is "yes", then this determines the depth of the table-of-contents
tocindent	if toc is "yes", then setting this to "yes" will indent subsections in the table-of-contents
tocnarrow	affects horizontal spacing in the table-of-content
tocompact	if toc is "yes", then setting this to "no" will make it a little less compact
topblock	put the famous header block on the first page
useobject	when producing a html file, use the html element with inner replacement content instead of the html element, when a source xml element includes an src attribute

Exceptionally, compact, toc-include, sym-refs, sort-refs and strict are is set by default to yes, subcompact to no, and toc-depth to 4.

The additional document option rfc2629xslt (default value: true) injects into the document header the processing instruction <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>, which impacts on the output of xml2rfc.

Document Name / Number (Mandatory)

The name attribute sets the document’s name. This should be a number if the document is an RFC, and a name (in the form of draft-ietf-somewg-someprotocol-07) if it is an Internet-Draft.

When doctype is set to:

• internet-draft: the value should be in the form draft-ietf-somewg-someprotocol-07.
  • v3: the front/seriesInfo@value will be set to this value.
  • v2: the rfc@docName will be set to this value.
• rfc: the value should be a number like 7991 as describedhere
  • v3: the front/seriesInfo@value will be set to this value.
  • v2: the rfc@number will be set to this value.

Document Status

Set the status attribute to set the current status of this document.

The following values are allowed: standard, informational, experimental, bcp, fyi,full-standard (v3 only), historic (v2 only).

• In v3, this sets the first front/seriesInfo element with @status as one of: standard, informational, experimental, bcp, fyi, full-standard.
• In v2, this sets the rfc@category value as one of std, info, exp, bcp, historic.

Intended Series

Set the intended-series attribute to set the intended series of this document.

The following values are allowed: standard, informational, experimental, bcp, fyi, full-standard.

When doctype is set to:

• internet-draft: this value can be one of standard, full-standard, bcp, fyi, informational,experimental, or historic to indicate the intended series once the document is published as an RFC.
  • In v3, this sets a second front/seriesInfo element with @status as one of those values, and an empty @name, to indicate this.
  • In v2, this sets the front@category value to one of std, bcp, info, exp, historic.
• rfc: this value can be either:
  • one of full-standard, bcp or fyi, to indicate the current status of this document, followed by the number of the document within the series; e.g. full-standard 1234, bcp 14.
  • exp, info, or historic. (experimental and informational will be accepted by the gem as synonyms.)
  • In v3, this sets a second front/seriesInfo element with @status as one of those values, and an empty @name, to indicate this.
  • In v2, this sets the front@category value to one of std, bcp, info. (While in v2, the values exp, historic are also possible for a RFC, our gem does not support it.)

Document Submission Type / Stream

Set document submission type via the submission-type document attribute.

The following values are allowed: IETF (default), independent, IAB, and IRTF.

• In v3, the rfc@submissionType and rfc/front/seriesInfo@stream attributes are set to this value.
• In v2, the rfc@submissionType is set to this value

Document Consensus

Set document consensus type via the consensus document attribute.

These values are accepted: false, true.

• In v3, this is the value set for the rfc@consensus attribute.
• In v2, this is the value set for the rfc@consensus attribute, but false is converted to no and true is converted to yes.

Document Language

Set the document language using the xml-lang document attribute.

By default this is en.

• In v3 and v2, this is the value set for the rfc@xml:lang attribute.

While v3 supports marking specific elements with their own xml:lang attribute, this is not yet supported by our gem.

Document Attributes for v2 only

These attributes are only supported for the v2 converter.

Document Attributes for v3 only

These attributes are only supported for the v3 converter.

Author Attributes

In an Internet-Draft/RFC, detailed information of an author is necessary, which is not supported by the normal AsciiDoc syntax.

You will need to provide the following information.

Multiple Author Names

Just like a normal AsciiDoc, you can provide author information in the author header (sample of 3 authors):

firstname middlename(s) lastname ; firstname middlename(s) lastname ; firstname middlename(s) lastname

These will be mapped as follows:

If any author names deviate from that pattern, e.g. with an honorific like Dr., they will not be recognised correctly by the Asciidoc API; use the fullnamedocument attribute instead.

Author Attributes

In asciidoctor-rfc, detailed author attributes are given as document attributes.

As multiple authors can be specified, the document attribute to specify the first author uses a unsuffixed attribute name :role, and the second author’s attributes onwards use a numeric suffix to identify the author: :role_2, :role_3, etc.

Shared RFC XML v3/v2 syntax:

Author Address

Only available for RFC XML v3:

Example. This source:

:street: 57 Mt Pleasant St\ Technology Park :city: Dullsville :region: NSW :country: Australia :code: 3333

Produces:

Abstract

Any paragraphs following the document header are treated as the abstract (front/abstract), whether or not they are in abstract style. The abstract is terminated by either the first section header (which ends the document preamble), or an admonition (e.g. note).

Any admonitions before the first section header are treated as notes (front/note).

[[abstract-id]] (1) [abstract] This is an abstract (2)

NOTE: This is a note (3)

[NOTE,remove-in-rfc=true] (4) .Note 2 Title (5)

This is another note (3)

1. v3 only: front/abstract@anchor (attribute only available in v3)
2. front/abstract
3. front/note
4. v3 only: front/note@removeInRFC (attribute only available in v3)
5. v3: front/note/name; v2: front/note@title (mandatory attribute; if not provided, NOTE is supplied)

Sections and Subsections

:sectnums: (1) [[id]] (2) [remove-in-rfc=true,toc=include|exclude|default] (3) == Section title (4) First paragraph of section (5)

Second paragraph of section (5)

:sectnums!: (6) === Subsection title (7) First paragraph of subsection (8)

==== Subsubsection title (9) Content content content (10)

1. middle/section@numbered=true (attribute only available in v3)
2. middle/section@anchor
3. v3 only: middle/section@removeInRFC, middle/section@toc (attributes only available in v3)
4. v3: middle/section/name; v2: middle/section@title
5. middle/section/t
6. middle/section@numbered=false (attribute only available in v3) (toggle)
7. v3: middle/section/section/name; v2: middle/section/section@title
8. middle/section/section/t
9. v3: middle/section/section/section/name; v2: middle/section/section/section@title
10. middle/section/section/section/t

Cross-References

Content content content <> (1) <<crossreference,text>> (2) <<crossreference,format=(counter|title|none|default): text>> (3) http://example.com/[linktext] (4) The following represent the v3 relref element <<crossreference,section_number (of|comma|parens|bare)>> (5) <<crossreference,section_number (of|comma|parens|bare): text>> (6) <<crossreference#fragment,section_number (of|comma|parens|bare)>> (7) <<crossreference#fragment,section_number (of|comma|parens|bare): text>> (8)

1. <xref target="crossreference"/>
2. <xref target="crossreference">text</xref>
3. <xref format="counter|title|none|default" target="crossreference">text</xref>
4. <eref href="http://example.com/">linktext</eref>
5. v3 only: <relref displayFormat="of|comma|parens|bare" section="section_number" target="crossreference"/> (element only available in v3)
6. v3 only: <relref displayFormat="of|comma|parens|bare" section="section_number" target="crossreference">text</relref> (element only available in v3)
7. v3 only: <relref relative="fragment" displayFormat="of|comma|parens|bare" section="section_number" target="crossreference"/> (element only available in v3)
8. v3 only: <relref relative="fragment" displayFormat="of|comma|parens|bare" section="section_number" target="crossreference">text</relref> (element only available in v3)

In v2, the relref style crossreferences are rendered as equivalent xref crossreferences, inserting section numbers as appropriate.

Note that fragments (e.g. crossreference#fragment) are not supported on the xref@target attribute, in either v2 or v3: the RFC XML specification requires that the xref@target attribute equals the value of an anchor attribute elsewhere in the document.

Internal crossreferences and bibliographic references are marked up in the same way; but bibliographic references are marked up separately from the main flow of Asciidoctor, and are processed later.

[[hash_whirlpool]] === WHIRLPOOL

The WHIRLPOOL hash function is defined in <>.

This section should actually be referenced as <>. ...

[bibliography] == Informative References ++++ ... ++++

Indexing

This (()) (1) is visible in the text, this one is not (((indexterm, index-subterm))). (2)

1. <iref item="indexterm">indexterm</iref>
2. <iref item="indexterm" subitem="index-subterm"/>

Inline formatting

Linebreak: + (1) Italic (2) Bold (3) Monospace (4) subscript (5) ^superscript^ (6) [bcp14]#MUST NOT# (7) MUST NOT (8) stem:[sqrt(4) = 2]

1. That is, "+ " at the end of a line. v3: <br/>; v2: <vspace/>.
2. v3: <em>Italic</em>; v2: <spanx style="emph">Italic</spanx>
3. v3: <strong>Bold</strong>; v2: <spanx style="strong">Bold</spanx>
4. v3: <tt>Monospace</tt>; v2: <spanx style="verb">Monospace</spanx>
5. v3 only: <sub>subscript</sub>. Not supported in v2; rendered as _subscript_
6. v3 only: <sup>superscript</sup>. Not supported in v2; rendered as ^superscript^
7. v3 only: <bcp14>MUST NOT</bcp14>. Not supported in v2; rendered as <spanx style="strong">MUST NOT</spanx>.
8. v3: if document flag :no-rfc-bold-bcp14: is present, then <strong>MUST NOT</strong>, else (by default) any BCP14/RFC2119 phrase in boldface and capitals is assumed to be intended to be tagged in <bcp14>. v2: <spanx style="strong">MUST NOT</spanx>.
9. Stem expressions are treated identically to monospace expressions; they are not currently rendered as MathML or any other notation.

Any formatting XML spans within spanx elements are stripped in postprocessing.

Paragraphs

[[id]] (1) [keep-with-next=true,keep-with-previous=true] (2) Paragraph text (3)

1. t@anchor
2. v3 only: t@keepWithNext, t@keepWithPrevious (attributes only available in v3)
3. <t>Paragraph text</t>

Quotes (v3 only)

[[id]] (1) [quote, attribution, citation info] (2) Quotation (3)

1. blockquote@anchor
2. blockquote@quotedFrom, blockquote@cite. In v3, citation info is limited to a URL.
3. <blockquote>Quotation</blockquote>

Comments

Asciidoctor comments

Asciidoctor implements both inline comments (prefixed with //) and block comments (prefixed with ////). Both are ignored by the Asciidoctor processor, and are not rendered in any output, including RFC XML.

Asciidoctor also permits paragraphs and open blocks (which can contain multiple paragraphs) to be treated as Asciidoctor comments, if they have the style attribute [comment]:

// This is an inline Asciidoctor comment, which will not be output to XML.

[comment] This is a single paragraph Asciidoctor comment, which will not be output to XML.

//// This is a block Asciidoctor comment,

which will not be output to XML. ////

[comment]

This is a

multiple paragraph

Asciidoctor comment, which will not be output to XML.

XML comments

XML inline comments may be introduced into XML through the [comment]formatting macro: any such comments may not span more than one line.

Text [comment]#This is a comment# Text

The foregoing will be rendered in RFC XML as:

Text Text

XML block comments are introduced through the role attribute[.comment], which can be prefied to a paragraph or an open block (which can contain multiple paragraphs):

[.comment] This is a single paragraph XML comment.

[.comment]

This is a

multiple paragraph

XML comment.

Text Comments

RFC XML provides for editorial comments which may optionally appear in the published text (subject to either the v3 cref@displayattribute, or the comments processing instruction).

In v2 RFC XML, comment text is stripped of all formatting.

NOTE: Any admonition inside the body of the text is a comment. (1) // Note that actual AsciiDoc comments are ignored by the converter.

[[id]] (2) [NOTE,display=true|false,source=name] (3) .Note Title (4)

Any admonition inside the body of the text is a comment.

1. <cref>Any admonition inside the body of the text is a comment.</cref>
2. cref@anchor
3. v3 only: cref@display (not supported in v2); v2: cref@source
4. v3 only: cref/name (not suppported in v2)

Source Code Listings

In RFC XML, sourcecode (v3) and artwork (v2) elements only occur within afigure wrapper; this gem supplies that wrapper if it is not provided explicitly.

Without Figure Wrapper

[[id]] (1) .Source code listing title (2) [source,type,src=uri,align,alt] (3)

begin() { source code listing (4) }

1. v3: figure/sourcecode@anchor; v2: figure@anchor (moved into supplied wrapper: anchors not supported on artwork)
2. v3: figure/sourcecode@name; v2: figure/artwork@name
3. v3: figure/sourcecode@type; figure/sourcecode@src (align and alt not supported). If src is present, the listing is not expected to have any content: content is taken from the hyperlink in the attribute. v2: figure/artwork@type, figure/artwork@src, figure/artwork@align, figure/artwork@alt.
4. v3: figure/sourcecode; v2: figure/artwork

With Figure Wrapper

[[id]] (1) [align,alt,suppress-title] (2) .Figure 1 (3)

Preamble text (4)

[[id1]] (5) .Source code listing title (6) [source,type,src=uri,align,alt] (7)

begin() { source code listing (8) }

Postamble text (9)

1. figure@anchor
2. v2 only: figure/artwork@align, figure/artwork@alt, figure@suppress-title (attributes only available in v2)
3. figure/name
4. v2 only: figure/preamble (only available in v2)
5. v3: figure/sourcecode@anchor; v2: Not supported: use figure@anchor
6. v3: figure/sourcecode@name; v2: figure/artwork@name
7. v3: figure/sourcecode@type; figure/sourcecode@src (align and alt not supported). If src is present, the listing is not expected to have any content: content is taken from the hyperlink in the attribute. v2: figure/artwork@type, figure/artwork@src, figure/artwork@align, figure/artwork@alt.
8. v3: figure/sourcecode; v2: figure/artwork
9. v2 only: figure/postamble (only available in v2)

ASCII Art and Images

In RFC XML, artwork elements only occur within afigure wrapper; this gem supplies that wrapper if it is not provided explicitly.

Ascii-Art Without Figure Wrapper

[[id]] (1) .Figure2.jpg (2) [align=left|center|right,alt=Ascii Art,type=text/plain] (3) ....

| Ascii Art | ------------------------ (4) ....

1. v3 only: figure/artwork@anchor; v2: figure@anchor (moved into supplied wrapper: anchors not supported on artwork)
2. figure/artwork@name
3. figure/artwork@align, figure/artwork@alt; figure@type (attribute only available in v2)
4. figure/artwork

Image Without Figure Wrapper

[[id]] (1) .Figure2.jpg (2) [align=left|center|right,alt=alt_text,type=img/jpeg] (3) image::filename.jpg[alt_text,700,200] (4)

1. v3 only: figure/artwork@anchor; v2: figure@anchor (moved into supplied wrapper: anchors not supported on artwork)
2. figure/artwork@name
3. figure/artwork@align, figure/artwork@alt; figure/artwork@type (only available in v2, intended to be a MIME type; v3: populated as either svg or binary-art depending on file suffix)
4. figure/artwork@src, figure/artwork@alt, figure/artwork@width (deprecated in v3), figure/artwork@height (deprecated in v3)

With Figure Wrapper

[[id]] (1) [align,alt,suppress-title] (2) .Figure 1 (3)

Preamble text (4)

[[id]] (5) .Figure2.jpg (8) [align=left|center|right,alt=alt_text,type=text/plain] (6) .... Figures are only permitted to contain listings (sourcecode), images (artwork), or literal (artwork) (7) .... [[id]] (5) .Figure2.jpg (8) [align=left|center|right,alt=alt_text,type=img/jpeg] (9) image::filename.jpg[alt_text,700,200] (10)

Postamble text (11)

1. figure@anchor
2. v2 only: figure/artwork@align, figure/artwork@alt, figure@suppress-title (attributes only available in v2)
3. figure/name
4. v2 only: figure/preamble (only available in v2)
5. v3: figure/artwork@anchor; v2: Not supported: use figure@anchor
6. figure/artwork@align, figure/artwork@alt; figure@type (attribute only available in v2)
7. figure/artwork
8. figure/artwork@name
9. figure/artwork@align, figure/artwork@alt; figure/artwork@type (only available in v2, intended to be a MIME type; v3: populated as either svg or binary-art depending on file suffix)
10. figure/artwork@src, figure/artwork@alt, figure/artwork@width (deprecated in v3), figure/artwork@height (deprecated in v3)
11. v2 only: figure/postamble (only available in v2)

Mathematical examples

In order for mathematical formatting to be recognised in Asciidoc, the document attribute :stem: needs to be set.

:stem:

[stem] ++++ sqrt(4) = 2 ++++

Mathematical examples are treated identically to literals, and are rendered as artwork in both v2 and v3; however their default alignment is set as center. As with inline stem expressions, they are treated identically to monospace expressions in the RFC XML output; they are not currently rendered as MathML or any other notation.

Unordered and Ordered Lists

[[id]] (1) [empty=true,spacing=normal|compact,hang-indent=n] (2)

• Unordered list 1 (3)
• Unordered list 2 (3) ** Nested list (4)

[[id]] (5) [spacing=compact,empty=true,start=n,group=n,counter=token,hang-indent=n,format=List #%d,arabic|loweralpha|upperralpha|lowerroman|upperroman] (6) . A (7) . B (7)

1. v3: ul@anchor; attribute only available in v3
2. v3: ul@empty, ul@spacing (hangIndent not available); v2: ul@style = empty, ul@hangIndent (spacing not available)
3. v2: list[@style="symbols"]/t; v3: ul/li
4. v2: list[@style="symbols"]/t/list[@style="symbols"]/t; v3: ul/li/ul/li
5. v3: ol@anchor; attribute only available in v3
6. v2: list/counter, list@hangIndent, list@style = format List %d, list@style (for arabic|loweralpha|upperralpha|lowerroman|upperroman) (spacing, start, empty and group not available) v3: ol@spacing, ol@empty, ol@start, ol@group, ol@type = "%d", `ol@type (for arabic|loweralpha|upperralpha|lowerroman|upperroman) (counter, hangIndent not available)
7. v2: list/t; v3: ol/li

Definition Lists

[[id]] (1) [horizontal,compact,hang-indent=n] (2) A:: B (3)

1. v3 only: dl@anchor (attribute only available in v3)
2. v3 only: dl@hanging, dl@spacing (attributes only available in v3); v2 only: list@hangIndent (attribute only available in v2). Note that the compact and horizontal attributes are mutually exclusive in AsciiDoc.
3. v3: dl/dt, dl/dd; v2: list[@style="hanging"]/t@hangText, list[@style="hanging"]/t

Tables

The converter respects the AsciiDoc (horizontal) align attributes of cells (v2, v3), column widths (v2), and colspan, rowspan attributes (v3).

(Exceptionally, column widths specified for v2 as "1,1,1,1,1,1…​." will be ignored, since Asciidoctor internally treats them identically to unspecified column widths on a table.)

[[id]] (1) [suppress-title=true|false,align=left|center|right,grid=all|cols|none|rows] (2) .Table Title (3) |=== |[[id]] head | head (4)

h|header cell | body cell (5) | | [[id]] body cell (6)

|foot | foot (7) |===

1. v3: table@anchor; v2: texttable@anchor
2. v2: texttable@suppress-title, texttable@align, texttable@style (attributes only available in v2). Mapping of Asciidoc grid attribute to RFC XML style attribute is: all > all, cols > full, none > none, rows > headers (although the two are not strictly equivalent).
3. v3: table/name; v2: texttable@title
4. v3: table/thead/tr/td; v2: texttable/ttcol@id (attribute only available in v2), texttable/ttcol
5. v3: table/tbody/tr/th, table/tbody/tr/td; v2: texttable/c, texttable/c
6. v3: table/tbody/tr/td@anchor (attribute only available in v3)
7. v3: table/tfoot/tr/td; v2: texttable/c

Sidebar (v3 only)

[[id]] (1)

Sidebar (2)

1. aside@anchor
2. <aside>Sidebar</aside>

References: Embedded in Document

References are expected to be provided in raw RFC XML v2 format. For v3, a list of crossreferences may precede the block of references, with alternative text. This will not be rendered, but it will be used to populate displayreference elements, mapping the reference anchors to display text. For example, a list entry [] means that any instances of the anchor ref1 should be displayed as alt1, and is rendered as <displayreference target="ref1" to="alt1"/>.

RFC requires two separate bibliographies, one for normative and one for informative references; either can be omitted. All bibliography sections in the must be styled with the prefix [bibliography], and must appear in sequence, before any appendices.

By default, the references cited must be included as raw RFC XML, and separated into the normative and informative sections.

[[id]] (1) [bibliography] == Normative References

• [[[ref1,alt1]]] (2) ++++ (raw XML) (3) ++++

[[id]] (1) [bibliography] == Informative References ++++ (raw XML) (2) ++++

1. back/references@anchor (only in v3)
2. back/displayreference@target, back/displayreference@to (only in v3)
3. back/references/reference

In postprocessing, bibliographic entries available from http://xml.resource.org/public/rfc are replaced with external references to that entry, using XML entities in RFC XML v2, and XML includes in RFC XML v3. Do not insert your own entities or XML includes into the references; the gem will have difficulty processing them.

References: External Directory

As an alternative, the document attribute :biblio-dir: can nominate a directory in which separate XML files can be placed, one for each reference to be included. (RFC XML v3 referencegroup elements will also be recognised as files.) The gem will read in from that directory only the files that have actually been cited, and insert them into the appropriate bibliography, without the references needing to be given under the bibliographies as above. (In fact, any XML already provided will be deleted.) By default, references will be considered informative; the document attribute :normative: can be used to specify a comma-delimited list of normative references.

The gem will issue a warning if any cited reference is not included in the directory. However, external references do not have to be included in the directory: they will be recognised by comparing their anchors against the external bibliography cache, and referenced as entities or includes. However, particular drafts of Internet-Draft documents do still need to be included as separate documents (see Lookup of external references.)

For example:

= The Holy Hand Grenade of Antioch Arthur Pendragon :doctype: internet-draft :workgroup: silly :biblio-dir: refs (1) :normative: RFC2119, AsciiDoc (1)

[[xyz]] == Hello Hello

• a <<RFC2119,2.3 of: See internet draft subsection>> (3)
• b <<I-D.abarth-cake>>
• b2 <<I-D.abarth-cake,what>>
• b1 <<I-D.abarth-cake,2.3 of: See internet draft subsection>> (3)
• c <<xyz,format=counter: xyzzy>> (4)
• d <> (4)
• e <<AsciiDoc,AsciiDoctor>>
• f <>

[[biblio]] === Biblio See biblio

[bibliography] == Normative References (5)

[bibliography] == Informative References (6)

1. The RFC XML references are included in the directory ./refs, with one file per reference. For example, we would expect it to contain a file corresponding to the reference mathrefs. A file corresponding to RFC2119 is optional, and in fact will be ignored, since the anchor is recognised as an external reference. A file corresponding to I-D.abarth-cake will not be ignored, if that file contains a seriesInfo element nominating a specific draft version.
2. The references in the ./refs directory are by default considered informative; this attribute indicates that RFC2119 and AsciiDoc are to be considered normative.
3. References are recognised in relref as well as xref elements.
4. The gem differentiates between bibliographic references and crossreferences to other anchors within the document.
5. The bibliographic headers need to be provided as above, and its titles are expected to be "Normative References" and "Informative References"; the gem will look for those titles specifically in order to insert the references it identifies from the file. However, no XML content is expected to be provided under each heading, and any XML content that is provided will be ignored.

Appendices

[[id]] (1) [appendix] == Appendix 1 (2) Content (3)

1. back/section@anchor
2. v3: back/section/name; v2: back/section@title
3. back/section/t

Unsupported RFC XML Elements

The following RFC XML v3/v2 elements are not (yet) supported through asciidoctor commands: