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