The 'XML2RFC' version 3 Vocabulary
draft-hoffman-xml2rfc-00

Abstract

This document defines the 'XML2RFC' version 3 vocabulary; an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion.

Editorial Note (To be removed by RFC Editor)

Discussion of this draft takes place on the rfc-interest mailing list (rfc-interest@rfc-editor.org), which has its home page at https://www.rfc-editor.org/mailman/listinfo/rfc-interest.

Status of This Memo

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 Internet-Draft will expire on August 01, 2014.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Differences from v2 to v3
• 1.2. Syntax Notation
• 2. Elements
• 2.1. <abstract>
• 2.2. <address>
• 2.3. <annotation>
• 2.4. <area>
• 2.5. <artwork>
• 2.6. <author>
• 2.7. <b>
• 2.8. <back>
• 2.9. <c>
• 2.10. <city>
• 2.11. <code>
• 2.12. <country>
• 2.13. <cref>
• 2.14. <date>
• 2.15. <email>
• 2.16. <eref>
• 2.17. <facsimile>
• 2.18. <figure>
• 2.19. <format>
• 2.20. <front>
• 2.21. <i>
• 2.22. <iref>
• 2.23. <keyword>
• 2.24. <list>
• 2.25. <middle>
• 2.26. <note>
• 2.27. <organization>
• 2.28. <phone>
• 2.29. <postal>
• 2.30. <postalbody>
• 2.31. <postamble>
• 2.32. <preamble>
• 2.33. <reference>
• 2.34. <references>
• 2.35. <region>
• 2.36. <rfc>
• 2.37. <section>
• 2.38. <seriesInfo>
• 2.39. <street>
• 2.40. <t>
• 2.41. <texttable>
• 2.42. <title>
• 2.43. <tt>
• 2.44. <ttcol>
• 2.45. <uri>
• 2.46. <vspace>
• 2.47. <workgroup>
• 2.48. <xref>
• 3. Special Unicode Code Points
• 4. Internationalization Considerations
• 5. Security Considerations
• 6. IANA Considerations
• 6.1. Internet Media Type Registration
• 7. Acknowledgments
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Front Page Generation
• A.1. The /rfc/@category Attribute
• A.2. The /rfc/@ipr Attribute
• A.2.1. Current Values: '*trust200902'
• A.2.2. Historic Values
• Appendix B. Relax NG Schema
• Index
• Author's Address

1. Introduction

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

This document obsoletes the version ("v2") vocablulary [XML2RFCv2], which contains the extended language definition. That document in turn obsoletes the original version ("v1") [RFC2629]. This document directly copies the material from [XML2RFCv2] where possible; as that document makes its way toward RFC publication, this document will incorporate as many of the changes as possible.

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

1.1. Differences from v2 to v3

The following is a hopefully-complete list of all the technical changes between [XML2RFCv2] and this document. Note that the list is for the current version of this document only. There are *many* additional changes that are expected to the v3 vocabulary that are being discussed. Also note that changes to the design choices for the differences are also expected.

• In <
• In <
• Added the <
• In <
• In <
• Added <
• In <
• Removed the <spanx> element, and replaced it with <b>, <i>, and <tt>.
• In <

1.2. Syntax Notation

The XML vocabulary here is defined in prose, based on the Relax NG schema ([RNC]) contained in Appendix B (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).

2. Elements

The sections below describe all elements and their attributes.

Note that attributes not labeled "mandatory" are optional.

2.1. <abstract>

Contains the abstract of the document. The abstract ought to be self-contained and thus should not contain references or unexpanded abbreviations. See [RFCSTYLE] for more information.

This element appears as child element of: <Section 2.20).

Content model:

One or more <Section 2.40)

2.2. <address>

Provides address information for the author.

This element appears as child element of: <Section 2.6).

Content model:

• <Section 2.29)
• <Section 2.28)
• <Section 2.17)
• <Section 2.15)
• <Section 2.45)

2.3. <annotation>

Provides additional prose augmenting a bibliographical reference.

