From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc7991.txt | 8459 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 8459 insertions(+)
 create mode 100644 doc/rfc/rfc7991.txt

(limited to 'doc/rfc/rfc7991.txt')

diff --git a/doc/rfc/rfc7991.txt b/doc/rfc/rfc7991.txt
new file mode 100644
index 0000000..603fc1a
--- /dev/null
+++ b/doc/rfc/rfc7991.txt
@@ -0,0 +1,8459 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                             P. Hoffman
+Request for Comments: 7991                                         ICANN
+Obsoletes: 7749                                            December 2016
+Category: Informational
+ISSN: 2070-1721
+
+
+                   The "xml2rfc" Version 3 Vocabulary
+
+Abstract
+
+   This document defines the "xml2rfc" version 3 vocabulary: an
+   XML-based language used for writing RFCs and Internet-Drafts.  It is
+   heavily derived from the version 2 vocabulary that is also under
+   discussion.  This document obsoletes the v2 grammar described in
+   RFC 7749.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7991.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 1]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................5
+      1.1. Expected Updates to the Specification ......................5
+      1.2. Design Criteria for the Changes in v3 ......................6
+      1.3. Differences from v2 to v3 ..................................6
+           1.3.1. New Elements in v3 ..................................6
+           1.3.2. New Attributes for Existing Elements ................7
+           1.3.3. Elements and Attributes Deprecated from v2 ..........8
+           1.3.4. Additional Changes from v2 ..........................9
+      1.4. Syntax Notation ...........................................10
+   2. Elements .......................................................10
+      2.1. <abstract> ................................................11
+      2.2. <address> .................................................12
+      2.3. <annotation> ..............................................12
+      2.4. <area> ....................................................13
+      2.5. <artwork> .................................................13
+      2.6. <aside> ...................................................17
+      2.7. <author> ..................................................18
+      2.8. <back> ....................................................19
+      2.9. <bcp14> ...................................................20
+      2.10. <blockquote> .............................................20
+      2.11. <boilerplate> ............................................22
+      2.12. <br> .....................................................22
+      2.13. <city> ...................................................22
+      2.14. <code> ...................................................22
+      2.15. <country> ................................................23
+      2.16. <cref> ...................................................23
+      2.17. <date> ...................................................24
+      2.18. <dd> .....................................................25
+      2.19. <displayreference> .......................................27
+      2.20. <dl> .....................................................27
+      2.21. <dt> .....................................................29
+      2.22. <em> .....................................................30
+      2.23. <email> ..................................................31
+      2.24. <eref> ...................................................31
+      2.25. <figure> .................................................32
+      2.26. <front> ..................................................34
+      2.27. <iref> ...................................................35
+      2.28. <keyword> ................................................36
+      2.29. <li> .....................................................36
+      2.30. <link> ...................................................38
+      2.31. <middle> .................................................39
+      2.32. <name> ...................................................39
+      2.33. <note> ...................................................39
+      2.34. <ol> .....................................................40
+      2.35. <organization> ...........................................42
+
+
+
+
+Hoffman                       Informational                     [Page 2]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      2.36. <phone> ..................................................43
+      2.37. <postal> .................................................43
+      2.38. <postalLine> .............................................44
+      2.39. <refcontent> .............................................44
+      2.40. <reference> ..............................................45
+      2.41. <referencegroup> .........................................46
+      2.42. <references> .............................................46
+      2.43. <region> .................................................47
+      2.44. <relref> .................................................47
+      2.45. <rfc> ....................................................51
+      2.46. <section> ................................................54
+      2.47. <seriesInfo> .............................................57
+      2.48. <sourcecode> .............................................59
+      2.49. <street> .................................................61
+      2.50. <strong> .................................................61
+      2.51. <sub> ....................................................62
+      2.52. <sup> ....................................................63
+      2.53. <t> ......................................................64
+      2.54. <table> ..................................................66
+      2.55. <tbody> ..................................................67
+      2.56. <td> .....................................................67
+      2.57. <tfoot> ..................................................69
+      2.58. <th> .....................................................69
+      2.59. <thead> ..................................................71
+      2.60. <title> ..................................................72
+      2.61. <tr> .....................................................72
+      2.62. <tt> .....................................................73
+      2.63. <ul> .....................................................74
+      2.64. <uri> ....................................................75
+      2.65. <workgroup> ..............................................75
+      2.66. <xref> ...................................................75
+   3. Elements from v2 That Have Been Deprecated .....................78
+      3.1. <c> .......................................................78
+      3.2. <facsimile> ...............................................78
+      3.3. <format> ..................................................79
+      3.4. <list> ....................................................79
+      3.5. <postamble> ...............................................80
+      3.6. <preamble> ................................................81
+      3.7. <spanx> ...................................................81
+      3.8. <texttable> ...............................................82
+      3.9. <ttcol> ...................................................83
+      3.10. <vspace> .................................................84
+   4. SVG ............................................................84
+   5. Use of CDATA Structures and Escaping ...........................85
+   6. Internationalization Considerations ............................85
+   7. Security Considerations ........................................85
+
+
+
+
+
+Hoffman                       Informational                     [Page 3]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   8. IANA Considerations ............................................86
+      8.1. Internet Media Type Registration ..........................86
+      8.2. Link Relation Registration ................................87
+   9. References .....................................................88
+      9.1. Normative References ......................................88
+      9.2. Informative References ....................................88
+   Appendix A. Front-Page ("Boilerplate") Generation .................93
+     A.1. The "ipr" Attribute ........................................93
+       A.1.1. Current Values: "*trust200902" .........................93
+       A.1.2. Historic Values ........................................95
+     A.2. The "submissionType" Attribute .............................96
+     A.3. The "consensus" Attribute ..................................97
+   Appendix B. The v3 Format and Processing Tools ....................98
+     B.1. Including External Text with XInclude ......................99
+     B.2. Anchors and IDs ...........................................100
+       B.2.1. Overlapping Values ....................................100
+     B.3. Attributes Controlled by the Prep Tool ....................102
+   Appendix C. RELAX NG Schema ......................................104
+   Appendix D. Schema Differences from v2 ...........................127
+   IAB Members at the Time of Approval ..............................151
+   Acknowledgements .................................................151
+   Author's Address .................................................151
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 4]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+1.  Introduction
+
+   This document describes version 3 ("v3") of the "xml2rfc" vocabulary:
+   an XML-based language ("Extensible Markup Language" [XML]) used for
+   writing RFCs [RFC7322] and Internet-Drafts [IDGUIDE].
+
+   This document obsoletes the version 2 vocabulary ("v2") [RFC7749],
+   which contains the extended language definition.  That document in
+   turn obsoletes the original version ("v1") [RFC2629].  This document
+   directly copies the material from [RFC7749] where possible.
+
+   The v3 format will be used as part of the new RFC Series format
+   described in [RFC6949].  The new format will be handled by one or
+   more new tools for preparing the XML and converting it to other
+   representations.  Features of the expected tools are described in
+   Appendix B.  That section defines some terms used throughout this
+   document, such as "prep tool" and "formatter".
+
+   Note that the vocabulary contains certain constructs that might not
+   be used when generating the final text; however, they can provide
+   useful data for other uses (such as index generation, populating a
+   keyword database, or syntax checks).
+
+   In this document, the term "format" is used when describing types of
+   documents, primarily XML and HTML.  The term "representation" is used
+   when talking about a specific instantiation of a format, such as an
+   XML document or an HTML document that was created by an XML document.
+
+1.1.  Expected Updates to the Specification
+
+   Non-interoperable changes in later versions of this specification are
+   likely based on experience gained in implementing the new publication
+   toolsets.  Revised documents will be published capturing those
+   changes as the toolsets are completed.  Other implementers must not
+   expect those changes to remain backwards-compatible with the details
+   described in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 5]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+1.2.  Design Criteria for the Changes in v3
+
+   The design criteria of the changes from v2 to v3 are as follows:
+
+   o  The intention is that starting and editing a v3 document will be
+      easier than for a v2 document.
+
+   o  There will be good v2-to-v3 conversion tools for when an author
+      wants to change versions.
+
+   o  There are no current plans to make v3 XML the required submission
+      format for drafts or RFCs.  That might happen eventually, but it
+      is likely to be years away.
+
+   There is a desire to keep as much of the v2 grammar as makes sense
+   within the above design criteria and not to make gratuitous changes
+   to the v2 grammar.  Another way to say this is "we would rather
+   encourage backwards compatibility but not be constrained by it."
+   Still, the goal of starting and editing a v3 document being easier
+   than for a v2 document is more important than backwards compatibility
+   with v2, given the latter two design criteria.
+
+   v3 is upwards compatible with v2, meaning that a v2 document is meant
+   to be a valid v3 document as well.  However, some features of v2 are
+   deprecated in v3 in favor of new elements.  Deprecated features are
+   listed in Section 1.3.3 and are described in [RFC7749].
+
+1.3.  Differences from v2 to v3
+
+   This is a (hopefully) complete list of all the technical changes
+   between [RFC7749] and this document.
+
+1.3.1.  New Elements in v3
+
+   o  Add <dl>, <ul>, and <ol> as new ways to make lists.  This is a
+      significant change from v2 in that the child under these elements
+      is <li>, not <t>.  <li> has a model of either containing one or
+      more <t> elements, or containing the flowing text normally found
+      in <t>.  These lists are children of <section>s and other lists
+      instead of <t>.
+
+   o  Add <strong>, <em>, <tt>, <sub>, and <sup> for character
+      formatting.
+
+   o  Add <aside> for incidental text that will be indented when
+      displayed.
+
+   o  Add <sourcecode> to differentiate from <artwork>.
+
+
+
+Hoffman                       Informational                     [Page 6]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  Add <table>, <thead>, <tbody>, <tfoot>, <tr>, <td>, and <th> to
+      give table functionality like that in HTML.
+
+   o  Add <boilerplate> to hold the automatically generated boilerplate
+      text.
+
+   o  Add <blockquote> to indicate a quotation as in a paragraph-like
+      format.
+
+   o  Add <name> to sections, notes, figures, and texttables to allow
+      character formatting (fixed-width font) in their titles and to
+      allow references in the names.
+
+   o  Add <postalLine>, free text that represents one line of the
+      address.
+
+   o  Add <displayreference> to allow display of more mnemonic anchor
+      names for automatically included references.
+
+   o  Add <refcontent> to allow better control of text in a reference.
+
+   o  Add <referencegroup> to allow referencing multi-RFC documents such
+      as STDs and BCPs.
+
+   o  Add <relref> to allow referencing specific sections or anchors in
+      references.
+
+   o  Add <link> to point to a resource related to the RFC.
+
+   o  Add <br> to allow line breaks (but not blank lines) in the
+      generated output for table cells.
+
+   o  Add <svg> to allow easy inclusion of SVG drawings in <artwork>.
+
+1.3.2.  New Attributes for Existing Elements
+
+   o  Add "sortRefs", "symRefs", "tocDepth", and "tocInclude" attributes
+      to <rfc> to cover Processing Instructions (PIs) that were in v2
+      that are still needed in the grammar.  Add "prepTime" to indicate
+      the time that the XML went through a preparation step.  Add
+      "version" to indicate the version of xml2rfc vocabulary used in
+      the document.  Add "scripts" to indicate which scripts are needed
+      to render the document.  Add "expiresDate" when an Internet-Draft
+      expires.
+
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 7]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  Add "ascii" attributes to <email>, <organization>, <street>,
+      <city>, <region>, <country>, and <code>.  Also add
+      "asciiFullname", "asciiInitials", and "asciiSurname" to <author>.
+      This allows an author to specify their information in their native
+      scripts as the primary entry and still allow the ASCII-equivalent
+      values to appear in the processed documents.
+
+   o  Add "anchor" attributes to many block elements to allow them to be
+      linked with <relref> and <xref>.
+
+   o  Add the "section", "relative", and "sectionFormat" attributes to
+      <xref>.
+
+   o  Add the "numbered" and "removeInRFC" attributes to <section>.
+
+   o  Add the "removeInRFC" attribute to <note>.
+
+   o  Add "pn" to <artwork>, <aside>, <blockquote>, <boilerplate>, <dt>,
+      <figure>, <iref>, <li>, <references>, <section>, <sourcecode>,
+      <t>, and <table> to hold automatically generated numbers for items
+      in a section that don't have their own numbering (namely figures
+      and tables).
+
+   o  Add "display" to <cref> to indicate to tools whether or not to
+      display the comment.
+
+   o  Add "keepWithNext" and "keepWithPrevious" to <t> as a hint to
+      tools that do pagination that they should try to keep the
+      paragraph with the next/previous element.
+
+1.3.3.  Elements and Attributes Deprecated from v2
+
+   Deprecated elements and attributes are legacy vocabulary from v2 that
+   are supported for input to v3 tools.  They are likely to be removed
+   from those tools in the future.  Deprecated attributes are still
+   listed in Section 2, and deprecated elements are listed in Section 3.
+   See Appendix B for more information on tools and how they will handle
+   deprecated features.
+
+   o  Deprecate <list> in favor of <dl>, <ul>, and <ol>.
+
+   o  Deprecate <spanx>; replace it with <strong>, <em>, and <tt>.
+
+   o  Deprecate <vspace> because the major use for it, creating pseudo-
+      paragraph-breaks in lists, is now handled properly.
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 8]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  Deprecate <texttable>, <ttcol>, and <c>; replace them with the new
+      table elements (<table> and the elements that can be contained
+      within it).
+
+   o  Deprecate <facsimile> because it is rarely used.
+
+   o  Deprecate <format> because it is not useful and has caused
+      surprise for authors in the past.  If the goal is to provide a
+      single URI (Uniform Resource Identifier) for a reference, use the
+      "target" attribute in <reference> instead.
+
+   o  Deprecate <preamble> and <postamble> in favor of simply using <t>
+      before or after the figure.  This also deprecates the "align"
+      attribute in <figure>.
+
+   o  Deprecate the "title" attribute in <section>, <note>, <figure>,
+      <references>, and <texttable> in favor of the new <name>.
+
+   o  Deprecate the "alt" and "src" attributes in <figure> because they
+      overlap with the attributes in <artwork>.
+
+   o  Deprecate the "xml:space" attribute in <artwork> because there was
+      only one useful value.  Deprecate the "height" and "width"
+      attributes in both <artwork> and <figure> because they are not
+      needed for the new output formats.
+
+   o  Deprecate the "pageno" attribute in <xref> because it was unused
+      in v2.  Deprecate the "none" values for the "format" attribute in
+      <xref> because it makes no sense semantically.
+
+1.3.4.  Additional Changes from v2
+
+   o  Allow non-ASCII characters in the format; the characters that are
+      actually allowed will be determined by the RFC Series Editor.
+
+   o  Allow <artwork> and <sourcecode> to be used on their own in
+      <section> (no longer confine them to a figure).
+
+   o  Give more specifics of handling the "type" attribute in <artwork>.
+
+   o  Allow <strong>, <em>, <tt>, <eref>, and <xref> in <cref>.
+
+   o  Allow the sub-elements inside a <reference> to be in any order.
+
+   o  Turn off the autogeneration of anchors in <cref> because there is
+      no use case for them that cannot be achieved in other ways.
+
+
+
+
+
+Hoffman                       Informational                     [Page 9]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  Allow more than one <artwork>, or more than one <sourcecode>, in
+      <figure>.
+
+   o  In <front>, make <date> optional.
+
+   o  In <date>, add restrictions to the "date" and "year" attributes
+      when used in the <front> for the document's boilerplate text.
+
+   o  In <postal>, allow the sub-elements to be in any order.  Also
+      allow the inclusion of the new <postalLine> instead of the older
+      elements.
+
+   o  In <section>, restrict the names of the anchors that can be used
+      on some types of sections.
+
+   o  Make <seriesInfo> a child of <front>, and deprecated it as a child
+      of <reference>.  This also deprecates some of the attributes from
+      <rfc> and moves them into <seriesInfo>.
+
+   o  <t> now only contains non-block elements, so it no longer contains
+      <figure> elements.
+
+   o  Do not generate the grammar from a DTD, but instead get it
+      directly from the RELAX Next Generation (RNG) grammar [RNG].
+
+1.4.  Syntax Notation
+
+   The XML vocabulary here is defined in prose, based on the RELAX NG
+   schema [RNC] contained in Appendix C (specified in RELAX NG Compact
+   Notation (RNC)).
+
+   Note that the schema can be used for automated validity checks, but
+   certain constraints are only described in prose (example: the
+   conditionally required presence of the "abbrev" attribute).
+
+2.  Elements
+
+   The sections below describe all elements and their attributes.
+
+   Note that attributes not labeled "mandatory" are optional.
+
+   Many elements have an optional "anchor" attribute.  In all cases, the
+   value of the "anchor" attribute needs to be a valid XML "Name"
+   (Section 2.3 of [XML]), additionally constrained to US-ASCII
+   characters [USASCII].  Thus, the character repertoire consists of
+   "A-Z", "a-z", "0-9", "_", "-", ".", and ":", where "0-9", ".", and
+   "-" are disallowed as start characters.  Anchors are described in
+   more detail in Appendix B.2.
+
+
+
+Hoffman                       Informational                    [Page 10]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Tools interpreting the XML described here will collapse horizontal
+   whitespace and line breaks to a single whitespace (except inside
+   <artwork> and <sourcecode>) and will trim leading and trailing
+   whitespace.  Tab characters (U+0009) inside <artwork> and
+   <sourcecode> are prohibited.
+
+   Some of the elements have attributes that are not described in this
+   section because those attributes are specific to the prep tool.
+   People writing tools to process this format should read all of the
+   appendices for a complete description of these attributes.
+
+   Every element in the v3 vocabulary can have an "xml:lang" attribute,
+   an "xml:base" attribute, or both.  The xml:lang attribute specifies
+   the language used in the element.  This is sometimes useful for
+   renderers that display different fonts for ideographic characters
+   used in China and Japan.  The xml:base attribute is sometimes added
+   to an XML file when doing XML-to-XML conversion where the base file
+   has XInclude attributes (see Appendix B.1).
+
+2.1.  <abstract>
+
+   Contains the Abstract of the document.  See [RFC7322] for more
+   information on restrictions for the Abstract.
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model:
+
+   In any order, but at least one of:
+
+   o  <dl> elements (Section 2.20)
+
+   o  <ol> elements (Section 2.34)
+
+   o  <t> elements (Section 2.53)
+
+   o  <ul> elements (Section 2.63)
+
+2.1.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the Abstract.
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 11]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.2.  <address>
+
+   Provides address information for the author.
+
+   This element appears as a child element of <author> (Section 2.7).
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <postal> element (Section 2.37)
+
+   2.  One optional <phone> element (Section 2.36)
+
+   3.  One optional <facsimile> element (Section 3.2)
+
+   4.  One optional <email> element (Section 2.23)
+
+   5.  One optional <uri> element (Section 2.64)
+
+2.3.  <annotation>
+
+   Provides additional prose augmenting a bibliographic reference.  This
+   text is intended to be shown after the rest of the generated
+   reference text.
+
+   This element appears as a child element of <reference>
+   (Section 2.40).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <spanx> elements (Section 3.7)
+
+
+
+Hoffman                       Informational                    [Page 12]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.4.  <area>
+
+   Provides information about the IETF area to which this document
+   relates (currently not used when generating documents).
+
+   The value ought to be either the full name or the abbreviation of one
+   of the IETF areas as listed on <http://www.ietf.org/iesg/area.html>.
+   A list of full names and abbreviations will be kept by the RFC Series
+   Editor.
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model: only text content.
+
+2.5.  <artwork>
+
+   This element allows the inclusion of "artwork" in the document.
+   <artwork> provides full control of horizontal whitespace and line
+   breaks; thus, it is used for a variety of things, such as diagrams
+   ("line art") and protocol unit diagrams.  Tab characters (U+0009)
+   inside of this element are prohibited.
+
+   Alternatively, the "src" attribute allows referencing an external
+   graphics file, such as a vector drawing in SVG or a bitmap graphic
+   file, using a URI.  In this case, the textual content acts as a
+   fallback for output representations that do not support graphics;
+   thus, it ought to contain either (1) a "line art" variant of the
+   graphics or (2) prose that describes the included image in sufficient
+   detail.
+
+   In [RFC7749], the <artwork> element was also used for source code and
+   formal languages; in v3, this is now done with <sourcecode>.
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 13]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   There are at least five ways to include SVG in artwork in
+   Internet-Drafts:
+
+   o  Inline, by including all of the SVG in the content of the element,
+      such as: <artwork type="svg"><svg xmlns="http://www.w3.org/2000/
+      svg...">
+
+   o  Inline, but using XInclude (see Appendix B.1), such as: <artwork
+      type="svg"><xi:include href=...>
+
+   o  As a data: URI, such as: <artwork type="svg" src="data:image/
+      svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3...">
+
+   o  As a URI to an external entity, such as: <artwork type="svg"
+      src="http://www.example.com/...">
+
+   o  As a local file, such as: <artwork type="svg" src="diagram12.svg">
+
+   The use of SVG in Internet-Drafts and RFCs is covered in much more
+   detail in [RFC7996].
+
+   The above methods for inclusion of SVG art can also be used for
+   including text artwork, but using a data: URI is probably confusing
+   for text artwork.
+
+   Formatters that do pagination should attempt to keep artwork on a
+   single page.  This is to prevent artwork that is split across pages
+   from looking like two separate pieces of artwork.
+
+   See Section 5 for a description of how to deal with issues of using
+   "&" and "<" characters in artwork.
+
+   This element appears as a child element of <aside> (Section 2.6),
+   <blockquote> (Section 2.10), <dd> (Section 2.18), <figure>
+   (Section 2.25), <li> (Section 2.29), <section> (Section 2.46), <td>
+   (Section 2.56), and <th> (Section 2.58).
+
+   Content model:
+
+   Either:
+
+      Text
+
+   Or:
+
+      <svg> elements (Section 4)
+
+
+
+
+
+Hoffman                       Informational                    [Page 14]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.5.1.  "align" Attribute
+
+   Controls whether the artwork appears left justified (default),
+   centered, or right justified.  Artwork is aligned relative to the
+   left margin of the document.
+
+   Allowed values:
+
+   o  "left" (default)
+
+   o  "center"
+
+   o  "right"
+
+2.5.2.  "alt" Attribute
+
+   Alternative text description of the artwork (which is more than just
+   a summary or caption).  When the art comes from the "src" attribute
+   and the format of that artwork supports alternate text, the
+   alternative text comes from the text of the artwork itself, not from
+   this attribute.  The contents of this attribute are important to
+   readers who are visually impaired, as well as those reading on
+   devices that cannot show the artwork well, or at all.
+
+2.5.3.  "anchor" Attribute
+
+   Document-wide unique identifier for this artwork.
+
+2.5.4.  "height" Attribute
+
+   Deprecated.
+
+2.5.5.  "name" Attribute
+
+   A filename suitable for the contents (such as for extraction to a
+   local file).  This attribute can be helpful for other kinds of tools
+   (such as automated syntax checkers, which work by extracting the
+   artwork).  Note that the "name" attribute does not need to be unique
+   for <artwork> elements in a document.  If multiple <artwork> elements
+   have the same "name" attribute, a processing tool might assume that
+   the elements are all fragments of a single file, and the tool can
+   collect those fragments for later processing.  See Section 7 for a
+   discussion of possible problems with the value of this attribute.
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 15]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.5.6.  "src" Attribute
+
+   The URI reference of a graphics file [RFC3986], or the name of a file
+   on the local disk.  This can be a "data" URI [RFC2397] that contains
+   the contents of the graphics file.  Note that the inclusion of art
+   with the "src" attribute depends on the capabilities of the
+   processing tool reading the XML document.  Tools need to be able to
+   handle the file: URI, and they should be able to handle http: and
+   https: URIs as well.  The prep tool will be able to handle reading
+   the "src" attribute.
+
+   If no URI scheme is given in the attribute, the attribute is
+   considered to be a local filename relative to the current directory.
+   Processing tools must be careful to not accept dangerous values for
+   the filename, particularly those that contain absolute references
+   outside the current directory.  Document creators should think hard
+   before using relative URIs due to possible later problems if files
+   move around on the disk.  Also, documents should most likely use
+   explicit URI schemes wherever possible.
+
+   In some cases, the prep tool may remove the "src" attribute after
+   processing its value.  See [RFC7998] for a description of this.
+
+   It is an error to have both a "src" attribute and content in the
+   <artwork> element.
+
+2.5.7.  "type" Attribute
+
+   Specifies the type of the artwork.  The value of this attribute is
+   free text with certain values designated as preferred.
+
+   The preferred values for <artwork> types are:
+
+   o  ascii-art
+
+   o  binary-art
+
+   o  call-flow
+
+   o  hex-dump
+
+   o  svg
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 16]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   The RFC Series Editor will maintain a complete list of the preferred
+   values on the RFC Editor web site, and that list is expected to be
+   updated over time.  Thus, a consumer of v3 XML should not cause a
+   failure when it encounters an unexpected type or no type is
+   specified.  The table will also indicate which type of art can appear
+   in plain-text output (for example, type="svg" cannot).
+
+2.5.8.  "width" Attribute
+
+   Deprecated.
+
+2.5.9.  "xml:space" Attribute
+
+   Deprecated.
+
+2.6.  <aside>
+
+   This element is a container for content that is semantically less
+   important or tangential to the content that surrounds it.
+
+   This element appears as a child element of <section> (Section 2.46).
+
+   Content model:
+
+   In any order:
+
+   o  <artwork> elements (Section 2.5)
+
+   o  <dl> elements (Section 2.20)
+
+   o  <figure> elements (Section 2.25)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <list> elements (Section 3.4)
+
+   o  <ol> elements (Section 2.34)
+
+   o  <t> elements (Section 2.53)
+
+   o  <table> elements (Section 2.54)
+
+   o  <ul> elements (Section 2.63)
+
+2.6.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this aside.
+
+
+
+
+Hoffman                       Informational                    [Page 17]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.7.  <author>
+
+   Provides information about a document's author.  This is used both
+   for the document itself (at the beginning of the document) and for
+   referenced documents.
+
+   The <author> elements contained within the document's <front> element
+   are used to fill the boilerplate and also to generate the "Author's
+   Address" section (see [RFC7322]).
+
+   Note that an "author" can also be just an organization (by not
+   specifying any of the "name" attributes, but adding the
+   <organization> child element).
+
+   Furthermore, the "role" attribute can be used to mark an author as
+   "editor".  This is reflected both on the front page and in the
+   "Author's Address" section, as well as in bibliographic references.
+   Note that this specification does not define a precise meaning for
+   the term "editor".
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <organization> element (Section 2.35)
+
+   2.  One optional <address> element (Section 2.2)
+
+2.7.1.  "asciiFullname" Attribute
+
+   The ASCII equivalent of the author's full name.
+
+2.7.2.  "asciiInitials" Attribute
+
+   The ASCII equivalent of the author's initials, to be used in
+   conjunction with the separately specified asciiSurname.
+
+2.7.3.  "asciiSurname" Attribute
+
+   The ASCII equivalent of the author's surname, to be used in
+   conjunction with the separately specified asciiInitials.
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 18]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.7.4.  "fullname" Attribute
+
+   The full name (used in the automatically generated "Author's Address"
+   section).  Although this attribute is optional, if one or more of the
+   "asciiFullname", "asciiInitials", or "asciiSurname" attributes have
+   values, the "fullname" attribute is required.
+
+2.7.5.  "initials" Attribute
+
+   An abbreviated variant of the given name(s), to be used in
+   conjunction with the separately specified surname.  It usually
+   appears on the front page, in footers, and in references.
+
+   Some processors will post-process the value -- for instance, when it
+   only contains a single letter (in which case they might add a
+   trailing dot).  Relying on this kind of post-processing can lead to
+   results varying across formatters and thus ought to be avoided.
+
+2.7.6.  "role" Attribute
+
+   Specifies the role the author had in creating the document.
+
+   Allowed value:
+
+   o  "editor"
+
+2.7.7.  "surname" Attribute
+
+   The author's surname, to be used in conjunction with the separately
+   specified initials.  It usually appears on the front page, in
+   footers, and in references.
+
+2.8.  <back>
+
+   Contains the "back" part of the document: the references and
+   appendices.  In <back>, <section> elements indicate appendices.
+
+   This element appears as a child element of <rfc> (Section 2.45).
+
+   Content model:
+
+   In this order:
+
+   1.  Optional <displayreference> elements (Section 2.19)
+
+   2.  Optional <references> elements (Section 2.42)
+
+   3.  Optional <section> elements (Section 2.46)
+
+
+
+Hoffman                       Informational                    [Page 19]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.9.  <bcp14>
+
+   Marks text that are phrases defined in [BCP14] such as "MUST",
+   "SHOULD NOT", and so on.  When shown in some of the output
+   representations, the text in this element might be highlighted.  The
+   use of this element is optional.
+
+   This element is only to be used around the actual phrase from BCP 14,
+   not the full definition of a requirement.  For example, it is correct
+   to say "The packet <bcp14>MUST</bcp14> be dropped.", but it is not
+   correct to say "<bcp14>The packet MUST be dropped.</bcp14>".
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <dd> (Section 2.18), <dt>
+   (Section 2.21), <em> (Section 2.22), <li> (Section 2.29), <preamble>
+   (Section 3.6), <refcontent> (Section 2.39), <strong> (Section 2.50),
+   <sub> (Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td>
+   (Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62).
+
+   Content model: only text content.
+
+2.10.  <blockquote>
+
+   Specifies that a block of text is a quotation.
+
+   This element appears as a child element of <section> (Section 2.46).
+
+   Content model:
+
+   Either:
+
+      In any order, but at least one of:
+
+      *  <artwork> elements (Section 2.5)
+
+      *  <dl> elements (Section 2.20)
+
+      *  <figure> elements (Section 2.25)
+
+      *  <ol> elements (Section 2.34)
+
+      *  <sourcecode> elements (Section 2.48)
+
+      *  <t> elements (Section 2.53)
+
+      *  <ul> elements (Section 2.63)
+
+
+
+
+
+Hoffman                       Informational                    [Page 20]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Or:
+
+      In any order, but at least one of:
+
+      *  Text
+
+      *  <bcp14> elements (Section 2.9)
+
+      *  <cref> elements (Section 2.16)
+
+      *  <em> elements (Section 2.22)
+
+      *  <eref> elements (Section 2.24)
+
+      *  <iref> elements (Section 2.27)
+
+      *  <relref> elements (Section 2.44)
+
+      *  <strong> elements (Section 2.50)
+
+      *  <sub> elements (Section 2.51)
+
+      *  <sup> elements (Section 2.52)
+
+      *  <tt> elements (Section 2.62)
+
+      *  <xref> elements (Section 2.66)
+
+2.10.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this quotation.
+
+2.10.2.  "cite" Attribute
+
+   The source of the citation.  This must be a URI.  If the "quotedFrom"
+   attribute is given, this URI will be used by processing tools as the
+   link for the text of that attribute.
+
+2.10.3.  "quotedFrom" Attribute
+
+   Name of person or document the text in this element is quoted from.
+   A formatter should render this as visible text at the end of the
+   quotation.
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 21]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.11.  <boilerplate>
+
+   Holds the boilerplate text for the document.  This element is filled
+   in by the prep tool.
+
+   This element contains <section> elements.  Every <section> element in
+   this element must have the "numbered" attribute set to "false".
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model:
+
+   One or more <section> elements (Section 2.46)
+
+2.12.  <br>
+
+   Indicates that a line break should be inserted in the generated
+   output by a formatting tool.  Multiple successive instances of this
+   element are ignored.
+
+   This element appears as a child element of <td> (Section 2.56) and
+   <th> (Section 2.58).
+
+   Content model: this element does not have any contents.
+
+2.13.  <city>
+
+   Gives the city name in a postal address.
+
+   This element appears as a child element of <postal> (Section 2.37).
+
+   Content model: only text content.
+
+2.13.1.  "ascii" Attribute
+
+   The ASCII equivalent of the city name.
+
+2.14.  <code>
+
+   Gives the postal region code.
+
+   This element appears as a child element of <postal> (Section 2.37).
+
+   Content model: only text content.
+
+2.14.1.  "ascii" Attribute
+
+   The ASCII equivalent of the postal code.
+
+
+
+Hoffman                       Informational                    [Page 22]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.15.  <country>
+
+   Gives the country name or code in a postal address.
+
+   This element appears as a child element of <postal> (Section 2.37).
+
+   Content model: only text content.
+
+2.15.1.  "ascii" Attribute
+
+   The ASCII equivalent of the country name.
+
+2.16.  <cref>
+
+   Represents a comment.
+
+   Comments can be used in a document while it is work in progress.
+   They might appear either inline and visually highlighted, at the end
+   of the document, or not at all, depending on the formatting tool.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <dd>
+   (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
+   (Section 2.29), <name> (Section 2.32), <postamble> (Section 3.5),
+   <preamble> (Section 3.6), <strong> (Section 2.50), <sub>
+   (Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td>
+   (Section 2.56), <th> (Section 2.58), <tt> (Section 2.62), and <ttcol>
+   (Section 3.9).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <strong> elements (Section 2.50)
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 23]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.16.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this comment.
+
+2.16.2.  "display" Attribute
+
+   Suggests whether or not the comment should be displayed by formatting
+   tools.  This might be set to "false" if you want to keep a comment in
+   a document after the contents of the comment have already been dealt
+   with.
+
+   Allowed values:
+
+   o  "true" (default)
+
+   o  "false"
+
+2.16.3.  "source" Attribute
+
+   Holds the "source" of a comment, such as the name or the initials of
+   the person who made the comment.
+
+2.17.  <date>
+
+   Provides information about the publication date.  This element is
+   used for two cases: the boilerplate of the document being produced,
+   and inside bibliographic references that use the <front> element.
+
+   Boilerplate for Internet-Drafts and RFCs:  This element defines the
+      date of publication for the current document (Internet-Draft or
+      RFC).  When producing Internet-Drafts, the prep tool uses this
+      date to compute the expiration date (see [IDGUIDE]).  When one or
+      more of "year", "month", or "day" are left out, the prep tool will
+      attempt to use the current system date if the attributes that are
+      present are consistent with that date.
+
+      In dates in <rfc> elements, the month must be a number or a month
+      in English.  The prep tool will silently change text month names
+      to numbers.  Similarly, the year must be a four-digit number.
+
+
+
+
+Hoffman                       Informational                    [Page 24]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      When the prep tool is used to create Internet-Drafts, it will
+      reject a submitted Internet-Draft that has a <date> element in the
+      boilerplate for itself that is anything other than today.  That
+      is, the tool will not allow a submitter to specify a date other
+      than the day of submission.  To avoid this problem, authors might
+      simply not include a <date> element in the boilerplate.
+
+   Bibliographic references:  In dates in <reference> elements, the date
+      information can have prose text for the month or year.  For
+      example, vague dates (year="ca. 2000"), date ranges
+      (year="2012-2013"), non-specific months (month="Second quarter"),
+      and so on are allowed.
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model: this element does not have any contents.
+
+2.17.1.  "day" Attribute
+
+   The day of publication.
+
+2.17.2.  "month" Attribute
+
+   The month or months of publication.
+
+2.17.3.  "year" Attribute
+
+   The year or years of publication.
+
+2.18.  <dd>
+
+   The definition part of an entry in a definition list.
+
+   This element appears as a child element of <dl> (Section 2.20).
+
+   Content model:
+
+   Either:
+
+      In any order, but at least one of:
+
+      *  <artwork> elements (Section 2.5)
+
+      *  <dl> elements (Section 2.20)
+
+      *  <figure> elements (Section 2.25)
+
+      *  <ol> elements (Section 2.34)
+
+
+
+Hoffman                       Informational                    [Page 25]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      *  <sourcecode> elements (Section 2.48)
+
+      *  <t> elements (Section 2.53)
+
+      *  <ul> elements (Section 2.63)
+
+   Or:
+
+      In any order, but at least one of:
+
+      *  Text
+
+      *  <bcp14> elements (Section 2.9)
+
+      *  <cref> elements (Section 2.16)
+
+      *  <em> elements (Section 2.22)
+
+      *  <eref> elements (Section 2.24)
+
+      *  <iref> elements (Section 2.27)
+
+      *  <relref> elements (Section 2.44)
+
+      *  <strong> elements (Section 2.50)
+
+      *  <sub> elements (Section 2.51)
+
+      *  <sup> elements (Section 2.52)
+
+      *  <tt> elements (Section 2.62)
+
+      *  <xref> elements (Section 2.66)
+
+2.18.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this definition.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 26]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.19.  <displayreference>
+
+   This element gives a mapping between the anchor of a reference and a
+   name that will be displayed instead.  This allows authors to display
+   more mnemonic anchor names for automatically included references.
+   The mapping in this element only applies to <xref> elements whose
+   format is "default".  For example, if the reference uses the anchor
+   "RFC6949", the following would cause that anchor in the body of
+   displayed documents to be "RFC-dev":
+
+   <displayreference target="RFC6949" to="RFC-dev"/>
+
+   If a reference section is sorted, this element changes the sort
+   order.
+
+   It is expected that this element will only be valid in input
+   documents.  It will likely be removed by prep tools when preparing a
+   final version after those tools have replaced all of the associated
+   anchors, targets, and "derivedContent" attributes.
+
+   This element appears as a child element of <back> (Section 2.8).
+
+   Content model: this element does not have any contents.
+
+2.19.1.  "target" Attribute (Mandatory)
+
+   This attribute must be the name of an anchor in a <reference> or
+   <referencegroup> element.
+
+2.19.2.  "to" Attribute (Mandatory)
+
+   This attribute is a name that will be displayed as the anchor instead
+   of the anchor that is given in the <reference> element.  The string
+   given must start with one of the following characters: 0-9, a-z, or
+   A-Z.  The other characters in the string must be 0-9, a-z, A-Z, "-",
+   ".", or "_".
+
+2.20.  <dl>
+
+   A definition list.  Each entry has a pair of elements: a term (<dt>)
+   and a definition (<dd>).  (This is slightly different and simpler
+   than the model used in HTML, which allows for multiple terms for a
+   single definition.)
+
+   This element appears as a child element of <abstract> (Section 2.1),
+   <aside> (Section 2.6), <blockquote> (Section 2.10), <dd>
+   (Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section>
+   (Section 2.46), <td> (Section 2.56), and <th> (Section 2.58).
+
+
+
+Hoffman                       Informational                    [Page 27]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Content model:
+
+   One or more sequences of:
+
+   1.  One <dt> element
+
+   2.  One <dd> element
+
+2.20.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the list.
+
+2.20.2.  "hanging" Attribute
+
+   The "hanging" attribute defines whether or not the term appears on
+   the same line as the definition.  hanging="true" indicates that the
+   term is to the left of the definition, while hanging="false"
+   indicates that the term will be on a separate line.
+
+   Allowed values:
+
+   o  "false"
+
+   o  "true" (default)
+
+2.20.3.  "spacing" Attribute
+
+   Defines whether or not there is a blank line between entries.
+   spacing="normal" indicates a single blank line, while
+   spacing="compact" indicates no space between.
+
+   Allowed values:
+
+   o  "normal" (default)
+
+   o  "compact"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 28]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.21.  <dt>
+
+   The term being defined in a definition list.
+
+   This element appears as a child element of <dl> (Section 2.20).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.21.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this term.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 29]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.22.  <em>
+
+   Indicates text that is semantically emphasized.  Text enclosed within
+   this element will be displayed as italic after processing.  This
+   element can be combined with other character formatting elements, and
+   the formatting will be additive.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
+   <dd> (Section 2.18), <dt> (Section 2.21), <li> (Section 2.29),
+   <preamble> (Section 3.6), <refcontent> (Section 2.39), <strong>
+   (Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t>
+   (Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and <tt>
+   (Section 2.62).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 30]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.23.  <email>
+
+   Provides an email address.
+
+   The value is expected to be the addr-spec defined in Section 2 of
+   [RFC6068].
+
+   This element appears as a child element of <address> (Section 2.2).
+
+   Content model: only text content.
+
+2.23.1.  "ascii" Attribute
+
+   The ASCII equivalent of the author's email address.  This is only
+   used if the email address has any internationalized components.
+
+2.24.  <eref>
+
+   Represents an "external" link (as specified in the "target"
+   attribute).  This is useful for embedding URIs in the body of a
+   document.
+
+   If the <eref> element has non-empty text content, formatters should
+   use the content as the displayed text that is linked.  Otherwise, the
+   formatter should use the value of the "target" attribute as the
+   displayed text.  Formatters will link the displayed text to the value
+   of the "target" attribute in a manner appropriate for the output
+   format.
+
+   For example, with an input of:
+
+         This is described at
+         <eref target="http://www.example.com/reports/r12.html"/>.
+
+   An HTML formatter might generate:
+
+         This is described at
+         <a href="http://www.example.com/reports/r12.html">
+         http://www.example.com/reports/r12.html</a>.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 31]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   With an input of:
+
+         This is described
+         <eref target="http://www.example.com/reports/r12.html">
+         in this interesting report</eref>.
+
+   An HTML formatter might generate:
+
+         This is described
+         <a href="http://www.example.com/reports/r12.html">
+         in this interesting report</a>.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <cref>
+   (Section 2.16), <dd> (Section 2.18), <dt> (Section 2.21), <em>
+   (Section 2.22), <li> (Section 2.29), <name> (Section 2.32),
+   <postamble> (Section 3.5), <preamble> (Section 3.6), <strong>
+   (Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t>
+   (Section 2.53), <td> (Section 2.56), <th> (Section 2.58), <tt>
+   (Section 2.62), and <ttcol> (Section 3.9).
+
+   Content model: only text content.
+
+2.24.1.  "target" Attribute (Mandatory)
+
+   URI of the link target [RFC3986].  This must begin with a scheme name
+   (such as "https://") and thus not be relative to the URL of the
+   current document.
+
+2.25.  <figure>
+
+   Contains a figure with a caption with the figure number.  If the
+   element contains a <name> element, the caption will also show that
+   name.
+
+   This element appears as a child element of <aside> (Section 2.6),
+   <blockquote> (Section 2.10), <dd> (Section 2.18), <li>
+   (Section 2.29), <section> (Section 2.46), <td> (Section 2.56), and
+   <th> (Section 2.58).
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 32]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <name> element (Section 2.32)
+
+   2.  Optional <iref> elements (Section 2.27)
+
+   3.  One optional <preamble> element (Section 3.6)
+
+   4.  In any order, but at least one of:
+
+       *  <artwork> elements (Section 2.5)
+
+       *  <sourcecode> elements (Section 2.48)
+
+   5.  One optional <postamble> element (Section 3.5)
+
+2.25.1.  "align" Attribute
+
+   Deprecated.
+
+   Note: does not affect title or <artwork> alignment.
+
+   Allowed values:
+
+   o  "left" (default)
+
+   o  "center"
+
+   o  "right"
+
+2.25.2.  "alt" Attribute
+
+   Deprecated.  If the goal is to provide a single URI for a reference,
+   use the "target" attribute in <reference> instead.
+
+2.25.3.  "anchor" Attribute
+
+   Document-wide unique identifier for this figure.
+
+2.25.4.  "height" Attribute
+
+   Deprecated.
+
+2.25.5.  "src" Attribute
+
+   Deprecated.
+
+
+
+Hoffman                       Informational                    [Page 33]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.25.6.  "suppress-title" Attribute
+
+   Deprecated.
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+2.25.7.  "title" Attribute
+
+   Deprecated.  Use <name> instead.
+
+2.25.8.  "width" Attribute
+
+   Deprecated.
+
+2.26.  <front>
+
+   Represents the "front matter": metadata (such as author information),
+   the Abstract, and additional notes.
+
+   A <front> element may have more than one <seriesInfo> element.  A
+   <seriesInfo> element determines the document number (for RFCs) or
+   name (for Internet-Drafts).  Another <seriesInfo> element determines
+   the "maturity level" (defined in [RFC2026]), using values of "std"
+   for "Standards Track", "bcp" for "BCP", "info" for "Informational",
+   "exp" for "Experimental", and "historic" for "Historic".  The "name"
+   attributes of those multiple <seriesInfo> elements interact as
+   described in Section 2.47.
+
+   This element appears as a child element of <reference> (Section 2.40)
+   and <rfc> (Section 2.45).
+
+   Content model:
+
+   In this order:
+
+   1.   One <title> element (Section 2.60)
+
+   2.   Optional <seriesInfo> elements (Section 2.47)
+
+   3.   One or more <author> elements (Section 2.7)
+
+   4.   One optional <date> element (Section 2.17)
+
+   5.   Optional <area> elements (Section 2.4)
+
+
+
+Hoffman                       Informational                    [Page 34]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   6.   Optional <workgroup> elements (Section 2.65)
+
+   7.   Optional <keyword> elements (Section 2.28)
+
+   8.   One optional <abstract> element (Section 2.1)
+
+   9.   Optional <note> elements (Section 2.33)
+
+   10.  One optional <boilerplate> element (Section 2.11)
+
+2.27.  <iref>
+
+   Provides terms for the document's index.
+
+   Index entries can be either regular entries (when just the "item"
+   attribute is given) or nested entries (by specifying "subitem" as
+   well), grouped under a regular entry.
+
+   Index entries generally refer to the exact place where the <iref>
+   element occurred.  An exception is the occurrence as a child element
+   of <section>, in which case the whole section is considered to be
+   relevant for that index entry.  In some formats, index entries of
+   this type might be displayed as ranges.
+
+   When the prep tool is creating index content, it collects the items
+   in a case-sensitive fashion for both the item and subitem level.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <aside> (Section 2.6), <blockquote> (Section 2.10),
+   <c> (Section 3.1), <dd> (Section 2.18), <dt> (Section 2.21), <em>
+   (Section 2.22), <figure> (Section 2.25), <li> (Section 2.29),
+   <postamble> (Section 3.5), <preamble> (Section 3.6), <section>
+   (Section 2.46), <strong> (Section 2.50), <sub> (Section 2.51), <sup>
+   (Section 2.52), <t> (Section 2.53), <table> (Section 2.54), <td>
+   (Section 2.56), <th> (Section 2.58), <tt> (Section 2.62), and <ttcol>
+   (Section 3.9).
+
+   Content model: this element does not have any contents.
+
+2.27.1.  "item" Attribute (Mandatory)
+
+   The item to include.
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 35]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.27.2.  "primary" Attribute
+
+   Setting this to "true" declares the occurrence as "primary", which
+   might cause it to be highlighted in the index.  There is no
+   restriction on the number of occurrences that can be "primary".
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+2.27.3.  "subitem" Attribute
+
+   The subitem to include.
+
+2.28.  <keyword>
+
+   Specifies a keyword applicable to the document.
+
+   Note that each element should only contain a single keyword; for
+   multiple keywords, the element can simply be repeated.
+
+   Keywords are used both in the RFC Index and in the metadata of
+   generated document representations.
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model: only text content.
+
+2.29.  <li>
+
+   A list element, used in <ol> and <ul>.
+
+   This element appears as a child element of <ol> (Section 2.34) and
+   <ul> (Section 2.63).
+
+   Content model:
+
+   Either:
+
+      In any order, but at least one of:
+
+      *  <artwork> elements (Section 2.5)
+
+      *  <dl> elements (Section 2.20)
+
+      *  <figure> elements (Section 2.25)
+
+
+
+Hoffman                       Informational                    [Page 36]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      *  <ol> elements (Section 2.34)
+
+      *  <sourcecode> elements (Section 2.48)
+
+      *  <t> elements (Section 2.53)
+
+      *  <ul> elements (Section 2.63)
+
+   Or:
+
+      In any order, but at least one of:
+
+      *  Text
+
+      *  <bcp14> elements (Section 2.9)
+
+      *  <cref> elements (Section 2.16)
+
+      *  <em> elements (Section 2.22)
+
+      *  <eref> elements (Section 2.24)
+
+      *  <iref> elements (Section 2.27)
+
+      *  <relref> elements (Section 2.44)
+
+      *  <strong> elements (Section 2.50)
+
+      *  <sub> elements (Section 2.51)
+
+      *  <sup> elements (Section 2.52)
+
+      *  <tt> elements (Section 2.62)
+
+      *  <xref> elements (Section 2.66)
+
+2.29.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this list item.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 37]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.30.  <link>
+
+   A link to an external document that is related to the RFC.
+
+   The following are the supported types of external documents that can
+   be pointed to in a <link> element:
+
+   o  The current International Standard Serial Number (ISSN) for the
+      RFC Series.  The value for the "rel" attribute is "item".  The
+      link should use the form "urn:issn:".
+
+   o  The Digital Object Identifier (DOI) for this document.  The value
+      for the "rel" attribute is "describedBy".  The link should use the
+      form specified in [RFC7669]; this is expected to change in the
+      future.
+
+   o  The Internet-Draft that was submitted to the RFC Editor to become
+      the published RFC.  The value for the "rel" attribute is
+      "convertedFrom".  The link should be to an IETF-controlled web
+      site that retains copies of Internet-Drafts.
+
+   o  A representation of the document offered by the document author.
+      The value for the "rel" attribute is "alternate".  The link can be
+      to a personally run web site.
+
+   In RFC production mode, the prep tool needs to check the values for
+   <link> before an RFC is published.  In draft production mode, the
+   prep tool might remove some <link> elements during the draft
+   submission process.
+
+   This element appears as a child element of <rfc> (Section 2.45).
+
+   Content model: this element does not have any contents.
+
+2.30.1.  "href" Attribute (Mandatory)
+
+   The URI of the external document.
+
+2.30.2.  "rel" Attribute
+
+   The relationship of the external document to this one.  The
+   relationships are taken from the "Link Relations" registry maintained
+   by IANA [LINKRELATIONS].
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 38]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.31.  <middle>
+
+   Represents the main content of the document.
+
+   This element appears as a child element of <rfc> (Section 2.45).
+
+   Content model:
+
+   One or more <section> elements (Section 2.46)
+
+2.32.  <name>
+
+   The name of the section, note, figure, or texttable.  This name can
+   indicate markup of flowing text (for example, including references or
+   making some characters use a fixed-width font).
+
+   This element appears as a child element of <figure> (Section 2.25),
+   <note> (Section 2.33), <references> (Section 2.42), <section>
+   (Section 2.46), <table> (Section 2.54), and <texttable>
+   (Section 3.8).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <cref> elements (Section 2.16)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.33.  <note>
+
+   Creates an unnumbered, titled block of text that appears after the
+   Abstract.
+
+   It is usually used for additional information to reviewers (Working
+   Group information, mailing list, ...) or for additional publication
+   information such as "IESG Notes".
+
+   This element appears as a child element of <front> (Section 2.26).
+
+
+
+
+Hoffman                       Informational                    [Page 39]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <name> element (Section 2.32)
+
+   2.  In any order, but at least one of:
+
+       *  <dl> elements (Section 2.20)
+
+       *  <ol> elements (Section 2.34)
+
+       *  <t> elements (Section 2.53)
+
+       *  <ul> elements (Section 2.63)
+
+2.33.1.  "removeInRFC" Attribute
+
+   If set to "true", this note is marked in the prep tool with text
+   indicating that it should be removed before the document is published
+   as an RFC.  That text will be "This note is to be removed before
+   publishing as an RFC."
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+2.33.2.  "title" Attribute
+
+   Deprecated.  Use <name> instead.
+
+2.34.  <ol>
+
+   An ordered list.  The labels on the items will be either a number or
+   a letter, depending on the value of the style attribute.
+
+   This element appears as a child element of <abstract> (Section 2.1),
+   <aside> (Section 2.6), <blockquote> (Section 2.10), <dd>
+   (Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section>
+   (Section 2.46), <td> (Section 2.56), and <th> (Section 2.58).
+
+   Content model:
+
+   One or more <li> elements (Section 2.29)
+
+
+
+
+
+Hoffman                       Informational                    [Page 40]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.34.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the list.
+
+2.34.2.  "group" Attribute
+
+   When the prep tool sees an <ol> element with a "group" attribute that
+   has already been seen, it continues the numbering of the list from
+   where the previous list with the same group name left off.  If an
+   <ol> element has both a "group" attribute and a "start" attribute,
+   the group's numbering is reset to the given start value.
+
+2.34.3.  "spacing" Attribute
+
+   Defines whether or not there is a blank line between entries.
+   spacing="normal" indicates a single blank line, while
+   spacing="compact" indicates no space between.
+
+   Allowed values:
+
+   o  "normal" (default)
+
+   o  "compact"
+
+2.34.4.  "start" Attribute
+
+   The ordinal value at which to start the list.  This defaults to "1"
+   and must be an integer of 0 or greater.
+
+2.34.5.  "type" Attribute
+
+   The type of the labels on list items.  If the length of the type
+   value is 1, the meaning is the same as it is for HTML:
+
+   a  Lowercase letters (a, b, c, ...)
+
+   A  Uppercase letters (A, B, C, ...)
+
+   1  Decimal numbers (1, 2, 3, ...)
+
+   i  Lowercase Roman numerals (i, ii, iii, ...)
+
+   I  Uppercase Roman numerals (I, II, III, ...)
+
+   For types "a" and "A", after the 26th entry, the numbering starts at
+   "aa"/"AA", then "ab"/"AB", and so on.
+
+
+
+
+
+Hoffman                       Informational                    [Page 41]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   If the length of the type value is greater than 1, the value must
+   contain a percent-encoded indicator and other text.  The value is a
+   free-form text that allows counter values to be inserted using a
+   "percent-letter" format.  For instance, "[REQ%d]" generates labels of
+   the form "[REQ1]", where "%d" inserts the item number as a decimal
+   number.
+
+   The following formats are supported:
+
+   %c Lowercase letters (a, b, c, ...)
+
+   %C Uppercase letters (A, B, C, ...)
+
+   %d Decimal numbers (1, 2, 3, ...)
+
+   %i Lowercase Roman numerals (i, ii, iii, ...)
+
+   %I Uppercase Roman numerals (I, II, III, ...)
+
+   %% Represents a percent sign
+
+   Other formats are reserved for future use.  Only one percent encoding
+   other than "%%" is allowed in a type string.
+
+   It is an error for the type string to be empty.  For bulleted lists,
+   use the <ul> element.  For lists that have neither bullets nor
+   numbers, use the <ul> element with the 'empty="true"' attribute.
+
+   If no type attribute is given, the default type is the same as
+   "type='%d.'".
+
+2.35.  <organization>
+
+   Specifies the affiliation [RFC7322] of an author.
+
+   This information appears both in the "Author's Address" section and
+   on the front page (see [RFC7322] for more information).  If the value
+   is long, an abbreviated variant can be specified in the "abbrev"
+   attribute.
+
+   This element appears as a child element of <author> (Section 2.7).
+
+   Content model: only text content.
+
+2.35.1.  "abbrev" Attribute
+
+   Abbreviated variant.
+
+
+
+
+Hoffman                       Informational                    [Page 42]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.35.2.  "ascii" Attribute
+
+   The ASCII equivalent of the organization's name.
+
+2.36.  <phone>
+
+   Represents a phone number.
+
+   The value is expected to be the scheme-specific part of a "tel" URI
+   (and so does not include the prefix "tel:"), using the
+   "global-number-digits" syntax.  See Section 3 of [RFC3966] for
+   details.
+
+   This element appears as a child element of <address> (Section 2.2).
+
+   Content model: only text content.
+
+2.37.  <postal>
+
+   Contains optional child elements providing postal information.  These
+   elements will be displayed in an order that is specific to
+   formatters.  A postal address can contain only a set of <street>,
+   <city>, <region>, <code>, and <country> elements, or only an ordered
+   set of <postalLine> elements, but not both.
+
+   This element appears as a child element of <address> (Section 2.2).
+
+   Content model:
+
+   Either:
+
+      In any order:
+
+      *  <city> elements (Section 2.13)
+
+      *  <code> elements (Section 2.14)
+
+      *  <country> elements (Section 2.15)
+
+      *  <region> elements (Section 2.43)
+
+      *  <street> elements (Section 2.49)
+
+   Or:
+
+      One or more <postalLine> elements (Section 2.38)
+
+
+
+
+
+Hoffman                       Informational                    [Page 43]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.38.  <postalLine>
+
+   Represents one line of a postal address.  When more than one
+   <postalLine> is given, the prep tool emits them in the order given.
+
+   This element appears as a child element of <postal> (Section 2.37).
+
+   Content model: only text content.
+
+2.38.1.  "ascii" Attribute
+
+   The ASCII equivalent of the text in the address line.
+
+2.39.  <refcontent>
+
+   Text that should appear between the title and the date of a
+   reference.  The purpose of this element is to prevent the need to
+   abuse <seriesInfo> to get such text in a reference.
+
+   For example:
+
+   <reference anchor="April1">
+     <front>
+       <title>On Being A Fool</title>
+       <author initials="K." surname="Phunny" fullname="Knot Phunny"/>
+       <date year="2000" month="April"/>
+     </front>
+     <refcontent>Self-published pamphlet</refcontent>
+   </reference>
+
+   would render as:
+
+      [April1]     Phunny, K., "On Being A Fool", Self-published
+                   pamphlet, April 2000.
+
+   This element appears as a child element of <reference>
+   (Section 2.40).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <em> elements (Section 2.22)
+
+
+
+
+Hoffman                       Informational                    [Page 44]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+2.40.  <reference>
+
+   Represents a bibliographic reference.
+
+   This element appears as a child element of <referencegroup>
+   (Section 2.41) and <references> (Section 2.42).
+
+   Content model:
+
+   In this order:
+
+   1.  One <front> element (Section 2.26)
+
+   2.  In any order:
+
+       *  <annotation> elements (Section 2.3)
+
+       *  <format> elements (Section 3.3)
+
+       *  <refcontent> elements (Section 2.39)
+
+       *  <seriesInfo> elements (Section 2.47; deprecated in this
+          context)
+
+2.40.1.  "anchor" Attribute (Mandatory)
+
+   Document-wide unique identifier for this reference.  Usually, this
+   will be used both to "label" the reference in the "References"
+   section and as an identifier in links to this reference entry.
+
+2.40.2.  "quoteTitle" Attribute
+
+   Specifies whether or not the title in the reference should be quoted.
+   This can be used to prevent quoting, such as on errata.
+
+   Allowed values:
+
+   o  "true" (default)
+
+   o  "false"
+
+
+
+Hoffman                       Informational                    [Page 45]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.40.3.  "target" Attribute
+
+   Holds the URI for the reference.
+
+2.41.  <referencegroup>
+
+   Represents a list of bibliographic references that will be
+   represented as a single reference.  This is most often used to
+   reference STDs and BCPs, where a single reference (such as "BCP 9")
+   may encompass more than one RFC.
+
+   This element appears as a child element of <references>
+   (Section 2.42).
+
+   Content model:
+
+   One or more <reference> elements (Section 2.40)
+
+2.41.1.  "anchor" Attribute (Mandatory)
+
+   Document-wide unique identifier for this reference group.  Usually,
+   this will be used both to "label" the reference group in the
+   "References" section and as an identifier in links to this reference
+   entry.
+
+2.42.  <references>
+
+   Contains a set of bibliographic references.
+
+   In the early days of the RFC Series, there was only one "References"
+   section per RFC.  This convention was later changed to group
+   references into two sets, "Normative" and "Informative", as described
+   in [RFC7322].  This vocabulary supports the split with the <name>
+   child element.  In general, the title should be either "Normative
+   References" or "Informative References".
+
+   This element appears as a child element of <back> (Section 2.8).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 46]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <name> element (Section 2.32)
+
+   2.  In any order:
+
+       *  <reference> elements (Section 2.40)
+
+       *  <referencegroup> elements (Section 2.41)
+
+2.42.1.  "anchor" Attribute
+
+   An optional user-supplied identifier for this set of references.
+
+2.42.2.  "title" Attribute
+
+   Deprecated.  Use <name> instead.
+
+2.43.  <region>
+
+   Provides the region name in a postal address.
+
+   This element appears as a child element of <postal> (Section 2.37).
+
+   Content model: only text content.
+
+2.43.1.  "ascii" Attribute
+
+   The ASCII equivalent of the region name.
+
+2.44.  <relref>
+
+   Represents a link to a specific part of a document that appears in a
+   <reference> element.  Formatters that have links (such as HTML and
+   PDF) render <relref> elements as external hyperlinks to the specified
+   part of the reference, creating the link target by combining the base
+   URI from the <reference> element with the "relative" attribute from
+   this element.  The "target" attribute is required, and it must be the
+   anchor of a <reference> element.
+
+   The "section" attribute is required, and the "relative" attribute is
+   optional.  If the reference is not an RFC or Internet-Draft that is
+   in the v3 format, the element needs to have a "relative" attribute;
+   in this case, the value of the "section" attribute is ignored.
+
+
+
+
+
+Hoffman                       Informational                    [Page 47]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   An example of the <relref> element with text content might be:
+
+         See
+         <relref section="2.3" target="RFC9999" displayFormat="bare">
+         the protocol overview</relref>
+         for more information.
+
+   An HTML formatter might generate:
+
+         See
+         <a href="http://www.rfc-editor.org/rfc/rfc9999.html#s-2.3">
+         the protocol overview</a>
+         for more information.
+
+   Note that the URL in the above example might be different when the
+   RFC Editor deploys the v3 format.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
+   <dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
+   (Section 2.29), <name> (Section 2.32), <preamble> (Section 3.6),
+   <strong> (Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52),
+   <t> (Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and
+   <tt> (Section 2.62).
+
+   Content model: only text content.
+
+2.44.1.  "displayFormat" Attribute
+
+   This attribute is used to signal formatters what the desired format
+   of the relative reference should be.  Formatters for document types
+   that have linking capability should wrap each part of the displayed
+   text in hyperlinks.  If there is content in the <relref> element,
+   formatters will ignore the value of this attribute.
+
+   "of"
+
+      A formatter should display the relative reference as the word
+      "Section" followed by a space, the contents of the "section"
+      attribute followed by a space, the word "of", another space, and
+      the value from the "target" attribute enclosed in square brackets.
+
+      For example, with an input of:
+
+         See
+         <relref section="2.3" target="RFC9999" displayFormat="of"/>
+         for an overview.
+
+
+
+
+Hoffman                       Informational                    [Page 48]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      An HTML formatter might generate:
+
+         See
+         <a href="http://www.rfc-editor.org/info/rfc9999#s-2.3">
+         Section 2.3</a> of
+         [<a href="#RFC9999">RFC9999</a>]
+         for an overview.
+
+      Note that "displayFormat='of'" is the default for <relref>, so it
+      does not need to be given in a <relref> element if that format is
+      desired.
+
+   "comma"
+
+      A formatter should display the relative reference as the value
+      from the "target" attribute enclosed in square brackets, a comma,
+      a space, the word "Section" followed by a space, and the "section"
+      attribute.
+
+      For example, with an input of:
+
+         See
+         <relref section="2.3" target="RFC9999" displayFormat="comma"/>,
+         for an overview.
+
+      An HTML formatter might generate:
+
+         See
+         [<a href="#RFC9999">RFC9999</a>],
+         <a href="http://www.rfc-editor.org/info/rfc9999#s-2.3">
+         Section 2.3</a>, for an overview.
+
+   "parens"
+
+      A formatter should display the relative reference as the value
+      from the "target" attribute enclosed in square brackets, a space,
+      a left parenthesis, the word "Section" followed by a space, the
+      "section" attribute, and a right parenthesis.
+
+      For example, with an input of:
+
+         See
+         <relref section="2.3" target="RFC9999" displayFormat="parens"/>
+         for an overview.
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 49]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      An HTML formatter might generate:
+
+         See
+         [<a href="#RFC9999">RFC9999</a>]
+         (<a href="http://www.rfc-editor.org/info/rfc9999#s-2.3">
+         Section 2.3</a>)
+         for an overview.
+
+   "bare"
+
+      A formatter should display the relative reference as the contents
+      of the "section" attribute and nothing else.  This is useful when
+      there are multiple relative references to a single base reference.
+
+      For example:
+
+         See Sections
+         <relref section="2.3" target="RFC9999" displayFormat="bare"/>
+         and
+         <relref section="2.4" target="RFC9999" displayFormat="of"/>
+         for an overview.
+
+      An HTML formatter might generate:
+
+         See Sections
+         <a href="http://www.rfc-editor.org/info/rfc9999#s-2.3">
+         2.3</a>
+         and
+         <a href="http://www.rfc-editor.org/info/rfc9999#s-2.4">
+         Section 2.4</a> of
+         [<a href="#RFC9999">RFC9999</a>]
+         for an overview.
+
+   Allowed values:
+
+   o  "of" (default)
+
+   o  "comma"
+
+   o  "parens"
+
+   o  "bare"
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 50]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.44.2.  "relative" Attribute
+
+   Specifies a relative reference from the URI in the target reference.
+   This value must include whatever leading character is needed to
+   create the relative reference; typically, this is "#" for HTML
+   documents.
+
+2.44.3.  "section" Attribute (Mandatory)
+
+   Specifies a section of the target reference.  If the reference is not
+   an RFC or Internet-Draft in the v3 format, it is an error.
+
+2.44.4.  "target" Attribute (Mandatory)
+
+   The anchor of the reference for this element.  If this value is not
+   an anchor to a <reference> or <referencegroup> element, it is an
+   error.  If the reference at the target has no URI, it is an error.
+
+2.45.  <rfc>
+
+   This is the root element of the xml2rfc vocabulary.
+
+   Content model:
+
+   In this order:
+
+   1.  Optional <link> elements (Section 2.30)
+
+   2.  One <front> element (Section 2.26)
+
+   3.  One <middle> element (Section 2.31)
+
+   4.  One optional <back> element (Section 2.8)
+
+2.45.1.  "category" Attribute
+
+   Deprecated; instead, use the "name" attribute in <seriesInfo>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 51]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.45.2.  "consensus" Attribute
+
+   Affects the generated boilerplate.  Note that the values of "no" and
+   "yes" are deprecated and are replaced by "false" (the default) and
+   "true".
+
+   See [RFC7841] for more information.
+
+   Allowed values:
+
+   o  "no"
+
+   o  "yes"
+
+   o  "false" (default)
+
+   o  "true"
+
+2.45.3.  "docName" Attribute
+
+   Deprecated; instead, use the "value" attribute in <seriesInfo>.
+
+2.45.4.  "indexInclude" Attribute
+
+   Specifies whether or not a formatter is requested to include an index
+   in generated files.  If the source file has no <iref> elements, an
+   index is never generated.  This option is useful for generating
+   documents where the source document has <iref> elements but the
+   author no longer wants an index.
+
+   Allowed values:
+
+   o  "true" (default)
+
+   o  "false"
+
+2.45.5.  "ipr" Attribute
+
+   Represents the Intellectual Property status of the document.  See
+   Appendix A.1 for details.
+
+2.45.6.  "iprExtract" Attribute
+
+   Identifies a single section within the document for which extraction
+   "as is" is explicitly allowed (only relevant for historic values of
+   the "ipr" attribute).
+
+
+
+
+
+Hoffman                       Informational                    [Page 52]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.45.7.  "number" Attribute
+
+   Deprecated; instead, use the "value" attribute in <seriesInfo>.
+
+2.45.8.  "obsoletes" Attribute
+
+   A comma-separated list of RFC numbers or Internet-Draft names.
+
+   The prep tool will parse the attribute value so that incorrect
+   references can be detected.
+
+2.45.9.  "prepTime" Attribute
+
+   The date that the XML was processed by a prep tool.  This is included
+   in the XML file just before it is saved to disk.  The value is
+   formatted using the "date-time" format defined in Section 5.6 of
+   [RFC3339].  The "time-offset" should be "Z".
+
+2.45.10.  "seriesNo" Attribute
+
+   Deprecated; instead, use the "value" attribute in <seriesInfo>.
+
+2.45.11.  "sortRefs" Attribute
+
+   Specifies whether or not the prep tool will sort the references in
+   each reference section.
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+2.45.12.  "submissionType" Attribute
+
+   The document stream, as described in [RFC7841].  (The RFC Series
+   Editor may change the list of allowed values in the future.)
+
+   Allowed values:
+
+   o  "IETF" (default)
+
+   o  "IAB"
+
+   o  "IRTF"
+
+   o  "independent"
+
+
+
+
+Hoffman                       Informational                    [Page 53]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.45.13.  "symRefs" Attribute
+
+   Specifies whether or not a formatter is requested to use symbolic
+   references (such as "[RFC2119]").  If the value for this is "false",
+   the references come out as numbers (such as "[3]").
+
+   Allowed values:
+
+   o  "true" (default)
+
+   o  "false"
+
+2.45.14.  "tocDepth" Attribute
+
+   Specifies the number of levels of headings that a formatter is
+   requested to include in the table of contents; the default is "3".
+
+2.45.15.  "tocInclude" Attribute
+
+   Specifies whether or not a formatter is requested to include a table
+   of contents in generated files.
+
+   Allowed values:
+
+   o  "true" (default)
+
+   o  "false"
+
+2.45.16.  "updates" Attribute
+
+   A comma-separated list of RFC numbers or Internet-Draft names.
+
+   The prep tool will parse the attribute value so that incorrect
+   references can be detected.
+
+2.45.17.  "version" Attribute
+
+   Specifies the version of xml2rfc syntax used in this document.  The
+   only expected value (for now) is "3".
+
+2.46.  <section>
+
+   Represents a section (when inside a <middle> element) or an appendix
+   (when inside a <back> element).
+
+   Subsections are created by nesting <section> elements inside
+   <section> elements.  Sections are allowed to be empty.
+
+
+
+
+Hoffman                       Informational                    [Page 54]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   This element appears as a child element of <back> (Section 2.8),
+   <boilerplate> (Section 2.11), <middle> (Section 2.31), and <section>
+   (Section 2.46).
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <name> element (Section 2.32)
+
+   2.  In any order:
+
+       *  <artwork> elements (Section 2.5)
+
+       *  <aside> elements (Section 2.6)
+
+       *  <blockquote> elements (Section 2.10)
+
+       *  <dl> elements (Section 2.20)
+
+       *  <figure> elements (Section 2.25)
+
+       *  <iref> elements (Section 2.27)
+
+       *  <ol> elements (Section 2.34)
+
+       *  <sourcecode> elements (Section 2.48)
+
+       *  <t> elements (Section 2.53)
+
+       *  <table> elements (Section 2.54)
+
+       *  <texttable> elements (Section 3.8)
+
+       *  <ul> elements (Section 2.63)
+
+   3.  Optional <section> elements (Section 2.46)
+
+2.46.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this section.
+
+2.46.2.  "numbered" Attribute
+
+   If set to "false", the formatter is requested to not display a
+   section number.  The prep tool will verify that such a section is not
+   followed by a numbered section in this part of the document and will
+   verify that the section is a top-level section.
+
+
+
+Hoffman                       Informational                    [Page 55]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Allowed values:
+
+   o  "true" (default)
+
+   o  "false"
+
+2.46.3.  "removeInRFC" Attribute
+
+   If set to "true", this note is marked in the prep tool with text
+   indicating that it should be removed before the document is published
+   as an RFC.  That text will be "This note is to be removed before
+   publishing as an RFC."
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+2.46.4.  "title" Attribute
+
+   Deprecated.  Use <name> instead.
+
+2.46.5.  "toc" Attribute
+
+   Indicates to a formatter whether or not the section is to be included
+   in a table of contents, if such a table of contents is produced.
+   This only takes effect if the level of the section would have
+   appeared in the table of contents based on the "tocDepth" attribute
+   of the <rfc> element, and of course only if the table of contents is
+   being created based on the "tocInclude" attribute of the <rfc>
+   element.  If this is set to "exclude", any section below this one
+   will be excluded as well.  The "default" value indicates inclusion of
+   the section if it would be included by the tocDepth attribute of the
+   <rfc> element.
+
+   Allowed values:
+
+   o  "include"
+
+   o  "exclude"
+
+   o  "default" (default)
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 56]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.47.  <seriesInfo>
+
+   Specifies the document series in which this document appears, and
+   also specifies an identifier within that series.
+
+   A processing tool determines whether it is working on an RFC or an
+   Internet-Draft by inspecting the "name" attribute of a <seriesInfo>
+   element inside the <front> element inside the <rfc> element, looking
+   for "RFC" or "Internet-Draft".  (Specifying neither value in any of
+   the <seriesInfo> elements can be useful for producing other types of
+   documents but is out of scope for this specification.)
+
+   It is invalid to have multiple <seriesInfo> elements inside the same
+   <front> element containing the same "name" value.  Some combinations
+   of <seriesInfo> "name" attribute values make no sense, such as having
+   both <seriesInfo name="rfc"/> and <seriesInfo name="Internet-Draft"/>
+   in the same <front> element.
+
+   This element appears as a child element of <front> (Section 2.26) and
+   <reference> (Section 2.40; deprecated in this context).
+
+   Content model: this element does not have any contents.
+
+2.47.1.  "asciiName" Attribute
+
+   The ASCII equivalent of the name field.
+
+2.47.2.  "asciiValue" Attribute
+
+   The ASCII equivalent of the value field.
+
+2.47.3.  "name" Attribute (Mandatory)
+
+   The name of the series.  The currently known values are "RFC",
+   "Internet-Draft", and "DOI".  The RFC Series Editor may change this
+   list in the future.
+
+   Some of the values for "name" interact as follows:
+
+   o  If a <front> element contains a <seriesInfo> element with a name
+      of "Internet-Draft", it can also have at most one additional
+      <seriesInfo> element with a "status" attribute whose value is of
+      "standard", "full-standard", "bcp", "fyi", "informational",
+      "experimental", or "historic" to indicate the intended status of
+      this Internet-Draft, if it were to be later published as an RFC.
+      If such an additional <seriesInfo> element has one of those
+      statuses, the name needs to be "".
+
+
+
+
+Hoffman                       Informational                    [Page 57]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  If a <front> element contains a <seriesInfo> element with a name
+      of "RFC", it can also have at most one additional <seriesInfo>
+      element with a "status" attribute whose value is of
+      "full-standard", "bcp", or "fyi" to indicate the current status of
+      this RFC.  If such an additional <seriesInfo> element has one of
+      those statuses, the "value" attribute for that name needs to be
+      the number within that series.  That <front> element might also
+      contain an additional <seriesInfo> element with the status of
+      "info", "exp", or "historic" and a name of "" to indicate the
+      status of the RFC.
+
+   o  A <front> element that has a <seriesInfo> element that has the
+      name "Internet-Draft" cannot also have a <seriesInfo> element that
+      has the name "RFC".
+
+   o  The <seriesInfo> element can contain the DOI for the referenced
+      document.  This cannot be used when the <seriesInfo> element is an
+      eventual child element of an <rfc> element -- only as an eventual
+      child of a <reference> element.  The "value" attribute should use
+      the form specified in [RFC7669].
+
+2.47.4.  "status" Attribute
+
+   The status of this document.  The currently known values are
+   "standard", "informational", "experimental", "bcp", "fyi", and
+   "full-standard".  The RFC Series Editor may change this list in the
+   future.
+
+2.47.5.  "stream" Attribute
+
+   The stream (as described in [RFC7841]) that originated the document.
+   (The RFC Series Editor may change this list in the future.)
+
+   Allowed values:
+
+   o  "IETF" (default)
+
+   o  "IAB"
+
+   o  "IRTF"
+
+   o  "independent"
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 58]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.47.6.  "value" Attribute (Mandatory)
+
+   The identifier within the series specified by the "name" attribute.
+
+   For BCPs, FYIs, RFCs, and STDs, this is the number within the series.
+   For Internet-Drafts, it is the full draft name (ending with the
+   two-digit version number).  For DOIs, the value is given, such as
+   "10.17487/rfc1149", as described in [RFC7669].
+
+   The name in the value should be the document name without any file
+   extension.  For Internet-Drafts, the value for this attribute should
+   be "draft-ietf-somewg-someprotocol-07", not
+   "draft-ietf-somewg-someprotocol-07.txt".
+
+2.48.  <sourcecode>
+
+   This element allows the inclusion of source code into the document.
+
+   When rendered, source code is always shown in a monospace font.  When
+   <sourcecode> is a child of <figure> or <section>, it provides full
+   control of horizontal whitespace and line breaks.  When formatted, it
+   is indented relative to the left margin of the enclosing element.  It
+   is thus useful for source code and formal languages (such as ABNF
+   [RFC5234] or the RNC notation used in this document).  (When
+   <sourcecode> is a child of other elements, it flows with the text
+   that surrounds it.)  Tab characters (U+0009) inside of this element
+   are prohibited.
+
+   For artwork such as character-based art, diagrams of message layouts,
+   and so on, use the <artwork> element instead.
+
+   Output formatters that do pagination should attempt to keep source
+   code on a single page.  This is to prevent source code that is split
+   across pages from looking like two separate pieces of code.
+
+   See Section 5 for a description of how to deal with issues of using
+   "&" and "<" characters in source code.
+
+   This element appears as a child element of <blockquote>
+   (Section 2.10), <dd> (Section 2.18), <figure> (Section 2.25), <li>
+   (Section 2.29), <section> (Section 2.46), <td> (Section 2.56), and
+   <th> (Section 2.58).
+
+   Content model: only text content.
+
+2.48.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this source code.
+
+
+
+Hoffman                       Informational                    [Page 59]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.48.2.  "name" Attribute
+
+   A filename suitable for the contents (such as for extraction to a
+   local file).  This attribute can be helpful for other kinds of tools
+   (such as automated syntax checkers, which work by extracting the
+   source code).  Note that the "name" attribute does not need to be
+   unique for <artwork> elements in a document.  If multiple
+   <sourcecode> elements have the same "name" attribute, a formatter
+   might assume that the elements are all fragments of a single file,
+   and such a formatter can collect those fragments for later
+   processing.
+
+2.48.3.  "src" Attribute
+
+   The URI reference of a source file [RFC3986].
+
+   It is an error to have both a "src" attribute and content in the
+   <sourcecode> element.
+
+2.48.4.  "type" Attribute
+
+   Specifies the type of the source code.  The value of this attribute
+   is free text with certain values designated as preferred.
+
+   The preferred values for <sourcecode> types are:
+
+   o  abnf
+
+   o  asn.1
+
+   o  bash
+
+   o  c++
+
+   o  c
+
+   o  cbor
+
+   o  dtd
+
+   o  java
+
+   o  javascript
+
+   o  json
+
+   o  mib
+
+
+
+
+Hoffman                       Informational                    [Page 60]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  perl
+
+   o  pseudocode
+
+   o  python
+
+   o  rnc
+
+   o  xml
+
+   o  yang
+
+   The RFC Series Editor will maintain a complete list of the preferred
+   values on the RFC Editor web site, and that list is expected to be
+   updated over time.  Thus, a consumer of v3 XML should not cause a
+   failure when it encounters an unexpected type or no type is
+   specified.
+
+2.49.  <street>
+
+   Provides a street address.
+
+   This element appears as a child element of <postal> (Section 2.37).
+
+   Content model: only text content.
+
+2.49.1.  "ascii" Attribute
+
+   The ASCII equivalent of the street address.
+
+2.50.  <strong>
+
+   Indicates text that is semantically strong.  Text enclosed within
+   this element will be displayed as bold after processing.  This
+   element can be combined with other character formatting elements, and
+   the formatting will be additive.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
+   <dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
+   (Section 2.29), <preamble> (Section 3.6), <refcontent>
+   (Section 2.39), <sub> (Section 2.51), <sup> (Section 2.52), <t>
+   (Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and <tt>
+   (Section 2.62).
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 61]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.51.  <sub>
+
+   Causes the text to be displayed as subscript, approximately half a
+   letter-height lower than normal text.  This element can be combined
+   with other character formatting elements, and the formatting will be
+   additive.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
+   <dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
+   (Section 2.29), <preamble> (Section 3.6), <refcontent>
+   (Section 2.39), <strong> (Section 2.50), <t> (Section 2.53), <td>
+   (Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62).
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 62]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.52.  <sup>
+
+   Causes the text to be displayed as superscript, approximately half a
+   letter-height higher than normal text.  This element can be combined
+   with other character formatting elements, and the formatting will be
+   additive.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
+   <dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
+   (Section 2.29), <preamble> (Section 3.6), <refcontent>
+   (Section 2.39), <strong> (Section 2.50), <t> (Section 2.53), <td>
+   (Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+
+
+
+Hoffman                       Informational                    [Page 63]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+2.53.  <t>
+
+   Contains a paragraph of text.
+
+   This element appears as a child element of <abstract> (Section 2.1),
+   <aside> (Section 2.6), <blockquote> (Section 2.10), <dd>
+   (Section 2.18), <li> (Section 2.29), <list> (Section 3.4), <note>
+   (Section 2.33), <section> (Section 2.46), <td> (Section 2.56), and
+   <th> (Section 2.58).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <list> elements (Section 3.4)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <spanx> elements (Section 3.7)
+
+   o  <strong> elements (Section 2.50)
+
+
+
+
+Hoffman                       Informational                    [Page 64]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <vspace> elements (Section 3.10)
+
+   o  <xref> elements (Section 2.66)
+
+2.53.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this paragraph.
+
+2.53.2.  "hangText" Attribute
+
+   Deprecated.  Instead, use <dd> inside of a definition list (<dl>).
+
+2.53.3.  "keepWithNext" Attribute
+
+   Acts as a hint to the output formatters that do pagination to do a
+   best-effort attempt to keep the paragraph with the next element,
+   whatever that happens to be.  For example, the HTML output @media
+   print CSS ("CSS" refers to Cascading Style Sheets) might translate
+   this to page-break-after: avoid.  For PDF, the paginator could
+   attempt to keep the paragraph with the next element.  Note: this
+   attribute is strictly a hint and not always actionable.
+
+   Allowed values:
+
+   o  "false" (default)
+
+   o  "true"
+
+2.53.4.  "keepWithPrevious" Attribute
+
+   Acts as a hint to the output formatters that do pagination to do a
+   best-effort attempt to keep the paragraph with the previous element,
+   whatever that happens to be.  For example, the HTML output @media
+   print CSS might translate this to page-break-before: avoid.  For PDF,
+   the paginator could attempt to keep the paragraph with the previous
+   element.  Note: this attribute is strictly a hint and not always
+   actionable.
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 65]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Allowed values:
+
+   o  "false" (default)
+
+   o  "true"
+
+2.54.  <table>
+
+   Contains a table with a caption with the table number.  If the
+   element contains a <name> element, the caption will also show that
+   name.
+
+   Inside the <table> element is, optionally, a <thead> element to
+   contain the rows that will be the table's heading and, optionally, a
+   <tfoot> element to contain the rows of the table's footer.  If the
+   XML is converted to a representation that has page breaks (such as
+   PDFs or printed HTML), the header and footer are meant to appear on
+   each page.
+
+   This element appears as a child element of <aside> (Section 2.6) and
+   <section> (Section 2.46).
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <name> element (Section 2.32)
+
+   2.  Optional <iref> elements (Section 2.27)
+
+   3.  One optional <thead> element (Section 2.59)
+
+   4.  One or more <tbody> elements (Section 2.55)
+
+   5.  One optional <tfoot> element (Section 2.57)
+
+2.54.1.  "anchor" Attribute
+
+   Document-wide unique identifier for this table.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 66]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.55.  <tbody>
+
+   A container for a set of body rows for a table.
+
+   This element appears as a child element of <table> (Section 2.54).
+
+   Content model:
+
+   One or more <tr> elements (Section 2.61)
+
+2.55.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the tbody.
+
+2.56.  <td>
+
+   A cell in a table row.
+
+   This element appears as a child element of <tr> (Section 2.61).
+
+   Content model:
+
+   Either:
+
+      In any order, but at least one of:
+
+      *  <artwork> elements (Section 2.5)
+
+      *  <dl> elements (Section 2.20)
+
+      *  <figure> elements (Section 2.25)
+
+      *  <ol> elements (Section 2.34)
+
+      *  <sourcecode> elements (Section 2.48)
+
+      *  <t> elements (Section 2.53)
+
+      *  <ul> elements (Section 2.63)
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 67]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Or:
+
+      In any order:
+
+      *  Text
+
+      *  <bcp14> elements (Section 2.9)
+
+      *  <br> elements (Section 2.12)
+
+      *  <cref> elements (Section 2.16)
+
+      *  <em> elements (Section 2.22)
+
+      *  <eref> elements (Section 2.24)
+
+      *  <iref> elements (Section 2.27)
+
+      *  <relref> elements (Section 2.44)
+
+      *  <strong> elements (Section 2.50)
+
+      *  <sub> elements (Section 2.51)
+
+      *  <sup> elements (Section 2.52)
+
+      *  <tt> elements (Section 2.62)
+
+      *  <xref> elements (Section 2.66)
+
+2.56.1.  "align" Attribute
+
+   Controls whether the content of the cell appears left justified
+   (default), centered, or right justified.  Note that "center" or
+   "right" will probably only work well in cells with plain text; any
+   other elements might make the contents render badly.
+
+   Allowed values:
+
+   o  "left" (default)
+
+   o  "center"
+
+   o  "right"
+
+2.56.2.  "anchor" Attribute
+
+   Document-wide unique identifier for the cell.
+
+
+
+Hoffman                       Informational                    [Page 68]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.56.3.  "colspan" Attribute
+
+   The number of columns that the cell is to span.  For example, setting
+   "colspan='3'" indicates that the cell occupies the same horizontal
+   space as three cells of a row without any "colspan" attributes.
+
+2.56.4.  "rowspan" Attribute
+
+   The number of rows that the cell is to span.  For example, setting
+   "rowspan='3'" indicates that the cell occupies the same vertical
+   space as three rows.
+
+2.57.  <tfoot>
+
+   A container for a set of footer rows for a table.
+
+   This element appears as a child element of <table> (Section 2.54).
+
+   Content model:
+
+   One or more <tr> elements (Section 2.61)
+
+2.57.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the tfoot.
+
+2.58.  <th>
+
+   A cell in a table row.  When rendered, this will normally come out in
+   boldface; other than that, there is no difference between this and
+   the <td> element.
+
+   This element appears as a child element of <tr> (Section 2.61).
+
+   Content model:
+
+   Either:
+
+      In any order, but at least one of:
+
+      *  <artwork> elements (Section 2.5)
+
+      *  <dl> elements (Section 2.20)
+
+      *  <figure> elements (Section 2.25)
+
+      *  <ol> elements (Section 2.34)
+
+
+
+
+Hoffman                       Informational                    [Page 69]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+      *  <sourcecode> elements (Section 2.48)
+
+      *  <t> elements (Section 2.53)
+
+      *  <ul> elements (Section 2.63)
+
+   Or:
+
+      In any order:
+
+      *  Text
+
+      *  <bcp14> elements (Section 2.9)
+
+      *  <br> elements (Section 2.12)
+
+      *  <cref> elements (Section 2.16)
+
+      *  <em> elements (Section 2.22)
+
+      *  <eref> elements (Section 2.24)
+
+      *  <iref> elements (Section 2.27)
+
+      *  <relref> elements (Section 2.44)
+
+      *  <strong> elements (Section 2.50)
+
+      *  <sub> elements (Section 2.51)
+
+      *  <sup> elements (Section 2.52)
+
+      *  <tt> elements (Section 2.62)
+
+      *  <xref> elements (Section 2.66)
+
+2.58.1.  "align" Attribute
+
+   Controls whether the content of the cell appears left justified
+   (default), centered, or right justified.  Note that "center" or
+   "right" will probably only work well in cells with plain text; any
+   other elements might make the contents render badly.
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 70]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Allowed values:
+
+   o  "left" (default)
+
+   o  "center"
+
+   o  "right"
+
+2.58.2.  "anchor" Attribute
+
+   Document-wide unique identifier for the row.
+
+2.58.3.  "colspan" Attribute
+
+   The number of columns that the cell is to span.  For example, setting
+   "colspan='3'" indicates that the cell occupies the same horizontal
+   space as three cells of a row without any "colspan" attributes.
+
+2.58.4.  "rowspan" Attribute
+
+   The number of rows that the cell is to span.  For example, setting
+   "rowspan='3'" indicates that the cell occupies the same vertical
+   space as three rows.
+
+2.59.  <thead>
+
+   A container for a set of header rows for a table.
+
+   This element appears as a child element of <table> (Section 2.54).
+
+   Content model:
+
+   One or more <tr> elements (Section 2.61)
+
+2.59.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the thead.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 71]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.60.  <title>
+
+   Represents the document title.
+
+   When this element appears in the <front> element of the current
+   document, the title might also appear in page headers or footers.  If
+   it is long (~40 characters), the "abbrev" attribute can be used to
+   specify an abbreviated variant.
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model: only text content.
+
+2.60.1.  "abbrev" Attribute
+
+   Specifies an abbreviated variant of the document title.
+
+2.60.2.  "ascii" Attribute
+
+   The ASCII equivalent of the title.
+
+2.61.  <tr>
+
+   A row of a table.
+
+   This element appears as a child element of <tbody> (Section 2.55),
+   <tfoot> (Section 2.57), and <thead> (Section 2.59).
+
+   Content model:
+
+   In any order, but at least one of:
+
+   o  <td> elements (Section 2.56)
+
+   o  <th> elements (Section 2.58)
+
+2.61.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the row.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 72]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.62.  <tt>
+
+   Causes the text to be displayed in a constant-width font.  This
+   element can be combined with other character formatting elements, and
+   the formatting will be additive.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16),
+   <dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li>
+   (Section 2.29), <name> (Section 2.32), <preamble> (Section 3.6),
+   <refcontent> (Section 2.39), <strong> (Section 2.50), <sub>
+   (Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td>
+   (Section 2.56), and <th> (Section 2.58).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <relref> elements (Section 2.44)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <xref> elements (Section 2.66)
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 73]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.63.  <ul>
+
+   An unordered list.  The labels on the items will be symbols picked by
+   the formatter.
+
+   This element appears as a child element of <abstract> (Section 2.1),
+   <aside> (Section 2.6), <blockquote> (Section 2.10), <dd>
+   (Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section>
+   (Section 2.46), <td> (Section 2.56), and <th> (Section 2.58).
+
+   Content model:
+
+   One or more <li> elements (Section 2.29)
+
+2.63.1.  "anchor" Attribute
+
+   Document-wide unique identifier for the list.
+
+2.63.2.  "empty" Attribute
+
+   Defines whether or not the label is empty.  empty="true" indicates
+   that no label will be shown.
+
+   Allowed values:
+
+   o  "false" (default)
+
+   o  "true"
+
+2.63.3.  "spacing" Attribute
+
+   Defines whether or not there is a blank line between entries.
+   spacing="normal" indicates a single blank line, while
+   spacing="compact" indicates no space between.
+
+   Allowed values:
+
+   o  "normal" (default)
+
+   o  "compact"
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 74]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.64.  <uri>
+
+   Contains a web address associated with the author.
+
+   The contents should be a valid URI; this most likely will be an
+   "http:" or "https:" URI.
+
+   This element appears as a child element of <address> (Section 2.2).
+
+   Content model: only text content.
+
+2.65.  <workgroup>
+
+   This element is used to specify the Working Group (IETF) or Research
+   Group (IRTF) from which the document originates, if any.  The
+   recommended format is the official name of the Working Group (with
+   some capitalization).
+
+   In Internet-Drafts, this is used in the upper left corner of the
+   boilerplate, replacing the "Network Working Group" string.
+   Formatting software can append the words "Working Group" or "Research
+   Group", depending on the "submissionType" property of the <rfc>
+   element (Section 2.45.12).
+
+   This element appears as a child element of <front> (Section 2.26).
+
+   Content model: only text content.
+
+2.66.  <xref>
+
+   A reference to an anchor in this document.  Formatters that have
+   links (such as HTML and PDF) are likely to render <xref> elements as
+   internal hyperlinks.  This element is useful for referring to
+   references in the "References" section, to specific sections of this
+   document, to specific figures, and so on.  The "target" attribute is
+   required.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <cref>
+   (Section 2.16), <dd> (Section 2.18), <dt> (Section 2.21), <em>
+   (Section 2.22), <li> (Section 2.29), <name> (Section 2.32),
+   <postamble> (Section 3.5), <preamble> (Section 3.6), <strong>
+   (Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t>
+   (Section 2.53), <td> (Section 2.56), <th> (Section 2.58), <tt>
+   (Section 2.62), and <ttcol> (Section 3.9).
+
+   Content model: only text content.
+
+
+
+
+Hoffman                       Informational                    [Page 75]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+2.66.1.  "format" Attribute
+
+   This attribute signals to formatters what the desired format of the
+   reference should be.  Formatters for document types that have linking
+   capability should wrap the displayed text in hyperlinks.
+
+   "counter"
+
+      The "derivedContent" attribute will contain just a counter.  This
+      is used for targets that are <section>, <figure>, <table>, or
+      items in an ordered list.  Using "format='counter'" where the
+      target is any other type of element is an error.
+
+      For example, with an input of:
+
+         <section anchor="overview">Protocol Overview</section>
+         . . .
+         See Section <xref target="overview" format="counter"/>
+         for an overview.
+
+      An HTML formatter might generate:
+
+         See Section <a href="#overview">1.7</a> for an overview.
+
+   "default"
+
+      If the element has no content, the "derivedContent" attribute will
+      contain a text fragment that describes the referenced part
+      completely, such as "XML" for a target that is a <reference>, or
+      "Section 2" or "Table 4" for a target to a non-reference.  (If the
+      element has content, the "derivedContent" attribute is filled with
+      the content.)
+
+      For example, with an input of:
+
+         <section anchor="overview">Protocol Overview</section>
+         . . .
+         See <xref target="overview"/> for an overview.
+
+      An HTML formatter might generate:
+
+         See <a href="#overview">Section 1.7</a> for an overview.
+
+   "none"
+
+      Deprecated.
+
+
+
+
+
+Hoffman                       Informational                    [Page 76]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   "title"
+
+      If the target is a <reference> element, the "derivedContent"
+      attribute will contain the name of the reference, extracted from
+      the <title> child of the <front> child of the reference.  Or, if
+      the target element has a <name> child element, the
+      "derivedContent" attribute will contain the text content of that
+      <name> element concatenated with the text content of each
+      descendant node of <name> (that is, stripping out all of the XML
+      markup, leaving only the text).  Or, if the target element does
+      not contain a <name> child element, the "derivedContent" attribute
+      will contain the name of the "anchor" attribute of that element
+      with no other adornment.
+
+   Allowed values:
+
+   o  "default" (default)
+
+   o  "title"
+
+   o  "counter"
+
+   o  "none"
+
+2.66.2.  "pageno" Attribute
+
+   Deprecated.
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+2.66.3.  "target" Attribute (Mandatory)
+
+   Identifies the document component being referenced.  The value needs
+   to match the value of the "anchor" attribute of an element in the
+   document; otherwise, it is an error.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 77]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.  Elements from v2 That Have Been Deprecated
+
+   This section lists the elements from v2 that have been deprecated.
+   Note that some elements in v3 have attributes from v2 that are
+   deprecated; those are not listed here.
+
+3.1.  <c>
+
+   Deprecated.  Instead, use <tr>, <td>, and <th>.
+
+   This element appears as a child element of <texttable> (Section 3.8).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <spanx> elements (Section 3.7)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+3.2.  <facsimile>
+
+   Deprecated.  The <email> element is a much more useful way to get in
+   touch with authors.
+
+   This element appears as a child element of <address> (Section 2.2).
+
+   Content model: only text content.
+
+
+
+Hoffman                       Informational                    [Page 78]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.3.  <format>
+
+   Deprecated.  If the goal is to provide a single URI for a reference,
+   use the "target" attribute in <reference> instead.
+
+   This element appears as a child element of <reference>
+   (Section 2.40).
+
+   Content model: this element does not have any contents.
+
+3.3.1.  "octets" Attribute
+
+   Deprecated.
+
+3.3.2.  "target" Attribute
+
+   Deprecated.
+
+3.3.3.  "type" Attribute (Mandatory)
+
+   Deprecated.
+
+3.4.  <list>
+
+   Deprecated.  Instead, use <dl> for list/@style "hanging"; <ul> for
+   list/@style "empty" or "symbols"; and <ol> for list/@style "letters",
+   "numbers", "counter", or "format".
+
+   This element appears as a child element of <t> (Section 2.53).
+
+   Content model:
+
+   One or more <t> elements (Section 2.53)
+
+3.4.1.  "counter" Attribute
+
+   Deprecated.  The functionality of this attribute has been replaced
+   with <ol>/@start.
+
+3.4.2.  "hangIndent" Attribute
+
+   Deprecated.  Use <dl> instead.
+
+3.4.3.  "style" Attribute
+
+   Deprecated.
+
+
+
+
+
+Hoffman                       Informational                    [Page 79]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.5.  <postamble>
+
+   Deprecated.  Instead, use a regular paragraph after the figure or
+   table.
+
+   This element appears as a child element of <figure> (Section 2.25)
+   and <texttable> (Section 3.8).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <spanx> elements (Section 3.7)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 80]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.6.  <preamble>
+
+   Deprecated.  Instead, use a regular paragraph before the figure or
+   table.
+
+   This element appears as a child element of <figure> (Section 2.25)
+   and <texttable> (Section 3.8).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <bcp14> elements (Section 2.9)
+
+   o  <cref> elements (Section 2.16)
+
+   o  <em> elements (Section 2.22)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <spanx> elements (Section 3.7)
+
+   o  <strong> elements (Section 2.50)
+
+   o  <sub> elements (Section 2.51)
+
+   o  <sup> elements (Section 2.52)
+
+   o  <tt> elements (Section 2.62)
+
+   o  <xref> elements (Section 2.66)
+
+3.7.  <spanx>
+
+   Deprecated.
+
+   This element appears as a child element of <annotation>
+   (Section 2.3), <c> (Section 3.1), <postamble> (Section 3.5),
+   <preamble> (Section 3.6), and <t> (Section 2.53).
+
+   Content model: only text content.
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 81]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.7.1.  "style" Attribute
+
+   Deprecated.  Instead of <spanx style="emph">, use <em>; instead of
+   <spanx style="strong">, use <strong>; instead of <spanx
+   style="verb">, use <tt>.
+
+3.7.2.  "xml:space" Attribute
+
+   Deprecated.
+
+   Allowed values:
+
+   o  "default"
+
+   o  "preserve" (default)
+
+3.8.  <texttable>
+
+   Deprecated.  Use <table> instead.
+
+   This element appears as a child element of <aside> (Section 2.6) and
+   <section> (Section 2.46).
+
+   Content model:
+
+   In this order:
+
+   1.  One optional <name> element (Section 2.32)
+
+   2.  One optional <preamble> element (Section 3.6)
+
+   3.  One or more <ttcol> elements (Section 3.9)
+
+   4.  Optional <c> elements (Section 3.1)
+
+   5.  One optional <postamble> element (Section 3.5)
+
+3.8.1.  "align" Attribute
+
+   Deprecated.
+
+   Allowed values:
+
+   o  "left"
+
+   o  "center" (default)
+
+   o  "right"
+
+
+
+Hoffman                       Informational                    [Page 82]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.8.2.  "anchor" Attribute
+
+   Deprecated.
+
+3.8.3.  "style" Attribute
+
+   Deprecated.
+
+3.8.4.  "suppress-title" Attribute
+
+   Deprecated.
+
+   Allowed values:
+
+   o  "true"
+
+   o  "false" (default)
+
+3.8.5.  "title" Attribute
+
+   Deprecated.
+
+3.9.  <ttcol>
+
+   Deprecated.  Instead, use <tr>, <td>, and <th>.
+
+   This element appears as a child element of <texttable> (Section 3.8).
+
+   Content model:
+
+   In any order:
+
+   o  Text
+
+   o  <cref> elements (Section 2.16)
+
+   o  <eref> elements (Section 2.24)
+
+   o  <iref> elements (Section 2.27)
+
+   o  <xref> elements (Section 2.66)
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 83]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+3.9.1.  "align" Attribute
+
+   Deprecated.
+
+   Allowed values:
+
+   o  "left" (default)
+
+   o  "center"
+
+   o  "right"
+
+3.9.2.  "width" Attribute
+
+   Deprecated.
+
+3.10.  <vspace>
+
+   Deprecated.  In earlier versions of this format, <vspace> was often
+   used to get an extra blank line in a list element; in the v3
+   vocabulary, that can be done instead by using multiple <t> elements
+   inside the <li> element.  Other uses have no direct replacement.
+
+   This element appears as a child element of <t> (Section 2.53).
+
+   Content model: this element does not have any contents.
+
+3.10.1.  "blankLines" Attribute
+
+   Deprecated.
+
+4.  SVG
+
+   The discussion of the use of SVG can be found in [RFC7996].  This
+   element is part of the namespace "http://www.w3.org/2000/svg".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 84]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+5.  Use of CDATA Structures and Escaping
+
+   A common problem authors have with <artwork> and <sourcecode>
+   elements is that the XML processor returns errors if the text in the
+   artwork contains either the "&" or "<" character, or the string
+   "]]>".  To avoid these problems, the "&" and "<" characters may be
+   escaped using the strings "&amp;" and "&lt;", respectively; the "]]>"
+   string can be represented as "]]&gt;".  Alternatively, they may be
+   surrounded in a CDATA structure: "<![CDATA[]]>".  For example:
+
+   Desired output:
+      allowed-chars = "." | "," | "&" | "<" | ">" | "|"
+
+   Using escaping:
+   <sourcecode>
+      allowed-chars = "." | "," | "&amp;" | "&lt;" | "&gt;" | "|"
+   </sourcecode>
+
+   Using CDATA:
+   <sourcecode>
+   <![CDATA[   allowed-chars = "." | "," | "&" | "<" | ">" | "|"]]>
+   </sourcecode>
+
+   Using CDATA is not a panacea, but it does help prevent having to use
+   escapes in places where using escapes can cause other problems, such
+   as difficulty of inclusion from other documents.
+
+6.  Internationalization Considerations
+
+   This format is based on [XML] and thus does not have any issues
+   representing arbitrary Unicode [UNICODE] characters in text content.
+   The RFC Series Editor may restrict some of the characters that can be
+   used in a particular RFC; the rules for such restrictions are covered
+   in [RFC7997].
+
+7.  Security Considerations
+
+   The "name" attribute of the <artwork> element (Section 2.5.5) can be
+   used to derive a filename for saving to a local file system.
+   Trusting this kind of information without pre-processing is a known
+   security risk; see Section 4.3 of [RFC6266] for more information.
+
+   The "src" attribute of the <artwork> element can be used to read
+   files from the local system.  Processing tools must be careful to not
+   accept dangerous values for the filename, particularly those that
+   contain absolute references outside the current directory.
+
+
+
+
+
+Hoffman                       Informational                    [Page 85]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   The "type" attribute of the <artwork> and <sourcecode> elements is
+   meant to encourage formatters to automatically extract known types of
+   content from an RFC or Internet-Draft.  While extraction is probably
+   safe, those tools might also think that they could further process
+   the extracted content, such as by rendering artwork or executing
+   code.  Doing so without first sanity-checking the extracted content
+   is clearly a terrible idea from a security perspective.  More
+   generally, a tool that is reading XML input needs to be suspicious of
+   any content that it intends to post-process.
+
+   When there is an external reference to a URL, a processor or renderer
+   should fetch the content into a sandbox and should have only a
+   localized impact on the document processing and rendering.
+
+   All security considerations related to XML processing are relevant as
+   well (see Section 7 of [RFC3470]).
+
+8.  IANA Considerations
+
+8.1.  Internet Media Type Registration
+
+   IANA maintains the registry of Internet Media Types [RFC6838] at
+   <https://www.iana.org/assignments/media-types>.
+
+   This document updates the specification for the Internet Media Type
+   "application/rfc+xml" from the one in [RFC7749].  The following has
+   been registered with IANA.
+
+   Type name:  application
+
+   Subtype name:  rfc+xml
+
+   Required parameters:  There are no required parameters.
+
+   Optional parameters:  "charset": This parameter has identical
+      semantics to the charset parameter of the "application/xml" Media
+      Type specified in Section 9.1 of [RFC7303].
+
+   Encoding considerations:  Identical to those of "application/xml" as
+      described in Section 9.1 of [RFC7303].
+
+   Security considerations:  As defined in Section 7.  In addition, as
+      this Media Type uses the "+xml" convention, it inherits the
+      security considerations described in Section 10 of [RFC7303].
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 86]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Interoperability considerations:  Different implementations of this
+      format have had interoperability issues.  It is not expected that
+      publication of this application will cause those implementations
+      to be fixed.
+
+   Published specification:  This specification.
+
+   Applications that use this Media Type:  Applications that transform
+      xml2rfc to output representations such as plain text or HTML, plus
+      additional analysis tools.
+
+   Fragment identifier considerations:  The "anchor" attribute is used
+      for assigning document-wide unique identifiers that can be used as
+      shorthand pointers, as described in [XPOINTER].
+
+   Additional information:
+
+      Deprecated alias names for this type:  None
+
+      Magic number(s):  As specified for "application/xml" in [RFC7303].
+
+      File extension(s):  .xml or .rfcxml when disambiguation from other
+         XML files is needed
+
+      Macintosh file type code(s):  TEXT
+
+   Person & email address to contact for further information:  See the
+      Author's Address section of RFC 7991.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  None
+
+   Author:  See the Author's Address section of RFC 7991.
+
+   Change controller:  RFC Series Editor (rse@rfc-editor.org)
+
+8.2.  Link Relation Registration
+
+   IANA has registered "convertedFrom" in the "Link Relation Types"
+   registry [LINKRELATIONS].
+
+   Relation Name: convertedFrom
+
+   Description: The document linked to was later converted to the
+   document that contains this link relation.  For example, an RFC can
+   have a link to the Internet-Draft that became the RFC; in that case,
+   the link relation would be "convertedFrom".
+
+
+
+Hoffman                       Informational                    [Page 87]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   Reference: This document.
+
+   Notes: This relation is different than "predecessor-version" in that
+   "predecessor-version" is for items in a version control system.  It
+   is also different than "previous" in that this relation is used for
+   converted resources, not those that are part of a sequence of
+   resources.
+
+   Application Data: None
+
+9.  References
+
+9.1.  Normative References
+
+   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/bcp14>.
+
+   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
+              and F. Yergeau, "Extensible Markup Language (XML) 1.0
+              (Fifth Edition)", W3C Recommendation REC-xml-20081126,
+              November 2008,
+              <https://www.w3.org/TR/2008/REC-xml-20081126/>.
+
+              Latest version available at <http://www.w3.org/TR/xml>.
+
+9.2.  Informative References
+
+   [IDGUIDE]  Housley, R., "Guidelines to Authors of Internet-Drafts",
+              December 2010, <https://www.ietf.org/id-info/
+              guidelines.html>.
+
+   [LINKRELATIONS]
+              IANA, "Link Relations", <https://www.iana.org/assignments/
+              link-relations/>.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process --
+              Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026,
+              October 1996, <http://www.rfc-editor.org/info/rfc2026>.
+
+   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
+              DOI 10.17487/RFC2397, August 1998,
+              <http://www.rfc-editor.org/info/rfc2397>.
+
+   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+              DOI 10.17487/RFC2629, June 1999,
+              <http://www.rfc-editor.org/info/rfc2629>.
+
+
+
+Hoffman                       Informational                    [Page 88]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
+              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
+              <http://www.rfc-editor.org/info/rfc3339>.
+
+   [RFC3470]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
+              the Use of Extensible Markup Language (XML) within IETF
+              Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470,
+              January 2003, <http://www.rfc-editor.org/info/rfc3470>.
+
+   [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
+              DOI 10.17487/RFC3667, February 2004,
+              <http://www.rfc-editor.org/info/rfc3667>.
+
+   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
+              RFC 3966, DOI 10.17487/RFC3966, December 2004,
+              <http://www.rfc-editor.org/info/rfc3966>.
+
+   [RFC3978]  Bradner, S., Ed., "IETF Rights in Contributions",
+              RFC 3978, DOI 10.17487/RFC3978, March 2005,
+              <http://www.rfc-editor.org/info/rfc3978>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5378]  Bradner, S., Ed., and J. Contreras, Ed., "Rights
+              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+              DOI 10.17487/RFC5378, November 2008,
+              <http://www.rfc-editor.org/info/rfc5378>.
+
+   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
+              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
+              <http://www.rfc-editor.org/info/rfc6068>.
+
+   [RFC6266]  Reschke, J., "Use of the Content-Disposition Header Field
+              in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
+              DOI 10.17487/RFC6266, June 2011,
+              <http://www.rfc-editor.org/info/rfc6266>.
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 89]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <http://www.rfc-editor.org/info/rfc6838>.
+
+   [RFC6949]  Flanagan, H. and N. Brownlee, "RFC Series Format
+              Requirements and Future Development", RFC 6949,
+              DOI 10.17487/RFC6949, May 2013,
+              <http://www.rfc-editor.org/info/rfc6949>.
+
+   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
+              DOI 10.17487/RFC7303, July 2014,
+              <http://www.rfc-editor.org/info/rfc7303>.
+
+   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
+              DOI 10.17487/RFC7322, September 2014,
+              <http://www.rfc-editor.org/info/rfc7322>.
+
+   [RFC7669]  Levine, J., "Assigning Digital Object Identifiers to
+              RFCs", RFC 7669, DOI 10.17487/RFC7669, October 2015,
+              <http://www.rfc-editor.org/info/rfc7669>.
+
+   [RFC7749]  Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
+              RFC 7749, DOI 10.17487/RFC7749, February 2016,
+              <http://www.rfc-editor.org/info/rfc7749>.
+
+   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
+              "RFC Streams, Headers, and Boilerplates", RFC 7841,
+              DOI 10.17487/RFC7841, May 2016,
+              <http://www.rfc-editor.org/info/rfc7841>.
+
+   [RFC7996]  Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
+              RFC 7996, DOI 10.17487/RFC7996, December 2016,
+              <http://www.rfc-editor.org/info/rfc7996>.
+
+   [RFC7997]  Flanagan, H., Ed., "The Use of Non-ASCII Characters in
+              RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
+              <http://www.rfc-editor.org/info/rfc7997>.
+
+   [RFC7998]  Hoffman, P. and J. Hildebrand, ""xml2rfc" Version 3
+              Preparation Tool Description", RFC 7998,
+              DOI 10.17487/RFC7998, December 2016,
+              <http://www.rfc-editor.org/info/rfc7998>.
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 90]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   [RNC]      Clark, J., "RELAX NG Compact Syntax", The Organization
+              for the Advancement of Structured Information
+              Standards (OASIS), November 2002,
+              <https://www.oasis-open.org/committees/
+              relax-ng/compact-20021121.html>.
+
+   [RNG]      ISO/IEC, "Information Technology - Document Schema
+              Definition Languages (DSDL) - Part 2: Regular-Grammar-
+              Based Validation - RELAX NG (Second Edition)",
+              ISO/IEC 19757-2:2008(E), December 2008.
+
+              A useful source of RNG-related information is
+              <http://relaxng.org/>.
+
+   [TLP1.0]   IETF Trust, "Legal Provisions Relating to IETF Documents",
+              November 2008,
+              <http://trustee.ietf.org/license-info/IETF-TLP-1.htm>.
+
+   [TLP2.0]   IETF Trust, "Legal Provisions Relating to IETF Documents",
+              February 2009,
+              <http://trustee.ietf.org/license-info/IETF-TLP-2.htm>.
+
+   [TLP3.0]   IETF Trust, "Legal Provisions Relating to IETF Documents",
+              September 2009,
+              <http://trustee.ietf.org/license-info/IETF-TLP-3.htm>.
+
+   [TLP4.0]   IETF Trust, "Legal Provisions Relating to IETF Documents",
+              December 2009,
+              <http://trustee.ietf.org/license-info/IETF-TLP-4.htm>.
+
+   [TLP5.0]   IETF Trust, "Legal Provisions Relating to IETF Documents",
+              March 2015,
+              <http://trustee.ietf.org/license-info/IETF-TLP-5.htm>.
+
+   [UAX24]    The Unicode Consortium, "UAX #24: Unicode Script
+              Property", <http://www.unicode.org/reports/tr24/>.
+
+   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
+              <http://www.unicode.org/versions/latest/>.
+
+   [USASCII]  American National Standards Institute, "Coded Character
+              Set -- 7-bit American Standard Code for Information
+              Interchange", ANSI X3.4, 1986.
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 91]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   [XInclude] Marsh, J., Orchard, D., and D. Veillard, "XML Inclusions
+              (XInclude) Version 1.0 (Second Edition)", W3C
+              Recommendation REC-xinclude-20061115, November 2006,
+              <https://www.w3.org/TR/2006/REC-xinclude-20061115/>.
+
+              Latest version available at
+              <http://www.w3.org/TR/xinclude/>.
+
+   [XPOINTER] Grosso, P., Maler, E., Marsh, J., and N. Walsh,
+              "XPointer Framework", W3C Recommendation
+              REC-xptr-framework-20030325, March 2003,
+              <http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.
+
+              Latest version available at
+              <http://www.w3.org/TR/xptr-framework/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 92]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+Appendix A.  Front-Page ("Boilerplate") Generation
+
+   The values listed here will be defined by the RFC Series Editor.
+   Those listed here are believed to be the current values in use.
+
+A.1.  The "ipr" Attribute
+
+   This attribute value can take a long list of values, each of which
+   describes an IPR policy for the document (Section 2.45.5).  The
+   values are not the result of a grand design, but they remain simply
+   for historic reasons.  Of these values, only a few are currently in
+   use; all others are supported by various tools for backwards
+   compatibility with old source files.
+
+      Note: Some variations of the boilerplate are selected based on the
+      document's date; therefore, it is important to specify the "year",
+      "month", and "day" attributes of the <date> element when archiving
+      the XML source of an Internet-Draft on the day of submission.
+
+   _Disclaimer: THIS ONLY PROVIDES IMPLEMENTATION INFORMATION.  IF YOU
+   NEED LEGAL ADVICE, PLEASE CONTACT A LAWYER._  For further
+   information, refer to <http://trustee.ietf.org/docs/
+   IETF-Copyright-FAQ.pdf>.
+
+   For the current "Copyright Notice" text, the submissionType attribute
+   of the <rfc> element (Section 2.45.12) determines whether a statement
+   about "Code Components" is inserted (which is the case for the value
+   "IETF", which is the default).  Other values, such as "independent",
+   suppress this part of the text.
+
+A.1.1.  Current Values: "*trust200902"
+
+   The name for these values refers to version 2.0 of the IETF Trust's
+   "Legal Provisions Relating to IETF Documents", sometimes simply
+   called the "TLP", which went into effect on February 15, 2009
+   [TLP2.0].  Updates to the document were published on September 12,
+   2009 [TLP3.0] and on December 28, 2009 [TLP4.0], modifying the
+   license for code components (see <http://trustee.ietf.org/
+   license-info/> for further information).  The actual text is located
+   in Section 6 ("Text to Be Included in IETF Documents") of these
+   documents.
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 93]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   The prep tool automatically produces the "correct" text, depending on
+   the document's date information (see above):
+
+      +----------+--------------------------------+
+      | TLP      | starting with publication date |
+      +----------+--------------------------------+
+      | [TLP3.0] | 2009-11-01                     |
+      | [TLP4.0] | 2010-04-01                     |
+      +----------+--------------------------------+
+
+      The TLP was again updated in March 2015 [TLP5.0], but the changes
+      made in that version do not affect the boilerplate text.
+
+A.1.1.1.  trust200902
+
+   This value should be used unless one of the more specific
+   "*trust200902" values is a better fit.  It produces the text in
+   Sections 6.a and 6.b of the TLP.
+
+A.1.1.2.  noModificationTrust200902
+
+   This produces the additional text from Section 6.c.i of the TLP:
+
+      This document may not be modified, and derivative works of it may
+      not be created, except to format it for publication as an RFC or
+      to translate it into languages other than English.
+
+      Note: this clause is incompatible with RFCs that are published on
+      the Standards Track.
+
+A.1.1.3.  noDerivativesTrust200902
+
+   This produces the additional text from Section 6.c.ii of the TLP:
+
+      This document may not be modified, and derivative works of it may
+      not be created, and it may not be published except as an
+      Internet-Draft.
+
+      Note: this clause is incompatible with RFCs.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 94]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+A.1.1.4.  pre5378Trust200902
+
+   This produces the additional text from Section 6.c.iii of the TLP,
+   frequently called the "pre-5378 escape clause" referring to changes
+   introduced in [RFC5378]:
+
+      This document may contain material from IETF Documents or IETF
+      Contributions published or made publicly available before November
+      10, 2008.  The person(s) controlling the copyright in some of this
+      material may not have granted the IETF Trust the right to allow
+      modifications of such material outside the IETF Standards Process.
+      Without obtaining an adequate license from the person(s)
+      controlling the copyright in such materials, this document may not
+      be modified outside the IETF Standards Process, and derivative
+      works of it may not be created outside the IETF Standards Process,
+      except to format it for publication as an RFC or to translate it
+      into languages other than English.
+
+   See Section 4 of <http://trustee.ietf.org/docs/
+   IETF-Copyright-FAQ.pdf> for further information about when to use
+   this value.
+
+      Note: this text appears under "Copyright Notice", unless the
+      document was published before November 2009, in which case it
+      appears under "Status of This Memo".
+
+A.1.2.  Historic Values
+
+A.1.2.1.  Historic Values: "*trust200811"
+
+   The attribute values "trust200811", "noModificationTrust200811", and
+   "noDerivativesTrust200811" are similar to their "trust200902"
+   counterparts, except that they use text specified in [TLP1.0].
+
+A.1.2.2.  Historic Values: "*3978"
+
+   The attribute values "full3978", "noModification3978", and
+   "noDerivatives3978" are similar to their counterparts above, except
+   that they use text specified in [RFC3978].
+
+A.1.2.3.  Historic Values: "*3667"
+
+   The attribute values "full3667", "noModification3667", and
+   "noDerivatives3667" are similar to their counterparts above, except
+   that they use text specified in [RFC3667].
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 95]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+A.1.2.4.  Historic Values: "*2026"
+
+   The attribute values "full2026" and "noDerivativeWorks2026" are
+   similar to their counterparts above, except that they use text
+   specified in Section 10 of [RFC2026].
+
+   The special value "none" was also used back then; it denied the IETF
+   any rights beyond publication as an Internet-Draft.
+
+A.2.  The "submissionType" Attribute
+
+   The RFC Editor publishes documents from different "document streams",
+   of which the "IETF stream" is the most prominent.  Other streams are
+   the "Independent Submissions stream" (used for things such as
+   discussion of Internet-related technologies that are not part of the
+   IETF agenda), the "IAB stream" (Internet Architecture Board), and the
+   "IRTF stream" (Internet Research Task Force).
+
+   The values for the attribute are "IETF" (the default value),
+   "independent", "IAB", and "IRTF".
+
+   Historically, this attribute did not affect the final appearance of
+   RFCs, except for subtle differences in copyright notices.  Nowadays
+   (as of [RFC7841]), the stream name appears in the first line of the
+   front page, and it also affects the text in the "Status of This Memo"
+   section.
+
+   For current documents, setting the "submissionType" attribute will
+   have the following effect:
+
+   o  For RFCs, the stream name appears in the upper left corner of the
+      first page (in Internet-Drafts, this is either "Network Working
+      Group" or the value of the <workgroup> element).
+
+   o  For RFCs, it affects the whole "Status of This Memo" section (see
+      Section 3.2 of [RFC7841]).
+
+   o  For all RFCs and Internet-Drafts, it determines whether the
+      "Copyright Notice" section mentions the Copyright on Code
+      Components (see Section 6 of the TLP ("Text to Be Included in IETF
+      Documents")).
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 96]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+A.3.  The "consensus" Attribute
+
+   For some of the publication streams (see Appendix A.2), the "Status
+   of This Memo" section depends on whether there was a consensus to
+   publish (again, see Section 3.4 of [RFC7841]).
+
+   The consensus attribute can be used to supply this information.  The
+   acceptable values are "true" (the default) and "false"; "yes" and
+   "no" from v2 are deprecated.
+
+   The effect of this value for the various streams is:
+
+   o  "independent": none.
+
+   o  "IAB": mention that there was an IAB consensus.
+
+   o  "IETF": mention that there was an IETF consensus.
+
+   o  "IRTF": mention that there was a research group consensus (where
+      the name of the research group is extracted from the <workgroup>
+      element).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 97]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+Appendix B.  The v3 Format and Processing Tools
+
+   This section describes topics that are specific to v3 processing
+   tools.  Note that there is some discussion of tools in the main body
+   of the document as well.  For example, some elements have
+   descriptions of how a processing tool might create output from the
+   element.
+
+   The expected design of the tools that will be used with v3 documents
+   includes:
+
+   o  A "prep tool" that takes a v3 document, makes many checks, adds
+      and changes many attribute values, and creates a file that is a
+      "prepared document".  The prepared document is a valid v3
+      document.  The prep tool is described in [RFC7998].
+
+      The prep tool is expected to have many modes:
+
+      *  RFC mode -- The mode used by the RFC Editor to process the
+         input from one of the RFC streams and to process XML produced
+         during the RFC editing process.  The restrictions on the
+         canonical XML for RFCs, as well as how the non-canonical
+         formats will look, are described at
+         <https://www.rfc-editor.org/rse/wiki/
+         doku.php?id=design:format-and-content-rfcs>.
+
+      *  Draft mode -- The mode used by the Internet-Draft submission
+         tool.  The restrictions for the XML from this mode will be
+         described later.
+
+      *  Diagnostic mode -- A mode that can be used by document authors
+         to look for errors or warnings before they submit their
+         documents for publication.
+
+      *  Consolidation mode -- Produces output where no external
+         resources are required to render the file output.  This
+         includes expanding the XInclude entities and DTD entities in
+         place, and changing all elements that have "src" attributes
+         with external links into either "data:" URI or content for the
+         element, as specified in [RFC7998].
+
+   o  Formatting tools that will create HTML, PDF, plain text, and
+      possibly other output formats.  These formatters will be created
+      by the IETF, but others can create such tools as well.  The IETF
+      tools are expected to take prepared documents as input.
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 98]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   There may also be processing tools that are meant to run on the
+   computers of authors.  These tools may be used to produce interim
+   versions of the non-canonical representations so that authors can see
+   how their XML might later be rendered, to create documents in
+   representations different than those supported by the RFC Editor, to
+   possibly create documents that are not meant to be Internet-Drafts or
+   RFCs, and to convert XML that has external information into XML that
+   has that external information included.
+
+   The prep tool is expected to have clear error reporting, giving more
+   context than just a line number.  For example, the error messages
+   should differentiate between errors in XML and those from the v3
+   format.
+
+   In v2, the grammar was specified as a DTD.  In v3, the grammar is
+   specified only as RELAX Next Generation (RNG).  This means that tools
+   need to work from the RNG, not from a DTD.  Some of the features of
+   the v3 grammar cannot be specified as a DTD.
+
+B.1.  Including External Text with XInclude
+
+   All tools for the v3 format are expected to support XInclude
+   [XInclude].  XInclude specifies a processing model and syntax for
+   general-purpose inclusion of information that is either on the
+   Internet or local to the user's computer.
+
+   In the v3 syntax, XInclude is expressed as the <xi:include> element.
+   To use this element, you need to include the "xi" namespace in the
+   <rfc> element; that is, you need to specify
+
+   xmlns:xi="http://www.w3.org/2001/XInclude"
+
+   as one of the attributes in the <rfc> element.
+
+   The most common way to use <xi:include> is to pull in references that
+   are already formed as XML.  Currently, this can be done from
+   xml2rfc.tools.ietf.org, but later this is expected to be from the RFC
+   Editor.  For example, if a document has three normative references,
+   all RFCs, the document might contain:
+
+   <references>
+       <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
+          bibxml/reference.RFC.2119.xml"/>
+       <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
+          bibxml/reference.RFC.4869.xml"/>
+       <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
+          bibxml/reference.RFC.7169.xml"/>
+   </references>
+
+
+
+Hoffman                       Informational                    [Page 99]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   <xi:include> can be used anywhere an XML element could be used (but
+   not where free text is used).  For example, if three Internet-Drafts
+   are all including a particular paragraph or section verbatim, that
+   text can be kept either in a file or somewhere on the web and can be
+   included with <xi:include>.  An example of pulling something from the
+   local disk would be:
+
+   <x:include href="file://home/chris/ietf/drafts/commontext.xml"/>
+
+   In general, XInclude should be used instead of ENTITY references and
+   XML Processing Instructions (PIs) that allow external inclusions.
+
+B.2.  Anchors and IDs
+
+   People writing and reading Internet-Drafts and RFCs often want to
+   make reference to specific locations in those documents.  In the case
+   of RFC authors, it is common to want to reference another part of
+   their document, such as "see Section 3.2 of this document."  Readers,
+   on the other hand, want to reference parts of documents that they
+   didn't write, such as "see Section 3.2 of RFC 6949."  The XML
+   vocabulary in this document attempts to support both sets of people.
+
+   Authors can leave anchors in a document that can later be used for
+   references with the "anchor" attribute.  Anchors can be included in
+   the numerous elements.  The author can then refer to that anchor in
+   the "target" attribute of the <xref> element.
+
+   Readers can refer to any element that has an "anchor" attribute by
+   that attribute.  Note, however, that most of the time, elements won't
+   have anchors.  In the common case, the reader wants to refer to an
+   element that does not have an "anchor" attribute, but that element
+   has a "pn" attribute.
+
+   Processing tools add the "pn" attribute to many elements during
+   processing.  This attribute and its value are automatically generated
+   by the tool if the attribute is not there; if the attribute is
+   already there, the tool may replace the value.
+
+B.2.1.  Overlapping Values
+
+   In the HTML representation of this XML vocabulary, both anchors and
+   "pn" attributes will be used in the "id" attributes of elements.
+   Thus, there can be no overlap between the names entered in "anchor"
+   attributes, in "slugifiedName" attributes, and those that are
+   generated for the "pn" attributes.  Also, there are some values for
+   the "anchor" values that are reserved for sections, and those
+   sections can only have those anchor values.
+
+
+
+
+Hoffman                       Informational                   [Page 100]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   The following rules prevent this overlap:
+
+   o  "pn" for regular sections always has the format "s-nnn", where
+      "nnn" is the section number, or the appendix identifier (which
+      starts with a letter).  For example, this would be "s-2.1.3" for
+      Section 2.1.3 and "s-a" for Appendix A.  For the <abstract>
+      element, it is always "s-abstract".  For the <note> element, it is
+      always "s-note-nnn", where "nnn" is a sequential value.  For
+      sections in the <boilerplate> element, it is always
+      "s-boilerplate-nnn", where "nnn" is a sequential value.
+
+   o  "pn" for <references> elements has the format "s-nnn".  It is
+      important to note that "nnn" is a number, not letters, even though
+      the <references> appear in the back.  It is the number that is one
+      higher than the highest top-level section number in <middle>.  If
+      there are two or more <references>, "nnn" will include a dot as if
+      the <references> are a subsection of a section that is numbered
+      one higher than the highest top-level section number in <middle>.
+
+   o  "pn" for <figure> elements always has the format "f-nnn", where
+      "nnn" is the figure number.  For example, this would be "f-5" for
+      Figure 5.
+
+   o  "pn" for <iref> elements always has the format "i-ttt-nnn", where
+      "ttt" is the slugified item (plus a hyphen and the slugified
+      subitem if there is a subitem), and "nnn" is the instance of that
+      item/subitem pair.  For example, this would be "i-foo-1" for
+      "<iref item='foo'>" and "i-foo-bar-1" for "<iref item='foo'
+      subitem='bar'>".
+
+   o  "pn" for <table> elements always has the format "t-nnn", where
+      "nnn" is the table number.  For example, this would be "t-5" for
+      Table 5.
+
+   o  "pn" for all elements not listed above always has the format
+      "p-nnn-mmm", where "nnn" is the section number and "mmm" is the
+      relative position in the section.  For example, this would be
+      "p-2.1.3-7" for the seventh part number in Section 2.1.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 101]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  "slugifiedName" always has the format "n-ttt", where "ttt" is the
+      text of the name after slugification.  For example, this would be
+      "n-protocol-overview" for the name "Protocol Overview".  The
+      actual conversions done in slugification will be specified at a
+      later time.
+
+   o  Anchors must never overlap with any of the above.  The easiest way
+      to assure that is to not pick an anchor name that starts with a
+      single letter followed by a hyphen.  If an anchor does overlap
+      with one of the types of names above, the processing tool will
+      reject the document.
+
+B.3.  Attributes Controlled by the Prep Tool
+
+   Many elements in the v3 vocabulary have new attributes whose role is
+   to hold values generated by the prep tool.  These attributes can
+   exist in documents that are input to the prep tool; however, any of
+   these attributes might be added, removed, or changed by the prep
+   tool.  Thus, it is explicitly unsafe for a document author to include
+   these attributes and expect that their values will survive processing
+   by the prep tool.
+
+   The attributes that are controlled by the prep tool are:
+
+   o  The "pn" attribute in any element -- The number for this item
+      within the section.  The numbering is shared with other elements
+      of a section.  The "pn" attribute is added to many block-level
+      elements inside sections.
+
+   o  <artwork> originalSrc -- This attribute is filled with the
+      original value of the "src" attribute if that attribute is removed
+      by the prep tool.
+
+   o  <figure> originalSrc -- This attribute is filled with the original
+      value of the "src" attribute if that attribute is removed by the
+      prep tool.
+
+   o  <name> "slugifiedName" attribute -- This attribute is filled with
+      a "slugified" version of the text in the element.  This attribute
+      can be used in the output formats for elements that have both
+      names and numbers.
+
+   o  <relref> "derivedLink" attribute -- This attribute is filled with
+      the link that is derived from combining the URI from the reference
+      and the relative part that is either a copy of the "relative"
+      attribute or a section number derived from the "section"
+      attribute.
+
+
+
+
+Hoffman                       Informational                   [Page 102]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   o  <rfc> "expiresDate" attribute -- This attribute is filled with the
+      date that an Internet-Draft expires.  The date is in the format
+      yyyy-mm-dd.
+
+   o  <rfc> "mode" attribute -- This attribute is filled with a string
+      that indicates what mode the prep tool was in when it processed
+      the XML, such as whether it was processing a file to become an
+      Internet-Draft or an RFC.
+
+   o  <rfc> "scripts" attribute -- This attribute is filled with a list
+      of scripts needed to render this document.  The list is comma-
+      separated, with no spaces allowed.  The order is unimportant.  The
+      names come from [UAX24].  For example, if the document has Chinese
+      characters in it, the value might be "Common,Latin,Han".
+
+   o  <sourcecode> "originalSrc" attribute -- This attribute is filled
+      with the original value of the "src" attribute if that attribute
+      is removed by the prep tool.
+
+   o  <xref> "derivedContent" attribute -- This attribute is filled in
+      if there is no content in the <xref> element.  The value for this
+      attribute is based on the value in the "displayFormat" attribute.
+      Examples of how this value is filled can be found in
+      Section 2.66.1.
+
+   In addition, note that the contents of the <boilerplate> element are
+   controlled by the prep tool.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 103]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+Appendix C.  RELAX NG Schema
+
+   The following is the RELAX NG schema for the v3 format.
+
+   namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
+
+   # xml2rfc Version 3 grammar
+
+   rfc =
+     element rfc {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute number { text }?,
+       [ a:defaultValue = "" ] attribute obsoletes { text }?,
+       [ a:defaultValue = "" ] attribute updates { text }?,
+       attribute category { text }?,
+       attribute mode { text }?,
+       [ a:defaultValue = "false" ]
+       attribute consensus { "no" | "yes" | "false" | "true" }?,
+       attribute seriesNo { text }?,
+       attribute ipr { text }?,
+       attribute iprExtract { xsd:IDREF }?,
+       [ a:defaultValue = "IETF" ]
+       attribute submissionType {
+         "IETF" | "IAB" | "IRTF" | "independent"
+       }?,
+       attribute docName { text }?,
+       [ a:defaultValue = "false" ]
+       attribute sortRefs { "true" | "false" }?,
+       [ a:defaultValue = "true" ]
+       attribute symRefs { "true" | "false" }?,
+       [ a:defaultValue = "true" ]
+       attribute tocInclude { "true" | "false" }?,
+       [ a:defaultValue = "3" ] attribute tocDepth { text }?,
+       attribute prepTime { text }?,
+       [ a:defaultValue = "true" ]
+       attribute indexInclude { "true" | "false" }?,
+       attribute version { text }?,
+       [ a:defaultValue = "Common,Latin" ] attribute scripts { text }?,
+       attribute expiresDate { text }?,
+       link*,
+       front,
+       middle,
+       back?
+     }
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 104]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   link =
+     element link {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute href { text },
+       attribute rel { text }?
+     }
+
+   front =
+     element front {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       title,
+       seriesInfo*,
+       author+,
+       date?,
+       area*,
+       workgroup*,
+       keyword*,
+       abstract?,
+       note*,
+       boilerplate?
+     }
+
+   title =
+     element title {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute abbrev { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   author =
+     element author {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute initials { text }?,
+       attribute asciiInitials { text }?,
+       attribute surname { text }?,
+       attribute asciiSurname { text }?,
+       attribute fullname { text }?,
+       attribute role { "editor" }?,
+       attribute asciiFullname { text }?,
+       organization?,
+       address?
+     }
+
+
+
+
+Hoffman                       Informational                   [Page 105]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   organization =
+     element organization {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute abbrev { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   address =
+     element address {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       postal?,
+       phone?,
+       facsimile?,
+       email?,
+       uri?
+     }
+
+   postal =
+     element postal {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       ((city | code | country | region | street)* | postalLine+)
+     }
+
+   street =
+     element street {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   city =
+     element city {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 106]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   region =
+     element region {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   code =
+     element code {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   country =
+     element country {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   postalLine =
+     element postalLine {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   phone =
+     element phone {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+   facsimile =
+     element facsimile {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 107]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   email =
+     element email {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute ascii { text }?,
+       text
+     }
+
+   uri =
+     element uri {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+   date =
+     element date {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute day { text }?,
+       attribute month { text }?,
+       attribute year { text }?,
+       empty
+     }
+
+   area =
+     element area {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+   workgroup =
+     element workgroup {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+   keyword =
+     element keyword {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 108]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   abstract =
+     element abstract {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       (dl | ol | t | ul)+
+     }
+
+   note =
+     element note {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute title { text }?,
+       attribute pn { text }?,
+       [ a:defaultValue = "false" ]
+       attribute removeInRFC { "true" | "false" }?,
+       name?,
+       (dl | ol | t | ul)+
+     }
+
+   boilerplate =
+     element boilerplate {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       section+
+     }
+
+   middle =
+     element middle {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       section+
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 109]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   section =
+     element section {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       attribute title { text }?,
+       [ a:defaultValue = "true" ]
+       attribute numbered { "true" | "false" }?,
+       [ a:defaultValue = "default" ]
+       attribute toc { "include" | "exclude" | "default" }?,
+       [ a:defaultValue = "false" ]
+       attribute removeInRFC { "true" | "false" }?,
+       name?,
+       (artwork
+        | aside
+        | blockquote
+        | dl
+        | figure
+        | iref
+        | ol
+        | sourcecode
+        | t
+        | table
+        | texttable
+        | ul)*,
+       section*
+     }
+
+   name =
+     element name {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute slugifiedName { text }?,
+       (text | cref | eref | relref | tt | xref)*
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 110]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   t =
+     element t {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       attribute hangText { text }?,
+       [ a:defaultValue = "false" ]
+       attribute keepWithNext { "false" | "true" }?,
+       [ a:defaultValue = "false" ]
+       attribute keepWithPrevious { "false" | "true" }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | \list
+        | relref
+        | spanx
+        | strong
+        | sub
+        | sup
+        | tt
+        | vspace
+        | xref)*
+     }
+
+   aside =
+     element aside {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       (artwork | dl | figure | iref | \list | ol | t | table | ul)*
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 111]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   blockquote =
+     element blockquote {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       attribute cite { text }?,
+       attribute quotedFrom { text }?,
+       ((artwork | dl | figure | ol | sourcecode | t | ul)+
+        | (text
+           | bcp14
+           | cref
+           | em
+           | eref
+           | iref
+           | relref
+           | strong
+           | sub
+           | sup
+           | tt
+           | xref)+)
+     }
+
+   \list =
+     element list {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       [ a:defaultValue = "empty" ] attribute style { text }?,
+       attribute hangIndent { text }?,
+       attribute counter { text }?,
+       attribute pn { text }?,
+       t+
+     }
+
+   ol =
+     element ol {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       [ a:defaultValue = "1" ] attribute type { text }?,
+       [ a:defaultValue = "1" ] attribute start { text }?,
+       attribute group { text }?,
+       [ a:defaultValue = "normal" ]
+       attribute spacing { "normal" | "compact" }?,
+       attribute pn { text }?,
+       li+
+     }
+
+
+
+
+Hoffman                       Informational                   [Page 112]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   ul =
+     element ul {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       [ a:defaultValue = "normal" ]
+       attribute spacing { "normal" | "compact" }?,
+       ([ a:defaultValue = "false" ]
+        attribute empty { "false" | "true" },
+        attribute pn { text }?)?,
+       li+
+     }
+
+   li =
+     element li {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       ((artwork | dl | figure | ol | sourcecode | t | ul)+
+        | (text
+           | bcp14
+           | cref
+           | em
+           | eref
+           | iref
+           | relref
+           | strong
+           | sub
+           | sup
+           | tt
+           | xref)+)
+     }
+
+   dl =
+     element dl {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       [ a:defaultValue = "normal" ]
+       attribute spacing { "normal" | "compact" }?,
+       [ a:defaultValue = "true" ]
+       attribute hanging { "false" | "true" }?,
+       attribute pn { text }?,
+       (dt, dd)+
+     }
+
+
+
+
+
+Hoffman                       Informational                   [Page 113]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   dt =
+     element dt {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | strong
+        | sub
+        | sup
+        | tt
+        | xref)*
+     }
+
+   dd =
+     element dd {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       ((artwork | dl | figure | ol | sourcecode | t | ul)+
+        | (text
+           | bcp14
+           | cref
+           | em
+           | eref
+           | iref
+           | relref
+           | strong
+           | sub
+           | sup
+           | tt
+           | xref)+)
+     }
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 114]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   xref =
+     element xref {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute target { xsd:IDREF },
+       [ a:defaultValue = "false" ]
+       attribute pageno { "true" | "false" }?,
+       [ a:defaultValue = "default" ]
+       attribute format { "default" | "title" | "counter" | "none" }?,
+       attribute derivedContent { text }?,
+       text
+     }
+
+   relref =
+     element relref {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute target { xsd:IDREF },
+       [ a:defaultValue = "of" ]
+       attribute displayFormat { "of" | "comma" | "parens" | "bare" }?,
+       attribute section { text },
+       attribute relative { text }?,
+       attribute derivedLink { text }?,
+       text
+     }
+
+   eref =
+     element eref {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute target { text },
+       text
+     }
+
+   iref =
+     element iref {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute item { text },
+       [ a:defaultValue = "" ] attribute subitem { text }?,
+       [ a:defaultValue = "false" ]
+       attribute primary { "true" | "false" }?,
+       attribute pn { text }?,
+       empty
+     }
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 115]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   cref =
+     element cref {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute source { text }?,
+       [ a:defaultValue = "true" ]
+       attribute display { "true" | "false" }?,
+       (text | em | eref | relref | strong | sub | sup | tt | xref)*
+     }
+
+   tt =
+     element tt {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | strong
+        | sub
+        | sup
+        | xref)*
+     }
+
+   strong =
+     element strong {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | sub
+        | sup
+        | tt
+        | xref)*
+     }
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 116]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   em =
+     element em {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | eref
+        | iref
+        | relref
+        | strong
+        | sub
+        | sup
+        | tt
+        | xref)*
+     }
+
+   sub =
+     element sub {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | strong
+        | tt
+        | xref)*
+     }
+
+   sup =
+     element sup {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | strong
+        | tt
+        | xref)*
+     }
+
+
+
+Hoffman                       Informational                   [Page 117]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   spanx =
+     element spanx {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       [ a:defaultValue = "preserve" ]
+       attribute xml:space { "default" | "preserve" }?,
+       [ a:defaultValue = "emph" ] attribute style { text }?,
+       text
+     }
+
+   vspace =
+     element vspace {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       [ a:defaultValue = "0" ] attribute blankLines { text }?,
+       empty
+     }
+
+   figure =
+     element figure {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       [ a:defaultValue = "" ] attribute title { text }?,
+       [ a:defaultValue = "false" ]
+       attribute suppress-title { "true" | "false" }?,
+       attribute src { text }?,
+       attribute originalSrc { text }?,
+       [ a:defaultValue = "left" ]
+       attribute align { "left" | "center" | "right" }?,
+       [ a:defaultValue = "" ] attribute alt { text }?,
+       [ a:defaultValue = "" ] attribute width { text }?,
+       [ a:defaultValue = "" ] attribute height { text }?,
+       name?,
+       iref*,
+       preamble?,
+       (artwork | sourcecode)+,
+       postamble?
+     }
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 118]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   table =
+     element table {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       name?,
+       iref*,
+       thead?,
+       tbody+,
+       tfoot?
+     }
+
+   preamble =
+     element preamble {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | spanx
+        | strong
+        | sub
+        | sup
+        | tt
+        | xref)*
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 119]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   artwork =
+     element artwork {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       attribute xml:space { text }?,
+       [ a:defaultValue = "" ] attribute name { text }?,
+       [ a:defaultValue = "" ] attribute type { text }?,
+       attribute src { text }?,
+       [ a:defaultValue = "left" ]
+       attribute align { "left" | "center" | "right" }?,
+       [ a:defaultValue = "" ] attribute alt { text }?,
+       [ a:defaultValue = "" ] attribute width { text }?,
+       [ a:defaultValue = "" ] attribute height { text }?,
+       attribute originalSrc { text }?,
+       (text* | svg)
+     }
+   # https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc
+
+   sourcecode =
+     element sourcecode {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute pn { text }?,
+       [ a:defaultValue = "" ] attribute name { text }?,
+       [ a:defaultValue = "" ] attribute type { text }?,
+       attribute src { text }?,
+       attribute originalSrc { text }?,
+       text
+     }
+
+   thead =
+     element thead {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       tr+
+     }
+
+   tbody =
+     element tbody {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       tr+
+     }
+
+
+
+Hoffman                       Informational                   [Page 120]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   tfoot =
+     element tfoot {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       tr+
+     }
+
+   tr =
+     element tr {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       (td | th)+
+     }
+
+   td =
+     element td {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       [ a:defaultValue = "0" ] attribute colspan { text }?,
+       [ a:defaultValue = "0" ] attribute rowspan { text }?,
+       [ a:defaultValue = "left" ]
+       attribute align { "left" | "center" | "right" }?,
+       ((artwork | dl | figure | ol | sourcecode | t | ul)+
+        | (text
+           | bcp14
+           | br
+           | cref
+           | em
+           | eref
+           | iref
+           | relref
+           | strong
+           | sub
+           | sup
+           | tt
+           | xref)*)
+     }
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 121]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   th =
+     element th {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       [ a:defaultValue = "0" ] attribute colspan { text }?,
+       [ a:defaultValue = "0" ] attribute rowspan { text }?,
+       [ a:defaultValue = "left" ]
+       attribute align { "left" | "center" | "right" }?,
+       ((artwork | dl | figure | ol | sourcecode | t | ul)+
+        | (text
+           | bcp14
+           | br
+           | cref
+           | em
+           | eref
+           | iref
+           | relref
+           | strong
+           | sub
+           | sup
+           | tt
+           | xref)*)
+     }
+
+   postamble =
+     element postamble {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text | cref | eref | iref | spanx | xref)*
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 122]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   texttable =
+     element texttable {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID }?,
+       [ a:defaultValue = "" ] attribute title { text }?,
+       [ a:defaultValue = "false" ]
+       attribute suppress-title { "true" | "false" }?,
+       [ a:defaultValue = "center" ]
+       attribute align { "left" | "center" | "right" }?,
+       [ a:defaultValue = "full" ]
+       attribute style { "all" | "none" | "headers" | "full" }?,
+       name?,
+       preamble?,
+       ttcol+,
+       c*,
+       postamble?
+     }
+
+   ttcol =
+     element ttcol {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute width { text }?,
+       [ a:defaultValue = "left" ]
+       attribute align { "left" | "center" | "right" }?,
+       (cref | eref | iref | xref | text)*
+     }
+
+   c =
+     element c {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text | cref | eref | iref | spanx | xref)*
+     }
+
+   bcp14 =
+     element bcp14 {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       text
+     }
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 123]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   br =
+     element br {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       empty
+     }
+
+   back =
+     element back {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       displayreference*,
+       references*,
+       section*
+     }
+
+   displayreference =
+     element displayreference {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute target { xsd:IDREF },
+       attribute to { text }
+     }
+
+   references =
+     element references {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute pn { text }?,
+       attribute anchor { xsd:ID }?,
+       attribute title { text }?,
+       name?,
+       (reference | referencegroup)*
+     }
+
+   reference =
+     element reference {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID },
+       attribute target { text }?,
+       [ a:defaultValue = "true" ]
+       attribute quoteTitle { "true" | "false" }?,
+       front,
+       (annotation | format | refcontent | seriesInfo)*
+     }
+
+
+
+
+
+Hoffman                       Informational                   [Page 124]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   referencegroup =
+     element referencegroup {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute anchor { xsd:ID },
+       reference+
+     }
+
+   seriesInfo =
+     element seriesInfo {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute name { text },
+       attribute value { text },
+       attribute asciiName { text }?,
+       attribute asciiValue { text }?,
+       attribute status { text }?,
+       [ a:defaultValue = "IETF" ]
+       attribute stream { "IETF" | "IAB" | "IRTF" | "independent" }?,
+       empty
+     }
+
+   format =
+     element format {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       attribute target { text }?,
+       attribute type { text },
+       attribute octets { text }?,
+       empty
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 125]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   annotation =
+     element annotation {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text
+        | bcp14
+        | cref
+        | em
+        | eref
+        | iref
+        | relref
+        | spanx
+        | strong
+        | sub
+        | sup
+        | tt
+        | xref)*
+     }
+
+   refcontent =
+     element refcontent {
+       attribute xml:base { text }?,
+       attribute xml:lang { text }?,
+       (text | bcp14 | em | strong | sub | sup | tt)*
+     }
+   start |= rfc
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 126]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+Appendix D.  Schema Differences from v2
+
+   The following is a non-normative comparison of the v3 format to the
+   v2 format.  A "-" indicates lines removed from the v2 schema, and a
+   "+" indicates lines added to the v3 schema.
+
+     namespace a =
+     "http://relaxng.org/ns/compatibility/annotations/1.0"
+
+   + # xml2rfc Version 3 grammar
+     rfc =
+       element rfc {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute number { text }?,
+         [ a:defaultValue = "" ] attribute obsoletes { text }?,
+         [ a:defaultValue = "" ] attribute updates { text }?,
+   -     attribute category { "std" | "bcp" | "info" | "exp" |
+   - "historic" }?,
+   -     attribute consensus { "no" | "yes" }?,
+   +     attribute category { text }?,
+   +     attribute mode { text }?,
+   +     [ a:defaultValue = "false" ]
+   +     attribute consensus { "no" | "yes" | "false" | "true" }?,
+         attribute seriesNo { text }?,
+   -     attribute ipr {
+   -       "full2026"
+   -       | "noDerivativeWorks2026"
+   -       | "none"
+   -       | "full3667"
+   -       | "noModification3667"
+   -       | "noDerivatives3667"
+   -       | "full3978"
+   -       | "noModification3978"
+   -       | "noDerivatives3978"
+   -       | "trust200811"
+   -       | "noModificationTrust200811"
+   -       | "noDerivativesTrust200811"
+   -       | "trust200902"
+   -       | "noModificationTrust200902"
+   -       | "noDerivativesTrust200902"
+   -       | "pre5378Trust200902"
+   -     }?,
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 127]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   +     attribute ipr { text }?,
+         attribute iprExtract { xsd:IDREF }?,
+         [ a:defaultValue = "IETF" ]
+         attribute submissionType {
+           "IETF" | "IAB" | "IRTF" | "independent"
+         }?,
+         attribute docName { text }?,
+   -     [ a:defaultValue = "en" ] attribute xml:lang { text }?,
+   +     [ a:defaultValue = "false" ]
+   +     attribute sortRefs { "true" | "false" }?,
+   +     [ a:defaultValue = "true" ]
+   +     attribute symRefs { "true" | "false" }?,
+   +     [ a:defaultValue = "true" ]
+   +     attribute tocInclude { "true" | "false" }?,
+   +     [ a:defaultValue = "3" ] attribute tocDepth { text }?,
+   +     attribute prepTime { text }?,
+   +     [ a:defaultValue = "true" ]
+   +     attribute indexInclude { "true" | "false" }?,
+   +     attribute version { text }?,
+   +     [ a:defaultValue = "Common,Latin" ] attribute scripts { text
+   + }?,
+   +     attribute expiresDate { text }?,
+   +     link*,
+         front,
+         middle,
+         back?
+       }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 128]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + link =
+   +   element link {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute href { text },
+   +     attribute rel { text }?
+   +   }
+     front =
+       element front {
+   -     title, author+, date, area*, workgroup*, keyword*, abstract?,
+   - note*
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     title,
+   +     seriesInfo*,
+   +     author+,
+   +     date?,
+   +     area*,
+   +     workgroup*,
+   +     keyword*,
+   +     abstract?,
+   +     note*,
+   +     boilerplate?
+       }
+     title =
+       element title {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute abbrev { text }?,
+   +     attribute ascii { text }?,
+         text
+       }
+     author =
+       element author {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute initials { text }?,
+   +     attribute asciiInitials { text }?,
+         attribute surname { text }?,
+   +     attribute asciiSurname { text }?,
+         attribute fullname { text }?,
+         attribute role { "editor" }?,
+   +     attribute asciiFullname { text }?,
+         organization?,
+         address?
+       }
+
+
+
+
+
+Hoffman                       Informational                   [Page 129]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     organization =
+       element organization {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute abbrev { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+   + address =
+   +   element address {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     postal?,
+   +     phone?,
+   +     facsimile?,
+   +     email?,
+   +     uri?
+   +   }
+   + postal =
+   +   element postal {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     ((city | code | country | region | street)* | postalLine+)
+   +   }
+   + street =
+   +   element street {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+   + city =
+   +   element city {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+   + region =
+   +   element region {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 130]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + code =
+   +   element code {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+   + country =
+   +   element country {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+   + postalLine =
+   +   element postalLine {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+   + phone =
+   +   element phone {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     text
+   +   }
+   + facsimile =
+   +   element facsimile {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     text
+   +   }
+   + email =
+   +   element email {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute ascii { text }?,
+   +     text
+   +   }
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 131]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + uri =
+   +   element uri {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         text
+       }
+   - address = element address { postal?, phone?, facsimile?, email?,
+   - uri? }
+   - postal = element postal { street+, (city | region | code |
+   - country)* }
+   - street = element street { text }
+   - city = element city { text }
+   - region = element region { text }
+   - code = element code { text }
+   - country = element country { text }
+   - phone = element phone { text }
+   - facsimile = element facsimile { text }
+   - email = element email { text }
+   - uri = element uri { text }
+     date =
+       element date {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute day { text }?,
+         attribute month { text }?,
+         attribute year { text }?,
+         empty
+       }
+   - area = element area { text }
+   - workgroup = element workgroup { text }
+   - keyword = element keyword { text }
+   - abstract = element abstract { t+ }
+   + area =
+   +   element area {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     text
+   +   }
+   + workgroup =
+   +   element workgroup {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     text
+   +   }
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 132]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + keyword =
+   +   element keyword {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     text
+   +   }
+   + abstract =
+   +   element abstract {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     (dl | ol | t | ul)+
+   +   }
+     note =
+       element note {
+   -     attribute title { text },
+   -     t+
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute title { text }?,
+   +     attribute pn { text }?,
+   +     [ a:defaultValue = "false" ]
+   +     attribute removeInRFC { "true" | "false" }?,
+   +     name?,
+   +     (dl | ol | t | ul)+
+   +   }
+   + boilerplate =
+   +   element boilerplate {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     section+
+   +   }
+   + middle =
+   +   element middle {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     section+
+       }
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 133]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   - middle = element middle { section+ }
+     section =
+       element section {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute anchor { xsd:ID }?,
+   -     attribute title { text },
+   +     attribute pn { text }?,
+   +     attribute title { text }?,
+   +     [ a:defaultValue = "true" ]
+   +     attribute numbered { "true" | "false" }?,
+         [ a:defaultValue = "default" ]
+         attribute toc { "include" | "exclude" | "default" }?,
+   -     (t | figure | texttable | iref)*,
+   +     [ a:defaultValue = "false" ]
+   +     attribute removeInRFC { "true" | "false" }?,
+   +     name?,
+   +     (artwork
+   +      | aside
+   +      | blockquote
+   +      | dl
+   +      | figure
+   +      | iref
+   +      | ol
+   +      | sourcecode
+   +      | t
+   +      | table
+   +      | texttable
+   +      | ul)*,
+         section*
+       }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 134]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + name =
+   +   element name {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute slugifiedName { text }?,
+   +     (text | cref | eref | relref | tt | xref)*
+   +   }
+     t =
+       element t {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+         attribute hangText { text }?,
+   +     [ a:defaultValue = "false" ]
+   +     attribute keepWithNext { "false" | "true" }?,
+   +     [ a:defaultValue = "false" ]
+   +     attribute keepWithPrevious { "false" | "true" }?,
+         (text
+   -      | \list
+   -      | figure
+   -      | xref
+   +      | bcp14
+   +      | cref
+   +      | em
+          | eref
+          | iref
+   -      | cref
+   +      | \list
+   +      | relref
+          | spanx
+   -      | vspace)*
+   +      | strong
+   +      | sub
+   +      | sup
+   +      | tt
+   +      | vspace
+   +      | xref)*
+   +   }
+   + aside =
+   +   element aside {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     (artwork | dl | figure | iref | \list | ol | t | table | ul)*
+   +   }
+
+
+
+
+Hoffman                       Informational                   [Page 135]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + blockquote =
+   +   element blockquote {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     attribute cite { text }?,
+   +     attribute quotedFrom { text }?,
+   +     ((artwork | dl | figure | ol | sourcecode | t | ul)+
+   +      | (text
+   +         | bcp14
+   +         | cref
+   +         | em
+   +         | eref
+   +         | iref
+   +         | relref
+   +         | strong
+   +         | sub
+   +         | sup
+   +         | tt
+   +         | xref)+)
+       }
+     \list =
+       element list {
+   -     attribute style { text }?,
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     [ a:defaultValue = "empty" ] attribute style { text }?,
+         attribute hangIndent { text }?,
+         attribute counter { text }?,
+   +     attribute pn { text }?,
+         t+
+       }
+   + ol =
+   +   element ol {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     [ a:defaultValue = "1" ] attribute type { text }?,
+   +     [ a:defaultValue = "1" ] attribute start { text }?,
+   +     attribute group { text }?,
+   +     [ a:defaultValue = "normal" ]
+   +     attribute spacing { "normal" | "compact" }?,
+   +     attribute pn { text }?,
+   +     li+
+   +   }
+
+
+
+
+
+Hoffman                       Informational                   [Page 136]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + ul =
+   +   element ul {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     [ a:defaultValue = "normal" ]
+   +     attribute spacing { "normal" | "compact" }?,
+   +     ([ a:defaultValue = "false" ]
+   +      attribute empty { "false" | "true" },
+   +      attribute pn { text }?)?,
+   +     li+
+   +   }
+   + li =
+   +   element li {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     ((artwork | dl | figure | ol | sourcecode | t | ul)+
+   +      | (text
+   +         | bcp14
+   +         | cref
+   +         | em
+   +         | eref
+   +         | iref
+   +         | relref
+   +         | strong
+   +         | sub
+   +         | sup
+   +         | tt
+   +         | xref)+)
+   +   }
+   + dl =
+   +   element dl {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     [ a:defaultValue = "normal" ]
+   +     attribute spacing { "normal" | "compact" }?,
+   +     [ a:defaultValue = "true" ]
+   +     attribute hanging { "false" | "true" }?,
+   +     attribute pn { text }?,
+   +     (dt, dd)+
+   +   }
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 137]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + dt =
+   +   element dt {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | strong
+   +      | sub
+   +      | sup
+   +      | tt
+   +      | xref)*
+   +   }
+   + dd =
+   +   element dd {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     ((artwork | dl | figure | ol | sourcecode | t | ul)+
+   +      | (text
+   +         | bcp14
+   +         | cref
+   +         | em
+   +         | eref
+   +         | iref
+   +         | relref
+   +         | strong
+   +         | sub
+   +         | sup
+   +         | tt
+   +         | xref)+)
+   +   }
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 138]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     xref =
+       element xref {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute target { xsd:IDREF },
+   -     [ a:defaultValue = "false" ] attribute pageno { "true" |
+   - "false" }?,
+   +     [ a:defaultValue = "false" ]
+   +     attribute pageno { "true" | "false" }?,
+         [ a:defaultValue = "default" ]
+   -     attribute format { "counter" | "title" | "none" | "default"
+   +     attribute format { "default" | "title" | "counter" | "none"
+   + }?,
+   +     attribute derivedContent { text }?,
+   +     text
+   +   }
+   + relref =
+   +   element relref {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute target { xsd:IDREF },
+   +     [ a:defaultValue = "of" ]
+   +     attribute displayFormat { "of" | "comma" | "parens" | "bare"
+     }?,
+   +     attribute section { text },
+   +     attribute relative { text }?,
+   +     attribute derivedLink { text }?,
+         text
+       }
+     eref =
+       element eref {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute target { text },
+         text
+       }
+     iref =
+       element iref {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute item { text },
+         [ a:defaultValue = "" ] attribute subitem { text }?,
+         [ a:defaultValue = "false" ]
+         attribute primary { "true" | "false" }?,
+   +     attribute pn { text }?,
+         empty
+       }
+
+
+
+
+Hoffman                       Informational                   [Page 139]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     cref =
+       element cref {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute anchor { xsd:ID }?,
+         attribute source { text }?,
+   -     text
+   +     [ a:defaultValue = "true" ]
+   +     attribute display { "true" | "false" }?,
+   +     (text | em | eref | relref | strong | sub | sup | tt | xref)*
+   +   }
+   + tt =
+   +   element tt {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | strong
+   +      | sub
+   +      | sup
+   +      | xref)*
+   +   }
+   + strong =
+   +   element strong {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | sub
+   +      | sup
+   +      | tt
+   +      | xref)*
+   +   }
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 140]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + em =
+   +   element em {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | strong
+   +      | sub
+   +      | sup
+   +      | tt
+   +      | xref)*
+   +   }
+   + sub =
+   +   element sub {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | strong
+   +      | tt
+   +      | xref)*
+   +   }
+   + sup =
+   +   element sup {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | strong
+   +      | tt
+   +      | xref)*
+       }
+
+
+
+
+
+Hoffman                       Informational                   [Page 141]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     spanx =
+       element spanx {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         [ a:defaultValue = "preserve" ]
+         attribute xml:space { "default" | "preserve" }?,
+         [ a:defaultValue = "emph" ] attribute style { text }?,
+         text
+       }
+     vspace =
+       element vspace {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         [ a:defaultValue = "0" ] attribute blankLines { text }?,
+         empty
+       }
+     figure =
+       element figure {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+         [ a:defaultValue = "" ] attribute title { text }?,
+         [ a:defaultValue = "false" ]
+         attribute suppress-title { "true" | "false" }?,
+         attribute src { text }?,
+   +     attribute originalSrc { text }?,
+         [ a:defaultValue = "left" ]
+         attribute align { "left" | "center" | "right" }?,
+         [ a:defaultValue = "" ] attribute alt { text }?,
+         [ a:defaultValue = "" ] attribute width { text }?,
+         [ a:defaultValue = "" ] attribute height { text }?,
+   +     name?,
+         iref*,
+         preamble?,
+   -     artwork,
+   +     (artwork | sourcecode)+,
+         postamble?
+       }
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 142]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + table =
+   +   element table {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     name?,
+   +     iref*,
+   +     thead?,
+   +     tbody+,
+   +     tfoot?
+   +   }
+     preamble =
+   -   element preamble { (text | xref | eref | iref | cref | spanx)* }
+   +   element preamble {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | spanx
+   +      | strong
+   +      | sub
+   +      | sup
+   +      | tt
+   +      | xref)*
+   +   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 143]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     artwork =
+       element artwork {
+   -     [ a:defaultValue = "preserve" ]
+   -     attribute xml:space { "default" | "preserve" }?,
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     attribute xml:space { text }?,
+         [ a:defaultValue = "" ] attribute name { text }?,
+         [ a:defaultValue = "" ] attribute type { text }?,
+         attribute src { text }?,
+         [ a:defaultValue = "left" ]
+         attribute align { "left" | "center" | "right" }?,
+         [ a:defaultValue = "" ] attribute alt { text }?,
+         [ a:defaultValue = "" ] attribute width { text }?,
+         [ a:defaultValue = "" ] attribute height { text }?,
+   -     text*
+   +     attribute originalSrc { text }?,
+   +     (text* | svg)
+   +   }
+   + # https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc
+   + sourcecode =
+   +   element sourcecode {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute pn { text }?,
+   +     [ a:defaultValue = "" ] attribute name { text }?,
+   +     [ a:defaultValue = "" ] attribute type { text }?,
+   +     attribute src { text }?,
+   +     attribute originalSrc { text }?,
+   +     text
+   +   }
+   + thead =
+   +   element thead {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     tr+
+   +   }
+   + tbody =
+   +   element tbody {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     tr+
+   +   }
+
+
+
+Hoffman                       Informational                   [Page 144]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + tfoot =
+   +   element tfoot {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     tr+
+   +   }
+   + tr =
+   +   element tr {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     (td | th)+
+   +   }
+   + td =
+   +   element td {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     [ a:defaultValue = "0" ] attribute colspan { text }?,
+   +     [ a:defaultValue = "0" ] attribute rowspan { text }?,
+   +     [ a:defaultValue = "left" ]
+   +     attribute align { "left" | "center" | "right" }?,
+   +     ((artwork | dl | figure | ol | sourcecode | t | ul)+
+   +      | (text
+   +         | bcp14
+   +         | br
+   +         | cref
+   +         | em
+   +         | eref
+   +         | iref
+   +         | relref
+   +         | strong
+   +         | sub
+   +         | sup
+   +         | tt
+   +         | xref)*)
+   +   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 145]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + th =
+   +   element th {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     [ a:defaultValue = "0" ] attribute colspan { text }?,
+   +     [ a:defaultValue = "0" ] attribute rowspan { text }?,
+   +     [ a:defaultValue = "left" ]
+   +     attribute align { "left" | "center" | "right" }?,
+   +     ((artwork | dl | figure | ol | sourcecode | t | ul)+
+   +      | (text
+   +         | bcp14
+   +         | br
+   +         | cref
+   +         | em
+   +         | eref
+   +         | iref
+   +         | relref
+   +         | strong
+   +         | sub
+   +         | sup
+   +         | tt
+   +         | xref)*)
+       }
+     postamble =
+   -   element postamble { (text | xref | eref | iref | cref | spanx)*
+   +   element postamble {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text | cref | eref | iref | spanx | xref)*
+     }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 146]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     texttable =
+       element texttable {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute anchor { xsd:ID }?,
+         [ a:defaultValue = "" ] attribute title { text }?,
+         [ a:defaultValue = "false" ]
+         attribute suppress-title { "true" | "false" }?,
+         [ a:defaultValue = "center" ]
+         attribute align { "left" | "center" | "right" }?,
+         [ a:defaultValue = "full" ]
+         attribute style { "all" | "none" | "headers" | "full" }?,
+   +     name?,
+         preamble?,
+         ttcol+,
+         c*,
+         postamble?
+       }
+     ttcol =
+       element ttcol {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute width { text }?,
+         [ a:defaultValue = "left" ]
+         attribute align { "left" | "center" | "right" }?,
+   +     (cref | eref | iref | xref | text)*
+   +   }
+   + c =
+   +   element c {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text | cref | eref | iref | spanx | xref)*
+   +   }
+   + bcp14 =
+   +   element bcp14 {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         text
+       }
+   - c = element c { (text | xref | eref | iref | cref | spanx)* }
+   - back = element back { references*, section* }
+   + br =
+   +   element br {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     empty
+   +   }
+
+
+
+
+Hoffman                       Informational                   [Page 147]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + back =
+   +   element back {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     displayreference*,
+   +     references*,
+   +     section*
+   +   }
+   + displayreference =
+   +   element displayreference {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute target { xsd:IDREF },
+   +     attribute to { text }
+   +   }
+     references =
+       element references {
+   -     [ a:defaultValue = "References" ] attribute title { text }?,
+   -     reference+
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute pn { text }?,
+   +     attribute anchor { xsd:ID }?,
+   +     attribute title { text }?,
+   +     name?,
+   +     (reference | referencegroup)*
+       }
+     reference =
+       element reference {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute anchor { xsd:ID },
+         attribute target { text }?,
+   +     [ a:defaultValue = "true" ]
+   +     attribute quoteTitle { "true" | "false" }?,
+         front,
+   -     seriesInfo*,
+   -     format*,
+   -     annotation*
+   +     (annotation | format | refcontent | seriesInfo)*
+   +   }
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 148]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+   + referencegroup =
+   +   element referencegroup {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     attribute anchor { xsd:ID },
+   +     reference+
+       }
+     seriesInfo =
+       element seriesInfo {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute name { text },
+         attribute value { text },
+   +     attribute asciiName { text }?,
+   +     attribute asciiValue { text }?,
+   +     attribute status { text }?,
+   +     [ a:defaultValue = "IETF" ]
+   +     attribute stream { "IETF" | "IAB" | "IRTF" | "independent" }?,
+         empty
+       }
+     format =
+       element format {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+         attribute target { text }?,
+         attribute type { text },
+         attribute octets { text }?,
+         empty
+       }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 149]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+     annotation =
+   -   element annotation { (text | xref | eref | iref | cref |
+   - spanx)* }
+   - start = rfc
+   +   element annotation {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text
+   +      | bcp14
+   +      | cref
+   +      | em
+   +      | eref
+   +      | iref
+   +      | relref
+   +      | spanx
+   +      | strong
+   +      | sub
+   +      | sup
+   +      | tt
+   +      | xref)*
+   +   }
+   + refcontent =
+   +   element refcontent {
+   +     attribute xml:base { text }?,
+   +     attribute xml:lang { text }?,
+   +     (text | bcp14 | em | strong | sub | sup | tt)*
+   +   }
+   + start |= rfc
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 150]
+
+RFC 7991           The "xml2rfc" Version 3 Vocabulary      December 2016
+
+
+IAB Members at the Time of Approval
+
+   The IAB members at the time this memo was approved were
+   (in alphabetical order):
+
+      Jari Arkko
+      Ralph Droms
+      Ted Hardie
+      Joe Hildebrand
+      Russ Housley
+      Lee Howard
+      Erik Nordmark
+      Robert Sparks
+      Andrew Sullivan
+      Dave Thaler
+      Martin Thomson
+      Brian Trammell
+      Suzanne Woolf
+
+Acknowledgements
+
+   Thanks to everybody who reviewed this document and provided feedback
+   and/or specification text.  Thanks especially go to Julian Reschke
+   for editing [RFC7749] and those who provided feedback on that
+   document.
+
+   We also thank Marshall T. Rose for both the original design and the
+   reference implementation of the "xml2rfc" processor.
+
+Author's Address
+
+   Paul Hoffman
+   ICANN
+
+   Email: paul.hoffman@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                   [Page 151]
+
-- 
cgit v1.2.3