In today's networked environment there are many instances of directories used for many different purposes. Example directories include Network Operating System Directories such as for managing logins, file-systems, and printers; Security Directories such as for single sign-on, web access management, and service management; application specific directories, such as online telephone directories, location directories, and email directories; and publishing directories, such as white pages, yellow pages, and blue pages.
In practice, many directories operate in isolation from each other, resulting in problems. One such problem is duplication of data, which may result in inconsistencies between servers depending on how the data is updated. Another problem is fragmentation of data, which results when different systems store data in different ways. Another problem is that management and administration of separate systems can be tedious and duplicated. Further, there can be problems with privileges and enforcing organizational wide policies between systems. With respect to standards, vendors have proprietary systems with many proprietary extensions and vendors are not obligated to adopt a common standard. In addition, sharing of databases or their customization is difficult; one operations group may “own” a particular directory and will not allow it to be used, written to, or extended by another group or other applications.
A fundamental aspect of defining and deploying directories is to pre-define the directory “schema.” The directory schema is a way of controlling what information is stored in a directory. Generally, a directory schema defines the following types of rules: the attribute syntax, the attribute type, the object class, and the directory information tree (DIT) structure rules. The attribute syntax is a way of defining an information type, such as a string, number, Boolean, date, etc. The attribute type is the universal name of an attribute. In X.500, for example, this is represented by an object identifier, such as 2.5.4.3 for commonName. In Lightweight Directory Access Protocol (LDAP), for example, this is represented by string identifier, such as a commonName, surname, address, etc. The object class is a special attribute that funds the rules about what attribute types are allowed in each entry. This basically defines which attributes are mandatory, in other words, which attributes must be contained, and which attributes are optional, which attributes may be contained, in an object entry. DIT structure rules are the rules about how the DIT is constructed. For example, allowable parents, allowable naming attributes, and at what depth an object may appear. For example, under an “organization” object there may be directory information tree structure rules the define that only an “organizationalUnit” object may appear. This object may only be named by “organizationalUnitName” and there may only be a maximum of, say four “organizationalUnit” objects under an “organization” object.
Fixed directory schema pose a number of problems. For example, applications that have “plug-in” architectures may not know in advance what information types they need to support. Further, applications installed in operationally sensitive environments may have complicated change control procedures to update configuration. In addition, applications may want their attribute definitions to be private and not go globally published as is the case with normal directory schema.
Conventionally, some directory services allow changes in their schema out of band. In other words configuration files may be changed and the service reinitialized. This procedure is cumbersome and time consuming. In some instances directory services can change their schema in band via a special change schema directory request. However, this approach is disadvantageous because it must be done prior to first use an attribute and/or it may require special administrative privileges.
USPTO Backgrounds
USPTO Backgrounds