|
Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
2008-12-28 05:27:10
Tom,
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:
John:
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
j(_dot_)larmouth(_at_)btinternet(_dot_)com
To
Alfred � <ah(_at_)tr-sys(_dot_)de>
cc
turners(_at_)ieca(_dot_)com, ietf-pkix(_at_)imc(_dot_)org,
ietf-smime(_at_)imc(_dot_)org
Subject
Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
Alfred,
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,
Alfred.
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon
j(_dot_)larmouth(_at_)btinternet(_dot_)com
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605
|
|