Critique my Initial Corporate Schema

[dannyman <dannyman@toldme.com>]

:)  I am a newbie.

That doesn't mean that I shall charge forth in to an OpenLDAP implementation,
replete with a customized schema, migrating it from Netscape Directory Server
to a world where I feed ActiveDirectory based on my own little rational
OpenLDAP world ...

Please critique my schema.  Here are some of my concerns:

Note our base OID in the attached document, as assigned by IANA.  Note I
assign the first part to MIBs, and only dabble with Corporate LDAP at .2.1.

Anyone can explain to me difference between STRUCTURAL and AUXILIARY object
classes?  I think I understood once but I lost my reference.

Originally, I was thinking tellmeIMUser could be a seperate (auxiliary?)
object class that could be applied to a tellmePerson, or other DN in the
directory, say a vendor organizational unit, but then I thought that I might
as well just make them optional to tellmePerson.  Reduces confusion, neh?

Okay, would someone dole out the OIDs in a way other than:
# 1.3.6.1.4.1.8580.2.1.1 - Attribute Types
# 1.3.6.1.4.1.8580.2.1.2 - Object Classes

I based it on the OpenLDAP administrators guide, but then I was thinking maybe
I prefer to define it by rational organization of objectClass -> attributeType
(which does not dictate that these attributeTypes are bound to the
objectClass)

2.1.1 - tellmeUser
2.1.1.1 - tellmePagerEmail
2.1.2 - tellmeIMUser
2.1.2.1 - tellmeAIMID
2.1.2.2 - tellmeICQID
2.1.2.3 - tellmeMSNID
2.1.2.4 - tellmeYahooID

Thanks. :)

-danny

-- 
http://dannyman.toldme.com/

# Tellme Networks LDAP Schema
#
# Base OID: 1.3.6.1.4.1.8580
#
# So, I'll do it this way:
# 1.3.6.1.4.1.8580.1 - SNMP MIBs
# 1.3.6.1.4.1.8580.2 - LDAP OIDs
# 1.3.6.1.4.1.8580.2.1 - Corporate Operations LDAP OIDs
# 1.3.6.1.4.1.8580.2.1.1 - Attribute Types
# 1.3.6.1.4.1.8580.2.1.2 - Object Classes
# 1.3.6.1.4.1.8580.2.1.2.1 - tellmePerson Object Class
# 1.3.6.1.4.1.8580.2.1.1.1.1 tellmePagerEmail
# 1.3.6.1.4.1.8580.2.1.2.2 - tellmeIMUser Object Class
# 1.3.6.1.4.1.8580.2.1.1.2.1 tellmeAIMID
# 1.3.6.1.4.1.8580.2.1.1.2.2 tellmeICQID
# 1.3.6.1.4.1.8580.2.1.1.2.3 tellmeMSNID
# 1.3.6.1.4.1.8580.2.1.1.2.4 tellmeYahooID

# All our employee entries will be of this objectClass.  In being derived from
# inetOrgPerson, we inhereit everything from inetOrgPerson,
# organizationalPerson, person, and top.
objectClass ( 1.3.6.1.4.1.8580.2.1.2.1 NAME 'tellmePerson'
	DESC 'Person employed by Tellme Networks, Inc.'
	SUP inetOrgPerson
	MAY ( tellmePagerEmail $
		tellmeAIMID $ tellmeICQID $ tellmeMSNID $ tellmeYahooID ) )

attributetype ( 1.3.6.1.4.1.8580.2.1.1.1 NAME 'tellmePagerEmail'
	DESC 'E-mail address of text pager.'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # Based on 'mail'

# We can re-use this objectClass in say, a vendor-directory type of context.
# Actually, I think this thing is wholly superfluous ...
objectClass ( 1.3.6.1.4.1.8580.2.1.2.2 NAME 'tellmeIMUser'
	DESC 'User of some Instant Messenger product.'
	SUP person
	MAY ( tellmeAIMID $ tellmeICQID $ tellmeMSNID $ tellmeYahooID ) )

attributetype ( 1.3.6.1.4.1.8580.2.1.2.1 NAME 'tellmeAIMID'
	DESC 'ID for AOL Instant Messenger'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) # Based on 'name'

attributetype ( 1.3.6.1.4.1.8580.2.1.2.2 NAME 'tellmeICQID'
	DESC 'ID for ICQ Instant Messenger'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) # Based on 'name'

attributetype ( 1.3.6.1.4.1.8580.2.1.2.3 NAME 'tellmeMSNID'
	DESC 'ID for MSN Instant Messenger'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) # Based on 'name'

attributetype ( 1.3.6.1.4.1.8580.2.1.2.4 NAME 'tellmeYahooID'
	DESC 'ID for Yahoo Instant Messenger'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) # Based on 'name'