Subject: RE: A tricky matched values problem

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 05 Oct 1999 13:41:15 +0200

At 09:34 04.10.99 -0400, Salter, Thomas A wrote:
>I'm not sure the 'Molesworth Principle" should apply here.  In this case,
>the requestor has explicitly set "matchedValuesOnly" in an attempt to limit
>the size of the response.  If he doesn't get enough information, he can
>always remove the matchedValuesOnly control and try again.

I'm not sure who Molesworth is, but if the purpose of the control is to 
limit the size of the response, it might be better to have a control that 
tells the server something about what the client wants back rather than 
something about how he wants the search criteria treated.

>If it is left up to policy, the control becomes unusable in multi-directory
>environments.  I think it's better to pick one definition and stick with it.

Couldn't agree more.
But I don't think the case for matchedValuesOnly as currently defined has 
been made convincingly - at least, I'm profoundly unconvinced.

Other scenarios:

- I want to search for a CN, but don't want ANY CN returned, I want the 
certificate that contains a certain string instead. (oops - how do I match 
that?)
- I want to search on (surname=Jones) and return the CN that contains 
"Jones", because I want to see what givenname he uses alongside that.

If the purpose of the control is to limit the size of the response, mixing 
that with how the search criteria are formulated seems nonorthogonal to me.

                        Harald
--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 05 Oct 1999 21:08:50 -0700

>something about how he wants the search criteria treated.
[snip]

I think that I get what Harald is saying.  The Matched Values Only Control
(MVO) is trying to force the Search filter into performing two tasks
simultaneously:

1. Decide which entries to retrieve
2. Decide which attribute values in entries that match to retrieve

It isn't clear to me that this will work.  The Search filter can only be
used for one of these tasks at a time. I'll modify one of Harald's examples:

- I want to search for a user's email address, and I want the certificate
that contains was issued by the Verisign Class 2 CA (assuming that the
fancy Certificate matching rules are supported).

As I understand it, the fact that entries can hold zillions of certificates
in the userCertificate attribute is one of the reasons for the MVO's
existence.  For this to actually give the user what he want's the user must
already know that the entry contains a Verisign Class 2 certificate,
otherwise the search wouldn't have matched.  Thus, if you already know the
answer to the filter item for all matching entries, don't include it in the
search.  You'd just be negatively impacting the performance of the search
with unnecessary computation.  On the other hand, if you don't know the
answer then you risk not giving the user back anything, which is not too
useful.  Instead the MVO should include its own simpler filter to get the
appropriate values from the matching entries...

Bruce

>                        Harald
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Mark Wahl <[email-masked]>
Date: Wed, 06 Oct 1999 01:46:46 -0500

In your example it would seem that to achieve the goals you simply issue two
searches. The first with single level or whole subtree scope, attributes types 
only and a filter to match the email address, the second then with base object
scope, the matched values only control and a filter to select the individual 
value of an attribute of interest. 

Mark Wahl, Directory Product Architect
Innosoft International, Inc.