2.27.  <postal>

   Contains child elements providing postal information.

   Note that at least one <street> element needs to be present; however,
   formatters will handle empty values just fine.

   This element appears as a child element of <address> (Section 2.2).

   Content model:

   In this order:

   1.  One or more <street> elements (Section 2.37)

   2.  In any order:

       *  <city> elements (Section 2.9)

       *  <region> elements (Section 2.32)

       *  <code> elements (Section 2.10)

       *  <country> elements (Section 2.11)

2.28.  <postamble>

   Gives text that appears at the bottom of a figure or table.

   This element appears as a child element of <figure> (Section 2.17)
   and <texttable> (Section 2.39).

   Content model:

   In any order:

   o  Text

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

2.29.  <preamble>

   Gives text that appears at the top of a figure or table.

   This element appears as a child element of <figure> (Section 2.17)
   and <texttable> (Section 2.39).

   Content model:

   In any order:

   o  Text

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

2.30.  <reference>

   Represents a bibliographical reference.

   This element appears as a child element of <references>
   (Section 2.31).

   Content model:

   In this order:

   1.  One <front> element (Section 2.19)

   2.  Optional <seriesInfo> elements (Section 2.35)

   3.  Optional <format> elements (Section 2.18)

   4.  Optional <annotation> elements (Section 2.3)

2.30.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.

   The value 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.

2.30.2.  "target" Attribute

   Holds the URI for the reference.

   Note that, depending on the <seriesInfo> element, a URI might not be
   needed and might not be desirable, as it can be automatically
   generated (for instance, for RFCs).

2.31.  <references>

   Contains a set of bibliographical 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 Section 4.8.6 of [RFC7322].  This vocabulary supports
   the split with the "title" attribute.

   By default, the order of references is significant.  Processors,
   however, can be instructed to sort them based on their anchor names.

   This element appears as a child element of <back> (Section 2.7).

   Content model:

   One or more <reference> elements (Section 2.30)

2.31.1.  "title" Attribute

   Provides the title for the "References" section (defaulting to
   "References").

   In general, the title should be either "Normative References" or
   "Informative References".

2.32.  <region>

   Provides the region name in a postal address.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.

2.33.  <rfc>

   This is the root element of the xml2rfc vocabulary.

   Processors distinguish between RFC mode ("number" attribute being
   present) and Internet-Draft mode ("docName" attribute being present):
   it is invalid to specify both.  Setting neither "number" nor
   "docName" can be useful for producing other types of documents but is
   out of scope for this specification.

   Content model:

   In this order:

   1.  One <front> element (Section 2.19)

   2.  One <middle> element (Section 2.23)

   3.  One optional <back> element (Section 2.7)

2.33.1.  "category" Attribute

   Document category (see Appendix A.1).

   Allowed values:

   o  "std"

   o  "bcp"

   o  "info"

   o  "exp"

   o  "historic"

2.33.2.  "consensus" Attribute

   Affects the generated boilerplate.

   See [RFC5741] for more information.

   Allowed values:

   o  "no"

   o  "yes"

2.33.3.  "docName" Attribute

   For Internet-Drafts, this specifies the draft name (which appears
   below the title).

   A processor should give an error if both the "docName" and "number"
   attributes are given in the <rfc> element.

   Note that the file extension is not part of the draft, so in general
   it should end with the current draft number ("-", plus two digits).

   Furthermore, it is good practice to disambiguate current editor
   copies from submitted drafts (for instance, by replacing the draft
   number with the string "latest").

   See Section 7 of [IDGUIDE] for further information.

2.33.4.  "ipr" Attribute

   Represents the Intellectual Property status of the document.  See
   Appendix A.2 for details.

   Allowed values:

   o  "full2026"

   o  "noDerivativeWorks2026"

   o  "none"

   o  "full3667"

   o  "noModification3667"

   o  "noDerivatives3667"

   o  "full3978"

   o  "noModification3978"

   o  "noDerivatives3978"

   o  "trust200811"

   o  "noModificationTrust200811"

   o  "noDerivativesTrust200811"

   o  "trust200902"

   o  "noModificationTrust200902"

   o  "noDerivativesTrust200902"

   o  "pre5378Trust200902"

2.33.5.  "iprExtract" Attribute

   Identifies a single section within the document (by its "anchor"
   attribute) for which extraction "as is" is explicitly allowed (this
   is only relevant for historic values of the "ipr" attribute).