For instance:

<annotation>
  Latest version available at <eref
  target='http://www.w3.org/TR/xml'/>.
</annotation>

...will generate the text used in the reference for [XML].

This element appears as child element of: <Section 2.33).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.43)
• <Section 2.7)
• <Section 2.21)

2.4. <area>

Provides information about the IETF area this document applies to (currently not used when generating documents).

This element appears as child element of: <Section 2.20).

Content model: only text content.

2.5. <artwork>

This element allows the inclusion of "artwork" into the document.

<artwork> 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),
• complex tables, or
• protocol unit diagrams.

Alternatively, the "src" attribute allows referencing an external graphics file, such as a bitmap or a vector drawing. 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].

This element appears as child element of: <Section 2.18).

Content model:

2.5.1. 'align' attribute

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

Allowed values:

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

2.5.2. 'alt' attribute

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

2.5.3. 'height' attribute

The suggested height of the graphics 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.

2.5.4. 'name' attribute

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

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

2.5.5. 'src' attribute

The URI of a graphics file.

Note that this can be a "data" URI ([RFC2397]) as well, in which case the graphics file essentially is in-lined.

2.5.6. 'type' attribute

Specifies the type of the artwork.

The value either is a well-known keyword (such as "abnf"), or an Internet Media Type (see [RFC2046]).

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

2.5.7. 'width' attribute

The suggested width of the graphics 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.

2.5.8. 'xml:lang' attribute

Allows specification of the language used. This is sometimes useful for renderers which display different fonts for CJK characters.

2.5.9. 'xml:space' attribute

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

Allowed values:

• "default"
• "preserve" (default)

2.6. <author>

Provides information about a document author.

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 [RFCSTYLE]).

Note that an "author" can also be just an organization (by not specifying any of the name attributes, but adding the <

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.

This element appears as child element of: <Section 2.20).

Content model:

1. One optional <Section 2.27)
2. One optional <Section 2.2)

2.6.1. 'fullname' attribute

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

2.6.2. 'initials' attribute

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.

2.6.3. 'role' attribute

Specifies the role the author had in creating the document.

Allowed values:

• "editor"

2.6.4. 'surname' attribute

The author's surname.

2.6.5. 'xml:lang' attribute

Allows specification of the language used. This is sometimes useful for renderers which display different fonts for CJK characters.

2.7. <b>

Causes the text to be displayed in a bold font.

This element appears as child element of: <Section 2.3), <Section 2.9), <Section 2.21), <Section 2.31), <Section 2.32), <Section 2.40), and <Section 2.43).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.43)
• <Section 2.21)

2.8. <back>

Contains the "back" part of the document: the references and appendices.

This element appears as child element of: <Section 2.36).

Content model:

1. Optional <Section 2.34)
2. Optional <Section 2.37)

2.9. <c>

Provides the content of a cell in a table.

This element appears as child element of: <Section 2.41).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.43)
• <Section 2.7)
• <Section 2.21)

2.10. <city>

Gives the city name in a postal address.

This element appears as child element of: <Section 2.29).

Content model: only text content.

2.11. <code>

Gives the postal region code.

This element appears as child element of: <Section 2.29).

Content model: only text content.

2.12. <country>

Gives the country in a postal address.

This element appears as child element of: <Section 2.29).

Content model: only text content.

2.13. <cref>

Represents a comment.

Comments can be used in a document while it is work-in-progress. They usually appear either 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 child element of: <Section 2.3), <Section 2.7), <Section 2.9), <Section 2.21), <Section 2.31), <Section 2.32), <Section 2.40), <Section 2.43), and <Section 2.44).

Content model: only text content.

2.13.1. 'anchor' attribute

2.13.2. 'source' attribute

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

2.14. <date>

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 first case, it defines the publication date, which, when producing Internet-Drafts, will be used for computing the expiration date (see [IDGUIDE]). When "year", "month" or "day" are left out, the processor will attempt to use the current system date if the attributes that are specified do match the system date.

