UUCP Subdomain Requirements Mark R. Horton Bell Laboratories Columbus, Ohio 43213 Karen Summers-Horton Usenix UUCP Project 2843 Valcour Ct.; Reynoldsburg, Ohio 43068 ABSTRACT This document outlines the structure of the UUCP domain, and specifies the requirements for subdomains of UUCP. 1. IIIINNNNTTTTRRRROOOODDDDUUUUCCCCTTTTIIIIOOOONNNN We are primarily trying to establish some notion of universal service in setting up domains. The current bang code was designed for an environment where every machine has a direct connection to every other machine, phone calls are free or cheap, and local area networks were just around the corner to replace this dialup kind of network. The UUCP network has grown into a huge network, and none of these assumptions are valid anymore. Hence, we are conforming to the only widely used, documented mail standard that has caught on in the electronic mail community, the ARPA domain standard. (The only other documented standard is X.400, which has not yet caught on well enough for us to consider. The old UUCP ! format is undocumented and unmanageable in a network the size of UUCP; we expect this format to continue to work indefinitely, but have chosen to support the ARPA standards at the user level.) The UUCP community has evolved as an anarchistic, loosely connected network with no central administration and no rules. An anarchy works if it is small, but with thousands of machines already on the network and the number of UNIX machines growing at breakneck speeds, it has already begun to break down. We are establishing a central administration to keep track of who is on the network, and who to contact in case something goes wrong. Nonetheless, we are keeping the established rules to a minimum, to retain the cooperative spirit of the UUCP world. We have determined that a flat name space is beyond our capability to administer, so we are dividing the UUCP world into subdomains. The current flat name space using the user@host.UUCP syntax will not be supported after a certain date [possibly December 1985] and all hosts will be expected January 17, 1985 D R A F T - 2 - to band together into subdomains. We intend to register UUCP as a top level domain. Direct subdomains of UUCP will therefore be 2nd level domains. (A subdomain is a domain which is beneath another particular domain in the tree. For example, ATT.UUCP is a 2nd level domain which is a subdomain of the first level domain UUCP, CB.ATT.UUCP is a 3rd level domain which is a subdomain of ATT.UUCP, and of UUCP.) 4th level, 5th level, and so on are also possible, but there will be different (presumably less restrictive) requirements for lower level subdomains. We want to keep the number of 2nd level domains manageable, since a complete list of 2nd level domains will be frequently published. We expect a hundred or so 2nd level domains to be a small enough number to be manageable and to allow frequent publishing of the list. These requirements are intended to keep the eventual number of 2nd level domains at around 100. Rather than having us arbitrarily divide the world into fixed subdomains, we have decided to encourage the world to divide itself up. Any group of machine administrators can join together to become a 2nd level domain, provided the domain meets the requirements stated herein. Groups can decide for themselves the basis for subdivision, although geographic regions are an obvious choice. For example, New England and Northern California would be two obvious choices for 2nd level domains. Very large organizations might also decide to become a 2nd level domain, for example, AT&T is spread out over much of the United States, but accounts for nearly half the UUCP hosts in the world, so will probably have its own 2nd level domain ATT.UUCP. Small and medium sized organizations are encouraged to join up with other nearby organizations to become regional 2nd level domains, in order to keep the total number of subdomains small. An organization with a few machines may wish to become a 3rd or 4th level subdomain, but should not become a 2nd level domain. Individual machines will not be allowed to be 2nd level domains, hence, the user@host.UUCP syntax will only be supported until we can get the subdomain framework in place. All hosts that want to become part of the UUCP domain will have to become part of some subdomain. It is not necessary that all hosts attach into the domain tree directly off a second level subdomain; further subdivision is allowed if it makes sense locally. Individual machines may or may not be 3rd level or lower domains, according to the policies of the 2nd level domain. All individual machines are viewed as Nth level domains, for some N. Thus, if OSGD.CB.ATT.UUCP represents a particular machine, it is also viewed as a 4th level domain. January 17, 1985 D R A F T - 3 - 2. RRRREEEEQQQQUUUUIIIIRRRREEEEMMMMEEEENNNNTTTTSSSS The following is a list of requirements for becoming a 2nd level domain under the top-level domain UUCP. They are grouped as administrative requirements, standards, services, and guidelines. 2.1 AAAAddddmmmmiiiinnnniiiissssttttrrrraaaattttiiiivvvveeee This section describes the administrative requirements for subdomains of UUCP. 2.1.1 Conformance_with_RFC920. We are operating under the guidelines established by the ARPANET document RFC920. That document describes the overall domain structure of the domain tree, and sets forth the requirements for domains. Some of these requirements apply only to top level domains, but many of them apply to all levels. Since subdomains of UUCP will be in the ARPA domain tree, they must conform to the rules specified there. Briefly, these rules are that each subdomain must have a responsible contact person, maintain a registry of all their subdomains and machines and the contact persons for them, provide some sort of access to that registry with a domain server, be at least a certain size, and register with their parent domain. 2.1.2 Responsible_Persons. There must be a minimum of two responsible people per subdomain. The main contact should be a technical contact, and the alternate may be either a technical or administrative contact. These people will be responsible to the UUCP Project, and to the UUCP community overall. When a contact person for a subdomain steps down, they must notify their parent domain, and either (a) find a replacement, (b) dismantle the subdomain, or (c) make arrangements with someone to be a temporary replacement. 2.1.3 Size. A subdomain must have a minimum of 100 machines, representing a minimum of 250 users. Exceptions to this rule will be made at the discretion of the UUCP Project. Exceptions are intended for situations where a subdomain is small but isolated from the rest of the community by an expensive bottleneck, for example, Asia and Israel should probably be separate subdomains because of their remote geographic location and the expensive dialup links to them. It is expected that Europe will have one or two subdomains as well. Note that this requirement is stricter than the 50 machine minimum recommended in RFC920. This is because the UUCP net is larger than the typical network envisioned by the authors of RFC920, is growing faster, and operates using a lower January 17, 1985 D R A F T - 4 - performance transport than the TCP/IP environment assumed in their environment. Single organizations (such as companies, universities, or government divisions) desiring a 2nd level domain must show that they represent at least 1/100 of the UUCP domain (so that if 100 subdomains are created, such organizational domains will be as large as other subdomains.) A medium sized company that cannot meet this requirement but would like to become a second level domain is encouraged to become a gateway for a larger geographic subdomain in its region, and possibly handle all or part of the domain administration. Our expectation is that there will initially be 10-20 2nd level domains in the United States, 2-5 in Canada, 2-10 in Europe, one in Australia, and 1-2 in Asia. These numbers are based upon the current distribution of hosts running UUCP, and are subject to revision as needed. 2.1.4 Right_of_Refusal. We reserve the right to accept or refuse 2nd level subdomain applications. For example, we would not accept two domains with an overlapping general purpose constituency; e.g. two domains that both claim to represent the state of New York. 2.1.5 Application. The responsible person must make application to the UUCP project responsible person (currently Karen Summers-Horton, cbosgd!ksh) outlining who the domain represents, what the name of the domain is, showing how it meets these requirements, the growth plan, and giving the name, postal address, electronic address, and telephone number of both the administrative and technical contacts. 2.1.6 Growth_Plan. When a domain grows, it may find that a once workable name space becomes unworkable because of its size, and that it should be subdivided. For example, ``plus5.uucp'' is an accepted convention now, but the size of the domain has grown to the point where subdomains have become essential. As a result, plus5.uucp will probably be renamed plus5.mid-w.uucp, or possibly even plus5.stl.mid- w.uucp. This causes an upward compatibility problem, and the old name must be supported for a reasonable period of time until people are using the new name. This is termed ``growth by lowering'', where hosts become one level (or more) lower in the domain tree. Growth by lowering is a difficult process, and we would like to avoid it where possible. We therefore ask that all subdomains make estimates of (1) their current size (in January 17, 1985 D R A F T - 5 - number of hosts), (2) size in one year, (3) size in 2 years, and (4) size in 5 years. We request that the subdomain structure of each domain be established so that growth by lowering is not needed for 5 years, if possible, and not for 2 years in any case. This growth plan, including estimates and proposed subdomain structure, should be included when the domain applies for registration in the UUCP domain. We do ask that an appropriate balance be created between room for growth and length of addresses. If the part of a typical mailing address to the right of an @ sign is longer than 16 characters, chances are that the structure is too bushy. A domain name like osgd.osg.cb.att.uucp might reflect the organizational heirarchy, but is a lot for people to remember and type. Please try to keep the names short and the number of levels small. AT&T is probably the largest subdomain of UUCP, yet addresses no worse than osgd.cb.att.uucp are anticipated. 2.2 SSSSttttaaaannnnddddaaaarrrrddddssss This section describes conventions and standards that all domains are expected to support. Additional standards will be established as necessary by the UUCP project. 2.2.1 Unique_Names. Each domain name must be unique within its parent domain. For example, within the UUCP domain, there cannot be two domains named CAL.UUCP and CAL.UUCP. There could, however be two domains called BA.CAL.UUCP and BA.ATL.UUCP, or CAL.UUCP and CAL.CSNET. Note that upper and lower case letters are considered the same in domain names, and that names may cntain the 26 Roman letters A-Z, the digits 0-9, and the hyphen, using periods to separate the levels. 2.2.2 Name_Length. No hard limit is placed on the length of names used for addresses in the UUCP domain. However, for human factors reasons, we expect that names chosen will be both representative of the constituency of the subdomain, and short enough that people will not object to typing complete electronic addresses. It is recommended that typical fully qualified domain names be no more than 16 characters long, including periods, and that typical user names on the left of the @ be kept under 16 characters in length as well. For example, the ATT.UUCP subdomain will probably allow electronic addresses in two forms, a machine address form like ``john@ihnp4.ATT.UUCP'' and a person name form like ``John.Smith@ATT.UUCP''. Software should be written to handle addresses of at least 255 characters, since explicit routes can create very long paths. January 17, 1985 D R A F T - 6 - This is not a hard limit, but rather a guideline. The primary motivation is that short names are easier to type than long names. If there are other overriding considerations, longer names may be necessary. However, in general, we recommend that the number of levels be kept as small as possible, and that names be kept as short as possible, so that addresses are kept easy to type. In many cases, a natural administrative subdomain does not need to be represented in the explicit domain tree, because software is capable of distinguishing a large number of names. For example, given a domain such as ``ernie.cs.berk.uc.cal.uucp'', representing the ``Ernie'' machine of the Computer Science department at the Berkeley campus of the University of California, some of these levels do not really need to be present. The alternative ``ernie.ucb.cal.uucp'' would have done just as well. Two levels of administrative delegation can often be compressed into one level of the domain tree. Notice also that we avoid longer names such as ``ernie.comp-sci.berkeley.university-of- california.california.uucp''. Try to keep the names as short as possible, while keeping them reasonably readable. Well known (or soon to become well known) two or three letter names for countries, states, provinces, and major geographic regions are accceptable, but don't carry this to an extreme. Three to six letters per domain level is a good typical name length, but there will be many situations where two or eight or ten letter names will be needed. 2.2.3 Software_Standards. All subdomains are expected to conform to the appropriate ARPA standards for syntax and semantics of mail and news, including RFC822, RFC920, and RFC850. (News need not be supported, but each contact person is required to have an electronic mail address.) Mail transferred within a subdomain is an internal matter and can be in any format agreed upon within the subdomain, but all mail leaving the subdomain must appear to external software to have originated on an 822 conforming host, and mail conforming to 822 standards entering the subdomain must be accepted and properly dealt with. It is recommended that internal mail also use the 822/920 syntax, as this makes gateway issues much easier. Two consenting hosts are free to exchange mail or news in any format they mutually agree upon, so long as it does not cause problems for the rest of the network. For example, two hosts may choose to exchange news in notesfile format; there is no problem unless news passing through this link loses information and the resulting news is propagated throughout the rest of the net. January 17, 1985 D R A F T - 7 - Mail must also conform to the companion document ``UUCP Mail Transmission Format Standard.'' This document summarizes how the 822/920 standards are to be interpreted in the UUCP domain. Subdomains must conform to the UUCP interpretation. In practice, this will mean at least support of one extension, the dom.ain.name!user syntax as being equivalent to user@dom.ain.name. We expect to provide public domain software that meets these requirements in the next several months, but hosts are free to run any software that conforms to the appropriate standards. 2.3 SSSSeeeerrrrvvvviiiicccceeeessss This section describes ongoing services that each subdomain is expected to provide to their members and to the UUCP community as a whole. Subdomains are encouraged to divide these services up, as much as possible, among the major participants in the domain, in order to share the work load and the traffic load. 2.3.1 Registry. Each subdomain must keep a registry of all machines and subdomains within it. While we do not require the complete registry to be published, it must be possible to determine the organization and contact person for any user, machine, or subdomain within the UUCP domain. For geographic domains, the registry will normally be available to the public, and distributed locally as needed. Private domains may publish their registry or not, as appropriate. A registry can be through of as a phone book. Top level domains, like country codes, are published everywhere. 2nd level domains, like city codes or area codes, are published in their own country, and available elsewhere. Lower level domains, like local phone numbers, are published locally. PBX extensions within a company, like private domain listings, may be considered private. There must be only one master copy of the registry for each domain, all others should be copies made from the master copy. (This is to prevent multiple, inconsistent, versions of the registry from appearing, with no final arbiter to determine which is correct, and to make maintenence of the registry practical.) We expect that either a name server will be made available, or else the responsible persons will be able to track down any address within their subdomain and find out who it belongs to. This chain of responsibility is necessary in order to idenfify the source of messages causing problems for other sites, and is a requirement placed on us by the ARPA registry in order to become a top January 17, 1985 D R A F T - 8 - level domain. (These registries are different from the UUCP host name registry, which registers the 6-letter UUCP transport names.) Responses to manual name service queries must include complete information for both contact persons, in order to provide a robust name service. 2.3.2 Domain_Server. Once a standard domain server protocol has been documented and public domain software made available to implement it in the UUCP environment, we expect each domain to support such a domain server and allow access to it to anyone. It is not necessary to provide a complete list of all registered hosts, but it is essential that requests of the form ``who is abc.xyz.n-eng.uucp and who is their contact person'' be answered, in order to track down the source of errant messages. It will also probably be necessary to provide a server that maps 6-letter UUCP names into domain names somewhere on the net. Until a name server has been made available, we adopt the convention that a name service is done by hand. A query such as ``who is the contact person for OSGD.CB.ATT.UUCP'' is resolved by contacting the contact person for the lowest known domain, either by telephone or electronic mail, and asking for the information for the next lower domain. For example, you could phone the ATT.UUCP contact, who would refer you to the CB.ATT.UUCP contact, who would refer you to the OSGD.CB.ATT.UUCP contact. This process will eventually be automated. 2.3.3 Gateway. The subdomain must provide at least one gateway machine for the subdomain. This machine must be able to handle all the traffic between the inside and outside of the subdomain, and must also be willing to forward traffic from outside machine to outside machine. This gateway machine or machines will become part of the UUCP backbone, and complete UUCP connection information for the gateway will be published regularly. Subdomains are encouraged to set up more than one gateway; however, in doing so, they should ensure that all gateways have good solid connections with each other and that all gateways run the same versions of routing tables for the subdomain. External nodes should be free to forward properly addressed mail to any gateway and be sure that the results will be the same as if the mail were forwarded to a different gateway. 2.3.4 Updates. The responsible people will be required to ensure that their parent domain has up-to-date and correct contact and connection information for them. We expect that, unless no information has changed, that gateways will be updated every one week to one month. The contacts for the subdomain will probably want to keep connection January 17, 1985 D R A F T - 9 - information for all internal sites, but are not required to present this information to the UUCP Project. 2.4 GGGGuuuuiiiiddddeeeelllliiiinnnneeeessss This section describes some guidelines for operation of hosts and subdomains. There is more flexibility in conforming to these guidelines than to the requirements above, but reasonable conformance is still expected. 2.4.1 Representative_Names. We expect all our subdomains and their subdomains to choose names that are reasonably representative of the constituency of the subdomain. In particular, we discourage subdomain names that are chosen from ``themes'', and subdomain names that are just the name of the gateway. Thus, ``ethel'' (an example from an ``I Love Lucy'' theme) and ``xyzvax'' (a machine name which is also a gateway) should be avoided, in favor of names like ``n-eng'' (New England.) Of course, if the most descriptive name for the subdomain happens to be theme based (e.g. ``homer'' for the machines named ``ulysses'', ``kalypso'', etc, or ``xyz'' if the subdomain is the company named ``xyz'' whose gateway machine is also called ``xyz'') the name will be allowed. In general, a descriptive organizational name or geographic name is preferred, if it is meaningful outside the subdomain. The intent of this requirement is that it is easier for humans to remember names that are descriptive of the user or the user's organization than ``cute'' names, especially for infrequent users of the system. It is also more helpful when a user receives a message from someone in a domain they don't recognize, if the name is somehow indicative of the location or organization of the sender. 2.4.2 New_Machines_and_Domain_Names. If you have a new machine or a new group of machines to register, it is your responsibility to find a domain (at some level) willing to accept your registration. If you belong to an organization that already has a domain registered, you should probably join that domain. If not, there is probably a geographic domain that represents your geographic region, and it should be willing to register you. If your geographic region does not have a domain, you can either find a nearby region and attempt to convince them to expand their borders to include your location; find others in your region and band together with them to create a new domain; or if you are remotely located you can apply for an exception to the minimum 2nd level domain size and create a new 2nd level domain (but this new domain must be willing to register any new machines in your region.) January 17, 1985 D R A F T - 10 - Choosing a name for a new machine is hard, especially if the owners of the machine are new to the net and unfamiliar with customs and problems that can arise. A good name for the first machine a company gets is the name of the company. It is quite common to name a machine after the type of machine (e.g., ``csvax'' or ``ucbvax'') but this is a bad idea, because if you acquire more machines of the same type the names will be confusing. Plan for the day you have lots of machines, for example, ``framus-a'' or ``a.framus'' if your company name is Framus and your theme is letters of the alphabet, or ``ethel.framus'' if you are naming your machines after an ``I Love Lucy'' theme. Themes already being used include the Marx Brothers, stars, constellations, Homeric characters, musical tempos, brands of automobile, and the cast of Leave it to Beaver, as well as more mundane themes such as letters of the alphabet, numbers, colors, names of departments, names of the users of personal computers, and so on. Originality is encouraged, as long as the higher level domain name is descriptive of the organization. Bad names include ``unix'', ``bigvax'', ``vax'', ``gateway'', ``sun'', ``framusvax''. Also bear in mind that ``UNIX'', ``VAX'', and similar terms are trademarks of various companies. 2.4.3 Geographic_Domains. There are two kinds of domains: geographic and non-geographic. A typical non-geographic domain would represent a particular organization, such as a university, company, government entity, or some other cooperative organization. A geographic domain is one that is intended to register anyone in that geographic region. A geographic domain need not accept top level registrations from sites in the region, but should allow any machine in the region to register somewhere under the domain. For example, a geographic domain called ``n-eng'' for ``New England'' may subdivide into domains ``boston'', ``nh'', ``mass'', and so on. The ``boston'' domain may in turn have a ``bbn'' subdomain for the BB&N company. A host ``cca'' at the BB&N company should be allowed to join the ``bbn'' domain as ``cca.bbn.boston.n-eng.uucp'', but need not be allowed to join the ``n-eng'' domain directly as ``cca.n- eng.uucp''. Non-geographic domains may establish any rules and requirements they wish upon their members. Geographic domains may also establish any rules and requirements, but it is expected that a rule obeying host which pays its own way can register somewhere within the geographic domain within which it is located. January 17, 1985 D R A F T - 11 - It is recommended that all hosts belong to some geographic domain, in addition to any non-geographic domains it joins. This will enable people to send you mail in terms of the geography. For example, the machine ``osgd'' may belong to the ``cb.att.uucp'' domain, but it should also register with the ``cmh.mid-w.uucp'' domain, since it is located in Columbus (cmh) in the midwest (mid-w.) 2.4.4 Initial_Domains. To set the flavor of this structure, our intent is that the initial 2nd level domains under UUCP will be along the lines of Figure 1. This is not a firm requirement, just a guideline. (We are still open to suggestions for restructuring this, changing the spelling conventions, splitting a few of these into two domains, and so on.) Geographic 2nd Level Domains WA.UUCP Washington State OR.UUCP Oregon State N-CA.UUCP Northern California S-CA.UUCP Southern California MTN.UUCP Mountain states (AZ, UT, CO, NM, WY, ID, MO) S-CEN.UUCP South Central states (TX, OK, LA) MID-W.UUCP Midwestern states (ND, SD, NB, KS, MN, IA, MO, WI, IL, IN, MI, OH, KY, WV) S-EAST.UUCP Southeastern states (AR, TN, MS, AL, GA, NC, SC, FL) ATL.UUCP Atlantic States (VA, DC, MD, PA, NJ, NY) N-ENG.UUCP New England (MA, CT, RI, VT, NH, ME) HI.UUCP Hawaii W-CAN.UUCP Western Canada (BC, AB, SK, MB) E-CAN.UUCP Eastern Canada (ON, PQ, etc) EUR.UUCP Europe UK.UUCP Great Britain, United Kingdom and Ireland AUS.UUCP Australia ASIA.UUCP East Asia, including Korea and Japan ISRAEL.UUCP Israel Non-Geographic 2nd Level Domains ATT.UUCP the AT&T company HP.UUCP the Hewlett Packard company FFFFiiiigggguuuurrrreeee 1111.... Sample UUCP 2nd Level Domains This is just a rough guideline, and the actual domains will determine their exact boundaries. For example, we aren't January 17, 1985 D R A F T - 12 - sure where to put Hawaii, or whether it makes sense to include Australia. There is room for a few additional domains, should some of the above be too big. For example, western New York state and Pennsylvania might wish to form their own domain, or North Carolina might. As new parts of the world join UUCP, such as Alaska or Africa, additional domains will be created, as needed. Finally, the names above are also only suggestions. 2.4.5 Routing. The established convention on UUCP is that if two users on different machines exchange mail often, a direct UUCP link should be set up between the two machines. If this is not possible, a short path should be established between the two, and permission should be obtained from all intermediate hosts (since you are running up their phone bill and using their machine cycles.) For seldom used connections, the convention is that others will forward your mail (at their expense) if you will forward their mail (at your expense.) Domains are not the same as routes. Mail from cbosgd.att.uucp to seismo.arpa does not necessarily travel to machines att.uucp, uucp, and arpa. Direct links and known short paths should be used whenever possible. Routes that go up the tree and back down should be viewed as fallback routes, used only when no better route is known. 3. CCCCOOOONNNNCCCCLLLLUUUUSSSSIIIIOOOONNNN This document is a draft. It does not represent final requirements. Comments and suggestions on these requirements are encouraged. Please send them to cbosgd!mark. cbosgd can be reached via seismo, ucbvax, ihnp4, allegra, decvax, and many other well known hosts. Discussion of the plan on Usenet newsgroup net.mail is also encouraged. January 17, 1985 D R A F T - 13 - 4. FFFFUUUURRRRTTTTHHHHEEEERRRR RRRREEEEAAAADDDDIIIINNNNGGGG For additional reading, see: 1. RFC822. Standard for the Format of ARPA Internet Text Messages, August, 1982. 2. RFC882. Domain Names - Concepts and Facilities, November 1983. 3. RFC883 Domain Names - Implementation and Specification, November 1983. 4. RFC920. Domain Requirements, October 1984. 5. RFC921. Domain Name System Implementation Schedule, October 1984. 6. UUCP Mail Transmission Format Standard, UUCP Project, in preparation. January 17, 1985 D R A F T