2.33.6.  "number" Attribute

   The number of the RFC to be produced.

   A processor should give an error if both the "docName" and "number"
   attributes are given in the <rfc> element.

2.33.7.  "obsoletes" Attribute

   A comma-separated list of RFC _numbers_ or Internet-Draft names.

   Processors ought to parse the attribute value, so that incorrect
   references can be detected and, depending on output format,
   hyperlinks can be generated.  Also, the value ought to be reformatted
   to insert whitespace after each comma if not already present.

2.33.8.  "seriesNo" Attribute

   Number within a document series.

   The document series is defined by the "category" attribute;
   "seriesNo" is only applicable to the values "info" ("FYI" series),
   "std" ("STD" series), and "bcp" ("BCP" series).

2.33.9.  "submissionType" Attribute

   The document stream.

   See Section 2 of [RFC5741] for details.

   Allowed values:

   o  "IETF" (default)

   o  "IAB"

   o  "IRTF"

   o  "independent"

2.33.10.  "updates" Attribute

   A comma-separated list of RFC _numbers_ or Internet-Draft names.

   Processors ought to parse the attribute value, so that incorrect
   references can be detected and, depending on output format,
   hyperlinks can be generated.  Also, the value ought to be reformatted
   to insert whitespace after each comma if not already present.

2.33.11.  "xml:lang" Attribute

   The natural language used in the document (defaults to "en").

   See Section 2.12 of [XML] for more information.

2.34.  <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.

   This element appears as a child element of <back> (Section 2.7),
   <middle> (Section 2.23), and <section> (Section 2.34).

   Content model:

   In this order:

   1.  In any order:

       *  <t> elements (Section 2.38)

       *  <figure> elements (Section 2.17)

       *  <texttable> elements (Section 2.39)

       *  <iref> elements (Section 2.20)

   2.  Optional <section> elements (Section 2.34)

2.34.1.  "anchor" Attribute

   Document-wide unique identifier for this section.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).

2.34.2.  "title" Attribute (Mandatory)

   The title of the section.

2.34.3.  "toc" Attribute

   Determines whether the section is included in the Table of Contents.

   The processor usually has defaults for whether a Table of Contents
   will be produced at all, and sections of which maximal depth will be
   included (frequently: 3).  "include" and "exclude" allow overriding
   the processor's default behavior for the element they are specified
   on (they do not affect either nested or parent elements).

   Allowed values:

   o  "include"

   o  "exclude"

   o  "default" (default)

2.35.  <seriesInfo>

   Specifies the document series in which this document appears, and
   also specifies an identifier within that series.

   This element appears as a child element of <reference>
   (Section 2.30).

   Content model: this element does not have any contents.

2.35.1.  "name" Attribute (Mandatory)

   The name of the series.

   Some series names might trigger specific processing (such as for
   autogenerating links, inserting descriptions such as "work in
   progress", or additional functionality like reference diagnostics).
   Examples for IETF-related series names are "BCP", "FYI",
   "Internet-Draft", "RFC", and "STD".

2.35.2.  "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).

2.36.  <spanx>

   Wraps a piece of text, indicating special formatting styles.

   When generating plain text, processors usually emulate font changes
   using characters such as "*" and "_".

   The following styles are defined:

   emph  Simple emphasis (this is the default).

   strong  Strong emphasis.

   verb  "Verbatim" text (usually displayed using a monospaced
      font face).

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <postamble> (Section 2.28),
   <preamble> (Section 2.29), and <t> (Section 2.38).

   Content model: only text content.

2.36.1.  "style" Attribute

   The style to be used (defaults to "emph").

2.36.2.  "xml:space" Attribute

   Determines whitespace handling.

   According to the DTD, the default value is "preserve".  However,
   tests show that it doesn't have any effect on processing; thus, this
   attribute will be removed in future versions of the vocabulary.

   See also Section 2.10 of [XML].

   Allowed values:

   o  "default"

   o  "preserve" (default)

2.37.  <street>

   Provides a street address.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.

2.38.  <t>

   Contains a paragraph of text.

   This element appears as a child element of <abstract> (Section 2.1),
   <list> (Section 2.22), <note> (Section 2.24), and <section>
   (Section 2.34).

   Content model:

   In any order:

   o  Text

   o  <list> elements (Section 2.22)

   o  <figure> elements (Section 2.17)

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

   o  <vspace> elements (Section 2.43)

2.38.1.  "anchor" Attribute

   Document-wide unique identifier for this paragraph.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).

