RFC 7991

The "xml2rfc" Version 3 Vocabulary

๐Ÿ“… published December 2016, from ietf

RFC 7991: The "xml2rfc" Version 3 Vocabulary ๐Ÿ’–

Quick title-block tea โ˜•: this one comes from the Internet Architecture Board (IAB) ๐Ÿ›๏ธ, and the author is P. Hoffman from ICANN ๐ŸŒธ. It's dated December 2016 ๐Ÿ“…, and it's Informational ๐Ÿ“š, which is a fancy way of saying it's not a standard. It's ISSN 2070-1721 ๐Ÿ”ข. It obsoletes RFC 7749 ๐Ÿ”„, and it doesn't update anything else.

Abstract โœจ

Okay so this doc defines the "xml2rfc" version 3 vocabulary ๐ŸŽ€. It's an XML-based language for writing RFCs and Internet-Drafts ๐Ÿ“. It's heavily derived from the version 2 vocabulary, which is also still being discussed ๐Ÿ’ฌ. This document obsoletes the v2 grammar described in RFC 7749 ๐Ÿซถ.

Status of This Memo ๐ŸŒˆ

Bestie, this is not an Internet Standards Track specification ๐Ÿ™…โ€โ™€๏ธ. It's published for informational purposes ๐Ÿ“–.

This document is a product of the Internet Architecture Board (IAB) ๐Ÿ‘‘. It represents information the IAB decided was valuable enough to keep on the permanent record ๐Ÿ—‚๏ธ. It represents the consensus of the IAB โœ…. Documents the IAB approves for publication are not a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details ๐Ÿ”.

Want to know the current status, any errata, or how to send feedback? Go to http://www.rfc-editor.org/info/rfc7991 ๐Ÿ’Œ.

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 ๐Ÿ“œ. Please read those carefully, because they describe your rights and restrictions for this document ๐Ÿงพ.

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

1. Introduction โœจ

This doc describes version 3 ("v3") of the "xml2rfc" vocabulary ๐Ÿฆ‹. It's an XML-based language ("Extensible Markup Language" [XML]) used for writing RFCs [RFC7322] and Internet-Drafts [IDGUIDE] ๐Ÿ’….

Here's the glow-up story ๐ŸŒฑ. 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 material from [RFC7749] wherever possible ๐Ÿซถ, so if something feels familiar, it's not a coincidence lol.

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 that prepare the XML and convert it to other representations ๐Ÿงš. Features of the expected tools are described in Appendix B ๐Ÿ“Ž. That section defines some terms used throughout this document, like "prep tool" and "formatter" ๐Ÿ”ง.

Also, the vocabulary has some constructs that might not show up when you generate the final text ๐Ÿ™ˆ. They can still be super useful for other stuff, though, like index generation, populating a keyword database, or syntax checks ๐Ÿ“.

In this document, the term "format" is used when describing types of documents, mainly XML and HTML ๐Ÿ“„. The term "representation" is used for a specific instantiation of a format, like an XML document or an HTML document that was created from an XML document ๐ŸŽ€.

1.1. Expected Updates to the Specification ๐Ÿ”ฎ

Okay, real talk: non-interoperable changes in later versions of this specification are likely, based on what people learn while implementing the new publication toolsets ๐Ÿ› ๏ธโœจ. Revised documents will be published to capture those changes as the toolsets get finished ๐Ÿ“š. Other implementers must not expect those changes to remain backwards-compatible with the details in this document ๐Ÿ™…โ€โ™€๏ธ. So don't get too attached, babe ๐Ÿ’€.

1.2. Design Criteria for the Changes in v3 โœจ

okay so here's the vibe check for going from v2 to v3 ๐ŸŽ€ the design criteria are:

  • starting and editing a v3 document should be way easier than doing it with v2 ๐Ÿ’…
  • there will be good v2-to-v3 conversion tools for when an author wants to switch versions ๐Ÿ”ฅ
  • there are no current plans to make v3 XML the required submission format for drafts or RFCs ๐Ÿ™ˆ that might happen eventually, but it's giving "years away" energy

we want to keep as much of the v2 grammar as makes sense within those criteria, and we don't want to make gratuitous changes to it. basically, "we would rather encourage backwards compatibility but not be constrained by it." ๐Ÿ’œ still, making it easier to start and edit a v3 document matters more than backwards compatibility with v2, given the last two criteria, so that's the priority ๐Ÿซถ

v3 is upwards compatible with v2, meaning a v2 document is meant to be a valid v3 document too ๐Ÿฆ‹ however, some v2 features are deprecated in v3 in favor of new elements. those are listed in Section 1.3.3 and 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 โœจ

  • add <dl>, <ul>, and <ol> as new ways to make lists. this is a big change from v2 because the child under these elements is <li>, not <t> ๐Ÿ˜ญ an <li> can either contain one or more <t> elements, or contain the flowing text that normally lives in <t>. these lists are children of <section>s and other lists instead of <t>.
  • add <strong>, <em>, <tt>, <sub>, and <sup> for character formatting ๐Ÿ’…
  • add <aside> for incidental text that gets indented when displayed ๐ŸŽ€
  • add <sourcecode> to tell it apart from <artwork> ๐Ÿ“
  • add <table>, <thead>, <tbody>, <tfoot>, <tr>, <td>, and <th> to give table functionality like in HTML ๐ŸŒธ
  • add <boilerplate> to hold the automatically generated boilerplate text ๐Ÿค
  • add <blockquote> to indicate a quotation in a paragraph-like format ๐Ÿ’ฌ
  • add <name> to sections, notes, figures, and texttables so you can use character formatting (fixed-width font) in their titles and allow references in the names ๐Ÿง
  • add <postalLine>, which is free text representing one line of the address ๐Ÿ“ฎ
  • add <displayreference> to display more mnemonic anchor names for automatically included references ๐Ÿ”–
  • add <refcontent> for better control of the text in a reference โœ๏ธ
  • add <referencegroup> so you can reference multi-RFC documents like STDs and BCPs ๐Ÿ“š
  • add <relref> to reference specific sections or anchors in references ๐Ÿ”—
  • add <link> to point to a resource related to the RFC ๐ŸŒ
  • add <br> for line breaks (but not blank lines) in the generated output for table cells ๐Ÿซง
  • add <svg> to make it easy to include SVG drawings in <artwork> ๐ŸŽจ

1.3.2. New Attributes for Existing Elements ๐Ÿ’œ

  • add the "sortRefs", "symRefs", "tocDepth", and "tocInclude" attributes to <rfc> to cover the Processing Instructions (PIs) from v2 that are still needed in the grammar. add "prepTime" to indicate when the XML went through a preparation step. add "version" to indicate the version of the xml2rfc vocabulary used in the document. add "scripts" to indicate which scripts are needed to render the document. add "expiresDate" for when an Internet-Draft expires ๐Ÿ—“๏ธ
  • add "ascii" attributes to <email>, <organization>, <street>, <city>, <region>, <country>, and <code>. also add "asciiFullname", "asciiInitials", and "asciiSurname" to <author>. this lets an author put their info in their native scripts as the main entry while still getting ASCII-equivalent values in the processed documents ๐ŸŒโœจ
  • add "anchor" attributes to lots of block elements so they can be linked with <relref> and <xref> ๐Ÿฆ‹
  • add the "section", "relative", and "sectionFormat" attributes to <xref> ๐Ÿ”—
  • add the "numbered" and "removeInRFC" attributes to <section> ๐Ÿ™ˆ
  • add the "removeInRFC" attribute to <note> ๐Ÿ“
  • 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) ๐Ÿ”ข
  • add "display" to <cref> to tell tools whether or not to display the comment ๐Ÿ‘€
  • add "keepWithNext" and "keepWithPrevious" to <t> as a hint for pagination tools, so they try to keep the paragraph with the next or previous element ๐Ÿ“„

1.3.3. Elements and Attributes Deprecated from v2 ๐Ÿฅ€

deprecated elements and attributes are legacy vocabulary from v2 that's still supported for input to v3 tools. they'll likely 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 info on tools and how they'll handle deprecated features ๐Ÿ“–

  • deprecate <list> in favor of <dl>, <ul>, and <ol> ๐Ÿ‘‹
  • deprecate <spanx>; replace it with <strong>, <em>, and <tt> ๐Ÿ‘‹
  • deprecate <vspace> because its major use, creating pseudo-paragraph-breaks in lists, is now handled properly ๐Ÿ‘‹
  • deprecate <texttable>, <ttcol>, and <c>; replace them with the new table elements (<table> and the elements that can go inside it) ๐Ÿ‘‹
  • deprecate <facsimile> because it's rarely used ๐Ÿ‘‹
  • deprecate <format> because it's not useful and has caused surprises 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 ๐Ÿ‘‹
  • deprecate <preamble> and <postamble> in favor of simply using <t> before or after the figure. this also deprecates the "align" attribute in <figure> ๐Ÿ‘‹
  • deprecate the "title" attribute in <section>, <note>, <figure>, <references>, and <texttable> in favor of the new <name> ๐Ÿ‘‹
  • deprecate the "alt" and "src" attributes in <figure> because they overlap with the attributes in <artwork> ๐Ÿ‘‹
  • 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're not needed for the new output formats ๐Ÿ‘‹
  • deprecate the "pageno" attribute in <xref> because it was unused in v2. deprecate the "none" values for the "format" attribute in <xref> because they make no semantic sense ๐Ÿ‘‹

