Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7991

 
 
 

The "xml2rfc" Version 3 Vocabulary

Part 4 of 5, p. 78 to 103
Prev Section       Next Section

 


prevText      Top      ToC       Page 78 
3.  Elements from v2 That Have Been Deprecated

   This section lists the elements from v2 that have been deprecated.
   Note that some elements in v3 have attributes from v2 that are
   deprecated; those are not listed here.

3.1.  <c>

   Deprecated.  Instead, use <tr>, <td>, and <th>.

   This element appears as a child element of <texttable> (Section 3.8).

   Content model:

   In any order:

   o  Text

   o  <bcp14> elements (Section 2.9)

   o  <cref> elements (Section 2.16)

   o  <em> elements (Section 2.22)

   o  <eref> elements (Section 2.24)

   o  <iref> elements (Section 2.27)

   o  <spanx> elements (Section 3.7)

   o  <strong> elements (Section 2.50)

   o  <sub> elements (Section 2.51)

   o  <sup> elements (Section 2.52)

   o  <tt> elements (Section 2.62)

   o  <xref> elements (Section 2.66)

3.2.  <facsimile>

   Deprecated.  The <email> element is a much more useful way to get in
   touch with authors.

   This element appears as a child element of <address> (Section 2.2).

   Content model: only text content.

Top      Up      ToC       Page 79 
3.3.  <format>

   Deprecated.  If the goal is to provide a single URI for a reference,
   use the "target" attribute in <reference> instead.

   This element appears as a child element of <reference>
   (Section 2.40).

   Content model: this element does not have any contents.

3.3.1.  "octets" Attribute

   Deprecated.

3.3.2.  "target" Attribute

   Deprecated.

3.3.3.  "type" Attribute (Mandatory)

   Deprecated.

3.4.  <list>

   Deprecated.  Instead, use <dl> for list/@style "hanging"; <ul> for
   list/@style "empty" or "symbols"; and <ol> for list/@style "letters",
   "numbers", "counter", or "format".

   This element appears as a child element of <t> (Section 2.53).

   Content model:

   One or more <t> elements (Section 2.53)

3.4.1.  "counter" Attribute

   Deprecated.  The functionality of this attribute has been replaced
   with <ol>/@start.

3.4.2.  "hangIndent" Attribute

   Deprecated.  Use <dl> instead.

3.4.3.  "style" Attribute

   Deprecated.

Top      Up      ToC       Page 80 
3.5.  <postamble>

   Deprecated.  Instead, use a regular paragraph after the figure or
   table.

   This element appears as a child element of <figure> (Section 2.25)
   and <texttable> (Section 3.8).

   Content model:

   In any order:

   o  Text

   o  <bcp14> elements (Section 2.9)

   o  <cref> elements (Section 2.16)

   o  <em> elements (Section 2.22)

   o  <eref> elements (Section 2.24)

   o  <iref> elements (Section 2.27)

   o  <spanx> elements (Section 3.7)

   o  <strong> elements (Section 2.50)

   o  <sub> elements (Section 2.51)

   o  <sup> elements (Section 2.52)

   o  <tt> elements (Section 2.62)

   o  <xref> elements (Section 2.66)

Top      Up      ToC       Page 81 
3.6.  <preamble>

   Deprecated.  Instead, use a regular paragraph before the figure or
   table.

   This element appears as a child element of <figure> (Section 2.25)
   and <texttable> (Section 3.8).

   Content model:

   In any order:

   o  Text

   o  <bcp14> elements (Section 2.9)

   o  <cref> elements (Section 2.16)

   o  <em> elements (Section 2.22)

   o  <eref> elements (Section 2.24)

   o  <iref> elements (Section 2.27)

   o  <spanx> elements (Section 3.7)

   o  <strong> elements (Section 2.50)

   o  <sub> elements (Section 2.51)

   o  <sup> elements (Section 2.52)

   o  <tt> elements (Section 2.62)

   o  <xref> elements (Section 2.66)

3.7.  <spanx>

   Deprecated.

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 3.1), <postamble> (Section 3.5),
   <preamble> (Section 3.6), and <t> (Section 2.53).

   Content model: only text content.

Top      Up      ToC       Page 82 
3.7.1.  "style" Attribute

   Deprecated.  Instead of <spanx style="emph">, use <em>; instead of
   <spanx style="strong">, use <strong>; instead of <spanx
   style="verb">, use <tt>.

3.7.2.  "xml:space" Attribute

   Deprecated.

   Allowed values:

   o  "default"

   o  "preserve" (default)

