idnits 2.17.1 draft-kwatsen-netmod-artwork-folding-07.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 (September 5, 2018) is 2059 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 486, 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: March 9, 2019 Huawei Technologies 6 A. Farrel 7 Juniper Networks 8 B. Claise 9 Cisco Systems, Inc. 10 September 5, 2018 12 Handling Long Lines in Artwork in Internet-Drafts and RFCs 13 draft-kwatsen-netmod-artwork-folding-07 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 March 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 . . . . . . . . . . . . . . . . . . . 6 74 6.2. Automated Unfolding . . . . . . . . . . . . . . . . . . . 7 75 7. Considerations for xml2rfc v3 . . . . . . . . . . . . . . . . 7 76 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Simple Example Showing Boundary Conditions . . . . . . . 8 78 8.2. Example Showing Multiple Wraps of a Single Line . . . . . 8 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 . . . . . . . . . . . . . . . . . 11 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 [RFC7994][RFC7994]sets out the requirements for plain-text RFCs and 94 states that each line of an RFC (and hence of an Internet-Draft) must 95 be 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 clearly indicating that some manipulation has 107 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 YANG, XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output 138 (e.g., tree diagrams) that are stitched into the final document to be 139 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 modules are 158 already extracted from Internet-Drafts and validated as part of the 159 draft-submission process. Additionally, there has been some 160 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 (YANG, XML, JSON, etc.) or, more generally, on artwork 172 that has 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. Artwork that is somewhat structured (e.g., YANG tree 178 diagrams [RFC8340]) fairs better when folded, as the eyes seem to be 179 able to still see the vertical lines, even when they are interrupted. 181 It is NOT RECOMMENDED to use the solution presented in this document 182 on graphical artwork. 184 4.2. Doesn't Work as Well as Format-Specific Options 186 The solution presented in this document works generically for all 187 artwork, as it only views artwork as plain text. However, various 188 formats sometimes have built-in mechanisms that can be used to 189 prevent long lines. 191 For instance, some source formats allow any quoted string to be 192 broken up into substrings separated by a concatenation character 193 ('+'), any of which can by on a different line. 195 In another example, some languages allow factoring chunks of code 196 into call outs, such as functions. Using such call outs is 197 especially helpful when in some deeply-nested code, as they typically 198 reset the indentation back to the first column. 200 As such, it is RECOMMENDED that authors do as much as possible within 201 the selected format to avoid long lines. 203 5. Folded Structure 205 Artwork that has been folded as specified by this document MUST 206 contain the following structure. 208 5.1. Header 210 The header is two lines long. 212 The first line is the following 46-character string that MAY be 213 surrounded by any number of printable characters. This first line 214 cannot itself be folded. 216 NOTE: '\\' line wrapping per BCP XX (RFC XXXX) 218 [Note to RFC Editor: Please replace XX and XXXX with the numbers 219 assigned to this document and delete this note. Please make this 220 change in multiple places in this document.] 222 The second line is a blank line. This line provides visual 223 separation for readability. 225 5.2. Body 227 The character encoding is the same as described in Section 2 of 228 [RFC7994], except that, per [RFC7991], tab characters are prohibited. 230 Lines that have a backslash ('\') occurring as the last character in 231 a line immediately followed by the end of line character sequence, 232 when the subsequent line starts with a backslash ('\') as the first 233 non-space (' ') character, are considered "folded". 235 Really long lines may be folded multiple times. 237 6. Algorithm 239 6.1. Automated Folding 241 Determine the desired maximum line length from input. If no value is 242 explicitly specified, the value "69" SHOULD be used. 244 Ensure that the desired maximum line length is not less than the 245 minimum header, which is 46 characters. If the desired maximum line 246 length is less than this minimum, exit (this artwork can not be 247 folded). 249 Scan the artwork to see if any line exceeds the desired maximum. If 250 no line exceeds the desired maximum, exit (this artwork does not need 251 to be folded). 253 Scan the artwork to ensure the horizontal tab character does not 254 appear. If any horizontal tab character appears, exit (this artwork 255 cannot be folded). 257 Scan the artwork to ensure no existing lines already end with a 258 backslash ('\') character when the subsequent line starts with a 259 backslash ('\') character as the first non-space (' ') character, as 260 this would lead to an ambiguous result. If such a line is found, 261 exit (this artwork cannot be folded). 263 For each line in the artwork, from top-to-bottom, if the line exceeds 264 the desired maximum, then fold the line at the desired maximum column 265 by 1) inserting the character backslash ('\') character at the 266 maximum column, 2) inserting the end of line character sequence, 267 inserting any number of space (' ') characters, and 4) inserting a 268 further backslash ('\') character. 270 The result of this previous operation is that the next line starts 271 with an arbitrary number of space (' ') characters, followed by a 272 backslash ('\') character, immediately followed by the character that 273 was previously in the maximum column. 275 Continue in this manner until reaching the end of the artwork. Note 276 that this algorithm naturally addresses the case where the remainder 277 of a folded line is still longer than the desired maximum, and hence 278 needs to be folded again, ad infinitum. 280 6.1.1. Manual Folding 282 Authors may choose to fold text examples and source code by hand to 283 produce a document that is more pleasant for a human reader but which 284 can still be automatically unfolded (as described in Section 6.2) to 285 produce single lines that are longer than the maximum document line 286 length. 288 For example, an author may choose to make the fold at convenient gaps 289 between words such that the backslash is placed in a lower column 290 number than the artwork's maximum column value. 292 Additionally, an author may choose to indent the start of a 293 continuation line by inserting space characters before the line 294 continuation marker backslash character. 296 Manual folding may also help handle the cases that cannot be 297 automatically folded as described in Section 6. 299 6.2. Automated Unfolding 301 All unfolding is assumed to be automated although a reader will 302 mentally perform the act of unfolding the text to understand the true 303 nature of the artwork or source code. 305 Scan the beginning of the artwork for the header described in 306 Section 5.1. If the header is not present, starting on the first 307 line of the artwork, exit (this artwork does not need to be 308 unfolded). 310 Remove the 2-line header from the artwork. 312 For each line in the artwork, from top-to-bottom, if the line has a 313 backslash ('\') character immediately followed by the end of line 314 character sequence, and if the next line has a backslash ('\') 315 character as the first non-space (' ') character, then the lines can 316 be unfolded. Remove the first backslash ('\') character, the end of 317 line character sequence, any leading space (' ') characters, and the 318 second backslash ('\') character, which will bring up the next line. 319 Then continue to scan each line in the artwork starting with the 320 current line (in case it was multiply folded). 322 Continue in this manner until reaching the end of the artwork. 324 7. Considerations for xml2rfc v3 326 [RFC7991] introduces the vocabulary for version 3 of the xml2rfc 327 tool. This includes a new element, "" used to present 328 sourcecode examples and fragments and to distinguish them from 329 general artwork and in particular figures and graphics. 331 The folding and unfolding described in this document is applicable to 332 the "" element in both v2 and v3 of xml2rfc, and is equally 333 applicable to the "" element in xml2rfc v3. 335 8. Examples 337 The following self-documenting examples illustrate a folded document. 339 The source artwork cannot be presented here, as it would again need 340 to be folded. Alas, only the result can be provided. 342 The examples in Sections 8.1 through 8.4 were automatically folded on 343 column 69, the default value. Section 8.5 shows an example of manual 344 folding. 346 8.1. Simple Example Showing Boundary Conditions 348 This example illustrates a boundary condition test using numbers for 349 counting purposes. The input contains 5 lines, each line one 350 character longer than the previous. 352 Any printable character (including ' ' and '\') can be used as a 353 substitute for any number, except for on the 4th row, the trailing 354 '9' is not allowed to be a '\' character if the first non-space 355 character of the next line is a '\' character, as that would lead to 356 an ambiguous result. 358 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 360 123456789012345678901234567890123456789012345678901234567890123456 361 1234567890123456789012345678901234567890123456789012345678901234567 362 12345678901234567890123456789012345678901234567890123456789012345678 363 123456789012345678901234567890123456789012345678901234567890123456789 364 12345678901234567890123456789012345678901234567890123456789012345678\ 365 \90 366 12345678901234567890123456789012345678901234567890123456789012345678\ 367 \901 368 12345678901234567890123456789012345678901234567890123456789012345678\ 369 \9012 371 8.2. Example Showing Multiple Wraps of a Single Line 373 This example illustrates one very long line (280 characters). 375 Any printable character (including ' ' and '\') can be used as a 376 substitute for any number. 378 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 380 12345678901234567890123456789012345678901234567890123456789012345678\ 381 \9012345678901234567890123456789012345678901234567890123456789012345\ 382 \6789012345678901234567890123456789012345678901234567890123456789012\ 383 \3456789012345678901234567890123456789012345678901234567890123456789\ 384 \01234567890 386 8.3. Example With Native Backslash 388 This example has a '\' character in the wrapping column. The native 389 text includes the sequence "fish\fowl" with the '\' character 390 occurring on the 69th column. 392 string1="The quick brown dog jumps over the lazy dog which is a fish\ 393 \\fowl as appropriate" 395 8.4. Example With Native Whitespace 397 This example has whitespace spanning the wrapping column. The native 398 input contains 15 space (' ') characters between "like" and "white". 400 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 402 Sometimes our strings include multiple spaces such as "We like \ 403 \ white space." 405 8.5. Example of Manual Wrapping 407 This example was manually wrapped to cause the folding to occur after 408 each term, putting each term on its own line. Indentation is used to 409 additionally improve readability. Also note that the mandatory 410 header is surrounded by different printable characters than shown in 411 the other examples. 413 [NOTE: '\\' line wrapping per BCP XX (RFC XXXX)] 415 ::= \ 416 \ \ 417 \[] \ 418 \[] \ 419 \[] \ 420 \[[]] \ 421 \[] \ 422 \[] 424 The manual folding produces a more readable result than the following 425 equivalent folding that contains no indentation. 427 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 429 ::= [] [] [\ 430 \] [[]] [] [] 432 9. Security Considerations 434 This BCP has no Security Considerations. 436 10. IANA Considerations 438 This BCP has no IANA Considerations. 440 11. References 442 11.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 450 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 451 May 2017, . 453 11.2. Informative References 455 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 456 RFC 7991, DOI 10.17487/RFC7991, December 2016, 457 . 459 [RFC7994] Flanagan, H., "Requirements for Plain-Text RFCs", 460 RFC 7994, DOI 10.17487/RFC7994, December 2016, 461 . 463 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 464 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 465 . 467 [yang-doctors-thread] 468 "[yang-doctors] automating yang doctor reviews", 469 . 472 Appendix A. POSIX Shell Script 474 This non-normative appendix section includes a shell script that can 475 both fold and unfold artwork. 477 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 479 #!/bin/bash 481 print_usage() { 482 echo 483 echo "Folds the text file, only if needed, at the specified" 484 echo "column, according to BCP XX." 485 echo 486 echo "Usage: $0 [-c ] [-r] -i -o " 487 echo 488 echo " -c: column to fold on (default: 69)" 489 echo " -r: reverses the operation" 490 echo " -i: the input filename" 491 echo " -o: the output filename" 492 echo " -d: show debug messages" 493 echo " -h: show this message" 494 echo 495 echo "Exit status code: zero on success, non-zero otherwise." 496 echo 497 } 499 # global vars, do not edit 500 debug=0 501 reversed=0 502 infile="" 503 outfile="" 504 maxcol=69 # default, may be overridden by param 505 hdr_txt="NOTE: '\\\\' line wrapping per BCP XX (RFC XXXX)" 506 equal_chars="==============================================" 507 space_chars=" " 509 fold_it() { 510 # since upcomming tests are >= (not >) 511 testcol=`expr "$maxcol" + 1` 513 # check if file needs folding 514 grep ".\{$testcol\}" $infile >> /dev/null 2>&1 515 if [ $? -ne 0 ]; then 516 if [[ $debug -eq 1 ]]; then 517 echo "nothing to do" 518 fi 519 cp $infile $outfile 520 return -1 521 fi 523 foldcol=`expr "$maxcol" - 1` # for the inserted '\' char 525 # ensure input file doesn't contain a TAB 526 grep "\t" $infile >> /dev/null 2>&1 527 if [ $? -eq 0 ]; then 528 echo 529 echo "Error: infile contains a TAB character, which is not allow\ 530 \ed." 531 echo 532 return 1 533 fi 535 # ensure input file doesn't contain the fold-sequence already 536 pcregrep -M "\\\\\n[\ ]*\\\\" $infile >> /dev/null 2>&1 537 if [ $? -eq 0 ]; then 538 echo 539 echo "Error: infile has a line ending with a '\' character follo\ 540 \wed" 541 echo " by '\' as the first non-space character on the next\ 542 \ line." 543 echo " This file cannot be folded." 544 echo 545 return 1 546 fi 548 # center header text 549 length=`expr ${#hdr_txt} + 2` 550 left_sp=`expr \( "$maxcol" - "$length" \) / 2` 551 right_sp=`expr "$maxcol" - "$length" - "$left_sp"` 552 header=`printf "%.*s %s %.*s" "$left_sp" "$equal_chars" "$hdr_txt"\ 553 \ "$right_sp" "$equal_chars"` 555 # fold using recursive passes ('g' didn't work) 556 if [ -z "$1" ]; then 557 # init recursive env 558 cp $infile /tmp/wip 559 fi 560 gsed "/.\{$testcol\}/s/\(.\{$foldcol\}\)/\1\\\\\n\\\\/" < /tmp/wip\ 561 \ >> /tmp/wip2 562 diff /tmp/wip /tmp/wip2 > /dev/null 2>&1 563 if [ $? -eq 1 ]; then 564 mv /tmp/wip2 /tmp/wip 565 fold_it "recursing" 566 else 567 echo "$header" > $outfile 568 echo "" >> $outfile 569 cat /tmp/wip2 >> $outfile 570 rm /tmp/wip* 571 fi 573 ## following two lines represent a non-functional variant to the r\ 574 \ecursive 575 ## logic presented in the block above. It used to work before the\ 576 \ '\' 577 ## on the next line was added to the format (i.e., the trailing '\\ 578 \\\\' 579 ## in the substitution below), but now there is an off-by-one erro\ 580 \r. 581 ## Leaving here in case anyone can fix it. 582 #echo "$header" > $outfile 583 #echo "" >> $outfile 584 #gsed "/.\{$testcol\}/s/\(.\{$foldcol\}\)/\1\\\\\n\\\\/g" < $infil\ 585 \e >> $outfile 587 return 0 588 } 590 unfold_it() { 591 # check if file needs unfolding 592 line=`head -n 1 $infile | fgrep "$hdr_txt"` 593 if [ $? -ne 0 ]; then 594 if [[ $debug -eq 1 ]]; then 595 echo "nothing to do" 596 fi 597 cp $infile $outfile 598 return -1 599 fi 601 # output all but the first two lines (the header) to wip (work in \ 602 \progress) file 603 awk "NR>2" $infile > /tmp/wip 605 # unfold wip file 606 gsed ":x; /.*\\\\\$/N; s/\\\\\n[ ]*\\\\//; tx; s/\t//g" /tmp/wip >\ 607 \ $outfile 609 # clean up and return 610 rm /tmp/wip 611 return 0 612 } 613 process_input() { 614 while [ "$1" != "" ]; do 615 if [ "$1" == "-h" -o "$1" == "--help" ]; then 616 print_usage 617 exit 1 618 fi 619 if [ "$1" == "-d" ]; then 620 debug=1 621 fi 622 if [ "$1" == "-c" ]; then 623 maxcol="$2" 624 shift 625 fi 626 if [ "$1" == "-r" ]; then 627 reversed=1 628 fi 629 if [ "$1" == "-i" ]; then 630 infile="$2" 631 shift 632 fi 633 if [ "$1" == "-o" ]; then 634 outfile="$2" 635 shift 636 fi 637 shift 638 done 640 if [ -z "$infile" ]; then 641 echo 642 echo "Error: infile parameter missing (use -h for help)" 643 echo 644 exit 1 645 fi 647 if [ -z "$outfile" ]; then 648 echo 649 echo "Error: outfile parameter missing (use -h for help)" 650 echo 651 exit 1 652 fi 654 if [ ! -f "$infile" ]; then 655 echo 656 echo "Error: specified file \"$infile\" is does not exist." 657 echo 658 exit 1 659 fi 660 min_supported=`expr ${#hdr_txt} + 8` 661 if [ $maxcol -lt $min_supported ]; then 662 echo 663 echo "Error: the folding column cannot be less than $min_support\ 664 \ed" 665 echo 666 exit 1 667 fi 669 max_supported=`expr ${#equal_chars} + 1 + ${#hdr_txt} + 1 + ${#equ\ 670 \al_chars}` 671 if [ $maxcol -gt $max_supported ]; then 672 echo 673 echo "Error: the folding column cannot be more than $max_support\ 674 \ed" 675 echo 676 exit 1 677 fi 679 } 681 main() { 682 if [ "$#" == "0" ]; then 683 print_usage 684 exit 1 685 fi 687 process_input $@ 689 if [[ $reversed -eq 0 ]]; then 690 fold_it 691 code=$? 692 else 693 unfold_it 694 code=$? 695 fi 696 exit $code 697 } 699 main "$@" 701 Acknowledgements 703 The authors thank the following folks for their various contributions 704 (sorted by first name): Jonathan Hansford, Joel Jaeggli, Lou Berger, 705 Martin Bjorklund, Italo Busi, and Rob Wilton. 707 The authors additionally thank the RFC Editor, for confirming that 708 there is no set convention today for handling long lines in artwork. 710 Authors' Addresses 712 Kent Watsen 713 Juniper Networks 715 EMail: kwatsen@juniper.net 717 Qin Wu 718 Huawei Technologies 720 EMail: bill.wu@huawei.com 722 Adrian Farrel 723 Juniper Networks 725 EMail: afarrel@juniper.net 727 Benoit Claise 728 Cisco Systems, Inc. 730 EMail: bclaise@cisco.com