1.3.4. Additional Changes from v2 ๐Ÿงš

  • allow non-ASCII characters in the format. the characters that are actually allowed will be decided by the RFC Series Editor ๐ŸŒ
  • allow <artwork> and <sourcecode> to be used on their own in <section> (no more confining them to a figure) ๐ŸŽ€
  • give more specifics on handling the "type" attribute in <artwork> ๐Ÿ“
  • allow <strong>, <em>, <tt>, <eref>, and <xref> in <cref> ๐Ÿ’…
  • allow the sub-elements inside a <reference> to be in any order ๐Ÿ”€
  • turn off the autogeneration of anchors in <cref> because there's no use case for them that can't be achieved in other ways ๐Ÿ™…โ€โ™€๏ธ
  • allow more than one <artwork>, or more than one <sourcecode>, in <figure> ๐Ÿ–ผ๏ธ
  • in <front>, make <date> optional ๐Ÿ—“๏ธ
  • in <date>, add restrictions to the "date" and "year" attributes when used in the <front> for the document's boilerplate text ๐Ÿ“œ
  • in <postal>, allow the sub-elements to be in any order. also allow the new <postalLine> to be included instead of the older elements ๐Ÿ“ฎ
  • in <section>, restrict the names of the anchors that can be used on some types of sections ๐Ÿ”–
  • make <seriesInfo> a child of <front>, and deprecate it as a child of <reference>. this also deprecates some of the attributes from <rfc> and moves them into <seriesInfo> ๐Ÿซถ
  • <t> now only contains non-block elements, so it no longer contains <figure> elements ๐Ÿšซ
  • don't generate the grammar from a DTD. 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)) ๐Ÿ“–

the schema can be used for automated validity checks, but some constraints are only described in prose (for example, the conditionally required presence of the "abbrev" attribute) ๐Ÿ”

2. Elements ๐Ÿ’–

the sections below describe all the elements and their attributes ๐ŸŽ€

attributes that aren't 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]), and it's additionally constrained to US-ASCII characters [USASCII]. so the character repertoire is "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 ๐Ÿงš

tools interpreting the XML described here will collapse horizontal whitespace and line breaks to a single whitespace (except inside <artwork> and <sourcecode>), and they'll trim leading and trailing whitespace โœ‚๏ธ tab characters (U+0009) inside <artwork> and <sourcecode> are prohibited ๐Ÿšซ

some elements have attributes that aren't described in this section because they're 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 during 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 info 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:

  • <dl> elements (Section 2.20)
  • <ol> elements (Section 2.34)
  • <t> elements (Section 2.53)
  • <ul> elements (Section 2.63)

2.1.1. "anchor" Attribute ๐Ÿ”–

document-wide unique identifier for the Abstract ๐Ÿ†”

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>

Okay so <annotation> is how you tack extra prose onto a bibliographic reference ๐Ÿ’… It's shown after all the generated reference text, so it's like the bonus track at the end โœจ

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

Content model:

In any order:

  • 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)
  • <spanx> elements (Section 3.7)
  • <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.4. <area>

Here's where you say which IETF area your document is about ๐ŸŒธ Heads up, it's currently not used when generating documents, so it's more of a vibe check than aๅŠŸ่ƒฝ thing ๐Ÿ™ˆ

The value ought to be either the full name or the abbreviation of one of the IETF areas listed at http://www.ietf.org/iesg/area.html. The RFC Series Editor keeps a list of full names and abbreviations, so that's your source of truth ๐Ÿ“š

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

Content model: only text content.


2.5. <artwork>

This is your go-to for putting "artwork" in the doc ๐ŸŽจ <artwork> gives you full control over horizontal whitespace and line breaks, which is why it's used for diagrams ("line art") and protocol unit diagrams. Tab characters (U+0009) inside this element are a no-go ๐Ÿšซ

Alternatively, the src attribute lets you point at an external graphics file, like an SVG vector drawing or a bitmap, using a URI ๐Ÿ–ผ๏ธ In that case the text content is the fallback for output formats that can't show graphics, so it ought to hold either (1) a "line art" version of the graphic or (2) prose that describes the image in enough detail to be useful.

In [RFC7749], <artwork> was also used for source code and formal languages. In v3, that job now belongs to <sourcecode> ๐Ÿ’ป

There are at least five ways to include SVG in artwork in Internet-Drafts ๐Ÿฆ‹

  • 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...">
  • Inline, but using XInclude (see Appendix B.1), such as: <artwork type="svg"><xi:include href=...>
  • As a data: URI, such as: <artwork type="svg" src="data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3...">
  • As a URI to an external entity, such as: <artwork type="svg" src="http://www.example.com/...">
  • As a local file, such as: <artwork type="svg" src="diagram12.svg">

The use of SVG in Internet-Drafts and RFCs is covered in way more detail in [RFC7996] ๐Ÿค“

The above methods for including SVG art can also work for text artwork, but a data: URI is probably confusing for text artwork ๐Ÿ˜ตโ€๐Ÿ’ซ

Formatters that do pagination should try to keep artwork on a single page. This stops artwork that's split across pages from looking like two separate pieces of art ๐Ÿ“„โœ‚๏ธ

See Section 5 for how to deal with 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)

2.5.1. "align" Attribute

This one controls whether the artwork sits left justified (the default), centered, or right justified ๐ŸŽ€ The artwork is lined up relative to the document's left margin.

Allowed values:

  • "left" (default)
  • "center"
  • "right"

2.5.2. "alt" Attribute

This is the alternative text description for the artwork ๐Ÿซถ It's more than just a summary or caption. When the art comes from the src attribute and that format supports alternate text, the alt text comes from the artwork's own text instead of this attribute. This matters a LOT for readers who are visually impaired, and for anyone on devices that can't show the artwork well, or at all ๐Ÿ˜ญ

2.5.3. "anchor" Attribute

This is a document-wide unique identifier for the artwork ๐Ÿ”–

2.5.4. "height" Attribute

Deprecated. ๐Ÿชฆ

2.5.5. "name" Attribute

This is a filename that suits the contents, like for extracting to a local file ๐Ÿ“ It's super helpful for other tools, like automated syntax checkers that work by pulling out the artwork. The name attribute doesn't need to be unique across <artwork> elements in a document. If several <artwork> elements share the same name, a processing tool might assume they're all fragments of one file, and it can collect those fragments for later processing ๐Ÿงฉ See Section 7 for a discussion of possible problems with the value of this attribute.

2.5.6. "src" Attribute

This is the URI reference of a graphics file [RFC3986], or the name of a file on the local disk ๐Ÿ—‚๏ธ It can also be a "data" URI [RFC2397] that contains the contents of the graphics file. Heads up that including art with src depends on what the processing tool reading the XML can handle. Tools need to be able to handle the file: URI, and they should be able to handle http: and https: URIs too. The prep tool will be able to handle reading the src attribute.

If there's no URI scheme in the attribute, the attribute is treated as a local filename relative to the current directory. Processing tools must be careful not to accept dangerous filename values, especially ones with absolute references outside the current directory ๐Ÿšจ Document creators should think hard before using relative URIs, since files can cause problems later if they 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. Pick one, bestie ๐Ÿ™…โ€โ™€๏ธ

2.5.7. "type" Attribute

This specifies the type of the artwork. The value is free text, with certain values designated as preferred ๐ŸŒˆ

The preferred values for <artwork> types are:

  • ascii-art
  • binary-art
  • call-flow
  • hex-dump
  • svg

The RFC Series Editor maintains a complete list of the preferred values on the RFC Editor web site, and that list is expected to be updated over time ๐Ÿ“ So a consumer of v3 XML should not fail when it runs into an unexpected type or when no type is specified. The table will also show which types 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 is a container for content that's semantically less important or a little tangential to the stuff around it ๐Ÿงš Think of it as the side quest ๐Ÿ—บ๏ธ

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

Content model:

In any order:

  • <artwork> elements (Section 2.5)
  • <dl> elements (Section 2.20)
  • <figure> elements (Section 2.25)
  • <iref> elements (Section 2.27)
  • <list> elements (Section 3.4)
  • <ol> elements (Section 2.34)
  • <t> elements (Section 2.53)
  • <table> elements (Section 2.54)
  • <ul> elements (Section 2.63)

2.6.1. "anchor" Attribute

This is a document-wide unique identifier for this aside ๐Ÿ”–


2.7. <author>

This gives you info about a document's author ๐Ÿ–‹๏ธ It's used for the document itself (at the very beginning) and for referenced documents too.

The <author> elements inside the document's <front> element fill in the boilerplate and also generate the "Author's Address" section (see [RFC7322]) ๐Ÿ’Œ

Heads up: an "author" can also just be an organization! Skip all of the name attributes and add the <organization> child element instead ๐Ÿข

The role attribute can mark an author as "editor". That shows up on the front page, in the "Author's Address" section, and in bibliographic references ๐Ÿ“š Note that this specification doesn't define a precise meaning for the term "editor", so no pressure to figure that one out ๐Ÿ™ƒ

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 together with the separately specified asciiSurname ๐Ÿ”ค

2.7.3. "asciiSurname" Attribute

The ASCII equivalent of the author's surname, to be used together with the separately specified asciiInitials ๐Ÿ”ค

