Subject: Re: Revised Matched Values Draft

From: "Subbu K. k." <[email-masked]>
Date: Wed, 12 Jul 2000 02:54:57 -0600

Bruce,

> Bruce Greenblatt <[email-masked]> 07/12/00 06:28AM >>>
>...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......

Sorry to digress from the main point, but there are valid reasons
 why a multi-valued attribute can have a large number of values. 
Take the example of a group member list. This can run into 
thousands and possibly millions of values on the Internet. Mailing 
list servers can also build up membership lists that are large.  

While such groups can be implemented using containers there are
 both pros and cons in going that way and not everyone will be 
happy with that choice. Group vs. OU is a separate topic for 
debate.

I do see some merit in supporting a server-side filter for an attribute value read operation. This should help in bridging any 'impedance' mismatch between an LDAP client and the server.

Subbu K. K.

--------------------------------------------------------------
K. K. Subramaniam,             email: [email-masked], [email-masked]                                   
Product Manager, NDS eDirectory (UNIX/Linux)
Novell Software, Bangalore, INDIA
Ph: +91 (80) 572-1290x2212,  (USA) 801-861-7000x42612x2206, cell:801-361-1339

---

From: "Miklos, Sue A." <[email-masked]>
Date: Wed, 12 Jul 2000 08:31:12 -0400

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: "Lloyd, Alan" <[email-masked]>
Date: Thu, 13 Jul 2000 16:20:37 +1000

Kurt... This OSI complex stuff...

I have always said that if the protocol stack - 130 KB of code is too
complex - its best to leave the rest of the directory service alone as
well... If a car door is to complex to build  - then dont even attempt to
make the cars...:-))

regards alan
-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, July 13, 2000 3:05 AM
To: Lloyd, Alan
Cc: Miklos, Sue A.; Bruce Greenblatt; [email-masked];
[email-masked]
Subject: RE: Revised Matched Values Draft

At 11:38 PM 7/12/00 +1000, Lloyd, Alan wrote:
>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

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: Bruce Greenblatt <[email-masked]>
Date: Thu, 13 Jul 2000 08:35:38 -0700

>delete/update the information?

From my perspective, there are many problems in using the groupOfNames
object class or something similar to manage mailing lists.  For example,
consider attempting to implement MajorDomo using just this LDAP object
class.  It becomes difficult to classify mailing list members since the
membership is implemented with a list of DNs.  There is no easy way to
attach additional information to indivual mailing list members.  An
approach is to begin using nested lists and containers to hold the
different lists, but this can lead to additional problems (such as constant
movement of list members from one sublist to another if a list member is
suspended).

In my opinion it would be straightforward to implement a robust mailing
list program that uses LDAP that doesn't create attributes with large
numbers of values.  It should be easier to administer than its counterpart.
 So, to answer your question, this narrow requirement CAN be managed
through "superior" schema design.

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories:
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 14 Jul 2000 17:12:58 +1000

You got your proposal through?

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Friday, 14 July 2000 16:33
To: 'Kurt D. Zeilenga'
Cc: [email-masked]
Subject: RE: Revised Matched Values Draft

> Sent: Thursday, 13 July 2000 3:05
> To: Lloyd, Alan

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

---

From: "Lloyd, Alan" <[email-masked]>
Date: Mon, 17 Jul 2000 17:58:55 +1000

We have had this debate havnt we... If you use DAP or DISP or DSP - then the
P_Layer is the ASN.1 decode/encode (C++-BER) which must be there.. Internal
representation (C++) to transfer syntax (BER)... This leaves us with the
S_Layer which in OSI terms was/is the same (almost) a every FAX machine on
this planet... But as we know the fundamental use of TLS/SSL for security in
most application protocols  - it still means we have DAP, etc over P-Layer
over SSL/TLS... So DAP over TCP is not very commercially acceptable.. is it?

OSI wasnt complex.. and now - with SSL/TLS - I think a simple stack is
"history"...Try OCSP over HTTP over SSL!

But the point is - the issue is not the stacks any more - its how one builds
large scale distributed information systems... and if the stack is complex
what label would one put on the rest of the distributed directory system
code - 

regards alan

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Monday, July 17, 2000 1:39 PM
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: Revised Matched Values Draft

It's now part of the amendments to X.519 and X.501.

> From: Ramsay, Ron [mailto:[email-masked]]
> Sent: Friday, 14 July 2000 17:13
> To: [email-masked]; 'Kurt D. Zeilenga'