application protocol must be allowed for, ranging from the simplest
   such as remote login up to the most complex such as distributed
   databases.

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

   3.3 All designs must scale readily to very many nodes per site and to
   many millions of sites.

   3.4 Performance and cost must be considered as well as functionality.

   3.5 Keep it simple. When in doubt during design, choose the simplest
   solution.

   3.6 Modularity is good. If you can keep things separate, do so.






 
RFC 1958        Architectural Principles of the Internet       June 1996


   3.7 In many cases it is better to adopt an almost complete solution
   now, rather than to wait until a perfect solution can be found.

   3.8 Avoid options and parameters whenever possible.  Any options and
   parameters should be configured or negotiated dynamically rather than
   manually.

   3.9 Be strict when sending and tolerant when receiving.
   Implementations must follow specifications precisely when sending to
   the network, and tolerate faulty input from the network. When in
   doubt, discard faulty input silently, without returning an error
   message unless this is required by the specification.

   3.10 Be parsimonious with unsolicited packets, especially multicasts
   and broadcasts.

   3.11 Circular dependencies must be avoided.

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing.

   3.12 Objects should be self decribing (include type and size), within
   reasonable limits. Only type codes and other magic numbers assigned
   by the Internet Assigned Numbers Authority (IANA) may be used.

   3.13 All specifications should use the same terminology and notation,
   and the same bit- and byte-order convention.

   3.14 And perhaps most important: Nothing gets standardised until
   there are multiple instances of running code.

4. Name and address issues

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

   4.2 A single naming structure should be used.

   4.3 Public (i.e. widely visible) names should be in case-independent
   ASCII.  Specifically, this refers to DNS names, and to protocol
   elements that are transmitted in text format.

   4.4 Addresses must be unambiguous (unique within any scope where they
   may appear).





 
RFC 1958        Architectural Principles of the Internet       June 1996


   4.5 Upper layer protocols must be able to identify end-points
   unambiguously. In practice today, this means that addresses must be
   the same at start and finish of transmission.

5. External Issues

   5.1 Prefer unpatented technology, but if the best technology is
   patented and is available to all at reasonable terms, then
   incorporation of patented technology is acceptable.

   5.2 The existence of export controls on some aspects of Internet
   technology is only of secondary importance in choosing which
   technology to adopt into the standards. All of the technology
   required to implement Internet standards can be fabricated in each