[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Revised Matched Values Draft
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:d.w.chadwick@salford.ac.uk]
Sent: Wednesday, July 12, 2000 8:49 PM
To: Lloyd, Alan
Cc: ietf-ldapext@netscape.com
Subject: RE: Revised Matched Values Draft
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: Bruce Greenblatt
<bgreenblatt@directory-applications.com>,
d.w.chadwick@salford.ac.uk, "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Copies to: ietf-ldapext@netscape.com
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 D.W.Chadwick@salford.ac.uk
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
***************************************************