2.7.4. "fullname" Attribute

The full name, used in the automatically generated "Author's Address" section ๐Ÿงพ Even though this attribute is optional, if one or more of the asciiFullname, asciiInitials, or asciiSurname attributes have values, the fullname attribute is required. No skipping this one, periodt ๐Ÿ’…

2.7.5. "initials" Attribute

An abbreviated version of the given name(s), used together with the separately specified surname ๐Ÿ”  It usually shows up on the front page, in footers, and in references.

Some processors will post-process the value. For instance, when it only has a single letter, they might add a trailing dot. Relying on that kind of post-processing can lead to results that vary across formatters, so it ought to be avoided ๐Ÿ™…โ€โ™€๏ธ

2.7.6. "role" Attribute

This specifies the role the author had in creating the document ๐ŸŽญ

Allowed value:

  • "editor"

2.7.7. "surname" Attribute

The author's surname, used together with the separately specified initials ๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘ It usually shows up on the front page, in footers, and in references.


2.8. <back>

This is the "back" part of the document: the references and appendices ๐ŸŽฌ Inside <back>, <section> elements are how you mark 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)

2.9. <bcp14>

This marks text that's a phrase defined in [BCP14], like "MUST", "SHOULD NOT", and so on ๐Ÿ”ฅ When it's shown in some output formats, the text in this element might get highlighted โœจ Using this element is optional.

Only wrap the actual phrase from BCP 14, not the full definition of a requirement ๐ŸŽฏ For example, this is correct: The packet <bcp14>MUST</bcp14> be dropped. But this is NOT correct: <bcp14>The packet MUST be dropped.</bcp14> Keep the wrapping tight, bestie ๐Ÿ’œ

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> ๐Ÿ’ฌ

Okay bestie, this one is for quoting other people's words ๐Ÿซถ It says a block of text is a quotation.

This element shows up as a child 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)

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 ๐Ÿ”–

This is the document-wide unique ID for this quotation, so nothing else in the doc can share it.

2.10.2. "cite" Attribute ๐Ÿ”—

This is where the quote came from: the source of the citation. It must be a URI. If the "quotedFrom" attribute is also there, processing tools will use this URI as the link for that attribute's text, which is so cute ๐Ÿฅบ

2.10.3. "quotedFrom" Attribute โœ๏ธ

This is the name of the person or document the text is quoted from. A formatter should show it as visible text at the end of the quotation. Credit where credit is due, always ๐Ÿ’…


2.11. <boilerplate> ๐Ÿ“œ

This is the boilerplate text for the document, and the prep tool fills it in for you, so you don't have to type it out yourself ๐Ÿ™Œ

This element holds <section> elements. Every <section> element inside it must have the "numbered" attribute set to "false". No numbering allowed here, it's giving unnumbered ๐ŸŒธ

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

Content model:

  • One or more <section> elements (Section 2.46)

2.12. <br> ๐Ÿ“

This tells a formatting tool to put a line break in the output. If you stack several of these in a row, the extra ones get ignored, so don't spam them, bestie ๐Ÿ˜ญ

This element appears as a child of <td> (Section 2.56) and <th> (Section 2.58).

Content model: this element does not have any contents. It's just vibes โœจ


2.13. <city> ๐Ÿ™๏ธ

This gives the city name in a postal address.

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

Content model: only text content.

2.13.1. "ascii" Attribute ๐Ÿ”ค

This is the ASCII version of the city name, for when you need plain characters.


2.14. <code> ๐Ÿ”ข

This gives the postal region code.

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

Content model: only text content.

2.14.1. "ascii" Attribute ๐Ÿ”ค

This is the ASCII version of the postal code.


2.15. <country> ๐ŸŒ

This gives the country name or code in a postal address.

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

Content model: only text content.

2.15.1. "ascii" Attribute ๐Ÿ”ค

This is the ASCII version of the country name.


2.16. <cref> ๐Ÿ—’๏ธ

This represents a comment. Comments are for when the doc is still a work in progress, and they can show up inline and highlighted, at the end of the document, or not at all, depending on which formatting tool you're using ๐Ÿ‘€

This element appears as a child 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:

  • Text
  • <em> elements (Section 2.22)
  • <eref> elements (Section 2.24)
  • <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.16.1. "anchor" Attribute ๐Ÿ”–

This is the document-wide unique ID for this comment.

2.16.2. "display" Attribute ๐Ÿ‘๏ธ

This suggests whether formatting tools should display the comment. Setting it to "false" is a neat move when you want to keep a comment around after you've already dealt with it, like a receipt ๐Ÿงพ

Allowed values:

  • "true" (default)
  • "false"

2.16.3. "source" Attribute ๐Ÿซ‚

This holds the "source" of a comment, like the name or initials of whoever left it. Give credit, babe ๐Ÿ’œ


2.17. <date> ๐Ÿ“…

This gives the publication date. It's used in two situations: the boilerplate of the document you're producing, 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. Strict, but fair ๐Ÿฅน

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. Honestly, the easy fix is just skipping it ๐Ÿ™ˆ

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. Vibes-based dates are welcome here ๐Ÿ˜Œ

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

Content model: this element does not have any contents.

2.17.1. "day" Attribute ๐Ÿ—“๏ธ

This is the day of publication.

2.17.2. "month" Attribute ๐ŸŒ™

This is the month or months of publication.

2.17.3. "year" Attribute โญ

This is the year or years of publication.


2.18. <dd> ๐Ÿ“

This is the definition part of an entry in a definition list. The term is the other half, and together they make a pair ๐ŸŽ€

This element appears as a child 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)
    • <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 ๐Ÿ”–

This is the document-wide unique ID for this definition.


2.19. <displayreference> ๐Ÿช„

This is a little glow-up trick ๐Ÿ’ซ It maps the anchor of a reference to a name that gets displayed instead. That way, you can show more mnemonic names for references that get pulled in automatically. The mapping 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 too, so keep an eye on that ๐Ÿ‘€

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. So it's a temporary helper, not a forever thing ๐Ÿฆ‹

This element appears as a child 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. It's required, so don't skip it!

2.19.2. "to" Attribute (Mandatory) ๐Ÿ’Œ

This is the name that will be displayed as the anchor, instead of the anchor given in the <reference> element. The string you give must start with one of these characters: 0-9, a-z, or A-Z. The other characters in the string must be 0-9, a-z, A-Z, "-", ".", or "_". Keep it clean, babe โœจ


2.20. <dl> ๐Ÿ“–

This is a definition list. Each entry is a pair: a term (<dt>) and a definition (<dd>). It's a bit simpler than the HTML version, which lets you have multiple terms for one definition. Simple is iconic ๐Ÿ’…

This element appears as a child 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 sequences of:

  1. One <dt> element
  2. One <dd> element

2.20.1. "anchor" Attribute ๐Ÿ”–

This is the document-wide unique ID for the list.

2.20.2. "hanging" Attribute ๐Ÿชง

This decides whether the term sits on the same line as the definition. hanging="true" means the term is to the left of the definition, and hanging="false" means the term gets its own line ๐ŸŒˆ

Allowed values:

  • "false"
  • "true" (default)

2.20.3. "spacing" Attribute ๐Ÿ“

This decides whether there's a blank line between entries. spacing="normal" gives you a single blank line, and spacing="compact" gives you no space at all between them ๐Ÿค

Allowed values:

  • "normal" (default)
  • "compact"

2.21. <dt> ๐Ÿท๏ธ

This is the term being defined in a definition list. Think of it as the label on the box ๐Ÿ“ฆ

This element appears as a child of <dl> (Section 2.20).

Content model:

In any order:

  • 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.21.1. "anchor" Attribute ๐Ÿ”–

This is the document-wide unique ID for this term.

2.22. <em> โœจ

Okay bestie, <em> is how you mark text as semantically emphasized ๐Ÿ’– Anything inside it gets displayed in italics after processing. You can stack it with other character formatting elements and the effects just add up ๐ŸŽ€

This element can show up as a child 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). It's giving main character energy everywhere ๐Ÿ’…

Content model:

In any order:

  • Text
  • <bcp14> elements (Section 2.9)
  • <cref> elements (Section 2.16)
  • <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.23. <email> ๐Ÿ’Œ

Provides an email address, bestie ๐Ÿ“ฌ

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

This is the ASCII equivalent of the author's email address. It's only used if the email address has any internationalized components ๐ŸŒธ

2.24. <eref> ๐Ÿ”—

Represents an "external" link (as specified in the "target" attribute). It's super useful for dropping URIs right into the body of a document ๐Ÿฆ‹

If the <eref> element has non-empty text content, formatters should use that content as the displayed text that gets linked. Otherwise, the formatter should use the value of the "target" attribute as the displayed text. Formatters link the displayed text to the value of the "target" attribute in whatever way fits 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>.

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) ๐ŸŽฏ

This is the URI of the link target [RFC3986]. It must begin with a scheme name (such as "https://"), so it can't be relative to the URL of the current document ๐Ÿ™…โ€โ™€๏ธ

2.25. <figure> ๐Ÿ–ผ๏ธ

Contains a figure with a caption that has 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).

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:

  • "left" (default)
  • "center"
  • "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 ๐Ÿฅ€

2.25.6. "suppress-title" Attribute

Deprecated ๐Ÿฅ€

