ITU-T and ISO have a recommended schema: a list of attribute types and object
classes, which are published as X.520 and X.521.
RFC 1274 suggests an extension to this for use in the COSINE and Internet
X.500 pilots. As well as indicating support for the standard object classes
and attributes, a large number of generally useful object classes and
attributes are also defined.
LDAP servers are generally expected to support these schema defined in
X.520(1988), X.521(1988) and RFC 1274.
> Is there a standard set of attributes for object classes like PERSON and
> ORGANIZTION?
Yes, this is defined in X.521. The list from X.521(1988) is present in
Appendix C of RFC 1274.
> If you want to add a new ATTRIBUTE to an object class do you do it through a
> standards committee?
Normally one would define a subclass of an existing class. The new subclass
would permit this additional attribute. For example, RFC 1274 defines an
object class pilotPerson, which is a subclass of person. All of the aspects
of person are present in pilotPerson, and in addition objects of class
pilotPerson can have the attributes listed in pilotPerson: roomNumber etc.
Defining a new class as a subclass of an existing class does not require a
modification to the existing class and so would not require a standards
committee blessing. Note that implementations will not recognize your new
object classes and attributes unless they are in some way configured to
support them.
> What about local only ATTRIBUTEs?
Yes, the procedure would be something like:
- Get an OBJECT IDENTIFIER assigned to your local organization. Object
identifiers (called enterprise numbers) are currently available for free
from IANA. For example, I have object identifier enterprises.1466.
Every object identifier should be uniquely used.
- Define the attribute, such as "phoneExtension", and assign it an object
identifier underneath that of your organization, such as
enterprises.1466.1. Identify the syntax for that attribute. While the
syntax may be an arbitrary ASN.1 data type, it is often best to use a
syntax which is already being used so that it would be easier to add
support for this attribute in your deployment. This example attribute
would probably have a string syntax such as "NumericString".
- Define an object class to permit this attribute to be present. For
example,
personWithExtension OBJECT-CLASS ::= {
SUBCLASS OF { person }
MAY CONTAIN { phoneExtension }
ID { enterprises 1466 2 } }
- Configure your clients and servers to recognize the new attribute and
object class definitions. This is often done through editing of "oidtable"
files or subschema entries.
- When creating your entries (such as through an Add operation or bulkload),
include the personWithExtension value in the objectClass attribute of each
entry, which will permit the phoneExtension attribute to also be present.
> Is there an 'official' repository of current DIT design standards?
I do not know of one, but you might wish to read RFC 1617 "Naming and
Structuring Guidelines for X.500 Directory Pilots".
RFC 1943 "Building an X.500 Directory Service in the US" and 1803
"Recommendations for an X.500 Production Directory Service" may also be of
interest.
Hope this helps,
Mark Wahl