mark@cbosgd.UUCP (Mark Horton) (09/11/85)
The first distribution of the UUCP project mail router will be
posted to the net soon. In order to install it, you have to have
a domain name that fits into the world domain tree. We need to
be making a final decision about how to position our systems.
We're currently using subdom.UUCP as our position. However,
we're running into some problems with existing sendmail.cf files
(as distributed in 4.2BSD and Sun UNIX) and the top level domain name
UUCP. Here's what happens.
We send out mail conforming to the standard, looking like this:
From: mark@cbosgd.ATT.UUCP (Mark Horton)
It's received by other systems, which feed it through sendmail.
Sendmail has a production that recognizes
user@host.UUCP
and translates it into
host!uucp
Unfortunately, due to a bug in their sendmail.cf, if "host" is a
dotted subdomain like "cbosgd.ATT" it still does the translation,
and gets
cbosgd.ATT!mark
This in itself might be OK if it translated it back later. However,
what it seems to do is pass it in this bang notation along to subsequent
hosts in the route, or drop it in local mailboxes looking like either
From: cbosgd.ATT!mark
or rarely
From: mark@cbosgd.ATT
In the meantime, I suspect that due to the widespread distribution
of this bug, and since (I think) it's in 4.3BSD and in Sun 2.0, both
of which are very recent major releases, it seems like it would be
very difficult to get the fix to this widely installed. Unless someone
has a better idea, I think we may be forced to avoid the name UUCP as
a top level domain, and fit into the name space somewhere else.
Possibilities include:
(1) renaming UUCP, calling it, say, UU or SMAIL or something else.
This would leave the name UUCP for the explicit purpose of
indicating a call to uux. (Suggestions for the name, should
we do this, are welcome.)
(2) do nothing. We essentially depend on the fact that the name UUCP
is built into the smail software as a default, so that cbosgd.ATT
is treated the same as cbosgd.ATT.UUCP.
(3) fit into the ARPA organizational space, with names like cbosgd.ATT.COM
and ucbvax.Berkeley.EDU. This might not be hard, given the facilities
of smail and pathalias, but we do not have official permission from
ARPA to do this, and they have not been moving quickly to
resolve the problem. (Since they keep the registries for EDU,
COM, GOV, MIL, and ORG, we would have to register with them.)
(4) fit into the MHS (X.400) name space, or some reasonable mapping of it.
This means that the top level is always a two letter country code,
and the level under that would be somewhat ad-hoc (they seem to be
moving in the direction of the organization at the next level, but
they don't require org names to be unique, and this isn't really
standardized yet.) This seems to be very close to what the parts
of UUCP outside the USA and Canada want to do anyway. We might have
subdivisions under US and/or Canada, those subdivisions might be
EDU, COM, and GOV, or they might be 8 or so geographic subdivisions,
or they might be the organizations themselves (if we can convince
ourselves we're really capable of handling that,) or they might be
the Administration Management Domain required by X.400 (this is
basically the name of the common carrier, e.g. telco, through which
the domain can be reached.) We would also have to share this name
space, each country would have to work it out with their appropriate
administration domain (this usually means the phone company, but in
the US it isn't clear who it means, perhaps the State Dept in the
Federal Government.)
We're very close to having the software ready to send out, but this may
slow us up.
Mark Hortonjordan@ucbvax.ARPA (Jordan Hayes) (09/12/85)
In article <1469@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >Possibilities include: > >(1) renaming UUCP, calling it, say, UU or SMAIL or something else. > This would leave the name UUCP for the explicit purpose of > indicating a call to uux. (Suggestions for the name, should > we do this, are welcome.) How about FUN ...? >(2) do nothing. We essentially depend on the fact that the name UUCP > is built into the smail software as a default, so that cbosgd.ATT > is treated the same as cbosgd.ATT.UUCP. Nope. No good. >(3) fit into the ARPA organizational space, EEK. What a nightmare. >(4) fit into the MHS (X.400) name space, or some reasonable mapping of it. Are you serious? No one UNDERSTANDS X.400... I see the only reasonable solution is to remove the .UUCP bug in 4.3 sendmail.cf, and rename the top level domain. Perhaps as a consolation (pronounced "boobie") to Peter, I suggest we make it the FUN domain, 'cause it just be soooo fun... /jordan
jer@peora.UUCP (J. Eric Roskos) (09/12/85)
Well, for what it's worth, here's my opinion:
(1) renaming UUCP ...
I think this is best. You have to bear in mind that other mailers out
there exist that use the domain name UUCP in the same way we (some of
us) use the domain names .COM, .GOV, etc. I.e., it says "forward it
to our UUCP gateway, who will figure out how to get it there". CSnet
did this back when I was a CSnet user, for example. The name UUCP doesn't
mean much to us since we are within the domain, but outside it has more
significance. Maybe something like UUMAIL would be good; it's always
been theoretically bothersome to me that UUCP transports both the mail and
the news, but the domain denotes the mail.
(2) do nothing. ...
No, this wouldn't work because then when someone outside gets a message,
if I understand you correctly, it would end up saying
From: jer@jerpc.PE
and they would have no idea what .PE meant: was it on CSnet? Bitnet? Mailnet?
PE's internal network? or what?
(3) fit into the ARPA organizational space, with names like cbosgd.ATT.COM
I think this would be worst of all, since it brings on the problems
inherent in insisting on the "domains are not routes" approach. I.e., if
we fit into the ARPA organizational space, it becomes hard in practice to
do the mail routing from the less privileged mail networks (those that
don't have access to the registry information). Presently they can blindly
forward the mail with .UUCP on the end to a site with pathalias, and let it
resolve it. If it says ATT.COM, they have to keep up with what the UUCP
subdomains of COM are, in some sense, in order to decide how to deliver it.
(4) fit into the MHS (X.400) name space, or some reasonable mapping of it.
The only problem with this is it's so hard to find out what X.400 is...
could you summarize, possibly, how X.400 works?
--
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-7642jww@sdcsvax.UUCP (Joel West) (09/13/85)
In article <1469@cbosgd.UUCP>, mark@cbosgd.UUCP (Mark Horton) writes: > Possibilities include: > > (4) fit into the MHS (X.400) name space, or some reasonable mapping of it. > This means that the top level is always a two letter country code, > and the level under that would be somewhat ad-hoc (they seem to be > moving in the direction of the organization at the next level, but > they don't require org names to be unique, and this isn't really > standardized yet.) This seems to be very close to what the parts > of UUCP outside the USA and Canada want to do anyway. We might have > subdivisions under US and/or Canada, those subdivisions might be > EDU, COM, and GOV, or they might be 8 or so geographic subdivisions, > or they might be the organizations themselves (if we can convince > ourselves we're really capable of handling that,) I vote for this. Besides being a proposed(?) standard, ".US", ".UK", and so on do have some real-world significance, rather than becoming a historical artifcat to justify to our grandchildren. I don't understand the politics of the name space control issue. Given the diversity of this country, I feel that breaking the ".US" domain up into pieces is a necessity. And what if there are two "Westech" companies (there are)? Who arbites it? One national, all powerful-registry? Or regional registries. Incidentally, California is about 10% of the US population, but more of the non-AT&T net. It should probably be a separate region. Perhaps we could follow the territory of Local Operating Companies, e.g., Pacific Bell, Bell South, US West, and so on. Judge Green had some sort of balance in mind. :-) Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
thomas@utah-gr.UUCP (Spencer W. Thomas) (09/16/85)
In article <10361@ucbvax.ARPA> jordan@ucbvax.UUCP (Jordan Hayes) writes: >Perhaps as a consolation (pronounced "boobie") >to Peter, I suggest we make it the FUN domain, 'cause it just be >soooo fun... Oh? I thought it stood for F***ed Up Network :-! -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) "The difference between reality and unreality is that reality has so little to recommend it." -- Allan Sherman
mcb@styx.UUCP (Michael C. Berch) (09/17/85)
In article <1469@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: > . . . Unless someone > has a better idea, I think we may be forced to avoid the name UUCP as > a top level domain, and fit into the name space somewhere else. > Possibilities include: > > . . . > (3) fit into the ARPA organizational space, with names like cbosgd.ATT.COM > and ucbvax.Berkeley.EDU. This might not be hard, given the facilities > of smail and pathalias, but we do not have official permission from > ARPA to do this, and they have not been moving quickly to > resolve the problem. (Since they keep the registries for EDU, > COM, GOV, MIL, and ORG, we would have to register with them.) This alternative looks like a clear winner to me. Note, for example, that the second name, ucbvax.BERKELEY.EDU, already exists. The idea of uniting the domain and name spaces of North America's two most visible electronic mail internets (DDN and UUCP) is tremendously attractive, even though it might mean giving up some measure of domain identity to the people who will eventually administer the entire domain name scheme for DOD. Michael C. Berch mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
chris@umcp-cs.UUCP (Chris Torek) (09/18/85)
[Warning: Human (and Elvish of course :-) ), not software, issues discussed herein. If you are not interested in such, do not read on.] In article <12532@styx.UUCP> mcb@styx.UUCP (Michael C. Berch) writes: > In article <1469@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >> [possibilities include trying to] fit into the ARPA organizational >> space, with names like cbosgd.ATT.COM and ucbvax.Berkeley.EDU. > This alternative looks like a clear winner to me. ... The idea of > uniting the domain and name spaces of North America's two most > visible electronic mail internets (DDN and UUCP) is tremendously > attractive, even though it might mean giving up some measure of > domain identity to the people who will eventually administer the > entire domain name scheme for DOD. That is indeed the problem, as Mark points out: >> This might not be hard, given the facilities of smail and pathalias, >> but we do not have official permission from ARPA to do this, and >> they have not been moving quickly to resolve the problem. (Since >> they keep the registries for EDU, COM, GOV, MIL, and ORG, we would >> have to register with them.) It would not actually be necessary to register with them; however, this would likely create an administrative disaster. The key feature of domains, as far as DARPA is concerned, is that administrivia is moved out of one central region, yet is still clearly defined: it is somewhere written that UMD.EDU shall be the responsibility of the University of Maryland. While we could simply ``take over'' the name space so thoughtfully provided us, it would create a great deal of confusion among many sites. No longer would ``*.COM'' be found in the COM registry on the ARPAnet, for ATT.COM would exist only in the UUCP world. I do not believe that the NIC would be happy about this situation; ARPA sites that receive UUCP mail and are unable to reply (as they are not running the UUCP routing software so cannot understand why the COM registry does not know about ATT) would likely bombard them with queries. This, then, is the problem: How can we adopt an existing namespace without hurting those already using it? The answer, I think, is that we cannot. The UUCP routing system is sufficiently different from the ARPA system that it will not simply ``plug in''. From a user's viewpoint, however, merging the namespaces is very attractive. If we do this, we must decide which naming scheme we shall use. I think that, in terms of software, it actually matters not whether we use ATT.UUCP or ATT.COM; the software will handle either, an it becomes common usage. It is true that a single special case is, at least, more obvious, and for this reason we should choose ATT.UUCP. But a UUCP domain has no real administrative implications, unlike other domains, so this is perhaps misleading, and we should then choose ATT.COM. * * * Elves seldom give unguarded advice, for advice is a dangerous gift, even from the wise to the wise, and all courses may run ill. But if you demand advice, I will for friendship's sake give it. . . . Oh, sorry, that was a different conversation. I personally believe that we should adopt the existing namespace wholeheartedly. d.osg.cb.att.com, ucbvax.berkeley.edu, and the like are at least consistent with their ARPA-world counterparts. But I have not invested as much time in studying these matters as others have, and I think we should hear their viewpoints before we commit ourselves to any one course of action. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jim@hwcs.UUCP (Jim Crammond) (09/22/85)
> (1) Renaming UUCP
Well since most/all other communication based domains seem to have
the obligatory word "NET" in them (e.g. csnet, bitnet, mailnet),
how about "UUNET" ?
--
-------------
-Jim Crammond JANET: jim@UK.AC.hw.cs
UUCP: jim@hwcs.uucp or ..!ukc!hwcs!jim
ARPA: jim@cs.hw.ac.uk