2.38.2.  "hangText" Attribute

   Holds the label ("hanging text") for items in lists using the
   "hanging" style (see Section 2.22.3).

2.39.  <texttable>

   Contains a table, consisting of an optional preamble, a header line,
   rows, an optional postamble, and an optional title.

   The number of columns in the table is determined by the number of
   <ttcol> elements.  The number of rows in the table is determined by
   the number of <c> elements divided by the number of columns.  There
   is no requirement that the number of <c> elements be evenly divisible
   by the number of columns.

   This element appears as a child element of <section> (Section 2.34).

   Content model:

   In this order:

   1.  One optional <preamble> element (Section 2.29)

   2.  One or more <ttcol> elements (Section 2.41)

   3.  Optional <c> elements (Section 2.8)

   4.  One optional <postamble> element (Section 2.28)

2.39.1.  "align" Attribute

   Determines the horizontal alignment of the table.

   Allowed values:

   o  "left"

   o  "center" (default)

   o  "right"

2.39.2.  "anchor" Attribute

   Document-wide unique identifier for this table.

   Furthermore, the presence of this attribute causes the table to be
   numbered.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).

2.39.3.  "style" Attribute

   Selects which borders should be drawn, where

   o  "all" means borders around all table cells,

   o  "full" is like "all", except no horizontal lines between table
      rows (except below the column titles),

   o  "headers" adds just a separator between column titles and
      rows, and

   o  "none" means no borders at all.

   Allowed values:

   o  "all"

   o  "none"

   o  "headers"

   o  "full" (default)

2.39.4.  "suppress-title" Attribute

   Tables that have an "anchor" attribute will automatically get an
   autogenerated title (such as "Table 1"), even if the "title"
   attribute is absent.  Setting this attribute to "true" will
   prevent this.

   Allowed values:

   o  "true"

   o  "false" (default)

2.39.5.  "title" Attribute

   The title for the table; this usually appears on a line below the
   table body.

2.40.  <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's long (~40 characters), the "abbrev" attribute is used to specify
   an abbreviated variant.

   This element appears as a child element of <front> (Section 2.19).

   Content model: only text content.

2.40.1.  "abbrev" Attribute

   Specifies an abbreviated variant of the document title.

2.41.  <ttcol>

   Contains a column heading in a table.

   This element appears as a child element of <texttable>
   (Section 2.39).

   Content model: only text content.

2.41.1.  "align" Attribute

   Determines the horizontal alignment within the table column.

   Allowed values:

   o  "left" (default)

   o  "center"

   o  "right"

2.41.2.  "width" Attribute

   The desired column width (as integer 0..100 followed by "%").

2.42.  <uri>

   Contains a web address associated with the author.

   The contents should be a valid URI (see Section 3 of [RFC3986]).

   This element appears as a child element of <address> (Section 2.2).

   Content model: only text content.

2.43.  <vspace>

   This element can be used to force the inclusion of a single line
   break or multiple blank lines.

   Note that this is a purely presentational element; thus, its use
   ought to be avoided, except within a <list> as discussed in
   Section 2.22.

   This element appears as a child element of <t> (Section 2.38).

   Content model: this element does not have any contents.

2.43.1.  "blankLines" Attribute

   Number of blank lines to be inserted, where "0" indicates a single
   line break (defaults to "0").

   For paged output formats, no additional blank lines should be
   generated after a page break.

2.44.  <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 default "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.33.9).

   This element appears as a child element of <front> (Section 2.19).

   Content model: only text content.

2.45.  <xref>

   Inserts a cross-reference to a different part of a document.

   The generated text depends on (1) whether the <xref> is empty (in
   which case the processor will try to generate a meaningful text
   fragment), (2) the "format" attribute, and (3) the nature (XML
   element type) of the referenced document part.

   Any element that allows the "anchor" attribute can be referenced;
   however, there are restrictions with respect to the text content
   being generated.  For instance, a <t> can be a reference target;
   however, because paragraphs are not (visibly) numbered, the author
   will have to make sure that the combination of prose and contained
   text content is sufficient for a reader to understand what is being
   referred to.

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <postamble> (Section 2.28),
   <preamble> (Section 2.29), and <t> (Section 2.38).

   Content model: only text content.

