rfc1386.txt

RFC 的详细文档！

   REGIONAL | DISTRICT | LIBRARY
   =============================

   SCAQMD.DISTRICT.CA.US                     <====  a regional district
   Bunker-Hill-Improvement.DISTRICT.LA.CA.US <====  a local district

   Huntington.LIB.LA.US                    <====  a private library
   Venice.LA-City.LIB.CA.US                <====  a city library
   MDR.LA-County.LIB.CA.US                 <====  a county library

   K12 | CC | STATE UNIV | PRIVATE SCHOOLS
   =======================================

   Los-Angeles.UC.STATE.CA.US      <====  UCLA
   Berkeley.UC.STATE.CA.US         <====  "CAL"
   Irvine.UC.STATE.CA.US           <====  University of Calif. Irvine
   Santa-Cruz.UC.STATE.CA.US       <====  University of Calif. Santa Cruz
   Northridge.CSU.STATE.CA.US      <====  Calif. State. Univ. Northridge
   Fullerton.CSU.STATE.CA.US       <====  Calif. State. Univ. Fullerton
   Sonoma.CSU.STATE.CA.US          <====  Calif. State. Univ. Sonoma

   SMCC.Santa-Monica.CC.CA.US      <====  a public community college
   Trade-Tech.Los-Angeles.CC.CA.US <====  a public community college

   Hamilton.High.LA-Unified.K12.CA.US      <====   a public K12 school
   Sherman-Oaks.Elem.LA-Unified.K12.CA.US  <====   a public K12 school
   John-Muir.Middle.Santa-Monica.K12.CA.US <====   a public K12 school

   St-Monica.High.Santa-Monica.CA.US       <====  a private high school
   St-Monica.Elem.Santa-Monica.CA.US       <====  a private elem. school
   Crossroads-School.Santa-Monica.CA.US    <====  a private school
   Mary-Ellens.Montessori-School.LA.CA.US  <====  a private school
   Leland-Stanford-Jr-Univ.Stanford.CA.US  <====  a private school
   Loyola-Marymount-Univ.Los-Angeles.CA.US <====  a private school










Cooper & Postel                                                 [Page 7]

RFC 1386                     The US Domain                 December 1992


   When appropriate, subdomains are delegated and partioned in various
   categories, such as:

                   K12.<state>.US   =   kindegarten thru 12th grade
                    CC.<state>.US   =   community colleges
                   LIB.<state>.US   =   libraries
                 STATE.<state>.US   =   state government agencies
                <org-name>.FED.US   =   federal government agencies

   The Appendix-I contains the current US Domain Names BNF, but in
   actuality, the names under these subdomains may vary according to the
   decision of the administrators of these subdomains.

   Some users would like names associated with a greater metropolitan
   area or region like the "Bay Area" or "Tri-Cities".  One problem with
   this is that these names are not necessarily unique within a state.
   The best thing to do in this case is to use the larger metropolitan
   city in your host name.  Cities and in some cases counties are used.

3. REGISTRATION

   3.1  Requirements

   Anyone requesting to register a host in the US Domain is sent a copy
   of the US Domain policy and procedure, and must fill out a US Domain
   questionnaire.

   The US Domain template, is similar to the NIC Domain template
   however, it is not the same.  To request a copy of the US Domain
   questionnaire, send a message to the US Domain registrar (us-
   [e-mail]).

      Note:  If you are registering a name in a delegated zone
             (see Section 3.3.6).  Please register with the
             contact for that zone.

   The key people must have electronic mailboxes (that work).  Please
   provide all the information indicated in the "Administrator" and
   "Technical Contact" slot.  This person will be the point of contact
   for any administrative and policy questions about the domain.

   The administrator is usually the person who manages the organization
   being registered. The technical contact can also be administrator, or
   the systems person, or someone who is familiar with the technical
   details of the Internet. The technical contact should have a valid
   working e-mail address. This is necessary in case something goes
   wrong.




