From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc733.txt | 1958 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1958 insertions(+) create mode 100644 doc/rfc/rfc733.txt (limited to 'doc/rfc/rfc733.txt') diff --git a/doc/rfc/rfc733.txt b/doc/rfc/rfc733.txt new file mode 100644 index 0000000..a2a1472 --- /dev/null +++ b/doc/rfc/rfc733.txt @@ -0,0 +1,1958 @@ + + + + +RFC # 733 +NIC # 41952 + +Obsoletes: RFC #561 (NIC #18516) + RFC #680 (NIC #32116) + RFC #724 (NIC #37435) + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA NETWORK TEXT MESSAGES(1) + + + + + 21 November 1977 + + + + + by + + + David H. Crocker + The Rand Corporation + + John J. Vittal + Bolt Beranek and Newman Inc. + + Kenneth T. Pogran + Massachusets Institute of Technology + + D. Austin Henderson, Jr.(2) + Bolt Beranek and Newman Inc. + + + +_________________________________________________________________ +(1)This work was supported by the Defense Advanced Research +Projects Agency of the Department of Defense, under contract Nos. +N00014-75-C-0661, MDA903-76-C-0212, and DAHC15-73-C0181. + +(2)The authors' postal addresses are: D. Crocker, The Rand +Corporation, Information Sciences Dept., 1700 Main St., Santa +Monica, California 90406; J. Vittal & D. A. Henderson, Bolt +Beranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138; +and K. Pogran, MIT Laboratory for Computer Science, 545 +Technology Square, Cambridge, Massachusetts 02139. The authors' +ARPANET addresses are: DCrocker at Rand-Unix, Vittal at BBN- +TenexD, Pogran at MIT-Multics, and Henderson at BBN-TenexD. + + -iii- + + + + + + PREFACE + + + + ARPA's Committee on Computer-Aided Human Communication +(CAHCOM) wishes to promulgate a standard for the format of ARPA +Network text message (mail) headers which will reasonably meet +the needs of the various message service subsystems on the +Network today. The authors of this document constitute the +CAHCOM subcommittee charged with the task of developing this new +standard. + + Essentially, we specify a revision to ARPANET Request for +Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC +680, "Message Transmission Protocol". This revision removes and +compacts portions of the previous syntax and adds several +features to network address specification. In particular, we +focus on people and not mailboxes as recipients and allow +reference to stored address lists. We expect this syntax to +provide sufficient capabilities to meet most users' immediate +needs and, therefore, give developers enough breathing room to +produce a new mail transmission protocol "properly". We believe +that there is enough of a consensus in the Network community in +favor of such a standard syntax to make possible its adoption at +this time. An earlier draft of this specification was published +as RFC #724, "Proposed Official Standard for the Format of ARPA +Network Messages" and contained extensive discussion of the +background and issues in ARPANET mail standards. + + This specification was developed 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, +participated in this discussion and we would like to acknowledge +their considerable efforts. The syntax of the standard 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 which compacts the +specification and allows increased comprehensibility. + + + + -v- + + + + + + CONTENTS + + + +PREFACE..................................................... iii + + +Section + I. INTRODUCTION......................................... 1 + + II. FRAMEWORK............................................ 2 + + III. SYNTAX............................................... 4 + A. Notational Conventions............................ 4 + B. Lexical Analysis of Messages...................... 5 + C. General Syntax of Messages........................ 13 + D. Syntax of General Addressee Items................. 15 + E. Supporting Constructs............................. 15 + + IV. SEMANTICS............................................ 17 + A. Address Fields.................................... 17 + B. Reference Specification Fields.................... 22 + C. Other Fields and Syntactic Items.................. 23 + D. Dates and Times................................... 24 + + V. EXAMPLES............................................. 25 + A. Addresses......................................... 25 + B. Address Lists..................................... 26 + C. Originator Items.................................. 26 + D. Complete Headers.................................. 28 + + +Appendix + A. ALPHABETICAL LISTING OF SYNTAX RULES................. 31 + B. SIMPLE PARSING....................................... 35 + +BIBLIOGRAPHY................................................ 37 + + +Standard for the Format of Text Messages 1 +I. Introduction + + + + + + I. INTRODUCTION + + + + + This standard specifies a syntax for text messages which are +passed between computer users within the framework of "electronic +mail". The standard supersedes the informal standards specified +in ARPANET Request for Comments numbers 561, "Standardizing +Network Mail Headers", and 680, "Message Transmission Protocol". +In this document, a general framework is first described; the +formal syntax is then specified, followed by a discussion of the +semantics. Finally, a number of examples are given. + + This specification is intended strictly as a definition of +what is to be passed between hosts on the ARPANET. It is NOT +intended to dictate either features which systems on the Network +are expected to support, or user interfaces to message creating +or reading programs. + + 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. These simplifications facilitate the formal +specification and indicate what the OFFICIAL semantics are for +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. + + + + +Standard for the Format of Text Messages 2 +II. Framework + + + + + + II. FRAMEWORK + + + + + Since there are many message systems which exist outside the +ARPANET environment, as well as those within it, it may be useful +to consider the general framework, and resulting capabilities and +limitations, provided by this standard. + + Messages are expected to consist of lines of text. No +special provisions are made, at this time, for encoding drawings, +facsimile, speech, or structured text. + + No significant consideration has been given to questions of +data compression or transmission/storage efficiency. The +standard, in fact, tends to be very free with the number of bits +consumed. For example, field names are specified as free text, +rather than special terse codes. + + A general "memo" framework is used. That is, a message +consists of some information, in a rigid format, followed by the +main part of the message, which is text and whose format is not +specified in this document. The syntax of several fields of the +rigidly-formated ("header") section is defined in this +specification; some of the header fields must be included in all +messages. The syntax which distinguishes between headers is +specified separately from the internal syntax for particular +headers. This separation is intended to allow extremely simple +parsers to operate on the overall structure of messages, without +concern for the detailed structure of individual headers. +Appendix B is provided to facilitate construction of these simple +parsers. In addition to the fields specified in this document, +it is expected that other fields will gain common use. User- +defined header fields allow systems to extend their functionality +while maintaining a uniform framework. The approach is similar +to that of the TELNET protocol, in that a basic standard is +defined which includes a mechanism for (optionally) extending +itself. As necessary, the authors of this document will regulate +the publishing of specifications for these "extension-fields", +through the same mechanisms used to publish this document. + + Such a framework severely constrains document tone and +appearance and is primarily useful for most intra-organization +communications and relatively structured inter-organization +communication. A more robust environment might allow for multi- +font, multi-color, multi-dimension encoding of information. A +less robust environment, 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 +to paper-based communication, it is interesting to note that the + +Standard for the Format of Text Messages 3 +II. Framework + + + +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. + + +Standard for the Format of Text Messages 4 +III. Syntax + + + + + + III. SYNTAX + + + + This syntax is given in five parts. The first part +describes the notation used in the specification. The second +part describes the base-level lexical analyzers which feed the +higher-level parser described in the succeeding sections. The +third part gives a general syntax for messages and standard +header fields; and the fourth part specifies the syntax of +addresses. A final part specifies some general syntax which +supports the other sections. + + + +A. NOTATIONAL CONVENTIONS + +These specifications are made in an augmented Backus-Naur Form +(BNF). Differences from standard BNF involve the naming of +rules, the indication of repetition and of "local" alternatives. + + +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. Parentheses: Local alternatives + +Elements enclosed in parentheses are treated as a single element. +Thus, "(elem (foo / bar) elem)" allows "(elem foo elem)" and +"(elem bar elem)". + + +3. * construct: 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. + +Standard for the Format of Text Messages 5 +III. Syntax + A. Notational Conventions + + + +4. element + +"(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. + + +5. # construct: 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 +element is required, at least one non-null element must be +present. + + +6. [optional] + +Square brackets enclose optional elements; "[foo bar]" is +equivalent to "*1(foo bar)". + + +7. ; Comments + +A semi-colon, set off some distance to the right of rule text, +starts a comment which continues to the end of line. This is a +simple way of including useful notes in parallel with the +specifications. + + + +B. LEXICAL ANALYSIS OF MESSAGES + + +1. General Description + +A message consists of headers and, optionally, a body (i.e. a +series of text lines). The text part is just a sequence of lines +containing ASCII characters; it is separated from the headers by +a null line (i.e., a line with nothing preceding the CRLF). + + +Standard for the Format of Text Messages 6 +III. Syntax + B. Lexical Analysis + + + +a. Folding and unfolding of headers + + Each header item can be viewed as a single, logical line of + ASCII characters. For convenience, the field-body portion of + this conceptual entity can be split into a multiple-line + representation (i.e., "folded"). The general rule is that + wherever there can be linear-white-space (NOT simply LWSP- + chars), a CRLF immediately followed by AT LEAST one LWSP-char + can instead be inserted. (However, a header's name and the + following colon (":"), which occur at the beginning of the + header item, may NOT be folded onto multiple lines.) Thus, + the single line + + To: "Joe Dokes & J. Harvey" , JJV at BBN + + can be represented as + + To: "Joe Dokes & J. Harvey" , + JJV at BBN + + and + + To: "Joe Dokes & J. Harvey" + , + JJV at BBN + + and + + To: "Joe Dokes + & J. Harvey" , JJV at BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line + representation will be called "unfolding". Unfolding is + accomplished by regarding CRLF immediately followed by a + LWSP-char as equivalent to the LWSP-char. + +b. Structure of header fields + + Once header fields have been unfolded, they may be viewed as + being composed of a field-name followed by a colon (":"), + followed by a field-body. The field-name must be composed of + printable ASCII characters (i.e., characters which have + values between 33. and 126., decimal, except colon) and + LWSP-chars. The field-body may be composed of any ASCII + characters (other than an unquoted CRLF, which has been + removed by unfolding). + + Certain field-bodies of header fields may be interpreted + according to an internal syntax which some systems may wish + to parse. These fields will be referred to as "structured" + fields. Examples include fields containing dates and + +Standard for the Format of Text Messages 7 +III. Syntax + B. Lexical Analysis + + + + addresses. Other fields, such as "Subject" and "Comments", + are regarded simply as strings of text. + + NOTE: Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, INDEPENDENT + "lexical" analyzer. + +c. Field-names + + To aid in the creation and reading of field-names, the free + insertion of LWSP-chars is allowed in reasonable places. + + Rather than obscuring the syntax specification for field-name + with the explicit syntax for these LWSP-chars, the existence + of a "lexical" analyzer is assumed. The analyzer interprets + the text which comprises the field-name as a sequence of + field-name atoms (fnatoms) separated by LWSP-chars + + Note that ONLY LWSP-chars may occur between the fnatoms of a + field-name and that CRLFs may NOT. In addition, comments are + NOT lexically recognized, as such, but parenthesized strings + are legal as part of field-names. These constraints are + different from what is permissible within structured field + bodies. In particular, this means that header field-names + must wholly occur on the FIRST line of a folded header item + and may NOT be split across two or more lines. + +d. Unstructured field bodies + + For some fields, such as "Subject" and "Comments", no + structuring is assumed; and they are treated simply as texts, + like those 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. + +e. 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 in reasonable places. + 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 field bodies which + are simply unstructured strings of text, as described above. + It provides an interpretation of the unfolded text comprising + the body of the field as a sequence of lexical symbols. + These symbols are: + + - individual special characters + - quoted-strings + +Standard for the Format of Text Messages 8 +III. Syntax + B. Lexical Analysis + + + + - comments + - atoms + + The first three of these symbols are self-delimiting. Atoms + are not; they therefore are delimited by the self-delimiting + symbols and by linear-white-space. For the purposes of re- + generating sequences of atoms and quoted-strings, exactly one + SPACE is assumed to exist and should be used between them. + (Also, in Section III.B.3.a, note the rules concerning + treatment of multiple continguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Host, + Muhammed(I am the greatest)Ali at(the)WBA + + is analyzed into the following lexical symbols and types: + + ":sysmail" quoted string + @ special + Some-Host atom + , special + Muhammed atom + (I am the greatest) comment + Ali atom + at atom + (the) comment + WBA atom + + The cononical representations for the data in these addresses + are the following strings (note that there is exactly one + SPACE between words): + + :sysmail at Some-Host + + and + + Muhammed Ali at WBA + + + +2. Formal Definitions + +The first four rules, below, indicate a meta-syntax for fields, +without regard to their particular type or internal syntax. The +remaining rules define basic syntactic structures which are used +by the rules in Sections III.C, III.D, and III.E. + +field = field-name ":" [ field-body ] CRLF + +field-name = fnatom *( LWSP-char [fnatom] ) + + +Standard for the Format of Text Messages 9 +III. Syntax + B. Lexical Analysis + + + +fnatom = 1* + +field-body = field-body-contents + [CRLF LWSP-char field-body] + +field-body-contents = + + ; ( 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 = "(" / ")" / "<" / ">" / "@" ; To use in a word, + / "," / ";" / ":" / "\" / <"> ; word must be a + ; quoted-string. + +delimiters = specials / comment / linear-white-space + +text = atoms, specials, + CR and/or bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT interpreted. + +atom = 1* + +quoted-string = <"> *(qtext/quoted-pair) <">; Any number of qtext + ; chars or any + ; quoted char. + +qtext = ; => may be folded + and CR, and including + linear-white-space> + + +Standard for the Format of Text Messages 10 +III. Syntax + B. Lexical Analysis + + + +comment = "(" *(ctext / comment / quoted-pair) ")" +ctext = may be folded + ")" and CR, and including + linear-white-space> + +quoted-pair = "\" CHAR + + +3. Clarifications + +a. "White space" + + Remember that in field-names and structured field bodies, + MULTIPLE LINEAR WHITE SPACE TELNET 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 space is REQUIRED is at the beginning of + continuation lines in a folded field. When passing text to + processes which do not interpret text according to this + standard (e.g., ARPANET FTP mail servers), then exactly one + SPACE should be used in place of arbitrary linear-white-space + and comment sequences. + + WHEREVER A MEMBER OF THE LIST OF S 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 horizontal-tab TELNET ASCII characters on the + appearance of text at another Network host; therefore, the + use of tabs in message headers, though permitted, is + discouraged. + + Note that during transmissions across the ARPANET using + TELNET NVT connections, data must conform to TELNET NVT + conventions (e.g., CR must be followed by either LF, making a + CRLF, or , if the CR is to stand alone). + +b. Comments + + Comments are detected as such only within field-bodies of + structured fields. A comment is a set of TELNET ASCII + characters, which is not within a quoted-string and which is + enclosed in matching parentheses; parentheses nest, so that + if an unquoted left parenthesis occurs in a comment string, + there must also be a matching right parenthesis. When a + comment is used to act as the delimiter between a sequence of + two lexical symbols, such as two atoms, it is lexically + equivalent with one SPACE, for the purposes of regenerating + the sequence, such as when passing the sequence onto an FTP + mail server. + + +Standard for the Format of Text Messages 11 +III. Syntax + B. Lexical Analysis + + + + In particular comments are NOT passed to the FTP server, as + part of a MAIL or MLFL command, since comments are not part + of the "formal" address. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See items III.B.1.a, + above, and III.B.3.f, below.) Note that the official + semantics therefore do not "see" any unquoted CRLFs which are + in comments, although particular parsing programs may wish to + note their presence. For these programs, it would be + reasonable to interpret a "CRLF LWSP-char" as being a CRLF + which 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. + +c. Delimiting and quoting characters + + The quote character (backslash) and characters which delimit + syntactic units are not, generally, to be taken as data which + are part of the delimited or quoted unit(s). The one + exception is SPACE. In particular, the quotation-marks which + define a quoted-string, the parentheses which define a + comment and the backslash which quotes a following character + are NOT part of the quoted-string, comment or quoted + character. A quotation-mark which is to be part of a + quoted-string, a parenthesis which is to be part of a comment + and a backslash which 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 + those which are not part of the alternate text group (i.e., + ctext or qtext). + + 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 which 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 which delimit a quoted string and backslashes + which quote the following character should NOT accompany the + quoted-string when the string is used with processes that do + not interpret data according to this specification (e.g., + ARPANET FTP mail servers). + + +Standard for the Format of Text Messages 12 +III. Syntax + B. Lexical Analysis + + + +d. Quoted-strings + + Where permitted (i.e., in words in structured fields) + quoted-strings are treated as a single symbol (i.e. + 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 items III.B.1.a, above, and + III.B.3.f, below.) Note that the official semantics + therefore do not "see" any bare CRLFs which are in quoted- + strings, although particular parsing programs may wish to + note their presence. For these programs, it would be + reasonable 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 followed 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. + +e. Bracketing characters + + There are three types of brackets which must be well nested: + + o Parentheses are used to indicate comments. + + o Angle brackets ("<" and ">") are generally used + to indicate the presence of at least one machine- + usable code (e.g., delimiting mailboxes). + + 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. + +f. Case independence of certain specials atoms + + Certain atoms, which are represented in the syntax as literal + alphabetic strings, can be represented in any combination of + upper and lower case. These are: + + - field-name, + - "Include", "Postal" and equivalent atoms in a + ":"":" address specification, + - "at", in a host-indicator, + - node, + - day-of-week, + - month, and + - zones. + + When matching an atom against one of these literals, case is + to be ignored. For example, the field-names "From", "FROM", + +Standard for the Format of Text Messages 13 +III. Syntax + B. Lexical Analysis + + + + "from", and even "FroM" should all be treated identically. + However, the case shown in this specification is suggested + for message-creating processes. Note that, at the level of + this specification, case IS relevant to other words and + texts. Also see Section IV.A.1.f, below. + +g. Folding long lines + + Each header item (field of the message) may be represented on + exactly one line consisting of the name of the field and its + body; this is what the parser sees. For readability, it is + recommended that the field-body portion of long header items + be "folded" onto multiple lines of the actual header. "Long" + is commonly interpreted to mean greater than 65 or 72 + characters. The former length is recommended as a limit, but + it is not imposed by this standard. + +h. Backspace characters + + Backspace TELNET ASCII characters (ASCII BS, 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. + + + +C. GENERAL SYNTAX OF MESSAGES: + + + NOTE: Due to an artifact of the notational conventions, + the syntax indicates that, when present, "Date", + "From", "Sender", and "Reply-To" fields must be + in a particular order. These header items must + be unique (occur exactly once). However header + fields, in fact, are NOT required to occur in any + particular order, except that the message body + must occur AFTER the headers. For readability + and ease of parsing by simple systems, it is + recommended that headers be sent in the order + "Date", "From", "Subject", "Sender", "To", "cc", + etc. This specification permits multiple + occurrences of most optional-fields. However, + their interpretation is not specified here, and + their use is strongly 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 section on Lexical Analysis (section II.B) +indicates how such long strings can be represented on more than +one line in the actual transmitted message. + + +Standard for the Format of Text Messages 14 +III. Syntax + C. Messages + + + +message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + +fields = date-field ; Creation time-stamp + originator-fields ; & author id are + *optional-field ; required: others + ; are all optional + +originator-fields = + ( "From" ":" mailbox ; Single author + ["Reply-To" ":" #address] ) + / ( "From" ":" 1#address ; Multiple authors & + "Sender" ":" mailbox ; may have non-mach- + ["Reply-To" ":" #address] ); ine addresses + +date-field = "Date" ":" date-time + +optional-field = + "To" ":" #address + / "cc" ":" #address + / "bcc" ":" #address ; Blind carbon + / "Subject" ":" *text + / "Comments" ":" *text + / "Message-ID" ":" mach-id ; Only one allowed + / "In-Reply-To"":" #(phrase / mach-id) + / "References" ":" #(phrase / mach-id) + / "Keywords" ":" #phrase + / extension-field ; To be defined in + ; supplemental + ; specifications + / user-defined-field ; Must have unique + ; field-name & may + ; be pre-empted + +extension-field = + +user-defined-field = + + + + +Standard for the Format of Text Messages 15 +III. Syntax + D. Addressee Items + + + +D. SYNTAX OF GENERAL ADDRESSEE ITEMS + + +address = host-phrase ; Machine mailbox + / ( [phrase] "<" #address ">") ; Individual / List + / ( [phrase] ":" #address ";") ; Group + / quoted-string ; Arbitrary text + / (":" ( "Include" ; File, w/ addr list + / "Postal" ; (U.S.) Postal addr + / atom ) ; Extended data type + ":" address) + +mailbox = host-phrase / (phrase mach-id) + +mach-id = "<" host-phrase ">" ; Contents must never + ; be modified! + + + +E. SUPPORTING CONSTRUCTS + + +host-phrase = phrase host-indicator ; Basic address + +host-indicator = 1*( ("at" / "@") node ) ; Right-most node is + ; at top of network + ; hierarchy; left- + ; most must be host + +node = word / 1*DIGIT ; Official host or + ; network name or + ; decimal address + + +date-time = [ day-of-week "," ] date time + +day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue" + / "Wednesday" / "Wed" / "Thursday" / "Thu" + / "Friday" / "Fri" / "Saturday" / "Sat" + / "Sunday" / "Sun" + +date = 1*2DIGIT ["-"] month ; day month year + ["-"] (2DIGIT /4DIGIT) ; e.g. 20 Aug [19]77 + +month = "January" / "Jan" / "February" / "Feb" + / "March" / "Mar" / "April" / "Apr" + / "May" / "June" / "Jun" + / "July" / "Jul" / "August" / "Aug" + / "September" / "Sep" / "October" / "Oct" + / "November" / "Nov" / "December" / "Dec" + + +Standard for the Format of Text Messages 16 +III. Syntax + E. Supporting Constructs + + + +time = hour zone ; ANSI and Military + ; (seconds optional) + +hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ] + ; 0000[00] - 2359[59] + +zone = ( ["-"] ( "GMT" ; Relative to GMT: + ; North American + / "NST" / ; Newfoundland:-3:30 + / "AST" / "ADT" ; Atlantic: - 4/ - 3 + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / "YST" / "YDT" ; Yukon: - 9/ - 8 + / "HST" / "HDT" ; Haw/Ala -10/ - 9 + / "BST" / "BDT" ; Bering: -11/ -10 + 1ALPHA )) ; Military: Z = GMT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours/min. (HHMM) + +phrase = 1*word ; Sequence of words. + ; Separation seman- + ; tically = SPACE + +word = atom / quoted-string + + + +Standard for the Format of Text Messages 17 +IV. Semantics + A. Address Fields + + + + + + IV. SEMANTICS + + + +A. ADDRESS FIELDS + + +1. General + +a. The phrase part of a host-phrase in an address specification + (i.e., the host's name for the mailbox) is understood to be + whatever the receiving FTP Server allows (for example, TENEX + systems do not now understand addresses of the form "P. D. + Q. Bach", but another system might). + + Note that a mailbox 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. + + An individual may have several mailboxes and a group of + individuals may wish to receive mail as a single unit (i.e., + a distribution list). The second and third alternatives of + an address list (#address) allow naming a collection of + subordinate addresses list(s). Recipient mailboxes are + specified within the bracketed part ("<" - ">" or ":" - ";") + of such named lists. The use of angle-brackets ("<", ">") is + intended for the cases of individuals with multiple mailboxes + and of special mailbox lists; it is not expected to be nested + more than one level, although the specification allows such + nesting. The use of colon/semi-colon (":", ";") is intended + for the case of groups. Groups can be expected to nest + (i.e., to contain subgroups). For both individuals and + groups, a copy of the transmitted message is to be sent to + EACH mailbox listed. For the case of a special list, + treatment of addresses is defined in the relevant subsections + of this section. + +b. The inclusion of bare quoted-strings as addresses (i.e., the + fourth address-form alternative) is allowed as a syntactic + convenience, but no semantics are defined for their use. + However, it is reasonable, when replicating an address list, + to replicate ALL of its members, including quoted-strings. + +c. ":Include:" specifications are used to refer to one or more + locations containing stored address lists (#address). If + more than one location is referenced, the address part of the + Include phrase must be a list (#address) surrounded by + angle-brackets, as per the "Individual / List" alternative of +
. Constituent addresses must resolve to a host- + +Standard for the Format of Text Messages 18 +IV. Semantics + A. Address Fields + + + + phrase; only they have any meaning within this construct. + The phrase part of indicated host-phrases should contain text + which the referenced host can resolve to a file. This + standard is not a protocol and so does not prescribe HOW data + is to be retrieved from the file. However, the following + requirements are made: + + o The file must be accessible through the local + operating system interface (if it exists), given + adequate user access rights; and + + o If a host has an FTP server and a user is able + to retrieve any files from the host using that + server, then the file must be accessible through + FTP, using DEFAULT transfer settings, given + adequate user access rights. + + It is intended that this mechanism allow programs to retrieve + such lists automatically. + + The interpretation of such a file reference follows. This is + not intended to imply any particular implementation scheme, + but is presented to aid in understanding the notion of + including file contents in address lists: + + o Elements of the address list part are alternates + and the contents of ONLY ONE of them are to be + included in the resultant address list. + + o The contents of the file indicated by a member + host-phrase are treated as an address list and + are inserted as an address list (#address) in + the position of the path item in the syntax. + That is, the TELNET ASCII characters specifying + the entire Include
is replaced by the + contents of one of the files to which the host- + phrase(s), of the address list (#address), + refers. Therefore, the contents of each file, + indicated by an Include address, must be + syntactically self-contained and must adhere to + the full syntax prescribed herein for an address + list. + +d. ":Postal:" specifications are used to indicate (U.S.) postal + addresses, but can be treated the same as quoted-string + addresses. To reference a list of postal addresses, the list + must conform to the "Individual / List" alternative of +
. The ":Include:" alternative also is valid. + +e. The "':' atom ':'" syntax is intended as a general mechanism + for indicating specially data-typed addresses. As with + extension-fields, the authors of this document will regulate + +Standard for the Format of Text Messages 19 +IV. Semantics + A. Address Fields + + + + the publishing of specifications for these extended data- + types. In the absence of defined semantics, any occurrence + of an address in this form may be treated as a quoted-string + address. + +f. A node name must be THE official name of a network or a host, + or else a decimal number indicating the Network address for + that network or host, at the time the message is created. + The USE OF NUMBERS IS STRONGLY DISCOURAGED and is permitted + only due to the occasional necessity of bypassing local name + tables. For the ARPANET, official names are maintained by + the Network Information Center at SRI International, Menlo + Park, California. + + Whenever a message might be transmitted or migrate to a host + on another network, full hierarchical addresses must be + specified. These are indicated as a series of words, + separated by at-sign or "at" indications. The communication + environment is assumed to consist of a collection of networks + organized as independent "trees" except for connections + between the root nodes. That is, only the roots can act as + gateways between these independent networks. While other + actual connections may exist, it is believed that presuming + this type of organization will provide a reliable method for + describing VALID, if not EFFICIENT, paths between hosts. A + typical full mailbox specification might therefore look like: + + Friendly User @ hosta @ local-net1 @ major-netq + + In the simplest case, a mail-sending host should transmit the + message to the node which is mentioned last (farthest to the + right), strip off that node reference from the specification, + and then pass the remaining host-phrase to the recipient host + (in the ARPANET, its FTP server) for it to process. This + treats the remaining portion of the host-indicator merely as + the terminating part of the phrase. + + NOTE: When passing any portion of a host-indicator + onto a process which does not interpret data + according to this standard (e.g., ARPANET + FTP servers), "@" must be used and not "at" + and it must not be preceded or followed by + any LWSP-chars. Using the above example, + the following string would be passed to the + major-netq gateway: + + Friendly User@hosta@local-net1 + + When the sending host has more knowledge of the network + environment, then it should send the message along a more + efficient path, making appropriate changes to the form of the + host-phrase which it gives to the recipient host. + +Standard for the Format of Text Messages 20 +IV. Semantics + A. Address Fields + + + + To use the above specification as an example: If a sending + hostb also were part of local-net1, then it could send the + message directly to hosta and would give only the phrase + "Friendly User" to hosta's mail-receiving program. If hostb + were part of local-net2, along with hostc, and happened to + know that hosta and hostc were part of another local-net, + then hostb could send the message to hostc to the address + "Friendly User@hosta". + + The phrase in a host-phrase is intended to be meaningful only + to the indicated receiving host. To all other hosts, the + phrase is to be treated as an uninterpreted string. No case + transformations should be (automatically) performed on the + phrase. The phrase is passed to the local host's mail + sending program; it is the responsibility of the destination + host's mail receiving (distribution) program to perform case + mapping on this phrase, if required, to deliver the mail. + + +2. Originator Fields + + WARNING: The standard allows only a subset of the + combinations possible with the From, Sender, + and Reply-To fields. The limitation is + intentional. + +a. 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 machine address, indicating + the AGENT (person or process) entering the message. If this + is NOT done, the "Sender" field MUST be present; if this IS + done, the "Sender" field is optional. + +b. Sender + + This field contains the identity of the AGENT (person or + process) who sends the message. It is intended for use when + the sender is not the author of the message, 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 host-phrase includes a phrase 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 or process) responsible for sending the + +Standard for the Format of Text Messages 21 +IV. Semantics + A. Address Fields + + + + 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 phrase + part of the host-phrase, 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. + + Since the critical function served by the "Sender" field is + the identification of the agent responsible for sending mail + and since computer programs cannot be held accountable for + their behavior, is strongly recommended that when a computer + program generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field + host-phrase. + +c. 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 + mailboxes 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, + responses; responders should send their replies to the + "Reply-To" mailbox(es) listed in the original message. 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. + + Reply-To fields are NOT required to contain any machine + addresses (i.e., host-phrases). Note, however, that the + absence of even one valid network address will tend to + prevent software systems from automatically assisting users + in conveniently responding to mail. + +NOTE: For systems which automatically generate address lists for +replies to messages, the following recommendations are made: + + o The receiver, when replying to a message, should + NEVER automatically include the "Sender" host-phrase + in the reply's address list; + + o If the "Reply-To" field exists, then the reply + should go ONLY to the addresses indicated in that + field and not to the addresses indicated in the + "From" field. + +Standard for the Format of Text Messages 22 +IV. Semantics + A. Address Fields + + + +(Extensive examples are provided in Section V.) This +recommendation is intended only for originator-fields and is not +intended to suggest that replies should not also be sent to the +other recipients of this message. It is up to the respective +mail handling programs to decide what additional facilities will +be provided. + + +3. Receiver Fields + +a. To + + This field contains the identity of the primary recipients of + the message. + +b. cc + + This field contains the identity of the secondary recipients + of the message. + +b. 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 + recipients. 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. + + + +B. REFERENCE SPECIFICATION FIELDS + + +1. Message-ID + +This field contains a unique identifier (the phrase) 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 each receive a new message identifier. + + +2. In-Reply-To + +The contents of this field identify previous correspondence which +this message answers. Note that if message identifiers are used +in this field, they must use the mach-id specification format. + + +Standard for the Format of Text Messages 23 +IV. Semantics + B. Reference Specification Fields + + + +3. References + +The contents of this field identify other correspondence which +this message references. Note that if message identifiers +are used, they must use the mach-id specification format. + + +4. Keywords + +This field contains keywords or phrases, separated by commas. + + + +C. OTHER FIELDS AND SYNTACTIC ITEMS + + +1. Subject + +The "Subject" field is intended to provide as much information as +necessary to adequately summarize or indicate the nature of the +message. + + +2. Comments + +Permits adding text comments onto the message without disturbing +the contents of the message's body. + + +3. Extension-field + +A relatively limited number of common fields have been defined in +this document. As network mail requirements dictate, additional +fields may be standardized. The authors of this document will +regulate the publishing of such definitions as extensions to the +basic specification. + + +4. 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. + + + + +Standard for the Format of Text Messages 24 +IV. Semantics + D. Dates + + + +D. DATES AND TIMES + +If included, day-of-week must be the day implied by the date +specification. + +Time zone may be indicated in several ways. The military +standard uses a single character for each zone. "Z" is +Greenwhich Mean Time; "A" indicates one hour earlier, and "M" +indicates 12 hours earlier; "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 GMT; the other +uses common 3-character strings for indicating time zones in +North America. + + +Standard for the Format of Text Messages 25 +V. Examples +A. Addresses + + + + + + V. EXAMPLES + + +A. ADDRESSES + + +1. Alfred E. Neuman + +2. Neuman@BBN-TENEXA + +These two "Alfred E. Neuman" examples have identical semantics, +as far as the operation of the local host's mail sending +(distribution) program (also sometimes called its "mailer") and +the remote host's FTP server are concerned. In the first +example, the "Alfred E. Neuman" is ignored by the mailer, as +"Neuman at BBN-TENEXA" completely specifies the recipient. The +second example contains no superfluous information, and, again, +"Neuman@BBN-TENEXA" is the intended recipient. + + +3. Al Neuman at BBN-TENEXA + +This is identical to "Al Neuman ". That +is, the full phrase, "Al Neuman", is passed to the FTP server. +Note that not all FTP servers accept multi-word identifiers; and +some that do accept them will treat each word as a different +addressee (in this case, attempting to send a copy of the message +to "Al" and a copy to "Neuman"). + + +4. "George Lovell, Ted Hackle" + +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, as "Shared-Mailbox at Office-1" +completely specifies the destination mailbox. + + +4. Wilt (the Stilt) Chamberlain at NBA + +The "(the Stilt)" is a comment, which is NOT included in the +destination mailbox address handed to the originating system's +mailer. The address is the string "Wilt Chamberlain", with +exactly one space between the first and second words. (The +quotation marks are not included.) + + + + +Standard for the Format of Text Messages 26 +V. Examples +B. Address Lists + + + +B. ADDRESS LISTS + + Gourmets: Pompous Person , + Cooks: Childs at WGBH, Galloping Gourmet at + ANT (Australian National Television);, + Wine Lovers: Cheapie at Discount-Liquors, + Port at Portugal;;, + Jones at SEA + +This group list example points out the use of comments, the +nesting of groups, and the mixing of addresses and groups. Note +that the two consecutive semi-colons preceding "Jones at SEA" +mean that Jones is NOT a member of the Gourmets group. + + +C. ORIGINATOR ITEMS + + +1. Author-sent + +George Jones logs into his Host as "Jones". He sends mail +himself. + + From: Jones at Host +or + From: George Jones + + +2. Secretary-sent + +George Jones logs in as Jones on his Host. His secretary, who +logs in as Secy on Shost sends mail for him. Replies to the mail +should go to George, of course. + + From: George Jones + Sender: Secy at SHost + + +3. Shared directory or unrepresentative directory-name + +George Jones logs in as Group at Host. He sends mail himself; +replies should go to the Group mailbox. + + From: George Jones + + + +Standard for the Format of Text Messages 27 +V. Examples +C. Originator Items + + + +4. Secretary-sent, for user of shared directory + +George Jones' secretary sends mail for George in his capacity as +a member of Group while logged in as Secy at Host. Replies +should go to Group. + + From: George Jones + Sender: Secy at Host + +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). + + +5. Secretary acting as full agent of author + +George Jones asks his secretary (Secy at Host) to send a message +for him in his capacity as Group. He wants his secretary to +handle all replies. + + From: George Jones + Sender: Secy at Host + Reply-To: Secy at Host + + +6. Agent for user without online mailbox + +A non-ARPANET user friend of George's, Sarah, is visting. +George's secretary sends some mail to a friend of Sarah in +computer-land. Replies should go to George, whose mailbox is +Jones at Host. + + From: Sarah Friendly + Sender: Secy at Host + Reply-To: Jones at Host + + +7. Sent by member of a committee + +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 at Host + Reply-To: Big-committee: Jones at Host, + Smith at Other-Host, + Doe at Somewhere-Else; + +Note that if George had not included himself in the enumeration +of Big-committee, he would not have gotten an implicit reply; the +presence of the "Reply-to" field SUPERSEDES the sending of a +reply to the person named in the "From" field. + +Standard for the Format of Text Messages 28 +V. Examples +C. Originator Items + + + +8. Example of INCORRECT use + +George desires a reply to go to his secretary; therefore his +secretary leaves his mailbox address off the "From" field, +leaving only his name, which is not, itself, a mailbox address. + + From: George Jones + Sender: Secy at SHost + +THIS IS NOT PERMITTED. Replies are NEVER implicitly sent to the +"Sender"; George's secretary should have used the "Reply-To" +field, or the mail creating program should have forced the +secretary to. + +9. Agent for member of a committee + +George's secretary sends out a message which was authored jointly +by all the members of the "Big-committee". + + From: Big-committee: Jones at Host, + Smith at Other-Host, + Doe at Somewhere-Else; + Sender: Secy at SHost + + + +D. COMPLETE HEADERS + + +1. Minimum required: + + Date: 26 August 1976 1429-EDT + From: Jones at Host + + +2. Using some of the additional fields: + + Date: 26 August 1976 1430-EDT + From:George Jones + Sender:Secy at SHOST + To:Al Neuman at Mad-Host, + Sam Irving at Other-Host + Message-ID: + + + +Standard for the Format of Text Messages 29 +V. Examples +D. Complete Headers + + + +3. About as complex as you're going to get: + + Date : 27 Aug 1976 0932-PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy at Other-Host + Reply-To : Sam Irving at Other-Host + To : George Jones , + Al Neuman at Mad-Host + cc : Important folk: + Tom Softwood , + Sam Irving at Other-Host;, + Standard Distribution::Include: + standard.dist.3" at Tops-20-Host>, + (The following Included Postal list is part + of Standard Distribution.) + :Postal::Include: Non-net-addrs@Other-host;, + :Postal: "Sam Irving, P.O. Box 001, Las Vegas, + Nevada" (So that he can stay + apprised of the situation) + 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: + Special (action): This is a sample of multi-word field- + names, using a range of characters. There + could also be a field-name "Special (info)". + Message-ID: <4231.629.XYzi-What at Other-Host> + + +Standard for the Format of Text Messages 31 +Appendix +A. Alphabetical Listing of Syntax Rules + + + + + + APPENDIX + + + +A. ALPHABETICAL LISTING OF SYNTAX RULES + + +address = host-phrase / quoted-string + / (*phrase "<" #address ">" ) + / (*phrase ":" #address ";" ) + / (":" ("Include" / "Postal" / atom) ":" address) +ALPHA = +atom = 1* + +CHAR = +comment = "(" *(ctext / comment / quoted-pair) ")" +CR = +CRLF = CR LF +ctext = +CTL = + +date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT) +date-field = "Date" ":" date-time +date-time = [ day-of-week "," ] date time +day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue" + / "Wednesday" / "Wed" / "Thursday" / "Thu" + / "Friday" / "Fri" / "Saturday" / "Sat" + / "Sunday" / "Sun" +delimiters = specials / comment / linear-white-space +DIGIT = + +extension-field = + +field = field-name ":" [ field-body ] CRLF + +fields = date-field originator-fields *optional-field +field-body = field-body-contents + [CRLF LWSP-char field-body] +field-body-contents = +field-name = fnatom *(LWSP-char [fnatom]) +fnatom = 1* + + +Standard for the Format of Text Messages 32 +Appendix +A. Alphabetical Listing of Syntax Rules + + + +host-indicator = 1*( ("at" / "@") node ) +host-phrase = phrase host-indicator +hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ] +HTAB = + +LF = +linear-white-space = 1*([CRLF] LWSP-char) +LWSP-char = SPACE / HTAB + +mach-id = "<" host-phrase ">" +mailbox = host-phrase / (phrase mach-id) +message = fields *(CRLF *text) +month = "January" / "Jan" / "February" / "Feb" + / "March" / "Mar" / "April" / "Apr" + / "May" / "June" / "Jun" + / "July" / "Jul" / "August" / "Aug" + / "September" / "Sep" / "October" / "Oct" + / "November" / "Nov" / "December" / "Dec" + +node = word / 1*DIGIT + +optional-field = + "To" ":" #address + / "cc" ":" #address + / "bcc" ":" #address + / "Subject" ":" *text + / "Comments" ":" *text + / "Message-ID" ":" mach-id + / "In-Reply-To"":" #(phrase / mach-id) + / "References" ":" #(phrase / mach-id) + / "Keywords" ":" #phrase + / extension-field + / user-defined-field +originator-fields = + ( "From" ":" mailbox + ["Reply-To" ":" #address] ) + / ( "From" ":" 1#address + "Sender" ":" mailbox + ["Reply-To" ":" #address] ) + +phrase = 1*word + +quoted-pair = "\" CHAR +quoted-string = <"> *(qtext / quoted-pair) <"> +qtext = , CR, or LF and including + linear-white-space> +SPACE = +specials = "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":" + / "\" / <"> + +text = + +Standard for the Format of Text Messages 33 +Appendix +A. Alphabetical Listing of Syntax Rules + + + +time = hour zone + +user-defined-field = + +word = atom / quoted-string + +zone = ( ("+" / "-") 4DIGIT ) + / ( ["-"] (1ALPHA + / "GMT" / "NST" / "AST" / "ADT" / "EST" / "EDT" + / "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT" + / "YST" / "YDT" / "HST" / "HDT" / "BST" / "BDT" )) + +<"> = + + +Standard for the Format of Text Messages 35 +Appendix +B. Simple Parsing + + + + +B. SIMPLE 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: + + - Header fields from the message body, + - Beginnings of fields from lines which continue fields, + - Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will +suffice for this purpose. They describe a limited view of +messages and are a subset of the syntactic rules provided in the +main part of this specification. One small exception is that the +contents of field-bodies consist only of text: + + +SYNTAX: + +message = *field *(CRLF *text) + +field = field-name ":" [field-body] CRLF + +field-name = fnatom *( LWSP-char [fnatom] ) + +fnatom = 1* + + +field-body = *text [CRLF LWSP-char field-body] + + +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), each separated by one or more SPACES or HTABS. +A field-name MUST be contained on one line. Upper and lower case +are not distinguished when comparing field-names. + + +Standard for the Format of Text Messages 37 +Bibliography + + + + + + + BIBLIOGRAPHY + + +ANSI. Representations of universal time, local time + differentials, and United States time zone references for + information interchange. ANSI X3.51-1975; American National + Standards Institute: New York, 1975. + +Bhushan, A.K. The File Transfer Protocol. ARPANET Request for + Comments, No. 354, Network Information Center No. 10596; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, July 1972. + +Bhushan, A.K. Comments on the File Transfer Protocol. ARPANET + Request for Comments, No. 385, Network Information Center No. + 11357; Augmentation Research Center, Stanford Research + Institute: Menlo Park, August 1972. + +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; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, September 1973. + +Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook. + Network Information Center No. 7104; Augmentation Research + Center, Stanford Research Institute: Menlo Park, April 1976. + (NTIS AD A003890). + +McKenzie, A. File Transfer Protocol. ARPANET Request for + Comments, No. 454, Network Information Center No. 14333; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, February 1973. + +McKenzie, A. TELNET Protocol Specification. Network Information + Center No. 18639; Augmentation Research Center, Stanford + Research Institute: Menlo Park, August 1973. + +Myer, T.H. and Henderson, D.A. Message Transmission Protocol. + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116; Augmentation Research Center, Stanford + Research Institute: Menlo Park, 1975. + +Neigus, N. File Transfer Protocol. ARPANET Request for + Comments, No. 542, Network Information Center No. 17759; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, July 1973. + +Pogran, K., Vittal, J., Crocker, D. and Henderson, A. Proposed + official standard for the format of ARPA network messages. + +Standard for the Format of Text Messages 38 +Bibliography + + + + + ARPANET Request for Comments, No. 724, Network Information + Center No. 37435; Augmentation Research Center, Stanford + Research Institute: Menlo Park, May 1977. + +Postel, J.B. Revised FTP Reply Codes. ARPANET Request for + Comments, No. 640, Network Information Center No. 30843; + Augmentation Research Center, Stanford Research Institute: + Menlo Park, June 1974. + \ No newline at end of file -- cgit v1.2.3