3.8.  <texttable>

   Deprecated.  Use <table> instead.

   This element appears as a child element of <aside> (Section 2.6) and
   <section> (Section 2.46).

   Content model:

   In this order:

   1.  One optional <name> element (Section 2.32)

   2.  One optional <preamble> element (Section 3.6)

   3.  One or more <ttcol> elements (Section 3.9)

   4.  Optional <c> elements (Section 3.1)

   5.  One optional <postamble> element (Section 3.5)

3.8.1.  "align" Attribute

   Deprecated.

   Allowed values:

   o  "left"

   o  "center" (default)

   o  "right"

Top      Up      ToC       Page 83 
3.8.2.  "anchor" Attribute

   Deprecated.

3.8.3.  "style" Attribute

   Deprecated.

3.8.4.  "suppress-title" Attribute

   Deprecated.

   Allowed values:

   o  "true"

   o  "false" (default)

3.8.5.  "title" Attribute

   Deprecated.

3.9.  <ttcol>

   Deprecated.  Instead, use <tr>, <td>, and <th>.

   This element appears as a child element of <texttable> (Section 3.8).

   Content model:

   In any order:

   o  Text

   o  <cref> elements (Section 2.16)

   o  <eref> elements (Section 2.24)

   o  <iref> elements (Section 2.27)

   o  <xref> elements (Section 2.66)

Top      Up      ToC       Page 84 
3.9.1.  "align" Attribute

   Deprecated.

   Allowed values:

   o  "left" (default)

   o  "center"

   o  "right"

3.9.2.  "width" Attribute

   Deprecated.

3.10.  <vspace>

   Deprecated.  In earlier versions of this format, <vspace> was often
   used to get an extra blank line in a list element; in the v3
   vocabulary, that can be done instead by using multiple <t> elements
   inside the <li> element.  Other uses have no direct replacement.

   This element appears as a child element of <t> (Section 2.53).

   Content model: this element does not have any contents.

3.10.1.  "blankLines" Attribute

   Deprecated.

4.  SVG

   The discussion of the use of SVG can be found in [RFC7996].  This
   element is part of the namespace "http://www.w3.org/2000/svg".

Top      Up      ToC       Page 85 
5.  Use of CDATA Structures and Escaping

   A common problem authors have with <artwork> and <sourcecode>
   elements is that the XML processor returns errors if the text in the
   artwork contains either the "&" or "<" character, or the string
   "]]>".  To avoid these problems, the "&" and "<" characters may be
   escaped using the strings "&amp;" and "&lt;", respectively; the "]]>"
   string can be represented as "]]&gt;".  Alternatively, they may be
   surrounded in a CDATA structure: "<![CDATA[]]>".  For example:

   Desired output:
      allowed-chars = "." | "," | "&" | "<" | ">" | "|"

   Using escaping:
   <sourcecode>
      allowed-chars = "." | "," | "&amp;" | "&lt;" | "&gt;" | "|"
   </sourcecode>

   Using CDATA:
   <sourcecode>
   <![CDATA[   allowed-chars = "." | "," | "&" | "<" | ">" | "|"]]>
   </sourcecode>

   Using CDATA is not a panacea, but it does help prevent having to use
   escapes in places where using escapes can cause other problems, such
   as difficulty of inclusion from other documents.

6.  Internationalization Considerations

   This format is based on [XML] and thus does not have any issues
   representing arbitrary Unicode [UNICODE] characters in text content.
   The RFC Series Editor may restrict some of the characters that can be
   used in a particular RFC; the rules for such restrictions are covered
   in [RFC7997].

7.  Security Considerations

   The "name" attribute of the <artwork> element (Section 2.5.5) 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.

   The "src" attribute of the <artwork> element can be used to read
   files from the local system.  Processing tools must be careful to not
   accept dangerous values for the filename, particularly those that
   contain absolute references outside the current directory.

Top      Up      ToC       Page 86 
   The "type" attribute of the <artwork> and <sourcecode> elements is
   meant to encourage formatters to automatically extract known types of
   content from an RFC or Internet-Draft.  While extraction is probably
   safe, those tools might also think that they could further process
   the extracted content, such as by rendering artwork or executing
   code.  Doing so without first sanity-checking the extracted content
   is clearly a terrible idea from a security perspective.  More
   generally, a tool that is reading XML input needs to be suspicious of
   any content that it intends to post-process.

   When there is an external reference to a URL, a processor or renderer
   should fetch the content into a sandbox and should have only a
   localized impact on the document processing and rendering.

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

