RFC 555

Responses to critiques of the proposed mail protocol

📅 published July 1973, from ietf

Response to Critiques of the Proposed Mail Protocol 💌✨

Okay bestie, let's start with the title block 🎀. This is RFC 555, written by James E. White (JEW) at SRI-ARC (NIC 17993) for the Network Working Group, dated July 27, 1973. The header doesn't list a category, and it doesn't say this one obsoletes or updates anything 🤷‍♀️.

James had a proposed Mail Protocol (JEW RFC 524, 17140,2:y), and people had lots of thoughts 🙈. So this RFC gathers the questions, complaints, and suggestions from the Network community and responds to each one. He says he'll critique his own work in a future RFC, which is iconic of him 👑.

He also wants the conversation to keep going 🦋. Anyone can send in more critiques, and he'll answer each one by RFC. He's hoping for a lot of them 💜.

I. QUESTIONS 💅

HOW DOES THE SERVER VERIFY AN ID? 🪪

References:

Discussion:

Okay so, the setup is that there's at least one host whose Mail server process does User Verification (JEW RFC 524, 17140,5f7:gy) 🔐. Any process can reach that server, hand it someone's name plus a test Id, and the server tells them whether the two match. It's giving security checkpoint, but make it friendly 🧚.

The NIC, for one, will without question provide this service. 🫶

Once that's available, ANY FTP server process can ask for an ID command whenever it wants during the user-server chat, as long as it stays within the rules of the Protocol 💖. Here's how it goes: the server prompts for the Id, gets it, opens a connection to the User Verification Agent, shows it the Individual's name and claimed Id, gets back a yes or no, and then handles the original user process based on that answer. Iconic behavior honestly ✨.

Example:

Say a user process connects to UCLA-NMC's server process, invokes the Delivery function, and says the Author is Roberts at USC-ISI 📬.

UCLA-NMC decided that every Delivery transaction needs proof that the Author is who they claim to be 🕵️‍♀️. So after the AUTHOR command, it prompts for an Id, and the user process replies with ID arpawheel <CA>.

Then UCLA-NMC's server connects to the NIC's server, runs the User Verification function there, and sends REQUESTOR roberts @ usc-isi <CA> and ID arpawheel <CA>. The NIC comes back saying the Id is wrong. UCLA-NMS then rejects the original ID command 💀.

Now, the Protocol does NOT make servers demand Ids. A server that doesn't care about proof of identity just never prompts for ID commands and treats any it gets as NOPs 😌. For those implementations, which is the current FTP mail protocol situation, no third-party interchanges are ever needed 🌸.

Each user has one Id that they use across the whole Net for sending and receiving mail 📮. It doesn't have to do anything else, though it can, on purpose or by coincidence 🍓. A user's Id is separate from the passwords they use to get into accounts on various hosts. Totally different lanes 🛣️.

Of course, a user could make their passwords and Id the same thing. The NIC, for example, might make users log in with NIC ident and Id, instead of host name and password like it does now. 🙈

Bestie, James says it again because it matters: Ids have NOTHING to do with accounting 🚫💰. UCLA-NMC doesn't make the Author prove who they are so UCLA knows who to bill for the resources used in a Delivery. It does it so Jim White can't write a piece of mail and claim Larry Roberts wrote it 😤.

UCLA-NMC can require the user process to log in before delivering mail so it can bill them for the resources used 💸. The commands for that are USER, PASS, and ACCT. But the billing part is separate from the part where you identify the Author, Clerk, and so on 🧩.

For example, the NIC, acting as a Distribution Agent, might set up an account at UCLA-NMC to use whenever it delivers mail there. UCLA-NMC will bill ALL of the NIC's activity at UCLA to that account 🧾. But if the NIC delivers a piece of mail that claims Larry Roberts wrote it, UCLA-NMC might still want to check that claim. That's why the ID command exists 🔍✨.

ACK, PROGRESS REPORT, OR REPLY WITH NO REFERENCE SERIAL NUMBER 🧾

References:

Discussion:

