directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [ApacheDS] Search Issues: need some ideas on possible solutions
Date Fri, 03 Feb 2006 19:03:46 GMT
Emmanuel Lecharny wrote:

> 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 ?


Yeah it's generally bad form to do that especially with name.  It's like 
saying to a jvm, hey print out all your objects.  However it is possible 
and not so bad if you are taking advantage of hierarchy / inheritance 
conservatively.  IMHO I don't think we should make presumptions about usage.

DIREVE-276 is pretty much done btw.  277 might not take much time 
actually.  Let me look at it some more tomorrow after some rest. If it's 
going to take days to do I won't mess with it.

Laters,
Alex


Mime
View raw message