directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [SchemaService]
Date Fri, 19 Jan 2007 23:42:23 GMT
Hi Stefan,

Doing this helps so much to see what the expected behavior is across 
servers.  Good going and thanks!

More comments below ...

Stefan Zoerner wrote:
> Hi Emmanuel!
> 
> I tried out the situations described by you with some LDAP servers I 
> have here (just to compare, which option they have choosen).
> 
> Emmanuel Lecharny wrote:
>> This is what I was trying to fix. Now, here are my questions :
>>
>> 1) Regarding missing ObjectClasses
>> 1-a)
>> We can add some of the missing ObjectClasses, like 'top', 'person', 
>> 'organizationalPerson', because we have all the needed informations to 
>> rebuild the hierarchy starting from 'inetOrgPerson'.
>>
>>  Q : Is it a good idea to do so, instead of simply rejecting the entry ?
> 
> I tried to add the following entry via JNDI call
> 
> dn: cn=Kate Bush,dc=example,dc=com
> objectclass: inetOrgPerson
> sn: Bush
> cn: Kate Bush
> 
> (1) IBM Tivoli Directory Server 6.0 creates the entry, but it adds the 
> missing object classes. The entry looks like this after creation:
> 
> dn: dn: cn=Kate Bush,dc=example,dc=com
> objectclass: inetOrgPerson
> objectclass: top
> objectclass: organizationalPerson
> objectclass: person
> sn: Bush
> cn: Kate Bush
> 
> (2) Sun Java System Directory Server 5.2 creates the entry as well, and 
> it also adds the missing object classes. Entry looks like above after 
> creation.
> 
> (3) OpenLDAP 2.3 creates the entry, it does not add the missing object 
> classes. Entry looks like this after creation:
> 
> dn: cn=Kate Bush,dc=example,dc=com
> objectClass: inetOrgPerson
> sn: Bush
> cn: Kate Bush
> 
> (This one is a little surprise ...).
> 
> 
>> 2) Regarding missing attributes
>> 2-a)
>> If we have a RDN with an attribute not declared as an attribute of the 
>> entry, its should be rejected, as stated by RFC 2251 ( 4.7. Add 
>> Operation :
>> "...
>>
>> - attributes: the list of attributes that make up the content of the
>>     entry being added.  Clients MUST include distinguished values
>>     (those forming the entry's own RDN) in this list,..."
>>
>>  Q : Is that ok with you to reject such entries ?
> 
> I tried to add the following entry via JNDI call
> 
> dn: cn=Kate Bush,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Bush
> 
> (1) IBM Tivoli Directory Server 6.0 creates the entry, and adds the 
> missing cn attribute. The entry looks like this after creation:
> 
> dn: cn=Kate Bush,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Bush
> cn: Kate Bush
> 
> (2) Sun Java System Directory Server 5.2 behaves the same.
> 
> (3) OpenLDAP 2.3 as well.
> 
> So at least these three servers do not reject such an entry. I 
> understand your cite from the RFC differently. But should we behave 
> other like major players (I assume Fedora and Red Hat behave like Sun 
> does).
> 

With this last example though CN is allowed to be added by the schema I 
think because it is a MAY attribute in person.  In this case ApacheDS 
will add the attribute I think.  It should if I remember correctly.

However we should get a naming violation if we try to add CN to an entry 
that does not support a USER_APPLICATION attributeType used in the RDN.

Alex

Mime
View raw message