RE: subentries comments

["Volpers, Helmut" <helmut.volpers@icn.siemens.de>]

Hi Rob,

I agree with Steven how the control should work.

> -----Original Message-----
> From: Rob Byrne - Sun Microsystems [mailto:robert.byrne@sun.com]
> Sent: Freitag, 7. Dezember 2001 11:02
> To: steven.legg@adacel.com.au
> Cc: 'Kurt D. Zeilenga'; ietf-ldapext@netscape.com
> Subject: Re: subentries comments
> 
> 
> Steven Legg wrote:
> 
> > Rob,
> >
> > Rob Byrne wrote:
> > > "Kurt D. Zeilenga" wrote:
> > > > We don't transfer mechanism, we adapt them while maintaining the
> > > > consistent semantics.  That is, the LDAP access to 
> subentries uses
> > > > different mechanisms than DAP, but both are 
> semantically consistent.
> > >
> > > Kurt,
> > >
> > > You point out below that in fact you have introduced a
> > > difference, namely in the
> > > retrieval behaviour when no control is attached.
> >
> > The last paragraph in section 1 needs rewording. The detailed
> > description in section 3 is correct.
> >
> > In DAP, if the ServiceControls.options is absent then subentries
> > are not visible to one-level and subtree search operations and
> > list operations. In LDAP, if the subentries control is absent
> > then subentries are not visible to subtree and one-level searches.
> > The means are different but the semantics are the same.
> >
> > Note that the sense of the LDAP control is the reverse of the
> > subentries bit in ServiceControls.options. The value FALSE for
> > the control is equivalent to the subentries bit being set.
> >
> > The only behavioural difference is that an LDAP base object search
> > without the subentries control sees both entries and subentries
> > while a DAP base object search without ServiceControls.options does
> > not see subentries (but should, in my opinion). However, a DAP read
> > operation sees both. If gateways translate LDAP base object searches
> > without the control into DAP reads the behaviour is the same.
> >
> > >  This
> > > difference and the
> > > subsequent control definition means that you have failed to
> > > reproduce a
> > > behaviour that exists with x500 subentries, namely the
> > > ability to recover both
> > > normal and subentries in one request.
> >
> > It isn't possible in X.500 to retrieve both entries and subentries
> > in the same request. The LDAP control is consistent with that.
> >
> 
> Steven,
> 
> Thanks for the clarification.
> 
> >
> > > I think that will be
> > > very painful for
> > > manageability.
> >
> > I haven't found it to be so.
> 
> Mmm...what you haven't had you don't miss :-), or maybe it's 
> that in x500
> you can always use the read operation.  In our implementaion of
> "subentries", we can get both and I think not being able to do that is
> unpleasant.

the baseobject search is nearly the same as the read and I think you can
return subentries in a baseobject search without the control.
> 
> >
> >
> > >
> > > How about changing the meaning of TRUE in the controlValue to
> > > mean "retrieve
> > > both normal and subentries" ?  It's still not exactly the
> > > same as x500 but it
> > > seems "usefully closer" to me.
> >
> > This would require splitting some LDAP search operations into
> > two DSP chained search operations. I want to avoid that 
> complication.
> 
> Ok, but I'm taking the same point of view for LDAP clients.

But is it really a feature what LDAP clients are looking for ? I think 90 %
of the 
clients don't want to handle subentries. All the administrative clients
which wants to work with subentries have to distinguish between Entries
and subentries and I think its easier for them when they know whether
they get subentries back or other entries and I think its a good feature
when you know that all the entries you got back are subentries / entries.

Regards

Helmut

> 
> I understand your goal in this draft is to just get the x500 
> functionality
> into LDAP and that's ok.  The thing that concerns me is how 
> easy it will be
> subsequently to make extensions (or whatever) that in my 
> opinion will make
> subentries that are good for LDAP, notably the filter and 
> retrieval points
> I've been making.
> 
> Cheers,
> Rob.
> 
> >
> 
> >
> >
> > Regards,
> > Steven
>