Subject: RE: Revised Matched Values Draft

From: "Lloyd, Alan" <[email-masked]>
Date: 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..
Too many values (more than 8 say) is NOT good schema design - ie. having 200
values and reading an entry (all) will clutter the browser..

What happens with this - if a full sequence of all 7 filter values are used
on all values - eg the lot on all values eg.. exact match, sounds like,
substring, begins with, ends with - what gets returned? 

In the case of human users, how many will be trained to understand critical
extensions and Sequences of Value  filters?

Doesnt "sounds like" do this job?
regards alan
-----Original Message-----
From: Bruce Greenblatt [mailto:[email-masked]]
Sent: Wednesday, July 12, 2000 11:02 AM
To: [email-masked]; Kurt D. Zeilenga
Cc: [email-masked]
Subject: Re: Revised Matched Values Draft

I'll voice the same reservations this time that I voiced last time.

Use of this control solves a problem that normally exists due to poor 
schema and DIT design.  There is no obvious reason why an entry should have 
so many values of an attribute that an LDAP client would have a problem 
retrieving them all.  Do not put hundreds of values (or however many you 
have in mind) in the attribute.  The introduction uses the userCertificate 
attribute as an example.  While it is true that a single user in the real 
world may have numerous certificates, this should not translate into an 
LDAP entry that has numerous userCertificate attribute values.  IMHO, this 
is poor schema/DIT design.  By creating this control, we only encourage 
this type of design, when we really need to discourage it.  In my mind it 
is analogous to encouraging non-normalized SQL schemas.  I wrote a little 
draft a while back 
(http://www.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema-0
2.txt) 
that recommends a schema/DIT design for holding certificate information in 
the schema that allows for selective retrieval of certificates without 
requiring any protocol extensions (or even any new syntaxes).  I have had 
several people ask me privately about this draft with indications that they 
were interested in implementing it.

Additionally, I believe that implementation of this control could place an 
unnecessary burden on the server for sifting through the attribute values, 
when it should be done on the client (perhaps this is more of a stylistic 
issue).  In any case, I would not be in favor of promoting this draft along 
the standards track.  Last time this came up, and I voice this same 
objection to the draft, I received several notes supporting my position.  I 
think that we need to think carefully about what kinds of protocol 
extension that should be standardized, and how they benefit LDAP 
applications.  In my mind this extension provides no benefits to LDAP 
applications.

Bruce

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 12 Jul 2000 11:48:46 +0100

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

> 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

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

***************************************************