Date: 3 July 1979 19:19-EDT From: Ken Harrenstien Subject: Internet addressing format? To: Header-People at MIT-MC I just learned that apparently the internet working group intends to use the format "-@" for internet addressing. I vaguely recall reading something about this earlier but forget exactly where. I've also been extremely preoccupied with getting "Deafnet" on the air, so might have missed some exchanges. Does anyone know much about this? My first reaction to this idea was quite simple: "Ugh!". I can imagine some reasons why it might be desirable for some people, but can also imagine other reasons why it would be undesirable for others. Hmmm. Re-considering, perhaps a better word is "Blorg". I would appreciate any attempts to mollify my viewpoint or support same. --Ken  Date: 3 JUL 1979 1650-PDT From: POSTEL at USC-ISIB Subject: re: internet address format To: Header-People at MIT-MC Ken: i think you got a hold of the some confusing data. the true facts are closer to the following (which you probably won't like either): 1) as a temporary hack, the existing network mail software should be able to handle user addresses of the form "USER@NET-HOST", where NET-HOST is a name that translates to a 32 bit internet host number (8 bits of net, 24 bits of host, see RFC755 for assigned net numbers). 2) it is recommended that in the long term user interface software for programs that deal with the internet use the form "!NET!HOST" for network and host names. If such an argument is to be further qualified by a user name or a program name the obvious extension is "!NET!HOST!USER" or "!NET!HOST!PROGRAM". If Header People want to learn more about "the internet" try snarfing copies of the Internet Experiment Notes (IENs). They are like RFCs but cover the internet development. Recent notes are online at the NIC, and most all of them are stashed in the Datacomputer. At the NIC they are in IEN-xx.TXT files and at the Datacomputer they are in IEN-xx.TXT files after one uses DFTP to get to the DC and attaches to "COMMON>IEN". --jon. -------  Date: 3 Jul 1979 1648-PDT Sender: GEOFF at SRI-KA Subject: Re: Internet addressing format? From: the tty of Geoffrey S. Goodfellow To: KLH at MIT-AI Cc: Header-People at MIT-MC Message-ID: <[SRI-KA] 3-Jul-79 16:48:36.GEOFF> In-Reply-To: Your message of 3 July 1979 19:19-EDT Reply-to: Geoff @ SRI-KA If that is the case, how would be send a message to header-people@mc? Wouldn't it then be translated into "user people" at the "mc host" on the "header network"?  Date: 4 July 1979 01:42 edt From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: foo at bar at frob at zork To: header-people at MIT-MC Message-ID: <790704054256.435786 at MIT-Multics> 1. There ain't no such thing as an interim implemenation. Once the internet format for address is established that is it!!! Especially if it is ever implemented by Hermes!! 2. How do I address my Apple computer connected to my Prime computer that periodically dials into Multics to exchange mail with the University of Delaware via the Arpanet? I doubt that my Prime's dialup connection will get a net number, especially with a precious 256 nets allowed in this universe. Neither will my Apple, TRS-80, PET, Atari etc be worth assigning a universal host number out of the limited 16,000,000 numbers available. I would like to send mail to Bob at Apple-1 at SAI_Rime at MIT-Multics via ARPANET (via and at are interchangable, just changed for readability) I am not being fanciful, all the machines in the above example exist and will communicate! At least if the protocols allow for it! 3. I will try to get around to reading the accumulate memos on internetworking and apologize if the issues are dealt with adequately in the memos, but I am skeptical in light of the immediate problems that crop up in attempting to apply the proposed form to existing configuarations of systems. 4 A last comment. The discussions of internetworking concentrate on communications between host pieces of iron. The communication is really between logical entities -- processes in common terminology which don't have as static a configuartion as the current Arpanetwork.  Date: 4 Jul 1979 0613-PDT From: Mark Crispin Subject: inter-network addressing To: Header-People at MIT-MC It is moderately reassuring that we won't see NET-USER@HOST. I am not, however, convinced that USER@NET-HOST is a good idea, nor am I in love with the exclamation mark format. Why are these design decisions being made without consulting the general community, or even those who are doing multi-network research presently? For whose benefit are these decisions? I have the impression that this is all to support the old Tenex host table and software, instead of trying to break new ground. Please let's not hear people complaining about "Tenex taking over the world" - on my Tops-20 system I started a redesign and rewrite of the network software along the lines of the Stanford/MIT host table described in an RFC earlier this year. It isn't the function of a particular operating system, but rather of trying to maintain ancient software into eternity. Are we talking about mail systems throughout the network when we mention "existing network programs", or are we talking about SNDMSG? The way I am implementing my multiple-network support is to have the host table know about every host on every network (a lie if ever there was one!). A host has a unique name throughout the universe, although it may have many nicknames (also unique of course). The software which decides the data path through which a message should be delivered has various built in parameters about the desirability of various paths, including their cost, functionality, reliability, and access authorization. Through some hair which hasn't been completely thought out yet (so far I'm only worrying about three networks at a time), it decides on the best path and tries to use it. The initial implementation I am starting on uses a contention method. As a simple example, let's talk about mail from SU-SCORE to SU-LOTS. Both sites implement Dialnet, as does SU-AI, which is on the Arpanet along with SU-SCORE. There are therefore two processes who contend for the right to send the message; the Dialnet process at SU-SCORE, and the Arpanet process to SU-AI who will pass it on to SU-AI's Dialnet process to SU-LOTS. The SU-SCORE Dialnet process would try to grab the message first, as it knows it can do the best job in delivering the message. But suppose the SU-SCORE Dialnet port is in use by another process. The SU-SCORE Arpanet process would then try to send it to SU-AI, who could either accept it or say "my port is busy too, maybe you want to hold on to it". The idea makes more sense as the number of paths increases. You can reasonably assign priority values for a certain process to handle traffic to a certain ultimate destination. The contention would be "first grab first get", with the additional parameter that a process whose priority is n can only try to grab traffic older than m, etc. There are other considerations which hair it up a bit - is this traffic authorized to use the Arpanet? Is this traffic going to pay the phone bill? etc... Under this scheme, I don't use a specific network at all! Just USER@HOST. My smart mega-buck computer is supposed to figure out how to get the message there. I don't say this way solves all things, but it's interesting to think about. Mark -------  Date: 4 July 1979 11:42 edt From: Frankston.Frankston at MIT-Multics Subject: Re: inter-network addressing To: Mark Crispin cc: Header-People at MIT-MC In-Reply-To: Msg of 07/04/79 09:13 from Mark Crispin Mark, I agree that it is nice to have systems which take care of details of getting mail from point A to point B. But. I do not like systems that are restrictive about points A and B. Does your scheme allow any alternative to using the central and centrally administered tables for sending mail? If I want to send mail to a destination via a third host C, which your tables know about, but with a final desintation of B, of which your host is not aware? Can I say "send mail to B via C"? or does it require intevention by the system admnistrater. Also, is your scheme susceptable to the NxN problem where all hosts must Know about all other hosts -- soon to be a 100000 of them (not counting telephones)? My basic dislike of any scheme for which I must go through a central registration process is that I will be personally penalized since I will rapidly fall into the class of users make disproportional use of the unusal cases requiring intervention by the admInistrators and secondly I do not want to be in a position where others judge the appropriateness of my requests--something inevitable ina beauracracy.  Date: 5 Jul 1979 0018-PDT From: Mark Crispin Subject: inter-network addressing To: Frankston.Frankston at MIT-MULTICS Cc: Header-People at MIT-MC At the present time the design has not been committed to stone. I don't see the administrative problems. Maybe it's because it has been a long time since I have had to deal with THAT oppressive a bureaucracy. I just don't feel that in the normal case the user should have to be bothered with routing considerations. As I said I don't claim that this is the ultimate right thing, but rather what seems to be the right thing for our immediate need. We have seven -10 systems at Stanford - two Tenexs, one WAITS, Three Tops-20s, and a new machine which may be Tenex or Tops-20. We have several -11's and other machines, including the IBM 3330 (or 3033 or whatever they call the thing. It's the one that replaces a 370). We have Arpanet, Dialnet, Ethernet, DECnet, and innumerable little private hookups; and we want these people to all talk with each other (well, maybe not the IBM machine and DECnet - they're a different world at Stanford). From a wizard's point of view, there will have to be a method to force explicit specification of routing, else it would be difficult to debug the communications protocols, etc. I do want to spare the user this nonsense whenever possible. The right thing for host information seems to be to have some sort of central service whose sole functin in life is to know how is connected to who. Possibly in the implementation in the sky this thing would also figure out the routing. It still needs a lot of thought and the ideas are bound to change a lot before it is finally implemented. Mark PS Forgive the typos. I am in a hotel in San Francisco at Westercon using this primitive TInoisy terminal. Sigh. -------  Date: 5 Jul 1979 0905-PDT From: Feinler at SRI-KL (Jake Feinler) Subject: Re: inter-network addressing To: Admin.MRC at SU-SCORE, Header-People at MIT-MC cc: FEINLER In response to the message sent 4 Jul 1979 0613-PDT from Admin.MRC@SU-SCORE Mark, I believe there is a flaw in your statement that each host has a unique name in the universe. This is not necessarily true. There may be many occasions where two or more hosts can have the same name on different networks. What should be universally unique is the host address. That is, no message sent to a given address should be delivered in several places due to conflicting addresses. Jake -------  Date: 5 Jul 1979 1824-PDT From: Mark Crispin Subject: inter-network addressing To: Feinler at SRI-KL Cc: Header-People at MIT-MC Jake, I think you have missed my point. I don't claim that my scheme is an end-all. Obviously if the powers that be are intent upon allowing a chaos of names to occur, then the world will be stuck with numbers (aka "network addresses" of ever increasing magnitute). I don't see why this has to be that way. I don't think the way I proposed if the ultimate right thing - far from it! But I think it is a closer step in the right direction. I don't think that explicit routing instructions are desirable, nor do I feel they are necessary. I was presenting as an example a very local scheme - unifying the communications networks used at Stanford (for the most part anyway). Perhaps MIT will do this with their Chaosnet - I believe the "SUPDUP" display TELNET there uses contention to get to the other host. I may be wrong (MIT hackers please correct!) but as I understand it it first tries Chaosnet and then Arpanet. I think that a similar thing can be done with daemon processes, although on a more advanced level. I believe that host names can be kept unique and should while they still are (for the most part anyway). I hope they are. Mark PS Excuse typos - still using the TInoisy. -------  Date: 5 JUL 1979 2151-EDT From: MOON at MIT-MC (David A. Moon) Subject: Supdup, multi-networking, MRC's contention To: HEADER-PEOPLE at MIT-MC The contention Mark might have been thinking of is in the Chaosnet routing algorithm (at the NCP level), not in any existing higher-level protocol. Also it's not the same as what he describes. The ITS supdup program does not use contention. It knows how to use two networks (Arpanet and Chaosnet), and chooses the (statically) faster of the two, unless it is constrained to use a particular network by the site it's running on, the site it's trying to get to, or a specification by the user. It does not take into account one network being down or unusually-heavily loaded. Nor does it take into account the case of the site it's on and the site it's trying to get to not being on some single network. The supdup program (and others) on the Lisp machine knows it's always on the Chaosnet, and knows that on that network it can find a gateway to the Arpanet, which it uses if you connect to a host which is not attached to the Chaosnet. None of this is sophisticated enough to qualify as a model for general internetwork use. Nor have we dealt with internetwork host naming at the "mail" level; we are waiting for some group such as the internet group to come up with a viable proposal (although this hope certainly seems vain at this point.)  Date: 5 JUL 1979 2050-PDT From: POSTEL at USC-ISIB Subject: re: foo at bar at frob at zork To: Header-People at MIT-MC Bob Frankston: i agree. 1) interim things do have a way of turning permanent. so we need to avoid being in an interim state for very long. RFC753 (aka IEN85) is a first draft attempt to guess at what the future should be. Please send me any further comments you may have. 2) the number of things to act as sources and sinks for packets and or messages is going to be huge, and no central authority will know about them all. any naming scheme will have to be hierarchical, but the interconnection of these things will not follow any hierarchy, so the kind of address as "address as route" will have to be allowed. This type of address is called "source routing" in some of the literature. 3) the internet group is focusing on experiments in the networks that arpa controls or has strong influence over. It turns out that this is a small number so it is hard to press a case for super generality in the face of the need to get some experiments working. 4) process are the ultimate sources and sinks of the data, all this stuff we build (layers of protocol) amount to an interprocess communication system. --jon. -------  Date: 6 July 1979 2334-edt From: Bob Frankston Subject: inter-network addressing To: Admin.MRC at SU-SCORE Cc: header-people at mit-mc I agree that automatic routing is nice and necessary. I a am just afraid of its being the only choice.  Date: Sat, 7 Jul 79 15:13-EDT From: Dave Crocker Reply-to: Dave at Rand-Unix Subject: Use of "Udel-EE" as hostname To: Header-People at Mit-Mc cc: Farber at UDel-EE Message-ID: <79187.54810.3701 @ UDel-EE> We would like to stop using the Reply-To mechanism for telling respondants what address to really reply-to, given that UDel-EE isn't a host on the net, but we first need to check if all the major (and as many minor as possible) hosts have us aliased with Rand-Unix. Any of you out there NOT have us in your tables (UDel-EE as decimal host number 199)? Thanks. Dave.  Date: 7 Aug 1979 1544-PDT From: Mark Crispin Subject: strange headers To: Header-People at MIT-MC Look at this header! It blew the mind of my mail reader --------------- Mail from CMU-10A rcvd at 7-Aug-79 1206-PDT Date: Tuesday, 7 August 1979 1502-EDT From: Ivor Durham Subject: RFC 441 Sender: TF00 at CMU-10A (F100TF00) To: Feinler @ SRI-KL CC: Admin.MRC @ SU-SCORE Reply-To: The Finger at CMU-10A (The Finger (F100TF00)) Message-ID: <07Aug79 150213 TF00@CMU-10A> -------  Date: Tuesday, 7 August 1979 1857-EDT From: Brian.Reid at CMU-10A Subject: Re: strange headers To: Mark Crispin CC: Header-People at MIT-MC Message-ID: <07Aug79 185715 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 7 Aug 79 17:44-EST Bizzarre but legal. That header must have escaped while we were testing Rdmail.  Date: 3 SEP 1979 2117-EDT From: MOON at MIT-MC (David A. Moon) Subject: Forwarded message from Lauren Weinstein To: HEADER-PEOPLE at MIT-MC Date: 3 Sep 1979 1231-PDT (Monday) From: lauren at UCLA-Security (Lauren Weinstein) Subject: mailing lists To: BUG-FTP at AI I am not sure who this message should be directed to, so I am sending it here in the hope (you) will forward it to the correct entity. One of the biggest problems I've seen with mailing lists around the net (especially the automatic repeater type) is the message traffic generated by people wanting on/off the lists. We see continual messages concerning "please don't send to the list, send to FOO for such matters", but it never really does any good -- for an obvious reason: people don't remember the maintainers generally, and new people only know about the list and have nowhere else to go. I have a suggestion concerning this problem. How about setting up a universal alias for the maintainer of a mailing list that is related to the mailing list name? That is, the info-terms list might be maintainted by: "info-terms-maint" or whatever. This suffix or whatever would be widely advertised (like through MSGGROUP, etc.) and would eventually be generally expected and known. I would even suspect that at many sites it would not be particularly hard to implement (though getting it set up for the currently existing mailing lists at ITS sites would be a one-time pain of course). What do you think? I'd appreciate comments and forwarding of this message to interested parties -- I think this is a problem whose time has come. --Lauren-- -------  Date: 4 September 1979 1647-EDT From: David Lamb Subject: case distinctions in mail destinations Sender: RdMail at CMU-10A To: header-people at mit-mc Reply-To: RdMail at CMU-10A Message-ID: <04Sep79 164735 RD00@CMU-10A> I have recently been told that some mailers out there consider mail names to be different if they have different case (e.g., Lamb and LAMB would be different names). This note is to (a) ask you folks to verify whether this is true and (b) suggest that this sort of distinction is a bad idea. This came up in the context of RDMAIL's duplicate-removal code. Suppose I receive mail of the following form To: Lamb at CMU-10A From: Person at Site1 CC: PERSON2 at Site1, PERSON at Site1 By default, when I reply to this I send CC's to everyone in the original CC field, giving From: Lamb at CMU-10A To: Person at Site1 CC: PERSON2 at Site1, PERSON at Site1 A few weeks ago RDMAIL was modified to send only one copy of the mail to PERSON at Site1 (it leaves the CC field alone, unlike some mailers that would have eliminated the occurrence of PERSON there). However, some people claimed that I wasn't allowed to do this, because Person and PERSON could be different. The harder problem is, unless we are willing to record properties of all mailers on all sites, the fact that some random site on the net insists that PERSON and Person are different means that two sites which case-fold all names are stuck with getting duplicates, even though their own mailers can handle the situation. On the strength of the complaint, we took case-folding out except for mail to other CMU hosts. I would like to put it back in. How many of you out there would be grossly inconvenienced by this? David Alex Lamb  Date: Tuesday, 4 September 1979 1717-EDT From: Richard H. Gumpertz Subject: Re: case distinctions in mail destinations To: David.Lamb at CMU-10A CC: header-people at mit-mc Message-ID: <04Sep79 171749 RG02@CMU-10A> In-Reply-To: <04Sep79 164735 RD00@CMU-10A> another question to append to David's question: if the names can be considered equivalent, then which name should be retained? Rick Gumpertz  Date: 04 Sep 1979 1443-PDT From: Mark Crispin To: Header-People at MIT-MC My feeling is that PERSON and Person should be considered identical, and it is a bug in any operating system which insists that PERSON and Person are different. I believe that even Multics' mail server was fixed to figure out that PERSON meant Person and did the right thing.  Date: Tuesday, 4 September 1979 1839-EDT From: Brian.Reid at CMU-10A Subject: Re: case distinctions in mail destinations To: RdMail at CMU-10A CC: header-people at mit-mc Message-ID: <04Sep79 183946 BR10@CMU-10A> In-Reply-To: <04Sep79 164735 RD00@CMU-10A> "a" and "A" are the same letter, and anybody who thinks otherwise it completely wedged.  Date: 4 September 1979 19:07-EDT From: Earl A. Killian Subject: case distinctions in mail destinations To: Brian.Reid at CMU-10A cc: HEADER-PEOPLE at MIT-MC, RdMail at CMU-10A Date: Tuesday, 4 September 1979 1839-EDT From: Brian.Reid at CMU-10A To: RdMail at CMU-10A cc: header-people Re: case distinctions in mail destinations "a" and "A" are the same letter, and anybody who thinks otherwise it completely wedged. Anyone who makes such sweeping generalizations is completely wedged.  Date: 4 September 1979 22:39-EDT From: Ken Harrenstien Subject: case distinctions in mail destinations To: RdMail at CMU-10A, header-people at MIT-MC As with so many other topics, this one was likewise beaten into the dust back in the early days of Header-people. If you have a copy of the archives, search on appropriate keywords like case-independence... My views haven't changed since. It's not surprising that the expected problems have manifested themselves.  Date: 4 Sep 1979 8:58 pm (Tuesday) From: Karlton at PARC-MAXC Subject: Re: case distinctions in mail destinations In-reply-to: <04Sep79 164735 RD00@CMU-10A> To: RdMail at CMU-10A cc: header-people at mit-mc, David.Lamb at CMU-10A David, Some mailers out there consider the names different. That should be enough for you to make sure that names don't get thrown away if that raises the possiblity that some mail might be lost. You can, however, take advantage of the special knowledge that CMU does case folding for delivery, and remove duplicates (except for case) to CMU sites. It is not a very serious thing to send duplicates to a user at a remote site because the names are spelled differently. The mail delivery program (or even the reader) might be able to figure out that it can chuck the duplicates and the recipient will never notice. If not, the user will not be very inconvenienced. The "right" thing will usually happen (i.e. no differenly capitilized names will be in the same mailing); but, when it doesn't, it is best to error on the side of not losing anything. PK  Date: 4 SEP 1979 2113-PDT Sender: POSTEL at USC-ISIB Subject: Re: case distinctions in mail destinations From: POSTEL at USC-ISIB To: Karlton at PARC-MAXC, RdMail at CMU-10A Cc: header-people at MIT-MC, David.Lamb at CMU-10A Message-ID: <[USC-ISIB]4-SEP-79 21:13:24-PDT.POSTEL> In response to the message sent 4 Sep 1979 8:58 pm (Tuesday) from Karlton@PARC-MAXC the mail program i use has the novel feature of asking the user! every once in a while i am asked if PERSON is the same as Person and it almost (what a word) always is. --jon. -------  Date: Wednesday, 5 September 1979 0057-EDT From: Richard H. Gumpertz Subject: Re: case distinctions in mail destinations To: David.Lamb at CMU-10A CC: header-people at mit-mc Message-ID: <05Sep79 005750 RG02@CMU-10A> In-Reply-To: <04Sep79 164735 RD00@CMU-10A> David - The more I think about it, you wil rarely get two names capitalized differently from foreign hosts in the kind of situation you are considering. Therfore I suggest that you just ignore the problem (i.e. err on the side of conserving the names as if different). As someone said, the consequences are not great at all if a duplicate arrives. Rick  Date: 4 Sep 1979 2137-PDT From: Mark Crispin Subject: case in names To: Header-People at MIT-MC I suspect most of the problem comes about when replying to a message originating at a TENEX or Tops-20 site. A user might have a cute form of his/her account name in the header, but the real account name is all upper case. For example, my account name is really "ADMIN.MRC", but I put "Admin.MRC" in my headers because I think it looks better. I think a couple of the TENEX/Tops-20 mail systems (not MM, which is what is in use here) reflect the user's desire to have CC's of all his/her messages as a flag and not as an address list. Therefore, when the mail system generates the header it puts in the CC list the account name, and not the user's cute form. Since TENEX/Tops-20 don't care about case, it makes sense to be case independant. How about these questions: What mailers out there consider PERSON and Person different? What systems actually have a PERSON and a Person as different users? I know, for example, that Multics has PERSON and Person as different entities, but I have been told that in real life they don't allow such conflicts to happen and that the netmail server is smart enough to do the appropriate mapping. No PDP-10 operating system has such a thing as Person as a different account name from PERSON. It IS theoretically possible on TENEX and Tops-20, but using it is so difficult as to be impractical (how would you like having to type control-V before every lower case character in your account ID?). The mail system in use at SCORE, MM, in fact does treat PERSON as Person and will continue to do so. I will resist that ever being changed. Case-invisibility is one of the most important human engineering features of all PDP-10 operating systems, and one of the easiest to export elsewhere. -------  Date: 9 September 1979 14:07 edt From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: name ~=name To: header-people at MIT-MC Message-ID: <790909180703.231030 at MIT-Multics> As pointed out this is an old topic. To restate my position briefly. 1. Since the recipient, using message-id's can eliminate duplication that should be sufficient. (Prvoided people finally begin to send message ids again). 2. If the mailer can decide that "RMF at mit-mc" and "bob at mit-multics" are both me as well as my other accept such an implementation. Those are the reasons I get duplicates. Actually the main reason for dupilcation is for things like a letter to info-micro with a cc to info-terms or something like that. Offhand I don't remember having to deal with Frankston vs FRANKSTON in headers, though that may have occured. The point is that why bother Implementating a program to deal with a trivial case when there is a chance of lossage. For example, JTAble.Foo and JTable.Foo on Mit Multics. If ther eis a network table entry then only one would get in as JTABLE (case not mattering). But if you want to send mail using a stndard Multics name.project hen cse does, and _s_h_o_u_l_d matter since your are then using Multics internal conventions. As we extend mail to other networks there will be other internal conventions to deal with and you better not go mucking around with headers that you don't know the rules for!  Date: 5 Oct 1979 1739-PDT From: Mark Crispin Subject: SAIL filenames for distribution lists To: Bug-MAIL at SU-AI cc: Header-People at MIT-MC The Tops-20 and Tenex MAILER daemon cannot parse SU-AI filename addresses like: "@FAC.DIS[1,DPB]" at SU-AI because this gets translated as a queued request to "@FAC.DIS[1,DPB]"@SU-AI and the first @ confuses it. While MM handles this alright MAILER is too dumb to, and it's up to MAILER to deliver the message. While I could make MAILER a little bit smarter with some work, it seems to me it would be better if you fix your mail system to send filespec addresses in some other way, or to make more estensive use of pseudo-people. "Better" here means for the benefit of other sites on the network. You can argue that this is legal RFC733 syntax and all that, but I doubt that the world is going to change to fix this bug, especially when only one host generates this format of address and the program which has trouble with it runs on many hosts. You cannot hope for everybody to change their versions of Tops-20/Tenex MAILER. I am told that other mail systems have problems with this kind of address too and that the overhead of parsing it correctly is too expensive to warrant fixing it. Unlike Tops-20 and Tenex, the SU-AI mail system DOES have pseudo-people, so I don't see any logical reason for not using it. I doubt anybody would use file mailing here if we had pseudo-people, which is why I'd rather work on implementing that instead of parsing @'s in site addresses. -------  Date: 27 Oct 1979 1919-PDT From: Mark Crispin Subject: spaces around at-signs To: Header-People at MIT-MC Is an address of the form "csl.dra @ su-score" legal? MM gets upset by this, thinking the address is local user "csl.dra " which does not exist (note that space is a valid although unlikely character in an account name on TENEX and TOPS-20). MM's understanding of the world is that "csl.dra at su-score" or "csl.dra@su-score" mean "csl.dra". It's the @ with whitespace that confuses it. The mailer which sent this address was CMU-10A's. If the form is legal, I would like to campaign for its removal. If we must have whitespace in an address let's use "at" instead of "@". -------  Date: 27 October 1979 2258-EDT From: David Lamb Subject: Re: spaces around at-signs Sender: RdMail at CMU-10A To: Mark Crispin CC: Header-People at MIT-MC Reply-To: RdMail at CMU-10A Message-ID: <27Oct79 225834 RD00@CMU-10A> In-Reply-To: Mark Crispin's message of 27 Oct 79 21:19-EST RFC733.TXT includes at least one example of spaces around at signs. Also, the BNF indicates that "@" is used in the same context as "at" (n.b. not " at "). It does say that the whitespace around the "@" should be removed if passing the host name through a gateway that doesn't conform to the standard. I conclude that the spaces are allowed by the standard. However, I am willing to consider trying to compress out the spaces in RDMAIL if the change turns out to not be too difficult. (No promises as to when). David Alex Lamb  Date: 28 Oct 79 14:42-EST (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: Re: spaces around at-signs To: Mark Crispin cc: header-people at Mit-Mc Message-ID: <79300.52943.9080 @ UDel-EE> In-Reply-To: Your message of 27 Oct 1979 1919-PDT "csl.dra @ su-score" is completely legal, syntactically; and I find it hard to believe that you want arbitrary linear white space to be illegal between lexical units. The state of the art hasn't been that baroque for several decades, Mark. Sounds like MM needs the fixing. Dave. P.S. to David Lamb: I would strongly recommend NOT changing RDMAIL, on this score (probably a pun, there). P.P.S. Perhaps it would be useful if I cite some of the relevant portions of RFC733, on this matter; it is clearly-enough worded that it is difficult to miss. Sectiofn III.B.3.a is titled "White space". (page 10 of the original document and page 350 in the protocol handbook): "...multiple linear white space telnet ascii characters... are treated as single spaces and may freely surround any symbol." and "wherever a member of the list of s is allowed, lwsp-chars may also occur before and/or after it." Both quotation appear in the original as all-upper case and the second quotation is in its own paragraph. D/  Date: 28 Oct 1979 1410-PST From: Mark Crispin Subject: spaces around at-signs To: DCrocker at RAND-UNIX cc: RdMail at CMU-10A, Header-People at MIT-MC Dave - I repressed a very strong desire to lash out at your message. Really. I don't think that anybody can expect a mail system to implement all of RFC 733. The network wonder-system, HERMES, not only doesn't implement all of 733 but in fact violates it in several places. MM tries to handle a reasonable subset, and in fact, it does. "foo @ bar" just ain't encountered all that often. MM would certainly never generate an address that looks like that, and it would be very hard for it to accept it on typein or a distribution list. TOPS-20's built-in command parser just wasn't set up for that sort of thing and it is in fact pretty remarkable that it can parse a network address at all. [Please - no nasty comments about how "baroque" this is or I will be glad to oblige you with several thousand words of flamage about the ways Unix loses.] If this was a major hardship upon a large number of network users to change their mail systems, that would be one thing. However, in this instant it did not seem that way. MM (and its DEC-distributed variant MS) does run on more systems than the CMU mailer. The maintainers of the CMU mailer graciously agreed to change their mail system. The thing is, we have sent mail to CMU before without a problem so obviously this is not CMU's standard format address but rather what comes out in some set of circumstances. It seems to be that the right philsophy is that if something unusual from one site breaks a mail reader at some number of other sites, then it's up to the site generating the offending format message to change their mail system to not do the offending thing, even if it IS part of the standard. Most people seemed to be concerned about communication first and cuteness (or revenge against somebody trying to limit the standard) last. By the way, Dave, is your mail system still generating the space in the blank line after the header? I could imagine somebody with your attitude on punishing those who don't implement the standard having a mail system that bounces such a blatant violation back to the sender with a CC to header-people, msggroup, the CIA, the FBI, the KCIA, the KGB, Senator Proxmire,... The possibilities are endless! -- Mark -------  Date: 28 Oct 1979 1416-PST From: Mark Crispin Subject: [Mailer Daemon : Undeliverable mail] To: Header-People at MIT-MC cc: DCrocker at RAND-UNIX Here's what happened to me when I tried to reply to Dave Crocker. Seems like somebody's FTP server is returning the wrong error code! --------------- Date: 28 Oct 1979 1413-PST From: Mailer Daemon Subject: Undeliverable mail To: ADMIN.MRC Mail for DCrocker at RAND-UNIX not deliverable because: Mail trouble, please try again later ------ --------------- -------  Date: Sunday, 28 October 1979 1741-EST From: Brian.Reid at CMU-10A Subject: RFC733 To: Mark Crispin CC: DCrocker at RAND-UNIX, RdMail at CMU-10A, Header-People at MIT-MC Message-ID: <28Oct79 174101 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 28 Oct 79 17:10-EST Since I played only an advisory role in its development, I feel free to mention that CMU's rdmail (really Philip Karlton's rdmail), as far as I know, implements all of RFC733, and can read any header that corresponds to that standard and a lot that don't. On the other hand, it was still being developed while RFC733 was being finalized, so it had a much better opportunity to be adapted to the full standard. Brian  Date: Sunday, 28 October 1979 1823-EST From: Brian.Reid at CMU-10A Subject: Re: [Mailer Daemon : Undeliverable mail] To: Mark Crispin CC: Header-People at MIT-MC, DCrocker at RAND-UNIX Message-ID: <28Oct79 182329 BR10@CMU-10A> In-Reply-To: Mark Crispin's message of 28 Oct 79 17:16-EST Actually, everybody's FTP server returns the wrong error codes. It's just one of those facts of life, like dirty air and dog droppings.  Date: 28 Oct 79 21:34-EST (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: Re: spaces around at-signs To: Mark Crispin cc: RdMail at Cmu-10a, Header-People at Mit-Mc Message-ID: <79300.77644.1541 @ UDel-EE> In-Reply-To: Your message of 28 Oct 1979 1410-PST I did not advocate everyone's being required to implement all of 733. I DID note the deficiency of a parser that can't handled something like white space around lexical units. Citing 733 was by way of making clear that a) it is legal in 733, and b) it is clearly explained. More to the point, you may not currently be encountering " @ " very often, but it is simply too trivial to generate for it to be reasonable to prohibit it. Some of our messages go out that way. Do not assume that because I use a Unix I am in love with all of] it and hopelessly biased against Twenex. The Unix mail-sending program that puts a space in the "blank" line separating headers from the body is not mine and never was. It was imported to Rand (from Berkeley?). Greep hacked on that program alot. He's indicated that he even once fixed the bug, but somehow it migrated back. To reiterate, the program in question (sndmsg) is not part of the older Rand MS system or the newer MH one. Dave.  Date: 29 OCT 1979 0246-EDT From: MOON at MIT-MC (David A. Moon) Subject: " @ " To: HEADER-PEOPLE at MIT-MC Please cease to fill my mailbox with unnecessary flaming. It was a bug and it took MMcM 30 seconds to fix it, once he was informed of its existence.  Date: Friday, 2 November 1979 1742-EST From: Richard H. Gumpertz Subject: Re: "Your" [in-reply-to field] To: JMCHUGH at USC-ECL CC: Header-People @ MIT-MC Message-ID: <02Nov79 174212 RG02@CMU-10A> In-Reply-To: JMCHUGH's message of 2 Nov 79 16:44-EST Well, it should be Rick Gumpertz' with no "s" after the apostrophe, but other than that you got the gist of what I was saying. Still, when a reply goes to other than the author I think it is important that the terms "you" and "your" not be used. Rick P.S. CMU RDMAIL will append just ' without an S!!!  Date: Saturday, 3 November 1979 1255-EST From: Philip L. Lehman (C410PL30) Subject: Re: "Your" [in-reply-to field] To: Richard H. Gumpertz CC: JMCHUGH at USC-ECL, Header-People @ MIT-MC Message-ID: <03Nov79 125524 PL30@CMU-10A> In-Reply-To: <02Nov79 174212 RG02@CMU-10A> Actually, Rick, I disagree. It SHOULD be "Rick Gumpertz's" WITH an apostrophe. The very first rule in Strunk and White (The Elements of Style(*)) is: "1. Form the possessive singular of nouns by adding 's. "Follow this rule whatever the final consonant. Thus write, Charles's friend Burns's poems the witch's malice "Exceptions are the possessives of ancient proper names [ending] in -es and -is, the possessive Jesus', and such forms as for conscience' sake, for righteousness' sake." Alas, writing and usage today are dictated mostly by personal whim, and anything goes. I actually think the "'s" code should be removed from RDMAIL, since it's unlikely that Jesus will LOGIN in the near future. Philip (*) Published by MacMillan. A small paperback, now in its third edition, and well worth the price -- whatever it is. I believe it's still an incredible bargain at $1.95!  Date: 5 November 1979 03:48-EST From: Mike McMahon Subject: Re: "Your" [in-reply-to field] To: Philip.Lehman at CMU-10A cc: HEADER-PEOPLE at MIT-MC "1. Form the possessive singular of nouns by adding 's. Ah, but there is no assurance that the field being replied to is singular, e.g. From: The Smiths  Date: 5 Nov 1979 14:50:24 EST From: Dan Franklin Subject: Re: in-reply-to field To: Philip.Lehman at cmu-10A Cc: header-people at mit-mc However, the rule for nouns and proper nouns is not necessarily the same as the rule for proper names - a case which the Chicago Style Manual ('A Manual of Style', The University of Chicago Press), distinguishes: (p. 78) 117. Form the possessive of a proper name ending in s or another sibilant, if monosyllabic, by addinng an apostrophe and s; if of more than one syllable (except names ending in -ce), by adding an apostrophe only (see sections 176 and 177 for other rules ...): Burns's poems Jesus' birth Berlioz' compositions Marx's theories Moses' law Demosthenes' orations Sophocles' stories conscience' sake Horace's odes Exceptions But in the case of a proper name ending in a silent sibilant the possessive is formed by the addition of the apostrophe and s, whether the word is monosyllabic or not: Charlevoix's discoveries Des Moines' population This rule would produce Gumpertz' because Gumpertz is polysyllabic. (The 'other rules' mentioned above describe the rules for nouns and agree with Strunk and White.) On the other hand, the 'Manual of Style' appears to be trying to rationalize what are essentially historical differences, judging from 'A Dictionary of Modern English Usage', by H. W. Fowler: (p. 466, under 'possessive puzzles') I. Septimus's, Achilles'. It was formerly customary, when a word ended in -s, to write its possessive with an apostrophe but no additional s, e.g. Mars' hill, Venus' bath, Achilles' thews. In verse, and in poetic or reverential contexts, this custom is retained ... But elsewhere we now usually add the s and the syllable -- always when the word is monosyllabic, and preferably when it is longer, Charles's Wain, St. James's Street, Jones's children, the Rev. Septimus's surplice, Pythagoras's doctrines. So the real question is whether the In-Reply-To: field is 'poetic or reverential' or not. If so, Rick is right.  Date: 5 Nov 1979 14:50:24 EST From: Dan Franklin Subject: Re: in-reply-to field To: Philip.Lehman at cmu-10A Cc: header-people at mit-mc However, the rule for nouns and proper nouns is not necessarily the same as the rule for proper names - a case which the Chicago Style Manual ('A Manual of Style', The University of Chicago Press), distinguishes: (p. 78) 117. Form the possessive of a proper name ending in s or another sibilant, if monosyllabic, by adding an apostrophe and s; if of more than one syllable (except names ending in -ce), by adding an apostrophe only (see sections 176 and 177 for other rules ...): Burns's poems Jesus' birth Berlioz' compositions Marx's theories Moses' law Demosthenes' orations Sophocles' stories conscience' sake Horace's odes Exceptions But in the case of a proper name ending in a silent sibilant the possessive is formed by the addition of the apostrophe and s, whether the word is monosyllabic or not: Charlevoix's discoveries Des Moines' population This rule would produce Gumpertz' because Gumpertz is polysyllabic. (The 'other rules' mentioned above describe the rules for nouns and agree with Strunk and White.) On the other hand, the 'Manual of Style' appears to be trying to rationalize what are essentially historical differences, judging from 'A Dictionary of Modern English Usage', by H. W. Fowler: (p. 466, under 'possessive puzzles') I. Septimus's, Achilles'. It was formerly customary, when a word ended in -s, to write its possessive with an apostrophe but no additional s, e.g. Mars' hill, Venus' bath, Achilles' thews. In verse, and in poetic or reverential contexts, this custom is retained ... But elsewhere we now usually add the s and the syllable -- always when the word is monosyllabic, and preferably when it is longer, Charles's Wain, St. James's Street, Jones's children, the Rev. Septimus's surplice, Pythagoras's doctrines. So the real question is whether the In-Reply-To: field is 'poetic or reverential' or not. If so, Rick is right.  Date: 5 Nov 1979 1336-PST From: Zellich at OFFICE-1 Subject: Re: in-reply-to field To: Header-People at MIT-MC In reply to the message from Dan Franklin, 5 Nov 1979 14:50:24 EST The excerpted treatises on style are all very interesting, but why not just do it as above? i.e. " the message from" xxx instead of xxx "'s message" Rich -------  RMS@MIT-AI 11/05/79 16:36:39 Re: "CORRECT" POSSESSIVES. To: HEADER-PEOPLE at MIT-MC SINCE IT IS CLEAR THAT ONLY AN AI PROGRAM CAN FORM THE POSSESSIVE "CORRECTLY", HOW ABOUT DROPPING THE SUBJECT?  Date: 5 Nov 1979 17:010:37 EST From: Dan Franklin Subject: Re: in-reply-to field To: Zellich at OFFICE-1 Cc: Header-People at MIT-MC That would be too easy. My message was intended mainly to saturate people's capacity for this kind of discussion. I think I've succeeded.  Date: 9 November 1979 2023-EST (Friday) From: Brian.Reid at CMU-10A Subject: the best-laid plans... To: Header-People at MIT-MC Message-ID: <09Nov79 202310 BR10@CMU-10A> CMU Computer Science now has two people named John Nestor, spelled exactly the same way. So even our Firstname-Lastname scheme falls apart here. Ironically, the "escape" mechanism that our account administrator used to install the second account ("John JNestor") will lead to enormous amounts of confusion. Sigh.  Date: 9 NOV 1979 2118-PST From: NMAX at USC-ECL Subject: Re: the best-laid plans... To: Brian.Reid at CMU-10A, Header-People at MIT-MC cc: NMAX In response to the message sent 9 November 1979 2023-EST (Friday) from Brian.Reid@CMU-10A Chuckle - As the inventor of those BR10 person codes at CMU 15 years ago, and an observer of the long standing discussion about the need for personalized (=humane) mailbox names, I have been quietly waiting for this collision with reality that must obtain as our community grows. Have you thought of measuring their respective heights and assigning a lower case mailbox name to the shorter member of the pair? Chuckle, Chuckle (This from the dummy who sent a personal reply to the whole msggroup list!) Good luck - Stef -------  Date: 10 November 1979 0210-EST (Saturday) From: Brian.Reid at CMU-10A Subject: Re: the best-laid plans... To: NMAX at USC-ECL CC: Brian.Reid at CMU-10A, Header-People at MIT-MC Message-ID: <10Nov79 021007 BR10@CMU-10A> In-Reply-To: NMAX' message of 10 Nov 79 00:18-EST Believe it or not, we actually include the height of mail users in our database (tho not the online version), and they are within a quarter of an inch (our resolution) of one another in height. Before you get a chance to ask: the reason we include height is for the assignment of physical mailboxes, so that tall people don't have to stoop to see if they have mail, and short people don't need to stand on a chair. We try to assign a mailbox at eye level.  JBROWN@MIT-ML 11/11/79 03:12:15 To: header-people at MIT-MC please remove me from the list  Date: 21 Nov 1979 1712-PST From: Geoff at SRI-KA (Geoff Goodfellow) Subject: Change in SRI-KA mail format. To: System cc: Cower, Header-People at MC The format of the SRI-KA netmail header line has been changed to be "Mail-from:" instead of "Mail from" to placate some people who think that is should be considered part of the message header. As a default, for HERMES users, you will not see this line printed out anymore. For those that desire it, you'll need to EDIT User-fields within HERMES and then DECLARE Mail-From: in addition to adding it to your various printing templates. Perhaps more 10/20X sites will catch on and do likewise. -------  Date: 22 Nov 1979 0745-EST From: Michael Travers Subject: Re: Change in SRI-KA mail format. To: Geoff at SRI-KA cc: Cower at SRI-KA, Header-People at MIT-MC In-Reply-To: Your message of 21-Nov-79 2012-EST MIT-XX netmail header lines have also been changed to start with "Mail-from:". -------  Date: 22 Nov 1979 0841-PST Sender: GEOFF at SRI-KA Subject: Re: Change in SRI-KA mail format. From: the tty of Geoffrey S. Goodfellow To: MT at MIT-XX Cc: Cower at SRI-KL, Header-People at MIT-MC Message-ID: <[SRI-KA]22-Nov-79 08:41:04.GEOFF> In-Reply-To: Your message of 22 Nov 1979 0745-EST Reply-to: Geoff @ SRI-KA SRI-KL, PARC-MAXC & PARC-MAXC2 also have joined in addition to XX and KA.  Date: 15 Jan 1980 2212-PST From: Mark Crispin Subject: implementation note to mailsystem implementors To: MsgGroup at MIT-ML cc: Header-People at MIT-MC This note is addressed to anybody likely to implement or work on a program which will send FTP mail. It is well-known that for Multics sites you must send USER NETML followed by PASS NETML (and that NETML must be all upper case). What isn't as well-known is that the Multics FTP server sends TELNET protocol commands; in particular, you are likely to encounter IAC GA in your data stream. If your user program is unprepared to handle this, you are likely to get into trouble (he says from sad experience). In the strictest sense, Multics is not violating protocol either by requiring NETML login or by sending the TELNET protocol commands. Both are explicitly allowed by the published protocol. However, standard usage has been that no TELNET protocol commands are used, although one or two other sites have used old TELNET protocol to implement the ABOR feature. The moral is: to be as robust as possible don't use TELNET protocol or require NETML login, but be prepared to accept TELNET protocol or to be told to use NETML at any time from any host. -- Mark -- PS My apologies to those who received this message twice, or to those of you who already knew all this. I didn't know about the TELNET protocol part (neither did the author of the mailer daemon I am using); had I known before this several hours of my time and quite possibly a system reload might have been prevented. -------  20-JAN-80 11:14:06,1691 Net mail from site CCA rcvd at 20-JAN-80 11:14:05 Date: 20 JAN 1980 1114-EST From: JZS at CCA (Joanne Z. Sattley) Subject: Scheduled termination of Datacomputer Service To: Datacomputer Users: I have been requested by ARPA to distribute the enclosed message. ***** begin enclosure To All Datacomputer Users: The TBM-based Datacomputer has become too expensive to operate. We are faced with a combination of increasing maintenance costs and a funding deficit which was created when a major user community's need for the service ended. The Ampex TBM hardware is obsolete, and no compatible follow-on product is planned. Therefore, with much regret, we have decided that Datacomputer service on the ARPANET must be terminated. We want to make the transition off the Datacomputer as painless as possible for existing users. On the other hand, we want to phase out the service as quickly as possible to avoid needless expense. Our plan is to stop accepting any additional files for storage, effective immediately. The Datacomputer will continue to operate for retrieval only during the transition period. We would like users to retrieve their private files by March 15, 1980. DFTP public files will be saved automatically by the CCA staff. We apologize for any problems which this decision causes you. If there is something specific we can do to ease the transition, we will do our best to help. Send a message to JZS@CCA if you have questions or need assistance. Bill Carlson Program Manager DARPA/IPTO ***** end enclosure It has been a genuine pleasure working with all of you. For the Datacomputer Staff, -- Joanne -------  Date: 1 February 1980 17:56-EST From: Richard M. Stallman Subject: headers To: RMS at MIT-AI, KLH at MIT-AI, Rick.Gumpertz at CMU-10A, MOON at MIT-MC cc: Header-People at MIT-MC Logically speaking, "(BUG @)"@MIT-AI ought to suppress the meaning of the parentheses and refer to a user named "(BUG @)", just as "Rick Gumpertz"@CMU would suppress the meaning of the space and refer to a user named "Rick Gumpertz".  Date: 1 February 1980 1707-EST (Friday) From: Richard H. Gumpertz Subject: headers To: MOON @ MIT-MC, RMS @ MIT-AI, KLH @ MIT-AI CC: Header-People @ MIT-MC Message-ID: <01Feb80 170749 RG02@CMU-10A> Any chance of getting you guys to put the parenthesized lists (such as in the TO field below) in quotes as they go out on the ARPANET? Rick - - - - Begin forwarded message - - - - Date: 1 FEB 1980 0315-EST From: HENRY at MIT-AI (Henry Lieberman) Subject: suggestion for feature To: (BUG @) at MIT-AI ... - - - - End forwarded message - - - -  Date: 1 FEB 1980 1959-EST From: MOON at MIT-MC (David A. Moon) Subject: headers To: Rick.Gumpertz at CMU-10A CC: HEADER-PEOPLE at MIT-MC Date: 1 February 1980 1707-EST (Friday) From: Richard H. Gumpertz Subject: headers To: MOON @ MIT-MC, RMS @ MIT-AI, KLH @ MIT-AI CC: Header-People @ MIT-MC Message-ID: <01Feb80 170749 RG02@CMU-10A> Any chance of getting you guys to put the parenthesized lists (such as in the TO field below) in quotes as they go out on the ARPANET? Rick - - - - Begin forwarded message - - - - Date: 1 FEB 1980 0315-EST From: HENRY at MIT-AI (Henry Lieberman) Subject: suggestion for feature To: (BUG @) at MIT-AI ... - - - - End forwarded message - - - - To be brief, no. If you want to know the reasons, review the Header-People minutes.  Date: 2 Feb 80 09:37-EST (Sat) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: Re: headers To: David A. Moon cc: Rick.Gumpertz at Cmu-10a, HEADER-PEOPLE at Mit-Mc Message-ID: <8032.34664.7180 @ UDel-EE> In-Reply-To: Your message of 1 FEB 1980 1959-EST As I recall, the primary reason you guys aren't putting the quotation marks around such strings is that you think they are ugly. Nonetheless, what you are -- technically -- sending is an address comprising a comment and a host reference, with no mailbox specified. Therefore, it is NOT a valid RFC733 address. With respect to "... suppress[ing] the meaning of the parentheses and refer[ing] to a user named '(BUG @)', that interpretation applies only to the (network) environment where the quoted string is passed, uninterpreted. When you guys get the string, you should remove the quotation marks and parse the string as you normally would. For example, "Rick Gumpertz" is NOT the name of a CMU mailbox. The string is parsed and mapped into something that IS. Dave. P.S. Given the long history on the topic, your refusal to make the change comes as no great surprise. It's been clear to me for a few years now that the only way these things get "enforced", given the absence of more centralized authority (which is fine with me) is through classic free-market mechanisms. The rest of us will have to pointedly refuse to compensate for your failure and not ever send mail to these improperly specified addresses. To the extent that that imposes a burden on you, you will feel pressure to change. In the current context, of course, a mediating factor is the extent to which Arpa IPTO people remain unaffected.  Date: 2 Feb 80 09:37-EST (Sat) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: Re: headers To: David A. Moon cc: Rick.Gumpertz at Cmu-10a, HEADER-PEOPLE at Mit-Mc Message-ID: <8032.34664.7180 @ UDel-EE> In-Reply-To: Your message of 1 FEB 1980 1959-EST As I recall, the primary reason you guys aren't putting the quotation marks around such strings is that you think they are ugly. Nonetheless, what you are -- technically -- sending is an address comprising a comment and a host reference, with no mailbox specified. Therefore, it is NOT a valid RFC733 address. With respect to "... suppress[ing] the meaning of the parentheses and refer[ing] to a user named '(BUG @)', that interpretation applies only to the (network) environment where the quoted string is passed, uninterpreted. When you guys get the string, you should remove the quotation marks and parse the string as you normally would. For example, "Rick Gumpertz" is NOT the name of a CMU mailbox. The string is parsed and mapped into something that IS. Dave. P.S. Given the long history on the topic, your refusal to make the change comes as no great surprise. It's been clear to me for a few years now that the only way these things get "enforced", given the absence of more centralized authority (which is fine with me) is through classic free-market mechanisms. The rest of us will have to pointedly refuse to compensate for your failure and not ever send mail to these improperly specified addresses. To the extent that that imposes a burden on you, you will feel pressure to change. In the current context, of course, a mediating factor is the extent to which Arpa IPTO people remain unaffected.  Date: 2 Feb 1980 1126-PST From: Mark Crispin Subject: Re: headers (into the fray!) To: Dcrocker at RAND-UNIX, MOON at MIT-MC cc: Rick.Gumpertz at CMU-10A, HEADER-PEOPLE at MIT-MC In-Reply-To: Your message of 2-Feb-80 0637-PST Dave - I would like to point out that MM handles MIT-style structured addresses, so at least TOPS-20 users who need to reply to such messages can always use MM. The code in MM that handles this case as opposed to a comment is quite simple - three PDP-10 machine instructions! I seem to remember that the MIT people repeatedly attempted to get this format included in the standard. I distinctly remember HEADER-PEOPLE messages on the topic, but I don't remember the motivation for it not being included. Why WASN'T it included in the standard? I don't remember ever seeing a reason for it not being included, except perhaps that the authors of the standard thought "they are ugly". (Speaking of ugliness, Dave, could you have the maintainer of the mailsystem you use remove that silly mixed-case host name output feature from your message headers? I think "Cmu-10a" and "Mit-Mc" and "Su-Score" are ugly!) I consider this kind of structured addresses to be a useful facility, providing a definite funtionality. In fact, I wish to implement this facility for other purposes on my system. You really don't want to have it quoted, because you want to be able to specify an address to be interpreted without any parsing. Consider the case of an address that by golly actually has parenthesis in it! What do you do once quotes have been usurped for structured addresses? Double quote it (duh...)? The last thing you want to do is apply structured address parsing to it! By the way, don't I remember something about using curly braces for structured addresses? What happened to that idea? Did it go away because some terminals can't input those characters? -- Mark -- -------  Date: 2 Feb 80 16:05-EST (Sat) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: Re: headers (into the fray!) To: Mark Crispin cc: Header-People at Mit-Mc Message-ID: <8032.57925.6671 @ UDel-EE> In-Reply-To: Your message of 2 Feb 1980 1126-PST It is unfortunate that the memory seems to be worst for the people who were most vociferous during the original discussion. 1. I don't care how easy it is to take care of a particular special case (in this case, MIT's address structuring). The issue is to avoid forcing the rest of us from dealing with them. That is the purpose of a standard. 1.a. Why not include their special case into the standard, so that it is no longer a special case? Well, where do you stop? One issue is whether they are prevented from encoding their special case (albeit with a degree of awkwardness they would quite reasonably rather avoid) and the answer, for this case, is no. That was explained when the standard was being specified. 2. The reason we didn't include their convention in the specification had nothing to do with our thinking it ugly. My comment, earlier today, was that I recalled MIT as thinking it ugly to use the quotation marks -- and I agree with their aesthetic opinion, but not their recommended solution. Their would be absolutely no semantic power added to the standard. As I recall, there was a possibility that the extended-typing feature (":" type ":" rest-of- address) would be helpful, by that wasn't pursued. 2.a. Simple aesthetics are not the primary reason for the mixed- case hostnames we use. All upper case is more difficult to read than all- lower or reasonably-mixed. All-lower is not used strictly for aesthetic reasons. We do not use "correctly" mixed because we use one of the more complete unofficial Arpanet host name tables, maintained by Geoff Goodfellow, and he refuses to keep it in proper mixed case. Hence, we have to perform some heuristics. 2.b. The question of case-mixing being ugly does not prevent you from correctly processing mail (addresses) from us. The failure of MIT to put quotations around their mailbox fields DOES. 3. I think structured address are useful, too. 3.1 "... You really don't want to have it quoted, because you want to be able to specify an address to be interpreted without any parsing. Consider the case of an address that by golly actually has parenthesis in it! What do you do once quotes have been usurped for structured addresses? Double quote it (duh...)? The last thing you want to do is apply structured address parsing to it!" I had some difficulty with the english in this paragraph and to the extent that I got past that, I'm not sure I understand what you are saying. My first suspicion is that you don't understand parsing, in this sort of situation; this was an impression I had about a number of people during the original discussion. In fact, at the outset of the specification effort, I didn't either. If you DO understand parsing, then you either haven't read the specification properly or are entirely out to lunch. All of this is being offered without intending to transmit a put-down, but of course, that IS the way it reads. The problem is that I don't know how else to formulate a response. 3.b. As I said a couple of years ago, some of you simply have not made a reasonable effort to understand the specification. Unless and until you do, these sorts of discussions can't possibly be productive. (That puts this note into the realm of frustration release.) Happy weekend. Dave.  JNC@MIT-AI 02/02/80 17:34:02 Re: Cm'on, you guys... To: header-people at MIT-MC Please stop filling my mailbox. I seem to recall having heard all this before. Noel  Date: 2 Feb 1980 1452-PST Sender: GEOFF at SRI-KA Subject: Re: headers (into the fray!) From: the tty of Geoffrey S. Goodfellow To: Dcrocker at UDEL-EE Cc: Admin.MRC at SU-SCORE, Header-People at MIT-MC Message-ID: <[SRI-KA] 2-Feb-80 14:52:10.GEOFF> In-Reply-To: <8032.57925.6671 @ UDel-EE> Fcc: SAVED.MESSAGES;1 Reply-to: Geoff @ SRI-KA As I believe I have told you on at least two distinct occasions (NTC '77 in LA, and the recent 6th Data Comm. Conf. in Monterey), years ago I tried to put mixed case into my hostable for select hosts (such as the TYMSHARE-TIP becoming the Tymshare-TIP, etc.), but found out that TENEX and TOPS20 monitors and programs ceased to function, because they were not written with this option in mind, so of course, i have rightly (and will continue) refuse to put mixed case in my table (until someone goes around the fixes all software concerned, everywhere -- hence: it isn't likely to happen). While the subject is in the fray, I'd like to add to MRC's support that i think your random mix-caseification(?) is unsightly and ugly. I think that mixed case host name issue is so frivolous anyway, that if my name wasn't explicitly mentioned wrt to the hostable you use, i wouldn't have bothered with replying. Having cleared my name, Geoff  Date: 2 FEB 1980 1834-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: How to have constructive discussion To: HEADER-PEOPLE at MIT-AI, dcrocker at RAND-UNIX Whenever we say that "(BUG @)" ought to suppress the meaning of a parentheses, you say that we haven't understood the standard. It is unthinkable that there can be any other basis for deciding what something should mean, so we must be basing our statements on an appeal to the standard, which implies that we are confused, careless or stupid. The fact is, those opinions are based on other things. Even if you don't agree with us in this (I assume you don't) you must start by recognizing the fact that there are other considerations which we regard as as important as what the standard says, or more important. For example, when I say that "(BUG @)" ought to suppress the meaning of the parentheses, my conclusion is based not on anything the header standard has to say, but on the general concept of string quoting and what it means in every other system that has it, including Lisp, PL1, SNOBOL, and many other situations in our mail system. To me that is a more powerful authority than the header standard, and if the standard disagrees, the standard is simply wrong, as if it had said that 3+3=7. Even if you don't agree, if you want to try to change my mind you must appeal to the authorities that I respect rather than to the ones you respect. So you will have to stop regarding it as unthinkable to question the standard, or you will not ever LET yourself understand us fully. And you must stop insisting on making your opinion (that the standard is the ultimate criterion of right and wrong) part of the grounds for the discussion or we can't have a discussion. You might also stop talking about our "failure" to adhere to the standard. In the same tone a Russian might bemoan my failure to support their bid to rule the world. It's not that we failed; we're against it. And stop talking about how everyone should be pointedly nasty to us, because that is resorting to force. Once again, it's taken for granted that you are right and the only question is how to force us into line. However, a threat of force is not a rationally valid argument that you are right, and it automatically terminates constructive discussion.  Date: 3 FEB 1980 0440-EST From: TVR at MIT-MC (Tovar) Subject: This fray (and others) To: HEADER-PEOPLE at MIT-MC Comments like: "To be brief, no. If you want to know the reasons, review the Header-People minutes." "P.S. Given the long history on the topic, your refusal to make the change comes as no great surprise. It's been clear to me for a few years now that the only way these things get "enforced" given the absence of more centralized authority (which is fine with me) is through classic free-market mechanisms. The rest of us will have to pointedly refuse to compensate for your failure and not ever send mail to these improperly specified addresses. To the extent that that imposes a burden on you, you will feel pressure to change. In the current context, of course, a mediating factor is the extent to which Arpa IPTO people remain unaffected." largely tend to make discussions more emotional than intelligent. How about increasing the amount of information and decreasing the number of "us" and "them" comments? I don't have a real good memory about what actually came out of this fray the last time it came up. What i do remember was that there wasn't much of a concensus on this issues. Agreement is what makes standards really work. And that's agreement by alot of the people. And that probably means change from time to time, as people and their needs change. NBS has a standard for connecting mainframes to peripherals, which i will call an IBM channel. That's was decided by a "majority". But do you want to have to put one on a PDP-10, as the U.S. Govt might want to insist (and who pays for most of the stuff on this net)? --- Tovar P.S. I hope no one takes this personally.  Date: 3 February 1980 02:48-PST (Sunday) From: Frank J. Wancho To: Header-People@AI Subject: A Digression on RFCs People, Let me digress/divert this discussion for a moment as I have missed something somewhere along the way and maybe those of us who are relatively new on the net have as well: It says somewhere that RFC means Request For Comment(s). Can anyone submit an "RFC"? Where/when in the process does an RFC become a "standard"? How is that designated? When is an RFC just that, a request for comments, with, perhaps, an eye toward working the responses into a "standard"? Was it ever that? Are RFCs taken as "standards" by their mere "publication", whether on the net and/or in the protocol handbook, or are they merely "proposed standards" which some may adopt and others can freely choose to ignore? I think you have the general idea of what I am looking for in the way of a reply. Then with that out of the way, can someone tell us just what the history and current status of RFC 733 really is, briefly? --Frank  Date: 3 FEB 1980 0631-EST From: TVR at MIT-MC (Tovar) Subject: "(BUG @)" To: HEADER-PEOPLE at MIT-MC Now that i've refreshed my memory by looking at the document and the comments, it is quite obvious that several people (not excluding myself) are confused. At any rate, my interpetation of "(BUG @)" [quotes included] is essentially an atom with funny characters in it. I would treat it as a legal address (according to 733). If i were printing it for a human, it would appear as (BUG @). If i put it in a header where a mailbox was needed (To, From, CC, reply-to, etc.), i would have to look at the thing to see if it needed quoting. I could not be use it as it stands, as (BUG @)@MIT-MC would reduce to @MIT-MC due to parentheses and i would be tempted to quote the thing solely on the basis of the @ as some stupid programmer might trip over it. In any case, i can check the string against: specials = "(" / ")" / "<" / ">" / "@" ; To use in a word, / "," / ";" / ":" / "\" / <"> ; word must be a ; quoted-string. If i found any, i would quote the whole thing, remembering the transformation within the string of " -> \" and \ -> \\ . (Can someone tell me if \ followed by CR really puts a CR in a string??!) If my system used \ as a letter, i might consider using <"..."@losing-site> to make things look nicer in front at least. Now, what i don't like about this scheme is the question of inter-networking. I would hate to see "\"Mike O'Hare\"@Acme-Local"@Somenet-Gateway because net A hates ' and net B doesn't know what to do with multiple @'s. Or how about just "\"foo\\\\bar\"" because non-standard machine on net B likes a \ in names. I know we've discussed this before, probably in the structured name fight. I don't recall any distinct conclusion on how to handle these sorts of problems. Also, aren't sites like UDEL-EE somewhat of a band-aid? --- Tovar P.S. If you're going to use heuristics to go from upper to mixed cases, please improve them. You will probably need a (large) list of exceptions to your rules. I think such techniques may work fairly well with English names, but a large number of site names are acronyms and such sites may be sensitive to typography.  Date: 3 February 1980 1107-EST From: David Lamb Subject: Header fray (pragmatics) Sender: RdMail at CMU-10A To: Header-People at MIT-MC Reply-To: RdMail at CMU-10A Message-ID: <03Feb80 110730 RD00@CMU-10A> 1) Now that the DataComputer has gone/is going away, isn't it a little pointless to refer to the HeaderPeople minutes? Or are they being archived somewhere else? 2) There are a number of theological positions one can take regarding a standard (or suggestion for a standard). I suggest that neither the "you must use it because it's the standard" and the "it doesn't do what I want so I'll ignore it" approach is particularly useful. I realise I am being unfair to both sides, but I tire of this particular debate. 3) My own point of view is that ease of communication is the key factor. If it is a pain in the ass for me to try to send mail to (BUG @)@MIT-AI, then I probably won't send mail there. If I have to send mail there, I'll get real upset and start complaining. Since there is no particularly good reason why anyone at MIT should pay any attention to me, they will ignore my complaints. So (BUG @) and I will stop communicating with each other. I don't think this will cause the world to end. 4) I hope it is obvious that the above was a paradigm rather than a specific instance. Few people outside MIT really have to care about MIT's structured addresses. Lets reserve our energies for problems that really do affect most of us.  Date: 3 Feb 1980 (Sunday) 1135-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: Jumping in... To: header-people at MIT-MC J U M P... Now that was easy. The problems in designing any standard is quite tough. Moreover getting some slob to program it in once agreed to, it even harder. True the TBM is going away, and I will forsee that people will have to get a mag tape out FAST or we will see all the disks on the ARPAnet filled to capacity with mail messages. For standards, what is wrong "SPECIFICALLY" with that recent RFC (783?) or whatever it is, someone refresh my bubble memory. More importantly other issues, like large scale mailings have to be delt with. Is anyone out there in CRTSTY land willing to bring up the point of a Mail COMPUTER? CCA already has something similar --> COMET. Has anyone talked to the CCA people, who do have heads on their shoulders, and EVEN good ideas... Jumping out ... for now  Date: 3 FEB 1980 1319-EST From: MOON at MIT-MC (David A. Moon) Subject: Locations of minutes To: HEADER-PEOPLE at MIT-MC Header-People messages are filed on a series of files with first name HEADER and second name MINS, MINS01, MINS02, etc. on the directory KSC; on the MIT-MC machine. The ones more than three years old have been reaped, but could easily be retrieved if anyone wanted to see them. As far as I know the Header-People messages were never archived on the Datacomputer.  Date: 4 February 1980 1525-EST (Monday) From: Richard H. Gumpertz Subject: ITS parenthesized headers (BUG @) To: Richard M. Stallman CC: Header-People at MIT-MC Message-ID: <04Feb80 152518 RG02@CMU-10A> In-Reply-To: Richard M. Stallman's message of 1 Feb 80 17:56-EST It seems to me that there are some things that people just aren't seeing. The first is that the interpretation of names by an addressed host need not match that by other, non-addressed hosts. RFC733 covers, in general, how names should be interpreted by the non-addressed hosts (i.e. ones whose name does not follow the "@" or "at"). Each site may choose how to interpret addresses specific to that host. For convenience, the 733 syntax was chosen so that the concepts employed by MOST hosts could be represented in a straightforward (and pretty?) manner. In many cases internal address formation rules can be mapped directly into network-wide address formation rules. For instance, typical names are easily represented. Punctuation of 733 addresses was chosen to avoid conflict with many of the already used internal rules. However, ITS parenthesized type addresses were NOT provided for. I will not comment here on the wisdom of that decision. For parenthesised ITS names, the catch-all called quoting MUST be used (or the parens mapped to braces or something). It may be a nuisance to the ITS people; it may be ugly; nevertheless that is how it is. Of course it is a pain for some sites to map internal representations into external representations. Those that have it easy can say that anything in quotes will be treated as a literal; those that have it harder must do something else. Since ITS must use quotes to get parenthesized lists through without being treated as comments, they cannot blindly assume that quotes mean to use the entire string as an uninterpreted literal. If they need such functionality (I am not sure why a mailbox would NEED to contain quoted parens), then they must invent ANOTHER syntax which can be imbedded inside the quotes. Given their LISP-like syntax, the use of ' would seem obvious, but far be it from me to dictate what they should use. Surely some ITS hacker can come up with some reasonable syntax that is works with RFC 733. Another thing to keep in mind is that the general rule that has been in effect for some time is that changes which ease communication should be made at the site which will require the least changing of multiple programs. Under this rule, CMU went to generating names with "."s in them instead of spaces -- they are treated identically internally but make things easier for those sites which aren't prepared for spaces in names. In a similar vein, I request that ITS do something to bring their names into conformance with 733. The most obvious thing is to put quotes around their structured names WHEN SENT TO OTHER ARPANET HOSTS. They can of course be stripped off for internal use if they really think that worthwhile. They can turn their characters upside-down or even map into the character set used by John Elliott to publish the first book published in the new world -- the bible translated into the Massasoit Indian language. (That would surely follow the tradition of rebelliousness that seems dominant in the Boston area.) I don't care what they do internally, but please give me something reasonable to reply to externally. Rick  Date: 4 February 1980 1535-EST (Monday) From: Richard H. Gumpertz Subject: Re: headers (into the fray!) To: Dcrocker at Rand-Unix CC: Header-People at Mit-Mc Message-ID: <04Feb80 153500 RG02@CMU-10A> In-Reply-To: <8032.57925.6671 @ UDel-EE> Maybe the solution, though ugly, is "(" BUG "@" ")" @ MIT-MC? Rick  KLH@MIT-AI 02/04/80 21:43:07 Re: !!STOP!! for a minute. To: header-people at MIT-MC Wait. People are assuming that MIT wants recipients of the form (BUG FOO) to be legal. We do not; we have known since the beginning of time that parentheses were targeted by the RFC-generators for "comments". We accepted this in the belief that a viable alternative would be provided, and in fact suggested more than one such alternative that would be acceptable to us. None was incorporated. Please get off the non-issue of how to pass parentheses around. A discussion of WHY the MIT sites continue to use parens should wait until one of us can dig up the original messages and proposals for re-transmittal; then we can proceed from there. This is easier than reaching the same point via re-hashings and thrashings. Perhaps when this is done we will find that perspectives have changed. --Ken  Date: 5 February 1980 1525-EST (Tuesday) From: Richard H. Gumpertz Subject: Re: !!STOP!! for a minute. To: KLH @ MIT-AI CC: Header-People @ MIT-MC Message-ID: <05Feb80 152510 RG02@CMU-10A> In-Reply-To: KLH's message of 4 Feb 80 21:43-EST Let me back off a bit. I originally requested the quotes around "(BUG @)" so that I could easily ANSWER/CC to that address. If I manually type the quoted string all works well (remember that the FTP that supports mail delivery never sees the quotes). It seemed (and still seems) like a trivial change for MIT to put the parenthesized addresses in quotes so that I would not have to manually retype such addresses but could use nice facilities for automatic copying of addresses. Besides, it would allow me to see the address when RDMAIL prints it (currently it parses it into " at MIT-AI" or whatever and so prints that it is from , unless I explicitly ask for the WHOLE header). Rather than get into a long discussion of what is right or wrong, why can't the ITS people just implement the expedient, kludge or not, of adding the quotes? Alternatively, translate parens to braces as they go out over the net (in structured addresses anyway). This would be no worse than CMU translating spaces to dots. Of course either can go away if something better (like official structured address syntax) comes along. For the moment, however, a legal address like "(BUG @)" at MIT-AI seems far superior to an illegal one like at MIT-AI with a comment thrown in. Rick  Date: 6 FEB 1980 1353-EST From: MOON at MIT-MC (David A. Moon) Subject: More flaming about structured recipients To: Rick.Gumpertz at CMU-10A CC: HEADER-PEOPLE at MIT-MC Here is why MIT does not put quotes around structured recipients. That would make it parse wrong in our own mail reading programs, where quotes have their normal meaning of causing special characters inside them not be special. Obviously it is more important for structured recipients to parse correctly locally than to parse correctly at foreign sites, since very few of them ever get to foreign sites. In fact, the only person I have ever heard complain about this problem is you, because you are a maintainer of the "@" program. The few other structured recipients at "foreign" sites (e.g. MIT-XX) have evidently just fixed their mail readers to parse that syntax in an ad hoc way. Well, why don't we write it one way when sending to a local host and another way when sending to a foreign host? That sounds superficially like a good idea, but unfortunately it cannot work, because headers are not reformatted when mail is forwarded from one host to another, so there is no way to know at the time when a header is generated what hosts and programs are going to see it in the future. Well, why don't we use some other characters instead of parentheses, like curly brackets? In fact, that is what we want to do. When RFC733 was being written we asked many times for such a feature to be put into the standard, but the authors of RFC733 were never interested in putting it in nor in understanding what it was for. So, in the absence of any standard we stick to what we have always done, which at least works adequately.  Date: 6 February 1980 1738-EST (Wednesday) From: Richard H. Gumpertz Subject: Re: More flaming about structured recipients To: MOON at MIT-MC (David A. Moon) CC: HEADER-PEOPLE at MIT-MC Message-ID: <06Feb80 173855 RG02@CMU-10A> In-Reply-To: David A. Moon's message of 6 Feb 80 13:53-EST 733 does allow braces in addresses without restriction, as best I recall. Why not just go ahead and use them, even if noone else knows their "structured" meaning?? Rick  Date: 6 Feb 1980 8:13 pm (Wednesday) From: AHenderson at PARC-MAXC Subject: Structured objects in messages. To: MOON at MIT-MC (David A. Moon) cc: HEADER-PEOPLE at MIT-MC David: As an author of RFC733, let me comment that the speculation in your recent message about us is false. We actually considered the support of structured objects fairly hard. In the end, for various reasons which were good at the time, we decided not to support them. I am now of the opinion that we made a mistake in deciding not to put in some explicit recognition of the need for structured portions of messages. I feel this for two reasons: 1. (pragmatic reason; 20/20 hindsight) We would not have had the recurring discussions which we now have on the subject. One of our goals in designing the RFC was to get something everybody could agree upon so that we could get on with life; these discussions indicate that the time may now have come for us to make this addition to allow us to do just that. 2. (technical reason) I think it is important that any standard in a research environment should have some means of escape; a way of extending the standard into territory which is not under discussion at the time of creation of the standard (the time of the decision-making). I see the structured objects which have been the subject of the recurrent discussion as serving that end. I discussed this with Richard Stallman long ago, but we were thinking then only of addresses. Now, I would advocate adding a more general escape mechanism. How about: 1. add (p7/8) a 5-th type of lexical symbol: {anything} - structured object add (p9) appropriate info to the formal definitions of the lexical structure: specials (include "{" / "}") structured-object (analogous to comment). 2. add (p16) to the production for : word = atom/ quoted-string/ structured-object One you have an escape mechanism, I think an important next step is to reach agreement about the shape that the "anything" can take. My feeling in this regard is that all we need, and all we ought to establish at this level is a convention by which a composer of a structured-object can communicate to his audience an indication of the "language" being used within that structured-object. Then we provide for different subcultures co-existing without trouble. How about: 1. The first within the brackets indicates the language. { } (A language is composed of a collection of objects and a format for representing those objects: a semantics and a syntax.) 2. Establish a registry for language-indicators (with the NIC, Jon Postel, ?). Thus, for example, register the "language" of the addresses which MIT uses to such advantage as, say, MIT-Address. Then they would use the form {MIT-Address } in their messages. Note that this permits even the language-indicator to be a structured-object; thus we can escape even a level deeper. (Always leave yourself a way out.) Some of us could even register and explore the use of "self-describing languages" (ultimately a contradiction in terms, but you know what I mean; eg. PCPB8, or the new internet mail format). What think you? Austin PS: I have not consulted the other authors of RFC733. They may be able to remind me if there are good reasons (pragmatic and technical) for not changing the standard.  Date: 7 February 1980 1105-EST (Thursday) From: Richard H. Gumpertz Subject: Re: Structured objects in messages. To: AHenderson at PARC-MAXC CC: HEADER-PEOPLE at MIT-MC Message-ID: <07Feb80 110507 RG02@CMU-10A> In-Reply-To: AHenderson's message of 6 Feb 80 20:13-EST Austin - Your proposal sounds good to me, but I would suggest using another language identifier like ITS-Structured-Address or such so as not to indicate that other MIT sites like Multics go along with such. Another point: Should there be any provision for comments within structured addresses? If so, would parens be totally reserved for comments? Reserved in certain contexts? The S-expression could always be worded in terms of nested braces or such. If parens are absolutely needed, they could be quoted with \ I guess. Maybe something else is appropriate, but comments would sometimes seem useful. Rick  Date: 7 Feb 1980 10:41 am (Thursday) From: AHenderson at PARC-MAXC Subject: Re: Structured objects in messages. To: Richard H.Gumpertz cc: HEADER-PEOPLE at MIT-MC Rick: Sure, pick any language-indicator you (read: the registrar) like. I think it wise not to have to do lexical analysis within {}. For one reason we then have recursive calls to the lexical analyzer. But secondly, and this seems more important, we are free of concerns over quoting, a much-to-be-sought-after situation if current discussion is indicative of people's real feelings on this matter. Austin  Date: 7 February 1980 2100-EST (Thursday) From: Richard H. Gumpertz Subject: Re: ITS-STructured-Address To: RMS at MIT-AI (Richard M. Stallman) CC: Header-People @ MIT-MC, AHenderson at PARC-MAXC Message-ID: <07Feb80 210011 RG02@CMU-10A> In-Reply-To: Richard M. Stallman's message of 7 Feb 80 17:45-EST RMS - I agree, BUG and FILE and @FILE would make for nice registered names (maybe with the perturbations made below). Perhaps the syntax should be changed, however, so that the language identifier need not be a single word. In particular, how about: { : } Note that the colon allows multi-word language identifers. I am not sure colon is the best character choice, but it seems reasonable. Examples of names that might possibly be useful are: {RFC-733 Address: Rick Gumpertz @ CMU-10a} @ MIT-AI {Site-specific address: Farber @ UDel-EE via Dialup Kludge} @ Rand-Unix {Site-specific address: Farber @ UDel-EE via OxCart} @ Rand-Unix {Site-specific address: Redell @ SDD} @ PARC-MAXC {Person (interpreted by some human): Harry Bovik} @ CMU-10A {Job Title: ARPANET Liason} @ MIT-Multics {Traditional Address: Richard H. Gumpertz, 47 Orchard Ave., West Newton, MA 02165} @ WU-Mailgram {Traditional Address: Margaret Thatcher, 10 Downing Street, London, England} @ USPS-Gateway {Log File: >udd>Multics>Hacker>foo} @ MIT-Multics {Distribution list File: SNAME; FNAM1 FNAM2} @ MIT-AI {Bug report: @} @ MIT-AI {Address Maintainer: Header-People} @ MIT-MC {Address Maintainer: {Bug Report: @}} @ MIT-MC {{MIT-ITS Extension: }: } A perverse example, which I am not absolutely sure I have right, might be: {RFC-733 Address: {Address Maintainer: {Bug Report: @}} @ MIT-AI} @ CMU-10A Note that "RFC-733 address" is just an explicit form for the default addressing and so may not be really necessary. I would allow comments to the left of the colon (the leftmost one anyway). To the right of the colon would be language dependent -- the only requirement would be that it have balanced braces so someone who doesn't know the syntax can just scan to the closing brace. \{ and \} would be available for languages which need unbalanced braces -- they would not be counted when scanning for the closing brace. For the names mentioned above, comments would probably be allowed in the right sides of only "RFC-733 Address" and "Address Maintainer". I am still not sure, by the way, whether the site should be required after the closing brace of a structured address. I think it should so that there is always indicated SOMEONE who can interpret the address and act appropriately. Of course the site named after {RFC-733 Address: ...} might not seem too useful. It is needed, however, because many hosts will not understand structured addresses at all (other than how to skip to the closing brace). In particular, the host after a structured address should be one that not only can understand structured addresses but also can understand the particular language indicated. All others could just pass off the address to that host for interpretation. Of course duplicate elimination would be difficult for the sender unless he understands the particular languages used, but that is just too bad. To keep HERMES and the other losers happy, I suggest that all registered language names not contain spaces for now -- use dashes as for field names. Also, any unnecessary white-space should be squeezed out. For example: {Bug-Report:MIDAS} at MIT-AI should get by most mailers without any code modification.  Date: 8 February 1980 1854-EST (Friday) From: Brian.Reid at CMU-10A Subject: header standards To: Header-People at MIT-MC Message-ID: <08Feb80 185454 BR10@CMU-10A> I haven't waded through all of my mail yet after being gone for several weeks, and may therefore find that somebody else has already said this. The reason we stalled out a year or two ago on header standards was that different people are applying different requirements. Group X wants the headers to be optimally human-readable. Group Y wants headers to be totally machine-readable, and will have a program do the translation from machine-readable form into human-readable form. Group Z, which is probably the majority of the fray members, doesn't much see or care about the distinction, and wants headers to be both human-readable and able to carry large amounts of sophisticated information. My position has always been that the problem can't be solved until we agree on what headers are for. At CMU a program stands between my mail headers and my screen, and can display any header any way I want. I submit that any attempt to encode more information in these mutant headers that are trying to be both human-readable and machine-readable is bogus, and that we ought to try to solve the @i[real] problem, which is machine-readable headers. Brian  Date: 8 Feb 1980 1658-PST From: Larry Campbell Subject: Re: header standards To: Brian.Reid at CMU-10A, Header-People at MIT-MC In-reply-to: Your message of 8-Feb-80 1554-PST Foo, Brian. Headers that are human-readable are also machine-readable, although you might have to do a bit more programming to get it right. After all, if you want headers to be machine-readable, why not just use some highly compressed binary crud and be done with it? It'd make net mail much more efficient. Human-readable headers win for two reasons. First, they make it easier on people with limited computing and/or programming resources (for example, home computers). Dumb computers or programs can just type out the header literally and let the human figure it out. If that means that programs which wish to do fancy things with the header must be a little bit smarter, that's just too bad; after all, that's what computers are for! The second reason is that it makes debugging easier; it also provides an escape mechanism when the fancy mail reader has bugs: the human can parse the header and get around the bug manually. At this late date, it is surprising to hear people still arguing in favor of encoding data (which has meaning to humans) in an obscure form to make it easier for the computer to read. If we're going to do that, why not finish the job and abolish compilers and assemblers? It'd be much easier on the poor computers if we programmed in binary! Let's put the burden on the computers, where it belongs. -------  Date: 8 Feb 1980 1844-PST Sender: POSTEL at USC-ISIE Subject: RFCs & Standards From: POSTEL at USC-ISIE To: Header-People@MIT-MC Message-ID: <[USC-ISIE] 8-Feb-80 18:44:15-PST.POSTEL> Frank Wancho: Anyone can write an RFC. To publish an RFC send it online to the RFC number czar (me). The RFC number czar will stick in the number and place it in the NIC online library, and send out an announcement of its existence. Most RFCs are in fact requests for comments. Some are not. Almost all the protocol standard documents appeared as RFCs in early versions for comments and as final versions for information. The standards setting process in the ARPA community is not formalized. There is no procedure handed down from above, or agreed to by the network users. However, given the history of the development of standards in the ARPANET, the development of the current mail standard (RFC 733) was is the result of a very formal and widely advertized standard making effort. In practice, the standards are what ever it is that gets published in the ARPANET Protocol Handbook. I am the technical editor of that document (Jake Feinler is the production editor, and does all the hard work). The editors serve at the pleasure of DCA and ARPA. --jon.  Date: 8 February 1980 2227-EST (Friday) From: Brian.Reid at CMU-10A Subject: Re: header standards To: Header-People at MIT-MC Message-ID: <08Feb80 222725 BR10@CMU-10A> In-Reply-To: Larry Campbell's message of 8 Feb 80 19:58-EST My point was pricisely that: let the computers do the work. You are sending a message that goes through 3 to 5 layers of encoding in various formats that are intelligible only to computers without elaborate diagnostic programs (IMP packets, NCP buffers, file buffers, etc.) and you are worried because the last level isn't optimally readable by people. Foo; I can read any header that anybody can write; that's not the problem. The problem is specifying the format of header fields rigorously enough for dumb mail programs to be able to understand them. I already have access to the smartest mail program around, and it can understand all of this junk, so I don't care. But for those people who would like to "let the computer do the work" and who don't have a natural language parser built into their mail reader, the compromise should be in the direction of machine-readable formats and not human-readable ones. My argument is that the header of a message is a higher-level analog of the packet control information in a network packet, and we seem all to have agreed that the hugely complicated software necessary to turn those packet bitsies into the flames that you see before you have not gone to waste. So why not take the same sound logic up a level, recognizing that the "message" is a data object of importance as great as the "packet", and equally rigorous format standards should be applied. Brian  Date: 14 February 1980 2304-EST From: David Lamb Subject: automatic CC's Sender: RdMail at CMU-10A To: header-people at mit-mc Reply-To: RdMail at CMU-10A Message-ID: <14Feb80 230406 RD00@CMU-10A> Yesterday I sent a note to MsgGroup announcing the RdMail manual and asking for people who wanted one to send me their U.S. mail addresses. I strongly suspected that someone would answer my note with a Hermes template that would generate a CC to the TO list of my note, which would have wound up sending a lot of junk mail to the whole mailing list. What I did was to generate the message and mailer queue entry by hand, eliminating the TO field from the message. One of the recipients noticed what I had done, and pointed out that I had thereby prevented him from knowing which of several mailing lists I had used in doing so. Does anyone have a better idea of what I could have done? The only alternative I could think of was to invent a new header field like Dont-Answer-To: that would have held the stuff I didn't want to put into a legitemate field.  Date: 14 February 1980 2334-EST (Thursday) From: Brian.Reid at CMU-10A Subject: Re: automatic CC's To: header-people at mit-mc Message-ID: <14Feb80 233457 BR10@CMU-10A> In-Reply-To: <14Feb80 230406 RD00@CMU-10A> The things we do to circumvent Hermes!!!!!  Date: 14 Feb 1980 2252-PST From: Feinler at SRI-KL (Jake Feinler) Subject: Postscript to "A digression on RFCs" To: header-people at MIT-AI cc: feinler I think Jon essentially outlined what an RFC is and how one is submitted. One thing that was perhaps not clear was the fact that most of the major Arpanet protocols were the result of a protocol committee or working group appointed by ARPA. These working groups generally came up with a draft document and submitted it as an RFC, then did rewrites incorporating feedback where pertinent, and finally submitted a final version which for all intents and purposes became the standard. Jon has coordinated this dialog for some time and is continuing to do so for the internet protocol dialog as well. RFC 733 was the result of such a committee which, as I understood it, had ARPA's sanction. (The members can verify this.) If I remember rightly it was the CAHCOM committee (although for the life of me I can't come close to what that acronym stands for!) Internet, Autodin II, NSW and DoD protocols (particularly the latter three of these) are the outcome of a more formal effort than that leading to the Arpanet protocols...at least in later years. I think we are heading more towards an environment where the hosts on a given network will be required to adhere rather closely to the official protocols for that network. [Perhaps Jon has more to add to this.] As I have watched the protocol dialog go back an forth, I have been very impressed by the usefulness and importance of letting interested parties beat on any proposed protocol to get as many points of view represented and as many serious discrepancies ironed out before it becomes an accepted protocol. Members of the Arpanet who have participated in this dialog have contributed very useful input. The net is a most unique environment for such collaboration. Jake -------  Date: 15 FEB 1980 0316-PST From: NMAX at USC-ECL Subject: Re: automatic CC's To: RdMail at CMU-10A, header-people at MIT-MC cc: NMAX In response to the message sent 14 February 1980 2304-EST from RdMail at CMU-10A The answer is to create "lists" that look lke mailbox names, but are not. This can, if you use the right names, convey who got them. for example: MSGGROUP: MSGGROUP@MIT-ML which should tell us who you sent it to, and get it to the right relay station, and not give us a way to inadvetently anwer to the whole list. And, I should note that it is not just HERMES that causes the problem in TENEX-land. MSG is just as prone. Seems to me that any mail handler with a reply or answer command that uses addresses pulled from recieved messages will let users make that mistake. As long as msggroup@mit-ml looks like any other individuals address, then how should any reply function guard against replying to it? the problem in this case requires the same solution used by USPS junk mailers. They don't give you access to their mailing list either, though they may code it so they know which one was used. Enuf of this for now - do we really need more than the blind list mechanism we have? Stef (yes, this is me in NMAX - I set this mailbox up just to catch header people and other junk mail for me, and keep it out of the way of business!) -------  Date: 15 February 1980 11:11 est From: Pogran.CompNet at MIT-Multics Subject: Re: Postscript to "A digression on RFCs" To: Feinler at SRI-KL (Jake Feinler) cc: header-people at MIT-AI, feinler at SRI-KL In-Reply-To: Msg of 02/15/80 01:52 from Jake Feinler Just for the record, CAHCOM = "Committee on Computer-Aided Human Communication", a relatively short-lived effort on Steve Walker's part, when he was an ARPA program manager, to provide some direction and advice regarding ARPA's efforts in the area. Ken  Date: 15 Feb 1980 10:33 am (Friday) From: AHenderson at PARC-MAXC Subject: Re: Postscript to "A digression on RFCs" To: Feinler at SRI-KL (Jake Feinler) cc: header-people at MIT-AI Addition to Ken's note: CAHCOM Chairman - Dave Farber. Mail format subcommittee membership: authors of RFC733; no chairman. Austin  Date: 15 Feb 1980 12:37 pm (Friday) From: AHenderson at PARC-MAXC Subject: Re: structured addresses To: Richard H.Gumpertz cc: Header-people at MIT-AI I have been away skiing, and so in an attempt to catch up have not followed the recent exchange of messages very closely. However . . . My chief concerns are: 1. that an escape mechanism be available; 2. that this mechanism support different languages (extensions); 3. that any syntax and characters be permitted within these languages with a minimum of quoting problems; 4. that the language in any particular structured-object be discernable; 5. that if the language is not understood by some program, that program be able to easily ignore that whole structured-object. In light of this, I think: 1. that "reading to } with some quoting convention (doubling?) for inserting }" is a good way of satisfying 5. To the extent that structured objectsdo not contain }, no quoting will be necessary. 2. that an MIT structured address, say "(FOO BUG)", would most cleanly (that is, in keeping with the concerns just expressed) best be encoded as "{MIT-ITS-ADDRESS-LANGUAGE-IDENTIFIER (FOO BUG)}", where the identifier is whatever (presumable short) word you register. To the extent that the MIT structured addresses do not contain }, no quoting will be necessary. 3. that you shouldn't register the specific forms you now have as their own languages; that doesn't feel like it is in the spirit of what I had intended by a "language". Austin  Date: 15 FEB 1980 1750-EST From: MOON at MIT-MC (David A. Moon) Subject: Re: structured addresses To: HEADER-PEOPLE at MIT-MC Just a brief note. I think saying {MIT-STRUCTURED-RECIPIENT (BUG PROGRAM)} is 100% entirely not in the spirit of what we are trying to do. The correct thing is to add "bug reports" as a standard facility which any host may support (I presume we are not the only hosts that sometimes have bugs in their programs), and write the syntax as {BUG FOO}. I don't think it makes sense to say there are different "languages". A more appropriate model would be FTP commands, where everything is in the common "language" that it starts with a keyword and ends with a carriage return. A certain set of keywords are registered and standardized; their documentation includes what comes on the line after them, but you can always skip over any keyword by reading up to the carriage return. There is a mechanism for experimenting with new, unregistered keywords, by spelling them starting with an X. Similarly, in structured recipients there is a common language, namely a structured recipient is enclosed in {}, contains balanced {} inside itself, and starts with an identifying keyword. Unregistered keywords should start with X to avoid any conflict with registered keywords (and should be renamed when they become registered). If you want we could have a way of quoting unbalanced {}, although I don't think it's of much practical importance. We should certainly register and standardize any keywords that seem to be of general use, even if not all sites plan to implement them any time soon.  Date: 16 Feb 1980 0108-EST Sender: FURST at BBN-TENEXB Subject: Automatic CC's From: Furst at BBN-TENEXB (Sheldon R. Furst) To: David.Lamb at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[BBN-TENEXB]16-Feb-80 01:08:52.FURST> The subject is probably dead, but for everyone's general information, HERMES can be suppressed from automatically CC'ing to the "To" field of the original message by setting the "Reply-Copies" switch (sigh) to "NO". Unfortunately, the default for this switch is "YES", and (out of ignorance, I suspect) most users leave it this way. I certainly think a case can be made for defaulting it to "NO", but whether someone will listen is another matter. -- Sheldon  Date: 16 FEB 1980 0319-PST From: NMAX at USC-ECL Subject: Re: Automatic CC's To: FURST at BBN-TENEXB, David.Lamb at CMU-10A cc: Header-People at MIT-MC, NMAX In response to the message sent 16 Feb 1980 0108-EST from FURST@BBN-TENEXB I will try to refrain from accepting your invitation to flame. Setting the switch to "NO" is simple. Living with it set to "NO" so I have to type in the addresses, or over-ride the switch 90% of the time is painful and unwarranted. So, I will repeat what seems so obvious. If you don't want replies sent to a certain address, such as a rebroadcast station, then you should not put it where people can get at it and use it wrongly. We have mechanisms such as blind lists which will do the reqquired thing. I move that we start to use them. Stef -------  Date: 16 February 1980 1001-EST (Saturday) From: Richard H. Gumpertz Subject: Re: Automatic CC's To: NMAX at USC-ECL CC: Header-People at MIT-MC, NMAX at USC-ECL Message-ID: <16Feb80 100126 RG02@CMU-10A> In-Reply-To: NMAX' message of 16 Feb 80 06:19-EST Stef - There is a big difference betwen automatically generating CC's and offering the user a short mechanism for generating the CC himself. For instance, on this very letter I had to type exactly one more character than if I had decided not to send CCs to Header-People! I'll bet nobody from CMU has automaticallly CC'ed lists unintentionally. Does this mean they type a lot of addresses? Absolutely not -- in fact I suspect they probably type fewer than other sites. Rick  Date: 16 Feb 80 11:23-EST (Sat) From: Dave.Farber Reply-to: Dave.Farber at Rand-Unix Subject: Re: Postscript to "A digression on RFCs" To: Jake Feinler cc: header-people at Mit-Ai, feinler at Sri-Kl Message-ID: <8046.41005.1040 @ UDel-EE> In-Reply-To: Your message of 14 Feb 1980 2252-PST CAHCOM translated as Computer Aided Human COMmunications. A word I still like. I was the Chairman of the Arpa Committee. Dave  Date: 16 Feb 80 12:46-EST (Sat) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: Re: Automatic CC's To: Sheldon R. Furst cc: Header-People at Mit-Mc Message-ID: <8046.45977.1703 @ UDel-EE> In-Reply-To: Your message of 16 Feb In-Reply-To: <[BBN-TENEXB]16-Feb-80 01:08:52.FURST> Hermes certainly is not the fundamental "cause" of the problem. It merely happens to be one of the systems with enough features (and no, I'm not a great Hermes fan) to have options that can be set wrong. I think you observation as to Hermes' problem being incorrect defaults is just right. I recommend that the default be ASK, rather than NO. This tells naive users what is going on and doesn't require them to first feret out the possiblities. Dave.  Date: 16 February 1980 1333-EST (Saturday) From: Richard H. Gumpertz Subject: Re: Automatic CC's To: Dcrocker at Rand-Unix CC: Header-People at Mit-Mc Message-ID: <16Feb80 133335 RG02@CMU-10A> In-Reply-To: <8046.45977.1703 @ UDel-EE> If ASK is what I think it is, it sounds like it is similar to RDMAIL. In that case I agree that it should definitely be the default behavior on automatic CC'ing. Rick  Date: 16 Feb 1980 1357-PST From: Mark Crispin Subject: automatic CC's To: Header-People at MIT-MC MM was changed to have its default in REPLY be SENDER instead of ALL. This default can of course be changed in an init and overridden by typing two extra characters (a space delimiter and an "a" before a CR). I was reluctant to do this because it seemed to me to be a major incompatability, but I got a lot of bureaucratic pressure at Stanford to change it (and since I personally agreed with the bureaucrats on the issue I couldn't argue the merits of the old default). Now I have people sending me messages saying that they preferred ALL and that it was a silly change to make. You can't please everybody. -- Mark -- -------  Date: 16 Feb 1980 1506-PST Sender: GEOFF at SRI-KA Subject: Re: automatic CC's From: the tty of Geoffrey S. Goodfellow To: Admin.MRC at SU-SCORE Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]16-Feb-80 15:06:51.GEOFF> In-Reply-To: Your message of 16 Feb 1980 1357-PST Reply-to: Geoff @ SRI-KA As was said earler, i think rather than forcing a default/option of only REPLY-TO-ALL or REPLY-TO-SENDER-ONLY on the user, HERMES, RdMail and MSG have the best solution: the initial default is to ASK the user each and every time what he wants to do each time a REPLY command is given -- ALL or just SENDER. Hence, I would suggest that the MM maintainers get togther, and add this option to MM.  Date: 16 FEB 1980 1510-PST From: ESTEFFERUD at USC-ECL Subject: Re: Automatic CC's To: Rick.Gumpertz at CMU-10A, Dcrocker at RAND-UNIX cc: Header-People at MIT-MC In response to the message sent 16 February 1980 1333-EST (Saturday) from Rick.Gumpertz@CMU-10A Yes, I have set my HERMES switches to the ASK setting which forces me to say "y" to include all TO's and another "y" to get all CC's. The next prroblem is that after saying yy 90% of the time, it stops being a thoughtful process. But, I will certainly concede that HERMES does not have everything right. You may quote me anytime! . "I hate HERMES! I hate it at least as much as I hate LISTERINE. But I use it 5 or more times each day because it does what I need, as compared to several other mail handling systems!" Now, with my HERMES LOVER IMAGE shattered, let me again put my issue on the table: Leaving rebroaadcast echo mailbox names in messages for which you do not want replies to be rebroadcast is not much different than what lawyers call "entrapment." This environment is full of little traps and distractions, and having to stop and carefully ponder an address list before replying is not any part of good design. This is the point I want to make. (Forget HERMES!) The thing we need to fix in the overall mail system is the problem of letting uneducated and/or careless folks get their hands on dangerous addresses without knowing it. On my last error of this kind with HUMAN-NETS, I very carefully pondered it for a while, and then made the wrong decision anyway. I just did not have enough information in hand to make the right decision, no matter what defaults or handy control mechnisms I might have in hand. What I am suggesting is that while we are at it, designing these nice powerful tools for getting work done, we aught to strive for elimination of traps for the unwary. You really don't mean these to be mechanisms for catching us so you can snicker at us do you? To sum up - I am trying to make a different point, and I ask you to consider it also, along with the issues of HERMES indictments. We can do very little about HERMES, you and I, so lets go work on something where we might do sme good? ONWARD! (not backward!) Stef -------  Date: 16 February 1980 1928-EST (Saturday) From: Brian.Reid at CMU-10A Subject: Re: Automatic CC's To: Header-People at MIT-MC Message-ID: <16Feb80 192820 BR10@CMU-10A> In-Reply-To: ESTEFFERUD's message of 16 Feb 80 18:10-EST I see two separate issues here. (1) The way programs handle options. There have been three diffent sorts of behaviors discussed: (1) A default behavior, with some mechanism by which the user can override it by a particular answer: "I will do X unless you explicitly tell me otherwise." A slight variation on this is the "I am about to do X; is this OK? Type CR if OK" This is, as far as I know, what Hermes does. (2) A set of default behaviors, with the user made to select among them each time: "Should I do A, B, C, D, or E? ". If there is a default (i.e. if hitting CR causes one of A-E to be executed, then this is just case (1) with better documentation. This is what MM does. (3) No default behaviors, but special keys on the keyboard to serve as "macros" for frequently-desired cases. This is what Rdmail does. It individually asks you each of the TO, CC, and Subject fields, making you explicitly fill in all of the recipients. It then provides various single-keystroke things that you can type in response to those prompts that will expand as macros into the various default behaviors used by MM. Case (1) seems to my mind to be the wrong way for an interactive program to behave; as (I think) Farber pointed out, any stimulus that ON THE AVERAGE contains no useful information will be assimilated. Case (2) seems to work better for beginning users, and case (3) seems to work better for experienced users. (2) Strategies for communicators to use that will maximize the probability that their privacy will be maintained. The thing that David Lamb did that started this whole discussion, namely to send out a message without a TO field, was an example of such a strategy. Since the NAME of the mailing list and the ADDRESS of the mailing list are the same, namely Header-People, there is no simple way that we can identify how a person came to get a piece of mail ("You-Got-This-Because-of: Header-People") without actually transmitting to him the information needed to use this list ("To: Header-People"). This comes right back to the thing we were all flaming about last week, namely the intermixing of machine-readable information (the "address" of a list) with human-readable information (the name of the list) in the same header. Brian  Date: 16 Feb 1980 1712-PST From: Zellich at OFFICE-1 Subject: Re: Automatic CC's To: Brian.Reid at CMU-10A, Header-People at MIT-MC cc: ZELLICH In response to the message sent 16 February 1980 1928-EST (Saturday) from Brian.Reid@CMU-10A Personally, I rather like the way MSG handles it - I have to type a minimum of characters; it doesn't lead to habitual typing of the same response all the time; and it lets me add additional (or selective) addresses: To reply to this message, I typed A10T, which is "ANSWER 10" then I was prompted "Reply to those whom the message is:" [The choices are From (sender), To (Sender and To field), Cc (Sender, To, and Cc fields)], I told it "To" this time because I wanted to send the reply to Header-People, and it then prompted me: "Additional addresses" I don't think you can get either much simpler or more foolproof than this. I don't have to worry about switch settings or not-always-right defaults, and both the prompting and option-selection are very simple. It also makes the user aware that there are functionaly different options without swamping him/her with prompting. Cheers, Rich -------  Date: 17 FEB 1980 0308-PST From: NMAX at USC-ECL Subject: Re: Automatic CC's To: Brian.Reid at CMU-10A, Header-People at MIT-MC cc: NMAX In response to the message sent 16 February 1980 1928-EST (Saturday) from Brian.Reid@CMU-10A Thanks Brian - It is your second issue that I have been trying to get onto the autopsy table. Autopsies are easier with a corpse on the table! The first issue has been pretty well covered as best I can tell, and I do not see need of beating on it further, at least not by mixing issue 1 with issue 2. I see real trouble in the future with the use of real addresses for list names, when that use disallows us users from using the name to convey information because some unconcious user may reply to it because he does not understand what he has in his hands. We don't (generally) give loaded guns to children (with notable and predictable reslts when we do), and we don't advocate legal entrapment (for even Congresspeople), or condone speed traps in Georgia, and a whole bunch of things like that. I don't condone or appreciate the presence of similar behaviors in the ARPANET or any OTHERNET where I plan to live and work. The fact that ARPANET has such undesirable behaviors in it is only acceptable because it happens to be the best and only available network environment that lets us even begin to explore what it is like to live and work in this kind of space. This does not mean we should perpetuate it. What kind of research are we doing in here anyway? This is my one and only point in this discussion. Stef -------  Date: 16 Feb 1980 1521-PST From: Mark Crispin Subject: Re: automatic CC's To: Geoff at SRI-KA cc: Header-People at MIT-MC In-Reply-To: Your message of 16-Feb-80 1506-PST In MM, the ANSWER command does ask whether or not you want ALL or SENDER. The REPLY command, which is only issued from within READ, doesn't ask. That is its purpose - to be a form of replying that doesn't ask because you can specify it on the command line. You cannot do this with top-level ANSWER because you need to give ANSWER a message-sequence. Essentially, I am talking about the default for the case when you use the command that says use the default. Asking in this case seems rather silly when you can (1) specify it and (2) use the command that asks. It's assumed that most people who use REPLY are reasonably sophisticated, since you have to be in READ to get at it (and READ is a more sophisticated command compared to the MSG-like TYPE command). -- Mark -- -------  BH@MIT-AI 02/17/80 11:12:20 Re: prompting the user To: header-people at MIT-MC More or less orthogonally to what the default should be, the user (who OF COURSE has a high-speed display terminal with good software support in the operating system) should be shown the header of the message s/he is about to send, as it currently exists, at all times during the dialog. That would solve the documentation problem.  Date: 17 Feb 1980 1421-PST From: Mark Crispin Subject: header question To: Header-People at MIT-MC I would once again like to condemn the practice of not including host names in the message header for "local addresses". Consider the following header extract: From: Jones Sender: SMITH at FOO-HOST To: Doe, Williams, Harrison cc: Jones Williams' mail at FOO-HOST is forwarded to FOO-OTHER-HOST. MM is now faced with the problem of trying to reply to this header. Only Williams has a mailbox or forwarding entry on FOO-OTHER-HOST. MM currently ignores Sender completely, since the standard says you never reply to Sender. However, in the case of this header the information it needs is only in Sender. MM's current algorithm is: If there exists a Reply-To:, then use it as the primary reply address; else use From:. Always use From:'s host information if valid (this handles the case where a local user has a Reply-To: to another host). It seems that it needs to try to get the default host name from Sender before trying From. Suppose there is no Sender? Do you use Reply-To? But that is DEFINITELY wrong!! Incidentally, MM has the "feature" of suppressing the local host name for local recepients, but ONLY if it personally delivered the message to a local mailbox. If the message is given to a mailer daemon for any reason (including mailbox busy!), it assumes the worst; that the message may go out on the network, and writes headers accordingly. -------  Date: 17 Feb 1980 (Sunday) 1900-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: Yet another totally different question, about Mail-size To: header-people at MIT-MC I have noticed a problem of abuse for the mail system, that is large papers and programs sent via netmail. At the current time I am not aware of any way to check the size of the file being sent. Perhaps a FTP error code could be allocated for those sites that want to limit the size of the incoming message to say, 150,000 characters. That is about 70 tenex pages, and YOU DO NOT REGULARLY GET 70 tenex pages from anyone, even your mother sending mail to lonely college students. This would stop the abuse that I see from time to time. What do you all think of this? (In our implimentation of NETMAIL, it is a triviality). Hank  Date: 17 Feb 1980 1624-PST Sender: GEOFF at SRI-KA Subject: Re: Yet another totally different question, about Mail-size From: the tty of Geoffrey S. Goodfellow To: DREIFU at WHARTON Cc: header-people at MIT-MC Message-ID: <[SRI-KA]17-Feb-80 16:24:37.GEOFF> In-Reply-To: Your message of 17 Feb 1980 (Sunday) 1900-EDT Reply-to: Geoff @ SRI-KA I think any sort of FTP error code about size is ridiculous --- I think common sense is the best judge here. Sure, I have gotten a paper or two via netmail from time to time, but that normally only happens once per person per ARPANET lifetime.  Date: 17 Feb 1980 2109-EST Sender: FURST at BBN-TENEXB Subject: Re: Yet another totally different question, about Mail-size From: Furst at BBN-TENEXB (Sheldon R. Furst) To: DREIFU at WHARTON Cc: Header-People at MIT-MC Message-ID: <[BBN-TENEXB]17-Feb-80 21:09:21.FURST> In-Reply-To: Your message of 17 Feb 1980 (Sunday) 1900-EDT I would have to differ. Firstly, I have received some outrageously long, yet perfectly valid network messages (the message from Jake Feinler listing liaisons for each network site immediately comes to mind, although there have been others). But more importantly, network mail is often the only way to get a file from one site to another without giving out some password. Any non-TENEX site (thus no ANONYMOUS login convention) to be specific. UNIX is an ideal example of this. I do not consider it to be "abusive" to transfer programs in this way. The only thing which might constitute abuse would be that many sites allow the mailer to exceed the disk allocation of a particular user, and thus some random might conceivably fill the disk by mailing dictionary files. Yet the advantages far outweigh the disadvantages, and I think that the two particular examples you cited are features, not faults. -- Sheldon  Date: 18 FEB 1980 1541-EST From: MOON at MIT-MC (David A. Moon) Subject: Mail size (Dreifus) To: HEADER-PEOPLE at MIT-MC Any site that wants to limit the size of incoming mail is quite free to do so. Since there are no standards for reply codes for mail (that is, there are several published standards, but there is no standard that is implemented by any large host community), you may use any reply code you like. There probably isn't anything useful you can accomplish by using a different reply code for "mail too large" than for "no such user". I don't think it would be useful to have a network standard upper limit on the size of mail.  Date: 18 FEB 1980 1340-PST From: NMAX at USC-ECL Subject: Re: Mail size (Dreifus) To: MOON at MIT-MC, HEADER-PEOPLE at MIT-MC cc: NMAX In response to the message sent 18 FEB 1980 1541-EST from MOON@MIT-MC I certainly want to concur with the opposition to a standard upper limit. We should be very carefull to avoid getting trapped in the concept of network mail services being a marginal extension of TWX And telegrams. Telegraphic communication is not where it is at for office automation, or the world of the future that we are looking for. I would be quite happy to use mail in most instances in place of FTP for text files, if there were handy maens for extracting my original file from the messgae body. I know that such handy tools can be built or course, but they have to become part of my regular facility to be regular and convenient. Please note that this is a normative comment about how I think it should be. It is not a complaint about the fact that no one has done it for me yet. Stef -------  Date: 19 February 1980 15:26 est From: Pogran.CompNet at MIT-Multics Subject: Re: Yet another totally different question, about Mail-size To: DREIFU at WHARTON (Henry Dreifus) cc: header-people at MIT-MC In-Reply-To: Msg of 02/17/80 19:02 from Henry Dreifus Henry, Are you objecting to the fact that these large objects are SENT using the NetMail mechanism, or that the NetMail mechanism is being used to distribute large objects to people who haven't asked for them? As Sheldon Furst pointed out, in the absence of login-less FTP, mailing things is about the only way to get a text file of any size, large or small, from one user to another. It's the only mechanism that can be used if you don't have the patience to find out about the intended recipient's host's file system (i.e., "What directory should I put it in? What's the syntaz of a path name on your system?), so it's a great "out" for the unsophisticated. To be sure, it may be a drain on a host's mailer or mail-receiving daemon if someone mails out numerous copies of a PhD dissertation, but is that sort of thing really all that common? Or perhaps you're unhappy with the fact that these large things wind up in your inbox along with the brief messages you'd rather pay attention to. The Postal Service developed a solution to this problem for P. O. Box holders: when an item (a parcel, say) doesn't fit in your box, they leave you a card that says "please call at window". A host's mail-receiving procedures could be set up to receive an incoming piece of mail and, if it's larger than some particular size, not put it in your inbox but, instead, put it in a separate file and synthesize a message for you that tells you the thing arrived and where it was filed. That way, you wouldn't have horrendously large things in your mailbox, yet the mechanism as seen from the network would remain uniform. Ken  Date: 20 FEB 1980 0027-PST From: ESTEFFERUD at USC-ECL Subject: Re: Yet another totally different question, about Mail-size To: Pogran.CompNet at MIT-MULTICS, DREIFU at WHARTON cc: header-people at MIT-MC In response to the message sent 19 February 1980 15:26 est from Pogran.CompNet@MIT-Multics Sure Ken, and henry - And that is what we get in some of the newer versipons of mail handlers which allow us to sepcify a process to be applied to each new arrivaal in our inboxes, automagically upon arrival. It could look at size, and put it in the BIG PACKAGE BIN, or delete itt with retention of enough info to get back to it or its source, or what ever else your imagination can think up ... It is the coming thing! Stef -------  Date: 21 Feb 80 20:36-EST (Thu) From: Farber at UDel-EE Reply-to: Farber at Rand-Unix Subject: Preliminary announcment of Symposium To: list: Message-ID: <8051.74167.9630 @ UDel-EE> IFIPS TC6 will be sponsoring a Symposium on Computer Message Systems in 1981. The Symposium is scheduled in early April 1981 and will be in Ottawa Canada. Announcements of the Symposium will be mailed out in the near future. Start thinking of papers etc. Dave  Date: 11 March 1980 0210-EST (Tuesday) From: Brian.Reid at CMU-10A Subject: Big hack attack To: :Include: "KSC;Header People" at MIT-MC CC: David.Lamb at CMU-10A, :Postal: "David Farber|Univ. of Delaware|Dept. of EE|Newark, Delaware 12345", Brian.Reid at CMU-10A Message-ID: <11Mar80 021019 BR10@CMU-10A> Ahem. Last weekend one of our Rdmail maintainers had a big hack attack and actually IMPLEMENTED those crazy :Include: and :Postal: features in RFC733. I'm not sure whether to commend David or commit him, but it's all up and running. We promise not to get carried away, but in fact :Postal: is pretty useful. Brian  Date: 14 MAR 1980 2201-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: Big hack attack To: Brian.Reid at CMU-10A CC: header-people at MIT-MC You realize, I hope, that your use of ":include:" in that message implies either fakery or illegality, because the file "KSC;HEADER PEOPLE" is in our structured-recipient syntax, which RFC733 doesn't recognize as valid (in concept or anything else). Thus, either you mis-represented your header, or RDMAIL has various special hacks that not only determine when a structured-rcpt syntax is being used, but parses it properly as well. That is a little hard to believe since it is still only an internal MIT standard; documented to be sure, but nevertheless little known outside. What actually does :POSTAL: do there? Do you really have a human being plugged into the machine, who puts copies of such messages into a physical stamped, addressed envelope? Do people bother to run off message copies on the XGP and deliver them themselves? I can think of several ways to hack it, just curious what actually happens.  Date: 14 March 1980 2252-EST (Friday) From: Brian.Reid at CMU-10A Subject: Re: Big hack attack To: KLH at MIT-AI (Ken Harrenstien) CC: header-people at MIT-MC Message-ID: <14Mar80 225238 BR10@CMU-10A> In-Reply-To: KLH@MIT-AI's message of 14 Mar 80 22:01-EST Right you are, of course; I manually converted the file. What we actually CAN handle is (a) the syntax without barfing (b) the semantics on our local machine. This allows us to send out To: :include: "foo.baz[gorp]" instead of the various To: a,b,c,d,e,f,g,h,i,...,z or To: Mumble^ or just To: that various people use to represent lists in address headers. ------------------- The way we handle :Postal: is to have another delivery demon running in parallel to the arpanet delivery demon; files queued for postal delivery are stored in a certain directory. The demon produces dover output, which gets filed in a certain bin. We have a daily run that prints out people's machine mailboxes (if they ask for it) and the secretaries put it in their physical mailbox. The dover output is structured so that the address shows through the window of a window envelope when it is folded in thirds. If it is official department business, the envelope is just put into the mail by staff. If not (how we tell isn't exactly certain yet; this is an administrative bug that needs to be worked out) then it just gets put into the person's physical mailbox. In general CMU CSD will meter outgoing mail without needing a charge number to bill it to; it all just goes a slush account, so there's no need to bill postage back to accounts. Brian  Date: 15 MAR 1980 1719-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: error in mail To: Lauren at UCLA-SECURITY CC: MOON at MIT-MC, HIC at MIT-MC, header-people at MIT-MC I'm sending this additional information to HEADER-PEOPLE as well, to forestall any other queries and to disseminate a technique useful for small or overloaded hosts. Lauren (and some others) have wondered why the ITS FTP server sometimes just closes the FTP connections after receiving a MAIL or MLFL command, without returning any reply code to indicate the nature of the failure. Well, this situation happens when the server determines that the backlog of mail to be processed is unreasonably large (typically this indicates that very little disk space is left!) and wants to refuse all incoming network mail. To do this, it simply closes the connections because there is no error code that will unambiguously mean "temporary error, try again later." FTP reply codes are really messed up; 4xx codes are supposed to be "temporary" and 5xx "permanent", but in practice a 4xx reply will often be interpreted as permanent. So the server simply kills itself to simulate a host crash or the like, which all mail sending programs obviously have to regard as temporary. It happens that this is almost always the most efficient thing to do anyway, because if no incoming net mail is allowed, what's the point of remaining connected? Only send-mail programs should be using MAIL or MLFL these days, and they have nothing else to do if mail isn't allowed; in fact, just returning a 4xx temporary error would probably be interpreted as "this recipient won't work right now, but others might" and the sending program would keep on ineffectively (and inefficiently) flailing away with all possible recipients. If the right thing were done, mail protocols would happen using a different server, thus a different ICP socket, which could simply be disabled whenever the host felt a little stuffed; this avoids protocol questions altogether. Don't even THINK about trying to implement a 4xx code for this situation!! P.S. This is one of the features I have added to SRI-TSC's UNIX FTP server to prevent the DEAFNET gateway from drowning in arpanet mail. The original implementation on ITS was Dave Moon's.  Date: 15 Mar 1980 1948-PST From: Mark Crispin Subject: 4xx codes which imply requeueing To: Header-People at MIT-MC XMAILR (the SU-SCORE and MIT-XX mailer daemon) has the following list of codes which mean "temporary mail failure" as opposed to hard failure: 401, 434, 436, 452, 453, 454. Tenex's MAILER (known as NMAILR on TOPS-20) uses the same list. There are one or two other codes which I used to know (in particular, UNIX sites send some strange 4xx code meaning their disk is full), but I lost the list I had of them. It just means that I have to wait until mail to some UNIX site fails due to their disk being full. Anyway, the point is that that list up above seems to be well known as "non-hard" mail failures. I am not making any judgements about the MIT ITS implementation of closing the connection without any message when its disk is full (or whatever). Back in the early days of XMAILR, it caused several XMAILR crashes until I bullet-proofed XMAILR against the network connection randomly closing (a non-trivial amount of code). -- Mark -- PS: For those of you who may be interested, XMAILR is a multi- network mailer daemon. It replaces the Tenex MAILER program. XMAILR uses the "HOSTS2" host table developed at MIT and Stanford; HOSTS2 currently contains configuration information for four networks and can be expanded to cover the entire internet world. XMAILR runs on TOPS-20 release 4 (and 3A systems which use 96-bit leaders), and was originally written by Mike McMahon at MIT (the author of MM). -------  Date: 19 Mar 1980 at 0740-CST From: david at UTEXAS Subject: Arpanet access control To: header-people at mit-ai,msggroup at mit-ml I just learned that the administrator of this system is working to install some form of Arpanet access control. In my work around the net I have seen no evidence of such controls on other systems. So I am curious as to whether there are systems that have access control, and if so, can you characterize how official access policy is applied? Thank you. David M. Phillips, liaison UTexas -------  Date: 19 Mar 1980 0618-PST From: Zellich at OFFICE-1 Subject: Re: Arpanet access control To: david at UTEXAS, header-people at MIT-AI, To: msggroup at MIT-ML cc: ZELLICH In response to the message sent 19 Mar 1980 at 0740-CST from david@UTEXAS I am aware of one type of existing control that, at least in theory, is applied to commercial systems such as the one I am using, that does not permit commercial-account users from accessing the ARPANET. I assume they are restricted from using certain programs (TELNET, FTP, mayne MSG?) and must instead use TYMNET-access programs for equivalent uses. I am also aware that DCA is working on, or has at least proposed, two different ways of restricting ARPANET access: TIP Logins, to keep randoms from getting into the net via Ma Bell's phone "net"; Some kind of TELNET access control (TELNET Login, God forbid?), intended to keep non-ARPANET users at ARPANET host sites from gaining access to the net once logged in on their local hosts. Since access to any of the hosts via either TIP or TELNET (or FTP) generally requires a login and password at the host being accessed, I see no valid reason for either of these proposed controls (other than it keeps GAO, who doesn't know the difference anyway, happy and off DCA's collective back). -------  Date: 19 MAR 1980 1054-EST From: JNC at MIT-AI (J. Noel Chiappa) Subject: Access control To: david at UTEXAS CC: msg-group at MIT-ML, header-people at MIT-MC Multics has access controls on a more fundamental level; i.e. it's not built into the user programs (since a programming user could circumvent them) but the monitor "calls" (the Multics equivalent thereof, actually) have access control lists on them; the MIT system (since it has non government people and even outside commercial users) makes use of this to prevent net access to all except authorized types. Noel  Date: 19 March 1980 11:16 est From: Sibert.SysMaint at MIT-Multics (W. Olin Sibert) Subject: ARPAnet access control, Multics To: HEADER-PEOPLE at MIT-AI, MSGGROUP at MIT-AI Multics, bless its complicated little heart, implements a highly flexible form of access control for the network, which allows one to restrict a users access to the network as a whole, or allow him to access only particular hosts. There are also all sorts of privileged administrative tools for making enquiries of the network software. All this control is, of course, an inconvenience, but it does seem to be exactly what the DCA wants. -- Olin  Date: 19 Mar 1980 0827-PST Sender: GEOFF at SRI-KA Subject: Re: Arpanet access control From: the tty of Geoffrey S. Goodfellow To: Zellich at OFFICE-1 Cc: header-people at MIT-MC, msggroup at MIT-ML Message-ID: <[SRI-KA]19-Mar-80 08:27:08.GEOFF> In-Reply-To: Your message of 19 Mar 1980 0619-PST Reply-to: Geoff @ SRI-KA The only problem with your theory (that access to any of the hosts via either TIP or TELNET generally requires a login and password) would (almost) work if that were indeed the case. There is a collection of hosts on the east coast at a well known institute, that seems to give out accounts/logins and password to just about any ol' random who requests them (and if this is a mistatement, an out right lie or otherwise, feel free to rake me over the coals for it and/or correct me). There are also other hosts that have a general guest account on them. You'd be surprised how fast these accounts get found out. I have seen a new system come on the net, have an unannounced guest account, and in one week they are saturated, and then usually by the end of month, one of the guests has done something nasty like compromise security or crash the system or delete or munge unsuspecting users files. Which brings me to the next point; allowing the randoms to get on the net in the first place, allows them to then have run-of-the-arpanet-backyard, and try their sharp hands as cracking and breaking into the various systems around the net --- fun fun fun! There have also been cases in the past, where such randoms, would link to a user (the random not being logged in) and fake him/her out that the password file had been lost or something and for them to tell this "official" person their password. The piece da resistance of this was when Col. Dave Russell was director of IPTO at ARPA, we got a link from "him" supposedly on the AMES-TIP via RSEXEC, which said "your contract has been canceled, and your host will be removed from the net". The other piece da resistance was a link from "the almighty himself" from the UTAH-TIP. There have also been numerous other "hacks" like this pulled on users from net randoms, and hence, i came to the consensus that its best to keep them at bay at the shell of the net. If someone feels they want to bear the responsibility of letting a "random" on the net, that is fine, they can just let them use THEIR tip login or otherwise, so that when an abuse is detected, the system administrator of the hacked system can call up net control and say "Who was logging in last night at 3am from the X-TIP" and get an answer with a finger to point. This to me seems much more responsible than just changing tip numbers around every 6 months, which get passed around and fall into the wrong hands, as no one feels its THEIR responsibility to protect them. Of course, the entire TIP login system will be shot to nothing if "general" type logins are done, as opposed to one for each net user. Last I heard on TIP LOGIN was that BBN wanted a million bucks to do it, and that it would be based on some of the concepts done in the NSW system, and would consist of 2 PDP-11/70 systems. I wonder of the GAO is willing to bite off a million bucks to do it, if indeed, that is the correct amount. Lastly, I want to make clear (in order to avoid having upset some people and taking some flak) that i have nothing against randoms on the net, just as long as they are controlled. i feel that the responsibility of such randoms will be of a much higher quaility than it is now, and there will be a less proliferation of them. if each one of these randoms feels that someone in a "responsible" position was kind enough to lend them their tip or host login in order for them to have access to the net -- and there are several people on my list who will be using my tip login in order to communicate with me and use my systems at my discretion when and if tip login is ever implemented.  Date: 19 Mar 1980 1037-EST Forwarded-to: header-people at MIT-AI, msggroup at MIT-ML, Raver at MIT-DMS Forwarded-by:WJN at MIT-DMS on 19 Mar 80 at 1151 EST From: WJN at MIT-DMS (Wayne J. Noss) To: david at UTEXAS In-reply-to: Message of 19 Mar 80 at 0000 EST by david@UTEXAS Subject: [Re: Arpanet access control] Message-id: <[MIT-DMS].140843> Notes: [From WJN] Perhaps I should have distributed this to the mailing list rather than just to the sender. A few months ago a situation arose where FTP-type access between MIT-MULTICS and MIT-XX was desired, so the comments are not merely hypothetical. Given that restricting FTP access from outside is pointless when TELNET works, I think a more reasonable approach would be either to prohibit logging into non-net accounts from outside or to allow the FTP server, logged in as some user, to access anything that user can access AND access the necessary monitor support to do the FTP. I prefer the latter of these alternatives because I think the proper role of a server (TELNET or FTP) in authentication is determining what access to allow to the local machine, NOT deciding whether or not the user should be on the net. Access to the net has already been established before the user tries to log the FTP server, so why check again? Message: David, I understand that MIT-MULTICS has ARPAnet access control. I know little about it, except that Multics users can't TELNET or FTP from Multics to other sites unless they have the necessary privilege, which can be granted by a system administrator. Also, one can not log in the Multics FTP server from another site without Multics net access. What seems to me to be a rather absurd inconsistency is that anyone can TELNET into the system if (s)he has an account, whether or not that account has net access privileges. So files can be transferred (inefficiently) using TELNET by dumping to a log file at the other site or by feeding data in from another site. Lack of FTP access therefore just means that the system gets more bogged down than it would otherwise when someone wants to transfer a file. I would suggest contacting the Liaison on that system for details. the Raver  Date: 19 March 1980 17:47-EST From: Earl A. Killian Subject: ARPAnet access control, Multics To: Sibert.SysMaint at MIT-MULTICS cc: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-AI I wouldn't call Multics' ARPAnet access control "highly flexible". Last time I was a Multics user the system administrator was unable to grant me access to both MIT-Multics itself (there was an obscure reason for wanting this) and the ITS systems.  Date: 19 Mar 1980 1413-PST (Wednesday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: arpanet access control under Unix To: HEADER-PEOPLE at AI,MSGGROUP at AI While we felt no need for extremely hairy access restrictions, I implemented a group structure a couple of years ago that prevented unauthorized users from accessing any net software (telnet, ftp, etc.) on our unix system, simply by setting protections correctly. Unless a user can demonstrate a real need for net access, he/she is put in one of the restricted groups that cannot access those programs. The whole thing was very simple and has worked fine. --Lauren-- -------  Date: 19 MAR 1980 2232-EST From: JNC at MIT-AI (J. Noel Chiappa) Sent-by: ___050 at MIT-AI Subject: Foo... To: msggroup at MIT-ML, header-people at MIT-MC Do I hear a volunterr for creating MSG-HDR-GROUP-PEOPLE? Getting all this mail TWICE is a real drag. Noel  Date: 20 March 1980 11:39 est From: Pogran.CompNet at MIT-Multics Subject: Re: ARPAnet access control, Multics To: Earl A. Killian cc: Sibert.SysMaint at MIT-Multics, HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-AI In-Reply-To: Msg of 03/19/80 17:47 from Earl A. Killian For heaven's sake! The Multics system's ARPANET access control certainly IS highly flexible; trouble is, some of their system adminsitrators might not be! Ken  Date: 20 March 1980 20:44-EST From: Charles Frankston Subject: header-people To: MSGROUP at MIT-MC, HEADER-PEOPLE at MIT-MC Date: 19 MAR 1980 2232-EST From: JNC at MIT-AI (J. Noel Chiappa) Sent-by: ___050 at MIT-AI Subject: Foo... To: msggroup at MIT-ML, header-people at MIT-MC Do I hear a volunterr for creating MSG-HDR-GROUP-PEOPLE? Getting all this mail TWICE is a real drag. Noel Date: 20 March 1980 01:14-EST From: FOO at MIT-AI Subject: header-people To: MSGGROUP at MIT-AI Can't we assume that header people is nearly a subset of msggroup? So send messages to msggroup only. If people would just send both messages to the same machine, then the ITS Comsat would be happy to weed out duplicate messages. It doesn't really have a chance when people scatter the messages among AI, ML and MC. For the record, header-people lives on MC. I normally encourage people to send MsgGroup out through ML to distribute the load, but I keep a parallel on MC for just this purpose. If you recieved this message twice, its because your name in the Msggroup file and your name in Header-People do not seem identical to ITS. (Ie. Sibert@MIT-Multics and Sibert.SysMaint@MIT-Multics are different, but Sibert@Multics and Sibert@MIT-Mul are the same).  Date: 20 MAR 1980 2149-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: Duplicate eliminations To: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-MC Unfortunately, CBF's statement (that COMSAT will weed out duplicates if you send the message to just the MC lists) is only true if the mail-sending program is local (on MC) or uses the FTP XRCP mechanism that I mentioned previously.  Date: 25 MAR 1980 0314-EST From: DAUL at MIT-MC (William Daul) Subject: INFO WANTED To: HEADER-PEOPLE at MIT-MC Could someone please tell me what the subject "header-people" is? THX.  Date: 25 March 1980 0321-EST (Tuesday) From: Brian.Reid at CMU-10A Subject: Re: INFO WANTED To: DAUL at MIT-MC (William Daul) CC: HEADER-PEOPLE at MIT-MC Message-ID: <25Mar80 032134 BR10@CMU-10A> In-Reply-To: DAUL@MIT-MC's message of 25 Mar 80 03:14-EST As Louis Armstrong is purported to have said when somebody once asked him what jazz was, "If you gotta ask, you ain't gonna understand the answer."  Date: 25 Mar 1980 0257-PST From: FEINLER at SRI-KL Subject: Re: INFO WANTED To: Brian.Reid at CMU-10A, DAUL at MIT-MC cc: HEADER-PEOPLE at MIT-MC, FEINLER Well, we would all have to concede that Header People is a lot of jazz! Jake -------  Date: 27 Mar 1980 (Thursday) 0907-EST From: COTTON at NBS-10 Subject: removal from mailing lists To: human-nets at MIT-AI, header-people at MIT-MC, msggroup at MIT-MC Please remove my name from all automatic distribution mailing lists (COTTON@NBS-10) since I will be leaving NBS shortly. After April 1 I will be at Booz, Allen & Hamilton, Inc., 4330 East West Highway, Bethesda, MD 20014. (301/951-2200) Ira Cotton  Date: Friday, 25 April 1980 13:50-PST From: MACRAKIS at USC-ISIE To: CASS at USC-ISI, Header-people at MC cc: Action at USC-ISIE, Macrakis at USC-ISIE Subject: MSG and "From:" [Background] ISI MSG displays the Sender and not the From field in its Header display. I would have thought that the From field was appropriate, but ISI interprets the fields differently from my expectation. I'm not sure which RFC defines the From and Sender fields. I do know that both Multics (MIT and Honeywell) and all MIT sites define "From" as the person who should be considered as the spiritual author of a message, and "Sender" as the person who sent it by entering keystrokes. This corresponds to the convention in English. A letter from the White House is "from" Jimmy Carter even though he had nothing directly to do with writing, typing, or mailing it. Some functionary presumably "sent" it. Of course, Multics and MIT may well have it backwards. I seem to recall something about a "claimed-from" field as well... In any case, this seems like something that should be resolvable one way or another among the maintainers of mail systems. Consistency is much more important than the names of the fields. Stavros Macrakis Intermetrics  Date: 27 APR 1980 0322-EST From: MOON at MIT-MC (David A. Moon) Subject: MSG and "From:" To: MACRAKIS at USC-ISIE CC: HEADER-PEOPLE at MIT-MC, CASS at USC-ISI, Action at USC-ISIE This was made a standard some time ago; refer to the file [SRI-KL]RFC733.TXT. I am sure the MIT mail systems conform to the standard as far as From vs Sender goes. It is a reasonable enough standard. Some Tenex mail systems do not conform, for some reason.  Date: 28 Apr 1980 1316-PDT Sender: LINDA at USC-ISIF Subject: Re: MSG and From From: Postel@ISIF To: Macrakis at ISIE Cc: Cass at ISI, Header-people at MC, Action at ISIE Message-ID: <[USC-ISIF]28-Apr-80 13:16:21.LINDA> Stavros: MSG is wrong. It is an old program. I hope it will be fixed, but I am not optimistic that it will be. --jon JP/ls  Date: 29 Apr 1980 1010-PDT From: CASS at USC-ISI Subject: Re: MSG and "From:" To: MACRAKIS at USC-ISIE, Header-people at MC cc: Action at USC-ISIE, CASS, REID at CMUA, MOON at MIT-MC, cc: POSTEL at ISIF In response to the message sent Friday, 25 April 1980 13:50-PST from MACRAKIS@USC-ISIE Stavros, First, I am sorry that MSG does not work as you want. We can put fixes on the list of things to do, but I cannot promise that fixes will happen rapidly. I believe that you are using the Wrong Mail System for your application! Please try MM (It is on because Mark Crispin, and several other people maintain it for us.) It uses the TOPS-20 COMND Parsing JSYS, and is faster than you would at first think (Strinctly PMAPed I/O...) Try it, you might like it (Note, you may still have problems with Sender since it only sees it and will not send it...) If MM does not do what you need, please Use HERMES, it may be slow but it will do the job. Enjoy, DEC -------  Date: 28 May 1980 1848-EDT (Wednesday) From: Brian Reid at CMU-10A Subject: FYI: Hermes To: Header-People at MIT-MC Message-ID: <28May80 184851 BR10@CMU-10A> For those of you who have, like CMU, had to hack up your mail senders to do vile things so that Hermes could cope with them, it appears that Hermes has cleaned up its act a little. The Hermes people just never bothered to tell us. Earl Killian at BBN reports as follows: - - - - Begin forwarded message - - - - Date: Wednesday, 28 May 1980 18:40-EDT From: Earl Killian To: Brian Reid at CMU-10A cc: Jan Walker Subject: spaces and dots Via: BBNA; 28 May 1980 1842-EDT There was an announcement via the Hermes NEWS command: February 6, 1980: 1. ... 2. ... 3. Hermes has improved handling for a number of types of fields. * Hermes will create, reply to, and otherwise handle usernames containing "white space", i.e., spaces or tabs. Exception: The EXPLODE or EDIT MESSAGE command does not carry over usernames containing "white space" into the draft. Please note that many host computers do not allow white space in usernames. The systems that do not allow white space in usernames are, in general, systems that require the username to be the same as the directory name. * Hermes will correctly reply to a message with a From: field that contains the username enclosed in angle brackets, unless there is a string in parentheses following the angle brackets. * Hermes will now recognize dates in the form: Tues., 5 February 1980 but it will not create dates in this form. For the purpose of determining the date, Hermes ignores the day-of-week string, and does not check to find out whether 5 February 1980 is, in fact, a Tuesday, or whether the string "Tues." is a valid day of the week. - - - - End forwarded message - - - -