@@ -71,7 +71,7 @@
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 March 30, 2025.¶
+ This Internet-Draft will expire on April 25, 2025.
¶
diff --git a/tests/valid/manpage.txt b/tests/valid/manpage.txt
index 94b35e4c..64b920af 100644
--- a/tests/valid/manpage.txt
+++ b/tests/valid/manpage.txt
@@ -1,10 +1,10 @@
xml2rfc(1) xml2rfc(1)
- 26 September 2024
+ 22 October 2024
Xml2rfc Vocabulary Version 3 Schema
- xml2rfc release 3.23.1
- xml2rfc-docs-3.23.1
+ xml2rfc release 3.23.2
+ xml2rfc-docs-3.23.2
Abstract
@@ -54,7 +54,7 @@ Table of Contents
The latest version of this documentation is available in HTML form at
https://ietf-tools.github.io/xml2rfc/.
- This documentation applies to xml2rfc version 3.23.1.
+ This documentation applies to xml2rfc version 3.23.2.
2. Schema Version 3 Elements
@@ -4336,7 +4336,7 @@ Appendix C. xml2rfc Configuration Files
Appendix D. xml2rfc Documentation Template Variables
The following variables are available for use in an xml2rfc manpage
- Jinja2 template, as of xml2rfc version 3.23.1:
+ Jinja2 template, as of xml2rfc version 3.23.2:
{{ bare_latin_tags }}:
diff --git a/tests/valid/rfc7911.html b/tests/valid/rfc7911.html
index d35a770c..51eeda22 100644
--- a/tests/valid/rfc7911.html
+++ b/tests/valid/rfc7911.html
@@ -16,22 +16,22 @@
that each path is identified by a Path Identifier in addition to the
address prefix.
" name="description">
-
+
diff --git a/tests/valid/rfc7911.v3add-xinclude.xml b/tests/valid/rfc7911.v3add-xinclude.xml
index b9354f60..1893c19f 100644
--- a/tests/valid/rfc7911.v3add-xinclude.xml
+++ b/tests/valid/rfc7911.v3add-xinclude.xml
@@ -875,16 +875,14 @@ draft-gieben-writing-rfcs-pandoc-00.txt -> draft.txt
-
-Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification
-
-International Organization for Standardization
-
-
-
-
-
-
+
+ Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification
+
+ International Organization for Standardization
+
+
+
+
@@ -897,16 +895,16 @@ draft-gieben-writing-rfcs-pandoc-00.txt -> draft.txt
-
-Source Routing Tutorial for End System Operation
-
-Institute of Electrical and Electronics Engineers
-
-
-
-
-
-
+
+ Source Routing Tutorial for End System Operation
+
+ Institute of Electrical and Electronics Engineers
+
+
+
+
+
+
diff --git a/tests/valid/rfc99999.exp.xml b/tests/valid/rfc99999.exp.xml
new file mode 100644
index 00000000..d66c36e7
--- /dev/null
+++ b/tests/valid/rfc99999.exp.xml
@@ -0,0 +1,47 @@
+
+
+
+
+ Fake RFC
+
+
+
+
+ NZ
+
+ example@example.org
+
+
+
+ General
+
+ This is not a real RFC.
+
+
+
+
+ Section 31
+ redacted
+
+
+
+
+ References
+
+ Normative References
+
+
+ Prime Directive
+
+
+
+ Fake reference
+
+
+
+
+
+
+
+
+
diff --git a/tests/valid/rfc99999.html b/tests/valid/rfc99999.html
new file mode 100644
index 00000000..af8cff57
--- /dev/null
+++ b/tests/valid/rfc99999.html
@@ -0,0 +1,1363 @@
+
+
+
+
+
+
+
RFC 99999: Fake RFC
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RFC 99999 |
+Fake RFC |
+October 2024 |
+
+
+Doe |
+Best Current Practice |
+[Page] |
+
+
+
+
+
RFC 99999
+
Fake RFC
+
+
+This is not a real RFC.¶
+
+
+
+
+
+ This memo documents an Internet Best Current Practice.¶
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further information
+ on BCPs is available in Section 2 of RFC 7841.¶
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc99999.¶
+
+
+
+
+
+
+ Copyright (c) 2024 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
+ (https://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 Revised BSD License text as described in
+ Section 4.e of the Trust Legal Provisions and are provided without
+ warranty as described in the Revised BSD License.¶
+
+
+
+
+
+
+
+
+
+ Jane Doe
+New Zealand
+
+
+
+
+
+
+
diff --git a/tests/valid/rfc99999.pages.text b/tests/valid/rfc99999.pages.text
new file mode 100644
index 00000000..14a0ac08
--- /dev/null
+++ b/tests/valid/rfc99999.pages.text
@@ -0,0 +1,69 @@
+
+
+
+
+Internet Engineering Task Force (IETF) J. Doe
+Request for Comments: 99999 October 2024
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Fake RFC
+
+Abstract
+
+ This is not a real RFC.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc99999.
+
+Copyright Notice
+
+ Copyright (c) 2024 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
+ (https://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 Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Section 31
+ 2. References
+ 2.1. Normative References
+ Author's Address
+
+1. Section 31
+
+ redacted [RFC99998]
+
+2. References
+
+2.1. Normative References
+
+ [RFC99998] Doe, J., "Prime Directive", RFC 99998,
+ DOI 10.17487/RFC99998, October 2024,
+
.
+
+Author's Address
+
+ Jane Doe
+ New Zealand
+ Email: example@example.org
diff --git a/tests/valid/rfc99999.prepped.xml b/tests/valid/rfc99999.prepped.xml
new file mode 100644
index 00000000..4e014172
--- /dev/null
+++ b/tests/valid/rfc99999.prepped.xml
@@ -0,0 +1,119 @@
+
+
+
+
+
+
+ Fake RFC
+
+
+
+
+ NZ
+
+ example@example.org
+
+
+
+ General
+
+ This is not a real RFC.
+
+
+
+ Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further information
+ on BCPs is available in Section 2 of RFC 7841.
+
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ .
+
+
+
+ Copyright Notice
+
+ Copyright (c) 2024 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
+ () 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 Revised BSD License text as described in
+ Section 4.e of the Trust Legal Provisions and are provided without
+ warranty as described in the Revised BSD License.
+
+
+
+
+
+ Table of Contents
+
+ -
+ . Section 31
+
+ -
+ . References
+
+ -
+ . Normative References
+
+
+
+ -
+ Author's Address
+
+
+
+
+
+
+
+ Section 31
+ redacted
+
+
+
+
+ References
+
+ Normative References
+
+
+ Prime Directive
+
+
+
+ Fake reference
+
+
+
+
+
+
+
+
+ Author's Address
+
+
+
+ NZ
+
+ example@example.org
+
+
+
+
+
diff --git a/tests/valid/rfc99999.text b/tests/valid/rfc99999.text
new file mode 100644
index 00000000..14a0ac08
--- /dev/null
+++ b/tests/valid/rfc99999.text
@@ -0,0 +1,69 @@
+
+
+
+
+Internet Engineering Task Force (IETF) J. Doe
+Request for Comments: 99999 October 2024
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Fake RFC
+
+Abstract
+
+ This is not a real RFC.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc99999.
+
+Copyright Notice
+
+ Copyright (c) 2024 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
+ (https://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 Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Section 31
+ 2. References
+ 2.1. Normative References
+ Author's Address
+
+1. Section 31
+
+ redacted [RFC99998]
+
+2. References
+
+2.1. Normative References
+
+ [RFC99998] Doe, J., "Prime Directive", RFC 99998,
+ DOI 10.17487/RFC99998, October 2024,
+ .
+
+Author's Address
+
+ Jane Doe
+ New Zealand
+ Email: example@example.org
diff --git a/tests/valid/rfc99999.txt b/tests/valid/rfc99999.txt
new file mode 100644
index 00000000..14a0ac08
--- /dev/null
+++ b/tests/valid/rfc99999.txt
@@ -0,0 +1,69 @@
+
+
+
+
+Internet Engineering Task Force (IETF) J. Doe
+Request for Comments: 99999 October 2024
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Fake RFC
+
+Abstract
+
+ This is not a real RFC.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc99999.
+
+Copyright Notice
+
+ Copyright (c) 2024 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
+ (https://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 Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Section 31
+ 2. References
+ 2.1. Normative References
+ Author's Address
+
+1. Section 31
+
+ redacted [RFC99998]
+
+2. References
+
+2.1. Normative References
+
+ [RFC99998] Doe, J., "Prime Directive", RFC 99998,
+ DOI 10.17487/RFC99998, October 2024,
+ .
+
+Author's Address
+
+ Jane Doe
+ New Zealand
+ Email: example@example.org
diff --git a/tests/valid/rfc99999.v2v3.xml b/tests/valid/rfc99999.v2v3.xml
new file mode 100644
index 00000000..35cc2567
--- /dev/null
+++ b/tests/valid/rfc99999.v2v3.xml
@@ -0,0 +1,41 @@
+
+
+
+
+
+]>
+
+
+ Fake RFC
+
+
+
+
+ NZ
+
+ example@example.org
+
+
+
+ General
+
+ This is not a real RFC.
+
+
+
+
+ Section 31
+ redacted
+
+
+
+
+ References
+
+ Normative References
+
+
+
+
+
diff --git a/tests/valid/rfc99999.v3.html b/tests/valid/rfc99999.v3.html
new file mode 100644
index 00000000..58440cc3
--- /dev/null
+++ b/tests/valid/rfc99999.v3.html
@@ -0,0 +1,174 @@
+
+
+
+
+
+
+RFC 99999: Fake RFC
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RFC 99999 |
+Fake RFC |
+October 2024 |
+
+
+Doe |
+Best Current Practice |
+[Page] |
+
+
+
+
+RFC 99999
+Fake RFC
+
+
+This is not a real RFC.¶
+
+
+
+
+
+ This memo documents an Internet Best Current Practice.¶
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further information
+ on BCPs is available in Section 2 of RFC 7841.¶
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc99999.¶
+
+
+
+
+
+
+ Copyright (c) 2024 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
+ (https://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 Revised BSD License text as described in
+ Section 4.e of the Trust Legal Provisions and are provided without
+ warranty as described in the Revised BSD License.¶
+
+
+
+
+
+
+
+
+
+ Jane Doe
+New Zealand
+
+
+
+
+
+
+
diff --git a/tests/valid/rfc99999.v3add-xinclude-w-revision.xml b/tests/valid/rfc99999.v3add-xinclude-w-revision.xml
new file mode 100644
index 00000000..8eb3274f
--- /dev/null
+++ b/tests/valid/rfc99999.v3add-xinclude-w-revision.xml
@@ -0,0 +1,750 @@
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Put Your Internet Draft Title
+ Here
+
+
+
+
+
+ Folly Consulting
+
+
+
+
+
+ Soham
+
+
+ UK
+
+ +44 7889 488 335
+ elwynd@dial.pipex.com
+
+
+
+
+
+ Huawei Technology
+
+
+ 125 Nagog Technology Park
+ Acton
+ MA
+ 01719
+ US
+
+ quintin.zhao@huawei.com
+
+
+
+
+
+
+
+ General
+ Internet Engineering Task Force
+
+
+ template
+
+
+
+ Insert an abstract: MANDATORY. This template is for creating an
+ Internet Draft.
+
+
+
+
+ Introduction
+ The original specification of xml2rfc format is in RFC 2629.
+
+ Requirements Language
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119.
+
+
+
+ Simple List
+ List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging',
+ 'format'.
+
+ -
+ First bullet
+
+ -
+ Second bullet
+
+
+ You can write text here as well.
+
+
+ Figures
+ Figures should not exceed 69 characters wide to allow for the indent
+ of sections.
+ Preamble text - can be omitted or empty.
+
+ Cross-references allowed in pre- and postamble. .
+ The CDATA means you don't need to escape meta-characters (especially
+ < (<) and & (&)) but is not essential.
+ Figures may also have a title attribute but it won't be displayed unless
+ there is also an anchor. White space, both horizontal and vertical, is
+ significant in figures even if you don't use CDATA.
+
+
+
+
+ Subsections and Tables
+
+ A Subsection
+ By default 3 levels of nesting show in table of contents but that
+ can be adjusted with the value of the "tocdepth" processing
+ instruction.
+
+
+ Tables
+ .. are very similar to figures:
+ Tables use ttcol to define column headers and widths.
+ Every cell then has a "c" element for its content.
+
+ A Very Simple Table
+
+
+ ttcol #1 |
+ ttcol #2 |
+
+
+
+
+ c #1 |
+ c #2 |
+
+
+ c #3 |
+ c #4 |
+
+
+ c #5 |
+ c #6 |
+
+
+
+ which is a very simple example.
+
+
+
+ More about Lists
+ Lists with 'hanging labels': the list item is indented the amount of
+ the hangIndent:
+
+ - short
+ - With a label shorter than the hangIndent.
+ - fantastically long label
+ - With a label longer than the
+ hangIndent.
+ - vspace_trick
+ - Forces the new
+ item to start on a new line.
+
+
+
+ Simulating more than one paragraph in a list item using
+ <vspace>:
+ -
+ First, a short item.
+
+ -
+ Second, a longer list item.
+ And
+ something that looks like a separate pararaph..
+
+
+ Simple indented paragraph using the "empty" style:
+
+ -
+ The quick, brown fox jumped over the lazy dog and lived to fool
+ many another hunter in the great wood in the west.
+
+
+
+ Numbering Lists across Lists and Sections
+ Numbering items continuously although they are in separate
+ <list> elements, maybe in separate sections using the "format"
+ style and a "counter" variable.
+ First list:
+ -
+ #1
+
+ -
+ #2
+
+ -
+ #3
+
+
+ Specify the indent explicitly so that all the items line up
+ nicely.
+ Second list:
+ -
+ #4
+
+ -
+ #5
+
+ -
+ #6
+
+
+
+
+ Where the List Numbering Continues
+ List continues here.
+ Third list:
+ -
+ #7
+
+ -
+ #8
+
+ -
+ #9
+
+ -
+ #10
+
+
+ The end of the list.
+
+
+ nested lists
+ Simulating more than one paragraph in a list item using
+ <vspace>:
+
+ -
+ First, a short item.
+
+ -
+ Second, a longer list item.
+ And
+ something that looks like a separate paragraph.
+
+ -
+ and a sublist, also with letters
+
+
-
+ first subitem
+
+ -
+ second subitem
+
+ -
+ and a sub-sublist, also with letters
+
+
-
+ first sub-subitem
+
+ -
+ second sub-subitem
+
+
+
+
+
+
+
+
+ List Formats
+ many formats
+
+ -
+ first %c-item
+
+ -
+ more %c-items
+
+
+ -
+ first %C-item
+
+ -
+ more %C-items
+
+
+ -
+ first %d-item.
+
+ -
+ more %d-items.
+
+
+ -
+ first %i-item
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+ -
+ more %i-items
+
+
+ -
+ first %I-item
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+ -
+ more %I-items
+
+
+ -
+ first %o-item
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+ -
+ more %o-items
+
+
+ -
+ first %x-item
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+ -
+ more %x-items
+
+
+ -
+ first %X-item
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+ -
+ more %X-items
+
+
+
+
+
+ Example of Code or MIB Module To Be Extracted
+ The <artwork> element has a number of extra attributes
+ that can be used to substitute a more aesthetically pleasing rendition
+ into HTML output while continuing to use the ASCII art version in the
+ text and nroff outputs (see the xml2rfc README for details). It also
+ has a "type" attribute. This is currently ignored except in the case
+ 'type="abnf"'. In this case the "artwork" is expected to contain a
+ piece of valid Augmented Backus-Naur Format (ABNF) grammar. This will
+ be syntax checked by xml2rfc and any errors will cause a fatal error
+ if the "strict" processing instruction is set to "yes". The ABNF will
+ also be colorized in HTML output to highlight the syntactic
+ components. Checking of additional "types" may be provided in future
+ versions of xml2rfc.
+
+
+void
+main(int argc, char *argv[])
+{
+ int i;
+
+ printf("program arguments are:\n");
+ for (i = 0; i < argc; i++) {
+ printf("%d: \"%s\"\n", i, argv[i]);
+ }
+
+ exit(0);
+} /* main */
+
+/* end of file */
+
+]]>
+
+
+ Acknowledgements
+ This template was derived from an initial version written by Pekka
+ Savola and contributed by him to the xml2rfc project.
+
+ This document is part of a plan to make xml2rfc indispensable .
+ This document may be shared as needed . If necessary, appeal to .
+
+
+
+
+
+ IANA Considerations
+ This memo includes no request to IANA.
+ All drafts are required to have an IANA considerations section (see
+ the update of
+ RFC 2434 for a guide). If the draft does not require IANA to do
+ anything, the section contains an explicit statement that this is the
+ case (as above). If there are no requirements for IANA, the section will
+ be removed during conversion into an RFC by the RFC Editor.
+
+
+ Security Considerations
+ All drafts are required to have a security considerations section.
+ See RFC 3552 for a guide.
+
+
+
+
+
+
+
+
+
+
+ References
+
+ Normative References
+
+
+
+
+
+
+ Minimal Reference
+
+
+
+
+
+
+
+
+ Informative References
+
+
+
+
+
+
+
+
+ Jupiter rising
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Google, Inc.
+
+
+ Association for Computing Machinery (ACM)
+
+
+
+ We present our approach for overcoming the cost, operational complexity, and limited scale endemic to datacenter networks a decade ago. Three themes unify the five generations of datacenter networks detailed in this paper. First, multi-stage Clos topologies built from commodity switch silicon can support cost-effective deployment of building-scale networks. Second, much of the general, but complex, decentralized network routing and management protocols supporting arbitrary deployment scenarios were overkill for single-operator, pre-planned datacenter networks. We built a centralized control mechanism based on a global configuration pushed to all datacenter switches. Third, modular hardware design coupled with simple, robust software allowed our design to also support inter-cluster and wide-area networks. Our datacenter networks run at dozens of sites across the planet, scaling in capacity by 100x over 10 years to more than 1 Pbps of bisection bandwidth. A more detailed version of this paper is available at Ref.
+
+
+ Communications of the ACM, vol. 59, no. 9, pp. 88-97
+
+
+
+
+
+
+ Ultimate Plan for Taking Over the World
+
+ Mad Dominators, Inc.
+
+
+
+
+
+
+
+ I Learned to Share in Kindergarten
+
+
+
+ Sesame Street
+
+
+
+
+
+
+
+
+
+
+ Additional Stuff
+ This becomes an Appendix.
+
+
+ Contributors
+ This becomes an unnumbered section
+
+
+
diff --git a/tests/valid/rfc99999.v3add-xinclude.xml b/tests/valid/rfc99999.v3add-xinclude.xml
new file mode 100644
index 00000000..1893c19f
--- /dev/null
+++ b/tests/valid/rfc99999.v3add-xinclude.xml
@@ -0,0 +1,1414 @@
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+ Writing I-Ds and RFCs using Pandoc and xml2rfc 2.x
+
+
+ Google
+
+
+ 123 Buckingham Palace Road
+
+ London
+
+ SW1W 9SH
+ UK
+
+
+ miek@miek.nl
+ http://miek.nl/
+
+
+
+ General
+ RFC Beautification Working Group
+ RFC
+ Request for Comments
+ I-D
+ Internet-Draft
+ XML
+ Pandoc
+ Extensible Markup Language
+
+
+ This memo presents a technique for using Pandoc syntax as a source
+ format for documents in the Internet-Drafts (I-Ds) and Request for
+ Comments (RFC) series.
+
+
+ This version is adapted to work with "xml2rfc" version 2.x.
+
+
+
+
+
+
+ Introduction
+
+ This document presents a technique for using Pandoc syntax as a
+ source format for documents in the Internet-Drafts (I-Ds) and
+ Request for Comments (RFC) series.
+
+
+ This version is adapted to work with
+ xml2rfc version 2.x.
+
+
+ Pandoc is an "almost plain text" format and therefor particularly
+ well suited for editing RFC-like documents.
+
+
+ -
+ Note: this document is typeset in Pandoc and does not render
+ completely correct when reading it on github.
+
+
+
+
+ Pandoc to RFC
+
+ -
+ Pandoc2rfc -- designed to do the right thing, until it doesn't.
+
+
+
+ When writing
+ we directly wrote the XML. Needless to say it was tedious even thought
+ the XML of xml2rfc
+ is very "light". The
+ latest version of xml2rfc version 2 can be found here.
+
+
+ During the last few years people have been developing markup
+ languages that are very easy to remember and type. These languages
+ have become known as
+ almost plain
+ text-markup languages. One of the first was the
+ Markdown
+ syntax. One that was developed later and incorporates Markdown and
+ a number of extensions is
+ Pandoc. The
+ power of Pandoc also comes from the fact that it can be translated
+ to numerous output formats, including, but not limited to: HTML,
+ (plain) Markdown and
+ docbook XML.
+
+
+ So using Pandoc for writing RFCs seems like a sane choice. As
+ xml2rfc uses XML,
+ the easiest way would be to create
+ docbook
+ XML and transform that using XSLT. Pandoc2rfc does just that. The
+ conversions are, in some way amusing, as we start off with
+ (almost) plain text, use elaborate XML and end up with plain text
+ again.
+
+
+
+ The XML generated (the output after the
+ xsltproc step in
+ )
+ is suitable for inclusion in either the
+ middle or
+ back section of
+ an RFC. The simplest way is to create a template XML file and
+ include the appropriate XML:
+
+
+
+ See the Makefile for an example of this. In this case you need to
+ edit 3 documents:
+
+ -
+ middle.pdc - contains the main body of text;
+
+ -
+ back.pdc - holds appendices and references;
+
+ -
+ template.xml (probably a fairly static file).
+
+
+
+ The draft
+ (draft.txt) you
+ are reading now, is automatically created when you call
+ make. The
+ homepage of Pandoc2rfc is
+ this github
+ repository.
+
+
+ Dependencies
+
+ It needs xsltproc
+ and pandoc to be
+ installed. See the
+ Pandoc
+ user manual for the details on how to type in Pandoc style.
+ And of course xml2rfc
+ version two.
+
+
+ When using Pandoc2rfc consider adding the following sentence to
+ an Acknowledgements section:
+
+
+
+
+
+ Starting a new project
+
+ When starting a new project with
+ pandoc2rfc you'll
+ need to copy the following files:
+
+
+ -
+ Makefile
+
+ -
+ transform.xslt
+
+ -
+
+ And the above mentioned files:
+
+ -
+ middle.pdc
+
+ -
+ back.pdc
+
+ -
+ template.xml
+
+
+
+
+
+ After that you can start editing.
+
+
+
+ Supported Features
+
+ -
+ Sections with an anchor and title attributes
+ ();
+
+ -
+
+ Lists
+
+ -
+ style=symbols ();
+
+ -
+ style=numbers ();
+
+ -
+ style=empty ();
+
+ -
+ style=format %i, use roman lowercase numerals, ();
+
+ -
+ style=format (%d), use roman uppercase numerals ();
+
+ -
+ style=letters (lower- and uppercase, );
+
+ -
+ style=hanging ();
+
+
+
+ -
+ Figure/artwork with a title ();
+
+ -
+ Block quote this is converted to
+ <list style="empty">
+ paragraph ();
+
+ -
+
+ References
+
+ -
+ external (eref) ();
+
+ -
+
+ internal (xref) (), you can refer to:
+
+ -
+ section (handled by Pandoc, see ));
+
+ -
+ figures (handled by XSLT, see );
+
+ -
+ tables (handled by XSLT, see ).
+
+
+
+
+
+ -
+ Citations, by using internal references;
+
+ -
+ Spanx style=verb, style=emph and style=strong ();
+
+ -
+ Tables with an anchor and title ();
+
+ -
+ Indexes, by using footnotes ().
+
+
+
+
+ Unsupported Features
+
+ -
+ Lists inside a table (xml2rfc doesn't handle this);
+
+ -
+ Pandoc markup in the caption for figures/artwork. Pandoc markup for table captions is supported;
+
+ -
+ crefs: for comments (no input syntax available), use HTML comments: <!-- ... -->;
+
+
+
+
+ Acknowledgements
+
+ The following people have helped to make Pandoc2rfc what it is today: Benno Overeinder, Erlend Hamnaberg, Matthijs Mekking, Trygve Laugstoel.
+
+
+ This document was prepared using Pandoc2rfc.
+
+
+
+ Pandoc Constructs
+
+ So, what syntax do you need to use to get the correct output? Well, it is
+ just Pandoc. The best introduction
+ to the Pandoc style is given in this
+ README from Pandoc itself.
+
+
+ For convenience we list the most important ones in the following sections.
+
+
+ Paragraph
+
+ Paragraphs are separated with an empty line.
+
+
+
+ Section
+
+ Just use the normal sectioning commands available in Pandoc, for instance:
+
+
+
+ Converts to: <section title="Section1
+ One" anchor="section1-one"> If you have another section that is also
+ named "Section1 One", that anchor will be called "section1-one-1", but
+ only when the sections are in
+ the same source file!
+
+
+ Referencing the section is done with see
+ [](#section1-one), as in see .
+
+
+
+ List Styles
+
+ A good number of styles are supported.
+
+
+ Symbol
+
+
+ Converts to <list style="symbol">:
+
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+
+ Number
+
+
+ Converts to <list style="numbers">:
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+
+ Empty
+
+ Using the default list markers from Pandoc:
+
+
+
+ Converts to <list style="empty">:
+
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+
+ Roman
+
+ Use the supported Pandoc syntax:
+
+
+
+ Converts to <list style="format %i.">:
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+ If you use uppercase Roman numerals, they convert to a different style:
+
+
+
+ Yields <list style="format (%d) ">:
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+
+ Letter
+
+ A numbered list.
+
+
+
+ Converts to <list style="letters">:
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+ Uppercasing the letters works too (note two spaces after the letter.
+
+
+
+ Becomes:
+
+ -
+ Item one;
+
+ -
+ Item two.
+
+
+
+
+ Hanging
+
+ This is more like a description list, so we need to use:
+
+
+
+ Converts to: <list style="hanging"> and <t hangText="First item that...">
+
+
+ If you want a newline after the hangTexts, search for the string OPTION in transform.xsl and uncomment it.
+
+
+
+
+ Figure/Artwork
+
+ Indent the paragraph with 4 spaces.
+
+
+
+ Converts to:
+ <figure><artwork> ...
+ Note that xml2rfc
+ supports a caption with
+ <artwork>. Pandoc does not
+ support this, but Pandoc2rfc does. If you add a
+ @Figure: some text as the last
+ line, the artwork gets a title
+ attribute with the text after
+ @Figure:. It will also be
+ possible to reference the artwork. If a caption is supplied the artwork will be
+ centered. If a caption is needed but the figure should not be centered use
+ @figure:\.
+
+
+ References
+
+ The reference anchor attribute will be: fig:
+ + first 10 (normalized) characters from the caption.
+ Where normalized means:
+
+
+ -
+ Take the first 10 characters of the caption (i.e. this is the text
+ after the string
+ @Figure:);
+
+ -
+ Spaces and single quotes (') are translated to a minus
+ -;
+
+ -
+ Uppercase letters translated to lowercase.
+
+
+
+ So the first artwork with a caption will get
+ fig:a-minimal-
+ as a reference. See for instance
+ .
+
+
+ This anchoring is completely handled from within the
+ xslt.
+ Note that duplicate anchors are an XML validation error which will make
+ xml2rfc fail.
+
+
+
+
+ Block Quote
+
+ Any paragraph like:
+
+ quoted text
+ ]]>
+
+ Converts to: <t><list style="empty"> ...
+ paragraph, making it indented.
+
+
+
+ References
+
+ External
+
+ Any reference like:
+
+
+
+ Converts to: <ulink target="URI">Click here ...
+
+
+
+ Internal
+
+ Any reference like:
+
+
+
+ Converts to: <link target="localid">Click here ...
+
+
+ For referring to RFCs (for which you manually need add the reference source in
+ the template, with an external XML entity), you can just use:
+
+
+
+ And it does the right thing. Referencing sections is done with:
+
+
+
+ The word 'Section' is inserted automatically: ... see
+
+ ... For referencing figures/artworks see
+ .
+ For referencing tables see .
+
+
+
+
+ Spanx Styles
+
+ The verb style can be selected with back-tics:
+ `text`
+ Converts to:
+ <spanx style="verb"> ...
+
+
+ And the emphasis style with asterisks:
+ *text*
+ or underscores: _text_
+ Converts to: <spanx style="emph"> ...
+
+
+ And the emphasis style with double asterisks:
+ **text**
+ Converts to: <spanx style="strong"> ...
+
+
+
+ Tables
+
+ A table can be entered as:
+
+
+
+ Is translated to <texttable>
+ element in xml2rfc.
+ You can choose multiple styles as input, but they all are converted to the same style (plain
+ <texttable>) table in
+ xml2rfc. The column alignment
+ is copied over to the generated XML.
+
+
+ References
+
+ The caption is always
+ translated to a title
+ attribute. If a table has a caption, it will
+ also get a reference.
+ The reference anchor attribute will be:
+ tab-
+ + first 10 (normalized) characters from the caption.
+ Where normalized means:
+
+
+ -
+ Take the first 10 characters of the caption (i.e. this is the text
+ after the string
+ Table:);
+
+ -
+ Spaces and single quotes (') are translated to a minus
+ -;
+
+ -
+ Uppercase letters translated to lowercase.
+
+
+
+ So the first table with a caption will get
+ tab-a-caption-
+ for reference use. See for instance
+
+
+ This anchoring is completely handled from within the
+ xslt.
+ Note that duplicate anchors are an XML validation error which will make
+ xml2rfc fail.
+
+
+
+
+ Indexes
+
+ The footnote syntax of Pandoc is slightly abused to support an index. Footnotes are entered in two steps, you have a marker in the text, and later you give actual footnote text. Like this:
+
+
+
+ We re-use this syntax for the <iref> tag. The above text translates to:
+
+
+ ]]>
+
+ Sub items are also supported. Use an exclamation mark (!) to separate them:
+
+
+
+
+
+ Usage guidelines
+
+ Working with multiple files
+
+ As an author you will probably break up a draft in multiple files, each dealing
+ with a subject or section. When doing so sections with the same title will clash
+ with each other. Pandoc can deal with this situation, but only if the different
+ sections are in the same file or
+ processed in the same Pandoc run. Concatenating the different section files
+ before processing them is a solution to this problem. You can, for instance,
+ amend the Makefile and add
+ something like this:
+
+ allsections.pdc
+ ]]>
+
+ And then process allsection.pdc in the normal way.
+
+
+
+ Setting the title
+
+ If you use double quotes in the documents title in the
+ docName attribute, like:
+
+
+ ]]>
+
+ The Makefile will pick this up automatically and make a symbolic link:
+
+ draft.txt
+ ]]>
+
+ This makes uploading the file to the i-d tracker a bit easier.
+
+
+
+ Uploading the XML/txt
+
+ The draft.xml target will
+ generate an XML file with all XML included, so you can upload just one file to
+ the I-D tracker.
+
+
+
+ VIM syntax highlighting
+
+ If you are a VIM user you might be interested in a syntax highlighting file (see
+ ) that slightly lightens up
+ your reading experience while viewing a draft.txt from VIM.
+
+
+
+
+ Security Considerations
+
+ This document raises no security issues.
+
+
+
+ IANA Considerations
+
+ This document has no actions for IANA.
+
+
+
+
+
+ References
+
+ Informative References
+
+
+ VIM syntax file for RFCs and I-Ds
+
+ Atoom Inc.
+
+ miek@miek.nl
+
+
+
+
+
+
+
+ Normative References
+
+
+
+
+ Informative References (by reference)
+
+
+
+
+ Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification
+
+ International Organization for Standardization
+
+
+
+
+
+
+
+
+ Accelerometer
+
+
+
+
+
+
+
+
+ Source Routing Tutorial for End System Operation
+
+ Institute of Electrical and Electronics Engineers
+
+
+
+
+
+
+
+
+
+
+ Tests
+
+ This appendix consists out of a few tests that should all render to proper
+ xml2rfc XML.
+
+
+ A Very Long Title Considerations With Regards to the Already Deployed Routing Policy
+
+ Test a very long title.
+
+
+
+ Markup in heading
+
+ This is discarded by xml2rfc.
+
+
+
+ Blockquote
+
+ -
+ This is a blockquote, how does it look?
+
+
+
+
+ Verbatim code blocks
+
+
+
+ Reference Tests
+
+ Refer to RFC 2119 if you will. Or maybe you want to inspect in again. Or you might want to Click here.
+
+
+
+ Spanx Tests
+
+ -
+ underscores: underscores
+
+ -
+ asterisks: asterisks
+
+ -
+ double asterisks: double asterisks
+
+ -
+ backticks: backticks
+
+
+
+
+ List Tests
+ -
+ First we do
+
+ -
+
+ And then
+
+ -
+ item 1
+
+ -
+ item 2
+
+
+
+
+
+ And the other around.
+
+
+ -
+ First we do
+
+ -
+
+ Then
+
-
+ Something
+
+ -
+ Another thing
+
+
+
+
+
+ Description lists:
+
+
+ - Item to explain:
+ - It works because of herbs.
+
+ - Another item to explain:
+ -
+ More explaining.
+ Multiple paragraphs in such a list.
+
+
+
+
+ lists in description lists.
+
+
+ - Item to explain:
+ -
+ It works because of
+
-
+ One
+
+ -
+ Two
+
+
+
+ - Another item to explain:
+ - More explaining
+
+ - Item to explain:
+ -
+ It works because of
+
-
+ One1
+
+ -
+
+ Two1
+
+ -
+ Itemize list
+
+ -
+ Another item
+
+
+
+
+
+ - Another item to explain again:
+ - More explaining
+
+
+
+ list with description lists.
+
+ -
+
+ More
+
+ - Item to explain:
+ - Explanation ...
+
+ - Item to explain:
+ - Another explanation ...
+
+
+
+ -
+ Go'bye
+
+
+
+ Multiple paragraphs in a list.
+
+ -
+
+ This is the first bullet point and it needs multiple paragraphs...
+
+ ... to be explained properly.
+
+
+ -
+ This is the next bullet. New paragraphs should be indented with 4 four spaces.
+
+ -
+
+ Another item with some artwork, indented by 8 spaces.
+
+
+
+ -
+ Final item.
+
+
+
+ xml2rfc does not allow this, so the second paragraph is faked with a
+
+
+ ]]>
+
+ Ordered lists.
+
+ -
+ First item
+
+ -
+ Second item
+
+
+
+ A lowercase roman list:
+
+ -
+ Item 1
+
+ -
+ Item 2
+
+
+
+ An uppercase roman list.
+
+ -
+ Item1
+
+ -
+ Item2
+
+ -
+ Item 3
+
+
+
+ And default list markers.
+
+
+ Some surrounding text, to make it look better.
+
+
+ -
+ First item. Use lot of text to get a real paragraphs sense.
+ First item. Use lot of text to get a real paragraphs sense.
+ First item. Use lot of text to get a real paragraphs sense.
+ First item. Use lot of text to get a real paragraphs sense.
+
+ -
+ Second item. So this is the second para in your list. Enjoy;
+
+ -
+ Another item.
+
+
+
+ Text at the end.
+
+
+ Lowercase letters list.
+
+ -
+ First item
+
+ -
+ Second item
+
+
+
+ Uppercase letters list.
+
+ -
+ First item
+
+ -
+ Second item
+
+
+
+
+
+
+ And artwork in a description list.
+
+
+ - Item1:
+ -
+
+ Tell something about it. Tell something about it. Tell something about
+ it. Tell something about it. Tell something about it. Tell something about it.
+
+
+
+ Tell some more about it. Tell some more about it. Tell some more about it.
+
+
+ - Item2:
+ - Another description
+
+
+
+ List with a sublist with a paragraph above the sublist
+
+ -
+ First Item
+
+ -
+ Second item
+
+ -
+
+ Third item
+ A paragraph that comes first
+
-
+ But what do you know
+
+ -
+ This is another list
+
+
+
+
+
+
+ Table Tests
+
+ Demonstration of simple table
+ syntax.
+
+
+ Right |
+ Left |
+ Center |
+ Default |
+
+
+
+
+ 12 |
+ 12 |
+ 12 |
+ 12 |
+
+
+ 123 |
+ 123 |
+ 123 |
+ 123 |
+
+
+ 1 |
+ 1 |
+ 1 |
+ 1 |
+
+
+
+
+ Here's the caption. It, too, may span multiple lines. This is a
+ multiline table. This is verbatim text.
+
+
+ Centered Header |
+ Default Aligned |
+ Right Aligned |
+ Left Aligned |
+
+
+
+
+ First |
+ row |
+ 12.0 |
+ Example of a row that spans multiple lines. |
+
+
+ Second |
+ row |
+ 5.0 |
+ Here's another one. Note the blank line between rows. |
+
+
+
+
+
+
+
+ Sample grid table.
+
+
+ Fruit |
+ Price |
+ Advantages |
+
+
+
+
+ Bananas |
+ $1.34 |
+ built-in wrapper |
+
+
+ Oranges |
+ $2.10 |
+ cures scurvy |
+
+
+
+
+ Grid tables without a caption
+
+
+
+
+ Fruit |
+ Price |
+ Advantages |
+
+
+
+
+ Bananas |
+ $1.34 |
+ built-in wrapper |
+
+
+ Oranges |
+ $2.10 |
+ cures scurvy |
+
+
+
+
+ This table has no caption, and therefor no reference. But you can refer to some of the other tables, with for instance:
+
+
+
+ Which will become "See ".
+
+
+
+
+
+ We should also be able to refer to the table numbers directly, to say things like
+ 'Look at Tables
+ ,
+
+ and .'
+
+
+
+ Numbered examples
+
+ This is another example:
+
+ -
+ Another bla bla..
+
+
+
+ as (1) shows...
+
+
+
+ Figure tests
+
+
+ And how a figure that is not centered, do to using figure and not Figure.
+
+
+
+ Test the use of @title:
+
+
+
+
+ Verse tests
+
+ This is a verse text This is another line
+
+
+
+
+
diff --git a/tests/valid/sourcecode.pages.text b/tests/valid/sourcecode.pages.text
index 9285fe75..9148c0bc 100644
--- a/tests/valid/sourcecode.pages.text
+++ b/tests/valid/sourcecode.pages.text
@@ -3,9 +3,9 @@
Network Working Group H. Person, Ed.
-Internet-Draft September 26, 2024
+Internet-Draft October 22, 2024
Intended status: Experimental
-Expires: March 30, 2025
+Expires: April 25, 2025
xml2rfc sourcecode tests
@@ -26,7 +26,7 @@ Status of This Memo
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 March 30, 2025.
+ This Internet-Draft will expire on April 25, 2025.
Copyright Notice
@@ -53,9 +53,9 @@ Table of Contents
-Person Expires March 30, 2025 [Page 1]
+Person Expires April 25, 2025 [Page 1]
-Internet-Draft xml2rfc sourcecode tests September 2024
+Internet-Draft xml2rfc sourcecode tests October 2024
print("01")
@@ -109,9 +109,9 @@ Internet-Draft xml2rfc sourcecode tests September 2024
-Person Expires March 30, 2025 [Page 2]
+Person Expires April 25, 2025 [Page 2]
-Internet-Draft xml2rfc sourcecode tests September 2024
+Internet-Draft xml2rfc sourcecode tests October 2024
print("49")
@@ -165,9 +165,9 @@ Internet-Draft xml2rfc sourcecode tests September 2024
-Person Expires March 30, 2025 [Page 3]
+Person Expires April 25, 2025 [Page 3]
-Internet-Draft xml2rfc sourcecode tests September 2024
+Internet-Draft xml2rfc sourcecode tests October 2024
print("47")
@@ -221,4 +221,4 @@ Author's Address
-Person Expires March 30, 2025 [Page 4]
+Person Expires April 25, 2025 [Page 4]
diff --git a/tests/valid/sourcecode.prepped.xml b/tests/valid/sourcecode.prepped.xml
index 205bc681..c42ef085 100644
--- a/tests/valid/sourcecode.prepped.xml
+++ b/tests/valid/sourcecode.prepped.xml
@@ -1,6 +1,6 @@
-
-
+
+
@@ -20,7 +20,7 @@
-
+
Status of This Memo
@@ -41,7 +41,7 @@
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on 30 March 2025.
+ This Internet-Draft will expire on 25 April 2025.
diff --git a/tests/valid/sourcecode.text b/tests/valid/sourcecode.text
index 1baa5343..503d889f 100644
--- a/tests/valid/sourcecode.text
+++ b/tests/valid/sourcecode.text
@@ -3,9 +3,9 @@
Network Working Group H. Person, Ed.
-Internet-Draft September 26, 2024
+Internet-Draft October 22, 2024
Intended status: Experimental
-Expires: March 30, 2025
+Expires: April 25, 2025
xml2rfc sourcecode tests
@@ -26,7 +26,7 @@ Status of This Memo
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 March 30, 2025.
+ This Internet-Draft will expire on April 25, 2025.
Copyright Notice
diff --git a/tests/valid/sourcecode.v3.html b/tests/valid/sourcecode.v3.html
index 3baf5d80..101bc331 100644
--- a/tests/valid/sourcecode.v3.html
+++ b/tests/valid/sourcecode.v3.html
@@ -6,7 +6,7 @@
xml2rfc sourcecode tests
-
+
@@ -19,11 +19,11 @@
Internet-Draft |
xml2rfc sourcecode tests |
-September 2024 |
+October 2024 |
Person |
-Expires March 30, 2025 |
+Expires April 25, 2025 |
[Page] |
@@ -36,12 +36,12 @@
sourcecode-00
Published:
-
+
Intended Status:
Experimental
Expires:
-
+
Author:
@@ -71,7 +71,7 @@
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 March 30, 2025.¶
+ This Internet-Draft will expire on April 25, 2025.
¶