Note that 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 second case, the date information will be embedded as-is into the reference text. Therefore, also vague dates ("ca. 2000"), date ranges, and so on, are allowed.

This element appears as child element of: <Section 2.20).

Content model: this element does not have any contents.

2.14.1. 'day' attribute

Day of publication.

2.14.2. 'month' attribute

Month of publication.

2.14.3. 'year' attribute

Year of publication.

2.15. <email>

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 [RFC6068] for details.

This element appears as child element of: <Section 2.2).

Content model: only text content.

2.16. <eref>

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 ([RFC3986]).

This element appears as child element of: <Section 2.3), <Section 2.7), <Section 2.9), <Section 2.21), <Section 2.31), <Section 2.32), <Section 2.40), <Section 2.43), and <Section 2.44).

Content model: only text content.

2.16.1. 'target' attribute (mandatory)

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

2.17. <facsimile>

Represents the phone number of a fax machine.

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

This element appears as child element of: <Section 2.2).

Content model: only text content.

2.18. <figure>

This element appears as child element of: <Section 2.37), and <Section 2.40).

Content model:

1. Optional <Section 2.22)
2. One optional <Section 2.32)
3. One <Section 2.5)
4. One optional <Section 2.31)

2.18.1. 'align' attribute

Used to change the alignment of <

Note: does not affect title or <

Allowed values:

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

2.18.2. 'alt' attribute

Duplicates functionality available on <artwork>; avoid it.

2.18.3. 'anchor' attribute

2.18.4. 'height' attribute

Duplicates functionality available on <artwork>; avoid it.

2.18.5. 'src' attribute

Duplicates functionality available on <artwork>; avoid it.

2.18.6. 'suppress-title' attribute

Figures that have an "anchor" attribute will automatically get an autogenerated title (such as "Figure 1"). Setting this attribute to "false" will prevent this.

Allowed values:

• "true"
• "false" (default)

2.18.7. 'title' attribute

2.18.8. 'width' attribute

Duplicates functionality available on <artwork>; avoid it.

2.19. <format>

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 <

This element appears as child element of: <Section 2.33).

Content model: this element does not have any contents.

2.19.1. 'octets' attribute

Octet length of linked-to document.

2.19.2. 'target' attribute

URI of document.

2.19.3. 'type' attribute (mandatory)

The type of the linked-to document, such as "TXT", "HTML", or "PDF".

2.20. <front>

Represent the "front matter": metadata (such as author information), abstract, and additional notes.

This element appears as child element of: <Section 2.33), and <Section 2.36).

Content model:

1. One <Section 2.42)
2. One or more <Section 2.6)
3. One optional <Section 2.14)
4. Optional <Section 2.4)
5. Optional <Section 2.47)
6. Optional <Section 2.23)
7. One optional <Section 2.1)
8. Optional <Section 2.26)

2.21. <i>

Causes the text to be displayed in an italic font.

This element appears as child element of: <Section 2.3), <Section 2.7), <Section 2.9), <Section 2.31), <Section 2.32), <Section 2.40), and <Section 2.43).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.7)
• <Section 2.43)

2.22. <iref>

Provides terms for the document's index.

Index entries can be either single items (when just the "item" attribute is given) or nested items (by specifying "subitem" as well).

For instance:

<iref item="Grammar" subitem="item"/>

will produce an index entry for "Grammar, item".

This element appears as child element of: <Section 2.3), <Section 2.7), <Section 2.9), <Section 2.18), <Section 2.21), <Section 2.31), <Section 2.32), <Section 2.37), <Section 2.40), <Section 2.43), and <Section 2.44).

Content model: this element does not have any contents.

2.22.1. 'item' attribute (mandatory)

The item to include.

2.22.2. 'primary' attribute

Setting this to "true" declares the occurrence as "primary", which might cause it to be highlighted in the index.

Allowed values:

• "true"
• "false" (default)

2.22.3. 'subitem' attribute

The subitem to include.

2.23. <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 formats.

This element appears as child element of: <Section 2.20).

Content model: only text content.

