RFC 7749

The "xml2rfc" Version 2 Vocabulary 💖

• Number: RFC 7749
• Title: The "xml2rfc" Version 2 Vocabulary
• Author: J. Reschke (greenbytes)
• Published by: Internet Architecture Board (IAB)
• Date: February 2016
• Category: Informational
• ISSN: 2070-1721
• Obsoletes: RFC 2629

---

Abstract ✨

okay so this doc defines the "xml2rfc" version 2 vocabulary 🎀 that's an XML-based language people use to write RFCs and Internet-Drafts. v2 is a snapshot of where the vocabulary was around 2014, as built into several tools and used by the RFC Editor 💅

and it obsoletes RFC 2629, so that one's officially retired 🫶

Status of This Memo 🌸

this one is not a Standards Track spec, it's just published for info 📖

it's an IAB product and it's basically information the IAB thinks is worth keeping on the record forever. it represents the IAB's consensus, but documents the IAB approves for publication are never a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🧚

you can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7749 💌

Copyright Notice 💜

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, bestie, they spell out your rights and restrictions for this document 🙈

Table of Contents 🍓

1. Introduction ....................................................4
   1.1. Syntax Notation ............................................4
2. Elements ........................................................5
   2.1. <abstract> .................................................5
   2.2. <address> ..................................................5
   2.3. <annotation> ...............................................6
   2.4. <area> .....................................................6
   2.5. <artwork> ..................................................7
   2.6. <author> ..................................................10
   2.7. <back> ....................................................11
   2.8. <c> .......................................................12
   2.9. <city> ....................................................12
   2.10. <code> ...................................................12
   2.11. <country> ................................................12
   2.12. <cref> ...................................................13
   2.13. <date> ...................................................14
   2.14. <email> ..................................................15
   2.15. <eref> ...................................................15
   2.16. <facsimile> ..............................................16
   2.17. <figure> .................................................16
   2.18. <format> .................................................18
   2.19. <front> ..................................................19
   2.20. <iref> ...................................................20
   2.21. <keyword> ................................................21
   2.22. <list> ...................................................21
   2.23. <middle> .................................................23
   2.24. <note> ...................................................24
   2.25. <organization> ...........................................24
   2.26. <phone> ..................................................24
   2.27. <postal> .................................................25
   2.28. <postamble> ..............................................25
   2.29. <preamble> ...............................................26
   2.30. <reference> ..............................................26
   2.31. <references> .............................................27
   2.32. <region> .................................................28
   2.33. <rfc> ....................................................28
   2.34. <section> ................................................32
   2.35. <seriesInfo> .............................................33
   2.36. <spanx> ..................................................34
   2.37. <street> .................................................35
   2.38. <t> ......................................................35
   2.39. <texttable> ..............................................36
   2.40. <title> ..................................................38
   2.41. <ttcol> ..................................................38
   2.42. <uri> ....................................................39
   2.43. <vspace> .................................................39
   2.44. <workgroup> ..............................................39
   2.45. <xref> ...................................................40
3. Escaping for Use in XML ........................................42
4. Special Unicode Code Points ....................................42
5. Including Files ................................................43
6. Internationalization Considerations ............................44
7. Security Considerations ........................................44
8. IANA Considerations ............................................44
   8.1. Internet Media Type Registration ..........................44
9. References .....................................................46
   9.1. Normative References ......................................46
   9.2. Informative References ....................................46
Appendix A. Front-Page ("Boilerplate") Generation .................50
  A.1. The "category" Attribute ...................................50
  A.2. The "ipr" Attribute ........................................50
    A.2.1. Current Values: "*trust200902" .........................51
    A.2.2. Historic Values ........................................52
  A.3. The "submissionType" Attribute .............................54
  A.4. The "consensus" Attribute ..................................55
Appendix B. Changes from RFC 2629 ("v1") ..........................56
  B.1. Removed Elements ...........................................56
  B.2. Changed Defaults ...........................................56
  B.3. Changed Elements ...........................................57
  B.4. New Elements ...............................................57
Appendix C. RELAX NG Schema .......................................58
  C.1. Checking Validity ..........................................65
IAB Members at the Time of Approval ...............................66
Acknowledgments ...................................................66
Index .............................................................67
Author's Address ..................................................76

---

1. Introduction ✨

this doc describes version 2 ("v2") of the "xml2rfc" vocabulary 🦋 which is an XML-based language ("Extensible Markup Language" [XML]) used for writing RFCs [RFC7322] and Internet-Drafts [IDGUIDE].

again, v2 is the state of the vocabulary as implemented by several tools and as used by the RFC Editor around 2014 💅

it obsoletes the original v1 [RFC2629], the one with the original language definition that got extended later on. a lot of the v2 changes were described in "Writing I-Ds and RFCs using XML (revised)" [V1rev], but that doc hasn't been updated since 2008, so the timeline's kinda old 🙈

Processing Instructions (Section 2.6 of [XML]) are generally specific to a given processor, so they're NOT counted as part of the vocabulary 🌸 if you want the list of Processing Instructions the first xml2rfc processor supported, check Section 4.1 of [TCLReadme] 🧚

also, the vocabulary has some constructs that might not show up in the final text, but they still give useful data for other stuff, like index generation, filling a keyword database, or syntax checks 🔥

1.1. Syntax Notation 💖

the XML vocabulary is defined in prose, based on the RELAX NG schema [RNC] in Appendix C (written in RELAX NG Compact Notation (RNC)) 📖

the schema can be used for automated validity checks, but some constraints are only described in prose. example: the conditionally required presence of the "abbrev" attribute 🫶

2. Elements 🎀

the sections below cover every element and its attributes 💅

attributes that aren't labeled "mandatory" are optional, so don't panic if you see one without that label 🌈

except inside <artwork>, horizontal whitespace and line breaks get collapsed into a single whitespace, and leading and trailing whitespace gets trimmed off ✨

2.1. <abstract> 🌸

contains the Abstract of the document 📝 the Abstract ought to be self-contained, so it shouldn't have references or unexpanded abbreviations in it. see Section 4.3 of [RFC7322] for more info 💜

this element shows up as a child of <front> (Section 2.19) 🧚

content model: one or more <t> elements (Section 2.38) 🍓

2.2. <address> 🦋

provides address info for the author 💌

this element shows up as a child of <author> (Section 2.6) 🎀

content model, in this order:

1. one optional <postal> element (Section 2.27)
2. one optional <phone> element (Section 2.26)
3. one optional <facsimile> element (Section 2.16)
4. one optional <email> element (Section 2.14)
5. one optional <uri> element (Section 2.42)

2.3. <annotation> 🌈

provides extra prose that adds to a bibliographical reference 📚

this element shows up as a child of <reference> (Section 2.30) ✨

content model, in any order:

• text
• <xref> elements (Section 2.45)
• <eref> elements (Section 2.15)
• <iref> elements (Section 2.20)
• <cref> elements (Section 2.12)
• <spanx> elements (Section 2.36)

2.4. <area> 🧚

