[Date Prev][Date Next]
Re: New schema
At 09:43 AM 4/26/99 +0200, Julio Sánchez Fernández wrote:
>Tonight (CET) I will start committing parts of the new schema to the repository.
I'd very much like to see
>I must say this has become a *very* frustrating process. Despite what one
>might think, RFC1274 does *not* describe the object classes and attribute
>types that we had with names including 'pilot' and such. They are very
>similar, but not the same. The definitions Netscape DS use are very similar to
>ours, with very small deviations. I can only deduce that the pilot schema
>evolved after RFC1274 and Umich, and later Netscape, tracked that evolution.
>That, or Umich literally made up the changes and were inherited by Netscape.
>Anyway, I have been unable to find updated COSINE pilot schemas that reflect
>those changes. As a consequence, some objects from the pilot do not have
>OIDs known to me. It is little consolation that Netscape does not have them
I'm sure someone on LDAPext would know.
>On the other hand, I have found two large blocks of definitions that do not
>come from RFCs as far as I know. One was expected: the Umich definitions.
We should move away from Umich in favor of newer, better defined, schema
items. We should be able to eliminate our dependencies upon these items.
>The second is something I did not even knew was there: US-centric things,
>many of which have names that include either 'nadf' or 'fips'. I do not
>know where they come from. I am desperate.
If we don't need these. I recommend we isolate them so that they can
be removed from the distribution before release.
>Well, since renaming files in CVS is messy, I will announce what files I will
>create tonight so that objections can be raised before I do. These files will
>be added to servers/slapd:
How about we add them to servers/slapd/schema?
> - slapd.std.schema: Definitions from RFC2252 and RFC2256 in the new
> - slapd.pilot.schema: Same for RFC1274 ammended as deemed necessary,
> this is incomplete and needs revision.
> - slapd.umich.schema: Same for Umich definitions, when available
> - slapd.misc.schema: Same for assorted definitions, like RFC2247,
> RFC2377 and, possibly, RFC2307. In general, final destination
> for all definitions not included in other files.
> - slapd.other.schema: Temporary file in the old format for all
> definitions for which adequate ASN.1 or RFC2252-style definitions
> are not known. Hopefully, this file will go away.
I'm am not sure how best to organize the information in files.
I do think we should separate items by source. Hence, I think
we should have a separate file per source:
Standard track RFCs:
rfc2256.schema (x500 user)
rfc2247.schema (dir-enabled apps, info)
rfc2307.schema (nis, experimental)
rfc2377.schema (internet naming)
inetorgperson.schema (latest draft, optional)
rfc1274.schema (rfc1274 items)
rfc1274++.schema (enhanced rfc1274 items)
ol-slapd.schema (OpenLDAP slapd items)
ol-APPLICATION.schema (OpenLDAP schema for 'APPLICATION')
umich.schema (umich items)
deprecated.schema (deprecated schema items)
OpenLDAP could, by default, install all schema files in the
$sharedir/openldap (ie: /usr/local/share/openldap/schema).
We can create a master.schema file that looks like:
# master schema file for OpenLDAP slapd
# include %SCHEMA%/umich.schema
# include %SCHEMA%/deprecated.schema
Of course, an default installed schema should be a subset
of the above. I think we should include schema only as required
by standard or by software within the distribution. Software
in the distribution should be updated to use latest IESG/IETF
defined schema items.
RFC1274 items concern me greatly. It sounds like the RFC
needs to be updated. This would be a good topic for LDAPext.
We probably should steer widely around RFC1274 as possible.
Hence, maybe rfc1274++.schema should be limited to only those
items to which we really need. Hence:
rfc1274.schema (as defined in the RFC)
rfc1274++.schema (common use 'pilot' items)
rfc1274opt.schema (optional, common use 'pilot' items)
We should consider moving towards better, well-defined (RFC or near
lastcall IETF draft) replacement schema items (where they exist).
- New schema
- From: Julio Sánchez Fernández <email@example.com>