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

Part 3 – OID tree structure, notations and encodings

– each arc should be allowed to have additional (possibly multiple) "secondary identifiers" in human
readable form.
It was the original intent that secondary identifiers should also be unambiguous, but for a variety of reasons,
this was often violated, and the requirement for this was withdrawn, largely because the unambiguous
number is always present in encodings, and (for all branches except the top-most) in human-readable
notation.

The secondary identifiers were restricted to the Latin alphabet, and were required (for historical ASN.1
reasons) to start with a lower-case letter and to contain only numbers, letters, and hyphens. In the early
2000s, the dependency on the Latin alphabet was seen to be too restrictive and ASCII was replaced by the
more flexible Unicode (see clause 13 for a discussion of Unicode labels) for naming arcs.

Unicode labels can be used to provide unambiguous identification of branches from a node using an
arbitrarily long string of (almost) any Unicode character (and hence any of the global languages). With the
introduction of Unicode labels, the OID tree is now more correctly referred to as "the International OID
tree". Moreover, a path through the tree (leading to an intermediate or to a leaf node) can now be identified
by a string of Unicode labels without any use of the numerical value for an arc (although use of the
numerical value is always allowed). This is the so-called OID-IRI form of identification (see clause 9.4), and
is standardized in the ASN.1 texts.

In the original work, all arcs from a node went to nodes at the next level; there was no concept of what
computer theorists would call "long arcs". Long arcs have been introduced at the same time as Unicode
labels (see clauses 6.4 and 15). Long arcs allow a node which is not immediately subordinate to a parent
node, but could be several levels below (but still subordinate to it). All normal arcs still have an
unambiguous integer value, and all nodes can be reached by a string of these values, but long arcs can be
identified only with Unicode labels, and do not have any integer value. Long arcs from the root provide a
more human-friendly way of directly identifying nodes two levels down, using the names of organizations
responsible for sub-trees beneath those nodes.

8 The high-level arcs and the naming of arcs
In the 1980s' discussions, it was felt that the only bodies that
would wish to make allocations of OIDs were (what was then Author's remarks:
called) CCITT (later to become ITU-T) and ISO. This gave us
arc 0 (ccitt) and arc 1 (iso) from the root. ISO and IEC share What standards organizations might
a common number space for numbering standards, some of want OIDs? The 1980s answer was
which are joint ISO/IEC standards, and so no independent only CCITT, ISO, and Joint-ISO-
provision has been made for IEC. CCITT allocations. This determined
the top-level arcs of the OID tree,
There was early recognition of the need for common sub- which with minor tweaking is what
allocations made within ITU-T Recommendations and we have today at the top-level.
ISO/IEC International Standards that were common text, or
technically aligned text, so a third arc called (originally)
joint-iso-ccitt was added as arc 2.

But then the first major name change occurred in 1993 when CCITT was renamed as ITU-T. Fortunately, as
the encoding did not use the names on the arcs (only the human-readable value notation), itu-t was added
as a synonym on arc 0, and joint-iso-itu-t as a synonym on arc 2, with use of ccitt in both cases
allowed but deprecated in all new publications. There are probably few publications today that contain the
historic ccitt.

11