Allowed values:

  • "true"
  • "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 (like author info), the Abstract, and any extra 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)
  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 (when "subitem" is given as well), grouped under a regular entry.

Index entries generally point to the exact place where the <iref> element occurred. The exception is when it's a child element of <section>, in which case the whole section counts as 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)

This is the item to include ๐Ÿท๏ธ

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's no restriction on how many occurrences can be "primary" โญ

Allowed values:

  • "true"
  • "false" (default)

2.27.3. "subitem" Attribute

This is the subitem to include ๐ŸŒฟ

2.28. <keyword> ๐Ÿ”‘

Specifies a keyword that applies to the document ๐ŸŽ€

Note that each element should only contain a single keyword. For multiple keywords, just repeat the element ๐Ÿ’–

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)
  • <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 ๐Ÿท๏ธ

A link to an external document related to the RFC ๐ŸŒ

These are the supported types of external documents that can be pointed to in a <link> element:

  • 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:".
  • 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.
  • 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.
  • 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)

This is the URI of the external document ๐Ÿ”—

2.30.2. "rel" Attribute

This is the relationship of the external document to this one. The relationships are taken from the "Link Relations" registry maintained by IANA [LINKRELATIONS] ๐Ÿ—ƒ๏ธ

2.31. <middle> ๐Ÿง

Represents the main content of the document, the good stuff ๐Ÿฐ

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> โœจ

okay so <name> is the name of a section, note, figure, or texttable ๐ŸŽ€ and this name can even say how the flowing text should be marked up, like pulling in references or making some characters use a fixed-width font ๐Ÿ’…

<name> lives inside <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) ๐Ÿฆ‹

Its content model is totally flexible, in any order:

  • Text
  • <cref> elements (Section 2.16)
  • <eref> elements (Section 2.24)
  • <relref> elements (Section 2.44)
  • <tt> elements (Section 2.62)
  • <xref> elements (Section 2.66)

2.33. <note> ๐ŸŒธ

<note> makes an unnumbered, titled block of text that shows up after the Abstract ๐Ÿ“

People usually use it to share extra info with reviewers (Working Group info, the mailing list, and so on) or for publication info like "IESG Notes" ๐Ÿงš

This element goes inside <front> (Section 2.26) ๐Ÿ’œ

Its content model is ordered, so:

  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 this is set to "true", the note gets marked in the prep tool with text saying it should be removed before the document is published as an RFC ๐Ÿ™ˆ That text is This note is to be removed before publishing as an RFC.

Allowed values:

  • "true"
  • "false" (default)

2.33.2. "title" Attribute ๐Ÿฅ€

This one is deprecated, so just use <name> instead ๐Ÿ’…

2.34. <ol> ๐Ÿ”ข

<ol> is an ordered list ๐Ÿ“ The labels on the items are either a number or a letter, depending on the value of the style attribute.

This element goes inside <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) ๐ŸŒˆ

It needs one or more <li> elements (Section 2.29) inside it ๐Ÿซถ

2.34.1. "anchor" Attribute ๐Ÿ”—

This is the document-wide unique identifier for the list โœจ

2.34.2. "group" Attribute ๐Ÿ‘‘

When the prep tool sees an <ol> with a "group" attribute it has already seen, it keeps counting the list from wherever the previous list with the same group name stopped ๐Ÿฆ‹ If an <ol> has both a "group" attribute and a "start" attribute, the group's numbering gets reset to the given start value ๐Ÿ”ฅ

2.34.3. "spacing" Attribute ๐Ÿซง

This decides whether there's a blank line between entries. spacing="normal" gives you a single blank line, and spacing="compact" gives you no space between them ๐Ÿ’–

Allowed values:

  • "normal" (default)
  • "compact"

2.34.4. "start" Attribute ๐ŸŒŸ

This is the ordinal value where the list starts. It defaults to "1" and must be an integer of 0 or greater ๐Ÿ’œ

2.34.5. "type" Attribute ๐ŸŽ€

This sets the type of the labels on the list items ๐Ÿ’… If the type value is only 1 character long, it works the same way it does in 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 "a" and "A", once you get past the 26th entry, the numbering rolls over to "aa"/"AA", then "ab"/"AB", and so on ๐Ÿฆ‹

If the type value is longer than 1 character, it must contain a percent-encoded indicator and other text ๐Ÿงš It's free-form text that lets you drop counter values in with a "percent-letter" format. For example, "[REQ%d]" makes labels like [REQ1], where %d puts in the item number as a decimal number ๐Ÿ’–

These 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's an error for the type string to be empty. For bulleted lists, use the <ul> element instead. For lists with neither bullets nor numbers, use the <ul> element with the empty="true" attribute ๐Ÿฅบ

If there's no type attribute at all, the default type is the same as type='%d.' โœจ

2.35. <organization> ๐Ÿข

This specifies the affiliation [RFC7322] of an author ๐Ÿ’ผ

The info shows up in both the "Author's Address" section and on the front page (see [RFC7322] for more information) ๐Ÿ“„ If the value is long, you can give an abbreviated version in the "abbrev" attribute โœ‚๏ธ

This element goes inside <author> (Section 2.7) ๐Ÿซถ

Content model: only text content ๐Ÿ’ฌ

2.35.1. "abbrev" Attribute โœ‚๏ธ

This is the abbreviated variant ๐Ÿ’–

2.35.2. "ascii" Attribute ๐Ÿ”ค

This is the ASCII equivalent of the organization's name ๐ŸŒธ

2.36. <phone> ๐Ÿ“ž

This represents a phone number โ˜Ž๏ธ

The value is expected to be the scheme-specific part of a "tel" URI, so it doesn't include the "tel:" prefix, and it uses the "global-number-digits" syntax ๐Ÿฆ‹ See Section 3 of [RFC3966] for the details ๐Ÿ’œ

This element goes inside <address> (Section 2.2) ๐Ÿงš

Content model: only text content ๐Ÿ’ฌ

2.37. <postal> ๐Ÿ“ฎ

<postal> holds optional child elements with postal info โœ‰๏ธ These get displayed in an order that's specific to each formatter ๐ŸŒˆ A postal address can have either a set of <street>, <city>, <region>, <code>, and <country> elements, or an ordered set of <postalLine> elements, but never both ๐Ÿ™…โ€โ™€๏ธ

This element goes inside <address> (Section 2.2) ๐ŸŽ€

Its content model is one of the following:

  • 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)

2.38. <postalLine> ๐Ÿก

This represents one line of a postal address ๐ŸŒท If you give more than one <postalLine>, the prep tool emits them in the order you gave them ๐Ÿ”

This element goes inside <postal> (Section 2.37) ๐Ÿ’…

Content model: only text content ๐Ÿ’ฌ

2.38.1. "ascii" Attribute ๐Ÿ”ค

This is the ASCII equivalent of the text in the address line ๐Ÿ’–

2.39. <refcontent> ๐Ÿ“š

This is text that should show up between the title and the date of a reference ๐Ÿฅฐ The whole point is so you don't have to abuse <seriesInfo> just to get that kind of text in there ๐Ÿ™ˆ

Here's an 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>

And that would render as:

[April1]     Phunny, K., "On Being A Fool", Self-published
             pamphlet, April 2000.

This element goes inside <reference> (Section 2.40) ๐Ÿฆ‹

Content model, in any order:

  • Text
  • <bcp14> elements (Section 2.9)
  • <em> elements (Section 2.22)
  • <strong> elements (Section 2.50)
  • <sub> elements (Section 2.51)
  • <sup> elements (Section 2.52)
  • <tt> elements (Section 2.62)

2.40. <reference> ๐Ÿ“–

This represents a bibliographic reference ๐Ÿ”–

This element goes inside <referencegroup> (Section 2.41) and <references> (Section 2.42) ๐Ÿงš

Its content model is ordered:

  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) ๐Ÿ”—

This is the document-wide unique identifier for this reference ๐ŸŒŸ Usually it's 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 ๐Ÿ’ฌ

This specifies whether or not the title in the reference should be quoted. You can use it to stop quoting, like for errata ๐Ÿ™ƒ

Allowed values:

  • "true" (default)
  • "false"

2.40.3. "target" Attribute ๐ŸŽฏ

This holds the URI for the reference ๐ŸŒ

2.41. <referencegroup> ๐Ÿ—‚๏ธ

This represents a list of bibliographic references that get shown as a single reference ๐Ÿฆ‹ It's most often used for STDs and BCPs, where one reference (like "BCP 9") might cover more than one RFC ๐Ÿ‘‘

This element goes inside <references> (Section 2.42) ๐ŸŒธ

Content model: one or more <reference> elements (Section 2.40) ๐Ÿ’…

2.41.1. "anchor" Attribute (Mandatory) ๐Ÿ”—

This is the document-wide unique identifier for this reference group โœจ Usually it's used both to label the reference group in the "References" section and as an identifier in links to this reference entry ๐Ÿซถ

2.42. <references> ๐Ÿ“š

This contains a set of bibliographic references ๐Ÿ’–

Back in the early days of the RFC Series, there was only one "References" section per RFC ๐Ÿ•ฐ๏ธ That got changed later, and references were split into two sets, "Normative" and "Informative", as described in [RFC7322] ๐ŸŽ€ This vocabulary supports that split with the <name> child element ๐Ÿ’… In general, the title should be either "Normative References" or "Informative References" โœจ

