idnits 2.17.1 draft-ietf-netmod-artwork-folding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 5, 2018) is 1992 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '-r' is mentioned on line 495, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Best Current Practice Q. Wu 5 Expires: May 9, 2019 Huawei Technologies 6 A. Farrel 7 Old Dog Consulting 8 B. Claise 9 Cisco Systems, Inc. 10 November 5, 2018 12 Handling Long Lines in Artwork in Internet-Drafts and RFCs 13 draft-ietf-netmod-artwork-folding-00 15 Abstract 17 This document introduces a simple and yet time-proven strategy for 18 handling long lines in artwork in drafts using a backslash ('\') 19 character where line-folding has occurred. The strategy works on any 20 text based artwork, but is primarily intended for sample text and 21 formatted examples and code, rather than for graphical artwork. The 22 approach produces consistent results regardless of the content and 23 uses a per-artwork header. The strategy is both self-documenting and 24 enables automated reconstitution of the original artwork. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 9, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Automated Folding of Long Lines in Artwork . . . . . . . 3 64 3.2. Automated Reconstitution of Original Artwork . . . . . . 4 65 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Not Recommended for Graphical Artwork . . . . . . . . . . 4 67 4.2. Doesn't Work as Well as Format-Specific Options . . . . . 4 68 5. Folded Structure . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.2. Body . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6.1. Automated Folding . . . . . . . . . . . . . . . . . . . . 6 73 6.1.1. Manual Folding . . . . . . . . . . . . . . . . . . . 7 74 6.2. Automated Unfolding . . . . . . . . . . . . . . . . . . . 7 75 7. Considerations for xml2rfc v3 . . . . . . . . . . . . . . . . 8 76 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Simple Example Showing Boundary Conditions . . . . . . . 8 78 8.2. Example Showing Multiple Wraps of a Single Line . . . . . 9 79 8.3. Example With Native Backslash . . . . . . . . . . . . . . 9 80 8.4. Example With Native Whitespace . . . . . . . . . . . . . 9 81 8.5. Example of Manual Wrapping . . . . . . . . . . . . . . . 9 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 11.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Appendix A. POSIX Shell Script . . . . . . . . . . . . . . . . . 12 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 [RFC7994]sets out the requirements for plain-text RFCs and states 94 that each line of an RFC (and hence of an Internet-Draft) must be 95 limited to 72 characters followed by the character sequence that 96 denotes an end-of-line (EOL). 98 Internet-Drafts and RFCs often include example text or code 99 fragments. In order to render the formatting of such text it is 100 usually presented as a figure using the "" element in the 101 source XML. Many times the example text or code exceeds the 72 102 character line-length limit and the "xml2rfc" utility does not 103 attempt to wrap the content of artwork, simply issuing a warning 104 whenever artwork lines exceed 69 characters. According to the RFC 105 Editor, there is currently no convention in place for how to handle 106 long lines, other than advising authors to clearly indicate what 107 manipulation has occurred. 109 This document introduces a simple and yet time-proven strategy for 110 handling long lines using a backslash ('\') character where line- 111 folding has occurred. The strategy works on any text based artwork, 112 but is primarily intended for sample text and formatted examples and 113 code, rather than for graphical artwork. The approach produces 114 consistent results regardless of the content and uses a per-artwork 115 header. The strategy is both self-documenting and enables automated 116 reconstitution of the original artwork. 118 Note that text files are represent as lines having their first 119 character in column 1, and a line length of N where the last 120 character is in the Nth column and is immediately followed by an end 121 of line character sequence. 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Goals 133 3.1. Automated Folding of Long Lines in Artwork 135 Automated folding of long lines is needed in order to support draft 136 compilations that entail a) validation of source input files (e.g., 137 XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output, using 138 a tool that doesn't observe line lengths, that is stitched into the 139 final document to be submitted. 141 Generally, in order for tooling to be able to process input files, 142 the files must be in their original/natural state, which may include 143 having some long lines. Thus, these source files need to be modified 144 before inclusion in the document in order to satisfy the line length 145 limits. This modification SHOULD be automated to reduce effort and 146 errors resulting from manual effort. 148 Similarly, dynamically generated output (e.g., tree diagrams) must 149 also be modified, if necessary, in order for the resulting document 150 to satisfy the line length limits. When needed, this effort again 151 SHOULD be automated to reduce effort and errors resulting from manual 152 effort. 154 3.2. Automated Reconstitution of Original Artwork 156 Automated reconstitution of the original artwork is needed to support 157 validation of artwork extracted from documents. YANG [RFC7950] 158 modules are already extracted from Internet-Drafts and validated as 159 part of the draft-submission process. Additionally, there has been 160 some discussion regarding needing to do the same for example YANG 161 fragments contained within Internet-Drafts ([yang-doctors-thread]). 162 Thus, it SHOULD be possible to mechanically reconstitute artwork in 163 order to satisfy the tooling input parsers. 165 4. Limitations 167 4.1. Not Recommended for Graphical Artwork 169 While the solution presented in this document will work on any kind 170 of text-based artwork, it is most useful on artwork that represents 171 sourcecode (XML, JSON, etc.) or, more generally, on artwork that has 172 not been laid out in two dimensions (e.g., diagrams). 174 Fundamentally, the issue is whether the artwork remains readable once 175 folded. Artwork that is unpredictable is especially susceptible to 176 looking bad when folded; falling into this category are most UML 177 diagrams. 179 It is NOT RECOMMENDED to use the solution presented in this document 180 on graphical artwork. 182 4.2. Doesn't Work as Well as Format-Specific Options 184 The solution presented in this document works generically for all 185 artwork, as it only views artwork as plain text. However, various 186 formats sometimes have built-in mechanisms that can be used to 187 prevent long lines. 189 For instance, both the `pyang` and `yanglint` utilities have the 190 command line option "--tree-line-length" that can be used to indicate 191 a desired maximum line length for when generating tree diagrams 192 [RFC8340]. 194 In another example, some source formats (e.g., YANG [RFC7950]) allow 195 any quoted string to be broken up into substrings separated by a 196 concatenation character (e.g., '+'), any of which can be on a 197 different line. 199 In yet another example, some languages allow factoring chunks of code 200 into call outs, such as functions. Using such call outs is 201 especially helpful when in some deeply-nested code, as they typically 202 reset the indentation back to the first column. 204 As such, it is RECOMMENDED that authors do as much as possible within 205 the selected format to avoid long lines. 207 5. Folded Structure 209 Artwork that has been folded as specified by this document MUST 210 contain the following structure. 212 5.1. Header 214 The header is two lines long. 216 The first line is the following 46-character string that MAY be 217 surrounded by any number of printable characters. This first line 218 cannot itself be folded. 220 NOTE: '\\' line wrapping per BCP XX (RFC XXXX) 222 [Note to RFC Editor: Please replace XX and XXXX with the numbers 223 assigned to this document and delete this note. Please make this 224 change in multiple places in this document.] 226 The second line is a blank line. This line provides visual 227 separation for readability. 229 5.2. Body 231 The character encoding is the same as described in Section 2 of 232 [RFC7994], except that, per [RFC7991], tab characters are prohibited. 234 Lines that have a backslash ('\') occurring as the last character in 235 a line immediately followed by the end of line character sequence, 236 when the subsequent line starts with a backslash ('\') as the first 237 non-space (' ') character, are considered "folded". 239 Really long lines may be folded multiple times. 241 6. Algorithm 243 6.1. Automated Folding 245 Determine the desired maximum line length from input. If no value is 246 explicitly specified, the value "69" SHOULD be used. 248 Ensure that the desired maximum line length is not less than the 249 minimum header, which is 46 characters. If the desired maximum line 250 length is less than this minimum, exit (this artwork can not be 251 folded). 253 Scan the artwork to see if any line exceeds the desired maximum. If 254 no line exceeds the desired maximum, exit (this artwork does not need 255 to be folded). 257 Scan the artwork for horizontal tab characters. If any horizontal 258 tab characters appear, either resolve them to space characters or 259 exit, forcing the input provider to convert them to space characters 260 themselves first. 262 Scan the artwork to ensure no existing lines already end with a 263 backslash ('\') character when the subsequent line starts with a 264 backslash ('\') character as the first non-space (' ') character, as 265 this would lead to an ambiguous result. If such a line is found, 266 exit (this artwork cannot be folded). 268 For each line in the artwork, from top-to-bottom, if the line exceeds 269 the desired maximum, then fold the line at the desired maximum column 270 by 1) inserting the character backslash ('\') character at the 271 maximum column, 2) inserting the end of line character sequence, 272 inserting any number of space (' ') characters, and 4) inserting a 273 further backslash ('\') character. 275 The result of this previous operation is that the next line starts 276 with an arbitrary number of space (' ') characters, followed by a 277 backslash ('\') character, immediately followed by the character that 278 was previously in the maximum column. 280 Continue in this manner until reaching the end of the artwork. Note 281 that this algorithm naturally addresses the case where the remainder 282 of a folded line is still longer than the desired maximum, and hence 283 needs to be folded again, ad infinitum. 285 6.1.1. Manual Folding 287 Authors may choose to fold text examples and source code by hand to 288 produce a document that is more pleasant for a human reader but which 289 can still be automatically unfolded (as described in Section 6.2) to 290 produce single lines that are longer than the maximum document line 291 length. 293 For example, an author may choose to make the fold at convenient gaps 294 between words such that the backslash is placed in a lower column 295 number than the artwork's maximum column value. 297 Additionally, an author may choose to indent the start of a 298 continuation line by inserting space characters before the line 299 continuation marker backslash character. 301 Manual folding may also help handle the cases that cannot be 302 automatically folded as described in Section 6. 304 6.2. Automated Unfolding 306 All unfolding is assumed to be automated although a reader will 307 mentally perform the act of unfolding the text to understand the true 308 nature of the artwork or source code. 310 Scan the beginning of the artwork for the header described in 311 Section 5.1. If the header is not present, starting on the first 312 line of the artwork, exit (this artwork does not need to be 313 unfolded). 315 Remove the 2-line header from the artwork. 317 For each line in the artwork, from top-to-bottom, if the line has a 318 backslash ('\') character immediately followed by the end of line 319 character sequence, and if the next line has a backslash ('\') 320 character as the first non-space (' ') character, then the lines can 321 be unfolded. Remove the first backslash ('\') character, the end of 322 line character sequence, any leading space (' ') characters, and the 323 second backslash ('\') character, which will bring up the next line. 324 Then continue to scan each line in the artwork starting with the 325 current line (in case it was multiply folded). 327 Continue in this manner until reaching the end of the artwork. 329 7. Considerations for xml2rfc v3 331 [RFC7991] introduces the vocabulary for version 3 of the xml2rfc 332 tool. This includes a new element, "" used to present 333 sourcecode examples and fragments and to distinguish them from 334 general artwork and in particular figures and graphics. 336 The folding and unfolding described in this document is applicable to 337 the "" element in both v2 and v3 of xml2rfc, and is equally 338 applicable to the "" element in xml2rfc v3. 340 8. Examples 342 The following self-documenting examples illustrate a folded document. 344 The source artwork cannot be presented here, as it would again need 345 to be folded. Alas, only the result can be provided. 347 The examples in Sections 8.1 through 8.4 were automatically folded on 348 column 69, the default value. Section 8.5 shows an example of manual 349 folding. 351 8.1. Simple Example Showing Boundary Conditions 353 This example illustrates a boundary condition test using numbers for 354 counting purposes. The input contains 5 lines, each line one 355 character longer than the previous. 357 Any printable character (including ' ' and '\') can be used as a 358 substitute for any number, except for on the 4th row, the trailing 359 '9' is not allowed to be a '\' character if the first non-space 360 character of the next line is a '\' character, as that would lead to 361 an ambiguous result. 363 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 365 123456789012345678901234567890123456789012345678901234567890123456 366 1234567890123456789012345678901234567890123456789012345678901234567 367 12345678901234567890123456789012345678901234567890123456789012345678 368 123456789012345678901234567890123456789012345678901234567890123456789 369 12345678901234567890123456789012345678901234567890123456789012345678\ 370 \90 371 12345678901234567890123456789012345678901234567890123456789012345678\ 372 \901 373 12345678901234567890123456789012345678901234567890123456789012345678\ 374 \9012 376 8.2. Example Showing Multiple Wraps of a Single Line 378 This example illustrates one very long line (280 characters). 380 Any printable character (including ' ' and '\') can be used as a 381 substitute for any number. 383 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 385 12345678901234567890123456789012345678901234567890123456789012345678\ 386 \9012345678901234567890123456789012345678901234567890123456789012345\ 387 \6789012345678901234567890123456789012345678901234567890123456789012\ 388 \3456789012345678901234567890123456789012345678901234567890123456789\ 389 \01234567890 391 8.3. Example With Native Backslash 393 This example has a '\' character in the wrapping column. The native 394 text includes the sequence "fish\fowl" with the '\' character 395 occurring on the 69th column. 397 string1="The quick brown dog jumps over the lazy dog which is a fish\ 398 \\fowl as appropriate" 400 8.4. Example With Native Whitespace 402 This example has whitespace spanning the wrapping column. The native 403 input contains 15 space (' ') characters between "like" and "white". 405 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 407 Sometimes our strings include multiple spaces such as "We like \ 408 \ white space." 410 8.5. Example of Manual Wrapping 412 This example was manually wrapped to cause the folding to occur after 413 each term, putting each term on its own line. Indentation is used to 414 additionally improve readability. Also note that the mandatory 415 header is surrounded by different printable characters than shown in 416 the other examples. 418 [NOTE: '\\' line wrapping per BCP XX (RFC XXXX)] 420 ::= \ 421 \ \ 422 \[] \ 423 \[] \ 424 \[] \ 425 \[[]] \ 426 \[] \ 427 \[] 429 The manual folding produces a more readable result than the following 430 equivalent folding that contains no indentation. 432 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 434 ::= [] [] [\ 435 \] [[]] [] [] 437 9. Security Considerations 439 This BCP has no Security Considerations. 441 10. IANA Considerations 443 This BCP has no IANA Considerations. 445 11. References 447 11.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 455 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 456 May 2017, . 458 11.2. Informative References 460 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 461 RFC 7950, DOI 10.17487/RFC7950, August 2016, 462 . 464 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 465 RFC 7991, DOI 10.17487/RFC7991, December 2016, 466 . 468 [RFC7994] Flanagan, H., "Requirements for Plain-Text RFCs", 469 RFC 7994, DOI 10.17487/RFC7994, December 2016, 470 . 472 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 473 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 474 . 476 [yang-doctors-thread] 477 "[yang-doctors] automating yang doctor reviews", 478 . 481 Appendix A. POSIX Shell Script 483 This non-normative appendix section includes a shell script that can 484 both fold and unfold artwork. 486 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 488 #!/bin/bash 490 print_usage() { 491 echo 492 echo "Folds the text file, only if needed, at the specified" 493 echo "column, according to BCP XX." 494 echo 495 echo "Usage: $0 [-c ] [-r] -i -o " 496 echo 497 echo " -c: column to fold on (default: 69)" 498 echo " -r: reverses the operation" 499 echo " -i: the input filename" 500 echo " -o: the output filename" 501 echo " -d: show debug messages" 502 echo " -h: show this message" 503 echo 504 echo "Exit status code: zero on success, non-zero otherwise." 505 echo 506 } 508 # global vars, do not edit 509 debug=0 510 reversed=0 511 infile="" 512 outfile="" 513 maxcol=69 # default, may be overridden by param 514 hdr_txt="NOTE: '\\\\' line wrapping per BCP XX (RFC XXXX)" 515 equal_chars="==============================================" 516 space_chars=" " 518 fold_it() { 519 # since upcomming tests are >= (not >) 520 testcol=`expr "$maxcol" + 1` 522 # check if file needs folding 523 grep ".\{$testcol\}" $infile >> /dev/null 2>&1 524 if [ $? -ne 0 ]; then 525 if [[ $debug -eq 1 ]]; then 526 echo "nothing to do" 527 fi 528 cp $infile $outfile 529 return -1 530 fi 532 foldcol=`expr "$maxcol" - 1` # for the inserted '\' char 534 # ensure input file doesn't contain a TAB 535 grep $'\t' $infile >> /dev/null 2>&1 536 if [ $? -eq 0 ]; then 537 echo 538 echo "Error: infile contains a TAB character, which is not allow\ 539 \ed." 540 echo 541 return 1 542 fi 544 # ensure input file doesn't contain the fold-sequence already 545 pcregrep -M "\\\\\n[\ ]*\\\\" $infile >> /dev/null 2>&1 546 if [ $? -eq 0 ]; then 547 echo 548 echo "Error: infile has a line ending with a '\' character follo\ 549 \wed" 550 echo " by '\' as the first non-space character on the next\ 551 \ line." 552 echo " This file cannot be folded." 553 echo 554 return 1 555 fi 557 # center header text 558 length=`expr ${#hdr_txt} + 2` 559 left_sp=`expr \( "$maxcol" - "$length" \) / 2` 560 right_sp=`expr "$maxcol" - "$length" - "$left_sp"` 561 header=`printf "%.*s %s %.*s" "$left_sp" "$equal_chars" "$hdr_txt"\ 562 \ "$right_sp" "$equal_chars"` 564 # fold using recursive passes ('g' didn't work) 565 if [ -z "$1" ]; then 566 # init recursive env 567 cp $infile /tmp/wip 568 fi 569 gsed "/.\{$testcol\}/s/\(.\{$foldcol\}\)/\1\\\\\n\\\\/" < /tmp/wip\ 570 \ >> /tmp/wip2 571 diff /tmp/wip /tmp/wip2 > /dev/null 2>&1 572 if [ $? -eq 1 ]; then 573 mv /tmp/wip2 /tmp/wip 574 fold_it "recursing" 575 else 576 echo "$header" > $outfile 577 echo "" >> $outfile 578 cat /tmp/wip2 >> $outfile 579 rm /tmp/wip* 580 fi 582 ## following two lines represent a non-functional variant to the r\ 583 \ecursive 584 ## logic presented in the block above. It used to work before the\ 585 \ '\' 586 ## on the next line was added to the format (i.e., the trailing '\\ 587 \\\\' 588 ## in the substitution below), but now there is an off-by-one erro\ 589 \r. 590 ## Leaving here in case anyone can fix it. 591 #echo "$header" > $outfile 592 #echo "" >> $outfile 593 #gsed "/.\{$testcol\}/s/\(.\{$foldcol\}\)/\1\\\\\n\\\\/g" < $infil\ 594 \e >> $outfile 596 return 0 597 } 599 unfold_it() { 600 # check if file needs unfolding 601 line=`head -n 1 $infile | fgrep "$hdr_txt"` 602 if [ $? -ne 0 ]; then 603 if [[ $debug -eq 1 ]]; then 604 echo "nothing to do" 605 fi 606 cp $infile $outfile 607 return -1 608 fi 610 # output all but the first two lines (the header) to wip (work in \ 611 \progress) file 612 awk "NR>2" $infile > /tmp/wip 614 # unfold wip file 615 gsed ":x; /.*\\\\\$/N; s/\\\\\n[ ]*\\\\//; tx; s/\t//g" /tmp/wip >\ 616 \ $outfile 618 # clean up and return 619 rm /tmp/wip 620 return 0 621 } 622 process_input() { 623 while [ "$1" != "" ]; do 624 if [ "$1" == "-h" -o "$1" == "--help" ]; then 625 print_usage 626 exit 1 627 fi 628 if [ "$1" == "-d" ]; then 629 debug=1 630 fi 631 if [ "$1" == "-c" ]; then 632 maxcol="$2" 633 shift 634 fi 635 if [ "$1" == "-r" ]; then 636 reversed=1 637 fi 638 if [ "$1" == "-i" ]; then 639 infile="$2" 640 shift 641 fi 642 if [ "$1" == "-o" ]; then 643 outfile="$2" 644 shift 645 fi 646 shift 647 done 649 if [ -z "$infile" ]; then 650 echo 651 echo "Error: infile parameter missing (use -h for help)" 652 echo 653 exit 1 654 fi 656 if [ -z "$outfile" ]; then 657 echo 658 echo "Error: outfile parameter missing (use -h for help)" 659 echo 660 exit 1 661 fi 663 if [ ! -f "$infile" ]; then 664 echo 665 echo "Error: specified file \"$infile\" is does not exist." 666 echo 667 exit 1 668 fi 669 min_supported=`expr ${#hdr_txt} + 8` 670 if [ $maxcol -lt $min_supported ]; then 671 echo 672 echo "Error: the folding column cannot be less than $min_support\ 673 \ed" 674 echo 675 exit 1 676 fi 678 max_supported=`expr ${#equal_chars} + 1 + ${#hdr_txt} + 1 + ${#equ\ 679 \al_chars}` 680 if [ $maxcol -gt $max_supported ]; then 681 echo 682 echo "Error: the folding column cannot be more than $max_support\ 683 \ed" 684 echo 685 exit 1 686 fi 688 } 690 main() { 691 if [ "$#" == "0" ]; then 692 print_usage 693 exit 1 694 fi 696 process_input $@ 698 if [[ $reversed -eq 0 ]]; then 699 fold_it 700 code=$? 701 else 702 unfold_it 703 code=$? 704 fi 705 exit $code 706 } 708 main "$@" 710 Acknowledgements 712 The authors thank the following folks for their various contributions 713 (sorted by first name): Gianmarco Bruno, Italo Busi, Jonathan 714 Hansford, Joel Jaeggli, Lou Berger, Martin Bjorklund, Italo Busi, and 715 Rob Wilton. 717 The authors additionally thank the RFC Editor for confirming that 718 there is no set convention today for handling long lines in artwork. 720 Authors' Addresses 722 Kent Watsen 723 Juniper Networks 725 EMail: kwatsen@juniper.net 727 Qin Wu 728 Huawei Technologies 730 EMail: bill.wu@huawei.com 732 Adrian Farrel 733 Old Dog Consulting 735 EMail: adrian@olddog.co.uk 737 Benoit Claise 738 Cisco Systems, Inc. 740 EMail: bclaise@cisco.com