OIDs are not seen by applications that restrict themselves to using only the RPC NSI routines (rpc_ns_...( )), but these identifiers are important for applications that use the XDS interface to read entries directly or to create new attributes for use with namespace entries.
RPC 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, which can be added by applications to RPC 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.
Unlike UUIDs, OIDs are not generated by command or function call. They originate from ISO, which allocates them in hierarchically organized blocks to recipients. Each recipient, typically some organization, is then responsible for ensuring that the OIDs it receives are used uniquely.
For example, the following OID block was allocated to OSF by ISO:
1.3.22
OSF can therefore generate, for example, the following OID and allocate it to identify some DCE directory object:
1.3.22.1.1.4
(The OID 1.3.22.1.1.4 identifies the RPC profile entry object attribute.) OSF is responsible for making sure that 1.3.22.1.1.4 is not used to identify any other attribute. Thus, as long as all OIDs are generated only from within each owner's properly obtained block, and as long as each block owner makes sure that the OIDs generated within its block are properly used, each OID will always be a universally valid identifier for its associated value.
OIDs are encoded and internally represented as strings of hexadecimal digits, and comparisons of OIDs have to be performed as hexadecimal string comparisons (not as comparisons on NULL-terminated strings since OIDs can have NULL bytes as part of their value).
When applications have occasion to handle OIDs, they do so directly because the numbers do not change and should not be reused. However, for users' convenience, CDS also maintains a file (called cds_attributes, found in /opt/dcelocal/etc) that lists string equivalents for all the OIDs in use in a cell in entries like the following one:
1.3.22.1.1.4 RPC_Profile byte
This allows users to see RPC_Profile in output, rather than the meaningless string 1.3.22.1.1.4. Further details about the cds_attributes file and OIDs can be found in the OSF DCE Administration Guide.
In summary, the procedure you should follow to create new attributes on CDS entries consists of three steps:
1. Request and receive from your locally designated authority the OIDs for the attributes you intend to create.
2. Update the cds_attributes file with the new attributes' OIDs and labels 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.
Your cell administrator should be able to provide you with a name and an OID. The name is a guaranteed-unique series of values for a global directory entry name. If the directory is GDS, the name is a series of type/value pairs, such as:
C=US O=OSF
The cell administrator can also obtain an OID block. From this OID space, the administrator can assign you the OIDs you need for your application.
Note that there is no need for new OIDs in connection with cell names. The OIDs for Country Name and Organization Name are part of the X.500 standard implemented in GDS; only the values associated with the OIDs (the values of the objects) change from entry name to entry name. Instead, being able to generate new OIDs gives you the ability to invent and add new details to the directory itself. For example, you can create new kinds of CDS entry attributes by generating new OIDs to identify them. The same thing can be done to GDS, although the procedure is more complicated because it involves altering the directory schema.