Subject: RE: Fwd: controlling visability of subentries

From: "Ed Reed" <[email-masked]>
Date: Thu, 19 Oct 2000 07:35:10 -0600

Hi, Helmut -

The ObjectClass=SUBENTRY approach (call that option 3) was my original
suggestion, but the objection to that is that search filters can quickly become
very complex, particularly if there are other similar "special" filters to add to the
mix, and that pulling them out into a control allows much more clarity of the
search filters themselves.  Reasonable.

So, I agree a control is prefered, and now we need to decide what that
control should look like - and thus my mail note.

In another response, Mark Smith copied the X.511 description of the
service control data strcture which governs subentry visibility as part
of the CommonArguments parameter of X.500 requests.  And he points
out that there is a lot of stuff there that not everyone will support
in the near (or even distant) future.

I suppose the "LDAP" thing to do would be to create a separate control
for subentry visibility, and if some LDAPv3bis work item in the future
wants to consolidate several controls into a single control ala X.511 we
can consider that then.  My current thinking is that makes sense.

But - would like to hear from more of the lists, first.

Thanks,
Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Volpers, Helmut" <[email-masked]> 10/19/00 02:03AM >>>
Hi Ed,

I personally think that solution 2 is the best one, specially for 
the future.
If you take solution 1 it will also work, but at least you will create
a control for every additional service control you will support.
I think to work with a control is a clean solution but the number
of controls increase rapitly and different servers have a lot of
different controls they support.
I think there is the requirement that the protocol has to be compatible
and only some administrative clients will use this feature and a simple
LDAP Client should not been broken.
We handle subentries over LDAP for all update operations like normal entries
and for the search in a special way, so if the filter contains
ObjectClass=SUBENTRY
the search operation is only for subentries and all other search operations
exclude subentries. Is this a problem ?

> -----Original Message-----
> From: Ed Reed [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2000 5:25 AM
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> Subject: Re: Fwd: controlling visability of subentries
> 
> 
> Okay, Kurt - I've reviewed what X.511 specifies for the 
> service control
> used to control subentry visibility.  What is your opinion on 
> what we should
> do in LDAP?
> 
> 1) create a control which has no parameters, but has the 
> effect that when
> it is present, it is interpreted identically to an X.511 
> service control with the
> subentries bit set TRUE; or
> 
> 2) create a control which has a parameter identical to the 
> service control
> specified by X.511.  This would have the effect of providing 
> a lot of the
> additional controls needed to add distributed operations to 
> LDAP (including
> preferChaining, chainingProhibited, etc.), but would also 
> provide things
> like timeLimit, sizeLimit, scopeOfReferral, and 
> attributeSizeLimit, etc.
> In X.511, the serviceControls are among the CommonArguments included
> with each request.
> 
> I suppose we could consider the list of controls in LDAP providing the
> equivalent to the set of CommonArguments.  
> 
> What's your take?  1 would be easier to document.  2 would lay
> important groundwork that should be considered in the context 
> of future
> work to add distributed operations to LDAP.
> 
> Ed
> 
> =================
> Ed Reed
> Reed-Matthews, Inc.
> +1 801 796 7065
> http://www.Reed-Matthews.COM 
> 
> >>> "Kurt D. Zeilenga" <[email-masked]> 08/01/00 07:41AM >>>
> Forwarded to LDUP list
> >Date: Mon, 31 Jul 2000 16:23:57 -0400
> >To: [email-masked] 
> >From: "Kurt D. Zeilenga" <[email-masked]>
> >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. 
> >
> >Comments?
> >
> >        Kurt
> 
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Oct 2000 07:18:07 -0700

I prefer option 1 as it is simple, adequately resolves this issue,
and is consistent with other such extensions (e.g. manageDsaIT
control).  As LDAP subentry TS is an elective extension to the
LDAP protocol, I believe this to be best.  I would prefer
to keep "future work" off this particular table so that we might
reach closure on the LDAP subentry TS soon.

Kurt

At 09:24 PM 10/18/00 -0600, Ed Reed wrote:
>Okay, Kurt - I've reviewed what X.511 specifies for the service control
>used to control subentry visibility.  What is your opinion on what we should
>do in LDAP?
>
>1) create a control which has no parameters, but has the effect that when
>it is present, it is interpreted identically to an X.511 service control with the
>2) create a control which has a parameter identical to the service control
>specified by X.511.  This would have the effect of providing a lot of the
>additional controls needed to add distributed operations to LDAP (including
>preferChaining, chainingProhibited, etc.), but would also provide things
>like timeLimit, sizeLimit, scopeOfReferral, and attributeSizeLimit, etc.
>important groundwork that should be considered in the context of future

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 19 Oct 2000 10:49:48 -0600

