PreviousNext

CDS Entry Attributes

Within the DCE Directory Service, entry attributes such as the four previously described attributes are identified by object identifiers (OIDs). This is an exception to the general rule that things in DCE are identified by UUID.

OIDs are not seen by applications that restrict themselves to using only the name service routines (rpc_ns_*( )), but these identifiers are important for applications that use the X/Open Directory Services (XDS) interface to create new attributes for use with namespace entries.

As was seen in the immediately preceding topics, the name service makes use of only four different entry attributes in various application-specified or administrator-specified combinations. CDS, however, contains definitions for many more than these, and attributes from this supply of already existing ones can be added by applications to NSI entries through the XDS interface. Attributes that already exist are already properly identified, so applications that use these attributes do not have to concern themselves with the OIDs, except to the extent of making sure that they handle them properly.

A further possibility is that an application requires new attributes for use with namespace entries. Such attributes can be created using the XDS interface. When it creates new attributes, the application is responsible for tagging them with new, properly allocated OIDs.

Unlike UUIDs, OIDs are not generated by command or function call. They originate from the International Organization for Standardization (ISO), which allocates them in hierarchically organized blocks to recipients. Each recipient (typically an organization of some kind) is then responsible for ensuring that the OIDs it received are used uniquely.

For example, the following OID identifies the NSI profile entry attribute. This number was assigned by the Open Software Foundation out of a block of numbers, beginning with the digits 1.3.22, which was allocated to it by ISO, and OSF is responsible for making sure that 1.3.22.1.1.4 is not used to identify any other attribute.

1.3.22.1.1.4

When applications have occasion to handle OIDs, they do so directly, since the numbers do not change and should not be reused. However, for users' convenience, CDS also maintains a file (whose name is /opt/dcelocal/etc/cds_attributes) that lists string equivalents for all the OIDs in use in a cell, in entries like the following:

1.3.22.1.1.4 RPC_Profile byte

This allows users to see RPC_Profile in output, rather than the mysterious 1.3.22.1.1.4. Further details about the cds_attributes file and OIDs can be found in the OSF DCE Administration Guide - Core Components.

Broadly speaking, the procedure you should follow to create new attributes on CDS entries consists therefore of three steps:

1. Request and receive, from your locally designated authority, OIDs for the attributes you intend to create.

2. Update the cds_attributes file with the new attributes' OIDs and labels; that is, if you want your application to be able to use string name representations for OIDs in output.

3. Using XDS, write the routines to create, add, and access the attributes.

Non-NSI attributes on NSI entries can be very useful, even though you cannot access the extra attributes through the name service routines but must use XDS instead.