Reasoning about naming systems - University of Texas at AustinSAUMYA K. DEBRAY and LARRY L. PETERSON The University of Arizona This paper reasons about naming systems as specialized

Reasoning About Naming Systems

MIC BOWMAN

The Pennsylvania State University

and

SAUMYA K. DEBRAY and LARRY L. PETERSON

The University of Arizona

This paper reasons about naming systems as specialized inference mechanisms, It describes a

preference )-zierarch.v that can be used to specify the structure of a naming system’s inference

mechanism and defines criteria by which different naming systems can be evaluated, For

example, the preference hierarchy allows one to compare naming systems based on how

dkcrzmznating they are and to identify the class of names for which a given naming system issound and complete. A study of several example naming systems demonstrates how the prefer-

ence hierarchy can be used as a formal tool for designing naming systems.

Categories and Subject Descriptors: H.2.3 [Database Management]: Languages—query lan-

guages; H.2.4 [Database Management]: Systems—query processing; H.3.3 [Information

Storage and Retrieval]: Information Search and Retrieval-selection processes; H.3.4 [Infor-

mation Storage and Retrieval]: Systems and Software—question-a nswering ( fact retrieval)

systems

General Terms: Design, Theory

Additional Key Words and Phrases: Descriptive naming systems, inference mechanisms

1. INTRODUCTION

A name is a syntactic entity that denotes an object, and a naming system is amechanism that answers queries of the form “what object is denoted by this

name?” A naming system resembles a restricted database system that infers

the object(s) referenced by a name. The class of queries that can be handled

by such a system and the precision of the answers it returns depend directly

on the power of its inference mechanism.

Conventional naming systems, such as those found in compilers [Price

1971], virtual memory managers [Fabry 1974], and file systems [Ritchie and

Thompson 1974], are functionally simple: The database contains a table of

name\ value pairs, clients submit a single name, and the system returns the

This work was supported in part by National Science Foundation Grant DCR-8609396 and

National Aeronautics and Space Administration Grant NCC-2-561.

Authors’ address: S. K. Debray and L. L. Peterson, Department of Computer Science, University

of Arizonaj Tucson, AZ 85721.

Permission to copy without fee all or part of this material is granted provided that the copies are

not made or distributed for direct commercial advantage, the ACM copyright notice and the title

of the publication and its date appear, and notice is given that copying is by permission of the

Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or

specific permission.

01993 ACM 0164-0925/93/1100-0795 $03.50

ACM Transact,.m on Progmmm,ng Languages and Systems, VOI 15. No. 5, November 1993, Pages 795–S25

796 . M, Bowman et al

corresponding value. More elaborate naming systems, such as white-pages

services used to identify users [International Organization for Standardiza-

tion 1988; Peterson 1988; Pickens et al. 1979; Solomon et al. 1982], yellow-

pages services used to identify network resources [Peterson 1987; Sun

Microsystems Inc. 1986], and document-preparation utilities for managing

bibliographic data [Budd 1986], allow clients to identify an object by giving a

collection of attributes that describe the object; we refer to such systems as

descriptive or attribute-based naming systems. For example, a client may

learn a user’s mailbox address by querying a white-pages service with a name

of the form

name = John Doe, phone = 621-1234, org = State University.

Similarly, a client may learn the address of a cycle server by querying a

yellow-page service with a name of the form

service = cycle, arch = mips, load

Reasoning About Naming Systems . 797

table cannot accommodate ambiguous answers. In contrast, the clients of a

white-pages service, in this case human users, often possess several pieces of

information about the object they want to name and are sometimes willing to

tolerate ambiguous results as long as it contains the desired object.

Second, the naming system is constrained by the conditions under which it

is implemented, that is, the properties of the environment in which it must

function. In many cases, there are no limitations; the naming system exists in

a perfect world. For example, the parser for a compiler never fails to insert

identifiers in the symbol table, and the symbol-table manager cannot fail

independently of the entire compilation. In contrast, many naming systems

must function in an imperfect world. For example, a white-pages service can

only resolve names that contain information put into the system by users. If a

user does not enter a particular fact in the naming system, then the system

cannot respond to queries using that information. As another example,

naming systems that are implemented in distributed environments may lose

information because independent components fail, or information may become

out-of-date because of communication delays between the components that

make up the system.

The preference hierarchy defined in this paper can be used to guide the

design of naming systems that must satisfy various requirements and con-

straints. Although the preference hierarchy is most useful when applied to

more complex descriptive naming systems, we have found that the preference

hierarchy provides insights into the design of more conventional naming

systems as well. In fact, Section 5 points out a naming system originally

conceived as a conventional system, but that has evolved over time in a way

that suggests the unconscious use of the preference hierarchy.

1.2 Related Work

Previous studies of naming focus on the operational aspects of naming

systems, describing their architecture and the implementation of the archi-

tecture’s base elements. For example, Fowler [1985], Lampson [1986], Mann

