From owner-ietf-ldup@mail.imc.org Wed Oct 18 23:59:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21656 for ; Wed, 18 Oct 2000 23:59:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06758 for ietf-ldup-bks; Wed, 18 Oct 2000 20:20:21 -0700 (PDT) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA06754 for ; Wed, 18 Oct 2000 20:20:19 -0700 (PDT) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13m6Ka-0006Tz-00 for ietf-ldup@imc.org; Wed, 18 Oct 2000 21:25:25 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 18 Oct 2000 21:25:23 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 18 Oct 2000 21:24:49 -0600 From: "Ed Reed" To: Cc: , Subject: Re: Fwd: controlling visability of subentries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA06755 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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" 08/01/00 07:41AM >>> Forwarded to LDUP list >Date: Mon, 31 Jul 2000 16:23:57 -0400 >To: ietf-ldapext@OpenLDAP.org >From: "Kurt D. Zeilenga" >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 owner-ietf-ldup@mail.imc.org Thu Oct 19 04:33:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13422 for ; Thu, 19 Oct 2000 04:33:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA13901 for ietf-ldup-bks; Thu, 19 Oct 2000 00:57:58 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13897 for ; Thu, 19 Oct 2000 00:57:56 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id e9J82ZB13254; Thu, 19 Oct 2000 10:02:36 +0200 (MET DST) Received: from pappel.mch.sni.de (pappel.mch.sni.de [139.23.81.148]) by mail2.siemens.de (8.11.0/8.11.0) with ESMTP id e9J82Z929505; Thu, 19 Oct 2000 10:02:35 +0200 (MET DST) Received: by pappel.mch.sni.de with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 10:02:32 +0200 Message-ID: From: "Volpers, Helmut" To: "'Ed Reed'" , Kurt@OpenLDAP.org Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 10:02:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:eer@OnCallDBA.COM] > Sent: Thursday, October 19, 2000 5:25 AM > To: Kurt@OpenLDAP.org > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > 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" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >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 owner-ietf-ldup@mail.imc.org Thu Oct 19 09:46:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29057 for ; Thu, 19 Oct 2000 09:46:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA23194 for ietf-ldup-bks; Thu, 19 Oct 2000 06:02:19 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23190 for ; Thu, 19 Oct 2000 06:02:18 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9JCxxD15220 for ; Thu, 19 Oct 2000 06:00:00 -0700 (PDT) Received: from netscape.com ([205.217.243.75]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G2OHRN03.BDH; Thu, 19 Oct 2000 06:06:59 -0700 Message-ID: <39EEF1F1.4345A416@netscape.com> Date: Thu, 19 Oct 2000 09:06:57 -0400 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: "Volpers Helmut" CC: "'Ed Reed'" , Kurt@OpenLDAP.org, ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Fwd: controlling visability of subentries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The problem I see with solution 2 (create a control that mimics the X511 ServiceControls) is that there would be no way for an LDAP client to discover the subset of ServiceControls that is supported on a given LDAP server. Surely we are not going to require support for everything in ServiceControls just to solve the subentry problem. Therefore, I prefer solution 1. And so everyone knows what we are talking about, from X.511: A ServiceControls parameter contains the controls, if any, that are to direct or constrain the provision of the service. ServiceControls ::= SET { options [0] BIT STRING { preferChaining (0), chainingProhibited (1), localScope (2), dontUseCopy (3), dontDereferenceAliases (4), subentries (5), copyShallDo (6), } DEFAULT {}, partialNameResolution (7), manageDSAIT (8) } } DEFAULT {}, priority [1] INTEGER { low (0), medium (1), high (2) } DEFAULT medium, timeLimit [2] INTEGER OPTIONAL, sizeLimit [3] INTEGER OPTIONAL, scopeOfReferral [4] INTEGER { dmd(0), country(1) } OPTIONAL, attributeSizeLimit [5] INTEGER OPTIONAL manageDSAITPlaneRef [6] SEQUENCE { dsaName Name, agreementID AgreementID } OPTIONAL } -- Mark Smith Netscape Communications Corp. "Volpers, Helmut" wrote: > > 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:eer@OnCallDBA.COM] > > Sent: Thursday, October 19, 2000 5:25 AM > > To: Kurt@OpenLDAP.org > > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > > 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" 08/01/00 07:41AM >>> > > Forwarded to LDUP list > > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > > >To: ietf-ldapext@OpenLDAP.org > > >From: "Kurt D. Zeilenga" > > >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 owner-ietf-ldup@mail.imc.org Thu Oct 19 10:18:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04137 for ; Thu, 19 Oct 2000 10:18:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA23750 for ietf-ldup-bks; Thu, 19 Oct 2000 06:30:28 -0700 (PDT) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23746 for ; Thu, 19 Oct 2000 06:30:26 -0700 (PDT) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13mFr9-0004GK-00 for ietf-ldup@imc.org; Thu, 19 Oct 2000 07:35:40 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 19 Oct 2000 07:35:37 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 19 Oct 2000 07:35:10 -0600 From: "Ed Reed" To: , Cc: , Subject: RE: Fwd: controlling visability of subentries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA23747 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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" 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:eer@OnCallDBA.COM] > Sent: Thursday, October 19, 2000 5:25 AM > To: Kurt@OpenLDAP.org > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > 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" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >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 owner-ietf-ldup@mail.imc.org Thu Oct 19 11:04:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09698 for ; Thu, 19 Oct 2000 11:04:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25158 for ietf-ldup-bks; Thu, 19 Oct 2000 07:13:24 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25153 for ; Thu, 19 Oct 2000 07:13:23 -0700 (PDT) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id OAA97443; Thu, 19 Oct 2000 14:18:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001018203414.00a4fe00@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 07:18:07 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Fwd: controlling visability of subentries Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 owner-ietf-ldup@mail.imc.org Thu Oct 19 11:19:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11679 for ; Thu, 19 Oct 2000 11:19:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25724 for ietf-ldup-bks; Thu, 19 Oct 2000 07:34:35 -0700 (PDT) Received: from goliath.siemens.de ([194.138.37.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25719 for ; Thu, 19 Oct 2000 07:34:32 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.0/8.11.0) with ESMTP id e9JEdfq28480; Thu, 19 Oct 2000 16:39:41 +0200 (MET DST) Received: from pappel.mch.sni.de (pappel.mch.sni.de [139.23.81.148]) by mail2.siemens.de (8.11.0/8.11.0) with ESMTP id e9JEde905588; Thu, 19 Oct 2000 16:39:40 +0200 (MET DST) Received: by pappel.mch.sni.de with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 16:39:38 +0200 Message-ID: From: "Volpers, Helmut" To: "'Kurt D. Zeilenga'" , Ed Reed Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 16:39:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:Kurt@OpenLDAP.org] > Sent: Thursday, October 19, 2000 4:18 PM > To: Ed Reed > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > 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 owner-ietf-ldup@mail.imc.org Thu Oct 19 13:21:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02306 for ; Thu, 19 Oct 2000 13:21:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04164 for ietf-ldup-bks; Thu, 19 Oct 2000 09:45:05 -0700 (PDT) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04160 for ; Thu, 19 Oct 2000 09:45:04 -0700 (PDT) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13mItV-0006CE-00 for ietf-ldup@imc.org; Thu, 19 Oct 2000 10:50:18 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 19 Oct 2000 10:50:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 19 Oct 2000 10:49:48 -0600 From: "Ed Reed" To: , Cc: , Subject: RE: Fwd: controlling visability of subentries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA04161 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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 http://www.Reed-Matthews.COM >>> "Volpers, Helmut" 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 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, October 19, 2000 4:18 PM > To: Ed Reed > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > 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 owner-ietf-ldup@mail.imc.org Thu Oct 19 13:57:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07029 for ; Thu, 19 Oct 2000 13:57:02 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA04772 for ietf-ldup-bks; Thu, 19 Oct 2000 10:17:42 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA04768 for ; Thu, 19 Oct 2000 10:17:41 -0700 (PDT) Received: (qmail 22066 invoked from network); 19 Oct 2000 17:22:24 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 19 Oct 2000 17:22:24 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Mark Smith'" , "'Volpers Helmut'" Cc: "'Ed Reed'" , , , Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 04:27:02 +1000 Message-ID: <000301c039fa$2dc709c0$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <39EEF1F1.4345A416@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Mark] The problem I see with solution 2 (create a control that mimics the X511 ServiceControls) is that there would be no way for an LDAP client to discover the subset of ServiceControls that is supported on a given LDAP server. Surely we are not going to require support for everything in ServiceControls just to solve the subentry problem. Therefore, I prefer solution 1. And so everyone knows what we are talking about, from X.511: [long list of X.511 controls snipped] [Albert] I've got no opinion either way on option 1 or option 2 as not familiar and don't have time to study it. However I question the validity of this argument against option 2. Would have thought that the usual "discovery" mechanism would work ok. Client tries to use a control, server returns error response, client that cares notes that server does not support control and caches that info for as long as they wish to. Clients that don't care don't care, so they don't try to use the control and don't get error responses. Sorry if there is some obvious flaw in that. I haven't studied the details. PS This also a "hi" to all in view of long absence. Sorry I haven't been able to respond to latest requirements doc due to other commitments (still stuck in those for a while yet). But then nobody else has either. I do believe it was a significant improvement and genuine effort to address my objections. For the record: 1. I'm assuming some means of guaranteeing eventual convergence *will* be proposed with at least an initial draft prior to final call on the requirements draft. I believe there is probably a consensus for eventual convergence and the apparant ambiguity in the requirements draft about this may be unintentional and therefore easily fixed. A fix would remove the contradictory references to non-convergent models in the final para of section 3. The whole discussion of models in section 3 is just confusing if in fact the intention is to require guaranteed eventual convergence. Model 2 should be clearly stated as *the* (only) relevant model. Actual requirements 4.1 G1 and G2 are also confusing. But the real test of whether there is in fact an intention to guarantee convergence is however whether anyone is actually working on a means to achieve it. The current URP and architecture simply does not. I still haven't seen a redraft of URP and architecture to meet the apparant consensus to support reliable eventual convergence under all circumstances. 2. My objection to non-atomicity still stands for final call but I'm assuming there is little point arguing about it further within LDUP unless others want to take it up. The draft now at least makes it possible to have serious discussion about the issue in IETF review and does include several requirements which cannot in fact be met without atomicity, such as accurate replication of access controls and attributes such as "modifiers name". although I disagree with much of the analysis in appendix B.5 and also the continued misunderstanding of applications for multi-master replication in appendix A on usage scenarios. There are still some inadequacies in presentation of the issue but the fundamental question is now simply whether or not atomicity should be a requirement rather than whether a document that shows no comprehension of the issue at all should be presented to the IETF at all. I still believe a fundamental technical mistake is being made on that question. I also still believe the requirements draft should be actively seeking input from directory users on the impact of non-atomicity. 3. I agree with the requirement 4.1 G6 for no unbounded conflict resolution records. This is a better description than "oscillation". It is not met by my MDCR draft and would need further work if in fact the current URP and architecture drafts do not come up with a means of guaranteed eventual convergence based only on timestamps. I'm not planning to do any work on it unless some interest is shown by others as a result of failure to deliver a viable URP and architecture with eventual convergence. Sorry I simply don't have time to follow up on these issues at the moment. Am just reminding that they are still there in case others want to take them up before the document goes from LDUP to IETF final call. From owner-ietf-ldup@mail.imc.org Thu Oct 19 14:03:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07872 for ; Thu, 19 Oct 2000 14:03:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04885 for ietf-ldup-bks; Thu, 19 Oct 2000 10:22:57 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04881 for ; Thu, 19 Oct 2000 10:22:56 -0700 (PDT) Received: from software.com ([207.19.203.65]) by mta1biz.bizmailsrvcs.net with ESMTP id <20001019173059.BYAZ779074.mta1biz.bizmailsrvcs.net@software.com>; Thu, 19 Oct 2000 12:30:59 -0500 Message-ID: <39EF2D9F.CB708C7@software.com> Date: Thu, 19 Oct 2000 10:21:36 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Volpers, Helmut" CC: "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Fwd: controlling visability of subentries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "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) ? > > > Helmut > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Thursday, October 19, 2000 4:18 PM > > To: Ed Reed > > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > > 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 owner-ietf-ldup@mail.imc.org Thu Oct 19 14:37:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13546 for ; Thu, 19 Oct 2000 14:37:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05919 for ietf-ldup-bks; Thu, 19 Oct 2000 10:53:33 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05915 for ; Thu, 19 Oct 2000 10:53:32 -0700 (PDT) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id RAA98797; Thu, 19 Oct 2000 17:58:16 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001019104256.00aae340@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 10:58:14 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: Fwd: controlling visability of subentries Cc: "Volpers, Helmut" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com In-Reply-To: <39EF2D9F.CB708C7@software.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:21 AM 10/19/00 -0700, 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) ? 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 . Kurt From owner-ietf-ldup@mail.imc.org Thu Oct 19 15:13:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21179 for ; Thu, 19 Oct 2000 15:13:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07340 for ietf-ldup-bks; Thu, 19 Oct 2000 11:34:49 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07328 for ; Thu, 19 Oct 2000 11:34:48 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9JIS1s12339 for ; Thu, 19 Oct 2000 11:28:01 -0700 (PDT) Received: from netscape.com ([205.217.243.75]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G2OX5U01.WJW; Thu, 19 Oct 2000 11:39:30 -0700 Message-ID: <39EF3FDF.1C86C55B@netscape.com> Date: Thu, 19 Oct 2000 14:39:27 -0400 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 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 References: <39EF2D9F.CB708C7@software.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 From owner-ietf-ldup@mail.imc.org Thu Oct 19 15:57:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00417 for ; Thu, 19 Oct 2000 15:57:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09170 for ietf-ldup-bks; Thu, 19 Oct 2000 12:26:46 -0700 (PDT) Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09166 for ; Thu, 19 Oct 2000 12:26:40 -0700 (PDT) Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA27569; Thu, 19 Oct 2000 19:26:38 GMT Received: from US-TR-EXCH-1.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id TAA07298 ; Thu, 19 Oct 2000 19:22:19 GMT Received: by us-tr-exch-1.tr.unisys.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 15:30:55 -0400 Message-ID: From: "Salter, Thomas A" To: Mark Smith , 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 Date: Thu, 19 Oct 2000 15:30:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 > From owner-ietf-ldup@mail.imc.org Thu Oct 19 20:55:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05731 for ; Thu, 19 Oct 2000 20:55:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15890 for ietf-ldup-bks; Thu, 19 Oct 2000 17:15:11 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15886 for ; Thu, 19 Oct 2000 17:15:10 -0700 (PDT) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id AAA99854; Fri, 20 Oct 2000 00:20:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.0.25.0.20001019170331.00aebdb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 17:20:18 -0700 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: Fwd: controlling visability of subentries Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com, ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-ldapbis@openldap.org > > -----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 > > From owner-ietf-ldup@mail.imc.org Thu Oct 19 22:21:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20714 for ; Thu, 19 Oct 2000 22:21:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA17439 for ietf-ldup-bks; Thu, 19 Oct 2000 18:42:36 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA17435 for ; Thu, 19 Oct 2000 18:42:33 -0700 (PDT) Received: (qmail 2822 invoked from network); 20 Oct 2000 01:50:18 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 20 Oct 2000 01:50:18 -0000 Reply-To: From: "Steven Legg" To: "'Salter, Thomas A'" Cc: , Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 12:47:59 +1100 Message-ID: <000501c03a37$c7aa6860$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Thomas, 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 > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Salter, Thomas A > Sent: Friday, 20 October 2000 6:31 > To: Mark Smith; 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 > > > 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 > > > From owner-ietf-ldup@mail.imc.org Fri Oct 20 00:13:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08806 for ; Fri, 20 Oct 2000 00:13:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA18972 for ietf-ldup-bks; Thu, 19 Oct 2000 20:28:30 -0700 (PDT) Received: from ns1.syntegra.com (ns1.syntegra.com [150.143.16.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA18968 for ; Thu, 19 Oct 2000 20:28:28 -0700 (PDT) Received: from [129.179.161.11] by ns1.cdc.com with ESMTP for ietf-ldup@imc.org; Thu, 19 Oct 2000 22:33:12 -0500 Received: from [150.143.220.130] by cdsms.cdc.com; Thu, 19 Oct 2000 22:33:09 -0500 Message-Id: <001101c03a46$7ae4a360$82dc8f96@arhdialin.cdc.com> Reply-To: "David A. Cahlander" From: "David A. Cahlander" To: "Mark Smith" , "sanjay jain" Cc: "Volpers Helmut" , "'Kurt D. Zeilenga'" , "Ed Reed" , , References: <39EF2D9F.CB708C7@software.com> <39EF3FDF.1C86C55B@netscape.com> Subject: Re: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 22:33:13 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 David.A.Cahlander@syntegra.com 651-415-3171 ----- Original Message ----- From: "Mark Smith" 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 owner-ietf-ldup@mail.imc.org Fri Oct 20 05:27:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06271 for ; Fri, 20 Oct 2000 05:27:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA04139 for ietf-ldup-bks; Fri, 20 Oct 2000 01:41:37 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA04135 for ; Fri, 20 Oct 2000 01:41:35 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id e9K8kdB12125; Fri, 20 Oct 2000 10:46:39 +0200 (MET DST) Received: from pappel.mch.sni.de (pappel.mch.sni.de [139.23.81.148]) by mail2.siemens.de (8.11.0/8.11.0) with ESMTP id e9K8kcL21951; Fri, 20 Oct 2000 10:46:38 +0200 (MET DST) Received: by pappel.mch.sni.de with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 10:46:35 +0200 Message-ID: From: "Volpers, Helmut" To: "'Salter, Thomas A'" , Mark Smith , 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 Date: Fri, 20 Oct 2000 10:46:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 > -----Original Message----- > From: Salter, Thomas A [mailto:Thomas.Salter@unisys.com] > Sent: Thursday, October 19, 2000 9:31 PM > To: Mark Smith; 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 > > > 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 > > > From owner-ietf-ldup@mail.imc.org Fri Oct 20 10:35:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24161 for ; Fri, 20 Oct 2000 10:35:15 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA13033 for ietf-ldup-bks; Fri, 20 Oct 2000 06:41:27 -0700 (PDT) Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13029 for ; Fri, 20 Oct 2000 06:41:26 -0700 (PDT) Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id NAA27518; Fri, 20 Oct 2000 13:41:23 GMT Received: from US-TR-EXCH-1.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id NAA14672 ; Fri, 20 Oct 2000 13:37:05 GMT Received: by us-tr-exch-1.tr.unisys.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 09:45:52 -0400 Message-ID: From: "Salter, Thomas A" To: steven.legg@adacel.com.au Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 09:45:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You are correct. I mistakenly equated baseObject search with Read. Tom > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Thursday, October 19, 2000 9:48 PM > To: 'Salter, Thomas A' > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: RE: Fwd: controlling visability of subentries > > > > Hi Thomas, > > 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 > > > -----Original Message----- > > From: owner-ietf-ldup@mail.imc.org > > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Salter, Thomas A > > Sent: Friday, 20 October 2000 6:31 > > To: Mark Smith; 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 > > > > > > 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 > > > > > > From owner-ietf-ldup@mail.imc.org Sat Oct 21 16:50:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23335 for ; Sat, 21 Oct 2000 16:50:33 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA03324 for ietf-ldup-bks; Sat, 21 Oct 2000 13:11:54 -0700 (PDT) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03320 for ; Sat, 21 Oct 2000 13:11:53 -0700 (PDT) Received: from dwc-acer ([62.252.108.143]) by mta07-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20001021201713.XEUK27285.mta07-svc.ntlworld.com@dwc-acer>; Sat, 21 Oct 2000 21:17:13 +0100 From: "David Chadwick" Organization: University of Salford To: "Ed Reed" , , Date: Sat, 21 Oct 2000 21:17:50 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fwd: controlling visability of subentries Reply-to: d.w.chadwick@salford.ac.uk CC: , Message-ID: <39F207FE.21899.214D7E8@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Date sent: Wed, 18 Oct 2000 21:24:49 -0600 From: "Ed Reed" To: Copies to: , 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? Ed I prefer option 1 for the following reasons i) several of the common arguments are already in LDAP e.g size limit so we dont want to add them again ii) at least one is already a LDAPv3 control e.g. manageDSAIT iii) we have had previous battles over some of the other common arguments (esp dontUseCopy) and there was no concensus to add them so it would not be sensible to add them all in one go. KISS David > > 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" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >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 > > > *************************************************** 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 D.W.Chadwick@salford.ac.uk 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 *************************************************** From owner-ietf-ldup@mail.imc.org Sat Oct 21 16:59:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24320 for ; Sat, 21 Oct 2000 16:59:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA03318 for ietf-ldup-bks; Sat, 21 Oct 2000 13:11:44 -0700 (PDT) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03314 for ; Sat, 21 Oct 2000 13:11:42 -0700 (PDT) Received: from dwc-acer ([62.252.108.143]) by mta07-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20001021201703.XETY27285.mta07-svc.ntlworld.com@dwc-acer>; Sat, 21 Oct 2000 21:17:03 +0100 From: "David Chadwick" Organization: University of Salford To: sanjay jain , Mark Smith Date: Sat, 21 Oct 2000 21:17:52 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fwd: controlling visability of subentries Reply-to: d.w.chadwick@salford.ac.uk CC: Volpers Helmut , "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Message-ID: <39F20800.22032.214DE2D@localhost> In-reply-to: <39EF3FDF.1C86C55B@netscape.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Date sent: Thu, 19 Oct 2000 14:39:27 -0400 From: Mark Smith > 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 > > 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 > *************************************************** 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 D.W.Chadwick@salford.ac.uk 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 *************************************************** From owner-ietf-ldup@mail.imc.org Wed Oct 25 03:12:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02094 for ; Wed, 25 Oct 2000 03:11:59 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA23482 for ietf-ldup-bks; Tue, 24 Oct 2000 23:32:47 -0700 (PDT) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23475 for ; Tue, 24 Oct 2000 23:32:42 -0700 (PDT) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13oKCd-00005y-00 for ietf-ldup@imc.org; Wed, 25 Oct 2000 00:38:24 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 25 Oct 2000 00:38:20 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 25 Oct 2000 00:37:46 -0600 From: "Ed Reed" To: Cc: , Subject: concensus, I think: controlling visability of subentries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA23476 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit David - I've heard several others voice the same opinion, and I'm glad to see you endorse the KISS principle, too. My reading of the concensus and arguments is to go with option 1. So be it. Ed >>> "David Chadwick" 10/21/00 02:17PM >>> Date sent: Wed, 18 Oct 2000 21:24:49 -0600 From: "Ed Reed" To: Copies to: , 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? Ed I prefer option 1 for the following reasons i) several of the common arguments are already in LDAP e.g size limit so we dont want to add them again ii) at least one is already a LDAPv3 control e.g. manageDSAIT iii) we have had previous battles over some of the other common arguments (esp dontUseCopy) and there was no concensus to add them so it would not be sensible to add them all in one go. KISS David > > 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" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >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 > > > *************************************************** 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 D.W.Chadwick@salford.ac.uk 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 *************************************************** ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM