As per Relevance of the word specific, we have this rfc below:
RFC # 733
NIC # 41952
Obsoletes: RFC #561 (NIC #18516)
RFC #680 (NIC #32116)
RFC #724 (NIC #37435)
STANDARD FOR THE FORMAT
ARPA NETWORK TEXT MESSAGES(1)
21 November 1977
David H.
The Rand
John J.
Bolt Beranek and Newman Inc
Kenneth T.
Massachusets Institute of
D. Austin Henderson, Jr.(2)
Bolt Beranek and Newman Inc
_________________________________________________________________
(1)This work was supported by the Defense Advanced
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
Corporation, Information Sciences Dept., 1700 Main St.,
Monica, California 90406; J. Vittal & D. A. Henderson,
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
ARPA's Committee on Computer-Aided Human
(CAHCOM) wishes to promulgate a standard for the format of
Network text message (mail) headers which will reasonably
the needs of the various message service subsystems on
Network today. The authors of this document constitute
CAHCOM subcommittee charged with the task of developing this
standard
Essentially, we specify a revision to ARPANET Request
Comments (RFC) 561, "Standardizing Network Mail Headers", and
680, "Message Transmission Protocol". This revision removes
compacts portions of the previous syntax and adds
features to network address specification. In particular,
focus on people and not mailboxes as recipients and
reference to stored address lists. We expect this syntax
provide sufficient capabilities to meet most users'
needs and, therefore, give developers enough breathing room
produce a new mail transmission protocol "properly". We
that there is enough of a consensus in the Network community
favor of such a standard syntax to make possible its adoption
this time. An earlier draft of this specification was
as RFC #724, "Proposed Official Standard for the Format of
Network Messages" and contained extensive discussion of
background and issues in ARPANET mail standards
This specification was developed over the course of
year, using the ARPANET mail environment, itself, to provide
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
their considerable efforts. The syntax of the standard
originally specified in the Backus-Naur Form (BNF) meta-language
Ken L. Harrenstien, of SRI International, was responsible
re-coding the BNF into an augmented BNF which compacts
specification and allows increased comprehensibility
-v
PREFACE.....................................................
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
A. ALPHABETICAL LISTING OF SYNTAX RULES................. 31
B. SIMPLE PARSING....................................... 35
BIBLIOGRAPHY................................................ 37
Standard for the Format of Text Messages 1
I.
I.
This standard specifies a syntax for text messages which
passed between computer users within the framework of "
mail". The standard supersedes the informal standards
in ARPANET Request for Comments numbers 561, "
Network Mail Headers", and 680, "Message Transmission Protocol".
In this document, a general framework is first described;
formal syntax is then specified, followed by a discussion of
semantics. Finally, a number of examples are given
This specification is intended strictly as a definition
what is to be passed between hosts on the ARPANET. It is
intended to dictate either features which systems on the
are expected to support, or user interfaces to message
or reading programs
A distinction should be made between what the
REQUIRES and what it ALLOWS. Messages can be made complex
rich with formally-structured components of information or can
kept small and simple, with a minimum of such information. Also
the standard simplifies the interpretation of differing
formats in messages. These simplifications facilitate the
specification and indicate what the OFFICIAL semantics are
messages. Only the visual aspect of a message is affected
not the interpretation of information within it.
may choose to retain such visual distinctions
Standard for the Format of Text Messages 2
II.
II.
Since there are many message systems which exist outside
ARPANET environment, as well as those within it, it may be
to consider the general framework, and resulting capabilities
limitations, provided by this standard
Messages are expected to consist of lines of text.
special provisions are made, at this time, for encoding drawings
facsimile, speech, or structured text
No significant consideration has been given to questions
data compression or transmission/storage efficiency.
standard, in fact, tends to be very free with the number of
consumed. For example, field names are specified as free text
rather than special terse codes
A general "memo" framework is used. That is, a
consists of some information, in a rigid format, followed by
main part of the message, which is text and whose format is
specified in this document. The syntax of several fields of
rigidly-formated ("header") section is defined in
specification; some of the header fields must be included in
messages. The syntax which distinguishes between headers
specified separately from the internal syntax for
headers. This separation is intended to allow extremely
parsers to operate on the overall structure of messages,
concern for the detailed structure of individual headers
Appendix B is provided to facilitate construction of these
parsers. In addition to the fields specified in this document
it is expected that other fields will gain common use. User
defined header fields allow systems to extend their
while maintaining a uniform framework. The approach is
to that of the TELNET protocol, in that a basic standard
defined which includes a mechanism for (optionally)
itself. As necessary, the authors of this document will
the publishing of specifications for these "extension-fields",
through the same mechanisms used to publish this document
Such a framework severely constrains document tone
appearance and is primarily useful for most intra-
communications and relatively structured inter-
communication. A more robust environment might allow for multi
font, multi-color, multi-dimension encoding of information.
less robust environment, as is present in most single-
message systems, would more severely constrain the ability to
fields and the decision to include specific fields. In
to paper-based communication, it is interesting to note that
Standard for the Format of Text Messages 3
II.
RECEIVER of a message can exercise an extraordinary amount
control over the message's appearance. The amount of
control available to message receivers is contingent upon
capabilities of their individual message systems
Standard for the Format of Text Messages 4
III.
III.
This syntax is given in five parts. The first
describes the notation used in the specification. The
part describes the base-level lexical analyzers which feed
higher-level parser described in the succeeding sections.
third part gives a general syntax for messages and
header fields; and the fourth part specifies the syntax
addresses. A final part specifies some general syntax
supports the other sections
A. NOTATIONAL
These specifications are made in an augmented Backus-Naur
(BNF). Differences from standard BNF involve the naming
rules, the indication of repetition and of "local" alternatives
1. Rule
Angle brackets ("<", ">") are not used, in general. The name
a rule is simply the name itself, rather than "".
Quotation-marks enclose literal text (which may be upper and/
lower case). Certain basic rules are in uppercase, such
SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
rule definitions, and in the rest of this document,
their presence will facilitate discerning the use of rule names
2. Parentheses: Local
Elements enclosed in parentheses are treated as a single element
Thus, "(elem (foo / bar) elem)" allows "(elem foo elem)"
"(elem bar elem)".
3. * construct:
The character "*" preceding an element indicates repetition.
full form is
*
indicating at least and at most occurrences of element
Default values are 0 and infinity so that "*(element)" allows
number, including zero; "1*element" requires at least one;
"1*2element" allows one or two
Standard for the Format of Text Messages 5
III.
A. Notational
4.
"(element)" is equivalent to "*(element)"; that is
exactly occurrences of (element). Thus 2DIGIT is a 2-
number, and 3ALPHA is a string of three alphabetic characters
5. # construct:
A construct "#" is defined, similar to "*", as follows
#
indicating at least and at most elements, each
by one or more commas (","). This makes the usual form of
very easy; a rule such as '(element *("," element))' can be
as "1#element". Wherever this construct is used, null
are allowed, but do not contribute to the count of
present. That is, "(element),,(element)" is permitted,
counts as only two elements. Therefore, where at least
element is required, at least one non-null element must
present
6. [optional
Square brackets enclose optional elements; "[foo bar]"
equivalent to "*1(foo bar)".
7. ;
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
simple way of including useful notes in parallel with
specifications
B. LEXICAL ANALYSIS OF
1. General
A message consists of headers and, optionally, a body (i.e.
series of text lines). The text part is just a sequence of
containing ASCII characters; it is separated from the headers
a null line (i.e., a line with nothing preceding the CRLF).
Standard for the Format of Text Messages 6
III.
B. Lexical
a. Folding and unfolding of
Each header item can be viewed as a single, logical line
ASCII characters. For convenience, the field-body portion
this conceptual entity can be split into a multiple-
representation (i.e., "folded"). The general rule is
wherever there can be linear-white-space (NOT simply LWSP
chars), a CRLF immediately followed by AT LEAST one LWSP-
can instead be inserted. (However, a header's name and
following colon (":"), which occur at the beginning of
header item, may NOT be folded onto multiple lines.) Thus
the single
To: "Joe Dokes & J. Harvey" , JJV at
can be represented
To: "Joe Dokes & J. Harvey" ,
JJV at
To: "Joe Dokes & J. Harvey
,
JJV at
To: "Joe
& J. Harvey" , JJV at
The process of moving from this folded multiple-
representation of a header field to its single
representation will be called "unfolding". Unfolding
accomplished by regarding CRLF immediately followed by
LWSP-char as equivalent to the LWSP-char
b. Structure of header
Once header fields have been unfolded, they may be viewed
being composed of a field-name followed by a colon (":"),
followed by a field-body. The field-name must be composed
printable ASCII characters (i.e., characters which
values between 33. and 126., decimal, except colon)
LWSP-chars. The field-body may be composed of any
characters (other than an unquoted CRLF, which has
removed by unfolding).
Certain field-bodies of header fields may be
according to an internal syntax which some systems may
to parse. These fields will be referred to as "structured
fields. Examples include fields containing dates
Standard for the Format of Text Messages 7
III.
B. Lexical
addresses. Other fields, such as "Subject" and "Comments",
are regarded simply as strings of text
NOTE: Field-names, unstructured field bodies and
field bodies each are scanned by their own,
"lexical" analyzer
c. Field-
To aid in the creation and reading of field-names, the
insertion of LWSP-chars is allowed in reasonable places
Rather than obscuring the syntax specification for field-
with the explicit syntax for these LWSP-chars, the
of a "lexical" analyzer is assumed. The analyzer
the text which comprises the field-name as a sequence
field-name atoms (fnatoms) separated by LWSP-
Note that ONLY LWSP-chars may occur between the fnatoms of
field-name and that CRLFs may NOT. In addition, comments
NOT lexically recognized, as such, but parenthesized
are legal as part of field-names. These constraints
different from what is permissible within structured
bodies. In particular, this means that header field-
must wholly occur on the FIRST line of a folded header
and may NOT be split across two or more lines
d. Unstructured field
For some fields, such as "Subject" and "Comments",
structuring is assumed; and they are treated simply as texts
like those in the message body. Rules of folding apply
these fields, so that such field bodies which occupy
lines must therefore have the second and successive
indented by at least one LWSP-char
e. Structured field
To aid in the creation and reading of structured fields,
free insertion of linear-white-space (which permits
by inclusion of CRLFs) is allowed in reasonable places
Rather than obscuring the syntax specifications for
structured fields with explicit syntax for this linear
white-space, the existence of another "lexical" analyzer
assumed. This analyzer does not apply for field bodies
are simply unstructured strings of text, as described above
It provides an interpretation of the unfolded text
the body of the field as a sequence of lexical symbols
These symbols are
- individual special
- quoted-
Standard for the Format of Text Messages 8
III.
B. Lexical
-
-
The first three of these symbols are self-delimiting.
are not; they therefore are delimited by the self-
symbols and by linear-white-space. For the purposes of re
generating sequences of atoms and quoted-strings, exactly
SPACE is assumed to exist and should be used between them
(Also, in Section III.B.3.a, note the rules
treatment of multiple continguous LWSP-chars.)
So, for example, the folded body of an address
":sysmail"@ Some-Host
Muhammed(I am the greatest)Ali at(the)
is analyzed into the following lexical symbols and types
":sysmail" quoted
@
Some-Host
,
Muhammed
(I am the greatest)
Ali
at
(the)
WBA
The cononical representations for the data in these
are the following strings (note that there is exactly
SPACE between words):
:sysmail at Some-
Muhammed Ali at
2. Formal
The first four rules, below, indicate a meta-syntax for fields
without regard to their particular type or internal syntax.
remaining rules define basic syntactic structures which are
by the rules in Sections III.C, III.D, and III.E
field = field-name ":" [ field-body ]
field-name = fnatom *( LWSP-char [fnatom] )
Standard for the Format of Text Messages 9
III.
B. Lexical
fnatom = 1*
field-body = field-body-
[CRLF LWSP-char field-body
field-body-contents =
field-body, as defined in the following sections
and consisting of combinations of atom, quoted
string, and specials tokens, or else consisting
texts
; ( Octal, Decimal.)
CHAR = character> ; ( 0-177, 0.-127.)
ALPHA = character
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = ; ( 60- 71, 48.- 57.)
CTL =
character and DEL> ; ( 177, 127.)
CR = ;( 15, 13.)
LF = linefeed> ; ( 12, 10.)
SPACE = ; ( 40, 32.)
HTAB = horizontal-tab>; ( 11, 9.)
<"> = ; ( 42, 34.)
CRLF = CR
LWSP-char = SPACE / HTAB ; semantics =
linear-white-space = 1*([CRLF] LWSP-char) ; semantics =
; CRLF =>
specials = "(" / ")" / "<" / ">" / "@" ; To use in a word
/ "," / ";" / ":" / "\" / <"> ; word must be
; quoted-string
delimiters = specials / comment / linear-white-
text = atoms, specials
CR and/or bare LF, but NOT ; comments
including CRLF> ; quoted-strings
; NOT interpreted
atom = 1*
quoted-string = <"> *(qtext/quoted-pair) <">; Any number of
; chars or
; quoted char
qtext = ; => may be
and CR, and
linear-white-space
Standard for the Format of Text Messages 10
III.
B. Lexical
comment = "(" *(ctext / comment / quoted-pair) ")"
ctext = may be
")" and CR, and
linear-white-space
quoted-pair = "\"
3.
a. "White space
Remember that in field-names and structured field bodies
MULTIPLE LINEAR WHITE SPACE TELNET ASCII CHARACTERS (
HTABs and SPACEs) ARE TREATED AS SINGLE SPACES AND MAY
SURROUND ANY SYMBOL. In all header fields, the only place
which at least one space is REQUIRED is at the beginning
continuation lines in a folded field. When passing text
processes which do not interpret text according to
standard (e.g., ARPANET FTP mail servers), then exactly
SPACE should be used in place of arbitrary linear-white-
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)
should realize that there is no Network-wide definition
the effect of horizontal-tab TELNET ASCII characters on
appearance of text at another Network host; therefore,
use of tabs in message headers, though permitted,
discouraged
Note that during transmissions across the ARPANET
TELNET NVT connections, data must conform to TELNET
conventions (e.g., CR must be followed by either LF, making
CRLF, or , if the CR is to stand alone).
b.
Comments are detected as such only within field-bodies
structured fields. A comment is a set of TELNET
characters, which is not within a quoted-string and which
enclosed in matching parentheses; parentheses nest, so
if an unquoted left parenthesis occurs in a comment string
there must also be a matching right parenthesis. When
comment is used to act as the delimiter between a sequence
two lexical symbols, such as two atoms, it is
equivalent with one SPACE, for the purposes of
the sequence, such as when passing the sequence onto an
mail server
Standard for the Format of Text Messages 11
III.
B. Lexical
In particular comments are NOT passed to the FTP server,
part of a MAIL or MLFL command, since comments are not
of the "formal" address
If a comment is to be "folded" onto multiple lines, then
syntax for folding must be adhered to. (See items III.B.1.a
above, and III.B.3.f, below.) Note that the
semantics therefore do not "see" any unquoted CRLFs which
in comments, although particular parsing programs may wish
note their presence. For these programs, it would
reasonable to interpret a "CRLF LWSP-char" as being a
which is part of the comment; i.e., the CRLF is kept and
LWSP-char is discarded. Quoted CRLFs (i.e., a
followed by a CR followed by a LF) still must be followed
at least one LWSP-char
c. Delimiting and quoting
The quote character (backslash) and characters which
syntactic units are not, generally, to be taken as data
are part of the delimited or quoted unit(s). The
exception is SPACE. In particular, the quotation-marks
define a quoted-string, the parentheses which define
comment and the backslash which quotes a following
are NOT part of the quoted-string, comment or
character. A quotation-mark which is to be part of
quoted-string, a parenthesis which is to be part of a
and a backslash which is to be part of either must each
preceded by the quote-character backslash ("\"). Note
the syntax allows any character to be quoted within
quoted-string or comment; however only certain
MUST be quoted to be included as data. These characters
those which are not part of the alternate text group (i.e.,
ctext or qtext).
A single SPACE is assumed to exist between contiguous
in a phrase, and this interpretation is independent of
actual number of LWSP-chars which the creator places
the words. To include more than one SPACE, the creator
make the LWSP-chars be part of a quoted-string
Quotation marks which delimit a quoted string and
which quote the following character should NOT accompany
quoted-string when the string is used with processes that
not interpret data according to this specification (e.g.,
ARPANET FTP mail servers).
Standard for the Format of Text Messages 12
III.
B. Lexical
d. Quoted-
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
to be "folded" onto multiple lines, then the syntax
folding must be adhered to. (See items III.B.1.a, above,
III.B.3.f, below.) Note that the official
therefore do not "see" any bare CRLFs which are in quoted
strings, although particular parsing programs may wish
note their presence. For these programs, it would
reasonable to interpret a "CRLF LWSP-char" as being a
which is part of the quoted-string; i.e., the CRLF is
and the LWSP-char is discarded. Quoted CRLFs (i.e.,
backslash followed by a CR followed by a LF) are also
to rules of folding, but the presence of the
character (backslash) explicitly indicates that the CRLF
data to the quoted string. Stripping off the first
LWSP-char is also appropriate when parsing quoted CRLFs
e. Bracketing
There are three types of brackets which must be well nested
o Parentheses are used to indicate comments
o Angle brackets ("<" and ">") are generally
to indicate the presence of at least one machine
usable code (e.g., delimiting mailboxes).
o Colon/semi-colon (":" and ";") are used
address specifications to indicate that
included list of addresses are to be treated as
group
f. Case independence of certain specials
Certain atoms, which are represented in the syntax as
alphabetic strings, can be represented in any combination
upper and lower case. These are
- field-name
- "Include", "Postal" and equivalent atoms in
":"":" address specification
- "at", in a host-indicator
- node
- day-of-week
- month,
- zones
When matching an atom against one of these literals, case
to be ignored. For example, the field-names "From", "FROM",
Standard for the Format of Text Messages 13
III.
B. Lexical
"from", and even "FroM" should all be treated identically
However, the case shown in this specification is
for message-creating processes. Note that, at the level
this specification, case IS relevant to other words
texts. Also see Section IV.A.1.f, below
g. Folding long
Each header item (field of the message) may be represented
exactly one line consisting of the name of the field and
body; this is what the parser sees. For readability, it
recommended that the field-body portion of long header
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,
it is not imposed by this standard
h. Backspace
Backspace TELNET ASCII characters (ASCII BS, decimal 8.)
be included in texts and quoted-strings to
overstriking; however, any use of backspaces which effects
overstrike to the left of the beginning of the text
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
in a particular order. These header items
be unique (occur exactly once). However
fields, in fact, are NOT required to occur in
particular order, except that the message
must occur AFTER the headers. For
and ease of parsing by simple systems, it
recommended that headers be sent in the
"Date", "From", "Subject", "Sender", "To", "cc",
etc. This specification permits
occurrences of most optional-fields. However
their interpretation is not specified here,
their use is strongly discouraged
The following syntax for the bodies of various fields should
thought of as describing each field body as a single long
(or line). The section on Lexical Analysis (section II.B
indicates how such long strings can be represented on more
one line in the actual transmitted message
Standard for the Format of Text Messages 14
III.
C.
message = fields *( CRLF *text ) ; Everything
; first null
; is message
fields = date-field ; Creation time-
originator-fields ; & author id
*optional-field ; required:
; are all
originator-fields =
( "From" ":" mailbox ; Single
["Reply-To" ":" #address] )
/ ( "From" ":" 1#address ; Multiple authors &
"Sender" ":" mailbox ; may have non-mach
["Reply-To" ":" #address] ); ine
date-field = "Date" ":" date-
optional-field =
"To" ":" #
/ "cc" ":" #
/ "bcc" ":" #address ; Blind
/ "Subject" ":" *
/ "Comments" ":" *
/ "Message-ID" ":" mach-id ; Only one
/ "In-Reply-To"":" #(phrase / mach-id
/ "References" ":" #(phrase / mach-id
/ "Keywords" ":" #
/ extension-field ; To be defined
;
;
/ user-defined-field ; Must have
; field-name &
; be pre-
extension-field =
published as a formal extension to
specification
user-defined-field =
this specification or published as an extension
this specification; names for such fields must
unique and may be preempted by
extensions
Standard for the Format of Text Messages 15
III.
D. Addressee
D. SYNTAX OF GENERAL ADDRESSEE
address = host-phrase ; Machine
/ ( [phrase] "<" #address ">") ; Individual /
/ ( [phrase] ":" #address ";") ;
/ quoted-string ; Arbitrary
/ (":" ( "Include" ; File, w/ addr
/ "Postal" ; (U.S.) Postal
/ atom ) ; Extended data
":" address
mailbox = host-phrase / (phrase mach-id
mach-id = "<" host-phrase ">" ; Contents must
; be modified
E. SUPPORTING
host-phrase = phrase host-indicator ; Basic
host-indicator = 1*( ("at" / "@") node ) ; Right-most node
; at top of
; hierarchy; left
; most must be
node = word / 1*DIGIT ; Official host
; network name
; decimal
date-time = [ day-of-week "," ] date
day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue
/ "Wednesday" / "Wed" / "Thursday" / "Thu
/ "Friday" / "Fri" / "Saturday" / "Sat
/ "Sunday" / "Sun
date = 1*2DIGIT ["-"] month ; day month
["-"] (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.
E. Supporting
time = hour zone ; ANSI and
; (seconds optional
hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
; 0000[00] - 2359[59]
zone = ( ["-"] ( "GMT" ; Relative to GMT
; North
/ "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
; hours/min. (HHMM
phrase = 1*word ; Sequence of words
; Separation seman
; tically =
word = atom / quoted-
Standard for the Format of Text Messages 17
IV.
A. Address
IV.
A. ADDRESS
1.
a. The phrase part of a host-phrase in an address
(i.e., the host's name for the mailbox) is understood to
whatever the receiving FTP Server allows (for example,
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
necessarily pertain to file storage. For example, some
may choose to print mail on their line printer and
the output to the addressee's desk
An individual may have several mailboxes and a group
individuals may wish to receive mail as a single unit (i.e.,
a distribution list). The second and third alternatives
an address list (#address) allow naming a collection
subordinate addresses list(s). Recipient mailboxes
specified within the bracketed part ("<" - ">" or ":" - ";")
of such named lists. The use of angle-brackets ("<", ">")
intended for the cases of individuals with multiple
and of special mailbox lists; it is not expected to be
more than one level, although the specification allows
nesting. The use of colon/semi-colon (":", ";") is
for the case of groups. Groups can be expected to
(i.e., to contain subgroups). For both individuals
groups, a copy of the transmitted message is to be sent
EACH mailbox listed. For the case of a special list
treatment of addresses is defined in the relevant
of this section
b. The inclusion of bare quoted-strings as addresses (i.e.,
fourth address-form alternative) is allowed as a
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
locations containing stored address lists (#address).
more than one location is referenced, the address part of
Include phrase must be a list (#address) surrounded
angle-brackets, as per the "Individual / List" alternative
. Constituent addresses must resolve to a host
Standard for the Format of Text Messages 18
IV.
A. Address
phrase; only they have any meaning within this construct
The phrase part of indicated host-phrases should contain
which the referenced host can resolve to a file.
standard is not a protocol and so does not prescribe HOW
is to be retrieved from the file. However, the
requirements are made
o The file must be accessible through the
operating system interface (if it exists),
adequate user access rights;
o If a host has an FTP server and a user is
to retrieve any files from the host using
server, then the file must be accessible
FTP, using DEFAULT transfer settings,
adequate user access rights
It is intended that this mechanism allow programs to
such lists automatically
The interpretation of such a file reference follows. This
not intended to imply any particular implementation scheme
but is presented to aid in understanding the notion
including file contents in address lists
o Elements of the address list part are
and the contents of ONLY ONE of them are to
included in the resultant address list
o The contents of the file indicated by a
host-phrase are treated as an address list
are inserted as an address list (#address)
the position of the path item in the syntax
That is, the TELNET ASCII characters
the entire Include is replaced by
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
syntactically self-contained and must adhere
the full syntax prescribed herein for an
list
d. ":Postal:" specifications are used to indicate (U.S.)
addresses, but can be treated the same as quoted-
addresses. To reference a list of postal addresses, the
must conform to the "Individual / List" alternative
. The ":Include:" alternative also is valid
e. The "':' atom ':'" syntax is intended as a general
for indicating specially data-typed addresses. As
extension-fields, the authors of this document will
Standard for the Format of Text Messages 19
IV.
A. Address
the publishing of specifications for these extended data
types. In the absence of defined semantics, any
of an address in this form may be treated as a quoted-
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
that network or host, at the time the message is created
The USE OF NUMBERS IS STRONGLY DISCOURAGED and is
only due to the occasional necessity of bypassing local
tables. For the ARPANET, official names are maintained
the Network Information Center at SRI International,
Park, California
Whenever a message might be transmitted or migrate to a
on another network, full hierarchical addresses must
specified. These are indicated as a series of words
separated by at-sign or "at" indications. The
environment is assumed to consist of a collection of
organized as independent "trees" except for
between the root nodes. That is, only the roots can act
gateways between these independent networks. While
actual connections may exist, it is believed that
this type of organization will provide a reliable method
describing VALID, if not EFFICIENT, paths between hosts.
typical full mailbox specification might therefore look like
Friendly User @ hosta @ local-net1 @ major-
In the simplest case, a mail-sending host should transmit
message to the node which is mentioned last (farthest to
right), strip off that node reference from the specification
and then pass the remaining host-phrase to the recipient
(in the ARPANET, its FTP server) for it to process.
treats the remaining portion of the host-indicator merely
the terminating part of the phrase
NOTE: When passing any portion of a host-
onto a process which does not interpret
according to this standard (e.g.,
FTP servers), "@" must be used and not "at
and it must not be preceded or followed
any LWSP-chars. Using the above example
the following string would be passed to
major-netq gateway
Friendly User@hosta@local-net
When the sending host has more knowledge of the
environment, then it should send the message along a
efficient path, making appropriate changes to the form of
host-phrase which it gives to the recipient host
Standard for the Format of Text Messages 20
IV.
A. Address
To use the above specification as an example: If a
hostb also were part of local-net1, then it could send
message directly to hosta and would give only the
"Friendly User" to hosta's mail-receiving program. If
were part of local-net2, along with hostc, and happened
know that hosta and hostc were part of another local-net
then hostb could send the message to hostc to the
"Friendly User@hosta".
The phrase in a host-phrase is intended to be meaningful
to the indicated receiving host. To all other hosts,
phrase is to be treated as an uninterpreted string. No
transformations should be (automatically) performed on
phrase. The phrase is passed to the local host's
sending program; it is the responsibility of the
host's mail receiving (distribution) program to perform
mapping on this phrase, if required, to deliver the mail
2. Originator
WARNING: The standard allows only a subset of
combinations possible with the From, Sender
and Reply-To fields. The limitation
intentional
a.
This field contains the identity of the person(s) who
this message to be sent. The message-creation process
default this field to be a single machine address,
the AGENT (person or process) entering the message. If
is NOT done, the "Sender" field MUST be present; if this
done, the "Sender" field is optional
b.
This field contains the identity of the AGENT (person
process) who sends the message. It is intended for use
the sender is not the author of the message, or to
who among a group of authors actually sent the message.
the contents of the "Sender" field would be
redundant with the "From" field, then the "Sender" field
not be present and its use is discouraged (though
legal); in particular, the "Sender" field MUST be
if it is NOT the same as the "From" Field
The Sender host-phrase includes a phrase which
correspond to a specific agent (i.e., a human user or
computer program) rather than a standard address.
indicates the expectation that the field will identify
single AGENT (person or process) responsible for sending
Standard for the Format of Text Messages 21
IV.
A. Address
mail and not simply include the name of a mailbox from
the mail was sent. For example in the case of a shared
name, the name, by itself, would not be adequate. The
part of the host-phrase, which refers to this agent,
expected to be a computer system term, and not (for example
a generalized person reference which can be used outside
network text message context
Since the critical function served by the "Sender" field
the identification of the agent responsible for sending
and since computer programs cannot be held accountable
their behavior, is strongly recommended that when a
program generates a message, the HUMAN who is responsible
that program be referenced as part of the "Sender"
host-phrase
c. Reply-
This field provides a general mechanism for indicating
mailbox(es) to which responses are to be sent. Three
uses for this feature can be distinguished. In the
case, the author(s) may not have regular machine-
mailboxes and therefore wish(es) to indicate an
machine address. In the second case, an author may
additional persons to be made aware of, or responsible for
responses; responders should send their replies to
"Reply-To" mailbox(es) listed in the original message.
somewhat different use may be of some help to "text
teleconferencing" groups equipped with automatic
services: include the address of that service in
"Reply-To" field of all messages submitted to
teleconference; then participants can "reply" to
submissions to guarantee the correct distribution of
submission of their own
Reply-To fields are NOT required to contain any
addresses (i.e., host-phrases). Note, however, that
absence of even one valid network address will tend
prevent software systems from automatically assisting
in conveniently responding to mail
NOTE: For systems which automatically generate address lists
replies to messages, the following recommendations are made
o The receiver, when replying to a message,
NEVER automatically include the "Sender" host-
in the reply's address list
o If the "Reply-To" field exists, then the
should go ONLY to the addresses indicated in
field and not to the addresses indicated in
"From" field
Standard for the Format of Text Messages 22
IV.
A. Address
(Extensive examples are provided in Section V.)
recommendation is intended only for originator-fields and is
intended to suggest that replies should not also be sent to
other recipients of this message. It is up to the
mail handling programs to decide what additional facilities
be provided
3. Receiver
a.
This field contains the identity of the primary recipients
the message
b.
This field contains the identity of the secondary
of the message
b.
This field contains the identity of additional recipients
the message. The contents of this field are not included
copies of the message sent to the primary and
recipients. Some systems may choose to include the text
the "Bcc" field only in the author(s)'s copy, while
may also include it in the text sent to all those
in the "Bcc" list
B. REFERENCE SPECIFICATION
1. Message-
This field contains a unique identifier (the phrase) which
to THIS version of THIS message. The uniqueness of the
identifier is guaranteed by the host which generates it.
identifier is intended to be machine readable and not
meaningful to humans. A message identifier pertains to
one instantiation of a particular message; subsequent
to the message should each receive a new message identifier
2. In-Reply-
The contents of this field identify previous correspondence
this message answers. Note that if message identifiers are
in this field, they must use the mach-id specification format
Standard for the Format of Text Messages 23
IV.
B. Reference Specification
3.
The contents of this field identify other correspondence
this message references. Note that if message
are used, they must use the mach-id specification format
4.
This field contains keywords or phrases, separated by commas
C. OTHER FIELDS AND SYNTACTIC
1.
The "Subject" field is intended to provide as much information
necessary to adequately summarize or indicate the nature of
message
2.
Permits adding text comments onto the message without
the contents of the message's body
3. Extension-
A relatively limited number of common fields have been defined
this document. As network mail requirements dictate,
fields may be standardized. The authors of this document
regulate the publishing of such definitions as extensions to
basic specification
4. User-defined-
Individual users of network mail are free to define and
additional header fields. Such fields must have names which
not already used in the current specification or in
definitions of extension-fields, and the overall syntax of
user-defined-fields must conform to this specification's
for delimiting and folding fields. Due to the extension-
publishing process, the name of a user-defined-field may be pre
empted
Standard for the Format of Text Messages 24
IV.
D.
D. DATES AND
If included, day-of-week must be the day implied by the
specification
Time zone may be indicated in several ways. The
standard uses a single character for each zone. "Z"
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
two forms are taken from ANSI standard X3.51-1975. One
explicit indication of the amount of offset from GMT; the
uses common 3-character strings for indicating time zones
North America
Standard for the Format of Text Messages 25
V.
A.
V.
A.
1. Alfred E. Neuman
2. Neuman@BBN-
These two "Alfred E. Neuman" examples have identical semantics
as far as the operation of the local host's mail
(distribution) program (also sometimes called its "mailer")
the remote host's FTP server are concerned. In the
example, the "Alfred E. Neuman" is ignored by the mailer,
"Neuman at BBN-TENEXA" completely specifies the recipient.
second example contains no superfluous information, and, again
"Neuman@BBN-TENEXA" is the intended recipient
3. Al Neuman at BBN-
This is identical to "Al Neuman ".
is, the full phrase, "Al Neuman", is passed to the FTP server
Note that not all FTP servers accept multi-word identifiers;
some that do accept them will treat each word as a
addressee (in this case, attempting to send a copy of the
to "Al" and a copy to "Neuman").
4. "George Lovell, Ted Hackle"
This form might be used to indicate that a single mailbox
shared by several users. The quoted string is ignored by
originating host's mailer, as "Shared-Mailbox at Office-1"
completely specifies the destination mailbox
4. Wilt (the Stilt) Chamberlain at
The "(the Stilt)" is a comment, which is NOT included in
destination mailbox address handed to the originating system'
mailer. The address is the string "Wilt Chamberlain",
exactly one space between the first and second words. (
quotation marks are not included.)
Standard for the Format of Text Messages 26
V.
B. Address
B. ADDRESS
Gourmets: Pompous Person ,
Cooks: Childs at WGBH, Galloping Gourmet
ANT (Australian National Television);,
Wine Lovers: Cheapie at Discount-Liquors
Port at Portugal;;,
Jones at
This group list example points out the use of comments,
nesting of groups, and the mixing of addresses and groups.
that the two consecutive semi-colons preceding "Jones at SEA
mean that Jones is NOT a member of the Gourmets group
C. ORIGINATOR
1. Author-
George Jones logs into his Host as "Jones". He sends
himself
From: Jones at
From: George Jones
2. Secretary-
George Jones logs in as Jones on his Host. His secretary,
logs in as Secy on Shost sends mail for him. Replies to the
should go to George, of course
From: George Jones
Sender: Secy at
3. Shared directory or unrepresentative directory-
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.
C. Originator
4. Secretary-sent, for user of shared
George Jones' secretary sends mail for George in his capacity
a member of Group while logged in as Secy at Host.
should go to Group
From: George Jones
Sender: Secy at
Note that there need not be a space between "Jones" and the "<",
but adding a space enhances readability (as is the case in
examples).
5. Secretary acting as full agent of
George Jones asks his secretary (Secy at Host) to send a
for him in his capacity as Group. He wants his secretary
handle all replies
From: George Jones
Sender: Secy at
Reply-To: Secy at
6. Agent for user without online
A non-ARPANET user friend of George's, Sarah, is visting
George's secretary sends some mail to a friend of Sarah
computer-land. Replies should go to George, whose mailbox
Jones at Host
From: Sarah
Sender: Secy at
Reply-To: Jones at
7. Sent by member of a
George is a member of a committee. He wishes to have any
to his message go to all committee members
From: George
Sender: Jones at
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
of Big-committee, he would not have gotten an implicit reply;
presence of the "Reply-to" field SUPERSEDES the sending of
reply to the person named in the "From" field
Standard for the Format of Text Messages 28
V.
C. Originator
8. Example of INCORRECT
George desires a reply to go to his secretary; therefore
secretary leaves his mailbox address off the "From" field
leaving only his name, which is not, itself, a mailbox address
From: George
Sender: Secy at
THIS IS NOT PERMITTED. Replies are NEVER implicitly sent to
"Sender"; George's secretary should have used the "Reply-To
field, or the mail creating program should have forced
secretary to
9. Agent for member of a
George's secretary sends out a message which was authored
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
D. COMPLETE
1. Minimum required
Date: 26 August 1976 1429-
From: Jones at
2. Using some of the additional fields
Date: 26 August 1976 1430-
From:George Jones
Sender:Secy at
To:Al Neuman at Mad-Host
Sam Irving at Other-
Message-ID:
Standard for the Format of Text Messages 29
V.
D. Complete
3. About as complex as you're going to get
Date : 27 Aug 1976 0932-
From : Ken Davis
Subject : Re: The Syntax in the
Sender : KSecy at Other-
Reply-To : Sam Irving at Other-
To : George Jones ,
Al Neuman at Mad-
cc : Important folk
Tom Softwood ,
Sam Irving at Other-Host;,
Standard Distribution::Include
standard at Other-Host
"standard.dist.3" at Tops-20-Host>,
(The following Included Postal list is
of Standard Distribution.)
:Postal::Include: Non-net-addrs@Other-host;,
:Postal: "Sam Irving, P.O. Box 001, Las Vegas
Nevada" (So that he can
apprised of the situation
Comment : Sam is away on business. He asked me to
his mail for him. He'll be able to provide
more accurate explanation when he
next week
In-Reply-To:
Special (action): This is a sample of multi-word field
names, using a range of characters.
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
A. Alphabetical Listing of Syntax
A. ALPHABETICAL LISTING OF SYNTAX
address = host-phrase / quoted-
/ (*phrase "<" #address ">" )
/ (*phrase ":" #address ";" )
/ (":" ("Include" / "Postal" / atom) ":" address
ALPHA = character
atom = 1*
CHAR = character
comment = "(" *(ctext / comment / quoted-pair) ")"
CR =
CRLF = CR
ctext =
including linear-white-space
CTL = character and DEL
date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT
date-field = "Date" ":" date-
date-time = [ day-of-week "," ] date
day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue
/ "Wednesday" / "Wed" / "Thursday" / "Thu
/ "Friday" / "Fri" / "Saturday" / "Sat
/ "Sunday" / "Sun
delimiters = specials / comment / linear-white-
DIGIT =
extension-field =
published as a formal extension to
specification
field = field-name ":" [ field-body ]
fields = date-field originator-fields *optional-
field-body = field-body-
[CRLF LWSP-char field-body
field-body-contents =
field-body, as defined in the following sections
and consisting of combinations of atom, quoted
string, and specials tokens, or else consisting
texts
field-name = fnatom *(LWSP-char [fnatom])
fnatom = 1*
Standard for the Format of Text Messages 32
A. Alphabetical Listing of Syntax
host-indicator = 1*( ("at" / "@") node )
host-phrase = phrase host-
hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
HTAB = horizontal-tab
LF = linefeed
linear-white-space = 1*([CRLF] LWSP-char
LWSP-char = SPACE /
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*
optional-field =
"To" ":" #
/ "cc" ":" #
/ "bcc" ":" #
/ "Subject" ":" *
/ "Comments" ":" *
/ "Message-ID" ":" mach-
/ "In-Reply-To"":" #(phrase / mach-id
/ "References" ":" #(phrase / mach-id
/ "Keywords" ":" #
/ extension-
/ user-defined-
originator-fields =
( "From" ":"
["Reply-To" ":" #address] )
/ ( "From" ":" 1#
"Sender" ":"
["Reply-To" ":" #address] )
phrase = 1*
quoted-pair = "\"
quoted-string = <"> *(qtext / quoted-pair) <">
qtext = , CR, or LF and
linear-white-space
SPACE =
specials = "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":"
/ "\" / <">
text =
NOT including CRLF
Standard for the Format of Text Messages 33
A. Alphabetical Listing of Syntax
time = hour
user-defined-field =
this specification or published as an extension
this specification; names for such fields must
unique and may be preempted by
extensions
word = atom / quoted-
zone = ( ("+" / "-") 4DIGIT )
/ ( ["-"] (1
/ "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
B. Simple
B. SIMPLE
Some mail-reading software systems may wish to perform
minimal processing, ignoring the internal syntax of
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
suffice for this purpose. They describe a limited view
messages and are a subset of the syntactic rules provided in
main part of this specification. One small exception is that
contents of field-bodies consist only of text
SYNTAX
message = *field *(CRLF *text
field = field-name ":" [field-body]
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
a null line (i.e., two contiguous CRLFs).
A line which continues a header field begins with a SPACE
HTAB character, while a line beginning a field starts with
printable character which is not a colon
A field-name consists of one or more printable
(excluding colon), each separated by one or more SPACES or HTABS
A field-name MUST be contained on one line. Upper and lower
are not distinguished when comparing field-names
Standard for the Format of Text Messages 37
ANSI. Representations of universal time, local
differentials, and United States time zone references
information interchange. ANSI X3.51-1975; American
Standards Institute: New York, 1975.
Bhushan, A.K. The File Transfer Protocol. ARPANET Request
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.
Request for Comments, No. 385, Network Information Center No
11357; Augmentation Research Center, Stanford
Institute: Menlo Park, August 1972.
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E
Standardizing Network Mail Headers. ARPANET Request
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
Center, Stanford Research Institute: Menlo Park, April 1976.
(NTIS AD A003890).
McKenzie, A. File Transfer Protocol. ARPANET Request
Comments, No. 454, Network Information Center No. 14333;
Augmentation Research Center, Stanford Research Institute
Menlo Park, February 1973.
McKenzie, A. TELNET Protocol Specification. Network
Center No. 18639; Augmentation Research Center,
Research Institute: Menlo Park, August 1973.
Myer, T.H. and Henderson, D.A. Message Transmission Protocol
ARPANET Request for Comments, No. 680, Network
Center No. 32116; Augmentation Research Center,
Research Institute: Menlo Park, 1975.
Neigus, N. File Transfer Protocol. ARPANET Request
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.
official standard for the format of ARPA network messages
Standard for the Format of Text Messages 38
ARPANET Request for Comments, No. 724, Network
Center No. 37435; Augmentation Research Center,
Research Institute: Menlo Park, May 1977.
Postel, J.B. Revised FTP Reply Codes. ARPANET Request
Comments, No. 640, Network Information Center No. 30843;
Augmentation Research Center, Stanford Research Institute
Menlo Park, June 1974.
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