[19871, Oppen and Dalal [1981], and Terry [19871 each describe techniquesfor managing a decentralized naming service. In addition, studies by Comer

and Peterson [1989] and Watson [1981] give general characterizations of the

resolution process. In contrast, this paper is concerned with the functional

aspects of naming. In other words, we consider the question of what objects

are identified by a given name, rather than the question of how the system is

structured.

In addition to work that explicitly addresses the problem of naming, many

of the underlying ideas found in this paper can be traced to two other related

areas: First, naming systems can be thought of as specialized database

systems, where the process of resolving a name is conceptually similar to that

of solving a database query [Gallaire et al. 1984]. In particular, the preference

hierarchy unifies ideas from work being done in open-world and closed-world

databases [Reiter 1978], partial match retrieval [Unman 1988], and incom-

plete information [Lipski 1979; 1981]. Second, one can view naming as a

specific constraint-satisfaction problem [Borning et al. 1987]. More specific

ACM Transactions on Programming Languages and Systems, Vol. 15, No 5, November 1993

798 . M. Bowman et al

comparisons to these related topics are made throughout the rest of this

paper.

2. BASIC CONCEPTS

In the abstract, naming systems answer queries about a universe of resources,

each of which has certain properties. If a resource possesses a particular

property, then the property is said to describe the resource. For example, if

we are considering the universe of printers, then the properties any element

of this set might possess include “fonts,” “location,” and “resolution.” The

specific property “location is Room 723” describes a particular printer.

In practice, a naming system maintains and manipulates a database of

syntactic information about a set of resources: It denotes each resource with a

database object (a record) and each property with an attribute (a tagged field

in the record). For example, a naming system that knows about printers

might store facts of the sort “printer ip2 supports italic font and is located in

room 723,” “ printer 1w6 is of type laserwriter and has 300 dots per square

inch resolution,” and so on. The corresponding objects in the naming-system

database would be

(font Italic, location. 723, uid : ip2)(type: laserwriter, resoluhon: 300, uid : Iw6)

where font: italic is an example of an attribute. Each attribute consists of a

tag and a ualue, denoted t : v. For example, the attribute font: italic consists of

the tag font and the value Italic. For convenience, we assume that each objectcontains a u Id attribute and refer to the object by this attribute’s value, for

example, object ip2. Also, if an attribute a is entered in the naming-systemdatabase for object x, then a is said to be registered for x.

The meaning of objects and attributes is given by a meaning function p:

The resource represented by object x is given by ~(x), and the meaning

w(a) of an attribute a is the property specified by a. For example, in theuniverse of printers, ~(font: itallc) is the property supporting the italic font.The information in a naming system is accurate when an attribute a is

registered for an object x implies that p(a) describes p(x). For example, if the

attribute phone: 621-1234 is registered for the object jones, then we expectthe referent of jones, presumably a person, to have the phone number

621-1234.

Clients query a naming system with a set of attributes, and the naming

system responds with the set of objects that correspond, in some sense, to

those attributes. Formally, a set of attributes N names object x if everyattribute in N is registered for x. That is, names maps sets of attributes into

sets of objects, where names(N) denotes the set of objects named by a set of

attributes N. If x = names(N), then N is said to be a name for x. The

corresponding semantic notion is represents: A set of properties w(N) repre-

sents a resource if every property in the set describes the resource.

The relationship between the semantic and syntactic domains and the

parallel between working with a single attribute and a set of attributes are

schematically depicted in Figure 1. The top layer corresponds to database

ACM Transactmns on Proqamm]ng Languages and Systems, Vol 15, No 5. November 1993


atibute,,,

,.,,,’ 1u,,,,,,

,.,.,, property,., ,,,,, ,,,’

,,, ,,,,,, ,,’

,., ,,,,.set(attributes) ~

registeredm object

,,.,” I,?.

,,, Iudescribes ,:’”,,,,,$’

,,,,,: ,,,

,,, ,,,

set(objects) ;’”w

I,,.

I,..,., ,,f

u ,/’” u ,;’”,,, ,/,

representsset(pmperties) ~ set(resources)

Fig. 1. Relationship between semantic and syntactic entities,

objects (i.e., operations on fields and records), while the bottom layer corre-

sponds to resources (i.e., operations on real-world entities, such as a printer

or a person). The dotted edges link single items with sets of items.

Conventional naming systems that operate in a “perfect” world, for exam-

ple, symbol tables and virtual memory systems, only have to implement a

procedure that supports the names function. That is, they simply return the

set of objects for which all of the given attributes are registered. In general,

however, naming systems do not operate in a perfect world. The information

that a client uses to query a naming system may contain imperfections. For

example, the client may not possess enough information to identify the

desired objects uniquely, or the information that the client does possess may

be inaccurate. Likewise, the information contained in the naming-system

database may not be perfect; it may contain incomplete or out-of-date infor-

mation. Thus, a naming system must use information specified by the client

and registered in the database to approximate the results that would be

obtained by names if it operated in a perfect world. The preference hierarchy

described in the next section suggests a method for deriving various proce-

dures, called resolution functions, that approximate the names mapping in

an imperfect world.

3. PREFERENCE HIERARCHY

Many naming systems distinguish between the “quality” of different kinds of

information. For example, a descriptive naming system must be able to

resolve names that contain a multiplicity of attributes. In doing so, it is

reasonable to give some attributes more importance than others. Suppose a

user is trying to identify John Smith at State University, where the user is

sure that the individual is at State University, but uncertain as to whether

his first name is John. Such a user would prefer that the naming system

respond with information about any Smith at State University, rather

ACM Transactions on Programmmg Languages and Systems, Vol. 15, No. 5, November 1993.

800 . M. Bowman et al.

than information about some John Smith not at State University. As another

example, because naming systems implemented in a distributed environment

such as the Domain Name System [Mockapetris 19871 must accommodate

out-of-date information, they generally prefer attributes that are guaranteed

to be current over cached attributes that may have become stale.

In a perfect world, where the client accurately and completely identifies a

set of objects and where there is no possibility of missing or out-of-date

information in the database, it suffices to always use names to resolve a set

of attributes. Indeed, this is essentially what is done when responding to

queries in conventional database systems. In an imperfect world, however,

the naming system must cope with two potential problems: inaccuracies

in the attributes specified by the client, and imperfect information in the

database. Furthermore, rather than providing a single resolution function

that compensates for these problems, a naming system might support a

number of different resolution functions. Each function might be tailored for

a set of assumptions about the contents of the database and the structure of

names.

Intuitively, each resolution function in a naming system uses certain

assumptions about the quality of information in the system and

resolves names according to the most preferred set of assumptions. Formally,

a preference, denoted by


denoted by an attribute in order to determine its accuracy. For example, an

approximation might consider social security number attributes to be accu-

rate, because a client that specifies a social security number usually knows it

accurately. Given a set of attributes, an approximation function based on a

preference for accurate attributes would remove those attributes that it

believes to be inaccurate, returning the accurate ones, It always returns a

subset of the attributes it is given. 1 Formally, a client approximation function

is defined as follows:

Definition 3.1 (Client approximation function). A client approximation

function over a domain of attributes A is a function f 2A + 2A that is

monotonic increasing; that is, for all set of attributes M and N, M G Nimplies that f(M) c f(N).

A client preference is a finite, totally ordered set of client approximation

functions. Approximations high in the order are those the client considers

most likely to be accurate. For example, a client may specify that an approxi-

mation that assumes that social security numbers are accurate is preferred to

an approximation that assumes that social security numbers are inaccurate.

The selection of the approximation functions and the order on them encapsu-

late information about the attributes supplied by the client, In practice, the

selection of a specific preference depends on the client’s assumptions about

the information within a system and on the kind of objects that the client

intends to identify. For example, a client that intends to identify processors

will specify a different preference than a client that intends to identify

human users.

The following list informally describes several preferences that we have

found useful in the naming systems we have designed. This list illustrates

some possible preferences; it is not intended to be complete. Formal defini-

tions for several of the preferences are given in Section 4, where we consider

specific resolution functions in more detail.

Universal Preference. The universal preference consists of a single func-

tion universal that maps every set of attributes to itself. This function is used

most often when the client believes that all of the attributes it specified are

accurate and are sufficient to distinguish the set of objects that are identified.

In other words, this function assumes that the client operates in a perfect

world.

Registered Preference. The registered preference, denoted


An attribute with tag t is closed if every attribute constructed from t is

guaranteed to be registered for every object it describes. For example, a

naming system may guarantee that every object with a name will have that

name registered in the database. The client approximation function closed,

which returns the closed attributes in a name, limits the scope of resolution

to portions of the database with complete information. An open attribute may

not be registered for an object even though the corresponding property

describes the resource the object denotes. The resolution of a name based on

open attributes may not contain all of the objects in the database that

represent resources described by the attributes. This preference is particu-

larly useful when users are responsible for maintaining some of the informa-

tion in the naming system. For example, one user may decide to include a

home phone number in the database, but another may choose to leave it out.

In this case, home phone number attributes are not closed and may provide

incomplete answers. Note that the registered preference order is similar to

the idea of open\ closed world databases [Reiter 1978]. Instead of making the

closed-world assumption over an entire database, however, we make

the distinction on an attribute-by-attribute basis.

Mutability Preference. The mutability preference, denoted


a name that are ambiguous. Thus

ambiguous


these functions select objects from the existing database in a way that

mirrors the selection of objects from what the function believes to be the

perfect database. This usually takes the form of some strategy for handling

partial matches, although it may use more sophisticated techniques such as

the statistical inference methods described by Wong [1982].

Definition 3.2 (Database approximation function). A database approxima-

tion function over a domain of attributes A and a domain of objects O is a

function m: 2A x 20 + 2° that is a contraction on its second argument; that

is, for any set of objects D, m((N, D) c D.

Intuitively, the definition says that a database approximation function

never adds new objects to the database. Most useful database approximation

functions have two other characteristics: First, most database approxima-

tion functions return more complete answers with more information abut the

world. In other words, as the size of the database increases, the number of

objects matching a name increases. More formally, a database approximation

function m is monotonic increasing relative to the set of objects; that is, for

sets of objects C and D, C c D implies that m(N, C) G m(N, D). The unique

approximation described below is an exception to this rule; unique returns

the single object that uniquely matches the set of attributes. Second, most

database approximation functions cannot approximate the set of objects that

the client intended to identify without some information from the client; thus,

m(O, D) = @ for any set of objects D is true for most database approximation

functions. One specific function that does not conform to this principle is a

database approximation function called identity; identity always returns the

set of objects that it is given no matter what attributes the client specifies.

A database preference is a total order on a set of database approximation

functions. As with client preferences, the selection of a particular preference

supplies the naming system with information about the assumptions that the

client possesses regarding the database. A particular preference may supply

information about how to handle different degrees of partial match or matchesin different locations. The following examples describe potential solutions to

these problems:

Match-Based Preference. The match-based preference, denoted

Reasoning About Nammg Systems . 805

and consider a name that consists of the attributes office: 737 and depart-ment: CS. In this case, possible returns cmb, rao, and gmt. This functioncomputes IIQll”, as defined by Lipski in the case where there is no partial

information [Lipski 1979; 1981]. The second approximation, partial, returns

all objects that possibly match and have at least one attribute in common

with the name. Partial would return cm b and rao, but not gmt in the

example. The third approximation, exact, returns all objects that are described

by all of the attributes in a name. For this example, exact returns just cmb; itis the only object that is known to match both attributes in the name. Exact

computes Lipski’s IIQ II~. The final approximation, unique, returns either the

single object that exactly matches the name or the empty set; in this case,

cm b would be returned by unique, but no objects would be returned for aname that consists of the single attribute office: 737 because there is nounique match. This preference may be used when the accuracy of the database

is not in question, though it may not be complete. That is, no object will be

returned if it conflicts with one of the attributes that the client supplies. Note

that this preference generalizes the idea of partial match retrieval [Unman

1988].

Voting Preference. The voting preference, denoted


out-of-date information within the database. The temporal preference may be

defined as

out-of-date


contains information that may be incomplete. Finally, some of the infor-

mation in the database is authoritative, that is, it is always up-to-date, and

some is cached. For a naming system based on these assumptions, three

preferences seem most applicable:


tions to construct a series of database approximation functions. Finally, the

first rule is applied to construct a single function called a composite approx-

imation function. Thus, the composition of {open, authoritative, exact} is

a function f defined as f(~, D) = authoritatiue(open( N), D) n exact(open

(N), D).

The second effect of the preference hierarchy is the order in which a set of

composite approximation functions are applied to the name. A preference

hierarchy specifies an induced preference on a set of composition functions;

that is, it orders the set of composite approximation functions that can be

constructed from the preferences in the hierarchy. In this example, the

resolution function attempts both exact and partial matches on the closed

attributes before attempting any match on open attributes. The preference

hierarchy induces the following preference on the sets of approximations:

{open, cached, partial} < {open, cached, exact}

{open, authoritative, partial} < {open, authoritative, exact} ~

{closed, cached, partial) < {closed, cached, exact} <

{closed, authoritative, partial) < {closed, authoritative, exact)

In other words, {closed, authoritative, exact} is the most preferred approxima-

tion. If this composite approximation function computes a nonempty set of

objects, than that set is returned by the resolution function. The resolution

function evaluates compositions in order from most preferred to least pre-

ferred. It returns the first nonempty set computed by a composition.

Formally, if we are given a set of preferences II = {


Intuitively, a composition function supports several approximations of the

perfect-world system, one from each preference in the hierarchy. The assump-

tions encapsulated in the set of approximations are considered “accurate” if

the composition returns a nonempty set of objects. A resolution function

computes the set of objects described by the name relative to the most

preferred, “accurate” set of approximations.

To complete the example, consider the implementation of the resolution

function defined by the preference hierarchy


about all of the imperfections that exist in the system and compensates for

them. We assume that every client attempts to identify at least one object;

therefore, oracle always returns at least one object. Using the oracle func-

tion, soundness and completeness can be formalized as follows:

Definition 3.4 (Soundness). A name resolution function p is said to be

sound for a name\ database pair (N, D) in A if and only if P(N, D) Goracle(N, D).

Definition 3.5 (Completeness). A name resolution function p is said to be

complete for a name\ database pair (N, D) in A if and only if oracle(N, D) LP(N, D).

We denote the set of nameidatabase pairs in A for which p is sound by S,

and the set of name/database pairs for which p is complete by rP.

Often, the designer of a naming system must ensure that the resolution

functions the system provides satisfy constraints about soundness or com-

pleteness. For example, our experience suggests that clients generally want a

white-pages naming system that allows clients to search for and to name

users to be complete. In contrast, clients want a yellow-pages naming system

that allows clients to locate system services to be sound. In the first case,

clients are willing to discard extra objects but want the desired object to be

contained in the result, whereas in the second case, the client often depends

on all of the answers being equally valid; for example, if a client asks for a

processor with a 68020 architecture then an answer that contains a processor

that has a different architecture cannot be tolerated.

Suppose we are given a resolution function defined by a preference hier-

archy (II, ~ ). Then, given information about the soundness or completeness

of each approximation function in the preferences of H, it is necessary to

be able to reason about the soundness or completeness of the induced resolu-

tion function. For instance, Profile supports several white-pages resolution

functions that attempt to handle databases that may contain incomplete

information and clients that may specify inaccurate descriptions [Peterson

1988]. It is important that the Profile functions be complete on many name\

database pairs where the database is incomplete and the name contains some

inaccuracies. The following results help a system designer determine the

extent to which such a resolution function meets its goals for soundness and

completeness.

A resolution function that consists of a single composite approximationfunction is sound only if the composition returns a subset of the objects the

client intends to identify. Similarly, the resolution function is complete only if

the objects that client seeks are contained in the set that the composition

returns. This observation leads to the definition of soundness and complete-

ness for a composite approximation function: A composite approximation

function c is sound on a set of 2C if a resolution function constructed from

just c is sound on Z,; c is complete on rC if the resolution function is

complete on r,.

ACM TransactIons on Programmmg Languages and Systems, Vol. 15, No 5, November 1993

Reasoning About Nammg Systems . 811

PROPOSITION 3.1. The composition c o d of two monotonic database approxi-

mation functions c and d, where c is sound on XC and d is sound on ~d, is

sound on ZC U Zd.

PROOF. Recall that database approximation functions always return a

subset of the objects in the database. If d is sound on (N, D), then c o d must

be sound because c cannot add any objects; a database approximation always

returns a subset of the objects in the database. Since c and d are monotonic

increasing relative to the database, (N, D) G XC implies that every subset of

D is also in XC. Therefore, if c is sound on (N, D) then c o d is sound on

(N, D). ❑

PROPOSITION 3.2. The composition c 0 d of two composite approximation

functions c and d, where c is complete on ~,, d is complete on ~d, and c is an

additive function—c has the property that c(N, D1 U D2) = c(N, D1 ) U

c(N, Dz ) for all sets of objects D—is complete on r, n rd.

PROOF. If d is complete on (N, D), then it returns at least the objects that

the client seeks. If c is pointwise determined and complete on (N, D), then it

is complete on every subset of D that contains oracle(N, D). Thus, c o d is

complete on all name\ database pairs in rc f’ rd. ❑

These two propositions allow a system designer to determine when a

composite approximation that consists of several client and database approxi-

mations is sound and complete. For example, it is easy to show that a

composite approximation defined by (closed, unanimous, open, also-ran) is

complete on r(oPen, az~o-run) n r(czobed. unanlm. us). In particular, this composite

approximation is complete when the database is accurate but potentially

incomplete and when the client’s description contains at least one accurate

open attribute and a nonempty set of closed attributes, all of which are

accurate. Since every name resolution function consists of one or more

composite approximation functions ordered by an induced preference, we may

use the sets on which the composite functions are sound and complete to

construct a set of name] database pairs on which the resolution function is

sound or complete.

In general, we are concerned with the entire resolution function. A resolu-

tion function, defined by an induced preference on a set of composite approxi-

mations, determines the set of objects described by a name based on the

failure of inaccurate approximations. Recall that an approximation fails when

it computes an empty set of objects. The set of name\ database pairs on which

any composite approximation c fails is contained in XC, the set of name\

database pairs where c is sound. In fact, Z. may be partitioned into two

disjoint sets PC and EC, where c computes a nonempty set of objects for every

(N, D) in P. and an empty set of objects for every (N, D) in Ec. Given aresolution function p consisting of an induced order on several composite

preferences, EP and rP may be computed using information about the

ACM Transactions on Programmmg Languages and Systems, Vol. 15, No, 5, November 1993.


name\ database pairs in PC and in EC for each composite approximation c

according to the following propositions:

PROPOSITION 3.3. A name resolution function p defined by the induced

preference c. < c.. ~ < . . . + c1 is sound on

~ ))),~ =plU(Eln(pzU(E~ n“””n-~P

where c, is sound on Xl = P, ~ Ec and c. is sound on Zn

PROPOSITION 3.4. A name resolution fi[rzction p defined by the induced

preference c. < . . . cz < c1 is complete on

r.= rl u (El n (r2 u (Ez n . . n r,,))),

where c1 is complete on ~, and empty on E,.

If it is the case that El n Ez n “”” n E, G P,, ~ for all i in the inducedpreference, then ~(, is just the union of all P,. In fact, the union is a good

approximation for X,, whenever P, is very small relative to E,. A simi-

lar approximation may be made for ~,. That is, when r, is very small relative

to E,, then $ is simply the union of all r,. These simplifications provide an

adequate estimate of ZP and r(, for most resolution functions that we have

written.

3.4.2 Discrimination. An important criterion when considering related

naming systems is that of how many (or how few) objects they return for a

given set of attributes. A more discriminating resolution function always

returns a smaller set of objects for a given set of attributes relative to a

particular database. This may be formalized as follows:

Definition 3.6. Given two resolution functions pl and pz and a set of

name) database pairs A, if pl(N, D) c pz(N, D), for all (N, D) E A, then pa is

said to be less discriminating than PI on A (written Pz E ~ PI).

Let Resolve~ denote the set of all resolution functions defined on A,partially ordered by E ~. ResolveJ is a complete lattice whose bottom elementis the function that always returns the set of all objects and whose top

element is the function that always returns the empty set. Different resol-

ution functions can therefore be compared and reasoned about based on

their power of discrimination. For example, consider two resolution func-

tions pl and pz, where pl is defined by a single composite approximation

( universal, possible) and pz, is defined by a single composite approxi-mation ( universal, exact). It w easy to show that

for A containing all name/database pairs.

In general, the choice of a particular resolution function from the family

Resolve3 depends on a consideration of trade-offs between the computationalcost and the precision of resolution offered by alternative functions. Elements

of ResolveL that are low in the lattice defined by c ~ are relatively efficient,

ACM TransactIons on Programmmg Lan~ages and Systems, Vol 15, No 5, November 1993


but typically not very discriminating. In other words, they may return

multiple objects that the user then has to sift through. On the other hand,

elements of Resolve~ that are high in the lattice may be computationallymore expensive, but are typically more discriminating. These functions,

however, run the risk of being overly discriminating in that they may not

return the object the user wants. Our experience is that, in practice, useful

resolution functions are tuned experimentally and are strongly influenced by

the client requirements and the underlying system constraints.

4. APPLICATIONS

The preference hierarchy provides a framework for precisely specifying and

reasoning about naming systems. This section shows how the preference

hierarchy can be applied to several existing naming systems. It also demon-

strates how the preference hierarchy can be used as a prescriptive model for

designing new naming systems. This section concludes with a discussion of

how different naming systems can be compared to each other. The Appendix

contains procedures that implement each resolution function.

4.1 Profile Resolution Functions

The Profile naming system [Peterson 1988] provides a white-pages service

that is used to identify users and organizations. Profile supports a suite of

resolution functions that were designed with three assumptions in mind.

First, Profile assumes that the database is accurate, but potentially incom-

plete. Profile automatically generates some of the information in the database.

These attributes are considered closed because they are entered by a reliable

system administrator. The remainder of the information is added to the

database by the system’s clients. These attributes are considered open because

one client might enter different information than another. Second, the

attributes contained in a name may be inaccurate, because people may forget

or incorrectly remember information about other people. Third, as mentioned

earlier, clients of the Profile system are generally interested in complete

answers, that is, ones that definitely contain the objects the client intended to

identify. This section shows how the first two assumptions affect the com-

pleteness of the resolution functions in Profile.

The preferences used to construct the Profile resolution functions consist of

three client approximation functions and four database approximation func-

tions. Although based on the example approximation functions informallypresented in Section 3, we define these functions formally so that we may

reason about the resolution functions that use them.

Definition 4.1 (Profile client approximation functions). The client approxi-

mation functions used by the Profile naming system are

—universal(N) = N;

—closed(N) = {t : v ~ N Ifor all u, p(t : u) describes p(x) implies that t : u is

registered for x}; and

—open(N) = N – closed(N).

ACM Transactions on Programming Languages and Systems, Vol 15, No. 5, November 1993.


Definition 4.2 (Profile database approximation functions). The database

approximation functions used by the Profile naming system are

—identity(N, D) = D;

—also-ran(N, D) == {x G D I there exists an a e N such that a is registered

for x};

—unanimous(N, D) = {x = D I for every a G N, a is registered for x}; and

—unique(N, D) = if I unanimous(N, D)l = 1, then unaninzous(N, D);

otherwise 0.

We now formally define each of the four resolution functions that constitute

the Profile naming system. For each function, we give an intuitive overview of

the function, the preferences used by the function, and the importance order

on the preferences.

Profilel. Returns all objects that match any of the given attributes. Pro-

filel is defined by

Reasoning About Naming Systems o 815

in the client specification, that is, one that does not describe any of the objects

that the client intends to identify, does not match any object within the

database. Although, in practice, the assumption cannot be guaranteed, it is

unlikely that a client will specify an inaccurate attribute that actually

describes another object.2 That is, the information in the naming system is

sparse in the same sense that error-detection codes, such as parity and

Hamming codes, use the distance between reasonable values to detect the

presence errors in binary information.

The following claims about completeness are valid under this assumption:

PROPOSITION 4.2. The function profilel is complete for all sets of attributes

that contain at least one attribute that is registered for each object that the

client intended to identify.

PROPOSITION 4.3. Profilez is complete on names that contain a nonempty

set, C, of closed attributes that are accurate; that is, each attribute in C

describes every object that the client intends to identify.

PROOF. Consider rCU = {(N, D) Ix c oracle(N, D) implies that p(closed(N))

represents w(x)}. If x = oracle(N, D), then ~(closed(N)) represents w(x). By

the definition of closed, each of these attributes is registered in D. Since

(closed, unanimous ) returns the objects that match all of the closed attri-

butes, it returns to x. Therefore, x E oracle(N, D) implies that x =

unanimous(closed(N), D) and that (closed, zmanimous ) is complete on rcU.

Let 17C.= {(N, D) Ithere exists a nonempty set C c closed(N) such thatx = oracle(N, D) implies that p(C) represents ~(x)}. If x ● oracle(N, D), then

there is a nonempty set of closed attributes, C, that represent x. By defini-

tion, each attribute in C is registered for x in D. Also-ran(closed( N), D) is the

set of objects in D for which at least one of the closed attributes is registered.

Therefore, x is contained in also-ran(closed(N), D) if x is in oracle(N, D) and

if (closed, also-ran) is complete on rCu.

ECU consists of the name/database pairs that have either no closed

attributes or at least one erroneous closed attribute and 17CUs rC.. At this

point, it is trivial to show that Proposition 3.4 implies that rCU u (ECU n

r,. ) = r.. c rP,.f,le,. Thus, Proposition 4.2 holds. ❑

We previously defined a closed attribute as one that is guaranteed to be

registered for every object it describes. A resolution function that uses open

attributes may be incomplete if some open attribute in the name is not

registered for some objects that the client intends to identify. For example,

(open, unanimous) returns a set of objects that match every attribute in the

name. However, one of the attributes in the name may not be registered for

an object that the client seeks, and so that object does not match every

attribute in the name according to the database. This leads to the following

definition: An attribute a is relevant to a set of objects D if, for every object x

2 It w possible to argue the completeness of resolution functions formally without this assump-

tion; however, it is far more cumbersome to describe the set of name/database pairs where an

approximation fails.

ACM Transactions on Programming Languages and Systems, Vol. 15, No. 5, November 1993.


in D, ~(a) describes ~(x) implies that a is registered for x. (Thus, an

attribute is closed if it is relevant to the entire database.) Using this defini-

tion, it is possible to show the following:

PROPOSITION 4.4. Profilez is complete on names where all open attributes

in the name are accurate and relevant to the set of objects that the client

intends to identify.

PROOF. Let roU = {(N, D) I x ~ oracle(N, D) implies that w(open(N)) repre-

sents W(X) and each attribute in open(N) is registered for x}. If x =

oracZe(N, D), then P( open(N)) represents w(x), and each attribute in open(N)

is registered for x in D. Recall that (open, unanimous) returns the objects

that match all of the open attributes. Therefore, x = unanimous(open(N), D)

if x ● oracle(N, D), so that according to the definition of completeness

(closed, unanimous) is complete on rOU.

When profilez resolves names using (open, unanimous), both of the earlier

composite approximations returned empty sets. This occurs whenever all of

the closed attributes are inaccurate; that is, ECU n EC. is the set of all (N, D)

where closed(N) contains no closed attributes that describe the objects the

client intended to identify. rCU U (ECU n rC.) includes any name that contains

a nonempty set of closed attributes that describe the client’s objects. rOU may

be partitioned into two disjoint sets: one where the names contain accurate

closed attributes and one where they do not contain any accurate closed

attributes. It is trivial to show that the former is contained in 17CUu ( E,,U n rca)and the latter in (ECU n E,. n rOU). Thus, 170Ug rCU u (ECU n 17Ca)u(ECU n EC. n rOU). Proposition 3.4 implies that rOU G r,,. ~,l,,,. Therefore, pro-filez is complete on rou, and Proposition 4.4 holds. ❑’ ‘

PROPOSITION 4.5. Profilet is complete on names that contain at least one

inaccurate, open attribute and a nonempty set of accurate, open attributes,

such that at least one attribute in this set is registered for every object that the

client intended to identify.

PROOF. Let rO~ = {(N, D) Ix ~ oracle(N, D) implies that there exists anonempty set O c open(N) such that K(O) represents p(x) and each attribute

in O is registered for x}. If x E oracle(N, D), then there is a nonempty set of

open attributes, O, that represent x, and each attribute in O is registered for

x in D. Also-ran(open(N), D) is the set of objects in D for which at least one

open attribute is registered. Therefore, x is contained in also-ran(open(N), D)if x is in oracle(N, D) and if { open, unanimous) is complete on Foa.

If every name N contains at least one inaccurate attribute, then rOU is

empty. In this case, 17CUu (ECU n rca) u (ECU n EC. n rOU) u (ECU n EC. nEOU n 170G)is equivalent to 17Cuu (ECU n rca) u (ECU n EC. n I’Oa). As before,this expression contains rO.. Therefore, pro filez is complete on rO~, and

Proposition 4.5 holds. u

Since profiles uses the open attributes to “trim” the set of objects returned,

it may not always be complete. However, we can give sufficient conditions for

ACM TransactIons on Programmmg Languages and Systems, Vol. 15, No. 5. November 1993


its completeness. First, note that, if there are no open attributes present in a

set of attributes submitted by the client, then no filtering is possible, and

profiles is identical to profilez. Thus, we have the following proposition:

PROPOSITION 4.6. Profiles is complete on names that do not contain any

open attributes, but do contain a nonempty set of closed attributes that

describe the objects the client intends to identify.

We can, however, do better than this. Proposition 4.6 is based on the fact

that, if there are no open attributes in the set, then they cannot contribute

to the discarding of an intended object. Thus, the reason for any possible

incompleteness is that some open attribute in the given set of attributes was

not registered for the intended object. Thus, if an open attribute is relevant to

the objects that the client intends to identify then it does not contribute to the

discarding of an intended object.

PROPOSITION 4.7. Profilea is complete on names that contain a nonempty

set of accurate attributes that are relevant to the set of objects that the client

intends to identify.

Note that Proposition 4.6 is a special case of Proposition 4.7, because a closed

attribute is, by definition, relevant to all objects.

The resolution functions provided by the Profile naming system attempt to

respond with complete answers. The analysis presented in this section points

out one design decision that adversely affects this goal. The composite

function, ( open, unanimous), selects objects that match all open attributes in

a name. This function is complete only if every open attribute in the name is

relevant to all of the objects that the client identifies. Because the very

definition of an open attribute is one that is not relevant to a large portion of

the database, it is unlikely that more than one or two open attributes will

be relevant to the set of objects that a client attempts to identify. Based on

this understanding, it is possible to design a new function similar to profilez

that does not use a precise match on open attributes and, thus, avoids

this problem. The function, called profile.,W, is defined on the following

preferences:

818 . M Bowman et al

PROPOSITION 4.9. Function profile~,,,, is complete if for every object that the

client intends to identify there is an accurate, open attribute in the name that

is relevant to it.

This example shows that the preference hierarchy can help a system designer

understand how well a resolution function meets its goals. Profilez sacrifices

completeness for a substantial set of name\ database pairs because it uses

an exact match on open attributes, whereas profile .,,,, overcomes this weak-

ness at the expense of being less discriminating for certain unlikely sets of

attributes.

4.2 Lookup Resolution Function

Consider a naming system where the database contains accurate but poten-

tially incomplete information and where the set of attributes specified by the

client is accurate but may match more objects than the client intended. For

these assumptions it seems unreasonable to use database approximation

functions that return any object that conflicts with the client’s description.

For example, if the client specifies two accurate attributes, (name: pollux,

domain: as.arizona.edu), also-ran may match an object with the attributes

(name: toto, domain: as.arizona.edu), even though name: toto conflicts

with part of the client’s specification. In this case, since by definition a

processor may have only one name, the object that is returned cannot be the

one that the client intends to identify.

We define a new resolution function, lookup, specifically for this situation.

Lookup uses partial and possible in conjunction with closed attributes to

guarantee that no object that is returned conflicts with attributes specified by

the client. Formally, partial and possible are defined as follows:

Definition 4.3 (Possible database approximation function). possible(N,

D) = {x E D Ifor every t : v E N either t : v is registered for x or no attribute

with tag t is registered for x}.

Definition 4.4 (Partial database approximation function). partial(N, D) =

{x e possible(N, D) Ithere is an a E N such that a is registered for x}.

The lookup resolution function is defined by the following preferences:


objects that are known to match the client’s description over those that are

not known to conflict with the description.

4.3 Other Nontrivial Resolution Functions

This section discusses several other nontrivial resolution functions.

4.3.1 Yellow-Pages. A yellow-pages resolution function allows clients to

discriminate among similar computational resources, such a printers, proces-

sors, databases, and network services, according to their particular character-

istics. The descriptive yellow-pages function [Peterson 1987], denoted yp,

is defined as follows: The set of attributes presented to yp are partitioned

into mandatory and optional subsets, denoted by N~ and NO, respectively,

where the optional attribute set is ordered; that is, NO = {al, az, . . . , a,}. The

most preferred answer matches the mandatory attributes and all of the

optional attributes; however, if no such match exists then a match based

on optional attribute al is preferred over a match based on attribute a~ if

i


registered for each object, such that, if a client gives a handle, the naming

system is guaranteed to return at most one object. Handles are implemented

by attaching a unique prefix to a registered attribute so as to ensure its

uniqueness.

4.4 Resolution Functions for Conventional Naming Systems

Although descriptive naming systems such as Profile, the CSNET name

server, and the NIC name server take advantage of the full expressive power

of the preference hierarchy, understanding preferences provides insight into

more conventional systems.

Conventional naming systems support a simple inference system: They

restrict the database to accurate, unambiguous attributes and restrict queries

to names containing a single, accurate attribute. This implies that all matches

are unique. As a consequence, conventional naming systems are trivially

given by a resolution function corw, which returns the set of objects uniquely

matched by the set of unambiguous attributes in the name. Given this

definition, it is easy to see the following:

PROPOSITION 4.10. The function conu is sound for all singleton sets of

attributes.

Notice, however, that the restriction that only unambiguous attributes may

be registered implies that such systems cannot be complete for attribute sets

other than those that contain a single, unambiguous attribute. Thus, we have

the following:

PROPOSITION 4.11. The function conzi is complete for all sets of attributes

that contain no ambiguous attributes.

Consider a common scenario in which the naming system is used to map a

symbolic name into a machine-readable address. In this case, the symbolic

name registered for a particular object is an authoritative attribute, that is,

one that always describes the object, and the object’s machine-readable

address is either a cached attribute, that is, one that currently describes the

object, in which case the system must be designed to flush the binding if

there is any chance that it has become stale, or it is an out-of-date attribute,

that is, one that described the object at one time but may not describe it now,

in which case users of the naming system must be able to accommodate

out-of-date information. The latter case is commonly referred to as a hint

[Terry 1987].It is important to note that conventional naming systems, because of the

requirements placed on them, generally sacrifice completeness for the sake

of soundness. Descriptive naming systems, on the other hand, often sacri-

fice soundness for the sake of completeness. To accomplish this, conventional

(low-level) systems are likely to deal exclusively with preference classes thatare high in the preference hierarchy (e.g., unambiguous, unique, and authori-

tative attributes), whereas descriptive (high-level) systems are likely to ac-

cept preference classes that are low in the hierarchy (e.g., ambiguous and

cached attributes). Moreover, although high-level naming systems are more

ACM Transactions on Programming Languages and Systems, Vol 15, No 5, November 1993


likely to accommodate multiple preference classes, even low-level namingsystems that accommodate only one preference class have implicitly made

a decision regarding that preference. That is, they mandate a certain

preference class.

4.5 Comparing Systems

The preference hierarchy provides a handle on comparing naming systems.

For example, because conventional naming systems assume unambiguous

attributes and unique matches, and because both of these preference classes

are present in the preference hierarchy upon which ProfUe is based, one can

directly compare Profile’s most discriminating resolution function with conv

as follows:

profiled L ~conv

for all sets of name\ database pairs in A. In other words, it is accurate to view

conu as a restrictive member of the Profile family of resolution functions.

Although we cannot compare naming systems unless the preference hier-

archy of one can be embedded in that of the other, being able to conclude that

the naming systems are inherently different is itself useful. For example, one

might be interested in knowing if white-pages and yellow-pages services are

fundamentally different or if they are simply synonyms for the same thing.

The answer, at least relative to the systems with which we have experience,

is that they are fundamentally different. White-pages services are based on

open and closed preference classes, whereas yellow-pages services are based

on mandatory and optional preference classes.

Furthermore, our experience strongly suggests that these preference classes

correctly represent the environment in which the two systems operate and

the requirements placed on the two systems by the clients that use them.

In the case of white-pages services, the fact that not all useful information

about users is known to the naming system is a significant constraint on the

sYstem; the resolution functions must be designed in a way that accommo-

dates missing information. Also, because clients of a white-pages system

generally have a particular object in mind when they submit a name, it is

implied that the object identified by the attribute should possess all of the

attributes in the name; that is, the distinction between mandatory and

optional attributes is not relevant. In the case of yellow-pages services, it is

possible to ensure that all of the necessary information be stored in the

database. A program is responsible for registering attributes; the distinction

between open and closed attributes is not an issue. Moreover, the client that

names a computational resource is most interested in distinguishing between

similar resources; that is, clients generally do not care which processor they

get as long as it has the appropriate blend of attributes. Thus, the fine-grain

control afforded by partitioning the name into mandatory and optional

attributes is useful.

5. CONCLUDING REMARKS

This paper reasons about naming systems as specialized inference mecha-

nisms. It defines a preference hierarchy that is used to specify the resolution

ACM TransactIons on PrOgramm,ng Languages and Systems, VO1.15, No 5, November 1993.


function(s) associated with a given naming system, including both conven-

tional and descriptive systems. The preference hierarchy has proved powerful

enough to describe the naming systems we have encountered. We have

implemented a general name server that explicitly enforces this model and

are using it to implement many of the naming systems described in this

paper.

In addition to providing a formal model for understanding existing naming

systems, we have also found the preference hierarchy to be a prescriptive tool

that can be used when designing new naming systems. For example, the

Profile naming system introduced in Section 3 was designed before we had

formally defined the preference hierarchy, but clearly, an intuitive under-

standing of preferences guided the design. It is interesting to note that the

formal specification of the preference hierarchy led us to understand and

correct a subtle flaw in the original definition of profile~. It also led to the

definition of the new function, profi[e.,,u, given in Section 4.1.

As another example, after having defined the preference hierarchy, we

were able to apply it to the problem of designing a yellow-pages service used

to identify computational resources such as printers, processors, databases,

network servers, and so on [Peterson 1987]. In particular, we wanted a

descriptive yellow-pages service that would allow users to discriminate among

a set of similar resources, that is, resources that provided approximately the

same service. The result was the resolution function yp given in Section 4.3.

As a final example, we have observed that the domain naming system

(DNS) [Mockapetris 1987] evolved in a way that suggests an implicit under-

standing of the preference hierarchy. Specifically, DNS provides the same

functionality as conventional systems: It maps host names into network

addresses. Unlike simpler systems, however, DNS is implemented in a net-

work environment in which the database is distributed over multiple hosts.

Several years of experience with the system led its designers to understand

that the DNS mechanism must be able to deal correctly with out-of-date data.

In particular, an updated specification of the system reads, “Cached data

should never be used in preference to authoritative data. .“ This informal

definition directly corresponds to the temporal preference cached +,

authoritative. The important points are that, even in functionally simple

systems that maps names into addresses, it is possible for the environment in

which the system is implemented to impose constraints on the system, and

that the technique used to deal with these constraints can, in turn, be

expressed in terms of the preference hierarchy.

APPENDIX

This Appendix contains several Scheme function definitions used to imple-

ment the name resolution functions described in Section 4. This is how we

actually define resolution functions in the Univers name server [Bowman

et al. 1990]. These functions may be included as part of the query, or stored in

the Univers server and referenced by the query. Note that several optimiza-

ACM TransactIons on Programmmg Languages and Systems, Vol. 15, No. 5, November 1993


tions have been made in order to avoid redundant computations of composite

approximation functions.

(define (profile 1 N D)(also-ran (urwersal N) D)

)

(d~&wJprofile2 N D)

[(unanimous (closed N) D)][(also-ran (closed N) D)][(unarwmous (open N) D)][(also-ran (open N) D)]

))

(dy:::Jprofile3 N D)

[(unique (closed N) D)][(unanimous (open N) (unarumous (closed N) D))][(also-ran (open N) (unanimous (closed N) D))][(unanimous (closed N) D)][(unanimous (open N) (also-ran (closed N) D))][(also-ran (open N) (also-ran (closed N) D))][(also-ran (closed N) D)][(unarumous (open N) D)][(also-ran (open N) D)]

))

(define (profile4 N D)(unique (closed N) D)

)

(de$w~profile-new N D)

[(also-ran (open N) (unanimous (closed N) D))][(unanimous (closed N) D)][(also-ran (open N) (also-ran (closed N) D))][(also-ran (closed N) D)][(also-ran (open N) D)][D]

))

