Re: help: understanding objectclasses and schemas

[Julio Sánchez Fernández <j_sanchez@stl.es>]

Martin Strohbach wrote:
> 
> Hello everybody!
> 
> It seems to me that the concept of objectclasses and schemas is not clear to me,

I share some of your concerns.

> so I would like to ask some questions:
> 
> As far as I understood schemas, they define what attributes an entry _must_ and
> _is allowed_ to have. I am now in the situation that I want to deploy a ldap
> server that is X.500 conform, for later (if at all) integration with X.500
> directories. But I cannot understand why I should recognize the objectclass
> "person" for example: if objectclasses only define what attributes a entry must
> and is allowed to have, why isn't it then sufficient to have an objectclass
> "myperson" that is identical with the X.500 objectclass "person" and allows or
> requires other attributes? So it would be sufficient to add
> "objectclass:myperson" instead of "objectclass:person" _and_
> "objectclass:myperson".

According to the X.5xx draft documents I have around, it is illegal to have
both, since both are structural classes and you can only have one.

On the other hand, in the RFCs for LDAP v3, an object has one or more
structural object classes and when adding a class, superior classes are
"implicitly added" if I remember the wording correctly.

It does not really make a difference for schema compliance checks, since the
subclass will accept or require the same list of attributes whether the
superior is present or not.  However, it changes the result of a search
with filter (objectclass=person).  And then comes the question of what
values should be returned for a search that requests that attribute type.
Should all (explicit and implicit) values be returned?  And what if I
now delete objectclass myperson from the entry?  Does the implicitly
added person go away too?

I think that in the long run, subclassing has to be something especially
taken care of, otherwise inconsistencies will abound and conflicts with
X.500 will happen.  My own CGIs for directory management I use here are
a mess already trying to maintain coherence with objectclass values on
entries.

> So the next qusetion is obvious: is it possibleto subclass schemas. I think I
> read about it, but I can't remember where.

I don't see why not.  Well, there is a conflict with the models again.  If
only one structural class is permitted (and the others are implicit), and
you subclass subschema, then it is not there unless some logic in the line
of what I described above is implemented.  So, it seems some thinking
is needed here and you are probably better off for the time being with
an auxiliary class with the additional attributes you need.

> Finally rfc2256 made me think of objectclass "top" and subschema. What is
> objectclass subschema? rfc2256 says: servers MUST recognize this objectclass. By
> the way: what does it mean "a server must recognize a objectclass".

That they "know" it.  That it allows that value for the objectClass attribute
type and that it is listed in the schema.

> Does this
> mean that each entry has to have such an attribute?

Not at all.  I think you are getting mixed the subschemaSubentry attribute
type with the "subschema" value in an objectClass attribute.  IIRC, any entry
may contain an attribute type subschemaSubentry of syntax Distinguished Name
that points to an entry with objectclass subschema.  But the RFCs don't require
that you can set it, not even through server configuration.  So it may never
appear in servers that only use one schema.  I think OpenLDAP is nowhere close
to there, though it might provide the attribute type in all entries with the
same value (CN=SCHEMA, to be precise).

> As I saw in many postings in this newsgroups people seem always to have an
> attribute called "objectclass:top" as rfc2256 requires. But this objectclass
> seems perfectcly strange to me: it requires nothing but objectclass and that is
> always right, if the entry is of objectclass "top" (for I have to add the
> attribute objectclass:top). So the next conclusion would be: why require the
> attribute objectclass at all: either it is always included or it is not and then
> no schema can require it, because the entry belongs to no objectclass.

I see your dilemma, but it is disambiguated by RFC2251 that literally says:
"Every entry MUST have an objectClass attribute".

Julio