[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Fwd: controlling visability of subentries
Your option 2 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.
> -----Original Message-----
> From: Mark Smith [mailto:mcs@netscape.com]
> Sent: Thursday, October 19, 2000 2:39 PM
> To: sanjay jain
> Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org;
> ietf-ldapext@netscape.com
> Subject: Re: Fwd: controlling visability of subentries
>
>
> sanjay jain wrote:
> >
> > "Volpers, Helmut" wrote:
> >
> > > 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 ?
> >
> > 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
>