8.  IANA Considerations

8.1.  Internet Media Type Registration

   IANA maintains the registry of Internet Media Types [RFC6838] at
   <https://www.iana.org/assignments/media-types>.

   This document updates the specification for the Internet Media Type
   "application/rfc+xml" from the one in [RFC7749].  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].

Top      Up      ToC       Page 87 
   Interoperability considerations:  Different implementations of this
      format have had interoperability issues.  It is not expected that
      publication of this application will cause those implementations
      to be fixed.

   Published specification:  This specification.

   Applications that use this Media Type:  Applications that transform
      xml2rfc to output representations such as plain text or HTML, plus
      additional analysis tools.

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

   Additional information:

      Deprecated alias names for this type:  None

      Magic number(s):  As specified for "application/xml" in [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 7991.

   Intended usage:  COMMON

   Restrictions on usage:  None

   Author:  See the Author's Address section of RFC 7991.

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

8.2.  Link Relation Registration

   IANA has registered "convertedFrom" in the "Link Relation Types"
   registry [LINKRELATIONS].

   Relation Name: convertedFrom

   Description: The document linked to was later converted to the
   document that contains this link relation.  For example, an RFC can
   have a link to the Internet-Draft that became the RFC; in that case,
   the link relation would be "convertedFrom".

Top      Up      ToC       Page 88 
   Reference: This document.

   Notes: This relation is different than "predecessor-version" in that
   "predecessor-version" is for items in a version control system.  It
   is also different than "previous" in that this relation is used for
   converted resources, not those that are part of a sequence of
   resources.

   Application Data: None

9.  References

9.1.  Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/bcp14>.

   [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,
              <https://www.w3.org/TR/2008/REC-xml-20081126/>.

              Latest version available at <http://www.w3.org/TR/xml>.

9.2.  Informative References

   [IDGUIDE]  Housley, R., "Guidelines to Authors of Internet-Drafts",
              December 2010, <https://www.ietf.org/id-info/
              guidelines.html>.

   [LINKRELATIONS]
              IANA, "Link Relations", <https://www.iana.org/assignments/
              link-relations/>.

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

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

Top      Up      ToC       Page 89 
   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <http://www.rfc-editor.org/info/rfc3339>.

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

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <http://www.rfc-editor.org/info/rfc3966>.

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

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

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

Top      Up      ToC       Page 90 
   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <http://www.rfc-editor.org/info/rfc6838>.

   [RFC6949]  Flanagan, H. and N. Brownlee, "RFC Series Format
              Requirements and Future Development", RFC 6949,
              DOI 10.17487/RFC6949, May 2013,
              <http://www.rfc-editor.org/info/rfc6949>.

   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
              DOI 10.17487/RFC7303, July 2014,
              <http://www.rfc-editor.org/info/rfc7303>.

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              DOI 10.17487/RFC7322, September 2014,
              <http://www.rfc-editor.org/info/rfc7322>.

   [RFC7669]  Levine, J., "Assigning Digital Object Identifiers to
              RFCs", RFC 7669, DOI 10.17487/RFC7669, October 2015,
              <http://www.rfc-editor.org/info/rfc7669>.

   [RFC7749]  Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
              RFC 7749, DOI 10.17487/RFC7749, February 2016,
              <http://www.rfc-editor.org/info/rfc7749>.

   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
              "RFC Streams, Headers, and Boilerplates", RFC 7841,
              DOI 10.17487/RFC7841, May 2016,
              <http://www.rfc-editor.org/info/rfc7841>.

   [RFC7996]  Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
              RFC 7996, DOI 10.17487/RFC7996, December 2016,
              <http://www.rfc-editor.org/info/rfc7996>.

   [RFC7997]  Flanagan, H., Ed., "The Use of Non-ASCII Characters in
              RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
              <http://www.rfc-editor.org/info/rfc7997>.

   [RFC7998]  Hoffman, P. and J. Hildebrand, ""xml2rfc" Version 3
              Preparation Tool Description", RFC 7998,
              DOI 10.17487/RFC7998, December 2016,
              <http://www.rfc-editor.org/info/rfc7998>.

Top      Up      ToC       Page 91 
   [RNC]      Clark, J., "RELAX NG Compact Syntax", The Organization
              for the Advancement of Structured Information
              Standards (OASIS), November 2002,
              <https://www.oasis-open.org/committees/
              relax-ng/compact-20021121.html>.

   [RNG]      ISO/IEC, "Information Technology - Document Schema
              Definition Languages (DSDL) - Part 2: Regular-Grammar-
              Based Validation - RELAX NG (Second Edition)",
              ISO/IEC 19757-2:2008(E), December 2008.

              A useful source of RNG-related information is
              <http://relaxng.org/>.

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

   [UAX24]    The Unicode Consortium, "UAX #24: Unicode Script
              Property", <http://www.unicode.org/reports/tr24/>.

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

Top      Up      ToC       Page 92 
   [XInclude] Marsh, J., Orchard, D., and D. Veillard, "XML Inclusions
              (XInclude) Version 1.0 (Second Edition)", W3C
              Recommendation REC-xinclude-20061115, November 2006,
              <https://www.w3.org/TR/2006/REC-xinclude-20061115/>.

              Latest version available at
              <http://www.w3.org/TR/xinclude/>.

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

Top      Up      ToC       Page 93 
Appendix A.  Front-Page ("Boilerplate") Generation

   The values listed here will be defined by the RFC Series Editor.
   Those listed here are believed to be the current values in use.

A.1.  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.45.5).  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 "Copyright Notice" text, the submissionType attribute
   of the <rfc> element (Section 2.45.12) 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.1.1.  Current Values: "*trust200902"

   The name for these values refers to version 2.0 of the IETF Trust's
   "Legal Provisions Relating to IETF Documents", sometimes simply
   called the "TLP", which went into effect on February 15, 2009
   [TLP2.0].  Updates to the 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.

Top      Up      ToC       Page 94 
   The prep tool automatically produces 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.1.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.1.1.2.  noModificationTrust200902

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

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

      Note: this clause is incompatible with RFCs that are published on
      the Standards Track.

A.1.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.

Top      Up      ToC       Page 95 
A.1.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.1.2.  Historic Values

A.1.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.1.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 [RFC3978].

A.1.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 [RFC3667].

Top      Up      ToC       Page 96 
A.1.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.2.  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 Submissions stream" (used for things such as
   discussion of Internet-related technologies that are not part of the
   IETF agenda), the "IAB stream" (Internet Architecture Board), and the
   "IRTF stream" (Internet Research Task Force).

   The values for the attribute are "IETF" (the default value),
   "independent", "IAB", and "IRTF".

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

   o  For all RFCs and Internet-Drafts, it determines whether the
      "Copyright Notice" section mentions the Copyright on Code
      Components (see Section 6 of the TLP ("Text to Be Included in IETF
      Documents")).

Top      Up      ToC       Page 97 
A.3.  The "consensus" Attribute

   For some of the publication streams (see Appendix A.2), the "Status
   of This Memo" section depends on whether there was a consensus to
   publish (again, see Section 3.4 of [RFC7841]).

   The consensus attribute can be used to supply this information.  The
   acceptable values are "true" (the default) and "false"; "yes" and
   "no" from v2 are deprecated.

   The effect of this value for the various streams is:

   o  "independent": none.

   o  "IAB": mention that there was an IAB consensus.

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

Top      Up      ToC       Page 98 
Appendix B.  The v3 Format and Processing Tools

   This section describes topics that are specific to v3 processing
   tools.  Note that there is some discussion of tools in the main body
   of the document as well.  For example, some elements have
   descriptions of how a processing tool might create output from the
   element.

   The expected design of the tools that will be used with v3 documents
   includes:

   o  A "prep tool" that takes a v3 document, makes many checks, adds
      and changes many attribute values, and creates a file that is a
      "prepared document".  The prepared document is a valid v3
      document.  The prep tool is described in [RFC7998].

      The prep tool is expected to have many modes:

      *  RFC mode -- The mode used by the RFC Editor to process the
         input from one of the RFC streams and to process XML produced
         during the RFC editing process.  The restrictions on the
         canonical XML for RFCs, as well as how the non-canonical
         formats will look, are described at
         <https://www.rfc-editor.org/rse/wiki/
         doku.php?id=design:format-and-content-rfcs>.

      *  Draft mode -- The mode used by the Internet-Draft submission
         tool.  The restrictions for the XML from this mode will be
         described later.

      *  Diagnostic mode -- A mode that can be used by document authors
         to look for errors or warnings before they submit their
         documents for publication.

      *  Consolidation mode -- Produces output where no external
         resources are required to render the file output.  This
         includes expanding the XInclude entities and DTD entities in
         place, and changing all elements that have "src" attributes
         with external links into either "data:" URI or content for the
         element, as specified in [RFC7998].

   o  Formatting tools that will create HTML, PDF, plain text, and
      possibly other output formats.  These formatters will be created
      by the IETF, but others can create such tools as well.  The IETF
      tools are expected to take prepared documents as input.

Top      Up      ToC       Page 99 
   There may also be processing tools that are meant to run on the
   computers of authors.  These tools may be used to produce interim
   versions of the non-canonical representations so that authors can see
   how their XML might later be rendered, to create documents in
   representations different than those supported by the RFC Editor, to
   possibly create documents that are not meant to be Internet-Drafts or
   RFCs, and to convert XML that has external information into XML that
   has that external information included.

   The prep tool is expected to have clear error reporting, giving more
   context than just a line number.  For example, the error messages
   should differentiate between errors in XML and those from the v3
   format.

   In v2, the grammar was specified as a DTD.  In v3, the grammar is
   specified only as RELAX Next Generation (RNG).  This means that tools
   need to work from the RNG, not from a DTD.  Some of the features of
   the v3 grammar cannot be specified as a DTD.

B.1.  Including External Text with XInclude

   All tools for the v3 format are expected to support XInclude
   [XInclude].  XInclude specifies a processing model and syntax for
   general-purpose inclusion of information that is either on the
   Internet or local to the user's computer.

   In the v3 syntax, XInclude is expressed as the <xi:include> element.
   To use this element, you need to include the "xi" namespace in the
   <rfc> element; that is, you need to specify

   xmlns:xi="http://www.w3.org/2001/XInclude"

   as one of the attributes in the <rfc> element.

   The most common way to use <xi:include> is to pull in references that
   are already formed as XML.  Currently, this can be done from
   xml2rfc.tools.ietf.org, but later this is expected to be from the RFC
   Editor.  For example, if a document has three normative references,
   all RFCs, the document might contain:

   <references>
       <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
          bibxml/reference.RFC.2119.xml"/>
       <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
          bibxml/reference.RFC.4869.xml"/>
       <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
          bibxml/reference.RFC.7169.xml"/>
   </references>

Top      Up      ToC       Page 100 
   <xi:include> can be used anywhere an XML element could be used (but
   not where free text is used).  For example, if three Internet-Drafts
   are all including a particular paragraph or section verbatim, that
   text can be kept either in a file or somewhere on the web and can be
   included with <xi:include>.  An example of pulling something from the
   local disk would be:

   <x:include href="file://home/chris/ietf/drafts/commontext.xml"/>

   In general, XInclude should be used instead of ENTITY references and
   XML Processing Instructions (PIs) that allow external inclusions.

B.2.  Anchors and IDs

   People writing and reading Internet-Drafts and RFCs often want to
   make reference to specific locations in those documents.  In the case
   of RFC authors, it is common to want to reference another part of
   their document, such as "see Section 3.2 of this document."  Readers,
   on the other hand, want to reference parts of documents that they
   didn't write, such as "see Section 3.2 of RFC 6949."  The XML
   vocabulary in this document attempts to support both sets of people.

   Authors can leave anchors in a document that can later be used for
   references with the "anchor" attribute.  Anchors can be included in
   the numerous elements.  The author can then refer to that anchor in
   the "target" attribute of the <xref> element.

   Readers can refer to any element that has an "anchor" attribute by
   that attribute.  Note, however, that most of the time, elements won't
   have anchors.  In the common case, the reader wants to refer to an
   element that does not have an "anchor" attribute, but that element
   has a "pn" attribute.

   Processing tools add the "pn" attribute to many elements during
   processing.  This attribute and its value are automatically generated
   by the tool if the attribute is not there; if the attribute is
   already there, the tool may replace the value.

B.2.1.  Overlapping Values

   In the HTML representation of this XML vocabulary, both anchors and
   "pn" attributes will be used in the "id" attributes of elements.
   Thus, there can be no overlap between the names entered in "anchor"
   attributes, in "slugifiedName" attributes, and those that are
   generated for the "pn" attributes.  Also, there are some values for
   the "anchor" values that are reserved for sections, and those
   sections can only have those anchor values.

Top      Up      ToC       Page 101 
   The following rules prevent this overlap:

   o  "pn" for regular sections always has the format "s-nnn", where
      "nnn" is the section number, or the appendix identifier (which
      starts with a letter).  For example, this would be "s-2.1.3" for
      Section 2.1.3 and "s-a" for Appendix A.  For the <abstract>
      element, it is always "s-abstract".  For the <note> element, it is
      always "s-note-nnn", where "nnn" is a sequential value.  For
      sections in the <boilerplate> element, it is always
      "s-boilerplate-nnn", where "nnn" is a sequential value.

   o  "pn" for <references> elements has the format "s-nnn".  It is
      important to note that "nnn" is a number, not letters, even though
      the <references> appear in the back.  It is the number that is one
      higher than the highest top-level section number in <middle>.  If
      there are two or more <references>, "nnn" will include a dot as if
      the <references> are a subsection of a section that is numbered
      one higher than the highest top-level section number in <middle>.

   o  "pn" for <figure> elements always has the format "f-nnn", where
      "nnn" is the figure number.  For example, this would be "f-5" for
      Figure 5.

   o  "pn" for <iref> elements always has the format "i-ttt-nnn", where
      "ttt" is the slugified item (plus a hyphen and the slugified
      subitem if there is a subitem), and "nnn" is the instance of that
      item/subitem pair.  For example, this would be "i-foo-1" for
      "<iref item='foo'>" and "i-foo-bar-1" for "<iref item='foo'
      subitem='bar'>".

   o  "pn" for <table> elements always has the format "t-nnn", where
      "nnn" is the table number.  For example, this would be "t-5" for
      Table 5.

   o  "pn" for all elements not listed above always has the format
      "p-nnn-mmm", where "nnn" is the section number and "mmm" is the
      relative position in the section.  For example, this would be
      "p-2.1.3-7" for the seventh part number in Section 2.1.3.

Top      Up      ToC       Page 102 
   o  "slugifiedName" always has the format "n-ttt", where "ttt" is the
      text of the name after slugification.  For example, this would be
      "n-protocol-overview" for the name "Protocol Overview".  The
      actual conversions done in slugification will be specified at a
      later time.

   o  Anchors must never overlap with any of the above.  The easiest way
      to assure that is to not pick an anchor name that starts with a
      single letter followed by a hyphen.  If an anchor does overlap
      with one of the types of names above, the processing tool will
      reject the document.

B.3.  Attributes Controlled by the Prep Tool

   Many elements in the v3 vocabulary have new attributes whose role is
   to hold values generated by the prep tool.  These attributes can
   exist in documents that are input to the prep tool; however, any of
   these attributes might be added, removed, or changed by the prep
   tool.  Thus, it is explicitly unsafe for a document author to include
   these attributes and expect that their values will survive processing
   by the prep tool.

   The attributes that are controlled by the prep tool are:

   o  The "pn" attribute in any element -- The number for this item
      within the section.  The numbering is shared with other elements
      of a section.  The "pn" attribute is added to many block-level
      elements inside sections.

   o  <artwork> originalSrc -- This attribute is filled with the
      original value of the "src" attribute if that attribute is removed
      by the prep tool.

   o  <figure> originalSrc -- This attribute is filled with the original
      value of the "src" attribute if that attribute is removed by the
      prep tool.

   o  <name> "slugifiedName" attribute -- This attribute is filled with
      a "slugified" version of the text in the element.  This attribute
      can be used in the output formats for elements that have both
      names and numbers.

   o  <relref> "derivedLink" attribute -- This attribute is filled with
      the link that is derived from combining the URI from the reference
      and the relative part that is either a copy of the "relative"
      attribute or a section number derived from the "section"
      attribute.

Top      Up      ToC       Page 103 
   o  <rfc> "expiresDate" attribute -- This attribute is filled with the
      date that an Internet-Draft expires.  The date is in the format
      yyyy-mm-dd.

   o  <rfc> "mode" attribute -- This attribute is filled with a string
      that indicates what mode the prep tool was in when it processed
      the XML, such as whether it was processing a file to become an
      Internet-Draft or an RFC.

   o  <rfc> "scripts" attribute -- This attribute is filled with a list
      of scripts needed to render this document.  The list is comma-
      separated, with no spaces allowed.  The order is unimportant.  The
      names come from [UAX24].  For example, if the document has Chinese
      characters in it, the value might be "Common,Latin,Han".

   o  <sourcecode> "originalSrc" attribute -- This attribute is filled
      with the original value of the "src" attribute if that attribute
      is removed by the prep tool.

   o  <xref> "derivedContent" attribute -- This attribute is filled in
      if there is no content in the <xref> element.  The value for this
      attribute is based on the value in the "displayFormat" attribute.
      Examples of how this value is filled can be found in
      Section 2.66.1.

   In addition, note that the contents of the <boilerplate> element are
   controlled by the prep tool.


Next Section