The RFCXML version 3 Vocabulary as ImplementedStandcorejohn.levine@standcore.comICANNpaul.hoffman@icann.org
This document describes the RFCXML version 3 vocabulary as implemented in tools used by the RFC Production Center
at the time of publication.
This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the rswg@rfc-editor.org
mailing list, which has its home page at
.
Source code and issues list for this draft can be found at
.
This document describes the updated version 3 ("v3") of the RFCXML vocabulary as implemented in tools used by the RFC Production Center at the time of publication.
The term "RFCXML" is defined in .
Some parts of the vocabulary in this document are used by the RFC Production Center to create RFCs.
Some parts of the vocabulary in this document are used by various tools to prepare Interne Drafts in XML; those drafts are sometimes input to the RFC series.
Some parts of the vocabulary in this document may not be used in current tools, but are documented here because they were thought to be possibly useful.
The v3 format is used as part of the new RFC Series format described in .
The new format is handled by existing tools for preparing the XML and
converting it to other representations.
Features of the tools are described in . That section defines some terms
used throughout this document, such as "prep tool" and "formatter".
Note that the vocabulary contains certain constructs that might not be used when generating
the final text; however, they can provide useful
data for other uses (such as index generation, populating a keyword database, or
syntax checks).
In this document, the term "format" is used when describing types of documents, primarily
XML and HTML. The term "representation" is used when talking about a specific instantiation
of a format, such as an XML document or an HTML document that was created by an XML document.
This terminology does not exactly match the terminology in , but it was deemed too difficult to update it in a clean way before publication.
In this document, "v2" refers to the format defined , which is no longer used in production.
This is a (hopefully) complete list of all the technical changes between
and this document.
Allowed <blockquote> as a child of <aside> and <li>.
Removed "It is an error to have both a "src" attribute and content in the <artwork> element."
from .
Added <u> element.
Removed the "hanging" attribute of <dl> and replaced it with "newline".
Added the "indent" attribute to <dl>.
Added the "align" attribute to <table>. Made the table title centered under the table.
Allowed the <name> element many more elements inside of it.
Redefined <references> to allow <references> within it.
In the typical case, an outer <references> will be used to hold an
inner <references> for normative references and an inner <references>
to hold informative references.
Un-deprecated metadata attributes on the <rfc> element
(with the intent to restore v2 () semantics of <seriesInfo>
as well).
Added <contact> element.
Allowed multiple <email> elements in <address>.
Added "markers" attribute to <sourcecode> element.
Added "brackets" attribute to <eref> element.
Added <toc> element, added grammar to allow authors section at the end.
Added "editorial" value to the "submissionType" attribute of <rfc>
and the <stream> element for the new Editorial stream.
Added <list> as a subelement of <t>.
Added "sortRefs", "symRefs", "tocDepth", and "tocInclude" attributes to <rfc>
to cover Processing Instructions (PIs) that were in v2 () that are still needed in the grammar.
Added "prepTime" to indicate the time that the XML went through a preparation step.
Added "version" to indicate the version of RFCXML vocabulary used in the document.
Added "scripts" to indicate which scripts are needed to render the document.
Added "expiresDate" when an Internet-Draft expires.
Added "ascii" attributes to <email>,
<organization>, <street>,
<city>, <region>, <country>, and <code>.
Also added "asciiFullname", "asciiInitials", and "asciiSurname" to <author>.
This allows an author to specify their information in their native scripts as the primary
entry and still allow the ASCII-equivalent values to appear in the processed documents.
Added "anchor" attributes to many block elements to allow them to be linked with
<relref> and <xref>.
Added the "section", "relative", and "sectionFormat" attributes to <xref>.
Added the "numbered" and "removeInRFC" attributes to <section>.
Added the "removeInRFC" attribute to <note>.
Added "pn" to <artwork>,
<aside>, <blockquote>, <boilerplate>, <dt>,
<figure>, <iref>, <li>, <references>, <section>,
<sourcecode>, <t>,
and <table> to hold automatically generated
numbers for items in a section that don't have their own numbering (namely figures and tables).
Added "display" to <cref> to indicate to tools whether or not
to display the comment.
Added "keepWithNext" and "keepWithPrevious" to <t> as a hint to tools that
do pagination that they should try to keep the paragraph with the next/previous element.
Added "indent" to <t> to allow for explicitly indented paragraphs.
These elements were present in the original vocabulary for v3 but have been deprecated.
They may be removed from tools in the future.
Deprecated attributes are still listed in , and deprecated elements are listed in .
Deprecate <city>, <cityarea>, <code>,
<extaddr>, <pobox>, <region>,
<sortingcode>, and <street> in favor of <postalLine>.
These elements require an unsupported external library to format.
Deprecate <relref>, in favor of <xref>.
The XML vocabulary here is defined in prose, based on the RELAX NG schema
contained in (specified in
RELAX NG Compact Notation (RNC)).
Note that the schema can be used for automated validity
checks, but certain constraints are only described in prose (example:
the conditionally required presence of the "abbrev" attribute).
The sections below describe all elements and their attributes.
Note that attributes not labeled "mandatory" are optional.
Many elements have an optional "anchor" attribute. In all cases, the value of the "anchor"
attribute needs to be a valid XML "Name" (),
additionally constrained to US-ASCII characters . Thus, the character repertoire consists of
"A-Z", "a-z", "0-9", "_", "-", ".", and ":", where "0-9", ".", and "-" are disallowed as start characters.
Anchors are described in more detail in .
Tools interpreting the XML described here will collapse horizontal whitespace and line breaks to a
single whitespace (except inside <artwork> and
<sourcecode>) and will trim leading and trailing whitespace.
Tab characters (U+0009) inside <artwork> and <sourcecode> are
prohibited.
Some of the elements have attributes that are not described in this section because those attributes
are specific to the prep tool. People writing tools to process this format should read all of
the appendices for a complete description of these attributes.
Every element in the v3 vocabulary can have an "xml:lang" attribute, an "xml:base" attribute, or
both. The xml:lang attribute specifies the language used in the element. This is sometimes useful
for renderers that display different fonts for ideographic characters used in China and Japan.
The xml:base attribute is sometimes added to an XML file when doing XML-to-XML conversion where the
base file has XInclude attributes (see ).
<abstract>
Contains the Abstract of the document.
See for more information on restrictions for the Abstract.
This element appears as a child element of <front> ().
Content model:
In any order, but at least one of:
<dl> elements ()
<ol> elements ()
<t> elements ()
<ul> elements ()
"anchor" Attribute
Document-wide unique identifier for the Abstract.
<address>
Provides address information for the author.
This element appears as a child element of <author> () and <contact> ().
Content model:In this order:
One optional <postal> element ()
One optional <phone> element ()
Optional <email> elements ()
One optional <uri> element ()
<annotation>
Provides additional prose augmenting a bibliographic reference.
This text is intended to be shown after the rest of the generated reference text.
This element appears as a child element of <reference> ().
Content model:
In any order:
Text
<bcp14> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
<area>
Provides information about the IETF area to which this document relates
(currently not used when generating documents).
The value ought to be either the full name or the abbreviation of one of
the IETF areas as listed on .
This element appears as a child element of <front> ().
Content model: only text content.<artset>
This element allows for the support of alternative artwork formats. This will allow the renderer to pick the most appropriate <artwork> instance for its format from the alternatives present within an <artset> element.
Each of the <artwork> elements must have a "type" attribute.
If more than one <artwork> element is found within an <artset> element, with the same "type" attribute, the rendere could select the first one, or possibly choose between the alternative instances based on the output format and some quality of the alternative instances that made one more suitable than the other for that particular format, such as size, aspect ration, etc.
This element appears as a child element of <aside> (), <blockquote> (), <dd> (), <figure> (), <li> (), <section> (), <td> (), and <th> ().
Content model:
One or more <artwork> elements ()"anchor" Attribute
Same as for the <artwork> element ().
<artwork>
This element allows the inclusion of "artwork" in the document.
<artwork> provides
full control of horizontal whitespace and line breaks; thus, it is
used for a variety of things, such as diagrams ("line art") and protocol unit diagrams.
Tab characters (U+0009) inside of this element are prohibited.
Alternatively, the "src" attribute allows referencing an external graphics
file, such as a vector drawing in SVG or a bitmap graphic file, using a URI. In this case, the textual
content acts as a fallback for output representations that do not support graphics;
thus, it ought to contain either (1) a "line art" variant of the graphics or (2)
prose that describes the included image in sufficient detail.
In v2 (), the <artwork> element was also used for source code and formal
languages; in v3, this is now done with <sourcecode>.
There are at least five ways to include SVG in artwork in Internet-Drafts:
Inline, by including all of the SVG in the content of the element,
such as: <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg...">
Inline, but using XInclude (see ),
such as: <artwork type="svg"><xi:include href=...>
As a data: URI, such as: <artwork type="svg"
src="data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3...">
As a URI to an external entity, such as: <artwork type="svg" src="http://www.example.com/...">
As a local file, such as: <artwork type="svg" src="diagram12.svg">
The use of SVG in Internet-Drafts and RFCs is covered in much more detail in
.
The above methods for inclusion of SVG art can also be used for including text artwork, but using a data: URI is probably
confusing for text artwork.
Formatters that do pagination should attempt to keep artwork on a single page. This is to prevent
artwork that is split across pages from looking like two separate pieces of artwork.
See for a description of how to deal with issues of using
"&" and "<" characters in artwork.
This element appears as a child element of <artset> (), <aside> (), <blockquote> (), <dd> (), <figure> (), <li> (), <section> (), <td> (), and <th> ().
Content model:
Either:
Text
Or:
<svg> elements ()
"align" Attribute
Controls whether the artwork appears left justified (default), centered,
or right justified.
Artwork is aligned relative to the left margin of the document.
Allowed values:
"left" (default)
"center"
"right"
"alt" Attribute
Alternative text description of the artwork (which is more than just a summary or caption).
When the art comes from the "src" attribute
and the format of that artwork supports alternate text,
the alternative text comes from the text of the artwork itself, not from this attribute.
The contents of this attribute are important to readers who are visually impaired, as well as
those reading on devices that cannot show the artwork well, or at all.
"anchor" Attribute
Document-wide unique identifier for this artwork.
"name" Attribute
A filename suitable for the contents (such as for extraction to a local file).
This attribute can
be helpful for other kinds of tools (such as automated syntax checkers,
which work by extracting the artwork).
Note that the "name" attribute does not need to be unique for <artwork> elements in a
document. If multiple <artwork> elements have the same "name" attribute, a processing tool might
assume that the elements are all fragments of a single file, and the tool can
collect those fragments for later processing.
See for a discussion of possible problems with the value of this attribute.
"src" Attribute
The URI reference of a graphics file , or the name of a file on the local disk.
This can be a "data" URI that contains the contents of the graphics file.
Note that the inclusion of art with the "src" attribute depends on the capabilities of the processing tool
reading the XML document. Tools need to be able to handle the file: URI, and they should
be able to handle http: and https: URIs as well. The prep tool will be able to handle reading the "src" attribute.
If no URI scheme is given in the attribute, the attribute is considered to be a local filename
relative to the current directory.
Processing tools must be careful to not accept dangerous values for the filename, particularly those that contain
absolute references outside the current directory.
Document creators should think hard before using relative URIs due to possible later problems if files move
around on the disk. Also, documents should most likely use explicit URI schemes wherever possible.
In some cases, the prep tool may remove the "src" attribute after processing its value.
See for a description of this.
"type" Attribute
Specifies the type of the artwork. The value of this attribute is free text with
certain values designated as preferred.
The preferred values for <artwork> types are:
ascii-art
binary-art
svg
<aside>
This element is a container for content that is semantically less important or tangential
to the content that surrounds it.
This element appears as a child element of <dd> () and <section> ().
Content model:
In any order:
<artset> elements ()
<artwork> elements ()
<blockquote> elements ()
<dl> elements ()
<figure> elements ()
<iref> elements ()
<ol> elements ()
<t> elements ()
<table> elements ()
<ul> elements ()
"anchor" Attribute
Document-wide unique identifier for this aside.
<author>
Provides information about a document's author. This is used both for
the document itself (at the beginning of the document) and for
referenced documents.
The <author> elements contained within the document's <front> element
are used to fill the boilerplate and also to generate the "Author's Address"
section (see ).
Note that an "author" can also be just an organization (by not specifying any
of the "name" attributes, but adding the <organization>
child element).
Furthermore, the "role" attribute can be used to mark an author as
"editor". This is reflected both on the front page and in the "Author's Address" section, as well as in bibliographic
references. Note that this specification does not define a precise
meaning for the term "editor".
This element appears as a child element of <front> () and <section> ().
Content model:In this order:
One optional <organization> element ()
One optional <address> element ()
"anchor" Attribute
Document-wide unique identifier for this <author> element.
"asciiFullname" Attribute
The ASCII equivalent of the author's full name.
"asciiInitials" Attribute
The ASCII equivalent of the author's initials, to be used in conjunction with the separately specified asciiSurname.
"asciiSurname" Attribute
The ASCII equivalent of the author's surname, to be used in conjunction with the separately specified asciiInitials.
"fullname" Attribute
The full name (used in the automatically generated "Author's Address" section).
Although this attribute is optional, if one or more of the "asciiFullname", "asciiInitials",
or "asciiSurname" attributes have values, the "fullname" attribute is required.
"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.
"role" Attribute
Specifies the role the author had in creating the document.
"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.
<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> ().
Content model:In this order:
Optional <displayreference> elements ()
Optional <references> elements ()
Optional <section> elements ()
<bcp14>
Marks text that are phrases defined in such as "MUST", "SHOULD NOT", and so on. When shown
in some of the output representations, the text in this element might be highlighted.
The use of this element is optional.
This element is only to be used around the actual phrase from BCP 14, not the full
definition of a requirement. For example, it is correct to say
"The packet <bcp14>MUST</bcp14> be dropped.", but it is not correct to say
"<bcp14>The packet MUST be dropped.</bcp14>".
This element appears as a child element of <annotation> (), <blockquote> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <refcontent> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), and <tt> ().
Content model: only text content.<blockquote>
Specifies that a block of text is a quotation.
This element appears as a child element of <aside> (), <li> (), and <section> ().
Content model:
Either:
In any order, but at least one of:
<artset> elements ()
<artwork> elements ()
<dl> elements ()
<figure> elements ()
<ol> elements ()
<sourcecode> elements ()
<t> elements ()
<ul> elements ()
Or:
In any order, but at least one of:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
"anchor" Attribute
Document-wide unique identifier for this quotation.
"cite" Attribute
The source of the citation. This must be a URI. If the "quotedFrom" attribute is given, this URI will be
used by processing tools as the link for the text of that attribute.
"quotedFrom" Attribute
Name of person or document the text in this element is quoted from. A formatter should render this
as visible text at the end of the quotation.
<boilerplate>
Holds the boilerplate text for the document. This element is filled in by the prep tool.
This element contains <section> elements. Every <section>
element in this element must have the "numbered" attribute set to "false".
This element appears as a child element of <front> ().
Content model:
One or more <section> elements ()<br>
Forces a line break. Since the layout and column widths of a document vary from
one rendering to another, authors should use this element sparingly and
consider its effect in all of the likely renderings. In some cases a U+200B,
ZERO WIDTH SPACE character as a hint as a place where a block of text might be
broken is a better choice.
This element appears as a child element of <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <strong> (), <t> (), <td> (), <th> (), <title> (), and <tt> ().
Content model: this element does not have any contents.<contact>
Provides information about a contact, such as a contributor to be
mentioned in an "Acknowledgements" section.
This element appears as a child element of <section> () and <t> ().
Content model:In this order:
One optional <organization> element ()
One optional <address> element ()
"anchor" Attribute
Document-wide unique identifier for this comment.
"asciiFullname" Attribute
See the corresponding attribute on <author> element
().
"asciiInitials" Attribute
See the corresponding attribute on <author> element
().
"asciiSurname" Attribute
See the corresponding attribute on <author> element
().
"fullname" Attribute
See the corresponding attribute on <author> element
().
"initials" Attribute
See the corresponding attribute on <author> element
().
"surname" Attribute
See the corresponding attribute on <author> element
().
<country>
Gives the country name or code in a postal address.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the country name.
<cref>
Represents a comment.
Comments can be used in a document while it is work in progress. They
might appear either inline and visually highlighted, at the end of the document,
or not at all, depending on the formatting tool.
This element appears as a child element of <annotation> (), <blockquote> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), and <tt> ().
Content model:
In any order:
Text
<br> elements ()
<em> elements ()
<eref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
"anchor" Attribute
Document-wide unique identifier for this comment.
"display" Attribute
Suggests whether or not the comment should be displayed by formatting tools. This might be
set to "false" if you want to keep a comment in a document after the contents of the comment
have already been dealt with.
Cross-referencing () a comment with
"display" set to "false" is an error.
Allowed values:
"true" (default)
"false"
"source" Attribute
Holds the "source" of a comment, such as the name or the initials
of the person who made the comment.
<date>
Provides information about the publication date.
This element is used for two cases: the boilerplate of the document
being produced, and inside bibliographic references that use the <front> element.
Boilerplate for Internet-Drafts and RFCs:
This element defines the date of publication for the current document (Internet-Draft or RFC).
When producing Internet-Drafts, the prep tool uses this date to compute the expiration date (see ).
When one or more of "year",
"month", or "day" are left out, the prep tool will attempt to use the
current system date if the attributes that are present are consistent with that
date.
In dates in <rfc> elements, the month must be a number or a month in English.
The prep tool will silently change text month names to numbers.
Similarly, the year must be a four-digit number.
When the prep tool is used to create Internet-Drafts, it will reject a submitted Internet-Draft that has a <date>
element in the boilerplate for itself that is anything other than today. That is, the tool
will not allow a submitter to specify a date other than the day of submission. To avoid this problem,
authors might simply not include a <date> element in the boilerplate.
Bibliographic references:
In dates in <reference> elements, the date information can have prose text for the month or year.
For example, vague dates (year="ca. 2000"), date ranges (year="2012-2013"),
non-specific months (month="Second quarter"), and so on are allowed.
This element appears as a child element of <front> ().
Content model: only text content."day" Attribute
The day of publication.
"month" Attribute
The month or months of publication.
"year" Attribute
The year or years of publication.
<dd>
The definition part of an entry in a definition list.
This element appears as a child element of <dl> ().
Content model:
Either:
In any order, but at least one of:
<artset> elements ()
<artwork> elements ()
<aside> elements ()
<dl> elements ()
<figure> elements ()
<ol> elements ()
<sourcecode> elements ()
<t> elements ()
<table> elements ()
<ul> elements ()
Or:
In any order, but at least one of:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
"anchor" Attribute
Document-wide unique identifier for this definition.
<displayreference>
This element gives a mapping between the anchor of a reference and a name that will be displayed instead.
This allows authors to display more mnemonic anchor names for automatically included references.
The mapping in this element only applies to <xref> elements whose format is "default".
For example, if the reference uses the anchor "RFC6949", the following would cause that anchor in the body
of displayed documents to be "RFC-dev":
]]>
If a reference section is sorted, this element changes the sort order.
Prep tools add a "derivedAnchor" attribute to the corresponding <reference> element with the display anchor.
This element appears as a child element of <back> ().
Content model: this element does not have any contents."target" Attribute (Mandatory)
This attribute must be the name of an anchor in a <reference> or <referencegroup> element.
"to" Attribute (Mandatory)
This attribute is a name that will be displayed as the anchor instead of the anchor that is given
in the <reference> element. The string given must start with one of the following
characters: 0-9, a-z, or A-Z. The other characters in the string must be 0-9, a-z, A-Z, "-", ".", or "_".
<dl>
A definition list. Each entry has a pair of elements: a term (<dt>) and
a definition (<dd>).
(This is slightly different and simpler than the model used in HTML, which allows for multiple terms for
a single definition.)
This element appears as a child element of <abstract> (), <aside> (), <blockquote> (), <dd> (), <li> (), <note> (), <section> (), <td> (), and <th> ().
Content model:
One or more sequences of:
One <dt> element
One <dd> element
"anchor" Attribute
Document-wide unique identifier for the list.
"indent" Attribute
Default value:
3
Indicates the indentation to be used for the rendering of the second and
following lines of the item (the first line starts with the term, and is not indented).
The indentation amount is interpreted as characters when rendering
plain-text documents, and en-space units when rendering in formats that have
richer typographic support such as HTML or PDF.
One en-space is assumed to be the length of 0.5 em-space in CSS units.
"newline" Attribute
The "newline" attribute defines whether or not the term appears on the same line as the definition.
newline="false" indicates that the term is to the left of the definition, while newline="true"
indicates that the term will be on a separate line.
Allowed values:
"false" (default)
"true"
"spacing" Attribute
Defines whether or not there is a blank line between entries. spacing="normal"
indicates a single blank line, while spacing="compact" indicates no space between.
Allowed values:
"normal" (default)
"compact"
<dt>
The term being defined in a definition list.
This element appears as a child element of <dl> ().
Content model:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
"anchor" Attribute
Document-wide unique identifier for this term.
<em>
Indicates text that is semantically emphasized. Text enclosed within this element will be displayed as italic after processing.
This element can be combined with other character formatting elements, and the
formatting will be additive.
This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <li> (), <name> (), <refcontent> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), <tt> (), and <xref> ().
Content model:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
<email>
Provides an email address.
The value is expected to be the addr-spec defined in .
This element appears as a child element of <address> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the author's email address. This is only used if the email address has
any internationalized components.
<eref>
Represents an "external" link (as specified in the "target" attribute).
This is useful for embedding URIs in the body of a document.
If the <eref> element has non-empty text content, formatters should use the content as the displayed text that is linked.
Otherwise, the formatter should use the value of the "target" attribute as the displayed text.
Formatters will link the displayed text to the value of the "target" attribute in a manner appropriate for the output format.
For example, with an input of:
.
]]>
An HTML formatter might generate:
http://www.example.com/reports/r12.html.
]]>
With an input of:
in this interesting report.
]]>
An HTML formatter might generate:
in this interesting report.
]]>This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), and <tt> ().
Content model: only text content."brackets" Attribute
Determines whether the formatter should automatically enclose the URI
in angle brackets ("angle") or not (default of "none").
Allowed values:
"none" (default)
"angle"
"target" Attribute (Mandatory)
URI of the link target .
This must begin with a scheme name (such as "https://") and thus not be relative to the URL of the current document.
<figure>
Contains a figure with a caption with the figure number.
If the element contains a <name> element, the caption will also show that name.
This element appears as a child element of <aside> (), <blockquote> (), <dd> (), <li> (), <section> (), <td> (), and <th> ().
Content model:In this order:
One optional <name> element ()
Optional <iref> elements ()
In any order, but at least one of:
<artset> elements ()
<artwork> elements ()
<sourcecode> elements ()
"align" Attribute
Deprecated.
Note: does not affect title or <artwork> alignment.
Allowed values:
"left" (default)
"center"
"right"
"anchor" Attribute
Document-wide unique identifier for this figure.
"suppress-title" Attribute
Deprecated.
Allowed values:
"true"
"false" (default)
<front>
Represents the "front matter": metadata (such as author information),
the Abstract, and additional notes.
This element appears as a child element of <reference> () and <rfc> ().
Content model:In this order:
One <title> element ()
Optional <seriesInfo> elements ()
One or more <author> elements ()
One optional <date> element ()
Optional <area> elements ()
Optional <workgroup> elements ()
Optional <keyword> elements ()
One optional <abstract> element ()
Optional <note> elements ()
One optional <boilerplate> element ()
One optional <toc> element ()
<iref>
Provides terms for the document's index.
Index entries can be either regular entries (when just the "item"
attribute is given) or nested entries (by specifying "subitem" as well),
grouped under a regular entry.
Index entries generally refer to the exact place where the <iref> element
occurred. An exception is the occurrence as a child element of
<section>, in which case the whole section is
considered to be relevant for that index entry. In some formats, index
entries of this type might be displayed as ranges.
When the prep tool is creating index content, it preserves the case of each item and subitem.
The index is sorted in conventional alphabetical order disregarding case.
This element appears as a child element of <annotation> (), <aside> (), <blockquote> (), <dd> (), <dt> (), <em> (), <figure> (), <li> (), <name> (), <section> (), <strong> (), <sub> (), <sup> (), <t> (), <table> (), <td> (), <th> (), and <tt> ().
Content model: this element does not have any contents."item" Attribute (Mandatory)
The item to include.
"primary" Attribute
Setting this to "true" declares the occurrence as "primary",
which might cause it to be highlighted in the index.
There is no restriction on the number of occurrences that can be "primary".
Allowed values:
"true"
"false" (default)
"subitem" Attribute
The subitem to include.
<keyword>
Specifies a keyword applicable to the document.
Note that each element should only contain a single keyword; for multiple keywords, the
element can simply be repeated.
Keywords are used both in the RFC Index and in the metadata of generated
document representations.
This element appears as a child element of <front> ().
Content model: only text content.<li>
A list element, used in <ol> and <ul>.
This element appears as a child element of <ol> () and <ul> ().
Content model:
Either:
In any order, but at least one of:
<artset> elements ()
<artwork> elements ()
<blockquote> elements ()
<dl> elements ()
<figure> elements ()
<ol> elements ()
<sourcecode> elements ()
<t> elements ()
<table> elements ()
<ul> elements ()
Or:
In any order, but at least one of:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
"anchor" Attribute
Document-wide unique identifier for this list item.
<link>
A link to an external document that is related to the RFC.
The following are the supported types of external documents that can be pointed to in
a <link> element:
The current International Standard Serial Number (ISSN) for the RFC Series.
The value for the "rel" attribute is "item".
The link should use the form "urn:issn:".
The Digital Object Identifier (DOI) for this document.
The value for the "rel" attribute is "describedBy".
The link should use the form specified in ;
this is expected to change in the future.
The Internet-Draft that was submitted to the RFC Editor to become the published RFC.
The value for the "rel" attribute is "convertedFrom".
The link should be to an IETF-controlled web site that retains copies of Internet-Drafts.
A representation of the document offered by the document author.
The value for the "rel" attribute is "alternate".
The link can be to a personally run web site.
In RFC production mode, the prep tool needs to check the values for <link> before an RFC is published.
In draft production mode, the prep tool might remove some <link> elements during the draft submission process.
This element appears as a child element of <rfc> ().
Content model: this element does not have any contents."href" Attribute (Mandatory)
The URI of the external document.
"rel" Attribute
The relationship of the external document to this one. The relationships are taken from
the "Link Relations" registry maintained by IANA .
<middle>
Represents the main content of the document.
This element appears as a child element of <rfc> ().
Content model:
One or more <section> elements ()<name>
The name of the section, note, or figure. This name can
indicate markup of flowing text (for example, including references or
making some characters use a fixed-width font).
This element appears as a child element of <figure> (), <note> (), <references> (), <section> (), and <table> ().
Content model:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
<note>
Creates an unnumbered, titled block of text that appears after the Abstract.
It is usually used for additional information to reviewers (Working
Group information, mailing list, ...) or for additional publication
information such as "IESG Notes".
This element appears as a child element of <front> ().
Content model:In this order:
One optional <name> element ()
In any order, but at least one of:
<dl> elements ()
<ol> elements ()
<t> elements ()
<ul> elements ()
"removeInRFC" Attribute
If set to "true", this note is marked in the prep tool with text indicating that it should be
removed before the document is published as an RFC.
That text will be "This note is to be removed before publishing as an RFC."
Allowed values:
"true"
"false" (default)
<ol>
An ordered list. The labels on the items will be either a number or a letter, depending
on the value of the type attribute.
This element appears as a child element of <abstract> (), <aside> (), <blockquote> (), <dd> (), <li> (), <note> (), <section> (), <td> (), and <th> ().
Content model:
One or more <li> elements ()"anchor" Attribute
Document-wide unique identifier for the list.
"group" Attribute
When the prep tool sees an <ol> element with a "group" attribute that has already been seen,
it continues the numbering of the list from where the previous list with the same
group name left off.
If an <ol> element has both a "group" attribute and a "start" attribute, the group's
numbering is reset to the given start value.
"indent" Attribute
The indentation of the list elements relative to the start of the list item number.
With indent='adaptive', the widest list item number determines the indentation.
A numeric value is interpreted as characters when rendering plain-text documents, and en-space units otherwise.
Only non-negative integer indentation is allowed.
Allowed values:
text
"adaptive" (default)
Allowed values:
"adaptive" (default)
"spacing" Attribute
Defines whether or not there is a blank line between entries. spacing="normal"
indicates a single blank line, while spacing="compact" indicates no space between.
Allowed values:
"normal" (default)
"compact"
"start" Attribute
The ordinal value at which to start the list. This defaults to "1" and must be an integer of 0 or greater.
"type" Attribute
The type of the labels on list items. If the length of the type value is 1, the
meaning is the same as it is for HTML:
a
Lowercase letters (a, b, c, ...)
A
Uppercase letters (A, B, C, ...)
1
Decimal numbers (1, 2, 3, ...)
i
Lowercase Roman numerals (i, ii, iii, ...)
I
Uppercase Roman numerals (I, II, III, ...)
For types "a" and "A", after the 26th entry, the numbering starts at "aa"/"AA", then
"ab"/"AB", and so on.
If the length of the type value is greater than 1, the value must contain a
percent-encoded indicator and other text.
The value is a free-form text that allows counter values to be
inserted using a "percent-letter" format. For instance, "[REQ%d]"
generates labels of the form "[REQ1]", where "%d" inserts the
item number as a decimal number.
The following formats are supported:
%c
Lowercase letters (a, b, c, ...)
%C
Uppercase letters (A, B, C, ...)
%d
Decimal numbers (1, 2, 3, ...)
%i
Lowercase Roman numerals (i, ii, iii, ...)
%I
Uppercase Roman numerals (I, II, III, ...)
%%
Represents a percent sign
Other formats are reserved for future use. Only one percent encoding other than "%%" is allowed in a type string.
It is an error for the type string to be empty.
For bulleted lists, use the <ul> element.
For lists that have neither bullets nor numbers, use the <ul> element with the
'empty="true"' attribute.
If no type attribute is given, the default type is the same as "type='%d.'".
<organization>
Specifies the affiliation of an author.
This information appears both in the "Author's Address" section and
on the front page (see for more information).
If the value is long, an abbreviated variant can be specified in the
"abbrev" attribute.
This element appears as a child element of <author> () and <contact> ().
Content model: only text content."abbrev" Attribute
Abbreviated variant.
"ascii" Attribute
The ASCII equivalent of the organization's name.
"asciiAbbrev" Attribute
To support abbreviated organization names in both ASCII and non-ASCII contexts.
"showOnFrontPage" Attribute
To support turning off listing organization with author name.
Allowed values:
"true" (default)
"false"
<phone>
Represents a phone number.
The value is expected to be the scheme-specific part of a "tel" URI
(and so does not include the prefix "tel:"), using the "global-number-digits"
syntax. See
for details.
This element appears as a child element of <address> ().
Content model: only text content.<postal>
Contains optional child elements providing postal information.
A postal address can contain only an ordered set of <postalLine> elements,
or only a set of <street>, <city>,
<region>, <code>, and <country>
elements, but not both.
The sub-elements other than <postalLine> and <country> have been deprecated and will likely be removed in a future version.
This element appears as a child element of <address> ().
Content model:
Either:
In any order:
<city> elements ()
<cityarea> elements ()
<code> elements ()
<country> elements ()
<extaddr> elements ()
<pobox> elements ()
<region> elements ()
<sortingcode> elements ()
<street> elements ()
Or:
One or more <postalLine> elements ()
<postalLine>
Represents one line of a postal address. When more than one <postalLine> is given, the prep tool
emits them in the order given.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the text in the address line.
<refcontent>
Text that should appear between the title and the date of a reference. The purpose
of this element is to prevent the need to abuse <seriesInfo> to
get such text in a reference.
For example:
On Being A FoolSelf-published pamphlet
]]>
would render as:
This element appears as a child element of <reference> ().
Content model:
In any order:
Text
<bcp14> elements ()
<em> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<reference>
Represents a bibliographic reference.
This element appears as a child element of <referencegroup> () and <references> ().
Content model:In this order:
One optional <stream> element ()
One <front> element ()
In any order:
<annotation> elements ()
<refcontent> elements ()
<seriesInfo> elements ()
"anchor" Attribute (Mandatory)
Document-wide unique identifier for this reference. Usually, this will
be used both to "label" the reference in the "References" section and
as an identifier in links to this reference entry.
"quote-title" Attribute
Deprecated variant of the "quoteTitle" attribute.
Prep tools turn this attribute into "quoteTitle".
Allowed values:
"true"
"false"
"quoteTitle" Attribute
Specifies whether or not the title in the reference should be quoted.
This can be used to prevent quoting, such as on errata.
Allowed values:
"true" (default)
"false"
"target" Attribute
Holds the URI for the reference.
<referencegroup>
Represents a list of bibliographic references that will be represented as a single reference.
This is most often used to reference STDs and BCPs, where a single reference
(such as "BCP 9") may encompass more than one RFC.
This element appears as a child element of <references> ().
Content model:
One or more <reference> elements ()"anchor" Attribute (Mandatory)
Document-wide unique identifier for this reference group. Usually, this will
be used both to "label" the reference group in the "References" section and
as an identifier in links to this reference entry.
"target" Attribute
Holds an URI for the reference group, analogous to the "target" attribute of <reference>.
Typically used for a reference to a STD which consists of multiple RFCs with their own URLs, but also has its own unique URL.
<references>
Contains a set of bibliographic references.
In the early days of the RFC Series, there was only one "References" section per RFC. This convention
was later changed to group references into two sets, "Normative" and "Informative",
as described in .
This vocabulary supports the split with the <name> child element.
In general, the title should be either "Normative References" or "Informative References".
This element appears as a child element of <back> () and <references> ().
Content model:In this order:
One optional <name> element ()
Either:
One or more <references> elements ()
Or:
In any order:
<reference> elements ()
<referencegroup> elements ()
"anchor" Attribute
An optional user-supplied identifier for this set of references.
<rfc>
This is the root element of the RFCXML vocabulary.
Processors distinguish between RFC mode ("number" attribute being
present) and Internet-Draft mode ("docName" present and "number" absent):
when both are present, "number" takes precedence.
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:
Optional <link> elements ()
One <front> element ()
One <middle> element ()
One optional <back> element ()
"category" Attribute
Document category (see ).
Allowed values:
"std"
"bcp"
"exp"
"info"
"historic"
"consensus" Attribute
Affects the generated boilerplate. Note that the values of "no" and "yes" are deprecated and are
replaced by "false" (the default) and "true".
See and for more information.
Allowed values:
"no"
"yes"
"false" (default)
"true"
"docName" Attribute
For Internet-Drafts, this specifies the draft name (which appears
below the title).
If both the "docName" and "number" attributes are given, the
latter takes precedence (and the draft name indicates the
Internet-Draft from which the document was produced).
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
for further information.
"indexInclude" Attribute
Specifies whether or not a formatter is requested to include an index in generated files.
If the source file has no <iref> elements, an index is
never generated. This option is useful for generating documents where the
source document has <iref> elements but the author no longer
wants an index.
Allowed values:
"true" (default)
"false"
"ipr" Attribute
Represents the Intellectual Property status of the document.
See for details.
"iprExtract" Attribute
Identifies a single section within the document for which extraction "as is"
is explicitly allowed (only relevant for historic values of the "ipr"
attribute).
"number" Attribute
The number of the RFC to be produced.
"obsoletes" Attribute
A comma-separated list of RFC numbers or
Internet-Draft names.
The implemenation has allowed white space around the commas, and one
RFC has Unicode zero-width space characters (U+200b), to work around
a line breaking problem when rendering the RFC.
It would be better to disallow white space and deal with line breaks
while rendering.
The prep tool will parse the attribute value so that incorrect
references can be detected.
"prepTime" Attribute
The date that the XML was processed by a prep tool.
This is included in the XML file just before it is saved to disk.
The value is formatted using the "date-time" format defined in .
The "time-offset" should be "Z".
"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).
"sortRefs" Attribute
Specifies whether or not the prep tool will sort the references in each reference section.
Allowed values:
"true"
"false" (default)
"submissionType" Attribute
The document stream, as described in .
(The RFC Series Editor may change the list of allowed values in the future.)
Allowed values:
"IETF" (default)
"IAB"
"IRTF"
"independent"
"editorial"
"symRefs" Attribute
Specifies whether or not a formatter is requested to use symbolic references (such as "[RFC2119]"). If the
value for this is "false", the references come out as numbers (such as "[3]").
Allowed values:
"true" (default)
"false"
"tocDepth" Attribute
Specifies the number of levels of headings that a formatter is requested to include in the table of contents; the default is "3".
"tocInclude" Attribute
Specifies whether or not a formatter is requested to include a table of contents in generated files.
Allowed values:
"true" (default)
"false"
"updates" Attribute
A comma-separated list of RFC numbers or
Internet-Draft names.
The implemenation has allowed white space around the commas, and one
RFC has Unicode zero-width space characters (U+200b), to work around
a line breaking problem when rendering the RFC.
It would be better to disallow white space and deal with line breaks
while rendering.
The prep tool will parse the attribute value so that incorrect
references can be detected.
"version" Attribute
Specifies the version of RFCXML syntax used in this document. The only expected value (for now) is "3".
<section>
Represents a section (when inside a <middle> element) or an appendix (when inside a
<back> element).
Subsections are created by nesting <section> elements inside <section> elements.
Sections are allowed to be empty.
This element appears as a child element of <back> (), <boilerplate> (), <middle> (), <section> (), and <toc> ().
Content model:In this order:
One optional <name> element ()
In any order:
<artset> elements ()
<artwork> elements ()
<aside> elements ()
<author> elements ()
<blockquote> elements ()
<contact> elements ()
<dl> elements ()
<figure> elements ()
<iref> elements ()
<ol> elements ()
<sourcecode> elements ()
<t> elements ()
<table> elements ()
<ul> elements ()
Optional <section> elements ()
"anchor" Attribute
Document-wide unique identifier for this section.
"numbered" Attribute
If set to "false", the formatter is requested to not display a section number. The prep tool will verify that such a
section is not followed by a numbered section in this part of the document and will verify that the section is a
top-level section. Descendant sections of unnumbered sections are unnumbered by definition.
Allowed values:
"true" (default)
"false"
"removeInRFC" Attribute
If set to "true", this note is marked in the prep tool with text indicating that it should be
removed before the document is published as an RFC.
That text will be "This note is to be removed before publishing as an RFC."
Allowed values:
"true"
"false" (default)
"toc" Attribute
Indicates to a formatter whether or not the section is to be included in a
table of contents, if such a table of contents is produced. This only takes effect if the level of the section would have
appeared in the table of contents based on the "tocDepth" attribute of the
<rfc> element, and of course only if the table of contents
is being created based on the "tocInclude" attribute of the
<rfc> element. If this is set to "exclude", any section
below this one will be excluded as well. The "default" value indicates
inclusion of the section if it would be included by the tocDepth attribute of the
<rfc> element.
Allowed values:
"include"
"exclude"
"default" (default)
<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 <front> () and <reference> ().
Content model: this element does not have any contents."asciiName" Attribute
The ASCII equivalent of the name field.
"asciiValue" Attribute
The ASCII equivalent of the value field.
"name" Attribute (Mandatory)
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".
Some of the values for "name" interact as follows:
A <front> element that has a <seriesInfo> element
that has the name "Internet-Draft" cannot also have a <seriesInfo>
element that has the name "RFC".
The <seriesInfo> element can contain the DOI for the referenced document.
This cannot be used when the <seriesInfo>
element is an eventual child element of an <rfc> element --
only as an eventual child of a <reference> element.
The "value" attribute should use the form specified in .
"status" Attribute
The status of this document. The currently known values are "standard", "informational", "experimental", "bcp", "fyi", and "full-standard".
The RFC Series Editor may change this list in the future.
"stream" Attribute
The stream (as described in ) that originated the document.
(The RFC Series Editor may change this list in the future.)
Allowed values:
"IETF"
"IAB"
"IRTF"
"independent"
"editorial"
"value" Attribute (Mandatory)
The identifier within the series specified by the "name" attribute.
For BCPs, FYIs, RFCs, and STDs, this is the number within the series.
For Internet-Drafts, it is the full draft name (ending with the two-digit
version number). For DOIs, the value is given, such as "10.17487/rfc1149",
as described in .
The name in the value should be the document name without any file
extension. For Internet-Drafts, the value for this attribute should
be "draft-ietf-somewg-someprotocol-07", not
"draft-ietf-somewg-someprotocol-07.txt".
<sourcecode>
This element allows the inclusion of source code into the document.
When rendered, source code is always shown in a monospace font.
When <sourcecode> is a child of <figure> or <section>, it provides
full control of horizontal whitespace and line breaks.
When formatted, it is indented relative to the left margin of the enclosing element.
It is thus useful for source code and formal languages (such as ABNF or the RNC notation used in this document).
(When <sourcecode> is a child of other elements, it flows with the text that surrounds it.)
Tab characters (U+0009) inside of this element are prohibited.
For artwork such as character-based art, diagrams of message layouts, and so on,
use the <artwork> element instead.
Output formatters that do pagination should attempt to keep source code on a single page. This is to prevent
source code that is split across pages from looking like two separate pieces of code.
See for a description of how to deal with issues of using
"&" and "<" characters in source code.
This element appears as a child element of <blockquote> (), <dd> (), <figure> (), <li> (), <section> (), <td> (), and <th> ().
Content model: only text content."anchor" Attribute
Document-wide unique identifier for this source code.
"markers" Attribute
Specifies whether or not the soure code should be displayed between
"<CODE BEGINS>"/"<CODE ENDS>" markers, as described in
.
Note that adding markers is not needed for the languages listed
under "Code Components" on .
Additionally, if the "name" attribute is present, if will be displayed
after "<CODE BEGINS>", as described in .
Allowed values:
"true"
"false" (default)
"name" Attribute
A filename suitable for the contents (such as for extraction to a local file).
This attribute can
be helpful for other kinds of tools (such as automated syntax checkers,
which work by extracting the source code).
Note that the "name" attribute does not need to be unique for <artwork> elements in a
document. If multiple <sourcecode> elements have the same "name" attribute, a formatter might
assume that the elements are all fragments of a single file, and such a formatter can
collect those fragments for later processing.
"src" Attribute
The URI reference of a source file .
It is an error to have both a "src" attribute and content in the <sourcecode> element.
"type" Attribute
Specifies the type of the source code. The value of this attribute is free text with
certain values designated as preferred.
The RFC Editor web site has a list of the preferred values at ).
That list is updated over time. Thus, a consumer of RFCXML should not cause a failure when it
encounters an unexpected type or no type is specified.
<stream>
The document stream, one of IETF, IAB, IRTF, independent, or editorial.
This element appears as a child element of <reference> ().
Text
The name of the document stream.
The stream name.
This element appears as a child element of <reference> ().
Content model:
Optionally:
Either:
"IETF"
Or:
"IAB"
Or:
"IRTF"
Or:
"independent"
Or:
"editorial"
<strong>
Indicates text that is semantically strong. Text enclosed within this element will be displayed as bold after processing.
This element can be combined with other character formatting elements, and the
formatting will be additive.
This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <refcontent> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), <tt> (), and <xref> ().
Content model:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
<sub>
Causes the text to be displayed as subscript, approximately half a letter-height lower than normal text.
This element can be combined with other character formatting elements, and the
formatting will be additive.
This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <refcontent> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), <tt> (), and <xref> ().
Content model:
In any order:
Text
<bcp14> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
<sup>
Causes the text to be displayed as superscript, approximately half a letter-height higher than normal text.
This element can be combined with other character formatting elements, and the
formatting will be additive.
This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <refcontent> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), <tt> (), and <xref> ().
Content model:
In any order:
Text
<bcp14> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<xref> elements ()
<t>
Contains a paragraph of text.
This element appears as a child element of <abstract> (), <aside> (), <blockquote> (), <dd> (), <li> (), <note> (), <section> (), <td> (), and <th> ().
Content model:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<contact> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
"anchor" Attribute
Document-wide unique identifier for this paragraph.
"hangText" Attribute
Deprecated. Instead, use <dd> inside of a definition list (<dl>).
"indent" Attribute
The indentation of the text element.
A numeric value is interpreted as characters when rendering plain-text documents, and en-space units otherwise.
Only non-negative integer indentation is allowed.
"keepWithNext" Attribute
Acts as a hint to the output formatters that do pagination to do a best-effort attempt to
keep the paragraph with the next element, whatever that happens to be. For example, the
HTML output @media print CSS ("CSS" refers to Cascading Style Sheets) might translate this to page-break-after: avoid. For PDF, the
paginator could attempt to keep the paragraph with the next element. Note: this attribute
is strictly a hint and not always actionable.
Allowed values:
"false" (default)
"true"
"keepWithPrevious" Attribute
Acts as a hint to the output formatters that do pagination to do a best-effort attempt to
keep the paragraph with the previous element, whatever that happens to be. For example,
the HTML output @media print CSS might translate this to page-break-before: avoid. For
PDF, the paginator could attempt to keep the paragraph with the previous element. Note:
this attribute is strictly a hint and not always actionable.
Allowed values:
"false" (default)
"true"
<table>
Contains a table with a caption with the table number.
If the element contains a <name> element, the caption will also show that name.
Inside the <table> element is, optionally, a <thead> element to
contain the rows that will be the table's heading and, optionally, a <tfoot> element
to contain the rows of the table's footer. If the XML is converted to a representation that has page
breaks (such as PDFs or printed HTML), the header and footer are meant to appear on each page.
This element appears as a child element of <aside> (), <dd> (), <li> (), and <section> ().
Content model:In this order:
One optional <name> element ()
Optional <iref> elements ()
One optional <thead> element ()
One or more <tbody> elements ()
One optional <tfoot> element ()
"align" Attribute
Controls whether the table appears left justified, centered (default),
or right justified.
The caption will be centered under the table, and the combined table and
caption will be aligned according to the "align" attribute.
Allowed values:
"left"
"center" (default)
"right"
"anchor" Attribute
Document-wide unique identifier for this table.
<tbody>
A container for a set of body rows for a table.
This element appears as a child element of <table> ().
Content model:
One or more <tr> elements ()"anchor" Attribute
Document-wide unique identifier for the tbody.
<td>
A cell in a table row.
This element appears as a child element of <tr> ().
Content model:
Either:
In any order, but at least one of:
<artset> elements ()
<artwork> elements ()
<dl> elements ()
<figure> elements ()
<ol> elements ()
<sourcecode> elements ()
<t> elements ()
<ul> elements ()
Or:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
"align" Attribute
Controls whether the content of the cell appears left justified (default), centered,
or right justified. Note that "center" or "right" will probably only work well in cells with plain text; any
other elements might make the contents render badly.
Allowed values:
"left" (default)
"center"
"right"
"anchor" Attribute
Document-wide unique identifier for the cell.
"colspan" Attribute
The number of columns that the cell is to span. For example, setting "colspan='3'"
indicates that the cell occupies the same horizontal space as three cells of
a row without any "colspan" attributes.
"rowspan" Attribute
The number of rows that the cell is to span. For example, setting "rowspan='3'"
indicates that the cell occupies the same vertical space as three rows.
<tfoot>
A container for a set of footer rows for a table.
This element appears as a child element of <table> ().
Content model:
One or more <tr> elements ()"anchor" Attribute
Document-wide unique identifier for the tfoot.
<th>
A cell in a table row. When rendered, this will normally come out in boldface; other than that,
there is no difference between this and the <td> element.
This element appears as a child element of <tr> ().
Content model:
Either:
In any order, but at least one of:
<artset> elements ()
<artwork> elements ()
<dl> elements ()
<figure> elements ()
<ol> elements ()
<sourcecode> elements ()
<t> elements ()
<ul> elements ()
Or:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
<u> elements ()
<xref> elements ()
"align" Attribute
Controls whether the content of the cell appears left justified (default), centered,
or right justified. Note that "center" or "right" will probably only work well in cells with plain text; any
other elements might make the contents render badly.
Allowed values:
"left" (default)
"center"
"right"
"anchor" Attribute
Document-wide unique identifier for the row.
"colspan" Attribute
The number of columns that the cell is to span. For example, setting "colspan='3'"
indicates that the cell occupies the same horizontal space as three cells of
a row without any "colspan" attributes.
"rowspan" Attribute
The number of rows that the cell is to span. For example, setting "rowspan='3'"
indicates that the cell occupies the same vertical space as three rows.
<thead>
A container for a set of header rows for a table.
This element appears as a child element of <table> ().
Content model:
One or more <tr> elements ()"anchor" Attribute
Document-wide unique identifier for the thead.
<title>
Represents the document title.
When this element appears in the <front> element of the current document,
the title might also appear in page headers or footers. If it is long
(~40 characters), the "abbrev" attribute can be used to specify an
abbreviated variant.
This element appears as a child element of <front> ().
Content model:
In any order:
Text
<br> elements ()
"abbrev" Attribute
Specifies an abbreviated variant of the document title.
"ascii" Attribute
The ASCII equivalent of the title.
<toc>
This element contains the Table of Contents.
It is created automatically by the preptool based on the "tocInclude" and "tocDepth" attributes of
the <rfc> element and the section headers.
In prepared drafts, it has no effect on document rendering and contains no useful information.
In prepared RFCs, it is used as the source for the table of contents.
Optional <section> elements ()This element appears as a child element of <front> ().
Content model:
Optional <section> elements ()<tr>
A row of a table.
This element appears as a child element of <tbody> (), <tfoot> (), and <thead> ().
Content model:
In any order, but at least one of:
<td> elements ()
<th> elements ()
"anchor" Attribute
Document-wide unique identifier for the row.
<tt>
Causes the text to be displayed in a constant-width font.
This element can be combined with other character formatting elements, and the
formatting will be additive.
This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <refcontent> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), and <xref> ().
Content model:
In any order:
Text
<bcp14> elements ()
<br> elements ()
<cref> elements ()
<em> elements ()
<eref> elements ()
<iref> elements ()
<relref> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<xref> elements ()
<u>
In order to insert Unicode characters in contexts that don't explicitly allow Unicide, the Unicode string is enclosed within an <u> element.
The element will be expanded inline based on the value of a "format" attribute.
This provides a generalised means of generating the 6 methods of Unicode renderings listed in , Section 3.4, and also several others found in for instance the RFC Format Tools example rendering of RFC 7700.
This element appears as a child element of <annotation> (), <blockquote> (), <dd> (), <li> (), <t> (), <td> (), and <th> ().
Content model: only text content."anchor" AttributeDocument-wide unique identifier for this <u> element.
"ascii" AttributeThe ASCII equivalent of the content, to be used if the "ascii" keyword is used in the "format" specification.
"format" Attribute
Default value:
"lit-name-num"
The "format" attribute accepts either a simplified format specification, or a full format string with placeholders for the various possible Unicode expansions.
The simplified format consists of dash-separated keywords, where each keyword represents a possible expansion of the Unicode character or string; use for example "<u "lit-num-name">foo</u>" to expand the text to its literal value, code point values, and code point names.
A combination of up to 3 of the following keywords may be used, separated by dashes: "num", "lit", "name", "ascii", "char". The keywords are expanded as follows and combined, with the second and third enclosed in parentheses if present:
ascii
The value of the 'ascii' attribute on the <u> element
char
The literal element text, without quotes
lit
The literal element text, enclosed in quotes
name
The Unicode name(s) of the element text
num
The numeric value(s) of the element text, in U+1234 notation
In order to ensure that no specification mistakes can result for rendering methods that cannot render all Unicode code points, "num" MUST always be part of the specified format.
In order to provide for cases where the simplified format above is insufficient,
without relinquishing the requirement that the number of a code point always must
be rendered, the "format" attribute can also accept a full format string. This
format uses placeholders which consist of any of the key words above enclosed in
curly braces; outside of this, any ascii text is permissible. For example,
will be rendered as
As for the simplified format, "num" MUST always be part of the
specified format in order to ensure that no specification
mistakes can result for rendering methods that cannot render all
Unicode code points,
<ul>
An unordered list. The labels on the items will be symbols picked by the formatter.
This element appears as a child element of <abstract> (), <aside> (), <blockquote> (), <dd> (), <li> (), <note> (), <section> (), <td> (), and <th> ().
Content model:
One or more <li> elements ()"anchor" Attribute
Document-wide unique identifier for the list.
"bare" Attribute
Can only be used with empty="true" (see below).
This attribute controls whether the blank bullet has an horizontal extension or not.
With bare="false", the empty list bullet will still occupy the same space as for empty="false".
With empty="true", there will be no bullet at all, i.e., the list items will have no indentation.
Allowed values:
"true"
"false" (default)
"empty" Attribute
Defines whether or not the label is empty. empty="true" indicates that no label will be shown.
Allowed values:
"false" (default)
"true"
"indent" Attribute
The indentation of the list elements relative to the start of the bullet or bullet text.
A numeric value is interpreted as characters when rendering plain-text documents, and en-space units otherwise.
Only non-negative integer indentation is allowed.
"spacing" Attribute
Defines whether or not there is a blank line between entries. spacing="normal"
indicates a single blank line, while spacing="compact" indicates no space between.
Allowed values:
"normal" (default)
"compact"
<uri>
Contains a web address associated with the author.
The contents should be a valid URI; this most likely will be an "http:" or "https:" URI.
This element appears as a child element of <address> ().
Content model: only text content.<workgroup>
This element is used to specify the Working Group (IETF) or Research Group (IRTF) from which the document originates,
if any. The recommended format is the official name of the Working Group
(with some capitalization).
In Internet-Drafts, this is used in the upper left corner of the boilerplate,
replacing the "Network Working Group" string. Formatting software can
append the words "Working Group" or "Research Group", depending on
the "submissionType" property of the <rfc> element
().
This element appears as a child element of <front> ().
Content model: only text content.<xref>
A reference to an anchor in this document.
Any element that has an anchor can be a reference target.
Formatters that have links (such as HTML and PDF) are likely to render <xref> elements as internal hyperlinks.
When referring to references in the "References" section, it can specify specific sections of this
document, to specific figures, and so on.
The "target" attribute is required.
This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), and <tt> ().
Content model:
In any order:
Text
<em> elements ()
<strong> elements ()
<sub> elements ()
<sup> elements ()
<tt> elements ()
"format" Attribute
This attribute signals to formatters what the desired format of the reference should be.
Formatters for document types that have linking capability should wrap the displayed text in hyperlinks.
"counter"
The "derivedContent" attribute will contain just a counter.
This is used for targets that are
<section>, <figure>, <table>, or items in an ordered list.
Using "format='counter'" where the target is any other type of element is an error.
For example, with an input of:
Protocol Overview
. . .
See Section
for an overview.
]]>
An HTML formatter might generate:
1.7 for an overview.
]]>
"default"
If the element has no content, the "derivedContent" attribute will contain a text fragment that describes the referenced part
completely, such as "XML" for a target that is a <reference>,
or "Section 2" or "Table 4" for a target to a non-reference.
(If the element has content, the "derivedContent" attribute is filled with the content.)
For example, with an input of:
Protocol Overview
. . .
See for an overview.
]]>
An HTML formatter might generate:
Section 1.7 for an overview.
]]>
"none"
There will be no autogenerated text at all (this format only makes
sense if the <xref> element has text content).
For example, with an input of:
Protocol Overview
. . .
See section above
for an overview.
]]>
An HTML formatter might generate:
section above for an overview.
]]>
"title"
If the target is a <reference> element, the "derivedContent" attribute will contain the name of
the reference, extracted from the <title> child of the
<front> child of the reference.
Or, if the target element has a <name> child element, the "derivedContent" attribute will contain the
text content of that <name> element concatenated with the text content of
each descendant node of <name> (that is, stripping out all of the
XML markup, leaving only the text).
Or, if the target element does not contain a <name> child element,
the "derivedContent" attribute will contain the name of the "anchor" attribute of that element
with no other adornment.
Allowed values:
"default" (default)
"title"
"counter"
"none"
"relative" Attribute
Specifies a relative reference to include in the URI in the target reference.
This value must include whatever leading character is needed to create the relative reference;
typically "#" for HTML documents.
"section" Attribute
Specifies a section of the target reference, which must be an external
document of some kind.
If the target is not an RFC or Internet-Draft in the v3 format,
and no "relative" attribute has been provided, it is an error.
"sectionFormat" Attribute
This attribute tells formatters the desired
format of the external reference.
Formatters for document types that have linking capability should wrap each
part of the displayed text in hyperlinks. If there is content
in the <xref> element, that content will be used when
rendering the internal link part of the <xref> rendering, but
will not affect the external link.
"of"
The <xref> element will be displayed as an external link followed by an internal link,
separated by the word 'of'.
The external link will have as its display text the word "Section" followed by a space and the
contents of the "section" attribute.
This will be followed by a space, the word "of", another space,
and an internal link to the relevant <reference> entry, formatted based on the "format" attribute.
"comma"
The <xref> element will be displayed as an internal link followed by an external link,
separated by a comma.
The external link will have as its display text the word "Section" followed by a space
and the contents of the "section" attribute.
The internal link will point to the relevant <reference> entry,
and will be rendered according to the "format" attribute.
"parens"
The <xref> element will be displayed as an internal link followed by an external link within parentheses.
The external link will have as its display text the word "Section" followed by a space
and the contents of the "section" attribute.
The internal link will point to the relevant <reference> entry,
and will be rendered according to the "format" attribute.
"bare"
The <xref> element will be displayed as an external link,
possibly followed by the same link within parentheses.
The first external link will have as its display text only contents of the "section" attribute;
the second link will be present within parentheses only if the <xref> element has any text content,
and will then have the text content as its display text.
This value for the "sectionFormat" attribute is useful when it is desired to express
for instance "Sections 3.2 and 3.3 of [RFC7997]".
Allowed values:
"of" (default)
"comma"
"parens"
"bare"
"target" Attribute (Mandatory)
Identifies the document component being referenced.
The value needs to match the value of the "anchor" attribute of an
element in the document; otherwise, it is an error.
This section lists the elements from the original version of v3 that have been deprecated.<city>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the city name.
<cityarea>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the city area name.
<code>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the postal code.
<extaddr>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
ASCII equivalent for extaddr.
<pobox>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
ASCII equivalent for pobox.
<region>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the region name.
<relref>
Deprecated, use <xref> instead.
Represents a link to a specific part of a document that appears in a <reference> element.
Formatters that have links (such as HTML and PDF) render <relref> elements as external hyperlinks
to the specified part of the reference, creating the link target by combining the base URI from the
<reference> element with the "relative" attribute from this element.
The "target" attribute is required, and it must be the anchor of a <reference> element.
The "section" attribute is required, and the "relative" attribute is optional.
If the reference is not an RFC or Internet-Draft that is in the v3 format, the element needs to have a "relative" attribute;
in this case, the value of the "section" attribute is ignored.
An example of the <relref> element with text content might be:
the protocol overview
for more information.
]]>
An HTML formatter might generate:
the protocol overview
for more information.
]]>This element appears as a child element of <annotation> (), <blockquote> (), <cref> (), <dd> (), <dt> (), <em> (), <li> (), <name> (), <strong> (), <sub> (), <sup> (), <t> (), <td> (), <th> (), and <tt> ().
Content model: only text content."displayFormat" Attribute
This attribute is used to signal formatters what the desired format of the relative reference should be.
Formatters for document types that have linking capability should wrap each part of the displayed text in hyperlinks.
If there is content in the <relref> element, formatters will ignore the value of this attribute.
"of"
A formatter should display the relative reference as the word "Section" followed by a space, the contents of the "section" attribute
followed by a space, the word "of", another space, and the value from the "target" attribute enclosed in square brackets.
For example, with an input of:
for an overview.
]]>
An HTML formatter might generate:
Section 2.3 of
[RFC9999]
for an overview.
]]>
Note that "displayFormat='of'" is the default for <relref>, so it does not need to be given in
a <relref> element if that format is desired.
"comma"
A formatter should display the relative reference as the value from the "target" attribute enclosed in square brackets,
a comma, a space, the word "Section" followed by a space, and the "section" attribute.
For example, with an input of:
,
for an overview.
]]>
An HTML formatter might generate:
RFC9999],
Section 2.3, for an overview.
]]>
"parens"
A formatter should display the relative reference as the value from the "target" attribute enclosed in square brackets,
a space, a left parenthesis, the word "Section" followed by a space, the "section" attribute, and a right parenthesis.
For example, with an input of:
for an overview.
]]>
An HTML formatter might generate:
RFC9999]
(
Section 2.3)
for an overview.
]]>
"bare"
A formatter should display the relative reference as the contents of the "section" attribute
and nothing else. This is useful when there are multiple relative references to a single base reference.
For example:
and
for an overview.
]]>
An HTML formatter might generate:
2.3
and
Section 2.4 of
[RFC9999]
for an overview.
]]>
Allowed values:
"of" (default)
"comma"
"parens"
"bare"
"relative" Attribute
Specifies a relative reference from the URI in the target reference.
This value must include whatever leading character is needed to create
the relative reference; typically, this is "#" for HTML documents.
"section" Attribute (Mandatory)
Specifies a section of the target reference.
If the reference is not an RFC or Internet-Draft in the v3 format, it is an error.
"target" Attribute (Mandatory)
The anchor of the reference for this element. If this value is not an anchor to a
<reference> or <referencegroup> element, it is an error.
If the reference at the target has no URI, it is an error.
<sortingcode>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
ASCII equivalent for sortingcode.
<street>
Deprecated, use <postalLine> instead.
This element appears as a child element of <postal> ().
Content model: only text content."ascii" Attribute
The ASCII equivalent of the street address.
The discussion of the use of SVG can be found in .
This element is part of the namespace "http://www.w3.org/2000/svg".
A common problem authors have with <artwork> and <sourcecode>
elements is that the XML processor returns errors
if the text in the artwork contains either the "&" or "<" character, or the string "]]>".
To avoid these problems, the "&" and "<" characters may be escaped using the strings
"&" and "<", respectively; the "]]>" string can be represented as "]]>".
Alternatively, they may be surrounded in a CDATA structure: "<![CDATA[]]>". For example:
Desired output:
" | "|"
]]>
Using escaping:
allowed-chars = "." | "," | "&" | "<" | ">" | "|"
]]>
Using CDATA:
" | "|"]]]]>
]]>
Using CDATA is not a panacea, but it does help prevent having to use escapes in places where
using escapes can cause other problems, such as difficulty of inclusion from other documents.
This format is based on and thus does not have any
issues representing arbitrary Unicode characters in text content.
The RFC Series Editor may restrict some of the characters that can be used in a particular RFC;
the rules for such restrictions are covered in .
The "name" attribute of the <artwork> element
()
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 for
more information.
The "src" attribute of the <artwork> element can be used to read files from
the local system. Processing tools must be careful to not accept dangerous values for the filename,
particularly those that contain absolute references outside the current directory.
The "type" attribute of the <artwork> and <sourcecode> elements is meant
to encourage formatters to automatically extract known types of content from
an RFC or Internet-Draft. While extraction is probably safe, those tools
might also think that they could further process the extracted content,
such as by rendering artwork or executing code. Doing so without first
sanity-checking the extracted content is clearly a terrible idea
from a security perspective. More generally, a tool that is reading XML input
needs to be suspicious of any content that it intends
to post-process.
When there is an external reference to a URL, a processor or renderer should fetch the content into a sandbox
and should have only a localized impact on the document processing and rendering.
All security considerations related to XML processing are
relevant as well (see ).
IANA maintains the registry of Internet Media Types
at .
This document updates the specification for the Internet Media Type
"application/rfc+xml" from the one in v2 (). The following has been registered with IANA.
Type name:
application
Subtype name:
rfc+xml
Required parameters:
There are no required parameters.
Optional parameters:
"charset": This parameter has identical semantics to the charset
parameter of the "application/xml" Media Type specified in .
Encoding considerations:
Identical to those of "application/xml" as described in .
Security considerations:
As defined in . In addition, as
this Media Type uses the "+xml" convention, it inherits the security
considerations described in .
Interoperability considerations:
Different implementations of this format have had interoperability issues.
It is not expected that publication of this application will cause those
implementations to be fixed.
Published specification:
This specification.
Applications that use this Media Type:
Applications that transform RFCXML to output representations such
as plain text or HTML, plus additional analysis tools.
Fragment identifier considerations:
The "anchor" attribute is used for assigning document-wide unique
identifiers that can be used as shorthand pointers, as described
in .
Additional information:
Deprecated alias names for this type:
None
Magic number(s):
As specified for "application/xml" in .
File extension(s):
.xml or .rfcxml when disambiguation from other XML files is needed
Macintosh file type code(s):
TEXT
Person & email address to contact for further information:
See the Author's Address section of RFC 7991.
Intended usage:
COMMON
Restrictions on usage:
None
Author:
See the Author's Address section of RFC 7991.
Change controller:
RFC Series Editor (rse@rfc-editor.org)
IANA has registered "convertedFrom" in the "Link Relation Types" registry .Relation Name: convertedFromDescription: The document linked to was later converted to the document
that contains this link relation. For example, an RFC can have a link
to the Internet-Draft that became the RFC; in that case, the link
relation would be "convertedFrom".Reference: This document.Notes: This relation is different than "predecessor-version" in that
"predecessor-version" is for items in a version control system. It is also
different than "previous" in that this relation is used for converted resources,
not those that are part of a sequence of resources.Application Data: NoneReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsThe "xml2rfc" Version 3 VocabularyExtensible Markup Language (XML) 1.0 (Fifth Edition)
Latest version available at
.
Informative ReferencesGuidelines to Authors of Internet-DraftsLink RelationsIANARFC Formats and VersionsThe Internet Standards Process -- Revision 3The "data" URL schemeDate and Time on the Internet: TimestampsGuidelines for the Use of Extensible Markup Language (XML) within IETF ProtocolsIETF Rights in ContributionsThe tel URI for Telephone NumbersIETF Rights in ContributionsUniform Resource Identifier (URI): Generic SyntaxAugmented BNF for Syntax Specifications: ABNFRights Contributors Provide to the IETF TrustThe 'mailto' URI SchemeUse of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)Media Type Specifications and Registration ProceduresRFC Series Format Requirements and Future DevelopmentXML Media TypesRFC Style GuideAssigning Digital Object Identifiers to RFCsThe "xml2rfc" Version 2 VocabularyRFC Streams, Headers, and BoilerplatesSVG Drawings for RFCs: SVG 1.2 RFCThe Use of Non-ASCII Characters in RFCs"xml2rfc" Version 3 Preparation Tool DescriptionGuidelines for Authors and Reviewers of Documents Containing YANG Data ModelsRELAX NG Compact Syntaxjjc@jclark.comLegal Provisions Relating to IETF DocumentsIETF TrustLegal Provisions Relating to IETF DocumentsIETF TrustLegal Provisions Relating to IETF DocumentsIETF TrustLegal Provisions Relating to IETF DocumentsIETF TrustLegal Provisions Relating to IETF DocumentsIETF TrustUAX #24: Unicode Script PropertyThe Unicode ConsortiumThe Unicode StandardThe Unicode ConsortiumCoded Character Set -- 7-bit American Standard Code for Information InterchangeAmerican National Standards InstituteXML Inclusions (XInclude) Version 1.0 (Second Edition)
Latest version available at
.
XPointer Framework
Latest version available at
.
The values listed here will be defined by the RFC Series Editor. Those listed here
are believed to be the current values in use.
For RFCs, the "category" attribute ()
determines the "maturity level" (see ).
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 is not needed; when supplied,
it will appear as "Intended Status". Supplying this information can
be useful to reviewers.
This attribute value can take a long list of values, each of which describes an IPR policy for the document
().
The values are not the result of a grand design, but they remain simply for historic
reasons. Of these values, only a few are currently in use; all others are
supported by various tools for backwards compatibility with old source
files.
Disclaimer: THIS ONLY PROVIDES IMPLEMENTATION INFORMATION. IF YOU NEED
LEGAL ADVICE, PLEASE CONTACT A LAWYER.
For further information, refer to .
For the current "Copyright Notice" text, the submissionType attribute of the <rfc> element
()
determines whether a statement about "Code Components" is inserted (which is the
case for the value "IETF", which is the default). Other values,
such as "independent", suppress this part of the text.
The name for these values refers to version 2.0 of the IETF Trust's "Legal Provisions Relating
to IETF Documents", sometimes simply called the "TLP", which went into effect on February 15, 2009 .
Updates to the document were published on September 12, 2009
and on December 28, 2009 ,
modifying the license for code components (see
for further information).
The actual text is located in Section 6 ("Text to Be Included in IETF Documents")
of these documents.
The prep tool automatically produces the "correct" text, depending on the
document's date information (see above):
TLP
starting with publication date
2009-11-01
2010-04-01
This value should be used unless one of the more specific "*trust200902"
values is a better fit. It produces the text in Sections 6.a and 6.b of
the TLP.
This produces the additional text from Section 6.c.i of the TLP:
This document may not be modified, and derivative works of it may
not be created, except to format it for publication as an RFC or
to translate it into languages other than English.
This produces the additional text from Section 6.c.ii of the TLP:
This document may not be modified, and derivative works of it may
not be created, and it may not be published except as an Internet-Draft.
This produces the additional text from Section 6.c.iii of the TLP, frequently
called the "pre-5378 escape clause" referring to changes introduced in :
This document may contain material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this document may not be modified outside
the IETF Standards Process, and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC or to translate it into languages
other than English.
See Section 4 of
for further information about when to use this value.
The attribute values "trust200811",
"noModificationTrust200811", and
"noDerivativesTrust200811"
are similar to their "trust200902" counterparts, except that they use text
specified in .
The attribute values "full3978",
"noModification3978", and
"noDerivatives3978"
are similar to their counterparts above, except that they use text
specified in .
The attribute values "full3667",
"noModification3667", and
"noDerivatives3667"
are similar to their counterparts above, except that they use text
specified in .
The attribute values "full2026" and
"noDerivativeWorks2026"
are similar to their counterparts above, except that they use text
specified in Section 10 of .
The special value "none"
was also used back then; it denied the IETF any rights beyond publication
as an Internet-Draft.
The RFC Editor publishes documents from different "document streams", of which
the "IETF stream" is the most prominent. Other streams are the "Independent Submissions stream"
(used for things such as discussion of Internet-related technologies that are
not part of the IETF agenda),
the "IAB stream" (Internet Architecture Board), and the "IRTF stream" (Internet Research Task Force).
The values for the attribute are "IETF" (the default value),
"independent", "IAB", "IRTF", and "editorial".
Historically, this attribute did not affect the final appearance of RFCs, except for
subtle differences in copyright notices.
Nowadays (as of ), the stream name appears in the first
line of the front page, and it also affects the text in the "Status of This Memo"
section.
For current documents, setting the "submissionType" attribute will
have the following effect:
For RFCs, the stream name appears in the upper left corner of the
first page (in Internet-Drafts, this is either "Network Working Group"
or the value of the <workgroup> element).
For RFCs, it affects the whole "Status of This Memo" section (see
).
For all RFCs and Internet-Drafts, it determines whether the "Copyright
Notice" section mentions the Copyright on Code Components (see Section 6 of the TLP
("Text to Be Included in IETF Documents")).
For some of the publication streams (see ),
the "Status of This Memo" section depends on whether there was a consensus
to publish (again, see ).
The consensus attribute
can be used to supply this information. The acceptable values are "true" (the default) and "false".
The effect of this value for the various streams is:
"independent": none.
"IAB": mention that there was an IAB consensus.
"IETF": mention that there was an IETF consensus.
"IRTF": mention that there was a research group consensus (where
the name of the research group is extracted from the <workgroup>
element).
"editorial": mention RSWG and RSAB approval.
This section describes topics that are specific to v3 processing tools.
Note that there is some
discussion of tools in the main body of the document as well. For example, some elements
have descriptions of how a processing tool might create output from the element.The expected design of the tools that will be used with v3 documents includes:
A "prep tool" that takes a v3 document, makes many checks, adds and changes many attribute
values, and creates a file that is a "prepared document". The prepared document is a valid v3
document. The prep tool is described in .The prep tool was expected to have many modes, although only RFC and Draft modes are implemented:
RFC mode -- The mode used by the RFC Editor to process the input from one of
the RFC streams and to process XML produced during the RFC editing process.
The restrictions on the canonical XML for RFCs, as well as how the non-canonical formats
will look, are described at
<https://www.rfc-editor.org/rse/wiki/doku.php?id=design:format-and-content-rfcs>.
Draft mode -- The mode used by the Internet-Draft submission tool. The restrictions
for the XML from this mode will be described later.
Diagnostic mode -- A mode that can be used by document authors to look for errors
or warnings before they submit their documents for publication.
Consolidation mode -- Produces output where no external resources are required to render the file
output. This includes expanding the XInclude entities and DTD entities in place, and changing all
elements that have "src" attributes with external links into either "data:" URI or
content for the element, as specified in .
Formatting tools that will create HTML, PDF, plain text, and possibly other output formats.
These formatters will be created by the IETF, but others can create such tools as well.
The IETF tools are expected to take prepared documents as input.
There may also be processing tools that are meant to run on the computers of
authors. These tools may be used to produce interim versions of the non-canonical representations
so that authors can see how their XML might later be rendered, to
create documents in representations different than those supported by the RFC Editor,
to possibly create documents that are not meant to be Internet-Drafts or RFCs,
and to convert XML that has external information into XML that has that external information
included.The prep tool is expected to have clear error reporting, giving more
context than just a line number. For example, the error messages should differentiate between
errors in XML and those from the v3 format.In v2 (), the grammar was specified as a DTD. In v3, the grammar is specified only as RELAX
Next Generation (RNG). This means that tools need to work from the RNG, not from a DTD.
Some of the features of the v3 grammar cannot be specified as a DTD.All tools for the v3 format are expected to support XInclude .
XInclude specifies a processing model and syntax for general-purpose inclusion of information
that is either on the Internet or local to the user's computer.
In the v3 syntax, XInclude is expressed as the <xi:include> element. To use this
element, you need to include the "xi" namespace in the <rfc> element; that is, you need to specify
as one of the attributes in the <rfc> element.The most common way to use <xi:include> is to pull in references
that are already formed as XML. This can be done from bib.ietf.org.
For example, if a document has three normative
references, all RFCs, the document might contain:
]]><xi:include> can be used anywhere an XML element could be used (but not where
free text is used). For example, if three Internet-Drafts are all including a particular paragraph
or section verbatim, that text can be kept either in a file or somewhere on the web and can be
included with <xi:include>. An example of pulling something from the local disk would
be:
]]>
In general, XInclude should be used instead of ENTITY references and XML Processing Instructions (PIs)
that allow external inclusions.
People writing and reading Internet-Drafts and RFCs often want to make reference to
specific locations in those documents. In the case of RFC authors, it is common
to want to reference another part of their document, such as "see Section 3.2 of this
document." Readers, on the other hand, want to reference parts of documents that they
didn't write, such as "see Section 3.2 of RFC 6949."
The XML vocabulary in this document attempts to support both sets of people.Authors can leave anchors in a document that can later be used for references with the "anchor"
attribute. Anchors can be included in the numerous elements. The
author can then refer to that anchor in the "target" attribute of the <xref>
element.Readers can refer to any element that has an "anchor" attribute by that attribute. Note, however,
that most of the time, elements won't have anchors. In the common case, the reader wants to refer to
an element that does not have an "anchor" attribute, but that element has a "pn" attribute.Processing tools add the "pn" attribute to many elements during processing. This attribute and
its value are automatically generated by the tool if the attribute is not there; if the
attribute is already there, the tool may replace the value.
In the HTML representation of this XML vocabulary, both anchors and "pn" attributes will
be used in the "id" attributes of elements. Thus, there can be no overlap between the names entered
in "anchor" attributes, in "slugifiedName" attributes, and those that are generated for the "pn" attributes.
Also, there are some values for the "anchor" values that are reserved for sections, and those
sections can only have those anchor values.The following rules prevent this overlap:
"pn" for regular sections always has the format "s-nnn", where "nnn" is the section number, or the appendix
identifier (which starts with a letter).
For example, this would be "s-2.1.3" for Section 2.1.3 and "s-a" for Appendix A.
For the <abstract> element, it is always "s-abstract".
For the <note> element, it is always "s-note-nnn", where "nnn" is a sequential value.
For sections in the <boilerplate> element, it is always "s-boilerplate-nnn", where "nnn" is a sequential value.
"pn" for <references> elements
has the format "s-nnn". It is important to note that "nnn" is a number, not letters,
even though the <references> appear in the back.
It is the number that is one higher than the highest top-level section number in <middle>.
If there are two or more <references>, "nnn" will include a dot as if
the <references> are a subsection of a section that is
numbered one higher than the highest top-level section number in <middle>.
"pn" for <figure> elements
always has the format "f-nnn", where "nnn" is the figure number.
For example, this would be "f-5" for Figure 5.
"pn" for <iref> elements
always has the format "i-ttt-nnn", where "ttt" is the
slugified item (plus a hyphen and the slugified subitem if there is a subitem),
and "nnn" is the instance of that item/subitem pair.
For example, this would be
"i-foo-1" for "<iref item='foo'>" and
"i-foo-bar-1" for "<iref item='foo' subitem='bar'>".
"pn" for <table> elements
always has the format "t-nnn", where "nnn" is the table number.
For example, this would be "t-5" for Table 5.
"pn" for all elements not listed above
always has the format "p-nnn-mmm", where "nnn" is the section number
and "mmm" is the relative position in the section.
For example, this would be "p-2.1.3-7" for the seventh part number in Section 2.1.3.
"slugifiedName" was supposed to have the format "n-ttt", where "ttt" is the text of the name after
slugification, but was implemented as "name-ttt".
For example, this would be "n-protocol-overview" or "name-protocol-overview" for the name "Protocol Overview".
The actual conversions done in slugification will be specified at a later time.
Anchors must never overlap with any of the above. The easiest way to assure that is to
not pick an anchor name that starts with a single letter followed by a hyphen. If an anchor
does overlap with one of the types of names above, the processing tool will reject the
document.
Many elements in the v3 vocabulary have new attributes whose role is to hold values
generated by the prep tool. These attributes can exist in documents that are input to the
prep tool; however, any of these attributes might be added, removed, or changed by the
prep tool. Thus, it is explicitly unsafe for a document author to include these attributes
and expect that their values will survive processing by the prep tool.The attributes that are controlled by the prep tool are:
The "pn" attribute -- The number for this item within the section. The numbering
is shared with other elements of a section. The "pn" attribute is added to these elements:
<abstract>, <artset>,
<artwork>, <aside>,
<blockquote>, <dd>,
<dl>, <dt>,
<figure>, <iref>,
<note>, <ol>,
<references>, <section>,
<sourcecode>, <t>,
<table>, <u>, and
<ul>
.
originalSrc -- This attribute is filled with the original value of the "src"
attribute if that attribute is removed by the prep tool in <artwork>, <figure>,
and <sourcecode>.
<name> "slugifiedName" attribute -- This attribute is filled with a "slugified" version of
the text in the element. This attribute can be used in the output formats for elements that have
both names and numbers.
"derivedLink" attribute -- This attribute is filled with the link that is derived
from combining the URI from the reference and the relative part that is either a copy of the
"relative" attribute or a section number derived from the "section" attribute.
This attribute is added to <relref> and <xref>.
<rfc> "expiresDate" attribute -- This attribute is filled with the date that an Internet-Draft
expires. The date is in the format yyyy-mm-dd.
<rfc> "mode" attribute -- This attribute is filled with a string that indicates what
mode the prep tool was in when it processed the XML, such as whether it was processing a file
to become an Internet-Draft or an RFC.
"scripts" attribute -- This attribute in the <rfc> element is filled with a list of scripts needed to
render this document. The list is comma-separated, with no spaces allowed. The order is
unimportant. The names come from . For example, if the document has Chinese
characters in it, the value might be "Common,Latin,Han".
"derivedContent" attribute -- This attribute is filled in if there is no content in
the <xref> or <relref> element. The value for this attribute is based on the value in the "displayFormat"
attribute.
Examples of how this value is filled can be found in .
"derivedAnchor" attribute -- This attribute in an <xref> element is filled in with the
display anchor from the corresponding <displayreference> element.
If there is no <displayreference>, this attribute is a copy of the "anchor" attribute.
"derivedCounter" -- This attribute in a <li> element in an ordered
list is filled in with the item number in the list.
In addition, note that the contents of the <boilerplate> element
are controlled by the prep tool.The following is the RELAX NG schema for the v3 format.
Thanks to everybody who reviewed this document and provided feedback and/or
specification text. Thanks especially go to Paul Hoffman for preparing the original
version of this document, to Julian Reschke for editing v2 ()
and to those who provided feedback on that document.
Many of the changes between this document and RFC 7991 came from the
work of Henrik Levkowetz.
We also thank Marshall T. Rose for both the original design and the reference
implementation of the "xml2rfc" processor.