A Delivery of type POSITIVE or NEGATIVE ACKNOWLEDGMENT, PROGRESS REPORT, or REPLY needs a Reference Serial Number from the user process 🔢. If the server notices one is missing when the final EXIT command arrives, it should reject the EXIT command with an appropriate error response 🚫.

The same goes for the Distribution function: a Reference Serial Number MUST be specified if the Delivery Type is REPLY 📌. Ngl, that's a must-have 💅.

James admits the Protocol document is missing this detail, and that's a fair callout 🫠. Consider this the fix 🌈.

II. COMPLAINTS 💅

TERMINATING BOTH THE SUBSYSTEM AND FUNCTIONS WITH EXIT 🦋

References:

(AAM -- 17404,)

Discussion:

Okay so bestie, the author is totally fine with having two terminating commands 🎀 one to leave a function and one to exit the whole subsystem. They even suggest a command GO <CA> for ending a function. Iconic energy ✨

Still, they don't think you need to split the two cases just to stop human users from getting confused 🙈

Even though the command language is ASCII and not binary, and even though they've borrowed Mike Padlipsky's idea of a Unified USER Level Protocol', they don't consider MP to be a protocol for humans to use directly 🧚 Nothing can stop a human from typing MP if they have access to a TELNET user program and are super determined, though 😭

The part they actually want to steal from the UULP is its model of a single process with many subsystems. They're not interested in its philosophy of a Network-standard command language for human users. (That might be a good idea too, but it's not what they're focused on right now 💜)

Here's the vibe check: designing a protocol for an exchange between processes is not the same job as designing one to mediate a conversation between a process and a human user 💅 Using ASCII commands makes it look like the second problem is the one being solved, as it did for FTP, RJE, etc. And it's not 💀

USING TELNET GO AHEAD TO TERMINATE CERTAIN COMMANDS 🌸

References:

(AAM -- 17404,)

(RCC -- 17822,1a:gy)

(DHC JBP RFC 539 -- 17644,3b:gy)

Discussion:

Agreed 🫶 my bad!

Honestly the author has a strong distaste for the current FTP convention of ending commands whose argument might itself contain CR LF with CR LF . CR LF 😤 That feels a little extra to them. They'd much prefer a single NVT character as the delimiter 🍓

<CA2> only ends two MP commands, COMMENTS and TEXT. So some NVT character (ESC? EXT? ...) can easily be picked that doesn't need to appear in the argument to either of those commands. The Protocol can then prohibit it from appearing there 🔥

SUBSYSTEM OR SEPARATE RJE-LIKE SERVER PROCESS 🎀

References:

(DHC JBP RFC 539 -- 17644,4a:gy)

(AAM -- 17404,)

(ADO RFC 552 -- 17809,3:y)

Discussion:

Okay there are two separable issues here, and I'm living for the drama 👑

(1) Server Process Proliferation of Not?

If the Network community agrees that Padlipsky's UULP approach to protocol design and implementation is actually better than the current scheme, then we should start embracing it and reshuffle existing protocol implementations to match 🦋 The current scheme implements each new Network protocol as its own server process with its own contact socket. Even more important, NEW protocols (like MP) should be designed under the new standards, not the old ones ✨

The author thinks Buz Owen's suggestion (ADO RFC 552 -- 17809,3:y) is excellent 🫶 That's the one where a skeletal UULP gets defined, a socket is assigned to server processes that implement it, and MP is defined as a subsystem under it. They retract their own earlier suggestion (JEW RFC 524 -- 17140,3a2:gy) in favor of Owen's 🌈

They also suggest that the latest revision of FTP (NJN RFC 542 -- 17759,) be implemented the same way, as a UULP subsystem 💜 Instead of being temporarily implemented under a new socket and later moved over to socket 3 like RFC 542 suggests, which feels like too much moving around to them 🙄

(2) RJE's model for FTP Use or Not?

If both MP (as currently defined) and RJE became UULP subsystems, they'd still have different philosophies about how they use FTP 💅 The author proposed and fought for the current RJE model (meaning its use of FTP), and they (still) think it's elegant. Way more elegant than the one they came up with for MP 😭

