From ldapext-bounces@ietf.org Thu Sep 2 14:01:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24140 for ; Thu, 2 Sep 2004 14:01:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2vhH-0006FS-47; Thu, 02 Sep 2004 13:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2vbp-0002tW-IN for ldapext@megatron.ietf.org; Thu, 02 Sep 2004 13:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22213 for ; Thu, 2 Sep 2004 13:42:52 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2veF-0007nm-MM for ldapext@ietf.org; Thu, 02 Sep 2004 13:45:25 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 02 Sep 2004 11:42:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 02 Sep 2004 11:41:55 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: [ldapext] A twisted extensible match proposal X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable We're thinking of proposing an extensible match to solve a particular = problem, but this matching rule sort of pushes the normal use of the = MatchingRuleAssertion.matchValue field. Here's an abstract representation of the requirement: Say I have a blacklist in the form of a DN-syntax attribute (the member = attribute is a good example) I want to search for all people with blue eyes, but I want to exclude all = people in my blacklist. So I want an extensible match where the 'type' = names the attribute which holds my blacklist and the 'matchValue' contains = the name of the object holding my blacklist. The matchValue is the part = that is twisted * it's not really the assertion value, the assertion value = is really the name of the object being tested. So if my blacklist is held = in an attribute called 'exclusions' on an entry named cn=3Dacquaintances, = this would be the string filter: (&(eyeColor=3Dblue)(!(exclusions:1.2.666:=3Dcn=3Dacquaintances))) So two questions: 1) Does this push the semantics of the MatchingRuleAssertion.matchValue = too far? 2) Is there a more obvious way to solve this problem? Thanks, Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Sep 3 01:01:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11162 for ; Fri, 3 Sep 2004 01:01:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3630-0004yT-5D; Fri, 03 Sep 2004 00:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C35rz-0000kV-5O for ldapext@megatron.ietf.org; Fri, 03 Sep 2004 00:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10037 for ; Fri, 3 Sep 2004 00:40:11 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C35uV-0001hW-RS for ldapext@ietf.org; Fri, 03 Sep 2004 00:42:52 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 4136CCFA000001B2; Fri, 3 Sep 2004 14:45:00 +1000 Message-ID: <4137F595.8080701@eb2bcom.com> Date: Fri, 03 Sep 2004 14:39:49 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] A twisted extensible match proposal References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > We're thinking of proposing an extensible match to solve a particular > problem, but this matching rule sort of pushes the normal use of the > MatchingRuleAssertion.matchValue field. > > Here's an abstract representation of the requirement: > Say I have a blacklist in the form of a DN-syntax attribute (the member > attribute is a good example) > I want to search for all people with blue eyes, but I want to exclude > all people in my blacklist. So I want an extensible match where the > 'type' names the attribute which holds my blacklist and the 'matchValue' > contains the name of the object holding my blacklist. The matchValue is > the part that is twisted * it's not really the assertion value, the > assertion value is really the name of the object being tested. So if my > blacklist is held in an attribute called 'exclusions' on an entry named > cn=acquaintances, this would be the string filter: > > (&(eyeColor=blue)(!(exclusions:1.2.666:=cn=acquaintances))) > > So two questions: >1 ) Does this push the semantics of the MatchingRuleAssertion.matchValue > too far? It pushes too far the semantics of MatchingRuleAssertion rather than matchValue. Filter items are evaluated against nominated attributes in a candidate entry, but the entries you expect to be returned typically won't have an exclusions attribute, and even if they did the attribute would be ignored. >2 ) Is there a more obvious way to solve this problem? There is a neater way. I'll let you decide whether it's obvious. What you want to know about a candidate entry is whether its DN is a member of a set of DNs that is the result of evaluating a subexpression. The recently discussed entryDN operational attribute gives us a way to nominate an entry's DN for testing. The "member of" aspect can be indicated by the matching rule, leaving the assertion value to specify the subexpression. For your purposes, the set of DNs is specified by a base entry and an attribute type with DN syntax. This is a sufficient definition for the assertion syntax: Subset ::= SEQUENCE { baseObject [0] DistinguishedName, type [1] AttributeType } So now, I would express your query like so: (&(eyeColor=blue)(!(entryDN:1.2.666:= { baseObject "cn=acquaintances", type exclusions }))) The assertion syntax is GSER encoded. Appropriate names for 1.2.666 would be "memberOf" or "withinSubset". Dereferencing of DNs within queries is something that keeps coming up and Subset could be extended to deal with other requirements. In the more general case it would be useful to be able to specify a collection of entries from which to extract DN syntax attribute values, instead of just one entry. The obvious form for that is a search filter, with scope and derefAliases for completeness. The DNs we might want to extract could also be in a component of the nominated attribute values, so we can add an optional ComponentReference. The more general Subset looks like this: Subset ::= SEQUENCE { baseObject [0] DistinguishedName, scope [1] ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) } DEFAULT baseObject, derefAliases [2] ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) } DEFAULT DerefFindingBaseObj, filter [3] Filter OPTIONAL, type [4] AttributeType, component [5] CHOICE { reference [0] ComponentReference -- [1] reserved for an alternative offered by XED -- } OPTIONAL } There's no technical reason why MatchingRuleAssertion.type and Subset.type have to refer to attributes with DN syntax. It is only necessary for them to refer to attributes with the same syntax (e.g. both Integer), with equality determined with respect to the equality matching rule of MatchingRuleAssertion.type . Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 8 18:32:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29296 for ; Wed, 8 Sep 2004 18:32:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5AvU-00032H-D3; Wed, 08 Sep 2004 18:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5AnB-0000du-FT for ldapext@megatron.ietf.org; Wed, 08 Sep 2004 18:19:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27911 for ; Wed, 8 Sep 2004 18:19:50 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Aqt-0004Y4-Oe for ldapext@ietf.org; Wed, 08 Sep 2004 18:23:45 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 08 Sep 2004 16:19:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 08 Sep 2004 16:18:47 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Subject: [ldapext] Placement of DSETypes X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I have a specific distributed data model question which affects Section = 4.1.3.1 of http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-distp= roc-00.txt . But there's a more general question that follows. The = specific question is: Can a DSE of type glue be placed immediately subordinate to a DSE of type = nssr? My assumption (when writing 4.1.3.1 above) was no. This is because = an nssr indicates that no knowledge is known of the context prefix name(s) = of the subordinate naming context(s). I've heard arguments that the names = of some subordinate context prefix might be known, but it is not known = which DSA holds it, thus an nssr is placed, and some glue might be placed = below it to bridge the gap to another cp, or maybe to a subr. So that's = the specific question. If it turns out that glue can be placed below an = nssr, then I'll amend 4.1.3.1 to include nssr as another bullet item. The general question is: What DSE types can appear below or above other = DSE types? Here's a strawman table: The X and Y axes names types of entries. The cells show the relationship = between the entry type in the Y axis and the entry type in the x axis. The = legend for the cell contents is: =B7 A means the Y axis item can be placed immediately Above the X axis = item. =B7 !A means the Y axis item can not be placed immediately Above the X = axis item =B7 B means the Y axis item can be placed immediately Below the X axis = item. =B7 !B means the Y axis item can not be placed immediately Below the X = axis item. =B7 ?A or ?B means I don't know. For now, these relationships assume that the DSE is only of the types = shown. So for example, while an entry dse may not appear immediately below = the root dse, an entry + cp dse can. It would probably be better if this = table showed 'above', 'below', and 'combined with' relationships. ImmSupr Xr Nssr Subr Entry Cp Glue Root A!B A!B A!B !A!B !A!B A!B A!B Glue ?A?B A?B !A?B !A B !A!B A!B A B Cp !A B !A B A B A B A!B !A!B Entry !A!B !A!B A B A!B A B Subr A!B A!B !A B !A!B Nssr ?A!B ?A!B !A!B Xr A B A B ImmSupr A B I can't find this information specified in any data model descriptions. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 8 22:28:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23927 for ; Wed, 8 Sep 2004 22:28:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5EVb-0003QO-OG; Wed, 08 Sep 2004 22:17:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5ETG-00038m-Se for ldapext@megatron.ietf.org; Wed, 08 Sep 2004 22:15:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18853 for ; Wed, 8 Sep 2004 22:15:32 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5EWy-0008Bw-Mv for ldapext@ietf.org; Wed, 08 Sep 2004 22:19:28 -0400 Received: from [192.168.1.156] (192.168.1.156) by micah.software-aus.com.au (7.1.016.1) id 4136CCFA00000BD6; Thu, 9 Sep 2004 12:20:19 +1000 Message-ID: <413FBC92.1020404@eb2bcom.com> Date: Thu, 09 Sep 2004 12:14:42 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Placement of DSETypes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: Quoted-Printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: Quoted-Printable Jim, The choice of a non-specific hierarchical operational binding (HOB) at a=20 superior naming context does not preclude the use of a specific HOB at a=20 subordinate naming context. Therefore, there is no reason why a glue DSE=20 should not occur below a nssr DSE. Regarding your general question about the hierarchical relationship=20 between DSEs of different types, I am not aware of an explicit=20 definition along these lines. Are you asking this with the intention of=20 including such a table as a normative reference? - Mark. Jim Sermersheim wrote: > I have a specific distributed data model question which affects Section= 4.1.3.1 of http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-di= stproc-00.txt . But there's a more general question that follows. The spe= cific question is: >=20 > Can a DSE of type glue be placed immediately subordinate to a DSE of ty= pe nssr? My assumption (when writing 4.1.3.1 above) was no. This is becau= se an nssr indicates that no knowledge is known of the context prefix nam= e(s) of the subordinate naming context(s). I've heard arguments that the = names of some subordinate context prefix might be known, but it is not kn= own which DSA holds it, thus an nssr is placed, and some glue might be pl= aced below it to bridge the gap to another cp, or maybe to a subr. So tha= t's the specific question. If it turns out that glue can be placed below = an nssr, then I'll amend 4.1.3.1 to include nssr as another bullet item. >=20 > The general question is: What DSE types can appear below or above other= DSE types? Here's a strawman table: >=20 > The X and Y axes names types of entries. The cells show the relationshi= p between the entry type in the Y axis and the entry type in the x axis. = The legend for the cell contents is: > =B7 A means the Y axis item can be placed immediately Above the X axis = item. > =B7 !A means the Y axis item can not be placed immediately Above the X = axis item > =B7 B means the Y axis item can be placed immediately Below the X axis = item. > =B7 !B means the Y axis item can not be placed immediately Below the X = axis item. > =B7 ?A or ?B means I don't know. > For now, these relationships assume that the DSE is only of the types s= hown. So for example, while an entry dse may not appear immediately below= the root dse, an entry + cp dse can. It would probably be better if this= table showed 'above', 'below', and 'combined with' relationships. >=20 > ImmSupr Xr Nssr Subr Entry Cp Glue > Root A!B A!B A!B !A!B !A!B A!B A!B > Glue ?A?B A?B !A?B !A B !A!B A!B A B > Cp !A B !A B A B A B A!B !A!B > Entry !A!B !A!B A B A!B A B > Subr A!B A!B !A B !A!B > Nssr ?A!B ?A!B !A!B > Xr A B A B > ImmSupr A B >=20 > I can't find this information specified in any data model descriptions. >=20 > Jim >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 9 00:16:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29710 for ; Thu, 9 Sep 2004 00:16:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5GKO-0001Ix-Pk; Thu, 09 Sep 2004 00:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5GGW-0008Aq-Jo for ldapext@megatron.ietf.org; Thu, 09 Sep 2004 00:10:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29298 for ; Thu, 9 Sep 2004 00:10:29 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5GKH-0001Qm-TS for ldapext@ietf.org; Thu, 09 Sep 2004 00:14:27 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 08 Sep 2004 22:09:54 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 08 Sep 2004 22:09:36 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Placement of DSETypes Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'm not sure if it would end up as a normative reference or not. It really = belongs in a yet-to-be-authored LDAP Distributed Data Model document. = Knowing what's possible in the data model will help in making the = distributed procedures doc more precise. Thanks, Jim >>> Mark Ennis 9/8/04 8:14:42 PM >>> Jim, The choice of a non-specific hierarchical operational binding (HOB) at = a=20 superior naming context does not preclude the use of a specific HOB at = a=20 subordinate naming context. Therefore, there is no reason why a glue = DSE=20 should not occur below a nssr DSE. Regarding your general question about the hierarchical relationship=20 between DSEs of different types, I am not aware of an explicit=20 definition along these lines. Are you asking this with the intention of=20 including such a table as a normative reference? - Mark. Jim Sermersheim wrote: > I have a specific distributed data model question which affects Section = 4.1.3.1 of http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-distp= roc-00.txt . But there's a more general question that follows. The = specific question is: >=20 > Can a DSE of type glue be placed immediately subordinate to a DSE of = type nssr? My assumption (when writing 4.1.3.1 above) was no. This is = because an nssr indicates that no knowledge is known of the context prefix = name(s) of the subordinate naming context(s). I've heard arguments that = the names of some subordinate context prefix might be known, but it is not = known which DSA holds it, thus an nssr is placed, and some glue might be = placed below it to bridge the gap to another cp, or maybe to a subr. So = that's the specific question. If it turns out that glue can be placed = below an nssr, then I'll amend 4.1.3.1 to include nssr as another bullet = item. >=20 > The general question is: What DSE types can appear below or above other = DSE types? Here's a strawman table: >=20 > The X and Y axes names types of entries. The cells show the relationship = between the entry type in the Y axis and the entry type in the x axis. The = legend for the cell contents is: > =B7 A means the Y axis item can be placed immediately Above the X axis = item. > =B7 !A means the Y axis item can not be placed immediately Above the X = axis item > =B7 B means the Y axis item can be placed immediately Below the X axis = item. > =B7 !B means the Y axis item can not be placed immediately Below the X = axis item. > =B7 ?A or ?B means I don't know. > For now, these relationships assume that the DSE is only of the types = shown. So for example, while an entry dse may not appear immediately below = the root dse, an entry + cp dse can. It would probably be better if this = table showed 'above', 'below', and 'combined with' relationships. >=20 > ImmSupr Xr Nssr Subr Entry Cp Glue > Root A!B A!B A!B !A!B !A!B A!B A!B > Glue ?A?B A?B !A?B !A B !A!B A!B A B > Cp !A B !A B A B A B A!B !A!B > Entry !A!B !A!B A B A!B A B > Subr A!B A!B !A B !A!B > Nssr ?A!B ?A!B !A!B > Xr A B A B > ImmSupr A B >=20 > I can't find this information specified in any data model descriptions. >=20 > Jim >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 9 19:34:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16853 for ; Thu, 9 Sep 2004 19:34:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5YQA-00089h-B8; Thu, 09 Sep 2004 19:33:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5YMp-0007Z5-U1 for ldapext@megatron.ietf.org; Thu, 09 Sep 2004 19:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16614 for ; Thu, 9 Sep 2004 19:30:12 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5YQl-00009C-OB for ldapext@ietf.org; Thu, 09 Sep 2004 19:34:21 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 4136CE6D00000ED0; Fri, 10 Sep 2004 09:38:55 +1000 Message-ID: <4140E731.3000005@eB2Bcom.com> Date: Fri, 10 Sep 2004 09:28:49 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Gabriele Garuglieri References: <41404559.9010604@infoblu.it> In-Reply-To: <41404559.9010604@infoblu.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: Ldapext Subject: [ldapext] Re: Password Policy for LDAP Directories X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Gabriele, I too have noticed this strange calculation of the warning time and sent a comment to this mailing list on the 20th November 2003. A copy of this message can be found in the archives: http://www.openldap.org/lists/ietf-ldapext/200311/msg00027.html Basically, at the end of the day, our implementation will simply return the pwdExpireWarning as the first warning value. My comments were made in regards to the -05 version of the draft. Currently the 'Password Policy for LDAP Directories' draft has expired so I am uncertain as to what the authors intend to do about this. The solution to this is certainly consistency. There are two paths that you could go down: * Consistently expire at the MaxAge time, which is how you describe IBM's solution. * Always provide a warning time of pwdExpireWarning seconds. I would argue that the way that the Tivoli Directory Server handles this is incorrect. It's my opinion, which also reflects our implementation, that the second option is preferable. For example, imagine that a server has the following rules: pwdMaxAge -> 500 seconds pwdExpireWarning -> 100 seconds And the user logs on for the first time at t=495, then they should receive a whole 100 seconds to change their password, instead of the 5 seconds that the Tivoli Directory Server would provide. Regards, ______________________________________ Andrew Sciberras eB2Bcom - Software Engineer EMail: andrew.sciberras@eb2bcom.com Web http://www.eb2bcom.com Gabriele Garuglieri wrote: > I 'm writing some java classes that are dealing with > PasswordPolicyResponseValue and i'm having some doubts about the Behera > draft. I'd be glad if someone could clarify the points that follow these > two quotes from Behera draft: > ------- > 4.3.4 pwdExpirationWarned > > This attribute contains the time when the password expiration > warning was first sent to the client. The password will expire in > the pwdExpireWarning time. > > ------- > D. Calculates whether the time before expiration warning should > be sent. > > If the pwdExpireWarning attribute is present and contains a > value, the server MUST perform the following steps. > > If the pwdExpirationWarned attribute is present and has a > time value, the warning time is the value of the > pwdExpirationWarned attribute plus the value of the > pwdExpireWarning attribute minus the current time. > > If the pwdExpirationWarned attribute is not present, the > server MUST subtract the current time from the time stored > in pwdChangedTime to arrive at the password's age. If the > age is greater than the value of the pwdMaxAge attribute > minus the value of the pwdExpireWarning attribute, the > server MUST set the current time as the value of the > pwdExpirationWarned attribute, and the warning time is the > value of pwdMaxAge minus the password's age. > ------- > > Reading the above i come to the following assumptions, please correct > me if they are wrong: > > 1- the password will expire at (pwdExpirationWarned plus > pwdExpireWarning) date. > 2- the first time i bind within the warning period, when the > pwdExpirationWarned is not yet initialized, the calculated warning time > is equal to (pwdChangedTime plus pwdMaxAge) minus current time. > 3- the second time i bind within the warning period, when the > pwdExpirationWarned is already initialized, the calculated warning time > is equal to (pwdExpirationWarned plus pwdExpireWarning) minus current > time, which is a a value surely larger than the one calculated during > the first bind. > > The last two points have the following implications: > > 4- if i calculate the expiration date using the returned warning time i > obtain two different values between first and any subsequent bind within > the warning period, which i think is not very consistent. > 5- the real expiration date can be extended well beyond the > (pwdChangedTime plus pwdMaxAge), depending on when i first bind during > the warning period, almost up to (pwdChangedTime plus pwdMaxAge plus > pwdExpireWarning) if my fist bind within the warning period falls within > the last usable second of (pwdChangedTime plus pwdMaxAge) time. > > Last but least, i'm experimenting with Tivoli Directory server 5.1, > whose behaviour seems to be happily ignoring all of the above, because > the returned warning time, independently from any pwdExpirationWarned > value, is ALWAYS (pwdChangedTime plus pwdMaxAge) minus current time. > Can, please, someone shed some light on the correct Behera draft meaning? > > Thanks, Gabriele. > > -- _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer Woodhouse Corporate Centre Suite 3, 935 Station Street Box Hill North, Victoria 3129, Australia phone: +61 3 9896 7833 fax: +61 3 9896 7801 mobile: 0412 098 771 EMail: andrew.sciberras@eb2bcom.com Web http://www.eb2bcom.com _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Sep 10 05:42:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07955 for ; Fri, 10 Sep 2004 05:42:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5hsX-0002FV-U3; Fri, 10 Sep 2004 05:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5hlc-0000xG-7F for ldapext@megatron.ietf.org; Fri, 10 Sep 2004 05:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07343 for ; Fri, 10 Sep 2004 05:32:25 -0400 (EDT) Received: from gort.hpl.hp.com ([192.6.10.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5hpd-0001tl-9u for ldapext@ietf.org; Fri, 10 Sep 2004 05:36:38 -0400 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by gort.hpl.hp.com (8.12.10/8.12.10) with ESMTP id i8A9W5j3003743 for ; Fri, 10 Sep 2004 10:32:05 +0100 (BST) Received: from dunbar-n-1.hpl.hp.com (dunbar-n-1.hpl.hp.com [15.144.26.129]) by otter.hpl.hp.com (8.9.3 (PHNE_25183+JAGae58098)/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA29920 for ; Fri, 10 Sep 2004 10:32:04 +0100 (BST) Subject: Re: [ldapext] Re: Password Policy for LDAP Directories From: Neil Dunbar To: Ldapext In-Reply-To: <4140E731.3000005@eB2Bcom.com> References: <41404559.9010604@infoblu.it> <4140E731.3000005@eB2Bcom.com> Content-Type: text/plain Organization: Directories Department, MSGD, Hewlett-Packard Company Message-Id: <1094808458.7463.20.camel@dunbar-n-1.hpl.hp.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 10:27:38 +0100 Content-Transfer-Encoding: 7bit X-HPL-MailScanner-Information: Please contact the Helpdesk for more information X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.502, required 5, autolearn=not spam, ALL_TRUSTED -0.84, AWL 0.44, BAYES_25 -1.10) X-MailScanner-From: neil.dunbar@hp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: neil.dunbar@hp.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit On Fri, 2004-09-10 at 00:28, Andrew Sciberras wrote: > The solution to this is certainly consistency. There are two paths that > you could go down: > * Consistently expire at the MaxAge time, which is how you describe > IBM's solution. > * Always provide a warning time of pwdExpireWarning seconds. > I would argue that the way that the Tivoli Directory Server handles this > is incorrect. It's my opinion, which also reflects our implementation, > that the second option is preferable. For example, imagine that a server > has the following rules: > pwdMaxAge -> 500 seconds > pwdExpireWarning -> 100 seconds > > And the user logs on for the first time at t=495, then they should > receive a whole 100 seconds to change their password, instead of the 5 > seconds that the Tivoli Directory Server would provide. Hmm. I'm not so sure. Are you saying that if you've passed the maximum age, then you go into the "grace login" period, where the only allowable operation is to change your password? If so, does that get overridden by the "number of grace logins" setting in the password policy? If not, then the maximum age of the password is not a boundary on the worthiness of the password. I'd argue that this would be a bad thing. The pwdMaxAge should be the absolute maximum time that the password can be used by anyone as a credential. The pwdExpirationWarning time, I think, should be the earliest opportunity that the directory server can warn the user that his/her password is approaching expiry. If the user comes into the expiry period late in the game - tough. You can always use the grace logins feature to allow the user with the dud password to change it after it has ceased to be a meaningful credential for general directory operations. When I prototyped the code for the password policy module for OpenLDAP, I used the same logic as the Tivoli system. I tried to make sense of the I-D, but couldn't turn it into clear code. That said, since Howard Chu of Symas rewrote the prototype into a real module, he may have altered the logic. I'll check later. Cheers, Neil _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Sep 14 21:54:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16921 for ; Tue, 14 Sep 2004 21:54:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7OyP-0001bm-Kr; Tue, 14 Sep 2004 21:52:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Ouy-0000v5-8y for ldapext@megatron.ietf.org; Tue, 14 Sep 2004 21:49:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16654 for ; Tue, 14 Sep 2004 21:49:06 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Ozv-0007KD-W6 for ldapext@ietf.org; Tue, 14 Sep 2004 21:54:19 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 4136CE6D0000183D; Wed, 15 Sep 2004 11:57:59 +1000 Message-ID: <41479F69.1020002@eB2Bcom.com> Date: Wed, 15 Sep 2004 11:48:25 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: neil.dunbar@hp.com Subject: Re: [ldapext] Re: Password Policy for LDAP Directories References: <41404559.9010604@infoblu.it> <4140E731.3000005@eB2Bcom.com> <1094808458.7463.20.camel@dunbar-n-1.hpl.hp.com> In-Reply-To: <1094808458.7463.20.camel@dunbar-n-1.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Ldapext , Gabriele Garuglieri , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Niel, Neil Dunbar wrote: > The pwdMaxAge should be the absolute maximum time that the password can > be used by anyone as a credential. The pwdExpirationWarning time, I > think, should be the earliest opportunity that the directory server can > warn the user that his/her password is approaching expiry. If the user > comes into the expiry period late in the game - tough. You can always > use the grace logins feature to allow the user with the dud password to > change it after it has ceased to be a meaningful credential for general > directory operations If someone was to implement the draft in its current form, their first warning time would indicate the time difference between the current time and the time that the password is due to expire. Subsequent logins would result in a warning time that will go beyond the specified pwdMaxAge allowing the user to receive their full warning period. Our implementation, which was based around the -05 version of the draft handled this inconsistency by returning an initial warning message of pwdExpireWarning. I've now noticed, in version -07 of the draft, that the following new line exists within the description of pwdExpireWarning: If not 0, the value must be smaller than the value of the pwdMaxAge attribute. This seriously implies that the author's intention is to ensure that the warning time does not exceed the maximum age of the password. I'm not extremely passionate about whether a user should receive their full warning period. Some consensus on this issue, and the author's opinion (Jim?) would be good though. Andrew Sciberras eB2Bcom - Software Engineer _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 22 16:34:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13464 for ; Wed, 22 Sep 2004 16:34:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CADWt-0005IM-SL; Wed, 22 Sep 2004 16:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CADCn-0007Qs-5E for ldapext@megatron.ietf.org; Wed, 22 Sep 2004 15:55:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07427 for ; Wed, 22 Sep 2004 15:55:06 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CADJP-0006Dm-Hm for ldapext@ietf.org; Wed, 22 Sep 2004 16:02:00 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 22 Sep 2004 13:54:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 22 Sep 2004 13:54:15 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [ldapext] syntax or matching rule flaw in RFC 3045 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit We were looking at implementing this and someone noticed that the syntax for the attributes is Directory String (1.3.6.1.4.1.1466.115.121.1.15) while the EQUALITY rule is caseExactIA5Match (1.3.6.1.4.1.1466.109.114.1). I assume the author was at one point using the IA5 String syntax and changed to Directory String but forgot to change the EQUALITY rule (the author doesn't work at Novell anymore or I'd ask him). We should probably update the RFC. Do other vendors who have implemented this use a caseExactMatch (2.5.13.5) for the EQUALITY? Thanks, Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 22 17:21:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16764 for ; Wed, 22 Sep 2004 17:21:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEJw-0000Ud-Ew; Wed, 22 Sep 2004 17:06:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEDy-0007Yi-Si for ldapext@megatron.ietf.org; Wed, 22 Sep 2004 17:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15519 for ; Wed, 22 Sep 2004 17:00:23 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEKb-0000LT-QC for ldapext@ietf.org; Wed, 22 Sep 2004 17:07:18 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i8ML0M4d021094; Wed, 22 Sep 2004 14:00:22 -0700 (PDT) Received: from [129.150.116.30] (vpn-129-150-116-30.UK.Sun.COM [129.150.116.30]) by odin.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i8ML0KLi003623; Wed, 22 Sep 2004 23:00:21 +0200 (MEST) Message-ID: <4151E7C7.3000502@Sun.COM> Date: Wed, 22 Sep 2004 22:59:51 +0200 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Sun Directory Server has implemented RFC 3045 with the schema as defined in the RFC. I'm not aware of any application or customer actually using the equality matching rule. The server itself doesn't (the values cannot be modified). Ludovic. Jim Sermersheim wrote: >We were looking at implementing this and someone noticed that the syntax >for the attributes is Directory String (1.3.6.1.4.1.1466.115.121.1.15) >while the EQUALITY rule is caseExactIA5Match >(1.3.6.1.4.1.1466.109.114.1). > >I assume the author was at one point using the IA5 String syntax and >changed to Directory String but forgot to change the EQUALITY rule (the >author doesn't work at Novell anymore or I'd ask him). We should >probably update the RFC. Do other vendors who have implemented this use >a caseExactMatch (2.5.13.5) for the EQUALITY? > >Thanks, > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 22 19:01:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24611 for ; Wed, 22 Sep 2004 19:01:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAG5K-0006Ld-WE; Wed, 22 Sep 2004 18:59:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAG0n-0005CX-Ed for ldapext@megatron.ietf.org; Wed, 22 Sep 2004 18:54:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24327 for ; Wed, 22 Sep 2004 18:54:54 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAG7S-0002LR-No for ldapext@ietf.org; Wed, 22 Sep 2004 19:01:51 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 22 Sep 2004 16:54:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 22 Sep 2004 16:54:01 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit or compared, or used in a filter I guess. >>> Ludovic Poitou 9/22/04 2:59:51 PM >>> Sun Directory Server has implemented RFC 3045 with the schema as defined in the RFC. I'm not aware of any application or customer actually using the equality matching rule. The server itself doesn't (the values cannot be modified). Ludovic. Jim Sermersheim wrote: >We were looking at implementing this and someone noticed that the syntax >for the attributes is Directory String (1.3.6.1.4.1.1466.115.121.1.15) >while the EQUALITY rule is caseExactIA5Match >(1.3.6.1.4.1.1466.109.114.1). > >I assume the author was at one point using the IA5 String syntax and >changed to Directory String but forgot to change the EQUALITY rule (the >author doesn't work at Novell anymore or I'd ask him). We should >probably update the RFC. Do other vendors who have implemented this use >a caseExactMatch (2.5.13.5) for the EQUALITY? > >Thanks, > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 22 19:29:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26293 for ; Wed, 22 Sep 2004 19:29:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAGOc-0001Ek-OP; Wed, 22 Sep 2004 19:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAGKe-0000lW-Ms for ldapext@megatron.ietf.org; Wed, 22 Sep 2004 19:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25392 for ; Wed, 22 Sep 2004 19:15:25 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAGRJ-0002aV-3F for ldapext@ietf.org; Wed, 22 Sep 2004 19:22:22 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 22 Sep 2004 17:14:56 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Wed, 22 Sep 2004 17:14:39 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [ldapext] when is manageDsaIT needed for the root DSE? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >From my read of X.501 (and others) is that the ManageDsaIT control is required to read and update the root DSE. If this is the case, LDAP has explicitly overriden that requirement by allowing a specific search operation* to read it, and implies that it may be updated without the use of ManageDsaIT. It seems obvious to me that when a wholeSubtree or singleLevel scope search has an empty base, that a referral is returned when the DSA is not a first-level DSA (if ManageDsaIT is not used). I also assume that an add of an object immediately subordinate to the root will also cause a referral when ManageDsaIT is not used on a anon-first-level DSA. I don't know what the behavior of a variant of the specific search operation* where a differnt filter is used should be. I also don't know what the behavior of compare should be. I'm trying to reconcile this with the distributed procedures document. It currently says: If a DSE held by a DSA meets all of the following criteria, it is said to be local to that DSA: - It is or falls (hierarchically) under and administrative point. - it is a DSE of any of the types: - root - cp - entry - alias - subentry Well, the root never falls under (nor is to my knowledge) an ap, so I should just remove it from the list. But for LDAP, it seems some exeption needs to be made for at least the specific search operation*, and maybe an exception for the modify operation on the empty DN. Or is my initial assumption just wrong? * The specific search operation is where the scope is baseObject, the base is empty, and the filter is (objectclass=*). Thanks for any clarification. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 22 19:34:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26576 for ; Wed, 22 Sep 2004 19:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAGaL-0002yp-5C; Wed, 22 Sep 2004 19:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAGPe-0001Nw-1W for ldapext@megatron.ietf.org; Wed, 22 Sep 2004 19:20:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25776 for ; Wed, 22 Sep 2004 19:20:34 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAGWJ-0002fS-Fb for ldapext@ietf.org; Wed, 22 Sep 2004 19:27:31 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8MNKWZv001205; Wed, 22 Sep 2004 23:20:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040922160844.041092b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 22 Sep 2004 16:20:46 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 12:54 PM 9/22/2004, Jim Sermersheim wrote: >We were looking at implementing this and someone noticed that the syntax >for the attributes is Directory String (1.3.6.1.4.1.1466.115.121.1.15) >while the EQUALITY rule is caseExactIA5Match >(1.3.6.1.4.1.1466.109.114.1). Yikes. This means that only assertion values in AVAs involving this attribute type are restricted to IA5. I do not believe that was intended. >I assume the author was at one point using the IA5 String syntax and >changed to Directory String but forgot to change the EQUALITY rule (the >author doesn't work at Novell anymore or I'd ask him). Last minute (and incomplete) internationalization perhaps. >We should probably update the RFC. Seems appropriate. >Do other vendors who have implemented this use >a caseExactMatch (2.5.13.5) for the EQUALITY? Current OpenLDAP code is using caseExactMatch as these attributes equality matching rule. Kurt >Thanks, > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 22 20:54:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01380 for ; Wed, 22 Sep 2004 20:54:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAHqK-0000iE-Mr; Wed, 22 Sep 2004 20:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAHoR-0000Ml-Gg for ldapext@megatron.ietf.org; Wed, 22 Sep 2004 20:50:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00851 for ; Wed, 22 Sep 2004 20:50:14 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAHv4-0003wV-WA for ldapext@ietf.org; Wed, 22 Sep 2004 20:57:11 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8N0oEZv001570; Thu, 23 Sep 2004 00:50:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040922172104.042747e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 22 Sep 2004 17:50:28 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Though I said "I disagree" over on the LDAPBIS list, in retrospect, I would have to minimally agree that a server *could* returning the rootDSE in response to subtree manageDsaIt search. RFC 3296 says: The control MAY cause other objects to be treated as normal entries as defined by subsequent documents. While there is no subsequent document stating how this control would cause rootDSE to be treated as a normal entry, I think it reasonable that some subsequent document could state how. I would hope that any such document would state a how consistent with X.511(97) manageDsaIt service. Are you able to reconcile things if you assume that the rootDSE is treated as a normal object in manageDsaIT searches with baseObject=""? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 05:33:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25836 for ; Thu, 23 Sep 2004 05:33:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPrC-0004Wo-E6; Thu, 23 Sep 2004 05:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPoY-0003rh-Je for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 05:22:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25311 for ; Thu, 23 Sep 2004 05:22:56 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAPvI-0003aP-IN for ldapext@ietf.org; Thu, 23 Sep 2004 05:29:57 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8N9Mt53025364; Thu, 23 Sep 2004 03:22:56 -0600 (MDT) Received: from [129.157.211.132] (dhcp-gnb07-211-132 [129.157.211.132]) by odin.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i8N9MsLi021588; Thu, 23 Sep 2004 11:22:55 +0200 (MEST) Message-ID: <415295D8.3060109@Sun.COM> Date: Thu, 23 Sep 2004 11:22:32 +0200 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >or compared, or used in a filter I guess. > > Correct. I've never heard of an app doing this so far. But RFC 3045 is very discreet and customers hardly noticed it. I don't have any issue with changing it to CaseExactMatch. Ludovic. > > >>>>Ludovic Poitou 9/22/04 2:59:51 PM >>> >>>> >>>> >Sun Directory Server has implemented RFC 3045 with the schema as >defined >in the RFC. >I'm not aware of any application or customer actually using the >equality >matching rule. >The server itself doesn't (the values cannot be modified). > >Ludovic. > > >Jim Sermersheim wrote: > > > >>We were looking at implementing this and someone noticed that the >> >> >syntax > > >>for the attributes is Directory String >> >> >(1.3.6.1.4.1.1466.115.121.1.15) > > >>while the EQUALITY rule is caseExactIA5Match >>(1.3.6.1.4.1.1466.109.114.1). >> >>I assume the author was at one point using the IA5 String syntax and >>changed to Directory String but forgot to change the EQUALITY rule >> >> >(the > > >>author doesn't work at Novell anymore or I'd ask him). We should >>probably update the RFC. Do other vendors who have implemented this >> >> >use > > >>a caseExactMatch (2.5.13.5) for the EQUALITY? >> >>Thanks, >> >>Jim >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> >> > > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 08:44:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08507 for ; Thu, 23 Sep 2004 08:44:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASti-0002LZ-RC; Thu, 23 Sep 2004 08:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASmq-0001vL-2r for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 08:33:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06949 for ; Thu, 23 Sep 2004 08:33:22 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAStb-0006ra-U5 for ldapext@ietf.org; Thu, 23 Sep 2004 08:40:25 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8NCWoRK610390 for ; Thu, 23 Sep 2004 08:32:50 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8NCY3al150872 for ; Thu, 23 Sep 2004 08:34:04 -0400 In-Reply-To: Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Thu, 23 Sep 2004 07:32:49 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V70_M2_07222004 Beta 2|July 22, 2004) at 09/23/2004 07:32:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org We didn't bother to put the root DSE attributes in our schema. Server behavior is hard-coded and wouldn't be affected by the proposed change. John McMeeking (Document link: John McMeeking) ldapext-bounces@ietf.org wrote on 09/22/2004 02:54:15 PM: > We were looking at implementing this and someone noticed that the syntax > for the attributes is Directory String (1.3.6.1.4.1.1466.115.121.1.15) > while the EQUALITY rule is caseExactIA5Match > (1.3.6.1.4.1.1466.109.114.1). > > I assume the author was at one point using the IA5 String syntax and > changed to Directory String but forgot to change the EQUALITY rule (the > author doesn't work at Novell anymore or I'd ask him). We should > probably update the RFC. Do other vendors who have implemented this use > a caseExactMatch (2.5.13.5) for the EQUALITY? > > Thanks, > > Jim > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 17:39:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25976 for ; Thu, 23 Sep 2004 17:39:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAb61-0001dw-FQ; Thu, 23 Sep 2004 17:25:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAaxs-0007op-OK for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 17:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23835 for ; Thu, 23 Sep 2004 17:17:17 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAb4i-0002Iu-Ni for ldapext@ietf.org; Thu, 23 Sep 2004 17:24:26 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 15:16:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 15:16:25 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I can reconcile some things, but not others. It's the inverse that is the = problem * in the absense of manageDsaIT, when is the root to be treated as = a normal object? I *think* X.500 says never, and LDAP special cased read, and sort of left = the door open for special casing write. I was hoping that an X.500 vendor with an LDAP front-end could clarify (as = they would have implemented the X.500 semantics, and the LDAP front-end = would have done something to special case where needed). Another question is: Assume an alias object which has = an aliasedObjectName set to the empty DN. If a base-scope search is rooted = at that alias, the filter is (objectclass=3D*), and derefAliases is = derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could = be read either way. What I wanted to do with the distproc I-D was give a simple, straight = forward way of determining whether a DSE reresents a normal object (in the = absense of manageDsaIT).=20 Jim >>> "Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> Though I said "I disagree" over on the LDAPBIS list, in retrospect, I would have to minimally agree that a server *could* returning the rootDSE in response to subtree manageDsaIt search. RFC 3296 says: The control MAY cause other objects to be treated as normal entries as defined by subsequent documents. While there is no subsequent document stating how this control would cause rootDSE to be treated as a normal entry, I think it reasonable that some subsequent document could state how. I would hope that any such document would state a how consistent with X.511(97) manageDsaIt service. Are you able to reconcile things if you assume that the rootDSE is treated as a normal object in manageDsaIT searches with baseObject=3D""?=20 Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 18:02:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27464 for ; Thu, 23 Sep 2004 18:02:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbOb-0001bq-3E; Thu, 23 Sep 2004 17:44:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbDS-0003AV-FS for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 17:33:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25325 for ; Thu, 23 Sep 2004 17:33:23 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAbKJ-0002l2-I9 for ldapext@ietf.org; Thu, 23 Sep 2004 17:40:32 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8NLXMZv007486; Thu, 23 Sep 2004 21:33:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040923142822.0423c8c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 23 Sep 2004 14:33:34 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >I can reconcile some things, but not others. It's the inverse that is the problem * in the absense of manageDsaIT, when is the root to be treated as a normal object? > >I *think* X.500 says never, and LDAP special cased read, and sort of left the door open for special casing write. > >I was hoping that an X.500 vendor with an LDAP front-end could clarify (as they would have implemented the X.500 semantics, and the LDAP front-end would have done something to special case where needed). > >Another question is: Assume an alias object which has an aliasedObjectName set to the empty DN. One could consider this invalid. aliasObjectName is suppose to refer an object entry (or possibly another alias entry). Having an alias refer to a root DSE, which is not part of the DIT, makes no (or, at most, little) sense. >If a base-scope search is rooted at that alias, the filter is (objectclass=*), and derefAliases is derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could be read either way. I would think the server would return some sort of aliasing error here. (I believe the OpenLDAP server does.) >What I wanted to do with the distproc I-D was give a simple, straight forward way of determining whether a DSE reresents a normal object (in the absense of manageDsaIT). > >Jim > >>>> "Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >Though I said "I disagree" over on the LDAPBIS list, in >retrospect, I would have to minimally agree that a server >*could* returning the rootDSE in response to subtree >manageDsaIt search. RFC 3296 says: > The control MAY cause other objects to be treated as > normal entries as defined by subsequent documents. > >While there is no subsequent document stating how this >control would cause rootDSE to be treated as a normal >entry, I think it reasonable that some subsequent document >could state how. I would hope that any such document >would state a how consistent with X.511(97) manageDsaIt >service. > >Are you able to reconcile things if you assume that >the rootDSE is treated as a normal object in >manageDsaIT searches with baseObject=""? > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 18:55:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02723 for ; Thu, 23 Sep 2004 18:55:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAcJa-00034a-Ez; Thu, 23 Sep 2004 18:43:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAcAu-0001Gf-Oq for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 18:34:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00855 for ; Thu, 23 Sep 2004 18:34:49 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAcHl-0003xD-7N for ldapext@ietf.org; Thu, 23 Sep 2004 18:41:59 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 16:34:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 16:33:56 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable True, if there is a check to validate that aliasedObjectName points to an = entry or alias DSE, this should just result in an error. So, getting back to my original question * does anyone know if X.500 = allows access to the root DSE without the use of ManageDsaIT? Jim >>> "Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >I can reconcile some things, but not others. It's the inverse that is the = problem * in the absense of manageDsaIT, when is the root to be treated as = a normal object? > >I *think* X.500 says never, and LDAP special cased read, and sort of left = the door open for special casing write. > >I was hoping that an X.500 vendor with an LDAP front-end could clarify = (as they would have implemented the X.500 semantics, and the LDAP = front-end would have done something to special case where needed). > >Another question is: Assume an alias object which = has an aliasedObjectName set to the empty DN. One could consider this invalid. aliasObjectName is suppose to refer an object entry (or possibly another alias entry). Having an alias refer to a root DSE, which is not part of the DIT, makes no (or, at most, little) sense. >If a base-scope search is rooted at that alias, the filter is (objectclass= =3D*), and derefAliases is derefFindingBaseObj, what is the proper = behavior? I think RFC 2251 could be read either way. I would think the server would return some sort of aliasing error here. (I believe the OpenLDAP server does.) >What I wanted to do with the distproc I-D was give a simple, straight = forward way of determining whether a DSE reresents a normal object (in the = absense of manageDsaIT).=20 > >Jim > >>>> "Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >Though I said "I disagree" over on the LDAPBIS list, in >retrospect, I would have to minimally agree that a server >*could* returning the rootDSE in response to subtree >manageDsaIt search. RFC 3296 says: > The control MAY cause other objects to be treated as > normal entries as defined by subsequent documents. > >While there is no subsequent document stating how this >control would cause rootDSE to be treated as a normal >entry, I think it reasonable that some subsequent document >could state how. I would hope that any such document >would state a how consistent with X.511(97) manageDsaIt >service. > >Are you able to reconcile things if you assume that >the rootDSE is treated as a normal object in >manageDsaIT searches with baseObject=3D""?=20 > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 20:15:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06966 for ; Thu, 23 Sep 2004 20:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAdiP-0007Lt-3D; Thu, 23 Sep 2004 20:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAdh9-00079j-8p for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 20:12:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06799 for ; Thu, 23 Sep 2004 20:12:13 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAdo1-0005bW-Q8 for ldapext@ietf.org; Thu, 23 Sep 2004 20:19:22 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 18:11:43 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 18:11:26 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Thinking more about the alias thing; an alias should be allowed to point to a glue DSE. I couldn't find anything in X.501 that said an alias must only point to DSETypes of entry or alias. Just that it points to an object entry or an alias entry. It further confuses things when it says: "The root is not an entry as such, but can, where convenient to do so [e.g. in the definitions of b) and c) below], be viewed as a null object entry [see d) below];" I assume it's not convenient to view the root as a 'null object entry' when it's being referenced by an alias entry :-) >>> "Jim Sermersheim" 9/23/04 4:33:56 PM >>> True, if there is a check to validate that aliasedObjectName points to an entry or alias DSE, this should just result in an error. So, getting back to my original question * does anyone know if X.500 allows access to the root DSE without the use of ManageDsaIT? Jim >>> "Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >I can reconcile some things, but not others. It's the inverse that is the problem * in the absense of manageDsaIT, when is the root to be treated as a normal object? > >I *think* X.500 says never, and LDAP special cased read, and sort of left the door open for special casing write. > >I was hoping that an X.500 vendor with an LDAP front-end could clarify (as they would have implemented the X.500 semantics, and the LDAP front-end would have done something to special case where needed). > >Another question is: Assume an alias object which has an aliasedObjectName set to the empty DN. One could consider this invalid. aliasObjectName is suppose to refer an object entry (or possibly another alias entry). Having an alias refer to a root DSE, which is not part of the DIT, makes no (or, at most, little) sense. >If a base-scope search is rooted at that alias, the filter is (objectclass=*), and derefAliases is derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could be read either way. I would think the server would return some sort of aliasing error here. (I believe the OpenLDAP server does.) >What I wanted to do with the distproc I-D was give a simple, straight forward way of determining whether a DSE reresents a normal object (in the absense of manageDsaIT). > >Jim > >>>> "Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >Though I said "I disagree" over on the LDAPBIS list, in >retrospect, I would have to minimally agree that a server >*could* returning the rootDSE in response to subtree >manageDsaIt search. RFC 3296 says: > The control MAY cause other objects to be treated as > normal entries as defined by subsequent documents. > >While there is no subsequent document stating how this >control would cause rootDSE to be treated as a normal >entry, I think it reasonable that some subsequent document >could state how. I would hope that any such document >would state a how consistent with X.511(97) manageDsaIt >service. > >Are you able to reconcile things if you assume that >the rootDSE is treated as a normal object in >manageDsaIT searches with baseObject=""? > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 20:25:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07349 for ; Thu, 23 Sep 2004 20:25:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAdqy-0008K0-LA; Thu, 23 Sep 2004 20:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAdqC-0008Df-VK for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 20:21:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07191 for ; Thu, 23 Sep 2004 20:21:35 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAdx5-0005jc-SW for ldapext@ietf.org; Thu, 23 Sep 2004 20:28:44 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8O0LYZv008316; Fri, 24 Sep 2004 00:21:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040923171742.040ac6b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 23 Sep 2004 17:21:46 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 05:11 PM 9/23/2004, Jim Sermersheim wrote: >Thinking more about the alias thing; an alias should be allowed to point >to a glue DSE. I'd argue that such an alias is not pointing at the glue, but the object/alias entry that the glue entry is providing glue for. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 20:42:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08193 for ; Thu, 23 Sep 2004 20:42:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAe4W-0001Gn-7K; Thu, 23 Sep 2004 20:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAe3j-00018S-9L for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 20:35:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07878 for ; Thu, 23 Sep 2004 20:35:33 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAeAY-0005vw-Qi for ldapext@ietf.org; Thu, 23 Sep 2004 20:42:42 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 4136CCFA00002915; Fri, 24 Sep 2004 10:40:06 +1000 Message-ID: <41536BA7.8020105@eb2bcom.com> Date: Fri, 24 Sep 2004 10:34:47 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Kurt@OpenLDAP.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > True, if there is a check to validate that aliasedObjectName points to an entry > or alias DSE, this should just result in an error. > > So, getting back to my original question * does anyone know if X.500 allows access > to the root DSE without the use of ManageDsaIT? I believe X.500 does not allow the root DSE (or any glue entry for that matter) to be visible except when manageDSAIT is used. This is how our implementation works for DAP and DSP. In LDAP we special-case a baseObject search of the root DSE. Regards, Steven > > Jim > > >>>>"Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> > > At 02:16 PM 9/23/2004, Jim Sermersheim wrote: > >>I can reconcile some things, but not others. It's the inverse that is the problem * in the absense of manageDsaIT, when is the root to be treated as a normal object? >> >>I *think* X.500 says never, and LDAP special cased read, and sort of left the door open for special casing write. >> >>I was hoping that an X.500 vendor with an LDAP front-end could clarify (as they would have implemented the X.500 semantics, and the LDAP front-end would have done something to special case where needed). >> >>Another question is: Assume an alias object which has an aliasedObjectName set to the empty DN. > > > One could consider this invalid. aliasObjectName is suppose to > refer an object entry (or possibly another alias entry). Having > an alias refer to a root DSE, which is not part of the DIT, > makes no (or, at most, little) sense. > > >>If a base-scope search is rooted at that alias, the filter is (objectclass=*), and derefAliases is derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could be read either way. > > > I would think the server would return some sort of aliasing > error here. (I believe the OpenLDAP server does.) > > >>What I wanted to do with the distproc I-D was give a simple, straight forward way of determining whether a DSE reresents a normal object (in the absense of manageDsaIT). >> >>Jim >> >> >>>>>"Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >> >>Though I said "I disagree" over on the LDAPBIS list, in >>retrospect, I would have to minimally agree that a server >>*could* returning the rootDSE in response to subtree >>manageDsaIt search. RFC 3296 says: >> The control MAY cause other objects to be treated as >> normal entries as defined by subsequent documents. >> >>While there is no subsequent document stating how this >>control would cause rootDSE to be treated as a normal >>entry, I think it reasonable that some subsequent document >>could state how. I would hope that any such document >>would state a how consistent with X.511(97) manageDsaIt >>service. >> >>Are you able to reconcile things if you assume that >>the rootDSE is treated as a normal object in >>manageDsaIT searches with baseObject=""? >> >>Kurt > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 20:57:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08871 for ; Thu, 23 Sep 2004 20:57:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAeMu-0003h6-L0; Thu, 23 Sep 2004 20:55:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAeKz-0003Q6-GT for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 20:53:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08618 for ; Thu, 23 Sep 2004 20:53:23 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAeRr-00069M-Sq for ldapext@ietf.org; Thu, 23 Sep 2004 21:00:33 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 18:52:53 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 18:52:37 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I agree conceptually. But when describing the steps for determining suitability of the pointed-to object in technical terms, you'd kind of have to say "aliasedObjectName can point to a glue DSE, but not the root DSE." >>> "Kurt D. Zeilenga" 9/23/04 6:21:46 PM >>> At 05:11 PM 9/23/2004, Jim Sermersheim wrote: >Thinking more about the alias thing; an alias should be allowed to point >to a glue DSE. I'd argue that such an alias is not pointing at the glue, but the object/alias entry that the glue entry is providing glue for. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 21:00:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08990 for ; Thu, 23 Sep 2004 21:00:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAePz-000445-8J; Thu, 23 Sep 2004 20:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAeOp-0003qP-0S for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 20:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08814 for ; Thu, 23 Sep 2004 20:57:20 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAeVi-0006DY-5h for ldapext@ietf.org; Thu, 23 Sep 2004 21:04:30 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 18:56:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 18:56:28 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: Kurt@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks Steven, Does your implementation allow updates to attributes of the root DSE? If so, does it allow LDAP to perform updates without ManageDsaIT? >>> Steven Legg 9/23/04 6:34:47 PM >>> Jim, Jim Sermersheim wrote: > True, if there is a check to validate that aliasedObjectName points to an entry > or alias DSE, this should just result in an error. > > So, getting back to my original question * does anyone know if X.500 allows access > to the root DSE without the use of ManageDsaIT? I believe X.500 does not allow the root DSE (or any glue entry for that matter) to be visible except when manageDSAIT is used. This is how our implementation works for DAP and DSP. In LDAP we special-case a baseObject search of the root DSE. Regards, Steven > > Jim > > >>>>"Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> > > At 02:16 PM 9/23/2004, Jim Sermersheim wrote: > >>I can reconcile some things, but not others. It's the inverse that is the problem * in the absense of manageDsaIT, when is the root to be treated as a normal object? >> >>I *think* X.500 says never, and LDAP special cased read, and sort of left the door open for special casing write. >> >>I was hoping that an X.500 vendor with an LDAP front-end could clarify (as they would have implemented the X.500 semantics, and the LDAP front-end would have done something to special case where needed). >> >>Another question is: Assume an alias object which has an aliasedObjectName set to the empty DN. > > > One could consider this invalid. aliasObjectName is suppose to > refer an object entry (or possibly another alias entry). Having > an alias refer to a root DSE, which is not part of the DIT, > makes no (or, at most, little) sense. > > >>If a base-scope search is rooted at that alias, the filter is (objectclass=*), and derefAliases is derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could be read either way. > > > I would think the server would return some sort of aliasing > error here. (I believe the OpenLDAP server does.) > > >>What I wanted to do with the distproc I-D was give a simple, straight forward way of determining whether a DSE reresents a normal object (in the absense of manageDsaIT). >> >>Jim >> >> >>>>>"Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >> >>Though I said "I disagree" over on the LDAPBIS list, in >>retrospect, I would have to minimally agree that a server >>*could* returning the rootDSE in response to subtree >>manageDsaIt search. RFC 3296 says: >> The control MAY cause other objects to be treated as >> normal entries as defined by subsequent documents. >> >>While there is no subsequent document stating how this >>control would cause rootDSE to be treated as a normal >>entry, I think it reasonable that some subsequent document >>could state how. I would hope that any such document >>would state a how consistent with X.511(97) manageDsaIt >>service. >> >>Are you able to reconcile things if you assume that >>the rootDSE is treated as a normal object in >>manageDsaIT searches with baseObject=""? >> >>Kurt > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 21:36:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10847 for ; Thu, 23 Sep 2004 21:36:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAevR-00083w-SE; Thu, 23 Sep 2004 21:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAetW-0007pu-Qj for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 21:29:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10584 for ; Thu, 23 Sep 2004 21:29:04 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAf0M-0006f5-IH for ldapext@ietf.org; Thu, 23 Sep 2004 21:36:14 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 4136CCFA00002955; Fri, 24 Sep 2004 11:33:55 +1000 Message-ID: <41537845.8020907@eb2bcom.com> Date: Fri, 24 Sep 2004 11:28:37 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > Thanks Steven, > > Does your implementation allow updates to attributes of the root DSE? Yes. In DAP, only if manageDSAIT is used. > If so, does it allow LDAP to perform updates without ManageDsaIT? We allow modifies of the root DSE in LDAP with or without manageDSAIT. Our implementation always has a root DSE, so add entry and remove entry on the root name are disallowed. ModifyDN is disallowed for obvious reasons. Glue entries can only be updated if manageDSAIT is used. Regards, Steven > >>>>Steven Legg 9/23/04 6:34:47 PM >>> > > > Jim, > > Jim Sermersheim wrote: > > >>True, if there is a check to validate that aliasedObjectName points > > to an entry > > or alias DSE, this should just result in an error. > >>So, getting back to my original question * does anyone know if X.500 > > allows access > > to the root DSE without the use of ManageDsaIT? > > I believe X.500 does not allow the root DSE (or any glue entry for that > matter) to > be visible except when manageDSAIT is used. This is how our > implementation works > for DAP and DSP. In LDAP we special-case a baseObject search of the > root DSE. > > Regards, > Steven > > >>Jim >> >> >> >>>>>"Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> >> >>At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >> >> >>>I can reconcile some things, but not others. It's the inverse that is > > the problem * in the absense of manageDsaIT, when is the root to be > treated as a normal object? > >>>I *think* X.500 says never, and LDAP special cased read, and sort of > > left the door open for special casing write. > >>>I was hoping that an X.500 vendor with an LDAP front-end could > > clarify (as they would have implemented the X.500 semantics, and the > LDAP front-end would have done something to special case where needed). > >>>Another question is: Assume an alias object which > > has an aliasedObjectName set to the empty DN. > >> >>One could consider this invalid. aliasObjectName is suppose to >>refer an object entry (or possibly another alias entry). Having >>an alias refer to a root DSE, which is not part of the DIT, >>makes no (or, at most, little) sense. >> >> >> >>>If a base-scope search is rooted at that alias, the filter is > > (objectclass=*), and derefAliases is derefFindingBaseObj, what is the > proper behavior? I think RFC 2251 could be read either way. > >> >>I would think the server would return some sort of aliasing >>error here. (I believe the OpenLDAP server does.) >> >> >> >>>What I wanted to do with the distproc I-D was give a simple, straight > > forward way of determining whether a DSE reresents a normal object (in > the absense of manageDsaIT). > >>>Jim >>> >>> >>> >>>>>>"Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >>> >>>Though I said "I disagree" over on the LDAPBIS list, in >>>retrospect, I would have to minimally agree that a server >>>*could* returning the rootDSE in response to subtree >>>manageDsaIt search. RFC 3296 says: >>> The control MAY cause other objects to be treated as >>> normal entries as defined by subsequent documents. >>> >>>While there is no subsequent document stating how this >>>control would cause rootDSE to be treated as a normal >>>entry, I think it reasonable that some subsequent document >>>could state how. I would hope that any such document >>>would state a how consistent with X.511(97) manageDsaIt >>>service. >>> >>>Are you able to reconcile things if you assume that >>>the rootDSE is treated as a normal object in >>>manageDsaIT searches with baseObject=""? >>> >>>Kurt >> >> >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext >> >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext >> > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 21:56:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12236 for ; Thu, 23 Sep 2004 21:56:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfIB-0002GI-4g; Thu, 23 Sep 2004 21:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAf91-00010g-PC for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 21:45:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11228 for ; Thu, 23 Sep 2004 21:45:05 -0400 (EDT) Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfFv-0006qB-7Z for ldapext@ietf.org; Thu, 23 Sep 2004 21:52:15 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by mail17.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Sep 2004 11:44:33 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] when is manageDsaIT needed for the root DSE? Date: Fri, 24 Sep 2004 11:44:33 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101D5994C@ausyms21.ca.com> Thread-Topic: [ldapext] when is manageDsaIT needed for the root DSE? Thread-Index: AcShy63seh/VYG0SQz+M0DGj4TUbygACnN4A From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 24 Sep 2004 01:44:33.0933 (UTC) FILETIME=[0ACB73D0:01C4A1D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Jim, I don't understand this talk about the root DSE in X.500. I would have = thought that "The root is not an entry" is clear enough? Do you have a = reference to any section other than 7.4 which talks about the root DSE? = I believe 7.4 is simply talking about the graph, not about the DIT. 9.7 says "It also proves convenient to define the 'distinguished name' of the = root, although this can never be the distinguished name of an object. The distinguished name of the root is defined to be an = empty sequence." In summary, I don't believe there is any such thing as the root DSE in = X.500. Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Friday, 24 September 2004 10:11 To: ldapext@ietf.org Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Thinking more about the alias thing; an alias should be allowed to point to a glue DSE. I couldn't find anything in X.501 that said an alias must only point to DSETypes of entry or alias. Just that it points to an object entry or an alias entry. It further confuses things when it says: "The root is not an entry as such, but can, where convenient to do so [e.g. in the definitions of b) and c) below], be viewed as a null object entry [see d) below];" I assume it's not convenient to view the root as a 'null object entry' when it's being referenced by an alias entry :-) >>> "Jim Sermersheim" 9/23/04 4:33:56 PM >>> True, if there is a check to validate that aliasedObjectName points to an entry or alias DSE, this should just result in an error. So, getting back to my original question * does anyone know if X.500 allows access to the root DSE without the use of ManageDsaIT? Jim >>> "Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >I can reconcile some things, but not others. It's the inverse that is the problem * in the absense of manageDsaIT, when is the root to be treated as a normal object? > >I *think* X.500 says never, and LDAP special cased read, and sort of left the door open for special casing write. > >I was hoping that an X.500 vendor with an LDAP front-end could clarify (as they would have implemented the X.500 semantics, and the LDAP front-end would have done something to special case where needed). > >Another question is: Assume an alias object which has an aliasedObjectName set to the empty DN. One could consider this invalid. aliasObjectName is suppose to refer an object entry (or possibly another alias entry). Having an alias refer to a root DSE, which is not part of the DIT, makes no (or, at most, little) sense. >If a base-scope search is rooted at that alias, the filter is (objectclass=3D*), and derefAliases is derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could be read either way. I would think the server would return some sort of aliasing error here. (I believe the OpenLDAP server does.) >What I wanted to do with the distproc I-D was give a simple, straight forward way of determining whether a DSE reresents a normal object (in the absense of manageDsaIT).=20 > >Jim > >>>> "Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >Though I said "I disagree" over on the LDAPBIS list, in >retrospect, I would have to minimally agree that a server >*could* returning the rootDSE in response to subtree >manageDsaIt search. RFC 3296 says: > The control MAY cause other objects to be treated as > normal entries as defined by subsequent documents. > >While there is no subsequent document stating how this >control would cause rootDSE to be treated as a normal >entry, I think it reasonable that some subsequent document >could state how. I would hope that any such document >would state a how consistent with X.511(97) manageDsaIt >service. > >Are you able to reconcile things if you assume that >the rootDSE is treated as a normal object in >manageDsaIT searches with baseObject=3D""?=20 > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 21:57:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12339 for ; Thu, 23 Sep 2004 21:57:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfIO-0002LZ-Ib; Thu, 23 Sep 2004 21:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfC3-0001K5-2d for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 21:48:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11496 for ; Thu, 23 Sep 2004 21:48:12 -0400 (EDT) Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfIw-0006tP-NQ for ldapext@ietf.org; Thu, 23 Sep 2004 21:55:23 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by mail17.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Sep 2004 11:47:42 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] when is manageDsaIT needed for the root DSE? Date: Fri, 24 Sep 2004 11:47:42 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101D59959@ausyms21.ca.com> Thread-Topic: [ldapext] when is manageDsaIT needed for the root DSE? Thread-Index: AcShz1SyqXMKI0ttQLW/a2zAYCpVGQACQCzw From: "Ramsay, Ron" To: "Steven Legg" , "Jim Sermersheim" X-OriginalArrivalTime: 24 Sep 2004 01:47:42.0805 (UTC) FILETIME=[7B5F0850:01C4A1D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: Kurt@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Steven, Could you please tell me where in the X.500 documents this root DSE is = described? Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Steven Legg Sent: Friday, 24 September 2004 10:35 To: Jim Sermersheim Cc: ldapext@ietf.org; Kurt@OpenLDAP.org Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Jim, Jim Sermersheim wrote: > True, if there is a check to validate that aliasedObjectName points to = an entry > or alias DSE, this should just result in an error. >=20 > So, getting back to my original question * does anyone know if X.500 = allows access > to the root DSE without the use of ManageDsaIT? I believe X.500 does not allow the root DSE (or any glue entry for that = matter) to be visible except when manageDSAIT is used. This is how our = implementation works for DAP and DSP. In LDAP we special-case a baseObject search of the root = DSE. Regards, Steven >=20 > Jim >=20 >=20 >>>>"Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> >=20 > At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >=20 >>I can reconcile some things, but not others. It's the inverse that is = the problem * in the absense of manageDsaIT, when is the root to be = treated as a normal object? >> >>I *think* X.500 says never, and LDAP special cased read, and sort of = left the door open for special casing write. >> >>I was hoping that an X.500 vendor with an LDAP front-end could clarify = (as they would have implemented the X.500 semantics, and the LDAP = front-end would have done something to special case where needed). >> >>Another question is: Assume an alias object which = has an aliasedObjectName set to the empty DN. >=20 >=20 > One could consider this invalid. aliasObjectName is suppose to > refer an object entry (or possibly another alias entry). Having > an alias refer to a root DSE, which is not part of the DIT, > makes no (or, at most, little) sense. >=20 >=20 >>If a base-scope search is rooted at that alias, the filter is = (objectclass=3D*), and derefAliases is derefFindingBaseObj, what is the = proper behavior? I think RFC 2251 could be read either way. >=20 >=20 > I would think the server would return some sort of aliasing > error here. (I believe the OpenLDAP server does.) >=20 >=20 >>What I wanted to do with the distproc I-D was give a simple, straight = forward way of determining whether a DSE reresents a normal object (in = the absense of manageDsaIT).=20 >> >>Jim >> >> >>>>>"Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >> >>Though I said "I disagree" over on the LDAPBIS list, in >>retrospect, I would have to minimally agree that a server >>*could* returning the rootDSE in response to subtree >>manageDsaIt search. RFC 3296 says: >> The control MAY cause other objects to be treated as >> normal entries as defined by subsequent documents. >> >>While there is no subsequent document stating how this >>control would cause rootDSE to be treated as a normal >>entry, I think it reasonable that some subsequent document >>could state how. I would hope that any such document >>would state a how consistent with X.511(97) manageDsaIt >>service. >> >>Are you able to reconcile things if you assume that >>the rootDSE is treated as a normal object in >>manageDsaIT searches with baseObject=3D""?=20 >> >>Kurt >=20 >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 22:09:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13106 for ; Thu, 23 Sep 2004 22:09:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfS8-0003ud-Bc; Thu, 23 Sep 2004 22:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfMY-0002yx-Ku for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 21:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12439 for ; Thu, 23 Sep 2004 21:59:04 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfTS-000778-1b for ldapext@ietf.org; Thu, 23 Sep 2004 22:06:14 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 4136CCFA0000296D; Fri, 24 Sep 2004 12:04:00 +1000 Message-ID: <41537F51.8090708@eb2bcom.com> Date: Fri, 24 Sep 2004 11:58:41 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > Thinking more about the alias thing; an alias should be allowed to point > to a glue DSE. I couldn't find anything in X.501 that said an alias must > only point to DSETypes of entry or alias. Just that it points to an > object entry or an alias entry. It further confuses things when it says: > "The root is not an entry as such, but can, where convenient to do so > [e.g. in the definitions of b) and c) below], be viewed as a null object > entry [see d) below];" I assume it's not convenient to view the root as > a 'null object entry' when it's being referenced by an alias entry :-) X.501 also says an aliasedEntryName "does not have to be the distinguished name of any entry", which sort of allows the root name. An implementation might disallow it though if it can't handle loops in subtree searches. Regards, Steven > > >>>>"Jim Sermersheim" 9/23/04 4:33:56 PM >>> > > True, if there is a check to validate that aliasedObjectName points to > an entry or alias DSE, this should just result in an error. > > So, getting back to my original question * does anyone know if X.500 > allows access to the root DSE without the use of ManageDsaIT? > > Jim > > >>>>"Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> > > At 02:16 PM 9/23/2004, Jim Sermersheim wrote: > >>I can reconcile some things, but not others. It's the inverse that is > > the problem * in the absense of manageDsaIT, when is the root to be > treated as a normal object? > >>I *think* X.500 says never, and LDAP special cased read, and sort of > > left the door open for special casing write. > >>I was hoping that an X.500 vendor with an LDAP front-end could clarify > > (as they would have implemented the X.500 semantics, and the LDAP > front-end would have done something to special case where needed). > >>Another question is: Assume an alias object which > > has an aliasedObjectName set to the empty DN. > > One could consider this invalid. aliasObjectName is suppose to > refer an object entry (or possibly another alias entry). Having > an alias refer to a root DSE, which is not part of the DIT, > makes no (or, at most, little) sense. > > >>If a base-scope search is rooted at that alias, the filter is > > (objectclass=*), and derefAliases is derefFindingBaseObj, what is the > proper behavior? I think RFC 2251 could be read either way. > > I would think the server would return some sort of aliasing > error here. (I believe the OpenLDAP server does.) > > >>What I wanted to do with the distproc I-D was give a simple, straight > > forward way of determining whether a DSE reresents a normal object (in > the absense of manageDsaIT). > >>Jim >> >> >>>>>"Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >> >>Though I said "I disagree" over on the LDAPBIS list, in >>retrospect, I would have to minimally agree that a server >>*could* returning the rootDSE in response to subtree >>manageDsaIt search. RFC 3296 says: >> The control MAY cause other objects to be treated as >> normal entries as defined by subsequent documents. >> >>While there is no subsequent document stating how this >>control would cause rootDSE to be treated as a normal >>entry, I think it reasonable that some subsequent document >>could state how. I would hope that any such document >>would state a how consistent with X.511(97) manageDsaIt >>service. >> >>Are you able to reconcile things if you assume that >>the rootDSE is treated as a normal object in >>manageDsaIT searches with baseObject=""? >> >>Kurt > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 22:20:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13657 for ; Thu, 23 Sep 2004 22:20:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAffC-0005Rg-RB; Thu, 23 Sep 2004 22:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfY3-0004h1-0G for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 22:10:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13152 for ; Thu, 23 Sep 2004 22:10:56 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfev-0007Jo-J1 for ldapext@ietf.org; Thu, 23 Sep 2004 22:18:07 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 4136CCFA00002976; Fri, 24 Sep 2004 12:15:44 +1000 Message-ID: <41538211.4050104@eb2bcom.com> Date: Fri, 24 Sep 2004 12:10:25 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Kurt@OpenLDAP.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > I agree conceptually. But when describing the steps for determining > suitability of the pointed-to object in technical terms, you'd kind of > have to say "aliasedObjectName can point to a glue DSE, but not the root > DSE." Couldn't you just say that the value of aliasedObjectName cannot be the empty RDN sequence ? You might be better off not saying that the aliasedObjectName *points* to anything, but rather that it provides a new name with which to recommence name resolution. The name is a reference to an entry or alias that may or may not exist (anywhere), and may or may not be locally represented by either an entry DSE, an alias DSE or a glue DSE. One finds out by doing name resolution. Regards, Steven > > >>>>"Kurt D. Zeilenga" 9/23/04 6:21:46 PM >>> > > At 05:11 PM 9/23/2004, Jim Sermersheim wrote: > >>Thinking more about the alias thing; an alias should be allowed to > > point > >>to a glue DSE. > > > I'd argue that such an alias is not pointing at the glue, > but the object/alias entry that the glue entry is providing > glue for. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 23 22:28:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14098 for ; Thu, 23 Sep 2004 22:28:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAflA-0006Hh-QY; Thu, 23 Sep 2004 22:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfjG-00064u-3j for ldapext@megatron.ietf.org; Thu, 23 Sep 2004 22:22:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13811 for ; Thu, 23 Sep 2004 22:22:31 -0400 (EDT) Received: from [210.8.119.70] (helo=micah.software-aus.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfq9-0007VB-4W for ldapext@ietf.org; Thu, 23 Sep 2004 22:29:42 -0400 Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 4136CCFA00002983; Fri, 24 Sep 2004 12:27:00 +1000 Message-ID: <415384B6.5060505@eb2bcom.com> Date: Fri, 24 Sep 2004 12:21:42 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ramsay, Ron" Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? References: <1395B4B334FCC143B36AF788E68B638101D59959@ausyms21.ca.com> In-Reply-To: <1395B4B334FCC143B36AF788E68B638101D59959@ausyms21.ca.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Ron, Ramsay, Ron wrote: > Could you please tell me where in the X.500 documents this root DSE is described? X.501:2001, Clause 23.4.2, under the description of the DSEType ASN.1 type. Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Sep 24 00:14:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19976 for ; Fri, 24 Sep 2004 00:14:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAhR7-00026K-0N; Fri, 24 Sep 2004 00:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAhN1-0001CL-32 for ldapext@megatron.ietf.org; Fri, 24 Sep 2004 00:07:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19728 for ; Fri, 24 Sep 2004 00:07:39 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAhTu-0000mF-V3 for ldapext@ietf.org; Fri, 24 Sep 2004 00:14:52 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 22:07:10 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 22:06:45 -0600 From: "Jim Sermersheim" To: , Subject: RE: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Sorry Ron, I imprecisely was referring to the X.5nn series of recommendations when I said X.500 below. I should have said X.501. >>> "Ramsay, Ron" 9/23/04 7:44:33 PM >>> Hi Jim, I don't understand this talk about the root DSE in X.500. I would have thought that "The root is not an entry" is clear enough? Do you have a reference to any section other than 7.4 which talks about the root DSE? I believe 7.4 is simply talking about the graph, not about the DIT. 9.7 says "It also proves convenient to define the 'distinguished name' of the root, although this can never be the distinguished name of an object. The distinguished name of the root is defined to be an empty sequence." In summary, I don't believe there is any such thing as the root DSE in X.500. Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Friday, 24 September 2004 10:11 To: ldapext@ietf.org Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Thinking more about the alias thing; an alias should be allowed to point to a glue DSE. I couldn't find anything in X.501 that said an alias must only point to DSETypes of entry or alias. Just that it points to an object entry or an alias entry. It further confuses things when it says: "The root is not an entry as such, but can, where convenient to do so [e.g. in the definitions of b) and c) below], be viewed as a null object entry [see d) below];" I assume it's not convenient to view the root as a 'null object entry' when it's being referenced by an alias entry :-) >>> "Jim Sermersheim" 9/23/04 4:33:56 PM >>> True, if there is a check to validate that aliasedObjectName points to an entry or alias DSE, this should just result in an error. So, getting back to my original question * does anyone know if X.500 allows access to the root DSE without the use of ManageDsaIT? Jim >>> "Kurt D. Zeilenga" 9/23/04 3:33:34 PM >>> At 02:16 PM 9/23/2004, Jim Sermersheim wrote: >I can reconcile some things, but not others. It's the inverse that is the problem * in the absense of manageDsaIT, when is the root to be treated as a normal object? > >I *think* X.500 says never, and LDAP special cased read, and sort of left the door open for special casing write. > >I was hoping that an X.500 vendor with an LDAP front-end could clarify (as they would have implemented the X.500 semantics, and the LDAP front-end would have done something to special case where needed). > >Another question is: Assume an alias object which has an aliasedObjectName set to the empty DN. One could consider this invalid. aliasObjectName is suppose to refer an object entry (or possibly another alias entry). Having an alias refer to a root DSE, which is not part of the DIT, makes no (or, at most, little) sense. >If a base-scope search is rooted at that alias, the filter is (objectclass=*), and derefAliases is derefFindingBaseObj, what is the proper behavior? I think RFC 2251 could be read either way. I would think the server would return some sort of aliasing error here. (I believe the OpenLDAP server does.) >What I wanted to do with the distproc I-D was give a simple, straight forward way of determining whether a DSE reresents a normal object (in the absense of manageDsaIT). > >Jim > >>>> "Kurt D. Zeilenga" 9/22/04 6:50:28 PM >>> >Though I said "I disagree" over on the LDAPBIS list, in >retrospect, I would have to minimally agree that a server >*could* returning the rootDSE in response to subtree >manageDsaIt search. RFC 3296 says: > The control MAY cause other objects to be treated as > normal entries as defined by subsequent documents. > >While there is no subsequent document stating how this >control would cause rootDSE to be treated as a normal >entry, I think it reasonable that some subsequent document >could state how. I would hope that any such document >would state a how consistent with X.511(97) manageDsaIt >service. > >Are you able to reconcile things if you assume that >the rootDSE is treated as a normal object in >manageDsaIT searches with baseObject=""? > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Sep 24 00:21:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20361 for ; Fri, 24 Sep 2004 00:21:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAhYg-0004M6-3o; Fri, 24 Sep 2004 00:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAhY4-0004GM-Kp for ldapext@megatron.ietf.org; Fri, 24 Sep 2004 00:19:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20231 for ; Fri, 24 Sep 2004 00:19:05 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAhez-0000wn-OF for ldapext@ietf.org; Fri, 24 Sep 2004 00:26:18 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Sep 2004 22:18:37 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Thu, 23 Sep 2004 22:18:17 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Kurt@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit For the record, I'm not writing any document that describes the behavior of aliases or the allowed values of aliasedObjectName. I was just using the example as another lever to help me understand whether (and to what extent) LDAP has 'special cased' reads and modifies of the root DSE. I'm trying to understand that is so I'll know how to best describe the way in which an LDAP server discovers whether an asserted DN represents an entry that can be normally accessed (without the use of manageDSAIT). I think I have it now, and I think it's straight-forward except there will have to be an exception for the read and modify of the root DSE to be compatible with RFC 2251. Thanks again, Jim >>> Steven Legg 9/23/04 8:10:25 PM >>> Jim, Jim Sermersheim wrote: > I agree conceptually. But when describing the steps for determining > suitability of the pointed-to object in technical terms, you'd kind of > have to say "aliasedObjectName can point to a glue DSE, but not the root > DSE." Couldn't you just say that the value of aliasedObjectName cannot be the empty RDN sequence ? You might be better off not saying that the aliasedObjectName *points* to anything, but rather that it provides a new name with which to recommence name resolution. The name is a reference to an entry or alias that may or may not exist (anywhere), and may or may not be locally represented by either an entry DSE, an alias DSE or a glue DSE. One finds out by doing name resolution. Regards, Steven > > >>>>"Kurt D. Zeilenga" 9/23/04 6:21:46 PM >>> > > At 05:11 PM 9/23/2004, Jim Sermersheim wrote: > >>Thinking more about the alias thing; an alias should be allowed to > > point > >>to a glue DSE. > > > I'd argue that such an alias is not pointing at the glue, > but the object/alias entry that the glue entry is providing > glue for. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Sep 27 14:40:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19642 for ; Mon, 27 Sep 2004 14:40:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0MI-00048F-PV; Mon, 27 Sep 2004 14:36:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0Je-0003WA-11 for ldapext@megatron.ietf.org; Mon, 27 Sep 2004 14:33:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19026 for ; Mon, 27 Sep 2004 14:33:36 -0400 (EDT) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC0RJ-00031a-47 for ldapext@ietf.org; Mon, 27 Sep 2004 14:41:33 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Mon, 27 Sep 2004 12:33:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 27 Sep 2004 12:31:29 -0600 From: "Vithalprasad Gaitonde" To: "Jim Sermersheim" , Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit it seems caseIgnorematch would be more useful than caseExactmatch...so that a client could match iplanet for iPlanet. Would there be problems if we change it to caseignore instead of caseexAct ? Prasad >>> Ludovic Poitou 9/23/2004 2:52:32 PM >>> Jim Sermersheim wrote: >or compared, or used in a filter I guess. > > Correct. I've never heard of an app doing this so far. But RFC 3045 is very discreet and customers hardly noticed it. I don't have any issue with changing it to CaseExactMatch. Ludovic. > > >>>>Ludovic Poitou 9/22/04 2:59:51 PM >>> >>>> >>>> >Sun Directory Server has implemented RFC 3045 with the schema as >defined >in the RFC. >I'm not aware of any application or customer actually using the >equality >matching rule. >The server itself doesn't (the values cannot be modified). > >Ludovic. > > >Jim Sermersheim wrote: > > > >>We were looking at implementing this and someone noticed that the >> >> >syntax > > >>for the attributes is Directory String >> >> >(1.3.6.1.4.1.1466.115.121.1.15) > > >>while the EQUALITY rule is caseExactIA5Match >>(1.3.6.1.4.1.1466.109.114.1). >> >>I assume the author was at one point using the IA5 String syntax and >>changed to Directory String but forgot to change the EQUALITY rule >> >> >(the > > >>author doesn't work at Novell anymore or I'd ask him). We should >>probably update the RFC. Do other vendors who have implemented this >> >> >use > > >>a caseExactMatch (2.5.13.5) for the EQUALITY? >> >>Thanks, >> >>Jim >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> >> > > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Sep 27 15:13:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22976 for ; Mon, 27 Sep 2004 15:13:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0pm-00067E-Uo; Mon, 27 Sep 2004 15:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0kl-0001y6-66 for ldapext@megatron.ietf.org; Mon, 27 Sep 2004 15:01:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21752 for ; Mon, 27 Sep 2004 15:01:36 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC0sQ-0003et-5q for ldapext@ietf.org; Mon, 27 Sep 2004 15:09:35 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8RJ1WZv037698; Mon, 27 Sep 2004 19:01:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040927115922.04104250@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 27 Sep 2004 12:01:36 -0700 To: "Vithalprasad Gaitonde" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] syntax or matching rule flaw in RFC 3045 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Jim Sermersheim , ldapext@ietf.org, ludovic.poitou@Sun.COM X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 11:31 AM 9/27/2004, Vithalprasad Gaitonde wrote: >it seems caseIgnorematch would be more useful than caseExactmatch...so >that a client could match iplanet for iPlanet. We discussed at great lengths during the engineering of this schema how it should be used. The conclusion was that an exact match was more appropriate. >Would there be problems if we change it to caseignore instead of >caseexAct ? Yes. >Prasad > >>>> Ludovic Poitou 9/23/2004 2:52:32 PM >>> > > >Jim Sermersheim wrote: > >>or compared, or used in a filter I guess. >> >> >Correct. I've never heard of an app doing this so far. >But RFC 3045 is very discreet and customers hardly noticed it. >I don't have any issue with changing it to CaseExactMatch. > >Ludovic. > >> >> >>>>>Ludovic Poitou 9/22/04 2:59:51 PM >>> >>>>> >>>>> >>Sun Directory Server has implemented RFC 3045 with the schema as >>defined >>in the RFC. >>I'm not aware of any application or customer actually using the >>equality >>matching rule. >>The server itself doesn't (the values cannot be modified). >> >>Ludovic. >> >> >>Jim Sermersheim wrote: >> >> >> >>>We were looking at implementing this and someone noticed that the >>> >>> >>syntax >> >> >>>for the attributes is Directory String >>> >>> >>(1.3.6.1.4.1.1466.115.121.1.15) >> >> >>>while the EQUALITY rule is caseExactIA5Match >>>(1.3.6.1.4.1.1466.109.114.1). >>> >>>I assume the author was at one point using the IA5 String syntax and >>>changed to Directory String but forgot to change the EQUALITY rule >>> >>> >>(the >> >> >>>author doesn't work at Novell anymore or I'd ask him). We should >>>probably update the RFC. Do other vendors who have implemented this >>> >>> >>use >> >> >>>a caseExactMatch (2.5.13.5) for the EQUALITY? >>> >>>Thanks, >>> >>>Jim >>> >>>_______________________________________________ >>>Ldapext mailing list >>>Ldapext@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ldapext >>> >>> >>> >>> >> >> >> > >-- >Ludovic Poitou >Directory Architect. >Directory Server Group, Grenoble, France >Sun Microsystems Inc. > >Sun Microsystems requires the following notice: >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >NOTICE: This email message is for the sole use of the intended >recipient(s) and may contain confidential and privileged >information. Any unauthorized review, use, disclosure or >distribution is prohibited. If you are not the intended >recipient, please contact the sender by reply email and destroy >all copies of the original message. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Sep 27 21:48:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00094 for ; Mon, 27 Sep 2004 21:48:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC74b-0004eX-8g; Mon, 27 Sep 2004 21:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC732-0004IW-Ns for ldapext@megatron.ietf.org; Mon, 27 Sep 2004 21:44:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29890 for ; Mon, 27 Sep 2004 21:44:54 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC7Ab-00067j-SD for ldapext@ietf.org; Mon, 27 Sep 2004 21:52:56 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 4136CE6D0000325C for ldapext@ietf.org; Tue, 28 Sep 2004 11:53:10 +1000 Message-ID: <4158C217.6060705@eB2Bcom.com> Date: Tue, 28 Sep 2004 11:44:55 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: Quoted-Printable Subject: [ldapext] LDAP ManageDSAIT Control Usage with JNDI X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: Quoted-Printable Hi There is a good chance that this may have been discussed in the past,=20 however I am currently seeing serious problems in which the manageDSAIT=20 control (RFC3296) is being used. My concerns are discussed below and it=20 would be greatly appreciated if I could get some feedback on whether=20 others also share my views. My concerns are with the way that JNDI handles naming referrals and=20 resultantly their use of the manageDSAIT control within LDAP operations. In the document titled "JNDI Implementor Guidelines for LDAP Service=20 Providers - Draft 0.4.2" which can be found at the following location: http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referral a property called java.naming.referral is described. This property identifies how referrals are to be handled. The default=20 value of this property is 'ignore'. The way in which the JNDI API will ignore a referral is by: "sending a non-critical ManageDsaIT (RFC 3296) LDAP control with each=20 LDAP request". In my opinion this is a massive abuse and misuse of the control since=20 the manageDSAIT control affects a lot more than the returning of referral= s. Looking at RFC3296, I see the following: "A control, ManageDsaIT, is defined to allow manipulation of referral and other special objects as normal objects. As the name of control implies, it is intended to be analogous to the ManageDsaIT service option described in X.511(97) [X.511]." Being analogous to the ManageDsaIT service option described in X.511=20 causes me to have the following concerns: =B7 The purpose of the control is that it should only be used by=20 administrative users to manage the DIT. This is significantly different=20 to it being used as a mechanism to ignore referrals. =B7 All DSE=92s are treated as normal entries. This means that all of the= =20 below DSE's will be treated as an object entry (i.e DSE Type Entry): o Root =96 Root DSE o Glue- Represents Knowledge of a name only o Cp =96 Context Prefix o Alias =96 Alias Entry o Subr =96 Subordinate Reference o Nssr =96 Non-Specific Subordinate Reference o Supr =96 Superior Reference o Xr =96 Cross Reference o AdmPoint =96 Administrative Point o Subentry o Shadow =96 Shadow Copy o ImmSupr =96 Immediate Superior Reference o Rhob =96 RHOB Information o Sa =96 Subordinate Reference to alias entry o DsSubentry =96 DSA Specific subentry o FamilyMember =96 Family Member The purpose here, as I see it, is purely to manage the data within these=20 entries that would not normally be accessible through the protocol=20 (DAP). The fact that you don't receive a referral is purely because you=20 want to administer the data within these entries. =B7 An operation will never be chained. This is an obvious effect of=20 treating all DSE's as object entries. If clients who want to ignore=20 referrals continue to send the manageDSAIT control with every request, a=20 request will never be chained. This will severely affect any LDAP=20 Directory that also supports the X.500 distributed protocol (DSP), as=20 well as any directory that implements Jim's distributed procedure draft. =B7 Schema Checking on entries. The manageDSAIT control in X.500 somewhat allows the directory to=20 perform operations that are not entirely consistent with the schema=20 governing that entry. For example, it is explicitly stated in X.511 that=20 an operation that carries the manageDSAIT control can result in the=20 modification of attributes that are specified as 'no user modification'. Based on the above information, it is my opinion that using the=20 manageDSAIT control to prevent a directory from returning referrals is=20 largely inappropriate and its future use should be largely discouraged. Comments? _________________________________________ Andrew Sciberras eB2Bcom - View500 Software Engineer Woodhouse Corporate Centre Suite 3, 935 Station Street Box Hill North, Victoria 3129, Australia EMail: andrew.sciberras@eb2bcom.com Web http://www.eb2bcom.com _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Sep 27 23:33:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06029 for ; Mon, 27 Sep 2004 23:33:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC8cu-0002BC-C2; Mon, 27 Sep 2004 23:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC8U3-0001Fu-3E for ldapext@megatron.ietf.org; Mon, 27 Sep 2004 23:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05217 for ; Mon, 27 Sep 2004 23:16:52 -0400 (EDT) Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC8bn-0007hL-11 for ldapext@ietf.org; Mon, 27 Sep 2004 23:24:55 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by mail17.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 13:16:18 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] LDAP ManageDSAIT Control Usage with JNDI Date: Tue, 28 Sep 2004 13:16:18 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101D76936@ausyms21.ca.com> Thread-Topic: [ldapext] LDAP ManageDSAIT Control Usage with JNDI Thread-Index: AcSk/VhyGVNwxOmDQbepP+rtOjPBUQADAOLw From: "Ramsay, Ron" To: , "Ldapext" X-OriginalArrivalTime: 28 Sep 2004 03:16:18.0717 (UTC) FILETIME=[858DD4D0:01C4A509] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I agree with you one hundred por cent! -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Andrew Sciberras Sent: Tuesday, 28 September 2004 11:45 To: Ldapext Subject: [ldapext] LDAP ManageDSAIT Control Usage with JNDI Hi There is a good chance that this may have been discussed in the past,=20 however I am currently seeing serious problems in which the manageDSAIT=20 control (RFC3296) is being used. My concerns are discussed below and it=20 would be greatly appreciated if I could get some feedback on whether=20 others also share my views. My concerns are with the way that JNDI handles naming referrals and=20 resultantly their use of the manageDSAIT control within LDAP operations. In the document titled "JNDI Implementor Guidelines for LDAP Service=20 Providers - Draft 0.4.2" which can be found at the following location: http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referral= a property called java.naming.referral is described. This property identifies how referrals are to be handled. The default=20 value of this property is 'ignore'. The way in which the JNDI API will ignore a referral is by: "sending a non-critical ManageDsaIT (RFC 3296) LDAP control with each=20 LDAP request". In my opinion this is a massive abuse and misuse of the control since=20 the manageDSAIT control affects a lot more than the returning of = referrals. Looking at RFC3296, I see the following: "A control, ManageDsaIT, is defined to allow manipulation of referral and other special objects as normal objects. As the name of control implies, it is intended to be analogous to the ManageDsaIT service option described in X.511(97) [X.511]." Being analogous to the ManageDsaIT service option described in X.511=20 causes me to have the following concerns: =B7 The purpose of the control is that it should only be used by=20 administrative users to manage the DIT. This is significantly different=20 to it being used as a mechanism to ignore referrals. =B7 All DSE=92s are treated as normal entries. This means that all of = the=20 below DSE's will be treated as an object entry (i.e DSE Type Entry): o Root =96 Root DSE o Glue- Represents Knowledge of a name only o Cp =96 Context Prefix o Alias =96 Alias Entry o Subr =96 Subordinate Reference o Nssr =96 Non-Specific Subordinate Reference o Supr =96 Superior Reference o Xr =96 Cross Reference o AdmPoint =96 Administrative Point o Subentry o Shadow =96 Shadow Copy o ImmSupr =96 Immediate Superior Reference o Rhob =96 RHOB Information o Sa =96 Subordinate Reference to alias entry o DsSubentry =96 DSA Specific subentry o FamilyMember =96 Family Member The purpose here, as I see it, is purely to manage the data within these = entries that would not normally be accessible through the protocol=20 (DAP). The fact that you don't receive a referral is purely because you=20 want to administer the data within these entries. =B7 An operation will never be chained. This is an obvious effect of=20 treating all DSE's as object entries. If clients who want to ignore=20 referrals continue to send the manageDSAIT control with every request, a = request will never be chained. This will severely affect any LDAP=20 Directory that also supports the X.500 distributed protocol (DSP), as=20 well as any directory that implements Jim's distributed procedure draft. =B7 Schema Checking on entries. The manageDSAIT control in X.500 somewhat allows the directory to=20 perform operations that are not entirely consistent with the schema=20 governing that entry. For example, it is explicitly stated in X.511 that = an operation that carries the manageDSAIT control can result in the=20 modification of attributes that are specified as 'no user modification'. Based on the above information, it is my opinion that using the=20 manageDSAIT control to prevent a directory from returning referrals is=20 largely inappropriate and its future use should be largely discouraged. Comments? _________________________________________ Andrew Sciberras eB2Bcom - View500 Software Engineer Woodhouse Corporate Centre Suite 3, 935 Station Street Box Hill North, Victoria 3129, Australia EMail: andrew.sciberras@eb2bcom.com Web http://www.eb2bcom.com _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Sep 27 23:49:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06810 for ; Mon, 27 Sep 2004 23:49:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC8to-0003cz-4h; Mon, 27 Sep 2004 23:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC8lq-0002zh-IK for ldapext@megatron.ietf.org; Mon, 27 Sep 2004 23:35:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06157 for ; Mon, 27 Sep 2004 23:35:15 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC8ta-0007zK-TU for ldapext@ietf.org; Mon, 27 Sep 2004 23:43:19 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 27 Sep 2004 21:34:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Beta Date: Mon, 27 Sep 2004 21:34:19 -0600 From: "Jim Sermersheim" To: , , Subject: Re: [ldapext] LDAP ManageDSAIT Control Usage with JNDI Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I completely agree with this Andrew. I suspect that the control was = somewhat misunderstood back in the day (4 years prior to RFC 3296 I think) = when the ldap service provider was written. Also, I think most servers at = that time only applied manageDsaIT to objects resembling the named = subodinate references in that RFC. Vincent, Are you still over the LDAP service provider development? If so (as = Andrew's message illustrates), it seems like some action should be taken = in order to avoid confusion and problems * especially since ignore is the = default.=20 Jiim >>> Andrew Sciberras 9/27/04 7:44:55 PM >>> Hi There is a good chance that this may have been discussed in the past,=20 however I am currently seeing serious problems in which the manageDSAIT=20 control (RFC3296) is being used. My concerns are discussed below and it=20 would be greatly appreciated if I could get some feedback on whether=20 others also share my views. My concerns are with the way that JNDI handles naming referrals and=20 resultantly their use of the manageDSAIT control within LDAP operations. In the document titled "JNDI Implementor Guidelines for LDAP Service=20 Providers - Draft 0.4.2" which can be found at the following location: http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referral= =20 a property called java.naming.referral is described. This property identifies how referrals are to be handled. The default=20 value of this property is 'ignore'. The way in which the JNDI API will ignore a referral is by: "sending a non-critical ManageDsaIT (RFC 3296) LDAP control with each=20 LDAP request". In my opinion this is a massive abuse and misuse of the control since=20 the manageDSAIT control affects a lot more than the returning of referrals.= Looking at RFC3296, I see the following: "A control, ManageDsaIT, is defined to allow manipulation of referral and other special objects as normal objects. As the name of control implies, it is intended to be analogous to the ManageDsaIT service option described in X.511(97) [X.511]." Being analogous to the ManageDsaIT service option described in X.511=20 causes me to have the following concerns: =B7 The purpose of the control is that it should only be used by=20 administrative users to manage the DIT. This is significantly different=20 to it being used as a mechanism to ignore referrals. =B7 All DSE's are treated as normal entries. This means that all of the=20 below DSE's will be treated as an object entry (i.e DSE Type Entry): o Root * Root DSE o Glue- Represents Knowledge of a name only o Cp * Context Prefix o Alias * Alias Entry o Subr * Subordinate Reference o Nssr * Non-Specific Subordinate Reference o Supr * Superior Reference o Xr * Cross Reference o AdmPoint * Administrative Point o Subentry o Shadow * Shadow Copy o ImmSupr * Immediate Superior Reference o Rhob * RHOB Information o Sa * Subordinate Reference to alias entry o DsSubentry * DSA Specific subentry o FamilyMember * Family Member The purpose here, as I see it, is purely to manage the data within = these=20 entries that would not normally be accessible through the protocol=20 (DAP). The fact that you don't receive a referral is purely because you=20 want to administer the data within these entries. =B7 An operation will never be chained. This is an obvious effect of=20 treating all DSE's as object entries. If clients who want to ignore=20 referrals continue to send the manageDSAIT control with every request, = a=20 request will never be chained. This will severely affect any LDAP=20 Directory that also supports the X.500 distributed protocol (DSP), as=20 well as any directory that implements Jim's distributed procedure draft. =B7 Schema Checking on entries. The manageDSAIT control in X.500 somewhat allows the directory to=20 perform operations that are not entirely consistent with the schema=20 governing that entry. For example, it is explicitly stated in X.511 = that=20 an operation that carries the manageDSAIT control can result in the=20 modification of attributes that are specified as 'no user modification'. Based on the above information, it is my opinion that using the=20 manageDSAIT control to prevent a directory from returning referrals is=20 largely inappropriate and its future use should be largely discouraged. Comments? _________________________________________ Andrew Sciberras eB2Bcom - View500 Software Engineer Woodhouse Corporate Centre Suite 3, 935 Station Street Box Hill North, Victoria 3129, Australia EMail: andrew.sciberras@eb2bcom.com=20 Web http://www.eb2bcom.com=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Sep 28 01:01:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10951 for ; Tue, 28 Sep 2004 01:01:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCA69-0004FE-5i; Tue, 28 Sep 2004 01:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCA5C-00048A-KL for ldapext@megatron.ietf.org; Tue, 28 Sep 2004 00:59:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10812 for ; Tue, 28 Sep 2004 00:59:17 -0400 (EDT) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCACq-00012W-3J for ldapext@ietf.org; Tue, 28 Sep 2004 01:07:19 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i8S4xBZv040799; Tue, 28 Sep 2004 04:59:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20040927214354.0443ab18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 27 Sep 2004 21:59:15 -0700 To: andrew.sciberras@eB2Bcom.com From: "Kurt D. Zeilenga" Subject: Re: [ldapext] LDAP ManageDSAIT Control Usage with JNDI In-Reply-To: <4158C217.6060705@eB2Bcom.com> References: <4158C217.6060705@eB2Bcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 06:44 PM 9/27/2004, Andrew Sciberras wrote: >=B7 The purpose of the control is that it should only be used by= administrative users to manage the DIT. This is significantly different to= it being used as a mechanism to ignore referrals. Yes. JNDI behavior is quite odd especially given that the LDAP ManageDsaIT control specification does not preclude the return of referrals and/or continuations when the control is present. Kurt=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Sep 29 19:32:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02026 for ; Wed, 29 Sep 2004 19:32:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnY4-0003Ea-DK; Wed, 29 Sep 2004 19:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCnAX-0006FP-Pt for ldapext@megatron.ietf.org; Wed, 29 Sep 2004 18:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26638 for ; Wed, 29 Sep 2004 18:43:25 -0400 (EDT) Received: from amos.eb2b.com.au ([210.8.191.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCnIb-0004lu-DZ for ldapext@ietf.org; Wed, 29 Sep 2004 18:51:52 -0400 Received: from [192.168.1.155] (210.8.191.250) by amos.eb2b.com.au (7.1.016.1) (authenticated as andrew.sciberras) id 4136CE6D00003664; Thu, 30 Sep 2004 08:52:05 +1000 Message-ID: <415B3AB2.5060507@eB2Bcom.com> Date: Thu, 30 Sep 2004 08:44:02 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: Vincent Ryan , ldapext Subject: Re: [ldapext] LDAP ManageDSAIT Control Usage with JNDI References: <41596470.7080702@sun.com> In-Reply-To: <41596470.7080702@sun.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: Quoted-Printable Cc: "Ramsay, Ron" , "Kurt D. Zeilenga" , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: Quoted-Printable Hi Thanks for all of the positive feedback (Vincent, Kurt, Ron, Jim). Vincent, you state below that you will "cease using the ManageDsaIT=20 control as a means to control when referrals are returned". I don't think that your focus should be on controlling whether a=20 referral is returned from the directory. Personally, I would focus on=20 what you do with that referral once it is received. Cheers, Andrew Sciberras eB2Bcom Vincent Ryan wrote: > I agree that the behaviour of the JNDI/LDAP provider now needs to be mo= dified. > We will update the provider to cease using the ManageDsaIT control as a= means > to control when referrals are returned. >=20 > In the meantime, JNDI applications that wish to avoid sending the Manag= eDsaIT > control should set the java.naming.referral property to "follow". >=20 > In addition, applications that wish to avoid sending the ManageDsaIT co= ntrol > but also wish to ignore (and not follow) referrals should set the prope= rty to > "throw" and then catch and ignore any ReferralException. >=20 >=20 > Jim Sermersheim wrote: >=20 >>I completely agree with this Andrew. I suspect that the control was som= ewhat misunderstood back in the day (4 years prior to RFC 3296 I think) w= hen the ldap service provider was written. Also, I think most servers at= that time only applied manageDsaIT to objects resembling the named subod= inate references in that RFC. >> >>Vincent, >> >>Are you still over the LDAP service provider development? If so (as And= rew's message illustrates), it seems like some action should be taken in = order to avoid confusion and problems * especially since ignore is the de= fault.=20 >> >>Jiim >> >> >> >>>>>Andrew Sciberras 9/27/04 7:44:55 PM >= >> >> >>Hi >> >>There is a good chance that this may have been discussed in the past,=20 >>however I am currently seeing serious problems in which the manageDSAIT= =20 >>control (RFC3296) is being used. My concerns are discussed below and it= =20 >>would be greatly appreciated if I could get some feedback on whether=20 >>others also share my views. >> >>My concerns are with the way that JNDI handles naming referrals and=20 >>resultantly their use of the manageDSAIT control within LDAP operations= =2E >> >>In the document titled "JNDI Implementor Guidelines for LDAP Service=20 >>Providers - Draft 0.4.2" which can be found at the following location: >> >>http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referr= al=20 >> >>a property called java.naming.referral is described. >>This property identifies how referrals are to be handled. The default=20 >>value of this property is 'ignore'. >>The way in which the JNDI API will ignore a referral is by: >>"sending a non-critical ManageDsaIT (RFC 3296) LDAP control with each=20 >>LDAP request". >> >>In my opinion this is a massive abuse and misuse of the control since=20 >>the manageDSAIT control affects a lot more than the returning of referr= als. >> >>Looking at RFC3296, I see the following: >>"A control, ManageDsaIT, is defined to allow manipulation of referral >> and other special objects as normal objects. As the name of contro= l >> implies, it is intended to be analogous to the ManageDsaIT service >> option described in X.511(97) [X.511]." >> >>Being analogous to the ManageDsaIT service option described in X.511=20 >>causes me to have the following concerns: >> >>=B7 The purpose of the control is that it should only be used by=20 >>administrative users to manage the DIT. This is significantly different= =20 >>to it being used as a mechanism to ignore referrals. >> >>=B7 All DSE's are treated as normal entries. This means that all of the= =20 >>below DSE's will be treated as an object entry (i.e DSE Type Entry): >> o Root * Root DSE >> o Glue- Represents Knowledge of a name only >> o Cp * Context Prefix >> o Alias * Alias Entry >> o Subr * Subordinate Reference >> o Nssr * Non-Specific Subordinate Reference >> o Supr * Superior Reference >> o Xr * Cross Reference >> o AdmPoint * Administrative Point >> o Subentry >> o Shadow * Shadow Copy >> o ImmSupr * Immediate Superior Reference >> o Rhob * RHOB Information >> o Sa * Subordinate Reference to alias entry >> o DsSubentry * DSA Specific subentry >> o FamilyMember * Family Member >>The purpose here, as I see it, is purely to manage the data within thes= e=20 >>entries that would not normally be accessible through the protocol=20 >>(DAP). The fact that you don't receive a referral is purely because you= =20 >>want to administer the data within these entries. >> >> >>=B7 An operation will never be chained. This is an obvious effect of=20 >>treating all DSE's as object entries. If clients who want to ignore=20 >>referrals continue to send the manageDSAIT control with every request, = a=20 >>request will never be chained. This will severely affect any LDAP=20 >>Directory that also supports the X.500 distributed protocol (DSP), as=20 >>well as any directory that implements Jim's distributed procedure draft= =2E >> >> >>=B7 Schema Checking on entries. >>The manageDSAIT control in X.500 somewhat allows the directory to=20 >>perform operations that are not entirely consistent with the schema=20 >>governing that entry. For example, it is explicitly stated in X.511 tha= t=20 >>an operation that carries the manageDSAIT control can result in the=20 >>modification of attributes that are specified as 'no user modification'= =2E >> >> >>Based on the above information, it is my opinion that using the=20 >>manageDSAIT control to prevent a directory from returning referrals is=20 >>largely inappropriate and its future use should be largely discouraged. >> >>Comments? >> >>_________________________________________ >>Andrew Sciberras >>eB2Bcom - View500 Software Engineer >> >>Woodhouse Corporate Centre >>Suite 3, 935 Station Street >>Box Hill North, Victoria 3129, Australia >> >>EMail: andrew.sciberras@eb2bcom.com=20 >>Web http://www.eb2bcom.com=20 >> >> >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org=20 >>https://www1.ietf.org/mailman/listinfo/ldapext >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Sep 30 13:46:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13384 for ; Thu, 30 Sep 2004 13:46:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD4kH-0007yB-S2; Thu, 30 Sep 2004 13:29:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3Kz-0004dE-3D for ldapext@megatron.ietf.org; Thu, 30 Sep 2004 11:59:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03458 for ; Thu, 30 Sep 2004 11:59:18 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD3TF-0003EN-5E for ldapext@ietf.org; Thu, 30 Sep 2004 12:07:54 -0400 Received: from phys-eris-2 ([129.156.85.26]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8UFxH55015117 for ; Thu, 30 Sep 2004 09:59:18 -0600 (MDT) Received: from conversion-daemon.eris-mail1.uk.sun.com by eris-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I4V00L012WRXV@eris-mail1.uk.sun.com> (original mail from Vincent.Ryan@Sun.COM) for ldapext@ietf.org; Thu, 30 Sep 2004 16:59:16 +0100 (BST) Received: from [129.156.220.142] (oasis.Ireland.Sun.COM [129.156.220.142]) by eris-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I4V000SQ32SG4@eris-mail1.uk.sun.com>; Thu, 30 Sep 2004 16:59:16 +0100 (BST) Date: Thu, 30 Sep 2004 16:59:16 +0100 From: Vincent Ryan Subject: Re: [ldapext] LDAP ManageDSAIT Control Usage with JNDI In-reply-to: <415B3AB2.5060507@eB2Bcom.com> To: andrew.sciberras@eB2Bcom.com Message-id: <415C2D54.6050703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040827) References: <41596470.7080702@sun.com> <415B3AB2.5060507@eB2Bcom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 30 Sep 2004 13:29:33 -0400 Cc: ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7BIT In future, transmission of the ManageDsaIT control will be controlled directly by the JNDI application. It will not be sent as a side-effect of setting the java.naming.referral property. Thanks for raising the issue. Andrew Sciberras wrote: > Hi > > Thanks for all of the positive feedback (Vincent, Kurt, Ron, Jim). > > Vincent, you state below that you will "cease using the ManageDsaIT > control as a means to control when referrals are returned". > I don't think that your focus should be on controlling whether a > referral is returned from the directory. Personally, I would focus on > what you do with that referral once it is received. > > Cheers, > Andrew Sciberras > eB2Bcom _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext