rfc1123.txt

bind 9.3结合mysql数据库





RFC1123                       INTRODUCTION                  October 1989


        are designed for restricted contexts might choose to use
        different specifications.

   However, the specifications of this document must be followed to meet
   the general goal of arbitrary host interoperation across the
   diversity and complexity of the Internet system.  Although most
   current implementations fail to meet these requirements in various
   ways, some minor and some major, this specification is the ideal
   towards which we need to move.

   These requirements are based on the current level of Internet
   architecture.  This document will be updated as required to provide
   additional clarifications or to include additional information in
   those areas in which specifications are still evolving.

   This introductory section begins with general advice to host software
   vendors, and then gives some guidance on reading the rest of the
   document.  Section 2 contains general requirements that may be
   applicable to all application and support protocols.  Sections 3, 4,
   and 5 contain the requirements on protocols for the three major
   applications: Telnet, file transfer, and electronic mail,
   respectively. Section 6 covers the support applications: the domain
   name system, system initialization, and management.  Finally, all
   references will be found in Section 7.

   1.1  The Internet Architecture

      For a brief introduction to the Internet architecture from a host
      viewpoint, see Section 1.1 of [INTRO:1].  That section also
      contains recommended references for general background on the
      Internet architecture.

   1.2  General Considerations

      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.

      1.2.1  Continuing Internet Evolution

         The enormous growth of the Internet has revealed problems of
         management and scaling in a large datagram-based packet
         communication system.  These problems are being addressed, and
         as a result there will be continuing evolution of the
         specifications described in this document.  These changes will
         be carefully planned and controlled, since there is extensive
         participation in this planning by the vendors and by the
         organizations responsible for operations of the networks.



Internet Engineering Task Force                                 [Page 6]




RFC1123                       INTRODUCTION                  October 1989


         Development, evolution, and revision are characteristic of
         computer network protocols today, and this situation will
         persist for some years.  A vendor who develops computer
         communication software for the Internet protocol suite (or any
         other protocol suite!) and then fails to maintain and update
         that software for changing specifications is going to leave a
         trail of unhappy customers.  The Internet is a large
         communication network, and the users are in constant contact
         through it.  Experience has shown that knowledge of
         deficiencies in vendor software propagates quickly through the
         Internet technical community.

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability:

                "Be liberal in what you accept, and
                 conservative in what you send"

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
         mere human malice would never have taken so devious a course!

         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.

         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out



Internet Engineering Task Force                                 [Page 7]




RFC1123                       INTRODUCTION                  October 1989


         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.

      1.2.3  Error Logging

         The Internet includes a great variety of host and gateway
         systems, each implementing many protocols and protocol layers,
         and some of these contain bugs and mis-features in their
         Internet protocol software.  As a result of complexity,
         diversity, and distribution of function, the diagnosis of user
         problems is often very difficult.

         Problem diagnosis will be aided if host implementations include
         a carefully designed facility for logging erroneous or
         "strange" protocol events.  It is important to include as much
         diagnostic information as possible when an error is logged.  In
         particular, it is often useful to record the header(s) of a
         packet that caused an error.  However, care must be taken to
         ensure that error logging does not consume prohibitive amounts
         of resources or otherwise interfere with the operation of the
         host.

         There is a tendency for abnormal but harmless protocol events
         to overflow error logging files; this can be avoided by using a
         "circular" log, or by enabling logging only while diagnosing a
         known failure.  It may be useful to filter and count duplicate
         successive messages.  One strategy that seems to work well is:
         (1) always count abnormalities and make such counts accessible
         through the management protocol (see Section 6.3); and (2)
         allow the logging of a great variety of events to be
         selectively enabled.  For example, it might useful to be able
         to "log everything" or to "log everything for host X".

         Note that different managements may have differing policies
         about the amount of error logging that they want normally
         enabled in a host.  Some will say, "if it doesn't hurt me, I
         don't want to know about it", while others will want to take a
         more watchful and aggressive attitude about detecting and
         removing protocol abnormalities.

      1.2.4  Configuration

         It would be ideal if a host implementation of the Internet
         protocol suite could be entirely self-configuring.  This would
         allow the whole suite to be implemented in ROM or cast into
         silicon, it would simplify diskless workstations, and it would



Internet Engineering Task Force                                 [Page 8]




RFC1123                       INTRODUCTION                  October 1989


         be an immense boon to harried LAN administrators as well as
         system vendors.  We have not reached this ideal; in fact, we
         are not even close.

         At many points in this document, you will find a requirement
         that a parameter be a configurable option.  There are several
         different reasons behind such requirements.  In a few cases,
         there is current uncertainty or disagreement about the best
         value, and it may be necessary to update the recommended value
         in the future.  In other cases, the value really depends on
         external factors -- e.g., the size of the host and the
         distribution of its communication load, or the speeds and
         topology of nearby networks -- and self-tuning algorithms are
         unavailable and may be insufficient.  In some cases,
         configurability is needed because of administrative
         requirements.

         Finally, some configuration options are required to communicate
         with obsolete or incorrect implementations of the protocols,
         distributed without sources, that unfortunately persist in many
         parts of the Internet.  To make correct systems coexist with
         these faulty systems, administrators often have to "mis-
         configure" the correct systems.  This problem will correct
         itself gradually as the faulty systems are retired, but it
         cannot be ignored by vendors.

         When we say that a parameter must be configurable, we do not
         intend to require that its value be explicitly read from a
         configuration file at every boot time.  We recommend that
         implementors set up a default for each parameter, so a
         configuration file is only necessary to override those defaults
         that are inappropriate in a particular installation.  Thus, the
         configurability requirement is an assurance that it will be
         POSSIBLE to override the default when necessary, even in a
         binary-only or ROM-based product.

         This document requires a particular value for such defaults in
         some cases.  The choice of default is a sensitive issue when
         the configuration item controls the accommodation to existing
         faulty systems.  If the Internet is to converge successfully to
         complete interoperability, the default values built into
         implementations must implement the official protocol, not
         "mis-configurations" to accommodate faulty implementations.
         Although marketing considerations have led some vendors to
         choose mis-configuration defaults, we urge vendors to choose
         defaults that will conform to the standard.

         Finally, we note that a vendor needs to provide adequate



Internet Engineering Task Force                                 [Page 9]




RFC1123                       INTRODUCTION                  October 1989


         documentation on all configuration parameters, their limits and
         effects.


   1.3  Reading this Document

      1.3.1  Organization

         In general, each major section is organized into the following
         subsections:

         (1)  Introduction

         (2)  Protocol Walk-Through -- considers the protocol
              specification documents section-by-section, correcting
              errors, stating requirements that may be ambiguous or
              ill-defined, and providing further clarification or
              explanation.

         (3)  Specific Issues -- discusses protocol design and
              implementation issues that were not included in the walk-
              through.

         (4)  Interfaces -- discusses the service interface to the next
              higher layer.

         (5)  Summary -- contains a summary of the requirements of the
              section.

         Under many of the individual topics in this document, there is
         parenthetical material labeled "DISCUSSION" or
         "IMPLEMENTATION".  This material is intended to give
         clarification and explanation of the preceding requirements
         text.  It also includes some suggestions on possible future
         directions or developments.  The implementation material
         contains suggested approaches that an implementor may want to
         consider.

         The summary sections are intended to be guides and indexes to
         the text, but are necessarily cryptic and incomplete.  The
         summaries should never be used or referenced separately from
         the complete RFC.

      1.3.2  Requirements

         In this document, the words that are used to define the
         significance of each particular requirement are capitalized.
         These words are: