From RFC4524 the following objectclasses are not defined correctly:

cRLDistributionPoint

Note that much of 4524 is not established in the product schema.

(In reply to comment #1)
> From RFC4524 the following objectclasses are not defined correctly:
> cRLDistributionPoint
> Note that much of 4524 is not established in the product schema.

Note that the above thet should have referred to RFC4523, not 4524.

We do not want to make any potentially invasive modifications to any default schema in an update release.  We hope to update most of the standard schema to use the definitions from the most recent RFCs in the 9.0 release.

Is there a smaller specific issue that you would like addressed in 8.1 related to the schema you referenced above?  The only difference I notice in the definitions of domainRelatedObject and simpleSecurityObject between DS and RFC4524 is that the RFC has the AUXILIARY keyword present.  Is this causing a problem that requires this to be addressed in DS 8.1?

Yes, simpleSecurityObject and domainReleatedObject are particular problems for an application I am working on.  It would be nice if these two could be set as AUXILIARY, as is mentioned in the schema, but I understand if this is considered to risky of a change at this time, though I kind of doubt there are users of this schema that are relying on it being structural.

I think it is safe to add the AUXILIARY keyword to these two definitions.  I would like to hold off on other updates until 9.0.  I'll open a new bug for the more major update and use this bug for simpleSecurityObject and domainReleatedObject.

Opened bug 479753 to deal with updating core schema to match the current RFCs in the 9.0 version.

Created attachment 328793 [details]
CVS Diffs

This adds the AUXILIARY keyword to the definitions of the domainRelatedObject and simpleSecurityObject objectclasses.

Checked into ldapserver (HEAD).  Thanks to Noriko for her review!

Checking in ldap/schema/28pilot.ldif;
/cvs/dirsec/ldapserver/ldap/schema/28pilot.ldif,v  <--  28pilot.ldif
new revision: 1.5; previous revision: 1.4
done

Please add steps to verify.  Currently:

[root@dhcp-100-2-17 schema]# cat *.ldif | grep simpleSecurityObject
objectClasses: ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' DESC 'Standard LDAP objectclass' SUP top AUXILIARY MUST ( userPassword ) X-ORIGIN 'RFC 1274' )
[root@dhcp-100-2-17 schema]# cat *.ldif | grep domainReleatedObject
[root@dhcp-100-2-17 schema]#

The simpleSecurityDefinition looks good.  You should just be looking for the "AUXILIARY" keyword to be present.

Your grep for domainRelatedObject has a type in it, but you should find that it also has the "AUXILIARY" keyword present in it's definition.

d'oh

[root@dhcp-100-2-17 schema]# cat *.ldif | grep domainRelatedObject
objectClasses: ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' DESC 'Standard LDAP objectclass' SUP top AUXILIARY MUST ( associatedDomain ) X-ORIGIN 'RFC 1274' )


Fix verified - RHEL5 DS 8.1

Another possible problem is with homeTelephoneNumber and homePhone attributes.

RFC 1274 defines the homeTelephoneNumber attribute:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9.3.16.  Home Telephone Number

   The Home Telephone Number attribute type specifies a home telephone
   number associated with a person.  Attribute values should follow the
   agreed format for international telephone numbers: i.e., "+44 71 123
   4567".

     homeTelephoneNumber ATTRIBUTE
         WITH ATTRIBUTE-SYNTAX
             telephoneNumberSyntax
     ::= {pilotAttributeType 20}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The OpenLDAP schema defines both attributes:
/etc/openldap/schema/cosine.schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
attributetype ( 0.9.2342.19200300.100.1.20
        NAME ( 'homePhone' 'homeTelephoneNumber' )
        DESC 'RFC1274: home telephone number'
        EQUALITY telephoneNumberMatch
        SUBSTR telephoneNumberSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But DS 8.0.5-3.el5dsrv only defines homePhone"
/etc/dirsrv/schema/01common.ldif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(In reply to comment #13)
> Another possible problem is with homeTelephoneNumber and homePhone attributes.
> [...]

Since this is a "verified" bug, I think you'd better open a new bug for the attribute.  The fix would be very simple like this...
cvs diff 01common.ldif
Index: 01common.ldif
===================================================================
RCS file: /cvs/dirsec/ldapserver/ldap/schema/01common.ldif,v
retrieving revision 1.4
diff -r1.4 01common.ldif
99c99
< attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' )
---
> attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME ( 'homePhone' 'homeTelephoneNumber' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' )

(In reply to comment #14)
> Since this is a "verified" bug, I think you'd better open a new bug for the
> attribute. 

See bug 492562

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html