Bug in QUIPU's handling of searches at different levels of tree?

"peter (p.w.) whittaker" <pww@bnr.ca> Mon, 01 May 1995 23:07 UTC

X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 1 May 1995 16:20:29 -0400
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 1 May 1995 16:20:20 -0400
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 1 May 1995 16:20:00 -0400
Date: Mon, 01 May 1995 16:20:00 -0400
X400-Originator: /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca
X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; bcars520.b.274:01.04.95.20.20.20]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Bug in QUIPU'...
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "peter (p.w.) whittaker" <pww@bnr.ca>
Message-ID: <"9277 Mon May 1 16:20:22 1995"@bnr.ca>
To: osi-ds@cs.ucl.ac.uk, quipu@cs.ucl.ac.uk, bug-quipu@isode.com
Subject: Bug in QUIPU's handling of searches at different levels of tree?

I have noticed some bizarre behavior in how QUIPU (IC 1.1v3) handles
searches at different levels of the DIT.

Nutshell summary:

Searches for sn=allen, sn="*allen*", cn="*allen" all succeed if
searching at or below second level of the DIT (@c=US@o=test1).  Searches
for sn="*allen*", cn="*allen" succeed when searching at first level of
the DIT (c=US).  As you would expect.

Searches for sn=allen at the first level of the tree (c=US) fail!  Why?
Why should a wildcard search (sn="*allen*") succeed at the first level
of the tree and a very specific search (sn=allen) fail?

Slightly less terse summary:

    DSA configuration:

	DSA configured to allow searches at level 0 (root) or 1
	(country) (tests below performed against both cases).

	DIT structure:  one country (c=US), two organizations (o=test1
	and o=test2) directly below c=US, people and OUs below test[12].

	No list ACLs or search ACLs in place.  Actual ACLs allow global
	reading and returning of all data, used primarily to control
	write/modify access.

	Several entries with sn=allen or cn="*allen*" exist.

	Tree @c=US index for surname and commonName.

	Non-optimized searches OK.

Now the bizarre behaovior:

    search command (from dish or from an LDAP client):

	base c=US@test1
	filter sn="*allen*"
	scope subtree

	result:  success AS YOU'D EXPECT

    search command (from dish or from an LDAP client):

	base c=US@test1
	filter cn="*allen*"
	scope subtree

	result:  success AS YOU'D EXPECT

    search command (from dish or from an LDAP client):

	base c=US@o=test1
	filter sn=allen
	scope subtree

	result:  success AS YOU'D EXPECT

    search command (from dish or from an LDAP client):

	base c=US
	filter sn="*allen*"
	scope subtree

	result:  success AS YOU'D EXPECT

    search command (from dish or from an LDAP client):

	base c=US
	filter cn="*allen*"
	scope subtree

	result:  success AS YOU'D EXPECT

    search command (from dish or from an LDAP client):

	base c=US
	filter sn=allen
	scope subtree

	result:  failure THAT'S BIZARRE.  WHY?

pww


Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   X.500 DS Specialist
pww@entrust.com      [                          ]   NORTEL Secure Networks
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 765 3520  [__________________________]   Ottawa, Canada, K1Y 4H7

Bug in QUIPU's handling of searches at different … peter (p.w.) whittaker