honey@down.FUN (Peter Honeyman) (09/14/85)
In [552@down], I compared the uucp and domain name spaces. This note continues that (one-sided) debate. .UUCP never was, ain't now, and never will be a domain. But .UUCP is just the tip of the iceberg. I am seeing strange and wonderful domain addresses proposed in net.mail and elsewhere, as well as in mail headers: cbosgd.ATT.UUCP cbosgd.IL.USA.UUCP down.PRINCETON.EDU ittvax.ATC.ITT.UUCP utzoo.TORONTO.EDU utzoo.ON.CAN vortex.DEC vortex.UUCP I view this morass with utter bewilderment, bordering on contempt, since not one of the above is truly a domain (as defined in RFCs 819 and 920). I am in no better position to produce electronic routes for the above than for their domain-free equivalents. A top-level domain is one that is recognized as such by sri-nic. Subdomains are registered with the authority for the higher-level domain. Nothing else fits the bill. Many contributors to this newsgroup view domains as a naming scheme, nothing more. This gives cold comfort to programmers (like me), after all a domain authority and name service might be exploited in pathalias and pathparse. But without these attributes, there is no stopping two postmasters from asserting "that's MY domain." This leaves me (and all of us) holding the ball. Haphazard invention of domain names adds no expressive power. In particular, attaching .UUCP to a host name is about as useful as running it through DES. Domains serve to facilitate name space control. They require administration from above and consent from below. In [552@down], I argued that the style and substance of uucp addressing is incompatible with domains. I still don't have the answer to questions like 1) What do I do with "bilbo.UUCP"? (There are at least three uucp hosts named bilbo.) 2) By what reasoning is "cbosgd.ATT.UUCP" better than "cbosgd"? (Any answer must satisfy members of the Albanian Turban Traders domain.) 3) What does .IL.USA.UUCP mean? RFC 920 [p. 11] asks for "the name, title, mailing address, phone number, and organization of the administrative head of the organization." Who will answer? The issues are not whether geographic domains make sense, or whether trailing dots are allowed, or even how d.osg.cb.att.uucp should be routed; the issues are more basic than that. Absent any concrete mechanism for name space control (and enforcement!) in the uucp "domain", I take a dim view of debates over the fine points. Peter
jordan@ucbvax.ARPA (Jordan Hayes) (09/15/85)
In article <583@down.FUN> honey@down.FUN (Peter Honeyman) writes: >Domains serve to facilitate name space control. They require >administration from above and consent from below. In [552@down], I >argued that the style and substance of uucp addressing is incompatible >with domains. I still don't have the answer to questions like > > 1) What do I do with "bilbo.UUCP"? (There are at least three > uucp hosts named bilbo.) You tell us! Why do you think that's a valid question? Why are there at least 3 "bilbo"'s floating around? Because someone let them. That goes away with domains. You MUST fit yourself into the namespace, or you won't get mail -- it's built in for a purpose. Of course the "style and substance of uucp addressing is incompatible with domains" -- they are completely different and do not co-exist. One replaces the other. > 2) By what reasoning is "cbosgd.ATT.UUCP" better than > "cbosgd"? (Any answer must satisfy members of the > Albanian Turban Traders domain.) See your question above (#1)... Why is 1200 Jones Street Mytown, CA 94035 better than 1200 Jones Street on an envelope going across the country? This is really silly. > 3) What does .IL.USA.UUCP mean? RFC 920 [p. 11] asks for "the > name, title, mailing address, phone number, and organization > of the administrative head of the organization." Who will > answer? It means whatever the person/org/entity meant it to be who set it up (read "created" it...). You don't just *decide* that there will be this subdomain. The way you set it up is come to some agreement of a group of 2nd level domains with people to be responsibl;e for themm and then it is up to each of these people to decide when/how/why the next level is created. Scenario: Say, for example, it is decide that there will be a NCA.UUCP, and that I will be in charge of it. Then, say, someone with a whole bunch of machines says "Hey -- let me into the namespace", and I say "okay, here's a sub-domain for you to administer called FNG.NCA.UUCP to which he can now parcel further. See, the question is not "how to enforce it" but, rather, how to have it flow with the least amount of resistance. If there is someone to get information from, namespace collisions could be a thing of the past. BTW -- do you think that if those machines knew there were other machines called "bilbo" that they would have done the same thing? ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
avolio@decuac.UUCP (Frederick M. Avolio) (09/15/85)
In article <583@down.FUN>, honey@down.FUN (Peter Honeyman) writes: > In [552@down], I compared the uucp and domain name spaces. This note > continues that (one-sided) debate. > > .UUCP never was, ain't now, and never will be a domain. But .UUCP is > just the tip of the iceberg. I am seeing strange and wonderful domain > addresses proposed in net.mail and elsewhere, as well as in mail > headers: > > cbosgd.ATT.UUCP > cbosgd.IL.USA.UUCP > down.PRINCETON.EDU > ittvax.ATC.ITT.UUCP > utzoo.TORONTO.EDU > utzoo.ON.CAN > vortex.DEC > vortex.UUCP My dear fellow, you left out down.FUN! This'll be short since it has all been said and for one reason or another hasn't satisfied you. Since you define "domain" in terms of sri-nic ("A top-level domain is one that is recognized as such by sri-nic.") replace domain with domain-style when/where you see it. > I view this morass with utter bewilderment, bordering on contempt, > since not one of the above is truly a domain (as defined in RFCs 819 > and 920). I am in no better position to produce electronic routes for > the above than for their domain-free equivalents. To send to the above all you need do is know who the smart (so to speak) machines are who "know about" those domains. (For example, send vortex.DEC to us or to decwrl.) No bewilderment is intended. In any event, those "pseudo-domains" (okay?) are in place temporarily. --- Fred @ DEC -- ULTRIX Applications Center
dave@uwvax.UUCP (Dave Cohrs) (09/15/85)
Speaking of unofficial domain names, what about all of those pseudo-internet
addresses I see in news? It's really hard to reply to honey@down.FUN.
However, your points are valid. We run an internet mailer here, and
unofficial domain names are a real pain (read, manual interpretation).
Also, with no administration, we will end up with different people
with the same domain name, just like hosts with the name uw* can
mean U of Wisc. or U of Wash.
Our only recourse is the uucp map. Mel is doing a great job, I think,
keeping things straightened out (like getting rid of duplicate hostnames,
etc). If we go to domain-based addressing, this will be even more important.
We can't forget this.
--
Dave Cohrs
(608) 262-1204
...!{harvard,ihnp4,seismo,topaz}!uwvax!dave
dave@wisc-romano.arpahoney@down.FUN (Peter Honeyman) (09/23/85)
you may recall my three questions for those who believe in .UUCP:
1) bilbo.UUCP? (there are three.)
2) cbosgd.ATT.UUCP? (what makes .ATT special?)
3) .IL.USA.UUCP? (who runs it?)
i have seen three replies, from ucbvax!jordan, decuac!avolio, and
uwvax!dave. perhaps more are forthcoming, but i'll address the
rebuttals made by jordan and fred. (dave is a good guy, and his note
requires no illumination on my part.)
jordan misses the point by a wide mark. for (1), he turns the question
around ("you tell us!"). ok, jordan, to make it perfectly clear, i
can't do anything with bilbo.UUCP. on the other hand, princeton!bilbo,
u-mt!bilbo, or wiretap!bilbo yield useful routes.
after belittling the question, jordan goes on to attack it as
meaningless. he suggests that we all fit into some name space (or we
won't get mail) and dispense with uucp routing altogether. a fine
example of throwing out the baby with the bathwater. he claims that
domain addressing will replace uucp routing altogether. jordan should
read the uux man page.
for (2) jordan refers us to his answer to (1), again missing the mark.
the issue here is the haphazard creation of domain tokens, not the
inner meaning of rfc 819.
for (3), jordan approaches the heart of the issue ("you don't just
*decide* that there will be this subdomain"). he describes how domains
are created in an ideal rfc-world, ignoring the fact that our world has
NO such structure, NO such organization, nor any obvious movement in
that direction. i don't see jordan, or anyone else, volunteering to
act as the name server for .UUCP or any of its sub-ilk.
on to fred.
fred opens with a reference to down.FUN. hmmm. well, the plain truth
is, north and i wanted to eliminate the domainisms altogether, but upon
checking with horton, we were told that this would break netnews
software world-wide. we took him at his word, leaving us with a
dilemma: there was no .UUCP domain (still true), and we weren't in any
domain we knew about, so we dedicated our inews to the fun-people
mailing list. we did not confuse netnews with mail; don't you make
that mistake.
fred goes on to remark that "this has all been said" (not on my screen
it hasn't), and that i should ignore the rfc's and just pretend that
things like .DEC (and, i infer, .UUCP) exist. i call .DEC a standoff
-- i'll send *.DEC to fred if he'll admit that i have only his word
that it will work. but back to the point: .UUCP. will you take that
too, fred? me neither.
fred indicates that this bewilderment is all temporary. sure, and so
is the human condition.
any other takers out there? here's an easy one for jordan: once you
have replaced uucp addressing with domains, what will your delivery
agent do with honey@princeton.UUCP? uux is out, since it wants
something!princeton!honey. what's the trick?
petergds@mit-eddie.UUCP (Greg Skinner) (09/25/85)
Let us all back off from the issue of uucp routes vs. domain addressing
for a minute.
Domain addressing and uucp routing can coexist, just as domain
addressing and Internet routing coexist! It is just a matter of
separating the transport agent, uucp, from the presentation agent, which
can be /bin/mail, sendmail, or what have you.
What is needed is an intelligent front end which can map from domain
names to uucp addresses, just as Internet names are mapped to Internet
addresses, and so forth. Mail which is addressed on ucbvax to
honey@down.princeton (well, actually honey@down.princeton.uucp) can be
transformed to an equivalent uux command (or set of uux commands,
depending on whether or not ucbvax knows about princeton.uucp or not, if
it doesn't, a uux command will be made to the uucp nameserver, and so
forth). This will keep non-domainists happy (they can continue to use
the raw uucp !-syntax) while domainists can feel free to use domain
addresses and have the front end convert them.
The key concept here is the layering, once we have separated mail
addresses from the transport mechanism we can make whatever syntax and
semantics we want.
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.edujordan@ucbvax.ARPA (Jordan Hayes) (09/27/85)
Once again in article <593@down.FUN> honey@down.FUN (Peter Honeyman) writes: >you may recall my three questions for those who believe in .UUCP: > > 1) bilbo.UUCP? (there are three.) > 2) cbosgd.ATT.UUCP? (what makes .ATT special?) > 3) .IL.USA.UUCP? (who runs it?) > >jordan misses the point by a wide mark. for (1), he turns the question >around ("you tell us!"). ok, jordan, to make it perfectly clear, i >can't do anything with bilbo.UUCP. on the other hand, princeton!bilbo, >u-mt!bilbo, or wiretap!bilbo yield useful routes. Ok, honey (since you don't capitalize my name, I'll assume that you are refering to me by my login name, and I'll extend the courtesy), you sure can't do anything with bilbo.UUCP, since there are more than one bilbo's. There would never exist a "bilbo.UUCP" since the "second-level" domains are not for machines, but rather are for administrative sub-domains that can expect a fair amount of growth both initially and in the future. The "three bilbos" problem reduces to placing them appropriately into the namespace. You keep wanting to talk about ROUTES. Jeeze. I guess I can't argue with you when you won't listen to what I'm saying. Of course there is an inherent problem with having 3 "bilbo.UUCP"s, but domaining them fixes that. Why is this so hard to see? The answer to (2) is clear -- cbosgd.ATT.UUCP is "special" because the number of ATT affiliated uucp sites is staggering, and warrants a domain. Hmmm... it seems I'm repeatd key equivalents; this is probably the most standard way to do this, and it provides the simplicity that novices need and the shortcut that experienced users want. Another possibility is to use Forward/Backward buttons somewhere in the window. Finally, a method I have seen in some software (although I don't fully approve of it) is to make use of the horizontal scroll bar when real horizontal scrolling doesn't apply in the current context; the standard Scrapbook DA does this, although I would much prefer real scrolling, or at least the ability to resize its window (I seem to be digressing). -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar #! rnews 2204 Relay-Version: version B 2.10.2 9/18/84; site burl.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: burl!ulysses!ucbvax!techunix.BITNET!ephraim From: ephraim@TECHUNIX.BITNET (Ephraim Silverberg) Newsgroups: net.religion.jewish Subject: Re: Does PEPSI discriminate Message-ID: <8509270744.any other takers out there? here's an easy one for jordan: once you >have replaced uucp addressing with domains, what will your delivery >agent do with honey@princeton.UUCP? uux is out, since it wants >something!princeton!honey. what's the trick? Hmmm. What makes you think that princeton will get a second-level domain? As far as I can see, I would be willing to make FUN a sub-domain of ATL.UUCP, but I don't see the need for princeton.UUCP... Now, as to what to do about it -- well, glad you asked. You see, it still depends on where you are, and who you have links to -- the only difference is that you remove the question of "what to do with ..." from the addressing, and place it in the hands of system administrators (in an abstract sort of way) and the software. So, what would *I* do with it? Well, on ucbvax, for instance, the software would see down.fun.atl.uucp ... scanning from the left it would see if it "knew" of a link to send "down.fun.atl.uucp" stuff to, and would not find one (since ucbvax does not talk to down), and move on to "fun.atl.uucp" and fail again. Then, it would check "atl.uucp" and (in the smart world) would HAVE to match *something*, in ucbvax's case it would most likely (here's where the sys admin part comes in) be allegra. See, if I were running ucbvax, I would try to make arrangements for all atl.uucp stuff to go to allegra (of course if there were a foo.atl.uucp that I had a link to, it's stuff would go directly to foo...), and allegra would do the same thing over and pass it on to princeton, which would give it to down ... hmmm... come to think of it, that's the same route that pathalias would have given me, only it didn't have to be explicit, and I can use the address honey@down.fun.atl.uucp from anywhere, such as a machine I run called "nike" that has a link to seismo that my .atl.uucp stuff would go to... See, it's not all that hard. uux could be fixed (or not, as the case may be -- there are still single host names that you have as links, so I would still send uux the line uux allegra!/usr/lib/uucp/dmail honey@down.fun.atl.uucp ... or some such ... details left as an exercise, but you get the idea. So, honey, what *else* do you want to rag about ...? ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
reid@Glacier.ARPA (Brian Reid) (09/28/85)
Honeyman is right. Most of his detractors are wrong. Most of them completely miss the point. Luckily it doesn't matter because none of this will ever work anyhow. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
jordan@ucbvax.ARPA (Jordan Hayes) (09/29/85)
[ munch ] In article <12317@Glacier.ARPA> reid@Glacier.ARPA (Brian Reid) writes: >Honeyman is right. Most of his detractors are wrong. Most of them >completely miss the point. Luckily it doesn't matter because none of this >will ever work anyhow. Sorry, I don't agree. Correct me if I'm wrong, but here is "THE POINT" that most of us "detractors" are missing. 1) Addresses should be global. Relative addressing leads to ambiguity and headache. 2) The current bang addressing scheme is old and has outlived its usefulness. 3) If something is not done, the structure of UUCP as we know it will fail to make the transition back into a useful network -- it used to be useful when it was smaller, but now it is bigger, and has undergone growing pains that have made magic (and moby expensive) techniques such as pathalias and 1Mb of map data the only way to make any sense of the topology of the net. One big, hacky workaround. Honeyman and his troops (yes, this now includes you, Mr. Reid) are too far into the problem to see that what needs to happen is to take a step back and see the *real* problems and respond with real solutions, instead of adding more kludges and declaring that "it will never work". "Lead, follow, or get the hell out of my way" ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
reid@Glacier.FUN (Brian Reid) (09/30/85)
In article <10490@ucbvax.ARPA> jordan@ucbvax.BOGUS (Jordan Hayes) writes: > Honeyman and his troops (yes, this now includes you, Mr. Reid) > are too far into the problem to ... > [meow, woof, growl, etc.] > "Lead, follow, or get the hell out of my way" I've already sent Peter a letter asking for my first paycheck; I sent him my caps lock key as proof of identity. Luckily most statements of the form ``it won't work'' end up being true in Computer Science, especially where big systems are involved. I'm therefore not quaking in fear of your proving me wrong. However, given that it's not going to work, I would derive much more satisfaction in seeing that its proponents ultimately understand why it didn't work. I therefore intend to archive this whole conversation, and bring it up maybe 5 years from now in a time capsule, for some yuks. I really wish somebody had videotaped Peter Denning's speech at the 1981 SOSP conference at which he predicted that the Intel 432 would revolutionize computers as we knew them. We could show it at the 1985 SOSP conference for amusement. It is completely impossible to achieve homogeneity, such as that required by domain schemes, without central authority. It's hard to imagine a more basic principle of distributed systems engineering. If the world were perfect and you were king, you could make the .UUCP domain work, but the world isn't perfect and you aren't king, and you are not going to succeed at making it work. I assert and predict that the first successful domain-based addressing scheme for UUCP-like mail will come about because a commercial company (perhaps AT&T) offers the transport service for a fee, and regulates the addresses as part of their business. MCI Mail, however bogus it might be, is a step in the right direction. In summary: * Basic principle of distributed system engineering: Domains will not work without central authority * Basic principle of modern life: Central authority will only come as part of a larger service that is valuable enough that people will be willing to pay for it. * Lemma: All communal ventures in the history of the modern world have ultimately failed, as judged by the world outside those ventures. uucp mail is fundamentally a communal venture (except inside AT&T where Gary Murakami holds it together). -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.FUN
chuqui@nsc.UUCP (Chuq Von Rospach) (09/30/85)
In article <10490@ucbvax.ARPA> jordan@ucbvax.UUCP (Jordan Hayes) writes: > >In article <12317@Glacier.ARPA> reid@Glacier.ARPA (Brian Reid) writes: >>Honeyman is right. Most of his detractors are wrong. Most of them >>completely miss the point. Luckily it doesn't matter because none of this >>will ever work anyhow. > >Sorry, I don't agree. Correct me if I'm wrong, but here is "THE POINT" >that most of us "detractors" are missing. > > 1) Addresses should be global. Relative addressing leads > to ambiguity and headache. > > 2) The current bang addressing scheme is old and has outlived > its usefulness. > > 3) If something is not done, the structure of UUCP as we know > it will fail to make the transition back into a useful > network Well, I started this discussion (innocently enough) decades (was it only weeks?) ago, and I'm both amused and dismayed that it is still going on. The inability for the people who KNOW the situation to agree on anything just shows the depth and severity of the problem. As far as I can tell, Honeyman is right. Reid is right. Jordan is also right. The only thing that doesn't seem to be right is the network, and there doesn't seem to be a lot that can be done about it. Problems: o size: .UUCP is too large to deal with as a single domain, as shown by the massive size of the maps. o organization: .UUCP has too much anarchy to ever agree on how to split things up and get the world to complete it successfully. Even the people on the same side seem to be arguing about which side they're on. o anarchy: Even if the experts could agree on a single plan, implement it, put it in the public domain and publicize the hell out of it, significant portions of the net will simply ignore it and do what they want anyway, either by implementing their own cute hacks (a LOT more fun than installing someone elses) or by doing nothing and relying on bang format to get them through. This means that the 'smart' sites are either going to have to be backwards compatible or mung headers, or both. I still find unrequested header munging at an unknown site distasteful; I don't like the thought of a piece of software knowing better regardless of what I know and not being able to override. I tend to think that if there was a 'real' solution that we'd have been able to agree on it by now. Without the real solution, large kludgey hacks that mostly work (mod.map, pathalias, 'smart' routers and distasteful header munging) seems to be better than nothing at all, even if it breaks things once in a while (ihnp4 decided that it wanted to route all nsc mail through cbosgd recently, even though we no longer talk to cbosgd, resulting in a fair amount of chaos for us...). I have a feeling that a lot of the things that were advantages when USENET was smaller (anarchy, autonomy, and the relative freedom to experiment and do your own things) has come back to bite us in spades... -- :From under the bar at Callahan's: Chuq Von Rospach nsc!chuqui@decwrl.ARPA {decwrl,hplabs,ihnp4,pyramid}!nsc!chuqui If you can't talk below a bellow, you can't talk...
jww@sdcsvax.UUCP (Joel West) (09/30/85)
In article <10490@ucbvax.ARPA>, jordan@ucbvax.ARPA (Jordan Hayes) writes: > 1) Addresses should be global. Relative addressing leads > to ambiguity and headache. > > 2) The current bang addressing scheme is old and has outlived > its usefulness. > > 3) If something is not done, the structure of UUCP as we know > it will fail to make the transition back into a useful > network -- it used to be useful when it was smaller, but > now it is bigger, and has undergone growing pains that have > made magic (and moby expensive) techniques such as pathalias > and 1Mb of map data the only way to make any sense of > the topology of the net. One big, hacky workaround. The generalization in #2 is a bit sweeping, but other than that, I'm afraid I must agree with Mr. Hayes. Fortunately, there are some people out there who are doing rather than just talking. Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
gds@mit-eddie.UUCP (Greg Skinner) (10/01/85)
I wish someone (you, Brian, or Peter) would explain exactly what the
"point" is. The way I see it, domaining UUCP is becoming more of a
political issue than a technical one. If in fact it is politics that is
opposing the domaining of UUCP, then I can see Peter's points in that
there is no real thrust towards the domaining of UUCP. (In other words,
you won't get every sys admin on the net to conform.) On the other
hand, if it's a technical consideration than I don't see what the
problem is, because there are enough examples of domaining in the
Internet that a suitable model for UUCP can be made where the transport
agent (uucp) remains the same and domain addresses map to uucp routes,
or uux calls, or what have you.
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.edujsq@im4u.UUCP (John Quarterman) (10/01/85)
In article <12347@Glacier.FUN> reid@Glacier.FUN (Brian Reid) writes: >In article <10490@ucbvax.ARPA> jordan@ucbvax.BOGUS (Jordan Hayes) writes: >> Honeyman and his troops (yes, this now includes you, Mr. Reid) >> are too far into the problem to ... >> [meow, woof, growl, etc.] >> "Lead, follow, or get the hell out of my way" > >I've already sent Peter a letter asking for my first paycheck; I sent him my >caps lock key as proof of identity. Well, you've at least adopted one of peter's favorite methods of argument: ignore anything cogent your opponent said and baldly reassert that none of your questions have been answered. By the way, you used caps. Nyah nyah. (End of obligatory character assasination which has become traditional in this discussion.) >It is completely impossible to achieve homogeneity, such as that required by >domain schemes, without central authority. You seem to have forgotten that why the Internet is moving to domains is exactly to *decentralize*, not to centralize. Until now, the Internet has used a huge centralized table (HOSTS.TXT) of all host names and addresses in the Internet. With domains, all the name assignments that have to be centralized are the top level domains. Second level domains do not have to be recognized by any Internet-wide central authority, only within their top-level domains. And so forth. We've got lots of hosts in CS.UTEXAS.EDU and UTEXAS.EDU that nobody outside of UTEXAS.EDU in the Internet knows exist, nor needs to. Now, in UUCP, we also have a huge, centralized table: the one posted to mod.map. It's even more out of date and inaccurate than the Internet HOSTS.TXT, due to the slow nature of the underlying transport mechanisms of the UUCP net and its anarchic nature. We also have an authority for top level domains under the UUCP domain: the people who currently maintain mod.map. What domains bring us on UUCP is just what they bring us in the Internet: decentralization, not centralization. Yes, name service has to be handled somewhat differently, but how it can be done has been spelled out by others. You assume that central authority is required because you assume homogeneity is required. That's not so, either. This has been pointed out over and over by many people. Domains and old-style bangist source-routing can, will, and do coexist. Not everybody has to use domains for domains to be useful. Your basic assumptions are incorrect, so your argument is false. But, then, nobody has to prove either side of this argument correct beforehand, anyway, *because* both source routing and domains can coexist. However, I agree with your appeal to history. Wait and see. Now that Gary Murakami isn't with ihnp4 anymore, we may see the old UUCP structure crumble even faster.... -- John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq ARPA Internet and CSNET: jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPA
peter@graffiti.UUCP (Peter da Silva) (10/02/85)
> 2) The current bang addressing scheme is old and has outlived > its usefulness. I don't see this. The only problem I see with the bang scheme is that sites are ignoring it. If they gave it precedence over ARPA and other non-bang syntax it'd work fine... If (the address contains BANGS && I am adjacent to the next site in the path) Send it to them; Use whatever heuristics you want to handle ambiguous paths, but if you get a UUCP message that is addressed to the site next door to you, DON'T look any further! Just pass it on. After you have dealt with vanilla UUCP mail, the way it used to be, then you can do gateway stuff.
henry@utzoo.UUCP (Henry Spencer) (10/02/85)
> Honeyman and his troops (yes, this now includes you, Mr. Reid) > are too far into the problem to see that what needs to > happen is to take a step back and see the *real* problems > and respond with real solutions, instead of adding > more kludges and declaring that "it will never work". Some of us took a step back, saw the *real* problems, and decided that there are no viable "real solutions" and we shouldn't waste our time building non-viable ones. > "Lead, follow, or get the hell out of my way" "Hackers rush in where wizards fear to tread." -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
mikel@codas.UUCP (Mikel Manitius) (10/03/85)
Could someone please elaborate on the concept and rulles of domains,
either email, or post an article if appropriate. Thanks.
--
=======
Mikel Manitius ==----===== AT&T
...!{ihnp4!}codas!mikel ==------===== Information Systems
(305) 869-2462 ===----====== SDSS Regional Support
AT&T-IS ETN: 755 =========== Altamonte Springs, FL
=======jpl@allegra.UUCP (John P. Linderman) (10/03/85)
>From princeton!down!honey Wed Oct 2 23:58:44 1985 >i don't know if you read net.mail, but ... > >> See, if I were running ucbvax, I would try to make arrangements for >> all atl.uucp stuff to go to allegra (of course if there were a >> foo.atl.uucp that I had a link to, it's stuff would go directly to >> foo...), and allegra would do the same thing over and pass it on to >> princeton, which would give it to down >> ... >> >> Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU > >perhaps this guy would care to know how allegra-land feels about his >plan to give allegra official status as the uucp route server for >the atlantic states. > > peter No, I don't read net.mail, but I'm always interested in other people's plans for allegra. My position in the bangists/attists debate is this... a plague on both your houses. Both sides are quite willing to use allegra [or some other intermediary] to move the mail, but nobody has offered to send me a check to pay for the service. I hate to trouble the philosophers out there with mundane issues, but communication costs MONEY. Unfortunately, the costs are not usually borne by those who reap the benefits. To take a simple case, when jordan sends mail to peter via allegra, allegra picks up the mail when polling ucbvax (which lacks dialout capability) and then calls princeton, which we call on demand. Allegra pays for two long distance calls, and hayes and honeyman get the benefits (if any). Allegra has to accept a good share of the blame for tolerating this kind of nonsense. It isn't difficult to stop it, as the growing number of sites that simply refuse to forward mail have found out. But the net will crumble if the policy is universally adopted. Maybe that's not so bad, but I'd like to give the net a little more time to figure out not only how to address mail, but how to pay for it. John P. Linderman allegra["Don't call us, we'll call you"]!jpl
geoff@desint.UUCP (Geoff Kuenning) (10/03/85)
In article <12347@Glacier.FUN> reid@Glacier.FUN (Brian Reid) writes: >In summary: > * Basic principle of distributed system engineering: > Domains will not work without central authority > * Basic principle of modern life: > Central authority will only come as part of a larger service > that is valuable enough that people will be willing to pay for it. > * Lemma: > All communal ventures in the history of the modern world have > ultimately failed, as judged by the world outside those ventures. > uucp mail is fundamentally a communal venture (except inside AT&T > where Gary Murakami holds it together). Gee, Brian, three out of three ain't bad at all. Three unsupported statements, that is, none of which are self-evident. All three are rather sweeping claims based on the author's opinions. As to (1), distributed systems without central authority exist and work; why do you think domains are special? As to (2) and (3), they are clearly based on the author's personal political opinions and are not worth dignifying with a response in this newsgroup. I have directed followups to net.politics, which is where this sort of unrigorous (is that a word?) noise belongs. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
dw@rocksvax.UUCP (Don Wegeng) (10/04/85)
Jordan makes a point in his last article that I'd like to restate,
since it's important to the concept of domains. When uucp switches
to domain based addressing it will move from flat namespace to a
hierarchical namespace. A name such as bilbo.uucp will not exist,
and therefore is not a problem that must be dealt with.
In a domain based scheme my address *might* be dw@rocksvax.wny.uucp,
which implys that I'm on the only rocksvax in the wny subdomain of
the uucp domain. There can be many other rocksvax's in the uucp
domain, but only one in the wny.uucp subdomain. Now the question
come up as to how do we enforce this rule of only one rocksvax
in wny.uucp? It doesn't require a designated authority, for only
the other machines in the wny.uucp subdomain will care about such
things. It can be up to them to enforce the rule, just as it is now
up to the entire net to insure that no two machines have the same name.
When the net was small this even worked. Subdomains will be small
enough that it will work again.
The nice thing about domain addressing is that in order to send mail
to dw@rocksvax.wny.uucp, a machine (and it's users!) do not have know
an exact route to rocksvax. All the machine needs is an agreement
with one of it's neighbors that traffic destined for the wny.uucp
subdomain will be sent to it, where it will be further routed using
the same method. If the software happens to know how to get to
rocksvax.wny.uucp it can use it's knowledge, but IT DOESN"T HAVE TO!
Ok Peter, it's your turn...
/Don
--
"To err is human - to blame someone else is even more human"
arpa: Wegeng.Henr@Xerox.ARPA
csnet: Wegeng.Henr@Xerox.ARPA
ns: dw:Wbst207V:Xerox
uucp: {allegra,amd,decvax!rochester,princeton}!rocksvax!dwchuqui@nsc.UUCP (Chuq Von Rospach) (10/04/85)
Hear! Hear! Well spoken, and all that... It is amazing how much the
people who don't pay the bills feel they have the right to control
the network... That will probably turn out to be the single biggest mistake
Usenet made.
chuq
--
:From under the bar at Callahan's: Chuq Von Rospach
nsc!chuqui@decwrl.ARPA {decwrl,hplabs,ihnp4,pyramid}!nsc!chuqui
If you can't talk below a bellow, you can't talk...henry@utzoo.UUCP (Henry Spencer) (10/04/85)
> ... Both sides are quite willing to use allegra... to move the mail, but > nobody has offered ... to pay for the service. > ... It isn't difficult to stop it, as the growing number of > sites that simply refuse to forward mail have found out. But the net will > crumble if the policy is universally adopted... An interesting side issue on this is the potential for additional overhead if sites must do routing of incoming mail, i.e. it arrives with a domainist address and the site must figure out where to send it. This becomes much more serious at "well known" sites (e.g. allegra) which are obvious places to send mail when you don't know exactly how to get to the site specified. Examples: "I don't know where 'down.FUN' is, I'll just punt it to <my nearest well-connected site, e.g. allegra> and let them figure it out". "I have no idea how to get to 'garfield.east.canada', I'll just send it somewhere in east.canada, like say utzoo, and let them send it the right way." The problem is not so much the additional overhead of doing routing, but the additional volume of traffic that such strategies cause. The creed of the domainists is that sites should determine more direct paths (how?) and remember them, to speed traffic and avoid overloading central sites. What the creed does not supply is the strong incentives that would be necessary to actually convince people to do this, when it's so much easier to just freeload a little more on the central sites. Ironically, the *lack* of routing mail relays so far is a powerful motive for decentralization of the routing process, i.e. the sender does the work because it's the only way he can depend on getting it done at all. This enforced decentralization is visibly collapsing as routing relayers become more common. Example #1 above is already a common tactic. We are seriously contemplating setting a firm policy that we will *not* re-route mail that we relay. That is, mail that arrives at utzoo had better be addressed to "neighbor!...", where "neighbor" is one of our neighbors, or we won't relay it. This happens to correspond to the routing policy (or rather non-policy) of old-style uucp mailers, but that is an accident rather than a major reason. This policy is not being proposed out of laziness or conservatism, but out of distaste for the probable consequences of providing a free routing service to the world. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
dms@mit-hermes.ARPA (David M. Siegel) (10/07/85)
From: henry@utzoo.UUCP (Henry Spencer) Keywords: sponge leech freeloader domains routing_overhead The problem is not so much the additional overhead of doing routing, but the additional volume of traffic that such strategies cause. The creed of the domainists is that sites should determine more direct paths (how?) and remember them, to speed traffic and avoid overloading central sites. What the creed does not supply is the strong incentives that would be necessary to actually convince people to do this, when it's so much easier to just freeload a little more on the central sites. Maybe the "domain servers" would just supply path information back to the requestor. With this approach, the requestors would have incentive to cache address information (to speed up mail xfers). Granted, the overall mail transfer speed might go down (but not by much of the order of host polling and caching protocols were done right). This is like the way the internet is doing domaining. The domain servers give a name and pass back an address (really a path). -Dave -- Arpa: dms@mit-hermes.arpa Usenet: mit-eddie!mit-hermes!dms
hokey@plus5.UUCP (Hokey) (10/09/85)
In article <273@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: > If (the address contains BANGS && > I am adjacent to the next site in the path) > Send it to them; It is always fascinating watching people follow the learning curve. I can hear the laughter of the folks who watched me follow the same path. The problem with this approach, Peter, is it *assumes* the first site of the bang path is the next hop, while in actuality the @site on the end might have been the neighbor who sent the mail along. Talk to Peter Honeyman about pathparse. I still think that it is better to break things cleanly and definitely; therefore, I still think hybrid routes *within the UUCP domain* (Hi jer!) should be rejected by the first site able to do so. In UUCP land, I still think everything should be in ! format, including RFC822 headers. really mui -- Hokey ..ihnp4!plus5!hokey 314-725-9492
jer@peora.UUCP (J. Eric Roskos) (10/10/85)
> I still think hybrid routes *within the UUCP domain* (Hi jer!) Hi. How did I get involved in this discussion again? Now, I really am not going to spend more than 5 minutes on this, but: > The problem with this approach, Peter, is it *assumes* the first site of > the bang path is the next hop, while in actuality the @site on the end > might have been the neighbor who sent the mail along. The last part of your statement is the key to your interpretation, and to one of the big hidden-dichotomies (what did someone recently call that? a "domain-problem"? an overused word) in people's solutions to the mail routing. You said "might have been the neighbor who sent the mail along"... this is only a problem if you are trying to generate a reply from some badly-written "From" line, a "From" line that contains a route rather than an address. This is also the major origin of a lot of the arguments for some other problematic things, e.g., the tendency of ihnp4, etc. to cut off ("optimize") parts of the UUCP route given it... because it has to deal with things like replies generated by the Netnews software from the path the news took. These problems disappear if you write addresses in your RFC822 headers instead of putting UUCP paths in there. I stand by my original opinion, though, that rejecting "hybrid" routes as soon as they reach a site that is willing to do so is going to be a bad thing. It's already getting hard enough to deliver mail the past few weeks as it is. [At this point I could demonstrate how anybody mailing through ucbvax right now must be generating hybrid addresses, since when I tested a week ago they wouldn't take the all-! addresses, but instead I will stop. I don't want to get into these long essays again.] > Talk to Peter Honeyman about pathparse. This is sort of an AI solution, and human beings (if they are the prototype of AI, which some AI people claim they are not) make many mistakes unless they discipline their thinking well. This includes not being swayed by counter arguments to your own unless you can see they are valid; > It is always fascinating watching people follow the learning curve. I can > hear the laughter of the folks who watched me follow the same path. the path that the majority agree on is not always the best, since good solutions often come from a perspective external enough to get the "big picture", and not to be confused by popular superstition. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
honey@down.FUN (Peter Honeyman) (10/11/85)
jer and i frequently agree, but a recent comment is too outrageous to overlook. someone, hokey i think, said Talk to Peter Honeyman about pathparse. to which jer replies This is sort of an AI solution, and human beings (if they are the prototype of AI, which some AI people claim they are not) make many mistakes unless they discipline their thinking well. This includes not being swayed by counter arguments to your own unless you can see they are valid; give me a fucking break, eric, pathparse and AI couldn't be more dissimilar; read the paper or read the code. whatever the hell you're trying to say here lacks a sound premise. peter
jer@peora.UUCP (J. Eric Roskos) (10/14/85)
> give me a fucking break, eric... Gee, Peter, what did I say? You're right, I haven't read pathparse's code yet (I'm still working on getting one of those "easy to install, works on all versions of Unix" mailers to work on a non-Berkeley system), and thus have only the information on it from comments people had posted before. My understanding was that pathparse was the program you wrote a paper on awhile back, which attempted to disambiguate addresses by the context in which they were used. My point was that programs that try to employ nontrivial heuristics of the sort people would use in solving the same problem only work if it is possible for a person to solve the problem in the first place! I've forgotten which article I was commenting on now, but it made reference to the confusing tangle of counterexamples that currently lead to most of the disagreement on how to do the mail routing. If people make the routing so confusing, by coming up with schemes based on confused principles, that it is difficult for a *person* to do the routing by hand (how do I get to Reed from here these days?), then I don't think a program will be able to do it either. This has nothing to do with the program itself; it has to do with other things. > ... pathparse and AI couldn't be more dissimilar ... Actually, the reason for my eternal boycott of unix-wizards has to do with an argument over philosophical issues related to AI; I hope this won't de- velop in here. I tend to feel that current definitions of "Artificial Intelligence" have grown to be unduly constraining. But AI is not presently my business, though it was a few years ago; so I merely observe it and keep busy. Let's not get into issues of semantics here. My point was just that the world's most flexible, adaptive program can't resolve routing problems that are outside its domain, as is the case when, for example, there is a mailer down the line that recognizes a different language from the one others in the same transport mechanism are using. Thus we have to not only have good programs, but good rules for making the things the program works with; which in this case is simply a routing language. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642