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
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