Yes - to follow the model of X.511, the following will apply:

If the control is present, then NO other
entries will be considered for return to a search operation, though other
entries may be referenced in the base of the search, and normal ACI
policy will be inforced.  

If the control is NOT present, then NO subentries
will be considered for return to a search operation.

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065

>>> "Volpers, Helmut" <[email-masked]> 10/19/00 08:39AM >>>
I think Kurt is right. It's the simplest solution.
Does this mean that an LDAPServer should never gives a subentry in the 
search result if this control is not set ?

Helmut

> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2000 4:18 PM
> To: Ed Reed

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Oct 2000 17:20:18 -0700

At 03:30 PM 10/19/00 -0400, Salter, Thomas A wrote:
>Your [Mark Smith's] option 2 [scope base] is the X.500 definition.  The subentries control applies to
>one-level and whole tree searches and lists, but not to baseObject or read.
>You can always get the entry with its name.

That's an interesting point.

RFC 2251 says "(objectclass=subentry)" was introduced to "allow
LDAPv3 servers which gateway to X.500(93) to detect that subentry
information is being requested."  However, given that the
requirement is for a scope base search, an LDAP/DAP gateway could
do a direct translation of the request and the appropriate
subentry would be returned by the DAP server to the gateway for
the LDAP client.  So my question is: why does a LDAP/DAP gateway
need to detect that the request is for a subentry?

Kurt

PS: I've cc'ed [email-masked]

> > From: Mark Smith [mailto:[email-masked]]
> > Sent: Thursday, October 19, 2000 2:39 PM
> > To: sanjay jain
> > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; [email-masked];
> > [email-masked]
> > sanjay jain wrote:
> > > "Volpers, Helmut" wrote:
> > > I guess, going with the new scheme would require change in the
> > > following text from RFC 2251:
> > > 
> > > " Clients MUST only retrieve attributes from a subschema entry by
> > >    requesting a base object search of the entry, where the 
> > search filter
> > >    is "(objectClass=subschema)". (This will allow LDAPv3 
> > servers which
> > >    gateway to X.500(93) to detect that subentry 
> > information is being
> > >    requested.) "
> > > 
> > > Any backward compatibility issues (existing clients
> > > using RFC 2251 scheme to read subschema subentries) ?
> > 
> > Perhaps.  A reasonable compromise might be to return LDAP 
> > subentries in
> > these two cases:
> > 
> > 1) When a returnSubEntries control (to be defined) is present in the
> > search request.
> > 
> > 2) When the scope of the search is baseObject.
> > 
> > Why return LDAP subentries in case 2)?  Because it is more compatible
> > with 2251.  And because I do not think it does any harm -- 
> > if a client
> > knows the name of a subentry, it might just as well be able 
> > to retrieve
> > it without using any controls.  Comments?
> > 
> > -- 
> > Mark Smith
> > Netscape
> >

---

From: "Volpers, Helmut" <[email-masked]>
Date: Fri, 20 Oct 2000 10:46:34 +0200

Hi Thomas,

By a read its true, but in a search (also base) you have to set
the service Control subentries=TRUE I think.

Helmut

> From: Salter, Thomas A [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 9:31 PM
> To: Mark Smith; sanjay jain
> Subject: RE: Fwd: controlling visability of subentries
> 
> 
> Your option 2 is the X.500 definition.  The subentries 
> control applies to

---

From: "Salter, Thomas A" <[email-masked]>
Date: Fri, 20 Oct 2000 09:45:51 -0400

You are correct.  I mistakenly equated baseObject search with Read.  

Tom

 > From: Steven Legg [mailto:[email-masked]]
 > Sent: Thursday, October 19, 2000 9:48 PM
 > To: 'Salter, Thomas A'
 > How did you reach the conclusion that the subentries service control
 > does not apply to baseObject searches ? I've just read X.511 and it
 > says the control applies to search and list operations, but 
 > it doesn't
 > qualify the type of search at all.
 > 
 > It would be sensible to ignore the setting of the subentries service
 > control for baseObject searches but X.511 doesn't read that way.
 > 
 > Regards,
 > Steven
 > 
 > > From: [email-masked]
 > > [mailto:[email-masked]]On Behalf Of Salter, Thomas A
 > > Sent: Friday, 20 October 2000 6:31