Solaris Naming Administration Guide

The XFN Model

This section describes the XFN naming model from several perspectives.

XFN Architectural Model

The primary services provided by a federated naming system are mapping a composite name to a reference and providing access to attributes associated with a named object. This section defines the elements of the XFN naming model.

Atomic Names

The smallest, indivisible component of a name is called an atomic name. For example, the machine name nismaster or the user name chou. An atomic name may have one or more attributes, or no attributes at all (see "Attributes").


A reference is the information on how to reach an object. A reference contains a list of addresses. An address identifies a communication endpoint (an object). For example, the address of a machine such as, or a user's email address such as

A reference might contain multiple addresses that identify multiple communication endpoints for a single conceptual object or service. For example, a list of addresses might be required because the object is distributed or because the object can be accessed through more than one communication mechanism.

Note -

XFN cannot guarantee specific properties of addresses such as their stability, validity, or reachability. A client might be able to look up a name but not be able to use the returned reference because the client might not have support for any of the necessary communication mechanisms or might lack the necessary network connectivity to reach the address. Further, the address might be invalid from that origin or stale; these issues are the province of the convention between the name's binder, the clients, and the service provider specified in the address.


A context is a set of atomic names bound to references, as shown in Figure 21-1. Every context has an associated naming convention. A context provides a lookup (resolution) operation, which returns the reference, and may provide operations such as binding names, unbinding names, and listing bound names. Contexts are at the heart of the lookup and binding operations.

Figure 21-1 An XFN `Context'



Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attributes, or multiple attributes.

Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values. Attributes are indicated by the dotted lines in Figure 21-1 above.

XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other types of objects. Associated with a context are syntax attributes that describe how the context parses compound names.

The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.

Compound Names

A compound name is a sequence of one or more atomic names. An atomic name in one context can be bound to a reference to another context of the same type, called a subcontext. Objects in the subcontext are named using a compound name. Compound names are resolved by looking up each successive atomic name in each successive context.

A familiar analogy for UNIX users is the file naming model, where directories are analogous to contexts, and path names serve as compound names. Furthermore, contexts can be arranged in a "tree" structure, just as directories are, with the compound names forming a hierarchical namespace.

For example:

Composite Names

A composite name is a name that spans multiple naming systems. Each component is a name from the namespace of a single naming system. Composite name resolution is the process of resolving a name that spans multiple naming systems.

Components are separated by slashes (/) and ordered from left to right, according to XFN composite name syntax. For example, the composite name

has two components, a DNS name ( and a UNIX path name (usr/local/bin).

FNS Namespaces

Atomic names and reference addresses may also be resolved relative to one or more namespaces. By default, FNS provides six namespaces: org (for organization), site, host, user, service, and fs (for files).

FNS policies are used to determine how names associated with namespaces relate to each other. For example; a user is named sergei in the user namespace and is identified as /user/sergei. A calendar application is named in the service namespace and is identified as /service/calendar. With this system, you can then identify Sergei's calendar service as: /user/sergei/service/calendar. (See "Introduction to FNS and XFN Policies" for more information on namespaces and how they are used.)

If an application is expecting you to type a user name, the application can include the namespace identifier user/ in front of names that you enter. If the application needs to name one of the user's services, such as the user's default fax machine, it can append the service namespace and the name of the service (/service/fax), to the input supplied. Hence, a fax tool might take as input the user name jacques and then compose the full name user/jacques/service/fax for the default fax of the user jacques. Similarly, to access a person's calendar, you just need to type the person's user name. The application takes the input, raj, and uses it to construct the composite name, in this case, user/raj/service/calendar.

XFN Links

An XFN link is a special form of a reference that is bound to an atomic name in a context. Instead of an address, a link contains a composite name. Many naming systems support a native notion of link that can be used within the naming system itself. XFN does not specify whether there is any relationship between such native links and XFN links.

Initial Context

Every XFN name is interpreted relative to some context, and every XFN naming operation is performed on a context object. The initial context object provides a starting point for the resolution of composite names. The XFN interface provides a function that allows the client to obtain an initial context.

The policies described in Chapter 22, FNS Policies, specify a set of names that the client can expect to find in this context and the semantics of their bindings. This provides the initial pathway to other XFN contexts.

User's View

Users experience federated naming through applications. Typically, the user does not need to compose or know the full composite name of objects because the application takes care of constructing the composite names. This allows the user to interact with XFN-aware applications in a simple, intuitive, and consistent manner.

File System View

Users and applications also experience federated naming through the file system. The initial context is located under /xfn in the root directory. For example, user ingrid's to_do file has the XFN name, xfn/user/ingrid/fs/to_do.

To read this file, you could type:

% cat /xfn/user/ingrid/fs/to_do

Applications access the files under /xfn just as they do any other files. Applications do not need to be modified in any way, nor do they need to use the XFN API.

Application View

The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures. Figure 21-2 shows an application that uses the XFN API and library.

Figure 21-2 Client Application Interaction With XFN


Figure 21-3 shows the details beneath the API. A name service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into name service-specific calls.

Figure 21-3 Details Beneath XFN API


API Usage Model

Many clients of the XFN interface are only interested in lookups. Their usage of the interface amounts to:

Once the client obtains a desired reference from the lookup operation, it constructs a client-side representation of the object from the reference.