This element goes inside <back> (Section 2.8) ๐Ÿงš

Its content model is ordered:

  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 ๐Ÿ”—

This is an optional user-supplied identifier for this set of references ๐ŸŒท

2.42.2. "title" Attribute ๐Ÿฅ€

This one's deprecated too, so use <name> instead ๐Ÿ’…

2.43. <region> ๐Ÿ—บ๏ธ

This provides the region name in a postal address ๐ŸŒ

This element goes inside <postal> (Section 2.37) ๐Ÿ’œ

Content model: only text content ๐Ÿ’ฌ

2.43.1. "ascii" Attribute ๐Ÿ”ค

This is the ASCII equivalent of the region name ๐Ÿซถ

2.44. <relref>

Okay bestie, <relref> is basically a link to one specific part of a document, and it lives inside a <reference> element ๐Ÿ”—โœจ Formatters that do links (like HTML and PDF) turn it into an external hyperlink pointing at that exact part. They build the link by smooshing together the base URI from the <reference> element and 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 in the v3 format, the element needs a "relative" attribute. In that case, the "section" attribute's value gets ignored ๐Ÿ™ˆ

Here's an example of <relref> with text content:

See
<relref section="2.3" target="RFC9999" displayFormat="bare">
the protocol overview</relref>
for more information.

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

Heads up, the URL in that example might look different once the RFC Editor deploys the v3 format ๐Ÿงš

This element shows up as a child 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 tells formatters how the relative reference should be displayed. Formatters for document types with linking capability should wrap each part of the displayed text in hyperlinks. If there's content in the <relref> element, formatters ignore this attribute's value ๐ŸŽ€

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

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 you don't need to include it in a <relref> element if that's the format you want ๐Ÿ’…

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

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 handy when you've got multiple relative references pointing at one 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:

  • "of" (default)
  • "comma"
  • "parens"
  • "bare"

2.44.2. "relative" Attribute

This specifies a relative reference from the URI in the target reference. The value has to include whatever leading character is needed to create the relative reference. Usually that's "#" for HTML documents ๐ŸŒธ

2.44.3. "section" Attribute (Mandatory)

This specifies a section of the target reference. If the reference is not an RFC or Internet-Draft in the v3 format, it's an error ๐Ÿ’€

2.44.4. "target" Attribute (Mandatory)

This is the anchor of the reference for this element. If this value isn't an anchor to a <reference> or <referencegroup> element, it's an error. If the reference at the target has no URI, that's also 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>.

2.45.2. "consensus" Attribute

This affects the generated boilerplate. The values "no" and "yes" are deprecated and get replaced by "false" (the default) and "true" โœจ

See [RFC7841] for more information.

Allowed values:

  • "no"
  • "yes"
  • "false" (default)
  • "true"

2.45.3. "docName" Attribute

Deprecated! Instead, use the "value" attribute in <seriesInfo>.

2.45.4. "indexInclude" Attribute

This 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 when the source document has <iref> elements but the author doesn't want an index anymore ๐Ÿ“š

Allowed values:

  • "true" (default)
  • "false"

2.45.5. "ipr" Attribute

This represents the Intellectual Property status of the document. See Appendix A.1 for details ๐ŸŽ€

2.45.6. "iprExtract" Attribute

This identifies a single section within the document for which extraction "as is" is explicitly allowed. It's only relevant for historic values of the "ipr" attribute.

2.45.7. "number" Attribute

Deprecated! Instead, use the "value" attribute in <seriesInfo>.

2.45.8. "obsoletes" Attribute

This is 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

This is the date that the XML was processed by a prep tool. It's included in the XML file just before it's 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

This specifies whether or not the prep tool will sort the references in each reference section.

Allowed values:

  • "true"
  • "false" (default)

2.45.12. "submissionType" Attribute

This is the document stream, as described in [RFC7841]. (The RFC Series Editor may change the list of allowed values in the future ๐ŸŒˆ)

Allowed values:

  • "IETF" (default)
  • "IAB"
  • "IRTF"
  • "independent"

2.45.13. "symRefs" Attribute

This specifies whether or not a formatter is requested to use symbolic references, like "[RFC2119]". If the value is "false", the references come out as numbers, like "[3]" ๐Ÿ”ข

Allowed values:

  • "true" (default)
  • "false"

2.45.14. "tocDepth" Attribute

This 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

This specifies whether or not a formatter is requested to include a table of contents in generated files.

Allowed values:

  • "true" (default)
  • "false"

2.45.16. "updates" Attribute

This is 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

This specifies the version of xml2rfc syntax used in this document. The only expected value (for now) is "3" ๐Ÿซถ


2.46. <section>

This represents a section (when it's inside a <middle> element) or an appendix (when it's inside a <back> element) ๐Ÿ“

Subsections are made by nesting <section> elements inside <section> elements. Sections are allowed to be empty.

This element appears as a child 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

This is a 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 isn't followed by a numbered section in this part of the document, and it'll verify that the section is a top-level section ๐Ÿ™…โ€โ™€๏ธ

Allowed values:

  • "true" (default)
  • "false"

2.46.3. "removeInRFC" Attribute

If set to "true", this note gets marked in the prep tool with text saying 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:

  • "true"
  • "false" (default)

2.46.4. "title" Attribute

Deprecated. Use <name> instead ๐ŸŒธ

2.46.5. "toc" Attribute

Okay so this one is the bouncer for the table of contents ๐ŸŽ€. It tells a formatter whether this section gets to show up in the TOC, if a TOC is being made at all ๐Ÿ’…. It only takes effect if the section's level would have shown up based on the tocDepth attribute of the <rfc> element, and obviously only if the TOC is being built from the tocInclude attribute of the <rfc> element ๐ŸŒธ. If you set it to exclude, every section underneath this one gets kicked out too ๐Ÿ˜ญ. The default value means the section is included if tocDepth says it should be ๐Ÿฆ‹.

Allowed values:

  • include
  • exclude
  • default (default)

2.47. <seriesInfo>

This element says which document series your doc belongs to, plus its ID inside that series ๐Ÿ“šโœจ.

A processing tool figures out whether it's looking at an RFC or an Internet-Draft by checking the name attribute of a <seriesInfo> element inside the <front> element inside the <rfc> element. It's looking for "RFC" or "Internet-Draft" ๐Ÿ”. (If you specify neither value in any of the <seriesInfo> elements, that can still be useful for making other kinds of documents, but it's out of scope for this spec ๐Ÿ™ˆ.)

It's invalid to have multiple <seriesInfo> elements inside the same <front> element with the same name value ๐Ÿ’€. Some combos just don't make sense, like having both <seriesInfo name="rfc"/> and <seriesInfo name="Internet-Draft"/> in the same <front> element. Absolutely not ๐Ÿ™…โ€โ™€๏ธ.

This element shows up as a child 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 version of the name field ๐ŸŽ€.

2.47.2. "asciiValue" Attribute

The ASCII version of the value field ๐ŸŒˆ.

2.47.3. "name" Attribute (Mandatory)

This is the name of the series. The currently known values are "RFC", "Internet-Draft", and "DOI". The RFC Series Editor might change this list later ๐Ÿ‘‘.

Some of the name values interact with each other like this:

  • If a <front> element has a <seriesInfo> element with a name of "Internet-Draft", it can also have at most one extra <seriesInfo> element with a status attribute set to "standard", "full-standard", "bcp", "fyi", "informational", "experimental", or "historic". That tells you the intended status of this Internet-Draft, if it ever gets published as an RFC ๐Ÿ”ฅ. If that extra element has one of those statuses, its name needs to be "".
  • If a <front> element has a <seriesInfo> element with a name of "RFC", it can also have at most one extra <seriesInfo> element with a status attribute set to "full-standard", "bcp", or "fyi", which shows the current status of this RFC โœจ. If that extra 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 another <seriesInfo> element with a status of "info", "exp", or "historic" and a name of "" to show the RFC's status ๐Ÿฆ‹.
  • A <front> element that has a <seriesInfo> element named "Internet-Draft" can't also have one named "RFC" ๐Ÿ™…โ€โ™€๏ธ. Pick a lane, bestie.
  • The <seriesInfo> element can contain the DOI for the referenced document ๐ŸŒธ. You can't use this when the <seriesInfo> is somewhere underneath an <rfc> element, only under a <reference> element. The value attribute should use the form specified in [RFC7669] โœจ.

2.47.4. "status" Attribute

This is the status of the document. The currently known values are "standard", "informational", "experimental", "bcp", "fyi", and "full-standard". The RFC Series Editor might change this list in the future ๐Ÿ’œ.

2.47.5. "stream" Attribute

This is the stream (as described in [RFC7841]) that started the document ๐ŸŒŠ. (The RFC Series Editor might change this list later too ๐Ÿซถ.)

Allowed values:

  • "IETF" (default)
  • "IAB"
  • "IRTF"
  • "independent"

2.47.6. "value" Attribute (Mandatory)

This is the identifier inside the series that the name attribute points to ๐ŸŽฏ.

For BCPs, FYIs, RFCs, and STDs, it's the number within the series ๐Ÿ”ข. For Internet-Drafts, it's the full draft name, ending with the two-digit version number ๐Ÿง. For DOIs, the value is given like "10.17487/rfc1149", as described in [RFC7669] ๐ŸŒท.

The name in the value should be the document name with no file extension ๐Ÿ™ˆ. For Internet-Drafts, the value should be "draft-ietf-somewg-someprotocol-07", not "draft-ietf-somewg-someprotocol-07.txt". Main character energy would be remembering the ".txt" isn't invited ๐Ÿ’….

2.48. <sourcecode>

This element lets you put source code right into the document ๐Ÿ’ปโœจ.

When it's rendered, source code is always shown in a monospace font ๐ŸŽ€. When <sourcecode> is a child of <figure> or <section>, you get full control over horizontal whitespace and line breaks ๐Ÿ™Œ. When it's formatted, it's indented relative to the left margin of the element around it ๐Ÿ“. That makes it super useful for source code and formal languages, like ABNF [RFC5234] or the RNC notation used in this document ๐Ÿ“œ. (When <sourcecode> is a child of other elements, it flows with the text around it ๐ŸŒˆ.) Tab characters (U+0009) are prohibited inside this element, so don't even try ๐Ÿšซ.

For artwork like character-based art and diagrams of message layouts, use the <artwork> element instead ๐ŸŽจ.

Output formatters that do pagination should try to keep source code on one page ๐Ÿ“„. This stops source code that gets split across pages from looking like two separate pieces of code ๐Ÿ˜ญ.

Check Section 5 for how to handle using & and < characters in source code ๐Ÿซถ.

This element shows up as a child 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

This is the document-wide unique identifier for this source code ๐Ÿ”‘.

2.48.2. "name" Attribute

This is a filename that fits the contents, like for pulling the code out into a local file ๐Ÿ“. It's helpful for other kinds of tools too, like automated syntax checkers, which work by extracting the source code ๐Ÿค“. The name attribute doesn't need to be unique for <artwork> elements in a document. If multiple <sourcecode> elements have the same name attribute, a formatter might assume they're all fragments of one file, and it can collect those fragments for later processing ๐Ÿงฉ.

2.48.3. "src" Attribute

This is the URI reference of a source file [RFC3986] ๐Ÿ”—.

It's an error to have both a src attribute and content in the <sourcecode> element ๐Ÿšจ. Pick one, periodt.

2.48.4. "type" Attribute

This specifies the type of the source code ๐Ÿท๏ธ. The value is free text, with certain values marked as preferred.

The preferred values for <sourcecode> types are:

  • abnf
  • asn.1
  • bash
  • c++
  • c
  • cbor
  • dtd
  • java
  • javascript
  • json
  • mib
  • perl
  • pseudocode
  • python
  • rnc
  • xml
  • yang

The RFC Series Editor keeps a complete list of the preferred values on the RFC Editor web site, and that list is expected to get updated over time ๐ŸŒธ. So a consumer of v3 XML shouldn't crash when it runs into an unexpected type, or when no type is specified at all ๐Ÿซถ. Chill, it's fine.

2.49. <street>

This element gives you a street address ๐Ÿก.

This element shows up as a child of <postal> (Section 2.37) ๐Ÿ“ฎ.

Content model: only text content.

2.49.1. "ascii" Attribute

The ASCII version of the street address ๐ŸŒท.

2.50. <strong>

This element marks text as semantically strong ๐Ÿ’ช. Anything inside it gets displayed in bold once it's processed ๐Ÿ–ค. You can mix it with other character formatting elements, and the formatting just stacks up โœจ.

This element shows up as a child 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) ๐ŸŽ€.

Content model:

In any order:

  • 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)
  • <sub> elements (Section 2.51)
  • <sup> elements (Section 2.52)
  • <tt> elements (Section 2.62)
  • <xref> elements (Section 2.66)

2.51. <sub>

This makes the text show up as subscript, about half a letter-height lower than normal text ๐Ÿ‘‡๐Ÿฆ‹. You can combine it with other character formatting elements, and the formatting stacks up ๐Ÿ’–.

This element shows up as a child 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:

  • 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)
  • <tt> elements (Section 2.62)
  • <xref> elements (Section 2.66)

2.52. <sup>

This makes the text show up as superscript, about half a letter-height higher than normal text ๐Ÿ‘†๐ŸŒŸ. Same deal as subscript: you can combine it with other character formatting elements, and the formatting stacks ๐Ÿซถ.

This element shows up as a child 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:

  • 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)
  • <tt> elements (Section 2.62)
  • <xref> elements (Section 2.66)

2.53. <t> โœจ

Contains a paragraph of text. ๐Ÿ’–

This element shows up as a child 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:

  • 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)
  • <list> elements (Section 3.4)
  • <relref> elements (Section 2.44)
  • <spanx> elements (Section 3.7)
  • <strong> elements (Section 2.50)
  • <sub> elements (Section 2.51)
  • <sup> elements (Section 2.52)
  • <tt> elements (Section 2.62)
  • <vspace> elements (Section 3.10)
  • <xref> elements (Section 2.66)

2.53.1. "anchor" Attribute ๐Ÿฆ‹

Document-wide unique identifier for this paragraph. Every paragraph gets its own name tag, bestie. ๐Ÿท๏ธ

2.53.2. "hangText" Attribute ๐Ÿ™ˆ

Deprecated. Instead, use <dd> inside of a definition list (<dl>). So don't use this one anymore, okay?

2.53.3. "keepWithNext" Attribute ๐ŸŒธ

This is a hint for the output formatters that handle pagination. They'll make a best-effort try to keep the paragraph on the same page as the next element, whatever that happens to be. ๐Ÿ“„ For example, the HTML output @media print CSS ("CSS" refers to Cascading Style Sheets) might turn this into page-break-after: avoid. For PDF, the paginator could try to keep the paragraph with the next element. Note: this attribute is strictly a hint and not always actionable. It's a suggestion, not a promise, so don't get too attached to it. ๐Ÿ˜ญ

Allowed values:

  • "false" (default)
  • "true"

2.53.4. "keepWithPrevious" Attribute ๐Ÿงš

This is a hint for the output formatters that handle pagination, too. They'll make a best-effort try to keep the paragraph with the previous element, whatever that happens to be. For example, the HTML output @media print CSS might turn this into page-break-before: avoid. For PDF, the paginator could try to keep the paragraph with the previous element. Note: this attribute is strictly a hint and not always actionable. Same energy as the last one: it's a hint, not a rule. ๐Ÿ’…

Allowed values:

  • "false" (default)
  • "true"

2.54. <table> ๐Ÿ“

Contains a table with a caption that has the table number. If the element contains a <name> element, the caption will also show that name. Iconic. ๐Ÿ“Š

Inside the <table> element there is, optionally, a <thead> element to hold the rows that will be the table's heading, and, optionally, a <tfoot> element to hold the rows of the table's footer. If the XML gets converted to something with page breaks (like PDFs or printed HTML), the header and footer are meant to show up on each page. ๐Ÿ“‘โœจ

This element shows up as a child 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. One name per table, no copycats! ๐Ÿ’œ

2.55. <tbody> ๐ŸŒˆ

A container for a set of body rows for a table. The main body of the table, it's giving substance. ๐Ÿซถ

This element shows up as a child 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 shows up as a child 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)
  • 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. Heads up, though: "center" or "right" will probably only work well in cells with plain text. Anything else might make the contents render badly. ๐Ÿ™ˆ

Allowed values:

  • "left" (default)
  • "center"
  • "right"

2.56.2. "anchor" Attribute ๐Ÿฆ‹

Document-wide unique identifier for the cell.

2.56.3. "colspan" Attribute ๐Ÿ’–

The number of columns that the cell is to span. For example, setting colspan='3' means the cell takes up the same horizontal space as three cells in a row that don't have any colspan attributes. Main character width. ๐Ÿ‘‘

2.56.4. "rowspan" Attribute ๐ŸŽ€

The number of rows that the cell is to span. For example, setting rowspan='3' means the cell takes up the same vertical space as three rows. Tall and iconic. ๐Ÿงš

2.57. <tfoot> ๐Ÿซถ

A container for a set of footer rows for a table. The closing act. ๐ŸŽฌ

This element shows up as a child 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 it gets rendered, it normally comes out in boldface. Other than that, there is no difference between this and the <td> element. Basically <td> with a bold moment. ๐Ÿ’…

This element shows up as a child 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)
  • 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. Same tea as before, bestie. โ˜•

Allowed values:

  • "left" (default)
  • "center"
  • "right"

2.58.2. "anchor" Attribute ๐Ÿฆ‹

