home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume8 / smail2 / part01 / doc / Registry < prev    next >
Encoding:
Text File  |  1987-02-16  |  11.1 KB  |  228 lines

  1.             UUCP Zone Registry
  2.                  2/6/87
  3.  
  4. To use smail, or other software supporting domain addresses, you need
  5. to have a domain name registered in the domain tree.  This name must be
  6. unique in the world, and must be registered with the appropriate
  7. registry.  Your domain must also have a forwarder from DDN (also
  8. called ARPANET and MILNET).
  9.  
  10. If your primary network affiliation is with CSNET, BITNET, or DDN,
  11. your organization may already have a domain name.  If you are not
  12. on one of these networks, you can join the UUCP Zone to get your
  13. organization name registered.
  14.  
  15.         History and Structure
  16.  
  17. The exact structure of the domain tree is evolving.  In 1984, the top
  18. levels were network names (ARPA, CSNET, BITNET, UUCP, and so on) and
  19. the second levels were hosts.  The problem with this structure is that
  20. machines connected to several networks have several names, and it's
  21. difficult for users to predict the address of someone without knowing
  22. their network connections.
  23.  
  24. In 1986, the domain tree in the USA has three major top level domains:
  25. COM for companies, EDU for educational institutions, and GOV for
  26. government entities.  Three other top level names exist: MIL, NET, ORG,
  27. but are somewhat specialized.  For the most part, countries other than
  28. the USA are using the ISO 3166 2 letter abbreviation for their country
  29. as a top level.
  30.  
  31. Examples include US for USA, AU for Australia, JP for Japan, NL for
  32. Netherlands.  Abbreviations that are not ISO 3166 include CAN for
  33. Canada and and UK for the United Kingdom.
  34.  
  35. One way of looking at the domain tree is that the top level is always
  36. the country, where COM, EDU, and GOV are three pretend "countries" all
  37. located in the USA.  (This isn't quite strictly true, since some Canadian
  38. organizations are registering under EDU or COM, intending to also register
  39. under CAN later.)
  40.  
  41. The second level is generally the name of the organization, using the
  42. shortest possible abbreviation that is clear and unique, thus ATT, DEC,
  43. IBM, HP, etc.  The choice of exact name is up to the organization, and
  44. longer names, such as Berkeley.EDU or Tektronix.COM are perfectly
  45. acceptable.  Just remember that people must type the name, as well as
  46. see it displayed.
  47.  
  48. Not all countries use the second level for the organization.  In
  49. particular, Australia and Britain have set up second level domains
  50. AC.UK and OZ.AU for their academic communities, and put the
  51. organization at the third level.
  52.  
  53. The third and subsequent levels, if used, should be organizational
  54. units within the organization.  Try to keep the number of levels to a
  55. minimum, since people have to type the names.  More than four total
  56. levels (country, org, ou1, and ou2) should rarely be needed.  The
  57. actual organizational units to be used are up to you, for example, they
  58. might be departments, or they might be machine names.  For example,
  59. Stargate has names like Base.Stargate.COM, where COM means a company,
  60. Stargate is the organization (company) name, and Base is the name of
  61. the machine within Stargate.  A larger example:  AT&T is using names
  62. like cbpavo.MIS.OH.ATT.COM, where COM means AT&T is a company, ATT is
  63. the organization, OH means Ohio, MIS stands for Medical Information
  64. Systems, and cbpavo is a computer in the MIS project.
  65.  
  66. A "zone" is a registry of domains kept by a particular organization.  A
  67. zone registry is "authoritative", that is, the master copy of the
  68. registry is kept by the zone organization, and this copy is, by
  69. definition, always up-to-date.  Copies of this registry may be
  70. distributed to other places and kept in caches, but these caches are
  71. not authoritative because they may be out of date.  An authoritative
  72. answer is required for certain decisions, such as "this mail cannot be
  73. delivered because there is no such domain", or "the name you have
  74. chosen is available and is now assigned uniquely to you."
  75.  
  76. In the USA, there are currently four zones: DDN (formerly called the
  77. ARPANET), CSNET, BITNET, and UUCP.  These zones all share the top level
  78. domains COM, EDU, GOV, etc.  The top level domains are administered by
  79. the DDN (Defense Data Network) NIC (Network Information Center) at SRI
  80. (SRI, Inc, formerly Stanford Research Institute, in Menlo Park, CA.)
  81. The CSNET, BITNET, and UUCP registries serve as a go-between to avoid
  82. swamping the NIC with individual registrations.  It is possible for an
  83. organization to be members of more than one of these networks, in which
  84. case they register with each network, using the same name on all
  85. networks.
  86.  
  87. The UUCP Project keeps a registry of members of the UUCP Zone.  This
  88. registry is different than the UUCP map, although the registry is posted
  89. with the UUCP map.  The UUCP Zone registry consists only of organizations
  90. which are members of the UUCP Zone.  To become a member, it is
  91. necessary to explicitly join, just as one joins CSNET or BITNET.  Just
  92. being reachable via a bang path does not imply membership, nor does
  93. appearance in the UUCP map.
  94.  
  95. To join the UUCP Zone, it is necessary to apply for membership.  This
  96. involves paying low annual membership dues to the project, deciding how to
  97. structure your domain and where to put it into the global domain tree,
  98. installing software such as smail, finding a forwarder, and doing some
  99. electronic paperwork.  Please contact us at one of these addresses and
  100. ask for the membership kit; it will contain up-to-date information on
  101. joining, including the fee structure, information about forwarders,
  102. information about 3rd level domain "parks", and forms to fill out.
  103.  
  104. See the "Contact Information" below for instructions to contact us;
  105. please use the "query" address for the initial query.
  106.  
  107.         Organizational Registry
  108.  
  109. If you are registering your organization in the UUCP zone, you are in
  110. effect creating another zone registry for your organization.  Any
  111. subdomains of your organizational domain must be registered with you.
  112. (You need not keep us informed of all your subdomains, just the gateways.)
  113.  
  114. For the time being, unless you are ready to start organizing the machines
  115. in your organization, don't worry about this.  You can just set things up
  116. to handle your one machine (or more if you like).  Just keep in mind that
  117. your machine is but one machine in your organization, so you should be
  118. planning to have an address like fred@compsci.BigCorp.COM (where "fred" is
  119. a login name on machine "compsci" owned by organization "BigCorp") rather
  120. than fred@BigCorp.COM.
  121.  
  122. For example, if you are the first host in the University of North Dakota to
  123. join, you are creating a subdomain UND.EDU (for example.)  Your host might
  124. have a name like undvax.UND.EDU.  When other machines are joined in later,
  125. they will also register under UND.EDU, for example, cs3b20.UND.EDU.
  126. All subdomains of UND (this may mean all hosts in the UND domain) are
  127. registered with the UND.EDU registry.  Unless you create a campus organization
  128. specifically to run this registry, this means you are the UND.EDU registry.
  129. It is your job to keep track of everybody in the registry, hand out names
  130. for subdomains, make sure there are no duplicates (you have to make sure there
  131. aren't two machines called cs3b2.UND.EDU, for example) and know who to
  132. contact if a problem arises.  You have created the UND Zone, which is
  133. similar to the UUCP Zone, but one level further down in the heirarchy.
  134.  
  135. At some point, you may decide that you want more layers of subdomains in
  136. your zone.  For example, if the CS, Math, and Stat departments at UND all
  137. want to manage their own zones, you might use names like vax.CS.UND.EDU,
  138. 3b20.Math.UND.EDU, and so on.  The UND Zone has delegated its naming
  139. authority to the CS Zone, the Math Zone, and so on.  The root delegates
  140. to COM, COM delegates to UUCP, UUCP delegates to UND, UND delegates to CS.
  141.  
  142. Note that the names are given in upper or mixed case, but the exact
  143. case doesn't matter, since the software ignores it.  We recommend that
  144. you choose your capitalization to look nice when printed.
  145.  
  146. Note also that "vax", "3b20", and the like are terrible host names,
  147. because sooner or later you'll have more than one vax, or more than
  148. one 3b20, and the names will be confusing.  We recommend organizational
  149. names, based on the department or project the machine is used for.
  150. Of course, in order to keep the names reasonably short and to avoid
  151. duplicating names in the heirarchy, some compromise will be needed.
  152. For example, csvax.CS.UND.EDU is redundant, but RISC.CS.UND.EDU might
  153. be a good name for the computer used by the RISC project in the CS
  154. department.
  155.  
  156.         Notes:
  157.  
  158. Organizations are encouraged to eventually support two kinds of electronic
  159. mail addresses:
  160.  
  161. (1) Login name on machine: a string which is understood on a particular
  162.     machine, combined with a fully qualified domain name of a machine.
  163.     The string is often, although not always, a login name.
  164.     Example:
  165.     mrh@cbosgd.ATT.COM
  166.  
  167. (2) Personal name in organization: a string which is the name of a person,
  168.     understood by all gateway machines.
  169.     Example:
  170.     Mark.R.Horton@ATT.COM
  171.     This allows mail to be sent without knowing the full address
  172.     of the recipient, only their name and company.  Implementations
  173.     should be as forgiving as possible of errors in the personal name.
  174.     For example, if possible, as many of the following as possible
  175.     should be accepted:
  176.     mark.r.horton@att.com    (ignore case)
  177.     m.r.horton@ATT.COM    (accept initials)
  178.     mark.horton@ATT.COM    (don't require initials)
  179.     mark.randolph.horton@ATT.COM
  180.     m.horton@ATT.COM    (if not ambiguous)
  181.     horton@ATT.COM        (if not ambiguous)
  182.     mark.horton.sr@ATT.COM    (allow generational qualifier)
  183.  
  184. However, it's perfectly fine to just support just one style.
  185. Since the login name style (1) is easy to support, you may prefer to
  186. just handle that one, especially at first.  Style (1) is by far the
  187. most commonly used method as this is written.
  188.  
  189. Please note that you should support both RFC 976 and the documents
  190. it refers to, in particular RFC 822 and RFC 920.  This means, for
  191. example:
  192.  
  193. (a) The name "postmaster" on all machines visible to the outside
  194.     should be forwarded to the technical contact.  This can be
  195.     easily done with an alias in /usr/lib/aliases, if your site
  196.     runs sendmail or smail 2.0.  Please be sure to also support
  197.     Postmaster, PostMaster, and POSTMASTER, if you use sendmail.
  198.  
  199. (b) Your machine should not alter valid RFC 822 headers, such as
  200.     From:, of mail it generates or forwards.  Many machines running
  201.     sendmail have a bug which adds uucpname! to the front of such
  202.     addresses.  Installing smail will fix the bug, because mail
  203.     passed through the machine is not passed through sendmail.
  204.     We hope to make a fix to sendmail available, also, at a
  205.     later date.
  206.  
  207.         Contact Information
  208.  
  209. We strongly encourage electronic mail for queries, updates, and
  210. applications.  This cuts down on our costs, and we can pass those
  211. savings along to you.  We currently do not have a telephone number
  212. for queries, although we hope to have one in the near future.  If
  213. you are unable to send and receive electronic mail, you will have
  214. to wait until we are prepared for telephone calls or postal mail.
  215.  
  216. For queries:    uucp-query@Stargate.COM        cbosgd!stargate!uucp-query
  217.  
  218. For updates:    uucpmap@Stargate.COM        cbosgd!stargate!uucpmap
  219.  
  220. For problems:    uucp-problem@Stargate.COM    cbosgd!stargate!uucp-problem
  221.  
  222. To register:    registry@Stargate.COM        cbosgd!stargate!registry
  223.  
  224. UUCP host "stargate" can also be reached via uiucdcs or cbatt.
  225. #
  226. #@(#)Registry    2.1 smail 12/14/86
  227. #
  228.