2.24. <list>

Delineates a text list.

Each list item is represented by a <Section 2.46) can be used as workaround.

This element appears as child element of: <Section 2.40).

Content model:

One or more <Section 2.40)

2.24.1. 'counter' attribute

This attribute holds a token that serves as an identifier for a counter. The intended use is continuation of lists.

Note that this attribute functions only when the style attribute is using the "format..." syntax (Section 2.24.3); otherwise, it is ignored.

2.24.2. 'hangIndent' attribute

For list styles with potentially wide labels, this attribute can override the default indentation level, measured in 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.

2.24.3. 'style' attribute

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" (or not set)

"hanging"

• For lists where the items are labeled with a piece of text.
• The label text is specified in the 'hangText' attribute of the <Section 2.40.2).

"letters"

"numbers"

"symbols"

"format ..."

2.25. <middle>

Represents the main content of the document.

This element appears as child element of: <Section 2.36).

Content model:

One or more <Section 2.37)

2.26. <note>

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 child element of: <Section 2.20).

Content model:

One or more <Section 2.40)

2.26.1. 'title' attribute (mandatory)

The title of the note.

2.27. <organization>

Specifies the affiliation of an author.

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

This element appears as child element of: <Section 2.6).

Content model: only text content.

2.27.1. 'abbrev' attribute

Abbreviated variant.

2.28. <phone>

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 [RFC3966] for details.

This element appears as child element of: <Section 2.2).

Content model: only text content.

2.29. <postal>

Contains optional child elements providing postal information. These elements will be displayed in an order that is processor-specific. Thus, a postal address should probably contain only a set of <

This element appears as child element of: <Section 2.2).

Content model:

• <Section 2.39)
• <Section 2.10)
• <Section 2.35)
• <Section 2.11)
• <Section 2.12)
• <Section 2.30)

2.30. <postalbody>

A method for presenting a postal address without using <

This element appears as child element of: <Section 2.29).

Content model: only text content.

2.31. <postamble>

Gives text that appears at the bottom of a figure or table.

This element appears as child element of: <Section 2.18), and <Section 2.41).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.43)
• <Section 2.7)
• <Section 2.21)

2.32. <preamble>

Gives text that appears at the top of a figure or table.

This element appears as child element of: <Section 2.18), and <Section 2.41).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.43)
• <Section 2.7)
• <Section 2.21)

2.33. <reference>

Represents a bibliographical reference.

This element appears as child element of: <Section 2.34).

Content model:

1. One <Section 2.20)
2. Optional <Section 2.38)
3. Optional <Section 2.19)
4. Optional <Section 2.3)

2.33.1. 'anchor' attribute

2.33.2. 'target' attribute

Holds the URI for the reference.

Note that depending on the <

2.34. <references>

Contains a set of bibliographical references.

In the early days of the RFC series, there was only one "References" section per RFC. This convention was later changed to group references into two sets, "Normative" and "Informative"; see item x of [RFCSTYLE]). This vocabulary supports the split with the "title" attribute.

This element appears as child element of: <Section 2.8).

Content model:

One or more <Section 2.33)

2.34.1. 'title' attribute

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

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

2.35. <region>

Provides the region name in a postal address.

This element appears as child element of: <Section 2.29).

Content model: only text content.

2.36. <rfc>

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:

1. One <Section 2.20)
2. One <Section 2.25)
3. One optional <Section 2.8)

2.36.1. 'category' attribute

Document category (see Appendix A.1).

Allowed values:

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

2.36.2. 'consensus' attribute

Affects the generated boilerplate.

See [RFC5741] for more information.

Allowed values:

• "no"
• "yes"

2.36.3. 'docName' attribute

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

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 [IDGUIDE] for further information.

2.36.4. 'ipr' attribute

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

Allowed values:

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

2.36.5. 'iprExtract' attribute

Identifies a Section within the document for which extraction "as-is" is explicitly allowed (only relevant for historic values of the "ipr" attribute).

2.36.6. 'number' attribute

The number of the RFC to be produced.

