MAY">
MUST">
MUST NOT">
OPTIONAL">
RECOMMENDED">
REQUIRED">
SHALL">
SHALL NOT">
SHOULD">
SHOULD NOT">
]>
The 'XML2RFC' version 2 Vocabularygreenbytes GmbHHafenweg 16MuensterNW48155Germanyjulian.reschke@greenbytes.dehttp://greenbytes.de/tech/webdav/
This document defines the 'XML2RFC' version 2 vocabulary; an XML-based
language used for writing RFCs and Internet-Drafts.
Version 2 represents the current state of the vocabulary (as implemented
by several tools and as used by the RFC Editor) around 2014.
Discussion of this draft takes place on the XML2RFC
mailing list (xml2rfc@ietf.org), which has its home page at
.
This document describes version 2 ("v2") of the 'XML2RFC' vocabulary; an XML-based
language ('Extensible Markup Language', ) used for writing RFCs
() and Internet-Drafts ().
Version 2 represents the current state of the vocabulary (as implemented
by several tools and as used by the RFC Editor) around 2014.
It obsoletes the original version ("v1") , which
contained the original language definition, and which was subsequently
extended. Many of the changes leading to version 2 have been described in
"Writing I-Ds and RFCs using XML (revised)" (), but
that document has not been updated since 2008.
Processing Instructions ()
generally are specific to a given processor, and thus are not considered to
be part of the vocabulary. See
for a list of the processing instructions supported by the first implementation
of an xml2rfc processor.
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 index generation, populating a keyword database, or
syntax checks).
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.
Except inside <artwork>, horizontal
whitespace and linebreaks are collapsed into a single whitespace, and leading and trailing
whitespace are trimmed off.
Contains the abstract of the document. The abstract ought to be self-contained
and thus should not contain references or unexpanded abbreviations.
See for more information.
This element appears as a child element of: <front> ().
Content model:
One or more <t> elements ()
Provides address information for the author.
This element appears as a child element of: <author> ().Content model:In this order:One optional <postal> element ()One optional <phone> element ()One optional <facsimile> element ()One optional <email> element ()One optional <uri> element ()
Provides additional prose augmenting a bibliographical reference.
This element appears as a child element of: <reference> ().
Content model:
In any order: Text<xref> elements ()<eref> elements ()<iref> elements ()<cref> elements ()<spanx> elements ()
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 .
The list at the time that this document is being published is:
"Applications", "app", "General", "gen", "Internet", "int", "Operations
and Management", "ops", "Real-time Applications and Infrastructure", "rai",
"Routing", "rtg", "Security", "sec", "Transport", "tsv".
This element appears as a child element of: <front> ().Content model: only text content.
This element allows the inclusion of "artwork" into the document.
<artwork> is the only element in the vocabulary that provides
full control of horizontal whitespace and line breaks, and thus is
used for a variety of things, such as:
diagrams ("line art"),source code,formal languages (such as ABNF or the RNC notation used in this document),message flow diagrams,complex tables, orprotocol unit diagrams.
Note that processors differ in the handling of horizontal TAB characters
(some expand them, some treat them as single space) and thus these ought
to be avoided.
Alternatively, the "src" attribute allows referencing an external graphics
file, such as a bitmap or a vector drawing, using a URI ("Uniform Resource Identifier", ).
In this case, the textual
content acts as fallback for output formats that do not support graphics,
and thus ought to contain either a "line art" variant of the graphics, or
otherwise prose that describes the included image in sufficient detail.
Note that RFCs occasionally are published with enhanced diagrams;
a recent example is .
This element appears as a child element of: <figure> ().
Content model:
Text
Controls whether the artwork appears left justified (default), centered,
or right justified.
Allowed values: "left" (default)"center""right"
Alternative text description of the artwork (not just the caption).
The suggested height of the graphics included using the "src" attribute.
This attribute is format-dependent and ought to be avoided.
When generating HTML output, current implementations copy the attribute "as is".
For other output formats it is usually ignored.
A filename suitable for the contents (such as for extraction to a local file).
This attribute generally isn't used for document generation, but it can
be helpful for other kinds of tools (such as automated syntax checkers
which work by extracting the source code).
The URI reference of a graphics file ().
Note that this can be a "data" URI () as well; in which case the graphics
file is wholly part of the XML file.
Specifies the type of the artwork.
The value either is an Internet Media Type (see )
or a keyword (such as "abnf"). The set of recognized keywords varies
across implementations.
How it is used depends on context and application. For instance, a formatter
can attempt to syntax-highlight code in certain known languages.
The suggested width of the graphics included using the "src" attribute.
This attribute is format-dependent and ought to be avoided.
When generating HTML output, current implementations copy the attribute "as is".
For other output formats it is usually ignored.
Determines whitespace handling.
"preserve" is both the default value and the only meaningful
setting anyway (because that's what the <artwork> element is for).
See also .
Allowed values: "default""preserve" (default)
Provides information about a document's author. This is used both for
the document itself (at the beginning of the document) and for
referenced documents (inside of <reference>).
The <author> elements contained within the document's <front> element
are used to fill the boilerplate, and also to generate the "Author's Address"
section (see ).
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 bibliographical
references. Note that this specification does not define a precise
meaning for the term "editor".
See Section "Authors vs. Contributors" of
for more information.
This element appears as a child element of: <front> ().Content model:In this order:One optional <organization> element ()One optional <address> element ()
The full name (used in the automatically generated "Author's Address" section).
Author initials (used on the front page and in references).
Initials should be provided as a whitespace separated list of
pairs of a letter and a dot.
Specifies the role the author had in creating the document.
Allowed values: "editor"
The author's surname (used on the front page and in references).
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 <references> elements ()Optional <section> elements ()
Provides the content of a cell in a table.
This element appears as a child element of: <texttable> ().
Content model:
In any order: Text<xref> elements ()<eref> elements ()<iref> elements ()<cref> elements ()<spanx> elements ()
Gives the city name in a postal address.
This element appears as a child element of: <postal> ().Content model: only text content.
Gives the postal region code.
This element appears as a child element of: <postal> ().Content model: only text content.
Gives the country in a postal address.
This element appears as a child element of: <postal> ().Content model: only text content.
Represents a comment.
Comments can be used in a document while it is work-in-progress. They
usually appear either inline and visually highlighted, at the end of the document
(depending on file format and settings of the formatter), or not at
all (when generating an RFC).
This element appears as a child element of: <annotation> (), <c> (), <postamble> (), <preamble> (), and <t> ().Content model: only text content.
Document-wide unique identifier for this comment. The processor
will auto-generate an identifier when none is given.
The value needs to be a valid XML "Name" (),
additionally constrained to US-ASCII characters ().
Holds the "source" of a comment, such as the name or the initials
of the person who made the comment.
Provides information about the publication date.
Note that this element is used both for the boilerplate of the document
being produced, and also inside bibliographic references.
In the boilerplate case, it defines the publication date, which, when producing
Internet-Drafts, will be used for computing the expiration date (see ).
When one or more of "year", "month", or "day" are left out, the processor
will attempt to use the current system date if the attributes that are
present are consistent with that date.
Note that in this case, month names need to match the full (English) month name
("January", "February", "March", "April", "May, "June", "July", "August",
"September", "October", "November", or "December") in order for expiration
calculations to work (some implementations might support additional
formats, though).
In the case of bibliographic references, the date information can have prose text for the month or year.
For example, vague dates (year="ca. 2000"), date ranges (year="2012-2013"),
non-specific months (month="Second quarter") and so on, are allowed.
This element appears as a child element of: <front> ().Content model: this element does not have any contents.
Day of publication; this is a number.
Month of publication; this is the English name of the month.
Year of publication.
Provides an email address.
The value is expected to be the scheme-specific part of a "mailto" URI
(so does not include the prefix "mailto:"). See
for details.
This element appears as a child element of: <address> ().Content model: only text content.
Represents an "external" link (as specified in the "target" attribute).
If the element has text content, that content will be used. Otherwise, the value of the
target attribute will be inserted in angle brackets ().
This element appears as a child element of: <annotation> (), <c> (), <postamble> (), <preamble> (), and <t> ().Content model: only text content.
URI of the link target (see ).
Represents the phone number of a fax machine.
The value is expected to be the scheme-specific part of a "tel" URI
(so does not include the prefix "tel:"), using the "global numbers"
syntax. See
for details.
This element appears as a child element of: <address> ().Content model: only text content.
This element is used to represent a figure, consisting of an optional preamble,
the actual figure, an optional postamble, and an optional title.
This element appears as a child element of: <section> (), and <t> ().Content model:In this order:Optional <iref> elements ()One optional <preamble> element ()One <artwork> element ()One optional <postamble> element ()
Used to change the alignment of <preamble>
and <postamble>.
Note: does not affect title or <artwork> alignment.
Allowed values: "left" (default)"center""right"
Duplicates functionality available on <artwork>; avoid it.
Document-wide unique identifier for this figure.
Furthermore, the presence of this attribute causes the figure to be numbered.
The value needs to be a valid XML "Name" ().
Duplicates functionality available on <artwork>; avoid it.
Duplicates functionality available on <artwork>; avoid it.
Figures that have an "anchor" attribute will automatically get
an autogenerated title (such as "Figure 1"), even if the "title"
attribute is absent. Setting this attribute to "true" will prevent this.
Allowed values: "true""false" (default)
The title for the figure; this usually appears on a line after the figure.
Duplicates functionality available on <artwork>; avoid it.
Provides a link to an additional format variant for a reference.
Note that these additional links are neither used in published RFCs, nor
supported by all tools. If the goal is to provide a single URI for
a reference, the "target" attribute on <reference>
can be used instead.
This element appears as a child element of: <reference> ().Content model: this element does not have any contents.
Octet length of linked-to document.
URI of document.
The type of the linked-to document, such as "TXT", "HTML", or "PDF".
Represent the "front matter": metadata (such as author information),
abstract, and additional notes.
This element appears as a child element of: <reference> (), and <rfc> ().Content model:In this order:One <title> element ()One or more <author> elements ()One <date> element ()Optional <area> elements ()Optional <workgroup> elements ()Optional <keyword> elements ()One optional <abstract> element ()Optional <note> elements ()
Provides terms for the document's index.
Index entries can be either be regular entries (when just the "item"
attribute is given) or nested entries (by specifying "subitem" as well),
grouped under a regular entry.
In this document, for instance, every element definition appears
as a regular index entry ("iref element "). In addition, for each use of that element inside
another parent element, a nested entry was added ("iref element ,
... inside annotation ").
Index entries generally refer to the exact place where the <iref> element
occured. An exception is the occurence 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 range.
This element appears as a child element of: <annotation> (), <c> (), <figure> (), <postamble> (), <preamble> (), <section> (), and <t> ().Content model: this element does not have any contents.
The item to include.
Setting this to "true" declares the occurrence as "primary",
which might cause it to be highlighted in the index.
Allowed values: "true""false" (default)
The subitem to include.
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
documents.
This element appears as a child element of: <front> ().Content model: only text content.
Delineates a text list.
Each list item is represented by a <t> element.
The vocabulary currently does not directly support list items consisting
of multiple paragraphs; if this is needed, <vspace>
() can be used as a workaround.
This element appears as a child element of: <t> ().
Content model:
One or more <t> elements ()
This attribute holds a token that serves as an identifier for a counter.
The intended use is continuation of lists, where the counter will
be incremented for every list item, and there is no way to reset the
counter.
Note that this attribute functions only when the style attribute is
using the "format..." syntax ();
otherwise, it is ignored.
For list styles with potentially wide labels, this attribute can
override the default indentation level, measured in number of characters.
Note that it only affects style with variable-width labels
("format..." and "hanging", see below), and it may not affect formats
in which the list item text appears below the
label.
This attribute is used to control the display of a list.
The value of this attribute is inherited by any nested lists that do
not have this attribute set. It may be set to:
"empty"
For unlabeled list items; it can also be used for indentation
purposes (this is the default value when there is an enclosing
list where the style is specified).
"hanging"
For lists where the items are labeled with a piece of text.
The label text is specified in the 'hangText' attribute of the <t>
element ().
"letters"
For ordered lists using letters as labels (lowercase letters
followed by a period; after "z", it rolls over to a two-letter
format). For nested lists, processors usually flip between uppercase and lowercase.
"numbers"
For ordered lists using numbers as labels.
"symbols"
For unordered (bulleted) lists.
The style of the bullets is chosen automatically be the processor
(some implementations allow overriding the default using a
processing instruction).
And, finally:
"format ..."
For lists with customized labels, consisting of fixed text and
an item counter in various formats.
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 decimal number.
The following formats are supported:
lowercase letters (a, b, c, etc.)
uppercase letters (A, B, C, etc.)
decimal numbers (1, 2, 3, etc.)
lowercase Roman numerals (i, ii, iii, etc.)
uppercase Roman numerals (I, II, III, etc.)
represents a percent sign
Other formats are reserved for future use.
Represents the main content of the document.
This element appears as a child element of: <rfc> ().
Content model:
One or more <section> elements ()
Creates an unnumbered section 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:
One or more <t> elements ()
The title of the note.
Specifies the affiliation of an author.
This information appears in both 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> ().Content model: only text content.
Abbreviated variant.
Represents a phone number.
The value is expected to be the scheme-specific part of a "tel" URI
(so does not include the prefix "tel:"), using the "global numbers"
syntax. See
for details.
This element appears as a child element of: <address> ().Content model: only text content.
Contains child elements providing postal information.
This element appears as a child element of: <address> ().Content model:In this order:One or more <street> elements ()In any order: <city> elements ()<region> elements ()<code> elements ()<country> elements ()
Gives text that appears at the bottom of a figure or table.
This element appears as a child element of: <figure> (), and <texttable> ().
Content model:
In any order: Text<xref> elements ()<eref> elements ()<iref> elements ()<cref> elements ()<spanx> elements ()
Gives text that appears at the top of a figure or table.
This element appears as a child element of: <figure> (), and <texttable> ().
Content model:
In any order: Text<xref> elements ()<eref> elements ()<iref> elements ()<cref> elements ()<spanx> elements ()
Represents a bibliographical reference.
This element appears as a child element of: <references> ().Content model:In this order:One <front> element ()Optional <seriesInfo> elements ()Optional <format> elements ()Optional <annotation> elements ()
Document-wide unique identifier for this reference. Usually, this will
be used both to "label" the reference in the references section, and
as an identifier in links to this reference entry.
The value needs to be a valid XML "Name" (),
additionally constrained to US-ASCII characters ().
Holds the URI for the reference.
Note that depending on the <seriesInfo>
element, a URI might not be needed, nor desirable, as it can
be automatically generated (for instance, for RFCs).
Contains a set of bibliographical references.
In the early days of the RFC series, there was only one "References" section per RFC. This convention
was later changed to group references into two sets, "Normative" and "Informative"
as described in ).
This vocabulary supports the split with the "title" attribute.
By default, the order of references is significant. Processors however
can be instructed to sort them based on their anchor names.
This element appears as a child element of: <back> ().
Content model:
One or more <reference> elements ()
Provides the title for the References section (defaulting to
"References").
In general, the title should be either "Normative References" or
"Informative References".
Provides the region name in a postal address.
This element appears as a child element of: <postal> ().Content model: only text content.
This is the root element of the xml2rfc vocabulary.
Processors distinguish between RFC mode ("number" attribute being
present) and Internet-Draft mode ("docName" attribute being present):
it is invalid to specify both. Setting neither "number" nor "docName" can be useful for
producing other types of document but is out-of-scope for this specification.
Content model:In this order:One <front> element ()One <middle> element ()One optional <back> element ()
Document category (see ).
Allowed values: "std""bcp""info""exp""historic"
Affects the generated boilerplate.
See for more information.
Allowed values: "no""yes"
For Internet-Drafts, this specifies the draft name (which appears
below the title).
A processor should give an error if both the "docName" and "number"
attributes are given in the <rfc> element.
Note that the file extension is not part of the draft, so in
general it should end with the current draft number ("-", plus two
digits).
Furthermore, it is good practice to disambiguate current editor
copies from submitted drafts (for instance, by replacing the
draft number with the string "latest").
See
for further information.
Represents the Intellectual Property status of the document.
See for details.
Allowed values: "full2026""noDerivativeWorks2026""none""full3667""noModification3667""noDerivatives3667""full3978""noModification3978""noDerivatives3978""trust200811""noModificationTrust200811""noDerivativesTrust200811""trust200902""noModificationTrust200902""noDerivativesTrust200902""pre5378Trust200902"
Identifies a single section within the document (by its 'anchor'
attribute) for which extraction "as-is" is explicitly allowed (this
is only relevant for historic values of the "ipr" attribute).
The number of the RFC to be produced.
A processor should give an error if both the "docName" and "number"
attributes are given in the <rfc> element.
A comma-separated list of RFC numbers or
Internet-Draft names.
Processors ought to parse the attribute value, so that incorrect
references can be detected and, depending on output format,
hyperlinks can be generated. Also, the value ought to be reformatted
to insert whitespace after each comma if not already present.
When producing a document within document series (such as "STD"):
the number within that series.
The document stream.
See for details.
Allowed values: "IETF" (default)"IAB""IRTF""independent"
A comma-separated list of RFC numbers or
Internet-Draft names.
Processors ought to parse the attribute value, so that incorrect
references can be detected and, depending on output format,
hyperlinks can be generated. Also, the value ought to be reformatted
to insert whitespace after each comma if not already present.
The natural language used in the document (defaults to "en").
See
for more information.
Represents a section (when inside a <middle> element) or an appendix (when inside a
<back> element).
Sub-sections are created by nesting <section> elements inside <section> elements.
This element appears as a child element of: <back> (), <middle> (), and <section> ().Content model:In this order:In any order: <t> elements ()<figure> elements ()<texttable> elements ()<iref> elements ()Optional <section> elements ()
Document-wide unique identifier for this section.
The value needs to be a valid XML "Name" ().
The title of the section.
Determines whether the section is included in the Table Of Contents.
The processor usually has defaults for whether a Table Of Contents
will be produced at all, and sections of which maximal depth will
be included (frequently: 3). "include" and "exclude" allow overriding
the processor's default behavior for the element they are specified
on (they do not affect nested elements).
Allowed values: "include""exclude""default" (default)
Specifies the document series in which this document appears, and also
specifies an identifier within that series.
This element appears as a child element of: <reference> ().Content model: this element does not have any contents.
The name of the series.
The following names trigger specific processing (such as for
auto-generating links, and adding descriptions such as
"work in progress"): "BCP", "FYI", "Internet-Draft", "RFC", and "STD".
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).
Wraps a piece of text, indicating special formatting styles.
When generating plain text, processors usually emulate font changes
using characters such as "*" and "_".
The following styles are defined:
Simple emphasis (this is the default).
Strong emphasis.
"Verbatim" text (usually displayed using a monospaced font face).
This element appears as a child element of: <annotation> (), <c> (), <postamble> (), <preamble> (), and <t> ().Content model: only text content.
The style to be used (defaults to "emph").
Determines whitespace handling.
According to the DTD, the default value is "preserve". Tests however
show that it doesn't have any effect on processing; thus this
attribute will be removed in future versions of the vocabulary.
See also .
Allowed values: "default""preserve" (default)
Provides a street address.
This element appears as a child element of: <postal> ().Content model: only text content.
Contains a paragraph of text.
This element appears as a child element of: <abstract> (), <list> (), <note> (), and <section> ().
Content model:
In any order: Text<list> elements ()<figure> elements ()<xref> elements ()<eref> elements ()<iref> elements ()<cref> elements ()<spanx> elements ()<vspace> elements ()
Document-wide unique identifier for this paragraph.
The value needs to be a valid XML "Name" ().
Holds the label ("hanging text") for items in lists using the "hanging"
style (see ).
Contains a table, consisting of an optional preamble, a header line,
rows, an optional postamble, and an optional title.
The number of columns in the table is determined by the number of
<ttcol> elements. The number of rows in the table is
determined by the number of <c> elements divided
by the number of columns. There is no requirement that the number of
<c> elements be evenly divisible by the number of
columns.
This element appears as a child element of: <section> ().Content model:In this order:One optional <preamble> element ()One or more <ttcol> elements ()Optional <c> elements ()One optional <postamble> element ()
Determines the horizontal alignment of the table.
Allowed values: "left""center" (default)"right"
Document-wide unique identifier for this table.
Furthermore, the presence of this attribute causes the table to be numbered.
The value needs to be a valid XML "Name" ().
Selects which borders should be drawn, where
"all" means borders around all table cells,
"full" is like "all" except no horizontal lines between table
rows (except below the column titles),
"headers" adds just a separator between column titles and rows, and
"none" means no borders at all.
Allowed values: "all""none""headers""full" (default)
Tables that have an "anchor" attribute will automatically get
an autogenerated title (such as "Table 1"), even if the "title"
attribute is absent. Setting this attribute to "true" will prevent this.
Allowed values: "true""false" (default)
The title for the table; this usually appears on a line below the table body.
Represents the document title.
When this element appears in the <front> element of the current document,
the title might also appear in page headers or footers. If it's long
(~40 characters), the "abbrev" attribute is used to specify an
abbreviated variant.
This element appears as a child element of: <front> ().Content model: only text content.
Specifies an abbreviated variant of the document title.
Contains a column heading in a table.
This element appears as a child element of: <texttable> ().Content model: only text content.
Determines the horizontal alignment within the table column.
Allowed values: "left" (default)"center""right"
The desired column width (as integer 0..100 followed by "%").
Contains a web address associated with the author.
The contents should be a valid URI (see ).
This element appears as a child element of: <address> ().Content model: only text content.
This element can be used to force the inclusion of a single line break
or multiple blank lines.
Note that this is a purely presentational element and thus its use ought
to be avoided.
This element appears as a child element of: <t> ().Content model: this element does not have any contents.
Number of blank lines to be inserted, where "0" indicates
a single line break (defaults to "0").
For paged output formats, no additional blank lines should be generated
after a page break.
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 on the <rfc> element
().
This element appears as a child element of: <front> ().Content model: only text content.
Inserts a reference to a different part of a document.
The generated text depends on whether the <xref> is empty
(in which case the processor will try to generate a meaningful text
fragment), and the nature of the referenced document part.
Any element that allows the "anchor" attribute can be referenced; however
there are restrictions with respect to the text content being generated.
For instance, a <t> can be a reference target, however,
because paragraphs are not (visibly) numbered, the author will have to
make sure that the prose is sufficient for a reader to understand what
is being referred to.
This needs to be expanded with examples and with a discussion
how the autogenerated text differs when <xref> is not emptyThis element appears as a child element of: <annotation> (), <c> (), <postamble> (), <preamble> (), and <t> ().Content model: only text content.
This attribute is used to control the format of the generated
reference text.
"counter"
Inserts a counter, such as the number of a section, figure, or
table.
"default"
Inserts a text fragment that describes the referenced part
completely, such as "Section 2", "Table 4", or "[XML]".
"none"
There will be no auto-generated text.
"title"
Inserts a title for the referenced element (usually obtained from
the referenced element's "title" attribute; some processors
also use the <title> child element or a <reference>
target).
Allowed values: "counter""title""none""default" (default)
Unused.
It's unclear what the purpose of this attribute is; processors
seem to ignore it and it never was documented.
Allowed values: "true""false" (default)
Identifies the document component being referenced.
The value needs to match the value of the "anchor" attribute of another
element in the document.
Text in XML cannot use the literal characters "<" and "&", as they
have special meaning to the XML processor (starting entities, elements, etc.).
Usually, these characters will need to be substituted by "&lt;" and
"&amp;" (see ).
">" does not require escaping, unless it appears in the sequence "]]>"
(which indicates the end of a CDATA section, see below).
Escaping the individual characters can be a lot of work (when done manually),
and also messes up alignment in artwork. Another approach to escaping is
to use CDATA sections ().
Within these, no further escaping is needed, except when the "end-of-CDATA"
marker needs to be used (in that case, the CDATA section needs to be closed,
and a new one needs to be started).
Although the current RFC format does not allow non-ASCII Unicode characters
(), some of them can be used to enforce certain
behaviors of formatters.
For instance:
non-breaking space (U+00A0)
Represents a space character where no line break should happen. This is
frequently used in titles (by excluding certain space characters from
the line breaking algorithm, the processor will use the remaining
whitespace occurrences for line breaks).
non-breaking hyphen (U+2011)
Similarly, this represents a hyphen character where nevertheless no
line breaking ought to occur.
word joiner (U+2060)
Also called "zero width non-breaking space" — can be used to
disallow line breaking between two non-whitespace characters.
Note that in order to use these characters by name, they need to be
declared either in the Document Type Definition (DTD,
), or
in the "internal subset" (),
like this:
<?xml version="1.0"?>
<!DOCTYPE rfc [
<!-- declare nbsp and friends -->
<!ENTITY nbsp "&#xa0;">
<!ENTITY nbhy "&#x2011;">
<!ENTITY wj "&#x2060;">
]>
This version of the vocabulary does not support an inclusion mechanism on
its own — thus, a document always needs to be self-contained.
That being said, some processors do support file inclusion using
processing instructions (
and ).
Furthermore, XML itself allows inclusion of external content using the
"internal subset" ().
Unfortunately, this requires declaring the external data in the DTD upfront.
For instance:
<?xml version="1.0"?>
<!DOCTYPE rfc [
<!-- allow later RFC2616 reference using "&rfc2616;" -->
<!-- the data will be fetched from xml.resource.org -->
<!ENTITY rfc2616 PUBLIC
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
]>
...declares the entity "rfc2616", which then can be used in the "references" section:
<references>
&rfc2616;
</references>
Note that this mechanism only works for well-formed XML fragments; thus
any plain text that would need to be escaped in XML can't be included as-is.
This format is based on , thus does not have any
issues representing arbitrary Unicode characters in text content.
However, the current canonical RFC format is restricted to US-ASCII
characters ( and ).
It is possible that this rule will be relaxed in future revisions of the
RFC format (for instance, to allow non-ASCII characters in examples and
contact information). In that case, it is
expected that the vocabulary will be extended accordingly.
The "name" attribute on 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.
Furthermore, the nature of XML, plus vocabulary features such as typed artwork,
make it attractive to extract content from documents for further
processing, such for the purpose of checking syntax, or computing/verifying
examples. In the latter case, care needs to be taken that only trusted
content is processed.
All security considerations related to XML processing are
relevant as well (see ).
IANA maintains the registry of Internet media types
at .
This document serves as the specification for the Internet media type
"application/rfc+xml". The following is to be registered with IANA.
application
rfc+xml
There are no required parameters.
"charset": This parameter has identical semantics as the charset
parameter of the "application/xml" media type specified in .
Identical to those of "application/xml" as described in .
As defined in . In addition, as
this media type uses the "+xml" convention, it inherits the security
considerations described in .
N/A
This specification.
Applications that transform xml2rfc to output formats such
as plain text or HTML, plus additional analysis tools.
The "anchor" attribute is used for assigning document-wide unique
identifiers that can be used as shorthand pointers, as described
in .
None.As specified for "application/xml" in ..xml or .rfcxml when disambiguation from other XML files is neededTEXT
See Authors Section.
COMMON
N/A
See Authors Section.
RFC Series Editor (rse@rfc-editor.org)
Thanks to everybody who reviewed this document and provided feedback and/or
specification text, in particular Brian Carpenter, Elwyn Davies, Tony Hansen,
Paul Hoffman, Henrik Levkowetz, Alice Russo, Tom Taylor, Jim Schaad, and Nico
Williams.
We also thank Marshall T. Rose for both the original design and the reference
implementation of the "xml2rfc" formatter.
Extensible Markup Language (XML) 1.0 (Fifth Edition)
Latest version available at
.
Media Type Specifications and Registration ProceduresThe Internet Standards Process -- Revision 3Multipurpose Internet Mail Extensions (MIME) Part Two: Media TypesInstructions to RFC AuthorsThe "data" URL schemeWriting I-Ds and RFCs using XMLGuidelines for the Use of Extensible Markup Language (XML) within IETF ProtocolsThe tel URI for Telephone NumbersUniform Resource Identifier (URI): Generic SyntaxInternet Mail ArchitecturePDF version: RFC Streams, Headers, and BoilerplatesThe 'mailto' URI SchemeUse of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)XML Media TypesRELAX NG Compact Syntaxjjc@jclark.comGuidelines to Authors of Internet-DraftsRFC Editorial Guidelines and ProceduresRFC EditorRFC Style GuideLegal Provisions Relating to IETF DocumentsIETF TrustLegal Provisions Relating to IETF DocumentsIETF TrustLegal Provisions Relating to IETF DocumentsIETF TrustThe Unicode Standard, Version 6.3.0The Unicode ConsortiumCoded Character Set -- 7-bit American Standard Code for Information InterchangeAmerican National Standards InstituteXPointer Framework
Latest version available at
.
Jing - A RELAX NG validator in JavaThai Open Source Software Center Ltd
Downloads:
.
Writing I-Ds and RFCs using XML (revised)xml2rfc v1.35pre1
For RFCs, the category 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, but will
appear on the front page 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.
This attribute's values are not the result of a grand plan, but remain simply for historic
reasons. Of these values, only a few are currently in use; all others are
supported by the various tools for backwards compatibility with old source
files.
Note: some variations of the boilerplate are selected based
on the document's date; therefore it is important to specify the "year",
"month" and "day" attributes of the <date> element
when archiving the XML source of an Internet-Draft on the day of submission.
Disclaimer: THIS ONLY PROVIDES IMPLEMENTATION INFORMATION. IF YOU NEED
LEGAL ADVICE, PLEASE CONTACT A LAWYER.
For further information, refer to .
For the current "Status Of This Memo" text, the submissionType attribute
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 the "IETF TRUST Legal Provisions Relating
to IETF Documents", sometimes simply called the "TLP, that went into effect on February 15, 2009 ().
Updates to this 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 tools will automatically produce the "correct" text depending on the
document's date information (see above):
TLPstarting with publication date2009-11-012010-04-01
This should be the default, 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 additional text from Section 6.c.i of the TLP:

This document may not be modified, and derivative works of it may
not be created, except to format it for publication as an RFC or
to translate it into languages other than English.

Note: this clause is incompatible with RFCs that are published
on the Standards Track.
This produces the additional text from Section 6.c.ii of the TLP:

This document may not be modified, and derivative works of it may
not be created, and it may not be published except as an Internet-Draft.

Note: this clause is incompatible with RFCs.
This produces the additional text from Section 6.c.iii of the TLP, frequently
called the "pre-5378 escape clause":

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.