RFC7749
Internet Architecture Board (IAB) J. Reschke Request for Comments: 7749 greenbytes Obsoletes: 2629 February 2016 Category: Informational ISSN: 2070-1721
The "xml2rfc" Version 2 Vocabulary
Abstract
This document defines the "xml2rfc" version 2 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts.
Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.
This document obsoletes RFC 2629.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7749.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This 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.
Contents
Introduction
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 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 as index generation, populating a keyword database, or syntax checks).
Syntax Notation
The XML vocabulary here is defined in prose, based on the RELAX NG schema [RNC] contained in Appendix C (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).
Elements
The sections below describe all elements and their attributes.
Note that attributes not labeled "mandatory" are optional.
Except inside <artwork>, horizontal whitespace and line breaks are collapsed into a single whitespace, and leading and trailing whitespace is trimmed off.
<abstract>
Contains the Abstract of the document. The Abstract ought to be self-contained and thus should not contain references or unexpanded abbreviations. See Section 4.3 of RFC7322 for more information.
This element appears as a child element of <front> (Section 2.19).
Content model:
One or more <t> elements (Section 2.38)
<address>
Provides address information for the author.
This element appears as a child element of <author> (Section 2.6).
Content model:
In this order:
1. One optional <postal> element (Section 2.27)
2. One optional <phone> element (Section 2.26)
3. One optional <facsimile> element (Section 2.16)
4. One optional <email> element (Section 2.14)
5. One optional <uri> element (Section 2.42)
<annotation>
Provides additional prose augmenting a bibliographical reference.
This element appears as a child element of <reference> (Section 2.30).
Content model:
In any order:
o Text
o <xref> elements (Section 2.45)
o <eref> elements (Section 2.15)
o <iref> elements (Section 2.20)
o <cref> elements (Section 2.12)
o <spanx> elements (Section 2.36)
<area>
Provides information about the IETF area to which this document relates (currently not used when generating documents).
The value ought to be either the full name or the abbreviation of one of the IETF areas as listed on <https://www.ietf.org/iesg/area.html>. The list at the time that this document is being published is "Applications and Real-Time" ("art"), "General" ("gen"), "Internet" ("int"), "Operations and Management" ("ops"), "Routing" ("rtg"), "Security" ("sec"), and "Transport" ("tsv").
Note that the set of IETF areas can change over time; for instance, "Applications and Real-Time" ("art") replaced "Applications" ("app") and "Real-time Applications and Infrastructure" ("rai") in 2015.
This element appears as a child element of <front> (Section 2.19).
Content model: only text content.
<artwork>
This element allows the inclusion of "artwork" in the document.
<artwork> is the only element in the vocabulary that provides full control of horizontal whitespace and line breaks; thus, it is used for a variety of things, such as:
o diagrams ("line art"),
o source code,
o formal languages (such as ABNF RFC5234 or the RNC notation used
in this document),
o message flow diagrams,
o complex tables, or
o protocol unit diagrams.
Note that processors differ in the handling of horizontal TAB characters (some expand them, some treat them as single spaces), 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 a fallback for output formats that do not support graphics; thus, it ought to contain either (1) a "line art" variant of the graphics or (2) prose that describes the included image in sufficient detail. Note that RFCs occasionally are published with enhanced diagrams; RFC5598 is a recent example of an RFC that was published along with a PDF with images.
This element appears as a child element of <figure> (Section 2.17).
Content model:
Text
"align" Attribute
Controls whether the artwork appears left justified (default), centered, or right justified.
Allowed values:
o "left" (default)
o "center"
o "right"
"alt" Attribute
Alternative text description of the artwork (not just the caption).
"height" Attribute
The suggested height of the graphics (when it was included using the "src" attribute).
This attribute is format dependent and ought to be avoided.
When generating HTML output [HTML], current implementations copy the attribute "as is", thus effectively treating it as CSS (Cascading Style Sheets) pixels (see Section 4.3.2 of [CSS]). For other output formats, it is usually ignored.
"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).
"src" Attribute
The URI reference of a graphics file (Section 4.1 of RFC3986).
Note that this can be a "data" URI RFC2397 as well, in which case the graphics file is wholly part of the XML file.
"type" Attribute
Specifies the type of the artwork.
The value is either an Internet Media Type (see RFC2046) or a keyword (such as "abnf"). The set of recognized keywords varies across implementations.
How it is used depends on context and application. For instance, a formatter can attempt to syntax-highlight code in certain known languages.
"width" Attribute
The suggested width of the graphics (when it was included using the "src" attribute).
This attribute is format dependent and ought to be avoided.
When generating HTML output [HTML], current implementations copy the attribute "as is", thus effectively treating it as CSS pixels (see Section 4.3.2 of [CSS]). For other output formats, it is usually ignored.
"xml:space" Attribute
Determines whitespace handling.
"preserve" is both the default value and the only meaningful setting (because that's what the <artwork> element is for).
See also Section 2.10 of [XML].
Allowed values:
o "default"
o "preserve" (default)
<author>
Provides information about a document's author. This is used both for the document itself (at the beginning of the document) and for referenced documents (inside of <reference>).
The <author> elements contained within the document's <front> element are used to fill the boilerplate, and also to generate the "Author's Address" section (see Section 4.12 of RFC7322).
Note that an "author" can also be just an organization (by not specifying any of the name attributes, but adding the <organization> child element).
Furthermore, the "role" attribute can be used to mark an author as "editor". This is reflected on the front page and in the "Author's Address" section, as well as in bibliographical references. Note that this specification does not define a precise meaning for the term "editor".
See Sections 4.10 and 4.11 of RFC7322 for more information.
This element appears as a child element of <front> (Section 2.19).
Content model:
In this order:
1. One optional <organization> element (Section 2.25)
2. One optional <address> element (Section 2.2)
"fullname" Attribute
The full name (used in the automatically generated "Author's Address" section).
"initials" Attribute
An abbreviated variant of the given name(s), to be used in conjunction with the separately specified surname. It usually appears on the front page, in footers, and in references.
Some processors will post-process the value -- for instance, when it only contains a single letter (in which case they might add a trailing dot). Relying on this kind of post-processing can lead to results varying across formatters and thus ought to be avoided.
"role" Attribute
Specifies the role the author had in creating the document.
Allowed values:
o "editor"
"surname" Attribute
The author's surname, to be used in conjunction with the separately specified initials. It usually appears on the front page, in footers, and in references.
<back>
Contains the "back" part of the document: the references and appendices. In <back>, <section> elements indicate appendices.
This element appears as a child element of <rfc> (Section 2.33).
Content model:
In this order:
1. Optional
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.
Internationalization Considerations
This format is based on [XML] and 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 (see [USASCII] and Section 3 of RFC2223). It is possible that this rule will be relaxed in future revisions of the RFC format (for instance, to allow non-ASCII characters in examples and contact information). In that case, it is expected that the vocabulary will be extended accordingly.
Security Considerations
The "name" attribute of the <artwork> element (Section 2.5.4) can be used to derive a filename for saving to a local file system. Trusting this kind of information without pre-processing is a known security risk; see Section 4.3 of RFC6266 for more information.
Furthermore, the nature of XML, plus vocabulary features such as typed artwork, make it attractive to extract content from documents for further processing, such as for the purpose of checking syntax or computing/verifying examples. In the latter case, care needs to be taken that only trusted content is processed.
All security considerations related to XML processing are relevant as well (see Section 7 of RFC3470).
IANA Considerations
Internet Media Type Registration
IANA maintains the registry of Internet Media Types [BCP13] at <http://www.iana.org/assignments/media-types>.
This document serves as the specification for the Internet Media Type "application/rfc+xml". The following has been registered with IANA.
Type name: application
Subtype name: rfc+xml
Required parameters: There are no required parameters.
Optional parameters: "charset": This parameter has identical
semantics to the charset parameter of the "application/xml" Media Type specified in Section 9.1 of RFC7303.
Encoding considerations: Identical to those of "application/xml" as
described in Section 9.1 of RFC7303.
Security considerations: As defined in Section 7. In addition, as
this media type uses the "+xml" convention, it inherits the security considerations described in Section 10 of RFC7303.
Interoperability considerations: Some aspects of this vocabulary
currently cannot be used interoperably; among the reasons for this are that they weren't precisely defined in the first place, that they have been added in an ad hoc fashion later on, or that they are specific to certain output formats. This specification attempts to identify these cases in the description of the individual elements/attributes.
Published specification: This specification.
Applications that use this media type: Applications that transform
xml2rfc to output formats such as plain text or HTML, plus additional analysis tools.
Fragment identifier considerations: The "anchor" attribute is used
for assigning document-wide unique identifiers that can be used as shorthand pointers, as described in Section 3.2 of [XPOINTER].
Additional information:
Deprecated alias names for this type: None.
Magic number(s): As specified for "application/xml" in
Section 9.1 of RFC7303.
File extension(s): .xml or .rfcxml when disambiguation from other
XML files is needed.
Macintosh file type code(s): TEXT
Person & email address to contact for further information: See the
Author's Address section of RFC 7749.
Intended usage: COMMON
Restrictions on usage: None.
Author: See the Author's Address section of RFC 7749.
Change controller: RFC Series Editor ([email protected])
References
Normative References
RFC2046 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
RFC3966 Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
RFC6068 Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <http://www.rfc-editor.org/info/rfc6068>.
RFC7303 Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014,
<http://www.rfc-editor.org/info/rfc7303>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", W3C Recommendation REC-xml-20081126,
November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126/>.
Latest version available at <http://www.w3.org/TR/xml>.
Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013, <http://www.rfc-editor.org/info/bcp13>.
[CSS] Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading
Style Sheets Level 2 Revision 1 (CSS 2.1) Specification",
W3C Recommendation REC-CSS2-20110607, June 2011,
<http://www.w3.org/TR/2011/REC-CSS2-20110607/>.
Latest version available at <http://www.w3.org/TR/CSS2>.
[HTML] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle
Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
Recommendation REC-html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028/>.
Latest version available at <http://www.w3.org/TR/html5/>.
[IDGUIDE] Housley, R., "Guidelines to Authors of Internet-Drafts",
December 2010,
<http://www.ietf.org/id-info/guidelines.html>.
[JING] Thai Open Source Software Center Ltd, "Jing - A RELAX NG
validator in Java", 2008,
<http://www.thaiopensource.com/relaxng/jing.html>.
Downloads: <https://code.google.com/p/jing-trang/ downloads/list>.
RFC2026 Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>.
RFC2223 Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, DOI 10.17487/RFC2223, October 1997, <http://www.rfc-editor.org/info/rfc2223>.
RFC2397 Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<http://www.rfc-editor.org/info/rfc2397>.
RFC2629 Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
RFC3470 Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML) within IETF
Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470,
January 2003, <http://www.rfc-editor.org/info/rfc3470>.
RFC3667 Bradner, S., "IETF Rights in Contributions", RFC 3667,
DOI 10.17487/RFC3667, February 2004,
<http://www.rfc-editor.org/info/rfc3667>.
RFC3978 Bradner, S., Ed., "IETF Rights in Contributions",
RFC 3978, DOI 10.17487/RFC3978, March 2005, <http://www.rfc-editor.org/info/rfc3978>.
RFC3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
RFC5234 Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
RFC5378 Bradner, S., Ed., and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>.
RFC5598 Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>.
PDF version: <http://www.rfc-editor.org/rfc/rfc5598.pdf>
RFC5741 Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
Headers, and Boilerplates", RFC 5741, DOI 10.17487/RFC5741, December 2009, <http://www.rfc-editor.org/info/rfc5741>.
RFC6266 Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, DOI 10.17487/RFC6266, June 2011, <http://www.rfc-editor.org/info/rfc6266>.
RFC7322 Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014,
<http://www.rfc-editor.org/info/rfc7322>.
[RNC] Clark, J., "RELAX NG Compact Syntax", OASIS,
November 2002, <http://www.oasis-open.org/committees/ relax-ng/compact-20021121.html>.
[TCLReadme]
Rose, M., Fenner, B., and C. Levert, "xml2rfc v1.35pre1",
October 2009, <http://svn.tools.ietf.org/svn/tools/
xml2rfc/archive/README.html>.
[TLP1.0] IETF Trust, "Legal Provisions Relating to IETF Documents",
November 2008,
<http://trustee.ietf.org/license-info/IETF-TLP-1.htm>.
[TLP2.0] IETF Trust, "Legal Provisions Relating to IETF Documents",
February 2009,
<http://trustee.ietf.org/license-info/IETF-TLP-2.htm>.
[TLP3.0] IETF Trust, "Legal Provisions Relating to IETF Documents",
September 2009,
<http://trustee.ietf.org/license-info/IETF-TLP-3.htm>.
[TLP4.0] IETF Trust, "Legal Provisions Relating to IETF Documents",
December 2009,
<http://trustee.ietf.org/license-info/IETF-TLP-4.htm>.
[TLP5.0] IETF Trust, "Legal Provisions Relating to IETF Documents",
March 2015,
<http://trustee.ietf.org/license-info/IETF-TLP-5.htm>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[V1rev] Rose, M., "Writing I-Ds and RFCs using XML (revised)",
February 2008,
<http://svn.tools.ietf.org/svn/tools/xml2rfc/archive/
draft-mrose-writing-rfcs.html>.
[XPOINTER] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
Framework", W3C Recommendation REC-xptr-framework-
20030325, March 2003,
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.
Latest version available at
<http://www.w3.org/TR/xptr-framework/>.
Appendix A. Front-Page ("Boilerplate") Generation
A.1. The "category" Attribute
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; when supplied, it will appear as "Intended Status". Supplying this information can be useful to reviewers.
A.2. The "ipr" Attribute
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 they remain simply for historic reasons. Of these values, only a few are currently in use; all others are supported by various tools for backwards compatibility with old source files.
*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 <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>.
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.
A.2.1. Current Values: "*trust200902"
The name for these values refers to the IETF Trust's "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.
Formatters will automatically produce the "correct" text, depending on the document's date information (see above):
+----------+--------------------------------+ | TLP | starting with publication date | +----------+--------------------------------+ | [TLP3.0] | 2009-11-01 | | [TLP4.0] | 2010-04-01 | +----------+--------------------------------+
The TLP was again updated in March 2015 ([TLP5.0]), but the changes made in that version do not affect the boilerplate text.
A.2.1.1. trust200902
This value should be used unless one of the more specific "*trust200902" values is a better fit. It produces the text in Sections 6.a and 6.b of the TLP.
A.2.1.2. noModificationTrust200902
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.
A.2.1.3. noDerivativesTrust200902
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.
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" (referring to changes introduced in RFC5378):
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
See Section 4 of <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf> for further information about when to use this value.
*Note:* this text appears under "Copyright Notice", unless the document was published before November 2009, in which case it appears under "Status of This Memo".
A.2.2. Historic Values
A.2.2.1. Historic Values: "*trust200811"
The attribute values "trust200811", "noModificationTrust200811", and "noDerivativesTrust200811" are similar to their "trust200902" counterparts, except that they use text specified in [TLP1.0].
A.2.2.2. Historic Values: "*3978"
The attribute values "full3978", "noModification3978", and "noDerivatives3978" are similar to their counterparts above, except that they use text specified in Section 5 of RFC3978.
A.2.2.3. Historic Values: "*3667"
The attribute values "full3667", "noModification3667", and "noDerivatives3667" are similar to their counterparts above, except that they use text specified in Section 5 of RFC3667.
A.2.2.4. Historic Values: "*2026"
The attribute values "full2026" and "noDerivativeWorks2026" are similar to their counterparts above, except that they use text specified in Section 10 of RFC2026.
The special value "none" was also used back then; it denied the IETF any rights beyond publication as an Internet-Draft.
A.3. The "submissionType" Attribute
The RFC Editor publishes documents from different document streams, of which the IETF stream is the most prominent. Other streams are the independent stream (used for things such as discussion of Internet-related technologies that are not part of the IETF agenda), the IAB stream (Internet Architecture Board) and the IRTF stream (Internet Research Task Force).
The values for the attribute are "IETF" (the default value), "independent", "IAB", 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 the "submissionType" attribute will have the following effect:
o 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).
o For RFCs, it affects the whole "Status of This Memo" section (see
Section 3.2.2 of RFC5741).
o For all RFCs and Internet-Drafts, it determines whether the
"Copyright Notice" mentions the copyright on Code Components (see
Section 6 of the TLP ("Text to Be Included in IETF Documents")).
A.4. The "consensus" Attribute
For some of the publication streams (see Appendix A.3), the "Status of This Memo" section depends on whether there was a consensus to publish (again, see Section 3.2.2 of RFC5741).
The "consensus" attribute ("yes"/"no", defaulting to "yes") can be used to supply this information. The effect for the various streams is:
o "independent" and "IAB": none.
o "IETF": mention that there was an IETF consensus.
o "IRTF": mention that there was a research group consensus (where
the name of the research group is extracted from the <workgroup> element).
Appendix B. Changes from RFC 2629 ("v1")
B.1. Removed Elements
The <appendix> element has been removed; to generate an appendix, place a <section> inside <back>.
B.2. Changed Defaults
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.
B.3. Changed Elements
<artwork>: Has a set of new attributes: "name", "type", "src", "align", "alt", "width", and "height". (Section 2.5)
<author>: The <organization> element is now optional. The "role" attribute was added. (Section 2.6)
<country>: The requirement to use ISO 3166 codes was removed. (Section 2.11)
<date>: All attributes are now optional. (Section 2.13)
<figure>: Has a set of new attributes: "suppress-title", "src", "align", "alt", "width", and "height". (Section 2.17)
<iref>: Has a new "primary" attribute. (Section 2.20)
<list>: The "style" attribute isn't restricted to a set of enumerated values anymore. The "hangIndent" and "counter" attributes have been added. (Section 2.22)
<reference>: <annotation> allows adding prose to a reference. The "anchor" attribute has been made mandatory. (Section 2.30)
<references>: Can now appear multiple times and can carry a "title" attribute (so that normative and informative references can be split). (Section 2.31)
<rfc>: The "ipr" attribute has gained additional values. The attributes "consensus", "iprExtract", "submissionType", and "xml:lang" have been added. (Section 2.33)
<section>: The new "toc" attribute controls whether it will appear in the Table Of Contents. <iref> can now appear as a direct child element. (Section 2.34)
<t>: The "anchor" attribute can now be used as well; however, there are restrictions on how they can be referred to. (Section 2.38)
B.4. New Elements
The following elements have been added: <annotation> (Section 2.3), <c> (Section 2.8), <cref> (Section 2.12), <format> (Section 2.18), <spanx> (Section 2.36), <texttable> (Section 2.39), and <ttcol> (Section 2.41).
Appendix C. RELAX NG Schema
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
rfc =
element rfc {
attribute number { text }?,
[ a:defaultValue = "" ] attribute obsoletes { text }?,
[ a:defaultValue = "" ] attribute updates { text }?,
attribute category {
"std" | "bcp" | "info" | "exp" | "historic"
}?,
attribute consensus { "no" | "yes" }?,
attribute seriesNo { text }?,
attribute ipr {
"full2026"
| "noDerivativeWorks2026"
| "none"
| "full3667"
| "noModification3667"
| "noDerivatives3667"
| "full3978"
| "noModification3978"
| "noDerivatives3978"
| "trust200811"
| "noModificationTrust200811"
| "noDerivativesTrust200811"
| "trust200902"
| "noModificationTrust200902"
| "noDerivativesTrust200902"
| "pre5378Trust200902"
}?,
attribute iprExtract { xsd:IDREF }?,
[ a:defaultValue = "IETF" ]
attribute submissionType {
"IETF" | "IAB" | "IRTF" | "independent"
}?,
attribute docName { text }?,
[ a:defaultValue = "en" ] attribute xml:lang { text }?,
front,
middle,
back?
}
front =
element front {
title,
author+,
date,
area*,
workgroup*,
keyword*,
abstract?,
note*
}
title =
element title {
attribute abbrev { text }?,
text
}
author =
element author {
attribute initials { text }?,
attribute surname { text }?,
attribute fullname { text }?,
attribute role { "editor" }?,
organization?,
address?
}
organization =
element organization {
attribute abbrev { text }?,
text
}
address =
element address { postal?, phone?, facsimile?, email?, uri? }
postal =
element postal { street+, (city | region | code | country)* }
street = element street { text }
city = element city { text }
region = element region { text }
code = element code { text }
country = element country { text }
phone = element phone { text }
facsimile = element facsimile { text }
email = element email { text }
uri = element uri { text }
date =
element date {
attribute day { text }?,
attribute month { text }?,
attribute year { text }?,
empty
}
area = element area { text }
workgroup = element workgroup { text }
keyword = element keyword { text }
abstract = element abstract { t+ }
note =
element note {
attribute title { text },
t+
}
middle = element middle { section+ }
section =
element section {
attribute anchor { xsd:ID }?,
attribute title { text },
[ a:defaultValue = "default" ]
attribute toc { "include" | "exclude" | "default" }?,
(t | figure | texttable | iref)*,
section*
}
t =
element t {
attribute anchor { xsd:ID }?,
attribute hangText { text }?,
(text
| \list
| figure
| xref
| eref
| iref
| cref
| spanx
| vspace)*
}
\list =
element list {
attribute style { text }?,
attribute hangIndent { text }?,
attribute counter { text }?,
t+
}
xref =
element xref {
attribute target { xsd:IDREF },
[ a:defaultValue = "false" ]
attribute pageno { "true" | "false" }?,
[ a:defaultValue = "default" ]
attribute format { "counter" | "title" | "none" | "default" }?,
text
}
eref =
element eref {
attribute target { text },
text
}
iref =
element iref {
attribute item { text },
[ a:defaultValue = "" ] attribute subitem { text }?,
[ a:defaultValue = "false" ]
attribute primary { "true" | "false" }?,
empty
}
cref =
element cref {
attribute anchor { xsd:ID }?,
attribute source { text }?,
text
}
spanx =
element spanx {
[ a:defaultValue = "preserve" ]
attribute xml:space { "default" | "preserve" }?,
[ a:defaultValue = "emph" ] attribute style { text }?,
text
}
vspace =
element vspace {
[ a:defaultValue = "0" ] attribute blankLines { text }?,
empty
}
figure =
element figure {
attribute anchor { xsd:ID }?,
[ a:defaultValue = "" ] attribute title { text }?,
[ a:defaultValue = "false" ]
attribute suppress-title { "true" | "false" }?,
attribute src { text }?,
[ a:defaultValue = "left" ]
attribute align { "left" | "center" | "right" }?,
[ a:defaultValue = "" ] attribute alt { text }?,
[ a:defaultValue = "" ] attribute width { text }?,
[ a:defaultValue = "" ] attribute height { text }?,
iref*,
preamble?,
artwork,
postamble?
}
preamble =
element preamble { (text | xref | eref | iref | cref | spanx)* }
artwork =
element artwork {
[ a:defaultValue = "preserve" ]
attribute xml:space { "default" | "preserve" }?,
[ a:defaultValue = "" ] attribute name { text }?,
[ a:defaultValue = "" ] attribute type { text }?,
attribute src { text }?,
[ a:defaultValue = "left" ]
attribute align { "left" | "center" | "right" }?,
[ a:defaultValue = "" ] attribute alt { text }?,
[ a:defaultValue = "" ] attribute width { text }?,
[ a:defaultValue = "" ] attribute height { text }?,
text*
}
postamble =
element postamble { (text | xref | eref | iref | cref | spanx)* }
texttable =
element texttable {
attribute anchor { xsd:ID }?,
[ a:defaultValue = "" ] attribute title { text }?,
[ a:defaultValue = "false" ]
attribute suppress-title { "true" | "false" }?,
[ a:defaultValue = "center" ]
attribute align { "left" | "center" | "right" }?,
[ a:defaultValue = "full" ]
attribute style { "all" | "none" | "headers" | "full" }?,
preamble?,
ttcol+,
c*,
postamble?
}
ttcol =
element ttcol {
attribute width { text }?,
[ a:defaultValue = "left" ]
attribute align { "left" | "center" | "right" }?,
text
}
c = element c { (text | xref | eref | iref | cref | spanx)* }
back = element back { references*, section* }
references =
element references {
[ a:defaultValue = "References" ] attribute title { text }?,
reference+
}
reference =
element reference {
attribute anchor { xsd:ID },
attribute target { text }?,
front,
seriesInfo*,
format*,
annotation*
}
seriesInfo =
element seriesInfo {
attribute name { text },
attribute value { text },
empty
}
format =
element format {
attribute target { text }?,
attribute type { text },
attribute octets { text }?,
empty
}
annotation =
element annotation { (text | xref | eref | iref | cref | spanx)* }
start = rfc
(This schema was derived from version 1.3.6 of the xml2rfc DTD ("Document Type Definition") (Section 2.8 of [XML]), available from <http://svn.tools.ietf.org/svn/tools/xml2rfc/vocabulary/v2/03/ xml2rfcv2.dtd>.)
C.1. Checking Validity
The validity of XML files can be checked with any tool that supports RELAX NG [RNC]. The reference implementation is the Java-based, open-sourced "Jing" [JING].
To use Jing, download the latest ZIP file from the "downloads" page (currently <https://code.google.com/p/jing-trang/downloads/ detail?name=jing-20091111.zip>), extract the archive, copy "jing.jar" from the "bin" folder, and make sure Java is installed.
To check a file "test.xml" using the RNC file "schema.rnc", run (from a command-line prompt):
java -jar jing.jar -c schema.rnc test.xml
In good Unix tradition, no output means the file is valid.
IAB Members at the Time of Approval
Jari Arkko (IETF Chair) Mary Barnes Marc Blanchet Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Brian Trammell Suzanne Woolf
Acknowledgments
Thanks to everybody who reviewed this document and provided feedback and/or specification text, in particular Brian Carpenter, Elwyn Davies, Tony Hansen, Joe Hildebrand, Paul Hoffman, Henrik Levkowetz, Alice Russo, Tom Taylor, Dave Thaler, Jim Schaad, and Nico Williams.
We also thank Marshall T. Rose for both the original design and the reference implementation of the "xml2rfc" formatter.
Index
A
Attributes
abbrev 21, 34
align 7, 14, 32, 34
alt 7, 15
anchor 11, 15, 23, 28, 31-32
blankLines 35
category 25
consensus 25
counter 18
day 12
docName 25
format 36
fullname 9
hangIndent 18
hangText 31
height 7, 15
initials 9
ipr 26
iprExtract 26
item 17
month 12
name 7, 29
number 27
obsoletes 27
octets 16
pageno 37
primary 17
role 9
seriesNo 27
source 12
src 7, 15
style 19, 30, 32
subitem 17
submissionType 27
suppress-title 15, 33
surname 10
target 13, 16, 23, 37
title 15, 21, 24, 28, 33
toc 28
type 8, 16
updates 27
value 29
width 8, 15, 34
xml:lang 28
xml:space 8, 30
year 13
abbrev attribute
in organization element 21
in title element 34
abstract element 4, 50
inside front 16
address element 4, 50
inside author 9
align attribute
in artwork element 7
in figure element 14
in texttable element 32
in ttcol element 34
alt attribute
in artwork element 7
in figure element 15
anchor attribute
in cref element 11
in figure element 15
in reference element 23
in section element 28
in t element 31
in texttable element 32
annotation element 5, 50
inside reference 23
application/rfc+xml Media Type 40
area element 5, 50
inside front 16
artwork element 6, 50
align attribute 7
alt attribute 7
height attribute 7
inside figure 14
name attribute 7
src attribute 7
type attribute 8
width attribute 8
xml:space attribute 8
author element 8, 50
fullname attribute 9
initials attribute 9
inside front 16
role attribute 9
surname attribute 10
B
back element 10, 50
inside rfc 25
blankLines attribute
in vspace element 35
C
c element 10, 50
inside texttable 32
category attribute
in rfc element 25
city element 11, 50
inside postal 22
code element 11, 50
inside postal 22
consensus attribute
in rfc element 25
counter attribute
in list element 18
country element 11, 50
inside postal 22
cref element 11, 50
anchor attribute 11
inside annotation 5
inside c 10
inside postamble 22
inside preamble 23
inside t 31
source attribute 12
D
date element 12, 50
day attribute 12
inside front 16
month attribute 12
year attribute 13
day attribute
in date element 12
docName attribute
in rfc element 25
E
Elements
abstract 4, 16
address 4, 9
annotation 5, 23
area 5, 16
artwork 6, 14
author 8, 16
back 10, 25
c 10, 32
city 11, 22
code 11, 22
country 11, 22
cref 5, 10-11, 22-23, 31
date 12, 16
email 5, 13
eref 5, 10, 13, 22-23, 31
facsimile 5, 14
figure 14, 28, 31
format 15, 23
front 16, 23, 25
iref 5, 10, 14, 17, 22-23, 28, 31
keyword 16, 18
list 18, 31
middle 20, 25
note 17, 20
organization 9, 21
phone 5, 21
postal 5, 21
postamble 14, 22, 32
preamble 14, 22, 32
reference 23-24
references 10, 24
region 22, 24
rfc 24
section 10, 20, 28
seriesInfo 23, 29
spanx 5, 10, 22-23, 29, 31
street 21, 30
t 4, 18, 20, 28, 31
texttable 28, 31
title 16, 33
ttcol 32, 34
uri 5, 34
vspace 31, 34
workgroup 16, 35
xref 5, 10, 22, 31, 35
email element 13, 50
inside address 5
eref element 13, 50
inside annotation 5
inside c 10
inside postamble 22
inside preamble 23
inside t 31
target attribute 13
F
facsimile element 14, 50
inside address 5
figure element 14, 50
align attribute 14
alt attribute 15
anchor attribute 15
height attribute 15
inside section 28
inside t 31
src attribute 15
suppress-title attribute 15
title attribute 15
width attribute 15
format attribute
in xref element 36
format element 15, 50
inside reference 23
octets attribute 16
target attribute 16
type attribute 16
front element 16, 50
inside reference 23
inside rfc 25
fullname attribute
in author element 9
H
hangIndent attribute
in list element 18
hangText attribute
in t element 31
height attribute
in artwork element 7
in figure element 15
I
initials attribute
in author element 9
ipr attribute
"*2026" 48
"*3667" 48
"*3978" 47
"*trust200811" 47
"*trust200902" 46
"noDerivativesTrust200902" 47
"noModificationTrust200902" 46
"pre5378Trust200902" 47
"trust200902" 46
in rfc element 26
iprExtract attribute
in rfc element 26
iref element 17, 50
inside annotation 5
inside c 10
inside figure 14
inside postamble 22
inside preamble 23
inside section 28
inside t 31
item attribute 17
primary attribute 17
subitem attribute 17
item attribute
in iref element 17
K
keyword element 18, 50
inside front 16
L
list element 18, 50
counter attribute 18
hangIndent attribute 18
inside t 31
style attribute 19
list styles
empty 19
format ... 20
hanging 19
letters 19
numbers 19
symbols 19
M
Media Type
application/rfc+xml 40
middle element 20, 50
inside rfc 25
month attribute
in date element 12
N
name attribute
in artwork element 7
in seriesInfo element 29
note element 20, 50
inside front 17
title attribute 21
number attribute
in rfc element 27
O
obsoletes attribute
in rfc element 27
octets attribute
in format element 16
organization element 21, 50
abbrev attribute 21
inside author 9
P
pageno attribute
in xref element 37
phone element 21, 50
inside address 5
postal element 21, 50
inside address 5
postamble element 22, 50
inside figure 14
inside texttable 32
preamble element 22, 50
inside figure 14
inside texttable 32
primary attribute
in iref element 17
R
reference element 23, 50
anchor attribute 23
inside references 24
target attribute 23
references element 24, 50
inside back 10
title attribute 24
region element 24, 50
inside postal 22
rfc element 24, 50
category attribute 25
consensus attribute 25
docName attribute 25
ipr attribute 26
iprExtract attribute 26
number attribute 27
obsoletes attribute 27
seriesNo attribute 27
submissionType attribute 27
updates attribute 27
xml:lang attribute 28
role attribute
in author element 9
S
section element 28, 50
anchor attribute 28
inside back 10
inside middle 20
inside section 28
title attribute 28
toc attribute 28
seriesInfo element 29, 50
inside reference 23
name attribute 29
value attribute 29
seriesNo attribute
in rfc element 27
source attribute
in cref element 12
spanx element 29, 50
inside annotation 5
inside c 10
inside postamble 22
inside preamble 23
inside t 31
style attribute 30
xml:space attribute 30
src attribute
in artwork element 7
in figure element 15
street element 30, 50
inside postal 21
style attribute
in list element 19
in spanx element 30
in texttable element 32
subitem attribute
in iref element 17
submissionType attribute
in rfc element 27
suppress-title attribute
in figure element 15
in texttable element 33
surname attribute
in author element 10
T
t element 31, 50
anchor attribute 31
hangText attribute 31
inside abstract 4
inside list 18
inside note 20
inside section 28
target attribute
in eref element 13
in format element 16
in reference element 23
in xref element 37
texttable element 31, 50
align attribute 32
anchor attribute 32
inside section 28
style attribute 32
suppress-title attribute 33
title attribute 33
title attribute
in figure element 15
in note element 21
in references element 24
in section element 28
in texttable element 33
title element 33, 50
abbrev attribute 34
inside front 16
toc attribute
in section element 28
ttcol element 34, 50
align attribute 34
inside texttable 32
width attribute 34
type attribute
in artwork element 8
in format element 16
U
updates attribute
in rfc element 27
uri element 34, 50
inside address 5
V
value attribute
in seriesInfo element 29
vspace element 34, 50
blankLines attribute 35
inside t 31
W
width attribute
in artwork element 8
in figure element 15
in ttcol element 34
workgroup element 35, 50
inside front 16
X
xml:lang attribute
in rfc element 28
xml:space attribute
in artwork element 8
in spanx element 30
xref element 35, 50
format attribute 36
inside annotation 5
inside c 10
inside postamble 22
inside preamble 22
inside t 31
pageno attribute 37
target attribute 37
xref formats
counter 36
default 36
none 36
title 36
Y
year attribute
in date element 13
Author's Address
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Email: [email protected] URI: http://greenbytes.de/tech/webdav/
