APPENDIX C. DIFFERENCES FROM RFC #733

The following summarizes the differences between this standard and the one specified in Arpanet Request for Comments #733, "Standard for the Format of ARPA Network Text Messages". The differences are listed in the order of their occurrence in the current specification.

C.1. FIELD DEFINITIONS

C.1.1. FIELD NAMES

These now must be a sequence of printable characters. They may not contain any LWSP-chars.

C.2. LEXICAL TOKENS

C.2.1. SPECIALS

The characters period ("."), left-square bracket ("["), and right-square bracket ("]") have been added. For presentation purposes, and when passing a specification to a system that does not conform to this standard, periods are to be contiguous with their surrounding lexical tokens. No linear-white-space is permitted between them. The presence of one LWSP-char between other tokens is still directed.

C.2.2. ATOM

Atoms may not contain SPACE.

C.2.3. SPECIAL TEXT

ctext and qtext have had backslash ("\") added to the list of prohibited characters.

C.2.4. DOMAINS

The lexical tokens <domain-literal> and <dtext> have been added.

C.3. MESSAGE SPECIFICATION

C.3.1. TRACE

The "Return-path:" and "Received:" fields have been specified.

C.3.2. FROM

The "From" field must contain machine-usable addresses (addr-spec). Multiple addresses may be specified, but named-lists (groups) may not.

C.3.3. RESENT

The meta-construct of prefacing field names with the string "Resent-" has been added, to indicate that a message has been forwarded by an intermediate recipient.

C.3.4. DESTINATION

A message must contain at least one destination address field. "To" and "CC" are required to contain at least one address.

C.3.5. IN-REPLY-TO

The field-body is no longer a comma-separated list, although a sequence is still permitted.

C.3.6. REFERENCE

The field-body is no longer a comma-separated list, although a sequence is still permitted.

C.3.7. ENCRYPTED

A field has been specified that permits senders to indicate that the body of a message has been encrypted.

C.3.8. EXTENSION-FIELD

Extension fields are prohibited from beginning with the characters "X-".

C.4. DATE AND TIME SPECIFICATION

C.4.1. SIMPLIFICATION

Fewer optional forms are permitted and the list of three-letter time zones has been shortened.

C.5. ADDRESS SPECIFICATION

C.5.1. ADDRESS

The use of quoted-string, and the ":"-atom-":" construct, have been removed. An address now is either a single mailbox reference or is a named list of addresses. The latter indicates a group distribution.

C.5.2. GROUPS

Group lists are now required to to have a name. Group lists may not be nested.

C.5.3. MAILBOX

A mailbox specification may indicate a person's name, as before. Such a named list no longer may specify multiple mailboxes and may not be nested.

C.5.4. ROUTE ADDRESSING

Addresses now are taken to be absolute, global specifications, independent of transmission paths. The <route> construct has been provided, to permit explicit specification of transmission path. RFC #733's use of multiple at-signs ("@") was intended as a general syntax for indicating routing and/or hierarchical addressing. The current standard separates these specifications and only one at-sign is permitted.

C.5.5. AT-SIGN

The string " at " no longer is used as an address delimiter. Only at-sign ("@") serves the function.

C.5.6. DOMAINS

Hierarchical, logical name-domains have been added.

C.6. RESERVED ADDRESS

The local-part "Postmaster" has been reserved, so that users can be guaranteed at least one valid address at a site.