RFC 8792
Handling Long Lines in Content of Internet-Drafts and RFCs
RFC 8792: Handling Long Lines in Content of Internet-Drafts and RFCs β¨
Okay bestie, so this is RFC 8792, Handling Long Lines in Content of Internet-Drafts and RFCs π¦. It's an Informational doc from the IETF, so it's published for info and isn't a Standards Track spec π«Ά. It's dated June 2020 and has ISSN 2070-1721. The authors are K. Watsen (Watsen Networks), E. Auerswald (Individual Contributor), A. Farrel (Old Dog Consulting), and Q. Wu (Huawei Technologies). The header doesn't list anything it obsoletes or updates, so it stands on its own π .
Abstract πΈ
This doc gives you two ways to handle long lines in width-bounded text π. Strategy one is the "single backslash" one. It copies the old-school habit of putting a single backslash (\) where a line got folded, and the continuation picks up with the first character that isn't a space (' ') on the next line. Strategy two is the "double backslash" one, which is basically strategy one's glow-up β¨. It adds a second backslash to mark exactly where the continuation begins, so it can handle stuff strategy one just can't. Both come with a self-describing header so the original content can be rebuilt automatically π§.
Status of This Memo π
Okay so this one is not an Internet Standards Track specification. It's published for informational purposes π.
It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for that π.
For the latest status, errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8792 π.
Copyright Notice π₯
Copyright (c) 2020 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. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License π
.
Table of Contents π§
1. Introduction
2. Applicability Statement
3. Requirements Language
4. Goals
4.1. Automated Folding of Long Lines in Text Content
4.2. Automated Reconstitution of the Original Text Content
5. Limitations
5.1. Not Recommended for Graphical Artwork
5.2. Doesn't Work as Well as Format-Specific Options
6. Two Folding Strategies
6.1. Comparison
6.2. Recommendation
7. The Single Backslash Strategy ('\')
7.1. Folded Structure
7.1.1. Header
7.1.2. Body
7.2. Algorithm
7.2.1. Folding
7.2.2. Unfolding
8. The Double Backslash Strategy ('\\')
8.1. Folded Structure
8.1.1. Header
8.1.2. Body
8.2. Algorithm
8.2.1. Folding
8.2.2. Unfolding
9. Examples
9.1. Example Showing Boundary Conditions
9.1.1. Using '\'
9.1.2. Using '\\'
9.2. Example Showing Multiple Wraps of a Single Line
9.2.1. Using '\'
9.2.2. Using '\\'
9.3. Example Showing "Smart" Folding
9.3.1. Using '\'
9.3.2. Using '\\'
9.4. Example Showing "Forced" Folding
9.4.1. Using '\'
9.4.2. Using '\\'
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Bash Shell Script: rfcfold
Acknowledgements
Authors' Addresses
1. Introduction π
Okay so [RFC7994] sets out the requirements for plain-text RFCs, and it says each line of an RFC (and so each line of an Internet-Draft) must be limited to 72 characters, followed by the character sequence that marks an end-of-line (EOL) π.
Internet-Drafts and RFCs often include example text or code fragments, and those examples are often longer than the 72-character limit π. At the time of this doc's publication, the xml2rfc utility [xml2rfc] doesn't try to wrap the content of those inclusions. It just gives a warning whenever lines go past 69 characters. Historically, the RFC Editor hasn't recommended any convention for long lines in those inclusions, except telling authors to clearly indicate what manipulation has happened β¨.
This doc defines two strategies for handling long lines in width-bounded text content. Strategy one is the "single backslash" strategy. It's based on the historical use of a single backslash ('\') to show where folding happened, with the continuation starting at the first character that isn't a space (' ') on the next line. Strategy two is the "double backslash" strategy. It extends strategy one by adding a second backslash to show where the continuation begins, so it can handle cases strategy one can't π¦. Both use a self-describing header so the original content can be reconstituted automatically π§.
The strategies here work on any text content, but they're mainly meant for a structured sequence of lines, like what the <sourcecode> element in Section 2.48 of [RFC7991] would reference. They're not really meant for two-dimensional imagery, like what the <artwork> element in Section 2.5 of [RFC7991] would reference π
.
Also, text files are represented as lines with their first character in column 1. A line of length N has its last character in the Nth column, and it's immediately followed by an end-of-line character sequence πΈ.
2. Applicability Statement π
The formats and algorithms in this doc may be used in any context, whether that's for IETF documents or for other situations where structured folding is wanted π«Ά.
Inside the IETF, this work mainly targets the xml2rfc v3 <sourcecode> element (Section 2.48 of [RFC7991]) and the xml2rfc v2 <artwork> element (Section 2.5 of [RFC7749]). For lack of a better option, xml2rfc v2 uses <artwork> for both source code and artwork π. This work may also be used for the xml2rfc v3 <artwork> element (Section 2.5 of [RFC7991]), but as Section 5.1 explains, it is generally not recommended π.
3. Requirements Language π₯
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here π. So if you see them in caps, they're the real deal, and if not, they're just regular words π§.
4. Goals π
4.1. Automated Folding of Long Lines in Text Content
Automated folding of long lines is needed so documents can be dynamically compiled to include content with potentially unconstrained line lengths π. For example, the build process might want to include content from other local files, or content that some external process generates on the fly. Both cases get their own paragraph below β¨.
Lots of documents need to include content from local files, like XML, JSON, ABNF, or ASN.1 π. Before including a file's content, the build process SHOULD first validate these source files using format-specific validators π
. For the tooling to process the files, they have to be in their original or natural state, and that can mean they have some long lines. So these source files need to be folded before they go into the XML document, in order to satisfy the xml2rfc line-length limits π₯.
Documents also sometimes contain dynamically generated output, usually from an external process working on the same source files as the previous paragraph. For instance, those processes might translate the input into another format, or render a report on the input file or a view of it π¦. In some cases the generated output may have lines that go over the xml2rfc line-length limits π.
In both cases, folding is required and SHOULD be automated, so you don't burn time and make mistakes doing it by hand π.
4.2. Automated Reconstitution of the Original Text Content
Automated reconstitution of the exact original text content is needed to support validation of text-based content pulled out of documents π§.
For example, YANG modules [RFC7950] are already extracted from Internet-Drafts and validated as part of the submission process πΈ. There's also been discussion about validating instance examples (that is, XML or JSON documents) contained within Internet-Drafts [yang-doctors-thread] π.
5. Limitations π«§
5.1. Not Recommended for Graphical Artwork
The solution in this doc works on any kind of text-based content, but it's most useful for content that represents source code (XML, JSON, and so on) or, more generally, content that hasn't been laid out in two dimensions, like diagrams π.
The big question is whether the text stays readable once it's folded π«£. Text that's unpredictable is especially likely to look bad when folded. That's most Unified Modeling Language (UML) diagrams, YANG tree diagrams, and ASCII art in general π.
It is NOT RECOMMENDED to use the solution in this document on graphical artwork β οΈ.
5.2. Doesn't Work as Well as Format-Specific Options
The solution here works generically for all text-based content, since it only treats content as plain text. But lots of formats have built-in mechanisms that are better suited to preventing long lines π .
For instance, both the pyang and yanglint utilities [pyang] [yanglint] have a command-line option called "tree-line-length". You can use it to set a desired maximum line length when generating YANG tree diagrams [RFC8340] π.
Another example: some source formats (for example, YANG [RFC7950]) let you break any quoted string into substrings joined by a concatenation character (for example, '+'). Any of those substrings can go on a different line π§.
It is RECOMMENDED that authors do as much as possible within the selected format to avoid long lines π«Ά. That's the main-character move π.
6. Two Folding Strategies π
This doc defines two nearly identical strategies for folding text-based content β¨.
- The Single Backslash Strategy (
'\'): Uses a backslash (\) at the end of the line where folding happens, and assumes the continuation begins at the first character that isn't a space (' ') on the following line π¦. - The Double Backslash Strategy (
'\\'): Uses a backslash (\) at the end of the line where folding happens, and assumes the continuation begins after a second backslash (\) on the following line π.
Those two are basically twins, just with one extra backslash to keep things clear π.
6.1. Comparison π
Okay so the first strategy gives you output that's more readable πβ¨. BUT (1) it's way more likely to run into unfoldable input, like a long line that's only space characters π, and (2) for long lines that can be folded, automation implementations might hit situations that, without special care, will produce errors π.
The second strategy is less readable π, but it's unlikely to run into unfoldable input, there are no long lines that can't be folded, and no special care is needed when folding a long line π«Ά.
6.2. Recommendation π
It is RECOMMENDED that implementations first try folding content with the single backslash strategy β¨. Only in the unlikely event that it can't fold the input, or the folding logic can't cope with a contingency happening on the desired folding column, should they then fall back to the double backslash strategy π.
7. The Single Backslash Strategy ('') πΈ
7.1. Folded Structure π§
Text content that's been folded this way MUST adhere to the following structure π.
7.1.1. Header π
The header is two lines long.
The first line is the following 36-character string π; this string MAY be surrounded by any number of printable characters. This first line cannot itself be folded.
NOTE: '\' line wrapping per RFC 8792
The second line is an empty line, containing only the end-of-line character sequence. This line provides visual separation for readability π.
7.1.2. Body π
The character encoding is the same as the encoding described in Section 2 of [RFC7994], except that, per [RFC7991], tab characters are prohibited π«.
Lines that have a backslash ('\') occurring as the last character in a line are considered "folded" π¦.
Exceptionally long lines MAY be folded multiple times π.
7.2. Algorithm π§
This section walks through how to fold and unfold long lines when you run into them in text content π«Ά.
The steps are complete, but implementations MAY achieve the same result in other ways π .
When a bigger document has multiple instances of text content that might need folding or unfolding, another process has to insert or extract the individual text content instances to or from the larger document before using the algorithms in this section. For example, the 'xiax' utility [xiax] does this π.
7.2.1. Folding βοΈ
Figure out the desired maximum line length from the input to the line-wrapping process, like from a command-line parameter. If no value is explicitly specified, the value "69" SHOULD be used π―.
Make sure the desired maximum line length is not less than the minimum header, which is 36 characters. If the desired maximum line length is less than this minimum, exit (this text-based content cannot be folded) π.
Scan the text content for horizontal tab characters. If any horizontal tab characters show up, either resolve them to space characters or exit, forcing the input provider to convert them to space characters themselves first π .
Scan the text content to make sure at least one line exceeds the desired maximum. If no line exceeds the desired maximum, exit (this text content does not need to be folded) π.
Scan the text content to make sure no existing lines already end with a backslash ('\') character, since that could lead to an ambiguous result. If such a line is found, and its width is less than the desired maximum, then it SHOULD be flagged for "forced" folding (folding even though it's unnecessary). If the folding implementation doesn't support forced foldings, it MUST exit π¨.
If this text content needs to, and can, be folded, insert the header described in Section 7.1.1, making sure any extra printable characters around the header don't push a line over the desired maximum π.
For each line in the text content, from top to bottom, if the line exceeds the desired maximum or requires a forced folding, then fold the line by doing the following steps:
- Figure out where the fold will happen. This location MUST be before or at the desired maximum column and MUST NOT be chosen such that the character immediately after the fold is a space (
' ') character. For forced foldings, the location is between the'\'and the end-of-line sequence. If no such location can be found, then exit (this text content cannot be folded). - At the location where the fold is to occur, insert a backslash (
'\') character followed by the end-of-line character sequence. - On the following line, insert any number of space (
' ') characters, provided that the resulting line does not exceed the desired maximum.
The result of the previous operation is that the next line starts with an arbitrary number of space (' ') characters, followed by the character that was previously occupying the position where the fold occurred π·.
Continue in this manner until reaching the end of the text content. Note that this algorithm naturally handles the case where the remainder of a folded line is still longer than the desired maximum and, hence, needs to be folded again, ad infinitum βΎοΈ.
The process described in this section is illustrated by the fold_it_1() function in Appendix A π.
7.2.2. Unfolding πͺ
Scan the beginning of the text content for the header described in Section 7.1.1. If the header is not present, exit (this text content does not need to be unfolded) π.
Remove the two-line header from the text content.
For each line in the text content, from top to bottom, if the line has a backslash ('\') character immediately followed by the end-of-line character sequence, then the line can be unfolded. Remove the backslash ('\') character, the end-of-line character sequence, and any leading space (' ') characters, which will bring up the next line. Then continue to scan each line in the text content starting with the current line (in case it was multiply folded) π.
Continue in this manner until reaching the end of the text content.
The process described in this section is illustrated by the unfold_it_1() function in Appendix A β¨.
8. The Double Backslash Strategy ('\') π
8.1. Folded Structure π
Text content folded the way this strategy describes MUST adhere to the following structure π.
8.1.1. Header πΈ
The header is two lines long.
The first line is the following 37-character string π; this string MAY be surrounded by any number of printable characters. This first line cannot itself be folded.
NOTE: '\\' line wrapping per RFC 8792
The second line is an empty line, containing only the end-of-line character sequence. This line provides visual separation for readability π.
8.1.2. Body π¦’
The character encoding is the same as the encoding described in Section 2 of [RFC7994], except that, per [RFC7991], tab characters are prohibited π«.
Lines that have a backslash ('\') occurring as the last character in a line, immediately followed by the end-of-line character sequence, when the subsequent line starts with a backslash ('\') as the first character that is not a space character (' '), are considered "folded" π¦.
Exceptionally long lines MAY be folded multiple times π.
8.2. Algorithm π§
This section walks through how to fold and unfold long lines when you run into them in text content π«Ά.
The steps are complete, but implementations MAY achieve the same result in other ways π .
When a bigger document has multiple instances of text content that might need folding or unfolding, another process has to insert or extract the individual text content instances to or from the larger document before using the algorithms in this section. For example, the 'xiax' utility [xiax] does this π.
8.2.1. Folding βοΈ
Figure out the desired maximum line length from the input to the line-wrapping process, like from a command-line parameter. If no value is explicitly specified, the value "69" SHOULD be used π―.
Make sure the desired maximum line length is not less than the minimum header, which is 37 characters. If the desired maximum line length is less than this minimum, exit (this text-based content cannot be folded) π.
Scan the text content for horizontal tab characters. If any horizontal tab characters show up, either resolve them to space characters or exit, forcing the input provider to convert them to space characters themselves first π .
Scan the text content to see if any line exceeds the desired maximum. If no line exceeds the desired maximum, exit (this text content does not need to be folded) π.
Scan the text content to make sure no existing lines already end with a backslash ('\') character while the subsequent line starts with a backslash ('\') character as the first character that is not a space character (' '), since that could lead to an ambiguous result. If such a line is found, and its width is less than the desired maximum, then it SHOULD be flagged for forced folding (folding even though it's unnecessary). If the folding implementation doesn't support forced foldings, it MUST exit π¨.
If this text content needs to, and can, be folded, insert the header described in Section 8.1.1, making sure any extra printable characters around the header don't push a line over the desired maximum π.
For each line in the text content, from top to bottom, if the line exceeds the desired maximum or requires a forced folding, then fold the line by doing the following steps:
- Figure out where the fold will happen. This location MUST be before or at the desired maximum column. For forced foldings, the location is between the
'\'and the end-of-line sequence on the first line. - At the location where the fold is to occur, insert a first backslash (
'\') character followed by the end-of-line character sequence. - On the following line, insert any number of space (
' ') characters, provided that the resulting line does not exceed the desired maximum, followed by a second backslash ('\') character.
The result of the previous operation is that the next line starts with an arbitrary number of space (' ') characters, followed by a backslash ('\') character, immediately followed by the character that was previously occupying the position where the fold occurred π·.
Continue in this manner until reaching the end of the text content. Note that this algorithm naturally handles the case where the remainder of a folded line is still longer than the desired maximum and, hence, needs to be folded again, ad infinitum βΎοΈ.
The process described in this section is illustrated by the fold_it_2() function in Appendix A π.
8.2.2. Unfolding β¨
Okay so unfolding is basically undoing the wrap π First, peek at the very start of the text content for the header from Section 8.1.1 π If it's not there, bail! This text content doesn't need unfolding π
If the header IS there, yank that two-line header out of the text content π
Then go line by line, top to bottom π¦ A line can be unfolded when it ends with a backslash (\) right before the end-of-line sequence AND the next line has a backslash (\) as its first character that isn't a space (' ') π«Ά When both are true, delete the first backslash, the end-of-line sequence, any leading spaces (' '), and that second backslash, and the next line slides right up onto this one β¨ Then keep scanning from the current line again, in case it got folded more than once π
Keep going like that until you reach the end of the text content π
If you want to see this in actual code, the "unfold_it_2()" function in Appendix A does exactly this π
9. Examples π
The following self-documenting examples illustrate folded text-based content.
The source text content can't be shown here, because it would just get folded again π Alas, only the results can be provided π
9.1. Example Showing Boundary Conditions π
This example illustrates boundary conditions. The input contains seven lines, each line one character longer than the previous line. Numbers are used for counting purposes. The default desired maximum column value "69" is used.
9.1.1. Using '' π¦
========== NOTE: '\' line wrapping per RFC 8792 ===========
123456789012345678901234567890123456789012345678901234567890123456
1234567890123456789012345678901234567890123456789012345678901234567
12345678901234567890123456789012345678901234567890123456789012345678
123456789012345678901234567890123456789012345678901234567890123456789
12345678901234567890123456789012345678901234567890123456789012345678\
90
12345678901234567890123456789012345678901234567890123456789012345678\
901
12345678901234567890123456789012345678901234567890123456789012345678\
9012
9.1.2. Using '\' πΈ
========== NOTE: '\\' line wrapping per RFC 8792 ==========
123456789012345678901234567890123456789012345678901234567890123456
1234567890123456789012345678901234567890123456789012345678901234567
12345678901234567890123456789012345678901234567890123456789012345678
123456789012345678901234567890123456789012345678901234567890123456789
12345678901234567890123456789012345678901234567890123456789012345678\
\90
12345678901234567890123456789012345678901234567890123456789012345678\
\901
12345678901234567890123456789012345678901234567890123456789012345678\
\9012
9.2. Example Showing Multiple Wraps of a Single Line π§
This example is about what happens when one super long line has to be folded multiple times π© The input contains one line with 280 characters. Numbers are used for counting purposes. The default desired maximum column value "69" is used.
9.2.1. Using '' π
========== NOTE: '\' line wrapping per RFC 8792 ===========
12345678901234567890123456789012345678901234567890123456789012345678\
90123456789012345678901234567890123456789012345678901234567890123456\
78901234567890123456789012345678901234567890123456789012345678901234\
56789012345678901234567890123456789012345678901234567890123456789012\
34567890
9.2.2. Using '\' π
========== NOTE: '\\' line wrapping per RFC 8792 ==========
12345678901234567890123456789012345678901234567890123456789012345678\
\9012345678901234567890123456789012345678901234567890123456789012345\
\6789012345678901234567890123456789012345678901234567890123456789012\
\3456789012345678901234567890123456789012345678901234567890123456789\
\01234567890
9.3. Example Showing "Smart" Folding π§
This example shows how readability can get a glow-up with "smart" folding π That means folding happens at format-specific locations, and format-specific indentations get used.
The text content was manually folded, since the script in Appendix A does not implement smart folding.
Note that the headers are surrounded by different printable characters than the ones in the script-generated examples β¨
9.3.1. Using '' π·
[NOTE: '\' line wrapping per RFC 8792]
<yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<module-set>
<name>config-modules</name>
<module>
<name>ietf-interfaces</name>
<revision>2018-02-20</revision>
<namespace>\
urn:ietf:params:xml:ns:yang:ietf-interfaces\
</namespace>
</module>
...
</module-set>
...
</yang-library>
Below is the equivalent of the above, but it was folded using the script in Appendix A π«Ά
========== NOTE: '\' line wrapping per RFC 8792 ===========
<yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<module-set>
<name>config-modules</name>
<module>
<name>ietf-interfaces</name>
<revision>2018-02-20</revision>
<namespace>urn:ietf:params:xml:ns:yang:ietf-interfaces</namesp\
ace>
</module>
...
</module-set>
...
</yang-library>
9.3.2. Using '\' π¦
[NOTE: '\\' line wrapping per RFC 8792]
<yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<module-set>
<name>config-modules</name>
<module>
<name>ietf-interfaces</name>
<revision>2018-02-20</revision>
<namespace>\
\urn:ietf:params:xml:ns:yang:ietf-interfaces\
\</namespace>
</module>
...
</module-set>
...
</yang-library>
Below is the equivalent of the above, but it was folded using the script in Appendix A π
========== NOTE: '\\' line wrapping per RFC 8792 ==========
<yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<module-set>
<name>config-modules</name>
<module>
<name>ietf-interfaces</name>
<revision>2018-02-20</revision>
<namespace>urn:ietf:params:xml:ns:yang:ietf-interfaces</namesp\
\ace>
</module>
...
</module-set>
...
</yang-library>
9.4. Example Showing "Forced" Folding π₯
This example shows how invalid sequences in lines that do NOT have to be folded can still be handled via forced folding, which means the folding happens even though it's unnecessary π Very extra, very on purpose π
The input looks like this:
The following line exceeds a 68-char max and, thus, demands folding:
123456789012345678901234567890123456789012345678901234567890123456789
This line ends with a backslash \
This line ends with a backslash \
\ This line begins with a backslash
The following is an indented 3x3 block of backslashes:
\\\
\\\
\\\
The samples below were manually folded, since the script in the appendix does not implement forced folding π
Note that the headers are prefixed by a pound (#) character, rather than surrounded by 'equals' (=) characters as shown in the script-generated examples π
9.4.1. Using '' π
# NOTE: '\' line wrapping per RFC 8792
The following line exceeds a 68-char max and, thus, demands folding:
1234567890123456789012345678901234567890123456789012345678901234567\
89
This line ends with a backslash \\
This line ends with a backslash \\
\ This line begins with a backslash
The following is an indented 3x3 block of backslashes:
\\\\
\\\\
\\\
9.4.2. Using '\' π§
# NOTE: '\\' line wrapping per RFC 8792
The following line exceeds a 68-char max and, thus, demands folding:
1234567890123456789012345678901234567890123456789012345678901234567\
\89
This line ends with a backslash \
This line ends with a backslash \\
\
\ This line begins with a backslash
The following is an indented 3x3 block of backslashes:
\\\\
\
\\\\
\
\\\
10. Security Considerations π
This document has no security considerations. Zero. Nada. Not a single one π«Ά Still, stay safe out there, bestie π
11. IANA Considerations πΈ
This document has no IANA actions. Nothing to register, nothing to request, just vibes β¨
12. References π
12.1. Normative References π
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC7991]Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <https://www.rfc-editor.org/info/rfc7991>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References π¦
[bash]"GNU Bash Manual", <https://www.gnu.org/software/bash/manual>.[pyang]"pyang", <https://pypi.org/project/pyang/>.[RFC7749]Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, <https://www.rfc-editor.org/info/rfc7749>.[RFC7950]Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.[RFC7994]Flanagan, H., "Requirements for Plain-Text RFCs", RFC 7994, DOI 10.17487/RFC7994, December 2016, <https://www.rfc-editor.org/info/rfc7994>.[RFC8340]Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.[xiax]"The 'xiax' Python Package", <https://pypi.org/project/xiax/>.[xml2rfc]"xml2rfc", <https://pypi.org/project/xml2rfc/>.[yang-doctors-thread]Watsen, K., "[yang-doctors] automating yang doctor reviews", message to the yang-doctors mailing list, 18 April 2018, <https://mailarchive.ietf.org/arch/msg/yang-doctors/DCfBqgfZPAD7afzeDFlQ1Xm2X3g>.[yanglint]"yanglint", commit 1b7d73d, February 2020, <https://github.com/CESNET/libyang#yanglint>.
Appendix A. Bash Shell Script: rfcfold π
This non-normative appendix includes a Bash shell script [bash] that can both fold and unfold text content using both the single and double backslash strategies described in Sections 7 and 8, respectively. This shell script, called 'rfcfold', is maintained at <https://github.com/ietf-tools/rfcfold>.
This script is intended to be applied to a single text content instance. If it is desired to fold or unfold text content instances within a larger document (e.g., an Internet-Draft or RFC), then another tool must be used to extract the content from the larger document before utilizing this script.
For readability purposes, this script forces the minimum supported line length to be eight characters longer than the raw header text defined in Sections 7.1.1 and 8.1.1, so as to ensure that the header can be wrapped by a space (' ') character and three 'equals' (=) characters on each side of the raw header text π
When a tab character is detected in the input file, this script exits with the following error message π«
Error: infile contains a tab character, which is not allowed.
okay so bestie, this part is where the script gets its little safety checks π§ it looks for GNU awk (gawk) so it can spot ASCII control characters and non-ASCII characters in the input file π heads up, testing found the default awk has flaws on some platforms π but since this script only uses gawk for warnings, if it can't find gawk it just shrugs and prints a debug message:
Debug: no GNU awk; skipping checks for special characters.
If gawk is around and it finds ASCII control characters, you get this warning:
Warning: infile contains ASCII control characters (unsupported).
Same energy for non-ASCII characters:
Warning: infile contains non-ASCII characters (unsupported).
The script does not do the whitespace-avoidance logic from Section 7.2.1 π¬ so if it finds a space on the folding column, it exits with this error:
Error: infile has a space character occurring on the folding column. This file cannot be folded using the '\' strategy.
It can unfold input that has forced foldings, but it can't fold a file that would need them π¦ (forced folding is covered in Sections 7.2.1 and 8.2.1). So if you ask it to fold one of those, it exits with one of these messages:
For '':
Error: infile has a line ending with a '\' character. This file cannot be folded using the '\' strategy without there being false positives produced in the unfolding (i.e., this script does not force-fold such lines, as described in RFC 8792).
For '\':
Error: infile has a line ending with a '\' character followed by a '\' character as the first non-space character on the next line. This script cannot fold this file using the '\\' strategy without there being false positives produced in the unfolding (i.e., this script does not force-fold such lines, as described in RFC 8792).
The shell-level end-of-line backslashes ('\') were added on purpose so the script itself doesn't get folded in this doc, which makes copy-pasting way easier π
You can tell they aren't folded-line markers because there's no mandatory header from Section 7.1.1 (see Section 7 for more on that π«Ά).
Here's the script, called rfcfold π
#!/bin/bash --posix
# This script may need some adjustments to work on a given system.
# For instance, the utility 'gsed' may need to be installed.
# Also, please be advised that 'bash' (not 'sh') must be used.
# Copyright (c) 2020 IETF Trust, Kent Watsen, and Erik Auerswald.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# * Redistributions in binary form must reproduce the above
# copyright notice, this list of conditions and the following
# disclaimer in the documentation and/or other materials
# provided with the distribution.
#
# * Neither the name of Internet Society, IETF or IETF Trust, nor
# the names of specific contributors, may be used to endorse or
# promote products derived from this software without specific
# prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
print_usage() {
printf "\n"
printf "Folds or unfolds the input text file according to"
printf " RFC 8792.\n"
printf "\n"
printf "Usage: rfcfold [-h] [-d] [-q] [-s <strategy>] [-c <col>]"
printf " [-r] -i <infile> -o <outfile>\n"
printf "\n"
printf " -s: strategy to use, '1' or '2' (default: try 1,"
printf " else 2)\n"
printf " -c: column to fold on (default: 69)\n"
printf " -r: reverses the operation\n"
printf " -i: the input filename\n"
printf " -o: the output filename\n"
printf " -d: show debug messages (unless -q is given)\n"
printf " -q: quiet (suppress error and debug messages)\n"
printf " -h: show this message\n"
printf "\n"
printf "Exit status code: 1 on error, 0 on success, 255 on no-op."
printf "\n\n"
}
# global vars, do not edit
strategy=0 # auto
debug=0
quiet=0
reversed=0
infile=""
outfile=""
maxcol=69 # default, may be overridden by param
col_gvn=0 # maxcol overridden?
hdr_txt_1="NOTE: '\\' line wrapping per RFC 8792"
hdr_txt_2="NOTE: '\\\\' line wrapping per RFC 8792"
equal_chars="======================================================="
space_chars=" "
temp_dir=""
prog_name='rfcfold'
# functions for diagnostic messages
prog_msg() {
if [[ "$quiet" -eq 0 ]]; then
format_string="${prog_name}: $1: %s\n"
shift
printf -- "$format_string" "$*" >&2
fi
}
err() {
prog_msg 'Error' "$@"
}
warn() {
prog_msg 'Warning' "$@"
}
dbg() {
if [[ "$debug" -eq 1 ]]; then
prog_msg 'Debug' "$@"
fi
}
# determine name of [g]sed binary
type gsed > /dev/null 2>&1 && SED=gsed || SED=sed
# warn if a non-GNU sed utility is used
"$SED" --version < /dev/null 2> /dev/null | grep -q GNU || \
warn 'not using GNU `sed` (likely cause if an error occurs).'
cleanup() {
rm -rf "$temp_dir"
}
trap 'cleanup' EXIT
fold_it_1() {
# ensure input file doesn't contain the fold-sequence already
if [[ -n "$("$SED" -n '/\\$/p' "$infile")" ]]; then
err "infile '$infile' has a line ending with a '\\' character."\
"This script cannot fold this file using the '\\' strategy"\
"without there being false positives produced in the"\
"unfolding."
return 1
fi
# where to fold
foldcol=$(expr "$maxcol" - 1) # for the inserted '\' char
# ensure input file doesn't contain whitespace on the fold column
grep -q "^\(.\{$foldcol\}\)\{1,\} " "$infile"
if [[ $? -eq 0 ]]; then
err "infile '$infile' has a space character occurring on the"\
"folding column. This file cannot be folded using the"\
"'\\' strategy."
return 1
fi
# center header text
length=$(expr ${#hdr_txt_1} + 2)
left_sp=$(expr \( "$maxcol" - "$length" \) / 2)
right_sp=$(expr "$maxcol" - "$length" - "$left_sp")
header=$(printf "%.*s %s %.*s" "$left_sp" "$equal_chars"\
"$hdr_txt_1" "$right_sp" "$equal_chars")
# generate outfile
echo "$header" > "$outfile"
echo "" >> "$outfile"
"$SED" 's/\(.\{'"$foldcol"'\}\)\(..\)/\1\\\n\2/;t M;b;:M;P;D;'\
< "$infile" >> "$outfile" 2> /dev/null
if [[ $? -ne 0 ]]; then
return 1
fi
return 0
}
fold_it_2() {
# where to fold
foldcol=$(expr "$maxcol" - 1) # for the inserted '\' char
# ensure input file doesn't contain the fold-sequence already
if [[ -n "$("$SED" -n '/\\$/{N;s/\\\n[ ]*\\/&/p;D}' "$infile")" ]]
then
err "infile '$infile' has a line ending with a '\\' character"\
"followed by a '\\' character as the first non-space"\
"character on the next line. This script cannot fold"\
"this file using the '\\\\' strategy without there being"\
"false positives produced in the unfolding."
return 1
fi
# center header text
length=$(expr ${#hdr_txt_2} + 2)
left_sp=$(expr \( "$maxcol" - "$length" \) / 2)
right_sp=$(expr "$maxcol" - "$length" - "$left_sp")
header=$(printf "%.*s %s %.*s" "$left_sp" "$equal_chars"\
"$hdr_txt_2" "$right_sp" "$equal_chars")
# generate outfile
echo "$header" > "$outfile"
echo "" >> "$outfile"
"$SED" 's/\(.\{'"$foldcol"'\}\)\(..\)/\1\\\n\\\2/;t M;b;:M;P;D;'\
< "$infile" >> "$outfile" 2> /dev/null
if [[ $? -ne 0 ]]; then
return 1
fi
return 0
}
fold_it() {
# ensure input file doesn't contain a tab
grep -q $'\t' "$infile"
if [[ $? -eq 0 ]]; then
err "infile '$infile' contains a tab character, which is not"\
"allowed."
return 1
fi
# folding of input containing ASCII control or non-ASCII characters
# may result in a wrong folding column and is not supported
if type gawk > /dev/null 2>&1; then
env LC_ALL=C gawk '/[\000-\014\016-\037\177]/{exit 1}' "$infile"\
|| warn "infile '$infile' contains ASCII control characters"\
"(unsupported)."
env LC_ALL=C gawk '/[^\000-\177]/{exit 1}' "$infile"\
|| warn "infile '$infile' contains non-ASCII characters"\
"(unsupported)."
else
dbg "no GNU awk; skipping checks for special characters."
fi
# check if file needs folding
testcol=$(expr "$maxcol" + 1)
grep -q ".\{$testcol\}" "$infile"
if [[ $? -ne 0 ]]; then
dbg "nothing to do; copying infile to outfile."
cp "$infile" "$outfile"
return 255
fi
if [[ "$strategy" -eq 1 ]]; then
fold_it_1
return $?
fi
if [[ "$strategy" -eq 2 ]]; then
fold_it_2
return $?
fi
quiet_sav="$quiet"
quiet=1
fold_it_1
result=$?
quiet="$quiet_sav"
if [[ "$result" -ne 0 ]]; then
dbg "Folding strategy '1' didn't succeed; trying strategy '2'..."
fold_it_2
return $?
fi
return 0
}
unfold_it_1() {
temp_dir=$(mktemp -d)
# output all but the first two lines (the header) to wip file
awk "NR>2" "$infile" > "$temp_dir/wip"
# unfold wip file
"$SED" '{H;$!d};x;s/^\n//;s/\\\n *//g' "$temp_dir/wip" > "$outfile"
return 0
}
unfold_it_2() {
temp_dir=$(mktemp -d)
# output all but the first two lines (the header) to wip file
awk "NR>2" "$infile" > "$temp_dir/wip"
# unfold wip file
"$SED" '{H;$!d};x;s/^\n//;s/\\\n *\\//g' "$temp_dir/wip"\
> "$outfile"
return 0
}
unfold_it() {
# check if file needs unfolding
line=$(head -n 1 "$infile")
line2=$("$SED" -n '2p' "$infile")
result=$(echo "$line" | fgrep "$hdr_txt_1")
if [[ $? -eq 0 ]]; then
if [[ -n "$line2" ]]; then
err "the second line in '$infile' is not empty."
return 1
fi
unfold_it_1
return $?
fi
result=$(echo "$line" | fgrep "$hdr_txt_2")
if [[ $? -eq 0 ]]; then
if [[ -n "$line2" ]]; then
err "the second line in '$infile' is not empty."
return 1
fi
unfold_it_2
return $?
fi
dbg "nothing to do; copying infile to outfile."
cp "$infile" "$outfile"
return 255
}
process_input() {
while [[ "$1" != "" ]]; do
if [[ "$1" == "-h" ]] || [[ "$1" == "--help" ]]; then
print_usage
exit 0
elif [[ "$1" == "-d" ]]; then
debug=1
elif [[ "$1" == "-q" ]]; then
quiet=1
elif [[ "$1" == "-s" ]]; then
if [[ "$#" -eq "1" ]]; then
err "option '-s' needs an argument (use -h for help)."
exit 1
fi
strategy="$2"
shift
elif [[ "$1" == "-c" ]]; then
if [[ "$#" -eq "1" ]]; then
err "option '-c' needs an argument (use -h for help)."
exit 1
fi
col_gvn=1
maxcol="$2"
shift
elif [[ "$1" == "-r" ]]; then
reversed=1
elif [[ "$1" == "-i" ]]; then
if [[ "$#" -eq "1" ]]; then
err "option '-i' needs an argument (use -h for help)."
exit 1
fi
infile="$2"
shift
elif [[ "$1" == "-o" ]]; then
if [[ "$#" -eq "1" ]]; then
err "option '-o' needs an argument (use -h for help)."
exit 1
fi
outfile="$2"
shift
else
warn "ignoring unknown option '$1'."
fi
shift
done
if [[ -z "$infile" ]]; then
err "infile parameter missing (use -h for help)."
exit 1
fi
if [[ -z "$outfile" ]]; then
err "outfile parameter missing (use -h for help)."
exit 1
fi
if [[ ! -f "$infile" ]]; then
err "specified file '$infile' does not exist."
exit 1
fi
if [[ "$col_gvn" -eq 1 ]] && [[ "$reversed" -eq 1 ]]; then
warn "'-c' option ignored when unfolding (option '-r')."
fi
if [[ "$strategy" -eq 0 ]] || [[ "$strategy" -eq 2 ]]; then
min_supported=$(expr ${#hdr_txt_2} + 8)
else
min_supported=$(expr ${#hdr_txt_1} + 8)
fi
if [[ "$maxcol" -lt "$min_supported" ]]; then
err "the folding column cannot be less than $min_supported."
exit 1
fi
# this is only because the code otherwise runs out of equal_chars
max_supported=$(expr ${#equal_chars} + 1 + ${#hdr_txt_1} + 1\
+ ${#equal_chars})
if [[ "$maxcol" -gt "$max_supported" ]]; then
err "the folding column cannot be more than $max_supported."
exit 1
fi
}
main() {
if [[ "$#" -eq "0" ]]; then
print_usage
exit 1
fi
process_input "$@"
if [[ "$reversed" -eq 0 ]]; then
fold_it
code=$?
else
unfold_it
code=$?
fi
exit "$code"
}
main "$@"
<CODE ENDS>
Acknowledgements β¨
Huge thanks to the RFC Editor π«Ά for confirming that, when this document was published, there was no set convention for handling long lines in source code inclusions. Honestly, that gap is what kicked off this whole project π
The authors also want to thank the following folks for their various contributions while producing this document (sorted by first name): Ben Kaduk, Benoit Claise, Gianmarco Bruno, Italo Busi, Joel Jaeggli, Jonathan Hansford, Lou Berger, Martin Bjorklund, and Rob Wilton. Iconic squad ππ
Authors' Addresses π
- Kent Watsen, Watsen Networks. Email: kent+ietf@watsen.net π
- Erik Auerswald, Individual Contributor. Email: auerswal@unix-ag.uni-kl.de π¦
- Adrian Farrel, Old Dog Consulting. Email: adrian@olddog.co.uk πΈ
- Qin Wu, Huawei Technologies. Email: bill.wu@huawei.com β
π¦ where this page comes from
- ietf: rfc8792 2020-06
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms