1 files changed, 233 insertions, 0 deletions
diff --git a/doc/rfc/rfc720.txt b/doc/rfc/rfc720.txt
new file mode 100644
index 0000000..091b8a6
--- /dev/null
+++ b/doc/rfc/rfc720.txt
@@ -0,0 +1,233 @@
+
+Network Working Group                                         D. Crocker  (ISI)
+Request for Comments: 720                                              Aug 1976
+NIC #36337
+References: RFC #680
+
+
+
+          Address Specification Syntax for Network Mail
+
+
+Experience with processing mail on the Arpanet has pointed up many
+addressing issues, including:
+
+1. People's names are not the same as their addresses;
+
+2. Mailing lists can get quite long;
+
+3. To allow responding, messages often need to carry all of their
+mailing list with them;
+
+4. It would be very useful to be able to send mail to files other
+than the person's primary mailbox.
+
+The current mail syntax, specified in RFC 680, does not provide a
+convenient mechanism for distinguishing between a person's name and
+their mailing address. In cases of shared directories, the ATTN: clause
+is marginally adequate; however it is completely inappropriate for
+single-user mailboxes in which the address specification is simply
+cryptic. CMU's identification tags are good examples of this problem,
+since they tend to appear to be random character sequences; the use of
+initials as tags also points up the problem. If you doubt the
+referential ambiguity of addresses, then try to use only the information
+presented, rather than random personal knowledge, to discern who
+Micro@ISI, JFH@ISI, or Greep@ISD are. By having a formal syntax for
+separately specifying names and addresses, mail display software can
+printout out name lists which only contain human names...makes things
+friendlier.
+
+The problem with long mailing lists is that, if included in the text of
+a message, they often are longer than the main part of the message.
+Group names are allowed in address fields primarily to circumvent this
+problem. However the advent of semi-automated message answering, in
+which a receiver's message system prepares address lists for reply
+messages by copying appropriate fields from the original message, makes
+the current mechanism deficient: having the group name means that the
+receiver does not have the names/addresses of the members of the group.
+A convention is generally followed, now, which has the group name be a
+pathname to the file containing the list. Though facilitative, this
+does not represent an adequate solution.
+
+And lastly is the issue of multiple mailboxes for a single user. This
+feature is probably has the largest potential for teleconferencing
+applications, with messages for an on-going discussion automatically
+placed into a separate mailbox. In the case of shared directories, this
+mechanism also would allow easy channeling into each person's own
+mailbox.
+
+
+                                  -1-
+
+
+
+With these needs in mind, and until a more robust mail syntax and
+protocol is specified, the following general syntax is proposed to
+augment the existing syntax specified in RFC 680, for address fields
+specified by the user:
+
+Name:(Person(User-Id(Mailbox) at Host),...),; ...
+
+Where
+
+"Name" is the name of the mailing list; "Person" presumably is
+the name of the person receiving the mail;
+
+"User-Id" is their online reference name (usually their signon
+directory);
+
+"Mailbox" is a a secondary mailbox/file;
+
+and the rest conforms to RFC 680, although "@" may be used in
+place of " at " in the specification.
+
+Parentheses may be replaced by other bracketing pairs ([], {}, <>).
+Quotation marks must be used any time the string contains ambiquating
+characters, such as space or parentheses. The brackets after Name are
+used to request exclusion of the address list from the message, instead
+using text which gives the pathname to the source of the list.
+
+The formal syntax for address specification, within network mail
+actually sent, is included in the next section.
+
+Not all of a specification is required, so perhaps some examples will
+clarify things:.
+
+A normal specification, as used currently: Walker at ISI
+
+A named list, to be carried with the message, with the last
+address not a member of the list: List:Walker at
+ISI,greep@rand-isd;Action@ISI
+
+A named list, NOT to be carried with the message; the list
+contents will be replaced with a text string indicating the source
+
+of the list -- not very useful if the list is typed in by the
+user, rather than pulled from a file; therefore
+List:(Walker@ISI,greep at rand); Action at ISi will be changed to
+appear in the message as List:("/rnd/dcrocker/mail.list"); Action
+at ISI
+
+A list with personal names. separate from addresses: "Steve
+Walker"[Walker at ISI], Bob<rha@isd>
+
+A teleconferencing address list:
+Talkers:"Dave C"(DCrocker(TC.msg)@isi),...;
+
+                                  -2-
+
+
+Formal Specification
+--------------------
+
+The following modified BNF is to serve as a direct
+addition/replacement for specifications within RFC 680. The fields
+eliminated from the existing specification are: <addressee item>,
+<address list>, <addressee>, <mailbox>, <host spec>, <attention spec>.
+<user list>, <mailbox group>, <group numbers>, and <mailbox list>.
+
+<Attention spec> can be performed through use of the person's name
+and secondary file specification. Also, <Sender> should be modified
+to be::
+
+Sender = "SENDER: " Individual
+
+And the added fields are:
+
+Address-Field = Address-List / Address-List ,,:,
+Address-Field
+
+Address-List = Individual-List / Group-List
+
+Group-List = Group-Name Group-Members
+
+Group-Name = / Name ":"
+
+Group-Members = Individual-List / L-Bracket Pathname
+R-Bracket
+
+Pathname = {A Name which can at least provide a
+human with enough information to find
+the file containing the Group-List}
+
+Individual-List = Individual / Individual
+Individual-List
+Address Specification Syntax for Network Mail
+
+
+
+Individual = Mailbox / Name L-Bracket Mailbox
+R-Bracket
+
+L-Bracket = "(" / "[" / "{" / "<"
+
+R-Bracket = ")" / "]" / "}" / ">"
+
+Mailbox = Id Secondary-File At Host
+
+Id = Name
+
+At = "" at "" / "@"
+
+Host = {An acceptable host name}
+
+
+                                 -3-
+
+
+Secondary-File = / L-Bracket Filename R-Bracket
+
+Filename = Name
+
+Name = {An Ascii string without carriage
+return, line feed, space, '"', ",",
+";", or any L-Bracket or R-Bracket} /
+'"' {An Ascii string with any double
+quotation marks doubled} '"'
+
+The particular L-Bracket and R-Bracket characters used must match
+each other. The requirement for quotation marks has been made more
+severe than absolutely necessary in order to simplify software
+requirments. Note also that the above specified syntax is for
+inter-entity communications and is not necessarily indicative of what
+the user types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                  -4-