Re: Root DSE

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

"Kurt D. Zeilenga" wrote:
> 
> At 06:37 PM 4/19/99 +0200, Julio Sánchez Fernández wrote:
> >Am I right in thinking that the schema requires an overhaul of
> >the config file?
> 
> Our schema parser (current U-Mich style specification) definitely
> needs to be updated.  We could extend the parser (ala NetscapeDS)
> to support v3ism... implement an ASN.1 schema parser... or
> use an LDIF format input.

There is not much difference between both options because I think
the biggie is parsing the string representation of the descriptions
anyway.  I had thought of something like this:

attribute ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

attribute ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )

[etc.]

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )

objectclass ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
     MAY ( searchGuide $ description ) )

[etc.]

Essentially the standard syntax, but allowing newlines for readability.

The parser would accept both old definitions and new definitions, that can
be told apart by the presence of the enclosing parentheses.  For old-style
definitions, missing fields would be stuffed with dummy data and would be
accepted as an aid during transition.  This would be assisted by structures
like these:

typedef struct Syntax {
	char * oid;
	char * description;
	...
} Syntax;

typedef struct MatchingRule {
	char * oid;
	char * name;
	char * description;
	int obsolete;  /* flag */
	int usage; /* equality, ordering, substr */
	int (*compare)(char *, char *);
	char * (*prepare)(char *);  /* To put in indices */
	Syntax * syntax;  /* What is this for? */
} MatchingRule;

typedef struct AttributeType {
	char * oid;
	char * name;  /* aliases? */
	char * description;
	int obsolete;  /* flag */
	struct AttributeType * sup;
	struct AttributeType ** subtypes;  /* For quick access */
	MatchingRule * equality;
	MatchingRule * ordering;
	MatchingRule * substr;
	Syntax * syntax;
	int single_value;  /* flag */
	int collective;  /* flag */
	int no_user_modification;  /* flag */
	int usage;  /* userApplications, ... */
} AttributeType;

typedef struct MatchingRuleUse {
	char * oid;
	char * name;
	char * description;
	int obsolete;  /* flag */
	AttributeType ** applies;
} MatchingRuleUse;

typedef struct ObjectClass {
	char * oid;
	char * name;
	char * description;
	int obsolete;  /* flag */
	struct ObjectClass ** sup;
	int kind;  /* ABSTRACT, STRUCTUTAL, AUXILIARY */
	AttributeType ** requires;
	AttributeType ** allows;
} ObjectClass;

Syntaxes are hard-wired and cannot be extended.  I think MatchingRule's
are hardwired too.  Unsure about MatchingRuleUse, it might be useful
to be able to extend them to cover new AttributeTypes.

The parser must accept without complaint duplicates in, for instance,
the attributes allowed or required.  These can happen because of
inheritance and even RFC2256 contains several cases of repeated
AttributeTypes in the very same list.  The parser may fill the entry
with data inherited from ancestors, if not, the inheritance graph will
have to be traversed during use.

There is no way with the standard syntax to have 'fax' stand as an
alias for 'facsimileTelephoneNumber' and the like.  There is an
inconsistency in our schema in that we use 'street' where the real
name is 'streetAddress', this could be catered for with aliases if
we add a way to specify them.

> I've been thinking that using LDIF for schema might work out
> nicely.  In fact, I'm thinking we can (ab)use LDIF for most
> everywhere we need to exchange information!

This is of course an option, but I think that we should deliver
the schema source in separate files: one for the standard LDAP
schema and one for every schema extension we support:  uMich,
RFC2307, etc.  Then come local additions.  Unless we have the
user fiddle with the main schema source adding classes and
attributes here and there, we would need the extended syntax
used by ldapmodify or maintenance would be difficult.  And I
think separation is a good way to keep the lineage of every
definition clearly documented.

By the way, I think we should move some of the schema parsing into
a common library that can be used by slapd, slurpd, ldif2ldbm,
ldbmcat, etc. (see openldap-bugs for a problem report with slurpd
not processing include's).

> Anyways, I see two urgent project that need volunteers:
>         * LDIF2 parser
>         * schema handling

Yeah, any takers? :-)

I have started translating schemas into the syntax I mentioned
above, checking at every step differences between what we had
and what we are supposed to have and trying to find the lineage
of every AttributeType and ObjectClass, their oids, etc.  Pointers
welcome (I have the dump of cn=schema from a Netscape server, but
I prefer to use it only for cross-check and use the original
definition if available instead).

At the very least, this will be useful anyway, translation into
LDIF would be trivial.

Julio