directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [ApacheDS] Search Issues: need some ideas on possible solutions
Date Fri, 03 Feb 2006 18:43:40 GMT
Alex Karasulu a écrit :

> Emmanuel you had one of these slated for RC1 but I think both are 
> pretty severe issues that impact ApacheDS' 2251 compliance in a major 
> way.  

That's true. In my mind DIREVE-276 is more important than DIREVE-277. We 
have to switch those two issues from the bug list.

> As a side discussion to this thread we should probably discussion 
> whether or not we want both these issues resolved before RC1.

As I said, I now think that DIREVE-276 is a must for RC1. DIREVE-277 
could wait a little bit.

>
> Here's a quick summary of each issue:
>
> DIREVE-276:
> ----------------
> A search filter with a superior objectClass (objectClass=person) does 
> not match for entries of the subordinate objectClass 
> (objectClass=organizationalPerson) if the entry does not contain all 
> ancestors as values in the objectClass attribute.  Right now it is 
> legal for me to create an entry that is just an inetOrgPerson without 
> including organizationalPerson, person and top within the objectClass 
> attribute.  I don't know if this is legal according to 2251 after 
> several passes.  My impression has been that this is valid since all 
> superior objectClasses are implied.  Can anyone confirm this?

RFC 2251, 3.2.1, §4 : "When creating an entry or adding an objectClass 
value to an entry, all superclasses of the named classes are implicitly 
added as well if not already present..."

So we must create the missiong object class. This should not be a big 
deal, as we have all needed informations in the registry.

> DIREVE-277:
> ----------------
> This is a similar problem.  A search filter with a superior 
> attributeType will not match subtypes with the same value.  So for 
> example (name=Alex) will not match an entry in scope with attribute 
> givenName with value of 'Alex'.  Again this effects search semantics 
> where we are clearly not compatible with 2251.

I think that it's not very clear that we should consider this a major 
bug which has to be fixed before 1.0-RC1. I never saw anybody searching 
for name=XXX in place of sn=XXX, even if sn inherits from name. wdyt ?



Mime
View raw message