10-Nov-85 22:13:14-PST,181;000000000000 Date: 1985 November 10 22:32:37 PST From: "MsgGroup Moderator - Einar Stefferud" To: MSGGROUP@BRL.ARPA Subject: Survey of msggroup#2451-2500 Fill in data here11-Nov-85 19:52:38-PST,2729;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Mon 11 Nov 85 19:50:38-PST Received: from usc-isib.arpa by AOS.BRL.ARPA id a016238; 11 Nov 85 22:22 EST Date: 11 Nov 1985 19:20:04 PST From: POSTEL@USC-ISIB.ARPA Subject: re: countries only at the top ? To: msggroup@BRL.ARPA Hi. I have some problems accepting the idea that only countries be top level domains. I think there are many cases of organizations that operate in multiple countries where attaching them to one country or another would cause (political and emotional) problems. For multinational companies (e.g., IBM) one can almost always find a home or base country that it can be associated with (e.g., US). But sometimes there are things where it is not so easy. One example is NATO, another is UNESCO, and what about CCITT or ISO. As a mechanism, the domain name system design does not care about which names are used. A policy has been established and described in RFC-940 that allows three types of top level names. The first type is the explicitly identified 3-letter groupings for education, commercial, government, etc (EDU, COM, GOV, ...). Please note that there is no restriction on the subdomains or hosts in these domains to be in the United States. The second type of top level domain is any 2-letter country code from the ISO-3166 list ("US" is on that list). The third type is a name for a "multi-organization organization" that somehow (not specified) justifies being a top level domain. Please note that for all top level domains a responsible person must register the domain with the NIC and in turn register the subdomains and hosts. There are other requirements on operating a domain, too. The domain system has been accused of being US-centric because other countries have to use their country code at the top, but the people in the US don't. That is not true, people in other countries can register in EDU (or COM, ...). Also people in the US who feel that they should use the country code at the top can register in the US domain. A responsible person has already come forward to supervise it. The domain name system has been accused of being ARPA-centric because "ARPA" is a top level name. I think this might be understandable if it were true. That something created by the ARPA community be ARPA-centric seems likely. But, the accusation is wrong. RFC-940 makes very clear that "ARPA" as a top level name is a temporary measure to support the process of getting from old style non-domain names to the full use of the domain name system. Eventually "ARPA" as a top level name will be phased out. --jon. ------- 11-Nov-85 20:24:41-PST,407;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Mon 11 Nov 85 20:22:43-PST Received: from usc-isib.arpa by AOS.BRL.ARPA id a016317; 11 Nov 85 23:02 EST Date: 11 Nov 1985 19:57:55 PST From: POSTEL@USC-ISIB.ARPA Subject: re: countries only at the top ? To: msggroup@BRL.ARPA oops. references to RFC-940 should be to RFC-920. --jon. ------- 11-Nov-85 20:54:13-PST,1281;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Mon 11 Nov 85 20:52:28-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a016384; 11 Nov 85 23:35 EST Received: by ucbvax.berkeley.edu (5.31/1.2) id AA21493; Mon, 11 Nov 85 20:35:00 PST Received: by ucbarpa (5.31/5.14) id AA20094; Mon, 11 Nov 85 20:34:52 PST Date: Mon, 11 Nov 85 20:34:52 PST From: Jordan Hayes Message-Id: <8511120434.AA20094@ucbarpa> To: msggroup@BRL.ARPA Subject: re: countries only at the top ? From: POSTEL@usc-isib.arpa For multinational companies (e.g., IBM) one can almost always find a home or base country that it can be associated with (e.g., US). But sometimes there are things where it is not so easy. One example is NATO, another is UNESCO, and what about CCITT or ISO. A policy has been established and described in RFC-940 that allows three types of top level names... Note this is a typo ... I think he means rfc920 -- 940 was about subnetting ... This, I think, is the crux of it -- it is the very reason that domains are so powerful, yet so simple. 'tain't nuthin' wrong with big companies being top-level domains. If they meet the requirements then life is good. /jordan 12-Nov-85 07:15:17-PST,1704;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 12 Nov 85 07:11:54-PST Received: from decwrl-gw by AOS.BRL.ARPA id a021112; 12 Nov 85 9:48 EST Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.01/4.7.34) id AA05743; Tue, 12 Nov 85 06:48:32 pst Message-Id: <8511121448.AA05743@decwrl.DEC.COM> Date: 12-Nov-1985 0927 From: John Covert To: msggroup@BRL.ARPA Subject: Political nonsense overrides good system design >A policy has been established and described in >RFC-940 that allows three types of top level names. Did the PTTs authorize the use of RFC-940? >The domain system has been accused of being US-centric because other >countries have to use their country code at the top, but the people in >the US don't. That is not true, people in other countries can >register in EDU (or COM, ...). Unfortunately, a site in Germany can register *only* with the Bundespost; the Bundespost is the *only* organization authorized to carry traffic which crosses a property line boundary, and as soon as public X.400 systems are available, this WILL be enforced and all sites within Germany will have to disconnect from any private networks and use the public network. The Bundespost blocked the connection of hosts to EARN (BITNET) until it was agreed that the connection was temporary and would be replaced by X.400 when available. Multinational organizations have to play by the rules set by the PTTs. These are the political realities. We can say anything we want to on this list, but unless the PTTs are participating, our arguments have no meaning. /john 12-Nov-85 10:02:34-PST,2060;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 12 Nov 85 10:00:08-PST Received: from cmu-cs-a.arpa by AOS.BRL.ARPA id a000343; 12 Nov 85 12:12 EST Date: 12 Nov 85 12:10 EST From: Rudy.Nedved@cmu-cs-a.ARPA To: John Covert Subject: Re: Political nonsense overrides good system design CC: msggroup@BRL.ARPA In-Reply-To: <8511121448.AA05743@decwrl.DEC.COM> Message-Id: <12Nov85.121035.EN0C@A.CS.CMU.EDU> PTTs are not a ruling class. They have poilitical AND economic realities. If they are playing "sit-on-my-hands-and-argue" games then too bad. I saw a network-creation proposal that indicated that a country would do what germany was doing and I wrote and said "why do that...why not get something that works somewhat and run with it?". "You mention the success of EARNET and yet you ignore it....why not just get connections to EARNET and avoid waiting for germany to devlope their three stage PTT included system?". A year later I heard that the country involved connected to EARNET...I believe the high-level, avoid obstacles and get things going thinking people won out over the high-level "what to do about CCITT and the European PTTs" lost. Multinational corporations can hack software as well as anybody. They can use a PTT line for private data comms and deal with the legal suits and fines as well as the corporations in the US deal with city, county and state boundaries. Politics turns just like MCI fought and basically won against ATT over a simple microwave link. In summary, the issue is not "what to do about PTTs in Europe" but how do we maximize the appeal of our solution so that some type of intelligent routing happens to the hosts not in the ARPA Internet. BITNET/EARNET, CSNET, UUCP, EasyNet, VNET and so on will develope and grow with or without PTT involvement. We can experiment, learn, develope and influence systems NOW by making sure we keep a global and future view that uses todays resources. -Rudy 12-Nov-85 14:56:03-PST,4051;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 12 Nov 85 14:55:23-PST Received: from su-ai.arpa by AOS.BRL.ARPA id a007345; 12 Nov 85 17:28 EST X-Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Nov-12 14:25:09 PST (=GMT-8hr) X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP Date: 1985 November 12 14:22:52 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132455235505.G0361 From: Robert Elton Maas To:MsgGroup@BRL.ARPA CC:covert%castor.DEC@DECWRL.ARPA SUBJECT:US and Multinational domains Sender: for undeliverable-mail notifications Reply-to: temporary until nameservers up | Date: Mon, 11 Nov 85 09:57:18 EST | From: "Marvin A. Sirbu, Jr." | Subject: problems with toplevel domains and other proposed domains | As for international organizations, ... You could have a top level | domain called "multinational" ... The problem is who will | administer the domain "Multinational" -- the International Chamber | of Commerce? (For that matter, who will administer the domain USA | when it becomes necessary? the NIC?, the FCC?, ANSI?) For the time being, NIC is probably most competant to administer the US (not USA I am told, it must be official 2-letter country code, sorry I introduced "USA" into this discussion) domain. Later perhaps a more official agency will do it, probably the FCC or FTC if either becomes interested, or maybe the FCC or FTC will contract it out to NIC in the forseeable future. Re multinational domain, probably NIC in the short term and INRIA in the long term? Maybe INRIA will contract it out to NIC or IBM or ITT. | The critical issue, I think, is figuring out who is a reliable, unbiased | organization/person to administer the name registry, and who will | provide the name service (not necessarily the same organization(s)). NIC or FCC or FTC for US, INRIA or CCITT or ISO for Multinational, in charge at toplevel but possibly contracting out actual registration and/or server duties. | Date: 12-Nov-1985 0927 | From: John Covert | Subject: Political nonsense overrides good system design | >The domain system has been accused of being US-centric because other | >countries have to use their country code at the top, but the people in | >the US don't. That is not true, people in other countries can | >register in EDU (or COM, ...). Good point (Author = Postel?? I forget) for EDU, where there's a lot of international cooperation and agreement on accreditation (sp?), although it's very unlikely we'll find some international agency to administer international COM, and MIL is hopelessly US (or at least NATO; When was the last time the Warsaw Pact, Israel, NATO, and Iran could all agree on anything military?) and ought to be MIL.US or MIL.NATO. | Unfortunately, a site in Germany can register *only* with the Bundespost; I wasn't aware of this. I thought a site would have to pass all off-site traffic, even with a single division of a single company, through the Bundespost, but not necessarily register its name with that country since Bundespost doesn't even recognize the domain system in the first place? So long as the international nameserver is accessed via Bundespost, and the nameserver gives a path that goes through Bundespost, I see no German-legal problem? | the Bundespost is the *only* organization authorized to carry traffic | which crosses a property line boundary, and as soon as public X.400 systems | are available, this WILL be enforced and all sites within Germany will have | to disconnect from any private networks and use the public network. The | Bundespost blocked the connection of hosts to EARN (BITNET) until it was | agreed that the connection was temporary and would be replaced by X.400 | when available. Note this deals with physical connection and passing of data, not name registration authority. 12-Nov-85 16:39:01-PST,2648;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 12 Nov 85 16:36:41-PST Received: from css-ring-gw by AOS.BRL.ARPA id a007863; 12 Nov 85 19:12 EST Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Tue, 12 Nov 85 18:57:11 EST Received: by hadron.UUCP (4.12/4.7) id AA02241; Tue, 12 Nov 85 18:54:16 est Date: Tue, 12 Nov 85 18:54:16 est From: "Joseph S. D. Yao" Message-Id: <8511122354.AA02241@hadron.UUCP> To: Rudy.Nedved@CMU-CS-A.ARPA, castor.DEC!covert@DECWRL.ARPA Subject: Re: Political nonsense overrides good system design Cc: msggroup@BRL.ARPA > ... "why do that...why not > get something that works somewhat and run with it?" ... The problem with this kind of thinking is that it leads to incomplete interim solutions that are then embraced as the final solution. Look at the IBM PC and clones. This especially becomes a problem when one is faced with the problem of converting running systems from one type of system to another. Look at the trouble with domains! If it turned out that X.400 (or some other standard) was the best thing for Germany and the PTT's, then the best thing they could have done was not allow connection via a BITNET until they were assured that the connection would later become standardised. (I don't know whether or not it is the best thing: flamers PLEASE note the IF ... THEN.) By the way, I do hate political nonsense getting in the way of good system design. My point is, that there are many valid non-technical issues in system design. Even just from a technical point of view, grabbing the first solution to make it to the shelf is usually about the worst way to decide on a solution. > In summary, the issue is not "what to do about PTTs in Europe" but > how do we maximize the appeal of our solution so that some type of > intelligent routing happens to the hosts not in the ARPA Internet. Actually, I'd say there are a lot more questions. One is, is what is good for US good for everybody? (Pun intended.) Second is, IS our solution the best? Third is, is our solution the only way to perform intelligent routing inter-net between Internet and non- Internet hosts? THEN we can ask the question above. > ... We can experiment, learn, > develope and influence systems NOW by making sure we keep a global > and future view that uses todays resources. Amen. (except for spelling & grammar ... ;-) ) Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 13-Nov-85 05:28:28-PST,873;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Wed 13 Nov 85 05:25:09-PST Received: from brl-tgr.arpa by AOS.BRL.ARPA id a010803; 13 Nov 85 8:02 EST Date: Wed, 13 Nov 85 7:57:47 EST From: Stephen Wolff To: "Joseph S. D. Yao" cc: Rudy.Nedved@CMU-CS-A.ARPA, castor.DEC!covert@DECWRL.ARPA, msggroup@BRL.ARPA Subject: Re: Political nonsense overrides good system design >> ... "why do that...why not >> get something that works somewhat and run with it?" ... > The problem with this kind of thinking is that it leads to incomplete > interim solutions that are then embraced as the final solution.... `The best is the enemy of the good' -- Voltaire -s (Aphorisms for any occasion) 13-Nov-85 21:45:25-PST,1621;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Wed 13 Nov 85 21:43:21-PST Received: from css-ring-gw by AOS.BRL.ARPA id a008271; 14 Nov 85 0:18 EST Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Thu, 14 Nov 85 00:13:51 EST Received: by hadron.UUCP (4.12/4.7) id AA05721; Thu, 14 Nov 85 00:10:40 est Date: Thu, 14 Nov 85 00:10:40 est From: "Joseph S. D. Yao" Message-Id: <8511140510.AA05721@hadron.UUCP> To: steve@BRL.ARPA Subject: Re: Political nonsense overrides good system design Cc: Rudy.Nedved@CMU-CS-A.ARPA, castor.DEC!covert@DECWRL.ARPA, msggroup@BRL.ARPA > >> ... "why do that...why not > >> get something that works somewhat and run with it?" ... > > The problem with this kind of thinking is that it leads to incomplete > > interim solutions that are then embraced as the final solution.... > `The best is the enemy of the good' -- Voltaire Granted. A more balanced statement of the point is that one should neither grab at the first solution, nor wait for the "ultimate solution" (which, yes, never comes); but should try to rationally plan for a reasonably good intermediate solution. Of course, that means reading the future ... Remember, if we just grab for the first thing off the shelf, we're not even sure that it's good, much less best. With domains, we think they're at least good ... but judging from the arguments, not everyone is even sure of that. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 14-Nov-85 14:14:29-PST,2511;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Thu 14 Nov 85 14:13:45-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 14 Nov 85 11:43:35-PST Date: 14 Nov 1985 11:39:22 PST Subject: RFCs 952, 953, 954 Now Available From: Ann Westine To: Request-For-Comments-List: ; New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 952: Title: DoD Internet Host Table Specification Author: K. Harrenstien, M. Stahl, E. Feinler Mailbox: NIC@SRI-NIC.ARPA Pages : 6 pathname: RFC952.TXT This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up-to-date. Distribution of this memo is unlimited. RFC 953: Title: Hostname Server Author: K. Harrenstien, M. Stahl, E. Feinler Mailbox: NIC@SRI-NIC.ARPA Pages : 4 pathname: RFC953.TXT This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up-to-date. Distribution of this memo is unlimited. RFC 954: Title: NICNAME/WHOIS Author: K. Harrenstien, M. Stahl, E. Feinler Mailbox: NIC@SRI-NIC.ARPA Pages : 4 pathname: RFC954.TXT This RFC is the official specification of the NICNAME/WHOIS Protocol. This memo describes the protocol and the service. This edition of the specification includes minor revisions to RFC-812 which brings it up-to-date. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 14-Nov-85 17:36:06-PST,1531;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Thu 14 Nov 85 17:34:41-PST Received: from css-ring-gw by AOS.BRL.ARPA id a025929; 14 Nov 85 20:01 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 14 Nov 85 19:37:37 EST Received: by mcvax.UUCP; Thu, 14 Nov 85 23:04:40 +0100 (MET) Received: from SERING.UUCP (sering) by mcvax.UUCP; Thu, 14 Nov 85 23:04:27 +0100 (MET) Message-Id: <8511142204.AA06758@mcvax.UUCP> Date: Thu, 14 Nov 85 23:06:09 MET From: Doug Kingston To: Vshank@weizmann.bitnet Cc: arpa-mhs@BRL.ARPA, msggroup@BRL.ARPA Subject: Domains (US vs EDU/COM/MIL/...) It is my feeling that the US entities I deal with would be better off in the long run if their domains were under a "US" domain. For example, "HQ.AMC.MIL.US" or perhaps "HQ.AMC.ARMY.US" makes more sense to me than the top level MIL domain given we have now. It may not be self centered, but it certainly comes off that way regardless of what we feel as Americans (Sorry Jon). This is particularly true given the expectation I have for communications between our organizations and others. I believe it also responsible to have a multinational top level domain, but the majority of people do not fall in this catagory. I suspect the decision to go MIL/EDU/COM/... will cost us a lot of unnecessary effort down the road as we integrate into other mail systems. -Doug- (CWI, Amsterdam and U.S.Army/BRL) 14-Nov-85 18:25:42-PST,711;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Thu 14 Nov 85 18:21:26-PST Received: from usc-isib.arpa by AOS.BRL.ARPA id a026082; 14 Nov 85 20:57 EST Date: 14 Nov 1985 17:54:13 PST From: POSTEL@USC-ISIB.ARPA Subject: domains To: msggroup@BRL.ARPA What second level domains are being talked about in other countries? If countries makes sense at the top level for the world, does states make sense for the second level in the US? If we are going to divide up the world based on political gepography at one level, why not keep going to the next (and the next, ...) level. Why not "Postel@B.ISI.Marina-del-Rey.CA.US" ? --jon. ------- 15-Nov-85 01:44:05-PST,2823;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Fri 15 Nov 85 01:39:06-PST Received: from ucl-cs.arpa by AOS.BRL.ARPA id a028269; 15 Nov 85 4:10 EST To: Doug Kingston , postel@f.USC-ISI.ARPA cc: arpa-mhs@BRL.ARPA, msggroup@BRL.ARPA Subject: Re: Domains (US vs EDU/COM/MIL/...) Phone: +44-1-387-7050 ext 226 In-reply-to: Your message of Thu, 14 Nov 85 23:06:09 MET. <8511142204.AA06758@mcvax.UUCP> Date: 15 Nov 85 09:05:05 GMT (Fri) Message-ID: <1360.500893505@UCL-CS.AC.UK> From: Steve Kille Commenting on two messages: Doug, It is wonderful to see that you are acquiring a European perspective! This is just to note that I feel it really is worth reconsidering the DARPA top level domains. Having countries (and possibly plus selected international organisations as is being propsed in the CCITT DS work) at the top levels will save a lot of agony in the meidum/long run. Like the UK Domain ordering, I had written it off as an "unfortunate choice" which we can live with. But.... However, in one respect, I strongly agree with Jon. The main function of the (non MILNET) part of the Internet is to do research. The interesting thing is to investigate the usage of a distributed nameserver scheme. Eternal arguments about what everyone is called is a waste of effort. It has already filled far more network bandwidth than any of the design discussions. Jon, The only country subdivision I know of in mail context is the UK (Academic Community) one. This is excepting the X.400 Management Domain splits, which really are not in the spirit of domains (or CCITT User Friendly Names). Our choice, like the CCITT DS business context one (which was made after our choice) was countries at the TOP level only, and then organisational underneath. We slid a thin second layer in, so that we were managing a namespace we has a full control of. The AC domain (Academic COmmunity) might more formally be considered to correspond the DES (The Department of Education and Science). It is analaogous to EDU. We have also added, in view of the Academic Community Rainbow Books being used in other places, the second levels: MOD (Ministry of Defence) (== MIL) ad CO (Commercial) (==COM). There is also Alvey.UK, which we couldn't think of anywhere else to put (preferring to fill the second level rather than make a catch all OTHER domain). This domain scheme will also cover the UK UUCP network, and UK Mailnet and Bitnet/EARN sites. As an aside, it would have been administratively unworkable to register all of these things under your .EDU/.MIL/.COM/.ORG setup. Neither UK Universities/Organisations nor the NIC could cope. Steve 15-Nov-85 05:23:10-PST,4530;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Fri 15 Nov 85 05:20:33-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a029666; 15 Nov 85 7:59 EST Received: by ucbvax.berkeley.edu (5.31/1.2) id AA15801; Fri, 15 Nov 85 04:54:36 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA29422; Fri, 15 Nov 85 04:57:32 pst Message-Id: <8511151257.AA29422@ucbjade.Berkeley.Edu> Date: 15 November 85 07:56 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: .EDU problems in Bitnet To: MSGGROUP@BRL.ARPA Originally sent from: SY.KEN@CU20B Originally sent to: RMXJ@CORNELLA Received: from CUVMA(MAILER) by CORNELLA (Mailer X1.21) id 0621; Thu, 14 Nov 85 01:44:38 EST Received: from CCNET(MAILER) by CUVMA (Mailer X1.21) id 5691; Thu, 14 Nov 85 01:34:09 EST Date: Thu 14 Nov 85 01:19:23-EST From: Ken Rossman Subject: Re: .EDU problems in Bitnet To: RMXJ@CORNELLA In-Reply-To: Message from "RMXJ@CORNELLA" of Wed 13 Nov 85 12:19:00-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12159094217.31.SY.KEN@CU20B.COLUMBIA.EDU> What some of the folks arguing against our new naming convention fail to realize is that the domain style name has nothing specifically to do with: a) Specific networks. b) TCP/IP or ARPAnet. Specific networks in domain names: The network name does not necessarily need to be somewhere within the name, and in most cases, isn't. Many hosts are also on several networks, for example (like CU20B or COLUMBIA), so how could it make sense to stick a network name somewhere in the domain name for the host? This would have to mean that such hosts would have to have different names for different networks, while the domain naming concept was created for exactly the opposite reason -- so that every host, no matter what network or networks it was on, could have ONE name which described it (the name should describe the administrative domain within which it resides, not (necessarily) the network domain). Network protocols: Here again, even though early on, domain names had .ARPA tacked onto them, they no longer will have them. The highest level domains are names like EDU (the research/educational segment of the Internet), MIL (the military segment), and COM (commercial). So even though we use domain style names for both our Internet and non Internet systems, it shouldn't matter, and the NIC host tables (which are disappearing sometime soon anyway!) don't need to know about some of these (and shouldn't). So, once the smoke clears, the name is neither related to the protocol nor the network, and the answer as to how one picks the return network path does not lie in parsing the name. Apparently, until recently, many BITnet sites would assume that if a domain style name was used, it should go back through the Wisconsin Internet gateway, and of course, this worked for most cases up to now. Since the face of networks and network names is changing rapidly now (and NOT just here at CU either!), BITnet folks are just going to have to figure a different way out of the dilemma. The recoommended way to do this, of course, is through the use of a name server. However, since these don't exist widely yet, the next best thing I can think of is to stick aliases into your host tables, with the older short-form BITnet host names as the official names. These should still work in the reverse direction, since they are still used as aliases on this side. As for being reluctant to send mail from here to BITnet with alternate names in the mail headers, this would mean major hacks to our mail system software, which naturally I am rather reluctant to do (not even having enough time to do the other things I should already be doing here). Also, folks on BITnet might as well get used to having to deal with the domain style names, as more and more hosts are using them, and they are becoming the standard on more than a few networks. Additionally, it is a bad idea to change the contents of mail headers or text while in transit through, say, a DECnet-BITnet gateway. Remember, we didn't cook up the concept of the domain name -- the folks writing the RFC's did. As far as I can tell, we're going by the rules. Please feel free to redistribute this to other interested parties, and I welcome further debate on the matter. /Ken ------- 15-Nov-85 06:13:45-PST,1193;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Fri 15 Nov 85 06:12:26-PST Received: from css-ring-gw by AOS.BRL.ARPA id a001103; 15 Nov 85 8:36 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Fri, 15 Nov 85 08:19:54 EST Received: by mcvax.UUCP; Fri, 15 Nov 85 13:37:50 +0100 (MET) Received: from SERING.UUCP (sering) by mcvax.UUCP; Fri, 15 Nov 85 13:37:28 +0100 (MET) Message-Id: <8511151237.AA09533@mcvax.UUCP> Date: Fri, 15 Nov 85 13:38:55 MET From: Doug Kingston To: Steve Kille Cc: Doug Kingston , BRL.ARPA!postel@f.USC-ISI.ARPA, arpa-mhs@BRL.ARPA, msggroup@BRL.ARPA Subject: Re: Domains (US vs EDU/COM/MIL/...) I would expect that in the not too distant future there will be a number of new country based domains used for mail. The European UUCP community (EUNET) is headed strongly in that direction. They are much better organized and coordinated than their US counterparts. I would expect that mcvax.cwi.nl to be a valid address within 6 months at the outside. -Doug- 15-Nov-85 09:18:28-PST,665;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Fri 15 Nov 85 09:15:08-PST Received: from wiscvm.arpa by AOS.BRL.ARPA id a006207; 15 Nov 85 11:43 EST Received: from (MAILER)CUNYVM.BITNET by WISCVM.ARPA on 11/15/85 at 10:40:41 CST Return-path: TIGQC356%CUNYVM.BITNET@WISCVM.ARPA Received: by CUNYVM (Mailer X1.21) id 2619; Fri, 15 Nov 85 11:29:44 EDT Date: Fri, 15 Nov 85 11:27 EDT From: "Mark F. Rand" Subject: _ To: Newsletter Please take me off of your mailing list... Acknowledge-To: Mark F. Rand 15-Nov-85 12:50:45-PST,1640;000000000000 Return-Path: <@ECLA:POSTEL@USC-ISIB> Received: from ECLA by ECLC with DECnet; Fri 15 Nov 85 12:50:38-PST Received: from USC-ISIB.ARPA by USC-ECL.ARPA; Fri 15 Nov 85 12:48:15-PST Date: 15 Nov 1985 12:43:15 PST From: POSTEL@USC-ISIB.ARPA Subject: re: domains To: MSGGROUP@USC-ECL.ARPA Just who in the UK, France, Germany, etc, is going to be in charge of deciding what is and what is not allowed as a second level domain? For the domain naming system (the one now in use in the Internet) it is generally the first person that asks for the job (and is somehow considered a "responsible person"). For the ISO/CCITT system now being designed it will probably be some bureaucrat that does not really want to do it, but is assigned the job by the government run PTT. For example, the current responsible person for the UK domain is Andrew McDowell of University College London. I'd suggest that the reason the UK domain has a AC (for academic community) subdomain is that the only people who even know about this scheme in the UK are in the academic community. It could be that if someone in the British Post Office gets to decide what subdomains are allowed they will be the postal codes (e.g., WC1E 6BT). A mail box might be steve@CS.UCL.WC1E-6BT.UK One important point is that the current Internet domain system is being built and operated by the people that use it right now, and that the people who decide what domains to use are the people doing the work. In the ISO/CCITT scheme, a lot of those decision are going to be made by politicians and bureaucrats. --jon. ------- 16-Nov-85 00:47:04-PST,2567;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Sat 16 Nov 85 00:44:50-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 15 Nov 85 22:24:02-PST Date: 15 Nov 1985 22:21:15 PST Subject: RFCs 963 and 964 Now Available From: To: Request-For-Comments-List: ; New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 963: Title: Some Problems with the Specification of the Military Standard Internet Protocol Author: Deepinder P. Sidhu Mailbox: sidhu%isucs1@CSNET-RELAY.ARPA Pages: 19 Characters: 45102 pathname: RFC963.TXT The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems. Distribution of this note is unlimited. RFC 964: Title: Some Problems with the Specification of the Military Standard Transmission Control Protocol Author: Deepinder P. Sidhu & Thomas P. Blumer Mailbox: sidhu%isucs1@CSNET-RELAY.ARPA Pages: 10 Characters: 21542 pathname: RFC964.TXT The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems. Distribution of this note is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 16-Nov-85 08:55:05-PST,1989;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 16 Nov 85 08:53:56-PST Received: from css-ring-gw by AOS.BRL.ARPA id a017412; 16 Nov 85 11:35 EST Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Sat, 16 Nov 85 11:18:56 EST Received: by hadron.UUCP (4.12/4.7) id AA12941; Sat, 16 Nov 85 11:15:56 est Date: Sat, 16 Nov 85 11:15:56 est From: "Joseph S. D. Yao" Message-Id: <8511161615.AA12941@hadron.UUCP> To: POSTEL@USC-ISIB.ARPA, mcvax!dpk@seismo.ARPA, msggroup@BRL.ARPA Subject: Re: domains You know, Doug's right. You know, Jon's also right. What makes sense, I guess, is to have organisations that are clearly US-specific, like the US GOV or MIL, be required to be .GOV.US or .MIL.US (maybe .ARMY.MIL.US, but I don't think so). Then we can have HQ.AMC.MIL.US, and HQ.AMC.MIL.NL, or whatever. Those other groups that wish to identify themselves as US-specific could follow suit, as TIME.COM.US vs TIME.COM.CA(nada, not lifornia). Those that wished to be thought of as multi-national or supra-national could drop the country loyalty entirely, like IBM.COM or ATT.COM. Oh, you say .ATT is a top-level domain now? ;-) Many educational institutions might want to identify themselves more strongly with the state or country than the top level. For instance (not saying they w o u l d), UMASS.EDU.GOV.MA.US. After all, that's where much of their money comes from. And isn't this naming supposed to be independent of routing etc.? Anyway, those institutions that want to be named primarily for their top-level affiliation could still call themselves, e.g., HARVARD.EDU, MIT.EDU, or B.ISI.USC.EDU (did I remember your affiliation correctly?). Unnecessary disclaimer, since we're all intelligent thinking people: these are only my opinions, my-only opinions, and my opinions only. Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 16-Nov-85 09:43:29-PST,1726;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 16 Nov 85 09:43:04-PST Received: from im4u.arpa by AOS.BRL.ARPA id a017580; 16 Nov 85 12:23 EST Posted-Date: Sat, 16 Nov 85 11:18:50 cst Received: from pop.UTEXAS.EDU by im4u (4.22/4.22) id AA24705; Sat, 16 Nov 85 11:19:33 cst Date: Sat, 16 Nov 85 11:18:50 cst From: Smoot Carl-Mitchell Message-Id: <8511161718.AA18672@pop.UTEXAS.EDU> Received: by pop.UTEXAS.EDU (2.0/4.22) id AA18672; Sat, 16 Nov 85 11:18:50 cst To: msggroup@BRL.ARPA Subject: Re: domains I guess I'll throw my two cents worth in on this discussion. I believe the disagreements about what a top level domain should be are not going to be resolved easily. From my own point of view I think it is not worth discussing to any great length because it really gets down to a question of what is the best way to logically divide up the namespace. Of course, the answer to that is there is no one best way to do it and reasonable people are going to disagree. A division along geopolitical boundaries is just as arbitrary as the currently proposed divisions. By way of example, we might want a UN (United Nations) top level domain which in fact crosses political boundaries. The same could be said for the world wide weather community which is in constant communication. I would also point out that the domain naming system is not necessarily a strict hierarchy, but rather a directed graph. Hosts and users can be in more than one domain. In a limited way this is already done with mailing lists. How about a msggroup top-level domain? Makes just as much sense as the currently proposed divisions. 16-Nov-85 12:18:55-PST,1286;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 16 Nov 85 12:17:38-PST Received: from isi-uci-gw by AOS.BRL.ARPA id a018077; 16 Nov 85 14:43 EST Received: from localhost by UCI.EDU id a001668; 16 Nov 85 11:35 PST From: Einar Stefferud - MsgGroup Moderator To: msggroup@BRL.ARPA Cc: msggroup-request@BRL.ARPA Subject: MsgGroup-Request@BRL - Administrivia Reminder Reply-to: msggroup-request@BRL.ARPA Date: 16 Nov 85 11:34:05 PST (Sat) Message-ID: <227.501017645@uci.edu> Sender: stef@uci-icsa.ARPA This is a reminder to you all that adiministriva mail regarding msggroup should be addressed to msggroup-request@brl.arpa to avoid bothering our 500 or so subscribers with needless mail. It is a general custom for groups to X-request@host" address arrangements for any list "X@host". Please pass this idea along when you recommend our list to others. We can tolerate newcomers who send requests to be added the the full list, but it is not easy to tolerate current subscribers who bother the whole list with removal requests (unless you think it is appropriate to say farewell to all 500 of us). Thanks for your attention to this bit of ettiquette. -- Stef 16-Nov-85 14:15:01-PST,4344;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 16 Nov 85 14:14:21-PST Received: from isi-uci-gw by AOS.BRL.ARPA id a018537; 16 Nov 85 16:47 EST Received: from localhost by UCI.EDU id a002653; 16 Nov 85 13:42 PST To: msggroup@BRL.ARPA Cc: stef@uci-icsa.ARPA Subject: Domains Summary Attempt Date: 16 Nov 85 13:42:18 PST (Sat) Message-ID: <227.501025338@uci.edu> From: Einar Stefferud "We have met the Enemy, and it is Us" ... According to Pogo. This is an attempt by your moderator to summarize and possibly provide a consensus for this discussion. First, some premises: 1. The RFC920 Domain System is entirely neutral to any and all technically correct arrangements of the names and addesses contained in any instantiation thereof. 2. SRI-NIC, acting as the Administrator for the Top-Level Domain, is technically neutral about registrants and the policies they use under their domains of authority and responsibility, as long as the names admitted therein do not violate the technical rules, such as "only use A-Z a-z 0-9 or `-' (dash) in domain/host names", etc. If a given Domain Administration wishes to confine itself to names that conform to names in some other name-space, this is fine if those names do not violate the rules for RFC920 host/domain names. 3. The SRI-NIC Registration Rules require that a Domain Administration Registrant agree to arrange for proper name service to the rest of the Internet for all the subdomains and hosts in/below the registered domain. (If there are other rules, I hope that SRI-NIC will enumerate them all for us here.) By derivation from these premises, all comments about how the U.S. Army or the Netherlands Army should register themselves with SRI-NIC should be directed to the Commander, U.S. Army and Commander, Netherlands Army. It should be obvious to us all that given a mechanism (Domain System) that cannot automatically enforce any kind of rules about patriotism or good taste on the registrants, that the registrants are free to choose good names or bad names, and to exhibit their tastes and judgement about names, both good and bad. Mediocrity is one more option. So, we who must look at the fruits of these good or bad choices are free to criticize them, but I do think we should direct our comments to the correct places to maximize our influence on the real decision makers (The Registrants) to obtain the kinds of choices we prefer. If we choose not to complain to the right places, I suggest that we stop complaining here. Choosing which domain to register one's hosts/domains in is a decision that all domain adinistrators must make for themselves. I have a few retorical questions. We don't want all the answers to appear in MsgGroup! To Doug Kingston: Who registered BRL in .ARPA? Why don't you ask BRL reregister as BRL.MIL.US? To everyone else: Who registered you to be what you are? Who can reregister you to be what you want to be? Why don't you request reregistration? at least, lets stop beating on Jon and SRI-NIC. Instead, lets look at what we have done to ourselves, and discuss what we might separately and jointly do about it. I am not advocating reregistration of every domain and host, but I do advocate careful rethinking of the choices that have been made so far, and careful thought about new choices to be made. Methinks that mostly, some education is needed for some administrators, including ourselves. We don't need blame. We need understanding. Best - Stef =========== BTW -- Here is the result of asking SRI-NIC about the .US domain. $ whois us-dom Connecting to server on sri-nic.arpa for "us-dom"... open. US Domain (US-DOM) Domain Name: US Servers: USC-ISIF SRI-NIC Administrative Contact: Postel, Jon (JBP) POSTEL@USC-ISIB (213) 822-1511 ext 167 Technical Contact: Postel, Jon (JBP) POSTEL@USC-ISIB (213) 822-1511 ext 167 Zone Contact: Postel, Jon (JBP) POSTEL@USC-ISIB (213) 822-1511 ext 167 anticipated number of hosts: init. - 10, one yr - 200 two yr - 500 five yr - 5000 16-Nov-85 15:14:08-PST,2005;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 16 Nov 85 15:13:09-PST Received: from usc-isib.arpa by AOS.BRL.ARPA id a018736; 16 Nov 85 17:35 EST Date: 16 Nov 1985 14:30:08 PST From: POSTEL@USC-ISIB.ARPA Subject: re: domains To: msggroup@BRL.ARPA My suggestion about using political geography for further subdivision of domains is not entirely a joke. Please consider it seriously. The domain names system was not conceived with (and does not now have) as a goal converting the whole world to use it. The domain names system is intended to be used in the limited community of the DARPA Internet and with any other communities that choose to join in. The key goal is to allow a useful running system to keep growing. The DARPA world of networking has used a central host table since the begining. This worked pretty well when the number of hosts was small, and less and less well as the number of hosts grew. I'd guess the reasonable size of system for using host tables is up to 500 hosts. We are now completeing the switch over to the domain name system which includes the use of distributed name servers. We think this system will work for a much larger system, say up to 100,000 hosts. I would not care to speculate if the current design will work for systems larger than that. An important factor in making the system work is the tradeoff between the branching factor at each level and the number of levels. At each node of the tree one has to keep a list of the subnodes. One wants to keep that list to a reasonable size (say, less than 500?). The design of the domain name system is much simpler and the its goals are much more limited than the design and goals of the X.400/MHS naming and directory assistance system. The time scale for implementation and service use is also different. The Internet community needs the domain name system now and is using it now. --jon. ------- 17-Nov-85 13:03:43-PST,1473;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 13:01:18-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021437; 17 Nov 85 15:43 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA11633; Sun, 17 Nov 85 12:37:41 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA01504; Sun, 17 Nov 85 12:40:57 pst Message-Id: <8511172040.AA01504@ucbjade.Berkeley.Edu> Date: 17 November 85 12:57 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: (copy) Re: domain names To: MSGGROUP@BRL.ARPA Originally sent from: PEB@CERNVM Originally sent to: RMXJ@CORNELLA Received: from CERNVM(MAILER) by CORNELLA (Mailer X1.21) id 1642; Thu, 14 Nov 85 06:26:15 EST Received: by CERNVM (Mailer X1.21) id 4179; Thu, 14 Nov 85 12:23:58 GVA Date: Thu, 14 Nov 1985 11:39 GVA From: Paul Bryant Subject: Re: (copy) Re: domain names To: In-Reply-To: Your message of 12 November 85 17:52 EST On behalf of the UK I can state that there is no intention to continue the use of Grey Book any longer than it takes to get adiquate X400 services to take its place. This is line with the other European countries who express similar statements at the Luxembourg meeting and susequently and it is also in line with the EARN policy to use X400 as soon as possible. (please forward- how do I reply directly?) 17-Nov-85 15:23:37-PST,1983;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 15:23:15-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021443; 17 Nov 85 15:43 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA11637; Sun, 17 Nov 85 12:38:00 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA01516; Sun, 17 Nov 85 12:41:10 pst Message-Id: <8511172041.AA01516@ucbjade.Berkeley.Edu> Date: 17 November 85 12:57 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: (copy) re: countries only at the top ? To: MSGGROUP@BRL.ARPA Originally sent from: PEB@CERNVM Originally sent to: RMXJ@CORNELLA Received: from CERNVM(MAILER) by CORNELLA (Mailer X1.21) id 1674; Thu, 14 Nov 85 06:41:39 EST Received: by CERNVM (Mailer X1.21) id 4505; Thu, 14 Nov 85 12:38:54 GVA Date: Thu, 14 Nov 1985 11:39 GVA From: Paul Bryant Subject: Re: (copy) re: countries only at the top ? To: In-Reply-To: Your message of 12 November 85 18:28 EST Since when have I been able to send (snail) mail to Fred, Foo, Baa, IBM. In much the same way I do not see why organizations should be regarded in the same light at countries. Similarly with ARPA/EDU or whatever. IBM will clearly have mamifestations in each country so you may well get US.IBM...... (or .......IBM.US depending). If IBM desires for all its electronic mail to enter through one gateway in the US then UK.IBM may well not exist (the PTTs may be none too happy but that's another question). If we allow multinational organizations to register at the top level then we are in danger of creating a large management problem in that I envisage that just about every tin pot organization will wish to so register for prestige reasons. Who is going to run and pay for this registration organization and which country will run it- United Nations? Looks too difficult to me. 17-Nov-85 15:23:46-PST,1379;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 15:23:38-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021513; 17 Nov 85 16:13 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA12108; Sun, 17 Nov 85 13:07:58 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA01469; Sun, 17 Nov 85 12:40:22 pst Message-Id: <8511172040.AA01469@ucbjade.Berkeley.Edu> Date: 17 November 85 12:52 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: (copy) Political nonsense overrides good sys To: MSGGROUP@BRL.ARPA Originally sent from: PEB@CERNVM Originally sent to: RMXJ@CORNELLA Received: from CERNVM(MAILER) by CORNELLA (Mailer X1.21) id 1679; Thu, 14 Nov 85 06:55:38 EST Received: by CERNVM (Mailer X1.21) id 4594; Thu, 14 Nov 85 12:43:52 GVA Date: Thu, 14 Nov 1985 11:39 GVA From: Paul Bryant Subject: Re: (copy) Political nonsense overrides good sys To: In-Reply-To: Your message of 12 November 85 18:31 EST It is a great pity that the PTT regulations in each country regaring electronic mail are not the same. (Not that I would like them all to follow Germany). Clearly CCITT? CEPT? or who? should be attempting to demand some common approaches in these multinational problems.. 17-Nov-85 15:25:54-PST,2151;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 15:24:02-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021543; 17 Nov 85 16:19 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA12197; Sun, 17 Nov 85 13:14:16 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA01486; Sun, 17 Nov 85 12:40:40 pst Message-Id: <8511172040.AA01486@ucbjade.Berkeley.Edu> Date: 17 November 85 12:52 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: (copy) Re: Political nonsense overrides good system To: MSGGROUP@BRL.ARPA Originally sent from: PEB@CERNVM Originally sent to: RMXJ@CORNELLA Received: from CERNVM(MAILER) by CORNELLA (Mailer X1.21) id 2650; Thu, 14 Nov 85 09:07:10 EST Received: by CERNVM (Mailer X1.21) id 7101; Thu, 14 Nov 85 14:36:40 GVA Date: Thu, 14 Nov 1985 14:01 GVA From: Paul Bryant Subject: Re: (copy) Re: Political nonsense overrides good system To: In-Reply-To: Your message of 13 November 85 12:04 EST Unfortunatly your comments are not quite correct regarding the European PTTs. EARN only has a licence to operate until 1987 during which time it must migrate to use ISO protocols and public data networks. The reason the PTTs have allowed the network to exist is that IBM computers could not provide systems capable of utilizing the PTT data networks. Thus the PTTs are putting pressure on IBM via EARN to 'conform'. It should also be noted that the European Academic consensus is that we should all use ISO protocols and EARN is seen as providing valuable but temporary facilities. The real point of contention with the PTTs is the tariff. If the PTTs will provide data transfer at a level the academics could afford then fine but if not then we have to explore other options and the PTTs do not like that as it chips away at their monopoly. I do not see why the academics need to run their own data network any more than they want to run a private telephone service- the PPTs are (should be) much better at it than us. 17-Nov-85 15:26:06-PST,2281;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 15:24:51-PST Received: from su-score.arpa by AOS.BRL.ARPA id a021745; 17 Nov 85 17:21 EST Date: Sun 17 Nov 85 14:19:38-PST From: David Roode Subject: Re: domains To: smoot@pop.ARPA, msggroup@BRL.ARPA In-Reply-To: <8511161718.AA18672@pop.UTEXAS.EDU> Message-ID: <12160055457.15.G.ROODE@SU-SCORE.ARPA> The solution so far as I can see it is for names to be registered (by those doing so) in the toplevel domain US rather than COM, etc. Existing registrations might change toplevel domains. Division of identity along geopolitical boundaries might be arbitrary, but it is the convention. The fact that multinational entities are considered exceptions proves that the convention exists. The naming of members of the world-wide weather community is a good case to illustrate of the fallacy of the rigid definition of the current top level domain. Is this possible namespace commercial, military, governmental or educational? One can envision the creation of the OTHER toplevel domain. The creation of the NET toplevel domain was possibly antithetical to the domain naming system. Alternatively it may have been a misnomer. Instead of something continuous and unlimited as we find at the lower levels of the domain naming system, we have only an apparently small and finite number of toplevel names in use currently. Why not allow multinational entities to register as toplevel domains? Why not have WEATHER as the toplevel domain for the world-wide weather community, if that community so desires and finds it advantageous? Would it not be natural for CSNET to create the worldwide or US-wide CS naming domain? In a sense, is that not what they are about? Membership in their network is restricted to an affinity group and spans any single hardware network definition. Consider if you will that they have formed a CS domain and not a mere network all along! In this sense, the NET toplevel domain might as well have been called DOMAIN. [I realize that CSNET intended to blend their hosts within existing domains and to only use the NET domain to name their relay/service host(s).] ------- 17-Nov-85 15:26:15-PST,1814;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 15:25:35-PST Received: from sri-nic.arpa by AOS.BRL.ARPA id a021871; 17 Nov 85 18:10 EST Date: Sun 17 Nov 85 15:09:00-PST From: Ole Jorgen Jacobsen Subject: Re: (copy) Re: (copy) re: countries only at the top ? To: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA cc: OLE@SRI-NIC.ARPA, msggroup@BRL.ARPA SRI-International: (415) 859-4536 Home: (415) 325-9427 Message-ID: <12160064445.14.OLE@SRI-NIC.ARPA> Please re-read Jon Postels and Einar Stefferuds recent messages (on this list) on the subject of top-level domains. The ARPA Internet domain system is just what the name says: A technical solution to an ARPA Internet problem, as far as I can see it has *nothing* to do with PTTs, CCITT, ISO, The United Nations, Multinational Organizations, International Politics, geography etc... Being an "international" person, I sort of wish we had the agreements/power to introduce a common standard/policy that would work for everyone, but I realize (with some regret) that we live in a world where things aren't quite that simple. Solutions lie in "gatewaying" and "conversion" and in the IFIP 6.5 working group we are doing just that. I have been of the opinion all along that it would have been "cleaner" to have .US at the top in the United States and have not been convinced that there would be too many objections and problems with this approach, but recent discussions have made me realize that a name is not a route, and a name is just a name , emotionally, and politically loaded as it may be. Meanwhile everyone is welcome to register in their favorite domain here at the NIC provided they satisfy the domain requirements. <370> ------- 17-Nov-85 18:44:42-PST,2290;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 18:41:07-PST Received: from rand-unix.arpa by AOS.BRL.ARPA id a022267; 17 Nov 85 21:19 EST Return-Path: Received: from vortex.UUCP by rand-unix.ARPA; Sun, 17 Nov 85 17:42:49 pst Date: Sun, 17-Nov-85 12:47:05 PST From: Lauren Weinstein Subject: From: lines in uucp mail Message-Id: <8511171247.2646.0.VT1.00C@vortex.UUCP> To: MSGGROUP@BRL.ARPA Please reread my original (long) message about this for an explanation of why most uucp sites should NOT modify From: lines. ARPA<->UUCP gateways may still need to VERY CAREFULLY perform From: line modifications (but not by simply prepending on a sitename!) until full domain handling on the Internet is in place. But for most uucp sites, simply trying to modify the From: line in a simplistic manner does much more harm than good for a variety of reasons which I outlined in my original reply to this list. Replies by uucp sites should be based on From_ and >From info which can generally be relied upon to be accurate and represent a true path. From: addresses in uucp mail, except where in non-hybrid domain form (that is, consisting solely of foo@site.domain) cannot be trusted for replies except in the simplest of cases, and not always even then. This isn't like on ARPA where a modification is just a simple name change from a nicname to a "real" name. On uucp we're talking about From: lines that in most cases AREN'T valid 822 to start with since they are simply multiple ! path addresses as generated by most sites. Trying to modify these paths in a simple manner can ruin the path information and result in paths that are totally bogus. Some uucp sites are starting to generate valid 822 From: lines (foo@site.domain) without the ! paths. These obviously also should not be modified by intermediate uucp sites except (as mentioned above) by particular ARPA gateways in a careful manner. Once again, my original message on this subject explained these issues in considerable detail. The bottom line is that for both ! and @ addresses in uucp From: lines, modification by most sites does far more damage than good. --Lauren-- 17-Nov-85 19:43:24-PST,689;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 19:43:08-PST Date: Sun, 17 Nov 85 22:23:01 EST From: Einar Stefferud (Consultant) To: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA cc: MSGGROUP@BRL.ARPA Subject: Re: Returned mail: unknown mailer error 255 (copy) Re: (copy) Re: domain names Hi All - I don't know why we suddenly have such a rash of administrivia mail being sent to the whole main list. It should be obvious that the right address for mail about bad addresses is msggroup-request@brl.arpa. Please do your best to avoid main list pollution. Thanks - Stef 17-Nov-85 21:50:41-PST,3623;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 21:50:02-PST Date: Mon, 18 Nov 85 0:31:35 EST From: Einar Stefferud (Consultant) To: msggroup@BRL.ARPA Subject: Explanation and aplology to Gligor My apologies to you all for bothering you with administrivia, but I need to explain that message I sent to Gligor and all of MsgGroup. My complaint was bogus, and I enclose the message I received which triggered my action. It seems that there is a new and more inventive Failed Mail Return program out there that sends back a thoroughly mystifying missive. In the enclosure below you will see that the Failure Message says it is From: RMXJ%CORNELLA.BITNET@ucbvax.berkeley.edu Subject: (copy) Re: (copy) re: countries only at the top ? To: To: MSGGROUP@brl.arpa In fact, it is not "From: RMXJ%CORNELLA.BITNET@ucbvax.berkeley.edu", nor was it delivered "To: MSGGROUP@brl.arpa", nor was it's proper "Subject: (copy) Re: (copy) re: countries only at the top ?" In all fairness, I do note that it has a second "Subject: Returned mail: unknown mailer error 255", and it was only delivered "To: ", in spite of what it says. It does not contain much of a clue as to who actually posted it, other than "Message-Id: <8511172041.AA01516@ucbjade.Berkeley.Edu>". So, after recieving 4 of these in a row from Gligor, I felt compelled to speak out in an effort to shut off the flow to the main list. Alas, only to discover that they were not flowing to the main list. Sigh! My most humble apologies to you all, and to Gligor. In the meantime, if anyone out there can locate the perpetrator of this hoax type failed mail notice, I have a Big Gold Colored Medal to award. This new "featureful" missive is going to cause a lot of confusion of it is not defused. Best - Stef ------ Enclosure Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021521; 17 Nov 85 16:15 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA12150; Sun, 17 Nov 85 13:08:55 PST Subject: Returned mail: unknown mailer error 255 Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021443; 17 Nov 85 15:43 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA11637; Sun, 17 Nov 85 12:38:00 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA01516; Sun, 17 Nov 85 12:41:10 pst Message-Id: <8511172041.AA01516@ucbjade.Berkeley.Edu> Date: 17 November 85 12:57 EST From: RMXJ%CORNELLA.BITNET@ucbvax.berkeley.edu Subject: (copy) Re: (copy) re: countries only at the top ? To: To: MSGGROUP@brl.arpa ----- Transcript of session follows ----- uux failed. code -1 554 ... unknown mailer error 255 uux failed. code -1 554 ... unknown mailer error 255 ----- Unsent message follows ----- Received: by ucbvax.berkeley.edu (5.31/1.3) id AA12137; Sun, 17 Nov 85 13:08:55 PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a021443; 17 Nov 85 15:43 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA11637; Sun, 17 Nov 85 12:38:00 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA01516; Sun, 17 Nov 85 12:41:10 pst Message-Id: <8511172041.AA01516@ucbjade.Berkeley.Edu> Date: 17 November 85 12:57 EST From: RMXJ%CORNELLA.BITNET@ucbvax.berkeley.edu Subject: (copy) Re: (copy) re: countries only at the top ? To: MSGGROUP@BRL.ARPA [Remainder removed by Stef] ------ End enclosure 17-Nov-85 23:31:00-PST,1166;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sun 17 Nov 85 23:26:34-PST Received: from im4u.arpa by AOS.BRL.ARPA id a023563; 18 Nov 85 2:08 EST Posted-Date: Sun, 17 Nov 85 20:14:44 cst Received: from pop.UTEXAS.EDU by im4u (4.22/4.22) id AA05170; Sun, 17 Nov 85 20:14:49 cst Date: Sun, 17 Nov 85 20:14:44 cst From: Smoot Carl-Mitchell Message-Id: <8511180214.AA00638@pop.UTEXAS.EDU> Received: by pop.UTEXAS.EDU (2.0/4.22) id AA00638; Sun, 17 Nov 85 20:14:44 cst To: G.ROODE@SU-SCORE.ARPA Subject: Re: domains Cc: msggroup@BRL.ARPA I agree that limiting top-level domains to the few suggested is probably a bad idea and it probably won't last long. I was simply suggesting that different people look at the world in different ways and the domain naming system can accomodate them all with a little thought and consideration. I also agree with Jon Postel that the domain naming system and its associated distributed database is a response to an immediate need of the ARPA community and does not preclude other solutions to a very hard and very general problem. 18-Nov-85 07:33:59-PST,807;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Mon 18 Nov 85 07:33:27-PST Received: from wiscvm.arpa by AOS.BRL.ARPA id a029642; 18 Nov 85 9:57 EST Received: from (JARRELLR)VTVAX5.BITNET by WISCVM.ARPA on 11/18/85 at 08:55:00 CST Date: Mon, 18-NOV-1985 09:46 EST From: "Ronald A. Jarrell" To: msggroup@BRL.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Subject: domains, top levels, etc... Didn't anyone bother commenting on the Request For Comments in question? Seems a little silly for it to have been partially implemented, and *NOW* everyone sticks up their head and says: "Hey whoa, who said you could do that.. No, do it this way, it's better..." 18-Nov-85 07:37:24-PST,1853;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Mon 18 Nov 85 07:36:18-PST Received: from acc.arpa by AOS.BRL.ARPA id a029827; 18 Nov 85 10:03 EST Date: 18 Nov 85 06:55:00 PST From: lars@ACC.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Subject: Weather Net and links to Europe To: info-nets%mit-oz cc: msggroup@BRL.ARPA, smoot@pop.ARPA, g.roode@su-score.ARPA, lars@BRL.ARPA Reply-To: lars@ACC.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Given the fact that Europe seems to be 2-5 years behind us in electronic mail network connection density (and maybe 2 years ahead of us in implementing X.400) I often find that I need to use some creativity in finding paths to my friends in Europe (most of them in Denmark). So far I have found working UUCP paths to Copenhagen University Computer Science department, and there are indications that there are several BitNet/EARN hosts in the universities, but I still don't have paths to several of the people. Recent discussions about mail DOMAINs in MsgGroup and the MHS group have referenced "the international weather community which is in constant communication". This is a solicitation of further information about the weather computing community. - Is there a network in the sense of BITNET or CSNET ? - What is the common protocol base used by this network ? - Does this network support mail in the sense that UUCP and the Internet do ? - Are there generally accessible gateways that will enable cross-over of mail to and from the Internet ? - Can anyone give me a path to the Copenhagen Meteorological Institute ? / Lars Poulsen Advanced Computer Communications ------ 18-Nov-85 19:44:10-PST,2738;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Mon 18 Nov 85 19:43:08-PST Received: from css-ring-gw by AOS.BRL.ARPA id a013140; 18 Nov 85 22:11 EST Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Mon, 18 Nov 85 21:28:41 EST Received: by hadron.UUCP (4.12/4.7) id AA18340; Mon, 18 Nov 85 13:35:52 est Date: Mon, 18 Nov 85 13:35:52 est From: "Joseph S. D. Yao" Message-Id: <8511181835.AA18340@hadron.UUCP> To: G.ROODE@SU-SCORE.ARPA, msggroup@BRL.ARPA, smoot@POP.ARPA Subject: Re: domains > The solution so far as I can see it is for names to be registered > (by those doing so) in the toplevel domain US rather than COM, etc. > Existing registrations might change toplevel domains. The problem here is that geopolitical location is not a constant for most groups. E.g., when my current company moved from Vienna to Fairfax a year ago, would we have had to re-register everywhere as Hadron.Fairfax.VA.US instead of Hadron.Vienna.VA.US? Better, when my former company re-incorporated in a different state, would they have had to change from SAI.CA.US to SAIC.DE.US? (Ignoring the minor but apparently legally necessary name change.) Obviously, there are some groups that are inherently affiliated with a given geopolitical subdivision. These mostly fall into the local- government category. (Yes, US government is a local government! If I move out to Guyana or Tau Beta Centauri I don't expect to have to recognise US government unless I retain citizenship in absentia.) However, for various reasons, Time Canada (only e.g.) may wish to be known as TIME.CA while IBM Canada may wish to be known as CA.IBM. Who knows? (There are business-politikal reasons for being affiliated with the country in which one is doing business.) One point someone at CERN seems to have missed, is that just because an organisation is registered as, e.g., IBM.US, that organisation doesn't necessarily only have a "gateway" in the US. There may be registrations for LONDON.IBM.US and GLASGOW.IBM.US and DUBLIN.IBM.US in all the British registries, or even in all the European registries. I doubt the US registries -- I have a difficult time finding the locations of corporations' overseas offices, in general, here. ;-) But the point is, that if one is looking for vaxg.LONDON.IBM.US, one only has to go back as far as the longest subdomain for which one has registry, not necessarily send it to a US gateway which will send it to an IBM gateway which ... (all e.g., of course). [yes, i realise that vaxg. ... .IBM is a flight of whimsy.] Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 19-Nov-85 15:37:26-PST,2332;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 19 Nov 85 15:34:44-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a002040; 19 Nov 85 18:05 EST Received: by ucbvax.berkeley.edu (5.31/1.3) id AA06445; Tue, 19 Nov 85 15:04:08 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.40.4) id AA09744; Tue, 19 Nov 85 15:03:49 pst Message-Id: <8511192303.AA09744@ucbjade.Berkeley.Edu> Date: 19 November 85 18:02 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: (copy) Re: (copy) Re: (copy) Political To: MSGGROUP@BRL.ARPA Originally sent from: RMXJ@CORNELLA.BITNET Originally sent to: RMXJ@CORNELLA The following message is in response to Erik Fair's comment of Sunday, 17 November. Replies should be addressed to the MSGGROUP list and to PEB%CERNVM.BITNET@WISCVM.WISC.EDU ============================================================================ Received: by CERNVM (Mailer X1.21) id 3540; Tue, 19 Nov 85 11:35:04 GVA Date: Tue, 19 Nov 1985 10:14 GVA From: Paul Subject: Re: (copy) Re: (copy) Re: (copy) Political nonsense overr To: In-Reply-To: Your message of 17 November 85 21:12 EST To Erik Fair. In blaiming CCITT and ISO you should include the European Academic community as well who are supporters of ISO protocols and their use as the only way of providing good services in the future. We believe very strongly that life will be a lot easier if we have only one set of protocols to worry about and that protocol converting gateways are a thing of the past. We have observed the American experiance of a multiplicity of networking methods, which was all very well when we were experimenting, and we do not want to follow that line. We now see that X25 is well established in Europe as well as the interactive protocols and that X400 is about to take off with a lot of help from manufacturers (including Americal ones such as DEC) who are dedicated to producing examples of ISO. In fact DEC , if you believe them, intend to migrate DECNET to ISO. The real argument with the European PTTs is the tariffs they charge abd also the bandwidth of the international X25 connections- both of these are unacceptable and the subject of discussion. 19-Nov-85 17:17:44-PST,1050;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 19 Nov 85 17:17:23-PST Received: from ucb-arpa.arpa by AOS.BRL.ARPA id a002667; 19 Nov 85 19:56 EST Received: by ucbarpa (5.31/1.3) id AA05172; Tue, 19 Nov 85 16:54:59 PST Date: Tue, 19 Nov 85 16:54:59 PST From: "Erik E. Fair" Message-Id: <8511200054.AA05172@ucbarpa> To: MSGGROUP@BRL.ARPA, RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: Re: (copy) Re: (copy) Re: (copy) Re: (copy) Political I have no quarrel with the movement to standardization. I quarrel with the technical decisions that have been made and that are being made by the CCITT and the ISO. They've come up with an abysmal protocol suite that will limit the development of computer networking for decades to come, except in those areas of the U.S. (and perhaps the world) where there are people courageous enough to give the ISO the bronx cheer that they deserve, and do their own thing. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu 19-Nov-85 19:00:35-PST,768;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Tue 19 Nov 85 18:59:46-PST Received: from bbna.arpa by AOS.BRL.ARPA id a002983; 19 Nov 85 21:32 EST Date: 19 Nov 1985 21:29-EST Sender: DDEUTSCH@BBNA.ARPA Subject: Re: (copy) Re: (copy) Re: (copy) Re: (copy) Political From: DDEUTSCH@BBNA.ARPA To: fair@ucb-arpa.ARPA Cc: MSGGROUP@BRL.ARPA Cc: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Cc: DDeutsch@BBNA.ARPA Message-ID: <[BBNA.ARPA]19-Nov-85 21:29:18.DDEUTSCH> In-Reply-To: <8511200054.AA05172@ucbarpa> I would be very interested to learn why you feel that the CCITT and ISO mail protocols are "abysmal" and how they will "limit the development of computer networking for decades to come". --Debbie Deutsch 20-Nov-85 15:38:02-PST,870;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Wed 20 Nov 85 15:37:33-PST Received: from rand-unix.arpa by AOS.BRL.ARPA id a022644; 20 Nov 85 18:02 EST Return-Path: Received: from vortex.UUCP by rand-unix.ARPA; Wed, 20 Nov 85 14:37:38 pst Date: Wed, 20-Nov-85 09:07:56 PST From: Lauren Weinstein Subject: Subject lines Message-Id: <8511200907.3963.0.VT1.00C@vortex.UUCP> To: MSGGROUP@BRL.ARPA It would really nice if people would take a few extra seconds and fix up their subject lines to be MEANINGFUL instead of just "blindly" generating replies to subject lines like: Re: (copy) re: (copy) re: (copy) and similar nonsense. All of us on this list should know better than to just keep letting such lines go out over and over again. --Lauren-- 23-Nov-85 17:16:28-PST,2165;000000000000 Return-Path: Received: from [192.5.25.82.] (for BRL-AOS) by USC-ECLC.ARPA; Sat 23 Nov 85 17:16:04-PST Received: from ucb-vax.arpa by AOS.BRL.ARPA id a008445; 23 Nov 85 19:54 EST Received: by ucbvax.berkeley.edu (5.31/1.7) id AB06639; Fri, 22 Nov 85 17:34:33 PST Received: from CORNELLA by ucbjade.Berkeley.Edu (4.19/4.41) id AA11523; Fri, 22 Nov 85 17:02:31 pst Message-Id: <8511230102.AA11523@ucbjade.Berkeley.Edu> Date: 22 November 85 19:48 EST From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA Subject: (copy) Re: (copy) Re: (copy) Re: (copy) Re: (copy) Re: (copy) To: MSGGROUP@BRL.ARPA Originally sent from: PEB@CERNVM Originally sent to: RMXJ@CORNELLA This is a reply from Paul Bryant in response to a letter earlier this week by Eric Fair. Comments should be addressed to PEB%CERNVM.BITNET@WISCVM.WISC.EDU as well as MSGGROUP. ================================================================================ Received: from CERNVM(MAILER) by CORNELLA (Mailer X1.21) id 4122; Fri, 22 Nov 85 04:25:29 EST Received: by CERNVM (Mailer X1.21) id 7182; Fri, 22 Nov 85 10:24:21 GVA Date: Fri, 22 Nov 1985 09:46 GVA From: Paul Subject: Re: (copy) Re: (copy) Re: (copy) Re: (copy) Re: (copy) Po To: In-Reply-To: Your message of 20 November 85 12:03 EST In reply to Eric E Fair. You may well criticise CCITT since they are a body beyond our control. ISO is not so placed as WE/YOU can influence ISO via our own standards organizations. You may well be right about the technical merits of x400 but like the IBM PC it is bland but there will be a lot of it about and it will provide a service which is rather more convenient than the current assembley of technolgy and gateways. My belief is that it is a major achievment to get any sort of agreement and once that is achieved and networks in place moves away from international standards will be unthinkable and we can talk exclusivly about how we putin place better standards. Regretfully international standards are more about agreement and compromise rather than technical excellence. 26-Nov-85 03:05:00-PST,1268;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Tue 26 Nov 85 03:02:37-PST Received: from usc-isib.arpa by AOS.BRL.ARPA id a006263; 26 Nov 85 1:39 EST Date: 25 Nov 1985 22:36:04 PST From: POSTEL@USC-ISIB.ARPA Subject: re: the US domain To: msggroup@BRL.ARPA Hi. One of the main reasons for the domain system is to subdivide the task of keeping the data base of names and associated information up to date. The idea is to have a reasonable number of entries to keep track of as the next level down from any node in the tree. Experience suggests that a reasonable number is on the order of 100. Experience clearly indicates that 1000 is too many. So given that there is a US domain (there is), what is the reasonable kind of thing to use (allow, encourage, suggest, legislate, ...) for the second level? It ought to be something there will be about 100 of. Of course, it could be something there is a lot fewer of. (If there are only a few things at a level it will take more levels to name everything.) Once you have something in mind for the second level, give some thought to a third level. Keep in mind the idea of a branching factor of 100. I'd appreciate your suggestions. --jon. ------- 26-Nov-85 03:05:05-PST,2542;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Tue 26 Nov 85 03:02:46-PST Received: from wiscvm.arpa by AOS.BRL.ARPA id a006861; 26 Nov 85 4:03 EST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/26/85 at 03:00:26 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 5389; Tue, 26 Nov 85 10:59:30 O Date: Tue, 26 Nov 1985 10:35 O From: Henry Nussbacher Subject: .US and domains To: MsgGroup@BRL.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA John, The obvious answer is to break the second level down by states, i.e ...NY.US or ...CA.US This of course would be the wrong solution. Out of the 4 major networks (Arpanet, Bitnet, UUCP and Csnet) all have sites in NY state. Suppose that 3 years from now there are a number of gateways between Bitnet and Arpanet. A piece of mail is to be sent to BUFFULO.NY.US. Suppose that a domain name resolver exists in NY state. It would have to have a record of all sites in NY state and which belongs to which network. It could end up that this mail is destined for UUCPland, and NY state doesn't have a UUCP gateway. So the mail gets shipped over to Penn. state for entry into UUCP. This whole scenerio doesn't seem workable to me. The state-second-level breakdown does work under one and only condition. All networks in the United States merge into one. They all run one common set of protocols and therefore no gateways exist. The only gateways are to get out of the country. A number of crucial sites throughout the United States would maintain such international gateways. The other alternative is for the various networks in existance today in the United States to be second-level domains (as CS.NET is already) and they are responsible for maintaining their subdomaining. A piece of mail destined then for user@QUEENS.CUNY.BITNET.US would be the responsilbility of Bitnet after it gets past the second level domain. Of course, then we get back to the problem of mail between two physically adjacent sites, but on different networks, may end up travelling across the continent just to get into a gateway. So back to the first solution. Merge all United States networks into one homogenous network under the domain level of .US with second level domains being state. States can then break up into EDU, MIL and others. Pie in the sky thinking, Hank 26-Nov-85 03:05:10-PST,1366;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Tue 26 Nov 85 03:02:57-PST Received: from su-score.arpa by AOS.BRL.ARPA id a006971; 26 Nov 85 4:32 EST Date: Tue 26 Nov 85 01:24:39-PST From: David Roode Subject: re: the US domain To: POSTEL@USC-ISIB.ARPA, msggroup@BRL.ARPA In-Reply-To: Message from "POSTEL@USC-ISIB.ARPA" of Mon 25 Nov 85 22:36:04-PST Message-ID: <12162273670.16.G.ROODE@SU-SCORE.ARPA> Pre-domain system, the host table was comfortably maintained with a lot more than 100 hosts. Are there likely to be more than say 500 registrants in the US domain even if no particular structure is imposed on the 2nd level names? What kind of total naming volume are we targeting and how much natural clustering is there likely to be to push names out to the 3rd level and reduce the number of 2nd level names? What if the only structural restriction were that all that could be registered under the US domain were other domains--no hosts such as we see under the COM, EDU, etc. domains? The advantages of lack of structure now is that at least the domains that register will likely have a motivated maintainer. Later on it might make sense to have a domain per state, for example, but to motivate someone to operate that domain at this point may be more difficult. ------- 28-Nov-85 02:52:33-PST,982;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 28 Nov 85 02:50:10-PST Received: from ucl-cs.arpa by AOS.BRL.ARPA id a017870; 28 Nov 85 5:26 EST Received: from geca.cardiff.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a001432; 27 Nov 85 15:23 GMT To: David Roode From: Ralph Martin (on ICF GEC 4090 at Cardiff) Date: Wed, 27 Nov 85 08:55 GMT In-reply-to: <12162273670.16.G.ROODE@SU-SCORE.ARPA> Message-Id: <27 NOV 1985 08:55:50 XACF03@CFGA> Subject: re: the US domain Cc: msggroup Are there likely to be more than 500 2nd level domains ? This reminds me of the statement, also made by an american, when he heard of the invention called a 'telephone'. It went something along the lines of, 'Hey, this is really great, I think every major city should have one'. Ralph 28-Nov-85 20:29:15-PST,1782;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 28 Nov 85 20:26:56-PST Received: from mit-multics.arpa by AOS.BRL.ARPA id a021443; 28 Nov 85 21:01 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2679528752540003@MIT-MULTICS.ARPA>; 28 Nov 1985 20:32:32 est Date: 28 Nov 85 22:14 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, MsgGroup Subject: .US and domains; Merging all US networks into one Message-ID: <138098@QZCOM> In-Reply-To: <137497@QZCOM> Hank, that is exactly what I would like to see! It really is a trouble - especially for non-US persons - to remember wheather that-person is on Arpanet, BITnet, CSnet, Mailnet, UUCP or whatever. Haven't your telephone companies come up with the same solution long time ago? This will not mean to break the current physical networks, but it will call for some multi-lateral agreement on Inter-Net Gateway Charging, where - I recall - some progress was made last summer in Stockholm. Note that the logical structures (e.g. grouping all CS insitutions) could still be possible using a good directory system. Also, I do not see any problem in having a set of Alias Global Naming Trees (to keep them being trees, not graphs) for multi- national "organisations" like 'Academic Community' and optionally their off-springs 'Computer Science' etc. The ITU cannot rule that out. Again, it is a matter of multi-lateral agreement. Have I overlooked something? Tommy 28-Nov-85 20:29:18-PST,710;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 28 Nov 85 20:27:41-PST Received: from su-score.arpa by AOS.BRL.ARPA id a021778; 28 Nov 85 22:40 EST Date: Thu 28 Nov 85 19:34:50-PST From: David Roode Subject: number of 2nd level domains To: msggroup@BRL.ARPA Message-ID: <12162996422.9.G.ROODE@SU-SCORE.ARPA> How many telephone area codes do you think there were in the initial days of the American telephone system? The question is not whether there will ever be 500 2nd level domains, but how soon. Does it make sense to build foundations for growth when the foundations may have to be changed before the growth occurs? ------- 4-Dec-85 14:28:34-PST,2416;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 4 Dec 85 14:27:32-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 4 Dec 85 11:32:54-PST Date: 4 Dec 1985 11:29:53 PST Subject: RFC960 & RFC961 Now Available From: Ann Westine To: Request-For-Comments-List: ; New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 960: Title: Assigned Numbers Author: Joyce Reynolds & Jon Postel Mailbox: JKREYNOLDS@USC-ISIB.ARPA Pages: 60 Characters: 129172 pathname: RFC960.TXT This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Distribution of this memo is unlimited. RFC 961: Title: Official ARPA-Internet Protocols Author: Joyce Reynolds & Jon Postel Mailbox: JKREYNOLDS@USC-ISIB.ARPA Pages: 38 Characters: 54798 pathname: RFC961.TXT This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 5-Dec-85 14:32:39-PST,1826;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Thu 5 Dec 85 14:29:39-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Dec 85 11:06:42-PST Date: 5 Dec 1985 11:05:01 PST Subject: RFC965 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 965: Title: A Format for a Graphical Communication Protocol Author: Lorenzo Aguilar Mailbox: Aguilar@SRI-TSC.ARPA Pages: 51 Characters: 108361 pathname: RFC965.TXT This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 9-Dec-85 17:15:21-PST,153;000000000001 Date: Mon 9 Dec 85 17:10:16-PST From: MsgGroup Moderator - Einar Stefferud Subject: Survey of MSGGROUP#2501-2550 Fill in data here 10-Dec-85 13:21:17-PST,1684;000000000001 Return-Path: Received: from ECLB by ECLC with DECnet; Tue 10 Dec 85 13:20:43-PST Date: Tue 10 Dec 85 13:20:23-PST From: ACCTING@ECLB Subject: Eclc To: AC@ECLC, CCA@ECLC, CCA.AC@ECLC, CCA.AC.COM@ECLC, CCA.GUEST@ECLC, CCA.LDM@ECLC, CCA.SDD-SCRIPT@ECLC, CCA.TENEX@ECLC, CCA.TIPCOPY@ECLC, DC-203@ECLC, DC-SOURCE@ECLC, DC-TEST@ECLC, DC-USER@ECLC, DC-USER.GM-TM@ECLC, FOX@ECLC, LDM@ECLC, MB-GDM@ECLC, MB-SOURCE@ECLC, MB-WORK@ECLC, MSGGROUP@ECLC, NORI@ECLC, OLSON@ECLC, RH@ECLC, SUTHERLAND@ECLC, SV@ECLC, TAL@ECLC, YEDWAB@ECLC, ABADIR@ECLC, BOND@ECLC, BOND.QMC@ECLC, BREUER@ECLC, GORDON@ECLC, GUPTA@ECLC, ZHU@ECLC, ANGEBRANNDT@ECLC, CAROL@ECLC, GABRIEL@ECLC, GOLDBERG@ECLC, GREEN@ECLC, JVC@ECLC, KANT@ECLC cc: accting@ECLB Message-ID: <12166073983.22.ACCTING@USC-ECLB.ARPA> To all concerned, Begining on the morning of 16 December 1985 the computer known as ECLC will be removed from service to the Arpanet and reverted to internal use by USC-UCS. If you desire to have an Arpanet account you will need to contact the appropriate Arpanet contacts directly. If you wish to continue using ECLC on a usage-charge basis under the current rates (which are available under rates.doc) please contact the USC-UCS Business Office at (213)743-3551. Starting 16 December 1985 all accounts which do not have a source of funding will be removed from the system. All files will be deleted and all USC System tapes returned to the system. If you have any questions or problems related to this shut-down please feel free to contact my office at the above number. --Martin Wills-- USC-UCS Accounting Group ------- 12-Dec-85 00:09:31-PST,1016;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Dec 85 00:08:07-PST Received: from office-1.arpa by AOS.BRL.ARPA id a018161; 12 Dec 85 2:41 EST Date: 11 Dec 85 23:33 PST From: William Daul / McDonnell-Douglas / APD-ASD Subject: PROFS --> IP --> DDN/Internet To: info-ibmpc@USC-ISIB.ARPA Cc: info-nets%mit-oz@mit-mc.ARPA, msggroup@BRL.ARPA, WRS.TYM@OFFICE-1.ARPA Cc: tcp-ip-vms@sri-nic.ARPA Message-ID: Does anyone know of sites running a PROFS environment with some sort of internet protocol for mail to the Internet? Could you send me names/sites/addresses? Thanks, //Signed// William B. Daul Systems Programmer , Postmaster , Augmentation Systems Division, McDonnell Douglas Computer Systems Company, 20705 Valley Green Drive Cupertino, CA. 95014 11-Dec-85 12-Dec-85 22:02:07-PST,1178;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Thu 12 Dec 85 22:01:03-PST Received: from sri-csl.arpa by AOS.BRL.ARPA id a005498; 13 Dec 85 0:37 EST Date: 12 Dec 1985 20:00-PST Sender: GEOFF@SRI-CSL.ARPA Subject: It's Been Real. From: "the tty of Geoffrey S. Goodfellow" To: MsgGroup@BRL.ARPA Message-ID: <[SRI-CSL.ARPA]12-Dec-85 20:00:06.GEOFF> It is with a good bit of reluctance that I announce my departure from the ivory walls of SRI on the West Coast in late January. I will be taking a position in the private sector at the Cellular Radio Corp in the Washington D.C. area. In my new position, I hope to be able to influence the ubiquitous and ever burgeoning untethered communication industry's realization of the paramount importance of security, privacy and integrity considerations in technology development. I plan to remain active on the ARPANET through a part-time relationship with SRI Washington D.C. I am very proud to have been associated with the considerable cadre of wonderful people on The Network who brought about the packet switching and Internet (r)evolution. g 13-Dec-85 18:42:50-PST,1908;000000000000 Return-Path: Received: from BRL-AOS.ARPA by USC-ECLC.ARPA; Fri 13 Dec 85 18:40:20-PST Received: from su-sushi.arpa by AOS.BRL.ARPA id a022783; 13 Dec 85 21:02 EST Date: Fri 13 Dec 85 17:56:01-PST From: Joan Feigenbaum Subject: SDI Debate at Stanford, 12/19/85 To: AILIST@SRI-AI.ARPA, ARMS-D@MIT-MC.ARPA, ARPANET-BBOARDS@MIT-MC.ARPA, EVOLUTION@KESTREL.ARPA, MsgGroup@BRL.ARPA, NA@SU-SCORE.ARPA, PHIL-SCI@MIT-MC.ARPA, POLI-SCI@rutgers.ARPA, PROLOG@SU-SCORE.ARPA Message-ID: <12166910591.26.JF@SU-SUSHI.ARPA> APOLOGIES TO THOSE WHOSE BBOARDS RECEIVED MULTIPLE COPIES OF THIS. ____________________________________________________________________________ ``SDI: How Feasible, How Useful, How Robust?'' This will be a technical debate, covering both hardware and software aspects of SDI. Sponsor: Stanford Computer Science Department Date: December 19, 1985 Time: 8:00 p.m. Place: Terman Auditorium Organizer: Barbara Simons, IBM-SJ Moderator: Dr. Marvin L. Goldberger, President of Cal Tech. Former member of President's Science Advisory Committee and Consultant on Arms Control and International Security. Panelists: Advocates: Professor Richard Lipton, Professor of Computer Science at Princeton University, Current member of SDIO's Panel on Computing and Support of Battle Management. Major Simon Peter Warden, the Special Assistant to the Director of the SDIO and Technical Advisor to the Nuclear and Space Arms Talk with the USSR in Geneva. Opponents: Dr. Richard L. Garwin, IBM Fellow and Adjunct Professor of Physics at Columbia University, Physicist and Defense Consultant. Professor David Parnas, Lansdown Professor of Computer Science at the University of Victoria, Former member of the SDI Organization's Panel on Computing and Support of Battle Management. ------- 29-Dec-85 00:42:29-PST,3554;000000000000 Return-Path: Received: from ICSE.UCI.EDU (for ICSE.UCI.EDU) by USC-ECLC.ARPA; Sun 29 Dec 85 00:41:01-PST Received: from localhost by ICSE.UCI.EDU id a009782; 29 Dec 85 0:37 PST BBoard-ID: 91 BB-Posted: Tue, 17 Dec 85 17:55:21 PST Received: from uci.edu by ICSE.UCI.EDU id a002741; 17 Dec 85 17:54 PST Received: from bboards by UCI.EDU id a007891; 17 Dec 85 17:54 PST Received: from brl-aos.arpa by UCI.EDU id a007886; 17 Dec 85 17:53 PST Received: from hplabs.arpa by AOS.BRL.ARPA id a003204; 17 Dec 85 16:00 EST Received: by hplabsd ; Tue, 17 Dec 85 12:57:33 pst To: veeger!hpcnoe!hpfcla!hplabs!MsgGroup@brl.arpa Date: Tue, 17 Dec 85 11:19:47 MST From: Dave Taylor Subject: Random mail headers... Organization: Hewlett Packard, Colorado Networks Operation X-Location: Fort Collins, Colorado, USA X-Mailer: msg [version 2.3] ReSent-To: msggroup@usc-eclc.arpa Resent-Date: 29 Dec 85 00:36:27 PST (Sun) Resent-From: Einar Stefferud Chris Kent at Purdue informs me that I missed his contribution to the mail header mania... ---------------- From root Tue Dec 17 10:48:25 1985 To: hpcnou!dat@hplabs.arpa (Dave Taylor) Subject: Re: X-* headers National-Indulgence-Of-The-Day: Lager From: "Christopher A. Kent" Dave, Somehow you've missed my contribution to mail header explosion (see above.) Chris ---------- My response is: Gee you have a wonderful header there. So do some other friends of mine: Phase-of-the-Day: management by objectives Fruit-of-the-Day: apple Buzzword-of-the-Day: user-friendly Mood-of-the-Moment: happy Neuron-Firing-Level: high Libido-Level: very high Weather: sunny with a 30% chance of rain this evening Temperature: 80 degrees, +/- 5 degrees and so on. My real reaction - the arbitrary headers are fine...no biggie...but I'm not about to start adding every random header to the list just to give people vicarious thrills. Y'know what I mean? (Besides, it would increase the size of the list without bounds once I started) If you can get a number of people at a number of different sites to start using your header then it will make it into the document I transmitted since that's the way I decide... While I'm at it, I'd like to poll the readers of this message about their reactions to my posting this list every so often, including all updates, to the newsgroup "net.mail". Any comments? It seems like this would be a pretty useful addition to the net... Sorry to seem so untractable, Chris, but I'd really like to avoid a replay of the header-wars that first hit when people realized they can put just about any random junk in the headers of their outbound messages. My worst nightmare is to start getting messages like: ----------- From root Subject: how about THESE headers! Alternative-Subject: more headers for inclusion in your list Mail-Generated-By: typing it in, of course. From: John Public Really-From: God Almost-From: Ronald Reagan Political-Stance-of-the-Day: ban the bomb! Start-Body: Line-1: Dave, Line-2: Line-3: Just thought you'd appreciate this message with it's wonderful Line-4: headers and would consider it for inclusion in your list of Line-5: mail headers... End-Body: Signed: John Q. Public Authorized-by: jqp at 4:50 pm hi ---------- or something equivalent. -- Dave Taylor Hewlett Packard 29-Dec-85 00:42:34-PST,2169;000000000000 Return-Path: Received: from ICSE.UCI.EDU (for ICSE.UCI.EDU) by USC-ECLC.ARPA; Sun 29 Dec 85 00:41:19-PST Received: from localhost by ICSE.UCI.EDU id a009807; 29 Dec 85 0:38 PST BBoard-ID: 92 BB-Posted: Sat, 21 Dec 85 11:31:55 PST Received: from uci.edu by ICSE.UCI.EDU id a012064; 21 Dec 85 11:31 PST Received: from bboards by UCI.EDU id a000938; 21 Dec 85 11:30 PST Received: from brl-aos.arpa by UCI.EDU id a000928; 21 Dec 85 11:30 PST Received: from mit-multics.arpa by AOS.BRL.ARPA id a021970; 21 Dec 85 14:11 EST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2681492612855296@MIT-MULTICS.ARPA>; 21 Dec 1985 14:03:32 est Date: 21 Dec 85 12:01 +0100 From: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa Reply-to: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.arpa To: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.arpa, MsgGroup Subject: Subject: Managing distribution lists Message-ID: <142751@QZCOM> ReSent-To: msggroup@usc-eclc.arpa Resent-Date: 29 Dec 85 00:36:56 PST (Sun) Resent-From: Einar Stefferud Today I got a request from an administrator how had a problem: a user of a computing facility did no longer use his ID and he was a member of one or more distribution lists that kept flooding their system, eating the available disk space, thus stopping other users from net-mailing. The user ID could for some reason not be deleted and their mail system did not seem to have a way to invalidate reception for individual users. What to do? Clearly you cannot start sending out a removal-request to every distribution list you know - too costly, and you would probably not know them all. The obvious (to me at least, we have had it for years) solution is to make memberships be registred BOTH with the D-list AND the recipient. You will then be able to answer the question "What lists is N.N a member of?" in an effective way. It is my hope that the coming Directory System from CCITT/ECMA/ISO will make this usage more wide-spread. 29-Dec-85 00:42:46-PST,1853;000000000000 Return-Path: Received: from ICSE.UCI.EDU (for ICSE.UCI.EDU) by USC-ECLC.ARPA; Sun 29 Dec 85 00:41:30-PST Received: from localhost by ICSE.UCI.EDU id a009814; 29 Dec 85 0:38 PST BBoard-ID: 94 BB-Posted: Sat, 21 Dec 85 16:43:19 PST Received: from uci.edu by ICSE.UCI.EDU id a012783; 21 Dec 85 16:41 PST Received: from bboards by UCI.EDU id a002373; 21 Dec 85 16:41 PST Received: from brl-aos.arpa by UCI.EDU id a002362; 21 Dec 85 16:38 PST Received: from css-ring-gw.arpa by AOS.BRL.ARPA id a022382; 21 Dec 85 19:11 EST Return-Path: Received: from hadron.UUCP by seismo.CSS.GOV with UUCP; Sat, 21 Dec 85 19:02:18 EST Received: by hadron.UUCP (4.12/4.7) id AA12342; Sat, 21 Dec 85 18:59:38 est Date: Sat, 21 Dec 85 18:59:38 est From: "Joseph S. D. Yao" Message-Id: <8512212359.AA12342@hadron.UUCP> To: msggroup@brl.arpa Subject: Re: Subject: Managing distribution lists ReSent-To: msggroup@usc-eclc.arpa Resent-Date: 29 Dec 85 00:37:36 PST (Sun) Resent-From: Einar Stefferud Suggestion: If your system has an aliasing capability, then alias the old login to either Postmaster, some other person who wants to take the newsgroup memberships, or a garbage login whose sole purpose is to send out to XXXXX-request a request to discontinue memberships. This is, of course, in lieu of requiring all persons who subscribe to newgroups to submit a certificate certifying he or she has sufficient responsibility to unsubscribe from his or her own newsgroups, signed by a local clergyperson and certified by a notary public. ;-) Personally, I would be very happy never again to receive an article submitted to a newsgroup back marked undeliverable. That goes double for this article (hint). Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} 29-Dec-85 00:43:03-PST,2081;000000000000 Return-Path: Received: from ICSE.UCI.EDU (for ICSE.UCI.EDU) by USC-ECLC.ARPA; Sun 29 Dec 85 00:41:39-PST Received: from localhost by ICSE.UCI.EDU id a009818; 29 Dec 85 0:39 PST BBoard-ID: 95 BB-Posted: Sat, 21 Dec 85 16:58:27 PST Received: from uci.edu by ICSE.UCI.EDU id a012796; 21 Dec 85 16:56 PST Received: from bboards by UCI.EDU id a002460; 21 Dec 85 16:56 PST Received: from brl-aos.arpa by UCI.EDU id a002424; 21 Dec 85 16:55 PST Received: from su-score.arpa by AOS.BRL.ARPA id a022415; 21 Dec 85 19:38 EST Received: from IMSSS by Score with Pup; Sat 21 Dec 85 16:32:23-PST Date: 21 Dec 1985 1635-PST From: Rem@imsss Subject: In reply to Tommy_Ericson (QZCOM etc.) To: MsgGroup%BRL-AOS.ARPA@su-score.arpa ReSent-To: msggroup@usc-eclc.arpa Resent-Date: 29 Dec 85 00:38:01 PST (Sun) Resent-From: Einar Stefferud An alternative to having to maintain a reverse index, for each user what mailing lists he/she is on, is to have headers of messages that arrive via mailing lists indicate what expansion occurred, that is what mailing list vectored to what user. Usually you can figure this out from the existing header, although sometimes it's difficult. Then after you think you've stopped your mail, and you get yet another mailing-list message, you can look at the header and know which list needs to be told to drop you. This expansion should be done whenever the recipient name is changed, including not just mailing lists but aliases and vectors. Then if you received a message addressed to INFO-FOO which expanded to TOMMY@MIT-MC which mapped to Tommy_Ericson... you can know to tell INFO-FOO-REQUEST to delete TOMMY@MIT-MC rather than Tommy_Ericson, and avoid hassle "no such name on mailing list, perhaps one of your other names is vectoring to it, can you guess what it might be?". This documentation of vectoring would be analagous to Received: from MIT-MC.ARPA by SAIL.STANFORD.EDU which traces the host path. Tracing of both host path and recipient-name vector/expansion is needed. ------- 24-Dec-85 17:45:43-PST,2131;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Tue 24 Dec 85 17:44:40-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 24 Dec 85 16:36:32-PST Date: 24 Dec 1985 16:32:09 PST Subject: RFC969 Now Available From: To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 969: Title: NETBLT: A Bulk Data Transfer Protocol Author: D. Clark, M. Lambert, and L. Zhang Mailbox: markl@MIT-BORAX.ARPA Pages: 15 Characters: 40,894 pathname: RFC:RFC969.TXT This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 27-Dec-85 16:07:26-PST,2418;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 27 Dec 85 16:07:12-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 27 Dec 85 14:35:30-PST Date: 27 Dec 1985 14:31:38 PST Subject: RFC970 Now Available From: To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 970: Title: On Packet Switches With Infinite Storage Author: John Nagle Mailbox: jbn@FORD-WDL1.ARPA Pages: 9 Characters: 24,966 pathname: RFC:RFC970.TXT The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 29-Dec-85 02:46:48-PST,1899;000000000000 Return-Path: Received: from ICSE.UCI.EDU (for ICSE.UCI.EDU) by USC-ECLC.ARPA; Sun 29 Dec 85 02:42:23-PST Received: from localhost by ICSE.UCI.EDU id a009821; 29 Dec 85 0:39 PST BBoard-ID: 93 BB-Posted: Sat, 21 Dec 85 15:11:15 PST Received: from uci.edu by ICSE.UCI.EDU id a012675; 21 Dec 85 15:09 PST Received: from bboards by UCI.EDU id a002033; 21 Dec 85 15:09 PST Received: from brl-aos.arpa by UCI.EDU id a002031; 21 Dec 85 15:08 PST Received: from sri-nic.arpa by AOS.BRL.ARPA id a022273; 21 Dec 85 17:53 EST Date: Sat 21 Dec 85 14:50:51-PST From: Ole Jorgen Jacobsen Subject: Re: Subject: Managing distribution lists To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.arpa cc: Message_Group_at_BRL_mailing_list%QZCOM.MAILNET@mit-multics.arpa, MsgGroup@brl-aos.arpa, OLE@sri-nic.arpa In-Reply-To: <142751@QZCOM> SRI-International: (415) 859-4536 Home: (415) 325-9427 Message-ID: <12168974035.17.OLE@SRI-NIC.ARPA> ReSent-To: msggroup@usc-eclc.arpa Resent-Date: 29 Dec 85 00:37:15 PST (Sun) Resent-From: Einar Stefferud Sorry to hear that there are still such awful machines and operating systems around which do not allow user invalidation and cannot return mail to "invalid" individual users. I think registering D-lists locally makes sense if everyone uses a local redistribution facility, i.e. your system only receives one copy from "the net", a practice which is becoming more and more popular these days. But what if my "mailing list administrator" decides to enforce some control on who should be on what list? A central person/database if probably OK in the COM monolith, but I am afraid it would cause many political and practical problems in the ARPA Internet. Mailing lists are touchy things! Ole ------- 29-Dec-85 02:46:50-PST,2634;000000000000 Return-Path: Received: from ICSE.UCI.EDU (for ICSE.UCI.EDU) by USC-ECLC.ARPA; Sun 29 Dec 85 02:42:34-PST Received: from localhost by ICSE.UCI.EDU id a009824; 29 Dec 85 0:39 PST BBoard-ID: 96 BB-Posted: Sat, 21 Dec 85 23:06:10 PST Received: from uci.edu by ICSE.UCI.EDU id a013365; 21 Dec 85 23:03 PST Received: from bboards by UCI.EDU id a003706; 21 Dec 85 23:02 PST Received: from brl-aos.arpa by UCI.EDU id a003704; 21 Dec 85 23:01 PST Received: from mit-multics.arpa by AOS.BRL.ARPA id a023048; 22 Dec 85 1:45 EST Date: Sun, 22 Dec 85 01:35 EST From: Frankston@mit-multics.arpa Subject: Re: Subject: Managing distribution lists cc: MsgGroup Message-ID: <851222063535.762401@MIT-MULTICS.ARPA> ReSent-To: msggroup@usc-eclc.arpa Resent-Date: 29 Dec 85 00:38:24 PST (Sun) Resent-From: Einar Stefferud Mailing lists that are maintained across authority domains and cannot be globally managed. One should not so much expect to assure that user names are properly removed from all containing mailing lists as much as gracefully handle their nonremoval. This is nontrivial since a user name disappearing may be a transient event due to a system error. With automatic redistribution locating the offending entries may be nearly impossible. Aids in tracking down invalidated entries help. For indicating where a given name originated (i.e., from which redistribution list) helps. Bad entries in mailing lists has been a chronic problem on the net and each case has been laboriously tracked down and solved. In worldnet there may be no means of doing so. One approach is to treat large distribution lists as open loop systems and not attempt to assure delivery beyond a some arbitrary level of reliability. For example, once an intermediate system has accepted the message it then has local responsibility. At the far end of the list a user who is unavailable for 24 hours may lose the message. The solution is to implement a discussion group mechanism which each entry sequentially tagged so that the recipient can ascertain that a message has been lost and request its retransmission. The actual details of such a system are pretty open to discussion, but the basic point is that the current methods of using mailing lists do not scale and some thought needs to be given to alternative mechanisms for lists that are large and/or cross authority domains. I should also point out that the current distribution lists are very useful and should be maintained. It is just that their limits should be recognized. 8-Jan-86 12:31:11-PST,2122;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 8 Jan 86 12:30:54-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 8 Jan 86 10:17:52-PST Date: 8 Jan 1986 10:09:19 PST Subject: RFC971 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 971: Title: A Survey of Data Representation Standards Author: Annette L. DeSchon Mailbox: DeSchon@USC-ISIB.ARPA Pages: 9 Characters: 22883 pathname: RFC:RFC971.TXT This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 14-Jan-86 12:59:31-PST,1854;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Tue 14 Jan 86 12:59:20-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 14 Jan 86 10:33:26-PST Date: 14 Jan 1986 10:32:36 PST Subject: RFC972 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 972: Title: Password Generator Protocol Author: F. Wancho Mailbox: Wancho@SIMTEL20.ARPA Pages: 2 Characters: 3890 pathname: RFC:RFC972.TXT This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 31-Jan-86 16:39:52-PST,2217;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 31 Jan 86 16:35:51-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 31 Jan 86 14:33:35-PST Date: 31 Jan 1986 14:30:49 PST Subject: RFC973 and RFC974 Now Available From: Ann Westine To: Request-For-Comments-List: ; New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 973: Title: Domain System Changes and Observations Author: Paul Mockapetris Mailbox: MOCKAPETRIS@USC-ISIB.ARPA Pages: 10 Characters: 22364 Pathname: RFC:RFC973.TXT This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system. Distribution of this memo is unlimited. RFC 974: Title: Mail Routing and the Domain System Author: Craig Partridge Mailbox: CRAIG@BBN-UNIX.ARPA Pages: 7 Characters: 18581 Pathname: RFC:RFC974.TXT This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 13-Feb-86 14:21:02-PST,1875;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Thu 13 Feb 86 14:20:35-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Feb 86 11:55:41-PST Date: 13 Feb 1986 11:43:19 PST Subject: RFC975 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 975: Title: Autonomous Confederations Author: Dave Mills Mailbox: MILLS@USC-ISID.ARPA Pages: 10 Characters: 28010 pathname: RFC:RFC975.TXT This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of the core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 28-Feb-86 21:03:17-PST,2701;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 28 Feb 86 21:02:58-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 28 Feb 86 14:22:36-PST Date: 28 Feb 1986 14:18:06 PST Subject: RFC976 and RFC977 Now Available From: Ann Westine To: Request-For-Comments-List: ; New Requests for Comments are now available from the Network Information Center in the directory at SRI-NIC.ARPA. RFC 976: Title: UUCP Mail Interchange Format Standard Author: Mark. R. Horton Mailbox: HORTON@UCB-VAX.ARPA Pages: 12 Characters: 26814 Pathname: RFC:RFC976.TXT This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone. Distribution of this memo is unlimited. RFC 977: Title: Network News Transfer Protocol Author: Brian Kantor & Phil Lapsley Mailbox: BRIAN@SDCSVAX.ARPA Pages: 27 Characters: 55062 Pathname: RFC:RFC977.TXT NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 5-Mar-86 01:43:49-PST,1776;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 5 Mar 86 01:39:21-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 4 Mar 86 15:31:02-PST Date: 4 Mar 1986 15:10:35 PST Subject: RFC978 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 978: Title: Voice File Interchange Protocol (VFIP) Author: J. K. Reynolds, R. Gillmann, W. A. Brackridge, A. Witkowski & J. Postel Mailbox: JKREYNOLDS@USC-ISIB.ARPA Pages: 5 Characters: 9223 pathname: RFC:RFC978.TXT The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 17-Mar-86 12:45:38-PST,2106;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Mon 17 Mar 86 12:45:20-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 17 Mar 86 10:00:59-PST Date: 17 Mar 1986 10:00:11 PST Subject: RFC979 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 979: Title: PSN End-to-End Functional Specification Author: Andrew G. Malis Mailbox: MALIS@BBNCCS.ARPA Pages: 15 Characters: 39472 pathname: RFC:RFC979.TXT This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification" and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 20-Mar-86 15:58:57-PST,1749;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Thu 20 Mar 86 15:57:34-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 19 Mar 86 11:44:46-PST Date: 19 Mar 1986 11:27:18 PST Subject: RFC980 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 980: Title: Protocol Document Order Information Author: Ole Jacobsen and Jon Postel Mailbox: OLE@SRI-NIC.ARPA Pages: 12 Characters: 24416 pathname: RFC:RFC980.TXT This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT). Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 25-Mar-86 23:29:41-PST,2110;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Tue 25 Mar 86 23:27:07-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 21 Mar 86 13:21:00-PST Date: 21 Mar 1986 13:14:43 PST Subject: RFC981 Now Availale From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 981: Title: An Experimental Multiple-Path Routing Algorithm Author: D. L. Mills Mailbox: MILLS@USC-ISID.ARPA Pages: 22 Characters: 59069 pathname: RFC:RFC981.TXT This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 10-Apr-86 05:26:37-PST,2146;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Thu 10 Apr 86 05:26:11-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 10:50:44-PST Date: 9 Apr 1986 10:40:29 PST Subject: RFC982 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 982: Title: Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address Author: ANSI Mailbox: HWB@GW.UMICH.EDU Pages: 11 Characters: 22595 pathname: RFC:RFC982.TXT This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 21-Apr-86 16:06:30-PST,2297;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Mon 21 Apr 86 16:02:58-PST Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 21 Apr 86 10:52:00-PST Date: 21 Apr 1986 10:45:53 PST Subject: RFC983 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 983: Title: ISO Transport Services on Top of the TCP Author: D. E. Cass and M. T. Rose Mailbox: DCass%NRTC@USC-ECL.ARPA Pages: 27 Characters: 59819 pathname: RFC:RFC983.TXT This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 2-May-86 23:39:44-PDT,2434;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Fri 2 May 86 23:38:36-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 2 May 86 21:47:55-PDT Date: 2 May 1986 21:34:20 PDT Subject: RFC984 Now Available From: To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 984: Title: PCMAIL: A Distributed Mail System for Personal Computers Author: David D. Clark & Mark L. Lambert Mailbox: markl@BORAX.LCS.MIT.EDU Pages: 31 Characters: 69333 pathname: RFC:RFC984.TXT This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 14-May-86 16:14:40-PDT,2278;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 14 May 86 16:14:05-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 14 May 86 11:41:01-PDT Date: 14 May 1986 11:39:27 PDT Subject: RFC985 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 985: Title: Requirements for Internet Gateways -- Draft Author: Network Technical Advisory Group Mailbox: MILLS@ISID.ARPA Pages: 23 Characters: 59221 pathname: RFC:RFC985.TXT This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification. Suggestions and comments on this document are welcomed and can be sent to Dave Mills (mills@usc-isid.arpa) or Dave Farber (farber@huey.udel.edu). Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 3-Jun-86 21:06:46-PDT,2059;000000000011 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Tue 3 Jun 86 21:05:35-PDT Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Jun 86 15:20:56-PDT Date: 3 Jun 1986 15:20:20 PDT Subject: RFC986 Now Available From: Ann Westine To: Request-For-Comments-List: ; A new Request for Comments is now available from the Network Information Center in the online library at SRI-NIC.ARPA. RFC 986: Title: WORKING DRAFT Guidelines for the Use of Internet-IP Addresses in the ISO Connectionless-Mode Network Protocol Author: Ross Callon Mailbox: RCALLON@BBN-UNIX.ARPA Pages: 7 Characters: 13947 pathname: RFC:RFC986.TXT This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DoD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Public access files may be copied from the directory at SRI-NIC.ARPA via FTP with username ANONYMOUS and password GUEST. The normal method for distribution of RFCs is for interested parties to copy the documents from the NIC online library using FTP. Requests for special distribution should be addressed to either the author of the RFC in question or to NIC@SRI-NIC.ARPA. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@USC-ISIB.ARPA. Requests to be added to or deleted from this distribution list should be sent to NIC@SRI-NIC.ARPA. --jon. ------- 11-Jun-86 13:41:22-PDT,552;000000000000 Return-Path: Received: from SRI-NIC.ARPA (for SRI-NIC) by USC-ECLC.ARPA; Wed 11 Jun 86 13:38:29-PDT Date: Wed 11 Jun 86 13:37:40-PDT From: DDN Reference Subject: Re: RFC986 Now Available To: MSGGROUP@USC-ECLC.ARPA cc: NIC@SRI-NIC.ARPA In-Reply-To: <12213887688.40.MSGGROUP@USC-ECLC.ARPA> Message-ID: <12214038559.20.NIC@SRI-NIC.ARPA> Hi Stef, Your message was forwarded from Ann Westine to NIC@SRI-NIC. I have made the changes to the RFC distribution list that you requested. Regards, Nan -------