From d568c898ff9c74906ec15945edf724e5823c9bbb Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 15 Jul 2022 16:21:44 -0400 Subject: [PATCH 01/16] Add RFCs and add rules about them --- EIPS/eip-1.md | 10 +- assets/eip-1/rfcs/README.md | 9 + assets/eip-1/rfcs/rfc2119.txt | 171 ++ assets/eip-1/rfcs/rfc822.txt | 2901 +++++++++++++++++++++++++++++++++ eip-template.md | 2 +- 5 files changed, 3089 insertions(+), 4 deletions(-) create mode 100644 assets/eip-1/rfcs/README.md create mode 100644 assets/eip-1/rfcs/rfc2119.txt create mode 100644 assets/eip-1/rfcs/rfc822.txt diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 15afc33ef311c8..cf3cbd50cb34ef 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -96,7 +96,7 @@ If this period results in necessary normative changes it will revert the EIP to Each EIP should have the following parts: -- Preamble - RFC 822 style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. +- Preamble - [RFC 822](../assets/eip-1/rfcs/rfc822.txt) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. - Motivation _(optional)_ - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident. - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (cpp-ethereum, go-ethereum, parity, ethereumJ, ethereumjs-lib, [and others](https://github.com/ethereum/wiki/wiki/Clients). @@ -265,11 +265,15 @@ The `description` field in the preamble: When referring to an EIP by number, it should be written in the hyphenated form `EIP-X` where `X` is the EIP's assigned number. +### IETF RFCs + +When referencing an IETF RFC, EIPs should link to the rfc in the `assets/eip-1/rfcs` directory. If the RFC is not currently in that directory, a separate pull request must be submitted which only adds the rfc. + ### RFC 2119 -EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: +EIPs are encouraged to follow [RFC 2119](../assets/eip-1/rfcs/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: -> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/rfcs/rfc2119.txt). ## History diff --git a/assets/eip-1/rfcs/README.md b/assets/eip-1/rfcs/README.md new file mode 100644 index 00000000000000..63fa6eddd5e183 --- /dev/null +++ b/assets/eip-1/rfcs/README.md @@ -0,0 +1,9 @@ +# Internet Engineering Task Force (IETF) Request for Comments (RFC) + +This folder is dedicated to storing relevant RFCs. If you would like to add an RFC to this folder, please submit a pull request adding it! + +According to the [IETF's FAQ](https://trustee.ietf.org/about/faq/#collapse3103): + +> Am I allowed to reproduce whole RFCs? +> +> Yes. Since the beginning of the RFC series, reproduction of whole RFCs (including translation into a language other than English) has been allowed and encouraged. The IETF Trust and the RFC Editor place no restrictions on this. Most RFCs include the standard phrase “Distribution of this memo is unlimited” to indicate this. diff --git a/assets/eip-1/rfcs/rfc2119.txt b/assets/eip-1/rfcs/rfc2119.txt new file mode 100644 index 00000000000000..e31fae47fd1ff4 --- /dev/null +++ b/assets/eip-1/rfcs/rfc2119.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group S. Bradner +Request for Comments: 2119 Harvard University +BCP: 14 March 1997 +Category: Best Current Practice + + + Key words for use in RFCs to Indicate Requirement Levels + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Abstract + + In many standards track documents several words are used to signify + the requirements in the specification. These words are often + capitalized. This document defines these words as they should be + interpreted in IETF documents. Authors who follow these guidelines + should incorporate this phrase near the beginning of their document: + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC 2119. + + Note that the force of these words is modified by the requirement + level of the document in which they are used. + +1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the + definition is an absolute requirement of the specification. + +2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the + definition is an absolute prohibition of the specification. + +3. SHOULD This word, or the adjective "RECOMMENDED", mean that there + may exist valid reasons in particular circumstances to ignore a + particular item, but the full implications must be understood and + carefully weighed before choosing a different course. + +4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that + there may exist valid reasons in particular circumstances when the + particular behavior is acceptable or even useful, but the full + implications should be understood and the case carefully weighed + before implementing any behavior described with this label. + + + + + +Bradner Best Current Practice [Page 1] + +RFC 2119 RFC Key Words March 1997 + + +5. MAY This word, or the adjective "OPTIONAL", mean that an item is + truly optional. One vendor may choose to include the item because a + particular marketplace requires it or because the vendor feels that + it enhances the product while another vendor may omit the same item. + An implementation which does not include a particular option MUST be + prepared to interoperate with another implementation which does + include the option, though perhaps with reduced functionality. In the + same vein an implementation which does include a particular option + MUST be prepared to interoperate with another implementation which + does not include the option (except, of course, for the feature the + option provides.) + +6. Guidance in the use of these Imperatives + + Imperatives of the type defined in this memo must be used with care + and sparingly. In particular, they MUST only be used where it is + actually required for interoperation or to limit behavior which has + potential for causing harm (e.g., limiting retransmisssions) For + example, they must not be used to try to impose a particular method + on implementors where the method is not required for + interoperability. + +7. Security Considerations + + These terms are frequently used to specify behavior with security + implications. The effects on security of not implementing a MUST or + SHOULD, or doing something the specification says MUST NOT or SHOULD + NOT be done may be very subtle. Document authors should take the time + to elaborate the security implications of not following + recommendations or requirements as most implementors will not have + had the benefit of the experience and discussion that produced the + specification. + +8. Acknowledgments + + The definitions of these terms are an amalgam of definitions taken + from a number of RFCs. In addition, suggestions have been + incorporated from a number of people including Robert Ullmann, Thomas + Narten, Neal McBurnett, and Robert Elz. + + + + + + + + + + + + +Bradner Best Current Practice [Page 2] + +RFC 2119 RFC Key Words March 1997 + + +9. Author's Address + + Scott Bradner + Harvard University + 1350 Mass. Ave. + Cambridge, MA 02138 + + phone - +1 617 495 3864 + + email - sob@harvard.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bradner Best Current Practice [Page 3] + diff --git a/assets/eip-1/rfcs/rfc822.txt b/assets/eip-1/rfcs/rfc822.txt new file mode 100644 index 00000000000000..35b09a3cb7eedd --- /dev/null +++ b/assets/eip-1/rfcs/rfc822.txt @@ -0,0 +1,2901 @@ + + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. Ken L. + Harrenstien, of SRI International, was responsible for re-coding + the BNF into an augmented BNF that makes the representation + smaller and easier to understand. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + *element + + indicating at least and at most occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "(element)" is equivalent to "*(element)"; that is, + exactly occurrences of (element). Thus 2DIGIT is a 2-digit + number, and 3ALPHA is a string of three alphabetic characters. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + #element + + indicating at least and at most elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a . Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by , if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + + + user-defined-field = + + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first parameter indicates the + software used to encrypt the body, and the second, optional + is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 5. DATE AND TIME SPECIFICATION + + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the
+ serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person , + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly + Sender: Secy-Name + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: , George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1* + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens and have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + August 13, 1982 - 44 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + <"> = ; ( 42, 34.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + diff --git a/eip-template.md b/eip-template.md index a561aeb07e84c0..a3b5d791b5c205 100644 --- a/eip-template.md +++ b/eip-template.md @@ -24,7 +24,7 @@ Abstract is a multi-sentence (short paragraph) technical summary. This should be The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? ## Specification -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/rfcs/rfc2119.txt). The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). From b2763e539c26f458f328024478eda19004821d5e Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 15 Jul 2022 16:31:55 -0400 Subject: [PATCH 02/16] Make referencing RFCs similar to referencing EIPs --- EIPS/eip-1.md | 8 ++++---- eip-template.md | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index cf3cbd50cb34ef..71464cf910253a 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -96,7 +96,7 @@ If this period results in necessary normative changes it will revert the EIP to Each EIP should have the following parts: -- Preamble - [RFC 822](../assets/eip-1/rfcs/rfc822.txt) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. +- Preamble - [RFC 822](../assets/eip-1/RFCs/rfc822.txt) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. - Motivation _(optional)_ - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident. - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (cpp-ethereum, go-ethereum, parity, ethereumJ, ethereumjs-lib, [and others](https://github.com/ethereum/wiki/wiki/Clients). @@ -267,13 +267,13 @@ When referring to an EIP by number, it should be written in the hyphenated form ### IETF RFCs -When referencing an IETF RFC, EIPs should link to the rfc in the `assets/eip-1/rfcs` directory. If the RFC is not currently in that directory, a separate pull request must be submitted which only adds the rfc. +When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/eip-1/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which only includes the RFC in that directory. ### RFC 2119 -EIPs are encouraged to follow [RFC 2119](../assets/eip-1/rfcs/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: +EIPs are encouraged to follow [RFC 2119](../assets/eip-1/RFCs/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: -> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/rfcs/rfc2119.txt). +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/RFCs/rfc2119.txt). ## History diff --git a/eip-template.md b/eip-template.md index a3b5d791b5c205..672f434cefacf8 100644 --- a/eip-template.md +++ b/eip-template.md @@ -24,7 +24,7 @@ Abstract is a multi-sentence (short paragraph) technical summary. This should be The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? ## Specification -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/rfcs/rfc2119.txt). +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/RFCs/rfc2119.txt). The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). From 70dab87fe42045dcac1d0060ba77e86d2cc94ace Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 15 Jul 2022 17:23:13 -0400 Subject: [PATCH 03/16] Make RFCs exempt from Codespell --- .github/workflows/ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 4fc8cee5c50cd8..9119e4b94b85c7 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -45,7 +45,7 @@ jobs: with: check_filenames: true ignore_words_file: .codespell-whitelist - skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css + skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css,assets/eip-1/RFCs/*.txt eip-validator: name: EIP Validator From 677eb04c42112aac2911203e875700a7f5c84255 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Fri, 15 Jul 2022 20:35:09 -0400 Subject: [PATCH 04/16] Move RFCs directory --- EIPS/eip-1.md | 8 ++++---- assets/{eip-1/rfcs => RFCs}/README.md | 0 assets/{eip-1/rfcs => RFCs}/rfc2119.txt | 0 assets/{eip-1/rfcs => RFCs}/rfc822.txt | 0 eip-template.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) rename assets/{eip-1/rfcs => RFCs}/README.md (100%) rename assets/{eip-1/rfcs => RFCs}/rfc2119.txt (100%) rename assets/{eip-1/rfcs => RFCs}/rfc822.txt (100%) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 71464cf910253a..e6c6e2ab9271e5 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -96,7 +96,7 @@ If this period results in necessary normative changes it will revert the EIP to Each EIP should have the following parts: -- Preamble - [RFC 822](../assets/eip-1/RFCs/rfc822.txt) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. +- Preamble - [RFC 822](../assets/RFCs/rfc822.txt) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. - Motivation _(optional)_ - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident. - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (cpp-ethereum, go-ethereum, parity, ethereumJ, ethereumjs-lib, [and others](https://github.com/ethereum/wiki/wiki/Clients). @@ -267,13 +267,13 @@ When referring to an EIP by number, it should be written in the hyphenated form ### IETF RFCs -When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/eip-1/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which only includes the RFC in that directory. +When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which only includes the RFC in that directory. ### RFC 2119 -EIPs are encouraged to follow [RFC 2119](../assets/eip-1/RFCs/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: +EIPs are encouraged to follow [RFC 2119](../assets/RFCs/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: -> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/RFCs/rfc2119.txt). +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/RFCs/rfc2119.txt). ## History diff --git a/assets/eip-1/rfcs/README.md b/assets/RFCs/README.md similarity index 100% rename from assets/eip-1/rfcs/README.md rename to assets/RFCs/README.md diff --git a/assets/eip-1/rfcs/rfc2119.txt b/assets/RFCs/rfc2119.txt similarity index 100% rename from assets/eip-1/rfcs/rfc2119.txt rename to assets/RFCs/rfc2119.txt diff --git a/assets/eip-1/rfcs/rfc822.txt b/assets/RFCs/rfc822.txt similarity index 100% rename from assets/eip-1/rfcs/rfc822.txt rename to assets/RFCs/rfc822.txt diff --git a/eip-template.md b/eip-template.md index 672f434cefacf8..c9894c93de2e2a 100644 --- a/eip-template.md +++ b/eip-template.md @@ -24,7 +24,7 @@ Abstract is a multi-sentence (short paragraph) technical summary. This should be The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? ## Specification -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/eip-1/RFCs/rfc2119.txt). +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/RFCs/rfc2119.txt). The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). From 04739ea0d2152b036dc8815a5705366e64a66f18 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Sat, 16 Jul 2022 08:08:29 -0400 Subject: [PATCH 05/16] Fix path in CI --- .github/workflows/ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 9119e4b94b85c7..85ef762025a41c 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -45,7 +45,7 @@ jobs: with: check_filenames: true ignore_words_file: .codespell-whitelist - skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css,assets/eip-1/RFCs/*.txt + skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css,assets/RFCs/*.txt eip-validator: name: EIP Validator From 5210e3560aae2a73f80b97c4ce4ff643f5711b84 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Tue, 19 Jul 2022 12:01:50 -0400 Subject: [PATCH 06/16] As requested --- EIPS/eip-1.md | 10 +- assets/RFCs/rfc2119.html | 329 +++ assets/RFCs/rfc2119.txt | 171 -- assets/RFCs/{rfc822.txt => rfc822.html} | 3100 ++++++++++++----------- 4 files changed, 1889 insertions(+), 1721 deletions(-) create mode 100644 assets/RFCs/rfc2119.html delete mode 100644 assets/RFCs/rfc2119.txt rename assets/RFCs/{rfc822.txt => rfc822.html} (65%) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index e6c6e2ab9271e5..2b0e5e2cae86d4 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -96,7 +96,7 @@ If this period results in necessary normative changes it will revert the EIP to Each EIP should have the following parts: -- Preamble - [RFC 822](../assets/RFCs/rfc822.txt) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. +- Preamble - [RFC 822](../assets/RFCs/rfc822.html) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details. - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. - Motivation _(optional)_ - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident. - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (cpp-ethereum, go-ethereum, parity, ethereumJ, ethereumjs-lib, [and others](https://github.com/ethereum/wiki/wiki/Clients). @@ -113,7 +113,7 @@ EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wik ## EIP Header Preamble -Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. +Each EIP must begin with an [RFC 822](../assets/RFCs/rfc822.html) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. `eip`: *EIP number* (this is determined by the EIP editor) @@ -267,13 +267,13 @@ When referring to an EIP by number, it should be written in the hyphenated form ### IETF RFCs -When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which only includes the RFC in that directory. +When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which ONLY includes the HTML rendering of that RFC, with all anchors replaced with internal anchors, in that directory. ### RFC 2119 -EIPs are encouraged to follow [RFC 2119](../assets/RFCs/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: +EIPs are encouraged to follow [RFC 2119](../assets/RFCs/rfc2119.html) for terminology and to insert the following at the beginning of the Specification section: -> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/RFCs/rfc2119.txt). +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/RFCs/rfc2119.html). ## History diff --git a/assets/RFCs/rfc2119.html b/assets/RFCs/rfc2119.html new file mode 100644 index 00000000000000..900d2b49a1b4a9 --- /dev/null +++ b/assets/RFCs/rfc2119.html @@ -0,0 +1,329 @@ + + + + + + + + + + + + + +RFC 2119: Key words for use in RFCs to Indicate Requirement Levels + + + + + +[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

BEST CURRENT PRACTICE
Updated by: 8174 Errata Exist
Network Working Group                                         S. Bradner
+Request for Comments: 2119                            Harvard University
+BCP: 14                                                       March 1997
+Category: Best Current Practice
+
+
+        Key words for use in RFCs to Indicate Requirement Levels
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   In many standards track documents several words are used to signify
+   the requirements in the specification.  These words are often
+   capitalized.  This document defines these words as they should be
+   interpreted in IETF documents.  Authors who follow these guidelines
+   should incorporate this phrase near the beginning of their document:
+
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in
+      RFC 2119.
+
+   Note that the force of these words is modified by the requirement
+   level of the document in which they are used.
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
+   definition is an absolute requirement of the specification.
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+   definition is an absolute prohibition of the specification.
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+

+RFC 2119                     RFC Key Words                    March 1997
+
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides.)
+
+6. Guidance in the use of these Imperatives
+
+   Imperatives of the type defined in this memo must be used with care
+   and sparingly.  In particular, they MUST only be used where it is
+   actually required for interoperation or to limit behavior which has
+   potential for causing harm (e.g., limiting retransmisssions)  For
+   example, they must not be used to try to impose a particular method
+   on implementors where the method is not required for
+   interoperability.
+
+7. Security Considerations
+
+   These terms are frequently used to specify behavior with security
+   implications.  The effects on security of not implementing a MUST or
+   SHOULD, or doing something the specification says MUST NOT or SHOULD
+   NOT be done may be very subtle. Document authors should take the time
+   to elaborate the security implications of not following
+   recommendations or requirements as most implementors will not have
+   had the benefit of the experience and discussion that produced the
+   specification.
+
+8. Acknowledgments
+
+   The definitions of these terms are an amalgam of definitions taken
+   from a number of RFCs.  In addition, suggestions have been
+   incorporated from a number of people including Robert Ullmann, Thomas
+   Narten, Neal McBurnett, and Robert Elz.
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+

+RFC 2119                     RFC Key Words                    March 1997
+
+
+9. Author's Address
+
+      Scott Bradner
+      Harvard University
+      1350 Mass. Ave.
+      Cambridge, MA 02138
+
+      phone - +1 617 495 3864
+
+      email - sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
+ + + + + \ No newline at end of file diff --git a/assets/RFCs/rfc2119.txt b/assets/RFCs/rfc2119.txt deleted file mode 100644 index e31fae47fd1ff4..00000000000000 --- a/assets/RFCs/rfc2119.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -Network Working Group S. Bradner -Request for Comments: 2119 Harvard University -BCP: 14 March 1997 -Category: Best Current Practice - - - Key words for use in RFCs to Indicate Requirement Levels - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Abstract - - In many standards track documents several words are used to signify - the requirements in the specification. These words are often - capitalized. This document defines these words as they should be - interpreted in IETF documents. Authors who follow these guidelines - should incorporate this phrase near the beginning of their document: - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC 2119. - - Note that the force of these words is modified by the requirement - level of the document in which they are used. - -1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the - definition is an absolute requirement of the specification. - -2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the - definition is an absolute prohibition of the specification. - -3. SHOULD This word, or the adjective "RECOMMENDED", mean that there - may exist valid reasons in particular circumstances to ignore a - particular item, but the full implications must be understood and - carefully weighed before choosing a different course. - -4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that - there may exist valid reasons in particular circumstances when the - particular behavior is acceptable or even useful, but the full - implications should be understood and the case carefully weighed - before implementing any behavior described with this label. - - - - - -Bradner Best Current Practice [Page 1] - -RFC 2119 RFC Key Words March 1997 - - -5. MAY This word, or the adjective "OPTIONAL", mean that an item is - truly optional. One vendor may choose to include the item because a - particular marketplace requires it or because the vendor feels that - it enhances the product while another vendor may omit the same item. - An implementation which does not include a particular option MUST be - prepared to interoperate with another implementation which does - include the option, though perhaps with reduced functionality. In the - same vein an implementation which does include a particular option - MUST be prepared to interoperate with another implementation which - does not include the option (except, of course, for the feature the - option provides.) - -6. Guidance in the use of these Imperatives - - Imperatives of the type defined in this memo must be used with care - and sparingly. In particular, they MUST only be used where it is - actually required for interoperation or to limit behavior which has - potential for causing harm (e.g., limiting retransmisssions) For - example, they must not be used to try to impose a particular method - on implementors where the method is not required for - interoperability. - -7. Security Considerations - - These terms are frequently used to specify behavior with security - implications. The effects on security of not implementing a MUST or - SHOULD, or doing something the specification says MUST NOT or SHOULD - NOT be done may be very subtle. Document authors should take the time - to elaborate the security implications of not following - recommendations or requirements as most implementors will not have - had the benefit of the experience and discussion that produced the - specification. - -8. Acknowledgments - - The definitions of these terms are an amalgam of definitions taken - from a number of RFCs. In addition, suggestions have been - incorporated from a number of people including Robert Ullmann, Thomas - Narten, Neal McBurnett, and Robert Elz. - - - - - - - - - - - - -Bradner Best Current Practice [Page 2] - -RFC 2119 RFC Key Words March 1997 - - -9. Author's Address - - Scott Bradner - Harvard University - 1350 Mass. Ave. - Cambridge, MA 02138 - - phone - +1 617 495 3864 - - email - sob@harvard.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 3] - diff --git a/assets/RFCs/rfc822.txt b/assets/RFCs/rfc822.html similarity index 65% rename from assets/RFCs/rfc822.txt rename to assets/RFCs/rfc822.html index 35b09a3cb7eedd..7a4f48de65a526 100644 --- a/assets/RFCs/rfc822.txt +++ b/assets/RFCs/rfc822.html @@ -1,128 +1,274 @@ - - - - - - - RFC # 822 - + + + + + + + + + + + + + +RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES + + + + + +[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

Obsoleted by: 2822 INTERNET STANDARD
Updated by: 1123, 2156, 1327, 1138, 1148 Errata Exist
     RFC #  822
+     
      Obsoletes:  RFC #733  (NIC #41952)
-
-
-
-
-
-
-
-
-
-
-
-
-                        STANDARD FOR THE FORMAT OF
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+                        STANDARD FOR THE FORMAT OF
+     
                         ARPA INTERNET TEXT MESSAGES
-
-
-
-
-
-
+     
+     
+     
+     
+     
+     
                               August 13, 1982
-
-
-
-
-
-
+     
+     
+     
+     
+     
+     
                                 Revised by
-
+     
                              David H. Crocker
-
-
+     
+     
                       Dept. of Electrical Engineering
                  University of Delaware, Newark, DE  19711
                       Network:  DCrocker @ UDel-Relay
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+
+ 
Standard for ARPA Internet Text Messages
+     
+     
                              TABLE OF CONTENTS
-
-
-     PREFACE ....................................................   ii
-
-     1.  INTRODUCTION ...........................................    1
-
-         1.1.  Scope ............................................    1
-         1.2.  Communication Framework ..........................    2
-
-     2.  NOTATIONAL CONVENTIONS .................................    3
-
-     3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
-
-         3.1.  General Description ..............................    5
-         3.2.  Header Field Definitions .........................    9
-         3.3.  Lexical Tokens ...................................   10
-         3.4.  Clarifications ...................................   11
-
-     4.  MESSAGE SPECIFICATION ..................................   17
-
-         4.1.  Syntax ...........................................   17
-         4.2.  Forwarding .......................................   19
-         4.3.  Trace Fields .....................................   20
-         4.4.  Originator Fields ................................   21
-         4.5.  Receiver Fields ..................................   23
-         4.6.  Reference Fields .................................   23
-         4.7.  Other Fields .....................................   24
-
-     5.  DATE AND TIME SPECIFICATION ............................   26
-
-         5.1.  Syntax ...........................................   26
-         5.2.  Semantics ........................................   26
-
-     6.  ADDRESS SPECIFICATION ..................................   27
-
-         6.1.  Syntax ...........................................   27
-         6.2.  Semantics ........................................   27
-         6.3.  Reserved Address .................................   33
-
-     7.  BIBLIOGRAPHY ...........................................   34
-
-
+     
+     
+     PREFACE ....................................................   ii
+     
+     1.  INTRODUCTION ...........................................    1
+     
+         1.1.  Scope ............................................    1
+         1.2.  Communication Framework ..........................    2
+     
+     2.  NOTATIONAL CONVENTIONS .................................    3
+     
+     3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
+     
+         3.1.  General Description ..............................    5
+         3.2.  Header Field Definitions .........................    9
+         3.3.  Lexical Tokens ...................................   10
+         3.4.  Clarifications ...................................   11
+     
+     4.  MESSAGE SPECIFICATION ..................................   17
+     
+         4.1.  Syntax ...........................................   17
+         4.2.  Forwarding .......................................   19
+         4.3.  Trace Fields .....................................   20
+         4.4.  Originator Fields ................................   21
+         4.5.  Receiver Fields ..................................   23
+         4.6.  Reference Fields .................................   23
+         4.7.  Other Fields .....................................   24
+     
+     5.  DATE AND TIME SPECIFICATION ............................   26
+     
+         5.1.  Syntax ...........................................   26
+         5.2.  Semantics ........................................   26
+     
+     6.  ADDRESS SPECIFICATION ..................................   27
+     
+         6.1.  Syntax ...........................................   27
+         6.2.  Semantics ........................................   27
+         6.3.  Reserved Address .................................   33
+     
+     7.  BIBLIOGRAPHY ...........................................   34
+     
+     
                              APPENDIX
-
-     A.  EXAMPLES ...............................................   36
-     B.  SIMPLE FIELD PARSING ...................................   40
-     C.  DIFFERENCES FROM RFC #733 ..............................   41
-     D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
-
-
-     August 13, 1982               - i -                      RFC #822
-
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     A.  EXAMPLES ...............................................   36
+     B.  SIMPLE FIELD PARSING ...................................   40
+     C.  DIFFERENCES FROM RFC #733 ..............................   41
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
+     
+     
+     August 13, 1982               - i -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
                                   PREFACE
-
-
+     
+     
           By 1977, the Arpanet employed several informal standards for
      the  text  messages (mail) sent among its host computers.  It was
      felt necessary to codify these practices and  provide  for  those
@@ -131,7 +277,7 @@
      Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
      The specification attempted to avoid major  changes  in  existing
      software, while permitting several new features.
-
+     
           This document revises the specifications  in  RFC  #733,  in
      order  to  serve  the  needs  of the larger and more complex ARPA
      Internet.  Some of RFC #733's features failed  to  gain  adequate
@@ -139,12 +285,12 @@
      that follows it, these features have been removed.   A  different
      addressing  scheme  is  used, to handle the case of inter-network
      mail; and the concept of re-transmission has been introduced.
-
+     
           This specification is intended for use in the ARPA Internet.
      However, an attempt has been made to free it of any dependence on
      that environment, so that it can be applied to other network text
      message systems.
-
+     
           The specification of RFC #733 took place over the course  of
      one  year, using the ARPANET mail environment, itself, to provide
      an on-going forum for discussing the capabilities to be included.
@@ -153,41 +299,38 @@
      revised specification has, similarly, utilized network mail-based
      group discussion.  Both specification efforts  greatly  benefited
      from the comments and ideas of the participants.
-
+     
           The syntax of the standard,  in  RFC  #733,  was  originally
      specified  in  the  Backus-Naur Form (BNF) meta-language.  Ken L.
      Harrenstien, of SRI International, was responsible for  re-coding
      the  BNF  into  an  augmented  BNF  that makes the representation
      smaller and easier to understand.
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - ii -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     1.  INTRODUCTION
-
-     1.1.  SCOPE
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - ii -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     1.  INTRODUCTION
+     
+     1.1.  SCOPE
+     
           This standard specifies a syntax for text messages that  are
      sent  among  computer  users, within the framework of "electronic
      mail".  The standard supersedes  the  one  specified  in  ARPANET
      Request  for Comments #733, "Standard for the Format of ARPA Net-
      work Text Messages".
-
+     
           In this context, messages are viewed as having  an  envelope
      and  contents.   The  envelope  contains  whatever information is
      needed to accomplish transmission  and  delivery.   The  contents
@@ -195,22 +338,22 @@
      dard applies only to the format and some of the semantics of mes-
      sage  contents.   It contains no specification of the information
      in the envelope.
-
+     
           However, some message systems may use information  from  the
      contents  to create the envelope.  It is intended that this stan-
      dard facilitate the acquisition of such information by programs.
-
+     
           Some message systems may  store  messages  in  formats  that
      differ  from the one specified in this standard.  This specifica-
      tion is intended strictly as a definition of what message content
      format is to be passed BETWEEN hosts.
-
+     
      Note:  This standard is NOT intended to dictate the internal for-
             mats  used  by sites, the specific message system features
             that they are expected to support, or any of  the  charac-
             teristics  of  user interface programs that create or read
             messages.
-
+     
           A distinction should be made between what the  specification
      REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
      rich with formally-structured components of information or can be
@@ -219,25 +362,22 @@
      formats  in  messages;  only  the  visual  aspect of a message is
      affected and not the interpretation  of  information  within  it.
      Implementors may choose to retain such visual distinctions.
-
+     
           The formal definition is divided into four levels.  The bot-
      tom level describes the meta-notation used in this document.  The
      second level describes basic lexical analyzers that  feed  tokens
      to  higher-level  parsers.   Next is an overall specification for
      messages; it permits distinguishing individual fields.   Finally,
      there is definition of the contents of several structured fields.
-
-
-
-     August 13, 1982               - 1 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     1.2.  COMMUNICATION FRAMEWORK
-
+     
+     
+     
+     August 13, 1982               - 1 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     1.2.  COMMUNICATION FRAMEWORK
+     
           Messages consist of lines of text.   No  special  provisions
      are  made for encoding drawings, facsimile, speech, or structured
      text.  No significant consideration has been given  to  questions
@@ -245,28 +385,28 @@
      and the standard tends to be free with the number  of  bits  con-
      sumed.   For  example,  field  names  are specified as free text,
      rather than special terse codes.
-
+     
           A general "memo" framework is used.  That is, a message con-
      sists of some information in a rigid format, followed by the main
      part of the message, with a format that is not specified in  this
      document.   The  syntax of several fields of the rigidly-formated
      ("headers") section is defined in  this  specification;  some  of
      these fields must be included in all messages.
-
+     
           The syntax  that  distinguishes  between  header  fields  is
      specified  separately  from  the  internal  syntax for particular
      fields.  This separation is intended to allow simple  parsers  to
      operate on the general structure of messages, without concern for
      the detailed structure of individual header fields.   Appendix  B
      is provided to facilitate construction of these parsers.
-
+     
           In addition to the fields specified in this document, it  is
      expected  that  other fields will gain common use.  As necessary,
      the specifications for these "extension-fields" will be published
      through  the same mechanism used to publish this document.  Users
      may also  wish  to  extend  the  set  of  fields  that  they  use
      privately.  Such "user-defined fields" are permitted.
-
+     
           The framework severely constrains document tone and  appear-
      ance and is primarily useful for most intra-organization communi-
      cations and  well-structured   inter-organization  communication.
@@ -282,83 +422,77 @@
      message's appearance.  The amount of actual control available  to
      message  receivers  is  contingent upon the capabilities of their
      individual message systems.
-
-
-
-
-
-     August 13, 1982               - 2 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     2.  NOTATIONAL CONVENTIONS
-
+     
+     
+     
+     
+     
+     August 13, 1982               - 2 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     2.  NOTATIONAL CONVENTIONS
+     
           This specification uses an augmented Backus-Naur Form  (BNF)
      notation.  The differences from standard BNF involve naming rules
      and indicating repetition and "local" alternatives.
-
-     2.1.  RULE NAMING
-
-          Angle brackets ("<", ">") are not  used,  in  general.   The
-     name  of  a rule is simply the name itself, rather than "".
+     
+     2.1.  RULE NAMING
+     
+          Angle brackets ("<", ">") are not  used,  in  general.   The
+     name  of  a rule is simply the name itself, rather than "<name>".
      Quotation-marks enclose literal text (which may be  upper  and/or
      lower  case).   Certain  basic  rules  are  in uppercase, such as
      SPACE, TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used  in
      rule  definitions,  and  in  the rest of this  document, whenever
      their presence will facilitate discerning the use of rule names.
-
-     2.2.  RULE1 / RULE2:  ALTERNATIVES
-
+     
+     2.2.  RULE1 / RULE2:  ALTERNATIVES
+     
           Elements separated by slash ("/") are alternatives.   There-
      fore "foo / bar" will accept foo or bar.
-
-     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
-
+     
+     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
+     
           Elements enclosed in parentheses are  treated  as  a  single
      element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
      sequences "elem foo elem" and "elem bar elem".
-
-     2.4.  *RULE:  REPETITION
-
+     
+     2.4.  *RULE:  REPETITION
+     
           The character "*" preceding an element indicates repetition.
      The full form is:
-
-                              *element
-
-     indicating at least  and at most  occurrences  of  element.
+     
+                              <l>*<m>element
+     
+     indicating at least <l> and at most <m> occurrences  of  element.
      Default values are 0 and infinity so that "*(element)" allows any
      number, including zero; "1*element" requires at  least  one;  and
      "1*2element" allows one or two.
-
-     2.5.  [RULE]:  OPTIONAL
-
+     
+     2.5.  [RULE]:  OPTIONAL
+     
           Square brackets enclose optional elements; "[foo  bar]"   is
      equivalent to "*1(foo bar)".
-
-     2.6.  NRULE:  SPECIFIC REPETITION
-
-          "(element)" is equivalent to "*(element)"; that is,
-     exactly    occurrences  of (element). Thus 2DIGIT is a 2-digit
+     
+     2.6.  NRULE:  SPECIFIC REPETITION
+     
+          "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
+     exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
      number, and 3ALPHA is a string of three alphabetic characters.
-
-
-     August 13, 1982               - 3 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     2.7.  #RULE:  LISTS
-
+     
+     
+     August 13, 1982               - 3 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     2.7.  #RULE:  LISTS
+     
           A construct "#" is defined, similar to "*", as follows:
-
-                              #element
-
-     indicating at least  and at most  elements, each  separated
+     
+                              <l>#<m>element
+     
+     indicating at least <l> and at most <m> elements, each  separated
      by  one  or more commas (","). This makes the usual form of lists
      very easy; a rule such as '(element *("," element))' can be shown
      as  "1#element".   Wherever this construct is used, null elements
@@ -369,58 +503,55 @@
      Default values are 0 and infinity so that "#(element)" allows any
      number,  including  zero;  "1#element" requires at least one; and
      "1#2element" allows one or two.
-
-     2.8.  ; COMMENTS
-
+     
+     2.8.  ; COMMENTS
+     
           A semi-colon, set off some distance to  the  right  of  rule
      text,  starts  a comment that continues to the end of line.  This
      is a simple way of including useful notes in  parallel  with  the
      specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982               - 4 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     3.  LEXICAL ANALYSIS OF MESSAGES
-
-     3.1.  GENERAL DESCRIPTION
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982               - 4 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     3.  LEXICAL ANALYSIS OF MESSAGES
+     
+     3.1.  GENERAL DESCRIPTION
+     
           A message consists of header fields and, optionally, a body.
      The  body  is simply a sequence of lines containing ASCII charac-
      ters.  It is separated from the headers by a null line  (i.e.,  a
      line with nothing preceding the CRLF).
-
-     3.1.1.  LONG HEADER FIELDS
-
+     
+     3.1.1.  LONG HEADER FIELDS
+     
         Each header field can be viewed as a single, logical  line  of
         ASCII  characters,  comprising  a field-name and a field-body.
         For convenience, the field-body  portion  of  this  conceptual
@@ -429,49 +560,46 @@
         may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
         immediately followed by AT LEAST one LWSP-char may instead  be
         inserted.  Thus, the single line
-
-            To:  "Joe & J. Harvey" , JJV @ BBN
-
+     
+            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
+     
         can be represented as:
-
-            To:  "Joe & J. Harvey" ,
+     
+            To:  "Joe & J. Harvey" <ddd @ Org>,
                     JJV@BBN
-
+     
         and
-
-            To:  "Joe & J. Harvey"
-                            , JJV
+     
+            To:  "Joe & J. Harvey"
+                            <ddd@ Org>, JJV
              @BBN
-
+     
         and
-
-            To:  "Joe &
-             J. Harvey" , JJV @ BBN
-
+     
+            To:  "Joe &
+             J. Harvey" <ddd @ Org>, JJV @ BBN
+     
              The process of moving  from  this  folded   multiple-line
         representation  of a header field to its single line represen-
         tation is called "unfolding".  Unfolding  is  accomplished  by
         regarding   CRLF   immediately  followed  by  a  LWSP-char  as
         equivalent to the LWSP-char.
-
+     
         Note:  While the standard  permits  folding  wherever  linear-
                white-space is permitted, it is recommended that struc-
                tured fields, such as those containing addresses, limit
                folding  to higher-level syntactic breaks.  For address
                fields, it  is  recommended  that  such  folding  occur
-
-
-     August 13, 1982               - 5 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982               - 5 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
                between addresses, after the separating comma.
-
-     3.1.2.  STRUCTURE OF HEADER FIELDS
-
+     
+     3.1.2.  STRUCTURE OF HEADER FIELDS
+     
         Once a field has been unfolded, it may be viewed as being com-
         posed of a field-name followed by a colon (":"), followed by a
         field-body, and  terminated  by  a  carriage-return/line-feed.
@@ -481,33 +609,33 @@
         ASCII characters, except CR or LF.  (While CR and/or LF may be
         present  in the actual text, they are removed by the action of
         unfolding the field.)
-
+     
         Certain field-bodies of headers may be  interpreted  according
         to  an  internal  syntax  that some systems may wish to parse.
         These  fields  are  called  "structured   fields".    Examples
         include  fields containing dates and addresses.  Other fields,
         such as "Subject"  and  "Comments",  are  regarded  simply  as
         strings of text.
-
+     
         Note:  Any field which has a field-body  that  is  defined  as
-               other  than  simply  is to be treated as a struc-
+               other  than  simply <text> is to be treated as a struc-
                tured field.
-
+     
                Field-names, unstructured field bodies  and  structured
                field bodies each are scanned by their own, independent
                "lexical" analyzers.
-
-     3.1.3.  UNSTRUCTURED FIELD BODIES
-
+     
+     3.1.3.  UNSTRUCTURED FIELD BODIES
+     
         For some fields, such as "Subject" and "Comments",  no  struc-
-        turing  is assumed, and they are treated simply as s, as
+        turing  is assumed, and they are treated simply as <text>s, as
         in the message body.  Rules of folding apply to these  fields,
         so  that  such  field  bodies  which occupy several lines must
         therefore have the second and successive lines indented by  at
         least one LWSP-char.
-
-     3.1.4.  STRUCTURED FIELD BODIES
-
+     
+     3.1.4.  STRUCTURED FIELD BODIES
+     
         To aid in the creation and reading of structured  fields,  the
         free  insertion   of linear-white-space (which permits folding
         by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
@@ -517,26 +645,23 @@
         This analyzer does not apply  for  unstructured  field  bodies
         that  are  simply  strings  of  text, as described above.  The
         analyzer provides  an  interpretation  of  the  unfolded  text
-
-
-     August 13, 1982               - 6 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982               - 6 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         composing  the body of the field as a sequence of lexical sym-
         bols.
-
+     
         These symbols are:
-
+     
                      -  individual special characters
                      -  quoted-strings
                      -  domain-literals
                      -  comments
                      -  atoms
-
+     
         The first four of these symbols  are  self-delimiting.   Atoms
         are not; they are delimited by the self-delimiting symbols and
         by  linear-white-space.   For  the  purposes  of  regenerating
@@ -544,48 +669,45 @@
         assumed to exist, and should be used, between them.  (Also, in
         the "Clarifications" section on "White Space", below, note the
         rules about treatment of multiple contiguous LWSP-chars.)
-
+     
         So, for example, the folded body of an address field
-
+     
             ":sysmail"@  Some-Group. Some-Org,
             Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982               - 7 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982               - 7 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         is analyzed into the following lexical symbols and types:
-
+     
                     :sysmail              quoted string
                     @                     special
                     Some-Group            atom
@@ -601,249 +723,237 @@
                     Vegas                 atom
                     .                     special
                     WBA                   atom
-
-        The canonical representations for the data in these  addresses
-        are the following strings:
-
-                        ":sysmail"@Some-Group.Some-Org
-
-        and
-
-                            Muhammed.Ali@Vegas.WBA
-
-        Note:  For purposes of display, and when passing  such  struc-
-               tured information to other systems, such as mail proto-
-               col  services,  there  must  be  NO  linear-white-space
-               between  s  that are separated by period (".") or
-               at-sign ("@") and exactly one SPACE between  all  other
-               s.  Also, headers should be in a folded form.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982               - 8 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     3.2.  HEADER FIELD DEFINITIONS
-
-          These rules show a field meta-syntax, without regard for the
-     particular  type  or internal syntax.  Their purpose is to permit
-     detection of fields; also, they present to  higher-level  parsers
-     an image of each field as fitting on one line.
-
-     field       =  field-name ":" [ field-body ] CRLF
-
-     field-name  =  1*
-
-     field-body  =  field-body-contents
-                    [CRLF LWSP-char field-body]
-
-     field-body-contents =
-                   
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982               - 9 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     3.3.  LEXICAL TOKENS
-
+     
+        The canonical representations for the data in these  addresses
+        are the following strings:
+     
+                        ":sysmail"@Some-Group.Some-Org
+     
+        and
+     
+                            Muhammed.Ali@Vegas.WBA
+     
+        Note:  For purposes of display, and when passing  such  struc-
+               tured information to other systems, such as mail proto-
+               col  services,  there  must  be  NO  linear-white-space
+               between  <word>s  that are separated by period (".") or
+               at-sign ("@") and exactly one SPACE between  all  other
+               <word>s.  Also, headers should be in a folded form.
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982               - 8 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     3.2.  HEADER FIELD DEFINITIONS
+     
+          These rules show a field meta-syntax, without regard for the
+     particular  type  or internal syntax.  Their purpose is to permit
+     detection of fields; also, they present to  higher-level  parsers
+     an image of each field as fitting on one line.
+     
+     field       =  field-name ":" [ field-body ] CRLF
+     
+     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+     
+     field-body  =  field-body-contents
+                    [CRLF LWSP-char field-body]
+     
+     field-body-contents =
+                   <the ASCII characters making up the field-body, as
+                    defined in the following sections, and consisting
+                    of combinations of atom, quoted-string, and
+                    specials tokens, or else consisting of texts>
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982               - 9 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     3.3.  LEXICAL TOKENS
+     
           The following rules are used to define an underlying lexical
      analyzer,  which  feeds  tokens to higher level parsers.  See the
      ANSI references, in the Bibliography.
-
+     
                                                  ; (  Octal, Decimal.)
-     CHAR        =          ; (  0-177,  0.-127.)
-     ALPHA       =  
+     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
+     ALPHA       =  <any ASCII alphabetic character>
                                                  ; (101-132, 65.- 90.)
                                                  ; (141-172, 97.-122.)
-     DIGIT       =      ; ( 60- 71, 48.- 57.)
-     CTL         =            ; (    177,     127.)
-     CR          =    ; (     15,      13.)
-     LF          =           ; (     12,      10.)
-     SPACE       =              ; (     40,      32.)
-     HTAB        =     ; (     11,       9.)
-     <">         =             ; (     42,      34.)
+     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
+     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
+                     character and DEL>          ; (    177,     127.)
+     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
+     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
+     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
+     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+     <">         =  <ASCII quote mark>           ; (     42,      34.)
      CRLF        =  CR LF
-
+     
      LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
-
+     
      linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
-                                                 ; CRLF => folding
-
-     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
-                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
+                                                 ; CRLF => folding
+     
+     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
+                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
                  /  "." / "[" / "]"              ;  within a word.
-
+     
      delimiters  =  specials / linear-white-space / comment
-
-     text        =   atoms, specials,
-                     CR & bare LF, but NOT       ;  comments and
-                     including CRLF>             ;  quoted-strings are
+     
+     text        =  <any CHAR, including bare    ; => atoms, specials,
+                     CR & bare LF, but NOT       ;  comments and
+                     including CRLF>             ;  quoted-strings are
                                                  ;  NOT recognized.
-
-     atom        =  1*
-
-     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+     
+     atom        =  1*<any CHAR except specials, SPACE and CTLs>
+     
+     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                  ;   quoted chars.
-
-     qtext       =  ,     ; => may be folded
-                     "\" & CR, and including
-                     linear-white-space>
-
+     
+     qtext       =  <any CHAR excepting <">,     ; => may be folded
+                     "\" & CR, and including
+                     linear-white-space>
+     
      domain-literal =  "[" *(dtext / quoted-pair) "]"
-
-
-
-
-     August 13, 1982              - 10 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     dtext       =   may be folded
-                     "]", "\" & CR, & including
-                     linear-white-space>
-
+     
+     
+     
+     
+     August 13, 1982              - 10 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     dtext       =  <any CHAR excluding "[",     ; => may be folded
+                     "]", "\" & CR, & including
+                     linear-white-space>
+     
      comment     =  "(" *(ctext / quoted-pair / comment) ")"
-
-     ctext       =   may be folded
-                     ")", "\" & CR, & including
-                     linear-white-space>
-
+     
+     ctext       =  <any CHAR excluding "(",     ; => may be folded
+                     ")", "\" & CR, & including
+                     linear-white-space>
+     
      quoted-pair =  "\" CHAR                     ; may quote any char
-
+     
      phrase      =  1*word                       ; Sequence of words
-
+     
      word        =  atom / quoted-string
-
-
-     3.4.  CLARIFICATIONS
-
-     3.4.1.  QUOTING
-
+     
+     
+     3.4.  CLARIFICATIONS
+     
+     3.4.1.  QUOTING
+     
         Some characters are reserved for special interpretation,  such
         as  delimiting lexical tokens.  To permit use of these charac-
         ters as uninterpreted data, a quoting mechanism  is  provided.
         To quote a character, precede it with a backslash ("\").
-
+     
         This mechanism is not fully general.  Characters may be quoted
         only  within  a subset of the lexical constructs.  In particu-
         lar, quoting is limited to use within:
-
+     
                              -  quoted-string
                              -  domain-literal
                              -  comment
-
+     
         Within these constructs, quoting is REQUIRED for  CR  and  "\"
         and for the character(s) that delimit the token (e.g., "(" and
         ")" for a comment).  However, quoting  is  PERMITTED  for  any
         character.
-
+     
         Note:  In particular, quoting is NOT permitted  within  atoms.
                For  example  when  the local-part of an addr-spec must
                contain a special character, a quoted  string  must  be
                used.  Therefore, a specification such as:
-
+     
                             Full\ Name@Domain
-
+     
                is not legal and must be specified as:
-
+     
                             "Full Name"@Domain
-
-
-     August 13, 1982              - 11 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     3.4.2.  WHITE SPACE
-
+     
+     
+     August 13, 1982              - 11 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     3.4.2.  WHITE SPACE
+     
         Note:  In structured field bodies, multiple linear space ASCII
                characters  (namely  HTABs  and  SPACEs) are treated as
                single spaces and may freely surround any  symbol.   In
                all header fields, the only place in which at least one
                LWSP-char is REQUIRED is at the beginning of  continua-
                tion lines in a folded field.
-
+     
         When passing text to processes  that  do  not  interpret  text
         according to this standard (e.g., mail protocol servers), then
         NO linear-white-space characters should occur between a period
-        (".") or at-sign ("@") and a .  Exactly ONE SPACE should
+        (".") or at-sign ("@") and a <word>.  Exactly ONE SPACE should
         be used in place of arbitrary linear-white-space  and  comment
         sequences.
-
+     
         Note:  Within systems conforming to this standard, wherever  a
                member of the list of delimiters is allowed, LWSP-chars
                may also occur before and/or after it.
-
+     
         Writers of  mail-sending  (i.e.,  header-generating)  programs
         should realize that there is no network-wide definition of the
         effect of ASCII HT (horizontal-tab) characters on the  appear-
         ance  of  text  at another network host; therefore, the use of
         tabs in message headers, though permitted, is discouraged.
-
-     3.4.3.  COMMENTS
-
+     
+     3.4.3.  COMMENTS
+     
         A comment is a set of ASCII characters, which is  enclosed  in
         matching  parentheses  and which is not within a quoted-string
         The comment construct permits message originators to add  text
@@ -853,7 +963,7 @@
         this standard.  However, comments  must  NOT  be  included  in
         other  cases,  such  as  during  protocol  exchanges with mail
         servers.
-
+     
         Comments nest, so that if an unquoted left parenthesis  occurs
         in  a  comment  string,  there  must  also be a matching right
         parenthesis.  When a comment acts as the delimiter  between  a
@@ -862,18 +972,15 @@
         regenerating  the  sequence, such as when passing the sequence
         onto a mail protocol server.  Comments are  detected  as  such
         only within field-bodies of structured fields.
-
+     
         If a comment is to be "folded" onto multiple lines,  then  the
         syntax  for  folding  must  be  adhered to.  (See the "Lexical
-
-
-     August 13, 1982              - 12 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 12 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         Analysis of Messages" section on "Folding Long Header  Fields"
         above,  and  the  section on "Case Independence" below.)  Note
         that  the  official  semantics  therefore  do  not  "see"  any
@@ -884,9 +991,9 @@
         kept  and  the  LWSP-char is discarded.  Quoted CRLFs (i.e., a
         backslash followed by a CR followed by a  LF)  still  must  be
         followed by at least one LWSP-char.
-
-     3.4.4.  DELIMITING AND QUOTING CHARACTERS
-
+     
+     3.4.4.  DELIMITING AND QUOTING CHARACTERS
+     
         The quote character (backslash) and  characters  that  delimit
         syntactic  units  are not, generally, to be taken as data that
         are part of the delimited or quoted unit(s).   In  particular,
@@ -902,36 +1009,33 @@
         MUST be quoted to be included as data.  These  characters  are
         the  ones that are not part of the alternate text group (i.e.,
         ctext or qtext).
-
+     
         The one exception to this rule  is  that  a  single  SPACE  is
         assumed  to  exist  between  contiguous words in a phrase, and
         this interpretation is independent of  the  actual  number  of
         LWSP-chars  that  the  creator  places  between the words.  To
         include more than one SPACE, the creator must make  the  LWSP-
         chars be part of a quoted-string.
-
+     
         Quotation marks that delimit a quoted string  and  backslashes
         that  quote  the  following character should NOT accompany the
         quoted-string when the string is passed to processes  that  do
         not interpret data according to this specification (e.g., mail
         protocol servers).
-
-     3.4.5.  QUOTED-STRINGS
-
+     
+     3.4.5.  QUOTED-STRINGS
+     
         Where permitted (i.e., in words in structured fields)  quoted-
         strings  are  treated  as a single symbol.  That is, a quoted-
         string is equivalent to an atom, syntactically.  If a  quoted-
         string  is to be "folded" onto multiple lines, then the syntax
         for folding must be adhered to.  (See the "Lexical Analysis of
-
-
-     August 13, 1982              - 13 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 13 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         Messages"  section  on "Folding Long Header Fields" above, and
         the section on "Case  Independence"  below.)   Therefore,  the
         official  semantics  do  not  "see" any bare CRLFs that are in
@@ -945,76 +1049,73 @@
         explicitly  indicates  that  the  CRLF  is  data to the quoted
         string.  Stripping off the first following LWSP-char  is  also
         appropriate when parsing quoted CRLFs.
-
-     3.4.6.  BRACKETING CHARACTERS
-
+     
+     3.4.6.  BRACKETING CHARACTERS
+     
         There is one type of bracket which must occur in matched pairs
         and may have pairs nested within each other:
-
+     
             o   Parentheses ("(" and ")") are used  to  indicate  com-
                 ments.
-
+     
         There are three types of brackets which must occur in  matched
         pairs, and which may NOT be nested:
-
+     
             o   Colon/semi-colon (":" and ";") are   used  in  address
                 specifications  to  indicate that the included list of
                 addresses are to be treated as a group.
-
-            o   Angle brackets ("<" and ">")  are  generally  used  to
+     
+            o   Angle brackets ("<" and ">")  are  generally  used  to
                 indicate  the  presence of a one machine-usable refer-
                 ence (e.g., delimiting mailboxes), possibly  including
                 source-routing to the machine.
-
+     
             o   Square brackets ("[" and "]") are used to indicate the
                 presence  of  a  domain-literal, which the appropriate
                 name-domain  is  to  use  directly,  bypassing  normal
                 name-resolution mechanisms.
-
-     3.4.7.  CASE INDEPENDENCE
-
+     
+     3.4.7.  CASE INDEPENDENCE
+     
         Except as noted, alphabetic strings may be represented in  any
         combination of upper and lower case.  The only syntactic units
-
-
-
-
-
-
-
-
-     August 13, 1982              - 14 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 14 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         which requires preservation of case information are:
-
+     
                     -  text
                     -  qtext
                     -  dtext
                     -  ctext
                     -  quoted-pair
                     -  local-part, except "Postmaster"
-
+     
         When matching any other syntactic unit, case is to be ignored.
         For  example, the field-names "From", "FROM", "from", and even
         "FroM" are semantically equal and should all be treated ident-
         ically.
-
+     
         When generating these units, any mix of upper and  lower  case
         alphabetic  characters  may  be  used.  The case shown in this
         specification is suggested for message-creating processes.
-
+     
         Note:  The reserved local-part address unit, "Postmaster",  is
                an  exception.   When  the  value "Postmaster" is being
                interpreted, it must be  accepted  in  any  mixture  of
                case, including "POSTMASTER", and "postmaster".
-
-     3.4.8.  FOLDING LONG HEADER FIELDS
-
+     
+     3.4.8.  FOLDING LONG HEADER FIELDS
+     
         Each header field may be represented on exactly one line  con-
         sisting  of the name of the field and its body, and terminated
         by a CRLF; this is what the parser sees.  For readability, the
@@ -1024,58 +1125,55 @@
         length serves as a limit, when the message is to be viewed  on
         most  simple terminals which use simple display software; how-
         ever, the limit is not imposed by this standard.
-
+     
         Note:  Some display software often can selectively fold lines,
                to  suit  the display terminal.  In such cases, sender-
                provided  folding  can  interfere  with   the   display
                software.
-
-     3.4.9.  BACKSPACE CHARACTERS
-
+     
+     3.4.9.  BACKSPACE CHARACTERS
+     
         ASCII BS characters (Backspace, decimal 8) may be included  in
         texts and quoted-strings to effect overstriking.  However, any
         use of backspaces which effects an overstrike to the  left  of
         the beginning of the text or quoted-string is prohibited.
-
-
-
-
-
-     August 13, 1982              - 15 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
-
+     
+     
+     
+     
+     
+     August 13, 1982              - 15 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
+     
         During transmission through heterogeneous networks, it may  be
         necessary  to  force data to conform to a network's local con-
         ventions.  For example, it may be required that a CR  be  fol-
-        lowed  either by LF, making a CRLF, or by , if the CR is
+        lowed  either by LF, making a CRLF, or by <null>, if the CR is
         to stand alone).  Such transformations are reversed, when  the
         message exits that network.
-
+     
         When  crossing  network  boundaries,  the  message  should  be
         treated  as  passing  through  two modules.  It will enter the
         first module containing whatever network-specific  transforma-
         tions  that  were  necessary  to  permit migration through the
         "current" network.  It then passes through the modules:
-
+     
             o   Transformation Reversal
-
+     
                 The "current" network's idiosyncracies are removed and
                 the  message  is returned to the canonical form speci-
                 fied in this standard.
-
+     
             o   Transformation
-
+     
                 The "next" network's local idiosyncracies are  imposed
                 on the message.
-
+     
                                 ------------------
-                    From   ==>  | Remove Net-A   |
+                    From   ==>  | Remove Net-A   |
                     Net-A       | idiosyncracies |
                                 ------------------
                                        ||
@@ -1085,31 +1183,28 @@
                                        ||
                                        \/
                                 ------------------
-                                | Impose Net-B   |  ==>  To
+                                | Impose Net-B   |  ==>  To
                                 | idiosyncracies |       Net-B
                                 ------------------
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - 16 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     4.  MESSAGE SPECIFICATION
-
-     4.1.  SYNTAX
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 16 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     4.  MESSAGE SPECIFICATION
+     
+     4.1.  SYNTAX
+     
      Note:  Due to an artifact of the notational conventions, the syn-
             tax  indicates that, when present, some fields, must be in
             a particular order.  Header fields  are  NOT  required  to
@@ -1118,36 +1213,36 @@
             that,  if  present,  headers be sent in the order "Return-
             Path", "Received", "Date",  "From",  "Subject",  "Sender",
             "To", "cc", etc.
-
+     
             This specification permits multiple  occurrences  of  most
             fields.   Except  as  noted,  their  interpretation is not
             specified here, and their use is discouraged.
-
+     
           The following syntax for the bodies of various fields should
      be  thought  of  as  describing  each field body as a single long
      string (or line).  The "Lexical Analysis of Message"  section  on
      "Long  Header Fields", above, indicates how such long strings can
      be represented on more than one line in  the  actual  transmitted
      message.
-
+     
      message     =  fields *( CRLF *text )       ; Everything after
                                                  ;  first null line
                                                  ;  is message body
-
+     
      fields      =    dates                      ; Creation time,
-                      source                     ;  author id & one
+                      source                     ;  author id & one
                     1*destination                ;  address required
                      *optional-field             ;  others optional
-
+     
      source      = [  trace ]                    ; net traversals
                       originator                 ; original mail
                    [  resent ]                   ; forwarded
-
+     
      trace       =    return                     ; path to sender
                     1*received                   ; receipt tags
-
+     
      return      =  "Return-path" ":" route-addr ; return address
-
+     
      received    =  "Received"    ":"            ; one per relay
                        ["from" domain]           ; sending host
                        ["by"   domain]           ; receiving host
@@ -1155,47 +1250,44 @@
                       *("with" atom)             ; link/mail protocol
                        ["id"   msg-id]           ; receiver msg id
                        ["for"  addr-spec]        ; initial form
-
-
-     August 13, 1982              - 17 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 17 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
                         ";"    date-time         ; time received
-
+     
      originator  =   authentic                   ; authenticated addr
                    [ "Reply-To"   ":" 1#address] )
-
+     
      authentic   =   "From"       ":"   mailbox  ; Single author
                  / ( "Sender"     ":"   mailbox  ; Actual submittor
                      "From"       ":" 1#mailbox) ; Multiple authors
                                                  ;  or not sender
-
+     
      resent      =   resent-authentic
                    [ "Resent-Reply-To"  ":" 1#address] )
-
+     
      resent-authentic =
                  =   "Resent-From"      ":"   mailbox
                  / ( "Resent-Sender"    ":"   mailbox
                      "Resent-From"      ":" 1#mailbox  )
-
+     
      dates       =   orig-date                   ; Original
                    [ resent-date ]               ; Forwarded
-
+     
      orig-date   =  "Date"        ":"   date-time
-
+     
      resent-date =  "Resent-Date" ":"   date-time
-
+     
      destination =  "To"          ":" 1#address  ; Primary
                  /  "Resent-To"   ":" 1#address
                  /  "cc"          ":" 1#address  ; Secondary
                  /  "Resent-cc"   ":" 1#address
                  /  "bcc"         ":"  #address  ; Blind carbon
                  /  "Resent-bcc"  ":"  #address
-
+     
      optional-field =
                  /  "Message-ID"        ":"   msg-id
                  /  "Resent-Message-ID" ":"   msg-id
@@ -1207,41 +1299,38 @@
                  /  "Encrypted"         ":" 1#2word
                  /  extension-field              ; To be defined
                  /  user-defined-field           ; May be pre-empted
-
-     msg-id      =  "<" addr-spec ">"            ; Unique message id
-
-
-
-
-
-
-     August 13, 1982              - 18 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     msg-id      =  "<" addr-spec ">"            ; Unique message id
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 18 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
      extension-field =
-                   
-
+                    with the string "X-">
+     
      user-defined-field =
-                   
-
-     4.2.  FORWARDING
-
+                    pre-empted by published extensions>
+     
+     4.2.  FORWARDING
+     
           Some systems permit mail recipients to  forward  a  message,
      retaining  the original headers, by adding some new fields.  This
      standard supports such a service, through the "Resent-" prefix to
      field names.
-
+     
           Whenever the string "Resent-" begins a field name, the field
      has  the  same  semantics as a field whose name does not have the
      prefix.  However, the message is assumed to have  been  forwarded
@@ -1250,70 +1339,67 @@
      original  field.   For  example, the "Resent-From", indicates the
      person that forwarded the message, whereas the "From" field indi-
      cates the original author.
-
+     
           Use of such precedence  information  depends  upon  partici-
      pants'  communication needs.  For example, this standard does not
      dictate when a "Resent-From:" address should receive replies,  in
      lieu of sending them to the "From:" address.
-
+     
      Note:  In general, the "Resent-" fields should be treated as con-
             taining  a  set  of information that is independent of the
             set of original fields.  Information for  one  set  should
             not  automatically be taken from the other.  The interpre-
             tation of multiple "Resent-" fields, of the same type,  is
             undefined.
-
+     
           In the remainder of this specification, occurrence of  legal
      "Resent-"  fields  are treated identically with the occurrence of
-
-
-
-
-
-
-
-
-     August 13, 1982              - 19 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 19 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
      fields whose names do not contain this prefix.
-
-     4.3.  TRACE FIELDS
-
+     
+     4.3.  TRACE FIELDS
+     
           Trace information is used to provide an audit trail of  mes-
      sage  handling.   In  addition,  it indicates a route back to the
      sender of the message.
-
+     
           The list of known "via" and  "with"  values  are  registered
      with  the  Network  Information  Center, SRI International, Menlo
      Park, California.
-
-     4.3.1.  RETURN-PATH
-
+     
+     4.3.1.  RETURN-PATH
+     
         This field  is  added  by  the  final  transport  system  that
         delivers  the message to its recipient.  The field is intended
         to contain definitive information about the address and  route
         back to the message's originator.
-
+     
         Note:  The "Reply-To" field is added  by  the  originator  and
                serves  to  direct  replies,  whereas the "Return-Path"
                field is used to identify a path back to  the  origina-
                tor.
-
+     
         While the syntax  indicates  that  a  route  specification  is
         optional,  every attempt should be made to provide that infor-
         mation in this field.
-
-     4.3.2.  RECEIVED
-
+     
+     4.3.2.  RECEIVED
+     
         A copy of this field is added by each transport  service  that
         relays the message.  The information in the field can be quite
         useful for tracing transport problems.
-
+     
         The names of the sending  and  receiving  hosts  and  time-of-
         receipt may be specified.  The "via" parameter may be used, to
         indicate what physical mechanism the message  was  sent  over,
@@ -1321,37 +1407,34 @@
         used to indicate the mail-,  or  connection-,  level  protocol
         that  was  used, such as the SMTP mail protocol, or X.25 tran-
         sport protocol.
-
+     
         Note:  Several "with" parameters may  be  included,  to  fully
                specify the set of protocols that were used.
-
+     
         Some transport services queue mail; the internal message iden-
         tifier that is assigned to the message may be noted, using the
         "id" parameter.  When the  sending  host  uses  a  destination
         address specification that the receiving host reinterprets, by
-
-
-     August 13, 1982              - 20 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 20 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         expansion or transformation, the receiving host  may  wish  to
         record  the original specification, using the "for" parameter.
         For example, when a copy of mail is sent to the  member  of  a
         distribution  list,  this  parameter may be used to record the
         original address that was used to specify the list.
-
-     4.4.  ORIGINATOR FIELDS
-
+     
+     4.4.  ORIGINATOR FIELDS
+     
           The standard allows only a subset of the combinations possi-
      ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
      and Resent-Reply-To fields.  The limitation is intentional.
-
-     4.4.1.  FROM / RESENT-FROM
-
+     
+     4.4.1.  FROM / RESENT-FROM
+     
         This field contains the identity of the person(s)  who  wished
         this  message to be sent.  The message-creation process should
         default this field  to  be  a  single,  authenticated  machine
@@ -1362,9 +1445,9 @@
         "From"  field.   In  all  cases, addresses in the "From" field
         must be machine-usable (addr-specs) and may not contain  named
         lists (groups).
-
-     4.4.2.  SENDER / RESENT-SENDER
-
+     
+     4.4.2.  SENDER / RESENT-SENDER
+     
         This field contains the authenticated identity  of  the  AGENT
         (person,  system  or  process)  that sends the message.  It is
         intended for use when the sender is not the author of the mes-
@@ -1374,7 +1457,7 @@
         "Sender" field need not be present and its use is  discouraged
         (though  still legal).  In particular, the "Sender" field MUST
         be present if it is NOT the same as the "From" Field.
-
+     
         The Sender mailbox  specification  includes  a  word  sequence
         which  must correspond to a specific agent (i.e., a human user
         or a computer program) rather than a standard  address.   This
@@ -1387,15 +1470,12 @@
         expected to be a computer system term, and not (for example) a
         generalized person reference which can  be  used  outside  the
         network text message context.
-
-
-     August 13, 1982              - 21 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 21 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         Since the critical function served by the  "Sender"  field  is
         identification  of  the agent responsible for sending mail and
         since computer programs cannot be held accountable  for  their
@@ -1403,9 +1483,9 @@
         gram generates a message, the HUMAN  who  is  responsible  for
         that program be referenced as part of the "Sender" field mail-
         box specification.
-
-     4.4.3.  REPLY-TO / RESENT-REPLY-TO
-
+     
+     4.4.3.  REPLY-TO / RESENT-REPLY-TO
+     
         This field provides a general  mechanism  for  indicating  any
         mailbox(es)  to which responses are to be sent.  Three typical
         uses for this feature can  be  distinguished.   In  the  first
@@ -1420,70 +1500,67 @@
         then  participants  can  "reply"  to conference submissions to
         guarantee the correct distribution of any submission of  their
         own.
-
+     
         Note:  The "Return-Path" field is added by the mail  transport
                service,  at the time of final deliver.  It is intended
                to identify a path back to the orginator  of  the  mes-
                sage.   The  "Reply-To"  field  is added by the message
                originator and is intended to direct replies.
-
-     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
-
+     
+     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
+     
         For systems which automatically  generate  address  lists  for
         replies to messages, the following recommendations are made:
-
+     
             o   The "Sender" field mailbox should be sent  notices  of
                 any  problems in transport or delivery of the original
                 messages.  If there is no  "Sender"  field,  then  the
                 "From" field mailbox should be used.
-
+     
             o   The  "Sender"  field  mailbox  should  NEVER  be  used
                 automatically, in a recipient's reply message.
-
+     
             o   If the "Reply-To" field exists, then the reply  should
                 go to the addresses indicated in that field and not to
                 the address(es) indicated in the "From" field.
-
-
-
-
-     August 13, 1982              - 22 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     
+     
+     August 13, 1982              - 22 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
             o   If there is a "From" field, but no  "Reply-To"  field,
                 the  reply should be sent to the address(es) indicated
                 in the "From" field.
-
+     
         Sometimes, a recipient may actually wish to  communicate  with
         the  person  that  initiated  the  message  transfer.  In such
         cases, it is reasonable to use the "Sender" address.
-
+     
         This recommendation is intended  only  for  automated  use  of
         originator-fields  and is not intended to suggest that replies
         may not also be sent to other recipients of messages.   It  is
         up  to  the  respective  mail-handling programs to decide what
         additional facilities will be provided.
-
-        Examples are provided in Appendix A.
-
-     4.5.  RECEIVER FIELDS
-
-     4.5.1.  TO / RESENT-TO
-
+     
+        Examples are provided in Appendix A.
+     
+     4.5.  RECEIVER FIELDS
+     
+     4.5.1.  TO / RESENT-TO
+     
         This field contains the identity of the primary recipients  of
         the message.
-
-     4.5.2.  CC / RESENT-CC
-
+     
+     4.5.2.  CC / RESENT-CC
+     
         This field contains the identity of  the  secondary  (informa-
         tional) recipients of the message.
-
-     4.5.3.  BCC / RESENT-BCC
-
+     
+     4.5.3.  BCC / RESENT-BCC
+     
         This field contains the identity of additional  recipients  of
         the  message.   The contents of this field are not included in
         copies of the message sent to the primary and secondary  reci-
@@ -1491,106 +1568,100 @@
         "Bcc" field only in the author(s)'s  copy,  while  others  may
         also include it in the text sent to all those indicated in the
         "Bcc" list.
-
-     4.6.  REFERENCE FIELDS
-
-     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
-
+     
+     4.6.  REFERENCE FIELDS
+     
+     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
+     
              This field contains a unique identifier  (the  local-part
         address  unit)  which  refers to THIS version of THIS message.
         The uniqueness of the message identifier is guaranteed by  the
         host  which  generates  it.  This identifier is intended to be
-        machine readable and not necessarily meaningful to humans.   A
-        message  identifier pertains to exactly one instantiation of a
-        particular message; subsequent revisions to the message should
-
-
-     August 13, 1982              - 23 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+        machine readable and not necessarily meaningful to humans.   A
+        message  identifier pertains to exactly one instantiation of a
+        particular message; subsequent revisions to the message should
+     
+     
+     August 13, 1982              - 23 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         each receive new message identifiers.
-
-     4.6.2.  IN-REPLY-TO
-
+     
+     4.6.2.  IN-REPLY-TO
+     
              The contents of this field identify  previous  correspon-
         dence  which this message answers.  Note that if message iden-
         tifiers are used in this  field,  they  must  use  the  msg-id
         specification format.
-
-     4.6.3.  REFERENCES
-
+     
+     4.6.3.  REFERENCES
+     
              The contents of this field identify other  correspondence
         which  this message references.  Note that if message identif-
         iers are used, they must use the msg-id specification format.
-
-     4.6.4.  KEYWORDS
-
+     
+     4.6.4.  KEYWORDS
+     
              This field contains keywords  or  phrases,  separated  by
         commas.
-
-     4.7.  OTHER FIELDS
-
-     4.7.1.  SUBJECT
-
+     
+     4.7.  OTHER FIELDS
+     
+     4.7.1.  SUBJECT
+     
              This is intended to provide a summary,  or  indicate  the
         nature, of the message.
-
-     4.7.2.  COMMENTS
-
+     
+     4.7.2.  COMMENTS
+     
              Permits adding text comments  onto  the  message  without
         disturbing the contents of the message's body.
-
-     4.7.3.  ENCRYPTED
-
+     
+     4.7.3.  ENCRYPTED
+     
              Sometimes,  data  encryption  is  used  to  increase  the
         privacy  of  message  contents.   If the body of a message has
         been encrypted, to keep its contents private, the  "Encrypted"
         field  can be used to note the fact and to indicate the nature
-        of the encryption.  The first  parameter  indicates  the
+        of the encryption.  The first <word> parameter  indicates  the
         software  used  to  encrypt the body, and the second, optional
-         is intended to  aid  the  recipient  in  selecting  the
+        <word> is intended to  aid  the  recipient  in  selecting  the
         proper  decryption  key.   This  code word may be viewed as an
         index to a table of keys held by the recipient.
-
+     
         Note:  Unfortunately, headers must contain envelope,  as  well
                as  contents,  information.  Consequently, it is neces-
                sary that they remain unencrypted, so that  mail  tran-
                sport   services   may   access   them.   Since  names,
                addresses, and "Subject"  field  contents  may  contain
-
-
-     August 13, 1982              - 24 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 24 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
                sensitive  information,  this  requirement limits total
                message privacy.
-
+     
              Names of encryption software are registered with the Net-
         work  Information Center, SRI International, Menlo Park, Cali-
         fornia.
-
-     4.7.4.  EXTENSION-FIELD
-
+     
+     4.7.4.  EXTENSION-FIELD
+     
              A limited number of common fields have  been  defined  in
         this  document.   As  network mail requirements dictate, addi-
         tional fields may be standardized.   To  provide  user-defined
         fields  with  a  measure  of  safety,  in name selection, such
         extension-fields will never have names  that  begin  with  the
         string "X-".
-
+     
              Names of Extension-fields are registered with the Network
         Information Center, SRI International, Menlo Park, California.
-
-     4.7.5.  USER-DEFINED-FIELD
-
+     
+     4.7.5.  USER-DEFINED-FIELD
+     
              Individual users of network mail are free to  define  and
         use  additional  header  fields.   Such fields must have names
         which are not already used in the current specification or  in
@@ -1599,57 +1670,54 @@
         rules   for   delimiting  and  folding  fields.   Due  to  the
         extension-field  publishing  process,  the  name  of  a  user-
         defined-field may be pre-empted
-
+     
         Note:  The prefatory string "X-" will never  be  used  in  the
                names  of Extension-fields.  This provides user-defined
                fields with a protected set of names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - 25 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     5.  DATE AND TIME SPECIFICATION
-
-     5.1.  SYNTAX
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 25 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     5.  DATE AND TIME SPECIFICATION
+     
+     5.1.  SYNTAX
+     
      date-time   =  [ day "," ] date time        ; dd mm yy
                                                  ;  hh:mm:ss zzz
-
+     
      day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                  /  "Fri"  / "Sat" /  "Sun"
-
+     
      date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                  ;  e.g. 20 Jun 82
-
+     
      month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                  /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                  /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
-
+     
      time        =  hour zone                    ; ANSI and Military
-
+     
      hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                  ; 00:00:00 - 23:59:59
-
+     
      zone        =  "UT"  / "GMT"                ; Universal Time
                                                  ; North American : UT
                  /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
@@ -1661,12 +1729,12 @@
                                                  ;  M:-12; N:+1; Y:+12
                  / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                  ;  hours+min. (HHMM)
-
-     5.2.  SEMANTICS
-
+     
+     5.2.  SEMANTICS
+     
           If included, day-of-week must be the day implied by the date
      specification.
-
+     
           Time zone may be indicated in several ways.  "UT" is Univer-
      sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
      mitted as a reference to Universal Time.  The  military  standard
@@ -1677,49 +1745,46 @@
      from ANSI standard X3.51-1975.  One allows explicit indication of
      the amount of offset from UT; the other uses  common  3-character
      strings for indicating time zones in North America.
-
-
-     August 13, 1982              - 26 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     6.  ADDRESS SPECIFICATION
-
-     6.1.  SYNTAX
-
+     
+     
+     August 13, 1982              - 26 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     6.  ADDRESS SPECIFICATION
+     
+     6.1.  SYNTAX
+     
      address     =  mailbox                      ; one addressee
                  /  group                        ; named list
-
+     
      group       =  phrase ":" [#mailbox] ";"
-
+     
      mailbox     =  addr-spec                    ; simple address
-                 /  phrase route-addr            ; name & addr-spec
-
-     route-addr  =  "<" [route] addr-spec ">"
-
+                 /  phrase route-addr            ; name & addr-spec
+     
+     route-addr  =  "<" [route] addr-spec ">"
+     
      route       =  1#("@" domain) ":"           ; path-relative
-
+     
      addr-spec   =  local-part "@" domain        ; global address
-
+     
      local-part  =  word *("." word)             ; uninterpreted
                                                  ; case-preserved
-
+     
      domain      =  sub-domain *("." sub-domain)
-
+     
      sub-domain  =  domain-ref / domain-literal
-
+     
      domain-ref  =  atom                         ; symbolic reference
-
-     6.2.  SEMANTICS
-
+     
+     6.2.  SEMANTICS
+     
           A mailbox receives mail.  It is a  conceptual  entity  which
      does  not necessarily pertain to file storage.  For example, some
      sites may choose to print mail on their line printer and  deliver
      the output to the addressee's desk.
-
+     
           A mailbox specification comprises a person, system  or  pro-
      cess name reference, a domain-dependent string, and a name-domain
      reference.  The name reference is optional and is usually used to
@@ -1727,23 +1792,20 @@
      ence specifies a sequence of sub-domains.   The  domain-dependent
      string is uninterpreted, except by the final sub-domain; the rest
      of the mail service merely transmits it as a literal string.
-
-     6.2.1.  DOMAINS
-
+     
+     6.2.1.  DOMAINS
+     
         A name-domain is a set of registered (mail)  names.   A  name-
         domain  specification  resolves  to  a subordinate name-domain
         specification  or  to  a  terminal  domain-dependent   string.
         Hence,  domain  specification  is  extensible,  permitting any
         number of registration levels.
-
-
-     August 13, 1982              - 27 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 27 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         Name-domains model a global, logical, hierarchical  addressing
         scheme.   The  model is logical, in that an address specifica-
         tion is related to name registration and  is  not  necessarily
@@ -1752,32 +1814,32 @@
         path  from  the root of the tree to any node in the hierarchy.
         If more than one path actually exists, they are considered  to
         be different addresses.
-
+     
         The root node is common to all addresses; consequently, it  is
         not  referenced.   Its  children  constitute "top-level" name-
         domains.  Usually, a service has access to its own full domain
         specification and to the names of all top-level name-domains.
-
+     
         The "top" of the domain addressing hierarchy -- a child of the
         root  --  is  indicated  by  the right-most field, in a domain
         specification.  Its child is specified to the left, its  child
         to the left, and so on.
-
+     
         Some groups provide formal registration services;  these  con-
         stitute   name-domains   that  are  independent  logically  of
         specific machines.  In addition, networks and machines  impli-
         citly  compose name-domains, since their membership usually is
         registered in name tables.
-
+     
         In the case of formal registration, an organization implements
         a  (distributed)  data base which provides an address-to-route
         mapping service for addresses of the form:
-
+     
                          person@registry.organization
-
+     
         Note that "organization" is a logical  entity,  separate  from
         any particular communication network.
-
+     
         A mechanism for accessing "organization" is universally avail-
         able.   That mechanism, in turn, seeks an instantiation of the
         registry; its location is not indicated in the address specif-
@@ -1785,81 +1847,75 @@
         the name "organization" knows how to find a subordinate regis-
         try.  The registry will then use the "person" string to deter-
         mine where to send the mail specification.
-
+     
         The latter,  network-oriented  case  permits  simple,  direct,
         attachment-related address specification, such as:
-
+     
                               user@host.network
-
+     
         Once the network is accessed, it is expected  that  a  message
         will  go  directly  to the host and that the host will resolve
-
-
-     August 13, 1982              - 28 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 28 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         the user name, placing the message in the user's mailbox.
-
-     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
-
+     
+     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
+     
         Since any number of  levels  is  possible  within  the  domain
         hierarchy,  specification  of  a  fully  qualified address can
         become inconvenient.  This standard permits abbreviated domain
         specification, in a special case:
-
+     
             For the address of  the  sender,  call  the  left-most
             sub-domain  Level  N.   In a header address, if all of
             the sub-domains above (i.e., to the right of) Level  N
             are  the same as those of the sender, then they do not
             have to appear in the specification.   Otherwise,  the
             address must be fully qualified.
-
+     
             This feature is subject  to  approval  by  local  sub-
             domains.   Individual  sub-domains  may  require their
             member systems, which originate mail, to provide  full
             domain  specification only.  When permitted, abbrevia-
             tions may be present  only  while  the  message  stays
             within the sub-domain of the sender.
-
+     
             Use of this mechanism requires the sender's sub-domain
             to reserve the names of all top-level domains, so that
             full specifications can be distinguished from abbrevi-
             ated specifications.
-
+     
         For example, if a sender's address is:
-
+     
                  sender@registry-A.registry-1.organization-X
-
+     
         and one recipient's address is:
-
+     
                 recipient@registry-B.registry-1.organization-X
-
+     
         and another's is:
-
+     
                 recipient@registry-C.registry-2.organization-X
-
+     
         then ".registry-1.organization-X" need not be specified in the
         the  message,  but  "registry-C.registry-2"  DOES  have  to be
         specified.  That is, the first two addresses may  be  abbrevi-
         ated, but the third address must be fully specified.
-
+     
         When a message crosses a domain boundary, all  addresses  must
         be  specified  in  the  full format, ending with the top-level
         name-domain in the right-most field.  It is the responsibility
         of  mail  forwarding services to ensure that addresses conform
-
-
-     August 13, 1982              - 29 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 29 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         with this requirement.  In the case of abbreviated  addresses,
         the  relaying  service must make the necessary expansions.  It
         should be noted that it often is difficult for such a  service
@@ -1867,61 +1923,58 @@
         ple, it will not be possible to find such abbreviations within
         the  body  of  the  message.   The "Return-Path" field can aid
         recipients in recovering from these errors.
-
+     
         Note:  When passing any portion of an addr-spec onto a process
                which  does  not interpret data according to this stan-
                dard (e.g., mail protocol servers).  There must  be  NO
                LWSP-chars  preceding  or  following the at-sign or any
                delimiting period ("."), such as  shown  in  the  above
                examples,   and   only  ONE  SPACE  between  contiguous
-               s.
-
-     6.2.3.  DOMAIN TERMS
-
+               <word>s.
+     
+     6.2.3.  DOMAIN TERMS
+     
         A domain-ref must be THE official name of a registry, network,
         or  host.   It  is  a  symbolic  reference, within a name sub-
         domain.  At times, it is necessary to bypass standard  mechan-
         isms  for  resolving  such  references,  using  more primitive
         information, such as a network host address  rather  than  its
         associated host name.
-
+     
         To permit such references, this standard provides the  domain-
         literal  construct.   Its contents must conform with the needs
         of the sub-domain in which it is interpreted.
-
+     
         Domain-literals which refer to domains within the ARPA  Inter-
         net  specify  32-bit  Internet addresses, in four 8-bit fields
         noted in decimal, as described in Request for  Comments  #820,
         "Assigned Numbers."  For example:
-
-                                 [10.0.3.19]
-
+     
+                                 [10.0.3.19]
+     
         Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
                is  permitted  only  as  a means of bypassing temporary
                system limitations, such as name tables which  are  not
                complete.
-
+     
         The names of "top-level" domains, and  the  names  of  domains
         under  in  the  ARPA Internet, are registered with the Network
         Information Center, SRI International, Menlo Park, California.
-
-     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
-
+     
+     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
+     
         The local-part of an  addr-spec  in  a  mailbox  specification
         (i.e.,  the  host's  name for the mailbox) is understood to be
-
-
-     August 13, 1982              - 30 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 30 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         whatever the receiving mail protocol server allows.  For exam-
         ple,  some systems do not understand mailbox references of the
         form "P. D. Q. Bach", but others do.
-
+     
         This specification treats periods (".") as lexical separators.
         Hence,  their  presence  in  local-parts which are not quoted-
         strings, is detected.   However,  such  occurrences  carry  NO
@@ -1931,294 +1984,279 @@
         preted unit.  The sequence  will  be  re-assembled,  when  the
         address is passed outside of the system such as to a mail pro-
         tocol service.
-
+     
         For example, the address:
-
+     
                            First.Last@Registry.Org
-
+     
         is legal and does not require the local-part to be  surrounded
         with  quotation-marks.   (However,  "First  Last" DOES require
         quoting.)  The local-part of the address, when passed  outside
         of  the  mail  system,  within  the  Registry.Org  domain,  is
         "First.Last", again without quotation marks.
-
-     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
-
+     
+     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
+     
         In some cases, the boundary between local-part and domain  can
         be  flexible.  The local-part may be a simple string, which is
         used for the final determination of the  recipient's  mailbox.
         All  other  levels  of  reference  are, therefore, part of the
         domain.
-
+     
         For some systems, in the case of abbreviated reference to  the
         local  and  subordinate  sub-domains,  it  may  be possible to
         specify only one reference within the domain  part  and  place
         the  other,  subordinate  name-domain  references  within  the
         local-part.  This would appear as:
-
+     
                         mailbox.sub1.sub2@this-domain
-
+     
         Such a specification would be acceptable  to  address  parsers
         which  conform  to  RFC  #733,  but  do not support this newer
         Internet standard.  While contrary to the intent of this stan-
         dard, the form is legal.
-
+     
         Also, some sub-domains have a specification syntax which  does
         not conform to this standard.  For example:
-
+     
                       sub-net.mailbox@sub-domain.domain
-
-
-     August 13, 1982              - 31 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 31 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         uses a different parsing  sequence  for  local-part  than  for
         domain.
-
+     
         Note:  As a rule,  the  domain  specification  should  contain
                fields  which  are  encoded  according to the syntax of
                this standard and which contain  generally-standardized
                information.   The local-part specification should con-
                tain only that portion of the  address  which  deviates
                from the form or intention of the domain field.
-
-     6.2.6.  MULTIPLE MAILBOXES
-
+     
+     6.2.6.  MULTIPLE MAILBOXES
+     
         An individual may have several mailboxes and wish  to  receive
         mail  at  whatever  mailbox  is  convenient  for the sender to
         access.  This standard does not provide a means of  specifying
         "any member of" a list of mailboxes.
-
+     
         A set of individuals may wish to receive mail as a single unit
-        (i.e.,  a  distribution  list).  The  construct permits
+        (i.e.,  a  distribution  list).  The <group> construct permits
         specification of such a list.  Recipient mailboxes are  speci-
         fied  within  the  bracketed  part (":" - ";").  A copy of the
         transmitted message is to be  sent  to  each  mailbox  listed.
         This  standard  does  not  permit  recursive  specification of
         groups within groups.
-
+     
         While a list must be named, it is not required that  the  con-
-        tents  of  the  list be included.  In this case, the 

+        tents  of  the  list be included.  In this case, the <address>
         serves only as an indication of group distribution  and  would
         appear in the form:
-
+     
                                     name:;
-
+     
         Some mail  services  may  provide  a  group-list  distribution
         facility,  accepting  a single mailbox reference, expanding it
         to the full distribution list, and relaying the  mail  to  the
         list's  members.   This standard provides no additional syntax
-        for indicating such a  service.   Using  the    address
+        for indicating such a  service.   Using  the  <group>  address
         alternative,  while listing one mailbox in it, can mean either
         that the mailbox reference will be expanded to a list or  that
         there is a group with one member.
-
-     6.2.7.  EXPLICIT PATH SPECIFICATION
-
+     
+     6.2.7.  EXPLICIT PATH SPECIFICATION
+     
         At times, a  message  originator  may  wish  to  indicate  the
         transmission  path  that  a  message  should  follow.  This is
         called source routing.  The normal addressing scheme, used  in
         an  addr-spec,  is  carefully separated from such information;
-        the  portion of a route-addr is provided for such occa-
+        the <route> portion of a route-addr is provided for such occa-
         sions.  It specifies the sequence of hosts and/or transmission
-
-
-     August 13, 1982              - 32 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 32 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         services that are  to  be  traversed.   Both  domain-refs  and
         domain-literals may be used.
-
+     
         Note:  The use of source routing is discouraged.   Unless  the
                sender has special need of path restriction, the choice
                of transmission route should be left to the mail  tran-
                sport service.
-
-     6.3.  RESERVED ADDRESS
-
+     
+     6.3.  RESERVED ADDRESS
+     
           It often is necessary to send mail to a site, without  know-
      ing  any  of its valid addresses.  For example, there may be mail
      system dysfunctions, or a user may wish to find  out  a  person's
      correct address, at that site.
-
+     
           This standard specifies a single, reserved  mailbox  address
      (local-part)  which  is  to  be valid at each site.  Mail sent to
      that address is to be routed to  a  person  responsible  for  the
      site's mail system or to a person with responsibility for general
      site operation.  The name of the reserved local-part address is:
-
+     
                                 Postmaster
-
+     
      so that "Postmaster@domain" is required to be valid.
-
+     
      Note:  This reserved local-part must be  matched  without  sensi-
             tivity to alphabetic case, so that "POSTMASTER", "postmas-
             ter", and even "poStmASteR" is to be accepted.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - 33 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     7.  BIBLIOGRAPHY
-
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 33 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     7.  BIBLIOGRAPHY
+     
+     
      ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
         American  National Standards Institute: New York (1968).  Also
         in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
         book", NIC 7104.
-
+     
      ANSI.  "Representations of Universal Time, Local  Time  Differen-
         tials,  and United States Time Zone References for Information
         Interchange," X3.51-1975.  American National Standards  Insti-
         tute:  New York (1975).
-
+     
      Bemer, R.W., "Time and the Computer."  In:  Interface  Age  (Feb.
         1979).
-
+     
      Bennett, C.J.  "JNT Mail Protocol".  Joint Network Team,  Ruther-
         ford and Appleton Laboratory:  Didcot, England.
-
+     
      Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
         "Standardizing  Network  Mail  Headers,"   ARPANET Request for
         Comments No. 561, Network Information Center  No.  18516;  SRI
         International:  Menlo Park (September 1973).
-
+     
      Birrell, A.D., Levin, R.,  Needham,  R.M.,  and  Schroeder,  M.D.
         "Grapevine:  An Exercise in Distributed Computing," Communica-
         tions of the ACM 25, 4 (April 1982), 260-274.
-
+     
      Crocker,  D.H.,  Vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A.
         "Standard  for  the  Format  of  ARPA  Network  Text Message,"
         ARPANET Request for  Comments  No.  733,  Network  Information
         Center  No.  41952.   SRI International:  Menlo Park (November
         1977).
-
+     
      Feinler, E.J. and Postel, J.B.  ARPANET Protocol  Handbook,  Net-
         work  Information  Center  No.  7104   (NTIS AD A003890).  SRI
         International:  Menlo Park (April 1976).
-
+     
      Harary, F.   "Graph  Theory".   Addison-Wesley:   Reading,  Mass.
         (1969).
-
+     
      Levin, R. and Schroeder, M.  "Transport  of  Electronic  Messages
         through  a  Network,"   TeleInformatics  79, pp. 29-33.  North
         Holland (1979).  Also  as  Xerox  Palo  Alto  Research  Center
         Technical Report CSL-79-4.
-
+     
      Myer, T.H. and Henderson, D.A.  "Message Transmission  Protocol,"
         ARPANET  Request  for  Comments,  No. 680, Network Information
         Center No. 32116.  SRI International:  Menlo Park (1975).
-
-
-     August 13, 1982              - 34 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 34 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
      NBS.  "Specification of Message Format for Computer Based Message
         Systems, Recommended Federal Information Processing Standard."
         National  Bureau   of   Standards:    Gaithersburg,   Maryland
         (October 1981).
-
+     
      NIC.  Internet Protocol Transition Workbook.  Network Information
         Center,   SRI-International,  Menlo  Park,  California  (March
         1982).
-
+     
      Oppen, D.C. and Dalal, Y.K.  "The Clearinghouse:  A Decentralized
         Agent  for  Locating  Named  Objects in a Distributed Environ-
         ment," OPD-T8103.  Xerox Office Products Division:  Palo Alto,
         CA. (October 1981).
-
+     
      Postel, J.B.  "Assigned Numbers,"  ARPANET Request for  Comments,
         No. 820.  SRI International:  Menlo Park (August 1982).
-
-     Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
-        for Comments, No. 821.  SRI International:  Menlo Park (August
-        1982).
-
-     Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
-        Proc. 17th IEEE Computer Society International Conference, pp.
-        72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
-
-     Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
-        User  Applications,"  ARPANET  Request  for Comments, No. 819.
-        SRI International:  Menlo Park (August 1982).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - 35 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
+        for Comments, No. 821.  SRI International:  Menlo Park (August
+        1982).
+     
+     Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
+        Proc. 17th IEEE Computer Society International Conference, pp.
+        72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
+     
+     Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
+        User  Applications,"  ARPANET  Request  for Comments, No. 819.
+        SRI International:  Menlo Park (August 1982).
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 35 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
                                  APPENDIX
-
-
-     A.  EXAMPLES
-
-     A.1.  ADDRESSES
-
-     A.1.1.  Alfred Neuman 
-
-     A.1.2.  Neuman@BBN-TENEXA
-
+     
+     
+     A.  EXAMPLES
+     
+     A.1.  ADDRESSES
+     
+     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
+     
+     A.1.2.  Neuman@BBN-TENEXA
+     
              These two "Alfred Neuman" examples have identical  seman-
         tics, as far as the operation of the local host's mail sending
         (distribution) program (also sometimes  called  its  "mailer")
@@ -2228,295 +2266,280 @@
         pient.  The second example contains  no  superfluous  informa-
         tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
         pient.
-
+     
         Note:  When the message crosses name-domain  boundaries,  then
                these specifications must be changed, so as to indicate
                the remainder of the hierarchy, starting with  the  top
                level.
-
-     A.1.3.  "George, Ted" 
-
+     
+     A.1.3.  "George, Ted" <Shared@Group.Arpanet>
+     
              This form might be used to indicate that a single mailbox
         is  shared  by several users.  The quoted string is ignored by
         the originating host's mailer, because  "Shared@Group.Arpanet"
         completely specifies the destination mailbox.
-
-     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
-
+     
+     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
+     
              The "(the  Stilt)" is a comment, which is NOT included in
         the  destination  mailbox  address  handed  to the originating
         system's mailer.  The local-part of the address is the  string
         "Wilt.Chamberlain", with NO space between the first and second
         words.
-
-     A.1.5.  Address Lists
-
-     Gourmets:  Pompous Person ,
+     
+     A.1.5.  Address Lists
+     
+     Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
                 Childs@WGBH.Boston, Galloping Gourmet@
                 ANT.Down-Under (Australian National Television),
                 Cheapie@Discount-Liquors;,
        Cruisers:  Port@Portugal, Jones@SEA;,
          Another@Somewhere.SomeOrg
-
-
-     August 13, 1982              - 36 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 36 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         This group list example points out the use of comments and the
         mixing of addresses and groups.
-
-     A.2.  ORIGINATOR ITEMS
-
-     A.2.1.  Author-sent
-
+     
+     A.2.  ORIGINATOR ITEMS
+     
+     A.2.1.  Author-sent
+     
              George Jones logs into his host  as  "Jones".   He  sends
         mail himself.
-
+     
             From:  Jones@Group.Org
-
+     
         or
-
-            From:  George Jones 
-
-     A.2.2.  Secretary-sent
-
+     
+            From:  George Jones <Jones@Group.Org>
+     
+     A.2.2.  Secretary-sent
+     
              George Jones logs in as Jones on his  host.   His  secre-
         tary,  who logs in as Secy sends mail for him.  Replies to the
         mail should go to George.
-
-            From:    George Jones 
+     
+            From:    George Jones <Jones@Group>
             Sender:  Secy@Other-Group
-
-     A.2.3.  Secretary-sent, for user of shared directory
-
+     
+     A.2.3.  Secretary-sent, for user of shared directory
+     
              George Jones' secretary sends mail  for  George.  Replies
         should go to George.
-
-            From:     George Jones
+     
+            From:     George Jones<Shared@Group.Org>
             Sender:   Secy@Other-Group
-
+     
         Note that there need not be a space between  "Jones"  and  the
-        "<",  but  adding a space enhances readability (as is the case
+        "<",  but  adding a space enhances readability (as is the case
         in other examples.
-
-     A.2.4.  Committee activity, with one author
-
+     
+     A.2.4.  Committee activity, with one author
+     
              George is a member of a committee.  He wishes to have any
         replies to his message go to all committee members.
-
-            From:     George Jones 
+     
+            From:     George Jones <Jones@Host.Net>
             Sender:   Jones@Host
             Reply-To: The Committee: Jones@Host.Net,
                                      Smith@Other.Org,
                                      Doe@Somewhere-Else;
-
+     
         Note  that  if  George  had  not  included  himself   in   the
-
-
-     August 13, 1982              - 37 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     August 13, 1982              - 37 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
         enumeration  of  The  Committee,  he  would not have gotten an
         implicit reply; the presence of the  "Reply-to"  field  SUPER-
         SEDES the sending of a reply to the person named in the "From"
         field.
-
-     A.2.5.  Secretary acting as full agent of author
-
+     
+     A.2.5.  Secretary acting as full agent of author
+     
              George Jones asks his secretary  (Secy@Host)  to  send  a
         message for him in his capacity as Group.  He wants his secre-
         tary to handle all replies.
-
-            From:     George Jones 
+     
+            From:     George Jones <Group@Host>
             Sender:   Secy@Host
             Reply-To: Secy@Host
-
-     A.2.6.  Agent for user without online mailbox
-
+     
+     A.2.6.  Agent for user without online mailbox
+     
              A friend  of  George's,  Sarah,  is  visiting.   George's
         secretary  sends  some  mail to a friend of Sarah in computer-
         land.  Replies should go to George, whose mailbox is Jones  at
         Registry.
-
-            From:     Sarah Friendly 
-            Sender:   Secy-Name 
+     
+            From:     Sarah Friendly <Secy@Registry>
+            Sender:   Secy-Name <Secy@Registry>
             Reply-To: Jones@Registry.
-
-     A.2.7.  Agent for member of a committee
-
+     
+     A.2.7.  Agent for member of a committee
+     
              George's secretary sends out a message which was authored
         jointly by all the members of a committee.  Note that the name
-        of the committee cannot be specified, since  names  are
+        of the committee cannot be specified, since <group> names  are
         not permitted in the From field.
-
+     
             From:   Jones@Host,
                     Smith@Other-Host,
                     Doe@Somewhere-Else
             Sender: Secy@SHost
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - 38 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     A.3.  COMPLETE HEADERS
-
-     A.3.1.  Minimum required
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 38 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     A.3.  COMPLETE HEADERS
+     
+     A.3.1.  Minimum required
+     
      Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
      From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
      Bcc:                                To:       Smith@Registry.Org
-
+     
         Note that the "Bcc" field may be empty, while the  "To"  field
         is required to have at least one address.
-
-     A.3.2.  Using some of the additional fields
-
+     
+     A.3.2.  Using some of the additional fields
+     
      Date:     26 Aug 76 1430 EDT
-     From:     George Jones
+     From:     George Jones<Group@Host>
      Sender:   Secy@SHOST
      To:       "Al Neuman"@Mad-Host,
                Sam.Irving@Other-Host
-     Message-ID:  
-
-     A.3.3.  About as complex as you're going to get
-
+     Message-ID:  <some.string@SHOST>
+     
+     A.3.3.  About as complex as you're going to get
+     
      Date     :  27 Aug 76 0932 PDT
-     From     :  Ken Davis 
+     From     :  Ken Davis <KDavis@This-Host.This-net>
      Subject  :  Re: The Syntax in the RFC
      Sender   :  KSecy@Other-Host
      Reply-To :  Sam.Irving@Reg.Organization
-     To       :  George Jones ,
+     To       :  George Jones <Group@Some-Reg.An-Org>,
                  Al.Neuman@MAD.Publisher
      cc       :  Important folk:
-                   Tom Softwood ,
+                   Tom Softwood <Balsa@Tree.Root>,
                    "Sam Irving"@Other-Host;,
                  Standard Distribution:
                    /main/davis/people/standard@Other-Host,
-                   "standard.dist.3"@Tops-20-Host>;
+                   "<Jones>standard.dist.3"@Tops-20-Host>;
      Comment  :  Sam is away on business. He asked me to handle
                  his mail for him.  He'll be able to provide  a
                  more  accurate  explanation  when  he  returns
                  next week.
-     In-Reply-To: , George's message
+     In-Reply-To: <some.string@DBM.Group>, George's message
      X-Special-action:  This is a sample of user-defined field-
                  names.  There could also be a field-name
                  "Special-action", but its name might later be
                  preempted
-     Message-ID: <4231.629.XYzi-What@Other-Host>
-
-
-
-
-
-
-     August 13, 1982              - 39 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     B.  SIMPLE FIELD PARSING
-
+     Message-ID: <4231.629.XYzi-What@Other-Host>
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 39 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     B.  SIMPLE FIELD PARSING
+     
           Some mail-reading software systems may wish to perform  only
      minimal  processing,  ignoring  the internal syntax of structured
      field-bodies and treating them the  same  as  unstructured-field-
      bodies.  Such software will need only to distinguish:
-
+     
          o   Header fields from the message body,
-
+     
          o   Beginnings of fields from lines which continue fields,
-
+     
          o   Field-names from field-contents.
-
+     
           The abbreviated set of syntactic rules  which  follows  will
      suffice  for  this  purpose.  It describes a limited view of mes-
      sages and is a subset of the syntactic rules provided in the main
      part of this specification.  One small exception is that the con-
      tents of field-bodies consist only of text:
-
-     B.1.  SYNTAX
-
-
+     
+     B.1.  SYNTAX
+     
+     
      message         =   *field *(CRLF *text)
-
+     
      field           =    field-name ":" [field-body] CRLF
-
-     field-name      =  1*
-
+     
+     field-name      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+     
      field-body      =   *text [CRLF LWSP-char field-body]
-
-
-     B.2.  SEMANTICS
-
+     
+     
+     B.2.  SEMANTICS
+     
           Headers occur before the message body and are terminated  by
      a null line (i.e., two contiguous CRLFs).
-
+     
           A line which continues a header field begins with a SPACE or
      HTAB  character,  while  a  line  beginning a field starts with a
      printable character which is not a colon.
-
+     
           A field-name consists of one or  more  printable  characters
      (excluding  colon,  space, and control-characters).  A field-name
      MUST be contained on one line.  Upper and lower case are not dis-
      tinguished when comparing field-names.
-
-
-
-
-
-
-
-     August 13, 1982              - 40 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     C.  DIFFERENCES FROM RFC #733
-
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 40 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     C.  DIFFERENCES FROM RFC #733
+     
           The following summarizes the differences between this  stan-
      dard  and the one specified in Arpanet Request for Comments #733,
      "Standard for the Format of ARPA  Network  Text  Messages".   The
      differences  are  listed  in the order of their occurrence in the
      current specification.
-
-     C.1.  FIELD DEFINITIONS
-
-     C.1.1.  FIELD NAMES
-
+     
+     C.1.  FIELD DEFINITIONS
+     
+     C.1.1.  FIELD NAMES
+     
         These now must be a sequence of  printable  characters.   They
         may not contain any LWSP-chars.
-
-     C.2.  LEXICAL TOKENS
-
-     C.2.1.  SPECIALS
-
+     
+     C.2.  LEXICAL TOKENS
+     
+     C.2.1.  SPECIALS
+     
         The characters period ("."), left-square  bracket  ("["),  and
         right-square  bracket ("]") have been added.  For presentation
         purposes, and when passing a specification to  a  system  that
@@ -2524,176 +2547,167 @@
         ous with their surrounding lexical tokens.   No  linear-white-
         space  is  permitted  between them.  The presence of one LWSP-
         char between other tokens is still directed.
-
-     C.2.2.  ATOM
-
+     
+     C.2.2.  ATOM
+     
         Atoms may not contain SPACE.
-
-     C.2.3.  SPECIAL TEXT
-
+     
+     C.2.3.  SPECIAL TEXT
+     
         ctext and qtext have had backslash ("\") added to the list  of
         prohibited characters.
-
-     C.2.4.  DOMAINS
-
-        The lexical tokens    and    have  been
+     
+     C.2.4.  DOMAINS
+     
+        The lexical tokens  <domain-literal>  and  <dtext>  have  been
         added.
-
-     C.3.  MESSAGE SPECIFICATION
-
-     C.3.1.  TRACE
-
+     
+     C.3.  MESSAGE SPECIFICATION
+     
+     C.3.1.  TRACE
+     
         The "Return-path:" and "Received:" fields have been specified.
-
-
-
-
-
-     August 13, 1982              - 41 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     C.3.2.  FROM
-
+     
+     
+     
+     
+     
+     August 13, 1982              - 41 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     C.3.2.  FROM
+     
         The "From" field must contain machine-usable addresses  (addr-
         spec).   Multiple  addresses may be specified, but named-lists
         (groups) may not.
-
-     C.3.3.  RESENT
-
+     
+     C.3.3.  RESENT
+     
         The meta-construct of prefacing field names  with  the  string
         "Resent-"  has been added, to indicate that a message has been
         forwarded by an intermediate recipient.
-
-     C.3.4.  DESTINATION
-
+     
+     C.3.4.  DESTINATION
+     
         A message must contain at least one destination address field.
         "To" and "CC" are required to contain at least one address.
-
-     C.3.5.  IN-REPLY-TO
-
+     
+     C.3.5.  IN-REPLY-TO
+     
         The field-body is no longer a comma-separated list, although a
         sequence is still permitted.
-
-     C.3.6.  REFERENCE
-
+     
+     C.3.6.  REFERENCE
+     
         The field-body is no longer a comma-separated list, although a
         sequence is still permitted.
-
-     C.3.7.  ENCRYPTED
-
+     
+     C.3.7.  ENCRYPTED
+     
         A field has been specified that permits  senders  to  indicate
         that the body of a message has been encrypted.
-
-     C.3.8.  EXTENSION-FIELD
-
+     
+     C.3.8.  EXTENSION-FIELD
+     
         Extension fields are prohibited from beginning with the  char-
         acters "X-".
-
-     C.4.  DATE AND TIME SPECIFICATION
-
-     C.4.1.  SIMPLIFICATION
-
+     
+     C.4.  DATE AND TIME SPECIFICATION
+     
+     C.4.1.  SIMPLIFICATION
+     
         Fewer optional forms are permitted  and  the  list  of  three-
         letter time zones has been shortened.
-
-     C.5.  ADDRESS SPECIFICATION
-
-
-
-
-
-
-     August 13, 1982              - 42 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     C.5.1.  ADDRESS
-
+     
+     C.5.  ADDRESS SPECIFICATION
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 42 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     C.5.1.  ADDRESS
+     
         The use of quoted-string, and the ":"-atom-":" construct, have
         been  removed.   An  address  now  is  either a single mailbox
         reference or is a named list of addresses.  The  latter  indi-
         cates a group distribution.
-
-     C.5.2.  GROUPS
-
+     
+     C.5.2.  GROUPS
+     
         Group lists are now required to to have a name.   Group  lists
         may not be nested.
-
-     C.5.3.  MAILBOX
-
+     
+     C.5.3.  MAILBOX
+     
         A mailbox specification  may  indicate  a  person's  name,  as
         before.   Such  a  named  list  no longer may specify multiple
         mailboxes and may not be nested.
-
-     C.5.4.  ROUTE ADDRESSING
-
+     
+     C.5.4.  ROUTE ADDRESSING
+     
         Addresses now are taken to be absolute, global specifications,
-        independent  of transmission paths.  The  construct has
+        independent  of transmission paths.  The <route> construct has
         been provided, to permit explicit specification  of  transmis-
         sion  path.   RFC  #733's  use  of multiple at-signs ("@") was
         intended as a general syntax  for  indicating  routing  and/or
         hierarchical addressing.  The current standard separates these
         specifications and only one at-sign is permitted.
-
-     C.5.5.  AT-SIGN
-
+     
+     C.5.5.  AT-SIGN
+     
         The string " at " no longer is used as an  address  delimiter.
         Only at-sign ("@") serves the function.
-
-     C.5.6.  DOMAINS
-
+     
+     C.5.6.  DOMAINS
+     
         Hierarchical, logical name-domains have been added.
-
-     C.6.  RESERVED ADDRESS
-
+     
+     C.6.  RESERVED ADDRESS
+     
      The local-part "Postmaster" has been reserved, so that users  can
      be guaranteed at least one valid address at a site.
-
-
-
-
-
-
-
-
-
-
-     August 13, 1982              - 43 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     D.  ALPHABETICAL LISTING OF SYNTAX RULES
-
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 43 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES
+     
      address     =  mailbox                      ; one addressee
                  /  group                        ; named list
      addr-spec   =  local-part "@" domain        ; global address
-     ALPHA       =  
+     ALPHA       =  <any ASCII alphabetic character>
                                                  ; (101-132, 65.- 90.)
                                                  ; (141-172, 97.-122.)
-     atom        =  1*
+     atom        =  1*<any CHAR except specials, SPACE and CTLs>
      authentic   =   "From"       ":"   mailbox  ; Single author
                  / ( "Sender"     ":"   mailbox  ; Actual submittor
                      "From"       ":" 1#mailbox) ; Multiple authors
                                                  ;  or not sender
-     CHAR        =          ; (  0-177,  0.-127.)
+     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
      comment     =  "(" *(ctext / quoted-pair / comment) ")"
-     CR          =    ; (     15,      13.)
+     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
      CRLF        =  CR LF
-     ctext       =   may be folded
-                     ")", "\" & CR, & including
-                     linear-white-space>
-     CTL         =            ; (    177,     127.)
+     ctext       =  <any CHAR excluding "(",     ; => may be folded
+                     ")", "\" & CR, & including
+                     linear-white-space>
+     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
+                     character and DEL>          ; (    177,     127.)
      date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                  ;  e.g. 20 Jun 82
      dates       =   orig-date                   ; Original
@@ -2709,59 +2723,56 @@
                  /  "Resent-cc"   ":" 1#address
                  /  "bcc"         ":"  #address  ; Blind carbon
                  /  "Resent-bcc"  ":"  #address
-     DIGIT       =      ; ( 60- 71, 48.- 57.)
+     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
      domain      =  sub-domain *("." sub-domain)
      domain-literal =  "[" *(dtext / quoted-pair) "]"
      domain-ref  =  atom                         ; symbolic reference
-     dtext       =   may be folded
-                     "]", "\" & CR, & including
-                     linear-white-space>
+     dtext       =  <any CHAR excluding "[",     ; => may be folded
+                     "]", "\" & CR, & including
+                     linear-white-space>
      extension-field =
-                   
-
-
-     August 13, 1982              - 44 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+                    with the string "X-">
+     
+     
+     August 13, 1982              - 44 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
      field       =  field-name ":" [ field-body ] CRLF
      fields      =    dates                      ; Creation time,
-                      source                     ;  author id & one
+                      source                     ;  author id & one
                     1*destination                ;  address required
                      *optional-field             ;  others optional
      field-body  =  field-body-contents
                     [CRLF LWSP-char field-body]
      field-body-contents =
-                   
-     field-name  =  1*
+                    specials tokens, or else consisting of texts>
+     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
      group       =  phrase ":" [#mailbox] ";"
      hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                  ; 00:00:00 - 23:59:59
-     HTAB        =     ; (     11,       9.)
-     LF          =           ; (     12,      10.)
+     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
      linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
-                                                 ; CRLF => folding
+                                                 ; CRLF => folding
      local-part  =  word *("." word)             ; uninterpreted
                                                  ; case-preserved
      LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
      mailbox     =  addr-spec                    ; simple address
-                 /  phrase route-addr            ; name & addr-spec
+                 /  phrase route-addr            ; name & addr-spec
      message     =  fields *( CRLF *text )       ; Everything after
                                                  ;  first null line
                                                  ;  is message body
      month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                  /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                  /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
-     msg-id      =  "<" addr-spec ">"            ; Unique message id
+     msg-id      =  "<" addr-spec ">"            ; Unique message id
      optional-field =
                  /  "Message-ID"        ":"   msg-id
                  /  "Resent-Message-ID" ":"   msg-id
@@ -2777,22 +2788,19 @@
      originator  =   authentic                   ; authenticated addr
                    [ "Reply-To"   ":" 1#address] )
      phrase      =  1*word                       ; Sequence of words
-
-
-
-
-     August 13, 1982              - 45 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
-     qtext       =  ,     ; => may be folded
-                     "\" & CR, and including
-                     linear-white-space>
+     
+     
+     
+     
+     August 13, 1982              - 45 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
+     qtext       =  <any CHAR excepting <">,     ; => may be folded
+                     "\" & CR, and including
+                     linear-white-space>
      quoted-pair =  "\" CHAR                     ; may quote any char
-     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                  ;   quoted chars.
      received    =  "Received"    ":"            ; one per relay
                        ["from" domain]           ; sending host
@@ -2802,7 +2810,7 @@
                        ["id"   msg-id]           ; receiver msg id
                        ["for"  addr-spec]        ; initial form
                         ";"    date-time         ; time received
-
+     
      resent      =   resent-authentic
                    [ "Resent-Reply-To"  ":" 1#address] )
      resent-authentic =
@@ -2812,40 +2820,37 @@
      resent-date =  "Resent-Date" ":"   date-time
      return      =  "Return-path" ":" route-addr ; return address
      route       =  1#("@" domain) ":"           ; path-relative
-     route-addr  =  "<" [route] addr-spec ">"
+     route-addr  =  "<" [route] addr-spec ">"
      source      = [  trace ]                    ; net traversals
                       originator                 ; original mail
                    [  resent ]                   ; forwarded
-     SPACE       =              ; (     40,      32.)
-     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
-                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
+     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
+     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
+                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
                  /  "." / "[" / "]"              ;  within a word.
      sub-domain  =  domain-ref / domain-literal
-     text        =   atoms, specials,
-                     CR & bare LF, but NOT       ;  comments and
-                     including CRLF>             ;  quoted-strings are
+     text        =  <any CHAR, including bare    ; => atoms, specials,
+                     CR & bare LF, but NOT       ;  comments and
+                     including CRLF>             ;  quoted-strings are
                                                  ;  NOT recognized.
      time        =  hour zone                    ; ANSI and Military
      trace       =    return                     ; path to sender
                     1*received                   ; receipt tags
      user-defined-field =
-                   
+                    pre-empted by published extensions>
      word        =  atom / quoted-string
-
-
-
-
-     August 13, 1982              - 46 -                      RFC #822
-
-
- 
-     Standard for ARPA Internet Text Messages
-
-
+     
+     
+     
+     
+     August 13, 1982              - 46 -                      RFC #822
+ 
Standard for ARPA Internet Text Messages
+     
+     
      zone        =  "UT"  / "GMT"                ; Universal Time
                                                  ; North American : UT
                  /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
@@ -2853,49 +2858,54 @@
                  /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                  /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                  /  1ALPHA                       ; Military: Z = UT;
-     <">         =             ; (     42,      34.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+     <">         =  <ASCII quote mark>           ; (     42,      34.)
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     
+     August 13, 1982              - 47 -                      RFC #822
+
- August 13, 1982 - 47 - RFC #822 + \ No newline at end of file From c4e94759e24df0edf2dff7f7f842449bc6c4a68d Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Thu, 21 Jul 2022 10:45:44 -0400 Subject: [PATCH 07/16] Use original RFCs --- assets/RFCs/rfc2119.html | 18 +-- assets/RFCs/rfc822.html | 306 +++++++++++++++++++-------------------- 2 files changed, 162 insertions(+), 162 deletions(-) diff --git a/assets/RFCs/rfc2119.html b/assets/RFCs/rfc2119.html index 900d2b49a1b4a9..34965f686d730c 100644 --- a/assets/RFCs/rfc2119.html +++ b/assets/RFCs/rfc2119.html @@ -187,18 +187,18 @@ Note that the force of these words is modified by the requirement level of the document in which they are used. -1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the +1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. -2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the +2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. -3. SHOULD This word, or the adjective "RECOMMENDED", mean that there +3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. -4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that +4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed @@ -213,7 +213,7 @@ RFC 2119 RFC Key Words March 1997 -5. MAY This word, or the adjective "OPTIONAL", mean that an item is +5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. @@ -225,7 +225,7 @@ does not include the option (except, of course, for the feature the option provides.) -6. Guidance in the use of these Imperatives +6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is @@ -235,7 +235,7 @@ on implementors where the method is not required for interoperability. -7. Security Considerations +7. Security Considerations These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or @@ -246,7 +246,7 @@ had the benefit of the experience and discussion that produced the specification. -8. Acknowledgments +8. Acknowledgments The definitions of these terms are an amalgam of definitions taken from a number of RFCs. In addition, suggestions have been @@ -269,7 +269,7 @@ RFC 2119 RFC Key Words March 1997 -9. Author's Address +9. Author's Address Scott Bradner Harvard University diff --git a/assets/RFCs/rfc822.html b/assets/RFCs/rfc822.html index 7a4f48de65a526..6590f0786d72a6 100644 --- a/assets/RFCs/rfc822.html +++ b/assets/RFCs/rfc822.html @@ -214,52 +214,52 @@ TABLE OF CONTENTS - PREFACE .................................................... ii + PREFACE .................................................... ii - 1. INTRODUCTION ........................................... 1 + 1. INTRODUCTION ........................................... 1 - 1.1. Scope ............................................ 1 - 1.2. Communication Framework .......................... 2 + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 - 2. NOTATIONAL CONVENTIONS ................................. 3 + 2. NOTATIONAL CONVENTIONS ................................. 3 - 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 - 3.1. General Description .............................. 5 - 3.2. Header Field Definitions ......................... 9 - 3.3. Lexical Tokens ................................... 10 - 3.4. Clarifications ................................... 11 + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 - 4. MESSAGE SPECIFICATION .................................. 17 + 4. MESSAGE SPECIFICATION .................................. 17 - 4.1. Syntax ........................................... 17 - 4.2. Forwarding ....................................... 19 - 4.3. Trace Fields ..................................... 20 - 4.4. Originator Fields ................................ 21 - 4.5. Receiver Fields .................................. 23 - 4.6. Reference Fields ................................. 23 - 4.7. Other Fields ..................................... 24 + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 - 5. DATE AND TIME SPECIFICATION ............................ 26 + 5. DATE AND TIME SPECIFICATION ............................ 26 - 5.1. Syntax ........................................... 26 - 5.2. Semantics ........................................ 26 + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 - 6. ADDRESS SPECIFICATION .................................. 27 + 6. ADDRESS SPECIFICATION .................................. 27 - 6.1. Syntax ........................................... 27 - 6.2. Semantics ........................................ 27 - 6.3. Reserved Address ................................. 33 + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 - 7. BIBLIOGRAPHY ........................................... 34 + 7. BIBLIOGRAPHY ........................................... 34 APPENDIX - A. EXAMPLES ............................................... 36 - B. SIMPLE FIELD PARSING ................................... 40 - C. DIFFERENCES FROM RFC #733 .............................. 41 - D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 August 13, 1982 - i - RFC #822 @@ -321,9 +321,9 @@ 
Standard for ARPA Internet Text Messages
      
      
-     1.  INTRODUCTION
+     1.  INTRODUCTION
      
-     1.1.  SCOPE
+     1.1.  SCOPE
      
           This standard specifies a syntax for text messages that  are
      sent  among  computer  users, within the framework of "electronic
@@ -376,7 +376,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     1.2.  COMMUNICATION FRAMEWORK
+     1.2.  COMMUNICATION FRAMEWORK
      
           Messages consist of lines of text.   No  special  provisions
      are  made for encoding drawings, facsimile, speech, or structured
@@ -431,13 +431,13 @@
      
Standard for ARPA Internet Text Messages
      
      
-     2.  NOTATIONAL CONVENTIONS
+     2.  NOTATIONAL CONVENTIONS
      
           This specification uses an augmented Backus-Naur Form  (BNF)
      notation.  The differences from standard BNF involve naming rules
      and indicating repetition and "local" alternatives.
      
-     2.1.  RULE NAMING
+     2.1.  RULE NAMING
      
           Angle brackets ("<", ">") are not  used,  in  general.   The
      name  of  a rule is simply the name itself, rather than "<name>".
@@ -447,18 +447,18 @@
      rule  definitions,  and  in  the rest of this  document, whenever
      their presence will facilitate discerning the use of rule names.
      
-     2.2.  RULE1 / RULE2:  ALTERNATIVES
+     2.2.  RULE1 / RULE2:  ALTERNATIVES
      
           Elements separated by slash ("/") are alternatives.   There-
      fore "foo / bar" will accept foo or bar.
      
-     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
+     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
      
           Elements enclosed in parentheses are  treated  as  a  single
      element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
      sequences "elem foo elem" and "elem bar elem".
      
-     2.4.  *RULE:  REPETITION
+     2.4.  *RULE:  REPETITION
      
           The character "*" preceding an element indicates repetition.
      The full form is:
@@ -470,12 +470,12 @@
      number, including zero; "1*element" requires at  least  one;  and
      "1*2element" allows one or two.
      
-     2.5.  [RULE]:  OPTIONAL
+     2.5.  [RULE]:  OPTIONAL
      
           Square brackets enclose optional elements; "[foo  bar]"   is
      equivalent to "*1(foo bar)".
      
-     2.6.  NRULE:  SPECIFIC REPETITION
+     2.6.  NRULE:  SPECIFIC REPETITION
      
           "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
      exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
@@ -486,7 +486,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     2.7.  #RULE:  LISTS
+     2.7.  #RULE:  LISTS
      
           A construct "#" is defined, similar to "*", as follows:
      
@@ -504,7 +504,7 @@
      number,  including  zero;  "1#element" requires at least one; and
      "1#2element" allows one or two.
      
-     2.8.  ; COMMENTS
+     2.8.  ; COMMENTS
      
           A semi-colon, set off some distance to  the  right  of  rule
      text,  starts  a comment that continues to the end of line.  This
@@ -541,16 +541,16 @@
      
Standard for ARPA Internet Text Messages
      
      
-     3.  LEXICAL ANALYSIS OF MESSAGES
+     3.  LEXICAL ANALYSIS OF MESSAGES
      
-     3.1.  GENERAL DESCRIPTION
+     3.1.  GENERAL DESCRIPTION
      
           A message consists of header fields and, optionally, a body.
      The  body  is simply a sequence of lines containing ASCII charac-
      ters.  It is separated from the headers by a null line  (i.e.,  a
      line with nothing preceding the CRLF).
      
-     3.1.1.  LONG HEADER FIELDS
+     3.1.1.  LONG HEADER FIELDS
      
         Each header field can be viewed as a single, logical  line  of
         ASCII  characters,  comprising  a field-name and a field-body.
@@ -598,7 +598,7 @@
      
                between addresses, after the separating comma.
      
-     3.1.2.  STRUCTURE OF HEADER FIELDS
+     3.1.2.  STRUCTURE OF HEADER FIELDS
      
         Once a field has been unfolded, it may be viewed as being com-
         posed of a field-name followed by a colon (":"), followed by a
@@ -625,7 +625,7 @@
                field bodies each are scanned by their own, independent
                "lexical" analyzers.
      
-     3.1.3.  UNSTRUCTURED FIELD BODIES
+     3.1.3.  UNSTRUCTURED FIELD BODIES
      
         For some fields, such as "Subject" and "Comments",  no  struc-
         turing  is assumed, and they are treated simply as <text>s, as
@@ -634,7 +634,7 @@
         therefore have the second and successive lines indented by  at
         least one LWSP-char.
      
-     3.1.4.  STRUCTURED FIELD BODIES
+     3.1.4.  STRUCTURED FIELD BODIES
      
         To aid in the creation and reading of structured  fields,  the
         free  insertion   of linear-white-space (which permits folding
@@ -761,7 +761,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     3.2.  HEADER FIELD DEFINITIONS
+     3.2.  HEADER FIELD DEFINITIONS
      
           These rules show a field meta-syntax, without regard for the
      particular  type  or internal syntax.  Their purpose is to permit
@@ -816,7 +816,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     3.3.  LEXICAL TOKENS
+     3.3.  LEXICAL TOKENS
      
           The following rules are used to define an underlying lexical
      analyzer,  which  feeds  tokens to higher level parsers.  See the
@@ -888,9 +888,9 @@
      word        =  atom / quoted-string
      
      
-     3.4.  CLARIFICATIONS
+     3.4.  CLARIFICATIONS
      
-     3.4.1.  QUOTING
+     3.4.1.  QUOTING
      
         Some characters are reserved for special interpretation,  such
         as  delimiting lexical tokens.  To permit use of these charac-
@@ -926,7 +926,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     3.4.2.  WHITE SPACE
+     3.4.2.  WHITE SPACE
      
         Note:  In structured field bodies, multiple linear space ASCII
                characters  (namely  HTABs  and  SPACEs) are treated as
@@ -952,7 +952,7 @@
         ance  of  text  at another network host; therefore, the use of
         tabs in message headers, though permitted, is discouraged.
      
-     3.4.3.  COMMENTS
+     3.4.3.  COMMENTS
      
         A comment is a set of ASCII characters, which is  enclosed  in
         matching  parentheses  and which is not within a quoted-string
@@ -992,7 +992,7 @@
         backslash followed by a CR followed by a  LF)  still  must  be
         followed by at least one LWSP-char.
      
-     3.4.4.  DELIMITING AND QUOTING CHARACTERS
+     3.4.4.  DELIMITING AND QUOTING CHARACTERS
      
         The quote character (backslash) and  characters  that  delimit
         syntactic  units  are not, generally, to be taken as data that
@@ -1023,7 +1023,7 @@
         not interpret data according to this specification (e.g., mail
         protocol servers).
      
-     3.4.5.  QUOTED-STRINGS
+     3.4.5.  QUOTED-STRINGS
      
         Where permitted (i.e., in words in structured fields)  quoted-
         strings  are  treated  as a single symbol.  That is, a quoted-
@@ -1050,7 +1050,7 @@
         string.  Stripping off the first following LWSP-char  is  also
         appropriate when parsing quoted CRLFs.
      
-     3.4.6.  BRACKETING CHARACTERS
+     3.4.6.  BRACKETING CHARACTERS
      
         There is one type of bracket which must occur in matched pairs
         and may have pairs nested within each other:
@@ -1075,7 +1075,7 @@
                 name-domain  is  to  use  directly,  bypassing  normal
                 name-resolution mechanisms.
      
-     3.4.7.  CASE INDEPENDENCE
+     3.4.7.  CASE INDEPENDENCE
      
         Except as noted, alphabetic strings may be represented in  any
         combination of upper and lower case.  The only syntactic units
@@ -1114,7 +1114,7 @@
                interpreted, it must be  accepted  in  any  mixture  of
                case, including "POSTMASTER", and "postmaster".
      
-     3.4.8.  FOLDING LONG HEADER FIELDS
+     3.4.8.  FOLDING LONG HEADER FIELDS
      
         Each header field may be represented on exactly one line  con-
         sisting  of the name of the field and its body, and terminated
@@ -1131,7 +1131,7 @@
                provided  folding  can  interfere  with   the   display
                software.
      
-     3.4.9.  BACKSPACE CHARACTERS
+     3.4.9.  BACKSPACE CHARACTERS
      
         ASCII BS characters (Backspace, decimal 8) may be included  in
         texts and quoted-strings to effect overstriking.  However, any
@@ -1146,7 +1146,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
+     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
      
         During transmission through heterogeneous networks, it may  be
         necessary  to  force data to conform to a network's local con-
@@ -1201,9 +1201,9 @@
      
Standard for ARPA Internet Text Messages
      
      
-     4.  MESSAGE SPECIFICATION
+     4.  MESSAGE SPECIFICATION
      
-     4.1.  SYNTAX
+     4.1.  SYNTAX
      
      Note:  Due to an artifact of the notational conventions, the syn-
             tax  indicates that, when present, some fields, must be in
@@ -1324,7 +1324,7 @@
                     such fields must be unique and may be
                     pre-empted by published extensions>
      
-     4.2.  FORWARDING
+     4.2.  FORWARDING
      
           Some systems permit mail recipients to  forward  a  message,
      retaining  the original headers, by adding some new fields.  This
@@ -1368,7 +1368,7 @@
      
      fields whose names do not contain this prefix.
      
-     4.3.  TRACE FIELDS
+     4.3.  TRACE FIELDS
      
           Trace information is used to provide an audit trail of  mes-
      sage  handling.   In  addition,  it indicates a route back to the
@@ -1378,7 +1378,7 @@
      with  the  Network  Information  Center, SRI International, Menlo
      Park, California.
      
-     4.3.1.  RETURN-PATH
+     4.3.1.  RETURN-PATH
      
         This field  is  added  by  the  final  transport  system  that
         delivers  the message to its recipient.  The field is intended
@@ -1394,7 +1394,7 @@
         optional,  every attempt should be made to provide that infor-
         mation in this field.
      
-     4.3.2.  RECEIVED
+     4.3.2.  RECEIVED
      
         A copy of this field is added by each transport  service  that
         relays the message.  The information in the field can be quite
@@ -1427,13 +1427,13 @@
         distribution  list,  this  parameter may be used to record the
         original address that was used to specify the list.
      
-     4.4.  ORIGINATOR FIELDS
+     4.4.  ORIGINATOR FIELDS
      
           The standard allows only a subset of the combinations possi-
      ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
      and Resent-Reply-To fields.  The limitation is intentional.
      
-     4.4.1.  FROM / RESENT-FROM
+     4.4.1.  FROM / RESENT-FROM
      
         This field contains the identity of the person(s)  who  wished
         this  message to be sent.  The message-creation process should
@@ -1446,7 +1446,7 @@
         must be machine-usable (addr-specs) and may not contain  named
         lists (groups).
      
-     4.4.2.  SENDER / RESENT-SENDER
+     4.4.2.  SENDER / RESENT-SENDER
      
         This field contains the authenticated identity  of  the  AGENT
         (person,  system  or  process)  that sends the message.  It is
@@ -1484,7 +1484,7 @@
         that program be referenced as part of the "Sender" field mail-
         box specification.
      
-     4.4.3.  REPLY-TO / RESENT-REPLY-TO
+     4.4.3.  REPLY-TO / RESENT-REPLY-TO
      
         This field provides a general  mechanism  for  indicating  any
         mailbox(es)  to which responses are to be sent.  Three typical
@@ -1507,7 +1507,7 @@
                sage.   The  "Reply-To"  field  is added by the message
                originator and is intended to direct replies.
      
-     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
+     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
      
         For systems which automatically  generate  address  lists  for
         replies to messages, the following recommendations are made:
@@ -1545,21 +1545,21 @@
         up  to  the  respective  mail-handling programs to decide what
         additional facilities will be provided.
      
-        Examples are provided in Appendix A.
+        Examples are provided in Appendix A.
      
-     4.5.  RECEIVER FIELDS
+     4.5.  RECEIVER FIELDS
      
-     4.5.1.  TO / RESENT-TO
+     4.5.1.  TO / RESENT-TO
      
         This field contains the identity of the primary recipients  of
         the message.
      
-     4.5.2.  CC / RESENT-CC
+     4.5.2.  CC / RESENT-CC
      
         This field contains the identity of  the  secondary  (informa-
         tional) recipients of the message.
      
-     4.5.3.  BCC / RESENT-BCC
+     4.5.3.  BCC / RESENT-BCC
      
         This field contains the identity of additional  recipients  of
         the  message.   The contents of this field are not included in
@@ -1569,9 +1569,9 @@
         also include it in the text sent to all those indicated in the
         "Bcc" list.
      
-     4.6.  REFERENCE FIELDS
+     4.6.  REFERENCE FIELDS
      
-     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
+     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
      
              This field contains a unique identifier  (the  local-part
         address  unit)  which  refers to THIS version of THIS message.
@@ -1588,37 +1588,37 @@
      
         each receive new message identifiers.
      
-     4.6.2.  IN-REPLY-TO
+     4.6.2.  IN-REPLY-TO
      
              The contents of this field identify  previous  correspon-
         dence  which this message answers.  Note that if message iden-
         tifiers are used in this  field,  they  must  use  the  msg-id
         specification format.
      
-     4.6.3.  REFERENCES
+     4.6.3.  REFERENCES
      
              The contents of this field identify other  correspondence
         which  this message references.  Note that if message identif-
         iers are used, they must use the msg-id specification format.
      
-     4.6.4.  KEYWORDS
+     4.6.4.  KEYWORDS
      
              This field contains keywords  or  phrases,  separated  by
         commas.
      
-     4.7.  OTHER FIELDS
+     4.7.  OTHER FIELDS
      
-     4.7.1.  SUBJECT
+     4.7.1.  SUBJECT
      
              This is intended to provide a summary,  or  indicate  the
         nature, of the message.
      
-     4.7.2.  COMMENTS
+     4.7.2.  COMMENTS
      
              Permits adding text comments  onto  the  message  without
         disturbing the contents of the message's body.
      
-     4.7.3.  ENCRYPTED
+     4.7.3.  ENCRYPTED
      
              Sometimes,  data  encryption  is  used  to  increase  the
         privacy  of  message  contents.   If the body of a message has
@@ -1648,7 +1648,7 @@
         work  Information Center, SRI International, Menlo Park, Cali-
         fornia.
      
-     4.7.4.  EXTENSION-FIELD
+     4.7.4.  EXTENSION-FIELD
      
              A limited number of common fields have  been  defined  in
         this  document.   As  network mail requirements dictate, addi-
@@ -1660,7 +1660,7 @@
              Names of Extension-fields are registered with the Network
         Information Center, SRI International, Menlo Park, California.
      
-     4.7.5.  USER-DEFINED-FIELD
+     4.7.5.  USER-DEFINED-FIELD
      
              Individual users of network mail are free to  define  and
         use  additional  header  fields.   Such fields must have names
@@ -1696,9 +1696,9 @@
      
Standard for ARPA Internet Text Messages
      
      
-     5.  DATE AND TIME SPECIFICATION
+     5.  DATE AND TIME SPECIFICATION
      
-     5.1.  SYNTAX
+     5.1.  SYNTAX
      
      date-time   =  [ day "," ] date time        ; dd mm yy
                                                  ;  hh:mm:ss zzz
@@ -1730,7 +1730,7 @@
                  / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                  ;  hours+min. (HHMM)
      
-     5.2.  SEMANTICS
+     5.2.  SEMANTICS
      
           If included, day-of-week must be the day implied by the date
      specification.
@@ -1751,9 +1751,9 @@
      
Standard for ARPA Internet Text Messages
      
      
-     6.  ADDRESS SPECIFICATION
+     6.  ADDRESS SPECIFICATION
      
-     6.1.  SYNTAX
+     6.1.  SYNTAX
      
      address     =  mailbox                      ; one addressee
                  /  group                        ; named list
@@ -1778,7 +1778,7 @@
      
      domain-ref  =  atom                         ; symbolic reference
      
-     6.2.  SEMANTICS
+     6.2.  SEMANTICS
      
           A mailbox receives mail.  It is a  conceptual  entity  which
      does  not necessarily pertain to file storage.  For example, some
@@ -1793,7 +1793,7 @@
      string is uninterpreted, except by the final sub-domain; the rest
      of the mail service merely transmits it as a literal string.
      
-     6.2.1.  DOMAINS
+     6.2.1.  DOMAINS
      
         A name-domain is a set of registered (mail)  names.   A  name-
         domain  specification  resolves  to  a subordinate name-domain
@@ -1863,7 +1863,7 @@
      
         the user name, placing the message in the user's mailbox.
      
-     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
+     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
      
         Since any number of  levels  is  possible  within  the  domain
         hierarchy,  specification  of  a  fully  qualified address can
@@ -1932,7 +1932,7 @@
                examples,   and   only  ONE  SPACE  between  contiguous
                <word>s.
      
-     6.2.3.  DOMAIN TERMS
+     6.2.3.  DOMAIN TERMS
      
         A domain-ref must be THE official name of a registry, network,
         or  host.   It  is  a  symbolic  reference, within a name sub-
@@ -1961,7 +1961,7 @@
         under  in  the  ARPA Internet, are registered with the Network
         Information Center, SRI International, Menlo Park, California.
      
-     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
+     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
      
         The local-part of an  addr-spec  in  a  mailbox  specification
         (i.e.,  the  host's  name for the mailbox) is understood to be
@@ -1995,7 +1995,7 @@
         of  the  mail  system,  within  the  Registry.Org  domain,  is
         "First.Last", again without quotation marks.
      
-     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
+     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
      
         In some cases, the boundary between local-part and domain  can
         be  flexible.  The local-part may be a simple string, which is
@@ -2036,7 +2036,7 @@
                tain only that portion of the  address  which  deviates
                from the form or intention of the domain field.
      
-     6.2.6.  MULTIPLE MAILBOXES
+     6.2.6.  MULTIPLE MAILBOXES
      
         An individual may have several mailboxes and wish  to  receive
         mail  at  whatever  mailbox  is  convenient  for the sender to
@@ -2067,7 +2067,7 @@
         that the mailbox reference will be expanded to a list or  that
         there is a group with one member.
      
-     6.2.7.  EXPLICIT PATH SPECIFICATION
+     6.2.7.  EXPLICIT PATH SPECIFICATION
      
         At times, a  message  originator  may  wish  to  indicate  the
         transmission  path  that  a  message  should  follow.  This is
@@ -2089,7 +2089,7 @@
                of transmission route should be left to the mail  tran-
                sport service.
      
-     6.3.  RESERVED ADDRESS
+     6.3.  RESERVED ADDRESS
      
           It often is necessary to send mail to a site, without  know-
      ing  any  of its valid addresses.  For example, there may be mail
@@ -2136,7 +2136,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     7.  BIBLIOGRAPHY
+     7.  BIBLIOGRAPHY
      
      
      ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
@@ -2249,13 +2249,13 @@
                                  APPENDIX
      
      
-     A.  EXAMPLES
+     A.  EXAMPLES
      
-     A.1.  ADDRESSES
+     A.1.  ADDRESSES
      
-     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
+     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
      
-     A.1.2.  Neuman@BBN-TENEXA
+     A.1.2.  Neuman@BBN-TENEXA
      
              These two "Alfred Neuman" examples have identical  seman-
         tics, as far as the operation of the local host's mail sending
@@ -2272,14 +2272,14 @@
                the remainder of the hierarchy, starting with  the  top
                level.
      
-     A.1.3.  "George, Ted" <Shared@Group.Arpanet>
+     A.1.3.  "George, Ted" <Shared@Group.Arpanet>
      
              This form might be used to indicate that a single mailbox
         is  shared  by several users.  The quoted string is ignored by
         the originating host's mailer, because  "Shared@Group.Arpanet"
         completely specifies the destination mailbox.
      
-     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
+     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
      
              The "(the  Stilt)" is a comment, which is NOT included in
         the  destination  mailbox  address  handed  to the originating
@@ -2287,7 +2287,7 @@
         "Wilt.Chamberlain", with NO space between the first and second
         words.
      
-     A.1.5.  Address Lists
+     A.1.5.  Address Lists
      
      Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
                 Childs@WGBH.Boston, Galloping Gourmet@
@@ -2304,9 +2304,9 @@
         This group list example points out the use of comments and the
         mixing of addresses and groups.
      
-     A.2.  ORIGINATOR ITEMS
+     A.2.  ORIGINATOR ITEMS
      
-     A.2.1.  Author-sent
+     A.2.1.  Author-sent
      
              George Jones logs into his host  as  "Jones".   He  sends
         mail himself.
@@ -2317,7 +2317,7 @@
      
             From:  George Jones <Jones@Group.Org>
      
-     A.2.2.  Secretary-sent
+     A.2.2.  Secretary-sent
      
              George Jones logs in as Jones on his  host.   His  secre-
         tary,  who logs in as Secy sends mail for him.  Replies to the
@@ -2326,7 +2326,7 @@
             From:    George Jones <Jones@Group>
             Sender:  Secy@Other-Group
      
-     A.2.3.  Secretary-sent, for user of shared directory
+     A.2.3.  Secretary-sent, for user of shared directory
      
              George Jones' secretary sends mail  for  George.  Replies
         should go to George.
@@ -2338,7 +2338,7 @@
         "<",  but  adding a space enhances readability (as is the case
         in other examples.
      
-     A.2.4.  Committee activity, with one author
+     A.2.4.  Committee activity, with one author
      
              George is a member of a committee.  He wishes to have any
         replies to his message go to all committee members.
@@ -2361,7 +2361,7 @@
         SEDES the sending of a reply to the person named in the "From"
         field.
      
-     A.2.5.  Secretary acting as full agent of author
+     A.2.5.  Secretary acting as full agent of author
      
              George Jones asks his secretary  (Secy@Host)  to  send  a
         message for him in his capacity as Group.  He wants his secre-
@@ -2371,7 +2371,7 @@
             Sender:   Secy@Host
             Reply-To: Secy@Host
      
-     A.2.6.  Agent for user without online mailbox
+     A.2.6.  Agent for user without online mailbox
      
              A friend  of  George's,  Sarah,  is  visiting.   George's
         secretary  sends  some  mail to a friend of Sarah in computer-
@@ -2382,7 +2382,7 @@
             Sender:   Secy-Name <Secy@Registry>
             Reply-To: Jones@Registry.
      
-     A.2.7.  Agent for member of a committee
+     A.2.7.  Agent for member of a committee
      
              George's secretary sends out a message which was authored
         jointly by all the members of a committee.  Note that the name
@@ -2411,9 +2411,9 @@
      
Standard for ARPA Internet Text Messages
      
      
-     A.3.  COMPLETE HEADERS
+     A.3.  COMPLETE HEADERS
      
-     A.3.1.  Minimum required
+     A.3.1.  Minimum required
      
      Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
      From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
@@ -2422,7 +2422,7 @@
         Note that the "Bcc" field may be empty, while the  "To"  field
         is required to have at least one address.
      
-     A.3.2.  Using some of the additional fields
+     A.3.2.  Using some of the additional fields
      
      Date:     26 Aug 76 1430 EDT
      From:     George Jones<Group@Host>
@@ -2431,7 +2431,7 @@
                Sam.Irving@Other-Host
      Message-ID:  <some.string@SHOST>
      
-     A.3.3.  About as complex as you're going to get
+     A.3.3.  About as complex as you're going to get
      
      Date     :  27 Aug 76 0932 PDT
      From     :  Ken Davis <KDavis@This-Host.This-net>
@@ -2466,7 +2466,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     B.  SIMPLE FIELD PARSING
+     B.  SIMPLE FIELD PARSING
      
           Some mail-reading software systems may wish to perform  only
      minimal  processing,  ignoring  the internal syntax of structured
@@ -2485,7 +2485,7 @@
      part of this specification.  One small exception is that the con-
      tents of field-bodies consist only of text:
      
-     B.1.  SYNTAX
+     B.1.  SYNTAX
      
      
      message         =   *field *(CRLF *text)
@@ -2497,7 +2497,7 @@
      field-body      =   *text [CRLF LWSP-char field-body]
      
      
-     B.2.  SEMANTICS
+     B.2.  SEMANTICS
      
           Headers occur before the message body and are terminated  by
      a null line (i.e., two contiguous CRLFs).
@@ -2521,7 +2521,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     C.  DIFFERENCES FROM RFC #733
+     C.  DIFFERENCES FROM RFC #733
      
           The following summarizes the differences between this  stan-
      dard  and the one specified in Arpanet Request for Comments #733,
@@ -2529,16 +2529,16 @@
      differences  are  listed  in the order of their occurrence in the
      current specification.
      
-     C.1.  FIELD DEFINITIONS
+     C.1.  FIELD DEFINITIONS
      
-     C.1.1.  FIELD NAMES
+     C.1.1.  FIELD NAMES
      
         These now must be a sequence of  printable  characters.   They
         may not contain any LWSP-chars.
      
-     C.2.  LEXICAL TOKENS
+     C.2.  LEXICAL TOKENS
      
-     C.2.1.  SPECIALS
+     C.2.1.  SPECIALS
      
         The characters period ("."), left-square  bracket  ("["),  and
         right-square  bracket ("]") have been added.  For presentation
@@ -2548,23 +2548,23 @@
         space  is  permitted  between them.  The presence of one LWSP-
         char between other tokens is still directed.
      
-     C.2.2.  ATOM
+     C.2.2.  ATOM
      
         Atoms may not contain SPACE.
      
-     C.2.3.  SPECIAL TEXT
+     C.2.3.  SPECIAL TEXT
      
         ctext and qtext have had backslash ("\") added to the list  of
         prohibited characters.
      
-     C.2.4.  DOMAINS
+     C.2.4.  DOMAINS
      
         The lexical tokens  <domain-literal>  and  <dtext>  have  been
         added.
      
-     C.3.  MESSAGE SPECIFICATION
+     C.3.  MESSAGE SPECIFICATION
      
-     C.3.1.  TRACE
+     C.3.1.  TRACE
      
         The "Return-path:" and "Received:" fields have been specified.
      
@@ -2576,51 +2576,51 @@
      
Standard for ARPA Internet Text Messages
      
      
-     C.3.2.  FROM
+     C.3.2.  FROM
      
         The "From" field must contain machine-usable addresses  (addr-
         spec).   Multiple  addresses may be specified, but named-lists
         (groups) may not.
      
-     C.3.3.  RESENT
+     C.3.3.  RESENT
      
         The meta-construct of prefacing field names  with  the  string
         "Resent-"  has been added, to indicate that a message has been
         forwarded by an intermediate recipient.
      
-     C.3.4.  DESTINATION
+     C.3.4.  DESTINATION
      
         A message must contain at least one destination address field.
         "To" and "CC" are required to contain at least one address.
      
-     C.3.5.  IN-REPLY-TO
+     C.3.5.  IN-REPLY-TO
      
         The field-body is no longer a comma-separated list, although a
         sequence is still permitted.
      
-     C.3.6.  REFERENCE
+     C.3.6.  REFERENCE
      
         The field-body is no longer a comma-separated list, although a
         sequence is still permitted.
      
-     C.3.7.  ENCRYPTED
+     C.3.7.  ENCRYPTED
      
         A field has been specified that permits  senders  to  indicate
         that the body of a message has been encrypted.
      
-     C.3.8.  EXTENSION-FIELD
+     C.3.8.  EXTENSION-FIELD
      
         Extension fields are prohibited from beginning with the  char-
         acters "X-".
      
-     C.4.  DATE AND TIME SPECIFICATION
+     C.4.  DATE AND TIME SPECIFICATION
      
-     C.4.1.  SIMPLIFICATION
+     C.4.1.  SIMPLIFICATION
      
         Fewer optional forms are permitted  and  the  list  of  three-
         letter time zones has been shortened.
      
-     C.5.  ADDRESS SPECIFICATION
+     C.5.  ADDRESS SPECIFICATION
      
      
      
@@ -2631,25 +2631,25 @@
      
Standard for ARPA Internet Text Messages
      
      
-     C.5.1.  ADDRESS
+     C.5.1.  ADDRESS
      
         The use of quoted-string, and the ":"-atom-":" construct, have
         been  removed.   An  address  now  is  either a single mailbox
         reference or is a named list of addresses.  The  latter  indi-
         cates a group distribution.
      
-     C.5.2.  GROUPS
+     C.5.2.  GROUPS
      
         Group lists are now required to to have a name.   Group  lists
         may not be nested.
      
-     C.5.3.  MAILBOX
+     C.5.3.  MAILBOX
      
         A mailbox specification  may  indicate  a  person's  name,  as
         before.   Such  a  named  list  no longer may specify multiple
         mailboxes and may not be nested.
      
-     C.5.4.  ROUTE ADDRESSING
+     C.5.4.  ROUTE ADDRESSING
      
         Addresses now are taken to be absolute, global specifications,
         independent  of transmission paths.  The <route> construct has
@@ -2659,16 +2659,16 @@
         hierarchical addressing.  The current standard separates these
         specifications and only one at-sign is permitted.
      
-     C.5.5.  AT-SIGN
+     C.5.5.  AT-SIGN
      
         The string " at " no longer is used as an  address  delimiter.
         Only at-sign ("@") serves the function.
      
-     C.5.6.  DOMAINS
+     C.5.6.  DOMAINS
      
         Hierarchical, logical name-domains have been added.
      
-     C.6.  RESERVED ADDRESS
+     C.6.  RESERVED ADDRESS
      
      The local-part "Postmaster" has been reserved, so that users  can
      be guaranteed at least one valid address at a site.
@@ -2686,7 +2686,7 @@
      
Standard for ARPA Internet Text Messages
      
      
-     D.  ALPHABETICAL LISTING OF SYNTAX RULES
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES
      
      address     =  mailbox                      ; one addressee
                  /  group                        ; named list

From 2785e802a7ab7ef5997f87f28be467faa74d711d Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Thu, 21 Jul 2022 10:46:13 -0400
Subject: [PATCH 08/16] EIP-1 wording change

---
 EIPS/eip-1.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md
index 2b0e5e2cae86d4..e7be5cc8aa3161 100644
--- a/EIPS/eip-1.md
+++ b/EIPS/eip-1.md
@@ -267,7 +267,7 @@ When referring to an EIP by number, it should be written in the hyphenated form
 
 ### IETF RFCs
 
-When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which ONLY includes the HTML rendering of that RFC, with all anchors replaced with internal anchors, in that directory.
+When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which ONLY includes the HTML rendering of that RFC.
 
 ### RFC 2119
 

From 709121d390efe44a73f39385df3d1ac071651c98 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Thu, 21 Jul 2022 11:24:40 -0400
Subject: [PATCH 09/16] Ignore RFCs in htmlpoofer

---
 .github/workflows/ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 85ef762025a41c..96101670db6c31 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -28,7 +28,7 @@ jobs:
           bundle exec jekyll build
       
       - name: HTML Proofer
-        run: bundle exec htmlproofer ./_site --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --disable-external
+        run: bundle exec htmlproofer ./_site --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --disable-external --ignore_files */RFCs/*
       
       - name: DNS Validator
         run: bundle exec github-pages health-check

From 0d41d7bf48727e79f2c5feb731b3fe5d42c92542 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Tue, 26 Jul 2022 11:57:17 -0400
Subject: [PATCH 10/16] Remove unneeded option

---
 .github/workflows/ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 96101670db6c31..85ef762025a41c 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -28,7 +28,7 @@ jobs:
           bundle exec jekyll build
       
       - name: HTML Proofer
-        run: bundle exec htmlproofer ./_site --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --disable-external --ignore_files */RFCs/*
+        run: bundle exec htmlproofer ./_site --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --disable-external
       
       - name: DNS Validator
         run: bundle exec github-pages health-check

From c47a8a34d9ef7f1fce4c97bd6aadca9f7da37d96 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Tue, 26 Jul 2022 11:57:23 -0400
Subject: [PATCH 11/16] Delete README.md

---
 assets/RFCs/README.md | 9 ---------
 1 file changed, 9 deletions(-)
 delete mode 100644 assets/RFCs/README.md

diff --git a/assets/RFCs/README.md b/assets/RFCs/README.md
deleted file mode 100644
index 63fa6eddd5e183..00000000000000
--- a/assets/RFCs/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Internet Engineering Task Force (IETF) Request for Comments (RFC)
-
-This folder is dedicated to storing relevant RFCs. If you would like to add an RFC to this folder, please submit a pull request adding it!
-
-According to the [IETF's FAQ](https://trustee.ietf.org/about/faq/#collapse3103):
-
-> Am I allowed to reproduce whole RFCs?
-> 
-> Yes. Since the beginning of the RFC series, reproduction of whole RFCs (including translation into a language other than English) has been allowed and encouraged. The IETF Trust and the RFC Editor place no restrictions on this. Most RFCs include the standard phrase “Distribution of this memo is unlimited” to indicate this.

From 14b696a6004c3b3895c5cfe94de88badae1bc6cf Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Tue, 26 Jul 2022 11:57:29 -0400
Subject: [PATCH 12/16] Delete rfc2119.html

---
 assets/RFCs/rfc2119.html | 329 ---------------------------------------
 1 file changed, 329 deletions(-)
 delete mode 100644 assets/RFCs/rfc2119.html

diff --git a/assets/RFCs/rfc2119.html b/assets/RFCs/rfc2119.html
deleted file mode 100644
index 34965f686d730c..00000000000000
--- a/assets/RFCs/rfc2119.html
+++ /dev/null
@@ -1,329 +0,0 @@
-
-
-
-    
-    
-    
-      
-      
-      
-      
-      
-      
-      
-RFC 2119: Key words for use in RFCs to Indicate Requirement Levels     
-        
-
-        
-        
-
-[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]         
                                                                        
                                                   BEST CURRENT PRACTICE
Updated by: 8174                                            Errata Exist
Network Working Group                                         S. Bradner
-Request for Comments: 2119                            Harvard University
-BCP: 14                                                       March 1997
-Category: Best Current Practice
-
-
-        Key words for use in RFCs to Indicate Requirement Levels
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Abstract
-
-   In many standards track documents several words are used to signify
-   the requirements in the specification.  These words are often
-   capitalized.  This document defines these words as they should be
-   interpreted in IETF documents.  Authors who follow these guidelines
-   should incorporate this phrase near the beginning of their document:
-
-      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
-      "OPTIONAL" in this document are to be interpreted as described in
-      RFC 2119.
-
-   Note that the force of these words is modified by the requirement
-   level of the document in which they are used.
-
-1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
-   definition is an absolute requirement of the specification.
-
-2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
-   definition is an absolute prohibition of the specification.
-
-3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
-   may exist valid reasons in particular circumstances to ignore a
-   particular item, but the full implications must be understood and
-   carefully weighed before choosing a different course.
-
-4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
-   there may exist valid reasons in particular circumstances when the
-   particular behavior is acceptable or even useful, but the full
-   implications should be understood and the case carefully weighed
-   before implementing any behavior described with this label.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 1]

-

-RFC 2119                     RFC Key Words                    March 1997
-
-
-5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
-   truly optional.  One vendor may choose to include the item because a
-   particular marketplace requires it or because the vendor feels that
-   it enhances the product while another vendor may omit the same item.
-   An implementation which does not include a particular option MUST be
-   prepared to interoperate with another implementation which does
-   include the option, though perhaps with reduced functionality. In the
-   same vein an implementation which does include a particular option
-   MUST be prepared to interoperate with another implementation which
-   does not include the option (except, of course, for the feature the
-   option provides.)
-
-6. Guidance in the use of these Imperatives
-
-   Imperatives of the type defined in this memo must be used with care
-   and sparingly.  In particular, they MUST only be used where it is
-   actually required for interoperation or to limit behavior which has
-   potential for causing harm (e.g., limiting retransmisssions)  For
-   example, they must not be used to try to impose a particular method
-   on implementors where the method is not required for
-   interoperability.
-
-7. Security Considerations
-
-   These terms are frequently used to specify behavior with security
-   implications.  The effects on security of not implementing a MUST or
-   SHOULD, or doing something the specification says MUST NOT or SHOULD
-   NOT be done may be very subtle. Document authors should take the time
-   to elaborate the security implications of not following
-   recommendations or requirements as most implementors will not have
-   had the benefit of the experience and discussion that produced the
-   specification.
-
-8. Acknowledgments
-
-   The definitions of these terms are an amalgam of definitions taken
-   from a number of RFCs.  In addition, suggestions have been
-   incorporated from a number of people including Robert Ullmann, Thomas
-   Narten, Neal McBurnett, and Robert Elz.
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]

-

-RFC 2119                     RFC Key Words                    March 1997
-
-
-9. Author's Address
-
-      Scott Bradner
-      Harvard University
-      1350 Mass. Ave.
-      Cambridge, MA 02138
-
-      phone - +1 617 495 3864
-
-      email - sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-

-
-
-
-
-
\ No newline at end of file

From 0f04a150c635752b36218e1b3a95246ce57212d0 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Tue, 26 Jul 2022 11:57:40 -0400
Subject: [PATCH 13/16] Delete rfc822.html

---
 assets/RFCs/rfc822.html | 2911 ---------------------------------------
 1 file changed, 2911 deletions(-)
 delete mode 100644 assets/RFCs/rfc822.html

diff --git a/assets/RFCs/rfc822.html b/assets/RFCs/rfc822.html
deleted file mode 100644
index 6590f0786d72a6..00000000000000
--- a/assets/RFCs/rfc822.html
+++ /dev/null
@@ -1,2911 +0,0 @@
-
-
-
-    
-    
-    
-      
-      
-      
-      
-      
-      
-      
-RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES    
-        
-
-        
-        
-
-[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]         
                                                                        
Obsoleted by: 2822                                     INTERNET STANDARD
Updated by: 1123, 2156, 1327, 1138, 1148                    Errata Exist
     RFC #  822
-     
-     Obsoletes:  RFC #733  (NIC #41952)
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-                        STANDARD FOR THE FORMAT OF
-     
-                        ARPA INTERNET TEXT MESSAGES
-     
-     
-     
-     
-     
-     
-                              August 13, 1982
-     
-     
-     
-     
-     
-     
-                                Revised by
-     
-                             David H. Crocker
-     
-     
-                      Dept. of Electrical Engineering
-                 University of Delaware, Newark, DE  19711
-                      Network:  DCrocker @ UDel-Relay
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     

-     
Standard for ARPA Internet Text Messages
-     
-     
-                             TABLE OF CONTENTS
-     
-     
-     PREFACE ....................................................   ii
-     
-     1.  INTRODUCTION ...........................................    1
-     
-         1.1.  Scope ............................................    1
-         1.2.  Communication Framework ..........................    2
-     
-     2.  NOTATIONAL CONVENTIONS .................................    3
-     
-     3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
-     
-         3.1.  General Description ..............................    5
-         3.2.  Header Field Definitions .........................    9
-         3.3.  Lexical Tokens ...................................   10
-         3.4.  Clarifications ...................................   11
-     
-     4.  MESSAGE SPECIFICATION ..................................   17
-     
-         4.1.  Syntax ...........................................   17
-         4.2.  Forwarding .......................................   19
-         4.3.  Trace Fields .....................................   20
-         4.4.  Originator Fields ................................   21
-         4.5.  Receiver Fields ..................................   23
-         4.6.  Reference Fields .................................   23
-         4.7.  Other Fields .....................................   24
-     
-     5.  DATE AND TIME SPECIFICATION ............................   26
-     
-         5.1.  Syntax ...........................................   26
-         5.2.  Semantics ........................................   26
-     
-     6.  ADDRESS SPECIFICATION ..................................   27
-     
-         6.1.  Syntax ...........................................   27
-         6.2.  Semantics ........................................   27
-         6.3.  Reserved Address .................................   33
-     
-     7.  BIBLIOGRAPHY ...........................................   34
-     
-     
-                             APPENDIX
-     
-     A.  EXAMPLES ...............................................   36
-     B.  SIMPLE FIELD PARSING ...................................   40
-     C.  DIFFERENCES FROM RFC #733 ..............................   41
-     D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
-     
-     
-     August 13, 1982               - i -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-                                  PREFACE
-     
-     
-          By 1977, the Arpanet employed several informal standards for
-     the  text  messages (mail) sent among its host computers.  It was
-     felt necessary to codify these practices and  provide  for  those
-     features  that  seemed  imminent.   The result of that effort was
-     Request for Comments (RFC) #733, "Standard for the Format of ARPA
-     Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
-     The specification attempted to avoid major  changes  in  existing
-     software, while permitting several new features.
-     
-          This document revises the specifications  in  RFC  #733,  in
-     order  to  serve  the  needs  of the larger and more complex ARPA
-     Internet.  Some of RFC #733's features failed  to  gain  adequate
-     acceptance.   In  order to simplify the standard and the software
-     that follows it, these features have been removed.   A  different
-     addressing  scheme  is  used, to handle the case of inter-network
-     mail; and the concept of re-transmission has been introduced.
-     
-          This specification is intended for use in the ARPA Internet.
-     However, an attempt has been made to free it of any dependence on
-     that environment, so that it can be applied to other network text
-     message systems.
-     
-          The specification of RFC #733 took place over the course  of
-     one  year, using the ARPANET mail environment, itself, to provide
-     an on-going forum for discussing the capabilities to be included.
-     More  than  twenty individuals, from across the country, partici-
-     pated in  the  original  discussion.   The  development  of  this
-     revised specification has, similarly, utilized network mail-based
-     group discussion.  Both specification efforts  greatly  benefited
-     from the comments and ideas of the participants.
-     
-          The syntax of the standard,  in  RFC  #733,  was  originally
-     specified  in  the  Backus-Naur Form (BNF) meta-language.  Ken L.
-     Harrenstien, of SRI International, was responsible for  re-coding
-     the  BNF  into  an  augmented  BNF  that makes the representation
-     smaller and easier to understand.
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - ii -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     1.  INTRODUCTION
-     
-     1.1.  SCOPE
-     
-          This standard specifies a syntax for text messages that  are
-     sent  among  computer  users, within the framework of "electronic
-     mail".  The standard supersedes  the  one  specified  in  ARPANET
-     Request  for Comments #733, "Standard for the Format of ARPA Net-
-     work Text Messages".
-     
-          In this context, messages are viewed as having  an  envelope
-     and  contents.   The  envelope  contains  whatever information is
-     needed to accomplish transmission  and  delivery.   The  contents
-     compose  the object to be delivered to the recipient.  This stan-
-     dard applies only to the format and some of the semantics of mes-
-     sage  contents.   It contains no specification of the information
-     in the envelope.
-     
-          However, some message systems may use information  from  the
-     contents  to create the envelope.  It is intended that this stan-
-     dard facilitate the acquisition of such information by programs.
-     
-          Some message systems may  store  messages  in  formats  that
-     differ  from the one specified in this standard.  This specifica-
-     tion is intended strictly as a definition of what message content
-     format is to be passed BETWEEN hosts.
-     
-     Note:  This standard is NOT intended to dictate the internal for-
-            mats  used  by sites, the specific message system features
-            that they are expected to support, or any of  the  charac-
-            teristics  of  user interface programs that create or read
-            messages.
-     
-          A distinction should be made between what the  specification
-     REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
-     rich with formally-structured components of information or can be
-     kept small and simple, with a minimum of such information.  Also,
-     the standard simplifies the interpretation  of  differing  visual
-     formats  in  messages;  only  the  visual  aspect of a message is
-     affected and not the interpretation  of  information  within  it.
-     Implementors may choose to retain such visual distinctions.
-     
-          The formal definition is divided into four levels.  The bot-
-     tom level describes the meta-notation used in this document.  The
-     second level describes basic lexical analyzers that  feed  tokens
-     to  higher-level  parsers.   Next is an overall specification for
-     messages; it permits distinguishing individual fields.   Finally,
-     there is definition of the contents of several structured fields.
-     
-     
-     
-     August 13, 1982               - 1 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     1.2.  COMMUNICATION FRAMEWORK
-     
-          Messages consist of lines of text.   No  special  provisions
-     are  made for encoding drawings, facsimile, speech, or structured
-     text.  No significant consideration has been given  to  questions
-     of  data  compression  or to transmission and storage efficiency,
-     and the standard tends to be free with the number  of  bits  con-
-     sumed.   For  example,  field  names  are specified as free text,
-     rather than special terse codes.
-     
-          A general "memo" framework is used.  That is, a message con-
-     sists of some information in a rigid format, followed by the main
-     part of the message, with a format that is not specified in  this
-     document.   The  syntax of several fields of the rigidly-formated
-     ("headers") section is defined in  this  specification;  some  of
-     these fields must be included in all messages.
-     
-          The syntax  that  distinguishes  between  header  fields  is
-     specified  separately  from  the  internal  syntax for particular
-     fields.  This separation is intended to allow simple  parsers  to
-     operate on the general structure of messages, without concern for
-     the detailed structure of individual header fields.   Appendix  B
-     is provided to facilitate construction of these parsers.
-     
-          In addition to the fields specified in this document, it  is
-     expected  that  other fields will gain common use.  As necessary,
-     the specifications for these "extension-fields" will be published
-     through  the same mechanism used to publish this document.  Users
-     may also  wish  to  extend  the  set  of  fields  that  they  use
-     privately.  Such "user-defined fields" are permitted.
-     
-          The framework severely constrains document tone and  appear-
-     ance and is primarily useful for most intra-organization communi-
-     cations and  well-structured   inter-organization  communication.
-     It  also  can  be used for some types of inter-process communica-
-     tion, such as simple file transfer and remote job entry.  A  more
-     robust  framework might allow for multi-font, multi-color, multi-
-     dimension encoding of information.  A  less  robust  one,  as  is
-     present  in  most  single-machine  message  systems,  would  more
-     severely constrain the ability to add fields and the decision  to
-     include specific fields.  In contrast with paper-based communica-
-     tion, it is interesting to note that the RECEIVER  of  a  message
-     can   exercise  an  extraordinary  amount  of  control  over  the
-     message's appearance.  The amount of actual control available  to
-     message  receivers  is  contingent upon the capabilities of their
-     individual message systems.
-     
-     
-     
-     
-     
-     August 13, 1982               - 2 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     2.  NOTATIONAL CONVENTIONS
-     
-          This specification uses an augmented Backus-Naur Form  (BNF)
-     notation.  The differences from standard BNF involve naming rules
-     and indicating repetition and "local" alternatives.
-     
-     2.1.  RULE NAMING
-     
-          Angle brackets ("<", ">") are not  used,  in  general.   The
-     name  of  a rule is simply the name itself, rather than "<name>".
-     Quotation-marks enclose literal text (which may be  upper  and/or
-     lower  case).   Certain  basic  rules  are  in uppercase, such as
-     SPACE, TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used  in
-     rule  definitions,  and  in  the rest of this  document, whenever
-     their presence will facilitate discerning the use of rule names.
-     
-     2.2.  RULE1 / RULE2:  ALTERNATIVES
-     
-          Elements separated by slash ("/") are alternatives.   There-
-     fore "foo / bar" will accept foo or bar.
-     
-     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
-     
-          Elements enclosed in parentheses are  treated  as  a  single
-     element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
-     sequences "elem foo elem" and "elem bar elem".
-     
-     2.4.  *RULE:  REPETITION
-     
-          The character "*" preceding an element indicates repetition.
-     The full form is:
-     
-                              <l>*<m>element
-     
-     indicating at least <l> and at most <m> occurrences  of  element.
-     Default values are 0 and infinity so that "*(element)" allows any
-     number, including zero; "1*element" requires at  least  one;  and
-     "1*2element" allows one or two.
-     
-     2.5.  [RULE]:  OPTIONAL
-     
-          Square brackets enclose optional elements; "[foo  bar]"   is
-     equivalent to "*1(foo bar)".
-     
-     2.6.  NRULE:  SPECIFIC REPETITION
-     
-          "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
-     exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
-     number, and 3ALPHA is a string of three alphabetic characters.
-     
-     
-     August 13, 1982               - 3 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     2.7.  #RULE:  LISTS
-     
-          A construct "#" is defined, similar to "*", as follows:
-     
-                              <l>#<m>element
-     
-     indicating at least <l> and at most <m> elements, each  separated
-     by  one  or more commas (","). This makes the usual form of lists
-     very easy; a rule such as '(element *("," element))' can be shown
-     as  "1#element".   Wherever this construct is used, null elements
-     are allowed, but do not  contribute  to  the  count  of  elements
-     present.   That  is,  "(element),,(element)"  is  permitted,  but
-     counts as only two elements.  Therefore, where at least one  ele-
-     ment  is required, at least one non-null element must be present.
-     Default values are 0 and infinity so that "#(element)" allows any
-     number,  including  zero;  "1#element" requires at least one; and
-     "1#2element" allows one or two.
-     
-     2.8.  ; COMMENTS
-     
-          A semi-colon, set off some distance to  the  right  of  rule
-     text,  starts  a comment that continues to the end of line.  This
-     is a simple way of including useful notes in  parallel  with  the
-     specifications.
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982               - 4 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     3.  LEXICAL ANALYSIS OF MESSAGES
-     
-     3.1.  GENERAL DESCRIPTION
-     
-          A message consists of header fields and, optionally, a body.
-     The  body  is simply a sequence of lines containing ASCII charac-
-     ters.  It is separated from the headers by a null line  (i.e.,  a
-     line with nothing preceding the CRLF).
-     
-     3.1.1.  LONG HEADER FIELDS
-     
-        Each header field can be viewed as a single, logical  line  of
-        ASCII  characters,  comprising  a field-name and a field-body.
-        For convenience, the field-body  portion  of  this  conceptual
-        entity  can be split into a multiple-line representation; this
-        is called "folding".  The general rule is that wherever  there
-        may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
-        immediately followed by AT LEAST one LWSP-char may instead  be
-        inserted.  Thus, the single line
-     
-            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
-     
-        can be represented as:
-     
-            To:  "Joe & J. Harvey" <ddd @ Org>,
-                    JJV@BBN
-     
-        and
-     
-            To:  "Joe & J. Harvey"
-                            <ddd@ Org>, JJV
-             @BBN
-     
-        and
-     
-            To:  "Joe &
-             J. Harvey" <ddd @ Org>, JJV @ BBN
-     
-             The process of moving  from  this  folded   multiple-line
-        representation  of a header field to its single line represen-
-        tation is called "unfolding".  Unfolding  is  accomplished  by
-        regarding   CRLF   immediately  followed  by  a  LWSP-char  as
-        equivalent to the LWSP-char.
-     
-        Note:  While the standard  permits  folding  wherever  linear-
-               white-space is permitted, it is recommended that struc-
-               tured fields, such as those containing addresses, limit
-               folding  to higher-level syntactic breaks.  For address
-               fields, it  is  recommended  that  such  folding  occur
-     
-     
-     August 13, 1982               - 5 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-               between addresses, after the separating comma.
-     
-     3.1.2.  STRUCTURE OF HEADER FIELDS
-     
-        Once a field has been unfolded, it may be viewed as being com-
-        posed of a field-name followed by a colon (":"), followed by a
-        field-body, and  terminated  by  a  carriage-return/line-feed.
-        The  field-name must be composed of printable ASCII characters
-        (i.e., characters that  have  values  between  33.  and  126.,
-        decimal, except colon).  The field-body may be composed of any
-        ASCII characters, except CR or LF.  (While CR and/or LF may be
-        present  in the actual text, they are removed by the action of
-        unfolding the field.)
-     
-        Certain field-bodies of headers may be  interpreted  according
-        to  an  internal  syntax  that some systems may wish to parse.
-        These  fields  are  called  "structured   fields".    Examples
-        include  fields containing dates and addresses.  Other fields,
-        such as "Subject"  and  "Comments",  are  regarded  simply  as
-        strings of text.
-     
-        Note:  Any field which has a field-body  that  is  defined  as
-               other  than  simply <text> is to be treated as a struc-
-               tured field.
-     
-               Field-names, unstructured field bodies  and  structured
-               field bodies each are scanned by their own, independent
-               "lexical" analyzers.
-     
-     3.1.3.  UNSTRUCTURED FIELD BODIES
-     
-        For some fields, such as "Subject" and "Comments",  no  struc-
-        turing  is assumed, and they are treated simply as <text>s, as
-        in the message body.  Rules of folding apply to these  fields,
-        so  that  such  field  bodies  which occupy several lines must
-        therefore have the second and successive lines indented by  at
-        least one LWSP-char.
-     
-     3.1.4.  STRUCTURED FIELD BODIES
-     
-        To aid in the creation and reading of structured  fields,  the
-        free  insertion   of linear-white-space (which permits folding
-        by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
-        Rather  than  obscuring  the  syntax  specifications for these
-        structured fields with explicit syntax for this  linear-white-
-        space, the existence of another "lexical" analyzer is assumed.
-        This analyzer does not apply  for  unstructured  field  bodies
-        that  are  simply  strings  of  text, as described above.  The
-        analyzer provides  an  interpretation  of  the  unfolded  text
-     
-     
-     August 13, 1982               - 6 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        composing  the body of the field as a sequence of lexical sym-
-        bols.
-     
-        These symbols are:
-     
-                     -  individual special characters
-                     -  quoted-strings
-                     -  domain-literals
-                     -  comments
-                     -  atoms
-     
-        The first four of these symbols  are  self-delimiting.   Atoms
-        are not; they are delimited by the self-delimiting symbols and
-        by  linear-white-space.   For  the  purposes  of  regenerating
-        sequences  of  atoms  and quoted-strings, exactly one SPACE is
-        assumed to exist, and should be used, between them.  (Also, in
-        the "Clarifications" section on "White Space", below, note the
-        rules about treatment of multiple contiguous LWSP-chars.)
-     
-        So, for example, the folded body of an address field
-     
-            ":sysmail"@  Some-Group. Some-Org,
-            Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982               - 7 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        is analyzed into the following lexical symbols and types:
-     
-                    :sysmail              quoted string
-                    @                     special
-                    Some-Group            atom
-                    .                     special
-                    Some-Org              atom
-                    ,                     special
-                    Muhammed              atom
-                    .                     special
-                    (I am  the greatest)  comment
-                    Ali                   atom
-                    @                     atom
-                    (the)                 comment
-                    Vegas                 atom
-                    .                     special
-                    WBA                   atom
-     
-        The canonical representations for the data in these  addresses
-        are the following strings:
-     
-                        ":sysmail"@Some-Group.Some-Org
-     
-        and
-     
-                            Muhammed.Ali@Vegas.WBA
-     
-        Note:  For purposes of display, and when passing  such  struc-
-               tured information to other systems, such as mail proto-
-               col  services,  there  must  be  NO  linear-white-space
-               between  <word>s  that are separated by period (".") or
-               at-sign ("@") and exactly one SPACE between  all  other
-               <word>s.  Also, headers should be in a folded form.
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982               - 8 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     3.2.  HEADER FIELD DEFINITIONS
-     
-          These rules show a field meta-syntax, without regard for the
-     particular  type  or internal syntax.  Their purpose is to permit
-     detection of fields; also, they present to  higher-level  parsers
-     an image of each field as fitting on one line.
-     
-     field       =  field-name ":" [ field-body ] CRLF
-     
-     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
-     
-     field-body  =  field-body-contents
-                    [CRLF LWSP-char field-body]
-     
-     field-body-contents =
-                   <the ASCII characters making up the field-body, as
-                    defined in the following sections, and consisting
-                    of combinations of atom, quoted-string, and
-                    specials tokens, or else consisting of texts>
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982               - 9 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     3.3.  LEXICAL TOKENS
-     
-          The following rules are used to define an underlying lexical
-     analyzer,  which  feeds  tokens to higher level parsers.  See the
-     ANSI references, in the Bibliography.
-     
-                                                 ; (  Octal, Decimal.)
-     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
-     ALPHA       =  <any ASCII alphabetic character>
-                                                 ; (101-132, 65.- 90.)
-                                                 ; (141-172, 97.-122.)
-     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
-     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
-                     character and DEL>          ; (    177,     127.)
-     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
-     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
-     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
-     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
-     <">         =  <ASCII quote mark>           ; (     42,      34.)
-     CRLF        =  CR LF
-     
-     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
-     
-     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
-                                                 ; CRLF => folding
-     
-     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
-                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
-                 /  "." / "[" / "]"              ;  within a word.
-     
-     delimiters  =  specials / linear-white-space / comment
-     
-     text        =  <any CHAR, including bare    ; => atoms, specials,
-                     CR & bare LF, but NOT       ;  comments and
-                     including CRLF>             ;  quoted-strings are
-                                                 ;  NOT recognized.
-     
-     atom        =  1*<any CHAR except specials, SPACE and CTLs>
-     
-     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
-                                                 ;   quoted chars.
-     
-     qtext       =  <any CHAR excepting <">,     ; => may be folded
-                     "\" & CR, and including
-                     linear-white-space>
-     
-     domain-literal =  "[" *(dtext / quoted-pair) "]"
-     
-     
-     
-     
-     August 13, 1982              - 10 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     dtext       =  <any CHAR excluding "[",     ; => may be folded
-                     "]", "\" & CR, & including
-                     linear-white-space>
-     
-     comment     =  "(" *(ctext / quoted-pair / comment) ")"
-     
-     ctext       =  <any CHAR excluding "(",     ; => may be folded
-                     ")", "\" & CR, & including
-                     linear-white-space>
-     
-     quoted-pair =  "\" CHAR                     ; may quote any char
-     
-     phrase      =  1*word                       ; Sequence of words
-     
-     word        =  atom / quoted-string
-     
-     
-     3.4.  CLARIFICATIONS
-     
-     3.4.1.  QUOTING
-     
-        Some characters are reserved for special interpretation,  such
-        as  delimiting lexical tokens.  To permit use of these charac-
-        ters as uninterpreted data, a quoting mechanism  is  provided.
-        To quote a character, precede it with a backslash ("\").
-     
-        This mechanism is not fully general.  Characters may be quoted
-        only  within  a subset of the lexical constructs.  In particu-
-        lar, quoting is limited to use within:
-     
-                             -  quoted-string
-                             -  domain-literal
-                             -  comment
-     
-        Within these constructs, quoting is REQUIRED for  CR  and  "\"
-        and for the character(s) that delimit the token (e.g., "(" and
-        ")" for a comment).  However, quoting  is  PERMITTED  for  any
-        character.
-     
-        Note:  In particular, quoting is NOT permitted  within  atoms.
-               For  example  when  the local-part of an addr-spec must
-               contain a special character, a quoted  string  must  be
-               used.  Therefore, a specification such as:
-     
-                            Full\ Name@Domain
-     
-               is not legal and must be specified as:
-     
-                            "Full Name"@Domain
-     
-     
-     August 13, 1982              - 11 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     3.4.2.  WHITE SPACE
-     
-        Note:  In structured field bodies, multiple linear space ASCII
-               characters  (namely  HTABs  and  SPACEs) are treated as
-               single spaces and may freely surround any  symbol.   In
-               all header fields, the only place in which at least one
-               LWSP-char is REQUIRED is at the beginning of  continua-
-               tion lines in a folded field.
-     
-        When passing text to processes  that  do  not  interpret  text
-        according to this standard (e.g., mail protocol servers), then
-        NO linear-white-space characters should occur between a period
-        (".") or at-sign ("@") and a <word>.  Exactly ONE SPACE should
-        be used in place of arbitrary linear-white-space  and  comment
-        sequences.
-     
-        Note:  Within systems conforming to this standard, wherever  a
-               member of the list of delimiters is allowed, LWSP-chars
-               may also occur before and/or after it.
-     
-        Writers of  mail-sending  (i.e.,  header-generating)  programs
-        should realize that there is no network-wide definition of the
-        effect of ASCII HT (horizontal-tab) characters on the  appear-
-        ance  of  text  at another network host; therefore, the use of
-        tabs in message headers, though permitted, is discouraged.
-     
-     3.4.3.  COMMENTS
-     
-        A comment is a set of ASCII characters, which is  enclosed  in
-        matching  parentheses  and which is not within a quoted-string
-        The comment construct permits message originators to add  text
-        which  will  be  useful  for  human readers, but which will be
-        ignored by the formal semantics.  Comments should be  retained
-        while  the  message  is subject to interpretation according to
-        this standard.  However, comments  must  NOT  be  included  in
-        other  cases,  such  as  during  protocol  exchanges with mail
-        servers.
-     
-        Comments nest, so that if an unquoted left parenthesis  occurs
-        in  a  comment  string,  there  must  also be a matching right
-        parenthesis.  When a comment acts as the delimiter  between  a
-        sequence of two lexical symbols, such as two atoms, it is lex-
-        ically equivalent with a single SPACE,  for  the  purposes  of
-        regenerating  the  sequence, such as when passing the sequence
-        onto a mail protocol server.  Comments are  detected  as  such
-        only within field-bodies of structured fields.
-     
-        If a comment is to be "folded" onto multiple lines,  then  the
-        syntax  for  folding  must  be  adhered to.  (See the "Lexical
-     
-     
-     August 13, 1982              - 12 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        Analysis of Messages" section on "Folding Long Header  Fields"
-        above,  and  the  section on "Case Independence" below.)  Note
-        that  the  official  semantics  therefore  do  not  "see"  any
-        unquoted CRLFs that are in comments, although particular pars-
-        ing programs may wish to note their presence.  For these  pro-
-        grams,  it would be reasonable to interpret a "CRLF LWSP-char"
-        as being a CRLF that is part of the comment; i.e., the CRLF is
-        kept  and  the  LWSP-char is discarded.  Quoted CRLFs (i.e., a
-        backslash followed by a CR followed by a  LF)  still  must  be
-        followed by at least one LWSP-char.
-     
-     3.4.4.  DELIMITING AND QUOTING CHARACTERS
-     
-        The quote character (backslash) and  characters  that  delimit
-        syntactic  units  are not, generally, to be taken as data that
-        are part of the delimited or quoted unit(s).   In  particular,
-        the   quotation-marks   that   define   a  quoted-string,  the
-        parentheses that define  a  comment  and  the  backslash  that
-        quotes  a  following  character  are  NOT  part of the quoted-
-        string, comment or quoted character.  A quotation-mark that is
-        to  be  part  of  a quoted-string, a parenthesis that is to be
-        part of a comment and a backslash that is to be part of either
-        must  each be preceded by the quote-character backslash ("\").
-        Note that the syntax allows any character to be quoted  within
-        a  quoted-string  or  comment; however only certain characters
-        MUST be quoted to be included as data.  These  characters  are
-        the  ones that are not part of the alternate text group (i.e.,
-        ctext or qtext).
-     
-        The one exception to this rule  is  that  a  single  SPACE  is
-        assumed  to  exist  between  contiguous words in a phrase, and
-        this interpretation is independent of  the  actual  number  of
-        LWSP-chars  that  the  creator  places  between the words.  To
-        include more than one SPACE, the creator must make  the  LWSP-
-        chars be part of a quoted-string.
-     
-        Quotation marks that delimit a quoted string  and  backslashes
-        that  quote  the  following character should NOT accompany the
-        quoted-string when the string is passed to processes  that  do
-        not interpret data according to this specification (e.g., mail
-        protocol servers).
-     
-     3.4.5.  QUOTED-STRINGS
-     
-        Where permitted (i.e., in words in structured fields)  quoted-
-        strings  are  treated  as a single symbol.  That is, a quoted-
-        string is equivalent to an atom, syntactically.  If a  quoted-
-        string  is to be "folded" onto multiple lines, then the syntax
-        for folding must be adhered to.  (See the "Lexical Analysis of
-     
-     
-     August 13, 1982              - 13 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        Messages"  section  on "Folding Long Header Fields" above, and
-        the section on "Case  Independence"  below.)   Therefore,  the
-        official  semantics  do  not  "see" any bare CRLFs that are in
-        quoted-strings; however particular parsing programs  may  wish
-        to  note  their presence.  For such programs, it would be rea-
-        sonable to interpret a "CRLF LWSP-char" as being a CRLF  which
-        is  part  of the quoted-string; i.e., the CRLF is kept and the
-        LWSP-char is discarded.  Quoted CRLFs (i.e., a backslash  fol-
-        lowed  by  a CR followed by a LF) are also subject to rules of
-        folding, but the presence of the quoting character (backslash)
-        explicitly  indicates  that  the  CRLF  is  data to the quoted
-        string.  Stripping off the first following LWSP-char  is  also
-        appropriate when parsing quoted CRLFs.
-     
-     3.4.6.  BRACKETING CHARACTERS
-     
-        There is one type of bracket which must occur in matched pairs
-        and may have pairs nested within each other:
-     
-            o   Parentheses ("(" and ")") are used  to  indicate  com-
-                ments.
-     
-        There are three types of brackets which must occur in  matched
-        pairs, and which may NOT be nested:
-     
-            o   Colon/semi-colon (":" and ";") are   used  in  address
-                specifications  to  indicate that the included list of
-                addresses are to be treated as a group.
-     
-            o   Angle brackets ("<" and ">")  are  generally  used  to
-                indicate  the  presence of a one machine-usable refer-
-                ence (e.g., delimiting mailboxes), possibly  including
-                source-routing to the machine.
-     
-            o   Square brackets ("[" and "]") are used to indicate the
-                presence  of  a  domain-literal, which the appropriate
-                name-domain  is  to  use  directly,  bypassing  normal
-                name-resolution mechanisms.
-     
-     3.4.7.  CASE INDEPENDENCE
-     
-        Except as noted, alphabetic strings may be represented in  any
-        combination of upper and lower case.  The only syntactic units
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 14 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        which requires preservation of case information are:
-     
-                    -  text
-                    -  qtext
-                    -  dtext
-                    -  ctext
-                    -  quoted-pair
-                    -  local-part, except "Postmaster"
-     
-        When matching any other syntactic unit, case is to be ignored.
-        For  example, the field-names "From", "FROM", "from", and even
-        "FroM" are semantically equal and should all be treated ident-
-        ically.
-     
-        When generating these units, any mix of upper and  lower  case
-        alphabetic  characters  may  be  used.  The case shown in this
-        specification is suggested for message-creating processes.
-     
-        Note:  The reserved local-part address unit, "Postmaster",  is
-               an  exception.   When  the  value "Postmaster" is being
-               interpreted, it must be  accepted  in  any  mixture  of
-               case, including "POSTMASTER", and "postmaster".
-     
-     3.4.8.  FOLDING LONG HEADER FIELDS
-     
-        Each header field may be represented on exactly one line  con-
-        sisting  of the name of the field and its body, and terminated
-        by a CRLF; this is what the parser sees.  For readability, the
-        field-body  portion of long header fields may be "folded" onto
-        multiple lines of the actual field.  "Long" is commonly inter-
-        preted  to  mean greater than 65 or 72 characters.  The former
-        length serves as a limit, when the message is to be viewed  on
-        most  simple terminals which use simple display software; how-
-        ever, the limit is not imposed by this standard.
-     
-        Note:  Some display software often can selectively fold lines,
-               to  suit  the display terminal.  In such cases, sender-
-               provided  folding  can  interfere  with   the   display
-               software.
-     
-     3.4.9.  BACKSPACE CHARACTERS
-     
-        ASCII BS characters (Backspace, decimal 8) may be included  in
-        texts and quoted-strings to effect overstriking.  However, any
-        use of backspaces which effects an overstrike to the  left  of
-        the beginning of the text or quoted-string is prohibited.
-     
-     
-     
-     
-     
-     August 13, 1982              - 15 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
-     
-        During transmission through heterogeneous networks, it may  be
-        necessary  to  force data to conform to a network's local con-
-        ventions.  For example, it may be required that a CR  be  fol-
-        lowed  either by LF, making a CRLF, or by <null>, if the CR is
-        to stand alone).  Such transformations are reversed, when  the
-        message exits that network.
-     
-        When  crossing  network  boundaries,  the  message  should  be
-        treated  as  passing  through  two modules.  It will enter the
-        first module containing whatever network-specific  transforma-
-        tions  that  were  necessary  to  permit migration through the
-        "current" network.  It then passes through the modules:
-     
-            o   Transformation Reversal
-     
-                The "current" network's idiosyncracies are removed and
-                the  message  is returned to the canonical form speci-
-                fied in this standard.
-     
-            o   Transformation
-     
-                The "next" network's local idiosyncracies are  imposed
-                on the message.
-     
-                                ------------------
-                    From   ==>  | Remove Net-A   |
-                    Net-A       | idiosyncracies |
-                                ------------------
-                                       ||
-                                       \/
-                                  Conformance
-                                  with standard
-                                       ||
-                                       \/
-                                ------------------
-                                | Impose Net-B   |  ==>  To
-                                | idiosyncracies |       Net-B
-                                ------------------
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 16 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     4.  MESSAGE SPECIFICATION
-     
-     4.1.  SYNTAX
-     
-     Note:  Due to an artifact of the notational conventions, the syn-
-            tax  indicates that, when present, some fields, must be in
-            a particular order.  Header fields  are  NOT  required  to
-            occur  in  any  particular  order, except that the message
-            body must occur AFTER  the  headers.   It  is  recommended
-            that,  if  present,  headers be sent in the order "Return-
-            Path", "Received", "Date",  "From",  "Subject",  "Sender",
-            "To", "cc", etc.
-     
-            This specification permits multiple  occurrences  of  most
-            fields.   Except  as  noted,  their  interpretation is not
-            specified here, and their use is discouraged.
-     
-          The following syntax for the bodies of various fields should
-     be  thought  of  as  describing  each field body as a single long
-     string (or line).  The "Lexical Analysis of Message"  section  on
-     "Long  Header Fields", above, indicates how such long strings can
-     be represented on more than one line in  the  actual  transmitted
-     message.
-     
-     message     =  fields *( CRLF *text )       ; Everything after
-                                                 ;  first null line
-                                                 ;  is message body
-     
-     fields      =    dates                      ; Creation time,
-                      source                     ;  author id & one
-                    1*destination                ;  address required
-                     *optional-field             ;  others optional
-     
-     source      = [  trace ]                    ; net traversals
-                      originator                 ; original mail
-                   [  resent ]                   ; forwarded
-     
-     trace       =    return                     ; path to sender
-                    1*received                   ; receipt tags
-     
-     return      =  "Return-path" ":" route-addr ; return address
-     
-     received    =  "Received"    ":"            ; one per relay
-                       ["from" domain]           ; sending host
-                       ["by"   domain]           ; receiving host
-                       ["via"  atom]             ; physical path
-                      *("with" atom)             ; link/mail protocol
-                       ["id"   msg-id]           ; receiver msg id
-                       ["for"  addr-spec]        ; initial form
-     
-     
-     August 13, 1982              - 17 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-                        ";"    date-time         ; time received
-     
-     originator  =   authentic                   ; authenticated addr
-                   [ "Reply-To"   ":" 1#address] )
-     
-     authentic   =   "From"       ":"   mailbox  ; Single author
-                 / ( "Sender"     ":"   mailbox  ; Actual submittor
-                     "From"       ":" 1#mailbox) ; Multiple authors
-                                                 ;  or not sender
-     
-     resent      =   resent-authentic
-                   [ "Resent-Reply-To"  ":" 1#address] )
-     
-     resent-authentic =
-                 =   "Resent-From"      ":"   mailbox
-                 / ( "Resent-Sender"    ":"   mailbox
-                     "Resent-From"      ":" 1#mailbox  )
-     
-     dates       =   orig-date                   ; Original
-                   [ resent-date ]               ; Forwarded
-     
-     orig-date   =  "Date"        ":"   date-time
-     
-     resent-date =  "Resent-Date" ":"   date-time
-     
-     destination =  "To"          ":" 1#address  ; Primary
-                 /  "Resent-To"   ":" 1#address
-                 /  "cc"          ":" 1#address  ; Secondary
-                 /  "Resent-cc"   ":" 1#address
-                 /  "bcc"         ":"  #address  ; Blind carbon
-                 /  "Resent-bcc"  ":"  #address
-     
-     optional-field =
-                 /  "Message-ID"        ":"   msg-id
-                 /  "Resent-Message-ID" ":"   msg-id
-                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
-                 /  "References"        ":"  *(phrase / msg-id)
-                 /  "Keywords"          ":"  #phrase
-                 /  "Subject"           ":"  *text
-                 /  "Comments"          ":"  *text
-                 /  "Encrypted"         ":" 1#2word
-                 /  extension-field              ; To be defined
-                 /  user-defined-field           ; May be pre-empted
-     
-     msg-id      =  "<" addr-spec ">"            ; Unique message id
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 18 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     extension-field =
-                   <Any field which is defined in a document
-                    published as a formal extension to this
-                    specification; none will have names beginning
-                    with the string "X-">
-     
-     user-defined-field =
-                   <Any field which has not been defined
-                    in this specification or published as an
-                    extension to this specification; names for
-                    such fields must be unique and may be
-                    pre-empted by published extensions>
-     
-     4.2.  FORWARDING
-     
-          Some systems permit mail recipients to  forward  a  message,
-     retaining  the original headers, by adding some new fields.  This
-     standard supports such a service, through the "Resent-" prefix to
-     field names.
-     
-          Whenever the string "Resent-" begins a field name, the field
-     has  the  same  semantics as a field whose name does not have the
-     prefix.  However, the message is assumed to have  been  forwarded
-     by  an original recipient who attached the "Resent-" field.  This
-     new field is treated as being more recent  than  the  equivalent,
-     original  field.   For  example, the "Resent-From", indicates the
-     person that forwarded the message, whereas the "From" field indi-
-     cates the original author.
-     
-          Use of such precedence  information  depends  upon  partici-
-     pants'  communication needs.  For example, this standard does not
-     dictate when a "Resent-From:" address should receive replies,  in
-     lieu of sending them to the "From:" address.
-     
-     Note:  In general, the "Resent-" fields should be treated as con-
-            taining  a  set  of information that is independent of the
-            set of original fields.  Information for  one  set  should
-            not  automatically be taken from the other.  The interpre-
-            tation of multiple "Resent-" fields, of the same type,  is
-            undefined.
-     
-          In the remainder of this specification, occurrence of  legal
-     "Resent-"  fields  are treated identically with the occurrence of
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 19 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     fields whose names do not contain this prefix.
-     
-     4.3.  TRACE FIELDS
-     
-          Trace information is used to provide an audit trail of  mes-
-     sage  handling.   In  addition,  it indicates a route back to the
-     sender of the message.
-     
-          The list of known "via" and  "with"  values  are  registered
-     with  the  Network  Information  Center, SRI International, Menlo
-     Park, California.
-     
-     4.3.1.  RETURN-PATH
-     
-        This field  is  added  by  the  final  transport  system  that
-        delivers  the message to its recipient.  The field is intended
-        to contain definitive information about the address and  route
-        back to the message's originator.
-     
-        Note:  The "Reply-To" field is added  by  the  originator  and
-               serves  to  direct  replies,  whereas the "Return-Path"
-               field is used to identify a path back to  the  origina-
-               tor.
-     
-        While the syntax  indicates  that  a  route  specification  is
-        optional,  every attempt should be made to provide that infor-
-        mation in this field.
-     
-     4.3.2.  RECEIVED
-     
-        A copy of this field is added by each transport  service  that
-        relays the message.  The information in the field can be quite
-        useful for tracing transport problems.
-     
-        The names of the sending  and  receiving  hosts  and  time-of-
-        receipt may be specified.  The "via" parameter may be used, to
-        indicate what physical mechanism the message  was  sent  over,
-        such  as  Arpanet or Phonenet, and the "with" parameter may be
-        used to indicate the mail-,  or  connection-,  level  protocol
-        that  was  used, such as the SMTP mail protocol, or X.25 tran-
-        sport protocol.
-     
-        Note:  Several "with" parameters may  be  included,  to  fully
-               specify the set of protocols that were used.
-     
-        Some transport services queue mail; the internal message iden-
-        tifier that is assigned to the message may be noted, using the
-        "id" parameter.  When the  sending  host  uses  a  destination
-        address specification that the receiving host reinterprets, by
-     
-     
-     August 13, 1982              - 20 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        expansion or transformation, the receiving host  may  wish  to
-        record  the original specification, using the "for" parameter.
-        For example, when a copy of mail is sent to the  member  of  a
-        distribution  list,  this  parameter may be used to record the
-        original address that was used to specify the list.
-     
-     4.4.  ORIGINATOR FIELDS
-     
-          The standard allows only a subset of the combinations possi-
-     ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
-     and Resent-Reply-To fields.  The limitation is intentional.
-     
-     4.4.1.  FROM / RESENT-FROM
-     
-        This field contains the identity of the person(s)  who  wished
-        this  message to be sent.  The message-creation process should
-        default this field  to  be  a  single,  authenticated  machine
-        address,  indicating  the  AGENT  (person,  system or process)
-        entering the message.  If this is not done, the "Sender" field
-        MUST  be  present.  If the "From" field IS defaulted this way,
-        the "Sender" field is  optional  and  is  redundant  with  the
-        "From"  field.   In  all  cases, addresses in the "From" field
-        must be machine-usable (addr-specs) and may not contain  named
-        lists (groups).
-     
-     4.4.2.  SENDER / RESENT-SENDER
-     
-        This field contains the authenticated identity  of  the  AGENT
-        (person,  system  or  process)  that sends the message.  It is
-        intended for use when the sender is not the author of the mes-
-        sage,  or  to  indicate  who among a group of authors actually
-        sent the message.  If the contents of the "Sender" field would
-        be  completely  redundant  with  the  "From"  field,  then the
-        "Sender" field need not be present and its use is  discouraged
-        (though  still legal).  In particular, the "Sender" field MUST
-        be present if it is NOT the same as the "From" Field.
-     
-        The Sender mailbox  specification  includes  a  word  sequence
-        which  must correspond to a specific agent (i.e., a human user
-        or a computer program) rather than a standard  address.   This
-        indicates  the  expectation  that  the field will identify the
-        single AGENT (person,  system,  or  process)  responsible  for
-        sending  the mail and not simply include the name of a mailbox
-        from which the mail was sent.  For example in the  case  of  a
-        shared login name, the name, by itself, would not be adequate.
-        The local-part address unit, which refers to  this  agent,  is
-        expected to be a computer system term, and not (for example) a
-        generalized person reference which can  be  used  outside  the
-        network text message context.
-     
-     
-     August 13, 1982              - 21 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        Since the critical function served by the  "Sender"  field  is
-        identification  of  the agent responsible for sending mail and
-        since computer programs cannot be held accountable  for  their
-        behavior, it is strongly recommended that when a computer pro-
-        gram generates a message, the HUMAN  who  is  responsible  for
-        that program be referenced as part of the "Sender" field mail-
-        box specification.
-     
-     4.4.3.  REPLY-TO / RESENT-REPLY-TO
-     
-        This field provides a general  mechanism  for  indicating  any
-        mailbox(es)  to which responses are to be sent.  Three typical
-        uses for this feature can  be  distinguished.   In  the  first
-        case,  the  author(s) may not have regular machine-based mail-
-        boxes and therefore wish(es) to indicate an alternate  machine
-        address.   In  the  second case, an author may wish additional
-        persons to be made aware of, or responsible for,  replies.   A
-        somewhat  different  use  may be of some help to "text message
-        teleconferencing" groups equipped with automatic  distribution
-        services:   include the address of that service in the "Reply-
-        To" field of all messages  submitted  to  the  teleconference;
-        then  participants  can  "reply"  to conference submissions to
-        guarantee the correct distribution of any submission of  their
-        own.
-     
-        Note:  The "Return-Path" field is added by the mail  transport
-               service,  at the time of final deliver.  It is intended
-               to identify a path back to the orginator  of  the  mes-
-               sage.   The  "Reply-To"  field  is added by the message
-               originator and is intended to direct replies.
-     
-     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
-     
-        For systems which automatically  generate  address  lists  for
-        replies to messages, the following recommendations are made:
-     
-            o   The "Sender" field mailbox should be sent  notices  of
-                any  problems in transport or delivery of the original
-                messages.  If there is no  "Sender"  field,  then  the
-                "From" field mailbox should be used.
-     
-            o   The  "Sender"  field  mailbox  should  NEVER  be  used
-                automatically, in a recipient's reply message.
-     
-            o   If the "Reply-To" field exists, then the reply  should
-                go to the addresses indicated in that field and not to
-                the address(es) indicated in the "From" field.
-     
-     
-     
-     
-     August 13, 1982              - 22 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-            o   If there is a "From" field, but no  "Reply-To"  field,
-                the  reply should be sent to the address(es) indicated
-                in the "From" field.
-     
-        Sometimes, a recipient may actually wish to  communicate  with
-        the  person  that  initiated  the  message  transfer.  In such
-        cases, it is reasonable to use the "Sender" address.
-     
-        This recommendation is intended  only  for  automated  use  of
-        originator-fields  and is not intended to suggest that replies
-        may not also be sent to other recipients of messages.   It  is
-        up  to  the  respective  mail-handling programs to decide what
-        additional facilities will be provided.
-     
-        Examples are provided in Appendix A.
-     
-     4.5.  RECEIVER FIELDS
-     
-     4.5.1.  TO / RESENT-TO
-     
-        This field contains the identity of the primary recipients  of
-        the message.
-     
-     4.5.2.  CC / RESENT-CC
-     
-        This field contains the identity of  the  secondary  (informa-
-        tional) recipients of the message.
-     
-     4.5.3.  BCC / RESENT-BCC
-     
-        This field contains the identity of additional  recipients  of
-        the  message.   The contents of this field are not included in
-        copies of the message sent to the primary and secondary  reci-
-        pients.   Some  systems  may choose to include the text of the
-        "Bcc" field only in the author(s)'s  copy,  while  others  may
-        also include it in the text sent to all those indicated in the
-        "Bcc" list.
-     
-     4.6.  REFERENCE FIELDS
-     
-     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
-     
-             This field contains a unique identifier  (the  local-part
-        address  unit)  which  refers to THIS version of THIS message.
-        The uniqueness of the message identifier is guaranteed by  the
-        host  which  generates  it.  This identifier is intended to be
-        machine readable and not necessarily meaningful to humans.   A
-        message  identifier pertains to exactly one instantiation of a
-        particular message; subsequent revisions to the message should
-     
-     
-     August 13, 1982              - 23 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        each receive new message identifiers.
-     
-     4.6.2.  IN-REPLY-TO
-     
-             The contents of this field identify  previous  correspon-
-        dence  which this message answers.  Note that if message iden-
-        tifiers are used in this  field,  they  must  use  the  msg-id
-        specification format.
-     
-     4.6.3.  REFERENCES
-     
-             The contents of this field identify other  correspondence
-        which  this message references.  Note that if message identif-
-        iers are used, they must use the msg-id specification format.
-     
-     4.6.4.  KEYWORDS
-     
-             This field contains keywords  or  phrases,  separated  by
-        commas.
-     
-     4.7.  OTHER FIELDS
-     
-     4.7.1.  SUBJECT
-     
-             This is intended to provide a summary,  or  indicate  the
-        nature, of the message.
-     
-     4.7.2.  COMMENTS
-     
-             Permits adding text comments  onto  the  message  without
-        disturbing the contents of the message's body.
-     
-     4.7.3.  ENCRYPTED
-     
-             Sometimes,  data  encryption  is  used  to  increase  the
-        privacy  of  message  contents.   If the body of a message has
-        been encrypted, to keep its contents private, the  "Encrypted"
-        field  can be used to note the fact and to indicate the nature
-        of the encryption.  The first <word> parameter  indicates  the
-        software  used  to  encrypt the body, and the second, optional
-        <word> is intended to  aid  the  recipient  in  selecting  the
-        proper  decryption  key.   This  code word may be viewed as an
-        index to a table of keys held by the recipient.
-     
-        Note:  Unfortunately, headers must contain envelope,  as  well
-               as  contents,  information.  Consequently, it is neces-
-               sary that they remain unencrypted, so that  mail  tran-
-               sport   services   may   access   them.   Since  names,
-               addresses, and "Subject"  field  contents  may  contain
-     
-     
-     August 13, 1982              - 24 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-               sensitive  information,  this  requirement limits total
-               message privacy.
-     
-             Names of encryption software are registered with the Net-
-        work  Information Center, SRI International, Menlo Park, Cali-
-        fornia.
-     
-     4.7.4.  EXTENSION-FIELD
-     
-             A limited number of common fields have  been  defined  in
-        this  document.   As  network mail requirements dictate, addi-
-        tional fields may be standardized.   To  provide  user-defined
-        fields  with  a  measure  of  safety,  in name selection, such
-        extension-fields will never have names  that  begin  with  the
-        string "X-".
-     
-             Names of Extension-fields are registered with the Network
-        Information Center, SRI International, Menlo Park, California.
-     
-     4.7.5.  USER-DEFINED-FIELD
-     
-             Individual users of network mail are free to  define  and
-        use  additional  header  fields.   Such fields must have names
-        which are not already used in the current specification or  in
-        any definitions of extension-fields, and the overall syntax of
-        these user-defined-fields must conform to this specification's
-        rules   for   delimiting  and  folding  fields.   Due  to  the
-        extension-field  publishing  process,  the  name  of  a  user-
-        defined-field may be pre-empted
-     
-        Note:  The prefatory string "X-" will never  be  used  in  the
-               names  of Extension-fields.  This provides user-defined
-               fields with a protected set of names.
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 25 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     5.  DATE AND TIME SPECIFICATION
-     
-     5.1.  SYNTAX
-     
-     date-time   =  [ day "," ] date time        ; dd mm yy
-                                                 ;  hh:mm:ss zzz
-     
-     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
-                 /  "Fri"  / "Sat" /  "Sun"
-     
-     date        =  1*2DIGIT month 2DIGIT        ; day month year
-                                                 ;  e.g. 20 Jun 82
-     
-     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
-                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
-                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
-     
-     time        =  hour zone                    ; ANSI and Military
-     
-     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
-                                                 ; 00:00:00 - 23:59:59
-     
-     zone        =  "UT"  / "GMT"                ; Universal Time
-                                                 ; North American : UT
-                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
-                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
-                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
-                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
-                 /  1ALPHA                       ; Military: Z = UT;
-                                                 ;  A:-1; (J not used)
-                                                 ;  M:-12; N:+1; Y:+12
-                 / ( ("+" / "-") 4DIGIT )        ; Local differential
-                                                 ;  hours+min. (HHMM)
-     
-     5.2.  SEMANTICS
-     
-          If included, day-of-week must be the day implied by the date
-     specification.
-     
-          Time zone may be indicated in several ways.  "UT" is Univer-
-     sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
-     mitted as a reference to Universal Time.  The  military  standard
-     uses  a  single  character for each zone.  "Z" is Universal Time.
-     "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
-     lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
-     letter "J" is not used.  The other remaining two forms are  taken
-     from ANSI standard X3.51-1975.  One allows explicit indication of
-     the amount of offset from UT; the other uses  common  3-character
-     strings for indicating time zones in North America.
-     
-     
-     August 13, 1982              - 26 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     6.  ADDRESS SPECIFICATION
-     
-     6.1.  SYNTAX
-     
-     address     =  mailbox                      ; one addressee
-                 /  group                        ; named list
-     
-     group       =  phrase ":" [#mailbox] ";"
-     
-     mailbox     =  addr-spec                    ; simple address
-                 /  phrase route-addr            ; name & addr-spec
-     
-     route-addr  =  "<" [route] addr-spec ">"
-     
-     route       =  1#("@" domain) ":"           ; path-relative
-     
-     addr-spec   =  local-part "@" domain        ; global address
-     
-     local-part  =  word *("." word)             ; uninterpreted
-                                                 ; case-preserved
-     
-     domain      =  sub-domain *("." sub-domain)
-     
-     sub-domain  =  domain-ref / domain-literal
-     
-     domain-ref  =  atom                         ; symbolic reference
-     
-     6.2.  SEMANTICS
-     
-          A mailbox receives mail.  It is a  conceptual  entity  which
-     does  not necessarily pertain to file storage.  For example, some
-     sites may choose to print mail on their line printer and  deliver
-     the output to the addressee's desk.
-     
-          A mailbox specification comprises a person, system  or  pro-
-     cess name reference, a domain-dependent string, and a name-domain
-     reference.  The name reference is optional and is usually used to
-     indicate  the  human name of a recipient.  The name-domain refer-
-     ence specifies a sequence of sub-domains.   The  domain-dependent
-     string is uninterpreted, except by the final sub-domain; the rest
-     of the mail service merely transmits it as a literal string.
-     
-     6.2.1.  DOMAINS
-     
-        A name-domain is a set of registered (mail)  names.   A  name-
-        domain  specification  resolves  to  a subordinate name-domain
-        specification  or  to  a  terminal  domain-dependent   string.
-        Hence,  domain  specification  is  extensible,  permitting any
-        number of registration levels.
-     
-     
-     August 13, 1982              - 27 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        Name-domains model a global, logical, hierarchical  addressing
-        scheme.   The  model is logical, in that an address specifica-
-        tion is related to name registration and  is  not  necessarily
-        tied  to  transmission  path.   The  model's  hierarchy  is  a
-        directed graph, called an in-tree, such that there is a single
-        path  from  the root of the tree to any node in the hierarchy.
-        If more than one path actually exists, they are considered  to
-        be different addresses.
-     
-        The root node is common to all addresses; consequently, it  is
-        not  referenced.   Its  children  constitute "top-level" name-
-        domains.  Usually, a service has access to its own full domain
-        specification and to the names of all top-level name-domains.
-     
-        The "top" of the domain addressing hierarchy -- a child of the
-        root  --  is  indicated  by  the right-most field, in a domain
-        specification.  Its child is specified to the left, its  child
-        to the left, and so on.
-     
-        Some groups provide formal registration services;  these  con-
-        stitute   name-domains   that  are  independent  logically  of
-        specific machines.  In addition, networks and machines  impli-
-        citly  compose name-domains, since their membership usually is
-        registered in name tables.
-     
-        In the case of formal registration, an organization implements
-        a  (distributed)  data base which provides an address-to-route
-        mapping service for addresses of the form:
-     
-                         person@registry.organization
-     
-        Note that "organization" is a logical  entity,  separate  from
-        any particular communication network.
-     
-        A mechanism for accessing "organization" is universally avail-
-        able.   That mechanism, in turn, seeks an instantiation of the
-        registry; its location is not indicated in the address specif-
-        ication.   It  is assumed that the system which operates under
-        the name "organization" knows how to find a subordinate regis-
-        try.  The registry will then use the "person" string to deter-
-        mine where to send the mail specification.
-     
-        The latter,  network-oriented  case  permits  simple,  direct,
-        attachment-related address specification, such as:
-     
-                              user@host.network
-     
-        Once the network is accessed, it is expected  that  a  message
-        will  go  directly  to the host and that the host will resolve
-     
-     
-     August 13, 1982              - 28 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        the user name, placing the message in the user's mailbox.
-     
-     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
-     
-        Since any number of  levels  is  possible  within  the  domain
-        hierarchy,  specification  of  a  fully  qualified address can
-        become inconvenient.  This standard permits abbreviated domain
-        specification, in a special case:
-     
-            For the address of  the  sender,  call  the  left-most
-            sub-domain  Level  N.   In a header address, if all of
-            the sub-domains above (i.e., to the right of) Level  N
-            are  the same as those of the sender, then they do not
-            have to appear in the specification.   Otherwise,  the
-            address must be fully qualified.
-     
-            This feature is subject  to  approval  by  local  sub-
-            domains.   Individual  sub-domains  may  require their
-            member systems, which originate mail, to provide  full
-            domain  specification only.  When permitted, abbrevia-
-            tions may be present  only  while  the  message  stays
-            within the sub-domain of the sender.
-     
-            Use of this mechanism requires the sender's sub-domain
-            to reserve the names of all top-level domains, so that
-            full specifications can be distinguished from abbrevi-
-            ated specifications.
-     
-        For example, if a sender's address is:
-     
-                 sender@registry-A.registry-1.organization-X
-     
-        and one recipient's address is:
-     
-                recipient@registry-B.registry-1.organization-X
-     
-        and another's is:
-     
-                recipient@registry-C.registry-2.organization-X
-     
-        then ".registry-1.organization-X" need not be specified in the
-        the  message,  but  "registry-C.registry-2"  DOES  have  to be
-        specified.  That is, the first two addresses may  be  abbrevi-
-        ated, but the third address must be fully specified.
-     
-        When a message crosses a domain boundary, all  addresses  must
-        be  specified  in  the  full format, ending with the top-level
-        name-domain in the right-most field.  It is the responsibility
-        of  mail  forwarding services to ensure that addresses conform
-     
-     
-     August 13, 1982              - 29 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        with this requirement.  In the case of abbreviated  addresses,
-        the  relaying  service must make the necessary expansions.  It
-        should be noted that it often is difficult for such a  service
-        to locate all occurrences of address abbreviations.  For exam-
-        ple, it will not be possible to find such abbreviations within
-        the  body  of  the  message.   The "Return-Path" field can aid
-        recipients in recovering from these errors.
-     
-        Note:  When passing any portion of an addr-spec onto a process
-               which  does  not interpret data according to this stan-
-               dard (e.g., mail protocol servers).  There must  be  NO
-               LWSP-chars  preceding  or  following the at-sign or any
-               delimiting period ("."), such as  shown  in  the  above
-               examples,   and   only  ONE  SPACE  between  contiguous
-               <word>s.
-     
-     6.2.3.  DOMAIN TERMS
-     
-        A domain-ref must be THE official name of a registry, network,
-        or  host.   It  is  a  symbolic  reference, within a name sub-
-        domain.  At times, it is necessary to bypass standard  mechan-
-        isms  for  resolving  such  references,  using  more primitive
-        information, such as a network host address  rather  than  its
-        associated host name.
-     
-        To permit such references, this standard provides the  domain-
-        literal  construct.   Its contents must conform with the needs
-        of the sub-domain in which it is interpreted.
-     
-        Domain-literals which refer to domains within the ARPA  Inter-
-        net  specify  32-bit  Internet addresses, in four 8-bit fields
-        noted in decimal, as described in Request for  Comments  #820,
-        "Assigned Numbers."  For example:
-     
-                                 [10.0.3.19]
-     
-        Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
-               is  permitted  only  as  a means of bypassing temporary
-               system limitations, such as name tables which  are  not
-               complete.
-     
-        The names of "top-level" domains, and  the  names  of  domains
-        under  in  the  ARPA Internet, are registered with the Network
-        Information Center, SRI International, Menlo Park, California.
-     
-     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
-     
-        The local-part of an  addr-spec  in  a  mailbox  specification
-        (i.e.,  the  host's  name for the mailbox) is understood to be
-     
-     
-     August 13, 1982              - 30 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        whatever the receiving mail protocol server allows.  For exam-
-        ple,  some systems do not understand mailbox references of the
-        form "P. D. Q. Bach", but others do.
-     
-        This specification treats periods (".") as lexical separators.
-        Hence,  their  presence  in  local-parts which are not quoted-
-        strings, is detected.   However,  such  occurrences  carry  NO
-        semantics.  That is, if a local-part has periods within it, an
-        address parser will divide the local-part into several tokens,
-        but  the  sequence  of  tokens will be treated as one uninter-
-        preted unit.  The sequence  will  be  re-assembled,  when  the
-        address is passed outside of the system such as to a mail pro-
-        tocol service.
-     
-        For example, the address:
-     
-                           First.Last@Registry.Org
-     
-        is legal and does not require the local-part to be  surrounded
-        with  quotation-marks.   (However,  "First  Last" DOES require
-        quoting.)  The local-part of the address, when passed  outside
-        of  the  mail  system,  within  the  Registry.Org  domain,  is
-        "First.Last", again without quotation marks.
-     
-     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
-     
-        In some cases, the boundary between local-part and domain  can
-        be  flexible.  The local-part may be a simple string, which is
-        used for the final determination of the  recipient's  mailbox.
-        All  other  levels  of  reference  are, therefore, part of the
-        domain.
-     
-        For some systems, in the case of abbreviated reference to  the
-        local  and  subordinate  sub-domains,  it  may  be possible to
-        specify only one reference within the domain  part  and  place
-        the  other,  subordinate  name-domain  references  within  the
-        local-part.  This would appear as:
-     
-                        mailbox.sub1.sub2@this-domain
-     
-        Such a specification would be acceptable  to  address  parsers
-        which  conform  to  RFC  #733,  but  do not support this newer
-        Internet standard.  While contrary to the intent of this stan-
-        dard, the form is legal.
-     
-        Also, some sub-domains have a specification syntax which  does
-        not conform to this standard.  For example:
-     
-                      sub-net.mailbox@sub-domain.domain
-     
-     
-     August 13, 1982              - 31 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        uses a different parsing  sequence  for  local-part  than  for
-        domain.
-     
-        Note:  As a rule,  the  domain  specification  should  contain
-               fields  which  are  encoded  according to the syntax of
-               this standard and which contain  generally-standardized
-               information.   The local-part specification should con-
-               tain only that portion of the  address  which  deviates
-               from the form or intention of the domain field.
-     
-     6.2.6.  MULTIPLE MAILBOXES
-     
-        An individual may have several mailboxes and wish  to  receive
-        mail  at  whatever  mailbox  is  convenient  for the sender to
-        access.  This standard does not provide a means of  specifying
-        "any member of" a list of mailboxes.
-     
-        A set of individuals may wish to receive mail as a single unit
-        (i.e.,  a  distribution  list).  The <group> construct permits
-        specification of such a list.  Recipient mailboxes are  speci-
-        fied  within  the  bracketed  part (":" - ";").  A copy of the
-        transmitted message is to be  sent  to  each  mailbox  listed.
-        This  standard  does  not  permit  recursive  specification of
-        groups within groups.
-     
-        While a list must be named, it is not required that  the  con-
-        tents  of  the  list be included.  In this case, the <address>
-        serves only as an indication of group distribution  and  would
-        appear in the form:
-     
-                                    name:;
-     
-        Some mail  services  may  provide  a  group-list  distribution
-        facility,  accepting  a single mailbox reference, expanding it
-        to the full distribution list, and relaying the  mail  to  the
-        list's  members.   This standard provides no additional syntax
-        for indicating such a  service.   Using  the  <group>  address
-        alternative,  while listing one mailbox in it, can mean either
-        that the mailbox reference will be expanded to a list or  that
-        there is a group with one member.
-     
-     6.2.7.  EXPLICIT PATH SPECIFICATION
-     
-        At times, a  message  originator  may  wish  to  indicate  the
-        transmission  path  that  a  message  should  follow.  This is
-        called source routing.  The normal addressing scheme, used  in
-        an  addr-spec,  is  carefully separated from such information;
-        the <route> portion of a route-addr is provided for such occa-
-        sions.  It specifies the sequence of hosts and/or transmission
-     
-     
-     August 13, 1982              - 32 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        services that are  to  be  traversed.   Both  domain-refs  and
-        domain-literals may be used.
-     
-        Note:  The use of source routing is discouraged.   Unless  the
-               sender has special need of path restriction, the choice
-               of transmission route should be left to the mail  tran-
-               sport service.
-     
-     6.3.  RESERVED ADDRESS
-     
-          It often is necessary to send mail to a site, without  know-
-     ing  any  of its valid addresses.  For example, there may be mail
-     system dysfunctions, or a user may wish to find  out  a  person's
-     correct address, at that site.
-     
-          This standard specifies a single, reserved  mailbox  address
-     (local-part)  which  is  to  be valid at each site.  Mail sent to
-     that address is to be routed to  a  person  responsible  for  the
-     site's mail system or to a person with responsibility for general
-     site operation.  The name of the reserved local-part address is:
-     
-                                Postmaster
-     
-     so that "Postmaster@domain" is required to be valid.
-     
-     Note:  This reserved local-part must be  matched  without  sensi-
-            tivity to alphabetic case, so that "POSTMASTER", "postmas-
-            ter", and even "poStmASteR" is to be accepted.
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 33 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     7.  BIBLIOGRAPHY
-     
-     
-     ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
-        American  National Standards Institute: New York (1968).  Also
-        in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
-        book", NIC 7104.
-     
-     ANSI.  "Representations of Universal Time, Local  Time  Differen-
-        tials,  and United States Time Zone References for Information
-        Interchange," X3.51-1975.  American National Standards  Insti-
-        tute:  New York (1975).
-     
-     Bemer, R.W., "Time and the Computer."  In:  Interface  Age  (Feb.
-        1979).
-     
-     Bennett, C.J.  "JNT Mail Protocol".  Joint Network Team,  Ruther-
-        ford and Appleton Laboratory:  Didcot, England.
-     
-     Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
-        "Standardizing  Network  Mail  Headers,"   ARPANET Request for
-        Comments No. 561, Network Information Center  No.  18516;  SRI
-        International:  Menlo Park (September 1973).
-     
-     Birrell, A.D., Levin, R.,  Needham,  R.M.,  and  Schroeder,  M.D.
-        "Grapevine:  An Exercise in Distributed Computing," Communica-
-        tions of the ACM 25, 4 (April 1982), 260-274.
-     
-     Crocker,  D.H.,  Vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A.
-        "Standard  for  the  Format  of  ARPA  Network  Text Message,"
-        ARPANET Request for  Comments  No.  733,  Network  Information
-        Center  No.  41952.   SRI International:  Menlo Park (November
-        1977).
-     
-     Feinler, E.J. and Postel, J.B.  ARPANET Protocol  Handbook,  Net-
-        work  Information  Center  No.  7104   (NTIS AD A003890).  SRI
-        International:  Menlo Park (April 1976).
-     
-     Harary, F.   "Graph  Theory".   Addison-Wesley:   Reading,  Mass.
-        (1969).
-     
-     Levin, R. and Schroeder, M.  "Transport  of  Electronic  Messages
-        through  a  Network,"   TeleInformatics  79, pp. 29-33.  North
-        Holland (1979).  Also  as  Xerox  Palo  Alto  Research  Center
-        Technical Report CSL-79-4.
-     
-     Myer, T.H. and Henderson, D.A.  "Message Transmission  Protocol,"
-        ARPANET  Request  for  Comments,  No. 680, Network Information
-        Center No. 32116.  SRI International:  Menlo Park (1975).
-     
-     
-     August 13, 1982              - 34 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     NBS.  "Specification of Message Format for Computer Based Message
-        Systems, Recommended Federal Information Processing Standard."
-        National  Bureau   of   Standards:    Gaithersburg,   Maryland
-        (October 1981).
-     
-     NIC.  Internet Protocol Transition Workbook.  Network Information
-        Center,   SRI-International,  Menlo  Park,  California  (March
-        1982).
-     
-     Oppen, D.C. and Dalal, Y.K.  "The Clearinghouse:  A Decentralized
-        Agent  for  Locating  Named  Objects in a Distributed Environ-
-        ment," OPD-T8103.  Xerox Office Products Division:  Palo Alto,
-        CA. (October 1981).
-     
-     Postel, J.B.  "Assigned Numbers,"  ARPANET Request for  Comments,
-        No. 820.  SRI International:  Menlo Park (August 1982).
-     
-     Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
-        for Comments, No. 821.  SRI International:  Menlo Park (August
-        1982).
-     
-     Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
-        Proc. 17th IEEE Computer Society International Conference, pp.
-        72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
-     
-     Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
-        User  Applications,"  ARPANET  Request  for Comments, No. 819.
-        SRI International:  Menlo Park (August 1982).
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 35 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-                                 APPENDIX
-     
-     
-     A.  EXAMPLES
-     
-     A.1.  ADDRESSES
-     
-     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
-     
-     A.1.2.  Neuman@BBN-TENEXA
-     
-             These two "Alfred Neuman" examples have identical  seman-
-        tics, as far as the operation of the local host's mail sending
-        (distribution) program (also sometimes  called  its  "mailer")
-        and  the remote host's mail protocol server are concerned.  In
-        the first example, the  "Alfred  Neuman"  is  ignored  by  the
-        mailer,  as "Neuman@BBN-TENEXA" completely specifies the reci-
-        pient.  The second example contains  no  superfluous  informa-
-        tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
-        pient.
-     
-        Note:  When the message crosses name-domain  boundaries,  then
-               these specifications must be changed, so as to indicate
-               the remainder of the hierarchy, starting with  the  top
-               level.
-     
-     A.1.3.  "George, Ted" <Shared@Group.Arpanet>
-     
-             This form might be used to indicate that a single mailbox
-        is  shared  by several users.  The quoted string is ignored by
-        the originating host's mailer, because  "Shared@Group.Arpanet"
-        completely specifies the destination mailbox.
-     
-     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
-     
-             The "(the  Stilt)" is a comment, which is NOT included in
-        the  destination  mailbox  address  handed  to the originating
-        system's mailer.  The local-part of the address is the  string
-        "Wilt.Chamberlain", with NO space between the first and second
-        words.
-     
-     A.1.5.  Address Lists
-     
-     Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
-                Childs@WGBH.Boston, Galloping Gourmet@
-                ANT.Down-Under (Australian National Television),
-                Cheapie@Discount-Liquors;,
-       Cruisers:  Port@Portugal, Jones@SEA;,
-         Another@Somewhere.SomeOrg
-     
-     
-     August 13, 1982              - 36 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        This group list example points out the use of comments and the
-        mixing of addresses and groups.
-     
-     A.2.  ORIGINATOR ITEMS
-     
-     A.2.1.  Author-sent
-     
-             George Jones logs into his host  as  "Jones".   He  sends
-        mail himself.
-     
-            From:  Jones@Group.Org
-     
-        or
-     
-            From:  George Jones <Jones@Group.Org>
-     
-     A.2.2.  Secretary-sent
-     
-             George Jones logs in as Jones on his  host.   His  secre-
-        tary,  who logs in as Secy sends mail for him.  Replies to the
-        mail should go to George.
-     
-            From:    George Jones <Jones@Group>
-            Sender:  Secy@Other-Group
-     
-     A.2.3.  Secretary-sent, for user of shared directory
-     
-             George Jones' secretary sends mail  for  George.  Replies
-        should go to George.
-     
-            From:     George Jones<Shared@Group.Org>
-            Sender:   Secy@Other-Group
-     
-        Note that there need not be a space between  "Jones"  and  the
-        "<",  but  adding a space enhances readability (as is the case
-        in other examples.
-     
-     A.2.4.  Committee activity, with one author
-     
-             George is a member of a committee.  He wishes to have any
-        replies to his message go to all committee members.
-     
-            From:     George Jones <Jones@Host.Net>
-            Sender:   Jones@Host
-            Reply-To: The Committee: Jones@Host.Net,
-                                     Smith@Other.Org,
-                                     Doe@Somewhere-Else;
-     
-        Note  that  if  George  had  not  included  himself   in   the
-     
-     
-     August 13, 1982              - 37 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-        enumeration  of  The  Committee,  he  would not have gotten an
-        implicit reply; the presence of the  "Reply-to"  field  SUPER-
-        SEDES the sending of a reply to the person named in the "From"
-        field.
-     
-     A.2.5.  Secretary acting as full agent of author
-     
-             George Jones asks his secretary  (Secy@Host)  to  send  a
-        message for him in his capacity as Group.  He wants his secre-
-        tary to handle all replies.
-     
-            From:     George Jones <Group@Host>
-            Sender:   Secy@Host
-            Reply-To: Secy@Host
-     
-     A.2.6.  Agent for user without online mailbox
-     
-             A friend  of  George's,  Sarah,  is  visiting.   George's
-        secretary  sends  some  mail to a friend of Sarah in computer-
-        land.  Replies should go to George, whose mailbox is Jones  at
-        Registry.
-     
-            From:     Sarah Friendly <Secy@Registry>
-            Sender:   Secy-Name <Secy@Registry>
-            Reply-To: Jones@Registry.
-     
-     A.2.7.  Agent for member of a committee
-     
-             George's secretary sends out a message which was authored
-        jointly by all the members of a committee.  Note that the name
-        of the committee cannot be specified, since <group> names  are
-        not permitted in the From field.
-     
-            From:   Jones@Host,
-                    Smith@Other-Host,
-                    Doe@Somewhere-Else
-            Sender: Secy@SHost
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 38 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     A.3.  COMPLETE HEADERS
-     
-     A.3.1.  Minimum required
-     
-     Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
-     From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
-     Bcc:                                To:       Smith@Registry.Org
-     
-        Note that the "Bcc" field may be empty, while the  "To"  field
-        is required to have at least one address.
-     
-     A.3.2.  Using some of the additional fields
-     
-     Date:     26 Aug 76 1430 EDT
-     From:     George Jones<Group@Host>
-     Sender:   Secy@SHOST
-     To:       "Al Neuman"@Mad-Host,
-               Sam.Irving@Other-Host
-     Message-ID:  <some.string@SHOST>
-     
-     A.3.3.  About as complex as you're going to get
-     
-     Date     :  27 Aug 76 0932 PDT
-     From     :  Ken Davis <KDavis@This-Host.This-net>
-     Subject  :  Re: The Syntax in the RFC
-     Sender   :  KSecy@Other-Host
-     Reply-To :  Sam.Irving@Reg.Organization
-     To       :  George Jones <Group@Some-Reg.An-Org>,
-                 Al.Neuman@MAD.Publisher
-     cc       :  Important folk:
-                   Tom Softwood <Balsa@Tree.Root>,
-                   "Sam Irving"@Other-Host;,
-                 Standard Distribution:
-                   /main/davis/people/standard@Other-Host,
-                   "<Jones>standard.dist.3"@Tops-20-Host>;
-     Comment  :  Sam is away on business. He asked me to handle
-                 his mail for him.  He'll be able to provide  a
-                 more  accurate  explanation  when  he  returns
-                 next week.
-     In-Reply-To: <some.string@DBM.Group>, George's message
-     X-Special-action:  This is a sample of user-defined field-
-                 names.  There could also be a field-name
-                 "Special-action", but its name might later be
-                 preempted
-     Message-ID: <4231.629.XYzi-What@Other-Host>
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 39 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     B.  SIMPLE FIELD PARSING
-     
-          Some mail-reading software systems may wish to perform  only
-     minimal  processing,  ignoring  the internal syntax of structured
-     field-bodies and treating them the  same  as  unstructured-field-
-     bodies.  Such software will need only to distinguish:
-     
-         o   Header fields from the message body,
-     
-         o   Beginnings of fields from lines which continue fields,
-     
-         o   Field-names from field-contents.
-     
-          The abbreviated set of syntactic rules  which  follows  will
-     suffice  for  this  purpose.  It describes a limited view of mes-
-     sages and is a subset of the syntactic rules provided in the main
-     part of this specification.  One small exception is that the con-
-     tents of field-bodies consist only of text:
-     
-     B.1.  SYNTAX
-     
-     
-     message         =   *field *(CRLF *text)
-     
-     field           =    field-name ":" [field-body] CRLF
-     
-     field-name      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
-     
-     field-body      =   *text [CRLF LWSP-char field-body]
-     
-     
-     B.2.  SEMANTICS
-     
-          Headers occur before the message body and are terminated  by
-     a null line (i.e., two contiguous CRLFs).
-     
-          A line which continues a header field begins with a SPACE or
-     HTAB  character,  while  a  line  beginning a field starts with a
-     printable character which is not a colon.
-     
-          A field-name consists of one or  more  printable  characters
-     (excluding  colon,  space, and control-characters).  A field-name
-     MUST be contained on one line.  Upper and lower case are not dis-
-     tinguished when comparing field-names.
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 40 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     C.  DIFFERENCES FROM RFC #733
-     
-          The following summarizes the differences between this  stan-
-     dard  and the one specified in Arpanet Request for Comments #733,
-     "Standard for the Format of ARPA  Network  Text  Messages".   The
-     differences  are  listed  in the order of their occurrence in the
-     current specification.
-     
-     C.1.  FIELD DEFINITIONS
-     
-     C.1.1.  FIELD NAMES
-     
-        These now must be a sequence of  printable  characters.   They
-        may not contain any LWSP-chars.
-     
-     C.2.  LEXICAL TOKENS
-     
-     C.2.1.  SPECIALS
-     
-        The characters period ("."), left-square  bracket  ("["),  and
-        right-square  bracket ("]") have been added.  For presentation
-        purposes, and when passing a specification to  a  system  that
-        does  not conform to this standard, periods are to be contigu-
-        ous with their surrounding lexical tokens.   No  linear-white-
-        space  is  permitted  between them.  The presence of one LWSP-
-        char between other tokens is still directed.
-     
-     C.2.2.  ATOM
-     
-        Atoms may not contain SPACE.
-     
-     C.2.3.  SPECIAL TEXT
-     
-        ctext and qtext have had backslash ("\") added to the list  of
-        prohibited characters.
-     
-     C.2.4.  DOMAINS
-     
-        The lexical tokens  <domain-literal>  and  <dtext>  have  been
-        added.
-     
-     C.3.  MESSAGE SPECIFICATION
-     
-     C.3.1.  TRACE
-     
-        The "Return-path:" and "Received:" fields have been specified.
-     
-     
-     
-     
-     
-     August 13, 1982              - 41 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     C.3.2.  FROM
-     
-        The "From" field must contain machine-usable addresses  (addr-
-        spec).   Multiple  addresses may be specified, but named-lists
-        (groups) may not.
-     
-     C.3.3.  RESENT
-     
-        The meta-construct of prefacing field names  with  the  string
-        "Resent-"  has been added, to indicate that a message has been
-        forwarded by an intermediate recipient.
-     
-     C.3.4.  DESTINATION
-     
-        A message must contain at least one destination address field.
-        "To" and "CC" are required to contain at least one address.
-     
-     C.3.5.  IN-REPLY-TO
-     
-        The field-body is no longer a comma-separated list, although a
-        sequence is still permitted.
-     
-     C.3.6.  REFERENCE
-     
-        The field-body is no longer a comma-separated list, although a
-        sequence is still permitted.
-     
-     C.3.7.  ENCRYPTED
-     
-        A field has been specified that permits  senders  to  indicate
-        that the body of a message has been encrypted.
-     
-     C.3.8.  EXTENSION-FIELD
-     
-        Extension fields are prohibited from beginning with the  char-
-        acters "X-".
-     
-     C.4.  DATE AND TIME SPECIFICATION
-     
-     C.4.1.  SIMPLIFICATION
-     
-        Fewer optional forms are permitted  and  the  list  of  three-
-        letter time zones has been shortened.
-     
-     C.5.  ADDRESS SPECIFICATION
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 42 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     C.5.1.  ADDRESS
-     
-        The use of quoted-string, and the ":"-atom-":" construct, have
-        been  removed.   An  address  now  is  either a single mailbox
-        reference or is a named list of addresses.  The  latter  indi-
-        cates a group distribution.
-     
-     C.5.2.  GROUPS
-     
-        Group lists are now required to to have a name.   Group  lists
-        may not be nested.
-     
-     C.5.3.  MAILBOX
-     
-        A mailbox specification  may  indicate  a  person's  name,  as
-        before.   Such  a  named  list  no longer may specify multiple
-        mailboxes and may not be nested.
-     
-     C.5.4.  ROUTE ADDRESSING
-     
-        Addresses now are taken to be absolute, global specifications,
-        independent  of transmission paths.  The <route> construct has
-        been provided, to permit explicit specification  of  transmis-
-        sion  path.   RFC  #733's  use  of multiple at-signs ("@") was
-        intended as a general syntax  for  indicating  routing  and/or
-        hierarchical addressing.  The current standard separates these
-        specifications and only one at-sign is permitted.
-     
-     C.5.5.  AT-SIGN
-     
-        The string " at " no longer is used as an  address  delimiter.
-        Only at-sign ("@") serves the function.
-     
-     C.5.6.  DOMAINS
-     
-        Hierarchical, logical name-domains have been added.
-     
-     C.6.  RESERVED ADDRESS
-     
-     The local-part "Postmaster" has been reserved, so that users  can
-     be guaranteed at least one valid address at a site.
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 43 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     D.  ALPHABETICAL LISTING OF SYNTAX RULES
-     
-     address     =  mailbox                      ; one addressee
-                 /  group                        ; named list
-     addr-spec   =  local-part "@" domain        ; global address
-     ALPHA       =  <any ASCII alphabetic character>
-                                                 ; (101-132, 65.- 90.)
-                                                 ; (141-172, 97.-122.)
-     atom        =  1*<any CHAR except specials, SPACE and CTLs>
-     authentic   =   "From"       ":"   mailbox  ; Single author
-                 / ( "Sender"     ":"   mailbox  ; Actual submittor
-                     "From"       ":" 1#mailbox) ; Multiple authors
-                                                 ;  or not sender
-     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
-     comment     =  "(" *(ctext / quoted-pair / comment) ")"
-     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
-     CRLF        =  CR LF
-     ctext       =  <any CHAR excluding "(",     ; => may be folded
-                     ")", "\" & CR, & including
-                     linear-white-space>
-     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
-                     character and DEL>          ; (    177,     127.)
-     date        =  1*2DIGIT month 2DIGIT        ; day month year
-                                                 ;  e.g. 20 Jun 82
-     dates       =   orig-date                   ; Original
-                   [ resent-date ]               ; Forwarded
-     date-time   =  [ day "," ] date time        ; dd mm yy
-                                                 ;  hh:mm:ss zzz
-     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
-                 /  "Fri"  / "Sat" /  "Sun"
-     delimiters  =  specials / linear-white-space / comment
-     destination =  "To"          ":" 1#address  ; Primary
-                 /  "Resent-To"   ":" 1#address
-                 /  "cc"          ":" 1#address  ; Secondary
-                 /  "Resent-cc"   ":" 1#address
-                 /  "bcc"         ":"  #address  ; Blind carbon
-                 /  "Resent-bcc"  ":"  #address
-     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
-     domain      =  sub-domain *("." sub-domain)
-     domain-literal =  "[" *(dtext / quoted-pair) "]"
-     domain-ref  =  atom                         ; symbolic reference
-     dtext       =  <any CHAR excluding "[",     ; => may be folded
-                     "]", "\" & CR, & including
-                     linear-white-space>
-     extension-field =
-                   <Any field which is defined in a document
-                    published as a formal extension to this
-                    specification; none will have names beginning
-                    with the string "X-">
-     
-     
-     August 13, 1982              - 44 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     field       =  field-name ":" [ field-body ] CRLF
-     fields      =    dates                      ; Creation time,
-                      source                     ;  author id & one
-                    1*destination                ;  address required
-                     *optional-field             ;  others optional
-     field-body  =  field-body-contents
-                    [CRLF LWSP-char field-body]
-     field-body-contents =
-                   <the ASCII characters making up the field-body, as
-                    defined in the following sections, and consisting
-                    of combinations of atom, quoted-string, and
-                    specials tokens, or else consisting of texts>
-     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
-     group       =  phrase ":" [#mailbox] ";"
-     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
-                                                 ; 00:00:00 - 23:59:59
-     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
-     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
-     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
-                                                 ; CRLF => folding
-     local-part  =  word *("." word)             ; uninterpreted
-                                                 ; case-preserved
-     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
-     mailbox     =  addr-spec                    ; simple address
-                 /  phrase route-addr            ; name & addr-spec
-     message     =  fields *( CRLF *text )       ; Everything after
-                                                 ;  first null line
-                                                 ;  is message body
-     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
-                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
-                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
-     msg-id      =  "<" addr-spec ">"            ; Unique message id
-     optional-field =
-                 /  "Message-ID"        ":"   msg-id
-                 /  "Resent-Message-ID" ":"   msg-id
-                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
-                 /  "References"        ":"  *(phrase / msg-id)
-                 /  "Keywords"          ":"  #phrase
-                 /  "Subject"           ":"  *text
-                 /  "Comments"          ":"  *text
-                 /  "Encrypted"         ":" 1#2word
-                 /  extension-field              ; To be defined
-                 /  user-defined-field           ; May be pre-empted
-     orig-date   =  "Date"        ":"   date-time
-     originator  =   authentic                   ; authenticated addr
-                   [ "Reply-To"   ":" 1#address] )
-     phrase      =  1*word                       ; Sequence of words
-     
-     
-     
-     
-     August 13, 1982              - 45 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     qtext       =  <any CHAR excepting <">,     ; => may be folded
-                     "\" & CR, and including
-                     linear-white-space>
-     quoted-pair =  "\" CHAR                     ; may quote any char
-     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
-                                                 ;   quoted chars.
-     received    =  "Received"    ":"            ; one per relay
-                       ["from" domain]           ; sending host
-                       ["by"   domain]           ; receiving host
-                       ["via"  atom]             ; physical path
-                      *("with" atom)             ; link/mail protocol
-                       ["id"   msg-id]           ; receiver msg id
-                       ["for"  addr-spec]        ; initial form
-                        ";"    date-time         ; time received
-     
-     resent      =   resent-authentic
-                   [ "Resent-Reply-To"  ":" 1#address] )
-     resent-authentic =
-                 =   "Resent-From"      ":"   mailbox
-                 / ( "Resent-Sender"    ":"   mailbox
-                     "Resent-From"      ":" 1#mailbox  )
-     resent-date =  "Resent-Date" ":"   date-time
-     return      =  "Return-path" ":" route-addr ; return address
-     route       =  1#("@" domain) ":"           ; path-relative
-     route-addr  =  "<" [route] addr-spec ">"
-     source      = [  trace ]                    ; net traversals
-                      originator                 ; original mail
-                   [  resent ]                   ; forwarded
-     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
-     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
-                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
-                 /  "." / "[" / "]"              ;  within a word.
-     sub-domain  =  domain-ref / domain-literal
-     text        =  <any CHAR, including bare    ; => atoms, specials,
-                     CR & bare LF, but NOT       ;  comments and
-                     including CRLF>             ;  quoted-strings are
-                                                 ;  NOT recognized.
-     time        =  hour zone                    ; ANSI and Military
-     trace       =    return                     ; path to sender
-                    1*received                   ; receipt tags
-     user-defined-field =
-                   <Any field which has not been defined
-                    in this specification or published as an
-                    extension to this specification; names for
-                    such fields must be unique and may be
-                    pre-empted by published extensions>
-     word        =  atom / quoted-string
-     
-     
-     
-     
-     August 13, 1982              - 46 -                      RFC #822

-     
Standard for ARPA Internet Text Messages
-     
-     
-     zone        =  "UT"  / "GMT"                ; Universal Time
-                                                 ; North American : UT
-                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
-                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
-                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
-                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
-                 /  1ALPHA                       ; Military: Z = UT;
-     <">         =  <ASCII quote mark>           ; (     42,      34.)
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     
-     August 13, 1982              - 47 -                      RFC #822
-     

-
-
-
-
-
\ No newline at end of file

From 848654bd4fbace9f5ce5f0759e45cb027aa8c7b2 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Tue, 26 Jul 2022 12:02:19 -0400
Subject: [PATCH 14/16] Update eip-1.md

---
 EIPS/eip-1.md | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md
index e7be5cc8aa3161..f16170e45bab5d 100644
--- a/EIPS/eip-1.md
+++ b/EIPS/eip-1.md
@@ -96,7 +96,7 @@ If this period results in necessary normative changes it will revert the EIP to
 
 Each EIP should have the following parts:
 
-- Preamble - [RFC 822](../assets/RFCs/rfc822.html) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details.
+- Preamble - [RFC 822](https://www.rfc-editor.org/rfc/rfc822.html) style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details.
 - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
 - Motivation _(optional)_ - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident.
 - Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (cpp-ethereum, go-ethereum, parity, ethereumJ, ethereumjs-lib, [and others](https://github.com/ethereum/wiki/wiki/Clients).
@@ -113,7 +113,7 @@ EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wik
 
 ## EIP Header Preamble
 
-Each EIP must begin with an [RFC 822](../assets/RFCs/rfc822.html) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order.
+Each EIP must begin with an [RFC 822](https://www.rfc-editor.org/rfc/rfc822.html) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order.
 
 `eip`: *EIP number* (this is determined by the EIP editor)
 
@@ -267,13 +267,18 @@ When referring to an EIP by number, it should be written in the hyphenated form
 
 ### IETF RFCs
 
-When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by a relative markdown link to the RFC (in the `assets/RFCs` directory) the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. If the RFC is not currently in that directory, a separate pull request must be submitted which ONLY includes the HTML rendering of that RFC.
+When referring to an IETF RFC by number, it must be written in the non-hyphenated form `RFC X`, where `X` is the RFC's assigned number. Each RFC that is referenced in an EIP **MUST** be accompanied by an absolute markdown link to the HTML rendering of the RFC hosted on `www.rfc-editor.org` the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. The following is an example of such a link:
+
+```
+
+https://www.rfc-editor.org/rfc/rfc822.html
+```
 
 ### RFC 2119
 
-EIPs are encouraged to follow [RFC 2119](../assets/RFCs/rfc2119.html) for terminology and to insert the following at the beginning of the Specification section:
+EIPs are encouraged to follow [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html) for terminology and to insert the following at the beginning of the Specification section:
 
-> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/RFCs/rfc2119.html).
+> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html).
 
 ## History
 

From 2129c6c18d4959c09c0c4e24ff92e076ca4d6747 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Tue, 26 Jul 2022 12:03:28 -0400
Subject: [PATCH 15/16] Update eip-template.md

---
 eip-template.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eip-template.md b/eip-template.md
index c9894c93de2e2a..6e5dbfe6ff11b1 100644
--- a/eip-template.md
+++ b/eip-template.md
@@ -24,7 +24,7 @@ Abstract is a multi-sentence (short paragraph) technical summary. This should be
 The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address?
 
 ## Specification
-The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](../assets/RFCs/rfc2119.txt).
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html).
 
 The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).
 

From f12d5050839e2d7941fb06118a7dd19b684f8374 Mon Sep 17 00:00:00 2001
From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Date: Wed, 27 Jul 2022 10:34:36 -0400
Subject: [PATCH 16/16] Somehow missed this

---
 .github/workflows/ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 914ce159da290d..4fd59576a5b471 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -45,7 +45,7 @@ jobs:
         with:
           check_filenames: true
           ignore_words_file: .codespell-whitelist
-          skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css,assets/RFCs/*.txt
+          skip: .git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css
   
   eip-validator:
     name: EIP Validator