⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc819.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 3 页
字号:
RFC 819                                                     August 1982;


      to a new domain X by D.  To allow name server at D to resolve
      simple names, the name for X must be distinct from L, E, D, C, F,
      and J.  However, allowing A to resolve simple names, X needs to be
      also distinct from A, B, K, as well as from Q, P, N, and R.

   The following observations can be made.

      Simple names along parallel trails (distinct trails leading from
      one domain to the naming universe) must be distinct, e.g., N must
      be distinct from E for B or A to properly resolve simple names.

      No universal uniqueness of simple names is called for, e.g., the
      simple name S does not have to be distinct from that of E, F, G,
      H, D, C, K, Q, B, or A.

      The lower the level at which a domain occurs, the more immune it
      is to the requirement of naming uniqueness.

   To satisfy the required distinction of simple names for proper
   resolution at all levels, a naming authority needs to ensure the
   simple name to be assigned distinct from those in the name server
   databases at the endpoint naming domains within its domain.  As an
   example, for D to assign a simple name for X, it would need to
   consult databases at A and K.  It is, however, acceptable to have
   simple names under domain A identical with those under K.  Failure of
   such distinct assignment of simple names by naming authority of one
   domain would jeopardize the capability of simple name resolution for
   entities within the subtree under that domain.























Su & Postel                                                    [Page 13]



RFC 819                                                     August 1982;


APPENDIX C

   Further Discussion of Name Service and Name Servers

   The name service on a system should appear to the programmer of an
   application program simply as a system call or library subroutine.
   Within that call or subroutine there may be several types of methods
   for resolving the name string into an address.

      First, a local table may be consulted.  This table may be a
      complete table and may be updated frequently, or it may simply be
      a cache of the few latest name to address mappings recently
      determined.

      Second, a call may be made to a name server to resolve the string
      into a destination address.

      Third, a call may be made to a name server to resolve the string
      into a relay address.

   Whenever a name server is called it may be a recursive server or an
   interactive server.

      If the server is recursive, the caller won't be able to tell if
      the server itself had the information to resolve the query or
      called another server recursively (except perhaps for the time it
      takes).

      If the server is iterative, the caller must be prepared for either
      the answer to its query, or a response indicating that it should
      call on a different server.

   It should be noted that the main name service discussed in this memo
   is simply a name string to address service.  For some applications
   there may be other services needed.

      For example, even within the Internet there are several procedures
      or protocols for actually transferring mail.  One need is to
      determine which mail procedures a destination host can use.
      Another need is to determine the name of a relay host if the
      source and destination hosts do not have a common mail procedure.
      These more specialized services must be specific to each
      application since the answers may be application dependent, but
      the basic name to address translation is application independent.







Su & Postel                                                    [Page 14]



RFC 819                                                     August 1982;


APPENDIX D

   Further Discussion of Interoperability and Protocol Translations

   The translation of protocols from one system to another is often
   quite difficult.  Following are some questions that stem from
   considering the translations of addresses between mail systems:

      What is the impact of different addressing environments (i.e.,
      environments of different address formats)?

      It is noted that the boundary of naming environment may or may not
      coincide with the boundary of different mail systems. Should the
      conversion of naming be independent of the application system?

      The boundary between different addressing environments may or may
      not coincide with that of different naming environments or
      application systems.  Some generic approach appears to be
      necessary.

      If the conversion of naming is to be independent of the
      application system, some form of interaction appears necessary
      between the interface module of naming conversion with some
      application level functions, such as the parsing and modification
      of message text.

      To accommodate encryption, conversion may not be desirable at all.
      What then can be an alternative to conversion?























Su & Postel                                                    [Page 15]



RFC 819                                                     August 1982;


GLOSSARY

   address

      An address is a numerical identifier for the topological location
      of the named entity.

   name

      A name is an alphanumeric identifier associated with the named
      entity.  For unique identification, a name needs to be unique in
      the context in which the name is used.  A name can be mapped to an
      address.

   complete (fully qualified) name

      A complete name is a concatenation of simple names representing
      the hierarchical relation of the named with respect to the naming
      universe, that is it is the concatenation of the simple names of
      the domain structure tree nodes starting with its own name and
      ending with the top level node name.  It is a unique name in the
      naming universe.

   partially qualified name

      A partially qualified name is an abbreviation of the complete name
      omitting simple names of the common ancestors of the communicating
      parties.

   simple name

      A simple name is an alphanumeric identifier unique only within its
      parent domain.

   domain

      A domain defines a region of jurisdiction for name assignment and
      of responsibility for name-to-address translation.

   naming universe

      Naming universe is the ancestor of all network entities.

   naming environment

      A networking environment employing a specific naming convention.





Su & Postel                                                    [Page 16]



RFC 819                                                     August 1982;


   name service

      Name service is a network service for name-to-address mapping.

   name server

      A name server is a network mechanism (e.g., a process) realizing
      the function of name service.

   naming authority

      Naming authority is an administrative entity having the authority
      for assigning simple names and responsibility for resolving naming
      conflict.

   parallel relations

      A network entity may have one or more hierarchical relations with
      respect to the naming universe.  Such multiple relations are
      parallel relations to each other.

   multiple parentage

      A network entity has multiple parentage when it is assigned a
      simple name by more than one naming domain.


























Su & Postel                                                    [Page 17]



RFC 819                                                     August 1982;


REFERENCES

   [1]  F. Harary, "Graph Theory", Addison-Wesley, Reading,
   Massachusetts, 1969.

   [2]  J. Postel, "Computer Mail Meeting Notes", RFC-805,
   USC/Information Sciences Institute, 8 February 1982.

   [3]  J. Postel, "Simple Mail Transfer Protocol", RFC-821,
   USC/Information Sciences Institute, August 1982.

   [4]  D. Crocker, "Standard for the Format of ARPA Internet Text
   Messages", RFC-822, Department of Electrical Engineering, University
   of Delaware, August 1982.





































Su & Postel                                                    [Page 18]


⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -