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

From: Alfred Hönes <[email-masked]>
Date: Mon, 22 Dec 2008 13:56:04 +0100 (MEZ)

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.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Dec 2008 08:33:51 -0500

Alfred:

This is a result of the name change from CCITT to ITU-T.  So, 
different documents use different names depending on when they were 
published.  The bits on the wire are not impacted, so I have never 
worried about it.

Russ

---

From: John Larmouth <[email-masked]>
Date: Mon, 22 Dec 2008 15:48:10 +0000

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

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Design Services Ltd)
   1 Blueberry Road                     
   Bowdon                               [email-masked]
   Altrincham
   Cheshire
   WA14 3LS                 
   England
   Tel: +44 161 928 1605

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Dec 2008 08:50:47 -0800

At 3:48 PM +0000 12/22/08, John Larmouth wrote:
>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. 

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.

Paging Peter Gutmann....

--Paul Hoffman, Director
--VPN Consortium

---

From: John Larmouth <[email-masked]>
Date: Tue, 23 Dec 2008 11:12:12 +0000

Please note my use of "if desired" below.  This presents an opportunity, 
not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or 
S/MIME (and may well never be), nor presented to them.  However, unless 
or until the "oid" IRI format is accepted by URI-review, it would be 
premature for PKIX or SMIME to even consider it.

John L

---

From: Tom Gindin <[email-masked]>
Date: Wed, 24 Dec 2008 14:15:17 -0500

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 <[email-masked]> 
Sent by: [email-masked]
12/22/2008 10:48 AM
Please respond to
[email-masked]

To
Alfred � <[email-masked]>
cc
[email-masked], [email-masked], [email-masked]
Subject
Re: consisten use of top-level oid branch name joint-iso-itu-t(2)

Alfred,

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: 

    joint-iso-itu-t(2) ,

    joint-iso-ccitt(2) .

Kind regards,
  Alfred.

---

From: John Larmouth <[email-masked]>
Date: Sun, 28 Dec 2008 10:05:54 +0000

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