Page 24 - 2010 Object identifiers (OIDs) and their registration authorities

Object identifiers (OIDs) and their registration authorities

9.2 Traditional notation

The original notation for specifying an OID was defined in 1986 as the value notation for the ASN.1 OBJECT
IDENTIFIER type.
It was (and still is) extensively used, and is well-known to most people.
Let us start with three more examples, similar to the ones used earlier, in their most common forms:

{iso identified-organization dod(6) internet(1) snmpV2(6) snmpModules(3)}
{itu-t recommendation h 323 main(0) generic-capabilities(0)}
{joint-iso-itu-t country(16) ir(364)}
They all start with an opening curly bracket "{" and end with a closing curly bracket "}". Within this there
are identifications of the arcs (separated by spaces) from the root that leads to the node that is being
identified, determining a path through the OID tree (the object identifier) to the node.
Notice that each component after the first few always contains a number as well as a name, but a number can
also be included (in parentheses), so we would then get (less commonly used, but more explicitly identifying
the arcs):

{iso(1) identified-organization(3) dod(6) internet(1) snmpV2(6) snmpModules(3)}

{itu-t(0) recommendation(0) h(8) 323 main(0) generic-capabilities(0)}
{joint-iso-itu-t(2) country(16) ir(364)}
Both forms are used in published standards, but the inclusion of the number in parenthesis is now
recommended for all new specifications by the 2008 version of [b-ITU-T X.660].
The original philosophy behind the permitted omission of numbers for the top few arcs was that the
secondary identifiers for high-level arcs are formally defined in ITU-T Recommendations or ISO
International Standards, so the number should not be required. For lower-level arcs, it has always been
mandatory to include the number (typically in parentheses).
Another form was also permitted (and still is), but has been almost never used after the 1980s, as it is not
exactly human-friendly (!), but it is close to the actual encoding for machines, and carries only the primary
integer values of the arcs:

{1 3 6 1 6 3}
{0 0 8 323 0 0}
{2 16 364}

The rules are that every object identifier component (arc identification) has to identify the primary integer
value. For the top-level components in Table 1, it can do that by using the additional secondary identifier
only, as in some of the examples above, but the 2008 version of [b-ITU-T X.660] recommends that the
parenthetical primary integer value also be included when there are multiple secondary identifiers. Generally,
it should now always be included (in parentheses) in new specifications.

It is important to note that the secondary identifier itu-r for the arc from the root to 0 is not in Table 1. The
intent was for the omission of the primary integer value to be permitted only for secondary values that were
included in the original specifications, so itu-t can be used without a number for the top-level arc zero, but
itu-r has to be shown as itu-r(0). This decision was taken to avoid implementation software upgrades.

14