Domain name system implementation schedule
RFC 897

Document Type RFC - Unknown (February 1984; No errata)
Updated by RFC 921
Updates RFC 881
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 897 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         Jon Postel
Request for Comments: 897                                            ISI
                                                           February 1984
Updates:  RFC 881

               Domain Name System Implementation Schedule

Status of this Memo

   This memo is a policy statement on the implementation of the Domain
   Style Naming System in the Internet.  This memo is a partial update
   of RFC 881.  This is an official policy statement of the ICCB and the
   DARPA.

   The intent of this memo is to detail the schedule for the
   implementation for the Domain Style Naming System.  The explanation
   of how this system works is to be found in the references.

The Current Situation

   Simple Names

      Hosts in the ARPA research and DDN operational communities are
      currently assigned names in a flat or global name space of
      character strings.  There are some limits on these names.  They
      must start with a letter, end with a letter or digit and have only
      letters or digits or hyphen as interior characters.  Case is not
      significant.

         For example:  USC-ISIF

   Tables

      Every host in the Internet is expected to have a way of
      translating the name of any other host into its Internet address.

      By and large, the name to address translation is done by looking
      up the information in a table of all hosts.

      The maintenance of this table is centralized at the Network
      Information Center (NIC).  Each host is expected to obtain a
      current copy of the table on a timely basis.

   Interface to the World

      A great deal of mail moves between the Internet and other
      "systems" that somehow transport mail among computers.  This is
      currently done by hiding some sort of "other-system" addressing
      information in the local-part of the mail address and using a
      mail-relay host in the host-part of the mailbox.

Postel                                                          [Page 1]



RFC 897                                                    February 1984
Domain Implementation Schedule

      For example,

         OBERST%EDUCOM.MAILNET@MIT-MULTICS
         EDMISTON.CIC@CSNET-RELAY

The Future Situation

   Hierarchical Names

      Because of the growth of the Internet, structured names (or domain
      style names) will be used.  Each element of the structured name
      will be a character string (with the same constraints that
      previously applied to the simple names).

         For example:  F.ISI.USC.ARPA

   Servers

      Every host in the Internet will be expected to have a way of
      translating the name of any other host into its Internet address.

      By and large, the name to address translation will be done by
      interacting with a service.  There will be a number of servers
      that each hold a portion of the name to address information.

      The maintenance of the translation data will be subdivided and
      distributed.

   There are several stages of implementation for the servers and
   several levels of development for use of the domain style names.

      First, there is the simple substitution of the domain style names
      for the current host names, and the subdivision of these into
      several domains.  At this stage all domain style names directly
      translate to host addresses and all domain style names have two
      components.

         For example:  USC-ISIF.ARPA  or  USC-ISIA.DDN

         and:  Postel@USC-ISIF.ARPA  or  Kahn@USC-ISIA.DDN

         Here we expect that "USC-ISIF.ARPA" is the name of an Internet
         host and that we can send mail for "Postel" to the SMTP port on
         that host.  It may be that some backward host can still fake it
         by ignoring the ".ARPA" and looking up an address for
         "USC-ISIF".

Postel                                                          [Page 2]



RFC 897                                                    February 1984
Domain Implementation Schedule

         Using the domain name servers (but not the tables) mail
         forwarding may be supported.  A domain name server query can
         say "I want to send mail to ABCDEF.ARPA".  The response might
         be "to send mail to ABCDEF.ARPA send it to the mail relay
         GHIJKL.ARPA at address 123.123.123.123".

      Second, there is an extension to more name components.

         For example:  F.ISI.USC.ARPA  or  A.USC-ISI.DDN

         and:  Postel@F.ISI.USC.ARPA  or  Kahn@A.USC-ISI.DDN

         Here we expect that "F.ISI.USC.ARPA" is the name of an Internet
         host and that we can send mail for "Postel" to the SMTP port on
         that host.  It is unlikely that a backward host can hack this
         at all.

      Third, there is an extension to domain style names that may
      represent only organizations or administrative entities.  Finding
      a host that represents such entities may require a level of
Show full document text