[(exact (closed (unambiguous N)) D)][(parhal (open (unambiguous N)) D)][(exact (ambiguous N) D)][(partial (open (ambiguous N)) (exact (closed (ambiguous N) D))][(possible (open (ambiguous N)) (exact (closed (ambiguous N)) D))][(exact (open (ambiguous N)) D)][(partial (open (ambiguous N)) D)]

))



(define (YP M O D)(If (null? O)

&oex: M D)

[(exact O (exact M D))][(YP M (cdr O) D)]

))

)

(d~~;~(csnet N D)

[(unique (mandatory N) D)][(maximum (optional N) (exact (mandatory N) D))][(exact (mandatory N) D)]

))

(define (conv N D)(unique (unambiguous N) D)

)

ACKNOWLEDGMENTS

The authors wish to thank the anonymous referees, who persisted in helping

us improve the quality of this paper.

REFERENCES

BETZ, D. M 1989. Xscherne: An ObJect-Oriented Scheme. Peterborough, N.H.

BORNING, A., DUISBER~, R , AND FREEMAN-BENSON, B. 1987. Constraint hierarchies. In Pro-

ceedings of 00PSLA ’87 (Ott). ACM, New York, 48–60.BOWMAN, M. 1990. Univers: The construction of an internet-wide descriptive nammg system.