Cooper & Postel                                                 [Page 8]

RFC 1386                     The US Domain                 December 1992


   It is important that your "Return-Path" and "From" field indicate an
   Internet style address.  UUCP style addresses such as "host1!user"
   will not work. This is fine within the UUCP world, but not the
   Internet.  If you want people on the Internet to be able to send mail
   to you, your return path needs to be an Internet style address: such
   as host1![e-mail] or [e-mail].

   It is also possible to register through one of the Internet service
   providers that have established working relationships with the US
   domain administrator.

   If everything checks out, turn around time for registering a host is
   usually a day or two.  The nameservers are updated anywhere from 12
   to 24 hours later.

   There are two ways to be registered in the US Domain, directly, or by
   delegation.

   3.2  Direct Entries

   Direct entry in the database of the US Domain appeals most to
   individuals and small companies.  Fill out the application and send
   it directly to the US Domain administrator.  If you are in an area
   where the zone is delegated to someone else your request will be
   forwarded to the zone administrator for your registration.

   3.2.1 UUCP Hosts

   Many applicants have hosts in the UUCP world.  Some are one hop away,
   some two and three hops away from their "Internet Forwarder", this is
   ok.  What is important is getting an Internet host to be your
   forwarder.  If you do not already have an Internet forwarder, there
   are several businesses that provide this service for a fee, such as
   UUNET.UU.NET ([e-mail]), PSI ([e-mail])
   and CERFNET ([e-mail]).  Sometimes local colleges in your area
   are already on the Internet and may be willing to act as an Internet
   Forwarder.  You would need to work this out with the systems
   administrator we cannot make these arrangements for you.

   Although we work with UUCP service providers, the Internet US Domain
   registration is not affiliated with the registration of UUCP Map
   entries.  The UUCP map entry does not provide us with sufficient
   information.  If you do not have a copy of the US Domain
   questionnaire template, please send a message to: [e-mail]
   and request one.  See Appendix-II.






Cooper & Postel                                                 [Page 9]

RFC 1386                     The US Domain                 December 1992


   This is not an appropriate registration for the US Domain.

     #N starl
     #S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
     #O Starlight BBS
     #C Stephen Baker
     #E starl!sbaker
     #T [phone]
     #P 1107 SW 200th St #303B Miami, Fl. 33157
     #L 25 47 N / 88 10 W [city]
     #R
     #U mthvax
     #W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
      starl        mthvax(DAILY)

   If you are registering your host as a central site for a USENET group
   where other UUCP sites will feed from you, that's fine.  These UUCP
   sites do not need to register.  If however, the other sites become a
   subdomain of your hostname, then we will need to register them
   individually or add a wildcard record.

           For example:          bah.rochester.ny.us
                           host1.bah.rochester.ny.us
                           host2.bah.rochester.ny.us

   3.2.2 NON-IP Hosts

   To use US Domain names for non-IP hosts, there must be a forwarder
   host that is an IP host.  There must be an adminstrative agreement
   and a technical procedure for relaying mail between the non-IP host
   and the forwarder host.

   Case 1:
   -------

   Your host is not an IP host but does talk directly with a host that
   is an IP host.
                                                  +-----------------+
   +----------+            +---------+            |                 |
   |your-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
   +----------+            +---------+            |                 |
                                                  +-----------------+
   "Forwarder" must be an IP host on the Internet.

   You must ask "forwarder" if they are willing to be the internet
   forwarder for "your-host".

   In the US Domain of the DNS data base there must be an entry like



Cooper & Postel                                                [Page 10]

