From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc555.txt | 619 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc555.txt (limited to 'doc/rfc/rfc555.txt') diff --git a/doc/rfc/rfc555.txt b/doc/rfc/rfc555.txt new file mode 100644 index 0000000..916e3cb --- /dev/null +++ b/doc/rfc/rfc555.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group James E. White (JEW) +Request for Comments: 555 SRI-ARC +NIC: 17993 July 27, 1973 + + + Response to Critiques of the Proposed Mail Protocol + + A number of people have responded to my proposal for a Mail Protocol + (JEW RFC 524 -- 17140,2:y). In the current RFC, I've attempted to + collect and respond to the questions, complaints, and suggestions + that various individuals in the Network community have offered. I + intend to critique myself in a forthcoming RFC. + + I hope that dialog on the protocol proposal will continue, and that + others will join in the discussion. I will respond via RFC to any + additional critiques I receive (I hope there'll be many). + +I. QUESTIONS + + HOW DOES THE SERVER VERIFY AN ID? + + References: + + (DHC JBP RFC 539 -- 17644,3g:gy) + + Discussion: + + One postulates the existence of AT LEAST ONE host whose Mail + server process implements the User Verification Function (JEW + RFC 524 -- 17140,5f7:gy). Any process can contact that server, + give him the name of any Individual in the Net and a test Id, + and the server will determine whether or not the Individual and + Id agree. + + The NIC, for one, will without question provide this + service. + + With such support available to it, ANY FTP server process can + then require (of any or all user processes that contact it) an + ID command wherever it wishes within the user-server + interchange (within the constraints of the Protocol). The + server simply prompts for the Id, gets it, opens a connection + to the User Verification Agent, presents to it the Individual's + name and purported Id, receives a positive or negative + response, and deals with the original user process accordingly. + + + + + + +White [Page 1] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + Example: + + Suppose a user process opens a connection to UCLA-NMC's + server process, invokes the Delivery function, and in the + course of the interchange identifies the Author as Roberts + at USC-ISI. + + The implementors at UCLA-NMC's server process chose to + require proof, in all Delivery transactions, that the Author + is who he claims he is. It therefore prompts for an Id in + response to the AUTHOR command from the user process, and + receives in return the command 'ID arpawheel '. + + UCLA-NMC's server then connects to the NIC's server, invokes + the User Verification function there, specifying 'REQUESTOR + roberts @ usc-isi ' and 'ID arpawheel '. The NIC + informs UCLA-NMS that the Id is incorrect. + + UCLA-NMC then rejects the original ID command. + + Of course, the Protocol does not require that a server demand + Ids from users that contact it. Servers who choose not to + require proof of identity simply never prompt for ID commands, + and treat any they receive as NOPs. For such implementations + (which represent the current, FTP mail protocol situation), no + third-part interchanges are ever required. + + Each user in the Net has a single Id that he uses throughout + the Net for purposes of sending and receiving mail. That Id + need not (but may, either coincidentally or by design) have any + other use. In particular, a user's Id is independent of the + passwords by which he gains access to accounts that he might + possess on hosts around the Net. + + Of course, a user could and might see to it that his + passwords and Id are the same. The NIC, for example, might + require that a user log in to its system with NIC ident and + Id, rather than with host name and password, as it does + currently. + + I emphasize again that Ids have nothing whatsoever to do with + accounting. UCLA-NMC doesn't force the Author to prove his + identity so UCLA has someone to whom it can bill the resources + consumed in processing the Delivery transaction. It does so to + prevent Jim White from authoring a piece of mail and claiming + that Larry Roberts wrote it. + + + + + +White [Page 2] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + UCLA-NMC does have the option of requiring that a user + process log in before it delivers mail so that it can be + billed for the resources it uses. The appropriate commands + to require of the user process are USER, PASS, and ACCT. + But, the billing process is separable from that of + identifying Author, Clerk, etc. + + The NIC, for example, in its role as a Distribution Agent, + might establish 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 when the NIC delivers + a piece of mail it claims was authored by Larry Roberts, + UCLA-NMC may still wish to verify that claim. Hence the ID + command. + + ACK, PROGRESS REPORT, OR REPLY WITH NO REFERENCE SERIAL NUMBER + + References: + + (DHC JBP RFC 539 -- 17644,3h:gy) + + Discussion: + + A Delivery of type POSITIVE or NEGATIVE ACKNOWLEDGMENT, + PROGRESS REPORT, or REPLY requires a Reference Serial Number of + the user process. Should the server determine that one is + lacking when the final EXIT command is given, he should reject + the EXIT command with an appropriate error response. + + The same applies in the Distribution function: a Reference + Serial Number MUST be specified if the Delivery Type is + REPLY. + + The Protocol document is deficient in that it doesn't state the + above. + +II. COMPLAINTS + + TERMINATING BOTH THE SUBSYSTEM AND FUNCTIONS WITH EXIT + + References: + + (AAM -- 17404,) + + + + + + + + +White [Page 3] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + Discussion: + + I have no objection to defining two terminating commands, one + to exit a function, the other to exit the subsystem. I guess + I'd suggest defining a command 'GO ' to be used to + terminate a function. + + I don't believe, however, that's it's necessary to distinguish + the two cases to avoid confusion by human users. + + Even though the command language is ASCII, rather than binary, + and even though I've adopted Mike Padlipsky's concept of a + Unified USER Level Protocol', I don't consider that MP is a + protocol for direct use by humans (although nothing can STOP a + human user from speaking MP if he has access to a TELNET user + program and is determined to do so). + + The concept I mean to extract from the UULP and exploit is its + model of a single process with many subsystems, not its + philosophy of a Network-standard command language for use by + human users (the latter may be a good idea, too, but it's not + the one I'm concerned with at the moment). + + I don't think that designing a protocol to govern an exchange + between processes is the same task as designing a protocol to + mediate a conversation between a process and a human user. + Using ASCII commands suggests (as it did for FTP, RJE, etc.) + that the latter problem is the one being addressed; 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 mistake. + + I simply have a strong distaste for the current FTP convention + of terminating commands whose argument may itself contain CR LF + with 'CR LF . CR LF'. That seems a little extravagant to me. + Personally, I'd prefer a single NVT character as a delimiter. + + + + +White [Page 4] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + only terminates two MP commands (COMMENTS and TEXT). + Some NVT character (ESC? EXT? ...) can easily be chosen that + need not appear (and can therefore be prohibited from appearing + by the Protocol) in the argument to either of those commands. + + SUBSYSTEM OR SEPARATE RJE-LIKE SERVER PROCESS + + References: + + (DHC JBP RFC 539 -- 17644,4a:gy) + + (AAM -- 17404,) + + (ADO RFC 552 -- 17809,3:y) + + Discussion: + + There are two separable issues here: + + (1) Server Process Proliferation of Not? + + If the consensus of the Network community is that + Padlipsky's UULP approach to protocol design and + implementation is in fact superior to the current scheme, + which calls for the implementation of each new Network + protocol as a distinct server process with its own + contact socket, then we should begin to embrace that + concept and begin reshuffling existing protocol + implementations accordingly. Even more surely, NEW + protocols (like MP), should be designed in accordance + with the new standards, not the old. + + I think Buz Owen's suggestion (ADO RFC 552 -- 17809,3:y) + -- that a skeletal UULP be defined, a socket assigned to + server processes which implement it, and MP defined as a + subsystem under it -- is excellent. I retract my + suggestion (JEW RFC 524 -- 17140,3a2:gy) in favor of + Owen's. + + I further suggest that the latest revision of FTP (NJN + RFC 542 -- 17759,) be similarly implemented (i.e., as a + UULP subsystem), rather then implemented temporarily + under a new socket and later moved over to socket 3 as + suggested in RFC 542. + + + + + + + +White [Page 5] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + (2) RJE's model for FTP Use or Not? + + If both MP (as currently defined) and RJE were instated + as UULP subsystems, they would still embrace different + philosophies regarding their use of FTP. As the person + who proposed and fought for the current RJE model (i.e., + to its use of FTP), I (still) believe it to be an + elegant one, more elegant by far then the one I've + proposed for MP. + + An alternative I considered and discarded SOLELY for + reasons of efficiency (neglecting, perhaps, the issue of + cleanness of implementation), is that the command + currently defined as 'FILE ' (JEW RFC 524 -- + 17140,4q2a:gy), both in specifying Content and in the + Citation Retrieval function, be 'FILE ' + 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, except that the former would specify + JUST Content (and none of the other Static Attributes), + and that the Server must retrieve the file (which may be + a temporary file created by the user process) in real + time, i.e. BEFORE it sends its response to the FILE + command. + + This alternative eliminates 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 allows + the user process the flexibility of specifying a file at + a host other than his own. + + After some thought, I think I agree with Crocker and + Postel that theirs is the better implementation. + + As they point out, however, this implementation + introduces the problem of somehow reconciling the + desire to permit (in general) the transfer of mail + files without requiring a login, with a server's + inability to distinguish that case from the general + case of file retrieval (for which many hosts will + require a login). + + + + + +White [Page 6] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + 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 does not, as Crocker and Postel state, impose an + order upon command specification within a function (see for + example, JEW RFC 524 -- 17140,5f1b:gy). + + Having considered their suggestion only briefly, it does seem + to me appropriate to impose some constraints on the order of + parameter specification by the user. Off hand, the order + suggested -- Dynamic, Optional, Static -- seems good. + +III. SUGGESTED ADDITIONS + + FORWARDING AT DELIVERY TIME + + References: + + (DHC JBP 539 -- 17644,4b:g) + + Discussion: + + Including provision for the forwarding of mail at Delivery Time, + in contrast to sometime after Delivery in response to a specific + Forward request (i.e., function), seems to me a useful addition to + the Protocol. + + As Crocker and Postel note, only one of the three mechanisms for + such forwarding bears upon the Protocol (although the Protocol + might mention the other two and either encourage or discourage + their use). + + I suggest the following reply format, however, rather than the one + suggested by Crocker and Postel (DHC JBP RFC 539 -- + 17644,4b3c2:gy): + + + + +White [Page 7] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + 476 -- 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: + + I see no value to defining numeric shades of urgency, + unless the Protocol suggests some particular action the + server might take in response to each one. + + The whole notion of flagging some pieces of mail as + urgent seems to me 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 apt to read the mail. If one + accepts that argument, there's clearly no point to + defining shades of urgency if they have meaning only to + the human recipient. True, any pair of human users + could privately agree on meanings, but it seems to me + preferable 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. + + + + + +White [Page 8] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + +IV. META-COMMENTS + + SIZE OF THE PROTOCOL DOCUMENT + + References: + + (RCC -- 17822,1e:gy) + + Discussion: + + I offer an apology for the format of the the Protocol document. + It differs radically from that of previous Protocol documents + (e.g., FTP, RJE), and is certainly not tutorial in its + orientation. The glossary is a device I found useful in + designing the Protocol. If the substance of the Protocol were + agreed upon, then friendlier documentation would have to be + written. The choice of approach was greatly affected by my own + time constraints. + + As I find time, I would like to define the minimum + implementation subsets that Clements requests. For the moment, + consider the command breakdown below. It represents the case + where the server permits only the function by which mail is + delivered to users in his host. It has the following + 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 + To invoke the Delivery function: + DELIVER + + + +White [Page 9] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + To specify the text of the message: + FILE + LOCATION + TEXT + To identify author(s), recipient(s), and title: + AUTHOR + RECIPIENT + 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> + + + +White [Page 10] + +RFC 555 Response to Critiques of Proposed Mail Protocol July 1973 + + + 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 ] + + + + + + + + + + + + +White [Page 11] + -- cgit v1.2.3