[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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.
****************************************************************************
**