2.45.1.  "format" Attribute

   This attribute is used to control the format of the generated
   reference text.

   "counter"

      Inserts a counter, such as the number of a section, figure, table,
      or list item.

      For targets that are not inherently numbered, such as references
      or comments, it uses the anchor name instead.

   "default"

      Inserts a text fragment that describes the referenced part
      completely, such as "Section 2", "Table 4", or "[XML]".

   "none"

      There will be no autogenerated text.

   "title"

      Inserts a title for the referenced element (usually obtained from
      the referenced element's "title" attribute; some processors also
      use the <title> child element or a <reference> target).

   Not all combinations of text content, "format" attribute, and type of
   referenced part lead to predictable results across different
   formatters.  In case this matters, the following combinations need to
   be avoided:

   o  Non-empty text content with any format other than "none".

   o  Empty text content with format "counter" for any target that isn't
      inherently numbered.

   o  Empty text content with format "title" for any target that doesn't
      have a title.

   Allowed values:

   o  "counter"

   o  "title"

   o  "none"

   o  "default" (default)

2.45.2.  "pageno" Attribute

   Unused.

   It's unclear what the purpose of this attribute is; processors seem
   to ignore it, and it never was documented.

   Allowed values:

   o  "true"

   o  "false" (default)

2.45.3.  "target" Attribute (Mandatory)

   Identifies the document component being referenced.

   The value needs to match the value of the "anchor" attribute of
   another element in the document.

3.  Escaping for Use in XML

   Text in XML cannot use the literal characters "<" and "&", as they
   have special meaning to the XML processor (starting entities,
   elements, etc.).  Usually, these characters will need to be
   substituted by "&lt;" and "&amp;" (see Section 4.6 of [XML]).

   ">" does not require escaping, unless it appears in the sequence
   "]]>" (which indicates the end of a CDATA section; see below).

   Escaping the individual characters can be a lot of work (when done
   manually) and also messes up alignment in artwork.  Another approach
   to escaping is to use CDATA sections (Section 2.7 of [XML]).  Within
   these, no further escaping is needed, except when the "end-of-CDATA"
   marker needs to be used (in that case, the CDATA section needs to be
   closed, and a new one needs to be started).

4.  Special Unicode Code Points

   Although the current RFC format does not allow non-ASCII Unicode
   characters [UNICODE], some of them can be used to enforce certain
   behaviors of formatters.

   For instance:

   non-breaking space (U+00A0)

      Represents a space character where no line break should happen.
      This is frequently used in titles (by excluding certain space
      characters from the line-breaking algorithm, the processor will
      use the remaining whitespace occurrences for line breaks).

   non-breaking hyphen (U+2011)

      Similarly, this represents a hyphen character where no line
      breaking ought to occur.

   word joiner (U+2060)

      Also called "zero width non-breaking space" -- can be used to
      disallow line breaking between two non-whitespace characters.

   Note that in order to use these characters by name, they need to be
   declared in either the Document Type Definition (DTD) or the
   "internal subset" (Section 2.8 of [XML]), like this:

   <?xml version="1.0"?>

   <!DOCTYPE rfc [

     <!-- declare nbsp and friends -->
     <!ENTITY nbsp    "&#xa0;">
     <!ENTITY nbhy    "&#x2011;">
     <!ENTITY wj      "&#x2060;">
   ]>

5.  Including Files

   This version of the vocabulary does not support an inclusion
   mechanism on its own -- thus, a document always needs to be
   self-contained.

   That being said, some processors do support file inclusion using
   Processing Instructions (Section 2.6 of [XML] and Section 4.1.2 of
   [TCLReadme]).

   Furthermore, XML itself allows inclusion of external content using
   the "internal subset" (Section 2.8 of [XML]).  Unfortunately, this
   requires declaring the external data in the DTD upfront.

   For instance:

   <?xml version="1.0"?>

   <!DOCTYPE rfc [

     <!-- allow later RFC 2629 reference using "&rfc2629;" -->
     <!-- the data will be fetched from xml2rfc.ietf.org -->
     <!ENTITY rfc2629 PUBLIC
     "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
   ]>

   ...declares the entity "rfc2629", which then can be used in the
   "References" section:

     <references>
       &rfc2629;
     </references>

   Note that this mechanism only works for well-formed XML fragments;
   thus, any plain text that would need to be escaped in XML can't be
   included as is.

6.  Internationalization Considerations

   This format is based on [XML] and thus does not have any issues
   representing arbitrary Unicode [UNICODE] characters in text content.

   However, the current canonical RFC format is restricted to US-ASCII
   characters (see [USASCII] and Section 3 of [RFC2223]).  It is
   possible that this rule will be relaxed in future revisions of the
   RFC format (for instance, to allow non-ASCII characters in examples
   and contact information).  In that case, it is expected that the
   vocabulary will be extended accordingly.

