From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1543.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc1543.txt (limited to 'doc/rfc/rfc1543.txt') diff --git a/doc/rfc/rfc1543.txt b/doc/rfc/rfc1543.txt new file mode 100644 index 0000000..2d9b094 --- /dev/null +++ b/doc/rfc/rfc1543.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group J. Postel +Request for Comments: 1543 ISI +Obsoletes: RFCs 1111, 825 October 1993 +Category: Informational + + + Instructions to RFC Authors + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 + 2. Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3a. ASCII Format Rules . . . . . . . . . . . . . . . . . . . . 4 + 3b. PostScript Format Rules . . . . . . . . . . . . . . . . . . 5 + 4. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4a. First Page Heading . . . . . . . . . . . . . . . . . . . . 6 + 4b. Running Header . . . . . . . . . . . . . . . . . . . . . . 7 + 4c. Running Footer . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Status Section . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Introduction Section . . . . . . . . . . . . . . . . . . . . 8 + 7. References Section . . . . . . . . . . . . . . . . . . . . . 9 + 8. Security Considerations Section . . . . . . . . . . . . . 10 + 9. Author's Address Section . . . . . . . . . . . . . . . . . 10 + 10. Relation to other RFCs . . . . . . . . . . . . . . . . . . 10 + 11. Protocol Standards Process . . . . . . . . . . . . . . . . 11 + 12. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 13. Distribution Lists . . . . . . . . . . . . . . . . . . . . 11 + 14. RFC Index . . . . . . . . . . . . . . . . . . . . . . . . 12 + 15. Security Considerations . . . . . . . . . . . . . . . . . 12 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . 12 + 17. Author's Address . . . . . . . . . . . . . . . . . . . . . 12 + 18. Appendix - RFC "nroff macros" . . . . . . . . . . . . . . 13 + +1. Introduction + + This Request for Comments (RFC) provides information about the + preparation of RFCs, and certain policies relating to the publication + of RFCs. + + The RFC series of notes covers a broad range of interests. The core + topics are the Internet and the TCP/IP protocol suite. However, any + + + +Postel [Page 1] + +RFC 1543 Instructions to RFC Authors October 1993 + + + topic related to computer communication may be acceptable at the + discretion of the RFC Editor. + + Memos proposed to be RFCs may be submitted by anyone. One large + source of memos that become RFCs is the Internet Engineering Task + Force (IETF). The IETF working groups (WGs) evolve their working + memos (known as Internet Drafts or I-Ds) until they feel they are + ready for publication, then the memos are reviewed by the Internet + Engineering Steering Group (IESG), and if approved sent by the IESG + to the RFC Editor. + + RFCs are distributed online by being stored as public access files, + and a short message is sent to the distribution list indicating the + availability of the memo. + + The online files are copied by the interested people and printed or + displayed at their site on their equipment. This means that the + format of the online files must meet the constraints of a wide + variety of printing and display equipment. (RFCs may also be + returned via e-mail in response to an e-mail query, or RFCs may be + found using information and database searching tools such as Gopher, + Wais, WWW, or Mosaic.) + + RFCs have been traditionally published and continue to be published + in ASCII text. + + While the primary RFCs is always an ASCII text file, secondary or + alternative versions of RFC may be provided in PostScript. This + decision is motivated by the desire to include diagrams, drawings, + and such in RFCs. PostScript documents (on paper only, so far) are + visually more appealing and have better readability. + + PostScript was chosen for the fancy form of RFC publication over + other possible systems (e.g., impress, interpress, oda) because of + the perceived wide spread availability of PostScript capable + printers. + + However, many RFC users read the documents online and use various + text oriented tools (e.g., emacs, grep) to search them. Often, brief + excerpts from RFCs are included in e-mail. These practices are not + yet practical with PostScript files. + + PostScript producing systems are less standard than had been assumed + and that several of the document production systems that claim to + produce PostScript actually produce nonstandard results. + + In the future, it may be necessary to identify a set of document + production systems authorized for use in production of PostScript + + + +Postel [Page 2] + +RFC 1543 Instructions to RFC Authors October 1993 + + + RFCs, based on the reasonableness of the output files they generate. + +2. Editorial Policy + + Documents proposed to be RFCs are reviewed by the RFC Editor and + possibly by other reviewers he selects. + + The result of the review may be to suggest to the author some + improvements to the document before publication. + + Occasionally, it may become apparent that the topic of a proposed RFC + is also the subject of an IETF Working Group, and that the author + could coordinate with the working group to the advantage of both. + The usual result of this is that a revised memo is produced as a + working group Internet Draft and eventually emerges from the IETF + process as a recommendation from the IESG to the RFC Editor. + + In some cases it may be determined that the submitted document is not + appropriate material to be published as an RFC. + + In some cases it may be necessary to include in the document a + statement based on the reviews about the ideas in the document. This + may be done in the case that the document suggests relevant but + inappropriate or unsafe ideas, and other situations. + + The RFC Editor may make minor changes to the document, especially in + the areas of style and format, but on some occasions also to the + text. Sometimes the RFC Editor will undertake to make more + significant changes, especially when the format rules (see below) are + not followed. However, more often the memo will be returned to the + author for the additional work. + + Documents intended to become RFCs specifying standards track + protocols must be approved by the IESG before being sent to the RFC + Editor. The established procedure is that when the IESG completes + work on a document that is to become a standards track RFC the + communication will be from the Secretary of the IESG to the RFC + Editor. Generally, the documents in question are Internet Drafts. + The communication usually cites the exact Internet Draft in question + (by file name). The RFC Editor must assume that only that file is to + be processed to become the RFC. If the authors have small + corrections to the text, they should be sent to the RFC Editor + separately (or as a "diff"), do not send a new version of the + document. + + In some cases, authors prepare alternate secondary versions of RFCs + in fancy format using PostScript. Since the ASCII text version of + the RFC is the primary version, the PostScript version must match the + + + +Postel [Page 3] + +RFC 1543 Instructions to RFC Authors October 1993 + + + text version. The RFC Editor must decide if the PostScript version + is "the same as" the ASCII version before the PostScript version can + be published. + + The effect of this is that the RFC Editor first processes the ASCII + version of the memo through to publication as an RFC. If the author + wishes to submit a PostScript version at that point that matches the + ASCII version (and the RFC Editor agrees that it does), then the + PostScript version will be installed in the RFC repositories and + announced to the community. + + Due to various time pressures on the RFC Editorial staff the time + elapsed between submission and publication can vary greatly. It is + always acceptable to query (ping) the RFC Editor about the status of + an RFC during this time (but not more than once a week). The two + weeks preceding an IETF meeting are generally very busy, so RFCs + submitted shortly before an IETF meeting are most likely to be + published after the meeting. + +3. Format Rules + + To meet the distribution constraints, the following rules are + established for the two allowed formats for RFCs: ASCII and + PostScript. + + The RFC Editor attempts to ensure a consistent RFC style. To do this + the RFC Editor may choose to reformat the RFC submitted. It is much + easier to do this if the submission matches the style of the most + recent RFCs. Please do look at some recent RFCs and prepare yours in + the same style. + + You must submit an editable online document to the RFC Editor. The + RFC Editor may require minor changes in format or style and will + insert the actual RFC number. + + Most of the RFCs are processed by the RFC Editor with the unix + "nroff" program using a very simple set of the formatting commands + (or "requests") from the "ms" macro package (see the appendix). If a + memo submitted to be an RFC has been prepared by the author using + nroff, it is very helpful to let the RFC Editor know that when it is + submitted. + + 3a. ASCII Format Rules + + The character codes are ASCII. + + Each page must be limited to 58 lines followed by a form feed on a + line by itself. + + + +Postel [Page 4] + +RFC 1543 Instructions to RFC Authors October 1993 + + + Each line must be limited to 72 characters followed by carriage + return and line feed. + + No overstriking (or underlining) is allowed. + + These "height" and "width" constraints include any headers, + footers, page numbers, or left side indenting. + + Do not fill the text with extra spaces to provide a straight right + margin. + + Do not do hyphenation of words at the right margin. + + Do not use footnotes. If such notes are necessary, put them at + the end of a section, or at the end of the document. + + Use single spaced text within a paragraph, and one blank line + between paragraphs. + + Note that the number of pages in a document and the page numbers + on which various sections fall will likely change with + reformatting. Thus cross references in the text by section number + usually are easier to keep consistent than cross references by + page number. + + RFCs in ASCII Format may be submitted to the RFC Editor in e-mail + messages (or as online files) in either the finished publication + format or in NROFF. If you plan to submit a document in NROFF + please consult the RFC Editor first. + + 3b. PostScript Format Rules + + Standard page size is 8 1/2 by 11 inches. + + Margin of 1 inch on all sides (top, bottom, left, and right). + + Main text should have a point size of no less than 10 points with + a line spacing of 12 points. + + Footnotes and graph notations no smaller than 8 points with a line + spacing of 9.6 points. + + Three fonts are acceptable: Helvetica, Times Roman, and Courier. + Plus their bold-face and italic versions. These are the three + standard fonts on most PostScript printers. + + Prepare diagrams and images based on lowest common denominator + PostScript. Consider common PostScript printer functionality and + + + +Postel [Page 5] + +RFC 1543 Instructions to RFC Authors October 1993 + + + memory requirements. + + The following PostScript commands should not be used: + initgraphics, erasepage, copypage, grestoreall, initmatrix, + initclip, banddevice, framedevice, nulldevice and renderbands. + + Note that the number of pages in a document and the page numbers + on which various sections fall will likely differ in the ASCII and + the PostScript versions. Thus cross references in the text by + section number usually are easier to keep consistent than cross + references by page number. + + These PostScript rules are likely to changed and expanded as + experience is gained. + + RFCs in PostScript Format may be submitted to the RFC Editor in + e-mail messages (or as online files). If you plan to submit a + document in PostScript please consult the RFC Editor first. + + Note that since the ASCII text version of the RFC is the primary + version, the PostScript version must match the text version. The + RFC Editor must decide if the PostScript version is "the same as" + the ASCII version before the PostScript version can be published. + +4. Headers and Footers + + There is the first page heading, the running headers, and the running + footers. + + 4a. First Page + + Please see the front page of this memo for an example of the front + page heading. On the first page there is no running header. The + top of the first page has the following items: + + Network Working Group + + The traditional heading for the group that founded the RFC + series. This appears on the first line on the left hand side + of the heading. + + Request for Comments: nnnn + + Identifies this as a request for comments and specifies the + number. Indicated on the second line on the left side. The + actual number is filled in at the last moment before + publication by the RFC Editor. + + + + +Postel [Page 6] + +RFC 1543 Instructions to RFC Authors October 1993 + + + Author + + The author's name (first initial and last name only) indicated + on the first line on the right side of the heading. + + Organization + + The author's organization, indicated on the second line on the + right side. + + Date + + This is the Month and Year of the RFC Publication. Indicated on + the third line on the right side. + + Updates or Obsoletes + + If this RFC Updates or Obsoletes another RFC, this is indicated + as third line on the left side of the heading. + + Category + + The category of this RFC, one of: Standards Track, + Informational, or Experimental. This is indicated on the third + (if there is no Updates or Obsoletes indication) or fourth line + of the left side. + + Title + + The title appears, centered, below the rest of the heading. + + If there are multiple authors and if the multiple authors are from + multiple organizations the right side heading may have additional + lines to accommodate them and to associate the authors with the + organizations properly. + + 4b. Running Headers + + The running header in one line (on page 2 and all subsequent + pages) has the RFC number on the left (RFC NNNN), the (possibly a + shortened form) title centered, and the date (Month Year) on the + right. + + 4c. Running Footers + + The running footer in one line (on all pages) has the author's + last name on the left and the page number on the right ([Page N]). + + + + +Postel [Page 7] + +RFC 1543 Instructions to RFC Authors October 1993 + + +5. Status Section + + Each RFC must include on its first page the "Status of this Memo" + section which contains a paragraph describing the type of the RFC. + + The content of this section will be one of the three following + statements. + + Standards Track + + "This document specifies an Internet standards track protocol for + the Internet community, and requests discussion and suggestions + for improvements. Please refer to the current edition of the + "Internet Official Protocol Standards" (STD 1) for the + standardization state and status of this protocol. Distribution + of this memo is unlimited." + + Experimental + + "This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited." + + Informational + + "This memo provides information for the Internet community. This + memo does not specify an Internet standard of any kind. + Distribution of this memo is unlimited." + +6. Introduction Section + + Each RFC should have an Introduction section that (among other + things) explains the motivation for the RFC and (if appropriate) + describes the applicability of the protocol described. + + Some example paragraphs are: + + Protocol + + This protocol is intended to provide the bla-bla service, + and be used between clients and servers on host computers. + Typically the clients are on workstation hosts and the + servers on mainframe hosts. + + or + + + + + +Postel [Page 8] + +RFC 1543 Instructions to RFC Authors October 1993 + + + This protocol is intended to provide the bla-bla service, + and be used between special purpose units such as terminal + servers or routers and a monitoring host. + + Discussion + + The purpose of this RFC is to focus discussion on particular + problems in the Internet and possible methods of solution. + No proposed solutions in this document are intended as + standards for the Internet. Rather, it is hoped that a + general consensus will emerge as to the appropriate solution + to such problems, leading eventually to the adoption of + standards. + + Interest + + This RFC is being distributed to members of the Internet + community in order to solicit their reactions to the + proposals contained in it. While the issues discussed may + not be directly relevant to the research problems of the + Internet, they may be interesting to a number of researchers + and implementers. + + Status Report + + In response to the need for maintenance of current + information about the status and progress of various + projects in the Internet community, this RFC is issued for + the benefit of community members. The information contained + in this document is accurate as of the date of publication, + but is subject to change. Subsequent RFCs will reflect such + changes. + + These paragraphs need not be followed word for word, but the + general intent of the RFC must be made clear. + +7. References Section + + Nearly all RFCs contain citations to other documents, and these are + listed in a References section near the end of the RFC. There are + many styles for references, and the RFCs have one of their own. + Please follow the reference style used in recent RFCs. See the + reference section of this RFC for an example. Please note that for + protocols that have been assigned STD numbers, the STD number must be + included in the reference. + + + + + + +Postel [Page 9] + +RFC 1543 Instructions to RFC Authors October 1993 + + +8. Security Considerations Section + + All RFCs must contain a section near the end of the document that + discusses the security considerations of the protocol or procedures + that are the main topic of the RFC. + +9. Author's Address Section + + Each RFC must have at the very end a section giving the author's + address, including the name and postal address, the telephone number, + (optional: a FAX number) and the Internet e-mail address. + +10. Relation to other RFCs + + Sometimes an RFC adds information on a topic discussed in a previous + RFC or completely replaces an earlier RFC. There are two terms used + for these cases respectively, UPDATES and OBSOLETES. A document that + obsoletes an earlier document can stand on its own. A document that + merely updates an earlier document cannot stand on its own; it is + something that must be added to or inserted into the previously + existing document, and has limited usefulness independently. The + terms SUPERSEDES and REPLACES are no longer used. + + UPDATES + + To be used as a reference from a new item that cannot be used + alone (i.e., one that supplements a previous document), to refer + to the previous document. The newer publication is a part that + will supplement or be added on to the existing document; e.g., an + addendum, or separate, extra information that is to be added to + the original document. + + OBSOLETES + + To be used to refer to an earlier document that is replaced by + this document. This document contains either revised information, + or else all of the same information plus some new information, + however extensive or brief that new information is; i.e., this + document can be used alone, without reference to the older + document. + + For example: + + On the Assigned Numbers RFCs the term OBSOLETES should be used + since the new document actually incorporate new information + (however brief) into the text of existing information and is + more up-to-date than the older document, and hence, replaces it + and makes it OBSOLETE. + + + +Postel [Page 10] + +RFC 1543 Instructions to RFC Authors October 1993 + + + In lists of RFCs or the RFC-Index (but not on the RFCs themselves) + the following may be used with early documents to point to later + documents. + + OBSOLETED-BY + + To be used to refer to the newer document(s) that replaces the + older document. + + UPDATED-BY + + To be used to refer to the newer section(s) which are to be added + to the existing, still used, document. + +11. Protocol Standards Process + + See the current "Internet Official Protocol Standards" (STD 1) memo + for the definitive statement on protocol standards and their + publication [1]. + + The established procedure is that when the IESG completes work on a + document that is to become a standards track RFC the communication + will be from the Secretary of the IESG to the RFC Editor. Generally, + the documents in question are Internet Drafts. The communication + usually cites the exact Internet Draft (by file name) in question. + The RFC Editor must assume that only that file is to be processed to + become the RFC. If the authors have small corrections to the text, + they should be sent to the RFC Editor separately (or as a "diff"), do + not send a new version of the document. + +12. Contact + + To contact the RFC Editor send an email message to + + "RFC-Editor@ISI.EDU". + +13. Distribution Lists + + The RFC announcements are distributed via two mailing lists: the + "IETF-Announce" list, and the "RFC-DIST" list. You don't want to be + on both lists. + + To join (or quit) the IETF-Announce list send a message to IETF- + Request@cnri.reston.va.us. + + To join (or quit) the RFC-DIST list send a message to RFC- + Request@NIC.DDN.MIL. + + + + +Postel [Page 11] + +RFC 1543 Instructions to RFC Authors October 1993 + + +14. RFC Index + + Several organizations maintain RFC Index files, generally using the + file name "rfc-index.txt". The contents of such a file copied from + one site may not be identical to that copied from another site. + +15. Security Considerations + + This RFC raises no security issues (however, see Section 6). + +16. References + + + [1] Postel, J., "Internet Official Protocol Standards", STD 1, RFC + 1540, Internet Architecture Board, October 1993. + +17. Author's Address + + Jon Postel + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: 310-822-1511 + Fax: 310-823-6714 + EMail: Postel@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 12] + +RFC 1543 Instructions to RFC Authors October 1993 + + +18. Appendix - RFC "nroff macros" + + Generally, we use the very simplest nroff features. We use the "ms" + macros. So, "nroff -ms input-file > output-file". However, we could + not get nroff to do the right thing about putting a form feed after + the last visible line on a page and no extra line feeds before the + first visible line of the next page. We want: + + last visible line on page i + ^L + first visible line on page i+1 + + So, we invented some hacks to fix this including a "sed" script + called "fix.sh" and a "c" program we called "pg" (pg is called from + fix). So the command to process the file becomes: + + nroff -ms input-file | fix.sh > output-file + + Now as to the nroff features we actually use, I'll append a sample + memo, prepared in RFC style. + + The sed script fix.sh is: + + sed -e 's/FORMFEED\[Page/ \[Page/' $* | pg -n5 + +The pg program is: + + ~~~Beginning of pg program~~~ + +/* $Header$ + * + * Remove N lines following any line that contains a form feed (^L). + * (Why can't this be done with awk or sed?) + * + * OPTION: + * -n# Number of lines to delete following each ^L (0 default). + * $Log$ + */ +#include +#define FORM_FEED '\f' +#define OPTION "n:N:" /* for getopt() */ + +extern char *optarg; +extern int optind; + +main(argc, argv) +int argc; +char *argv[]; + + + +Postel [Page 13] + +RFC 1543 Instructions to RFC Authors October 1993 + + +{ + int c, /* next input char */ + nlines = 0; /* lines to delete after ^L */ + void print_and_delete(); /* print line starting with ^L, + then delete N lines */ + +/* Process option (-nlines) */ + + while ((c = getopt(argc, argv, OPTION)) != EOF) + switch(c) + { + case 'n' : + case 'N' : nlines = atoi(optarg); + break; + } +/* READ AND PROCESS CHARS */ + + while ((c = getchar()) != EOF) + if (c == FORM_FEED) + print_and_delete(nlines); /* remove N lines after this one */ + else + putchar(c); /* we write the form feed */ + exit(0); +} + +/* Print rest of line, then delete next N lines. */ + +void print_and_delete(n) +int n; /* nbr of lines to delete */ +{ + int c, /* next input char */ + cntr = 0; /* count of deleted lines */ + + while ((c = getchar()) != '\n') /* finish current line */ + putchar(c); + putchar('\n'); /* write the last CR */ + putchar(FORM_FEED); + + for ( ; cntr < n; cntr++) + while ((c = getchar()) != '\n') + if (c == EOF) + exit(0); /* exit on EOF */ + putchar(c); /* write that last CR */ +} + ~~~End of pg program~~~ + + + + + + +Postel [Page 14] + +RFC 1543 Instructions to RFC Authors October 1993 + + +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Waitzman +.ds RF FORMFEED[Page %] +.ds CF +.ds LH RFC 1149 +.ds RH 1 April 1990 +.ds CH IP Datagrams on Avian Carriers +.hy 0 +.ad l +.in 0 +Network Working Group D. Waitzman +Request for Comments: 1149 BBN STC + 1 April 1990 + + +.ce +A Standard for the Transmission of IP Datagrams on Avian Carriers + +.ti 0 +Status of this Memo + +.fi +.in 3 +This memo describes an experimental method for the encapsulation of IP +datagrams in avian carriers. This specification is primarily useful +in Metropolitan Area Networks. This is an experimental, not recommended +standard. Distribution of this memo is unlimited. + +.ti 0 +Overview and Rational + +Avian carriers can provide high delay, low throughput, and low +altitude service. The connection topology is limited to a single +point-to-point path for each carrier, used with standard carriers, but +many carriers can be used without significant interference with each +other, outside of early spring. This is because of the 3D ether space +available to the carriers, in contrast to the 1D ether used by +IEEE802.3. The carriers have an intrinsic collision avoidance system, +which increases availability. Unlike some network technologies, such +as packet radio, communication is not limited to line-of-sight +distance. Connection oriented service is available in some cities, +usually based upon a central hub topology. + + + + +Postel [Page 15] + +RFC 1543 Instructions to RFC Authors October 1993 + + +.ti 0 +Frame Format + +The IP datagram is printed, on a small scroll of paper, in +hexadecimal, with each octet separated by whitestuff and blackstuff. +The scroll of paper is wrapped around one leg of the avian carrier. +A band of duct tape is used to secure the datagram's edges. The +bandwidth is limited to the leg length. The MTU is variable, and +paradoxically, generally increases with increased carrier age. A +typical MTU is 256 milligrams. Some datagram padding may be needed. + +Upon receipt, the duct tape is removed and the paper copy of the +datagram is optically scanned into a electronically transmittable +form. + +.ti 0 +Discussion + +Multiple types of service can be provided with a prioritized pecking +order. An additional property is built-in worm detection and +eradication. Because IP only guarantees best effort delivery, loss of +a carrier can be tolerated. With time, the carriers are +self-regenerating. While broadcasting is not specified, storms can +cause data loss. There is persistent delivery retry, until the +carrier drops. Audit trails are automatically generated, and can +often be found on logs and cable trays. + +.ti 0 +Security Considerations + +.in 3 +Security is not generally a problem in normal operation, but special +measures must be taken (such as data encryption) when avian carriers +are used in a tactical environment. + +.ti 0 +Author's Address + +.nf +David Waitzman +BBN Systems and Technologies Corporation +BBN Labs Division +10 Moulton Street +Cambridge, MA 02238 + +Phone: (617) 873-4323 + +EMail: dwaitzman@BBN.COM + + + +Postel [Page 16] + \ No newline at end of file -- cgit v1.2.3