20-Sep-82 14:36:42-PDT,6765;000000000001 Mail-from: ARPANET site BRL rcvd at 20-Sep-82 1431-PDT Date: 20 Sep 1982 0031-PDT Sender: MSGGROUP at Usc-Eclc Subject: MSGGROUP#1901 SURVEY #1851-#1900 from MSGGROUP.1801-1900.1 From: MsgGroup Moderator - Einar Stefferud Reply-To: MsgGroup-Request at BRL To: MSGGROUP at BRL Message-ID: <[USC-ECLC]20-Sep-82 00:31:33.MSGGROUP> Via: Usc-Eclc; 20 Sep 82 3:32-EDT Via: Brl; 20 Sep 82 13:55-EDT Via: Brl-Bmd; 20 Sep 82 14:58-EDT MSGGROUP#1851 SURVEY #1800-#1850 from MSGGROUP.1801-1900.1 7003 chars 30 Aug 1982 1927-PDT From: MsgGroup Moderator - Einar Steffe MSGGROUP#1852 Re: Xerox Woes -- Variable width fonts 2684 chars 29 Aug 1982 0453-PDT From: Mark Crispin To: reid.SU-SHASTA a MSGGROUP#1853 Re: Xerox Woes -- Long lines with out returns in them. 1443 chars 29 August 1982 1919-EDT (Sunday) From: David.Lamb at Cmu-10a MSGGROUP#1854 Re: Line folding 1587 chars 29 Aug 1982 18:40-PDT - Sunday From: gaines at Rand-Unix To: MSGGROUP#1855 Re: Effective Communication 3610 chars 30-Aug-82 20:06:42 PDT (Monday) From: Phil Karlton MSGGROUP#1858 Xerox Woes -- Long lines with out returns in them. 2566 chars 31 August 1982 11:49-PDT - Tuesday From: Jonathan Alan Solo MSGGROUP#1859 Background and info on the Xerox environment 7073 chars 31-Aug-82 15:35:03 PDT (Tuesday) From: holbrook.ES at Parc-M MSGGROUP#1860 Background and info on the Xerox environment 3221 chars 31 August 1982 16:40-PDT - Tuesday From: Jonathan Alan Solo MSGGROUP#1861 Re: Line folding and Effective Communication 1427 chars 31 August 1982 1951-EDT (Tuesday) From: Craig.Everhart at Cm MSGGROUP#1862 Re: Background and info on the Xerox environment 2568 chars 31 August 1982 20:23 edt From: Barry.Margolin at Mit-Multi MSGGROUP#1863 more on Xerox mail 2424 chars 31 Aug 1982 2150-PDT From: Mark Crispin To: MsgGroup at Usc- MSGGROUP#1864 Re: Background and info on the Xerox environment 2608 chars 1-Sep-82 9:53:18 PDT (Wednesday) From: holbrook.ES at Parc MSGGROUP#1865 Re: Xerox Woes -- Long lines without returns in them. 1030 chars 2-Sep-82 18:34:32 PDT (Thursday) From: AlHall at Parc-Maxc MSGGROUP#1866 Query on Recipient Specified Redistribution 1082 chars 6 Sep 1982 1356-PDT From: MsgGroup Moderator - Stefferud MSGGROUP#1872 Re: number of messages 965 chars 7 Sep 1982 1309-PDT From: Mark Crispin To: Header-People at MSGGROUP#1873 Stef's comment on my answer to Jake 2010 chars 7 Sep 1982 14:57-PDT - Tuesday From: Brian Reid MSGGROUP#1875 local mail vs. network mail 2718 chars 7 Sep 1982 1641-PDT From: Mark Crispin To: MsgGroup at BRL, MSGGROUP#1876 Re: #1831 Re: Xerox Woes -- Variable width fonts and local mail vs. network mail 1141 chars 7 September 1982 2356-EDT (Tuesday) From: Craig.Everhart at MSGGROUP#1877 Long lines and the Arpanet 2140 chars 7 Sep 82 23:50:33-EDT (Tue) From: Doug Kingston MSGGROUP#1878 statistics 808 chars 7 September 1982 20:36-EDT From: Earl A Killian MSGGROUP#1879 minor complaint 756 chars 7 Sep 82 23:46:13 EDT (Tue) From: smb.unc at BRL To: Msg MSGGROUP#1880 Re: #1866 Re: recipient specified redistribution 2227 chars 8 Sep 1982 9:42:37 EDT (Wednesday) From: schoka at Mitre T MSGGROUP#1881 Re: Stef's comment on my answer to Jake 1778 chars 8 September 1982, 03:58-EDT - Wednesday From: Robert W Kerns MSGGROUP#1882 Re: Xerox Woes -- Long lines without returns in them. 603 chars 9 Sep 1982 0219-PDT From: Mike Peeler MSGGROUP#1883 UCL statistics 742 chars 9 Sep 82 9:17:35-BST (Thu) From: Steve Kille To MSGGROUP#1887 header mangling 2333 chars 10 Sep 1982 0111-PDT From: Mark Crispin To: MsgGroup at BRL, MSGGROUP#1888 Re: UCL statistics 935 chars 10 Sep 82 9:09:25-BST (Fri) From: Steve Kille T MSGGROUP#1896 Re: Header Mangling. 1048 chars 13 Sep 1982 1239-EDT From: Larry Campbell To: r 20-Sep-82 12:23:11-PDT,564;000000000001 Mail-from: ARPANET site BRL rcvd at 20-Sep-82 1220-PDT Date: 18 Sep 1982 0105-PDT From: Mike Peeler Subject: MSGGROUP#1902 Re: REMOVAL OF NAME FROM MAILING LIST To: MCCRARY at Usc-Isie cc: MSGGROUP at BRL In-Reply-To: Your message of 17-Sep-82 1300-PDT Via: Su-Score; 19 Sep 82 17:52-EDT Via: Brl; 20 Sep 82 12:35-EDT Via: Brl-Bmd; 20 Sep 82 14:16-EDT Look, anybody else who wants off, fine, but the address to send your requests to is MSGGROUP-REQUEST, not just plain MSGGROUP. Thanx, Mike ------- 20-Sep-82 14:47:17-PDT,1178;000000000001 Mail-from: ARPANET site BRL rcvd at 20-Sep-82 1444-PDT Date: 20 Sep 1982 1601-EDT Sender: MOOERS at Bbna Subject: MSGGROUP#1903 Re: REMOVAL OF NAME FROM MAILING LIST From: MOOERS at Bbna To: Admin.MDP at Su-Score Cc: MCCRARY at Usc-Isie, MSGGROUP at BRL Cc: Mooers at Bbna Message-ID: <[BBNA]20-Sep-82 16:01:34.MOOERS> In-Reply-To: Your message of 18 Sep 1982 0105-PDT Via: Bbna; 20 Sep 82 16:08-EDT Via: Brl; 20 Sep 82 16:20-EDT Via: Brl-Bmd; 20 Sep 82 16:34-EDT How about changing the address for MSGGROUP to MSGGROUP-BROADCAST (or something similar but shorter)? Then you can change MSGGROUP-REQUEST to MSGGROUP. The advantage of this change is that the smaller group of people who want to broadcast messages to the whole group can learn the less obvious name, and if they make mistakes and send messages to MSGGROUP, the manager of the MSGGROUP will eventually straighten things out. The larger group of people who want to be put on or taken off of the list can send messages to MSGGROUP, which is the obvious thing to do. I think this little bit of human engineering or common sense could make life easier for everyone. ---Charlotte 21-Sep-82 00:25:43-PDT,1177;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Sep-82 0010-PDT Date: 20 Sep 1982 2213-PDT Sender: STEF at Darcom-Ka Subject: MSGGROUP#1904 Re: Don't change mailing list conventions From: STEF at Darcom-Ka To: MsgRoup at BRL Message-ID: <[DARCOM-KA]20-Sep-82 22:13:37.STEF> In-Reply-To: Your message of 20 Sep 1982 17:52:43-EDT Via: Darcom-Ka; 21 Sep 82 1:40-EDT Via: Brl-Bmd; 21 Sep 82 2:18-EDT I agree that changing the name or the conventions is not a solution in this case. Our offending members who want off the list are simply unconcious of the results of their actions. Such people will be with us always, and they will use the name that they see most often, which is not msggroup-request. Perhaps you would suggest that I insert a large visible notice about how to request removal, into each message as it goes through the distributor? I somehow doubt that many would approve. (No! Don't send me your votes!) So, I would rather encourage you all to simply exercise your option to delete such mail and otherwise ignore it. The clamor is worse than the problem, every time this happens. Ah! Sweet Oblivion! Would that I could be so! Stef 21-Sep-82 00:45:56-PDT,2077;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Sep-82 0041-PDT Date: 20 Sep 1982 17:52:43-EDT From: mullen at Nrl-Css (Preston Mullen) To: MOOERS at Bbna, MSGGROUP-REQUEST at BRL Subject: MSGGROUP#1905 Don't change mailing list conventions Via: Nrl-Css; 20 Sep 82 17:59-EDT Redistributed-To: msggroup at BRL Redistributed-By: STEF at Darcom-Ka Redistributed-Date: 20 Sep 1982 Via: Darcom-Ka; 21 Sep 82 1:40-EDT Via: Brl-Bmd; 21 Sep 82 2:16-EDT [MsgGroup administrator: you may send this to MsgGroup if you think it will close off discussion on this topic.] All this useless traffic is getting tiresome. Ignorance is excusable, but I am beginning to suspect frowardness as a factor. The ARPANET mailing list convention is that the mailing list name is used to submit contributions and that a related name, usually the list name with "-Request" appended to it, is used for requests to the administrator. This convention is widely known and is brought to the attention of people when they join a mailing list; also, the addresses for the list and for the administrator are both given in the list of lists put out by ZELLICH@OFFICE-3. [It is therefore ironic that most of the people broadcasting these annoying requests are at OFFICE-3 themselves!] Think of "MsgGroup" as a collective name for "the group of people who share an interest in message systems" and you will see why it is ridiculous to send administrative messages like "take me off your list" to everyone in "MsgGroup" -- unless one is attempting to demonstrate dissatisfaction with the list to a wide audience, in which case, if the REASONS for the dissatisfaction were added, the message might actually be of interest to the group. It isn't worth violating the general net convention to avoid this nuisance, which arises only with direct-remail lists, and only rarely at that (except for the recent flurry). [Note: the list of lists mentioned above is available via FTP as [OFFICE-3]INTEREST-GROUPS.TXT, but I don't remember whether it is necessary to log in.] 21-Sep-82 01:40:49-PDT,844;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Sep-82 0140-PDT Date: 21 Sep 82 2:24:30-EDT (Tue) From: Michael Muuss To: MOOERS at Bbna cc: Admin.MDP at Su-Score, MCCRARY at Usc-Isie, MSGGROUP at BRL, Mooers at Bbna Subject: MSGGROUP#1906 Re: REMOVAL OF NAME FROM MAILING LIST Via: Brl-Bmd; 21 Sep 82 2:50-EDT Via: Brl; 21 Sep 82 3:05-EDT Via: Brl-Bmd; 21 Sep 82 3:19-EDT Charlotte - Surely you don't think that the traffic to maintain a mailing list comes anywhere close to the traffic that the list actually carries? The TCP Digest, with a readership of over 1000 and a seasonal contribution rate still has fewer maintenance messages than actual traffic. Is it really unreasonable to have people remeber to append -REQUEST to a mailing list name when they have a request? Best, -Mike 21-Sep-82 17:17:37-PDT,1134;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Sep-82 1713-PDT Date: 21 Sep 82 14:20:35-EDT (Tue) From: Gene Spafford To: MsgGroup-Request at BRL Subject: MSGGROUP#1907 suggestions Via: GATech; 21 Sep 82 18:26-EDT Via: Udel-Relay; 21 Sep 82 18:42-EDT Redistributed-To: msggroup at BRL Redistributed-By: STEF at Darcom-Ka Redistributed-Date: 21 Sep 1982 Via: Darcom-Ka; 21 Sep 82 19:27-EDT Via: Brl-Bmd; 21 Sep 82 19:30-EDT If I may make a suggestion or two... how difficult would it be to collect submitted articles into one "digest" (as is done with Human-Nets) and then remail that digest rather than simply forward the submitted article? If you were to do this, you could include two lines in the header like: Requests: MsgGroup-Request at BRL Publish: MsgGroup at BRL or something similar. This might help avoid the incidence of people broadcasting requests to be removed from the mailing list. It would also make it a lot easier for those of us who subscribe to many newsletters and have to manually sort the letters ourselves. Just thought I'd ask. Gene 21-Sep-82 21:29:49-PDT,497;000000000001 Mail-from: ARPANET site BRL rcvd at 21-Sep-82 2129-PDT Date: 21 Sep 1982 1730-PDT From: jim vernon Subject: MSGGROUP#1908 suggestions To: msggroup at BRL cc: spaf.gatech at Udel-Relay Via: Usc-Isif; 21 Sep 82 20:31-EDT Via: Brl; 21 Sep 82 22:48-EDT Via: Brl-Bmd; 21 Sep 82 23:00-EDT I think the idea for a digest of some sort is a good one, but I also think that the issue of MsgGroup-Request vs. MsgGroup is a separate topic from the digest question. --jrv 22-Sep-82 00:14:35-PDT,737;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 0011-PDT Date: 22 Sep 82 2:23:48-EDT (Wed) From: Michael Muuss To: jim vernon cc: msggroup at BRL Subject: MSGGROUP#1909 Re: suggestions Via: Brl-Bmd; 22 Sep 82 2:25-EDT Via: Brl; 22 Sep 82 2:31-EDT Via: Brl-Bmd; 22 Sep 82 2:40-EDT Of course, switching to a Digest format has two costs: 1) Time and Effort for the moderator, to prepare the digests. 2) Delay in turnaround while "enough" mail accumulates to make a digest. (Usually, 3 or more messages). #1 is the real kicker, as Stef is probably too busy to play moderator, and finding a volunteer is likely to be difficult. Any volunteers? Best, -Mike 22-Sep-82 01:54:32-PDT,2138;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 0149-PDT Date: 22 Sep 1982 0054-PDT Sender: STEF at Darcom-Ka Subject: MSGGROUP#1910 Digest suggestions From: STEF at Darcom-Ka To: MsgGroup at BRL Message-ID: <[DARCOM-KA]22-Sep-82 00:54:36.STEF> In-Reply-To: Mike's message of 22 Sep 82 2:23:48-EDT (Wed) Via: Darcom-Ka; 22 Sep 82 3:56-EDT Via: Brl; 22 Sep 82 4:08-EDT Via: Brl-Bmd; 22 Sep 82 4:13-EDT It is my experience that shifting to a Digest mode causes significant changes in the character of discussions, due to delayed transmission. What I have noted is that the disgests often contain a public report of what was a private discussion among a group who included each other in their CC fields. I feel that this is limiting in some unfortunate ways, so I will continue to resist the simple Digest mode. I have in the past considered segmenting the lists into two or three levels of distribution service, and one of these might turn out to be a Digest mode. What I would do is to offer delayed distribution of processed items, with the MSGGROUP#nnnn accession numbers inserted, and irrelevant items discarded. This might be fine for those who want to watch, but will not likely contribute. Another offer would be to have a SURVEY list for those who only want to see the Index of mesages that are flowing, so they might be able to fetch or request a copy of items that look interesting. There would be 3 levels: The FRAY list, DIGEST list, and SURVEY list. All this would require some additional work, much of which might be automated. Volunteered effort would be appreciated, but only if it is offered in support of these kinds of ideas. I am also looking at ways to revamp the immediate distribution mechanism as I have mentioned in earlier messages. BTW, I have taken a somewhat different view towards archiving, et al, than I find in some other group lists. I have always believed that the transcript of MsgGroup should be kept accessible for public access and reference, and I have managed to keep it thus ever since the group began in June of 1975. Cheers - Stef 22-Sep-82 08:18:23-PDT,2872;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 0814-PDT Date: 22 Sep 1982 0631-PDT Sender: WMARTIN at Office-8 Subject: MSGGROUP#1911 Format change suggestions From: WMartin at Office-8 (Will Martin) To: Msggroup at BRL Message-ID: <[OFFICE-8]22-Sep-82 06:31:28.WMARTIN> Via: Office-8; 22 Sep 82 9:32-EDT Via: Brl; 22 Sep 82 9:40-EDT Via: Brl-Bmd; 22 Sep 82 9:52-EDT The recent suggestions about digestifying Msggroup prompt me to mention this: Has anyone else noticed that the net digests, except the more sporadic ones (TCP-IP, Telecom, Poli-Sci), or the totally automated ones (Space is the only one like that I know of) seem to be dying or have died? I'd hate to see that happen to Msggroup, too! Human-Nets went through a long hiatus, seemed to revive (though the submissions from the gap period were never distributed), and has now sunk back into limbo. SF-Lovers has used up "n" moderators and is only sent out in spasms, often with signs of disinterested editing (outdated messages about time-dependent items included). It's not for lack of submissions; you can FTP files of undigestified input from the home directories of the big lists. I fear that unpaid moderatorship rapidly palls, and it becomes an onerous task which is avoided after a relatively short time. The original digests were all moderated by Roger Duffey, who used them to get a thesis on computer communication -- without such a payback, moderators have little incentive. I have often thought that some academic site(s) whose administrators could be persuaded into viewing digest maintenance and mailing as a research tool and community participation could solve the problem by getting some use out of the proverbial "high-school hackers" the net security people used to complain about so much. (They are still out there, aren't they?) I say an academic site, because they have more freedom about access and accounting than an audited government or contractor site. Such a school could pay a hacker to be a moderator/maintainer by granting an account or access to their system, and thus the net. As long as the hacker performs well as a moderator, his privileges are continued. When the list dries up due to moderator indifference or otherwise ceasing work, these privileges are cut off and another from the limitless pool of eager computer-whiz kids is selected to take over. Free labor and a good use of the energies of the kids who would otherwise be spending time trying to gain unauthorized access. Anyway, I fear that making Msggroup a digest will get it into the same spiral of decline which has plagued other digests. If it can be done in a totally automated fashion, it might be OK, but the danger of destroying the value of the list is too great to risk this valuable resource. Will Martin USArmy DARCOM ALMSA 22-Sep-82 11:28:17-PDT,663;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 1123-PDT Date: 22 Sep 82 9:36:09 PDT (Wednesday) From: Suk at Parc-Maxc Subject: MSGGROUP#1912 Re: Format change suggestions In-reply-to: WMARTIN's message of 22 Sep 1982 0631-PDT, <[OFFICE-8]22-Sep-82 06:31:28.WMARTIN> To: WMartin at Office-8 (Will Martin) cc: Msggroup at BRL Via: Parc-Maxc; 22 Sep 82 12:37-EDT Via: Brl; 22 Sep 82 13:11-EDT Via: Brl-Bmd; 22 Sep 82 13:32-EDT I disagree (with your contention that digests are passe'). I still subscribe to Human-Nets, Space, and Telecom, but have come that close to removing myself from Msggroup due to the high number of messages. Stan Suk 22-Sep-82 17:01:34-PDT,2849;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 1657-PDT Date: 22 SEP 1982 1526-PDT To: MSGGROUP at BRL cc: ZELLICH AT OFFICE-3 From: Reynolds at Ames-67 Subject: MSGGROUP#1913 MSGGROUP DIGEST SUGGESTIONS Via: Ames-67; 22 Sep 82 18:26-EDT Via: Brl; 22 Sep 82 19:00-EDT Via: Brl-Bmd; 22 Sep 82 19:04-EDT Stef, I've also noticed the effects on Digest lists (i.e. Human-Nets) and agree with Will Martin. Unless some low-cost, long-term solution to the manpower problem providing "motivated" moderators is found, the digest lists have problems. I assume the automated mailers could be set to distribute daily, or whenever some pre-set distribution character count is exceeded, so as to impact the network minimally. The MsgGroup distributer at BRL apparently distributes as each message comes in. Some of us have primitive mail reading software such that messages cannot be addressed individually. Since I cannot display just a message header catalog, I have to file through the day's mail to get to the last, recent message. Batching messages for a day wouldn't hurt this process. Incidentally, we cannot accept lines longer than 132 characters here either--we truncate 'em to 132 characters. If all the "dumb" terminals on the net beep at column 72 like this VT100 does, long lines would not be a problem. (Sorry to digress to a dead topic, but I sometimes think of things I should have said). The discussion seems to be focussing on the different needs of the list readers--The discussion participants don't mind several mailings per day, and the observers prefer edited, spelling corrected (albeit delayed) mail. The labor to edit out the "Please remove me from the list" messages is understood as is the protection from obscene, libelous, or otherwise improper messages that a moderator affords . A suggestion appears for the interim while we wait for the 3-list MsgGroup: Create a second list for those who want only the archive index with the MSGGROUP#nnnn headers. Thus we have the FRAY and SURVEY lists you described. To make the SURVEY list usable for the infrequent FTP users, perhaps prefix an instruction message to each mailing of this index describing the FTP pathnames just as Jon does for new RFC's. I wasn't aware of the pathnames to the undigestified messages on Human-Nets, etc. Jon generates a very understandable message for those of us who use FTP infrequently and don't understand pathnames. Maybe these should be also included on the list of ARPAnet mailing lists. Rich, any comments? Stef, for now I'd vote for a 2-list MsgGroup with the second list also automated. If and when we automate a moderator (or procure one at slave-labor rates), a digest could be considered. Comments? Best, Don Reynolds (Reynolds at Ames-67) ------- 22-Sep-82 23:13:35-PDT,873;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 2308-PDT Date: 22 Sep 1982 17:41-PDT - Wednesday To: Reynolds at Ames-67 Cc: MSGGROUP at BRL Subject: MSGGROUP#1914 Re: MSGGROUP DIGEST SUGGESTIONS In-reply-to: Your message of 22 SEP 1982 1554-PDT. From: Brian Reid Via: Su-Score; 22 Sep 82 20:45-EDT Remailed-date: 22 Sep 1982 2224-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 23 Sep 82 1:25-EDT Via: Brl-Bmd; 23 Sep 82 1:35-EDT I see that your mail sender is also pretty primitive: it keeps retransmitting the same message over and over and over again. I had always heard rumors that IBM software contained secret loops designed to use extra computer time and thereby encourage customers to buy bigger computers. This evidence supports that rumor. 22-Sep-82 23:23:13-PDT,737;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 2319-PDT Date: 22 Sep 1982 17:47-PDT - Wednesday To: holbrook.ES at Parc-Maxc Cc: Reynolds at Ames-67, MSGGROUP at BRL Subject: MSGGROUP#1915 Re: MSGGROUP DIGEST SUGGESTIONS In-reply-to: Your message of 22-Sep-82 17:15:55 PDT (Wednesday). From: Brian Reid Via: Su-Score; 22 Sep 82 20:49-EDT Remailed-date: 22 Sep 1982 2226-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 23 Sep 82 1:27-EDT Via: Brl-Bmd; 23 Sep 82 1:37-EDT I can see the headline tomorrow: Government Computer massacres thousands of civilian mailboxes. Disk blocks riddled with messages. Few survivors. 22-Sep-82 17:58:39-PDT,1196;000000000001 Mail-From: USC-ECLC Received-Date: 22-Sep-82 1758-PDT Date: 22 Sep 1982 1758-PDT Sender: MSGGROUP at USC-ECLC Subject: MSGGROUP#1916 (FORWARDING LOOP?) MSGGROUP DIGEST SUGGESTIONS From: MSGGROUP at USC-ECLC To: "[ECLC]MAIL.LST;100": Message-ID: <[USC-ECLC]22-Sep-82 17:58:37.MSGGROUP> Subject: [Hamilton: Re: MSGGROUP DIGEST SUGGESTIONS (FORWARDING LOOP?)] Hi All - We have disconnected the main MsgGroup relay operation at BRL until we get the flow of looping mail stopped from AMES-67, where it is originating. DPK at BRL reports by phone that he is in contact with someone at AMES who says it has been stopped, but I will leave the relay service disconnected for an hour or so to be sure we are clear of the trouble. I have diverted all the mail to a nice safe place in the meantime, so nothing will get lost. Cheers - Stef --------------- Date: 22-Sep-82 17:25:21 PDT (Wednesday) From: Hamilton.es at PARC-MAXC Subject: Re: MSGGROUP DIGEST SUGGESTIONS (FORWARDING LOOP?) To: Reynolds at Ames-67 cc: STEF @ DARCOM-KA Is there a forwarding loop somewhere? I've gotten four copies of your msg in the last half hour. --Bruce 22-Sep-82 23:43:15-PDT,1604;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 2339-PDT Date: 22 September 1982 22:01-EDT From: David A Moon Subject: MSGGROUP#1917 header mangling To: Admin.MRC at Su-Score cc: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Via: Mit-Mc; 22 Sep 82 22:10-EDT Remailed-date: 22 Sep 1982 2231-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Via: Usc-Eclc; 23 Sep 82 1:32-EDT Via: Brl-Bmd; 23 Sep 82 1:38-EDT Date: 10 Sep 1982 0111-PDT From: Mark Crispin In an attempt to work around the problem of multiple at's and relays, I am planning on having MMAILR use "%" instead of multiple " at "'s to indicate a routed address. In other words, the former RWK at SCRC-TENEX at MIT-MC will become RWK%SCRC-TENEX at MIT-MC I would like to ask the maintainers of the MIT I.T.S. FTP server to make the (simple) change to their software so that "%" is accepted as an alternative to "@". The FTP server does not presume to reformat addresses that pass through it. I don't see how substituting one character from another buys anything, other than hiding the @'s from people and programs that are looking for multiple @'s to flame about, until they learn that % and @ are synonymous. However, in the interests of maximizing the usefulness of the mail system, I will make Comsat understand this syntax whenever you tell me that mail is being or going to be sent in it (plus a week or two for seeing my mail and having the half hour to do it, test it, and install it.) 22-Sep-82 23:53:12-PDT,1488;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 2350-PDT Date: 22 SEP 1982 1912-PDT To: STEF at Usc-Eclc From: Reynolds at Ames-67 Subject: MSGGROUP#1918 FORWARDING LOOP BROKEN cc: holbrook.es at Parc-Maxc, hamilton.es at Parc-Maxc, AlHall at Parc-Maxc, Newman.es at Parc-Maxc cc: Stef at Usc-Eclc cc: Cerf at Usc-Isi cc: Reid at Su-Score Via: Usc-Eclc; 23 Sep 82 1:34-EDT Via: Brl-Bmd; 23 Sep 82 1:50-EDT Hey people, I'm sorry we apparently have a mailer problem between Ames-67 and BRL. I got a "TERMINATED: FATAL ERROR RECEIVED FROM BRL" message after I sent the message to BRL, then my mailer queued the message and called upon the mailer to send again. Obviously the message was getting through and we have some return code problems between here and BRL. I caught it after about an hour and turned off the "re-transmit if message fails" operation for my account here. Last time this problem occurred on FTP, I believe there was some confusion about what is classed as a fatal return code, and it was not uniform across the ARPAnet. Remailed-date: 22 Sep 1982 2233-PDT Remailed-from: MsgGroup Moderator - Stefferud Remailed-to: msggroup at BRL-BMD Our systems person is working on a permanent fix. Sorry for the inconvenience. Contrary to any nasty rumors circulated in fun, the ARPAnet mailer software here was generated locally, not by IBM. Again, sorry for the inconvenience, Don Reynolds ------ 22-Sep-82 22:24:18-PDT,692;000000000001 Mail-from: ARPANET site BRL rcvd at 22-Sep-82 2223-PDT Date: 22 Sep 1982 1147-PDT Sender: WMARTIN at Office-8 Subject: MSGGROUP#1919 Re: Format change suggestions From: WMartin at Office-8 (Will Martin) To: Suk at Parc-Maxc Cc: msggroup at BRL Message-ID: <[OFFICE-8]22-Sep-82 11:47:14.WMARTIN> In-Reply-To: Your message of 22-Sep-82 9:36:09 PDT (Wednesday) Via: Office-8; 22 Sep 82 14:47-EDT Via: Brl; 22 Sep 82 15:07-EDT Via: Brl-Bmd; 22 Sep 82 15:23-EDT I don't think that digests are "passe'", as you inferred. They are great. I am just sad that they seem to not be viable in our current environment as based on observed changes in the digests over time. Will 23-Sep-82 05:34:10-PDT,1472;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 0532-PDT Date: 23 Sep 82 6:28:29-EDT (Thu) From: Dave Crocker To: David A Moon cc: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL, Cerf at Usc-Isi Subject: MSGGROUP#1920 Re: header mangling Via: Udel-Relay; 23 Sep 82 6:36-EDT Via: Brl; 23 Sep 82 7:38-EDT Via: Brl-Bmd; 23 Sep 82 7:51-EDT With respect to the illegal transmission of multiple @/" at " in address headers, the basic requirement is that the relevant MIT, Stanford, and CMU sites stop sending them. Some of the affected sites, most notably Mark Crispin, were very much caught in the time-warp which failed to publish the ARPA decision to prohibit mutliple at-signs. Some of the affected sites have known about the situtation for close to two years and continue to refuse to make the change. The BRL MMDF behavior that started this brouhaha is the result of MMDF very carefully intercepting such extra tokens and converting them to a character which MMDF treats at lexically equivalent to at-sign. In our case, we chose period. This was done about 2 years ago. Mark Crispin is choosing percent sign; UCL has chosen it also. Rather than complain that some remote system, like BRL, should put quotes around text that it had no organizational responsibility for generating, the sending sites should make sure that the text conforms, before letting the text loose onto the Arpanet. Dave 23-Sep-82 07:08:54-PDT,977;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 0707-PDT Date: 23 Sep 82 8:32:08-EDT (Thu) From: Dave Crocker To: David A Moon cc: Admin.MRC at Su-Score, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1921 Re: header mangling Via: Udel-Relay; 23 Sep 82 8:43-EDT Via: Brl; 23 Sep 82 8:57-EDT Via: Brl-Bmd; 23 Sep 82 9:10-EDT It is amazing how useful waking up can be. I reread your note and realized that, besides suggesting that the source(s) of the problem be fixed, there was a simple expedient to request, based on your last paragraph: Please make your ftp server accept period (".") as lexically equivalent to at-sign ("@"); the use of the period is effective immediately. Dave P.S. It occurs to me that it might be useful to note that the BRL MMDF is using a header-munger that was added to MMDF by SRI and is run by them, as well as UDel and will be run on Rand-Relay (for CSNet). D/ 23-Sep-82 12:53:58-PDT,1827;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1252-PDT Mail-from: SU-NET host Shasta rcvd at 23-Sep-82 0954-PDT Date: 23 Sep 1982 09:54-PDT - Thursday To: Dave Crocker Cc: David A Moon , Admin.MRC at Su-Score, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1922 NO! Don't propagate this madness! Stop the Bloody periods!!!! In-reply-to: Your message of 23 Sep 82 8:32:08-EDT (Thu). From: Brian Reid Via: Su-Score; 23 Sep 82 12:59-EDT Via: Brl; 23 Sep 82 13:22-EDT Via: Brl-Bmd; 23 Sep 82 14:26-EDT The period is the worst possible choice as a substitute for the @ sign, and nobody else should track this foolish mistake. Please don't go convincing other people to do this too! Almost every site on the Arpanet assigns some meaning to the period already: Tops-20 sites use periods for subdirectories: Admin.MRC Multics uses periods for account codes: Schauble.Multics Xerox uses periods for registry names: Schroeder.PA (Palo Alto registry) CMU uses periods as an equivalent for spaces: Craig.Everhart Berkeley uses prefix periods the way Crocker wants to use suffix periods: Kim.ouster means person "ouster" at site "Kim". Dave, you should pick almost any other character besides the period for this vigilante action. I have a nagging feeling that it would cause less grief for the collected Arpanet community if you used a lowercase "q" instead of a period: MOONqSCRC-TENEX@AI. There is maybe 1 instance in 50 of a net name that legitimately contains a "q"; enormous numbers of them contain periods. A % sign or an ampersand or a # sign or something that does not customarily show up in net names would be far superior. Brian Reid, a.k.a. Brian.Reid@CMUA, CSL.BKR@SU-SCORE, BReid.PA@Parc 23-Sep-82 12:33:32-PDT,856;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1229-PDT Date: 23 Sep 82 13:08:03-EDT (Thu) From: Dave Crocker To: Brian Reid cc: David A Moon , Admin.MRC at Su-Score, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1923 Re: NO! Don't propagate this madness! Stop the Bloody periods!!!! Via: Udel-Relay; 23 Sep 82 13:17-EDT Via: Brl; 23 Sep 82 13:27-EDT Via: Brl-Bmd; 23 Sep 82 14:31-EDT Perhaps my main point was not clear: We chose period over two years ago. I was merely responding to David Moon's offer to incorporate interpretation of whatever character was specified. I still believe that the correct resolution is for the ITS, CMU, and Stanford sites to remove/fix the symbols before letting messages out onto the Arpanet. Dave 23-Sep-82 12:53:57-PDT,1174;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1251-PDT Mail-from: SU-NET host Shasta rcvd at 23-Sep-82 1031-PDT Date: 23 Sep 1982 10:31-PDT - Thursday To: Dave Crocker Cc: David A Moon , Admin.MRC at Su-Score, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1924 Re: Re: NO! Don't propagate this madness! Stop the Bloody periods!!!! In-reply-to: Your message of 23 Sep 82 13:08:03-EDT (Thu). From: Brian Reid Via: Su-Score; 23 Sep 82 13:50-EDT Via: Brl; 23 Sep 82 14:02-EDT Via: Brl-Bmd; 23 Sep 82 14:35-EDT You might have chosen period 2 years ago, just like the Multics people chose another meaning for it 15 years ago and the Tops-20 people 10 years ago. But you didn't start this vigilante substitution of other people's codes into your kind of codes until fairly recently. It is the subsitution, not your unfortunate choice of the period, that is the act of aggression. However, your basic position of vigilante action about the multiple @ signs would be cute instead of obnoxious if you had chosen some character besides the period to change them into. 23-Sep-82 14:03:41-PDT,864;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1402-PDT Date: 23 Sep 1982 1129-PDT From: Zellich at Office-3 (Rich Zellich) Subject: MSGGROUP#1925 Re: NO! Don't propagate... To: MsgGroup at BRL cc: DCrocker at Udel-Relay Via: Office-3; 23 Sep 82 14:28-EDT Via: Brl; 23 Sep 82 14:57-EDT Via: Brl-Bmd; 23 Sep 82 16:15-EDT Maybe I'm missing something, but it is my distinct impression that most of the current problems can be handled by the new "local-part" definition of what goes on the left side of the at-sign. It doesn't matter if a cluster of sites (say, ITS sites) picks a period, percent sign, or a "q"; it's all part of the local-part and they are then the only ones who have to worry about interpreting it...the rest of us can just ignore it as if it is really specifying user/account, user/registry, or whatever. -Rich ------- 23-Sep-82 14:08:27-PDT,4120;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1406-PDT Date: 23 Sep 1982 1048-PDT From: Mark Crispin Subject: MSGGROUP#1926 cooling off the flames Sender: ADMIN.MRC at Su-Score To: MsgGroup at Mit-Ml, Header-People at Mit-Mc Reply-To: Admin.MRC at Su-Score Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Via: Mit-Ml; 23 Sep 82 13:54-EDT Via: Brl; 23 Sep 82 14:03-EDT Via: Brl-Bmd; 23 Sep 82 15:28-EDT Folks, I talked with Dave Crocker during the Internet conference in Germany. Here are some facts which are not generally known, but should be: . Dave did not take vigilante action. What happened was that his mailsystem once generated multiple at's the way the mailsystem at MIT, Stanford, and CMU does. Being closer to the Internet working group at the time, he was aware of the decision to eliminate multiple at's. The way he did it was that his mail delivery system converts multiple at's into the dot format. This was done a few years ago. Nobody was aware of it at the time, until MsgGroup mailings started going via MMDF at BRL and multiple at MsgGroup mail got clobbered. . The way in which multiple at's are generated by the TOPS-20 mailsystem makes it moderately difficult to fix it. In particular, the address "FOO at SCRC-TENEX" is passed by the mailsystem with a special request to expand "SCRC-TENEX" to a routed address if necessary. The mail delivery process will then expand it, e.g . to "SCRC-TENEX at MIT-MC". This is only done at the explicit request of the mail composition process, and otherwise the mail delivery process will never modify a message header. Incoming network mail, not generated by the mail composition process, will not have the request and consequently the mail delivery process (XMAILR in this case) will not touch the header. The problem is that since the request is around "SCRC-TENEX", it is moderately difficult to change the " at " preceding it to any character, be it "%" or "." or "q". There are various complex cases which have to be considered to do it properly; it is not a trivial fix. I am unwilling to make any change to that part of the mailsystem without verifying its correctness, for fear of destroying possibly valuable mail. The change which will be made is that the previous " at " will be converted into a "%", and all subsequent at's in the routing address up to the last one will be likewise converted. The FTP servers will be fixed to treat "%" as equivalent to "@" in the MAIL and MLFL commands. This has already been agreed to. It is a dead issue; complaining about it further is valueless. . Period is completely unacceptable to us as a node delimiter to the left of the at-sign. Despite what the standards may say, we will not use it for that purpose, preferring "%" instead. However, the standard (as well as private conversations with Crocker) makes it clear that we are perfectly free to fantasize that "." is an ordinary character and "%" is special, just as Crocker is free to fantasize the other way. I wish the standard had not given such special meaning to ".", but it is irrelevant. This only refers to the "mailbox" part of the address. Period is a perfectly reasonable character in a domain address. Ultimately the address should become something like @MIT.ARPA:RWK@TENEX.SCRC but for now we'll use "RWK%SCRC-TENEX at MIT-MC". Surprisingly it looks like domains would be easier to implement for me than the "%" hack, but I wish to coddle older programs for just a little while longer. Given this, I propose the following rules: (1) NO FURTHER COMPLAINTS ABOUT MIT OR STANFORD MULTIPLE AT'S. (2) NO FURTHER DEFENSE FROM MIT OR STANFORD OF MULTIPLE AT'S. (3) NO FURTHER ARGUMENTS ABOUT THE MERITS OF "%" VS. "."; IT HAS BEEN MADE CLEAR THAT BOTH CAN BE USED AS NODE DELIMITERS OR ORDINARY CHARACTERS. Anybody who violates these rules should have their terminal taken away from them for a week. -- Mark -- ------- 23-Sep-82 14:33:25-PDT,1493;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1433-PDT Date: 23 Sep 82 14:18:12-EDT (Thu) From: Dave Crocker To: Brian Reid cc: David A Moon , Admin.MRC at Su-Score, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1927 Re: Re: NO! Don't propagate this madness! Stop the Bloody periods!!!! Via: Udel-Relay; 23 Sep 82 14:35-EDT Via: Brl; 23 Sep 82 15:14-EDT Via: Brl-Bmd; 23 Sep 82 16:24-EDT The MMDF code in question is semantically unchanged from two years ago. To my knowledge, no recent changes took place. It just happens that the mapping behavior became highly visible, due to BRL's acting as a relay. There is a chance that some code DID get changed; if so, it was merely to make the address munging work 'correctly' (as we originally specified it). At any rate, per Crispin's note, I want to stress that hassling non-conforming sites was not on the agenda. In fact, they were not considered, at all. (It has been a tempting thought, for the past couple of years, but was deemed counter-productive.) The munging was being performed strictly for the purpose of following the dictum that says 'be generous in what you accept with your parser and conservative in what you feed others'. Postel has some version of this statement in one of his specifications. MMDF is generous in accepting the multiple at-signs but conservative in generating only one. Dave 23-Sep-82 14:58:41-PDT,1485;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1453-PDT Date: 23 Sep 1982 1316-PDT From: KLH at Sri-Nic Subject: MSGGROUP#1928 Using "%" instead of "@" To: header-people at Mit-Mc, msggroup at Mit-Ml cc: KLH at Sri-Nic In-Reply-To: Your message of 23-Sep-82 0957-PDT Via: Mit-Ml; 23 Sep 82 16:16-EDT Via: Brl; 23 Sep 82 16:41-EDT Via: Brl-Bmd; 23 Sep 82 17:14-EDT Moon is correct. The ITS FTP server has no business doing anything about the arguments to MAIL or MLFL; it is up to the actual mailer, COMSAT, to handle them in whatever fashion is deemed fit. I must confess I have totally forgotten why it is necessary to even have a substitute character at all. I think if you counted up the software that would have to be fixed to parse the hostname off by going "backwards", versus the programs that would have to be modified to understand "%", you might find that the latter number is much larger. Finally, I am tired of seeing people beat on MIT for being "uncooperative", refusing to recognize the requirements of the rest of the world. From my viewpoint it is the other way around; the rest of the world has never recognized MIT's needs, and RFC733 required a very significant compromising of MIT capabilities, for no clearly stated reason. This left a bitter taste which RFC822 does nothing to alleviate; the surprising thing is that people there are still willing to be accomodating, as Moon's message demonstrates. --Ken ------- 23-Sep-82 15:28:37-PDT,1451;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1523-PDT Date: 23 September 1982 1527-EDT (Thursday) From: Richard H Gumpertz To: Brian Reid Subject: MSGGROUP#1929 Re: NO! Don't propagate this madness! Stop the Bloody periods!!!! CC: David A Moon , Admin.MRC at Su-Score, HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL, Dave Crocker In-Reply-To: Brian Reid@Shasta@SU-Score's message of 23 Sep 82 11:54-EST Message-Id: <23Sep82 152754 RG02@CMU-10A> Via: Cmu-10a; 23 Sep 82 16:34-EDT Via: Brl; 23 Sep 82 17:01-EDT Via: Brl-Bmd; 23 Sep 82 17:37-EDT I would like to make a radical suggestion: instead of ".", "%", or "#", why not use "@"? Is it really that hard to change the standard back to allow (but perhaps discourage) multiple "@"s? It surely is not difficult for mail-processing programs that don't want to understand them to just IGNORE AND PASS THROUGH all but the last (rightmost) @. After all, multiple @s do form a fairly straightforward syntax and have proven to be useful. Why build kludge upon kludge to translate old conventions when it would be easier to just accept the old convention as it was? Why not support BOTH domain naming AND route naming, with the former the preferred method? Who is getting any benefit out of eliminating multiple @s? Is that benefit greater than the cost? Rick 23-Sep-82 15:33:44-PDT,573;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1530-PDT Date: 23 Sep 82 16:08:03-EDT (Thu) From: Michael Muuss To: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1930 Can we all agree? Via: Brl-Bmd; 23 Sep 82 16:37-EDT Via: Brl; 23 Sep 82 17:01-EDT Via: Brl-Bmd; 23 Sep 82 17:44-EDT Why don't we all just agree to translate to the percent-sign (instead of the Dot), and be done with it? The change to MMDF is like a line or two of code; surely the same is true for all the other mailers that bother to change headers. -Mike 23-Sep-82 16:49:00-PDT,795;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1647-PDT Date: 23 September 1982 15:37-PDT - Thursday From: Jonathan Alan Solomon To: Richard H Gumpertz Cc: Admin.MRC at Su-Score, Dave Crocker , HEADER-PEOPLE at Mit-Mc, David A Moon , MsgGroup at BRL, Brian Reid Address: 3737 So. Hoover St. LA, Cal. 90089-0273 Phone: (213) 743-6861 Subject: MSGGROUP#1931 NO! Don't propagate this madness! Stop the Bloody periods!!!! Via: Usc-Eclc; 23 Sep 82 18:38-EDT Via: Brl; 23 Sep 82 18:50-EDT Via: Brl-Bmd; 23 Sep 82 19:11-EDT Gee, I second that. If we can use either "." or "%", why not "@"? I get the feeling we have asked this before. Oh well... --Jsol 23-Sep-82 17:40:40-PDT,721;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1739-PDT Date: 23 September 1982 1936-EDT (Thursday) From: Richard H Gumpertz To: KLH at Sri-Nic Subject: MSGGROUP#1932 Programs to be changed CC: header-people at Mit-Mc, msggroup at Mit-Ml In-Reply-To: KLH@Sri-Nic's message of 23 Sep 82 15:16-EST Message-Id: <23Sep82 193616 RG02@CMU-10A> Via: Mit-Ml; 23 Sep 82 19:40-EDT Via: Brl; 23 Sep 82 19:58-EDT Via: Brl-Bmd; 23 Sep 82 20:07-EDT In case I didn't say it clearly enough, I would like to ask the question that Ken mentioned: How many programs would have to be modified to allow multiple @s? Anyone out there have one? If so, would it be at all hard to fix? Rick 23-Sep-82 19:54:52-PDT,814;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 1951-PDT Date: 23 September 1982 2043-EDT (Thursday) From: Richard H Gumpertz To: Header-People at Mit-Mc, MsgGroup at BRL Subject: MSGGROUP#1933 munging my name! Message-Id: <23Sep82 204303 RG02@CMU-10A> Via: Cmu-10a; 23 Sep 82 21:00-EDT Via: Brl; 23 Sep 82 21:11-EDT Via: Brl-Bmd; 23 Sep 82 22:24-EDT Why is BRL munging my FROM line? It originally reads Richard H. Gumpertz When it comes back, however, the "." after the H is gone (my middle name is not "H"!) and the capitalization of CMU-10A has been raped. THIS SHOULD NOT BE DONE!!!!! The only change I consider acceptable (though still annoying) is changing " at " to "@". If you can't get it right, LEAVE IT ALONE!!!!! Rick 23-Sep-82 22:59:45-PDT,861;000000000001 Mail-from: ARPANET site BRL rcvd at 23-Sep-82 2245-PDT Date: 23 September 1982 23:48 cdt From: Stachour.CSCswtec at Hi-Multics Subject: MSGGROUP#1934 Re: munging my name! To: Richard H Gumpertz cc: Header-People at Mit-Mc, MsgGroup at BRL In-Reply-To: Msg of 09/23/82 21:39 from Richard H Gumpertz Via: Hi-Multics; 24 Sep 82 0:52-EDT Via: Brl; 24 Sep 82 0:57-EDT Via: Brl-Bmd; 24 Sep 82 1:14-EDT Gee, Rick, I don't know why your line of CMU-10A is getting changed by BRL. The mailer tables here at HI-Multics (which are carefully maintained, I'm told, in the 'right' capitalization from 'official netowrk tables' (wherever they are) ) have the capitalization of your site as 'CMU-10a' (and I suspect that's what the capitialization is on this msg (CMU-10a) of your host-id. Always questing, ...Paul 24-Sep-82 14:10:23-PDT,1783;000000000001 Mail-from: ARPANET site BRL rcvd at 24-Sep-82 1410-PDT Date: 24 Sep 1982 1544-EDT From: Mark Plotnick Subject: MSGGROUP#1935 Re: NO! Don't propagate... To: msggroup at BRL In-Reply-To: Your message of 23-Sep-82 1648-EDT Via: Mit-Mc; 24 Sep 82 15:39-EDT Via: Brl; 24 Sep 82 16:02-EDT Via: Brl-Bmd; 24 Sep 82 16:19-EDT Having a separate convention for forwarding mail within local networks (say, by using '%' as an address delimiter with a lower priority than '@'), will soon run into problems. Anyone who has tried to send mail through multiple uucp networks hanging off the Arpanet has seen a problem similar to this. If everyone on the MIT local net is called Foo%Host, I would be UC.MP%MIT-EE. If, say, CMU adopts this convention, then consider someone named KHH%CMU-EE1: to send mail from one CMU computer to another, you'd mail to KHH%CMU-EE1. to send mail to this person from an Arpanet site, you'd send mail to KHH%CMU-EE1@CMUA. If I wanted to send mail to this person, what would I write? (remember, I'm on MIT-EE, not the Arpanet) KHH%CMU-EE1@CMUA%MIT-MC? How would this be parsed? Well, you can't simply take everything to the right of the atsign as an arpanet address, or you run into the same problem that started this whole discussion. I see two solutions: 1) Forget about the routing info; just send to user@domain and let smart programs do the routing for you. 2) parse the address right-to-left, with % and @ having the same precedence. So why bother having different separation characters? Just use @. This is what MIT, CMU, and Stanford have been doing, and now they're being told to stop this. In a quandary, Mark (MP@XX, for those of you who run MMDF) ------- 24-Sep-82 17:33:34-PDT,1498;000000000001 Mail-from: ARPANET site BRL rcvd at 24-Sep-82 1730-PDT Date: 24 Sep 1982 1613-PDT Sender: STEF at Darcom-Ka Subject: MSGGROUP#1936 MsgGroup vs Header-People & @ % . From: STEF at Darcom-Ka To: MsgGroup at BRL Message-ID: <[DARCOM-KA]24-Sep-82 16:13:06.STEF> Via: Darcom-Ka; 24 Sep 82 19:19-EDT Via: Brl-Bmd; 24 Sep 82 19:39-EDT Hi All - People are asking me what the difference between MsgGroup and header-People is supposed to be, and why we are copying everything to both lists when the membership of both seem to overlap so much. I expect that the copying to both lists is caused by the fact that the current topic at least started out in an area that is truly inside the intersection of both list's interests. As I see it, MsgGroup should focus more on general issues and problems, like the impact of long lines on recipients, while Header-People focuses more on details of implementation, such as arguing through 733/822 details, et al, and the problems of FTPSERS that break on long lines. In this regard, I think that the % vs @ vs . discussion would be better served by Header-People alone, without copying MsgGroup on it till we have a resolution. I fear that if we continue in the current manner, that many members will drop from one or the other list, assuming that we are both the same, and in the end, we will be the same, and also be unable to revert to our separate foci. So, lets shift the @ vs % discussion to header-people. OK? Stef 25-Sep-82 12:02:01-PDT,667;000000000001 Mail-from: ARPANET site BRL rcvd at 25-Sep-82 1159-PDT Date: 25 September 1982 13:48-EDT From: Ken Harrenstien Subject: MSGGROUP#1937 MsgGroup vs Header-People & @ % . To: STEF at Darcom-Ka cc: HEADER-PEOPLE at Mit-Mc, MsgGroup at BRL Via: Mit-Mc; 25 Sep 82 13:40-EDT Via: Brl; 25 Sep 82 14:03-EDT Via: Brl-Bmd; 25 Sep 82 14:22-EDT Stef is correct. Header-people is for the discussion of nitty-gritty and should include all those people who actually implement mail software. Please try to ensure that MsgGroup is not on the CC list for future messages about the "@ % ." issue, as well as similar technical details. Thanks. 26-Sep-82 21:35:28-PDT,701;000000000001 Mail-from: ARPANET site BRL rcvd at 26-Sep-82 2131-PDT Date: 25 Sep 82 22:10 edt From: Schauble.Multics at Mit-Multics Subject: MSGGROUP#1938 MsgGroup vs Header-People To: Header-People at Mit-Mc, MsgGroup at BRL Via: Mit-Multics; 26 Sep 82 23:05-EDT Via: Brl; 26 Sep 82 23:27-EDT Via: Brl-Bmd; 26 Sep 82 23:44-EDT May I suggest, then, that it is probably almost never correct to send a message to both Header-People and MsgGroup. What is better, if the discussion moves into territory covered by the other list is to move it, and provide a pointer to the archives for those interested in picking up the threads. I would like to keep the traffic unduplicated. Paul 26-Sep-82 22:55:23-PDT,1219;000000000001 Mail-from: ARPANET site BRL rcvd at 26-Sep-82 2254-PDT Date: 26 Sep 1982 2148-PDT Sender: STEF at Darcom-Ka Subject: MSGGROUP#1939 Re: MsgGroup vs Header-People From: STEF at Darcom-Ka To: Schauble at Mit-Multics Cc: Header-People at Mit-Mc, MsgGroup at BRL Message-ID: <[DARCOM-KA]26-Sep-82 21:48:02.STEF> In-Reply-To: Your message of 25 September 1982 22:10 edt Via: Darcom-Ka; 27 Sep 82 0:36-EDT Via: Brl; 27 Sep 82 0:58-EDT Via: Brl-Bmd; 27 Sep 82 1:04-EDT Hi Paul - Were the world perfect, with the boundary between Msggroup and Header-People as clear as black and white, and if everyone who ever contributed knew the distinction perfectly, then we might be blessed with no need to ever deal with a duplicate message. In the meantime, I would be happy to see it minimized, as best we can, without inhibiting the flow of ideas. To me, it is the flow of ideas that is paramount. Minimizing my use of the delete command can never compare as an objective function. But, the recent overlap was beyond reason, and was threatening the flow of ideas. Perhaps I should have realized it and stepped in sooner. Some things are only visible with hindsight, I fear. Cheers - Stef 30-Sep-82 22:34:59-PDT,935;000000000001 Mail-from: ARPANET site BRL rcvd at 30-Sep-82 2229-PDT Date: 1 Oct 1982 0033-EDT Sender: MOOERS at Bbna Subject: MSGGROUP#1940 Re: REMOVAL OF NAME FROM MAILING LIST From: MOOERS at Bbna To: GANESHA at Office-1 Cc: Admin.MDP at Su-Score, MCCRARY at Usc-Isie Cc: Msggroup at BRL, Mooers at Bbna Message-ID: <[BBNA] 1-Oct-82 00:33:06.MOOERS> In-Reply-To: Your message of 30 September 1982 18:55-PDT (Thursday) Via: Bbna; 1 Oct 82 0:38-EDT Via: Brl; 1 Oct 82 0:49-EDT Via: Brl-Bmd; 1 Oct 82 0:57-EDT How fast the dead hand of tradition grasps us in its iron grip! I do think you overestimate how many people fully understand the less-than-perfect system that has grown up. Actually, the current naming conventions give little if any clue to the fact that a given name is a mailing list, so they are in fact booby traps for the unwary or hasty user. Once you have been caught, you may learn, I guess ... 1-May-83 11:34:54-PDT,903;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 18-Nov-82 2135-PST Return-path: Postel@ISIF Date: 18 Nov 1982 1945-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1941 New RFC 825 Available To: "Request-for-Comments-List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 825: Title: Request for Comments on Requests for Comments Author: J. Postel Pages : 2 pathname: [SRI-NIC]RFC825.TXT This memo specifies some aspects of RFCs. In particular, RFCs are required to contain a statement of intent. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. Submissions for RFCs should be sent to POSTEL@ISIF. --jon. 1-May-83 11:34:54-PDT,1113;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 18-Nov-82 2135-PST Return-path: Postel@ISIF Date: 18 Nov 1982 2045-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1942 RFC 823 Now Available To: "Request-for-Comments-List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 823: Title: The DARPA Internet Gateway Author: R. Hinden and A. Sheltzer Pages : 45 pathname: [SRI-NIC]RFC823.TXT This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however this is not an implementation specification, and such details are subject to change. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. Submissions for RFCs should be sent to POSTEL@USC-ISIF. --jon. 1-May-83 11:34:54-PDT,1249;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 19-Nov-82 1957-PST Return-path: Postel@ISIF Date: 19 Nov 1982 1531-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1943 RFC 827 Now Available To: "Request-for-Comments-List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 827: Title: Exterior Gateway Protocol (EGP) Author: E. Rosen Pages : 46 pathname: [SRI-NIC]RFC827.TXT This RFC proposes a standard for the communications between mutually suspicious gateways. This is a DRAFT STANDARD and comments are especially encouraged. This note describes a grouping of the internet gateways into several autonomous systems. Within an autonomous system the gateways may use a private protocol. Between autonomous systems gateways will use this Exterior Gateway Protocol (when it is finally established as a standard). Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. Submissions for RFCs should be sent to POSTEL@USC-ISIF. --jon. 1-May-83 11:34:54-PDT,964;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 22-Nov-82 2316-PST Return-path: Postel@ISIF Date: 22 Nov 1982 2145-PST From: Postel@USC-ISIF Subject: MSGGROUP#1944 RFC 699 Now Available To: "Request-For-Comments-List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 699: Title: Requests For Comments Summary - Notes: 600-699 Author: J. Postel & J. Vernon Pages : 9 pathname: [SRI-NIC]RFC699.TXT This long overdue RFC is a slightly annotated list of the 100 RFCs from RFC 600 through RFC 699. This is in the nature of a status report on these RFCs. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:55-PDT,1140;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 23-Nov-82 1538-PST Date: 23 Nov 1982 1145-PST Sender: WESTINE at USC-ISIF Subject: MSGGROUP#1945 RFC 828 Now Avaliable From: WESTINE at USC-ISIF To: "[ISIF]Request-for-Comments.List": Message-ID: <[USC-ISIF]23-Nov-82 11:45:15.WESTINE> A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 828: Title: Data Communications: IFIP's International "Network" of Experts Author: Kenneth Owen Pages : 8 pathname: [SRI-NIC]RFC828.TXT This memo describes the activities of IFIP technical committee 6, which is the IFIP committee on Data Communications. This memo is intended to bring the work of IFIP to your attention and encourage your partcipation in IFIP activities." Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:55-PDT,1023;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 30-Nov-82 1948-PST Return-path: Postel@ISIF Date: 30 Nov 1982 1735-PST From: POSTEL@USC-ISIF Subject: MSGGROUP#1946 RFC 800 Now Available To: "Request-for-Comments-List": One RFC Announcement A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 800: Title: Requests for Comments Summary Author: J. Postel & J. Vernon Pages : 10 pathname: [SRI-NIC]RFC800.TXT This memo is an annotated listing of the RFCs from 700 through 799. It is essentially a status report on the RFCs. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:55-PDT,2041;000000000001 Mail-from: ARPANET site BRL rcvd at 1-Dec-82 1008-PST Date: 1 Dec 82 10:26:24-EST (Wed) From: Dave Crocker To: MsgGroup@BRL Subject: MSGGROUP#1947 Transition Via: Mit-Mc; 1 Dec 82 11:32-EST Via: Brl; 1 Dec 82 11:56-EST Via: Brl-Bmd; 1 Dec 82 12:23-EST Ten years ago, the ArpaNet had its coming out party at the first International Conference on Computers and Communications, held in Washington, D.C. As part of my first full-time job, I served as a floor-walker during the demonstration, oblivious to the historical import of the event. The job was simply an interesting way to fill some time during an hiatus in my education. As such things go, it turned out to be the start of my professional life. Over the course of that life, I have had close contact with people on the net, while at UCLA, USC, Rand, and most recently at the University of Delaware. It has been an extraordinary learning and growing experience. In particular, I have appreciated people's openness to sharing and discussing their ideas. Even the occasional verbal flaming has not detracted. We focus on questions of system development; however, to the extent that we also are studying this technology's impact on the way people communicate, the flaming has been useful. Besides, families are expected to have squabbles. Consequently, it has been very difficult for me to decide to move in a new direction. After quite a lot of consideration, I have taken a position with MCI Communications in Washington, D.C., working in their Corporate Development Department with Vint Cerf. My last effective day at UDel will be 21 December, starting at MCI on 5 January. The new UDel contact for CSNet operations questions is Brendan Reilly (reilly@udel-relay), with Dave Farber (farber@udel-relay) continuing as principal investigator. Since some of the Relay's tasks are handled by our distributed staff, the best address for general queries is mmdf@udel-relay. Dave 1-May-83 11:34:55-PDT,1708;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 7-Dec-82 0021-PST Return-path: Postel@ISIF Date: 6 Dec 1982 2245-PST Subject: MSGGROUP#1948 RFCs 824 & 826 Now Available From: Postel@USC-ISIF To: "Request-For-Comments-List": New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. These are two memos discuss the mapping between Internet Addresses and local network addresses. This is a subject of current interest in the internet community, and it is intended that these memos stimulate further discussion of this topic. These are not specifications of Internet Standards. RFC 824: Title: The CRONUS Virtual Local Network Author: W. MacGregor & D. Tappan Pages : 41 pathname: [SRI-NIC]RFC824.TXT This memo presents the concept of a Virtual Local Network (VLN) that can operate on several different types of Physical Local Networks (PLNs), and the specific mechanisms for mapping between Internet addresses and VLN addresses, and between VLN addresses and PLN addresses. RFC 826: Title: An Ethernet Address Resolution Protocol Author: D. Plummer Pages : 10 pathname: [SRI-NIC]RFC826.TXT This memo presents a method of converting a Protocol Address (e.g., an IP address) to a Local Network Address (e.g., an Ethernet address). Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:55-PDT,3770;000000000001 Mail-from: ARPANET site BRL rcvd at 14-Dec-82 2138-PST Date: 12 Dec 82 18:47:31 PST (Sun) Message-ID: <267.408595651@UCI> To: MsgGroup.UCI at Rand-Relay Subject: MSGGROUP#1949 822 flame From: Marshall Rose Via: uci; 12 Dec 82 19:20-PDT Via: Rand-Relay; 12 Dec 82 22:52-EST Via: Brl; 12 Dec 82 23:23-EST Via: Brl-Bmd; 12 Dec 82 23:30-EST In reading the following, please keep in mind that I really do like 822: I've just finished making our UCI user agents 822-compatible, which wasn't all that difficult. In a very real sense all conforming to 822 means is that there another standard that the user agents have to know about. There's still a lot of 733 formatted mail sitting around and our user agents are still going to have to know about 733 if they are going to be able to handle those messages. Fortunately, 733 and 822 are very similar in a lot of respects. So again, this really wasn't that much work as the effort is more upgrading than replacement. *** BEGIN FLAME *** What really burns me up though is that there are still mailers around that don't even conform to 733. Question one: what good are standards if they're not conformed to? At this point you're probably thinking "oh, there only a few of those still around." WRONG. The date format used in the messages for several discussion groups is day-of-the-week, Month day, year hh:mmAM such as Thursday, January 21, 1982 2:39AM This is neither 733 nor is it 822, yet it's used commonly around the ARPAnet today. It's the TOPS-20 style date format (ODTIM). If you care to look at: Human-Nets, Sf-Lovers, or some of the other large discussion groups, you'll see dates just like this in the latest issues. Here we have two of the largest discussion groups, which literally pulse across the bandwidth of the ARPAnet, delivering useful reading to lots of networking folk, and they don't even conform to the official standards. If any standard is really going to be successful, it's going to have to be honored and used by all mailers across the Internet that send mail. Question two: what steps can be taken to prevent non-conforming mail from entering the net? Clearly this is the responsibility of the local mailer that accepts the message into the transport system at the posting slot. But given the realization that not all sites are going to have mailers around that are smart enough to tell what's valid and what's invalid, who is going to act as policeman? I really don't care what particular format a given site uses for its own local mail, but it had better be 822 when it hits UCI! I'm VERY tempted to modify the message transport service that we use (MMDF and XMAILR) to spit such messages back with a nasty reply saying something like "Message returned due to lack of conformance, clean up your act!". The reason I don't do this though is that I don't like the idea of having the transport service mucking about in a message's contents. Whatever mailer accepted the message into the transport service should have done that at that point, and we shouldn't have to check conformance to the standard when it enters our net. 822 talks about this briefly (hurrah). This isn't enough, we need action! *** END FLAME *** Well, anyone out there listening? PS: I'm going off-net next weekend for the rest of the year (I finished my 822 hacking), so if you don't reply prior to that, I won't see your responses until January 2 or so. /mtr 1-May-83 11:34:56-PDT,921;000000000001 Return-path: @USC-ISIF,Postel@ISIF Received: FROM USC-ISIF.ARPA BY USC-ECLC.ARPA WITH TCP ; 14 Dec 82 01:35:53 PST Date: 13 Dec 1982 2245-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1950 RFC 818 Now Available To: "Request-For-Comments-List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 818: Title: The Remote User Telnet Service Author: J. Postel Pages : 2 pathname: [SRI-NIC]RFC818.TXT This memo specifies the application service of User Telnet. This is an official protocol specification. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:59:42-PDT,6397;000000000001 Date: 14 Dec 1982 0845-PST Subject: MSGGROUP#1951 SURVEY #1901-#1950 from MSGGROUP.1901-2000.1 From: MsgGroup Moderator - Stefferud To: msggroup at USC-ECLC MSGGROUP#1901 SURVEY #1851-#1900 from MSGGROUP.1801-1900.1 6765 chars 20 Sep 1982 0031-PDT From: MsgGroup Moderator - Einar Steffe MSGGROUP#1902 Re: REMOVAL OF NAME FROM MAILING LIST 564 chars 18 Sep 1982 0105-PDT From: Mike Peeler MSGGROUP#1903 Re: REMOVAL OF NAME FROM MAILING LIST 1178 chars 20 Sep 1982 1601-EDT From: MOOERS at Bbna To: Admin.MDP at S MSGGROUP#1904 Re: Don't change mailing list conventions 1177 chars 20 Sep 1982 2213-PDT From: STEF at Darcom-Ka To: MsgRoup at MSGGROUP#1905 Don't change mailing list conventions 2077 chars 20 Sep 1982 17:52:43-EDT From: mullen at Nrl-Css (Preston Mu MSGGROUP#1906 Re: REMOVAL OF NAME FROM MAILING LIST 844 chars 21 Sep 82 2:24:30-EDT (Tue) From: Michael Muuss T MSGGROUP#1907 suggestions 1134 chars 21 Sep 82 14:20:35-EDT (Tue) From: Gene Spafford To: MSGGROUP#1909 Re: suggestions 737 chars 22 Sep 82 2:23:48-EDT (Wed) From: Michael Muuss T MSGGROUP#1910 Digest suggestions 2138 chars 22 Sep 1982 0054-PDT From: STEF at Darcom-Ka To: MsgGroup at MSGGROUP#1911 Format change suggestions 2872 chars 22 Sep 1982 0631-PDT From: WMartin at Office-8 (Will Martin) MSGGROUP#1912 Re: Format change suggestions 663 chars 22 Sep 82 9:36:09 PDT (Wednesday) From: Suk at Parc-Maxc To MSGGROUP#1913 MSGGROUP DIGEST SUGGESTIONS 2849 chars 22 SEP 1982 1526-PDT From: Reynolds at Ames-67 To: MSGGROUP MSGGROUP#1914 Re: MSGGROUP DIGEST SUGGESTIONS 873 chars 22 Sep 1982 17:41-PDT - Wednesday From: Brian Reid MSGGROUP#1918 FORWARDING LOOP BROKEN 1488 chars 22 SEP 1982 1912-PDT From: Reynolds at Ames-67 To: STEF at U MSGGROUP#1919 Re: Format change suggestions 692 chars 22 Sep 1982 1147-PDT From: WMartin at Office-8 (Will Martin) MSGGROUP#1920 Re: header mangling 1472 chars 23 Sep 82 6:28:29-EDT (Thu) From: Dave Crocker MSGGROUP#1931 NO! Don't propagate this madness! Stop the Bloody periods!!!! 795 chars 23 September 1982 15:37-PDT - Thursday From: Jonathan Alan MSGGROUP#1932 Programs to be changed 721 chars 23 September 1982 1936-EDT (Thursday) From: Richard H Gumper MSGGROUP#1933 munging my name! 814 chars 23 September 1982 2043-EDT (Thursday) From: Richard H Gumper MSGGROUP#1934 Re: munging my name! 861 chars 23 September 1982 23:48 cdt From: Stachour.CSCswtec at Hi-Mu MSGGROUP#1935 Re: NO! Don't propagate... 1783 chars 24 Sep 1982 1544-EDT From: Mark Plotnick To: ROODE at Sri-Nic Cc: MsgGroup at BRL Subject: MSGGROUP#1953 Re: 822 flame In-reply-to: Your message of 14 Dec 1982 2251-PST. From: Marshall Rose Via: uci; 15 Dec 82 19:11-PDT Via: Rand-Relay; 15 Dec 82 22:36-EST Via: Brl; 15 Dec 82 17:05-EST Via: Brl-Bmd; 15 Dec 82 23:01-EST I agree, TOPS-20 is not at fault. I make no difference to me as to what system calls a program uses to generate a date/time string. I really don't care if it's ODTIM on TOPS-20 or ctime() on UNIX, or ... What concerns me is when that string gets put in the ``Date:'' field of a mail message and somebody lets it get out onto the net. /mtr BTW - neither of the two date/time strings we've discussed are legal in the 822 sense. The second one is the one I started to complain about Tuesday, December 14, 1982 22:23:21-PST which is clearly improper. The first one which you used as a counter example 14-Dec-82 22:23:14 is also improper as it lacks a timezone. 1-May-83 11:34:56-PDT,1041;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 18-Dec-82 0249-PST Return-path: Postel@ISIF Date: 17 Dec 1982 22:45:00-PST From: Postel@USC-ISIF Subject: MSGGROUP#1954 RFC 829 Now Available To: "Request-For-Comments-List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 829: Title: Packet Satellite Technology Reference Sources Author: V. Cerf Pages : 5 pathname: [SRI-NIC]RFC829.TXT This memo briefly describes the packet satellite technology developed by DARPA and other participating organizations, and provides a bibliography of papers on this work. This is, in a sense, a status report on the packet satellite work. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:56-PDT,1226;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 20-Dec-82 2358-PST Return-path: Postel@ISIF Date: 20 Dec 1982 21:45:01-PST From: Postel@USC-ISIF To: "Request-For-Comments-List": Subject: MSGGROUP#1955 RFC 830 Now Available A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 830: Title: A Distributed System for Internet Name Service Author: Z. Su Pages : 16 pathname: [SRI-NIC]RFC830.TXT This memo proposes an internet name resolution service based on a distributed set of domain relative name servers, and includes features for determining the availability of compatible application protocols. This is a suggestion for a service which may lead to a internet standard. The intention is to stimulate discussion of this and similar ideas. This is not the specification of an internet standard. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:57-PDT,1246;000000000001 Mail-from: ARPANET site USC-ISIF rcvd at 28-Dec-82 1148-PST Return-path: WESTINE@USC-ISIF Date: 28 Dec 1982 1038-PST Subject: MSGGROUP#1956 RFC831 Now Available From: Ann Westine To: "[ISIF]Request-for-Comments.List": ; A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 831: Title: Backup Access to the European Side of SATNET Author: Robert Braden Pages : 5 pathname: [SRI-NIC]RFC831.TXT The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:57-PDT,3041;000000000001 Return-path: <@USC-ISID:Postel@ISIF> Received: from USC-ISID by USC-ECLC; Thu 27 Jan 83 23:24:35-PST Date: 26 Jan 1983 22:45 PST From: Postel@USC-ISIF.ARPA Subject: MSGGROUP#1957 New RFCs 832 through 839 Now Available To: "Request-for-Comments.List": New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. There are eight new memos summarizing the results of weekly surveys of the Internet Hosts. The surveys make a very simple check for evidence of TCP based server capability for the Telnet, FTP, and Mail services. These RFCs are status reports. RFC 832: Title: Who Talks TCP? Author: D. Smallberg Pages : 13 pathname: [SRI-NIC]RFC832.TXT or: [USC-ISIF]RFC832.TXT Survey of the Telnet, FTP, and Mail servers on 7-Dec-82. RFC 833: Title: Who Talks TCP? Author: D. Smallberg Pages : 13 pathname: [SRI-NIC]RFC833.TXT or: [USC-ISIF]RFC833.TXT Survey of the Telnet, FTP, and Mail servers on 14-Dec-82. RFC 834: Title: Who Talks TCP? Author: D. Smallberg Pages : 13 pathname: [SRI-NIC]RFC834.TXT or: [USC-ISIF]RFC833.TXT Survey of the Telnet, FTP, and Mail servers on 22-Dec-82. RFC 835: Title: Who Talks TCP? Author: D. Smallberg Pages: 13 pathname: [SRI-NIC]RFC835.TXT or: [USC-ISIF]RFC835.TXT Survey of the Telnet, FTP, and Mail servers on 28-Dec-82. RFC 836: Title: Who Talks TCP? Author: D. Smallberg Pages: 13 pathname: [SRI-NIC]RFC836.TXT or: [USC-ISIF]RFC836.TXT Survey of the Telnet, FTP, and Mail servers on 4-Jan-83. RFC 837: Title: Who Talks TCP? Author: D. Smallberg Pages: 14 pathname: [SRI-NIC]RFC837.TXT or: [USC-ISIF]RFC837.TXT Survey of the Telnet, FTP, and Mail servers on 11-Jan-83. RFC 838: Title: Who Talks TCP? Author: D. Smallberg Pages: 14 pathname: [SRI-NIC]RFC838.TXT or: [USC-ISIF]RFC838.TXT Survey of the Telnet, FTP, and Mail servers on 18-Jan-83. RFC 839: Title: Who Talks TCP? Author: D. Smallberg Pages: 14 pathname: [SRI-NIC]RFC839.TXT or: [USC-ISIF]RFC839.TXT Survey of the Telnet, FTP, and Mail servers on 25-Jan-83. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Public access files may be copied from the INTERNET-NOTEBOOK directory at USC-ISIF via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:57-PDT,934;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Thu 3 Feb 83 23:28:46-PST Date: 3 Feb 1983 21:15 PST From: Postel@USC-ISIF To: "Request-for-Comments.List": Subject: MSGGROUP#1958 New RFC 820 Now Available A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 820: Title: Assigned Numbers Author: J. Postel Pages : 22 pathname: [SRI-NIC]RFC820.TXT This memo give the status of number assignments for various protocols used in the Internet, including network numbers, protocol numbers, and port numbers. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. 1-May-83 11:34:57-PDT,604;000000000001 Return-path: Received: from BRL by USC-ECLC; Sun 6 Feb 83 17:10:49-PST Date: 4 Feb 83 3:57:30 EST (Fri) From: Michael Muuss To: MSGGroup@brl.arpa Subject: MSGGROUP#1959 List was down 1/27 -> 2/4 Received: From Brl-Bmd.ARPA via smtptcp; 4 Feb 83 3:59 EST Received: From Brl.ARPA via smtptcp; 6 Feb 83 19:40 EST Received: From Brl-Bmd.ARPA via smtptcp; 6 Feb 83 19:44 EST Due to a error in the address list for MSGGroup, all submissions sent between Jan 27 and today (Feb 4) were not delivered. Please resend your messages at this time. -Mike 1-May-83 11:34:57-PDT,879;000000000001 Return-path: Received: from USC-ISIB by USC-ECLC; Wed 9 Feb 83 03:18:05-PST Date: 8 Feb 1983 2034-PST From: POSTEL at USC-ISIB Subject: MSGGROUP#1960 RFC 842 Now Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 842: Title: Who Talks TCP? - Survey of 1-Feb-83 Author: D. Smallberg Pages: 14 pathname: [SRI-NIC]RFC842.TXT Survey of the Telnet, FTP, and Mail servers on 1-Feb-83. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:58-PDT,878;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Mon 14 Feb 83 19:11:02-PST Date: 14 Feb 1983 1837-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1961 RFC 843 Now Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 843: Title: Who Talks TCP? - Survey of 8-Feb-83 Author: D. Smallberg Pages: 14 pathname: [SRI-NIC]RFC843.TXT Survey of the Telnet, FTP, and Mail servers on 1-Feb-83. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:58-PDT,919;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Sat 19 Feb 83 16:56:48-PST Date: 19 Feb 1983 1618-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1962 RFC 844 Now Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 844: Title: Who Talks ICMP too? - Survey of 18-Feb-83 Author: R. Clements Pages: 5 pathname: [SRI-NIC]RFC844.TXT Survey of Telnet Servers from a Telnet User on a Class C Internet Address on 18-Feb-83. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:58-PDT,872;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Thu 24 Feb 83 20:25:58-PST Date: 24 Feb 1983 1919-PST From: POSTEL at USC-ISIF To: Request-for-Comments-List: Subject: MSGGROUP#1963 RFC 845 Now Available A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 845: Title: Who Talks TCP? - Survey of 15-Feb-83 Author: D. Smallberg Pages: 14 pathname: [SRI-NIC]RFC845.TXT A survey of the Telnet, FTP, and SMTP servers made on 15-Feb-83. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:58-PDT,1543;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Thu 3 Mar 83 22:21:30-PST Date: 3 Mar 1983 2054-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1964 RFC 847 Now Available To: "[ISIF]Request-for-Comments.List": A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 847: Title: Summary of Smallberg Surveys Author: A. Westine Pages: 2 pathname: [SRI-NIC]RFC847.TXT Over the past three months David Smallberg has made a weekly survey of the Telnet, FTP, and Mail servers in the Internet. These surveys were reported in RFC 832, 833, 834, 835, 836, 837, 838, 839, 842, 843, 845, and 846. This memo briefly summarizes the results of those surveys. The Smallberg surveys were made from the ISI-VAXA host which is on the ARPANET. There is concern that some ARPANET host may communicate with other ARPANET hosts but not with hosts on other networks (even though they use the Internet protocols). RFC 844 by Clements highlights this problem by surveying from a class C network host the hosts that respond positively to Smallbergs Telnet survey. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:58-PDT,991;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Thu 17 Mar 83 02:38:18-PST Date: 16 Mar 1983 2111-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1965 RFC 848 Now Available To: Request-for-Comments-List: A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 848: Title: Who Provides the "Little" TCP Services? Author: D. Smallberg Pages: 5 pathname: [SRI-NIC]RFC848.TXT This is a survey of the minor service operated on TCP (i.e., Echo, Discard, Active Users, Date and Time, Netstat, Quote of the Day, Character Generator, Time, and Finger). Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:58-PDT,745;000000000001 Return-path: <@MIT-MULTICS:Schauble.HDSA@m.pco.lisd.his> Received: from BRL by USC-ECLC; Sun 20 Mar 83 00:42:56-PST Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 20-Mar-1983 02:51:44-est Date: 20 Mar 83 00:48 mst From: Schauble.HDSA@m.pco.lisd.his Subject: MSGGROUP#1966 Where to order documents Reply-To: Schauble%PCO-Multics@mit-multics.arpa To: MsgGroup@brl.arpa, Human-Nets@rutgers.arpa Received: From Mit-Multics.ARPA via smtptcp; 20 Mar 83 2:58 EST Received: From Brl.ARPA via smtptcp; 20 Mar 83 3:03 EST Received: From Brl-Bmd.ARPA via smtptcp; 20 Mar 83 3:11 EST Can someone please supply with the addresses from which I can order NBS, ISO, ANSI, and CCITT standards documents. Thanks, Paul 1-May-83 11:34:58-PDT,2290;000000000001 Return-path: Received: from BRL by USC-ECLC; Mon 21 Mar 83 13:14:02-PST Date: 21 Mar 1983 1015-PST From: POSTEL@usc-isif.arpa Subject: MSGGROUP#1967 Document Ordering To: msggroup@brl.arpa Received: From Usc-Isif.ARPA via smtptcp; 21 Mar 83 13:20 EST Received: From Brl.ARPA via smtptcp; 21 Mar 83 13:25 EST Received: From Brl-Bmd.ARPA via smtptcp; 21 Mar 83 13:28 EST Return-path: Mail-From: SMTP created at 21-Mar-83 08:42:11 Received: FROM USC-ISIB.ARPA BY USC-ISIF.ARPA WITH TCP ; 21 Mar 83 08:42:17 PST Date: 21 Mar 1983 0839-PST Sender: SABATINE at USC-ISIB Subject: Re: Where To Order Documents ? From: SABATINE at USC-ISIB To: POSTEL at USC-ISIF Cc: sabatine at USC-ISIB Message-ID: <[USC-ISIB]21-Mar-83 08:39:58.SABATINE> In-Reply-To: Your message of 20 Mar 1983 1342-PST Jon, Here are the appropriate locations. I'm sending this to you in the hopes that you'll forward it to the original requestor. ISO and ANSI standards are both ordered from: American National Standards Institute 1430 Broadway New York, NY 10018 (212) 354-3300 It's best to call first and receive price quotes and info re the correct method of payment. They also have an ISO catalog that can be obtained. NBS publications are ordered either from the Superintendent of Documents, US. Government Printing Office, Washington D.C. 20204, or from the National Technical Information Service (NTIS). I always go through NTIS because they are fast and accept phone orders. Their address is Port Royal Road, Springfield Virginia, 22161. (703) 487-4650. Both agencies only accept orders via a GPO SuDoc number, or an NTIS accession number. To find out the available publications from NBS, and the corresponding order numbers, it may be best to contact them directly. The NBS address is simply: National Bureau of Standards, U.S. Department of Commerce, Washington D.C. 20234. I'm sorry, I don't have a phone number. CCITT: International Telecommunication Union General Secretariat Sales Service Place des Nations CH-1211 Geneva 20 Switzerland They, too, can be contacted for publications lists and order forms. I hope this helps, Alicia ------- 1-May-83 11:34:59-PDT,1892;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Tue 12 Apr 83 19:50:06-PST Date: 12 Apr 1983 1856-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1968 RFCs 851 & 852 Now Available To: Request-for-Comments-List: New RFCs are now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 851: Title: The ARPANET 1822L Host Access Protocol Author: A. Malis Pages : 47 pathname: [SRI-NIC]RFC851.TXT This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. The RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. RFC 852: Title: The ARPANET Short Blocking Feature Author: A. Malis Pages : 13 pathname: [SRI-NIC]RFC852.TXT This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. The RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:59-PDT,1256;000000000001 Return-path: Received: from USC-ISIF by USC-ECLC; Tue 12 Apr 83 21:17:30-PST Date: 12 Apr 1983 2038-PST From: POSTEL at USC-ISIF Subject: MSGGROUP#1969 RFC 840 Now Available To: Request-for-Comments-List: A new RFC is now available from the Network Information Center in the NETINFO directory at SRI-NIC. RFC 840: Title: Official Protocols Author: J. Postel Pages: 23 pathname: [SRI-NIC]RFC840.TXT This memo lists the protocols used in the DARPA Internet, it indicates the status of each protocol, it identifies the specification, it comments on the protocol -- especially noting differences from the existing specification, and it indicates a contact person for each protocol. This memo documents the status of protocols at the time it is issued. It is expected that updated editions of this document will be issued from time to time. Public access files may be copied from the NETINFO directory at SRI-NIC via FTP with username ANONYMOUS and password GUEST. Submissions for RFCs should be sent to POSTEL@USC-ISIF. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC. --jon. ------- 1-May-83 11:34:59-PDT,6443;000000000001 Return-path: <@MIT-MC:MRC@su-score> Received: from BRL by USC-ECLC; Tue 19 Apr 83 14:21:06-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 19 Apr 83 4:13 EST Received: From Brl.ARPA by BRL-BMD via smtp; 19 Apr 83 4:02 EST Received: From Mit-Mc.ARPA by BRL via smtp; 19 Apr 83 3:52 EST Date: 14 Apr 83 21:29:26-PST Thu From: Mark Crispin Subject: MSGGROUP#1970 domains and host naming issues To: Postel@usc-isif.arpa cc: nethax%SU-HNV@su-score.arpa, MsgGroup@mit-mc.arpa Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Folks - As some of you may know already, I am on the verge of completing a new release of the TOPS-20 mailsystem with many improvements in the area of host name/address lookups. A lot of time and energy was spent on doing it "right" so that the implementation would last for the conceivable networking future. Phase II of HSTNAM (source on [SU-SCORE.ARPA]MRC:HSTNAM.MAC) is more or less complete. The TOPS-20 mail delivery process (MMailr) uses it and I'm working on getting the message composer (MM) to use it as well. One of the most innovative features of HSTNAM is the capability to support local networks in conjunction with Internet. For example, at Stanford the mailsystem is obligated to support Pup Ethernet in conjunction with Internet. At MIT Chaosnet is supported along with Internet. In addition, there is a lot of relayed traffic between Internet and these local networks. This brings me to the point of this message, which is how should these multiple registries be handled? It is simple to determine a local network registry from an Internet registry, because the latter has the ".ARPA" domain at the end. However, there is no way to determine one local network registry from another. For local networks which are directly connected to the host this is not a problem; a trial and error approach could be taken. Where it does become an issue is with non-Internet networks which the host is not a member but can receive mail via relays. A related problem is when a non-Internet host on one of these networks wishes to mail through the Internet. For example, user Crispin on host Tiny (which is not on Internet) on Stanford's Pup Ethernet would have the mailbox so far as other Pup Ethernet hosts are concerned. Suppose however a message crosses out of the Pup Ethernet to Internet, say to NLM-MCS. Under the old HOSTS2-based software, the mailbox is , which is a cleverly disguised form of the multiple-at to satisfy RFC 822. Under the RFC 822 way of satisfying routes, the mailbox would become <@SU-SCORE.ARPA:Crispin@Tiny>. Already we are starting to get into problems; the receiver has to be able to comprehend that it may not know of the name "Tiny" and act accordingly. Additionally, replying to the message makes the assumption that that particular relay host is available. Let's make matters more complicated by having the message go to some user on a host that is only on MIT's Chaosnet. The mailbox has now become <@MIT-MC,@SU-SCORE:Crispin@Tiny>. Either we are stuck with having to use that exact path to deliver a reply to, or we must have a guarantee that the name "Tiny" is unique. Already, MIT and Stanford have been picking the same names for some of their systems. The problem is further complicated by the possibility of local network mail which gets redistributed outside of its domain. There were several other ambiguity problems I encountered while implementing this. One of the nastiest was the inability to specify a particular network in mailing. Suppose there is a satelite like so that Score gets on MIT's Chaosnet? Well, there's a problem that MIT has a host called "Robotics" and so does Stanford. What does mail to "Crispin@Robotics" mean? The problem comes down to this; only Internet messages get any form of domain specifier when you really want domain specifiers for everybody. A simple domain of "Chaosnet" would not suffice because there are multiple Chaosnets; the same applies for Pup Ethernet. The obvious solution to me would be to define top-level domain names for every non-Internet network environment. Now, I can already hear the screams of terror; it would mean "we'd have to implement domains" and DCA has temporarily disallowed domains other than ".ARPA". Let me reassure everyone. I'm not proposing that all of a sudden people would be faced with addresses such as . That would in fact be what may appear within the Stanford Ethernet, but what would appear on the Internet would be <@SU-SCORE:Crispin@Tiny.SU-NET>. If your mailsystem can parse <@SU-SCORE:Crispin@Tiny> I don't see why it should get upset at seeing a ".SU-NET" domain. I don't even see how this would be a violation of DCA's decision to not use non-ARPA domain names; since a relay name is specified the stuff to the right of the "@" is in an undefined format. There is as much hope of an Internet site understanding "Tiny" as there is of "Tiny.SU-NET". So, my first query would be how widely understood is the RFC 822 style of relay specification. I have seen messages using that format appear on the Internet, but not very many. Most sites which do relaying seem to use some form of multiple-at replacement kludge (e.g. "%" for TOPS-20's, "." for Unix, etc.). Second, given that RFC 822 relay specifications are valid, is there general agreement or disagreement with my assertation that <@SU-SCORE:Crispin@Tiny.SU-NET> is a perfectly valid address TODAY. Specifically, is it agreed that the prohibition against non-ARPA domains does not apply here and the burden of parsing "Tiny.SU-NET" is exclusively SU-SCORE's? Third, if RFC 822 relay specifications are not generally recognized as valid, does anybody venture to dispute that the mailbox is valid? Fourth, what is the opinion of the SU-NET and MIT Chaosnet hackers on this issue? In particular, are the non-TOPS-20 software implementors willing to implement a "SU-NET" or "MIT-CHAOS" domain? Do they recognize and agree with the need for this? -- Mark -- ------- 1-May-83 11:34:59-PDT,2817;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 19 Apr 83 00:01:54-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 17 Apr 83 14:11 EST Received: From Brl.ARPA by BRL-BMD via smtp; 17 Apr 83 14:08 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Apr 83 14:05 EST Date: 16 Apr 1983 2025-PST From: POSTEL@usc-isif.arpa Subject: MSGGROUP#1971 re: domains and host naming issues To: msggroup@mit-mc.arpa This is in response to Mark Crispin's comments and questions of 14 April 83. Mark brings up some difficult questions, the more difficult because we live in a changing world, where we are always only part of the way toward "getting it right". One assumption Mark (and many others) make is that the 822 route syntax allows relative routes. The syntax itself can't say, but i claim that the intention was (and is) that each element of a route-address be a fully specified address in the internet. That is that each element of the route must be absolutely and independently addressable and unique. I am pretty sure that there are still many user level mail programs that do not handle the "route" aspect of addresses. So trying to use "routes" now to solve some addressing problem is likely to simple move the problem to other programs and locations. I disagree that "<@SU-SCORE:Crispin@Tiny.SU-NET>" is a valid address today. My disagreement is that "Tiny.SU-NET" is not an absolute address in the internet, and further that it is a currently disallowed use of a domain style name. The currently allowed domain style names are the host names registered in the NICs "HOSTS.TXT" file, or those names suffixed with ".ARPA". I have no problem with an address of the form "". It is entirely up to SU-SCORE to determine valid "local-part"s. As far as thinking to the future, when domains other than "ARPA" are allowed, i would guess that names like "STANFORD" and "MIT" would be of interest, rather than "SU-NET", or "MIT-CHAOS". A point that could be made clearer is that the hosts that Mark is concerned about (e.g., "Tiny") are not really in the Internet at all. They do not implement the Internet protocols (i.e., they don't know SMTP). So these hosts really have the same status with the Internet as hosts in USENET or other communication environments. This is not to dismiss the problem, but to point out that it is actually more difficult than one might at first realize. It is one of the goals of the work on domain style names in the Internet to come up with a name system and name resolution procedures that do reasonably handle communication (especially mail) with non-Internet hosts. --jon. ------- 1-May-83 11:35:00-PDT,6133;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 20 Apr 83 05:47:59-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 20 Apr 83 2:11 EST Received: From Brl.ARPA by BRL-BMD via smtp; 20 Apr 83 1:39 EST Received: From Mit-Mc.ARPA by BRL via smtp; 20 Apr 83 1:30 EST Date: 19 Apr 83 22:30:49 PST (Tue) From: "Mike O'Dell [system]" Subject: MSGGROUP#1972 re: domains and host naming issues Message-Id: <8304200630.AA17592@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.7) id AA17592; 19 Apr 83 22:30:49 PST (Tue) To: POSTEL@usc-isif.arpa Cc: msggroup@mit-mc.arpa In-Reply-To: Your message of 19 Apr 1983 1920-PST (Tuesday). <8304200319.AA02941@LBL-CSAM.ARPA> Jon, It is hard to know where to begin. I would submit that a better formulation of Mark's address would be MRC@Tiny.SU-Net-Mail-Gateway.ARPA This is a perfectly valid domain name, assuming "SU-Net-Mail-Gateway" is registered in the NIC host database. Indeed, if the Name Servers are do be worth the trouble to do, they must be able to return one or more Internet addresses for hosts which perform mail gatewaying for SU-Net, whatever that is. The bottom line is the the Mail world in an internet (note small "i") and needs gateways, routing tables, and "redirect messages" returned from knowledgeable gateways who can provide assistance optimizing routes. As far as I can see, this is the ONLY way the local mail universes can be organized in ways which don't require updating all the databases in the universe every time someone buys a new Sun workstation. This also means that the Name Servers, as constituted, aren't up to it without "redirect messages" from name servers. Assume the simple case where LBL's local network is in fact IP/TCP/SMTP based and therefore it is possible for similar mailers to directly deliver mail without gatewaying (assuming they don't need whitepage service, or the like). We have several choices: (1) the entries in the NIC database for LBL will be 20 or 30 over the next year, with a number like 200 in the next 3 years, or instead, we create a subdomain "LBL-Mail" which, along with "major" hosts on the LBL local net, is listed in the NIC database. "LBL-Mail" should probably be replicated on several machines, and the name servers should return all the possible addresses so they can be tried. Now, when LBL sends out mail, the return address will be of the form mo-himself@mo-sun.LBL-Mail.ARPA when someone tries to send mail back, you use the "address resolution protocol" I described in an earlier note to this list. The mailer will discover an Internet address for some host with a nicname "LBL-Mail" and send to it. It is then the responsibility of that machine to get the mail to whomever and whatever "mo-himself@mo-sun" might be. Note carefully this does NOT require all the name servers to be working before we can do this!!! All it requires is for the mail gateway hosts to register nicnames which are the same as their subdomain. Later, when name servers are the rule, you can get multiple IP addresses to try looking for "LBL-Mail". There is another algorithm using redirects from the name server. If LBL is clever and considerate of the outside world, we will provide a name server which will gladly map "mo-sun.LBL-Mail.ARPA" to the Internet address of the Sun on my desk, and some enterprising peer SMTP implementation could try to connect directly to my machine to deliver the mail. This implementation would discover this by the reply from the name lookup on "LBL-Mail" returning advisory information that host so-and-so provides name service for the LBL-Mail.ARPA subdomain. Whether this ultimately works depends on the state of my machine, etc. In any event, it can always back off and send it to the mail gateway. Where this is even more important is where the mail universe isn't always IP/TCP/SMTP. Providing the gateway mechanism lets sites present a coherent model to the Internet world, and discretely conceal their internal anarchy from the Host Tables of the world. As we move towards whitepage services, this will be even more important. As an example, I cite the "network" currently concealed (inadequately, at times) behind LBL-CSAM. On our 30 host VMS/RSX DECnet network, we run the Software Tools Mail System which is based on SMTP and interfaces to peers via DECnet process-to-process channels or Hyperchannel connections. It also interfaces with VMS Mail so machines not running the Tools can send mail around the Lab, it interfaces with UUCP to connect to LBL-CSAM, and it now talks over TCP connections around our local ring to this machine and any other host who happens to know about getting to Internet address 128.3.0.21. Mail format conversions are done when necessary. The point is that while some of this chewing-gum and bailing-wire will be going away in the next year as a more coherent IP/TCP network somes into operation, the DECnet subnet will NEVER go away - it connects to other laboratories who don't care a whit about protocol wars, and we MUST have coherent mail service. Moreover, many of those people on the unenlightened machines are authorized Internet users, and politically, they have every right to send and receive mail on the machine of their choice, especially since we know how to make that work. If we could start sending addresses with subdomains and/or real routes, people might not be able to "reply" with their favorite reply command, but they would have the information necessary to reply! I claim this is NOT generally the case now. The Mail internet is already MUCH larger than the Internet and is suffering fearfully because of it. The sooner we let people start sending addresses like the ones above the sooner people can stop trying to figure out the "address format de jour" for hosts hidden behind ad hoc gateways (I don't have to remind anyone of the % fiasco). Sorry if this got a little charred around the edges. -Mike 1-May-83 11:35:00-PDT,1552;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 20 Apr 83 17:56:24-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 20 Apr 83 16:54 EST Received: From Brl.ARPA by BRL-BMD via smtp; 20 Apr 83 16:39 EST Received: From Su-Score.ARPA by BRL via smtp; 20 Apr 83 14:35 EST Date: 20 Apr 83 11:38:03-PST Wed From: ADDRESS PROBLEM: (BRL) ("Mark Crispin "); Subject: MSGGROUP#1973 re: domains and host naming issues To: POSTEL@usc-isif.arpa cc: MsgGroup@brl.arpa Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of Sat 16 Apr 83 20:25:00-PST This is in reply to Jon's message. Now that it's been officially stated that a routed address must have absolute components which are valid, I'd like to make the following radical proposal: let's flush routed addresses altogether. The only reason I can see for having them is to support relaying between Internet and non-Internet environments. They aren't fully implemented everywhere (for example, my SMTP server parses but otherwise ignores them; MM doesn't even parse them yet), and some people have in fact started using relay addresses for the purpose of supporting routing between Internet and non-Internet addresses. Since Jon says this is wrong and it isn't generally implemented let's stamp it out now, and get rid of a part of the spec that only makes things more complicated while we're at it. -- Mark -- ------- 1-May-83 11:35:00-PDT,4950;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 20 Apr 83 18:34:46-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 20 Apr 83 18:14 EST Received: From Brl.ARPA by BRL-BMD via smtp; 20 Apr 83 18:09 EST Received: From Su-Score.ARPA by BRL via smtp; 20 Apr 83 18:02 EST Date: 20 Apr 83 15:04:05-PST Wed From: Mark Crispin Subject: MSGGROUP#1974 more on domains To: MsgGroup@brl.arpa, Header-People@mit-mc.arpa cc: Postel@usc-isif.arpa, Hedrick@rutgers.arpa, nethax@su-hnv.arpa, Bug-MAIL@mit-mc.arpa Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is a problem with Jon's suggestion to use "STANFORD" or "MIT" as top-level domains meaning "the Stanford Pup Ethernet" or "the MIT Chaosnet". Both MIT and Stanford have more than one network. At Stanford, an Internet network [36.x.y.z] share the same backbone and some of the same members with a Pup Ethernet. This is the first part of my problem. The name "SU-Shasta.ARPA" refers unambiguously to Internet [36.40.0.192]. The question that pops up is how to refer to Pup 50#300. The present situation is this. My name/address lookup module (HSTNAM) prefers to use Internet registries whenever possible. SHASTA is listed in the NIC HOSTS.TXT file as a nickname for SU-SHASTA, but does not appear in HSTNAM.MULTINET (also distributed by the NIC) which is used by the TOPS-20 kernal and thus consulted by the HSTNAM module. Only SU-SHASTA is in HSTNAM.MULTINET. Therefore, SU-Shasta becomes SU-SHASTA.ARPA, Internet [36.40.0.192]. Shasta is unrecognized as an Internet name and stays as such, becoming Pup 50#300. The same thing happens for most other members on Stanford's Ethernet. This would only be a side note in the annuals of networking comedy, if it weren't for the fact that Pup mailing is presently preferred for most of the Stanford network! A way is therefore needed to unambiguously specify the name registry. Then, Shasta would mean "any registry that recognizes Shasta", but Shasta.ARPA would only be in the Internet domain and Shasta.SU-Pup would only be in the Stanford Pup domain. If you want to have automatic relaying to some network that you are not connected to, it is virtually impossible to do this today without some form of high-level name registry. Automatic relaying is a well-known and loved feature of the TOPS-20 mailer, and several sites have indicated stiff opposition to the prospect of losing it. It is much more feasible to inform the mailer that "mail for anything.MIT-Chaos should be relayed through MIT-MC.ARPA" than to make the futile attempt of keeping track of all the members of MIT-Chaos. It also makes it possible for an intelligent mailsystem to reply to a message from one of these sites without requiring local knowledge of the name. Since there are multiple name registries at multiple sites, I suggest names such as SU-Pup, MIT-Chaos, DEC-DECnet, CMU-CU-DECnet, CSnet, etc. It is wrong to consider "Stanford" and "Stanford Pup Ethernet" to be the same entity. More importantly, I want an official Internet registry of these non-Internet name registries. I am not (yet) asking that these names be recognized as alternative top-level domains to ARPA. I am asking that some list of these names be made and kept so that applications like mine which must have this now will use a common set of names. Mail sent out on the Internet would be of the form: to satisfy the constraints of absolute host naming and non-use of domains other than ARPA. But within the non-Internet networks, you would see addresses such as It is, of course, possible that such addresses will leak out on the Internet from time to time with about the same frequency as host names such as SCRC-TENEX or SU-TINY leak out now. My feeling is that it's a tough world out there and there isn't much that can be done until the restriction on non-ARPA domains is removed. The best we can do is make a good try. I propose as an initial implementation that the Stanford Pup Ethernet get the name SU-Pup and the MIT Chaosnet get the name MIT-Chaos.... I would like to receive input from the network hackers at both the Stanford Pup net and the MIT Chaosnet as to whether this will impose a hardship upon them and if they object to those names and want something different. I imagine the Unix systems on the Stanford Pup net would get by if it ignored SU-Pup the way they ignore ARPA now; I would take care of the TOPS-20's. I do want to receive some input from the MIT Chaosnet people. I am willing to create such a registry for ultimate adoption by the NIC, provided that these proposals aren't met with outright hostility. -- Mark -- ------- 1-May-83 11:35:00-PDT,1760;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 20 Apr 83 23:55:40-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 21 Apr 83 0:44 EST Received: From Brl.ARPA by BRL-BMD via smtp; 21 Apr 83 0:40 EST Received: From Lbl-Csam.ARPA by BRL via smtp; 21 Apr 83 0:35 EST From: "Mike O'Dell [system]" Resent-Date: 20 Apr 83 21:04:48 PST (Wed) Date: 20 Apr 83 21:04:48 PST (Wed) Resent-From: "Mike O'Dell [system]" Subject: MSGGRPUP#1975 Mark's note on Jon's note about routed addresses Resent-Message-Id: <8304210504.AA12755@LBL-CSAM.ARPA> Message-Id: <8304210504.AA12755@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA12755; 20 Apr 83 21:04:48 PST (Wed) To: header-people@mit-mc.arpa, msggroup@brl.arpa Outlawing routed addresses will be as sucessful as outlawing Rain on Tuesday or the 55 mile per hour speed limit. We can either face the reality of relaying mail between dissimilar mail systems, or we will surely drown in an every increasing trickle of bizarre addresses. We can all bust our collective butts continuing to hide all of our internal hosts behind various address magic cookies (%, for instance), or we can work as hard trying to make some progress solving some admittedly non-trivial problems. Here at LBL, adopted SMTP and the entire RFC82* suite just so we could make this stuff work. Moreover, up to now, I have been lobbying VERY hard to convert the UUCP universe to an SMTP/82*-based scheme just so all this crap would stick together just a little better. But if now we are going to reinstitute Internet Xenophobia, why did we ever drop 733????? Hoping I misunderstand, -Mike 1-May-83 11:35:01-PDT,2209;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 21 Apr 83 07:57:09-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 21 Apr 83 7:51 EST Received: From Brl.ARPA by BRL-BMD via smtp; 21 Apr 83 7:46 EST Received: From Sri-Unix.ARPA by BRL via smtp; 21 Apr 83 7:34 EST Date: 20 Apr 1983 at 2245-PST From: Andrew Knutsen To: msggroup@brl.arpa Subject: MSGGROUP#1976 domains and routes Sender: knutsen@sri-unix.arpa This is starting to scare me... just as I was beginning to think that the concept of domains could solve most of our addressing problems, it looks as if people are seriously considering tossing them into the mixed bag of pre-existing addressing methods to drown. In the ideal world, it seems to me, the NIC would have a list of domains, and a list of hosts which could be assumed responsible for each domain (ie posessing a host table for it). These domains would not correspond to physical networks; they would correspond to organizations capable of maintaining an up to date table of the hosts within them. The sender would find one of the hosts which was up, and send the message there (unless a name server protocol was used). The address in the message would contain the name of the domain being sent to, but not necessarily the name of the host actually sent to. Also, no SMTP routes in the header (but thats another story). There has been a suggestion that domains would not be validated unless they supported a name server. I think that the idea of an address resolution algorithm is great, since if the sending host has the receivers address it can get a quick end-to-end acknowledgement. However it would also be useful if we could get our mail through *today*. Thus I would suggest that domains be allowed to exist without name servers (but not too happily). I realize that if every host is allowed in the domain field, this would be just like equating '.' with '@', and we would be in danger of letting source routed addresses get out of hand. There may also be some military-political issues involved. However if we aren't careful, the chance to clear the mess up will pass. 1-May-83 11:35:01-PDT,1576;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 21 Apr 83 03:57:22-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 21 Apr 83 5:11 EST Received: From Brl.ARPA by BRL-BMD via smtp; 21 Apr 83 5:05 EST Received: From Su-Score.ARPA by BRL via smtp; 21 Apr 83 4:58 EST Date: 21 Apr 83 02:01:19-PST Thu From: Mark Crispin Subject: MSGGROUP#1977 Re: domains and host naming issues To: MsgGroup@brl.arpa cc: Postel@usc-isif.arpa Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Mike's message underscores exactly the problem I find myself facing. I have an internet (with small "i") mailer that is having a helluva time coping with the restrictions Internet places on it. I had thought when we invented domains that that would solve the problem for internet mailing. If we couldn't use domains right away, at least we could use the @relay-host:foo@host syntax. The "%" kludge has a lot of problems, not the least being that it is relative to its recepient. Woe be it if a message with an "%" address is redistributed outside of its domain. You also can't be clever about flushing multiple levels of "%" the way you were with multiple at's, because "%" may not necessarily be a relaying character. Needless to say, I also find myself quite frustrated at having the capability to implement domains right now, and not being able to use it. Could we have some timetable on when non-ARPA domains will be allowed? ------- 1-May-83 11:35:01-PDT,1002;000000000001 Return-path: <@MIT-MC:BILLW@sri-kl> Received: from BRL by USC-ECLC; Sat 23 Apr 83 02:05:03-PST Received: From Brl-Bmd.ARPA by BRL via smtp; 22 Apr 83 18:16 EST Received: From Brl.ARPA by BRL-BMD via smtp; 22 Apr 83 18:07 EST Received: From Mit-Mc.ARPA by BRL via smtp; 22 Apr 83 17:31 EST Date: 21 Apr 1983 1211-PST Sender: BILLW@sri-kl.arpa Subject: MSGGROUP#1978 domains... From: William "Chops" Westfield To: msgGroup@mit-mc.arpa Message-ID: <[SRI-KL]21-Apr-83 12:11:01.BILLW> Seems to me there are only two ways that things get implemented: 1) By edict (ala TCP) 2) Somebody does it, and the rest of us decide its a good idea (remember when MIT was the only place that had mailing lists?) So, MRC, go ahead and implement domains in your mailer. The worst that can happen is that no one except those at stanford will be able to understand your message headers. Thats OK. Even now, many mesasges have un-parsable headers... BillW 1-May-83 11:35:01-PDT,922;000000000001 Return-path: Received: from BRL by USC-ECLC; Tue 26 Apr 83 03:40:09-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 24 Apr 83 19:49 EDT Received: From Brl.ARPA by BRL-BMD via smtp; 24 Apr 83 19:19 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 23 Apr 83 6:58 EST Date: 22 Apr 1983 1455-EST From: Chris Ryland Subject: MSGGROUP#1979 Domain flap To: msggroup@mit-mc.arpa I would like to point out that the domain scheme is probably hopeless anyway for non-DOD-Internet naming, as the number of internet (lower case) domains would probably be in hundreds already. As a simple example, imagine trying to deal with the UUCP domain; it is so ad-hoc itself that having a naming authority makes almost no sense. I would be happy to be corrected, but it seems that the Internet domain names will be useful for the few dozen DCA domains, and nothing else. ------- 1-May-83 11:35:01-PDT,2158;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 00:34:34-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 26 Apr 83 0:19 EDT Received: From Brl.ARPA by BRL-BMD via smtp; 26 Apr 83 0:04 EDT Received: From Purdue.ARPA by BRL via smtp; 25 Apr 83 13:41 EDT Date: 25 Apr 1983 12:34:36-EST From: Christopher A Kent Reply-to: cak@purdue.arpa To: MRC@su-score.arpa Cc: MsgGroup@brl.arpa, Header-People@mit-mc.arpa, Postel@usc-isif.arpa, Hedrick@rutgers.arpa, nethax%Diablo@su-score.arpa, Bug-MAIL@mit-mc.arpa Subject: MSGGROUP#1980 Re: more on domains Personal reaction, no animosity or character assasination intended: Yuck! Bletch! Ugh! Foo! Domains are supposed to do away with exactly this mess. I don't want to have to know that you have four (or fourteen) different kinds of networks inside your domain. I don't want to have to know whether or not there are different naming conventions for each. I think that top-level domains are being used for two purposes, and perhaps this is the root of the problem. They seem to be used to diambiguate different physical networks within a computing environment, and to indicate a funding or administrative grouping of machines. These two purposes seem to be mutually exclusive in many cases. I would propose that something more like be the address that gets to Mark in his example, with the possible modification of dropping the .ARPA qualifier. There's no funny relaying going on, and all I as a user have to understand is how to get to the Stanford domain. Beyond that, it's "invisible". I really don't like the idea of having to know that SU-Tiny is on Pup; I think that should be hanlded by the gateway/nameserver, with protocol translation if so desired, or by having the nameserver return the Internet address of an appropriate relay host. I also feel that it is wrong to think about addresses such as , even within subdomains. The mailer should fully qualify these, even though the user might not have to type the whole ***Sender closed connection*** { 1-May-83 11:35:02-PDT,1149;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 01:00:25-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 26 Apr 83 0:41 EDT Received: From Brl.ARPA by BRL-BMD via smtp; 26 Apr 83 0:09 EDT Received: From Su-Score.ARPA by BRL via smtp; 25 Apr 83 16:43 EDT Date: 25 Apr 83 13:40:09-PDT Mon From: Mark Crispin Subject: MSGGROUP#1981 Re: more on domains To: cak@purdue.arpa cc: MsgGroup@brl.arpa, Header-People@mit-mc.arpa, Postel@usc-isif.arpa, Hedrick@rutgers.arpa, nethax%Diablo@su-score.arpa, Bug-MAIL@mit-mc.arpa Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of Mon 25 Apr 83 10:34:34-PDT I agree that having a Stanford name domain would be desirable. The problem is that it seems to require considerably more cooperation from various individuals in the Internet world, not to mention at Stanford, than seems to be forthcoming. A solution that says "you should do this", but "you can't do this yet" doesn't help me when I have to do something "now". ------- 1-May-83 11:35:02-PDT,2806;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 01:14:29-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 26 Apr 83 0:42 EDT Received: From Brl.ARPA by BRL-BMD via smtp; 26 Apr 83 0:10 EDT Received: From Rutgers.ARPA by BRL via smtp; 25 Apr 83 17:04 EDT Date: 25 Apr 1983 1700-EDT From: Mgr DEC-20s/Dir LCSR Comp Facility Subject: MSGGROUP#1982 Re: more on domains To: MRC@su-score.arpa cc: cak@purdue.arpa, MsgGroup@brl.arpa, Header-People@mit-mc.arpa, Postel@usc-isif.arpa, nethax%Diablo@su-score.arpa, Bug-MAIL@mit-mc.arpa In-Reply-To: Your message of 25-Apr-83 1644-EDT I agree with Mark that something should be done to allow an interim form of domains to start up immediately. I don't much care what it is. My preference, as many of you may know, is to allow any Arpanet host name or nickname to be used as a penultimate subdomain, i.e. right before the .ARPA. Until domains are completely implemented, if a mailer didn't know what the host was, it would direct the mail to the corresponding host. The host name with domain would still be absolute, in principle. In our case we would have other ways of finding better routings in most cases. This would simply be a way of specifying a default routing until we get a complete set of domain servers. If Mark needs more information, my proposal would either require him to use a sub-sub-domain, e.g. SAIL.PUP.SCORE.ARPA. This is what I would prefer. Or if he insists, and NIC agrees, he could define STANFORD-PUP as a nickname for SCORE, and then use SAIL.STANFORD-PUP.ARPA. I think it is fairly important to insist that the penultimate subdomain be a real host name or nickname, since otherwise I am going to have to have a table that maps domain names into relay hosts. I think that is too much for an "interim" solution. Personally I think the whole idea of having to specify the network within Stanford is a violation of the concept of absolute addressing. That seems to be something that belongs in the routing. But I am not sure that is any of my business. If he wants to have two different hosts whose names are the same up to the first dot, I guess I don't care. I do think that something needs to be done quickly. It is clear that there is currently a gaping hole in the mail system. We are seeing various kludges come in to fill it. I would much rather see almost any interim domain system get started as soon as possible. I am going to assume that any reasonable interim system is going to have the same results for just about everybody except Stanford, namely HOST.SITE.ARPA, where site is likely to be fairly obvious (RUTGERS, STANFORD, BERKELEY, etc.) ------- 1-May-83 11:35:02-PDT,779;000000000001 Return-path: <@usc-isid,@ucl-cs:steve@ucl-cs> Received: from BRL by USC-ECLC; Wed 27 Apr 83 01:00:14-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 26 Apr 83 16:25 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 26 Apr 83 16:14 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 26 Apr 83 16:04 EDT Via: UCL-CS.AC.UK ; to USC-ISID.ARPA ; Tuesday, April 26, 1983 12:55:58-PDT Date: 26 Apr 83 17:30:06-BST (Tue) From: Steve Kille To: Chris Ryland cc: msggroup@mit-mc.arpa Subject: MSGGROUP#1983 Re: Domain flap The naming scheme may be hopeless for some non-Internet domains. There are others (the UK Academic community being the case I am concerned with) which should fit in fairly naturally. Steve Kille 1-May-83 11:35:02-PDT,842;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 01:16:58-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 26 Apr 83 17:21 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 26 Apr 83 17:10 EDT Received: From Purdue.ARPA by BRL via smtp; 26 Apr 83 17:03 EDT Date: 26 Apr 1983 16:04:09-EST From: Christopher A Kent Reply-to: cak@purdue.arpa To: HEDRICK@rutgers.arpa Cc: MRC@su-score.arpa, cak@purdue.arpa, MsgGroup@brl.arpa, Header-People@mit-mc.arpa, Postel@usc-isif.arpa, nethax%Diablo@su-score.arpa, Bug-MAIL@mit-mc.arpa Subject: MSGGROUP#1984 Re: more on domains In-reply-to: Your message of 25 Apr 1983 1700-EDT.. I'll third the motion that we need something soon. All the confusion is going to give way to inertia for the incompatible hacks. chris 1-May-83 11:35:02-PDT,6683;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 08:47:51-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 0:49 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 0:01 EDT Received: From Usc-Isif.ARPA by BRL via smtp; 26 Apr 83 23:44 EDT Date: 26 Apr 1983 1859-PDT From: MOCKAPETRIS@usc-isif.arpa Subject: MSGGROUP#1985 Domains proposal To: msggroup@brl.arpa Given that everyone agrees that we need a plan for an expanded mail service that includes name service and domain addressing, I propose the following plan and solicit your comments. The basic idea is that we convert in four steps, with four cutover dates; the motivation is to allow mail and name server program development to proceed in parallel. In step 1, we allow subdomains of the form X.NicHost.ARPA, where X can be a multiple component name, but NicHost must be a host in the NIC tables. The host refered to by NicHost must accept and be be able to forward mail for all hosts in its subdomain. In step 2, we add the requirement that if NicHost.ARPA is a domain, that it support name service for that domain. In step 3, we remove the restriction on choice of domains. Instead, we require that every subdomain be registered with all name servers in the parent domain. Name servers for the top level domain will be registered in a master table (at the NIC). All name servers are required to know about their parent name servers, children name servers, and children hosts. The proposed name server strategy is discussed in detail below. In step 4, we assume that all hosts in the Internet implement the step 3 facilities and change status from experimental to production. Prior to this step the default assumption is that domain names are to be avoided when possible so that their impact is minimized. MAIL PROGRAM IMPLICATIONS The plan supposes that mail programs that need to validate domain names or route mail do so through a well defined interface to a local set of name service routines, and that the style of interaction is to present mail op-code and domain name to the service and receive a list of methods in response. For example, if the query is "mail-info for X.ISI.ARPA" the return might be "TCP SMTP forward to address 10.2.0.52, TCP SMTP forward to address 10.2.0.51, TCP SMTP deliver to address 128.8.0.8, UUCP to 213-822-1512". That is, the returned value can be a prioritized list of alternatives. During phase 1, the local name service is a stub that uses the NIC database. For queries of the form NicHost.ARPA it returns a "TCP SMTP deliver to address" response; for queries of the form X.NicHost.ARPA it returns "TCP SMTP forward to address" responses. Note that this type of forwarding has nothing to do with SMTP paths. During phase 2, the local name server can call up the name server at NicHost and present the domain name. If the transaction fails, the assumption is "TCP SMTP forward to address". Local name service can cache results if desired. During phase 3, the local name server will be required to reference remote name servers because domain names may not correspond to host names. Hence, full name service is required. NAME SERVER IMPLICATIONS I believe that a great deal of the argument regarding whether names are routes or names are addresses occurs because the participants are not listening to each other. Jon argues that domain names should be structured according to administrative boundaries, while others say that domain names must be routes. I think that the way out is to agree that domain names parallel administrative structure, but that the lookup procedure allows any domain name to be mapped onto a route. That is, the question you ask your local server is "Given my name (or names) and the destination name, how can I route this mail item". Name server operation follows the succesive refinement model. In order to route a mail item we attempt to get information about the fully qualified host, and we fall back one level of qualification if we fail. We guarantee that we can always get a "forwarder of last resort" from top level name servers. Given a name of the form A.B.C.D, the name server follows the following steps: 1) If A.B.C.D data is cached, return it. 2) If I know a name server for domain B.C.D, ask it about A.B.C.D, and go to step 1. 3) If I know a name server for C.D, ask it about A.B.C.D and go to step 1. 4) I must know a name server for D (its a top level domain after all). Ask it and go to step 1. If I can't get to a particular name server, I can try it's brothers (if it has any). If none respond, I have to give up and try later. A name server can respond with either mail instructions or the name of a closer name server. For example, in step 3, the name server for domain C.D can respond with either the names of B.C.D level name servers or some mail routing instructions, or both types of information. The D level name server could return with the address of B.C.D level name servers, the address of C.D level servers, or mail instructions. Some additional refinements are necessary. Each name server is required to respond with at least one answer that is compatible with the transport used to access the server. For example, a name query delivered via TCP must return either a TCP SMTP forward address, a TCP SMTP delivery address, or a TCP name server address which will eventually lead to a SMTP address. A name server may return incompatible answers as well, but the questioner may ignore this information. We can't require that all name servers be able to access all top level name servers; a low level server may have no transport to it. In this case, the low level server must have in it's permanent tables the address of a forwarder for all top level domains, or the address of a name server for top level domains which will in turn furnish a forwarding address. We should probably assume that all name servers can access its root name server, i.e. F.G.H.Q will have access to a name server at level Q, and that the Q level name server will have forwarding information for all other top level domains. WHAT REMAINS TO BE DONE Refinement of the principles of "last resort routing" Definition of name server transaction formats, and the interactions between name servers (i.e. the recursive and iterative methods mentioned by jon). Definition of the method for distributing the top level name server list Setting the cutover dates ------- 1-May-83 11:35:03-PDT,1828;000000000001 Return-path: <@MIT-MC:cbosgd!mark@ucb-vax> Received: from BRL by USC-ECLC; Wed 27 Apr 83 20:11:28-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 17:06 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 16:58 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 27 Apr 83 16:46 EDT Date: 27 Apr 83 13:12:49-EDT (Wed) From: Mark Horton Subject: MSGGROUP#1986 Re: Domain flap Message-Id: <8304272043.AA24188@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.332/3.21) id AA24188; 27 Apr 83 13:43:52 PDT (Wed) Via: cbosgd.UUCP (V3.94 [3/6/82]); 27-Apr-83 13:12:51-EDT (Wed) To: CPR@mit-xx.arpa, msggroup@mit-mc.arpa Sorry, Chris, but I'm correcting you. (Are you happy?) The UUCP domain wants to change over to internet. (At least, the most vocal of us do.) Nobody really LIKES typing addresses like cbosgd!npois!hou5f!hou5b!hou5c!hou5e!hou5a!hou5d!hogpc!houti!ariel!vax135!floyd!harpo!seismo!hao!cires!nbires!ut-ngp!utastro!alt (the above is a real path I dug out of net.general just now) or having their mail take the scenic tour of New Jersey (yes, I know that's an oxymoron) to get to a destination in Texas. The major problems holding back UUCP from conversion are (1) the Berkeley sendmail program has not yet reached general-consumption status, and (2) the ARPANET refuses to admit that UUCP exists, and thus our internet-style addresses (e.g. alt@utastro.UUCP) are declared illegal. So we still use cbosgd!npois!hou5f!hou5b!hou5c!hou5e!hou5a!hou5d!hogpc!houti!ariel!vax135!floyd!harpo!seismo!hao!cires!nbires!ut-ngp!utastro!alt@Berkeley.ARPA to get mail from the ARPANET. I wish you guys whose programs broke when the conversion was made would get your act together so DCA could acknowledge that we exist! Mark 1-May-83 11:35:03-PDT,4029;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 20:45:43-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 17:07 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 16:58 EDT Received: From Ucb-Vax.ARPA by BRL via smtp; 27 Apr 83 16:46 EDT Date: 27 Apr 83 13:40:43-EDT (Wed) From: Mark Horton Subject: MSGGROUP#1987 Re: Name servers Message-Id: <8304272044.AA24210@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.332/3.21) id AA24210; 27 Apr 83 13:44:58 PDT (Wed) Via: cbosgd.UUCP (V3.94 [3/6/82]); 27-Apr-83 13:40:47-EDT (Wed) To: msggroup@brl.arpa I must have missed a piece of this conversation. I am hearing something to the effect that you insist that every domain have a name server. What I don't understand is why you feel this is necessary. The only explanation I can think of is that you are writing mail programs that like to have the buck passed on them. E.g. when sending mail to, say, joe@Amber.CC.UCB.ARPA, your mailer connects to the ARPA name server and asks who UCB is. It gets the internet address for UCB, connects to the UCB name server, and asks who CC is. It gets the internet address for CC, connects to the CC name server, and asks who Amber is. Then gets the internet address for Amber, connects directly (from the sending ARPANET host) to Amber, and sends the mail. This seems to imply the fundamental assumption that it always is possible (after possibly waiting awhile for some machine or net to come up) to have a direct TCP connection between any two machines that can ever exchange mail. This assumption seems fragile at best and is simply false at worst. Consider, for instance, the world of dialup phone links. Modems with autodialers are becoming common now and more and more people are buying computers with a phone line, which can either dial in our out. In general, if you want to talk to a machine which is (say) 3 hops away from an ARPANET host, and one of those hops involves a machine with only one dialer, and another involves a machine with no dialer, it won't be possible to have a direct link all the way over, even if you can get TCP/IP working over a dialup link. (And don't kid yourselves, I believe that there will be a TCP/IP implementation over dialups, although there will be connectivity restrictions for this reason.) Let's look at two real-world examples. Suppose Berkeley is the gateway to a dialup TCP/IP net (let's call this net DIALNET - it doesn't exist yet but it could in a few years). Berkeley, being a university, does not have much money for phone calls. They do have a dialer on their machine, but use of the dialer is very restricted, and there is no way they will place a long distance phone call because somebody on the ARPANET wants to send mail through Berkeley. Instead, they rely on generous corporate sites (e.g. DEC and Bell Labs) to poll them regularly and pick up any waiting spooled traffic. This kind of delay (e.g. overnight or whenever any incoming traffic happens from the same host) is much longer than an ARPANET host is going to wait for a direct connection. Another real world example is the current UUCP net. Again, Berkeley is the gateway, but this time the protocol is not TCP/IP, it's UUCP. UUCP is a store-and-forward net, it does not allow two processes to talk to each other SMTP style. So mail MUST be forwarded. In summary, I think that there is no need for the requirement that a name server exist for every domain you would ever send mail to. It would never happen anyway. It's not hard for a mailer program to follow the chain as far as it wants, but at some point the name server tells it "the domain you want doesn't run TCP, but you can send mail for it to internet site [x.y.z.w] and it will be forwarded". Then the mailer passes the mail off and lets the other end worry about forwarding the mail. Is this so hard? Mark Horton 1-May-83 11:35:03-PDT,17466;000000000001 Return-path: Received: from BRL by USC-ECLC; Thu 28 Apr 83 00:26:04-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 19:52 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 19:42 EDT Received: From Lbl-Csam.ARPA by BRL via smtp; 27 Apr 83 19:25 EDT Date: 27 Apr 83 16:25:26 PDT (Wed) From: "Mike O'Dell [system]" Subject: MSGGROUP#1988 One man's view of the world (MOBY message) Return-Path: Message-Id: <8304272325.AA10000@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA10000; 27 Apr 83 16:25:26 PDT (Wed) To: MsgGroup@brl.arpa, Header-People@mit-mc.arpa Cc: cak@purdue.arpa, MRC@su-score.arpa, Postel@usc-isif.arpa, mo@lbl-csam.arpa Friends, What follows is an attempt to write down my model of how the SMTP World can/should work. While there are religious issues involved here, I am submitting this to the list as an attempt to provide one whole view of of the problem (limited mightly by my powers of exposition), all in one place. Earlier today I got copies of notes describing different pieces of this model, but I decided that posting this to the list for the purpose of dissection would be valuable. Because of some of these notes presenting similar ideas, some obvious details have been glossed over (probably wrongly). Again, this are just my views (but I know them to be shared by several others), and they are presented soley to promote understanding and interchange. So, with this in mind, here goes... ---------------------------------------------------------------- A Model for Mail Using SMTP Mike O'Dell Lawrence Berkeley Laboratory mo@lbl-csam This note describes one possible model for using the SMTP mail transport protocol to implement a Mail internet whose addressing is based upon the notion of Mail Domains. A basic philosophy for interconnecting mail systems will be described and its ramifications will be discussed. The reader is assumed to be intimately familiar with the RFC82* family of protocol specifications. 1. Assumptions and Definitions Assumption: There exist large collections of hosts which implement SMTP, and further, the hosts provide facilities whereby SMTP implementations can "directly converse" with some, but not necessarily all, peer SMTP implementations. The existance of such communcations facilities plus the connectivity of such mechanisms indues a partitioning on the collections of hosts; these partitions are called Subnetworks, or Subnets. The connectivity is an important because if there is no direct communication between two Subnets there must be an intermediary agent if traffic is to flow between them. Such intermediaries are called Mail Gateways. Example: The ARPA Internet is one such Subnetwork. It is a collection of hosts which implement SMTP, the communication facility is TCP virtual circuits. Moreover, the Subnet is fully connected. By this we mean that any SMTP can directly communicate with any other SMTP, subject to the usual problems of the node being up, etc. An alternate example would be a Subnet where hosts may only talk to some collection of neighbors. Such networks might require explicit address-to-route binding, but this can be accommodated, as we will show later. Assumption: The SMTP mail transport protocol implements a store-and-forward, hop-routed, negative acknowledgment, message switching network. SMTP implementations, henceforth called Nodes, recieve mail from Sources (e.g., mail composers), reliably pass the mail from one node to another, and finally deliver it to a Sink (local mailbox, delivery agent, etc.). Elaboration: The reliable transfer of mail is based on the notion of Responsibility. At any time, there is at generally one Node which is said to Responsible for a piece of mail. When one SMTP node transfers it to another SMTP node, the Responsibility is "tendered" the sending node transfers the message to the recieving node, and Responsibilty is "discharged" when the sending node receives the positive response from the receiving node. Until such a positive response is received, the node "last in possession" of a message is said to be Responsible. Responsibilty implies that a node will continue to provide its best efforts at continued transfer, until such time as its policies decide a message is "undeliverable". When such a determination is made, the Responsible Node is charged with returning a negative acknowledgement to the Source of the message. This is done via the "Return-path:" field accumulated during message transfer. In cases where SMTP nodes communicate over high-delay channels (as with Batch SMTP over UUCP links, or TCP/SMTP over phone lines), there is a window when both sender and reciever node can believe they are Responsible for a message. This can cause a replication of a message if the ACK to the sender is lost, and could cause two negative acknowledgements to be returned in some failure cases. Solution of these problems would require a 3-way handshake be introduced into the model. At this time, this seems like excessive work when most connections are already quite reliable, and those that aren't will be dramatically improved by this scheme. It is, however, a topic to be explored further. While end-to-end reliability of mail service is clearly a desirable goal, until the mandatory institution of "Return-reciept-requested:" and "registered mail", such guarantees are not possible. Therefore, the goal is to insure a high likelyhood that non-delivery will result in a negative acknowledgement being returned to the Source. It is still possible for a message to be lost in-transit because of catastrophic failure of a node, but all nodes must make best-efforts to return error messages (subject to supression of error loops). In practice, within Subnets like the Internet, the likelyhood of undelivered and not-NAKed mail is small because the number of hops is usually one. Assumption: Addresses are provided on the envelope of the message. In the case of messages coming from another SMTP, the envelope information is provided by the messages exchanged in the protocol. In the case of mail submitted for transfer by a local Source, local policy determines whether it is taken from the message itself, or provided out-of-band through argument lists, etc. Upon final delivery, a "return-path:" line is created from the return address information accumulated along the way. This is the only way to guarantee "reply" operations will always work in the face of arbitrary network topology. User agents may with to perform heuristics for optimizing addresses for replys, but the correct inclusion of a "return-path:" line provided a sufficient mechanism by allowing routing back to the Source and then out again. Clearly, optimizations are useful, but we desire a mechanism which is sufficient in all cases. The issue of whether headers in mail are modified en route is religious, but this author's position is that this scheme will work without "header munging", and ought to be done that way. But, there are others who believe otherwise and are free do modify headers en route. The only requirement is that the minimal correct information ("return-path:" and other required fields) be present with it reaches its final destination. 2. The Form of Addresses The addresses in this model are taken from RFC82*, i.e, domain addresses and routed addresses. The formal syntax is given in the appropriate RFC's, but a few examples will insure conceptual alignment. A domain address is of the form leftpart@domain where "leftpart" is a string prohited from containing any unescaped @ characters and whitespace. The "domain" is a sequence of at least two tokens containing no unescaped @ characters or whitespace, separated by periods (.). A few examples of valid domain addresses: mo@lbl-csam.arpa mo@mo-sun.lbl-csam.arpa "Mike O'Dell"@lbl-mail.arpa Routed addresses are of the form [@domain,]@domain:leftpart@domain where [@domain] can be repeated zero or more times, and "domain" and "leftpart" are as above. 3. The Meaning of Addresses Assigning meaning to addresses is one of the most subtle parts of this scenario so an algorithm will be provided describing the elaboration and routing decisions an SMTP node must perform when processing a message. One of the paramount requirements is that the return-path information be generated and propagaged along each hop. Negative acknowledgements cannot be generated if this is not done. We assume the following algorithm is being performed for each destination address on the envelope of the message. This applies equally whether the Source of the message was another SMTP node or a local user agent program. Further, the algorithmn assumes all addresses are syntactically compliant with (2) above. For a routed address, the "first hop" is the leftmost @domain clause of an address, punctuated by an unescaped comma or colon. In the case of normal domain addresses, the @domain excluding the left part is assumed to be the "first hop" (and "only hop"!). We introduce the notion of an "i-right-subclause" of a domain. Remember that a domain is a clause of the form [xxx.]yyy.zzz An "i-right-subclause" is a clause containing the "i" rightmost subclauses. Example: Given: alpha.beta.gamma.lbl-csam.arpa 1-right-subclause: arpa 2-right-subclause: lbl-csam.arpa 3-right-subclause: gamma.lbl-csam.arpa 4-right-subclause: beta.gamma.lbl-csam.arpa The function NumberOfSubclauses() applied to the Example clause returns the integer 5. We now give the Address Elaboration and Routing Algorithm in a pseudo-code resembling C. The pseudo-function relating to name lookups will be described below. Address Elaboration and Routing Algorigthm ------------------------------------------ ImmediateDomain = ExtractFirstHop(address_to_be_resolved); NameServersToUse = KnownNameServers(); i = 1; NofS = NumberOfSubclauses(ImmediateDomain); State = Unresolved; /* sucess or failure indicator */ DestinationToUse = Undefined; /* resolved destination */ while (State == Unresolved) { if (i <= NofS) { CurrentTry = I_Right_Subclause(ImmdiateDomain, i); } else { State = Unresolvable; break; /* out of loop */ } Response = NameLookup(CurrentTry, NameServersToUse); switch (Response.Type) { case UNKNOWN: /* struck out */ State = Unresolvable; break; case DOMAIN: /* * continue resolution with more components * using name servers returned */ i = i + 1; NameServersToUse = Response.NameServers; continue; /* at top of loop */ case HOST: case MAILGATEWAY: /* * got a direct path to either a host * or a gateway */ State = Resolved; AddressToUse = Response.HostAddresses; break; } } /* * Sucess of resolution is now in State * AddressToUse contains host identifiers * to use getting to the first hop */ /* * If we don't know what to do, but know someone who might, * try sending it to him */ if (State == Unresolvable) { if (KnownOracle()) { ForwardNextHop(KnownOracle()); } else { ReturnToSender(); } } else { ForwardNextHop(AddressToUse); /* updates return-path: */ } ------------------------------------------------------ Comments: This algorithm works whether the NameLookUp function is implemented by really pinging a name server, or whether they are really just files on the host. This is important for bootstrapping - not everyone will have nameservers immediately, and the algorithm allows hosts to serve as interim mail gateways with no prearrangement because any host will make best efforts to forward a message without regard to its source. This algorithm can also be improved by caching some information locally (not unlike implementing NameLookUp() with a file), but in no case can the caching, or any other optimization, violate the right-to-left precidence of clauses within the domain being resolved. It is critically important to allow pieces of the domain to be uninterpreted except by mail gateways. If nodes are allowed to evaluate any part of a name they choose, they can usurp gateway policy decisions regarding issues like centralized mailroom facilities. This problem is really one of binding an address to a route. A critical part of this model is that the binding can be done piecewise as with the algorithmn above, or the algorithm can be embellished with "peephole" optimization to remove extraneous routes, etc. All such optimizations can be done with simple-to-formulate RULES for Address Algebra, and not random heuristics. Additionally, the binding scheme relies on a "most-likely-knowledgable oracle". The KnownNameServers() provide an initial list of oracles, with the knowledge sources vectoring toward the final authority. This scheme allows small machines to have degenerate tables which cannot resolve any address, but have a KnownOracle() which can do mail routing for them. The oracle can do whatever Address Algebra it wants to implement an external address policy. One such policy might be to show only "white pages" addresses in external mail, or whether to transform the routed address (resulting from such "hot potato routing") into a pure domain address of the form . There are good reasons for keeping the routed address and transforming to the non-interpreted scheme, so that should be the purview of the local domain, and not a global decision. The important issue is that such policies can be concentrated in the oracle (mail gateways) for the domain and not every little machine on the subnet. This scheme strictly avoids "recursive name servers" whereby one server will query another on behalf of a request. This can cause serious bookeeping problems, and I really think the "redirect" scheme is much cleaner, particularly in the case of networks with high delay. It is clear that this scheme works best if mail gateways for domains provide name service for at least that domain. 4. The Notion of Domains The notion of a domain is central to this model, but is a rather difficult notion to pin down. The word "domain" has already appeared in the above text, so this discussion is assumed to be retroactive. A domain is a recursive mechanism for collecting and containing details about naming. Domains are frequently composed of subdomains (also called domains) to divide the work of providing naming services for a large collection of nodes on a subnet. The reasons for such division can be either administrative or tactical, but generally, domains don't usually span subnets with radically different communication facilities (e.g., BSMTP over UUCP and SMTP over TCP). Additionally, "subnets" are recursive and subdomains don't usually extend across subnets "owned" by different parties. The notion of "ownership" is a ticklish matter, but is generally based in who has responsibility for arbitrating global names. As an example, DCA/ARPA has global naming authority within ARPANET, so the domain is called ARPA, and is a "top level domain", meaning it always appears only as a 1-right-subclause in a domain clause. In the desirable case of multiple top level domains, mail gateways will have to cross-register with each other to allow a host with a .UUCP address to ask its .ARPA name server about who to see to get his .UUCP address resolved. (Again, the name server can certainly be implemented be a file on the host.) 5. Reverse addresses and Replys The problem of generating reverse addresses for replies is tricky. The only scheme which is sufficient, meaning it will *always* work is reverse routing. This means that the address generated for a reply is a routed address of the form reverse-path:forward-address where "reverse-path" is taken from the envelope and "forward-address" is taken from the recipient fields (To:, CC:, etc.). This will result in replies going back to the source host and then being forwarded like the original mail. Clearly this is manifestly inefficient for most traffic, but in the case of general internet relaying, it is the only semantics which will *always* work, short of hosts having complete, or at least *very considerable* knowledge of global network topology and "externalizing" all addresses in the message at each hop (this nasty business is also known as Header Munging). It is possible to describe a set of rules for "optimizing" outgoing address which will reduce the number of hops in a deterministic way and preserves the semantics of the reverse route. Any optimization preformed by a host must preserve the reverse-route semantics. 6. Conclusions "Mail is a lot harder than you think, and astonishingly harder than it looks." 1-May-83 11:35:04-PDT,1704;000000000001 Return-path: <@MIT-MC:TIHOR.CMCL1@nyu> Received: from BRL by USC-ECLC; Thu 28 Apr 83 21:15:25-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 22:22 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 22:15 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 27 Apr 83 22:10 EDT Date: 27 Apr 83 21:20 EST From: Stephen Tihor To: mo@lbl-csam.arpa Subject: MSGGROUP#1989 RE: One man's view of the world (MOBY message) Cc: header-people@mit-mc.arpa, msggroup@mit-mc.arpa Message-ID: <117752466.01350029;1983@CMCL1.NYU.ARPA> In-Reply-To: <8304272325.AA10000@LBL-CSAM.ARPA> ; Message of 27-APR-1983 19:44 from mo@LBL-CSAM (Mike O'Dell [syste Although I can see that reflecting replies off the Sender is the only way to guarentee unambiguous and guarenteed reply routing for messages with relative addresses in them one of the points of Absolute names is that regardless of where on an Internet you are a message containing TIHOR@CMCL1.NYU.ARPA as an address can always be used to send a message to me regardless of when you are since all mail servers must know someone somewhere who can deal with the .ARPA domain and thus can route a reply to me through there. From this I get the impression that you really intend to include the existing UUCP explicit routing as a real method of getting from here to there rather than as a temporary kludge that we can use until the Domain Name/Mail Servers are available. Did I miss something in you message? p.s. Gang: can we limit this discussion to either Header-People or MsgGroup, seeing everything in stereo with several hour delay is beginning to get to me? ------- 1-May-83 11:35:04-PDT,1058;000000000001 Return-path: <@MIT-MC:TIHOR.CMCL1@nyu> Received: from BRL by USC-ECLC; Thu 28 Apr 83 14:27:05-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Apr 83 22:54 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 27 Apr 83 22:49 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 27 Apr 83 22:44 EDT Date: 27 Apr 83 21:28 EST From: Stephen Tihor Subject: MSGGROUP#1990 RE: One man's view of the world (MOBY message) Cc: header-people@mit-mc.arpa, msggroup@mit-mc.arpa Message-ID: <11775F9B4.026D002B;1983@CMCL1.NYU.ARPA> In-Reply-To: <8304272325.AA10000@LBL-CSAM.ARPA>; Message of 27-APR-1983 19:44 from mo@LBL-CSAM (Mike O'Dell [syste Rereading this massive missive again I guess its just that the UUCP routing rules seem to have too solid a place, since one of the main points of Domain addressing is to get away from that. In effect your document describes a different syntax and specific Heuristic for the old mutiple-@ style of routing which domains were supposed to have obsoleted. ------- 1-May-83 11:35:04-PDT,3125;000000000001 Return-path: Received: from BRL by USC-ECLC; Wed 27 Apr 83 07:46:38-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 26 Apr 83 0:19 EDT Received: From Brl.ARPA by BRL-BMD via smtp; 26 Apr 83 0:04 EDT Received: From Purdue.ARPA by BRL via smtp; 25 Apr 83 13:42 EDT Date: 25 Apr 1983 12:34:36-EST From: Christopher A Kent Reply-to: cak@purdue.arpa To: MRC@su-score.arpa Cc: MsgGroup@brl.arpa, Header-People@mit-mc.arpa, Postel@usc-isif.arpa, Hedrick@rutgers.arpa, nethax%Diablo@su-score.arpa, Bug-MAIL@mit-mc.arpa Subject: MSGGROUP#1991 Re: more on domains Personal reaction, no animosity or character assasination intended: Yuck! Bletch! Ugh! Foo! Domains are supposed to do away with exactly this mess. I don't want to have to know that you have four (or fourteen) different kinds of networks inside your domain. I don't want to have to know whether or not there are different naming conventions for each. I think that top-level domains are being used for two purposes, and perhaps this is the root of the problem. They seem to be used to diambiguate different physical networks within a computing environment, and to indicate a funding or administrative grouping of machines. These two purposes seem to be mutually exclusive in many cases. I would propose that something more like be the address that gets to Mark in his example, with the possible modification of dropping the .ARPA qualifier. There's no funny relaying going on, and all I as a user have to understand is how to get to the Stanford domain. Beyond that, it's "invisible". I really don't like the idea of having to know that SU-Tiny is on Pup; I think that should be hanlded by the gateway/nameserver, with protocol translation if so desired, or by having the nameserver return the Internet address of an appropriate relay host. I also feel that it is wrong to think about addresses such as , even within subdomains. The mailer should fully qualify these, even though the user might not have to type the whole string. There should be 0.00% chance of unqualified names leaking out of a subdomain. Should we get Namedroppers@NIC in on this? Along the same lines, there seems to be a recent trend for groups that are bringing up private internets to grab a bunch of class C numbers, rather than one class B number that they manage privately. I think this is wrong. The Internet is cluttered enough with routing packets between gateways; why should the rest of the world know that you have, say, an 10Mb Ethernet, 3Mb Ethernet, Proteon ring, serial line IP, fiber optics, and back-to-back parallel interfaces? I certainly don't care. It should all be invisible to the outside world. Of course, I understand that this is tough until the ICCB gets going and approves a standard way of doing subaddressing; but implementors should be willing to put out a little effort and invent their own, with an eye towards possibly having to do it over later. Comments welcome, as always... Cheers, chris 1-May-83 11:35:04-PDT,948;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 29 Apr 83 00:14:26-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 28 Apr 83 9:01 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 28 Apr 83 8:46 EDT Received: From Parc-Maxc.ARPA by BRL via smtp; 28 Apr 83 8:42 EDT Date: 27 Apr 83 21:07:35 PDT (Wednesday) From: Hamilton.ES@parc-maxc.arpa Subject: MSGGROUP31992 Re: more on domains To: MsgGroup@brl.arpa cc: Hamilton.ES@parc-maxc.arpa Coming from Xerox, I can't help but see all this traffic and think, "what's all the fuss"? We've had around a dozen domains (Grapevine registries) for years. If a msg has ARPAnet recipients, then a mail server sticks all the appropriate "@PARC-MAXC"s into the header, and forwards it to the ArpaGateway registry as well as to all the local addressees. If an incoming msg from the Arpanet has no registry specified, it defaults to .PA. --Bruce 1-May-83 11:35:05-PDT,2227;000000000001 Return-path: <@USC-ISID,@ucl-cs:steve@ucl-cs> Received: from BRL by USC-ECLC; Thu 28 Apr 83 23:00:28-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 28 Apr 83 6:26 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 28 Apr 83 6:16 EDT Received: From Usc-Isid.ARPA by BRL via smtp; 28 Apr 83 6:07 EDT Via: UCL-CS.AC.UK ; to USC-ISID.ARPA ; Thursday, April 28, 1983 03:02:52-PDT Date: 28 Apr 83 10:51:48-BST (Thu) From: Steve Kille To: MOCKAPETRIS@usc-isif.arpa cc: msggroup@brl.arpa Subject: MSGGROUP#1993 Re: Domains proposal Paul, Some thoughts on your proposal. I agree that there is a need for a plan to be made. I am not convinced that a host which can only handle names of the form ISIF.ARPA or ISIF is going to find it easier to handle names of the style XXX.ISIF.ARPA than completely new top level domains. The former are still significantly easier to introduce, but only for the administrative reason of requiring top level domains to be registered in a very controlled way. It seems quite reasonable to be able to operate within the new domain scheme WITHOUT resort to nameservers. This is not to say that I do not feel nameservers are highly desirable and neccessary - they are. I propose the following modification to the scheme (although you may have implied this within step 1) 1) If A.B.C.D data is cached, return it 2) If I know a name server for domain B.C.D, ask it about A.B.C.D and go to step 1. 2a) If I know a relay for domain B.C.D, return it's data. 3) 3a)..... This does not preclude the relay (using SMTP of course!) from indicating that A.B.C.D can be reached directly, and forcing the mail implementation to find this address (by querying Nameservers from the top level downwards if needed). For Internet domains, this model may be too inefficient, although it does not seem unreasonable that an implementation should know when a domain level relay is not going to be allowed. For other internets, with domains registered in the Internet it will probably be more efficient, given Jon's model of limited interconnection (i.e. number of relay points) for such internets. Steve Kille  1-May-83 11:35:05-PDT,4190;000000000001 Return-path: Received: from BRL by USC-ECLC; Fri 29 Apr 83 00:47:42-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 28 Apr 83 13:11 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 28 Apr 83 12:55 EDT Received: From Bbna.ARPA by BRL via smtp; 28 Apr 83 12:37 EDT Date: 28 Apr 1983 1129-EDT Sender: DDEUTSCH@bbna.arpa Subject: MSGGROUP#1994 Re: Name servers From: DDEUTSCH@bbna.arpa To: cbosgd!mark@ucb-vax.arpa Cc: msggroup@brl.arpa, DDeutsch@bbna.arpa Message-ID: <[BBNA]28-Apr-83 11:29:35.DDEUTSCH> In-Reply-To: <8304272044.AA24210@UCBVAX.ARPA> If I understand you correctly, you are concerned about how and when names are resolved into addresses. You point out that some hosts are not always "connected" to the network, and worry about name resolution schemes that require the originating host to connect to the network any more than absolutely necessary. You are concerned that using name servers could require hosts to connect to the network too much. You outline one scenario for how name servers are used. In it, the originating host contacts the server for the "rightmost" naming domain in order to find the server for the rightmost subdomain, then contacts that server, and so on. Finally the originating host gets an internet address for whatever is to the left of the "@", and it sends the message. If a name is in the form foo@d(n).d(n-1). .... .d(1).d(0) then the originating host will have to make n calls to various name servers before the message can be transmitted. That is not the only way that name servers can be used. It is also possible to build a mail system that allows name servers to be accessed by the relaying hosts. In this scenario, mail is transmitted to an intermediate (relay) host. The relay host can consult one or more name servers to further resolve the name, and then it transmits the message to the "next" host for delivery or further relaying. This scenario avoids the problem that you point out. However, the price you pay to avoid the problem is in the complexity of the software and operation of the relaying hosts. (It is at this point that great confusion about naming and routing usually occurs. It is perhaps useful to point out that the name is absolute, and remains the same no matter if the message is routed to go through hosts that have name servers or if the message is routed to go through hosts that can speak to name servers, or if the message is routed directly from any originating host to the host to the left of the "@". Also, there may be other factors in the route taken by a message that have nothing to do with name servers. In fact, a route such as we usually discuss (such as a requirement that a certain gateway be used) is associated with a final address and tells how to get there from whereever the message currently is. That address could have been determined by consulting one or more name servers, but it is best to keep the concept of a potentially highly variable path a message may or may not take as name servers are consulted totally separate from the concept of determining a route from a message's current location to a known final address.) In the most general case, where each domain (and sub-domain, etc.) has a name server, both kinds of name/address resolution are possible. It is possible, I believe, to build a heterogeneous network where both modes are used. This would allow relatively "unconnected" sites to rely upon a smart relay host to take care of name resolution for them, while allowing other hosts to take advantage of the presumably faster and more direct method of name/address resolution and message transmission. Debbie P.S. Each domain still has a name server, but the pattern of who (what?) uses the name server is changed. Also, appropriate replication of name servers can be very useful. Let's remember that naming domains are administrative, and have to do only with assignment of names and associating those names with addresses. They are not necessarily associated with on or more hunks of hardware, copper, optical fiber, or so on. 1-May-83 11:35:05-PDT,856;000000000001 Return-path: <@MIT-MC:CPR@mit-xx> Received: from BRL by USC-ECLC; Fri 29 Apr 83 00:49:08-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 28 Apr 83 13:12 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 28 Apr 83 12:55 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 28 Apr 83 12:38 EDT Date: 28 Apr 1983 1238-EDT From: Chris Ryland Subject: MSGGROUP#1995 Re: Domain flap To: cbosgd!mark@ucb-vax.arpa, msggroup@mit-mc.arpa In-Reply-To: Your message of 27-Apr-83 1312-EDT Mark: I think my missed my point (or I didn't make it well). Domains are a good things--no question--, but they don't magically solve problems in a non- hierarchical environment such as uucp. I'll wager that, after uucp goes "domain" that you'll see addresses like alt.Utexas.NBI.Harvard.BTL.Berkeley.UUCP@UCBVAX. ------- 1-May-83 11:35:05-PDT,4680;000000000001 Return-path: <@MIT-MC:TIHOR.CMCL1@nyu> Received: from BRL by USC-ECLC; Sat 30 Apr 83 06:27:31-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 30 Apr 83 8:44 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 30 Apr 83 8:43 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 30 Apr 83 8:34 EDT Date: 29 Apr 83 10:52 EST From: Stephen Tihor To: mo@lbl-csam.arpa Subject: MSGGROUP#1996 RE: One man's view of the world (MOBY message) Cc: header-people@mit-mc.arpa, msggroup@mit-mc.arpa Message-ID: <1193BAF1E.00DF0022;1983@CMCL1.NYU.ARPA> In-Reply-To: <8304281504.AA19861@LBL-CSAM.ARPA> ; Message of 28-APR-1983 11:06 from mo@LBL-CSAM (Mike O'Dell [syste [Note: I am still getting this from both header people and msggroup and I am afraid that my mail presenter isn't up to unifying messages that arrive days apart (one well after I have deleted the other) yet, even if they have the same message-id. Will the maintainers of these two lists please get their heads together and pick one to carry this discussion on?-SWT] { I think my pooint has been may have been more clearly made by the last few messages so if you understand the source-routing vs. mail-forwarding/gatewaying flap ignore this message. - SWT} No I am not arguing that we need perfect instant SMTP links ... just that since the name server selection algorithm must, in the original design, know where to find a name-server (on a high-reliability direct connect internet route) or a mail-gateway to some Domain in ANY domain string since each SMTP transport program is required to know all the top level domains and how to get to them, then all fully qualified mail can be delivered directly to [or TOWARDS] that gateway if there is no better way and one can be certain that it is going the right way. Thus explicit paths are merely an optimization, or deliberate disoptimization, which you are providing to force mail away from this path. Thus while I can not dispute some of the ideas presented, UUCP-style SMTP routing, except for UUCP-style diagnostic purposes is useful only if your mailer knows the state of the world better than the SMTPs between you and your desired gateway OR if you know of and wish to use a selective gateway. It is not clear to me that this is at all reasonable in the four sets of multinets where I currently see SMTP being of interest: (1) core ARPA Internet. Nearly-instant SMTP, full service name servers -- No Problems. (2) adjacent local networks and their friends. SMTP services may be too slow or have too many steps to efficiently provide rapid name-server service -- however can quickly pass mail for major top level domains up to internet through local gateway, handle local domains locally, and have special cases specially routed directly to special local gateways based on local routing tables. (3) UUCP-land after the Great replacement of /bin/mail and UUCP explicit routing with SMTP and table driven routing algorithms. The major problem I see here is keeping track of low level adjacencies between multiply connected organizational domains: BTL, DEC, Tektronix, HP, Berkeley, etc. This is the piece of the general routing problem that Postel last stamped "UNDER STUDY" for normal IP/TCP gateways. Is the added inefficiency of routing all mail from BTL to DEC through one link (say the cannonical and soon to be defunct harpo--decvax link) worth the simplicity? That is not a real question since as long as you control the mail tables (and within any organization that deserves the term ORGANIZED and is serious about networking mail this is not a problem) you can route mail "optimally" by default simply by putting the right paths in the forward-to for the correct target subdomains. (4) A purely chaotic network such as PCnet. This is a good case in that there are a number of small nodes which probably do not have a logical and direct path to some known mail server. A current problem is developing a reasonable routing method for such nodes. Certainly none of the existing proposals are reasonable enough to suggest using such nodes as a route through to another internet. The strongest current proposal, longitude, lattitude, and phone number is certainly something which a PCnet-mail gateway could handle since it each node currently is a single mailbox system. -- Here there are a number of unresolved issues reflect the lack of an clear underlying model and example of the network. Are these small systems without room for routing tables the sort of machines that are motivating this discussion? ------- 1-May-83 11:35:06-PDT,1204;000000000001 Return-path: <@MIT-MC:cbosgd!mark@ucb-vax> Received: from BRL by USC-ECLC; Sat 30 Apr 83 07:16:39-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 30 Apr 83 9:46 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 30 Apr 83 9:27 EDT Received: From Mit-Mc.ARPA by BRL via smtp; 30 Apr 83 9:26 EDT Date: 29 Apr 83 11:27:51-EDT (Fri) From: Mark Horton Subject: MSGGROUP#1997 Re: Domain flap Message-Id: <8304291745.AA00579@UCBVAX.ARPA> Received: by UCBVAX.ARPA (3.332/3.21) id AA00579; 29 Apr 83 10:45:08 PDT (Fri) Via: cbosgd.UUCP (V3.94 [3/6/82]); 29-Apr-83 11:27:53-EDT (Fri) To: CPR@mit-xx.arpa, msggroup@mit-mc.arpa Domains do not magically solve problems, agreed. That's why we are accumulating a path routing database and have software that figures out how to get mail to some random system. You will never see alt.Utexas.NBI.Harvard.BTL.Berkeley.UUCP@Berkeley.ARPA you will either see btl!harvard!nbi!utexas!alt@Berkeley.ARPA (old style) or alt@utexas.UUCP (new style), using the routing database, or alt%utexas.UUCP@Berkeley.ARPA (kludge style if ARPA won't allow .UUCP as a top level domain). Mark 1-May-83 11:35:06-PDT,8523;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 30 Apr 83 16:29:06-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 30 Apr 83 18:29 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 30 Apr 83 17:43 EDT Received: From ffff6666.ARPA by BRL via smtp; 30 Apr 83 17:30 EDT Date: 30 Apr 1983 16:26:44-CDT From: Marvin Solomon Reply-to: solomon@csnet-sh.arpa To: msggroup@brl.arpa Subject: MSGGROUP#1998 The truth about uucp Ladies and Gentlemen: I've been silently watching the raging debate about mail for some time, and I've finally decided to add my two cents. Since I have two rather different pieces of information to contribute, and since people often ignore messages that are too long, I've broken my contribution into two pieces. In this note I discuss the uucp and CSNET "networks". In the other, I offer some more opinions on the structure of domains. Over the years, I've seen those in the Internet occasionally try to make a point about names, addresses, and routes by citing the structure of uucp. Frequently, these citations show serious misunderstandings. In the interests of improving understanding, I submit a brief description. UUCP Uucp originally stood for "Unix-to-Unix CoPy". Like Arpanet mail, uucp mail was originally a part of a file-transfer facility, but today, the term "uucp" is often used to refer specifically to the mail service. I will follow that usage here. The etymology is also misleading for another reason: uucp (or parts of it) now runs on some non-UNIX systems. Uucp works very much like SMTP. A host establishes a connection to another and they exchange mail files. Each mail file is accompanied by a separate piece of routing information (envelope), which may be either the name of a mailbox or instructions on how to relay the mail. The syntax of a simple mail address is different, but the semantics are the same: the form is "host!local-part", corresponding to the Internet "local-part@host". Like SMTP, uucp allows source routing. The syntax is host1!host2!...!hostn!local-part which corresponds to <@host1,@host2,...:local-part@hostn>. The primary difference between the two worlds is the assumption in the Internet that the source and destination hosts can usually establish a direct connection between them if only they have enough information. The current assumption in the uucp world is that such direct connections are rare and that relaying is the rule. Right now there is little or no facility for automatic relaying in uucp, so the source route must be manually supplied by the sender, or reconstructed from a message for a reply. The ubiquity of source routes--and the fact that they are syntactically included with the mailbox name--has lead many observers to conclude (incorrectly) that uucp uses relative addressing. I would estimate that the uucp "network" contains well over 1000 hosts, but I know of no two with the same eight-character name. I am told that such examples do exist, but they must be extremely rare. Since all mail is currently sent by source-routing, such duplicates cause no problems, provided no host has more than one neighbor with the same name. Nonetheless, I would view duplicate hosts with the same name to be a bug, and I suspect that all such bugs will be fixed as uucp moves towards more centralized coordination. UUCP AND USENET Uucp should not be confused with USENET. USENET is a distributed news dissemination system. A large part of USENET uses uucp, but there are uucp sites that do not run netnews (the program that implements USENET), and there are USENET connections that uses services other than uucp to transfer the news. USENET has a function similar to Arpanet interest groups (such as MsgGroup), but the mechanism is very different. Items are broadcast using a flooding algorithm. When I submit a news item, my host appends a unique identifier composed by concatenating my its host name with a serial number. It then transmits copies of the message to all USENET neighbors. When a host receives a news item, it compares the unique id with the id's of all messages it has received "recently" (usually information about a message is kept around for at least two weeks). If the incoming message is new, it is filed in a public place for users on the local host to read and relayed to all USENET neighbors. Each copy of a news item carries a list of sites it's been through, and (as an added efficiency measure) a host avoids relaying a message to a site it has already been through. This list is kept in the the header of the item in the form "site-n!...!site-2!site-1!submitter", where site-n is the current host and site-1 is the host where the item originated. It is no coincidence that this path has the form of a uucp "address". In fact, the news-reading software on uucp USENET sites has a "reply" command that sends mail back along such a path. The USENET connection graph (neighbor relation) is NOT the same as the uucp graph; the former has many fewer links. In fact, to a reasonable approximation, the USENET graph is a spanning tree of the uucp graph. The result is that a USENET path can get VERY long. Replying along that path is usually a reliable but very inefficient way of getting back to the sender. I offer this explanation primarily to explain why you in Arpa-land sometimes see such long "addresses" coming out of uucp-land. CSNET I feel I can speak rather objectively about Arpanet and uucp, since I am actively involved in maintaining service to both but I have no vested interest in either. I am, however, a CSNET contractor, responsible for implementation of the CSNET "Name Server" (what is often called in Arpanet jargon, a "white-pages" service). Nonetheless, I will try to be objective. In some sense, CSNET is a "meta-network" since it uses the services of three other networks: the DARPA Internet, the X.25 public networks, and something called "PhoneNet". The public network component of CSNET uses TCP/IP, so as far as mail is concerned, it merely extends the Internet (with a capital "I"). PhoneNet is similar to uucp in that the source and destination hosts of a message are seldom able to establish a direct connection, but whereas uucp has a random topology, PhoneNet has a sort of star topology. There are currently two PhoneNet Relays: UDEL-RELAY on the East cost and RAND-RELAY on the West coast. Each Relay is an Arpanet host. Each PhoneNet user host is polled periodically a Relay. The Relay picks up mail and delivers it to the destination by sending it over the Internet (including GTE Telenet), by establishing a phone connection to the destination, or by relaying it though the other Relay. Currently, CSNET addressing is a bit of a kludge. Mail FROM PhoneNet sites is fairly straight-forward. For example, if Tim Curry at the University of Central Florida (UCF-CS) wants to send mail to Mike O'Dell, he addresses it to "mo@LBL-CSAM". His mailer checks a table (derived from the NIC host tables) to verify that LBL-CSAM is an Arpanet site, and queues the mail for the relay. The next time UDEL-RELAY contacts UCF-CS, it picks up the mail and sends it over ARPANET to LBL-CSAM. If Mike O'Dell wants to send mail to Tim, however, he must send it to "tim.UCF-CS@UDEL-RELAY". The "reply-to" in Tim's original message will contain this address, Mike O'Dell will get this address if he consults the CSNET Name Server, and mail to "tim.UCF-CS@RAND-RELAY" will also get there OK, but I still have to admit that this is a kludgy form of source-routing. I'd much rather see this specified as (or <@UDEL-RELAY.ARPA: tim@UCF-CS.CSNET> if source routing is necessary). But I'm beginning to stray into the subject matter of my other message, so I won't explore CSNET addressing any further here. In closing, let me point out that the real problem isn't in uucp addressing or Arpanet addressing, but interoperability between them. Consider the address "hosta!user@hostb". Is that (hosta!user)@hostb (i.e., use Arpanet first) or is it hosta!(user@hostb) (use uucp first)? Hosts sitting on the boundary between the two networks have a real dilemma. At least some people in uucp seem willing to change their syntax. Let's be as helpful as we can. Marvin Solomon University of Wisconsin 1-May-83 11:35:06-PDT,10996;000000000001 Return-path: Received: from BRL by USC-ECLC; Sat 30 Apr 83 17:20:31-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 30 Apr 83 18:29 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 30 Apr 83 17:43 EDT Received: From ffff6666.ARPA by BRL via smtp; 30 Apr 83 17:30 EDT Date: 30 Apr 1983 16:27:31-CDT From: Marvin Solomon Reply-to: solomon@csnet-sh.arpa To: msggroup@brl.arpa Subject: MSGGROUP#1999 What is a domain? I've been watching the mail debate for some time, and I've decided to add my two cents. One cent was sent in a separate message, in which I tried to set the record straight about uucp and its current addressing methods. In this message, I will try to make some sense about domains. I think Mike O'Dell did an excellent job of overviewing the SMTP concept. I strongly urge everyone taking part in this debate to go back and reread his "Moby message" on the subject. It bears more than one reading. One point that I think could use more discussion is the question of what constitutes a domain. It is, as Mike said "a rather difficult notion to pin down". Let me see if I can say anything useful on the subject. 1. Domains and Unique Names Relative naming (in which the name of a node depends on who is referring to it) has many problems. (It is sometimes stated that the uucp network uses relative naming. I argue against that view in my other message.) Therefore, it is generally agreed that every host in the the mail universe should have a unique absolute name. (By "unique" I mean that no two hosts have the same name, not that no two names designate the same host). One way of assigning unique absolute names is to have a "flat" space of names in which conflicts are prevented by a central authority (as in ARPANET) or by a distributed algorithm (as in uucp--in uucp the algorithm is called "peer pressure"). Aside from the obvious procedural problems of keeping the names unique, a flat name space has the severe problem that merging two name spaces that grew up independently is nearly impossible. An alternative is a "hierarchal" name space, as proposed for domains. If all we are concerned with is uniqueness of names, the question of what constitutes a domain is not so hard: A domain corresponds to an authority (let's call it the "domain czar") who is willing to guarantee that no two hosts under its control will have the same name. Each host is put under the control of at least one domain czar. [There's no reason why a host can't be in more than one domain. It will derive a different name from each, but remember I'm not trying to prevent a host from having more than one name.] An absolute unique name for a host can be created simply by concatenating the name assigned by its czar to the name of its domain. The czar does his job either by handing out names directly (a bottom-level domain) or by delegating his responsibility. In the latter case, he need only insure that his subordinates (subdomains) have distinct names. The czar of czars (aka NIC) is no different. 2. Domains and Routing As long as we have a structured name space, why not use the structure to help with routing? It is this idea that introduces all the confusion. Suddenly the boundaries between domains cease to be a purely arbitrary administrative question and get tied up with questions about network boundaries and the extremely sticky question of what constitutes a network. We would like to associate with a domain not only a naming czar, but also an entity (host, program, or table) that can help us get mail to all hosts in the domain. As Mike O'Dell (and others, most recently Paul Mockapetris) have pointed out, the "help" could come in any of (at least) three forms: a "mail relay" that is willing to relay mail to any host in the domain, a "name server" that can supply "information" on how to get mail to hosts in the domain [more on this later], or a "buck-passer" [I can't think of a better name for it] that can respond with the name of another entity that might be of help. 2.1 Mail Relays The domain-relay approach is straightforward but may be too inefficient for very large domains since all mail to any host in the domain would have to go through its relay. Taken to its logical extreme, this approach would have all mail anywhere in the universe be relayed through NIC! (Are you listening, Jake?) Nonetheless, it is quite reasonable for some local domains and in conjunction with the other approaches. 2.2 Name Servers A problem with the name server approach is deciding the form of "information" it should return. In the Internet (with a capital "I"), the information could be simply a 32-bit internet addresses. In fact, I believe I once heard Jon say that ".uucp" can't be a domain because it can't have a name server and that the reason it can't have a name server is that there's no way to assign Internet addresses to uucp hosts. (Sorry if I'm misquoting you Jon.) I think the assumption behind this statement is that the function of a name server is to translate between one kind of address (what I've been calling a "name") and another (the Internet address) and that translation from address to route is done at a different level by a completely separate mechanism (namely IP). I think such a concept of name server is two narrow for at least two reasons. First, it starts at the wrong level. Why would I want to translate from "usc-isif.arpa" to 10.2.0.52? Perhaps because a user sent mail to . Chances are, what the user really wanted to do was send mail to [John whats-his-name, that guy with the long beard who is the Arpanet numbers czar]. I maintain that the string in brackets is the real "name", and that both and 10.2.0.52 are addresses. (Warning: advertisement follows) This is the whole idea behind the CSNET Name Server. The user should be able to "address" his mail by specifying a "name" like the one above, and the system should do the rest. Software to do this has been written and is in the final stages of debugging. See "The Design of the CSNET Name Server" by Solomon, Landweber, and Neuhengen in "Computer Networks" (I forget the date, but it was some time last spring) for more details. The other problem with the domain->Internet-address model of name servers is that it stops at the wrong place. The name server should translate from a name [I'm once more using "name" to mean domain-name] to a route. In the particular case of the Internet, the "route" is one hop (so far as the mail level of the protocol hierarchy is concerned) so it can be specified by a single internet address. In the more general case, the very form of the information may depend on the environment. Once consequence of returning a route is that a query must specify not only a destination name but also a source name. For example, the question "how do I get from lbl-csam.arpa to ucf-cs.csnet" might produce the answer "Via Arpanet using address 10.0.0.96; then via PhoneNet using address @ucf-cs". 2.3 Mail Buck-passers Just as the Mail Relay may forward my message through other Mail Relays rather than directly to its destination, a Name Server may give me a route to another Name Server rather than to the ultimate destination. In a sense, the list of all top level domains is such a buck-passer. Given a domain name, it tells me how to get in touch with a Name Server for that domain. Hopefully, the "route" returned will have one hop, so that I can establish a direct connection to the Name Sever. However, I can imagine cases where the only connection to a remote Name Server is via a multi-hop mail path. I would have to mail off a query to it and wait for it to mail back a response. Such a scenario is not quite as bad as it may sound. The CSNET Name Server software already handles this kind of interaction. However, it does provide a strong incentive for some kind of caching of information. 2.4 Example Suppose I want to send mail from my home machine (a VAX/11-780 called "crystal" on the WISC local network) to a user named "jane" on a host called "c" on a Berknet-based local network at Intermetrics. (I've actually been trying to do this for several months with very little success.) Here's how it would all work in the mail system in the sky: 1. I compose the letter and send it off to "Jane Henderson". 2. A "white pages" program similar to the CSNET Name Server translates the name "Jane Henderson" to the address "jane@c.inmet.uucp". 3. My local mailer consults a table and finds that mail for the uucp domain should be sent over the WISC local network from my host (crystal = 192.5.2.7) to the local host connected to uucp (uwvax = 197.5.2.1). That local table may be thought of a Buck-passer for the root domain (the one with empty name) that responds to the query "crystal.uwisc.arpa -> c.inmet.uucp" with the route "via TCP/IP: 192.5.2.1". 4. The mail is forwarded to uwvax. The SMTP mailer on that host queries the uucp Name Server (remember, this is utopia) about "uwvax.uucp -> c.inmet.uucp" and gets back the path "via uucp: @seismo.uucp,@harpo.uucp,@inmet.uucp". 5. The mail is sent via the uucp path to the inmet Mail Relay, from which it is forwarded via Berknet to the host named "c". 3. Source Routing A lot of recent debate in this group concerns the need for source-routing in the shiny new world of SMTP. I get the feeling that some of the confusion comes from failing to realize that there are not TWO but THREE possibilities: direct connection, automatic routing, and source routing. The situation is exactly analogous to TCP/IP. If the the source and destination are both on Arpanet, a datagram can simply be handed to the local imp with instructions to send it to the destination imp. A still lower-level algorithm figures out what sequence of imps to use. If I want to send the datagram from crystal (192.5.2.7) to lbl-csam (10.1.0.34) I can simply hand it to my local IP module that uses tables to route it through a local gateway (WISC-GATEWAY = 192.5.2.6, 10.0.0.94), or I can use the IP source routing option to send it via a multi-homed host (CSNET-SH= 192.5.2.3, 10.1.0.94). The SMTP world is no different: Ideally, every mailbox in the universe should have a unique name and the system should be able to get mail to it automatically, even if it's not possible to make a direct connection to it. However, for a variety of reasons, may be necessary to override the automatic routing with source routing, especially in the early phases. Mike O'Dell touched on some of them (replies, error-return-to-sender). 1-May-83 18:43:28-PDT,2007;000000000001 Return-path: <@rand-relay:milazzo.rice.Rice@rand-relay> Received: from BRL by USC-ECLC; Sun 1 May 83 18:41:30-PDT Received: From Brl-Bmd.ARPA by BRL via smtp; 1 May 83 19:36 EDT Received: From brl-gateway2.ARPA by BRL-BMD via smtp; 1 May 83 19:33 EDT Received: From Rand-Relay.ARPA by BRL via smtp; 1 May 83 7:34 EDT Date: 1 May 83 04:08:30 CDT From: Paul.Milazzo Return-Path: Subject: MSGGROUP#2000 Re: What is a domain? To: msggroup@brl.arpa Message-Id: <1983.05.01.0408.200.01584@rice> In-Reply-To: Marvin Solomon's message of 30 Apr 1983 16:27:31-CDT Via: Rice; 1 May 83 4:18-PDT In his last message, Marvin Solomon refers, as have many others, to the "UUCP network," and speaks of a hypothetical UUCP Name Server which returns routing information for the "UUCP Domain." Unfortunately, the many UUCP hosts do not form a domain at all, but simply share a transport mechanism. Domain-based addressing relies on the ability to transport mail entirely within the given domain, but there is no guarantee that a UUCP path exists between two arbitrary UUCP hosts. Marvin's UUCP Name Server could certainly return a path which included, for example, the use of the ARPA Internet, and thus his mail routing scheme will still function. Still, why should the name server store paths to sites to which it cannot route mail? Since the hosts using UUCP have been partitioned into several disconnected subnetworks, each such subnetwork would provide its own name server or domain relay, and thus routing to another subnetwork would be referred to the enclosing domain (such as .ARPA). The second subnetwork must, therefore, constitute a separate domain. My point is that I suspect that treating UUCP as a single domain will lead to still greater confusion about the nature and use of domains and name servers. Paul Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX