[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Revised Matched Values Draft
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:samiklo@missi.ncsc.mil]
Sent: Wednesday, July 12, 2000 10:31 PM
To: Lloyd, Alan; Bruce Greenblatt; d.w.chadwick@salford.ac.uk; Kurt D.
Zeilenga
Cc: ietf-ldapext@netscape.com
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:Alan.Lloyd@ca.com]
Sent: Wednesday, July 12, 2000 1:06 AM
To: Bruce Greenblatt; d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga
Cc: ietf-ldapext@netscape.com
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:bgreenblatt@directory-applications.com]
Sent: Wednesday, July 12, 2000 11:02 AM
To: d.w.chadwick@salford.ac.uk; Kurt D. Zeilenga
Cc: ietf-ldapext@netscape.com
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.
****************************************************************************
**