Subject: RE: Returning single values from multivalued attributes

From: "James Benedict" <[email-masked]>
Date: Wed, 11 Aug 1999 11:01:11 -0400

I think "families of entries" kind of overlaps this problem space.

I agree that when we have a small small number of values in a multi-valued
attribute,
the benifit of matchedValuesOnly is small. I also agree that having a large
number of values in a single entry is likely the result of a bad information
model... unfortunately, there are many bad information models out there.

I think that entry families cover this quite well.  If we break the
offending attributes up into familie entries, then matchedValuesOnly will be
the default (returning the DN of then family entry).  Returning all values
will be a little more interesting, but I assume
David Chadwick already has this covered in the "Families" draft.  I think
that both of these extensions (families & matchedValuesOnly) will require
some substantial changes on both the client and server side.  I think we can
minimize the work (and concentrate design effort), by folding the two
together.  At the very least, we need to consider how these two features
will work together.

That's a good question:  Since X.500 already has matchedValuesOnly and will
be extended to include entry families, what sort of return set should I
expect when both families and matchedValuesOnly are involved?

> -----Original Message-----
> From: Bruce Greenblatt [mailto:[email-masked]]
> Sent: Wednesday, August 11, 1999 1:03 AM
> To: Miklos, Sue A.; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Returning single values from multivalued attributes
> 
> 
> At 12:41 PM 8/10/99 -0400, Miklos, Sue A. wrote:
> >In the early days of a program called "MISSI", we defined a different
> attribute type (with
> >a single value) for every permutation of algorithm used, and 
> subsequently
> named it (for 
> >example) FortezzaKMandSigCertificate; SNDSSuiteACertificate, 
> ad nauseum
> with a different 
> >oid for each type.  We found it to be a minimally functional 
> design, that
> did not allow for 
> >extensibility, unless we had a mechanism to disseminate 
> changes to all of
> the client and 
> >crypto service provider software already deployed.  I believe you've
> already run into that 
> >issue with schema discovery.
> >
> >It is not out of the realm of possibility again, in the certificate
> mindset)to have
> >products allowing us to 1) store many (where I believe an 
> order of 10-25
> per entry is 
> >possible) values for any given attribute type and 2) allow 
> either the user
> interface or 
> >the CSP software interface to provide selected pieces of 
> information (CA
> issuer's name?  
> [snip ...]
> 
> Sandi,
> 
> I still don't think that this is really a requirement.  If 
> you only have
> around 10 attribute values, you're better off getting them 
> all from the
> server, and tossing the ones that you don't want.  This is easily done
> using a client API...  You'll be doing the exact same thing 
> on the client
> side that the server would be doing.   On the other hand, if 
> you have in
> the range of 1000 attribute values, I would definitely urge 
> you to abandon
> whatever scheme has let you here, and redesign the 
> application.  I know of
> at least one firm that will help you do this (for a small fee :))...
> 
> Bruce
> 
> ==============================================
> Bruce Greenblatt
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com
> 
>

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 18 Aug 1999 16:18:49 +0100

Date forwarded: 	Wed, 11 Aug 1999 08:03:53 -0700 (PDT)
From:           	"James Benedict" <[email-masked]>
To:             	[email-masked], [email-masked]
Copies to:      	[email-masked]
Subject:        	RE: Returning single values from multivalued attributes
Date sent:      	Wed, 11 Aug 1999 11:01:11 -0400
Forwarded by:   	[email-masked]

> I think "families of entries" kind of overlaps this problem space.

It kind of does, but they do have different purposes. Families are 
designed for grouping together single (or few) values from several 
multivalued attributes, into one child entry. Returning matched values 
on the other hand is simply an extra way of filtering a result. It will 
apply equally to families and single entries.

> I think we can
> That's a good question:  Since X.500 already has matchedValuesOnly and
> will be extended to include entry families, what sort of return set should
> I expect when both families and matchedValuesOnly are involved?
> 

I see them as separate features with different purposes, 
that can work together or separately without purturbing each other.

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email [email-masked] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************