Subject: RE: Revised Matched Values Draft

From: "Lloyd, Alan" <[email-masked]>
Date: Wed, 12 Jul 2000 23:38:33 +1000

Sue - the issues of nested lists - is a good one - and with directory
operators - what would be the approach to find a memeber three levels down
if "fuzzy searching" is applied in a nested sequence - and the accuracy or
concept of searching is open to the user..? 

I always tend to think (and please dont debate that point on the list) that
where compound information and relationship issues exist on directory
information, its better to have a directory enabled utility to manage that
ie "find and clear duplicate or really old certs".. "provide mail list
hierarchies where end users have...name, properties, etc." ie dont update
protocols - have functional utilities..

How does an SQL application get more functionality?... they dont keep
updating the SQL standard do they?

This utility approach is far less damaging to directory suppliers who have
to go through formal releases of software to thousands of users - with
online deployed global systems  - because of a specific or theoretical
requirement from somewhere..that only deals one instance a problem related
to the multi value, nested refernces and operationally related information.

Does the utility idea - sound useful for managing lists?

Isnt it amazing that the reason for LDAP was that DAP was too complex - and
here we are (years later) adding more complexity to LDAP beyond that of
DAP..:-)
 regards alan

-----Original Message-----
From: Miklos, Sue A. [mailto:[email-masked]]
Sent: Wednesday, July 12, 2000 10:31 PM
To: Lloyd, Alan; Bruce Greenblatt; [email-masked]; Kurt D.
Zeilenga
Cc: [email-masked]
Subject: RE: Revised Matched Values Draft

All,

I can think of instances where there may be many values in an attribute, but
they are mostly related to mail lists.  I have requirements to be able to
manage varying sizes of lists (AllMil which is essentially a series of
nested lists, down to smaller, 10-30 member lists).  

Can this narrow requirement be managed through superior schema design, or do
I need to be able to match on member characteristics (name?) to selectively
delete/update the information?

Regards,
Sandi

-----Original Message-----
From: Lloyd, Alan [mailto:[email-masked]]
Sent: Wednesday, July 12, 2000 1:06 AM
To: Bruce Greenblatt; [email-masked]; Kurt D. Zeilenga
Cc: [email-masked]
Subject: RE: Revised Matched Values Draft

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

****************************************************************************
*
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
****************************************************************************
**

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 12 Jul 2000 10:04:45 -0700

>here we are (years later) adding more complexity to LDAP beyond that of

The primary complexity of DAP that LDAP removed was need to implement
the ISO protocol stack.

As far as other so-called simplications made, I would argue that many
of them have actually made things more complex.  Note that in X.500/DAP,
a client did not need to discover the syntax of attributes simply to
browse a directory... now everything is a BLOB until the client
reads and recognizes syntaxes of values as published in the subschema.

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 14 Jul 2000 16:32:49 +1000

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, 13 July 2000 3:05
> To: Lloyd, Alan
> Cc: Miklos, Sue A.; Bruce Greenblatt; [email-masked];
> [email-masked]

Even the OSI stack can be avoided now. The 2000 edition of X.500 contains
the provisions for mapping the protocols directly onto TCP/IP.

Regards,
Steven