home *** CD-ROM | disk | FTP | other *** search
- UUCP Zone Registry
- 2/6/87
-
- To use smail, or other software supporting domain addresses, you need
- to have a domain name registered in the domain tree. This name must be
- unique in the world, and must be registered with the appropriate
- registry. Your domain must also have a forwarder from DDN (also
- called ARPANET and MILNET).
-
- If your primary network affiliation is with CSNET, BITNET, or DDN,
- your organization may already have a domain name. If you are not
- on one of these networks, you can join the UUCP Zone to get your
- organization name registered.
-
- History and Structure
-
- The exact structure of the domain tree is evolving. In 1984, the top
- levels were network names (ARPA, CSNET, BITNET, UUCP, and so on) and
- the second levels were hosts. The problem with this structure is that
- machines connected to several networks have several names, and it's
- difficult for users to predict the address of someone without knowing
- their network connections.
-
- In 1986, the domain tree in the USA has three major top level domains:
- COM for companies, EDU for educational institutions, and GOV for
- government entities. Three other top level names exist: MIL, NET, ORG,
- but are somewhat specialized. For the most part, countries other than
- the USA are using the ISO 3166 2 letter abbreviation for their country
- as a top level.
-
- Examples include US for USA, AU for Australia, JP for Japan, NL for
- Netherlands. Abbreviations that are not ISO 3166 include CAN for
- Canada and and UK for the United Kingdom.
-
- One way of looking at the domain tree is that the top level is always
- the country, where COM, EDU, and GOV are three pretend "countries" all
- located in the USA. (This isn't quite strictly true, since some Canadian
- organizations are registering under EDU or COM, intending to also register
- under CAN later.)
-
- The second level is generally the name of the organization, using the
- shortest possible abbreviation that is clear and unique, thus ATT, DEC,
- IBM, HP, etc. The choice of exact name is up to the organization, and
- longer names, such as Berkeley.EDU or Tektronix.COM are perfectly
- acceptable. Just remember that people must type the name, as well as
- see it displayed.
-
- Not all countries use the second level for the organization. In
- particular, Australia and Britain have set up second level domains
- AC.UK and OZ.AU for their academic communities, and put the
- organization at the third level.
-
- The third and subsequent levels, if used, should be organizational
- units within the organization. Try to keep the number of levels to a
- minimum, since people have to type the names. More than four total
- levels (country, org, ou1, and ou2) should rarely be needed. The
- actual organizational units to be used are up to you, for example, they
- might be departments, or they might be machine names. For example,
- Stargate has names like Base.Stargate.COM, where COM means a company,
- Stargate is the organization (company) name, and Base is the name of
- the machine within Stargate. A larger example: AT&T is using names
- like cbpavo.MIS.OH.ATT.COM, where COM means AT&T is a company, ATT is
- the organization, OH means Ohio, MIS stands for Medical Information
- Systems, and cbpavo is a computer in the MIS project.
-
- A "zone" is a registry of domains kept by a particular organization. A
- zone registry is "authoritative", that is, the master copy of the
- registry is kept by the zone organization, and this copy is, by
- definition, always up-to-date. Copies of this registry may be
- distributed to other places and kept in caches, but these caches are
- not authoritative because they may be out of date. An authoritative
- answer is required for certain decisions, such as "this mail cannot be
- delivered because there is no such domain", or "the name you have
- chosen is available and is now assigned uniquely to you."
-
- In the USA, there are currently four zones: DDN (formerly called the
- ARPANET), CSNET, BITNET, and UUCP. These zones all share the top level
- domains COM, EDU, GOV, etc. The top level domains are administered by
- the DDN (Defense Data Network) NIC (Network Information Center) at SRI
- (SRI, Inc, formerly Stanford Research Institute, in Menlo Park, CA.)
- The CSNET, BITNET, and UUCP registries serve as a go-between to avoid
- swamping the NIC with individual registrations. It is possible for an
- organization to be members of more than one of these networks, in which
- case they register with each network, using the same name on all
- networks.
-
- The UUCP Project keeps a registry of members of the UUCP Zone. This
- registry is different than the UUCP map, although the registry is posted
- with the UUCP map. The UUCP Zone registry consists only of organizations
- which are members of the UUCP Zone. To become a member, it is
- necessary to explicitly join, just as one joins CSNET or BITNET. Just
- being reachable via a bang path does not imply membership, nor does
- appearance in the UUCP map.
-
- To join the UUCP Zone, it is necessary to apply for membership. This
- involves paying low annual membership dues to the project, deciding how to
- structure your domain and where to put it into the global domain tree,
- installing software such as smail, finding a forwarder, and doing some
- electronic paperwork. Please contact us at one of these addresses and
- ask for the membership kit; it will contain up-to-date information on
- joining, including the fee structure, information about forwarders,
- information about 3rd level domain "parks", and forms to fill out.
-
- See the "Contact Information" below for instructions to contact us;
- please use the "query" address for the initial query.
-
- Organizational Registry
-
- If you are registering your organization in the UUCP zone, you are in
- effect creating another zone registry for your organization. Any
- subdomains of your organizational domain must be registered with you.
- (You need not keep us informed of all your subdomains, just the gateways.)
-
- For the time being, unless you are ready to start organizing the machines
- in your organization, don't worry about this. You can just set things up
- to handle your one machine (or more if you like). Just keep in mind that
- your machine is but one machine in your organization, so you should be
- planning to have an address like fred@compsci.BigCorp.COM (where "fred" is
- a login name on machine "compsci" owned by organization "BigCorp") rather
- than fred@BigCorp.COM.
-
- For example, if you are the first host in the University of North Dakota to
- join, you are creating a subdomain UND.EDU (for example.) Your host might
- have a name like undvax.UND.EDU. When other machines are joined in later,
- they will also register under UND.EDU, for example, cs3b20.UND.EDU.
- All subdomains of UND (this may mean all hosts in the UND domain) are
- registered with the UND.EDU registry. Unless you create a campus organization
- specifically to run this registry, this means you are the UND.EDU registry.
- It is your job to keep track of everybody in the registry, hand out names
- for subdomains, make sure there are no duplicates (you have to make sure there
- aren't two machines called cs3b2.UND.EDU, for example) and know who to
- contact if a problem arises. You have created the UND Zone, which is
- similar to the UUCP Zone, but one level further down in the heirarchy.
-
- At some point, you may decide that you want more layers of subdomains in
- your zone. For example, if the CS, Math, and Stat departments at UND all
- want to manage their own zones, you might use names like vax.CS.UND.EDU,
- 3b20.Math.UND.EDU, and so on. The UND Zone has delegated its naming
- authority to the CS Zone, the Math Zone, and so on. The root delegates
- to COM, COM delegates to UUCP, UUCP delegates to UND, UND delegates to CS.
-
- Note that the names are given in upper or mixed case, but the exact
- case doesn't matter, since the software ignores it. We recommend that
- you choose your capitalization to look nice when printed.
-
- Note also that "vax", "3b20", and the like are terrible host names,
- because sooner or later you'll have more than one vax, or more than
- one 3b20, and the names will be confusing. We recommend organizational
- names, based on the department or project the machine is used for.
- Of course, in order to keep the names reasonably short and to avoid
- duplicating names in the heirarchy, some compromise will be needed.
- For example, csvax.CS.UND.EDU is redundant, but RISC.CS.UND.EDU might
- be a good name for the computer used by the RISC project in the CS
- department.
-
- Notes:
-
- Organizations are encouraged to eventually support two kinds of electronic
- mail addresses:
-
- (1) Login name on machine: a string which is understood on a particular
- machine, combined with a fully qualified domain name of a machine.
- The string is often, although not always, a login name.
- Example:
- mrh@cbosgd.ATT.COM
-
- (2) Personal name in organization: a string which is the name of a person,
- understood by all gateway machines.
- Example:
- Mark.R.Horton@ATT.COM
- This allows mail to be sent without knowing the full address
- of the recipient, only their name and company. Implementations
- should be as forgiving as possible of errors in the personal name.
- For example, if possible, as many of the following as possible
- should be accepted:
- mark.r.horton@att.com (ignore case)
- m.r.horton@ATT.COM (accept initials)
- mark.horton@ATT.COM (don't require initials)
- mark.randolph.horton@ATT.COM
- m.horton@ATT.COM (if not ambiguous)
- horton@ATT.COM (if not ambiguous)
- mark.horton.sr@ATT.COM (allow generational qualifier)
-
- However, it's perfectly fine to just support just one style.
- Since the login name style (1) is easy to support, you may prefer to
- just handle that one, especially at first. Style (1) is by far the
- most commonly used method as this is written.
-
- Please note that you should support both RFC 976 and the documents
- it refers to, in particular RFC 822 and RFC 920. This means, for
- example:
-
- (a) The name "postmaster" on all machines visible to the outside
- should be forwarded to the technical contact. This can be
- easily done with an alias in /usr/lib/aliases, if your site
- runs sendmail or smail 2.0. Please be sure to also support
- Postmaster, PostMaster, and POSTMASTER, if you use sendmail.
-
- (b) Your machine should not alter valid RFC 822 headers, such as
- From:, of mail it generates or forwards. Many machines running
- sendmail have a bug which adds uucpname! to the front of such
- addresses. Installing smail will fix the bug, because mail
- passed through the machine is not passed through sendmail.
- We hope to make a fix to sendmail available, also, at a
- later date.
-
- Contact Information
-
- We strongly encourage electronic mail for queries, updates, and
- applications. This cuts down on our costs, and we can pass those
- savings along to you. We currently do not have a telephone number
- for queries, although we hope to have one in the near future. If
- you are unable to send and receive electronic mail, you will have
- to wait until we are prepared for telephone calls or postal mail.
-
- For queries: uucp-query@Stargate.COM cbosgd!stargate!uucp-query
-
- For updates: uucpmap@Stargate.COM cbosgd!stargate!uucpmap
-
- For problems: uucp-problem@Stargate.COM cbosgd!stargate!uucp-problem
-
- To register: registry@Stargate.COM cbosgd!stargate!registry
-
- UUCP host "stargate" can also be reached via uiucdcs or cbatt.
- #
- #@(#)Registry 2.1 smail 12/14/86
- #
-