Subject: subentries comments

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Wed, 05 Dec 2001 16:21:13 +0100

Kurt/Stephen,

Couple of comments on
http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-01.txt.

1.  I think it's good to promote the chop scoping rules--we are seeing
more and more requests for complicated scoping for admininstrative
data.  The problem I want to point out is that in our implementation we
are used to allowing arbitrary LDAP filters for this kind of selection
of entries, so I'm concerned that the restriction of being able to
select only on objectclass could be a problem for us taking up this
definition of subentries.  Could we relax this restriction to make
specificationFilter a general LDAP filter ?  Any other possibilites ?

2. In the subentries control I think, for usability, it would be very
nice to have in addition the option to retrieve normal and subentries at
the same time, as opposed to one or the other.

Rob.

---

From: "Volpers, Helmut" <[email-masked]>
Date: Fri, 7 Dec 2001 14:57:20 +0100

Hi Rob,

I agree with Steven how the control should work.

> -----Original Message-----
> From: Rob Byrne - Sun Microsystems [mailto:[email-masked]]
> Sent: Freitag, 7. Dezember 2001 11:02
> To: [email-masked]
> Cc: 'Kurt D. Zeilenga'; [email-masked]
> 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
>