Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
Obsoleted by:822 UNKNOWN
RFC # 733NIC # 41952Obsoletes: RFC #561 (NIC #18516) RFC #680 (NIC #32116) RFC #724 (NIC #37435) STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES(1) 21 November 1977by 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 ResearchProjects 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 RandCorporation, Information Sciences Dept., 1700 Main St., SantaMonica, California 90406; J. Vittal & D. A. Henderson, BoltBeranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138;and K. Pogran, MIT Laboratory for Computer Science, 545Technology 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 ARPANetwork text message (mail) headers which will reasonably meetthe needs of the various message service subsystems on theNetwork today. The authors of this document constitute theCAHCOM subcommittee charged with the task of developing this newstandard. Essentially, we specify a revision to ARPANET Request forComments (RFC)561, "Standardizing Network Mail Headers", and RFC680, "Message Transmission Protocol". This revision removes andcompacts portions of the previous syntax and adds severalfeatures to network address specification. In particular, wefocus on people and not mailboxes as recipients and allowreference to stored address lists. We expect this syntax toprovide sufficient capabilities to meet most users' immediateneeds and, therefore, give developers enough breathing room toproduce a new mail transmission protocol "properly". We believethat there is enough of a consensus in the Network community infavor of such a standard syntax to make possible its adoption atthis time. An earlier draft of this specification was publishedas RFC #724, "Proposed Official Standard for the Format of ARPANetwork Messages" and contained extensive discussion of thebackground and issues in ARPANET mail standards. This specification was developed over the course of oneyear, using the ARPANET mail environment, itself, to provide anon-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 acknowledgetheir considerable efforts. The syntax of the standard wasoriginally specified in the Backus-Naur Form (BNF) meta-language.Ken L. Harrenstien, of SRI International, was responsible forre-coding the BNF into an augmented BNF which compacts thespecification and allows increased comprehensibility.
-v- CONTENTSPREFACE.....................................................iiiSectionI. INTRODUCTION.........................................1 II. FRAMEWORK............................................2 III. SYNTAX...............................................4A. Notational Conventions............................4B. Lexical Analysis of Messages......................5C. General Syntax of Messages........................13D. Syntax of General Addressee Items.................15E. Supporting Constructs.............................15 IV. SEMANTICS............................................17A. Address Fields....................................17B. Reference Specification Fields....................22C. Other Fields and Syntactic Items..................23D. Dates and Times...................................24V. EXAMPLES.............................................25A. Addresses.........................................25B. Address Lists.....................................26C. Originator Items..................................26D. Complete Headers..................................28AppendixA. ALPHABETICAL LISTING OF SYNTAX RULES.................31B. SIMPLE PARSING.......................................35BIBLIOGRAPHY................................................37
Standard for the Format of Text Messages 1I. Introduction I. INTRODUCTION This standard specifies a syntax for text messages which arepassed between computer users within the framework of "electronicmail". The standard supersedes the informal standards specifiedin ARPANET Request for Comments numbers 561, "StandardizingNetwork Mail Headers", and 680, "Message Transmission Protocol".In this document, a general framework is first described; theformal syntax is then specified, followed by a discussion of thesemantics. Finally, a number of examples are given. This specification is intended strictly as a definition ofwhat is to be passed between hosts on the ARPANET. It is NOTintended to dictate either features which systems on the Networkare expected to support, or user interfaces to message creatingor reading programs. A distinction should be made between what the specificationREQUIRES and what it ALLOWS. Messages can be made complex andrich with formally-structured components of information or can bekept small and simple, with a minimum of such information. Also,the standard simplifies the interpretation of differing visualformats in messages. These simplifications facilitate the formalspecification and indicate what the OFFICIAL semantics are formessages. Only the visual aspect of a message is affected andnot the interpretation of information within it. Implementorsmay choose to retain such visual distinctions.
Standard for the Format of Text Messages 2II. Framework II. FRAMEWORK Since there are many message systems which exist outside theARPANET environment, as well as those within it, it may be usefulto consider the general framework, and resulting capabilities andlimitations, provided by this standard. Messages are expected to consist of lines of text. Nospecial provisions are made, at this time, for encoding drawings,facsimile, speech, or structured text. No significant consideration has been given to questions ofdata compression or transmission/storage efficiency. Thestandard, in fact, tends to be very free with the number of bitsconsumed. For example, field names are specified as free text,rather than special terse codes. A general "memo" framework is used. That is, a messageconsists of some information, in a rigid format, followed by themain part of the message, which is text and whose format is notspecified in this document. The syntax of several fields of therigidly-formated ("header") section is defined in thisspecification; some of the header fields must be included in allmessages. The syntax which distinguishes between headers isspecified separately from the internal syntax for particularheaders. This separation is intended to allow extremely simpleparsers to operate on the overall structure of messages, withoutconcern for the detailed structure of individual headers.Appendix B is provided to facilitate construction of these simpleparsers. 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 functionalitywhile maintaining a uniform framework. The approach is similarto that of the TELNET protocol, in that a basic standard isdefined which includes a mechanism for (optionally) extendingitself. As necessary, the authors of this document will regulatethe publishing of specifications for these "extension-fields",through the same mechanisms used to publish this document. Such a framework severely constrains document tone andappearance and is primarily useful for most intra-organizationcommunications and relatively structured inter-organizationcommunication. A more robust environment might allow for multi-font, multi-color, multi-dimension encoding of information. Aless robust environment, as is present in most single-machinemessage systems, would more severely constrain the ability to addfields and the decision to include specific fields. In contrastto paper-based communication, it is interesting to note that the
Standard for the Format of Text Messages 3II. FrameworkRECEIVER of a message can exercise an extraordinary amount ofcontrol over the message's appearance. The amount of actualcontrol available to message receivers is contingent upon thecapabilities of their individual message systems.
Standard for the Format of Text Messages 4III. Syntax III. SYNTAX This syntax is given in five parts. The first partdescribes the notation used in the specification. The secondpart describes the base-level lexical analyzers which feed thehigher-level parser described in the succeeding sections. Thethird part gives a general syntax for messages and standardheader fields; and the fourth part specifies the syntax ofaddresses. A final part specifies some general syntax whichsupports the other sections.A. NOTATIONAL CONVENTIONSThese specifications are made in an augmented Backus-Naur Form(BNF). Differences from standard BNF involve the naming ofrules, the indication of repetition and of "local" alternatives.1. Rule namingAngle brackets ("<", ">") are not used, in general. The name ofa rule is simply the name itself, rather than "<name>".Quotation-marks enclose literal text (which may be upper and/orlower case). Certain basic rules are in uppercase, such asSPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used inrule definitions, and in the rest of this document, whenevertheir presence will facilitate discerning the use of rule names.2. Parentheses:Local alternativesElements enclosed in parentheses are treated as a single element.Thus, "(elem (foo / bar) elem)" allows "(elem foo elem)" and"(elem bar elem)".3. * construct:RepetitionThe character "*" preceding an element indicates repetition. Thefull form is: <l>*<m>elementindicating at least <l> and at most <m> occurrences of element.Default values are 0 and infinity so that "*(element)" allows anynumber, including zero; "1*element" requires at least one; and"1*2element" allows one or two.
Standard for the Format of Text Messages 5III. Syntax A. Notational Conventions4. <number>element"<n>(element)" is equivalent to "<n>*<n>(element)"; that is,exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digitnumber, and 3ALPHA is a string of three alphabetic characters.5. # construct:ListsA construct "#" is defined, similar to "*", as follows: <l>#<m>elementindicating at least <l> and at most <m> elements, each separatedby one or more commas (","). This makes the usual form of listsvery easy; a rule such as '(element *("," element))' can be shownas "1#element". Wherever this construct is used, null elementsare allowed, but do not contribute to the count of elementspresent. That is, "(element),,(element)" is permitted, butcounts as only two elements. Therefore, where at least oneelement is required, at least one non-null element must bepresent.6. [optional]Square brackets enclose optional elements; "[foo bar]" isequivalent to "*1(foo bar)".7. ; CommentsA semi-colon, set off some distance to the right of rule text,starts a comment which continues to the end of line. This is asimple way of including useful notes in parallel with thespecifications.B. LEXICAL ANALYSIS OF MESSAGES1. General DescriptionA message consists of headers and, optionally, a body (i.e. aseries of text lines). The text part is just a sequence of linescontaining ASCII characters; it is separated from the headers bya null line (i.e., a line with nothing preceding the CRLF).
Standard for the Format of Text Messages 6III. Syntax B. Lexical Analysisa. 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" <ddd at Host>, JJV at BBN can be represented as To: "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN and To: "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN and To: "Joe Dokes & J. Harvey" <ddd at Host>, 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 7III. 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 8III. 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 WBA2. Formal DefinitionsThe first four rules, below, indicate a meta-syntax for fields,without regard to their particular type or internal syntax. Theremaining rules define basic syntactic structures which are usedby the rules in Sections III.C, III.D, and III.E.field = field-name ":" [ field-body ] CRLFfield-name = fnatom *( LWSP-char [fnatom] )
Standard for the Format of Text Messages 9III. Syntax B. Lexical Analysisfnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">field-body = field-body-contents [CRLF LWSP-char field-body]field-body-contents = <the TELNET 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> ; ( Octal, Decimal.)CHAR = <any TELNET ASCII character> ; ( 0-177, 0.-127.)ALPHA = <any TELNET ASCII alphabetic character> ; (101-132, 65.- 90.) ; (141-172, 97.-122.)DIGIT = <any TELNET ASCII digit> ; ( 60- 71, 48.- 57.)CTL = <any TELNET ASCII control ; ( 0- 37, 0.- 31.) character and DEL> ; ( 177, 127.)CR = <TELNET ASCII carriage return>;( 15, 13.)LF = <TELNET ASCII linefeed> ; ( 12, 10.)SPACE = <TELNET ASCII space> ; ( 40, 32.)HTAB = <TELNET ASCII horizontal-tab>; ( 11, 9.)<"> = <TELNET ASCII quote mark> ; ( 42, 34.)CRLF = CR LFLWSP-char = SPACE / HTAB ; semantics = SPACElinear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE ; CRLF => foldingspecials = "(" / ")" / "<" / ">" / "@" ; To use in a word, / "," / ";" / ":" / "\" / <"> ; word must be a ; quoted-string.delimiters = specials / comment / linear-white-spacetext = <any CHAR, including bare ; => atoms, specials, CR and/or bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT interpreted.atom = 1*<any CHAR except specials and CTLs>quoted-string = <"> *(qtext/quoted-pair) <">; Any number of qtext ; chars or any ; quoted char.qtext = <any CHAR excepting <"> ; => may be folded and CR, and including linear-white-space>
Standard for the Format of Text Messages 10III. Syntax B. Lexical Analysiscomment = "(" *(ctext / comment / quoted-pair) ")"ctext = <any CHAR excluding "(", ; => may be folded ")" and CR, and including linear-white-space>quoted-pair = "\" CHAR3. Clarificationsa. "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 <DELIMITER>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 <null>, 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 11III. 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 12III. Syntax B. Lexical Analysisd. 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 ":"<atom>":" 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 13III. 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 bethought 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 thanone line in the actual transmitted message.
Standard for the Format of Text Messages 14III. Syntax C. Messagesmessage = fields *( CRLF *text ) ; Everything after ; first null line ; is message bodyfields = date-field ; Creation time-stamp originator-fields ; & author id are *optional-field ; required: others ; are all optionaloriginator-fields = ( "From" ":" mailbox ; Single author ["Reply-To" ":" #address] ) / ( "From" ":" 1#address ; Multiple authors & "Sender" ":" mailbox ; may have non-mach- ["Reply-To" ":" #address] ); ine addressesdate-field = "Date" ":" date-timeoptional-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-emptedextension-field = <Any field which is defined in a document published as a formal extension to this specification>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 preempted by published extensions>
Standard for the Format of Text Messages 15III. Syntax D. Addressee ItemsD. SYNTAX OF GENERAL ADDRESSEE ITEMSaddress = 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 CONSTRUCTShost-phrase = phrase host-indicator ; Basic addresshost-indicator = 1*( ("at" / "@") node ) ; Right-most node is ; at top of network ; hierarchy; left- ; most must be hostnode = word / 1*DIGIT ; Official host or ; network name or ; decimal addressdate-time = [ day-of-week "," ] date timeday-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]77month = "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 16III. Syntax E. Supporting Constructstime = 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 = SPACEword = atom / quoted-string
Standard for the Format of Text Messages 17IV. Semantics A. Address Fields IV. SEMANTICSA. ADDRESS FIELDS1. Generala. 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 <address>. Constituent addresses must resolve to a host-
Standard for the Format of Text Messages 18IV. 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 <address> 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 <address>. 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 19IV. 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 20IV. 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 21IV. 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 forreplies 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 22IV. Semantics A. Address Fields(Extensive examples are provided in Section V.) Thisrecommendation is intended only for originator-fields and is notintended to suggest that replies should not also be sent to theother recipients of this message. It is up to the respectivemail handling programs to decide what additional facilities willbe provided.3. Receiver Fieldsa. 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 FIELDS1. Message-IDThis field contains a unique identifier (the phrase) which refersto THIS version of THIS message. The uniqueness of the messageidentifier is guaranteed by the host which generates it. Thisidentifier is intended to be machine readable and not necessarilymeaningful to humans. A message identifier pertains to exactlyone instantiation of a particular message; subsequent revisionsto the message should each receive a new message identifier.2. In-Reply-ToThe contents of this field identify previous correspondence whichthis message answers. Note that if message identifiers are usedin this field, they must use the mach-id specification format.
Standard for the Format of Text Messages 23IV. Semantics B. Reference Specification Fields3. ReferencesThe contents of this field identify other correspondence whichthis message references. Note that if message identifiersare used, they must use the mach-id specification format.4. KeywordsThis field contains keywords or phrases, separated by commas.C. OTHER FIELDS AND SYNTACTIC ITEMS1. SubjectThe "Subject" field is intended to provide as much information asnecessary to adequately summarize or indicate the nature of themessage.2. CommentsPermits adding text comments onto the message without disturbingthe contents of the message's body.3. Extension-fieldA relatively limited number of common fields have been defined inthis document. As network mail requirements dictate, additionalfields may be standardized. The authors of this document willregulate the publishing of such definitions as extensions to thebasic specification.4. User-defined-fieldIndividual users of network mail are free to define and useadditional header fields. Such fields must have names which arenot already used in the current specification or in anydefinitions of extension-fields, and the overall syntax of theseuser-defined-fields must conform to this specification's rulesfor delimiting and folding fields. Due to the extension-fieldpublishing process, the name of a user-defined-field may be pre-empted.
Standard for the Format of Text Messages 24IV. Semantics D. DatesD. DATES AND TIMESIf included, day-of-week must be the day implied by the datespecification.Time zone may be indicated in several ways. The militarystandard uses a single character for each zone. "Z" isGreenwhich Mean Time; "A" indicates one hour earlier, and "M"indicates 12 hours earlier; "N" is one hour later, and "Y" is 12hours later. The letter "J" is not used. The other remainingtwo forms are taken from ANSI standard X3.51-1975. One allowsexplicit indication of the amount of offset from GMT; the otheruses common 3-character strings for indicating time zones inNorth America.
Standard for the Format of Text Messages 25V. ExamplesA. Addresses V. EXAMPLESA. ADDRESSES1. Alfred E. Neuman <Neuman at BBN-TENEXA>2. Neuman@BBN-TENEXAThese 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") andthe remote host's FTP server are concerned. In the firstexample, the "Alfred E. Neuman" is ignored by the mailer, as"Neuman at BBN-TENEXA" completely specifies the recipient. Thesecond example contains no superfluous information, and, again,"Neuman@BBN-TENEXA" is the intended recipient.3. Al Neuman at BBN-TENEXAThis is identical to "Al Neuman <Al Neuman at BBN-TENEXA>". Thatis, the full phrase, "Al Neuman", is passed to the FTP server.Note that not all FTP servers accept multi-word identifiers; andsome that do accept them will treat each word as a differentaddressee (in this case, attempting to send a copy of the messageto "Al" and a copy to "Neuman").4. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1>This form might be used to indicate that a single mailbox isshared by several users. The quoted string is ignored by theoriginating host's mailer, as "Shared-Mailbox at Office-1"completely specifies the destination mailbox.4. Wilt (the Stilt) Chamberlain at NBAThe "(the Stilt)" is a comment, which is NOT included in thedestination mailbox address handed to the originating system'smailer. The address is the string "Wilt Chamberlain", withexactly one space between the first and second words. (Thequotation marks are not included.)
Standard for the Format of Text Messages 26V. ExamplesB. Address ListsB. ADDRESS LISTS Gourmets: Pompous Person <WhoZiWhatZit at Cordon-Bleu>, Cooks: Childs at WGBH, Galloping Gourmet at ANT (Australian National Television);, Wine Lovers: Cheapie at Discount-Liquors, Port at Portugal;;, Jones at SEAThis group list example points out the use of comments, thenesting of groups, and the mixing of addresses and groups. Notethat the two consecutive semi-colons preceding "Jones at SEA"mean that Jones is NOT a member of the Gourmets group.C. ORIGINATOR ITEMS1. Author-sentGeorge Jones logs into his Host as "Jones". He sends mailhimself. From: Jones at Hostor From: George Jones <Jones at Host>2. Secretary-sentGeorge Jones logs in as Jones on his Host. His secretary, whologs in as Secy on Shost sends mail for him. Replies to the mailshould go to George, of course. From: George Jones <Jones at Host> Sender: Secy at SHost3. Shared directory or unrepresentative directory-nameGeorge Jones logs in as Group at Host. He sends mail himself;replies should go to the Group mailbox. From: George Jones <Group at Host>
Standard for the Format of Text Messages 27V. ExamplesC. Originator Items4. Secretary-sent, for user of shared directoryGeorge Jones' secretary sends mail for George in his capacity asa member of Group while logged in as Secy at Host. Repliesshould go to Group. From: George Jones<Group at Host> Sender: Secy at HostNote that there need not be a space between "Jones" and the "<",but adding a space enhances readability (as is the case in otherexamples).5. Secretary acting as full agent of authorGeorge Jones asks his secretary (Secy at Host) to send a messagefor him in his capacity as Group. He wants his secretary tohandle all replies. From: George Jones <Group at Host> Sender: Secy at Host Reply-To: Secy at Host6. Agent for user without online mailboxA non-ARPANET user friend of George's, Sarah, is visting.George's secretary sends some mail to a friend of Sarah incomputer-land. Replies should go to George, whose mailbox isJones at Host. From: Sarah Friendly Sender: Secy at Host Reply-To: Jones at Host7. Sent by member of a committeeGeorge is a member of a committee. He wishes to have any repliesto 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 enumerationof Big-committee, he would not have gotten an implicit reply; thepresence of the "Reply-to" field SUPERSEDES the sending of areply to the person named in the "From" field.
Standard for the Format of Text Messages 28V. ExamplesC. Originator Items8. Example of INCORRECT useGeorge desires a reply to go to his secretary; therefore hissecretary 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 SHostTHIS 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 thesecretary to.9. Agent for member of a committeeGeorge's secretary sends out a message which was authored jointlyby all the members of the "Big-committee". From: Big-committee: Jones at Host, Smith at Other-Host, Doe at Somewhere-Else; Sender: Secy at SHostD. COMPLETE HEADERS1. Minimum required: Date: 26 August 1976 1429-EDT From: Jones at Host2. Using some of the additional fields: Date: 26 August 1976 1430-EDT From:George Jones<Group at Host> Sender:Secy at SHOST To:Al Neuman at Mad-Host, Sam Irving at Other-Host Message-ID: <some string at SHOST>
Standard for the Format of Text Messages 29V. ExamplesD. Complete Headers3. About as complex as you're going to get: Date : 27 Aug 1976 0932-PDT From : Ken Davis <KDavis at Other-Host> Subject : Re: The Syntax in the RFC Sender : KSecy at Other-Host Reply-To : Sam Irving at Other-Host To : George Jones <Group at Host>, Al Neuman at Mad-Host cc : Important folk: Tom Softwood <Balsa at Another-Host>, Sam Irving at Other-Host;, Standard Distribution::Include: </main/davis/people/standard at Other-Host, "<Jones>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: <some string at SHOST> 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 31AppendixA. Alphabetical Listing of Syntax Rules APPENDIXA. ALPHABETICAL LISTING OF SYNTAX RULESaddress = host-phrase / quoted-string / (*phrase "<" #address ">" ) / (*phrase ":" #address ";" ) / (":" ("Include" / "Postal" / atom) ":" address)ALPHA = <any TELNET ASCII alphabetic character>atom = 1*<any CHAR except specials and CTLs>CHAR = <any TELNET ASCII character>comment = "(" *(ctext / comment / quoted-pair) ")"CR = <TELNET ASCII carriage return>CRLF = CR LFctext = <any CHAR excluding "(", ")", CR, LF and including linear-white-space>CTL = <any TELNET ASCII control character and DEL>date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT)date-field = "Date" ":" date-timedate-time = [ day-of-week "," ] date timeday-of-week = "Monday" / "Mon" / "Tuesday" / "Tue" / "Wednesday" / "Wed" / "Thursday" / "Thu" / "Friday" / "Fri" / "Saturday" / "Sat" / "Sunday" / "Sun"delimiters = specials / comment / linear-white-spaceDIGIT = <any TELNET ASCII digit>extension-field = <Any field which is defined in a document published as a formal extension to this specification>field = field-name ":" [ field-body ] CRLFfields = date-field originator-fields *optional-fieldfield-body = field-body-contents [CRLF LWSP-char field-body]field-body-contents = <the TELNET 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 = fnatom *(LWSP-char [fnatom])fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">
Standard for the Format of Text Messages 32AppendixA. Alphabetical Listing of Syntax Ruleshost-indicator = 1*( ("at" / "@") node )host-phrase = phrase host-indicatorhour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]HTAB = <TELNET ASCII horizontal-tab>LF = <TELNET ASCII linefeed>linear-white-space = 1*([CRLF] LWSP-char)LWSP-char = SPACE / HTABmach-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*DIGIToptional-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-fieldoriginator-fields = ( "From" ":" mailbox ["Reply-To" ":" #address] ) / ( "From" ":" 1#address "Sender" ":" mailbox ["Reply-To" ":" #address] )phrase = 1*wordquoted-pair = "\" CHARquoted-string = <"> *(qtext / quoted-pair) <">qtext = <any CHAR except <">, CR, or LF and including linear-white-space>SPACE = <TELNET ASCII space>specials = "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":" / "\" / <">text = <any CHAR, including bare CR and/or bare LF, but NOT including CRLF>
Standard for the Format of Text Messages 33AppendixA. Alphabetical Listing of Syntax Rulestime = hour zoneuser-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 preempted by putlished extensions>word = atom / quoted-stringzone = ( ("+" / "-") 4DIGIT ) / ( ["-"] (1ALPHA / "GMT" / "NST" / "AST" / "ADT" / "EST" / "EDT" / "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT" / "YST" / "YDT" / "HST" / "HDT" / "BST" / "BDT" ))<"> = <TELNET ASCII quote mark>
Standard for the Format of Text Messages 35AppendixB. Simple ParsingB. SIMPLE PARSING Some mail-reading software systems may wish to perform onlyminimal processing, ignoring the internal syntax of structuredfield-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 willsuffice for this purpose. They describe a limited view ofmessages and are a subset of the syntactic rules provided in themain part of this specification. One small exception is that thecontents of field-bodies consist only of text:SYNTAX:message = *field *(CRLF *text)field = field-name ":" [field-body] CRLFfield-name = fnatom *( LWSP-char [fnatom] )fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">field-body = *text [CRLF LWSP-char field-body]SEMANTICS: Headers occur before the message body and are terminated bya null line (i.e., two contiguous CRLFs). A line which continues a header field begins with a SPACE orHTAB character, while a line beginning a field starts with aprintable 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 caseare not distinguished when comparing field-names.
Standard for the Format of Text Messages 37Bibliography BIBLIOGRAPHYANSI. 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 38Bibliography 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.
[8]ページ先頭