Subject: RE: Fwd: controlling visability of subentries

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 19 Oct 2000 16:39:37 +0200

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

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 4:18 PM
> To: Ed Reed
> Cc: [email-masked]; [email-masked]
> Subject: Re: Fwd: controlling visability of subentries
> 
> 
> 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
> >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.
> 
>

---

From: sanjay jain <[email-masked]>
Date: Thu, 19 Oct 2000 10:21:36 -0700

> 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) ?

---

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

>using RFC 2251 scheme to read subschema subentries) ?

Yes.  And they will have to be addressed in due course.

I suggest the LDAP subentry I-D itself not directly address issues
surrounding the LDAP subschema "entry (or subentry)" as described in
RFC 2251.  This is better left to LDAPbis efforts.

Some of the issues are:
  RFC 2251 says "subschema entry (or subentry)"
  RFC 2251 is referring to X.500's subentry
  LDAP subentry != X.500 subentry
  Support for subentries (of any flavor) is optional in LDAP
    (as currently defined).
  RFC 2251 ONLY allows "(objectClass=subschema)" and
    clients often want to apply more complex filters
    (such as an objectClasses or attributeTypes assertion)

I suggest discussing regarding the updating of RFC 2251 and
other core documents be moved to the LDAPbis mailing list
<[email-masked]>.

Kurt

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Oct 2000 14:39:27 -0400

> 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: "David A. Cahlander" <[email-masked]>
Date: Thu, 19 Oct 2000 22:33:13 -0500

Syntegra has modified the X500 directory to return an entry for a
base object search.  With X500 logic, a "read" would return the entry,
but no search would return the entry.  With the change, a base level
search returns the entry.

As I read the X500 specs, the flag to return the subentry is an exclusive
flag.  Only subentries are returned or only non-subentries are returned.
An X500 browser needed to make two calls to the directory to read all the
entries in a list command (one-level search).

We added three Syntegra specific controls to pass on the information
about subentries and operational attributes.

Return operational attributes as well as user attributes:

    #define LDAP_C_SETOPERATTR_OID  "2.16.840.1.113531.18.2.4"

Return only subentries:

    #define LDAP_C_SETSUBENTRIES_OID "2.16.840.1.113531.18.2.5"

Return normal entries as well as sub-entries:

    #define LDAP_C_SETALLENTRIES_OID "2.16.840.1.113531.18.2.11"

The complete list of controls added for X500 are:

/*
 *  Define LDAP controls.
 */
#define LDAP_C_SETOPTIONS_OID   "2.16.840.1.113531.18.2.1"
#define LDAP_C_SETDONTUSECOPY_OID "2.16.840.1.113531.18.2.2"
#define LDAP_C_SETLOCALSCOPE_OID "2.16.840.1.113531.18.2.3"
#define LDAP_C_SETOPERATTR_OID  "2.16.840.1.113531.18.2.4"
#define LDAP_C_SETSUBENTRIES_OID "2.16.840.1.113531.18.2.5"
#define LDAP_C_SETUSEALIAS_OID  "2.16.840.1.113531.18.2.6"
#define LDAP_C_SETPREFERCHAIN_OID "2.16.840.1.113531.18.2.7"
#define LDAP_C_SETX500DN_OID    "2.16.840.1.113531.18.2.8"
#define LDAP_C_SETCOPYSHALLDO_OID "2.16.840.1.113531.18.2.9"
#define LDAP_C_SETDONTMAPATTRS_OID "2.16.840.1.113531.18.2.10"
#define LDAP_C_SETALLENTRIES_OID "2.16.840.1.113531.18.2.11"

Thanks.
---
David Cahlander [email-masked]  651-415-3171

----- Original Message ----- 
From: "Mark Smith" <[email-masked]>

-- 
Mark Smith
Netscape

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 21 Oct 2000 21:17:52 +0100

Date sent:      	Thu, 19 Oct 2000 14:39:27 -0400
From:           	Mark Smith <[email-masked]>

> Perhaps.  A reasonable compromise might be to return LDAP subentries
> in these two cases:

Mark

I agree with you. If the dn of the subentry is used in a base Search 
(and the schema subentry DN can be easily got from every entry 
that holds the subschemaSubentry op attribute for example), then it 
would be churlish to not return any information just because the 
control is not set

David

> knows the name of a subentry, it might just as well be able to
> retrieve it without using any controls.  Comments?
> 
> -- 
> Mark Smith
> Netscape
> 

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************