Zdenek Styblik writes:

My biggest concern is about numbering [OID/PEN ?]. I've requested PEN from IANA, no problem here. But how should I divide numbers to attributes? Does it matter? Can I run out of space? Do something [utterly] wrong? I just haven't seen this [numbering] explained to the last bit anywhere.

When you have been delegated an oid X, that includes all OIDs X.<anything>. You can delegate further - give X.123 to one department unit, which then owns the X.123.* OID space, and so on.

You can't run out of space, but you can make a bit of a mess of it, as we did. It's basically a matter of administration. You need to remember that you are now wearing several hats:

Presumably you wanted the OID for some project or application, but IANA gave the OID to your organization, not to your project. Maybe some other project of yours will want its own OIDs later, without worries about coordinating with your current project. If so, the first thing to do is to delegate an OID from your organization to your project. I.e. if your organization has oid X, give your project OID X.<something>. X.1, or X.12345, X.<internal project number>, whatever.

Or if your organization is bigger than that, first wearing your hat as the organization's OID admin, delegate OID X.Y to your department. Then then wearing your new hat as that department's OID admin delegate X.Y.<something> to your project.

Or if the organization is bigger still, maybe the top hats don't fit on you.

Also you can run into name conflicts with attribute/object class names from other schemas, schemas which you'll someday want to include in addition to your own schema.

So it's good practice to prefix names of schema elements (attributes, objectclass, ...) with (an abbreviation of) the name of your project or organization. That doesn't eliminate the possibility of name conflicts, but does reduce it.

Alternatively, you can reserve your schema element by registering them with IANA.

Or may be, I've just read wrong. I mean, should it be like tree structure and eg. class1 = prefix.PEN.1.X; class2 = prefix.PEN.2.X; ...; classN = prefix.PEN.N.X; ? But may be there is no "bigger" sense I'm looking for and incremental numbering (+1 per attribute) is just enough.

Right, there is no ordering. By itself, an OID just needs to be unique - LDAP doesn't care what your mapping is to attribute types, object classes, etc. Well, it's best to keep integer components in the range [0, 2**31 - a slight margin], since some apps may translate components to machine integers.

Anyway, now that your project (or application) has an OID (I'll call it Z), wearing your hat as the project's OID admin, you can start using its OIDs. Maybe just use OIDs Z.* for everything. Another common way is to use Z.1.* for attributes, Z.2.* for object classes, etc. Or for that matter, delegate a bit further first, to the particular schema you are defining.

PS: for example, I would like to add JID [jabber ID]/IM [which would hold whatever Instant Messaging string] attribute and extend InetOrgPerson with this attribute.

Avoid "extending inetOrgPerson" by modifying the existing object class definition, if that's what you mean. That invites interoperability and maintenance problems.

Create another object class which allows the new attributes. Either an 'AUXILIARY' class to be included in the objectClass attribute along with inetOrgPerson, or a 'STRUCTURAL' class - a superclass of inetOrgPerson.

# schema for project xyzzy, oid 1.3.6.1.4.1.98765.1.1:

attributeType ( 1.3.6.1.4.1.98765.1.1 NAME 'xyzzyJabberID' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ... objectClass ( 1.3.6.1.4.1.98765.2.1 NAME 'xyzzyPerson' AUXILIARY MAY ( xyzzyJabberID ) )

# ldif entry dn: uid=stybla,ou=people,dc=turnovfree,dc=net objectClass: inetOrgPerson objectClass: xyzzyPerson uid: stybla cn: ... ... xyzzyJabberID: <sorry, i don't know what jabber IDs look like>