They also considered an alternative and tossed it SOLELY for efficiency reasons (maybe ignoring how clean the implementation is, tbh 🙈). The idea was that the command currently defined as FILE <CA> (JEW RFC 524 -- 17140,4q2a:gy), both for specifying Content and for the Citation Retrieval function, would become FILE <fileaddr> <CA> instead 🧚

The server is then obliged to retrieve the Content of the Mail from the designated server process via a third-party exchange.

The redefined FILE command would be similar to the LOCATION command, with one big difference: FILE would specify JUST Content (and none of the other Static Attributes). And the Server would have to retrieve the file in real time, i.e. BEFORE it sends its response to the FILE command 🍓 The file could even be a temporary file the user process created.

This alternative would kill the need to borrow the BYTE, SOCK, PASV, TYPE, STRU, MODE, REST, and SITE commands from FTP (JEW RFC 524 -- 17140,7c1:gy) 🙌 It also gives the user process the flexibility to specify a file at a host other than its own 💖

After some thought, though, the author agrees with Crocker and Postel that their version is the better implementation 🎀

Here's the catch they point out. This implementation brings up the problem of reconciling two things: wanting to allow (in general) transfer of mail files without requiring a login, and a server's inability to tell that case apart from the general case of file retrieval (where lots of hosts will require a login) 😬

USE OF THE DATE FORM 1/2/73 (JAN 2 OR FEB 1?) 📅

References:

(RCC -- 17822,1b)

Discussion:

Agreed ✨

ORDER OF PARAMETER SPECIFICATION 🌷

References:

(DHC JBP RFC 539 -- 17644,31:gy)

Discussion:

The Protocol doesn't actually impose an order on command specification within a function, even though Crocker and Postel say it does (see for example, JEW RFC 524 -- 17140,5f1b:gy) 🙈

That said, after thinking about their suggestion only briefly, the author does feel it's appropriate to put some constraints on the order in which the user specifies parameters 🫶 Off the top of their head, the order Dynamic, Optional, Static seems good 💜

III. SUGGESTED ADDITIONS 🧚

FORWARDING AT DELIVERY TIME 🦋

References:

(DHC JBP 539 -- 17644,4b:g)

Discussion:

Adding support for forwarding mail at Delivery Time seems super useful to the author 🔥 That's different from forwarding sometime after Delivery in response to a specific Forward request (i.e., function).

As Crocker and Postel note, only one of the three mechanisms for that forwarding actually bears on the Protocol. The Protocol might still mention the other two and either encourage or discourage their use 🌈

The author suggests a different reply format from the one Crocker and Postel proposed (DHC JBP RFC 539 -- 17644,4b3c2:gy) 👑 It looks like this:

476 <localname> -- is his location.

DEFAULT SIGNATURE SHOULD BE THE AUTHOR ✍️

References:

(DHC JBP 539 -- 17644,3c:gy)

Discussion:

Agreed 💖

LEVELS OF INTERRUPT 🚨

References:

(DHC JBP 539 -- 17644,3d:gy)

Discussion:

The author sees no value in defining numeric shades of urgency, unless the Protocol suggests some particular action the server might take for each one 🙄

Flagging some mail as urgent only seems useless unless the MP server process (not the human recipient) takes some kind of special action for urgent mail, BEFORE the human recipient would otherwise be likely to read it ⭐ If you accept that argument, there's clearly no point in defining shades of urgency that only mean something to the human recipient 💀

Sure, any two human users could privately agree on what the meanings are. But the author thinks it's better to define those meanings formally or not at all 🎀

WARNING THE SERVER OF THE SIZE OF MAIL 📦

References:

(DHC JBP RFC 539 -- 17644,3f:gy)

Discussion:

Agreed 🫶 Further suggestions as to the implementation?

DISCOURAGING SERVERS FROM REQUIRING LOGINS 🔐

References:

(DHC JBP RFC 539 -- 17644,3j:gy)

Discussion:

Agreed 💅 This is not a new issue, bestie 🌸

