RFC 469

Network Mail Meeting Summary 💌

Okay bestie, let's get into this one 📬. Quick title block tea: it's NWG/RFC#469, written by Michael D. Kudlick MDK (SRI-ARC), also filed as NIC 14798, dated 8-MAR-73. The header doesn't list a category, and it doesn't say this one obsoletes or updates anything 🧚

The purpose of this RFC is to briefly sum up, from the NIC's viewpoint, the main conclusions from the Network Mail Meeting that went down Friday, February 23 1973, at SRI-ARC ✨

Read more before you dive in, okay? 🙈

• Check out 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) has background info 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 explains briefly how the NIC would use that info.

The layout goes: Conclusions, Discussion, and Attendees 💅

---

Conclusions

Okay so the big decision is that more FTP mail requirements were agreed on 🔥 They'd be implemented as a new mail command with the following subcommands, and I'm obsessed with how clean this is:

• TO
  • This field is explicitly allowed to contain multiple addressees, with a standard syntax: user@host.
• FROM
  • This field gives a return address for notification of undeliverable mail, plus a clearcut identification of the sender for the recipient's information..
• 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
  • This one is for the intermediate host, probably the NIC in most cases, to tell the sender what happened to their 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 gives you the option of having the mail recorded. Info given with this subcommand would be recognized at the NIC. The 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 tell 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 lets the recipient site do whatever it thinks is appropriate when storing the mail 🦋
• TEXT / FILE / CITATION
  • TEXT
    • This field is for the text of the mail message.
  • FILE
    • Honestly, 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
    • 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 of 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. 🫶

TO 💌

Addressee Format 🎀

okay so the standard form of an address is user@host 💖

"User" can be an individual's last name, OR whatever other identification the recipient has picked AND made known to the rest of the network 🫶

If the intended host doesn't recognize the recipient's identification, 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. 😭

NIC Role 🧚

the NIC really doesn't need any role at all for mail going from point A to point B, as long as that mail isn't supposed to be recorded at the NIC ✨

for mail that is getting recorded at the NIC, you use the RECORDED subcommand 📚

also, if the sender doesn't know the standard address of the recipients, they can use the NIC to look it up 🔍

Idents and Addresses 🦋

the NIC is going to update its identification files so each individual has a "user@host" standard address 💅

sites can ask the NIC to translate from a NIC Ident, or from a user's last name, to the standard address 🌸 there will be a query facility at the NIC to do the translation on request, and the translation service will also work for "group idents" 👑

ngl this service is FTP-like in terms of the protocol it accepts, but it is NOT part of FTP itself. a different server process handles Ident translation requests 🤓

translation also happens 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, there's already a provision for specifying hardcopy or on-line delivery of recorded (NIC Journal) mail 📬

this provision is getting extended to include a "network" attribute, which means "deliver the mail to the host of this person" 🌈

the network attribute can be qualified by restricting all mail to be kept at the sender, with only a notification message actually mailed 🫣

notification would be a citation giving "to", "from", "title", "date of submission", and "location of mail" 💜

TIP Users 🌷

so to let TIP users send AND receive mail, it was suggested that some hosts become the "home" site for these users (but no more than one "home" site per user) 🏠

basically, an account that lets a TIP user send and receive mail has to be set up at one of these hosts 🔑

for now, any TIP user can use the SRI-ARC system for their mail needs ✨

there was also an alternate idea: equip TIPs with a hardcopy device that's always available for printing mail. this got discarded in favor of the approach above 🙅‍♀️

---

FROM 🌟

the "FROM" command in FTP identifies the sender in "standard address" form 💌

this is what lets "undeliverable" mail notices get sent back to the originator 🔙

Default Retention 🛡️

by default, the sender's host has to keep the mail until it's "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 can designate an intermediate host to store the mail. then that intermediate host is responsible for storing it until it's "delivered" to ALL intended recipients 🧳

the "ACKNOWLEDGEMENT" command lets an optional, positive acknowledgement go back to the originator (the "FROM" addressee), saying the mail was delivered 🎀

---

AUTHOR ✍️

the AUTHOR can be several people! for recorded documents, the authors show up separately in the index of authors, so you can search for mail when you know an author but not the title or location 🔍💖

---

TITLE 🏷️

the TITLE field is super useful for recorded mail, because indexes on key words in the title can be made pretty easily, which makes searching for mail way easier 🧠✨

so the title should be a succinct indicator of the contents 💅

---

ACKNOWLEDGEMENT 🧾

acknowledgement of a 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 the sender's request, kinda like U.S. CERTIFIED mail 📮

BUT no acknowledgement that the recipient actually saw the mail will be given (it's comparable to NOT having U.S. REGISTERED mail) 🙈

---

RECORDED 📚

the whole concept of "recorded" mail is that a permanent record of the mail gets kept centrally, so you can make future references and re-readings 🦋

for example, in the NIC Journal system, a record is kept of all the items entered into the Journal. from that record, author, title-word, and NIC number indexes get produced for references and re-readings 🗂️

the key to retrieving recorded Journal items is an accession number (the NIC number). this basically removes any chance of duplicate filenames being used 🫶

Accession Numbers 🔢

the basic aspect of recorded mail that was discussed at the mail meeting is assigning an "accession" number 💫

it was decided to get accession numbers from the NIC on an as-needed basis, with no pre-assignment and no local assignment ✨

this might get reviewed in the future. local assignment could be desirable to keep 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 like sitename, date, and time 🧩

Where the Document Lives 📍

one other problem exists, namely "where is the recorded document?" 🥺

initially the document should be in the NIC, but ultimately it could be anywhere on the Network, provided there's 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 came out of a discussion about the problems of large mail files, and the related question of who would pay for processing and storing these files 🤑

the main decisions 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 that helps the recipient host make an intelligent decision about where to store incoming mail gets passed along via the TYPE command 🧠

the recipient host has the local option of providing either of these services:

• 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 wants the recipient to read 👀

an alternative to sending entire messages or files over the Network is the "CITATION" mechanism. the sender sends a short message (the citation) that basically says "please read file X at site Y" 🌸

this would be especially useful for:

• a) mail that's 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

BUT no method of enforcing use of this alternative was discussed 😅 it'll be up to the recipients to come up with a scheme that works for them 🫶

---

Other General Discussion 🌈

Bob Kahn's Question 💭

Bob Kahn put this question on the floor (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? 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 allow things like:
   • a) handling a calendar that reflects the known and anticipated whereabouts of people, so 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 they don't 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 🧘‍♀️

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 communication isn't 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

a design for a mailbox-type system won't be required to cover the problems of something like a computer teleconferencing system 🎥 which has attributes (real-time, video, a very large volume of data to be transferred, to name a few) that aren't attributes of a mailbox system 💜

okay bestie, the roll call 💅 these are the people who showed up to the Network Mail Meeting on 2/23/73 at SRI-ARC, with their initials and sites:

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  ]

that's the whole cast, and the machine-readable note at the bottom is the final credit 🎀