Internet RFC/STD/FYI/BCP Archives

Comment on RFC720

RFC720 - Address Specification Syntax for Network Mail

Network Working Group                                         D. Crocker  (ISI)Request for Comments: 720                                              Aug 1976NIC #36337References: RFC#680          Address Specification Syntax for Network MailEXPerience with PRocessing mail on the Arpanet has pointed up manyaddressing 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 theirmailing list with them;4. It would be very useful to be able to send mail to files otherthan the person's primary mailbox.The current mail syntax, specified in RFC680, does not provide aconvenient mechanism for distinguishing between a person's name andtheir mailing address. In cases of shared Directories, the ATTN: clauseis marginally adequate; however it is completely inappropriate forsingle-user mailboxes in which the address specification is simplycryptic. CMU's identification tags are good examples of this problem,since they tend to appear to be random character sequences; the use ofinitials as tags also points up the problem. If you douBT thereferential ambiguity of addresses, then try to use only the informationpresented, rather than random personal knowledge, to discern whoMicro@ISI, JFH@ISI, or Greep@ISD are. By having a formal syntax forseparately specifying names and addresses, mail display software canprintout out name lists which only contain human names...makes thingsfriendlier.The problem with long mailing lists is that, if included in the text ofa message, they often are longer than the main part of the message.Group names are allowed in address fields primarily to circumvent thisproblem. However the advent of semi-automated message answering, inwhich a receiver's message system prepares address lists for replymessages by copying appropriate fields from the original message, makesthe current mechanism deficient: having the group name means that thereceiver does not have the names/addresses of the members of the group.A convention is generally followed, now, which has the group name be apathname 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. Thisfeature is probably has the largest potential for teleconferencingapplications, with messages for an on-going discussion automaticallyplaced into a separate mailbox. In the case of shared directories, thismechanism also would allow easy channeling into each person's ownmailbox.                                  -1-With these needs in mind, and until a more robust mail syntax andprotocol is specified, the following general syntax is proposed toaugment the existing syntax specified in RFC680, for address fieldsspecified by the user:Name:(Person(User-Id(Mailbox) at Host),...),; ...Where"Name" is the name of the mailing list; "Person" presumably isthe name of the person receiving the mail;"User-Id" is their online reference name (usually their signondirectory);"Mailbox" is a a secondary mailbox/file;and the rest conforms to RFC680, although "@" may be used inplace of " at " in the specification.Parentheses may be replaced by other bracketing pairs ([], {}, <>).Quotation marks must be used any time the string contains ambiquatingcharacters, sUCh as space or parentheses. The brackets after Name areused to request exclusion of the address list from the message, insteadusing text which gives the pathname to the source of the list.The formal syntax for address specification, within network mailactually sent, is included in the next section.Not all of a specification is required, so perhaps some examples willclarify things:.A normal specification, as used currently: Walker at ISIA named list, to be carried with the message, with the lastaddress not a member of the list: List:Walker atISI,greep@rand-isd;Action@ISIA named list, NOT to be carried with the message; the listcontents will be replaced with a text string indicating the sourceof the list -- not very useful if the list is typed in by theuser, rather than pulled from a file; thereforeList:(Walker@ISI,greep at rand); Action at ISi will be changed toappear in the message as List:("/rnd/dcrocker/mail.list"); Actionat ISIA list with personal names. separate from addresses: "SteveWalker"[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 directaddition/replacement for specifications within RFC680. The fieldseliminated 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 modifiedto be::Sender = "SENDER: " IndividualAnd the added fields are:Address-Field = Address-List / Address-List ,,:,Address-FieldAddress-List = Individual-List / Group-ListGroup-List = Group-Name Group-MembersGroup-Name = / Name ":"Group-Members = Individual-List / L-Bracket PathnameR-BracketPathname = {A Name which can at least provide ahuman with enough information to findthe file containing the Group-List}Individual-List = Individual / IndividualIndividual-ListAddress Specification Syntax for Network MailIndividual = Mailbox / Name L-Bracket MailboxR-BracketL-Bracket = "(" / "[" / "{" / "<"R-Bracket = ")" / "]" / "}" / ">"Mailbox = Id Secondary-File At HostId = NameAt = "" at "" / "@"Host = {An acceptable host name}                                 -3-Secondary-File = / L-Bracket Filename R-BracketFilename = NameName = {An Ascii string without carriagereturn, line feed, space, '"', ",",";", or any L-Bracket or R-Bracket} /'"' {An Ascii string with any doublequotation marks doubled} '"'The particular L-Bracket and R-Bracket characters used must matcheach other. The requirement for quotation marks has been made moresevere than absolutely necessary in order to simplify softwarerequirments. Note also that the above specified syntax is forinter-entity communications and is not necessarily indicative of whatthe user types.