Subject: RE: Revised Matched Values Draft

From: "Lloyd, Alan" <[email-masked]>
Date: Wed, 12 Jul 2000 21:22:02 +1000

David - Yes a case can always be made for something - In fact in my early
days in manchester (ICL) we designed machines and systems that had 600 +
User features on their screens - But in operational reality mode - in a real
survey , it said that the human users only used 15% of these features
because they did not understand the rest...

In these cases with complex filters - one relies on the user to have a lot
of pre and detailed knowledge.. This for 99.99% of the directory searches I
see is not the case.

In fact we built an advanced search screen into our DAP DXplorer to give the
user access to complex filters (ANDs, ORs, NOTs etc) - and guess what - 

In addition component matching rules are really good for searching for
certificates and CRls (as per the standard) and and other complex attributes
because one can characterise the search properties on the client screen with
the order of the construction and the attribute types within the compound
attribute.. That is why we are applying Cert and CRL component matching
rules.. and other component matching capabilities.

How do expect a normal "user" to know what all the fields in a cert,crl,
compound attribute, etc are it by name, value and syntax...?

So IMHO - some of the argument breaks down when considered operationally -
in that a user must have the mind of a directory schema management module to
use this stuff - and if it does not work, ie because it isnt supported -
they have to revert to look and see methods anyway.

The point is... the feature is questionabe for general use and needs a
schema, directory filter expert to use it.

As for mail lists - sounds like, begins with, etc deal with most of the
partial access/retrieval issues.

And just becuause we have a compound attribute for schema publication - to
be used by engineering types - it does not necessarily follow - that we need
to pile more filter features added on to all the products - just to see bits
of it. After all, If I have a file, an image or a document as an attribute -
do we now need a filter extension to count the words, pixels in them?
woops....

regards as always alan

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Wednesday, July 12, 2000 8:49 PM
To: Lloyd, Alan
Cc: [email-masked]
Subject: RE: Revised Matched Values Draft

From:           	"Lloyd, Alan" <[email-masked]>
To:             	Bruce Greenblatt
<[email-masked]>, 
	[email-masked], "Kurt D. Zeilenga" <[email-masked]>
Copies to:      	[email-masked]
Subject:        	RE: Revised Matched Values Draft
Date sent:      	Wed, 12 Jul 2000 15:05:32 +1000

> My personal view..
> 
> I agree with Bruce.. a directory is a common repository for many
> applications and users.. It follows that those using it are "looking
> for things fast" or browsing. It follows that good, predicatble schema
> design is essential if the directory is to be effective. A user who is
> looking for things will not have to much pre knowledge of an
> attributes value or values..

I disagree. The version that I am preparing has examples in which 
this is precisely the case. They are
i) a user who wants a particular schema definition
ii) a user who wants a certificate with particular key usage bits (e.g. 
an encryption certificate)

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: "David Chadwick" <[email-masked]>
Date: Wed, 12 Jul 2000 13:32:35 +0100

> David - Yes a case can always be made for something - In fact in my
> early days in manchester (ICL) we designed machines and systems that
> had 600 + User features on their screens - But in operational reality
> mode - in a real survey , it said that the human users only used 15%
> of these features because they did not understand the rest...
> 

I agree. Same goes for Word and other general purpose 
applications. However, different types of clients will need different 
features. I would not expect a PKI LDAP client to be the same as a 
general browse client (and indeed it is not in Netscape for example)

> In these cases with complex filters - one relies on the user to have a
> lot of pre and detailed knowledge.. 

No, it should be the user interface that has the knowledge, not the 
user. So for example, I retrieve an attribute and the interface does 
not understand it, but the interface knows how to construct a search 
to fetch the single schema definition. This could even be done 
automatically without any user intervention. It is not necessarily an 
engineer that uses this feature. Or, I want to fetch an encryption 
certificate to send an email, so, the interface software knows hows 
to construct the search operation, but has a very simplified screen 
display to the user.

Ultimately, you cannot escape from the user interface having to 
know about the directory schema. You client (Dxplorer - still one of 
the best on the market to my mind, and free at that) has the 
complete X.501 schema built into it and can be configured to know 
about more elements. However what it is missing in Dxplorer is 
knowing for example that ordering matching is not applicable to 
telephone numbers or titles. It allows the user to try these out and 
get an error from the server. So an enhanced Dxplorer would know 
that when I am searching for a certificate that certificateExactMatch 
and certificateMatch should be used and bring up an appropriate 
display for this. All the user needs to know is
i) I want to find a certificate
ii) the display shows me the types I can search for
iii) the display optionally asks me about validity periods
iv) the display optionally asks me which CA I am interested in etc. 
etc.

The point is, the user does not need to know the schema, the client 
software does, and it should guide the user through this.

David

David Chadwick