[Top] [All Lists]

Re: consisten use of top-level oid branch name joint-iso-itu-t(2)

2008-12-28 05:27:10


There are several comments to be made. Forgive me for being verbose, but I think that in this area, brief replies can so easily be misunderstood.

1)    First, forget the old stuff with identifiers (that is the old and
correct term) for names on arcs of the OID tree.  They were always (and
still are) ASCII text, with an initial lower-case letter.  Originally,
they were expected to be unique (but were never carried in protocol,
only in human value notation).  Then later, it was recognised that
company names changed (due to take-over, merger, etc, and that they wanted to use a different name for their arc (but not to change the numerical value). It was then (circa 1992) that they should NOT be regarded as unique, and that variants would be allowed (this brought the Standard into line with existing practice). About the same time, CCITT changed its name, and synonyms were formally assigned for some top-level arcs - but still
restricted to ASCII characters, starting with a lower case letter.
**Forget that stuff - it is historical! But, of course, still in use.**

2) Formally, an arc now has an always unique and unambiguous numerical value (as before); the old not-necessarily-unique-or-unambiguous identifiers (as before); but also has one or more Unicode labels (any - more-or-less - Unicode characters) that is required to be unambiguous from the superior node, but not necessarily unique (multiple Unicode labels are allowed on an arc to allow for different language variants). This was much discussed and fought over, but was eventually agreed as the best solution, but with some people still dissenting, and wanting only one (unique) Unicode label on an arc.

3) As part of this extension, it was recognised that the limitation to three top-level arcs (itu-t(0), iso(1), and joint-iso-itu-t(2)) was too limiting. Fortunately, arc 2 had already been used to provide allocations for other SDOs, and provided the x is less than 47, the OID {2, x} encodes into a single octet. We now restrict the allocation of arcs {2, x} to organisations that need the single octet encoding, but there are still quite a few x values left for future allocation. For encoding purposes, the top two levels are effectively a single set of top-level arcs, encoding into a single octet, provided x is less than 47 for arc 2, with similar restrictions on the arcs beneath arcs 0 and 1.

4) When Unicode labels were introduced, the concept of "long arcs" were included specifically for use at the top level. So it is now possible for long arcs to be allocated, with Unicode labels (but no numeric identifier) directly from the root to an arc beneath arc 2, and it is now common practice to allocate a long arc whenever an arc is allocated beneath arc 2 for any major organisation or SDO.

5) Finally, there was recognition of the problem of mapping a sequence of Unicode labels (representing a set of arcs) into a canonical list of integers for the numerical values of those arcs (in the case of a long arc, a Unicode label would map into - typically - two integers, for example 2.13). This gave rise to "work in progress" on an "OID resolution process". You will recognise that this is very much what the ubiquitous DNS service provides - a mapping from a set of names (domain names, little-endian order in the set) to a set of numbers (IP addresses, big-endian order in the set). DNS look-up is universally supported, and well-established, and the current hope/intent is to be able to do OID resolution using the DNS service, but discussions are still in progress on this. The alternative of an X.500 base for OID resolution has also been much discussed, and not abandonned. But deployment of X.500 look-up software is not as ubiquitous as DNS resolution software and databases. It may be that at the stardardisation level, we will see two resolution services documented - DNS-based and X.500-based. But it is too early to comment on that.

6) Now we come to IRI registration of the "oid" scheme, which is what the Internet Draft is concerned with. This is not essential to support these developments, but was a target from the start of the work. The sequence of Unicode labels on a path from the root to a node is undoubtedly, in plain English language terms, an internationalised resource identifier. So registration of an IRI "oid" scheme with IANA was always a target for the work. It was felt that the Standard should be in place before the registration was attempted. So we now have an Internet Draft under review with uri-review, in the hope that this can be "massaged" into a form that would allow us to proceed with the formal IANA registration of the "oid" IRI scheme in the not too distant future.

I hope this has gone some way towards answering your questions.

John L

Tom Gindin wrote:


This draft is interesting and useful for some purposes, but I don't see how it addresses the case where a high-level arc (beyond the control of the development organization) is renamed. Since that's precisely the case we are discussing here (although the change took place quite a while ago and it's reasonable to expect people to adjust), it doesn't actually seem to help us. Am I missing something? Also, unless I have missed something, there are only three top-level arcs defined for OID's and they all now have names.

               Tom Gindin

John Larmouth <j(_dot_)larmouth(_at_)btinternet(_dot_)com> Sent by: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org
12/22/2008 10:48 AM
Please respond to

Alfred � <ah(_at_)tr-sys(_dot_)de>
turners(_at_)ieca(_dot_)com, ietf-pkix(_at_)imc(_dot_)org, 
Re: consisten use of top-level oid branch name joint-iso-itu-t(2)


The synonyms were introduced some time ago, and, indeed, the names are non-normative, and may not even be unambiguous. Only the numbers matter in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. Unicode labels with names similar to the old ASCII names have been assigned for many of the top-level arcs, and more will be added over time.

The OID_IRI type is related to (but not dependent on) the application for an "oid" IRI scheme, but for consistency this is desired. See I-D draft-larmouth-oid-iri-00.

John L

Alfred � wrote: Folks / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

   joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

   joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version  joint-iso-itu-t(2)  be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

Kind regards,

  Prof John Larmouth
  Larmouth T&PDS Ltd
  (Training and Protocol Design Services Ltd)
  1 Blueberry Road
  WA14 3LS
  Tel: +44 161 928 1605