honey@down.FUN (Peter Honeyman) (08/02/85)
i can see my graph model made a big hit. i was told it was wrong, and if it's not wrong it can't be done, and if it can be done it's wrong to do it, because it's just plain wrong. what we have here is a failure to communicate. what's so great about domains? domains are a great thing. as a naming authority, a domain has knowledge of its parent domain, its subdomains, and a few other domains. this structure immediately suggests a set of undirected trees. if the set of top-level domains is small, the full set can be treated as connected, giving every domain an absolute name. absolute names are wonderful; they free us from the twin tyrannies of relative addressing and explicit routing. why don't i advocate the domain naming scheme? first, i object to the way names are controlled. the notions of exercising control over a domain, delegating a piece of control to children, and accepting control from above seem overly rigid. in the uucp world, it is customary to negotiate such things in an ad hoc way. uucp is inherently egalitarian. i see no way for domains to forcibly replace these long-established customs. in any case, the administrative structure of domains has little to recommend itself in a world where "controlling the name space" is a highfalutin way of saying edit L.sys. uucp has no knowledge beyond the names of hosts to which it can connect, in fact a uucp host may not know which hosts can connect to it. this point is incontrovertible and leads to an inescapable conclusion: the uucp topology resembles a directed graph. in the abstract, this graph need not have any special properties: it can be cyclic, unconnected, have sinks, etc. in practice, about all you can say is that it's sparse yet "clumpy" and that no host can have out-edges to multiple identically named hosts. what's wrong with uucp-style addressing? with a dearth of candidates for absolute names, it's no surprise that relative addressing is the rule in the uucp world. to make matters worse, while unambiguous route specifiers can be constructed, it is common practice to generate ambiguous ones. so the uucp model has two major flaws: the absence of absolute names, and the prevalence of ambiguous addresses. why prefer uucp-style addressing? o it's loosely structured. i control the name space in my locale, you in yours, and if we're happy with one another, our uucp relationship will be fruitful (and maybe even multiply). o it's easy. routing tools are commonplace, obviating the need to carry explicit routes in one's head (or .mailrc). in fact, if i am to believe other notes in this newsgroup, it's easier than domaining, where tokens like honey@down.fun.princeton.edu are mandatory. (in fact, i don't believe this for a moment.) o it's inevitable. my uucp dialing/login info is public, so my host has hundreds, perhaps thousands more "in-edges" than "out-edges." since these neighboring hosts are staffed in large part by at&t techno-zealots, i conclude that living with them is going to require a lot more tolerance than living with, say, brian reid. and every unix box that hits the street adds weight to my argument. are there other problems with uucp-style addressing? the problems with uucp-style addressing are exacerbated by pathalias (or any other routing program). pathalias provides a means to specify distant hosts with local names. in its simplest form, pathalias converts graph connectivity and weight data to routes. thanks to the uucp project people, obtaining data is easy. however, pathalias distorts the uucp name space: with 9,736 host names in my route database (including several prominent non-uucp networks), i am taking on far more than my measly 100 or so uucp neighbors. where the uucp graph can have no host name conflicts, the name space induced by pathalias has many. so pathalias, in attempting to solve one problem, introduces another. how can these problems be solved? first, the directed graph model must be faced squarely. it has been claimed that the necessity of maintaining the uucp graph is overly burdensome; this proves not to be the case. even so it's apparent that some data must be available if ambiguities are to resolved. in the simplest case, i may be satisfied with resolving the ambiguity in x!<route>@y choosing between x and y, without examining or modifying <route>. for such cases, it suffices to have the fragment of the graph describing the local host and its neighbors. there are instances that necessitate data describing the distant world; the better the data, the better the parser and the better the routes. to reiterate, high quality data of precisely the form needed is readily available to everyone reading this. there is no requirement for complete connection data. the route ambiguity problem has a reasonable treatment, one that i can effect and administer locally, rather than waiting for all my neighbors to see the light. the problem with host name collisions remains: i don't have a satisfactory solution. in practice, i keep my eyes peeled for such occurrences and decline to maintain routes to these hosts; it works but is subject to abuse, miscalculation, and neglect. on this front, i await progress from someone with better ideas on local solutions or enough influence to effect global ones. these are not religious issues. it doesn't matter how much one likes or dislikes uucp or rfc819, nor whether a scheme encourages or prohibits anarchy, nor whether one feels that name space control should be in the hands of users, site administrators, or hostmasters. the crucial issues are whether a given naming scheme can coexist with the realities of the uucp world, its loose topological and administrative structures, and its narrow name space control. domains can not. peter
thomas@utah-gr.UUCP (Spencer W. Thomas) (08/02/85)
Thank you Peter, for a well reasoned article. I'm not sure I agree with your final conclusion (although it does follow from your premises, to some extent), but then, I'm not sure I know what I think the "best" solution is, anyway. However, I must disagree with one of your points. I present here a concatenation of statements from your message. In article <552@down.FUN> honey@down.FUN (Peter Honeyman) writes: >in the abstract, this graph need not have any special properties: it >can be cyclic, unconnected, have sinks, etc. in practice, about all >you can say is that it's sparse yet "clumpy" and that no host can have >out-edges to multiple identically named hosts. Sounds good, so far. >o it's inevitable. my uucp dialing/login info is public, so my > host has hundreds, perhaps thousands more "in-edges" than > "out-edges." We begin to see here the glimmerings of a problem. In particular, you can control your out edges, but not your in edges. Suppose one of the three "bilbo" sites decides to call you. You have NO WAY of knowing from which of the three the call came. You may have only one "bilbo" out edge, but this does NOT protect you from getting a message from one of the other "bilbo" sites in such a way that it LOOKS like a local message. If, on the other hand, their names were specified absolutely via a domain-type scheme, you would always know which one was addressing you. > >where the uucp graph can have no host name conflicts, the name space >induced by pathalias has many. so pathalias, in attempting to solve >one problem, introduces another. As we can see above, the uucp graph CAN have host name conflicts, in trying to determine the SOURCE (not destination) of a message. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) "You don't get to choose how you're going to die. Or when. You can only decide how you're going to live." Joan Baez