IV. META-COMMENTS ✨

SIZE OF THE PROTOCOL DOCUMENT

References:

(RCC -- 17822,1e:gy)

Discussion:

Okay bestie, first I owe you an apology 🥺 The format of the the Protocol document is totally different from older ones like FTP and RJE, and it is so not tutorial 💀 The glossary was a device I found useful while designing the Protocol. If everyone agrees on the substance, then friendlier documentation would have to be written 🎀 My time was super tight, so that shaped how I went about everything.

As I find time, I want to define the minimum implementation subsets that Clements requests ✨ For now, check out the command breakdown below. It covers the case where the server only permits the function that delivers mail to users on its host 💌 It has these attributes:

  1. It supports all of the functions of the current FTP mail protocol. In addition,
  2. It makes specification of author and title explicit, avoiding the current problem of multiple headers (one supplied by the server, the other embedded by the user in the text of the message),
  3. It allows the text of the message to reside at a third host, and
  4. It permits multiple recipients.

The breakdown is the following 🍓

COMMANDS THAT MUST BE IMPLEMENTED
(Author and Title could be treated as NOPs)

   To enter the Mail subsystem:
      MAIL <CA>
   To invoke the Delivery function:
      DELIVER <CA>

   To specify the text of the message:
      FILE <CA>
      LOCATION <fileaddr> <CA>
      TEXT <string> <CA2>
   To identify author(s), recipient(s), and title:
      AUTHOR <individual> <CA>
      RECIPIENT <individual> <CA>
      TITLE <title> <CA>
   To exit the function or subsystem:
      ABORT <CA>
      EXIT <CA>

COMMANDS THAT CAN BE TREATED AS NOPS
(they can legally appear in the Delivery function)

   ACCESS <individual> <CA>
   ACCESSTYPES <accesstypes> <CA>
   CATALOG <catalog> <CA>
   CLERK <individual> <CA>
   COMMENTS <comments> <CA2>
   CREATIONDATE <datetime> <CA>
   DELIVERYTYPE <deliverytype> <CA>
   DISPOSITION <disposition> <CA>
   GENERALDELIVERY <CA>
   GREETING <greeting> <CA>
   ID <id> <CA>
   REFERENCESERIAL <serialnumber> <CA>
   SERIAL <serialnumber> <CA>
   SIGNATURE <signature> <CA>

COMMANDS THAT NEEDN'T BE RECOGNIZED
(they cannot legally appear in the Delivery function)

   Commands that invoke unsupported functions:

      DISTRIBUTE <CA>
      FORWARD <CA>
      RECORD <CA>
      RETRIEVE <CA>
      UPDATE <CA>
      VERIFY <CA>

   Miscellaneous parameter specification commands:

      ACKCONDITION <ackcondition> <CA>
      ACKTYPE <acktype> <CA>
      CITATIONTEMPLATE <citationtemp> <CA>
      CUTOFF <interval> <CA>
      FORWARDEE <individual> <CA>
      MONITOR <individual> <CA>
      PATHNAME <pathname> <CA>
      REPORTINTERVAL <interval> <CA>
      REQUESTOR <individual> <CA>
      UPDATETYPE <updatetype> <CA>

CA AND CA2 NOT EXPLAINED SOON ENOUGH

References:

(DHC JBP RFC 539 -- 17644,3a:gy)

Discussion:

Agreed 💅

CHANGE 'INTERRUPT' TO 'URGENT' OR 'PRIORITY'

References:

(DHC JBP RFC 539 -- 17644,3e:gy)

Discussion:

Agreed 🔥 How about 'URGENT' 👑

CARRY STATIC/DYNAMIC ATTRIBUTE DISTINCTION INTO FORMAL SYNTAX

References:

(DHC JBP RFC 539 -- 17644,3i:gy)

Discussion:

Agreed 🦋

CRYPTIC DEFAULT DESCRIPTIONS

References:

(DHC JBP RFC 539 -- 17644,3k:gy)

Discussion:

Agreed 🫶

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Sergio Kleiman 12/99 ]

📦 where this page comes from