Subject: Re: controlling visability of subentries

From: Zachary Amsden <[email-masked]>
Date: Tue, 1 Aug 2000 18:57:33 -0700

Yes, a control is definitely needed.  I wasn't looking
forwards to parsing arbitrary filters correctly.  Also, since
ldapSubEntries aren't actually in our object databases, but
are metadata, using a control is a much easier way to figure
this out.

>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:
>
>(objectclass=ldapSubEntry)
>(!(objectclass=ldapSubEntry))
>(&(objectclass=ldapSubentry)(cn=foo))
>(|(objectclass=ldapSubEntry)(objectclass=myReplicaSubEntry))
>
>If we stick with the filter approach, we should at least add
some
>examples to the document.

---

From: Zachary Amsden <[email-masked]>
Date: Thu, 10 Aug 2000 13:36:49 -0700

>I would suggest the control have a syntax similar to
>ManageDsaIT control defined by
draft-ietf-ldapext-refer-00.txt
>(or draft-zeilenga-ldap-nameref-00.txt) but with semantics of
>the X.511 ServiceControls "subentries" option [X.511(97)
5.7f].
>Kurt

How about 

Control ::= SEQUENCE {
   controlType = 2.16.840.1.113719.2.142.7.TBD
   criticality = TRUE
   controlValue = (not present)
}

I think it should be critical, since if the server doesn't
recognize it, there is no way the request can be processed
sucessfully.

Zach