rfc1958.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页


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).




IAB                          Informational                      [Page 5]

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
   country, so world wide deployment of Internet technology does not
   depend on its exportability from any particular country or countries.

   5.3 Any implementation which does not include all of the required
   components cannot claim conformance with the standard.

   5.4 Designs should be fully international, with support for
   localisation (adaptation to local character sets). In particular,
   there should be a uniform approach to character set tagging for
   information content.

6. Related to Confidentiality and Authentication

   6.1 All designs must fit into the IP security architecture.

   6.2 It is highly desirable that Internet carriers protect the privacy
   and authenticity of all traffic, but this is not a requirement of the
   architecture.  Confidentiality and authentication are the
   responsibility of end users and must be implemented in the protocols
   used by the end users. Endpoints should not depend on the
   confidentiality or integrity of the carriers. Carriers may choose to
   provide some level of protection, but this is secondary to the
   primary responsibility of the end users to protect themselves.

   6.3 Wherever a cryptographic algorithm is called for in a protocol,
   the protocol should be designed to permit alternative algorithms to
   be used and the specific algorithm employed in a particular
   implementation should be explicitly labeled. Official labels for
   algorithms are to be recorded by the IANA.

   (It can be argued that this principle could be generalised beyond the
   security area.)





IAB                          Informational                      [Page 6]

RFC 1958        Architectural Principles of the Internet       June 1996


   6.4 In choosing algorithms, the algorithm should be one which is
   widely regarded as strong enough to serve the purpose. Among
   alternatives all of which are strong enough, preference should be
   given to algorithms which have stood the test of time and which are
   not unnecessarily inefficient.

   6.5 To ensure interoperation between endpoints making use of security
   services, one algorithm (or suite of algorithms) should be mandated
   to ensure the ability to negotiate a secure context between
   implementations. Without this, implementations might otherwise not
   have an algorithm in common and not be able to communicate securely.

Acknowledgements

   This document is a collective work of the Internet community,
   published by the Internet Architecture Board. Special thanks to Fred
   Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal
   McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan.

References

   Note that the references have been deliberately limited to two
   fundamental papers on the Internet architecture.

   [Clark] The Design Philosophy of the DARPA Internet Protocols,
   D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988,
   pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995,
   pages 102-111).

   [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
   D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp
   277-288.



















IAB                          Informational                      [Page 7]

RFC 1958        Architectural Principles of the Internet       June 1996


Security Considerations

   Security issues are discussed throughout this memo.

Editor's Address

   Brian E. Carpenter
   Group Leader, Communications Systems
   Computing and Networks Division
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland

   Phone:  [phone]
   Fax:    [phone]
   EMail: [e-mail]



































IAB                          Informational                      [Page 8]