summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc469.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc469.txt')
-rw-r--r--doc/rfc/rfc469.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc469.txt b/doc/rfc/rfc469.txt
new file mode 100644
index 0000000..f77fcb9
--- /dev/null
+++ b/doc/rfc/rfc469.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+NWG/RFC#469 Michael D. Kudlick MDK (SRI-ARC)
+NIC 14798 8-MAR-73
+
+ Network Mail Meeting Summary
+
+Introduction
+
+ The purpose of this RFC is to briefly summarize, from the NIC's
+ viewpoint, the principal conclusions reached at the Network Mail
+ Meeting held Friday, February 23 1973, at SRI-ARC.
+
+ Please refer to RFC #475 (NIC 14919) for Abhay Bhushan's
+ comprehensive summary of the issues discussed at the meeting.
+
+ There is no major disagreement between the present RFC and RFC
+ #475.
+
+ RFC #453 (NIC 14317) contains background information on the
+ meeting.
+
+ RFC #479 (NIC 14948) describes what the NIC would like to see
+ included in the File Transfer Protocol for Network Mail purposes,
+ and also describes briefly how the NIC would use the information.
+
+ The present RFC is organized as follows:
+
+ Conclusions
+ Discussion
+ Attendees
+
+Conclusions
+
+ Additional FTP mail requirements were decided upon. These would be
+ implemented as a new mail command, with the following subcommands:
+
+ TO
+
+ This field is explicitly allowed to contain multiple
+ addressees, with a standard syntax: user@host.
+
+ FROM
+
+ This field provides a return-address for notification of
+ undeliverable mail, as well as a clearcut identification of the
+ sender for the recipient's information..
+
+
+
+
+
+
+ [Page 1]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ AUTHOR
+
+ This field denotes the author of the mail. There may be
+ multiple authors
+
+ TITLE
+ The "title" (i.e. subject) of the mail is to be terminated by
+ period carriage return.
+
+ ACKNOWLEDEGMENT success / failure (time out) / normal
+
+ For use by the intermediate host, probably the NIC in most
+ cases, to tell the sender what happened to his attempt to send
+ mail. (Note: "normal" wasn't defined.)
+
+ RECORDED jnumber / null
+
+ Note: "jnumber" is the pre-assigned accession number (NIC
+ number), to be used when known.
+
+ The "RECORDED" subcommand provides for the option of having the
+ mail recorded. Information given with this subcommand would be
+ recognized at the NIC. Options are:
+
+ to be recorded (in NIC journal) only,
+ to be recorded and distributed,
+ to be distributed only.
+
+ This field would also be used to inform the recipient that the
+ mail has been recorded.
+
+ (In retrospect, it may be preferable to have a separate
+ command to inform the recipient of this fact, but no
+ decision on this was made at the 23-Feb-73 meeting.)
+
+ TYPE long / urgent / ordinary
+
+ This allows the recipient site to take whatever action it
+ thinks appropriate in storing the mail.
+
+ TEXT / FILE / CITATION
+
+ TEXT
+
+ This field is for the text of the mail message.
+
+
+
+
+
+
+ [Page 2]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ FILE
+
+ The purpose of the field is unclear to me. Does it contain a
+ machine readable pointer to the file that the sender wishes the
+ recipient to read?
+
+ CITATION
+
+ This field is a person-readable pointer to the file that the
+ sender wishes the recipient to read. When the citation command
+ is used, no mail is sent other than the citation.
+
+
+Discussion
+
+ Introduction
+
+ The key aspects in the solution are:
+
+ 1) It is based on FTP.
+
+ 2) It uses the NIC without requiring direct use of NLS.
+
+ 3) There is a mechanism for uniformity in the use of
+ user identifications.
+
+ 4) There is a mechanism for recording the mail for
+ later reference.
+
+ These issues are covered in the discussion that follows.
+
+New FTP Mail Subcommands
+
+ TO
+
+ Addressee Format
+
+ The standard form of the address is: user@host
+
+ "User" may be an individual's last name; or it may be whatever
+ other identification the recipient has chosen AND has made
+ known to the rest of the network.
+
+ If the intended host doesn't recognize the intended
+ recipient's identification, then it sends back an
+ "undeliverable" mail message to the sender's host. It is up
+ to the individual to keep the NIC informed of his wherabouts
+ [sic]; otherwise, he may not get his mail on time.
+
+
+
+ [Page 3]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ NIC Role
+
+ The NIC need have no role at all for mail sent from point A to
+ point B, whenever that mail is not to be recorded at the NIC.
+
+ For mail that is to be recorded at the NIC, the RECORDED
+ subcommand is to be used.
+
+ Also, when the sender does not know the standard address of the
+ recipients, he may use the NIC to obtain this information.
+
+ Idents and Addresses
+
+ The NIC will modify its identification files to include the
+ "user@host" standard address for each individual.
+
+ Sites may ask the NIC to translate from NIC Ident, or from a
+ user's last name, to the standard address. A query facility
+ will be made available at the NIC to do the translation on
+ request. The translation service will also be available for
+ "group idents".
+
+ This service would be FTP-like, in term of the prootocol
+ [sic] it accepts, but would not be within FTP itself. A
+ different server process would handle Ident translation
+ requests.
+
+ Translation will also be done at the NIC when the NIC is
+ used as an intermediate point on the delivery route.
+
+ The NIC could be an intermediate point for recording the
+ mail as a NIC journal item, and for forwarding the mail
+ to its ultimate destinations. During this process, the
+ NIC would translate from NIC idents to standard
+ addresses.
+
+ In the NIC ident files, provision already exists to specify
+ hardcopy or on-line delivery of recorded (NIC Journal) mail.
+
+ This provision will be extended to include a "network"
+ attribute, which means "deliver the mail to the host of this
+ person".
+
+ The network attribute may be qualified by restricting all
+ mail to be kept at the sender, with only a notification
+ message actually mailed.
+
+
+
+
+
+ [Page 4]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ Notification would be in the form of a citation giving "to",
+ "from", "title", "date of submission", and "location of
+ mail".
+
+ TIP Users
+
+ To enable TIP users to have access to the mail system, both for
+ sending and receiving mail, it was suggested that some hosts
+ will have to be the "home" site for these users (but no more
+ than one "home" site per user).
+
+ That is, an account that allows a TIP user to send and receive
+ mail will have to be established at such a host.
+
+ For the present, any TIP user can use the SRI-ARC system for
+ his mail requirements.
+
+ An alternate solution, that TIP's be equipped with a hardcopy
+ device that is continuously available for printing mail, was
+ discarded in favor of the above approach.
+
+ FROM
+
+ The "FROM" command in FTP, identifies the sender in "standard
+ address" form.
+
+ This will allow "undeliverable" mail notices to be sent back to
+ the originator.
+
+ The default condition is that the sender's host must retain
+ the mail until it is "delivered" to the recipient's host.
+
+ "Delivered" means that the recipient's host has accepted
+ the mail. It does NOT mean that the recipient has READ
+ the mail.
+
+ Alternatively, the sender may designate that an intermediate
+ host store the mail. Then the intermediate host has the
+ responsibility of storing the mail until it is "delivered"
+ to all intended recipients.
+
+ The "ACKNOWLEDGEMENT" command will allow an optional, positive
+ acknowledgement to be given to the originator of the mail (the
+ "FROM" addressee), stating that the mail was delivered.
+
+
+
+
+
+
+
+ [Page 5]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ AUTHOR
+
+ The AUTHOR may be several persons. For recorded documents the
+ authors appear separately in the index of authors, to facilitate
+ searching for mail when an author is known, but the title and
+ location of the mail are unknown.
+
+ TITLE
+
+ The TITLE field is especially useful for recorded mail, since
+ indexes on key words in the title can be produced relatively
+ easily, and facilitate searching for mail.
+
+ For this reason, the title should be a succinct indicator of the
+ contents.
+
+ ACKNOWLEDGEMENT
+
+ Acknowledgement of failure to deliver should be given to the
+ sender.
+
+ An optional, positive acknowledgement of successful delivery to
+ the recipient's sitename will be given on request of sender
+ (like U.S. CERTIFIED mail).
+
+ No acknowledgement that the recipient actually saw the mail
+ will be given (comparable to not having U.S. REGISTERED mail).
+
+ RECORDED
+
+ The concept of "recorded" mail is that a permanent record of the
+ mail is kept centrally, to allow future references and re-readings
+ of the mail to be made.
+
+ For example, in the NIC Journal system, a record is kept of all
+ the items entered into the Journal. From this record, author,
+ title-word, and NIC number indexes are produced to allow for
+ references and re-readings.
+
+ The key to retrieval of recorded Journal items is the use of an
+ accession number (the NIC number). This essentially removes
+ the possibility of duplicate filenames being used.
+
+ The basic aspect of recorded mail which was discussed at the mail
+ meeting is the assignment of an "accession" number.
+
+
+
+
+
+
+ [Page 6]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ It was decided to get the accession numbers from the NIC on an
+ as-needed basis, without pre-assignment and without local
+ assignment of numbers.
+
+ This subject may be reviewed in the future. Local assignment
+ may be desirable to prevent the NIC from becoming a bottleneck
+ in the mail process.
+
+ It was pointed out that local assignment of numbers would be
+ un-ambiguous if the numbers included some information such as
+ sitename, date, and time.
+
+ One other problem exits [sic], namely "where is the recorded
+ document?".
+
+ Initially the document should be in the NIC, but ultimately it
+ could be anywhere on the Network, provided only that there is a
+ central mechanism for indexing and cataloging all the recorded
+ documents.
+
+ The pathname to the recorded document would then include
+ filename and sitename.
+
+ TYPE
+
+ The TYPE subcommand was a result of a discussion on the
+ problems of large mail files, and the associated
+ question of who would pay for the processing and storing
+ of these files.
+
+ The main decisions made were:
+
+ a) The processing, transmittal, and storage costs of
+ sending mail should be borne at the sender's host.
+
+ b) The processing and storage costs of receiving
+ mail should be borne at the recipient's host
+ initially, as a default.
+
+ Information to enable the recipient host to make an
+ intelligent decision about where to store the incoming
+ mail are passed along via the TYPE command.
+
+ The recipient host will have the local option of
+ providing either of the following services:
+
+
+
+
+
+
+ [Page 7]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ a) free use of system to send mail;
+ b) free use of system to receive mail, i.e. login
+ not required for delivery over the Network. (A
+ possible alternative is use of a "mail" account,
+ or use of the recipient's account, for processing
+ and storage of the incoming mail.
+
+ TEXT / FILE / CITATION
+
+ TEXT
+
+ This field is for the text of the mail message.
+
+ FILE
+
+ The purpose of this field is unclear to me. Does it contain a
+ machine readable pointer to the file that the sender wishes the
+ recipient to read?
+
+ CITATION
+
+ The citation is a person-readable pointer to the file that the
+ sender wishes the recipient to read.
+
+ An alternative to sending entire messages or files over the
+ Network is to use the "CITATION" mechanism. With this, the
+ sender sends a short message (the citation) saying, in effect,
+ "please read file X at site Y".
+
+ This alternative would be especially useful for
+
+ a) mail that is distributed with group idents (to all
+ liaisons, for example), and
+
+ b) "long" files (size not defined) that the recipient may
+ not be immediately interested in.
+
+ However no method of enforcing use of this alternative was
+ discussed. It will be up to the recipients to devise a
+ scheme satisfactory to them.
+
+Other General Discussion
+
+ Bob Kahn placed on the floor the following question (I paraphrase):
+
+ Can't the design of a mail system be made to include alternative
+ sources of data and alternative modes of operation, unless
+ exclusion of these alternatives can be quantitatively defended?
+
+
+
+ [Page 8]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ Particular aspects of this question are:
+
+ 1) What is the desirability and difficulty of admitting different
+ data sources into the mail system?
+
+ What are the "boundaries" that divide permitted from prohibited
+ data sources?
+
+ What is the quantitative distinction between deferred and
+ realtime mail?
+
+ Will the design we come up with allow such things as
+
+ a) handling a calendar that reflects the known and
+ anticipated whereabouts of people so that meetings can be
+ scheduled sensibly?
+
+ b) formatting the mail contents for later query and other
+ information handling?
+
+ 2) Whatever primitives we implement, can't they be designed so as
+ not to preclude things like Tenex "linking"?
+
+ This requires two-way data communication paths.
+
+ How do we specify and get the attention of a "sink" for the
+ data stream?
+
+ e.g., for interprocess communication, and for Tenex-type
+ "linking".
+
+ The general reaction to this discussion was one of perspective:
+
+ In the scheme of things that could be considered "point-to-point
+ communication", mailbox-type of communication is not the most
+ general kind.
+
+ AKB listed several types of communication problems:
+
+ program-program communication
+ people-people real-time communication, e.g.
+ Tenex-type "links"
+ computer teleconferencing
+ mailbox communication: cataloging, storage
+ protocols: host-host, telnet, file transfer
+
+
+
+
+
+
+ [Page 9]
+
+NIC 14798 MDK 8-MAR-73 17:24 14798
+
+
+ A design for a mailbox-type system won't be required to encompass
+ the problems of, say, a computer teleconferencing system, which
+ has attributes (real-time, video, very large volume of data to be
+ transferred, to name some) that are not attributes of a mail box
+ system.
+
+Attendees at the Network Mail Meeting 2/23/73 at SRI-ARC
+
+ Nancy Mimno BBN
+ ACB Alan Bomberger AMES-67
+ AKB Abhay Bhushan MIT-DMOG
+ AWH Wayne Hathaway AMES-67
+ CHI Charles Irby SRI-ARC
+ DHC Dave Crocker UCLA-NMC
+ JBP Jon Postel UCLA-NMC
+ JDH Dave Hopper SRI-ARC
+ JEW Jim White SRI-ARC
+ LPD Peter Deutsch PARC-MAXC
+ MCK Mark Krilanovich UCSB-MOD75
+ MDK Mike Kudlick SRI-ARC
+ REK2 Bob Kahn ARPA
+ RKK Rajendra Kanodia MIT-MULTICS
+ RST Ray Tomlinson BBN-TENEX
+
+
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Joseph Marshall 9/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 10]
+