Information:
|
This OID was wrongly defined (with a superfluous "}") in Rec. ITU-T X.660 (1993)/Amd. 1 | ISO/IEC 9834-1:1993/Amd. 1, as:
id ::= {joint-iso-itu-t registration-procedures(17) }directory-defs (2)}
When republishing the Rec. ITU-T X.660 | ISO/IEC 9834 Series, we chose to correct is as follows, in accordance with the Directory group:
id ::= {joint-iso-itu-t registration-procedures(17) module(1) directory-defs (2)}
Date: 29 Oct 2002
From: Hoyt L. Kesterson
To: DUBUISSON Olivier
Cc: Phillip Griffin, Bryan Wood, David W. Chadwick, Peter Furniss, Anthony Hodson
The ASN.1 statement causing the problem was to support the OID form of AE-title.
An AE-title was initially defined as a Rec. ITU-T X.500 distinguished name.
Some people believed that a distinguished name was too long for the Association Control Service Element (ACSE) protocol and wanted an OID form. At this time I was chairing the directory group but I had worked on both ACSE and registration authorities.
I pointed out that an OID could not be presented to the directory service to get to the entry for the application entity. I argued that the directory standard would not define how a name of the OID form could be translated to a distinguished name form. I suspect that if we were defining how to provide this service now, we would have just created an attribute in the Application Entity (AE)'s entry to hold the OID name form and then just searched for it.
In the end it was agreed that the transformation would be specified in the registration authority standards.
The definition of the translation of an AE-title-form2 name to a distinguished name (AE-title-form1) was defined in amendment 1 to ITU-T X.660. The translation is specified in change 5 of the amendment which creates new sub-clauses B.5 through B.10.
Since the directory standard was not going to specify the directory attributes, object class, and name form to represent each element of the OID as a directory relative distinguished name (attribute type, value), the registration authority document did.
The OIDs of the attributes, object class, and name form would therefore need to be rooted in the registration authority document and OID arch, not in ITU-T X.500 (ITU-T X.520).
I don't think the nameform2 was ever used (either in an ACSE implementation or whether any directory implementation supported the attribute types).
|
|
joint-iso-itu-t(2)
oidC1(0)