2.36.7. 'obsoletes' attribute

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

2.36.8. 'seriesNo' attribute

When producing a document within document series (such as "STD"): the number within that series.

2.36.9. 'submissionType' attribute

The document stream.

See [RFC5741] for details.

Allowed values:

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

2.36.10. 'updates' attribute

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

2.36.11. 'xml:lang' attribute

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

See [XML] for more information.

2.37. <section>

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 child element of: <Section 2.8), <Section 2.25), and <Section 2.37).

Content model:

1. In any order:
   • <Section 2.40)
   • <Section 2.18)
   • <Section 2.41)
   • <Section 2.22)

2. Optional <Section 2.37)

2.37.1. 'anchor' attribute

2.37.2. 'numbered' attribute

If set to "no", this section does not get a section number. Processors will verify that such a section is not followed by a numbered section in a part, and will verify that the section is a top-level section.

Allowed values:

• "yes" (default)
• "no"

2.37.3. 'removeinrfc' attribute

If set to "yes", this section is marked in the processor with text indicating that it should be removed before the document is published as an RFC.

Allowed values:

• "yes"
• "no" (default)

2.37.4. 'title' attribute (mandatory)

The title of the section.

2.37.5. 'toc' attribute

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

Allowed values:

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

2.38. <seriesInfo>

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

This element appears as child element of: <Section 2.33).

Content model: this element does not have any contents.

2.38.1. 'name' attribute (mandatory)

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

2.38.2. 'value' attribute (mandatory)

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

For BCPs, FYIs, RFCs, and STDs this is the number within the series. For Internet-Drafts, it is the full draft name (ending with the two-digit version number).

2.39. <street>

Provides a street address.

This element appears as child element of: <Section 2.29).

Content model: only text content.

2.40. <t>

Contains a paragraph of text.

This element appears as child element of: <Section 2.1), <Section 2.24), <Section 2.26), and <Section 2.37).

Content model:

• Text
• <Section 2.24)
• <Section 2.18)
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.43)
• <Section 2.7)
• <Section 2.21)
• <Section 2.46)

2.40.1. 'anchor' attribute

2.40.2. 'hangText' attribute

2.41. <texttable>

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

The number of columns in the table is determined by the number of <

This element appears as child element of: <Section 2.37).

Content model:

1. One optional <Section 2.32)
2. One or more <Section 2.44)
3. Optional <Section 2.9)
4. One optional <Section 2.31)

2.41.1. 'align' attribute

Determines the horizontal alignment of the table.

Allowed values:

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

2.41.2. 'anchor' attribute

2.41.3. 'style' attribute

Allowed values:

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

2.41.4. 'suppress-title' attribute

Allowed values:

• "true"
• "false" (default)

2.41.5. 'title' attribute

2.42. <title>

Represents the document title.

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

This element appears as child element of: <Section 2.20).

Content model: only text content.

2.42.1. 'abbrev' attribute

Specifies an abbreviated variant of the document title.

2.43. <tt>

Causes the text to be displayed in a constant-width font.

This element appears as child element of: <Section 2.3), <Section 2.7), <Section 2.9), <Section 2.21), <Section 2.31), <Section 2.32), and <Section 2.40).

Content model:

• Text
• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• <Section 2.7)
• <Section 2.21)

2.44. <ttcol>

Contains a column heading in a table.

This element appears as child element of: <Section 2.41).

Content model:

• <Section 2.48)
• <Section 2.16)
• <Section 2.22)
• <Section 2.13)
• Text

2.44.1. 'align' attribute

Determines the horizontal alignment within the table column.

Allowed values:

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

2.44.2. 'width' attribute

2.45. <uri>

Contains a web address associated with the author.

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

This element appears as child element of: <Section 2.2).

Content model: only text content.

2.46. <vspace>

This element appears as child element of: <Section 2.40).

Content model: this element does not have any contents.

2.46.1. 'blankLines' attribute

2.47. <workgroup>

This element is used to specify the Working Group the document originates from, 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 <Section 2.36.9).