RFC 1386                     The US Domain                 December 1992


   this:
          "your-host"  MX  10  "forwarder"

   This must be entered by the US Domain administrator.

   In the "forwarder" routing tables there must be information about
   "your-host" with a rule like: If I see mail for "your-host" I will
   send it via uucp by calling phone number "123-4567".

   Case 2:
   -------

   In this case your hosts talks to another host that ... that talks to
   an IP host.  In other words, there are multiple hops between your host
   and the Internet.
                                                  +-----------------+
   +----------+            +---------+            |                 |
   |path-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
   +----------+            +---------+            |                 |
       |                                          +-----------------+
      UUCP
       |
   +----------+
   |your-host |
   +----------+

   "Forwarder" must be an IP host on the internet.

   You must ask "forwarder" if they are willing to be the Internet
   Forwarder for "Your-Host".  You must ask "path-host" to relay your
   mail.

   In the US Domain of the DNS DataBase there must be an entry like this:

          "your-host"  MX  10  "forwarder"

   This must be entered by the US Domain Administrator.

   In the "forwarder" routing tables there must be information about
   "your-host" with a rule like: If I see mail for "your-host" I will
   send it via UUCP to "path-host" by calling phone number "123-4567".
   and "path-host" must also know how to relay the mail to "your-host".

   Note: It is assumed that "path-host" is already MXed to "forwarder".
   It is not appropriate to ask to MX "your-host" to "path-host" (this
   is sometimes called double MXing).  The host on the right hand side
   of an MX entry must be a host on the Internet with an IP address
   (e.g., 128.9.2.32).



Cooper & Postel                                                [Page 11]

RFC 1386                     The US Domain                 December 1992


   3.3  Delegated Subdomains

   The administrator of the US Domain is responsible for the assignment
   of all the DNS names that end with ".US".  Of course, one person or
   even one group can't handle all this in the long run so portions of
   the name space are delegated to others.

   Delegation of cities, companies within cities, schools (K12),
   community colleges (CC), libraries (LIB), state government (STATE),
   and federal government agencies, departments, etc., is acceptable and
   practical.

   For a delegated portion of the namespace, for example a city, no
   alterations can be made to that name, no abbreviations added, etc.
   unless applied for.

   Sometimes there may be two people running name servers in the same
   city because different portions of the name space has been delegated
   to them.  For example, someone may be delegated the <city>.<state>.US
   name space, and someone else from a state government agency may have
   the .STATE.<state>.US, portion.  For example, Fred may run the name
   servers for Sacramento.CA.US and Joe may run the name servers for
   STATE.CA.US in Sacramento.

   If a company would like to have wildcard records added, or run their
   own name servers in a city that we have delegated name space to, this
   is ok.

   Delegation of the whole State namespace is not yet implemented.  The
   delegated part of the name space is in the form of:

                    .STATE.<state>.US.
                      .K12.<state>.US.
                       .CC.<state>.US.
                      .LIB.<state>.US.
        .<org-name>.<city>.<state>.US.
         .CITY.<city-name>.<state>.US.
                   .<org-name>.FED.US.

   3.3.1  Schools

   As schools begin to join the Internet, there ought to be a consistent
   scheme for naming them.  A "K12" name branch has been established in
   each state in the US Domain for this purpose.

   Public schools are usually organized by districts which can be larger
   or smaller than a city or county.




Cooper & Postel                                                [Page 12]

RFC 1386                     The US Domain                 December 1992


   It makes sense to name schools within districts.  However districts
   often have the same name as a city or county so there has to be a way
   to distinguish a public school district name from some other type of
   locality name.  The keyword "K12" is used for this.

   In some districts, the same school name is used at different levels,
   for example, Washington Elementary School and Washington High School.
   We suggest that when necessary the keywords "Elementary", "Middle",
   and "High" be used to distinguish these schools.  These keywords
   would only be used when they are needed, if the school's name is
   unique without such keywords don't use them.

   Typical K12 school names currently used are like:

              IVY.PRS.K12.NJ.US
              DMHS.JCPS.K12.KY.US
              OHS.EUNION.K12.CA.US
              BOHS.BREA.K12.CA.US