This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

This document describes version 2 ("v2") of the 'XML2RFC' vocabulary; an XML-based language ('Extensible Markup Language', [XML]) used for writing RFCs ([RFC7322]) and Internet-Drafts ([IDGUIDE]).¶

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") [RFC2629], 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)" ([V1rev]), but that document has not been updated since 2008.¶

Processing Instructions (Section 2.6 of [XML]) generally are specific to a given processor, and thus are not considered to be part of the vocabulary. See Section 4.1 of [TCLReadme] 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).¶

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 <http://www.ietf.org/iesg/area.html>. 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".¶

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

protocol 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", [RFC3986]). 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 [RFC5598].¶

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

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

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

Furthermore, the "role" attribute can be used to mark an author as "editor". This is reflected 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 [RFCPOLICY] for more information.¶

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).¶

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 Section 8 of [IDGUIDE]). When one or more of "year", "month", or "day" are left out, the processor will attempt to use the current system date if the attributes that are present are consistent with that date.¶

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

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

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

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

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 2.20"). In addition, for each use of that element inside another parent element, a nested entry was added ("iref element 2.20, ... inside annotation 2.3").¶

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

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> (Section 2.43) can be used as a workaround.¶

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 (Section 2.22.3); otherwise, it is ignored.¶

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.

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.

This information appears in both the "Author's Address" section and on the front page (see [RFC7322], Section 4.1.1 for more information). If the value is long, an abbreviated variant can be specified in the "abbrev" attribute.¶

Document-wide unique identifier for this reference. Usually, this will be used both to "label" the reference in the references section, and as an identifier in links to this reference entry.¶

The value needs to be a valid XML "Name" (Section 2.3 of [XML]), additionally constrained to US-ASCII characters ([USASCII]). Thus, the character repertoire consists of "A-Z", "a-z", "0-9", "_", "-", ".", and ":", where "0-9", ".", and "-" are disallowed as start character.¶

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

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

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

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

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

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

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 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 (Section 2.33.9).¶

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

[oi-xref: This needs to be expanded with examples and with a discussion how the autogenerated text differs when <xref> is not empty]¶

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

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

Escaping the individual characters can be a lot of work (when done manually), and also messes up alignment in artwork. Another approach to escaping is to use CDATA sections ([XML], Section 2.7). 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).¶

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

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, [XML], Section 2.9), or in the "internal subset" ([XML], Section 2.8), like this:¶

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

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

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

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

All security considerations related to XML processing are relevant as well (see Section 7 of [RFC3470]).¶

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

For Internet-Drafts, the category attribute 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 (Section 2.33.4). The values are not the result of a grand design, but 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.¶

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

For the current "Status Of This Memo" text, the submissionType attribute (Section 2.33.9) 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", which went into effect on February 15, 2009 ([TLP2.0]). Updates to this document were published on September 12, 2009 ([TLP3.0]) and on December 28, 2009 ([TLP4.0]), modifying the license for code components (see <http://trustee.ietf.org/license-info/> for further information). The actual text is located in Section 6 ("Text To Be Included in IETF Documents") of these documents.¶

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

The RFC Editor publishes documents from different "document streams", of which the "IETF stream" is the most prominent one. Other streams are the "independent stream" (used for things such as administrative information or April 1st RFCs), 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", and "IRTF".¶

Historically, this attribute did not affect the final appearance of RFCs, except for subtle differences in Copyright notices. Nowadays (as of [RFC5741]), 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 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).

Many attributes have lost their "default" value; this is to avoid having document semantics differ based on whether a DTD was specified and evaluated. Processors will handle absent values the way the default value was specified before.¶