idnits 2.17.1 draft-swindell-ptsc-hdr-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 14) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2000) is 8770 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual R. Swindell 2 Internet Draft Wind River Systems 3 Document: October 1999 4 Category: Informational Expires April 2000 6 Plain Text/Source Code File Header 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Copyright (C) The Internet Society 1999. All Rights Reserved. 33 1. Abstract 35 Anyone that has dealt at length with plain (ASCII [1]) text and 36 source code files can testify that the lack of a global definition 37 of the effect of the horizontal-tab character, all too often, causes 38 ill-formed display and printed output of plain text files that 39 utilize the horizontal-tab character for formatting. 41 This document defines a common header for plain text and source code 42 (PT/SC) files, whose primary purpose is to specify the tab-dependant 43 formatting parameters to be used when displaying, printing, or 44 editing such files. The defined header also addresses such issues 45 as whether to use the line-feed character or carriage-return/line- 46 feed character sequence to terminate lines in the file. Widespread 47 adoption and support of the header defined in this document could 48 substantially improve the interoperability of text and source code 49 files distributed across the Internet and other mediums. 51 Swindell [Page 1] Expires April 2000 52 1.1 Change Log 54 This section tracks changes made to the revisions of the Internet 55 Drafts of this document. It will be *deleted* when the document is 56 published as an RFC. 58 October 1, 1999: Revision 1 60 1: Introduced limitations on the location of headers within a file 61 (section 5). i.e. Headers must be located within the first 60 62 lines or 3000 characters of a file (whichever comes first) and 63 within the first 160 characters of an individual line. This 64 should simplify the parsing of large files (or files with 65 unusually long lines) and encourage the placement of headers 66 towards the top of files and beginning of lines for maximum 67 visibility. 69 2: Clarified the header syntax requirements in section 5. 70 Specifically, added paragraphs to detail the required white- 71 space, line-feed, or beginning-of-file that must immediately 72 precede a valid header token and the required white-space that 73 must immediately follow a valid variable name. Examples of 74 invalid headers that may be commonly mistaken for valid headers 75 (e.g. user@format.com) were added. 77 3: Section 4 now specifies that if a "programmer's editor" adds 78 PT/SC headers to a file and the file is determined to be a 79 source code file (possibly determined by the file's extension), 80 the editor must embed all headers in the comment delimiters of 81 the appropriate programming language for the file. 83 4: Added section 3.3, "Existing Proprietary Solutions". 85 5: Eliminated NOTE2 from section 5.1. This note was determined to 86 be a misleading and unnecessary suggestion. 88 6: Replaced the term "column" with "offset" in section 3. 90 7: Replaced the term "User" with "Name" in the tables contained in 91 section 3.1. 93 8: Replaced the term "document" with "file" in section 4. 95 9: Improved the consistency of the use of the terms "define" and 96 "specify" in regards to headers and format variables throughout 97 the document. i.e. Formatting variables are "defined", while 98 formatting variable values or parameters are "specified". 100 10: Section 5 now notes that formatting variables may be defined in 101 any order. 103 11: Copyright section was completed and miscellaneous typos were 104 fixed throughout the document. 106 Swindell [Page 2] Expires April 2000 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC 2119 [2]. 113 All numbers in this document a represented in decimal (base 10) 114 format unless otherwise noted. 116 3. Introduction 118 The tab key is typically used in plain (ASCII) text editors as a 119 fast and convenient way to align text on predetermined column 120 boundaries (tab-stops). Upon editing or creating a file, when the 121 tab key is pressed, the editor will usually place a horizontal-tab 122 (ASCII 9) character in the current insert position and move the 123 cursor forward to the next tab-stop position (i.e. indention). The 124 offset (tab-size) of each subsequent tab-stop is usually 125 configurable in the editor, though the default value of such a 126 parameter may be different from one editor to the next (typically in 127 the range of two to ten character positions). Additionally, some 128 editors allow asymmetric tab-stops (variable tab-size) where for 129 example, the first tab-stop may be at offset five and the second at 130 offset eight. 132 3.1 The Problem 134 The problem occurs when the file is printed, viewed, or loaded into 135 a different editor, or perhaps loaded into the same editor, but with 136 a different tab-size or tab-stop configuration. The resulting file 137 image may or may not resemble the original formatting of the file. 138 This is especially critical for the legibility of program and script 139 source code (C/C++, Java, HTML, etc.) files. 141 The problem is especially apparent in a multi-author environment, 142 where inevitably, different authors will have their editors and 143 other text processing applications configured with different tab- 144 dependent formatting parameters, resulting in what is affectionately 145 referred to as "tab-hell". 147 Example: Bob creates the following text file with his editor 148 configured with eight space (symmetric) tab-stops: 150 +-------+-------+-------+---------------+---------------+ 151 | Name | Meat | Dairy | Favorite Food | Favorite Band | 152 +-------+-------+-------+---------------+---------------+ 153 | Bob | No | Yes | Salad | Meat Loaf | 154 | Sally | Yes | No | Burrito | Cream | 155 | Mike | Yes | No | Pasta | Vanilla Fudge | 156 +-------+-------+-------+---------------+---------------+ 158 Swindell [Page 3] Expires April 2000 159 Julie would like to add herself to the table, so she loads the file 160 into her editor, which happens to be configured for two space tab- 161 stops (her preference). This is what Julie is presented with: 163 +-------+-------+-------+---------------+---------------+ 164 | Name | Meat | Dairy | Favorite Food | Favorite Band | 165 +-------+-------+-------+---------------+---------------+ 166 | Bob | No | Yes | Salad | Meat Loaf | 167 | Sally | Yes | No | Burrito | Cream | 168 | Mike | Yes | No | Pasta | Vanilla Fudge | 169 +-------+-------+-------+---------------+---------------+ 171 Confused, but determined, Julie adds herself to the table and prints 172 the file for the caterer and DJ of the upcoming company party: 174 +-------+-------+-------+---------------+---------------+ 175 | Name | Meat | Dairy | Favorite Food | Favorite Band | 176 +-------+-------+-------+---------------+---------------+ 177 | Bob | No | Yes | Salad | Meat Loaf | 178 | Sally | Yes | No | Burrito | Cream | 179 | Mike | Yes | No | Pasta | Vanilla Fudge | 180 | Julie | Yes | Yes | Milk | Roast Beef | 181 +-------+-------+-------+---------------+---------------+ 183 Needless to say, the party is a disaster: Bob's a vegetarian, Sally 184 and Mike are lactose intolerant, and the DJ brings only Modern Dance 185 music. 187 This is obviously an extreme hypothetical example. Typically, tab- 188 related formatting problems are more of an esthetics than a 189 logistics problem, but you get the idea. 191 NOTE: This document must be viewed or printed using a non- 192 proportional font for the above tables to appear as intended. 194 3.2 Existing Work-around 196 Many existing text editors offer the option of writing the 197 appropriate number of space (ASCII 32) characters to a file in place 198 of horizontal-tab characters. While such an option can be a 199 functional work-around to the problem for files created and 200 subsequently edited with an editor configured in this manner, it 201 does nothing to solve the problem of correctly displaying, printing, 202 or editing files that utilize horizontal-tab characters. 204 Subsequent editing of a file that uses spaces in place of 205 horizontal-tab characters may still adversely affect the formatting 206 of the file if the author utilizes the tab key for indention and 207 their editor is configured with different tab-stop parameters than 208 the original editor configuration. 210 Swindell [Page 4] Expires April 2000 211 Utilizing such an option also eliminates the possibility of 212 convenient indentation/column resizing by simply adjusting the tab- 213 stop configuration. Additionally, most editors allow quick cursor 214 movement through white-space in a file that utilizes the horizontal- 215 tab character (typically, one arrow-key press per tab-stop), while 216 white-space in files that use spaces in place of horizontal-tabs 217 must be navigated one character position at a time (e.g. eight 218 arrow-key presses per tab-stop). An increasingly minor 219 consideration is the fact that files (particularly source code 220 files) that replace horizontal-tab characters with spaces can 221 require as much as twenty percent more storage space than files that 222 utilize horizontal-tab characters. 224 3.3 Existing Proprietary Solutions 226 There are developers of plain text editors that have identified the 227 need for a solution to this problem and have addressed the problem 228 by allowing authors to define tab-stops and other formatting 229 parameters in the contents of their files. Unfortunately, all known 230 solutions have been implemented in a proprietary, incomplete, non- 231 extensible, or non-adoptable manner. For this reason, these 232 solutions are not often found in existing text or source code files 233 and are not expected to garner widespread use in the future. 235 3.4 Proposed Common Solution 237 While common computer users have migrated toward modern word 238 processors and their elaborate document formats, this problem, 239 although seemingly obscure, remains a thorn in the side of the 240 minority of users who must still deal with plain text files. 241 Ironically, the one group of computer users who are most affected by 242 this problem are programmers, the same ones who are in a position to 243 solve it by implementing a common solution. 245 The solution proposed in this document is a plain text/source code 246 (PT/SC) file header, whose primary purpose is to specify the tab- 247 dependant formatting parameters to be used when printing, 248 displaying, or editing such files. Other common text file 249 formatting issues (such as whether to use the line-feed character or 250 carriage-return/line-feed character sequence to terminate lines) are 251 also addressed in this header. 253 Swindell [Page 5] Expires April 2000 254 4. Application 256 It is hoped that a significant percentage of the developers of plain 257 text editors, specifically those designed for use by programmers, 258 will adopt this proposal. Adoption would include parsing any PT/SC 259 headers (if present) in files opened in the editor and setting the 260 formatting parameters accordingly and optionally, adding PT/SC 261 headers (if not already present) to files written to disk. 263 A supporting editor MUST update any PT/SC headers (if present) with 264 the current formatting parameters when a file is written to disk. A 265 supporting editor SHOULD allow the option of adding PT/SC headers to 266 a file (if not already present) with all relevant formatting 267 parameter values specified. 269 A supporting programmer's editor (an editor designed specifically 270 for use by programmers) MUST embed all PT/SC headers in the comment 271 delimiters of the appropriate language for the file. The 272 appropriate language may be determined by the file's extension (e.g. 273 ".c", ".pas", ".bas", etc.). 275 Text editors that support multiple concurrently opened files MUST 276 support a unique set of formatting parameters for each opened file. 277 Many editors already support a unique set of parameters based on the 278 extension (e.g. ".c", ".pas", ".txt") of the opened file. Such a 279 feature would need to be extended to set the appropriate formatting 280 parameters based on the values specified in any PT/SC headers 281 present. 283 Two-way support is defined as that of linking the PT/SC header 284 values and corresponding configuration menu options (if applicable) 285 such that a value changed in the file is reflected in the 286 configuration menu and vice versa. Two-way support is RECOMMENDED, 287 but not required. 289 It is also desirable that developers of applications designed to 290 view, print, or modify in anyway plain text or source code files 291 adopt this proposal. Such applications include (but are not limited 292 to) version control systems, file comparison utilities, syntax 293 verification utilities, source-level debuggers, and universal 294 document viewing and printing utilities. 296 Authors of plain text and source code files need not wait for PT/SC 297 header support in text editors. The simplicity of the PT/SC header 298 format allows authors to significantly help one another by at least 299 "documenting" the original formatting parameters by hand-coding the 300 PT/SC header so that other users and co-authors of such files need 301 not "guess" at the correct formatting parameters. And when 302 applications supporting the PT/SC header become available, existing 303 documents and source code files will immediately benefit from the 304 automatic adjustment of formatting parameters based on the pre- 305 existing PT/SC headers. 307 Swindell [Page 6] Expires April 2000 308 5. Header Format 310 @format. 312 Where is the beginning of the file (offset 0), is the 313 line-feed (ASCII 10) character, is one or more space 314 (ASCII 32) or horizontal-tab (ASCII 9) characters, is one 315 of the supported format variable names (see section 6), and 316 is one or more desired values (separated by white-space) in the 317 appropriate format for the corresponding variable. 319 Example: 321 This is MyFile.txt, @format.tab-size 8 323 A space character, horizontal-tab character, line-feed character, or 324 the beginning of the file MUST immediately precede the "@format." 325 header token. Additionally, a supported format variable name MUST 326 immediately follow the header token. For example, the text string 327 "user@format.com" SHALL NOT be interpreted as a valid PT/SC header 328 because it does not meet either of these requirements. 330 A space or horizontal-tab character MUST immediately follow a 331 supported format variable name (e.g. " @format.tab-size: 8" is not a 332 valid header). 334 The "@format." header token and the supported format variable names 335 SHALL NOT be case sensitive (e.g. "@FoRmAt." is a valid header 336 token). 338 Decimal numeric values SHALL NOT be zero-padded (e.g. "08" is an 339 invalid decimal value). Hexadecimal numeric values MAY be zero- 340 padded (e.g. "0x08" is a valid hexadecimal value). 342 PT/SC headers MUST appear within the first 60 lines or 3000 343 characters of a file (whichever comes first) and they SHOULD be 344 located as close to the beginning of the file as possible (hence the 345 use of the term "header"). 347 PT/SC headers MUST appear within the first 160 characters of an 348 individual line and, when possible, SHOULD appear within the first 349 80 characters for maximum visibility. 351 It is RECOMMENDED that no horizontal-tab characters precede the 352 definition of any tab-related variables (if present) and no end-of- 353 line characters or character sequences precede the definition of the 354 new-line variable (if present). If, for example, horizontal-tab 355 characters precede the definition of the tab-size or tab-stops 356 variables, they may not be expanded correctly if the file is 357 processed in a single pass (e.g. first line read, processed, 358 printed, next line read, processed, printed, etc.). 360 Swindell [Page 7] Expires April 2000 361 Multiple formatting variables may be defined by including multiple 362 headers. Multiple headers may be included in any order. Multiple 363 headers may be included on a single line: 365 This is MyFile.txt, @format.tab-size 8, @format.new-line crlf 367 or multiple lines: 369 This is MyFile.txt, @format.new-line crlf 370 @format.tab-size 8 372 Format variables SHOULD NOT be multiply defined. If a format 373 variable is defined more than once in a file (e.g. this document), 374 only the first occurrence SHALL be interpreted as valid. 376 5.1 Headers in Source Code Files 378 PT/SC headers may be embedded in program or script source code files 379 by including the header in the comment delimiters of the appropriate 380 language for the file. 382 Examples: 384 /* MyProgram.c, @format.tab-size 4 */ 386 // MyProgram.cpp, @format.tab-size 3 387 // @format.use-tabs true 389 391 REM MyProgram.bas, @format.tab-size 8 393 { MyProgram.pas, @format.tab-size 4 } 395 ; MyProgram.asm, @format.tab-size 4 397 # MyProgram.mak, @format.tab-size 4 399 /** 400 * MyProgram.java, JavaDoc comment 401 * @author R. R. Swindell 402 * @version 1.00 403 * @format.tab-size 4 404 * @format.use-tabs true 405 */ 407 Since the comment delimiters are not part of the header format, 408 PT/SC headers are not restricted to a specific set of programming or 409 scripting languages and should remain compatible with any future 410 languages provided they allow for free-form in-line comments. 412 Swindell [Page 8] Expires April 2000 413 NOTE: PT/SC headers in source code files define formatting 414 parameters for the display, editing, or printing of the source code 415 itself and not the output of the resulting program or script. 416 Although certain languages (e.g. HTML) could benefit from a 417 standardized method of specifying formatting parameters for output 418 (specifically tab-size/tab-stops), such a definition is beyond the 419 scope of this document. 421 6. Format Variables 423 Supported PT/SC Format Variables: 425 tab-size 426 tab-stops 427 indent-size 428 line-length 429 new-line 430 use-tabs 432 If any of the supported format variables are not defined by a PT/SC 433 header in a file, the value of the corresponding format parameter 434 (if supported by the application) SHALL be left in its default or 435 user-configured state unless otherwise noted. 437 NOTE: Format variable names SHALL NOT be case sensitive (i.e. "tab- 438 size" and "TAB-Size" are both valid format variable names). 440 6.1 tab-size 442 The variable was the initial inspiration for the PT/SC 443 header and remains its primary purpose. The variable is 444 used to specify the symmetric offset of each tab-stop in the file 445 (in non-proportional character widths). 447 Syntax: @format.tab-size 449 Where is a positive decimal (base 10) number in the 450 range of 1 to 60. 452 Example: @format.tab-size 4 454 Would result in tab-stops at offsets (from the beginning of 455 each line) of 4, 8, 12, 16, 20, 24, etc. 457 If asymmetric tab-stops are supported by the application and the 458 variable is defined, the application SHALL ignore any 459 definition of the variable and use the values specified 460 for the variable instead. 462 Swindell [Page 9] Expires April 2000 463 6.2 tab-stops 465 The variable is to be used in files that utilize 466 asymmetric tab-stops. The variable MAY still be defined 467 as a back up in the case of applications that do not support 468 asymmetric tab-stops. 470 Syntax: @format.tab-stops... 472 Where each is a positive decimal (base 10) number in 473 the range of 1 to 255, increasing in order (e.g. 4 8 10). A 474 minimum of two (2) values MUST be specified. A maximum of 475 forty (40) values may be specified. All values MUST be 476 separated by white-space. 478 Any tab-stops on a line beyond the offset of the last specified tab- 479 stop MUST be interpreted as symmetric tab-stops with the width 480 determined by the difference of the last two (2) specified tab- 481 stops. 483 Example: @format.tab-stops 4 8 10 485 Would result in tab-stops at offsets (from the beginning of 486 each line) of 4, 8, 10, 12, 14, 16, 18, etc. 488 If all tab-stops are symmetric, this variable MUST NOT be defined 489 and the variable MUST be defined instead. 491 6.3 indent-size 493 The variable is used in cases where the editor 494 supports an indent-size configuration option and it has been 495 configured with a value different than the configured tab-size. The 496 variable is used to specify the symmetric offset of 497 each indent-stop in the file (in non-proportional character widths). 498 Indent-stops are very similar to symmetric tab-stops, except that 499 they are used only in the editing of the file; they are not used in 500 the display or printing of the file. If the variable 501 is defined and the editor is configured to use horizontal-tab 502 characters, it MUST use a combination of horizontal-tab and space 503 characters to indent the proper number of character positions when 504 the tab key is pressed. If the editor supports an indent-size 505 configuration option, but the variable has not been 506 defined and the variable has, the indent-size option 507 shall be set to the value specified for the variable. 509 Syntax: @format.indent-size 511 Where is a positive decimal (base 10) number in range 512 of 1 to 60. 514 Example: @format.ident-size 4 516 Swindell [Page 10] Expires April 2000 517 6.4 line-length 519 The variable is used to specify the maximum allowable 520 individual line length (excluding any end-of-line character 521 sequences). It is used in cases where the editor has been 522 configured to enforce a right-hand margin. In cases where the 523 editor does not support a right-hand margin, this variable may be 524 defined in a header by the author to notify the file's co-authors of 525 the desired maximum line length. 527 Syntax: @format.line-length 529 Where is a positive decimal (base 10) number in the 530 range of 1 to 255. 532 Example: @format.line-length 79 534 6.5 new-line 536 The variable is used to specify the character sequence 537 that signifies the end-of-line. This character sequence will be 538 used to determine the end of each line when the file is read and to 539 terminate individual lines when the file is printed or written to 540 disk. 542 Syntax: @format.new-line 544 Where is one or more decimal (base 10) numbers in the 545 range of 0 to 255 or hexadecimal (base 16) numbers (signified 546 by a "0x" prefix) in the range of 0x00 to 0xff. A maximum of 547 forty (40) values may be specified. If multiple numeric values 548 are specified, they MUST be separated by white-space. 550 The keywords "CR" and "LF" may also be used in place of a 551 numeric value to signify the carriage-return (ASCII 13) and 552 line-feed (ASCII 10) characters respectively. If the "CR" and 553 "LF" keywords are used, they need not be separated by white- 554 space. The keywords are not case sensitive. 556 Example: @format.new-line lf 558 Would result in lines being terminated by the ASCII line-feed 559 character upon input or output. 561 Example: @format.new-line crlf 563 Would result in lines being terminated by the ASCII carriage- 564 return/line-feed character sequence upon input or output. 566 Swindell [Page 11] Expires April 2000 567 6.6 use-tabs 569 The variable is used to specify whether the editor was 570 configured to write horizontal-tab (ASCII 9) characters to the file 571 or use the appropriate number of space (ASCII 32) characters in 572 place of each horizontal-tab character (see section 3.2). 574 Syntax: @format.use-tabs 576 Where is one of the following keywords (without 577 quotes): "TRUE", "FALSE", "ON", "OFF", "YES", or "NO". 579 The keywords "TRUE", "ON", and "YES" specify that horizontal- 580 tab characters are to be written to the file. The keywords 581 "FALSE", "OFF", and "NO" specify that the appropriate number of 582 space characters are to be used in place of each horizontal-tab 583 character when the file is read from or written to disk. The 584 keywords are not case sensitive. 586 Example: @format.use-tabs true 588 7. Formal Syntax 590 The following syntax specification uses the augmented Backus-Naur 591 Form (BNF) and Core Rules as described in RFC 2234 [3]. 593 file = [header] *(*CHAR [escape header]) 595 header = "@format." variable values 597 escape = WSP / LF 599 variable = "tab-size" / "tab-stops" / "indent-size" / 600 "line-length" / "new-line" / "use-tabs" 602 values = 1*40((1*WSP) value) 604 value = numeric / keyword 606 numeric = 1*3DIGIT / ("0x" 1*2HEXDIG) 608 keyword = "true" / "false" / "on" / "off" / "yes" / "no" / 609 "cr" / "lf" 611 8. Security Considerations 613 There are no known security issues with the solution proposed in 614 this document. 616 Swindell [Page 12] Expires April 2000 617 9. References 619 [1] ANSI X3.4-1986, "US-ASCII Coded Character Set--7-Bit American 620 Standard Code for Information Interchange". 622 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 623 Levels", BCP 14, RFC 2119, March 1997. 625 [3] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 626 RFC 2234, November 1997. 628 10. Author's Addresses 630 Robert R. Swindell 631 Wind River Systems, Inc. 632 3961 MacArthur Blvd., Suite 212 633 Newport Beach, CA 92660 634 United States of America 636 Email: swindell@windriver.com 638 Swindell [Page 13] Expires April 2000 639 Full Copyright Statement 641 "Copyright (C) The Internet Society 1999. All Rights Reserved. 642 This document and translations of it may be copied and furnished to 643 others, and derivative works that comment on or otherwise explain it 644 or assist in its implementation may be prepared, copied, published 645 and distributed, in whole or in part, without restriction of any 646 kind, provided that the above copyright notice and this paragraph 647 are included on all such copies and derivative works. However, this 648 document itself may not be modified in any way, such as by removing 649 the copyright notice or references to the Internet Society or other 650 Internet organizations, except as needed for the purpose of 651 developing Internet standards in which case the procedures for 652 copyrights defined in the Internet Standards process must be 653 followed, or as required to translate it into languages other than 654 English. 656 The limited permissions granted above are perpetual and will not be 657 revoked by the Internet Society or its successors or assigns. 659 This document and the information contained herein is provided on 660 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Swindell [Page 14] Expires April 2000