Front cover - IBM Redbooks

OIDs are intended to be globally unique. They are formed by taking a unique
numeric string (for example, 1.3.4.7.4.17) and adding additional digits in a unique
fashion (such as 1.3.4.7.4.17.1, 1.3.4.7.4.17.2, 1.3.4.7.4.17.3, and so forth). An
organization may acquire a “branch” from some root or vertex in the OID tree.
Such a branch is more commonly referred to as an arc (in the previous example,
it was 1.3.4.7.4.17). The organization may then extend the arc (with subarcs) as
shown, to create additional OIDs and arcs. We have no idea why the terminology
for the OID tree uses the words “vertex” and “arc” instead of “root” and “branch”
as is more commonly used in LDAP and its X.500 heritage.
If you have an LDAP directory that is a derivative of the original University of
Michigan LDAP code (many open source and commercial LDAP directory
servers are), your object class definitions are contained in files ending with “.oc”.
For those of you wondering where the “eDominoAccount” object class definition
is located, it is of course specific to IBM Directory Server. Note that IBM-specific
OIDs begin with the arc 1.3.18.0.2; this is a unique private enterprise number
that has been assigned to IBM. The number breaks down as follows:
1 (ISO-assigned OID)
1.3 (ISO-identified organization)
1.3.18 (IBM)
1.3.18.0 (IBM Objects)
1.3.18.0.2 (IBM Distributed Directory)
As you may have guessed, the “dot notation” as first used by the IETF for IP
addresses was adopted for OIDs to keep things simple. However, unlike IP
addresses, there is no limit to the length of an OID.
If your organization must define your own attributes for use within your internal
directories, you should consider obtaining your own private enterprise number
arc to identify these attributes. We do not recommend that you “make up” your
own numbers, as you will probably not be able to interoperate with other
organizations (or some vendor’s LDAP products). This is not to say obtaining
your own OID arc from ISO, IANA, or some other authority to define your own
object classes and attributes will guarantee interoperability. But it will prevent you
from using OIDs that have already been assigned to or by someone else. OIDs
are only used for “equality-matching.” That is, two objects (for example, directory
attributes or certificate policies) are considered to be the same if they have
exactly the same OID. There are no implied navigational or hierarchical
capabilities with OIDs (unlike IP addresses, for example); given an OID, one can
not readily find out who owns the OID, related OIDs, and so forth. OIDs exist to
provide a unique identifier. There is nothing to stop two organizations from
picking the same identical names for objects that they manage; however, the
OIDs will be unique assuming they were assigned from legitimate arc numbers.
Chapter 8. Directory strategies 319