Re: Root DSE

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

"Kurt D. Zeilenga" wrote:
> 
>         ldap_str2objectclasses(value, &oc);
>         ldap_str2attributetypes(value, &at);
> 
> Structures for objectclasses and attributetypes, of course, would
> be needed.  Inverse routines would also be useful.

Yes, the prettyprinters used when sending this info out, like in results
for searchs on cn=schema.

>  typedef struct ldap_attributetype {
>         char *at_name;
>         char *at_desc;
>         char *at sup_oid;
>         char *at_equality_oid;
>         char *at_ordering_oid;
>         char *at_substr_oid;
>         char *at_syntax_oid;
>         int  *at_single-value; /* 0=no, 1=yes */
>  } LDAP_ATTRIBUTE_TYPE;

This thing of putting prefixes on struct or union fields is very unlike
me, but I will comply, after all, most of the code follows that style...
Flashbacks of Hungarian notation or, gasp, FORTRAN II...

> In the future, these will NOT be hardwired... but will likely
> be only statically extensible.  That is, slapd could be extended
> at startup with modules (which would be dynamically loaded) but
> would not allow on-the-fly extensibility.

Point taken.  You know what I mean anyway.

> >There is no way with the standard syntax to have 'fax' stand as an
> >alias for 'facsimileTelephoneNumber' and the like.
> 
> I'm not sure how best to handle aliases.  However, no matter how
> we handle aliases, it should be formalized.  That is, we should
> document (via an informational rfc) our aliasing handling.  We
> should investigate mechnanims for publishing this schema
> information.

I blush.  I did not read the syntax carefully enough.  From RFC2252,
section 4.2:

      AttributeTypeDescription = "(" whsp
            numericoid whsp              ; AttributeType identifier
          [ "NAME" qdescrs ]             ; name used in AttributeType
	[etc.]

And from 4.1:

    qdstrings       = qdstring / ( whsp "(" qdstringlist ")" whsp )

Scrap all that, we have a standard syntax for alias definition.  Notice,
however, that NAME is optional.

> Why LDIF?  Using LDIF to specify configuration information lends
> itself to placing configuration information in the directory which
> lends itself to dynamic modification...

Well, yes, I think I agree and yet..., well I don't know.

It would be nice to have ACLs stored in the directory.  Moreover, do you
know what I would kill to have?  Stored perl procedures...  That get
called on modifications to enforce policy, referential integrity, etc.

> Great!  I suggest separating parsing of LDAPv3 schema
> information for it's use in slapd as suggested above.

I guess you want this because some tools don't need the whole syntax
bang, right?  Anyway, I think we should always remember that little
thing we have there called ldapd, we tend to disregard it as if some
embarrassing relative.  Probably not many of us use it.  I don't know
how ldapd could make use of this.  Well, of course, if any component
needs the oids, it's got to be it...

Julio