This element appears as child element of: <Section 2.20).

Content model: only text content.

2.48. <xref>

This element appears as child element of: <Section 2.3), <Section 2.7), <Section 2.9), <Section 2.21), <Section 2.31), <Section 2.32), <Section 2.40), <Section 2.43), and <Section 2.44).

Content model: only text content.

2.48.1. 'format' attribute

Allowed values:

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

2.48.2. 'pageno' attribute

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)

2.48.3. 'target' attribute (mandatory)

3. Special Unicode Code Points

4. Internationalization Considerations

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 [USASCII] characters (see [RFCSTYLE]). Future versions are likely to relax this role, and it is expected that the vocabulary will be extended so that US-ACSII alternatives can be provided when that makes sense (for instance, in contact information).

5. Security Considerations

The "name" attribute on the <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 [RFC6266] for more information.

Furthermore, all security considerations related to XML processing are relevant as well (see [RFC3470]).

6. IANA Considerations

6.1. Internet Media Type Registration

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

This document serves as the specification for the Internet media type "application/rfc+xml". The following is to be 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 as the charset parameter of the "application/xml" media type specified in [RFC3023].

Encoding considerations:

Identical to those of "application/xml" as described in [RFC3023].

Security considerations:

As defined in Section 5. In addition, as this media type uses the "+xml" convention, it inherits the security considerations described in [RFC3023].

Interoperability considerations:

N/A

Published specification:

This specification.

Applications that use this media type:

Applications that either transform xml2rfc to output formats such as plain text or HTML, plus additional analysis tools.

Fragment identifier considerations:

The "anchor" attribute is used for assigning document-wide unique identifiers that can be uses as shorthand pointers, as described in [XPOINTER].

Additional information:

Deprecated alias names for this type:

None.

Magic number(s):

As specified for "application/xml" in [RFC3023].

File extension(s):

.xml

Macintosh file type code(s):

TEXT

Person & email address to contact for further information:

See Authors Section.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See Authors Section.

Change controller:

RFC Series Editor (rse@rfc-editor.org)

7. Acknowledgments

Thanks to everybody who reviewed this document and provided feedback and/or specification text. Thanks especially go to Julian Reschke for editing [XML2RFCv2] and those who provided feedback on that document.

We also thank Marshall T. Rose for both the original design and the reference implementation of the "xml2rfc" formatter.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Front Page Generation

A.1. The /rfc/@category Attribute

For RFCs, the category determines the "maturity level" (see [RFC2026]). The allowed values are "std" for "Standards Track", "bcp" for "BCP", "info" for "Informational", "exp" for "Experimental", and "historic" for - surprise - "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.

A.2. The /rfc/@ipr Attribute

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.

Disclaimer: THIS ONLY PROVIDES IMPLEMENTATION INFORMATION. IF YOU NEED LEGAL ADVICE, PLEASE CONTACT A LAWYER. For further information, refer to http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf.

For the current "Status Of This Memo" text, the submissionType attribute 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.

A.2.1. Current Values: '*trust200902'

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 ([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.

The tools will automatically produce the "correct" text depending on the document's date information (see above):

A.2.1.1. trust200902

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.

A.2.1.2. noModificationTrust200902

This produces additional text from Section 6.c.i of the TLP:

A.2.1.3. noDerivativesTrust200902

This produces the additional text from Section 6.c.ii of the TLP:

A.2.1.4. pre5378Trust200902

This produces the additional text from Section 6.c.iii of the TLP, frequently called the "pre-5378 escape clause":

See Section 4 of http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf for further information about when to use this value.

A.2.2. Historic Values

A.2.2.1. Historic Values: '*trust200811'

The attribute values "http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy_11-10-08.pdf.

A.2.2.2. Historic Values: '*3978'

The attribute values "

A.2.2.3. Historic Values: '*3667'

The attribute values "

A.2.2.4. Historic Values: '*2026'

The attribute values "

The special value "

Appendix B. Relax NG Schema

Index

Author's Address