Ph.D thesis, Dept. of Computer Science, Univ. of Arizona, Tucson, Aug.

BOWMAN, M., PETERSON, L., AND YEATTS, A. 1990. Univers An attribute-based name server.

Softw. Prac. Exper. 20, 4 (Apr.), 403-424.

BUDD, T. 1986. Bib—A program for formatting bibliographies. In Unw User’s Supplementary

Documents. 4.3 Berkeley Software Dustrlbution Apr.

COMER, D. E,, AND PETERSON, L, L. 1989. Understanding naming in distributed systems.

Dtstrib. Comput. 3, 2 (May), 51-60.

I?ABRY, R. S. 1974. Capability-based addressing. Commun. ACM 17, 7 (July), 403-411.

FOWLER, R. J. 1985. Decentralized object finding using forwarding addresses. Ph.D. thesis,

Dept. of Computer Science, Univ. of Washington, Seattlej Dec.

GALLAIRE, H., MINKER, J., AND NICOLAS, J. 1984. Logic and databases: A deductive approach.

ACM Comput. Suru. 16, 2 (June), 153-186.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. 1988. Information processing systems:

Open systems interconnection—The directory-Overview of concepts, models, and ser-

vice. Draft International Standard I SO 9594-1: 1988(E), International Organization of

Standardization, New York.

