RFC 1498 (rfc1498) - Page 3 of 10

On the Naming and Binding of Network Destinations

RFC 1498   On the Naming and Binding of Network Destinations August 1993


    1. Service and Users. These are the functions that one uses, and
       the clients that use them. Examples of services are one that
       tells the time of day, one that performs accounting, or one
       that forwards packets. An example of a client is a particular
       desktop computer.

    2. Nodes. These are computers that can run services or user
       programs. Some nodes are clients of the network, while others
       help implement the network by running forwarding services.
       (We will not need to distinguish between these two kinds of
       nodes.)

    3. Network attachment points. These are the ports of a network, the
       places where a node is attached. In many discussions about data
       communication networks, the term "address" is an identifier of a
       network attachment point.

    4. Paths. These run between network attachment points, traversing
       forwarding nodes and communication links.

   We might note that our first step, the listing and characterization
   of the objects of discussion, is borrowed from the world of abstract
   data types. Our second step is to make two observations about the
   naming of network objects, the first about form and the second about
   bindings.

   First, one is free to choose any form of name that seems helpful --
   binary identifiers, printable character strings, or whatever, and
   they may be chosen from either a flat or hierarchical name space.
   There may be more than one form of name for a single type of object.
   A node might, for example, have both a hierarchical character string
   name and a unique binary identifier.  There are two semantic traps
   that one can fall into related to name form.  First, the word "name"
   is, in the network world, usually associated with a printable
   character string, while the word "address" is usually associated with
   machine-interpretable binary strings. In the world of systems and
   languages, the term "print name" is commonly used for the first and
   "machine name" or "address" for the second, while "name" broadly
   encompasses both forms. (In this paper we are using the broad meaning
   of "name".)  The second semantic trap is to associate some
   conventional form of name for a particular type of object as a
   property of that type. For example, services might be named by
   character strings, nodes by unique ID's, and network attachment
   points named by hierarchical addresses.  When one participant in a
   discussion assumes a particular name form is invariably associated
   with a particular type of object and another doesn't, the resulting
   conversation can be very puzzling to all participants.




Saltzer