FNS Policy Principles

The following principles were used to arrive at FNS policies:

• When it is natural to name other objects relative to a certain object, that object should provide a naming context. For example, because it is natural to want to name various things relative to a user, a user object should be a naming context.

• It should be possible to compose names using common components. This reduces the number of names that users need to remember and makes it easier for applications and users to construct names based on their knowledge of common components and how they can be logically composed.

• Names should be intuitive and self-evident. For example, the FNS name /user/wong/service/calendar clearly identifies the calendar service used by Wong. In contrast, the calendar name wong@deneb names the host (deneb) where the calendar service for Wong is being provided. But to other users, there is no obvious connection between the user's calendar and a host. The host name is extraneous and difficult to discover and remember.

• Never use two contexts when one context will do. In the example above, we would like to name a mail address, a calendar, and a file's directory relative to the user wong. Sharing contexts and their names make naming more coherent and simplifies administration.