LAMPSON, B. 1986 Designing a global name service. In Proceedings of 5th Symposzum on the

Principles of Distributed Computing (Aug.). ACM, New York, 1-10.

LIPSKL W., JR. 198L On databases with incomplete information. J. ACM 28, 1,41-70.LIPSW, W., JR. 1979 On semantic issues connected with incomplete information databases.

ACM Trans. Database Syst. 4, 3 (Sept.), 262-296.

MANN, T. 1987. Decentralized naming in distributed computer system. Ph.D. thesis, Stanford

Univ., Palo Alto, Calif, May.

ACM TransactIons on Programming Languages and Systems, Vol 15, No. 5, November 1993


MOCKAPETRIS, P. 1987. Domain names—ImpIementation and specification. Request For Com-

ments 1035, USC Information Sciences Institute, Marina del Ray, Calif., Nov.

OPPEN, D., AND DALAL, Y. 1981. The clearinghouse: A decentralized agent for locating named

objects in a distributed environment. Tech. Rep. OPD-T8 103, Xerox Office Products Division,

Palo Alto, Calif., Oct.

PETERSON, L. L. 1988. The Profile naming service. ACM Trans. Comput. Syst. 6, 4 (Nov.),

341-364.

PETERSON, L. L. 1987. A yellow-pages service for a local-area network. In Proceedings of the

SIGCOMM ’87 Workshop: Frontiers m Computer Communications Technology (Stowe, Vt.,

Aug.). ACM, New York, 235-242.

PICKENS, J., FEINLER, E., AND MATHIS, J. 1979. The NIC name server—a datagram based

information utility. In Proceedings of the 4th Berkeley Works}Lop on Distributed Data

Management and Computer Networks (Aug.).

PRICE, C. 1971. Table lookup techniques. ACM Comput. Suru. 3, 2, 49-65,

REITER, R. 1980. On closed world databases. In Logic and Databases, H. Gallaire and

J. Minker, Eds. Plenum Press, New York, 55-76.

RITCHIE, D. M., AND THOMPSON, K. 1974. The Unix time-sharing system. Commun. ACM 17, 7

(July), 365-375.

SOLOMON, M., LANDWEBER, L., AND NEUHENGEN, D. 1982. The CSNET name server. Comput.

Networks 6, 161-172.

SUN MICROSYSTEMS INC. 1986. Yellow Pages Protocol Spec@catLon. Sun Microsystems Inc.,

Mountain View, Calif., Feb.

TERRY, D. 1987. Caching hints in distributed systems. IEEE Trans. Softw. Eng. SE-13, 1

(Jan.), 48-54.ULLMAN, J. D. 1988. Principles of Database and Knowledge-Base Systems. Vol. 1. Computer

Science Press, Rockville, Md.

WATSON, R. 1981. Identifiers (naming) in distributed systems. In Distributed Systems—

Architecture and Implenzentatzon, B. Lampson, M. Paul, and H. Siegert, Eds. Lecture Notesin Computer Science. Springer-Verlag, New York, 191–210.

WONG, E. 1982. A statistical approach to incomplete information in database systems. ACM

Trans. Database Syst. 7, 3 (Sept.), 470-488.

Received October 1987; revised February 1989, June 1990, April 1992, and March 1993; accepted

March 1993
