Subject: RE: A tricky matched values problem

From: "Molesworth, Roger" <[email-masked]>
Date: Wed, 29 Sep 1999 16:02:18 +0100

I think that in principle, you should not reduce the quantity of information
supplied to the user unnecessarily.  That is, to be user-friendly, "if in
doubt, give more out".  Humans have a habit of not being optimal in their
usage of systems.

Obviously if access control prohibits then that's a different matter.  But
if there is some doubt, at the end of the day (or the request, which takes
longest) remember that the user is looking for useful information.  It is
extremely frustrating if an academically precise interpretation of a filter
just happens to exclude what the user needs, and causes him to have to
submit a second, perhaps more vague, request in order to reach that
information.  It gives X.500 a bad name!

That's my pennyworth!

Roger

> ----------
> From: 	David Chadwick[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	29 September 1999 12:17
> To: 	[email-masked]; [email-masked]
> Subject: 	A tricky matched values problem
> 
> Thomas Salter providing the following filter:
> 
> (OR(AND(mail=[email-masked])(telephoneNumber=47))(cn=
> Sean*))
> 
> to an entry containing the following attributes.
> 
> cn: Sean Mullan
> mail: [email-masked]
> mail: [email-masked]
> telephoneNumber: +1 781 442 0926
> telephoneNumber: 555-9999
> 
> As you can see, the overall filter is true, the AND is false, but the 
> mail attribute value matches true. The question is "does matched 
> ValuesOnly apply to the mail attribute or not". ie. should one or two 
> mail attribute values be returned.
> 
> On the FOR side (one returned value), we have that the AVA was 
> true,
> On the AGAINST side, we have that the AVA did not contribute to 
> the overall filter matching true.
> 
> My first reaction was to say that only one mail value should be 
> returned, but whilst drafting the proposed textual addition to X.500 I 
> have started to change my mind. 
> 
> What does anyone else think.
> 
> David
> 
> 
> ***************************************************
> 
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 790 167 0359
> Email [email-masked]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
> 
> ***************************************************
>

---

From: steve fisher <[email-masked]>
Date: Wed, 29 Sep 1999 18:13:13 +0100

I think that there may be examples where both courses of action are
relevant, but dependant upon the intention of the directory user, which I
think is what Erik is also saying. Under certain circumstances, the
'correct' response would entail understanding the directory user's
intentions with no information to do so.

Another example could be

an entry of

cn: Sean Mullan
mail: [email-masked]
mail: [email-masked]
streetAddress: Work Street
telephoneNumber: +1 781 442 0926
telephoneNumber: 555-9999

and a query containing

(OR(AND(mail=[email-masked])(streetAddress=Home Street))(cn=Sean*))

If the 'driver' in this filter is the streetAddress and the directory user
is really looking for the home email address, then if all matched values
were returned, the work email address would be returned and then be used
erroneously. This may or may not be a problem.

One option to this may be to let the server use policy to decide what it
wants to do, allowing it to override the matchedValuesOnly directive, public
systems being stricter than private ones. If a decision must be taken then I
would err on the side of inhibiting these 'matched' values

Steve Fisher

-----Original Message-----
From: Erik Andersen <[email-masked]>
To: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: 29 September 1999 14:25
Subject: Sv: A tricky matched values problem

A tricky question. I believe the problem comes from the ambiguity of the
word "contribute".

We can either understand "contribute" to mean

1) that a non-negated filter item matches a value of the attribute and
therefore only the matched value should be returned.

2) that for an attribute value to contribute, it is not only required that a
non-negated filter item matches the value, but this filter item shall also
be a part of a subfilter that evaluates to TRUE  (for definition of
subfilter, see the current X.500 extension work to fulfil ITU-T F.510
requirements).

If we take the first interpretation,  the value [email-masked] will
contribute.

Taking the second interpretation and by looking at the filter, we easily see
that it consists of two subfilters:

AND(mail=[email-masked])(telephoneNumber=47)
AND(cn=Sean*)

and the value [email-masked] will not contribute.

The question is what the user expect when setting this search control (a
user would not or should not be required to understand the tricky difference
between the two interpretation). I have a feeling that an ignorant user will
assume the first interpretation and will not understand the fine point about
subfilters.

Whatever we do, we have to be precise. It will also affect our text for
family of entries.

Kind regards, Erik Andersen

-----Oprindelig meddelelse-----
Fra: David Chadwick <[email-masked]>
Til: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Dato: 29. september 1999 13:45
Emne: A tricky matched values problem

cn: Sean Mullan

David

David Chadwick