Re: defining own attributes/class

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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>

-- 
Hallvard