provides info about the IETF area this document relates to 🌷 (heads up, it's currently not used when generating documents)

the value ought to be either the full name or the abbreviation of one of the IETF areas listed at https://www.ietf.org/iesg/area.html 🗺️ at the time this doc was published, those were "Applications and Real-Time" ("art"), "General" ("gen"), "Internet" ("int"), "Operations and Management" ("ops"), "Routing" ("rtg"), "Security" ("sec"), and "Transport" ("tsv") 💜

the set of IETF areas can change over time, though 👀 for example, "Applications and Real-Time" ("art") replaced "Applications" ("app") and "Real-time Applications and Infrastructure" ("rai") in 2015 🔥

this element shows up as a child of <front> (Section 2.19) 🎀

content model: text content only 💅

2.5. <artwork> ✨

This one is the boss of the vocab 👑 <artwork> is the ONLY element that gives you full control over horizontal whitespace and line breaks, so it's the go-to for basically anything that needs to look exactly the way you typed it. Bestie, it's used for things like:

• diagrams ("line art"),
• source code,
• formal languages (such as ABNF [RFC5234] or the RNC notation used in this document),
• message flow diagrams,
• complex tables, or
• protocol unit diagrams.

Heads up 🚨 processors handle horizontal TAB characters differently (some expand them, some treat them as single spaces), so these ought to be avoided. Nobody wants a diagram that falls apart because of a sneaky tab 💀

Alternatively, the "src" attribute lets you reference an external graphics file, like a bitmap or a vector drawing, using a URI ("Uniform Resource Identifier") [RFC3986] 🦋 In that case, the textual content acts as a fallback for output formats that can't do graphics, so it ought to contain either (1) a "line art" variant of the graphics or (2) prose that describes the included image in enough detail. Also, RFCs occasionally get published with enhanced diagrams, and [RFC5598] is a recent example of an RFC that was published along with a PDF with images 🌈

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

Content model:

• Text

2.5.1. "align" Attribute

Controls whether the artwork appears left justified (default), centered, or right justified. 💖

Allowed values:

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

2.5.2. "alt" Attribute

Alternative text description of the artwork (not just the caption). 🎀

2.5.3. "height" Attribute

The suggested height of the graphics (when it was included using the "src" attribute).

This attribute is format dependent and ought to be avoided. 🙈

When generating HTML output [HTML], current implementations copy the attribute "as is", thus effectively treating it as CSS (Cascading Style Sheets) pixels (see Section 4.3.2 of [CSS]). For other output formats, it is usually ignored.

2.5.4. "name" Attribute

A filename suitable for the contents (such as for extraction to a local file). 📁

This attribute generally isn't used for document generation, but it can be helpful for other kinds of tools (such as automated syntax checkers, which work by extracting the source code). 🧚

2.5.5. "src" Attribute

The URI reference of a graphics file (Section 4.1 of [RFC3986]).

Note that this can be a "data" URI [RFC2397] as well, in which case the graphics file is wholly part of the XML file. 🍓

2.5.6. "type" Attribute

Specifies the type of the artwork. ✨

The value is either an Internet Media Type (see [RFC2046]) or a keyword (such as "abnf"). The set of recognized keywords varies across implementations.

How it's used depends on context and application. For instance, a formatter can attempt to syntax-highlight code in certain known languages. 🌸

2.5.7. "width" Attribute

The suggested width of the graphics (when it was included using the "src" attribute).

This attribute is format dependent and ought to be avoided. 🙈

When generating HTML output [HTML], current implementations copy the attribute "as is", thus effectively treating it as CSS pixels (see Section 4.3.2 of [CSS]). For other output formats, it is usually ignored.

2.5.8. "xml:space" Attribute

Determines whitespace handling. 🧠

"preserve" is both the default value and the only meaningful setting (because that's what the <artwork> element is for) 💅

See also Section 2.10 of [XML].

Allowed values:

• "default"
• "preserve" (default)

2.6. <author>

Provides information about a document's author. This is used both for the document itself (at the beginning of the document) and for referenced documents (inside of <reference>). 🫶

The <author> elements contained within the document's <front> element are used to fill the boilerplate, and also to generate the "Author's Address" section (see Section 4.12 of [RFC7322]).

Note that an "author" can also be just an organization (by not specifying any of the name attributes, but adding the <organization> child element). 🏢

Furthermore, the "role" attribute can be used to mark an author as "editor". This is reflected on the front page and in the "Author's Address" section, as well as in bibliographical references. Note that this specification does not define a precise meaning for the term "editor". 🤷‍♀️

See Sections 4.10 and 4.11 of [RFC7322] for more information.

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

Content model:

In this order:

1. One optional <organization> element (Section 2.25)
2. One optional <address> element (Section 2.2)

2.6.1. "fullname" Attribute

The full name (used in the automatically generated "Author's Address" section). 💜

2.6.2. "initials" Attribute

An abbreviated variant of the given name(s), to be used in conjunction with the separately specified surname. It usually appears on the front page, in footers, and in references. 🦋

Some processors will post-process the value -- for instance, when it only contains a single letter (in which case they might add a trailing dot). Relying on this kind of post-processing can lead to results varying across formatters and thus ought to be avoided. 😬

2.6.3. "role" Attribute

Specifies the role the author had in creating the document.

Allowed values:

• "editor"

2.6.4. "surname" Attribute

The author's surname, to be used in conjunction with the separately specified initials. It usually appears on the front page, in footers, and in references. 🎀

2.7. <back>

Contains the "back" part of the document: the references and appendices. In <back>, <section> elements indicate appendices. 📚

This element appears as a child element of <rfc> (Section 2.33).

Content model:

In this order:

1. Optional <references> elements (Section 2.31)
2. Optional <section> elements (Section 2.34)

2.8. <c>

Provides the content of a cell in a table. 🌷

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

Content model:

In any order:

• Text
• <xref> elements (Section 2.45)
• <eref> elements (Section 2.15)
• <iref> elements (Section 2.20)
• <cref> elements (Section 2.12)
• <spanx> elements (Section 2.36)

2.9. <city>

Gives the city name in a postal address. 🏙️

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

Content model: only text content.

2.10. <code>

Gives the postal region code. 📮

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

Content model: only text content.

2.11. <country>

Gives the country in a postal address. 🌍

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

Content model: only text content.

2.12. <cref>

Represents a comment. 💬

Comments can be used in a document while it is a work in progress. They usually appear (1) inline and visually highlighted, (2) at the end of the document (depending on file format and settings of the formatter), or (3) not at all (when generating an RFC).

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

Content model: only text content.

2.12.1. "anchor" Attribute

Document-wide unique identifier for this comment. The processor will autogenerate an identifier when none is given. 🔖

The value needs to be a valid XML "Name" (Section 2.3 of [XML]), additionally constrained to US-ASCII characters [USASCII].

2.12.2. "source" Attribute

Holds the "source" of a comment, such as the name or the initials of the person who made the comment. 🗣️

2.13. <date>

Provides information about the publication date. 📅

Note that this element is used for the boilerplate of the document being produced, and also inside bibliographic references.

In the "boilerplate" case, it defines the publication date, which, when producing Internet-Drafts, will be used for computing the expiration date (see Section 8 of [IDGUIDE]). When one or more of "year", "month", or "day" are left out, the processor will attempt to use the current system date if the attributes that are present are consistent with that date.

Note that in this case, month names need to match the full (English) month name ("January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", or "December") in order for expiration calculations to work (some implementations might support additional formats, though). 🗓️

In the case of bibliographic references, the date information can have prose text for the month or year. For example, vague dates (year="ca. 2000"), date ranges (year="2012-2013"), non-specific months (month="Second quarter") and so on are allowed. ✨

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

Content model: this element does not have any contents.

2.13.1. "day" Attribute

In the "boilerplate" case, the day of publication; this is a number. Otherwise, an indication of the publication day, with the format not being restricted. 🌞

2.13.2. "month" Attribute

In the "boilerplate" case, the month of publication; this is the English name of the month. Otherwise, an indication of the publication month, with the format not being restricted. 🌙

2.13.3. "year" Attribute

In the "boilerplate" case, the year of publication; this is a number (usually four-digit). Otherwise, an indication of the publication year, with the format not being restricted. 🎉

2.14. <email>

Provides an email address. 💌

The value is expected to be an email address conforming to the addr-spec definition in Section 2 of [RFC6068] (so does not include the prefix "mailto:").

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

Content model: only text content.

2.15. <eref>

Represents an "external" link (as specified in the "target" attribute). 🔗

If the element has no text content, the value of the "target" attribute will be inserted in angle brackets (as described in Appendix C of [RFC3986]) and, depending on the capabilities of the output format, hyperlinked.

Otherwise, the text content will be used (and potentially hyperlinked). Depending on output format and formatter, additional text might be inserted (such as a "URI" counter, and a "URIs" section in the back of the document). Avoid this variant when consistent rendering across formats and formatters is desired. 🧐

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

Content model: only text content.

2.15.1. "target" Attribute (Mandatory)

URI of the link target (see Section 3 of [RFC3986]). 🎯

2.16. <facsimile>

Represents the phone number of a fax machine. 📠

The value is expected to be the scheme-specific part of a "tel" URI (so does not include the prefix "tel:"), using the "global numbers" syntax. See Section 3 of [RFC3966] for details.

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

Content model: only text content.

2.17. <figure> 🎀

okay so <figure> is giving "frame for your artwork" 🖼️✨ It holds an optional preamble (the text up top), the actual figure, an optional postamble (the text underneath), and an optional title. bestie this is so clean 💖

This element shows up as a child of <section> (Section 2.34) and <t> (Section 2.38).

Content model:

In this order:

1. Optional <iref> elements (Section 2.20)
2. One optional <preamble> element (Section 2.29)
3. One <artwork> element (Section 2.5)
4. One optional <postamble> element (Section 2.28)

2.17.1. "align" Attribute 🌸

This one changes the alignment of <preamble> and <postamble> 💅

Note: it does NOT touch the title or the <artwork> alignment. Not your vibe for those, sorry 🙈

Allowed values:

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

2.17.2. "alt" Attribute 🙅‍♀️

This duplicates what <artwork> already does, so just avoid it, periodt 💀

2.17.3. "anchor" Attribute 🦋

This is the document-wide unique ID for the figure. Slay 👑

Having this attribute also means the figure gets numbered 🔢

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

2.17.4. "height" Attribute 🙄

Same deal as "alt": <artwork> already handles it, so skip it 💅

2.17.5. "src" Attribute 🙄

Also duplicates <artwork>. Avoid, iykyk 🫶

2.17.6. "suppress-title" Attribute 🤫

Okay, so figures with an "anchor" attribute automatically get a made-up title, like "Figure 1", even when there's no "title" attribute. If you don't want that, set this to "true" and it'll stop 🛑

Allowed values:

• "true"
• "false" (default)

2.17.7. "title" Attribute 📝

This is the title for the figure. It usually shows up on a line after the figure 🎀

2.17.8. "width" Attribute 🙄

Duplicates <artwork> again. Avoid it, bestie 💖

2.18. <format> 🌈

This gives you a link to an extra format variant for a reference ✨

ngl, these extra links aren't used in published RFCs, and not every tool supports them 😭 If you just want one URI for a reference, use the "target" attribute on <reference> instead 🫶

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

Content model: this element doesn't have any contents 🧚

2.18.1. "octets" Attribute 🍓

This is the octet length of the linked-to document 📏

2.18.2. "target" Attribute 🎯

This is the URI of the document 🔗

2.18.3. "type" Attribute (Mandatory) 💜

This is the type of the linked-to document, like "TXT", "HTML", or "PDF" 📄 This one is mandatory, so don't skip it 🚨

2.19. <front> 🧁

This is the "front matter" 💅 It holds metadata like author info, the Abstract, and extra notes.

This element shows up as a child of <reference> (Section 2.30) and <rfc> (Section 2.33).

Content model:

In this order:

1. One <title> element (Section 2.40)
2. One or more <author> elements (Section 2.6)
3. One <date> element (Section 2.13)
4. Optional <area> elements (Section 2.4)
5. Optional <workgroup> elements (Section 2.44)
6. Optional <keyword> elements (Section 2.21)
7. One optional <abstract> element (Section 2.1)
8. Optional <note> elements (Section 2.24)

2.20. <iref> 📚

This provides terms for the document's index 🗂️

Index entries can be regular (when you only give the "item" attribute) or nested (when you also give "subitem"), grouped under a regular entry 🌷

Like, in this document, every element definition shows up as a regular index entry ("iref element 2.20"). Then, for each time that element is used inside another parent element, there's a nested entry too ("iref element 2.20, ... inside annotation 2.3") 🤓 so cute, the organization is giving 👑

Index entries usually point to the exact spot where the <iref> happened. The exception is when it's a child of <section>. Then the whole section counts as relevant for that entry 🦋 Some formats might show these as ranges.

This element shows up as a child of <annotation> (Section 2.3), <c> (Section 2.8), <figure> (Section 2.17), <postamble> (Section 2.28), <preamble> (Section 2.29), <section> (Section 2.34), and <t> (Section 2.38).

Content model: this element doesn't have any contents 🧚

2.20.1. "item" Attribute (Mandatory) ✨

This is the item to include 📌

2.20.2. "primary" Attribute 🌟

Set this to "true" to mark the occurrence as "primary". That might get it highlighted in the index 💛

Allowed values:

• "true"
• "false" (default)

2.20.3. "subitem" Attribute 🌿

This is the subitem to include 🌱

2.21. <keyword> 🔑

This specifies a keyword that applies to the document 🗝️

Note: each element should only hold ONE keyword. If you need more, just repeat the element, bestie 💅

Keywords get used in the RFC Index and in the metadata of generated documents 📇

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

Content model: only text content 📝

2.22. <list> 📋

This marks up a text list 🌸

Each list item is a <t> element. Heads up, the vocabulary doesn't directly support list items with multiple paragraphs yet 😭 If you really need that, <vspace> (Section 2.43) can be used as a workaround 🛠️

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

Content model:

• One or more <t> elements (Section 2.38)

2.22.1. "counter" Attribute 🔢

This attribute holds a token that acts as an identifier for a counter. It's meant for continuing lists, where the counter goes up for every list item, and there's no way to reset it 🔄

Note: this attribute only works when "style" uses the "format..." syntax (Section 2.22.3). Otherwise it gets ignored 🙈

2.22.2. "hangIndent" Attribute 📐

For list styles with potentially wide labels, this lets you override the default indentation, measured in number of characters 📏

Note: it only affects styles with variable-width labels ("format..." and "hanging"; see below), and it may not affect formats where the list item text sits _below_ the label 🫠

2.22.3. "style" Attribute 🎨

This controls how the list is displayed 💖

The value gets inherited by any nested lists that don't set this attribute themselves. It can be:

"empty"

For unlabeled list items. It can also be used for indentation (this is the default when there's an enclosing list where the style is specified) 🌬️

"hanging"

For lists where the items are labeled with a piece of text. The label text is specified in the "hangText" attribute of the <t> element (Section 2.38.2) 🏷️

"letters"

For ordered lists using letters as labels (lowercase letters followed by a period). After "z", it rolls over to a two-letter format 🔤 For nested lists, processors usually flip between uppercase and lowercase 🔁

"numbers"

For ordered lists using numbers as labels 1️⃣

"symbols"

For unordered (bulleted) lists 🫧 The processor picks the bullet style automatically. Some implementations let you override the default using a Processing Instruction 🪄

And finally:

"format ..."

For lists with customized labels, made of fixed text plus an item counter in various formats 🎀 The value is free-form text that lets you insert counter values using a "percent-letter" format. For instance, "[REQ%d]" generates labels like "[REQ1]", where "%d" inserts the item number as a decimal number 🔢 These formats are supported: - %c lowercase letters (a, b, c, etc.) - %C uppercase letters (A, B, C, etc.) - %d decimal numbers (1, 2, 3, etc.) - %i lowercase Roman numerals (i, ii, iii, etc.) - %I uppercase Roman numerals (I, II, III, etc.) - %% represents a percent sign Other formats are reserved for future use 🔮

2.23. <middle> 🍰

This is the main content of the document 📖

This element shows up as a child of <rfc> (Section 2.33).

Content model:

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

2.24. <note> 🗒️

This creates an unnumbered section that shows up after the Abstract 👀

It's usually for extra info for reviewers (working group info, mailing list, ...), or extra publication info like "IESG Notes" 📬

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

Content model:

• One or more <t> elements (Section 2.38)

2.24.1. "title" Attribute (Mandatory) 🏷️

This is the title of the note. Required, no skipping 🙅‍♀️

2.25. <organization> 🏢

This specifies an author's affiliation (Section 4.1.2 of [RFC7322]) 💼

This info shows up both in the "Author's Address" section and on the front page (see Section 4.1.1 of [RFC7322] for more info) 📄 If the value is long, you can give a shorter version in the "abbrev" attribute ✂️

This element shows up as a child of <author> (Section 2.6).

Content model: only text content 📝

2.25.1. "abbrev" Attribute ✂️

This is the abbreviated variant 💫

2.26. <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 prefix tel: 🙅‍♀️ It uses the "global numbers" syntax. See Section 3 of [RFC3966] for details 🌍

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

Content model: only text content 📝

2.27. <postal> 📮

This holds child elements with postal info 📬

Note: at least one <street> element needs to be present. Formatters will handle empty values just fine though, so don't stress 💖

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

Content model:

In this order:

1. One or more <street> elements (Section 2.37)
2. In any order:
   • <city> elements (Section 2.9)
   • <region> elements (Section 2.32)
   • <code> elements (Section 2.10)
   • <country> elements (Section 2.11)

2.28. <postamble> 🌙

This gives text that appears at the bottom of a figure or table 👇

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

Content model:

In any order:

• Text
• <xref> elements (Section 2.45)
• <eref> elements (Section 2.15)
• <iref> elements (Section 2.20)
• <cref> elements (Section 2.12)
• <spanx> elements (Section 2.36)

2.29. <preamble> 🌅

This gives text that appears at the top of a figure or table 👆

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

Content model:

In any order:

• Text
• <xref> elements (Section 2.45)
• <eref> elements (Section 2.15)
• <iref> elements (Section 2.20)
• <cref> elements (Section 2.12)
• <spanx> elements (Section 2.36)

2.30. <reference> 📖

This represents a bibliographical reference 📚✨

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

Content model:

In this order:

1. One <front> element (Section 2.19)
2. Optional <seriesInfo> elements (Section 2.35)
3. Optional <format> elements (Section 2.18)
4. Optional <annotation> elements (Section 2.3)

2.30.1. "anchor" Attribute (Mandatory) 🦋

This is the document-wide unique ID for this reference. Usually it's used both to "label" the reference in the "References" section and as an identifier in links to this entry 🔗

The value has to be a valid XML "Name" (Section 2.3 of [XML]), and it's also limited to US-ASCII characters [USASCII]. So the character set is "A-Z", "a-z", "0-9", "_", "-", ".", and ":". The "0-9", ".", and "-" characters aren't allowed as start characters 🙈 Be careful with that one, bestie 💀

2.30.2. "target" Attribute 🔗

Okay bestie, this one holds the URI for the reference 🫶

Heads up though: depending on the <seriesInfo> element, a URI might not be needed, and it might not even be desirable 🙈 because it can be automatically generated (for instance, for RFCs) ✨

2.31. <references> 📚

Contains a set of bibliographical references 💜

In the early days of the RFC series, there was only one "References" section per RFC 🥹 This convention was later changed to group references into two sets -- "Normative" and "Informative" -- as described in Section 4.8.6 of [RFC7322] 💅 This vocabulary supports the split with the "title" attribute 🎀

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

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

Content model:

One or more <reference> elements (Section 2.30)

2.31.1. "title" Attribute 🌸

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

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

2.32. <region> 🌍

Provides the region name in a postal address 📮

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

Content model: only text content.

2.33. <rfc> 👑

This is the root element of the xml2rfc vocabulary 🌳 It's the main character, no cap 💅

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

Content model:

In this order:

1. One <front> element (Section 2.19)
2. One <middle> element (Section 2.23)
3. One optional <back> element (Section 2.7)

2.33.1. "category" Attribute 🏷️

Document category (see Appendix A.1).

Allowed values:

• "std"
• "bcp"
• "info"
• "exp"
• "historic"

2.33.2. "consensus" Attribute 🗳️

Affects the generated boilerplate ✨

See [RFC5741] for more information.

Allowed values:

• "no"
• "yes"

2.33.3. "docName" Attribute 📝

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

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

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

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

See Section 7 of [IDGUIDE] for further information.

2.33.4. "ipr" Attribute ⚖️

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

Allowed values:

• "full2026"
• "noDerivativeWorks2026"
• "none"
• "full3667"
• "noModification3667"
• "noDerivatives3667"
• "full3978"
• "noModification3978"
• "noDerivatives3978"
• "trust200811"
• "noModificationTrust200811"
• "noDerivativesTrust200811"
• "trust200902"
• "noModificationTrust200902"
• "noDerivativesTrust200902"
• "pre5378Trust200902"

2.33.5. "iprExtract" Attribute 🧾

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

2.33.6. "number" Attribute 🔢

The number of the RFC to be produced.

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

2.33.7. "obsoletes" Attribute 🪦

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

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

2.33.8. "seriesNo" Attribute 🎀

Number within a document series.

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

2.33.9. "submissionType" Attribute 🛤️

The document stream.

See Section 2 of [RFC5741] for details.

Allowed values:

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

2.33.10. "updates" Attribute 🆙

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

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

2.33.11. "xml:lang" Attribute 🌐

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

See Section 2.12 of [XML] for more information.

2.34. <section> 🧚

Represents a section (when inside a <middle> element) or an appendix (when inside a <back> element) ✨

Subsections are created by nesting <section> elements inside <section> elements 🪆

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

Content model:

In this order:

1. In any order:
   • <t> elements (Section 2.38)
   • <figure> elements (Section 2.17)
   • <texttable> elements (Section 2.39)
   • <iref> elements (Section 2.20)
2. Optional <section> elements (Section 2.34)

2.34.1. "anchor" Attribute ⚓

Document-wide unique identifier for this section.

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

2.34.2. "title" Attribute (Mandatory) 🏷️

The title of the section.

2.34.3. "toc" Attribute 📑

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

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

Allowed values:

• "include"
• "exclude"
• "default" (default)

2.35. <seriesInfo> 🎀

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

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

Content model: this element does not have any contents.

2.35.1. "name" Attribute (Mandatory) 🏷️

The name of the series.

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

2.35.2. "value" Attribute (Mandatory) 🔑

The identifier within the series specified by the "name" attribute.

For BCPs, FYIs, RFCs, and STDs, this is the number within the series.

For Internet-Drafts, it is the full draft name (ending with the two-digit version number).

2.36. <spanx> 🖍️

Wraps a piece of text, indicating special formatting styles ✨

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

The following styles are defined:

emph  Simple emphasis (this is the default).

strong  Strong emphasis.

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

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

Content model: only text content.

2.36.1. "style" Attribute 💫

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

2.36.2. "xml:space" Attribute 🫧

Determines whitespace handling.

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

See also Section 2.10 of [XML].

Allowed values:

• "default"
• "preserve" (default)

2.37. <street> 🛣️

Provides a street address 🏠

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

Content model: only text content.

2.38. <t> 💬

Contains a paragraph of text 💖

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

Content model:

In any order:

• Text
• <list> elements (Section 2.22)
• <figure> elements (Section 2.17)
• <xref> elements (Section 2.45)
• <eref> elements (Section 2.15)
• <iref> elements (Section 2.20)
• <cref> elements (Section 2.12)
• <spanx> elements (Section 2.36)
• <vspace> elements (Section 2.43)

2.38.1. "anchor" Attribute ⚓

Document-wide unique identifier for this paragraph.

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

2.38.2. "hangText" Attribute 🪧

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

2.39. <texttable> 📊

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

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

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

Content model:

In this order:

1. One optional <preamble> element (Section 2.29)
2. One or more <ttcol> elements (Section 2.41)
3. Optional <c> elements (Section 2.8)
4. One optional <postamble> element (Section 2.28)

2.39.1. "align" Attribute ↔️

Determines the horizontal alignment of the table.

Allowed values:

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

2.39.2. "anchor" Attribute ⚓

Document-wide unique identifier for this table.

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

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

2.39.3. "style" Attribute 🖼️

Selects which borders should be drawn, where:

• "all" means borders around all table cells,
• "full" is like "all", except no horizontal lines between table rows (except below the column titles),
• "headers" adds just a separator between column titles and rows, and
• "none" means no borders at all.

Allowed values:

• "all"
• "none"
• "headers"
• "full" (default)

2.39.4. "suppress-title" Attribute 🙊

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

Allowed values:

• "true"
• "false" (default)

2.39.5. "title" Attribute 🏷️

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

2.40. <title> 🏷️

Represents the document title 👑

When this element appears in the <front> element of the current document, the title might also appear in page headers or footers. If it's long (~40 characters), the "abbrev" attribute is used to specify an abbreviated variant 🪞

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

Content model: only text content.

2.40.1. "abbrev" Attribute ✨

Okay so this one is giving short and sweet 💅 It specifies an abbreviated variant of the document title. That's literally the whole vibe 🎀

2.41. <ttcol> 🌸

Contains a column heading in a table. 💖

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

Content model: only text content. 🫶

2.41.1. "align" Attribute 🦋

Determines the horizontal alignment within the table column. It's giving neat lineup energy 📏

Allowed values:

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

2.41.2. "width" Attribute 🍓

The desired column width, written as an integer 0..100 followed by "%". ✨

2.42. <uri> 🌈

Contains a web address associated with the author. Main character address book moment 📮

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

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

Content model: only text content. 💅

2.43. <vspace> 🧚

This element can be used to force the inclusion of a single line break or multiple blank lines. Little vertical space spell, iconic 🪄

Note that this is a purely presentational element; thus, its use ought to be avoided, except within a <list> as discussed in Section 2.22. Bestie, it's a presentation tool, not a crutch 😭

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

Content model: this element does not have any contents. Empty and proud of it 🙈

2.43.1. "blankLines" Attribute 💜

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

For paged output formats, no additional blank lines should be generated after a page break. Page breaks are not the time for extra fluff 📄

2.44. <workgroup> 🦋

This element is used to specify the Working Group (IETF) or Research Group (IRTF) from which the document originates, if any. The recommended format is the official name of the Working Group (with some capitalization). Give the group its proper name, babe ✨

In Internet-Drafts, this is used in the upper left corner of the boilerplate, replacing the default "Network Working Group" string. Formatting software can append the words "Working Group" or "Research Group", depending on the "submissionType" property of the <rfc> element (Section 2.33.9). Software does the glam work for you 💁‍♀️

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

Content model: only text content. 🎀

2.45. <xref> 🔥

Inserts a cross-reference to a different part of a document. Hyperlink-adjacent but make it a whole vibe 🌐

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

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

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

Content model: only text content. 💜

2.45.1. "format" Attribute ✨

This attribute is used to control the format of the generated reference text. Think of it as the outfit for your cross-reference 👗

• "counter": Inserts a counter, such as the number of a section, figure, table, or list item. For targets that are not inherently numbered, such as references or comments, it uses the anchor name instead. 🔢
• "default": Inserts a text fragment that describes the referenced part completely, such as "Section 2", "Table 4", or "[XML]". Full descriptive glow-up 🌟
• "none": There will be no autogenerated text. Silent mode, no drama 🤫
• "title": Inserts a title for the referenced element (usually obtained from the referenced element's "title" attribute; some processors also use the <title> child element or a <reference> target). 🎬

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

• Non-empty text content with any format other than "none".
• Empty text content with format "counter" for any target that isn't inherently numbered.
• Empty text content with format "title" for any target that doesn't have a title.

These combos are a little chaotic across formatters, so just steer clear 🙅‍♀️

Allowed values:

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

2.45.2. "pageno" Attribute 🙈

Unused.

It's unclear what the purpose of this attribute is; processors seem to ignore it, and it never was documented. Honestly? A mystery attribute. Ignored, unloved, iconic in its own way 👻

Allowed values: "true", "false" (default).

2.45.3. "target" Attribute (Mandatory) 💖

Identifies the document component being referenced. This one is NOT optional, bestie 🚨

The value needs to match the value of the "anchor" attribute of another element in the document. It's a matchmaking situation, the anchors have to match 💘

3. Escaping for Use in XML 🫶

Text in XML cannot use the literal characters < and &, as they have special meaning to the XML processor (starting entities, elements, etc.). Usually, these characters will need to be substituted by < and & (see Section 4.6 of [XML]). Those two are the drama queens of XML 🎭

> does not require escaping, unless it appears in the sequence ]]> (which indicates the end of a CDATA section; see below). Only that one exception, so chill about the rest 😌

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

4. Special Unicode Code Points 🌸

Although the current RFC format does not allow non-ASCII Unicode characters [UNICODE], some of them can be used to enforce certain behaviors of formatters. Sneaky little characters doing the work 🕵️‍♀️

For instance:

• non-breaking space (U+00A0): Represents a space character where no line break should happen. This is frequently used in titles (by excluding certain space characters from the line-breaking algorithm, the processor will use the remaining whitespace occurrences for line breaks). Keeps the words holding hands 🤝
• non-breaking hyphen (U+2011): Similarly, this represents a hyphen character where no line breaking ought to occur. Same energy, but for hyphens 🪢
• word joiner (U+2060): Also called "zero width non-breaking space" -- can be used to disallow line breaking between two non-whitespace characters. Invisible and iconic 🫥

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

<?xml version="1.0"?>

<!DOCTYPE rfc [

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

5. Including Files 🦋

This version of the vocabulary does not support an inclusion mechanism on its own -- thus, a document always needs to be self-contained. No built-in import glow-up here 🙅‍♀️

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

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

For instance:

<?xml version="1.0"?>

<!DOCTYPE rfc [

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

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

  <references>
    &rfc2629;
  </references>

Note that this mechanism only works for well-formed XML fragments; thus, any plain text that would need to be escaped in XML can't be included as is. Raw text with special characters is a no-go here 🙈

6. Internationalization Considerations 🌈

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

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

7. Security Considerations 💀

Bestie, this section is not optional. Read every word 🚨

The "name" attribute of the <artwork> element (Section 2.5.4) can be used to derive a filename for saving to a local file system. Trusting this kind of information without pre-processing is a known security risk; see Section 4.3 of [RFC6266] for more information. Never trust a filename you didn't check first 😬

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

All security considerations related to XML processing are relevant as well (see Section 7 of [RFC3470]). The XML security checklist is also on the list, no skipping 🛡️

8. IANA Considerations 🎀

8.1. Internet Media Type Registration 👑

IANA maintains the registry of Internet Media Types [BCP13] at http://www.iana.org/assignments/media-types.

This document serves as the specification for the Internet Media Type application/rfc+xml. The following has been registered with IANA. It's officially on the list now 📜

• Type name: application
• Subtype name: rfc+xml
• Required parameters: There are no required parameters.
• Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" Media Type specified in Section 9.1 of [RFC7303].
• Encoding considerations: Identical to those of "application/xml" as described in Section 9.1 of [RFC7303].
• Security considerations: As defined in Section 7. In addition, as this media type uses the "+xml" convention, it inherits the security considerations described in Section 10 of [RFC7303].
• Interoperability considerations: Some aspects of this vocabulary currently cannot be used interoperably; among the reasons for this are that they weren't precisely defined in the first place, that they have been added in an ad hoc fashion later on, or that they are specific to certain output formats. This specification attempts to identify these cases in the description of the individual elements/attributes. Some parts are a little messy, but the spec flags them 🫠
• Published specification: This specification.
• Applications that use this media type: Applications that transform xml2rfc to output formats such as plain text or HTML, plus additional analysis tools.
• Fragment identifier considerations: The "anchor" attribute is used for assigning document-wide unique identifiers that can be used as shorthand pointers, as described in Section 3.2 of [XPOINTER]. 📍
• Additional information:
  • Deprecated alias names for this type: None.
  • Magic number(s): As specified for "application/xml" in Section 9.1 of [RFC7303].
  • File extension(s): .xml or .rfcxml when disambiguation from other XML files is needed.
  • Macintosh file type code(s): TEXT
• Person & email address to contact for further information: See the Author's Address section of RFC 7749.
• Intended usage: COMMON
• Restrictions on usage: None.
• Author: See the Author's Address section of RFC 7749.
• Change controller: RFC Series Editor (rse@rfc-editor.org)

9. References 📚

9.1. Normative References ✨

okay so these are the references the spec needs you to have read, bestie 📚

• [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, http://www.rfc-editor.org/info/rfc2046.
• [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, http://www.rfc-editor.org/info/rfc3966.
• [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, http://www.rfc-editor.org/info/rfc6068.
• [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, http://www.rfc-editor.org/info/rfc7303.
• [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/. Latest version available at http://www.w3.org/TR/xml.

9.2. Informative References ✨

these ones are the extra reading list 🌈 not strictly required, but SO good for context

• [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013, http://www.rfc-editor.org/info/bcp13.
• [CSS] Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", W3C Recommendation REC-CSS2-20110607, June 2011, http://www.w3.org/TR/2011/REC-CSS2-20110607/. Latest version available at http://www.w3.org/TR/CSS2.
• [HTML] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C Recommendation REC-html5-20141028, October 2014, http://www.w3.org/TR/2014/REC-html5-20141028/. Latest version available at http://www.w3.org/TR/html5/.
• [IDGUIDE] Housley, R., "Guidelines to Authors of Internet-Drafts", December 2010, http://www.ietf.org/id-info/guidelines.html.
• [JING] Thai Open Source Software Center Ltd, "Jing - A RELAX NG validator in Java", 2008, http://www.thaiopensource.com/relaxng/jing.html. Downloads: https://code.google.com/p/jing-trang/downloads/list.
• [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, http://www.rfc-editor.org/info/rfc2026.
• [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, DOI 10.17487/RFC2223, October 1997, http://www.rfc-editor.org/info/rfc2223.
• [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, http://www.rfc-editor.org/info/rfc2397.
• [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, http://www.rfc-editor.org/info/rfc2629.
• [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, January 2003, http://www.rfc-editor.org/info/rfc3470.
• [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, DOI 10.17487/RFC3667, February 2004, http://www.rfc-editor.org/info/rfc3667.
• [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", RFC 3978, DOI 10.17487/RFC3978, March 2005, http://www.rfc-editor.org/info/rfc3978.
• [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, http://www.rfc-editor.org/info/rfc3986.
• [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, http://www.rfc-editor.org/info/rfc5234.
• [RFC5378] Bradner, S., Ed., and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, http://www.rfc-editor.org/info/rfc5378.
• [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, http://www.rfc-editor.org/info/rfc5598. PDF version: http://www.rfc-editor.org/rfc/rfc5598.pdf
• [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, DOI 10.17487/RFC5741, December 2009, http://www.rfc-editor.org/info/rfc5741.
• [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, DOI 10.17487/RFC6266, June 2011, http://www.rfc-editor.org/info/rfc6266.
• [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, http://www.rfc-editor.org/info/rfc7322.
• [RNC] Clark, J., "RELAX NG Compact Syntax", OASIS, November 2002, http://www.oasis-open.org/committees/relax-ng/compact-20021121.html.
• [TCLReadme] Rose, M., Fenner, B., and C. Levert, "xml2rfc v1.35pre1", October 2009, http://svn.tools.ietf.org/svn/tools/xml2rfc/archive/README.html.
• [TLP1.0] IETF Trust, "Legal Provisions Relating to IETF Documents", November 2008, http://trustee.ietf.org/license-info/IETF-TLP-1.htm.
• [TLP2.0] IETF Trust, "Legal Provisions Relating to IETF Documents", February 2009, http://trustee.ietf.org/license-info/IETF-TLP-2.htm.
• [TLP3.0] IETF Trust, "Legal Provisions Relating to IETF Documents", September 2009, http://trustee.ietf.org/license-info/IETF-TLP-3.htm.
• [TLP4.0] IETF Trust, "Legal Provisions Relating to IETF Documents", December 2009, http://trustee.ietf.org/license-info/IETF-TLP-4.htm.
• [TLP5.0] IETF Trust, "Legal Provisions Relating to IETF Documents", March 2015, http://trustee.ietf.org/license-info/IETF-TLP-5.htm.
• [UNICODE] The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/versions/latest/.
• [USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
• [V1rev] Rose, M., "Writing I-Ds and RFCs using XML (revised)", February 2008, http://svn.tools.ietf.org/svn/tools/xml2rfc/archive/draft-mrose-writing-rfcs.html.
• [XPOINTER] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Framework", W3C Recommendation REC-xptr-framework-20030325, March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/. Latest version available at http://www.w3.org/TR/xptr-framework/.

---

Appendix A. Front-Page ("Boilerplate") Generation ✨

this is the bit that writes the front page for you, so you don't have to type all the legal stuff yourself 🎀

A.1. The "category" Attribute

for RFCs, the "category" attribute (Section 2.33.1) decides the "maturity level" (see Section 4 of [RFC2026]) 💅 the allowed values are "std" for "Standards Track", "bcp" for "BCP", "info" for "Informational", "exp" for "Experimental", and "historic" for "Historic" 🌸

for Internet-Drafts, the "category" attribute isn't needed. if you do supply it, it shows up as "Intended Status", and that can be really helpful for reviewers 🫶

A.2. The "ipr" Attribute

this attribute can take a long list of values 😭 each one describes an IPR policy for the document (Section 2.33.4). no grand master plan behind them, they just stuck around for historic reasons 🙈 only a few are actually used now, and the rest are only kept around so tools can handle old source files.

Note: some variations of the boilerplate are picked based on the document's date, so it really matters that you set the "year", "month", and "day" attributes of the <date> element when archiving the XML source of an Internet-Draft on the day you submit it 📅

_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 "Status of This Memo" text, the "submissionType" attribute (Section 2.33.9) decides whether a statement about "Code Components" gets inserted 🧚 that happens for the value "IETF", which is the default. other values, like "independent", skip that part.

A.2.1. Current Values: "*trust200902

these values come from the IETF Trust's "Legal Provisions Relating to IETF Documents", which everyone just calls the "TLP" 💜 the TLP went into effect on February 15, 2009 [TLP2.0]. it got updated on September 12, 2009 [TLP3.0] and on December 28, 2009 [TLP4.0], and those updates changed the license for code components (see http://trustee.ietf.org/license-info/ for more info). the actual text lives in Section 6 ("Text to Be Included in IETF Documents") of those documents 📖

formatters will automatically produce the "correct" text, based on the document's date information (see above) ✨ here's the lookup:

+----------+--------------------------------+
| TLP      | starting with publication date |
+----------+--------------------------------+
| [TLP3.0] | 2009-11-01                     |
| [TLP4.0] | 2010-04-01                     |
+----------+--------------------------------+

the TLP got another update in March 2015 ([TLP5.0]), but those changes don't touch the boilerplate text 🌈

A.2.1.1. trust200902

this is the one you should use, 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.2.1.2. noModificationTrust200902

this one adds some extra text from Section 6.c.i of the TLP, and it goes like this:

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.2.1.3. noDerivativesTrust200902

this one 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.2.1.4. pre5378Trust200902

okay so this one produces the extra text from Section 6.c.iii of the TLP 💅, which everyone calls the "pre-5378 escape clause" (it's about changes introduced in [RFC5378]) 🎀:

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

for more details on when to use this value, check Section 4 of <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, in which case it shows up under "Status of This Memo" 🌸

A.2.2. Historic Values

A.2.2.1. Historic Values: "*trust200811"

the attribute values "trust200811", "noModificationTrust200811", and "noDerivativesTrust200811" are basically the same as their "trust200902" cousins 🦋, except they use the text from [TLP1.0] ✨.

A.2.2.2. Historic Values: "*3978"

the attribute values "full3978", "noModification3978", and "noDerivatives3978" are like their counterparts above, except they use the text from Section 5 of [RFC3978] 💜.

A.2.2.3. Historic Values: "*3667"

the attribute values "full3667", "noModification3667", and "noDerivatives3667" are like their counterparts above, except they use the text from Section 5 of [RFC3667] 🌈.

A.2.2.4. Historic Values: "*2026"

the attribute values "full2026" and "noDerivativeWorks2026" are like their counterparts above, except they use the text from Section 10 of [RFC2026] 🍓.

the special value "none" was also a thing back then 🙈. it denied the IETF any rights beyond publication as an Internet-Draft 💀.

A.3. The "submissionType" Attribute

the RFC Editor publishes documents from different document streams 🎀, and the IETF stream is the most prominent one 👑. The other streams are the independent stream (used for stuff like discussion of Internet-related technologies that aren't part of the IETF agenda) 🦋, the IAB stream (Internet Architecture Board) 🌸, and the IRTF stream (Internet Research Task Force) ✨.

the values for this attribute are "IETF" (the default value), "independent", "IAB", and "IRTF" 💖.

historically, this attribute didn't really change the final look of RFCs, except for subtle differences in copyright notices 🙈. nowadays (as of [RFC5741]), 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 the following 🫶:

o For RFCs, the stream name shows up in the upper left corner of the first page (in Internet-Drafts, this is either "Network Working Group" or the value of the <workgroup> element) 🎀.

o For RFCs, it affects the whole "Status of This Memo" section (see Section 3.2.2 of [RFC5741]) 🔥.

o 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.4. The "consensus" Attribute

for some of the publication streams (see Appendix A.3), the "Status of This Memo" section depends on whether there was a consensus to publish (again, see Section 3.2.2 of [RFC5741]) 👑.

The "consensus" attribute ("yes"/"no", defaulting to "yes") can be used to supply this information 💜. The effect for the various streams is:

o "independent" and "IAB": none 🌈.

o "IETF": mention that there was an IETF consensus ✨.

o "IRTF": mention that there was a research group consensus (where the name of the research group is pulled from the <workgroup> element) 🦋.

Appendix B. Changes from RFC 2629 ("v1")

B.1. Removed Elements

the <appendix> element has been removed 💀. to make an appendix, put a <section> inside <back> 🫶.

B.2. Changed Defaults

Many attributes lost their "default" value 🙈, and this is so that document semantics don't end up differing based on whether a DTD was specified and evaluated 💅. Processors will handle absent values the way the default value was specified before ✨.

B.3. Changed Elements

<artwork>: has a set of new attributes: "name", "type", "src", "align", "alt", "width", and "height" 🎀. (Section 2.5)

<author>: the <organization> element is now optional 🌸. The "role" attribute was added 💖. (Section 2.6)

<country>: the requirement to use ISO 3166 codes was removed 🧚. (Section 2.11)

<date>: all attributes are now optional 💜. (Section 2.13)

<figure>: has a set of new attributes: "suppress-title", "src", "align", "alt", "width", and "height" 🔥. (Section 2.17)

<iref>: has a new "primary" attribute 🍓. (Section 2.20)

<list>: the "style" attribute isn't restricted to a set of enumerated values anymore 🌈. The "hangIndent" and "counter" attributes were added 👑. (Section 2.22)

<reference>: <annotation> lets you add prose to a reference ✨. The "anchor" attribute is now mandatory 💀. (Section 2.30)

<references>: can now appear multiple times and can carry a "title" attribute (so normative and informative references can be split up) 🦋. (Section 2.31)

<rfc>: the "ipr" attribute gained additional values 🫶. The attributes "consensus", "iprExtract", "submissionType", and "xml:lang" were added 🎀. (Section 2.33)

<section>: the new "toc" attribute controls whether it appears in the Table Of Contents 🌸. <iref> can now appear as a direct child element 💅. (Section 2.34)

<t>: the "anchor" attribute can now be used too 🧚; however, there are restrictions on how they can be referred to 🙈. (Section 2.38)

B.4. New Elements

The following elements were added: <annotation> (Section 2.3), <c> (Section 2.8), <cref> (Section 2.12), <format> (Section 2.18), <spanx> (Section 2.36), <texttable> (Section 2.39), and <ttcol> (Section 2.41) 💖✨

Appendix C. RELAX NG Schema ✨

This is the big schema file that says what a valid RFC XML document looks like. It's a whole vibe, honestly 💅🎀

namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

rfc =
  element rfc {
    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 seriesNo { text }?,
    attribute ipr {
      "full2026"
      | "noDerivativeWorks2026"
      | "none"
      | "full3667"
      | "noModification3667"
      | "noDerivatives3667"
      | "full3978"
      | "noModification3978"
      | "noDerivatives3978"
      | "trust200811"
      | "noModificationTrust200811"
      | "noDerivativesTrust200811"
      | "trust200902"
      | "noModificationTrust200902"
      | "noDerivativesTrust200902"
      | "pre5378Trust200902"
    }?,
    attribute iprExtract { xsd:IDREF }?,
    [ a:defaultValue = "IETF" ]
    attribute submissionType {
      "IETF" | "IAB" | "IRTF" | "independent"
    }?,
    attribute docName { text }?,
    [ a:defaultValue = "en" ] attribute xml:lang { text }?,
    front,
    middle,
    back?
  }

front =
  element front {
    title,
    author+,
    date,
    area*,
    workgroup*,
    keyword*,
    abstract?,
    note*
  }

title =
  element title {
    attribute abbrev { text }?,
    text
  }

author =
  element author {
    attribute initials { text }?,
    attribute surname { text }?,
    attribute fullname { text }?,
    attribute role { "editor" }?,
    organization?,
    address?
  }

organization =
  element organization {
    attribute abbrev { 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 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+ }

note =
  element note {
    attribute title { text },
    t+
  }

middle = element middle { section+ }

section =
  element section {
    attribute anchor { xsd:ID }?,
    attribute title { text },
    [ a:defaultValue = "default" ]
    attribute toc { "include" | "exclude" | "default" }?,
    (t | figure | texttable | iref)*,
    section*
  }

t =
  element t {
    attribute anchor { xsd:ID }?,
    attribute hangText { text }?,
    (text
     | \list
     | figure
     | xref
     | eref
     | iref
     | cref
     | spanx
     | vspace)*
  }

\list =
  element list {
    attribute style { text }?,
    attribute hangIndent { text }?,
    attribute counter { text }?,
    t+
  }

xref =
  element xref {
    attribute target { xsd:IDREF },
    [ a:defaultValue = "false" ]
    attribute pageno { "true" | "false" }?,
    [ a:defaultValue = "default" ]
    attribute format { "counter" | "title" | "none" | "default" }?,
    text
  }

eref =
  element eref {
    attribute target { text },
    text
  }

iref =
  element iref {
    attribute item { text },
    [ a:defaultValue = "" ] attribute subitem { text }?,
    [ a:defaultValue = "false" ]
    attribute primary { "true" | "false" }?,
    empty
  }

cref =
  element cref {
    attribute anchor { xsd:ID }?,
    attribute source { text }?,
    text
  }

spanx =
  element spanx {
    [ a:defaultValue = "preserve" ]
    attribute xml:space { "default" | "preserve" }?,
    [ a:defaultValue = "emph" ] attribute style { text }?,
    text
  }

vspace =
  element vspace {
    [ a:defaultValue = "0" ] attribute blankLines { text }?,
    empty
  }

figure =
  element figure {
    attribute anchor { xsd:ID }?,
    [ a:defaultValue = "" ] attribute title { text }?,
    [ a:defaultValue = "false" ]
    attribute suppress-title { "true" | "false" }?,
    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 }?,
    iref*,
    preamble?,
    artwork,
    postamble?
  }

preamble =
  element preamble { (text | xref | eref | iref | cref | spanx)* }

artwork =
  element artwork {
    [ a:defaultValue = "preserve" ]
    attribute xml:space { "default" | "preserve" }?,
    [ 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*
  }

postamble =
  element postamble { (text | xref | eref | iref | cref | spanx)* }

texttable =
  element texttable {
    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" }?,
    preamble?,
    ttcol+,
    c*,
    postamble?
  }

ttcol =
  element ttcol {
    attribute width { text }?,
    [ a:defaultValue = "left" ]
    attribute align { "left" | "center" | "right" }?,
    text
  }

c = element c { (text | xref | eref | iref | cref | spanx)* }

back = element back { references*, section* }
references =
  element references {
    [ a:defaultValue = "References" ] attribute title { text }?,
    reference+
  }

reference =
  element reference {
    attribute anchor { xsd:ID },
    attribute target { text }?,
    front,
    seriesInfo*,
    format*,
    annotation*
  }

seriesInfo =
  element seriesInfo {
    attribute name { text },
    attribute value { text },
    empty
  }

format =
  element format {
    attribute target { text }?,
    attribute type { text },
    attribute octets { text }?,
    empty
  }

annotation =
  element annotation { (text | xref | eref | iref | cref | spanx)* }

start = rfc

This schema was derived from version 1.3.6 of the xml2rfc DTD ("Document Type Definition") (Section 2.8 of [XML]), which you can find at http://svn.tools.ietf.org/svn/tools/xml2rfc/vocabulary/v2/03/xml2rfcv2.dtd. 🧚

C.1. Checking Validity

You can check whether XML files are valid with any tool that supports RELAX NG [RNC]. The reference implementation is the Java-based, open-sourced "Jing" [JING]. 🔥

To use Jing, download the latest ZIP file from the "downloads" page (right now that's https://code.google.com/p/jing-trang/downloads/detail?name=jing-20091111.zip), extract the archive, copy "jing.jar" from the "bin" folder, and make sure Java is installed. 💜

To check a file "test.xml" using the RNC file "schema.rnc", run this from a command-line prompt:

java -jar jing.jar -c schema.rnc test.xml

In good Unix tradition, no output means the file is valid. Silence is golden, periodt ✨

---

IAB Members at the Time of Approval

These are the IAB members who were around when this got approved 🌸

• Jari Arkko (IETF Chair)
• Mary Barnes
• Marc Blanchet
• Ralph Droms
• Ted Hardie
• Joe Hildebrand
• Russ Housley
• Erik Nordmark
• Robert Sparks
• Andrew Sullivan
• Dave Thaler
• Brian Trammell
• Suzanne Woolf

Acknowledgments

Huge thank-yous to everybody who reviewed this document and gave feedback and/or specification text 🫶 Special shoutouts to Brian Carpenter, Elwyn Davies, Tony Hansen, Joe Hildebrand, Paul Hoffman, Henrik Levkowetz, Alice Russo, Tom Taylor, Dave Thaler, Jim Schaad, and Nico Williams. You all ate 👑

We also thank Marshall T. Rose for both the original design and the reference implementation of the "xml2rfc" formatter. Honestly, the people who built the tools that make all of this possible are iconic 🦋

Index ✨

okay bestie, this is the big cheat sheet 🧚 every attribute, element, and media type with the page numbers where they show up, so you can jump straight to whatever you're hunting for 💅

   A
      Attributes
         abbrev  21, 34
         align  7, 14, 32, 34
         alt  7, 15
         anchor  11, 15, 23, 28, 31-32
         blankLines  35
         category  25
         consensus  25
         counter  18
         day  12
         docName  25
         format  36
         fullname  9
         hangIndent  18
         hangText  31
         height  7, 15
         initials  9
         ipr  26
         iprExtract  26
         item  17
         month  12
         name  7, 29
         number  27
         obsoletes  27
         octets  16
         pageno  37
         primary  17
         role  9
         seriesNo  27
         source  12
         src  7, 15
         style  19, 30, 32
         subitem  17
         submissionType  27
         suppress-title  15, 33
         surname  10
         target  13, 16, 23, 37
         title  15, 21, 24, 28, 33
         toc  28
         type  8, 16
         updates  27
         value  29
         width  8, 15, 34
         xml:lang  28
         xml:space  8, 30
         year  13
      abbrev attribute
         in organization element  21
         in title element  34
      abstract element  4, 50
         inside front  16
      address element  4, 50
         inside author  9
      align attribute
         in artwork element  7
         in figure element  14
         in texttable element  32
         in ttcol element  34
      alt attribute
         in artwork element  7
         in figure element  15
      anchor attribute
         in cref element  11
         in figure element  15
         in reference element  23
         in section element  28
         in t element  31
         in texttable element  32
      annotation element  5, 50
         inside reference  23
      application/rfc+xml Media Type  40
      area element  5, 50
         inside front  16
      artwork element  6, 50
         align attribute  7
         alt attribute  7
         height attribute  7
         inside figure  14
         name attribute  7
         src attribute  7
         type attribute  8
         width attribute  8
         xml:space attribute  8
      author element  8, 50
         fullname attribute  9
         initials attribute  9
         inside front  16
         role attribute  9
         surname attribute  10

   B
      back element  10, 50
         inside rfc  25
      blankLines attribute
         in vspace element  35
   C
      c element  10, 50
         inside texttable  32
      category attribute
         in rfc element  25
      city element  11, 50
         inside postal  22
      code element  11, 50
         inside postal  22
      consensus attribute
         in rfc element  25
      counter attribute
         in list element  18
      country element  11, 50
         inside postal  22
      cref element  11, 50
         anchor attribute  11
         inside annotation  5
         inside c  10
         inside postamble  22
         inside preamble  23
         inside t  31
         source attribute  12
   D
      date element  12, 50
         day attribute  12
         inside front  16
         month attribute  12
         year attribute  13
      day attribute
         in date element  12
      docName attribute
         in rfc element  25
   E
      Elements
         abstract  4, 16
         address  4, 9
         annotation  5, 23
         area  5, 16
         artwork  6, 14
         author  8, 16
         back  10, 25
         c  10, 32
         city  11, 22
         code  11, 22
         country  11, 22
         cref  5, 10-11, 22-23, 31
         date  12, 16
         email  5, 13
         eref  5, 10, 13, 22-23, 31
         facsimile  5, 14
         figure  14, 28, 31
         format  15, 23
         front  16, 23, 25
         iref  5, 10, 14, 17, 22-23, 28, 31
         keyword  16, 18
         list  18, 31
         middle  20, 25
         note  17, 20
         organization  9, 21
         phone  5, 21
         postal  5, 21
         postamble  14, 22, 32
         preamble  14, 22, 32
         reference  23-24
         references  10, 24
         region  22, 24
         rfc  24
         section  10, 20, 28
         seriesInfo  23, 29
         spanx  5, 10, 22-23, 29, 31
         street  21, 30
         t  4, 18, 20, 28, 31
         texttable  28, 31
         title  16, 33
         ttcol  32, 34
         uri  5, 34
         vspace  31, 34
         workgroup  16, 35
         xref  5, 10, 22, 31, 35
      email element  13, 50
         inside address  5
      eref element  13, 50
         inside annotation  5
         inside c  10
         inside postamble  22
         inside preamble  23
         inside t  31
         target attribute  13

   F
      facsimile element  14, 50
         inside address  5
      figure element  14, 50
         align attribute  14
         alt attribute  15
         anchor attribute  15
         height attribute  15
         inside section  28
         inside t  31
         src attribute  15
         suppress-title attribute  15
         title attribute  15
         width attribute  15
      format attribute
         in xref element  36
      format element  15, 50
         inside reference  23
         octets attribute  16
         target attribute  16
         type attribute  16
      front element  16, 50
         inside reference  23
         inside rfc  25
      fullname attribute
         in author element  9
   H
      hangIndent attribute
         in list element  18
      hangText attribute
         in t element  31
      height attribute
         in artwork element  7
         in figure element  15
   I
      initials attribute
         in author element  9
      ipr attribute
         "*2026"  48
         "*3667"  48
         "*3978"  47
         "*trust200811"  47
         "*trust200902"  46
         "noDerivativesTrust200902"  47
         "noModificationTrust200902"  46
         "pre5378Trust200902"  47
         "trust200902"  46
         in rfc element  26

      iprExtract attribute
         in rfc element  26
      iref element  17, 50
         inside annotation  5
         inside c  10
         inside figure  14
         inside postamble  22
         inside preamble  23
         inside section  28
         inside t  31
         item attribute  17
         primary attribute  17
         subitem attribute  17
      item attribute
         in iref element  17
   K
      keyword element  18, 50
         inside front  16
   L
      list element  18, 50
         counter attribute  18
         hangIndent attribute  18
         inside t  31
         style attribute  19
      list styles
         empty  19
         format ...  20
         hanging  19
         letters  19
         numbers  19
         symbols  19
   M
      Media Type
         application/rfc+xml  40
      middle element  20, 50
         inside rfc  25
      month attribute
         in date element  12
   N
      name attribute
         in artwork element  7
         in seriesInfo element  29
      note element  20, 50
         inside front  17
         title attribute  21
      number attribute
         in rfc element  27

   O
      obsoletes attribute
         in rfc element  27
      octets attribute
         in format element  16
      organization element  21, 50
         abbrev attribute  21
         inside author  9
   P
      pageno attribute
         in xref element  37
      phone element  21, 50
         inside address  5
      postal element  21, 50
         inside address  5
      postamble element  22, 50
         inside figure  14
         inside texttable  32
      preamble element  22, 50
         inside figure  14
         inside texttable  32
      primary attribute
         in iref element  17
   R
      reference element  23, 50
         anchor attribute  23
         inside references  24
         target attribute  23
      references element  24, 50
         inside back  10
         title attribute  24
      region element  24, 50
         inside postal  22
      rfc element  24, 50
         category attribute  25
         consensus attribute  25
         docName attribute  25
         ipr attribute  26
         iprExtract attribute  26
         number attribute  27
         obsoletes attribute  27
         seriesNo attribute  27
         submissionType attribute  27
         updates attribute  27
         xml:lang attribute  28
      role attribute
         in author element  9

   S
      section element  28, 50
         anchor attribute  28
         inside back  10
         inside middle  20
         inside section  28
         title attribute  28
         toc attribute  28
      seriesInfo element  29, 50
         inside reference  23
         name attribute  29
         value attribute  29
      seriesNo attribute
         in rfc element  27
      source attribute
         in cref element  12
      spanx element  29, 50
         inside annotation  5
         inside c  10
         inside postamble  22
         inside preamble  23
         inside t  31
         style attribute  30
         xml:space attribute  30
      src attribute
         in artwork element  7
         in figure element  15
      street element  30, 50
         inside postal  21
      style attribute
         in list element  19
         in spanx element  30
         in texttable element  32
      subitem attribute
         in iref element  17
      submissionType attribute
         in rfc element  27
      suppress-title attribute
         in figure element  15
         in texttable element  33
      surname attribute
         in author element  10

   T
      t element  31, 50
         anchor attribute  31
         hangText attribute  31
         inside abstract  4
         inside list  18
         inside note  20
         inside section  28
      target attribute
         in eref element  13
         in format element  16
         in reference element  23
         in xref element  37
      texttable element  31, 50
         align attribute  32
         anchor attribute  32
         inside section  28
         style attribute  32
         suppress-title attribute  33
         title attribute  33
      title attribute
         in figure element  15
         in note element  21
         in references element  24
         in section element  28
         in texttable element  33
      title element  33, 50
         abbrev attribute  34
         inside front  16
      toc attribute
         in section element  28
      ttcol element  34, 50
         align attribute  34
         inside texttable  32
         width attribute  34
      type attribute
         in artwork element  8
         in format element  16
   U
      updates attribute
         in rfc element  27
      uri element  34, 50
         inside address  5

   V
      value attribute
         in seriesInfo element  29
      vspace element  34, 50
         blankLines attribute  35
         inside t  31
   W
      width attribute
         in artwork element  8
         in figure element  15
         in ttcol element  34
      workgroup element  35, 50
         inside front  16
   X
      xml:lang attribute
         in rfc element  28
      xml:space attribute
         in artwork element  8
         in spanx element  30
      xref element  35, 50
         format attribute  36
         inside annotation  5
         inside c  10
         inside postamble  22
         inside preamble  22
         inside t  31
         pageno attribute  37
         target attribute  37
      xref formats
         counter  36
         default  36
         none  36
         title  36
   Y
      year attribute
         in date element  13

---

Author's Address 💌

and that's the whole crew! 🎀 here's who wrote it, with all their contact details, so you know exactly who to thank (or yell at) 🫶

   Julian F. Reschke
   greenbytes GmbH
   Hafenweg 16
   Muenster, NW  48155
   Germany

   Email: julian.reschke@greenbytes.de
   URI:   http://greenbytes.de/tech/webdav/