Document-wide unique identifier for the row. (Yes, the spec really says "row" here, even though it's the cell section. Sus, but we respect it. ๐Ÿคทโ€โ™€๏ธ)

2.58.3. "colspan" Attribute ๐Ÿ’–

The number of columns that the cell is to span. For example, setting colspan='3' means the cell takes up the same horizontal space as three cells in a row that don't have any colspan attributes. ๐Ÿ‘‘

2.58.4. "rowspan" Attribute ๐ŸŽ€

The number of rows that the cell is to span. For example, setting rowspan='3' means the cell takes up the same vertical space as three rows. ๐Ÿงš

2.59. <thead> ๐ŸŒธ

A container for a set of header rows for a table. The intro era. ๐ŸŽ€

This element shows up as a child 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.

2.60. <title> ๐Ÿ“œ

Represents the document title. โœจ

When this element shows up in the <front> element of the current document, the title might also appear in page headers or footers. If it's long (about 40 characters or more), the "abbrev" attribute can be used to specify a shortened version. Shorter is slay. ๐Ÿ™Œ

This element shows up as a child of <front> (Section 2.26).

Content model: only text content.

2.60.1. "abbrev" Attribute โœ‚๏ธ

Specifies an abbreviated variant of the document title. Short and sweet. ๐Ÿฌ

2.60.2. "ascii" Attribute ๐Ÿ”ค

The ASCII equivalent of the title. For when you need the plain-text version. ๐Ÿงพ

2.61. <tr> ๐Ÿฆ‹

A row of a table. Lowkey the backbone of every table. ๐Ÿชœ

This element shows up as a child of <tbody> (Section 2.55), <tfoot> (Section 2.57), and <thead> (Section 2.59).

Content model:

In any order, but at least one of:

  • <td> elements (Section 2.56)
  • <th> elements (Section 2.58)

2.61.1. "anchor" Attribute ๐Ÿฆ‹

Document-wide unique identifier for the row.

2.62. <tt> ๐Ÿ’ป

Causes the text to show up in a constant-width font. This element can be combined with other character formatting elements, and the formatting will stack up additively. Stacking styles is so iconic. ๐Ÿฅžโœจ

This element shows up as a child 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:

  • 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)
  • <xref> elements (Section 2.66)

2.63. <ul> ๐ŸŽ€

An unordered list. The labels on the items are symbols picked by the formatter, so the bullets are a surprise. ๐ŸŽ

This element shows up as a child 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" means that no label will be shown. Minimalist era. ๐Ÿค

Allowed values:

  • "false" (default)
  • "true"

2.63.3. "spacing" Attribute ๐Ÿ“

Defines whether or not there is a blank line between entries. spacing="normal" means a single blank line, while spacing="compact" means no space between. Choose your vibe. ๐ŸŒŠ

Allowed values:

  • "normal" (default)
  • "compact"

2.64. <uri> ๐Ÿ”—

Contains a web address associated with the author. ๐ŸŒ

The contents should be a valid URI. This will most likely be an "http:" or "https:" URI. ๐Ÿ”’

This element shows up as a child 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) that the document comes from, if there is one. The recommended format is the official name of the Working Group, with some capitalization. Official name, big energy. ๐Ÿ’ผ

In Internet-Drafts, this goes in the upper left corner of the boilerplate, where it replaces the "Network Working Group" string. Formatting software can add the words "Working Group" or "Research Group" on the end, depending on the "submissionType" property of the <rfc> element (Section 2.45.12). ๐Ÿ“โœจ

This element shows up as a child of <front> (Section 2.26).

Content model: only text content.

2.66. <xref> ๐Ÿฆ‹

Okay bestie, <xref> is basically a reference to an anchor somewhere in this document ๐Ÿ”— Formatters that have links (like HTML and PDF) are likely to turn <xref> elements into internal hyperlinks โœจ It's giving "jump right to that part" energy. It's super useful for pointing at things in the "References" section, specific sections of this doc, 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.

2.66.1. "format" Attribute

This attribute tells 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 ๐Ÿ’€

"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:

  • "default" (default)
  • "title"
  • "counter"
  • "none"

2.66.2. "pageno" Attribute

Deprecated ๐Ÿ˜ญ

Allowed values:

  • "true"
  • "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 โš ๏ธ


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:

  • 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)
  • <spanx> elements (Section 3.7)
  • <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)

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.

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.

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:

  • 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)
  • <spanx> elements (Section 3.7)
  • <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)

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:

  • 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)
  • <spanx> elements (Section 3.7)
  • <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)

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.

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:

  • "default"
  • "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:

  • "left"
  • "center" (default)
  • "right"

3.8.2. "anchor" Attribute

Deprecated.

3.8.3. "style" Attribute

Deprecated.

3.8.4. "suppress-title" Attribute

Deprecated.

Allowed values:

  • "true"
  • "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:

  • Text
  • <cref> elements (Section 2.16)
  • <eref> elements (Section 2.24)
  • <iref> elements (Section 2.27)
  • <xref> elements (Section 2.66)

3.9.1. "align" Attribute

Deprecated.

Allowed values:

  • "left" (default)
  • "center"
  • "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" ๐ŸŒˆ

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 ๐Ÿ”’โœจ

okay bestie, this part is serious but make it make sense ๐Ÿ’… 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 info without pre-processing is a known security risk, so see Section 4.3 of [RFC6266] for more tea ๐Ÿต

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. ๐Ÿšจ no cap, this one is a big deal ๐Ÿ˜ญ

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 they could further process the extracted content, like rendering artwork or executing code. Doing that 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. Sandbox it, bestie ๐Ÿงš

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

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)

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

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

Okay bestie, these are the extra reads the document points to ๐Ÿ“š Not the core rules, but still worth knowing about ๐Ÿ’…


Appendix A. Front-Page ("Boilerplate") Generation โœจ

The RFC Series Editor is the one who defines these values ๐Ÿ‘‘ The ones listed below are the ones 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 aren't the result of a grand design, they just stick around for historic reasons ๐Ÿ™ˆ Only a few of them are actually in use right now. The rest are supported by various tools so older source files still work ๐Ÿ”ฅ

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) decides whether a statement about "Code Components" gets inserted. That's 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 just 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. ๐Ÿงš

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. ๐Ÿซถ

A.1.1.4. pre5378Trust200902

okay so this one is the pre-5378 escape clause ๐Ÿ’… It produces the extra text from Section 6.c.iii of the TLP. People call it that because of the changes that [RFC5378] brought in ๐ŸŒธ

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.

For more info on when to actually use this value, check out Section 4 of the IETF Copyright FAQ ๐Ÿฆ‹ The link is:

<http://trustee.ietf.org/docs/
IETF-Copyright-FAQ.pdf>
Note: this text shows up under "Copyright Notice", unless the document was published before November 2009. If it was, the text shows up under "Status of This Memo" instead ๐Ÿ™ˆ

A.1.2. Historic Values

A.1.2.1. Historic Values: "*trust200811"

The values "trust200811", "noModificationTrust200811", and "noDerivativesTrust200811" are basically the same vibe as their "trust200902" cousins. The one difference is that they use the text from [TLP1.0] ๐ŸŽ€

A.1.2.2. Historic Values: "*3978"

The values "full3978", "noModification3978", and "noDerivatives3978" are like their counterparts above. They just use the text from [RFC3978] โœจ

A.1.2.3. Historic Values: "*3667"

The values "full3667", "noModification3667", and "noDerivatives3667" are like their counterparts above too. They use the text from [RFC3667] ๐ŸŒˆ

A.1.2.4. Historic Values: "*2026"

The values "full2026" and "noDerivativeWorks2026" match their counterparts above, except they use the text in Section 10 of [RFC2026] ๐Ÿงš

Back then there was also a special value called "none". It meant the IETF got no rights beyond publishing as an Internet-Draft ๐Ÿ˜ญ

A.2. The "submissionType" Attribute

The RFC Editor publishes documents from different "document streams" ๐ŸŒธ The "IETF stream" is the biggest one, but there are others. The "Independent Submissions stream" is for things like discussing Internet-related technologies that aren't on the IETF agenda. Then there's the "IAB stream" (Internet Architecture Board) and the "IRTF stream" (Internet Research Task Force) ๐Ÿ’œ

The values for this attribute are "IETF" (the default), "independent", "IAB", and "IRTF" ๐Ÿซถ

Historically, this attribute didn't change how RFCs looked, except for tiny differences in the copyright notices. These days (as of [RFC7841]), the stream name shows up in the first line of the front page, and it also changes the text in the "Status of This Memo" section ๐Ÿ‘‘

For current documents, setting the "submissionType" attribute does a few things:

  • For RFCs, the stream name shows up in the upper left corner of the first page. In Internet-Drafts it's either "Network Working Group" or whatever the value of the <workgroup> element is ๐Ÿ“
  • For RFCs, it affects the whole "Status of This Memo" section (see Section 3.2 of [RFC7841]) ๐Ÿ’…
  • For all RFCs and Internet-Drafts, it decides whether the "Copyright Notice" mentions the Copyright on Code Components (see Section 6 of the TLP ("Text to Be Included in IETF Documents")) โœจ

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 is how you supply that info. The acceptable values are "true" (the default) and "false". "yes" and "no" from v2 are deprecated ๐Ÿ™ˆ

Here's what the value does for each stream:

  • "independent": nothing ๐ŸŒ™
  • "IAB": mentions that there was an IAB consensus ๐Ÿ’œ
  • "IETF": mentions that there was an IETF consensus ๐ŸŽ€
  • "IRTF": mentions that there was a research group consensus. The name of the research group gets pulled from the <workgroup> element ๐Ÿฆ‹

Appendix B. The v3 Format and Processing Tools

This section is all about topics specific to v3 processing tools. Heads up, there's also some tool talk in the main body of the document. For example, some elements describe how a processing tool might create output from that element ๐Ÿงš

Here's the design the tools for v3 documents are expected to have:

  • A "prep tool" that takes a v3 document, makes lots of checks, adds and changes lots of 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 the RFC Editor uses to process 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, plus 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 the Internet-Draft submission tool uses. The restrictions on the XML from this mode will be described later ๐ŸŒธ
  • Diagnostic mode: a mode authors can use to look for errors or warnings before they submit their documents for publication ๐Ÿ”
  • Consolidation mode: makes output where no external resources are needed to render the file. This includes expanding the XInclude entities and DTD entities in place, and changing every element with "src" attributes that point to external links into either a "data:" URI or the content for the element, as specified in [RFC7998] ๐ŸŒˆ
  • Formatting tools that create HTML, PDF, plain text, and maybe other output formats. The IETF will create these formatters, but others can make tools like them too. The IETF tools are expected to take prepared documents as input ๐Ÿ’œ

There may also be processing tools meant to run on authors' computers. These tools can be used to make interim versions of the non-canonical representations, so authors can preview how their XML might later be rendered. They can also create documents in representations the RFC Editor doesn't support, create documents that aren't meant to be Internet-Drafts or RFCs, and convert XML that has external information into XML that has that information included ๐Ÿซถ

The prep tool is expected to have clear error reporting, with more context than just a line number. For example, the error messages should tell apart errors in the XML from errors in the v3 format โœจ

In v2, the grammar was specified as a DTD. In v3, the grammar is specified only as RELAX Next Generation (RNG). That means tools need to work from the RNG, not from a DTD. Some features of the v3 grammar can't 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 gives you a processing model and syntax for general-purpose inclusion of information, whether that info is on the Internet or local to the user's computer ๐ŸŒธ

In the v3 syntax, XInclude is written as the <xi:include> element. To use it, you need the "xi" namespace in the <rfc> element. In other words, you need to specify this as one of the attributes on <rfc>:

xmlns:xi="http://www.w3.org/2001/XInclude"

The most common use of <xi:include> is pulling in references that are already formed as XML. Right now you can do this from xml2rfc.tools.ietf.org, but later it's expected to come from the RFC Editor ๐Ÿฆ‹ For example, if a document has three normative references, all of them 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>

<xi:include> can go anywhere an XML element could go (but not where free text is used). For example, if three Internet-Drafts all include a particular paragraph or section verbatim, that text can live in a file or somewhere on the web and be pulled in 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 point at specific spots in those documents ๐ŸŽ€ Authors often want to reference another part of their own document, like "see Section 3.2 of this document." Readers, on the other hand, want to reference parts of documents they didn't write, like "see Section 3.2 of RFC 6949." The XML vocabulary in this document tries to support both groups ๐Ÿ’–

Authors can leave anchors in a document, and use them later for references with the "anchor" attribute. Anchors can go on lots of elements. The author then refers 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. Heads up, though: most of the time, elements won't have anchors. In the common case, the reader wants to refer to an element that doesn't have an "anchor" attribute, but does have a "pn" attribute ๐Ÿ™ˆ

Processing tools add the "pn" attribute to lots of elements during processing. The tool generates this attribute and its value automatically if it isn't there. If the attribute is already there, the tool may replace the value ๐Ÿซถ

B.2.1. Overlapping Values โœจ

okay so bestie, in the HTML version of this vocab, both anchors AND "pn" attributes end up in id attributes ๐Ÿ˜ญ which means there can be NO overlap between the names in "anchor" attributes, in "slugifiedName" attributes, and the ones generated for "pn" attributes. ๐Ÿซถ Also some "anchor" values are reserved for sections, and those sections can ONLY use those anchor values. Main character rules, fr fr.

Here's how the rules keep everything from clashing ๐Ÿ’…

  • "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. ๐ŸŽ€
  • "pn" for <references> elements has the format s-nnn. This one is lowkey tricky ๐Ÿ™ˆ nnn is a NUMBER, not letters, even though the <references> show up in the back. It's the number 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 numbered one higher than the highest top-level section number in <middle>. ๐Ÿงš
  • "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. ๐ŸŒธ
  • "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'>. ๐Ÿฆ‹
  • "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. ๐Ÿ’–
  • "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. โœจ
  • "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. ๐ŸŒˆ
  • Anchors must never overlap with any of the above. The easiest way to make sure of 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. ๐Ÿ’€
Don't be the person whose anchor starts with x- and then wonders why the whole doc got rejected ๐Ÿ˜ญ

B.3. Attributes Controlled by the Prep Tool

Okay so a bunch of elements in the v3 vocab have new attributes whose whole job is holding values the prep tool generates ๐Ÿ“ These attributes CAN show up in documents you feed into the prep tool, BUT the prep tool might add, remove, or change any of them. ๐Ÿซ  So it's explicitly unsafe for an author to include these attributes and expect their values to survive prep processing. Don't be that girl ๐Ÿ™…โ€โ™€๏ธ

The attributes controlled by the prep tool are:

  • The "pn" attribute in any element. This is 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. ๐Ÿ”ข
  • <artwork> originalSrc. This attribute is filled with the original value of the "src" attribute if that attribute is removed by the prep tool. ๐ŸŽจ
  • <figure> originalSrc. This attribute is filled with the original value of the "src" attribute if that attribute is removed by the prep tool. ๐Ÿ–ผ๏ธ
  • <name> "slugifiedName" attribute. This attribute is filled with a "slugified" version of the text in the element. It can be used in the output formats for elements that have both names and numbers. ๐Ÿท๏ธ
  • <relref> "derivedLink" attribute. This attribute is filled with the link derived from combining the URI from the reference and the relative part, which is either a copy of the "relative" attribute or a section number derived from the "section" attribute. ๐Ÿ”—
  • <rfc> "expiresDate" attribute. This attribute is filled with the date that an Internet-Draft expires. The date is in the format yyyy-mm-dd. ๐Ÿ“…
  • <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. ๐Ÿง
  • <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, and 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". ๐Ÿ€„
  • <sourcecode> "originalSrc" attribute. This attribute is filled with the original value of the "src" attribute if that attribute is removed by the prep tool. ๐Ÿ’ป
  • <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. ๐ŸŽฏ

And one more thing ๐Ÿ‘€ the contents of the <boilerplate> element are controlled by the prep tool too. Hands off, bestie ๐Ÿคš

Appendix C. RELAX NG Schema ๐Ÿฆ‹

The following is the RELAX NG schema for the v3 format. Schema time, and yes it's giving very structured ๐Ÿค“

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?
  }

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?
  }

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
  }

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
  }

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
  }

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)+
  }

Okay bestie, this is the schema zone ๐ŸŽ€ Every element and attribute is copied exactly, so the parser stays happy ๐Ÿ’…

   boilerplate =
     element boilerplate {
       attribute xml:base { text }?,
       attribute xml:lang { text }?,
       section+
     }

   middle =
     element middle {
       attribute xml:base { text }?,
       attribute xml:lang { text }?,
       section+
     }

   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)*
     }

   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)*
     }

   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+
     }

   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)+
     }

   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)+)
     }

   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
     }

   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)*
     }

   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)*
     }

   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?
     }

   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)*
     }

   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+
     }

   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)*)
     }

   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)*
     }

   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
     }

   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)*
     }

   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
     }

   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

Okay, the schema is all laid out, and it's time to look at the bits that changed from v2 to v3 ๐ŸŽ€โœจ This next part is a non-normative comparison (so it's just a helpful guide, not a rule ๐Ÿ’…). Lines starting with a "-" got removed from the v2 schema, and lines starting with a "+" got added in v3. Everything else stayed the same ๐ŸŒธ

Appendix D. Schema Differences from v2 โœจ

     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"
   -     }?,
   +     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?
       }

   + 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?
       }

Okay bestie, the schema glow-up keeps going ๐Ÿ’– Here's the diff: + is what got added and - is what got cut ๐ŸŽ€

     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
   +   }
   + 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
   +   }
   + 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
   +   }
   + 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+
       }

   - 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*
       }

   + 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)*
   +   }
   + 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+
   +   }
   + 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)+
   +   }
   + 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)+)
   +   }

     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
       }

That's the whole diff chunk ๐ŸŒธ more parts are coming, so stay tuned โœจ

okay this schema diff is literally a whole glow-up ๐Ÿ’…โœจ here's the rest of the tea:

     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)*
   +   }
   + 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)*
       }

     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?
       }

   + 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)*
   +   }

     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+
   +   }
   + 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)*)
   +   }
   + 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)*
     }
     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
   +   }
   + 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)*
   +   }
   + 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
       }

     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

IAB Members at the Time of Approval โœจ

okay so bestie, here's who was on the IAB when this memo got approved ๐Ÿงš they're listed in alphabetical order, so no drama, just vibes:

  • 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 ๐Ÿซถ

ngl this part is so sweet ๐Ÿฅน thank you to literally everyone who looked over this document and gave feedback and/or wrote spec text. a huge shoutout goes to Julian Reschke for editing [RFC7749] ๐Ÿ‘‘ and to everyone who gave feedback on that one too, because that's a whole team effort, periodt ๐Ÿ’…

we also have to thank Marshall T. Rose for both the original design and the reference implementation of the xml2rfc processor ๐ŸŽ€ the whole RFC world runs on that tool, so he's an absolute icon ๐ŸŒˆ

Author's Address ๐Ÿฆ‹

this is where you can find the author! ๐Ÿ’– Paul Hoffman, over at ICANN โœจ

Email: paul.hoffman@icann.org ๐Ÿ’Œ

๐Ÿ“ฆ where this page comes from