To allow interoperation with a different naming convention, the names
   assigned by a foreign naming convention need to be accommodated.
   Given the autonomous nature of domains, a foreign naming environment
   may be incorporated as a domain anywhere in the hierarchy.  Within
   the naming universe, the name service for a domain is provided within
   that domain.  Thus, a foreign naming convention can be independent of
   the Internet naming convention.  What is implied here is that no
   standard convention for naming needs to be imposed to allow
   interoperations among heterogeneous naming environments.

      For example:

         There might be a naming convention, say, in the FOO world,
         something like "%%".  Communications with an
         entity in that environment can be achieved from the Internet
         community by simply appending ".FOO" on the end of the name in
         that foreign convention.

            John%ISI-Tops20-7%California.FOO

      Another example:

         One way of accommodating the "uucp world" described in the last
         section is to declare it as a foreign system.  Thus, a uucp
         name

            "alpha!beta!gamma!john"



 


RFC 819                                                     August 1982;


         might be known in the Internet community as

            "alpha!beta!gamma!john.UUCP".

      Communicating with a complex subdomain is another case which can
      be treated as interoperation.  A complex subdomain is a domain
      with complex internal naming structure presumably unknown to the
      outside world (or the outside world does not care to be concerned
      with its complexity).

   For the mail system application, the names embedded in the message
   text are often used by the destination for such purpose as to reply
   to the original message.  Thus, the embedded names may need to be
   converted for the benefit of the name server in the destination
   environment.

   Conversion of names on the boundary between heterogeneous naming
   environments is a complex subject.  The following example illustrates
   some of the involved issues.

      For example:

         A message is sent from the Internet community to the FOO
         environment.  It may bear the "From" and "To" fields as:

            From: Fred@F.ISI.ARPA
            To:   John%ISI-Tops20-7%California.FOO

         where "FOO" is a domain independent of the Internet naming
         environment.  The interface on the boundary of the two
         environments may be represented by a software module.  We may
         assume this interface to be an entity of the Internet community
         as well as an entity of the FOO community.  For the benefit of
         the FOO environment, the "From" and "To" fields need to be
         modified upon the message's arrival at the boundary. One may
         view naming as a separate layer of protocol, and treat
         conversion as a protocol translation.  The matter is
         complicated when the message is sent to more than one
         destination within different naming environments; or the
         message is destined within an environment not sharing boundary
         with the originating naming environment.

   While the general subject concerning conversion is beyond the scope
   of this note, a few questions are raised in Appendix D.








 


RFC 819                                                     August 1982;


5.  Name Service

   Name service is a network service providing name-to-address
   translation.  Such service may be achieved in a number of ways.  For
   a simple networking environment, it can be accomplished with a single