pgf@mtung.ATT.COM (Paul Fox) (07/02/87)
Okay, so I've got a question. First let me say that I know next to nothing about this stuff, though I do understand the concept of domains etc. I am relatively naive about mail/uucp networking issues. Please don't chop my head off... Why wouldn't the following be a "good thing"?: Let's assume that for quite some time there will be UNIX boxes around that know nothing about domains. I don't think that's too farfetched. Let's assume that I use one regularly. Don't even assume that. I do. Let's also assume that I want to send mail to a friend who logs into a similar box running similarly antiquated (you say) software. It used to be that I could send mail to friend on theirbox via various machines as: mail mach1!mach2!theirbox!friend And *sometimes* they could reply as: mail mach2!mach1!mybox!pgfox At other times (or for other friends), the path would not be reversible, and different hops would be used: mail mach3!mach4!mybox!pgfox This is the anarchy we've all grown to know and love, expressed in an incredibly intuitive (I think) syntax. Now if I ruled the world, and had thought of domains (which I might not have, that's a different problem), I might have tried to preserve the syntax so beloved to all of my subjects, and invented some "meta-machines" for people to send mail through, as in: mail EDU!UNIV!theirbox!friend The path is non-reversible, of course. My friend would type: mail COM!ATT!mtune!pgfox but that's okay, because we're already used to non-reversible paths. The reason I mention this is that it extends naturally to the current situation where neither mybox nor theirbox speaks domains. If we assume we both talk to machines that do know domains (mine is mtune), then we get: mail mtune!EDU!UNIV!theirneighbor!theirbox!friend and of course: mail theirneighbor!COM!ATT!mtune!mybox!pgfox In reality, of course, mtune, which understands domains, will eat both the EDU and the UNIV "meta-machines", treating them however it does now in "theirneighbor@UNIV.EDU". I thinks this also eliminates precedence problems (of the NO NO NO NO NO variety. (As well as the problem that my addresses are always being swallowed by my line kill character. :-) Okay-- I've proved my ignorance-- rip me apart. By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM", but I *know* I can be reached at "ihnp4!mtung!pgf". -- Paul Fox, AT&T Information Systems, Middletown NJ. [ihnp4|vax135]!mtung!pgf (201)957-2698
pdb@sei.cmu.edu (Patrick Barron) (07/03/87)
In article <969@mtung.ATT.COM> pgf@mtung.UUCP (gws-Paul Fox) writes:
-> The reason I mention this is that it extends naturally to the
-> current situation where neither mybox nor theirbox speaks
-> domains. If we assume we both talk to machines that do know
-> domains (mine is mtune), then we get:
->
-> mail mtune!EDU!UNIV!theirneighbor!theirbox!friend
->
-> and of course:
->
-> mail theirneighbor!COM!ATT!mtune!mybox!pgfox
->
-> In reality, of course, mtune, which understands domains, will
-> eat both the EDU and the UNIV "meta-machines", treating them
-> however it does now in "theirneighbor@UNIV.EDU".
There already is such a thing, though it doesn't work quite the way you
describe. Check out RFC 976, "UUCP Mail Interchange Format Standard".
According to that, your first example would become:
mail mtune!UNIV.EDU!theirneighbor!theirbox!friend
Since mtune understands domains, it should be able to deal with the UNIV.EDU
part, and your mail gets sent happily along its way. It's almost, but not
quite, what your idea says. The big problem with your system is: what if
EDU or UNIV, or whatever other meta-machines you might recognize, are
coincidentally the *real* names of *real* machines?
-> I thinks this also eliminates precedence problems (of the NO
-> NO NO NO NO variety. (As well as the problem that my
-> addresses are always being swallowed by my line kill
-> character. :-)
Try "stty dec". Oh, wait, you work for AT&T, right? Ooops, never mind. :-)
->
-> Okay-- I've proved my ignorance-- rip me apart.
->
-> By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM",
-> but I *know* I can be reached at "ihnp4!mtung!pgf".
From a domain-based machine, it would more likely be "mtune!p.g.fox@ATT.COM".
->--
-> Paul Fox, AT&T Information Systems, Middletown NJ.
-> [ihnp4|vax135]!mtung!pgf (201)957-2698
--Pat.diamant@hpfclp.HP.COM (John Diamant) (07/04/87)
> Okay, so I've got a question. First let me say that I know > next to nothing about this stuff, though I do understand the > concept of domains etc. I am relatively naive about mail/uucp > networking issues. Please don't chop my head off... That's O.K. This is complicated stuff. > > Why wouldn't the following be a "good thing"?: > > Now if I ruled the world, and had thought of domains (which I > might not have, that's a different problem), I might have > tried to preserve the syntax so beloved to all of my subjects, > and invented some "meta-machines" for people to send mail > through, as in: > > mail EDU!UNIV!theirbox!friend > > The path is non-reversible, of course. My friend would type: > > mail COM!ATT!mtune!pgfox > > but that's okay, because we're already used to non-reversible paths. > > I thinks this also eliminates precedence problems (of the NO > NO NO NO NO variety. (As well as the problem that my > addresses are always being swallowed by my line kill > character. :-) Well, it doesn't. I'll explain below. > > Okay-- I've proved my ignorance-- rip me apart. The problem is you are assuming a "bangist" world. The ARPANET (and now the ARPA Internet) has been using "@" for a long time already and they are officially sanctioned and supported by the Network Information Center. UUCP on the other hand, is an anarchy that is trying to get somewhat organized. If "@" never existed, then your suggestion would avoid the ambiguity. But "@" is about as old as "!" (I'm not sure which actually appeared first), so the problem remains. The larger question is which one is better. What you were almost doing above is reinventing domains, except that you were unwilling to make the break and say that these things were no longer routes, but were now addresses (the difference being that a route tells you how to get somewhere and an address simply tells you where someone is in an absolute coordinate system -- like a mail address on an envelope to the post office; imagine what would happen if you had to know the route in order to send a letter to the post office). Well, given an ever expanding network, addresses are clearly superior to routes because it puts the burden on the computer instead of the human. All it involves is upgrading some software (and smail which does much of this for you is free and doesn't require a source license, so anyone can use it if they don't have other alternatives). The next question is whether "!" or "@" is superior. Besides the obvious point that "@" actually means something having to do with location and "!" doesn't, one really isn't superior to the other. The reason why "@" is preferred is that the rules and standards for using "@" style addressing are official and sanctioned. The "!" stuff is all folk-lore and unofficial. For no other reason than to improve consistency and standardization, it makes sense to move to the standardized addressing format. This allows people to intelligently discuss whether a particular mailer conforms to the standards (which are fairly explicit, though there is an occasional ambiguity) or not. > > By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM", > but I *know* I can be reached at "ihnp4!mtung!pgf". You're address is fox@mtune.ATT.COM, not fox@mtune!ATT.COM. I don't think any mailer will except a "!" after an "@" (except that there are contorted cases with ARPA style source routes and UUCP stuff mixed in where this would happen, but even then there would be an "@" as the right-most meta-character). > > -- > Paul Fox, AT&T Information Systems, Middletown NJ. > [ihnp4|vax135]!mtung!pgf (201)957-2698 > ---------- John Diamant TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
paul@vixie.UUCP (Paul Vixie Esq) (07/05/87)
In article <969@mtung.ATT.COM> pgf@mtung.UUCP (gws-Paul Fox) writes: |Okay, so I've got a question. First let me say that I know |next to nothing about this stuff, though I do understand the |concept of domains etc. I am relatively naive about mail/uucp |networking issues. Please don't chop my head off... Okay :-). |Why wouldn't the following be a "good thing"?: ... |It used to be that I could send mail to friend on theirbox via |various machines as: | mail mach1!mach2!theirbox!friend |And *sometimes* they could reply as: | mail mach2!mach1!mybox!pgfox | |At other times (or for other friends), the path would not be |reversible, and different hops would be used: | mail mach3!mach4!mybox!pgfox | |This is the anarchy we've all grown to know and love, |expressed in an incredibly intuitive (I think) syntax. I wouldn't call it anarchy - there IS structure to it. FYI, !-paths are a form of what's called 'source routing', and also fall generally under the term (loosely applied here): "route-address". |Now if I ruled the world, [...] | mail EDU!UNIV!theirbox!friend |The path is non-reversible, of course. My friend would type: | mail COM!ATT!mtune!pgfox |but that's okay, because we're already used to non-reversible paths. You and your friend are used to non-reversible paths. As the general public begins to use this stuff, they need to be able to just say 'reply' and have the message get back to the sender. This is one of the reasons why domains were "invented". Your syntax will actually work on some hosts, because of the way the first steps of address parsing ("canonicalization" or "homogenation") are sometimes done. (Please, don't anyone press me for specifics! I have a sendmail.cf that I'm experimenting with that would accept this -- quite by accident). However, the syntax that most domain-uucp hosts would accept is: mail theirbox.UNIV.EDU!friend which means that "domain!user" when there's only one "!" will often be taken as equivilent to "user@domain". |If we assume we both talk to machines that do know |domains (mine is mtune), then we get: | mail mtune!EDU!UNIV!theirneighbor!theirbox!friend mail mtune!theirneighbor.UNIV.EDU!theirbox!friend |and of course: | mail theirneighbor!COM!ATT!mtune!mybox!pgfox mail theirneighbor!mtime.ATT.COM!mybox!pgbox |In reality, of course, mtune, which understands domains, will |eat both the EDU and the UNIV "meta-machines", treating them |however it does now in "theirneighbor@UNIV.EDU". The variants I've shown above will work on most or all UUCP/domain hosts, already. I think they are cleaner and more elegant (and more intuitive to the uninitiated!) than what you suggest. |Okay-- I've proved my ignorance-- rip me apart. Hardly. Or at least, I hope not. |By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM", |but I *know* I can be reached at "ihnp4!mtung!pgf". |-- | Paul Fox, AT&T Information Systems, Middletown NJ. | [ihnp4|vax135]!mtung!pgf (201)957-2698 You can probably be reached at: p.g.fox@mtune.ATT.COM pgfox@mtune.ATT.COM mtune.ATT.COM!pgfox mtung!pgfox pgfox@mtung.UUCP (I notice that mtunE is different from mtunG, which probably causes some confusion. I have both in my maps here...) -- Paul A. Vixie, Esq. "A viler evil than to throw a man into a paul%vixie@uunet.uu.net sacrificial furnace, is to demand that he {uunet,ptsfa,hoptoad}!vixie!paul leap in, of his own free will, and that he San Francisco, (415) 647-7023 build the furnace, besides." (Ayn Rand)
mc68020@nonvon.UUCP (07/08/87)
> > The problem is you are assuming a "bangist" world. The ARPANET (and now > the ARPA Internet) has been using "@" for a long time already and they are > officially sanctioned and supported by the Network Information Center. UUCP > on the other hand, is an anarchy that is trying to get somewhat organized. > If "@" never existed, then your suggestion would avoid the ambiguity. But > "@" is about as old as "!" (I'm not sure which actually appeared first), so > the problem remains. OK! Who and WHAT is the Network Information Center. By what authority does this organization "sanction" anything? I have been hearing references to NIC for about a year now. I'd sure like to know who those Nazis are!
tli@sargas.usc.edu (Tony Li) (07/09/87)
In article <599@nonvon.UUCP> mc68020@nonvon.UUCP (root) writes:
OK! Who and WHAT is the Network Information Center. By what authority
does this organization "sanction" anything? I have been hearing references
to NIC for about a year now. I'd sure like to know who those Nazis are!
The NIC is the organization contracted to DARPA to run the Arpanet.
(BBN is responsible for day to day operations of the physical
network.) NIC is the central clearinghouse for user information and
official protocol information.
As far as for their being Nazis, please remember -- DARPA pays for
their network. They can do what they want. If you don't want to talk
to the Internet, that's fine.
;-)
Tony Li - USC University Computing Services "Fene mele kiki bobo"
Uucp: oberon!tli -- Joe Isuzu
Bitnet: tli@uscvaxq, tli@ramoth
Internet: tli@sargas.usc.edubrian@sdcsvax.UUCP (07/09/87)
[ NETINFO:WHAT-THE-NIC-DOES.TXT ] [ ND, 8/86 ]
THE DDN NETWORK INFORMATION CENTER (NIC)
The DDN Network Information Center (NIC) is located at SRI
International, Menlo Park, CA, and is funded by the Defense Data
Network (DDN) Defense Communications System (DCS) to provide general
user services to DDN users via telephone, electronic mail, and U.S.
postal mail.
The NIC works closely with the network Host Administrators, Node Site
Coordinators, Responsible Persons, network protocol groups, vendors,
contractors, government agencies, and military sponsors to assist new
users and potential subscribers in obtaining pertinent network
information.
Databases and information servers of interest to network users are
provided, including the WHOIS registry of network users, the NIC/Query
browsing system, TACNEWS, and the official DoD Host Name Service. The
NIC also serves as the DDN Protocol Repository, and will soon be
providing a BIBLIO server for identifying network documents. The NIC
is the source for official DDN protocol documents (other than the
MIL-STDs), as well as other DDN documents, and maintains the RFC
(Request for Comments) collection. The NIC also registers network
users and issues MILNET TAC access cards.
I. USER ASSISTANCE SERVICE
Toll-free telephone service is available Monday through Friday, 7 am
to 5 pm, Pacific time. Users who experience problems with using the
network in general, and with terminal-to-TAC use, in particular, are
encouraged to make use of this service.
Toll-free: (800) 235-3155
International: +1 415 859-3695
II. NIC ONLINE MAILBOXES
To contact the NIC via electronic mail 24 hours a day, 7 days a
week, use these mailboxes:
NIC@SRI-NIC.ARPA General user assistance, document requests
REGISTRAR@SRI-NIC.ARPA User registration and WHOIS updates
HOSTMASTER@SRI-NIC.ARPA Hostname and domain changes and updates
ACTION@SRI-NIC.ARPA SRI-NIC computer operations
SUGGESTIONS@SRI-NIC.ARPA Comments on NIC publications and services
FEINLER@SRI-NIC.ARPA Manager, NIC
III. NIC U.S. POSTAL ADDRESS
Send U.S. postal mail correspondence to:
DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025
IV. NIC COMPUTER SERVICES
The NIC host computer is a DEC-2065, running the TOPS20 operating
system, and its hostname is SRI-NIC. It has two network addresses,
and so is accessible from either the MILNET or the ARPANET. The
network addresses are:
26.0.0.73 (MILNET)
10.0.0.51 (ARPANET)
NIC online services are available 24 hours a day, 7 days a week.
Operations personnel are in attendance from 4 am - 11 pm weekdays, and
8 am - midnight weekends, Pacific time. NIC operators are available
at (415) 859-5921.
V. DOCUMENTS DISTRIBUTED BY THE NIC
The NIC publishes and distributes the following documents, all of
which are available in hardcopy and some of which are available
online. Many of these documents are deposited at the Defense
Technical Information Center (DTIC). An annotated list of NIC
publications is found in the file NETINFO:NIC-PUBS.TXT on SRI-NIC.
Title Online Filename
ARPANET Information Brochure . . . . . . . . . . . . . . NETINFO:AIB.DOC
DDN Defense Data Network Brochure
DDN Directory
DDN New User Guide . . . . . . . . . . . . . . . . . . . NETINFO:NUG.DOC
DDN Newsletters. . . . . . . . . . . . . . . . .DDN-NEWS:DDN-NEWS-nn.TXT
DDN Management Bulletins . . . . . . . .DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT
DDN Protocol Implementations and Vendors Guide . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .NETINFO:VENDORS-GUIDE.DOC
DDN Protocol Handbook
DDN Subscriber Interface Guide
DDN Subscriber Security Guide
DDN X.25 Host Interface Specification. . . . . . . . . . NETINFO:X25.DOC
Interface Message Processor
Logical and Geographic Maps of MILNET and ARPANET
RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . .RFC:RFCnnn.TXT
RFC Index. . . . . . . . . . . . . . . . . . . . . . . RFC:RFC-INDEX.TXT
TAC Users' Guide . . . . . . . . . . . . . . . . . .NETINFO:TAC-USER.DOC
NOTE: In the filenames, the "nn" or the "nnn" should be replaced by the
number of the newsletter, bulletin or RFC.
VI. ONLINE INFORMATION SERVERS
TACNEWS
TACNEWS offers login help for MILNET TAC users, includes the current
list of ARPANET and MILNET TAC dial-up numbers, and provides a
mechanism for reading the DDN Newsletters and Management Bulletins.
Users should read these newsletters and bulletins regularly to stay
current on DDN policies, announcements, and network news items.
Accessing TACNEWS
From a TAC: @n <Return>
From TELNET: connect SRI-NIC
At the SRI-NIC system prompt "@": tacnews <Return>
WHOIS/NICNAME
WHOIS/NICNAME is a NIC program that provides an electronic "white
pages" of network users. It lists the name, network mailbox, U.S.
postal address, telephone number, and host for all registered users.
Accessing WHOIS/NICNAME
From TELNET: connect SRI-NIC
At the SRI-NIC system prompt "@": whois help <Return> or
nicname help <Return>
WHOIS/NICNAME may also be run from a local host. WHOIS/NICNAME user
programs for several operating systems are available from the NIC.
Contact the NIC for copies.
NIC/QUERY
NIC/QUERY contains host information, protocol and other document
information, and access to WHOIS/NICNAME. NIC/QUERY is geared toward
novice or casual users.
Accessing NIC/QUERY
From TELNET: connect SRI-NIC
At the SRI-NIC system prompt "@": nic <Return>
NAMSER
NAMSER is an internet hostname server on SRI-NIC port 101 decimal.
This server delivers machine-translatable hostname/address/attribute
information for networks, gateways, and hosts within the DDN. The
server can deliver a single response or the entire host table,
depending upon the type of query sent. The server provides the
information outlined in RFC 952 and is itself described in RFC 953.
Accessing NAMSER
From TELNET: connect SRI-NIC 101 <Return>
help <Return>
VII. ONLINE FILES
The NIC maintains a number of online files which are available to
network subscribers via file transfer (FTP). These files contain
information about protocols, site personnel, hosts and other subjects
relevant to network users. See the file 00NETINFO:NETINFO-INDEX.TXT for
an index to the files in the NETINFO directory. See also the DDN New
User Guide, or contact the NIC User Assistance service for more
information.
To retrieve any of the NIC's public files, use your local FTP program,
connect to the SRI-NIC host, and log in as "anonymous" with password
of "guest" (known as the "anonymous login convention"). FTP servers
differ slightly from host to host, so please consult your Host
Administrator for instructions, if needed.
VIII. USER REGISTRATION
Host Administrators have overall responsibility for registering their
users. When new users come onto a MILNET host, their Host
Administrator must complete a NIC-generated template to register them
in the NIC database. Registration is voluntary for ARPANET users.
Host Administrator names and addresses are on the SRI-NIC host in the
files NETINFO:MIL-HOST-ADMINISTRATORS.TXT and
NETINFO:ARPA-HOST-ADMINISTRATORS.TXT.
Users who require MILNET TAC dial-up access to reach their host must
have a TAC Access card, which is provided by the NIC. Approval for
distributing the card is sent to the NIC from the user's Host
Administrator. Until the user is permanently registered, there are
temporary "Guest" TAC cards available from the Host Administrator for
immediate use.
ARPANET TAC use is authorized by "Responsible Persons" of DARPA
organizations. A list of DARPA Responsible Persons is in the file
NETINFO:RESPONSIBLE-PERSONS.TXT on the SRI-NIC host.david@ukma.UUCP (07/09/87)
In article <599@nonvon.UUCP> mc68020@nonvon.UUCP (root) writes: >> >> The problem is you are assuming a "bangist" world. The ARPANET (and now >> the ARPA Internet) has been using "@" for a long time already and they are >> officially sanctioned and supported by the Network Information Center. >> [ ... ] > OK! Who and WHAT is the Network Information Center. By what authority >does this organization "sanction" anything? I have been hearing references >to NIC for about a year now. I'd sure like to know who those Nazis are! Why, by their *own* authority of course ... :-) Seriously. The arpanet is where the domainist stuff was developed. The Network Information Center (better known as sri-nic.arpa or nic.sri.com) is the people who did the work to organize the domains and such. (sure, there were technical people everywhere working on it, but they did the political/administrative part of the organizing). Their name implies their function. They keep all of the information about the hosts and connectivity in the ARPA/Internet. They directly administer the top-level domain names and the second levels of the US domains (EDU, GOV, ORG, MIL, etc). They get to do this because the DOD hired them to do it. -- ----- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet ----- {uunet,cbosgd}!ukma!david, david@UKMA.BITNET ----- bsmtp-users@ms.uky.edu for bsmtp discussion ----- bsmtp-users-request@ms.uky.edu for administrivia
aad+@andrew.cmu.edu (Anthony A. Datri) (07/11/87)
These Nazi's are the us government, sort of. Part of SRI, the NIC people sort of administer the Arpanet. Among other things, they put out all those RFC's that everyone's been arguing about. There are some machines, like the God-like seismo, that can figure out just about any semi-reasonable way you have of addressing something. For instance, if you wanted to send me mail on my favorite PDP-10 over the arpanet, you'd send to ad0r@tb.cc.cmu.edu. However, some uucp sites don't understand that, but they can use seismo!tb.cc.cmu.edu!ad0r and have it work just fine. To look at that address, you'd think that tb was a uucp machine, when in fact this isn't really a terribly official path, but seismo gets the idea. The problem is that in the past the major networks were stayed pretty much away from each other. Now, as we get more and more machines, and more and more machines on more than one net, people are faced with the problem of making their software compatible with everyone elses.