[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Returning single values from multivalued attributes
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:bgreenblatt@dtasi.com]
> Sent: Wednesday, August 11, 1999 1:03 AM
> To: Miklos, Sue A.; mcs@netscape.com; d.w.chadwick@salford.ac.uk
> Cc: ietf-ldapext@netscape.com
> 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
>
>