Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com
 designates 209.85.146.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=HKOQBzUgJIXHWveb0hv2hMY2lsrUDQd+7gZxLkygg+pQB7nBAiD/2ZgOkHDzGEHhbj1ZUbp+ZD25IxqHp+Ium21KqT/zeQnVIh0RMHId17PxoJXMiLpnnOk4xeTc8yMWFJz4WDcNg6QSQJJZfC6wlTjnn+AOPzO10CVi/gutdI0=
Message-ID: <a32f6b020710081046i234d5354g26ec0710c6f6d793@mail.gmail.com>
Date: Mon, 8 Oct 2007 13:46:32 -0400
From: "Alex Karasulu" <akarasulu@apache.org>
Sender: akarasulu@gmail.com
To: users@directory.apache.org, elecharny@iktek.com
Subject: Re: [ApacheDS 1.5.1] unable to search for uniqueMember
In-Reply-To: <d45b08f00710080638j5a9de93fie4d9c5bfdeebb567@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_574_28993994.1191865592873"
References: <20071005190330.dojpsfu4fug0koo4@nemo.granus-werkstatt.de>
	 <d45b08f00710060004y47d9c377y52c0948576df2d3a@mail.gmail.com>
	 <470A2051.3080407@webunity.de>
	 <d45b08f00710080536l1799aa38gcddd1948fcd31266@mail.gmail.com>
	 <470A2D63.5090000@webunity.de>
	 <d45b08f00710080638j5a9de93fie4d9c5bfdeebb567@mail.gmail.com>

------=_Part_574_28993994.1191865592873
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/8/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> Again, doing a seach with (uniqueMember=uid*) is _not_ allowed by the
> LDAP specification. At best, you should get an empty list.
>
> Substring search are valid for strings. A DN is not as string.
>

This is hard to believe although I totally follow your reasoning.  It just
seems like a very
common search to be performing to determine group membership.  DN's btw do
have a
string representation defined in RFC's so I don't understand why the
matching would
not be conducted on the string representation.

Also note that you cannot construct a DN with name components using
attributeTypes
that do not have support for equality matching.  I don't think the same
applies for substring
matching.

I'm afraid we may be quickly coming to the wrong conclusions on this topic.
Perhaps
we're lacking some additional knowledge.  Perhaps we can post some questions
on the
umich LDAP mailing list to get to the bottom of this.

Alex

------=_Part_574_28993994.1191865592873--