7.  Security Considerations

   The "name" attribute of the <artwork> element (Section 2.5.4) 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.

   Furthermore, the nature of XML, plus vocabulary features such as
   typed artwork, make it attractive to extract content from documents
   for further processing, such as for the purpose of checking syntax or
   computing/verifying examples.  In the latter case, care needs to be
   taken that only trusted content is processed.

   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 [BCP13] at
   <http://www.iana.org/assignments/media-types>.

   This document serves as the specification for the Internet Media Type
   "application/rfc+xml".  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].

   Interoperability considerations:  Some aspects of this vocabulary
      currently cannot be used interoperably; among the reasons for this
      are that they weren't precisely defined in the first place, that
      they have been added in an ad hoc fashion later on, or that they
      are specific to certain output formats.  This specification
      attempts to identify these cases in the description of the
      individual elements/attributes.

   Published specification:  This specification.

   Applications that use this media type:  Applications that transform
      xml2rfc to output formats 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 Section 3.2 of [XPOINTER].

   Additional information:

      Deprecated alias names for this type:  None.

      Magic number(s):  As specified for "application/xml" in
         Section 9.1 of [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 7749.

   Intended usage:  COMMON

   Restrictions on usage:  None.

   Author:  See the Author's Address section of RFC 7749.

   Change controller:  RFC Series Editor (rse@rfc-editor.org)

9.  References

9.1.  Normative References

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <http://www.rfc-editor.org/info/rfc2046>.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <http://www.rfc-editor.org/info/rfc3966>.

   [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>.

   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
              DOI 10.17487/RFC7303, July 2014,
              <http://www.rfc-editor.org/info/rfc7303>.

   [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,
              <http://www.w3.org/TR/2008/REC-xml-20081126/>.

              Latest version available at <http://www.w3.org/TR/xml>.

9.2.  Informative References

   [BCP13]    Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, January 2013,
              <http://www.rfc-editor.org/info/bcp13>.

   [CSS]      Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading
              Style Sheets Level 2 Revision 1 (CSS 2.1) Specification",
              W3C Recommendation REC-CSS2-20110607, June 2011,
              <http://www.w3.org/TR/2011/REC-CSS2-20110607/>.

              Latest version available at <http://www.w3.org/TR/CSS2>.

   [HTML]     Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle
              Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
              Recommendation REC-html5-20141028, October 2014,
              <http://www.w3.org/TR/2014/REC-html5-20141028/>.

              Latest version available at <http://www.w3.org/TR/html5/>.

   [IDGUIDE]  Housley, R., "Guidelines to Authors of Internet-Drafts",
              December 2010,
              <http://www.ietf.org/id-info/guidelines.html>.

   [JING]     Thai Open Source Software Center Ltd, "Jing - A RELAX NG
              validator in Java", 2008,
              <http://www.thaiopensource.com/relaxng/jing.html>.

              Downloads: <https://code.google.com/p/jing-trang/
              downloads/list>.

   [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>.

   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, DOI 10.17487/RFC2223, October 1997,
              <http://www.rfc-editor.org/info/rfc2223>.

   [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>.

   [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>.

   [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>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <http://www.rfc-editor.org/info/rfc5598>.

              PDF version: <http://www.rfc-editor.org/rfc/rfc5598.pdf>

   [RFC5741]  Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
              Headers, and Boilerplates", RFC 5741,
              DOI 10.17487/RFC5741, December 2009,
              <http://www.rfc-editor.org/info/rfc5741>.

   [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>.

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              DOI 10.17487/RFC7322, September 2014,
              <http://www.rfc-editor.org/info/rfc7322>.

   [RNC]      Clark, J., "RELAX NG Compact Syntax", OASIS,
              November 2002, <http://www.oasis-open.org/committees/
              relax-ng/compact-20021121.html>.

   [TCLReadme]
              Rose, M., Fenner, B., and C. Levert, "xml2rfc v1.35pre1",
              October 2009, <http://svn.tools.ietf.org/svn/tools/
              xml2rfc/archive/README.html>.

   [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>.

   [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.

   [V1rev]    Rose, M., "Writing I-Ds and RFCs using XML (revised)",
              February 2008,
              <http://svn.tools.ietf.org/svn/tools/xml2rfc/archive/
              draft-mrose-writing-rfcs.html>.

   [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/>.