[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: controlling visability of subentries
I also agree that it is probably better to define a control for this.
Can we do so soon?
FYI, our implementation of draft-ietf-ldup-subentry-03.txt today checks
each equalityMatch filter component for objectclass=ldapSubEntry and
considers returning subentries if it finds one anywhere. So all of
these filters may result in ldapSubEntries being returned:
If we stick with the filter approach, we should at least add some
examples to the document.
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's. Got LDAP?
Albert Langer wrote:
> -----Original Message-----
> From: owner-ietf-ldup@xxxxxxxxxxxx
> [mailto:owner-ietf-ldup@xxxxxxxxxxxx]On Behalf Of Kurt D. Zeilenga
> Sent: Tuesday, August 01, 2000 11:42 PM
> To: ietf-ldup@xxxxxxx
> Subject: Fwd: controlling visability of subentries
> Forwarded to LDUP list
> >Date: Mon, 31 Jul 2000 16:23:57 -0400
> >To: ietf-ldapext@xxxxxxxxxxxx
> >From: "Kurt D. Zeilenga" <Kurt@xxxxxxxxxxxx>
> >Subject: controlling visability of subentries
> >One other issue I would like to raise in regards to LDAP subentry
> >is the mechanism proposed to control their visibility. I believe
> >the approach of overloading the search filter to control visibility
> >is not the best approach. As we've found previously, the semantics
> >of such overloads are difficult to define (and hence implement) when
> >the filter is complex (which we must assume it will be).
> >I believe that LDAPsubentry visibility should be control by a mechanism
> >more closely modeled after the X.500 subentry visibility mechanism.
> >In particular, I suggest use of a control. The use of a control
> >will allow a clear and concise specification of visibility semantics
> >which facilitates implementation and use.
> > Kurt