home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 700s / rfc720.txt < prev    next >
Text File  |  1992-10-14  |  7KB  |  234 lines
  1.  
  2. Network Working Group                                         D. Crocker  (ISI)
  3. Request for Comments: 720                                              Aug 1976
  4. NIC #36337
  5. References: RFC #680
  6.  
  7.  
  8.  
  9.           Address Specification Syntax for Network Mail
  10.  
  11.  
  12. Experience with processing mail on the Arpanet has pointed up many
  13. addressing issues, including:
  14.  
  15. 1. People's names are not the same as their addresses;
  16.  
  17. 2. Mailing lists can get quite long;
  18.  
  19. 3. To allow responding, messages often need to carry all of their
  20. mailing list with them;
  21.  
  22. 4. It would be very useful to be able to send mail to files other
  23. than the person's primary mailbox.
  24.  
  25. The current mail syntax, specified in RFC 680, does not provide a
  26. convenient mechanism for distinguishing between a person's name and
  27. their mailing address. In cases of shared directories, the ATTN: clause
  28. is marginally adequate; however it is completely inappropriate for
  29. single-user mailboxes in which the address specification is simply
  30. cryptic. CMU's identification tags are good examples of this problem,
  31. since they tend to appear to be random character sequences; the use of
  32. initials as tags also points up the problem. If you doubt the
  33. referential ambiguity of addresses, then try to use only the information
  34. presented, rather than random personal knowledge, to discern who
  35. Micro@ISI, JFH@ISI, or Greep@ISD are. By having a formal syntax for
  36. separately specifying names and addresses, mail display software can
  37. printout out name lists which only contain human names...makes things
  38. friendlier.
  39.  
  40. The problem with long mailing lists is that, if included in the text of
  41. a message, they often are longer than the main part of the message.
  42. Group names are allowed in address fields primarily to circumvent this
  43. problem. However the advent of semi-automated message answering, in
  44. which a receiver's message system prepares address lists for reply
  45. messages by copying appropriate fields from the original message, makes
  46. the current mechanism deficient: having the group name means that the
  47. receiver does not have the names/addresses of the members of the group.
  48. A convention is generally followed, now, which has the group name be a
  49. pathname to the file containing the list. Though facilitative, this
  50. does not represent an adequate solution.
  51.  
  52. And lastly is the issue of multiple mailboxes for a single user. This
  53. feature is probably has the largest potential for teleconferencing
  54. applications, with messages for an on-going discussion automatically
  55. placed into a separate mailbox. In the case of shared directories, this
  56. mechanism also would allow easy channeling into each person's own
  57. mailbox.
  58.  
  59.  
  60.                                   -1-
  61.  
  62.  
  63.  
  64. With these needs in mind, and until a more robust mail syntax and
  65. protocol is specified, the following general syntax is proposed to
  66. augment the existing syntax specified in RFC 680, for address fields
  67. specified by the user:
  68.  
  69. Name:(Person(User-Id(Mailbox) at Host),...),; ...
  70.  
  71. Where
  72.  
  73. "Name" is the name of the mailing list; "Person" presumably is
  74. the name of the person receiving the mail;
  75.  
  76. "User-Id" is their online reference name (usually their signon
  77. directory);
  78.  
  79. "Mailbox" is a a secondary mailbox/file;
  80.  
  81. and the rest conforms to RFC 680, although "@" may be used in
  82. place of " at " in the specification.
  83.  
  84. Parentheses may be replaced by other bracketing pairs ([], {}, <>).
  85. Quotation marks must be used any time the string contains ambiquating
  86. characters, such as space or parentheses. The brackets after Name are
  87. used to request exclusion of the address list from the message, instead
  88. using text which gives the pathname to the source of the list.
  89.  
  90. The formal syntax for address specification, within network mail
  91. actually sent, is included in the next section.
  92.  
  93. Not all of a specification is required, so perhaps some examples will
  94. clarify things:.
  95.  
  96. A normal specification, as used currently: Walker at ISI
  97.  
  98. A named list, to be carried with the message, with the last
  99. address not a member of the list: List:Walker at
  100. ISI,greep@rand-isd;Action@ISI
  101.  
  102. A named list, NOT to be carried with the message; the list
  103. contents will be replaced with a text string indicating the source
  104.  
  105. of the list -- not very useful if the list is typed in by the
  106. user, rather than pulled from a file; therefore
  107. List:(Walker@ISI,greep at rand); Action at ISi will be changed to
  108. appear in the message as List:("/rnd/dcrocker/mail.list"); Action
  109. at ISI
  110.  
  111. A list with personal names. separate from addresses: "Steve
  112. Walker"[Walker at ISI], Bob<rha@isd>
  113.  
  114. A teleconferencing address list:
  115. Talkers:"Dave C"(DCrocker(TC.msg)@isi),...;
  116.  
  117.                                   -2-
  118.  
  119.  
  120. Formal Specification
  121. --------------------
  122.  
  123. The following modified BNF is to serve as a direct
  124. addition/replacement for specifications within RFC 680. The fields
  125. eliminated from the existing specification are: <addressee item>,
  126. <address list>, <addressee>, <mailbox>, <host spec>, <attention spec>.
  127. <user list>, <mailbox group>, <group numbers>, and <mailbox list>.
  128.  
  129. <Attention spec> can be performed through use of the person's name
  130. and secondary file specification. Also, <Sender> should be modified
  131. to be::
  132.  
  133. Sender = "SENDER: " Individual
  134.  
  135. And the added fields are:
  136.  
  137. Address-Field = Address-List / Address-List ,,:,
  138. Address-Field
  139.  
  140. Address-List = Individual-List / Group-List
  141.  
  142. Group-List = Group-Name Group-Members
  143.  
  144. Group-Name = / Name ":"
  145.  
  146. Group-Members = Individual-List / L-Bracket Pathname
  147. R-Bracket
  148.  
  149. Pathname = {A Name which can at least provide a
  150. human with enough information to find
  151. the file containing the Group-List}
  152.  
  153. Individual-List = Individual / Individual
  154. Individual-List
  155. Address Specification Syntax for Network Mail
  156.  
  157.  
  158.  
  159. Individual = Mailbox / Name L-Bracket Mailbox
  160. R-Bracket
  161.  
  162. L-Bracket = "(" / "[" / "{" / "<"
  163.  
  164. R-Bracket = ")" / "]" / "}" / ">"
  165.  
  166. Mailbox = Id Secondary-File At Host
  167.  
  168. Id = Name
  169.  
  170. At = "" at "" / "@"
  171.  
  172. Host = {An acceptable host name}
  173.  
  174.  
  175.                                  -3-
  176.  
  177.  
  178. Secondary-File = / L-Bracket Filename R-Bracket
  179.  
  180. Filename = Name
  181.  
  182. Name = {An Ascii string without carriage
  183. return, line feed, space, '"', ",",
  184. ";", or any L-Bracket or R-Bracket} /
  185. '"' {An Ascii string with any double
  186. quotation marks doubled} '"'
  187.  
  188. The particular L-Bracket and R-Bracket characters used must match
  189. each other. The requirement for quotation marks has been made more
  190. severe than absolutely necessary in order to simplify software
  191. requirments. Note also that the above specified syntax is for
  192. inter-entity communications and is not necessarily indicative of what
  193. the user types.
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.                                   -4-
  234.