This chapter provides information about writing applications that use the XDS/XOM interface to access the portion of the DCE namespace contained in the Cell Directory Service.
The XDS/XOM interface provides generalized access to CDS. However, if you only need to use CDS to store information related to RPC (for example, storing the location of a server so that clients can find it), you should use the Name Service Independent (NSI) interface of DCE RPC. NSI implements RPC-specific use of the namespace. For information on using RPC NSI, see the OSF DCE Application Development Guide--Core Components volume.
For information on the details of accessing the CDS namespace through the XDS/XOM interface, see Chapter 3.
The following subsections describe the organization of a cell's namespace after it has initially been configured. (For more information on configuring a cell, see the Transarc DCE Administration Guide.)
Every DCE cell is set up at configuration with the basic namespace structure necessary for the other DCE components to be able to find each other and to be accessible to applications. The vital parts of the namespace are protected from being accessed by unauthorized entities by Access Control Lists (ACLs) that are attached to the entries and directories.
Figure 2-1 shows what the cell namespace looks like after a cell has been configured and before any additional directories or entries have been added to it by system administrators or applications. In the figure, ovals represent directories, rectangles represent simple entries, circles represent soft links, and triangles represent namespace junctions.
All of the simple entries shown in the figure are created for use with RPC NSI routines; that is, they all contain server-binding information and exist to enable clients to find servers. These are referred to as ``RPC entries.''
Note that only the name entries (those in boxes) and junction entries (those in triangles) are RPC entries. The directories (entries indicated by ovals) are normal CDS directories.
Some of the namespace entries in the figure are intended to be used (if desired) directly by applications; namely, /.:/cell-profile, /.:/lan-profile, and, through the /: soft link alias, /.:/fs. The self and profile name entries under hosts also fall into this category. Others, such as those under /.:/subsys/dce, are for the internal use of the DCE components themselves.
Each of the entries is explained in detail in the following subsections. See the Transarc DCE Administration Guide for detailed information on the contents of the initial DCE cell namespace.
The /.:/cell-profile entry is an RPC profile entry that contains the default list of namespace entries to be searched by clients trying to bind to certain basic services. An RPC profile is a class of namespace entry used by the RPC NSI routines. When a client imports bindings from such an entry, it imports, through the profile, from an ordered list of RPC entries containing appropriate bindings. The list of entries is keyed by their interface UUIDs so that only bindings to servers offering the interface sought by the client are returned. The entries listed in the profile exist independently in the namespace, and can be separately accessed in the normal way. The profile is simply a way of organizing clients' searches.
The main purpose of cell-profile is to have a ``path of last resort'' for prospective clients. All other profile entries in the cell namespace are required to have the cell-profile entry in their entry lists so that if a client exhausts a particular profile's list of entries, it tries the entries in cell-profile.
The /.:/lan-profile entry is a LAN-oriented default list of services' namespace entries that is used when servers' relative positions in the network topography are of importance to their prospective clients.
The /.:/cdshostname_ch entry is the namespace entry for cdshostname's clearinghouse, where cdshostname is the name of the host machine on which a CDS server is installed.
A ``clearinghouse'' is the database managed by a CDS server; it is where CDS directory replicas are physically stored. For more information about clearinghouses, see the Transarc DCE Administration Guide. All clearinghouse namespace entries reside at the cell root, and there must be at least one in a DCE cell. The first clearinghouse's name must be in the form shown in Figure 2-1, but additional clearinghouses can be named as desired.
The /.:/hosts entry is a directory containing entries for all of the host machines in the cell. Each host has a separate directory under hosts; its directory has the same name as the host. Four entries are created in each host's directory:
This entry contains bindings to the host's DCE daemon (dced), which is responsible for, among other things, dynamically resolving the partial bindings that it receives in incoming RPCs from clients attempting to reach servers resident on this host.
This entry is the default profile entry for the host. This profile contains in its list of entries at least the /.:/cell-profile entry described in Section 2.1.1.
This entry contains bindings to the host's resident CDS clerk.
This entry contains bindings to a CDS server.
The /.:/subsys entry is the directory for subsystems. Subdirectories below subsys are used to hold entries that contain location-independent information about services, particularly RPC binding information for servers.
The dce directory is created below /.:/subsys at configuration. This directory contains directories for the DCE Security Service and Distributed File Service components. The functional difference between these two directories and the fs and sec junctions described in Section 2.1.7 is that the latter two entries are the access points for the components' special databases, whereas the directories under subsys/dce contain the services' binding information.
Subsystems that are added to DCE should place their system names in directories created beneath the /.:/subsys directory. Companies adding subsystems should conform to the convention of creating a unique directory below subsys by using their trademark as a directory name. Use these directories for storage of location independent information about services. You should store server entries, groups and profiles for the entire cell in the directories below subsys. For example, International Air Freight-supplied subsystems should be placed in /.:subsys/IAF.
The entry /: is created and set up as a soft link to the /.:/fs entry, which is the DFS database junction. The name /: is equivalent to /.:/fs. Note, however, that the name /: is well-known, whereas the name /.:/fs is not, so using /: makes an application more portable. A CDS soft link entry is an alias to some other CDS entry. A soft link is created through the cdscp command. The procedure is described in the Transarc DCE Administration Guide.
The /.:/fs entry is the Distributed File Service junction entry. This is the entry for a server that manages the DFS file location database.
The /.:/sec entry is the DCE Security Service junction entry. This is the entry for a server that manages the Security Service database (also called the registry database).
The /.:/fs and /.:/sec root entries in Figure 2-1 are junctions maintained by DCE components. The /.:/sec junction is the DCE Security Service's namespace of principal identities and related information. The Distributed File Service's fileset location servers are reached through the /.:/fs entry, making /.:/fs effectively the entry point into the cell's distributed file system.
Note that /.:/sec and /.:/fs are both actually RPC group entries (for definitions of the RPC entry types, see Chapter 2 of the present book); the junctions are implemented by the servers whose entries are members of the group entries. (See the Transarc DCE Administration Guide for further details on the Security Service and DFS junctions.)
CDS data is maintained in a loosely consistent manner. This means that when the writeable copy of a replicated name is updated, the read-only copies may not be updated for some period of time, and applications reading from those nonsynchronized copies can receive stale data. This is in contrast to distributed databases, which use multiphase commit protocols that prevent readers from accessing potentially stale or inconsistent data while the writes are being propagated to all copies of the data. It is possible to specifically request data from the master copy, which is guaranteed to be up-to-date, but replication advantages are then lost. This should only be done when it is important to obtain current data.
Some CDS entries may contain information that is immediately useful or meaningful to applications. Other entries may contain RPC information that enables application clients to reach application servers; that is, binding handles for servers, which are stored and retrieved using the RPC NSI routines. In either case, the entry's name should be a meaningful identification label for the information that the entry contains. This is because the namespace entry names are the main clue that users and applications have to the available set of resources in the DCE cell. Using the CDS namespace to store and retrieve binding information for distributed applications is the function of DCE RPC NSI.
In general, applications can store data into CDS object entry attributes in any XDS-expressible form they wish. Tables 3-2 and 3-3 show XDS-to-CDS data type translations. If you add new attributes to the /opt/dcelocal/etc/cds_attributes file, together with a meaningful CDS syntax (that is, a data type identifier) and name, then the attribute is displayed by cdscp show commands when executed on objects containing instances of that attribute.
There are three main questions to consider when using CDS to store data through application calls to XDS:
You are free to create new directories as long as you do not disturb the namespace's configured structure. Keep in mind that CDS directories must be created with the cdscp command; they cannot be created by applications.
Only two root-level directories are created at configuration: hosts and subsys. Applications should not add entries under the hosts tree; the host's default profile should instead be set up by a system administrator. The subsys directory is intended to be populated by directories (for example, /.:/subsys/dce) in which the servers and other components of independent vendors' distributed products are accessed. Thus, the typical cell should usually have a series of root-level CDS directories that represent a reasonable division of categories.
One obvious division could be between entries intended for RPC use (that is, namespace entries that contain bindings for distributed applications), and entries that contain data of other kinds. On the other hand, it may be very useful to add supplementary data attributes to RPC entries in which various housekeeping or administrative data can be held. In this way, for example, performance data for printers can be associated with the print servers' name entries. You can either add new attributes to the server entries themselves, where, for example,
/.:/applications/printers/pr1
is the name of a server entry that receives the new attributes. Or you can change the subtree structure so that new entries are added to hold the data, the server bindings are still held in separate wholly RPC entries, and each group of entries is located under a directory named for the printer:
/.:/applications/printers/pr1 -- directory /.:/applications/printers/pr1/server -- server bindings /.:/applications/printers/pr1/stats -- extra data
In general, the same principals of logic and order that apply to the organization of a file system apply to the organization of a namespace. For example, server entries should not be created directly at the namespace root because this is the place for default profiles, clearinghouse entries, and directories.
Figure 2-2 illustrates some of the preceding suggestions, added to the initial configuration namespace structure shown in Figure 2-1.
In Figure 2-2, the vendor of the ``xyz'' subsystem has set up an xyz directory under /.:/subsys in which the system's servers are exported. This cell also has an /.:/applications directory in which the printers directory contains separate directories for each installed printer available on the system; the directory for pr1 is illustrated in the figure. In the pr1 directory, server is an RPC entry containing exported binding handles, and stats is an entry created and maintained through the XDS interface.
Because CDS allows you to add as many attributes as you wish to an object entry, it is up to you to impose some restraint in doing this. In view of the XDS overhead involved in reading and writing single CDS attributes, it makes sense to combine multiple related attributes under single entries (that is, in the same directory object) where they can be read and written in single calls to ds_read() or ds_modify_entry(). This way, for example, you only have to create one interface input object (to pass to ds_read()) to read all the attributes, which you can do with one call to ds_read(). You can then separate out the returned subobjects that you are interested in and ignore the rest. Chapter 3 contains detailed discussions of XDS programming techniques.
In any case, you should define object types for use in applications so that namespace access operations can be standardized and kept efficient. A CDS object type consists of a specific set of attributes that belong to an object of that type, with no other attributes allowed. Note again that CDS, unlike GDS, does not force you to do things this way. You could theoretically have hundreds of CDS object entries, each of which would contain a different combination of attributes.
When you consider adding information to the namespace, you can choose between creating a new directory, possibly with entries in it, or creating simply one or more entries. When making your decision, take into consideration the following:
Each object in the CDS namespace is automatically equipped with a mechanism by which access to it can be regulated by the object's owner or by another authority. For each object, the mechanism is implemented by a separate list of the entities that can access the object in some way; for example, to read it, write to it, delete it, and so on. Associated with each entity in this list is a string that specifies which operations are allowed for that entity on the object. The object's list is automatically checked by CDS whenever any kind of access is attempted on that object by any entity. If the entity can be found in the object's list, and if the kind of access the entity intends is found among its permissions, then the operation is allowed to proceed by CDS; otherwise, it is not allowed.
DCE permission lists are called Access Control Lists (ACLs). ACLs are one of the features of the DCE Security Service used by the Cell Directory Service. ACLs are used to test the entities' (that is, the principals') authorization to do things to the objects they propose to do them to. The authorization mechanism for all CDS objects is handled by CDS itself. All that users of the CDS namespace have to do is make sure that ACLs on the CDS objects that they create are set up with the appropriate permissions.
Whenever you create a new entry in the CDS namespace, an ACL is created for it implicitly, and its initial list of entries and their permission sets are determined by the ACL templates associated with the CDS directory in which you create the entry.
Each CDS directory has the following two ACL templates associated with it:
This template is used to generate the initial ACL for any directories created within the directory.
This template is used to generate ACLs for entries created within the directory.
Every CDS directory also has its own ACL, just like any other CDS object. This ACL is generated from the parent directory's Initial Container template when the child directory is created. The Initial Container template also serves as a template for the child directories' own Initial Container templates.
There are two ways to manipulate ACLs: either through the acl_edit command, which is documented in the Transarc DCE Command Reference, or through the DCE ACL application interface, which consists of routines documented in the OSF DCE Application Development Reference. (These routines have names in the form of sec_acl_...().)
After creating a CDS directory using the cdscp command, your first step is usually to run the acl_edit command to set up the new directory's ACLs the way you want them. (The new directory will have inherited its ACLs and its templates from the directory in which it was created, as explained in Section 2.2.2.1.) You may want to modify not only the directory's own ACLs, but also its two templates. To edit the latter, you can specify the -ic option (for the Initial Container template) or the -io option (for the Initial Object template); otherwise, you will edit the object ACL.
You can modify a directory's ACL templates from an application, assuming that you have control permission for the object, with the same combination of sec_acl_lookup() and sec_acl_replace() calls as for the object ACL. An option to these routines lets you specify which of the three possible ACLs on a directory object you want the call applied to. The ACLs themselves are in identical format.
The -e (entry) option to acl_edit can be used to make sure that you get the ACL for the specified namespace entry object, and not the ACL (if any) for the object that is referenced by the entry. This distinction has to be made clear to acl_edit because it finds the object (and hence the ACL) in question by looking it up in the namespace and binding to its ACL manager. Essentially, the -e option tells acl_edit whether it should bind to the CDS ACL manager (if the entry ACL is wanted), or to the manager responsible for the referenced object's ACL. This latter manager would be a part of the server application whose binding information the entry contained.
An example of such an ambiguous name would be a CDS clearinghouse entry, such as the cdshostname_ch entry discussed previously. With the -e option
acl_edit -e /.:/cdshostname_ch
you would edit the ACL on the namespace entry; without the -e option you would edit the ACL on the clearinghouse itself, which you presumably do not want to do.
Similarly, there is a bind_to_entry parameter by which the caller of sec_acl_bind() can indicate whether the entry object's ACL or the ACL to which the entry refers is desired. For further details on the pitfalls of binding ambiguity, see Chapter 2 of this guide.
The ACLs attached to the CDS namespace at configuration are described in Transarc DCE Administration Guide. The following ACL permissions are defined for CDS objects. The single letter in parentheses for each item represents the DCE notation for that permission. These single letters are identical to the untokenized forms returned by sec_acl_get_printstring().
This permission allows a principal to look up an object entry and view its attribute values.
This permission allows a principal to change an object's modifiable attributes, except for its ACLs.
This permission allows a principal to create new entries in a CDS directory. It is used with directory entries only.
This permission allows a principal to delete a name entry from the namespace.
This permission allows a principal to test whether an attribute of an object has a particular value, but does not permit it actually to see any of the attribute values (in other words, read permission for the object is not granted). The test permission allows an application to verify a particular CDS attribute's value without reading it.
This permission allows a principal to modify the entries in the object's ACL. The control permission is automatically granted to the creator of a CDS object.
This permission allows a principal to issue cdscp commands that control the replication of directories. It is used with directory entries only.
Detailed instructions on the mechanics of setting up ACLs on CDS objects can be found in the Transarc DCE Administration Guide.
For CDS directories, read and test permissions are sufficient to allow ordinary principals to access the directory and to read and test entries therein. Principals who you want to be able to add entries in a CDS directory should have insert permission for that directory. Entries created by the RPC NSI routines (for example, when a server exports bindings for the first time) are automatically set up with the correct permissions. However, if you are creating new CDS directories for RPC use, you should be sure to grant prospective user principals insert permission to the directory so that servers can create entries when they export their bindings. A general list of the permissions required for the various RPC NSI operations can be found in the rpc_intro(3rpc) reference page in the OSF DCE Application Development Reference, and the reference pages for the RPC NSI routines (all of whose names are in the form rpc_ns_...()) in the same manual.
Note that CDS names do not behave the same way as file system names. A principal does not have to have access to an entire entry name path in order to have access to an entry at the end of that path. For example, a principal can be granted read access to the following entry:
/.:/applications/utilities/pr2
and yet not have read access to the utilities directory itself.
The following subsections discuss the valid character sets for DCE Directory Service names as used by CDS interfaces. They also explain some characters that have special meaning and describe some restrictions and rules regarding case matching, syntax, and size limits.
The use of names in DCE often involves more than one directory service. For example, CDS interacts with either GDS or DNS to find names outside the local cell.
Figure 2-3 details the valid characters in CDS names, and the valid characters in GDS and DNS names as used by CDS interfaces.
Note: Because CDS, GDS, and DNS all have their own valid character sets and syntax rules, the best way to avoid problems is to keep names short and simple, consisting of a minimal set of characters common to all three services. The recommended set is the letters A to Z, a to z, and the digits 0 to 9. In addition to making directory service interoperations easier, use of this subset decreases the probability that users in a heterogeneous hardware and software environment will encounter problems creating and using names.
Although spaces are valid in both CDS and GDS names, a CDS simple name containing a space must be enclosed in `` '' (double quotes) when you enter it through the CDS control program. Additional interface-specific rules are documented in the modules where they apply.
| Directory Service | Character | Meaning |
|---|---|---|
| CDS | / | Separates elements of a name (simple names). |
| * | When used in the rightmost simple name of a name entered in a cdscp show or list command, acts as a wildcard, matching zero or more characters. | |
| ? | When used in the rightmost simple name of a name entered in a cdscp show or list command, acts as a wildcard, matching exactly one character. | |
| \ | Used where necessary in front of an * (asterisk), or a ? (question mark) to escape the character (indicates that the following character is not a metacharacter). | |
| GDS | / | Separates Relative Distinguished Names (RDNs). |
| , | Separates multiple attribute type/value pairs (attribute value assertions) within an RDN. | |
| = | Separates an attribute type and value in an attribute value assertion. | |
| \ | Used in front of a / (slash), a, (comma), or an = (equal sign) to escape the character (indicates that the following character is not a metacharacter). | |
| DNS | . | Separates elements of a name. |
Some metacharacters are not permitted as normal characters within a name. For example, a \ (backslash) cannot be used as anything but an escape character in GDS. You can use other metacharacters as normal characters in a name, provided that you escape them with the backslash metacharacter.
Table 2-2 summarizes major points to remember about CDS, GDS, and DNS character sets, metacharacters, restrictions, case-matching rules, internal storage of data, and ordering of elements in a name. For additional details, see the documentation for each technology.
| Characteristic | CDS | GDS | DNS |
|---|---|---|---|
| Character Set | a to z, A to Z, 0 to 9 plus space and special characters shown in Figure 2-3 | a to z, A to Z, 0 to 9 plus. :, ' + - = () ? / and space | a to z, A to Z, 0 to 9 plus. - |
| Metacharacters | / * ? \ | /, = \ | . |
| Restrictions | Simple names cannot contain a / (slash). The first simple name following the global cell name (or /.: prefix) cannot contain an = (equal sign). When entering a name as part of a cdscp show or list command, you must use a \ (backslash) to escape any * (asterisk) or ? (question mark) character in the rightmost simple name. Otherwise, the character is interpreted as a wildcard. | Relative distinguished names cannot begin or end with a / (slash). Attribute types must begin with an alphabetic character, can contain only alphanumerics, and cannot contain spaces. An alternate method of specifying attribute types is by object identifier, a sequence of digits separated by. (dots). You must use a \ (backslash) to escape a / (slash), a, (comma), and an = (equal sign) when using them as anything other than metacharacters. Multiple consecutive unescaped occurrences of / (slashes),, (commas), = (equal signs) and \ (back-slashes) are not allowed. Each attribute value assertion contains exactly one unescaped = (equal sign). | The first character must be alphabetic. The first and last characters cannot be a. (dot) or a - (dash). Cell names in DNS must contain at least one. (dot); they must be more than one level deep. |
| Case-Matching Rules | Case exact | Attribute types are matched case insensitive. The case-matching rule for an attribute value can be case exact or case insensitive, depending on the rule defined for its type at the DSA. | Case insensitive |
| Internal Representation | Case exact | Depends on the case-matching rule defined at DSA. If the rule says case insensitive, alphabetic characters are converted to all lowercase characters. Spaces are removed regardless of the case-matching rule. | Alphabetic characters are converted to all lowercase characters. |
| Ordering of Name Elements | Big endian (left to right from root to lower-level names). | Big endian (left to right from root to lower-level names). | Little endian (right to left from root to lower-level names). |
| Name Type | Maximum Size (characters) |
|---|---|
| CDS simple name (character string between two slashes) | 254 |
| CDS full name (including global or local prefix, cell name, and slashes separating simple names) | 1023 |
| GDS relative distinguished name | 64 |
| GDS distinguished name | 1024 |
| DNS relative name (character string between two dots) | 64 |
| DNS fully qualified name (sum of all relative names) | 255 |
This section describes the valid character sets for the GDS attributes.
The values of the country attributes are restricted to the ISO Alpha-2 code representation of country names. (For more information, see the Transarc DCE Administration Guide.)
The character set for all other naming attributes is the T61 graphical character set. It is described in the next section.
Table 2-4 shows the T61 graphical character set.
Note: The 1) entry in the table indicates that it is not recommended that you use the codes in Column 2, Row 3 and Column 2, Row Instead, use the appropriate code in Column A.
The administration interface supports only characters smaller than 0x7e for names. The X/Open Directory Service (XDS) Application Programming Interface (API) supports the full T61 range as indicated in the preceding table.
Some T61 alphabetical characters have a 2-byte representation. For example, a lowercase letter ``a'' with an acute accent is represented by 0xc2 (the code for an acute accent) followed by 0x61 (the code for a lowercase ``a'').
Only certain combinations of diacritical characters and basic letters are valid. They are shown in Table 2-5.
| Name | Repr. | Code | Valid Basic Letters Following |
|---|---|---|---|
| grave accent | FOO | 0xc1 | a, A, e, E, i, I, o, O, u, U |
| acute accent | FOO | 0xc2 | a,A,c,C,e,E,g,i,I,l,L,n,N,o,O,r,R, s,S,u,U,y,Y,z,Z |
| circumflex accent | ^ | 0xc3 | a,A,c,C,e,E,g,G,h,H,i,I,j,J,o,O,s,S, u,U,w,W,y,Y |
| tilde | ~ | 0xc4 | a,A,i,I,n,N,o,O,u,U |
| macron | FOO | 0xc5 | a,A,e,E,i,I,o,O,u,U |
| breve | FOO | 0xc6 | a, A, g, G, u, U |
| dot above | \(dt | 0xc7 | c,C,e,E,g,G,I,z,Z |
| umlaut | FOO | 0xc8 | a,A,e,E,i,I,o,O,u,U,y,Y |
| ring | FOO | 0xca | a, A, u, U |
| cedilla | FOO | 0xcb | c,C,G,k,K,l,L,n,N,r,R,s,S,t,T |
| double accent | " | 0xcd | o, O, u, U |
| ogonek | FOO | 0xce | a, A, e, E, i, I, u, U |
| caron | \(hc | 0xcf | c,C,d,D,e,E,l,L,n,N,r,R,s,S,t,T,z,Z |
The nonspacing underline (code 0xcc) must be followed by a Latin alphabetical character; that is, a basic letter (a to z or A to Z), or a valid diacritical combination.
Object Identifiers (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 the International Organization for Standardization (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 OID block
1.3.22
was allocated to OSF by ISO. OSF can now generate, for example, the OID
1.3.22.1.1.4
and allocate it to identify some DCE directory object. (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 Transarc DCE Administration Guide.
In summary, the procedure you should follow to create new attributes on CDS entries consists of three steps:
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.
