PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc0883.txt =

page 6 of 44
























 

RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


   Design philosophy

      The design presented in this memo attempts to provide a base which
      will be suitable for several existing networks.  An equally
      important goal is to provide these services within a framework
      that is capable of adjustment to fit the evolution of services in
      early clients as well as to accommodate new networks.

      Since it is impossible to predict the course of these
      developments, the domain system attempts to provide for evolution
      in the form of an extensible framework.  This section describes
      the areas in which we expect to see immediate evolution.

      DEFINING THE DATABASE

      This memo defines methods for partitioning the database and data
      for host names, host addresses, gateway information, and mail
      support.  Experience with this system will provide guidance for
      future additions.

      While the present system allows for many new RR types, classes,
      etc., we feel that it is more important to get the basic services
      in operation than to cover an exhaustive set of information.
      Hence we have limited the data types to those we felt were
      essential, and would caution designers to avoid implementations
      which are based on the number of existing types and classes.
      Extensibility in this area is very important.

      While the domain system provides techniques for partitioning the
      database, policies for administrating the orderly connection of
      separate domains and guidelines for constructing the data that
      makes up a particular domain will be equally important to the
      success of the system.   Unfortunately, we feel that experience
      with prototype systems will be necessary before this question can
      be properly addressed.  Thus while this memo has minimal
      discussion of these issues, it is a critical area for development.

      TYING TOGETHER INTERNETS

      Although it is very difficult to characterize the types of
      networks, protocols, and applications that will be clients of the
      domain system, it is very obvious that some of these applications
      will cross the boundaries of network and protocol.  At the very
      least, mail is such a service.

      Attempts to unify two such systems must deal with two major
      problems:

      1. Differing formats for environment sensitive data.  For example,



 

RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


         network addresses vary in format, and it is unreasonable to
         expect to enforce consistent conventions.

      2. Connectivity may require intermediaries.  For example, it is a
         frequent occurence that mail is sent between hosts that share
         no common protocol.

      The domain system acknowledges that these are very difficult
      problems, and attempts to deal with both problems through its
      CLASS mechanism:

      1. The CLASS field in RRs allows data to be tagged so that all
         programs in the domain system can identify the format in use.

      2. The CLASS field allows the requestor to identify the format of
=6=

1|2|3|4|5| < PREV = PAGE 6 = NEXT > |7|8|9|10|11|12|13|14|15.44

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.012217 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)