From ldapext-admin@ietf.org Fri Oct 3 19:18:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03797 for ; Fri, 3 Oct 2003 19:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ZBR-0001kZ-4T; Fri, 03 Oct 2003 19:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ZBB-0001k6-Mn for ldapext@optimus.ietf.org; Fri, 03 Oct 2003 19:17:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03787 for ; Fri, 3 Oct 2003 19:17:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZBA-0000Z3-00 for ldapext@ietf.org; Fri, 03 Oct 2003 19:17:44 -0400 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZB9-0000Yz-00 for ldapext@ietf.org; Fri, 03 Oct 2003 19:17:43 -0400 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 03 Oct 2003 17:17:13 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 03 Oct 2003 17:16:45 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] DSA Information Model Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All, I've ben thinking for a long time that it would be interesting and useful to bring the notions of the DSA Information Model, DSA Operational Framework (both X.501), and pretty much all of X.518 to into LDAP. This doesn't seem like something that can be easily done all at once (at least not by my definition of easy), so I think an iterative approach would have the best chance of success. If we were to tackle this, I think it'd be best to address first those things that are more useful and easy to implement, while planning for the more arcane and difficult things in the future. After looking at things, I'm thinking along these lines: 1) Review RFC3296 and Relevant sections in X.500 series. 2) Define the X.501 DSA Info Model (Knowledge References: Superior, Immediate Superior, Subordinate, Non-Specific Subordinate, and Cross References). I don't want to deal with Supplier and Consumer references right now. 3) Define the X.518 Chained Operation as an extended operation (this encapsulates the DSA Abstract Service and Distributed Procedures). Also define some auxiliary controls and extended operations that are similar but different to the chained operation (things that can be used by DUAs to understand and help control chaining). 4) Define the X.501 DSA Operational Framework. 5) Define the X.518 Knowledge Administration. I'm mostly interested in #'s 2, and 3 right now. And I believe they can be specified before #'s 4 and 5. So why am I posting this? I guess it's just a preamble to some future messages and possible I-Ds. I have a few I-D's in the works, but they aren't yet complete. Plus I want to make sure this seems like a sane and useful thing to be doing. Let me know if you have any suggestions, doubts, or whatever. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 3 20:01:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04823 for ; Fri, 3 Oct 2003 20:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Zr5-0003At-7Y; Fri, 03 Oct 2003 20:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ZqX-00039E-AD for ldapext@optimus.ietf.org; Fri, 03 Oct 2003 20:00:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04779 for ; Fri, 3 Oct 2003 20:00:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZqV-0000wC-00 for ldapext@ietf.org; Fri, 03 Oct 2003 20:00:27 -0400 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZqU-0000vo-00 for ldapext@ietf.org; Fri, 03 Oct 2003 20:00:26 -0400 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 03 Oct 2003 17:59:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 03 Oct 2003 17:59:37 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] RFC3296 review Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, I have been reviewing RFC3296. I did not review it in earnest (if at all) during its last call, so, well, there's my excuse--you don't need to slam me, I've just slammed myself... I'm splitting my questions/comments into three parts. First are some general questions which I'm simply curious about (most of the "why does it say that" nature). Second are issues that I see being obstructions to future specifications (like chaining). Third (and I wish it were not so) some problems that I consider being impediments to implementing the RFC. I know that one or more of these prevent at least one vendor from implementing the RFC. Questions: Q1: Why is it that LDAP URL values in the ref attribute SHOULD contain a non-empty DN? I imagine that many Referral objects will have the same name as the object they point at in the remote DSA. It seems better to state that when the DN of the remote object differs, that the DN field is present. If they are the same, it's easier to deal with events like moves and renames. Q2: In Section 5.3, Cases 2 and 4: Why MUST the server return an explicit scope when returning a referral (not search result reference)? It will always be the same as the original--thus not needed as the client (per RFC2251) MUST use the same scope. Q3: Why is there a SHOULD NOT return referral for bind? I can think of some possible problems, but it's not clear why this imperative is here. Issues: I1: Section 2.1 says: "Referral objects are analogous to X.500 subordinate knowledge (subr) DSEs [X.501].". But in fact a Referral object is more like a DSE with the subr *and* entry DSE Types. I believe there are many (most) cases where a subr DSE in and X.500 deployment are *not* entry's. This inconsistency with X.501 makes me worry that X.500 servers with LDAP front-ends will have a hard time implementing this RFC. I2: Why SHOULD NOT an LDAP URL in the ref attribute contain extensions? Future applications will wish to make use of this field. I3: Why is there an imperative restricting referential integrity validation of the ref URI? I4: The ref attribute has an EQUALITY of caseExactMatch. This will prohibit applications in the future from using it. Future applications will want to treat the "ldap://example.org" and "ldap://192.0.34.166" as equal. This _may_ be able to be worked around using an extensible match, not sure... Problems: P1: The Referral object class is STRUCTURAL. This prohibits various implementations from implementing the RFC. The DIT Structure Rule and Name Form for this object class needs to allow it to be placed and named in a variety of ways. If this was an AUXILIARY class, this problem could be avoided. P2: Referral suggests using "extensibleObject" object class to allow any naming. This doesn't work for some implementations that use name forms. the extensibleObject object class is more analogous to having a DIT Content rule that allows [anything] in the MAY list. It has nothing to do with naming. P3: The ref attribute is supposed to hold a URI, and the RFC goes as far as to say "If the URI component is not a LDAP URL, it should be returned as is.". RFC2251 and draft-ietf-ldapbis-protocol-xx.txt says a referral holds one or more URLs. How can a more generic URI be converted to a more specific URL? Either RFC 3296 needs to address this, or draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in referral values. P4: In various places, the semantics of the ManageDsaIT control are wrong. It states things like "When the control is present in the request, the server SHALL NOT generate a referral or continuation reference based upon information held in referral objects and instead SHALL treat the referral object as a normal entry". AFAIK, during name resolution, the manageDsaIT control is applied only when the last RDN of the DN being evaluated is a reference. Otherwise, how does one manage a Referral object that is subordinate to another Referral objet (in the DIT)? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 3 23:35:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09619 for ; Fri, 3 Oct 2003 23:35:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dCC-0002OL-G2; Fri, 03 Oct 2003 23:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dBc-0002Ny-HC for ldapext@optimus.ietf.org; Fri, 03 Oct 2003 23:34:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09577 for ; Fri, 3 Oct 2003 23:34:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5dBZ-0002hE-00 for ldapext@ietf.org; Fri, 03 Oct 2003 23:34:25 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A5dBY-0002hB-00 for ldapext@ietf.org; Fri, 03 Oct 2003 23:34:24 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h943YElg033512; Sat, 4 Oct 2003 03:34:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031004055942.03f05110@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 04 Oct 2003 08:33:56 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] RFC3296 review Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 04:59 PM 10/3/2003, Jim Sermersheim wrote: >I have been reviewing RFC3296. I did not review it in earnest (if at >all) during its last call, so, well, there's my excuse--you don't need >to slam me, I've just slammed myself... > >I'm splitting my questions/comments into three parts. First are some >general questions which I'm simply curious about (most of the "why does >it say that" nature). Second are issues that I see being obstructions to >future specifications (like chaining). Third (and I wish it were not so) >some problems that I consider being impediments to implementing the RFC. >I know that one or more of these prevent at least one vendor from >implementing the RFC. Most of these topics were discussed on the list.... >Questions: >Q1: Why is it that LDAP URL values in the ref attribute SHOULD contain >a non-empty DN? I imagine that many Referral objects will have the same >name as the object they point at in the remote DSA. It seems better to >state that when the DN of the remote object differs, that the DN field >is present. If they are the same, it's easier to deal with events like >moves and renames. While some servers do that... others treat the URL as referring to the root DSE. To avoid interoperability problems, the specification recommends the DN always be explicit. >Q2: In Section 5.3, Cases 2 and 4: Why MUST the server return an >explicit scope when returning a referral (not search result reference)? >It will always be the same as the original--thus not needed as the >client (per RFC2251) MUST use the same scope. Because, per RFC 2255, the default scope is "base". However, some clients regarded no explicit scope as meaning to use the same scope (as implied by RFC 2251). To avoid interoperability problems, the specification mandates the scope be explicit. >Q3: Why is there a SHOULD NOT return referral for bind? I can think of >some possible problems, but it's not clear why this imperative is here. Note that this imperative is limited to one particular case... when the bind name is or is subordinate to a referral object. (There may be other cases where such an imperative might be appropriate, but that was left to LDAPBIS to address.) This imperative is because chasing a referral to another server cannot complete the authentication of the client to the original server. >Issues: >I1: Section 2.1 says: "Referral objects are analogous to X.500 >subordinate knowledge (subr) DSEs [X.501].". But in fact a Referral >object is more like a DSE with the subr *and* entry DSE Types. Analogous is that referral objects and subr DSE provide similar function. >I believe >there are many (most) cases where a subr DSE in and X.500 deployment are >*not* entry's. This inconsistency with X.501 makes me worry that X.500 >servers with LDAP front-ends will have a hard time implementing this >RFC. We'll see (at implementation report time, I guess). >I2: Why SHOULD NOT an LDAP URL in the ref attribute contain extensions? >Future applications will wish to make use of this field. Because it would be confusing as to whether the extension applied to how the server processed the URL or whether the extension was to be returned to the client for it to process. If some future application developer fully understands the implications of using LDAP URL extensions referrals, they can make use of them. >I3: Why is there an imperative restricting referential integrity >validation of the ref URI? Because the server cannot assume that it has the ability to verify the integrity of the URL. If the server developer fully understands the implications of verify URIs, they may. >I4: The ref attribute has an EQUALITY of caseExactMatch. This will >prohibit applications in the future from using it. Future applications >will want to treat the "ldap://example.org" and "ldap://192.0.34.166" as >equal. This _may_ be able to be worked around using an extensible match, >not sure... The choice of caseExactMatch was made due to labeledURI use of it. As far as doing matching differently, it would be hell. >Problems: >P1: The Referral object class is STRUCTURAL. This prohibits various >implementations from implementing the RFC. The DIT Structure Rule and >Name Form for this object class needs to allow it to be placed and named >in a variety of ways. If this was an AUXILIARY class, this problem could >be avoided. Such implementations likely should use subclasses of referral (as they do for aliases). >P2: Referral suggests using "extensibleObject" object class to allow >any naming. This doesn't work for some implementations that use name >forms. the extensibleObject object class is more analogous to having a >DIT Content rule that allows [anything] in the MAY list. It has nothing >to do with naming. We likely should add the subclassing approach when the RFC is revised. >P3: The ref attribute is supposed to hold a URI, and the RFC goes as >far as to say "If the URI component is not a LDAP URL, it should be >returned as is.". RFC2251 and draft-ietf-ldapbis-protocol-xx.txt says a >referral holds one or more URLs. How can a more generic URI be converted >to a more specific URL? As used in RFC 2251 and RFC 3396, the terms URI and URL are interchangeable. >Either RFC 3296 needs to address this, or >draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in >referral values. We likely should s/URL/URI/ in RFC 2251. >P4: In various places, the semantics of the ManageDsaIT control are >wrong. It states things like "When the control is present in the >request, the server SHALL NOT generate a referral or continuation >reference based upon information held in referral objects and instead >SHALL treat the referral object as a normal entry". AFAIK, during name >resolution, the manageDsaIT control is applied only when the last RDN of >the DN being evaluated is a reference. Yes. We'll need to correct this when the RFC is revised. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Oct 4 00:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11093 for ; Sat, 4 Oct 2003 00:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5eJp-0004iF-KB; Sat, 04 Oct 2003 00:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5eJ1-0004hz-4g for ldapext@optimus.ietf.org; Sat, 04 Oct 2003 00:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11057 for ; Sat, 4 Oct 2003 00:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5eIy-0003CN-00 for ldapext@ietf.org; Sat, 04 Oct 2003 00:46:08 -0400 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1A5eIx-0003CK-00 for ldapext@ietf.org; Sat, 04 Oct 2003 00:46:07 -0400 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 03 Oct 2003 22:45:37 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Fri, 03 Oct 2003 22:45:23 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] RFC3296 review Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part0A544673.0__=" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0A544673.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> "Kurt D. Zeilenga" Kurt@OpenLDAP.org> 10/4/03 9:33:56 AM >> >>Problems: >>P1: The Referral object class is STRUCTURAL. This prohibits various >>implementations from implementing the RFC. The DIT Structure Rule and >>Name Form for this object class needs to allow it to be placed and named >>in a variety of ways. If this was an AUXILIARY class, this problem could >>be avoided. > >Such implementations likely should use subclasses of referral (as >they do for aliases). As we all know this underspecification of aliases has been problematic. I assume one reason that RFC3296 was published was to promote interoperability of the management of subordinate references. If one DSA allows "referral" and "extensableObject" to build a subordinate reference, and another requires some number of subclasses (domainContainerSubRef, organizationSubRef, localitySubRef, and on and on ad nauseum), it is an imedement to interoperability. If there is a better solution, the better solution should be preferred. >>P2: Referral suggests using "extensibleObject" object class to allow >>any naming. This doesn't work for some implementations that use name >>forms. the extensibleObject object class is more analogous to having a >>DIT Content rule that allows [anything] in the MAY list. It has nothing >>to do with naming. > >We likely should add the subclassing approach when the RFC is revised. I would prefer a non-subclassing solution. I'd rather not see one referral-type subclass for every naming and containment scenario. One idea is to allow an aux class to mark an entry as a reference, another idea is to use a DSEType attribute, a third idea is to invent an name form and dit structure rule. >>P3: The ref attribute is supposed to hold a URI, and the RFC goes as >>far as to say "If the URI component is not a LDAP URL, it should be >>returned as is.". RFC2251 and draft-ietf-ldapbis-protocol-xx.txt says a >>referral holds one or more URLs. How can a more generic URI be converted >>to a more specific URL? > >As used in RFC 2251 and RFC 3396, the terms URI and URL are >interchangeable. It is not clear in my mind why you say this. I'll have to do some more reading I guess. >>Either RFC 3296 needs to address this, or >>draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in >>referral values. > >We likely should s/URL/URI/ in RFC 2251. Probably. I'll raise in ldapbis. >>P4: In various places, the semantics of the ManageDsaIT control are >>wrong. It states things like "When the control is present in the >>request, the server SHALL NOT generate a referral or continuation >>reference based upon information held in referral objects and instead >>SHALL treat the referral object as a normal entry". AFAIK, during name >>resolution, the manageDsaIT control is applied only when the last RDN of >>the DN being evaluated is a reference. > >Yes. We'll need to correct this when the RFC is revised. > >Kurt Regarding the answers to the other questions/issues, they all seam reasonable, but I wish most of the explanations were present in the RFC. Also, I think the issues #2 and 3 (SHOULD NOT have LDAP URL extensions, and SHOULD NOT validate referential integrity) should be prefixed with like "in absense of further specification...". This would clarify the intent. Thanks for the quick response. Jim --=__Part0A544673.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
>>> "Kurt D. Zeilenga" Kurt@OpenLDAP.org> 10/4/03 9:33:56 AM >>
>>Problems:
>>P1: The Referral object class is STRUCTURAL. This prohibits various
>>implementations from implementing the RFC. The DIT Structure Rule and
>>Name Form for this object class needs to allow it to be placed and named
>>in a variety of ways. If this was an AUXILIARY class, this problem could
>>be avoided.
>
>Such implementations likely should use subclasses of referral (as
>they do for aliases).
As we all know this underspecification of aliases has been problematic. I assume one reason that RFC3296 was published was to promote interoperability of the management of subordinate references. If one DSA allows "referral" and "extensableObject" to build a subordinate reference, and another requires some number of subclasses (domainContainerSubRef, organizationSubRef, localitySubRef, and on and on ad nauseum), it is an imedement to interoperability. If there is a better solution, the better solution should  be preferred.

>>P2: Referral suggests using "extensibleObject" object class to allow
>>any naming. This doesn't work for some implementations that use name
>>forms. the extensibleObject object class is more analogous to having a
>>DIT Content rule that allows [anything] in the MAY list. It has nothing
>>to do with naming.
>
>We likely should add the subclassing approach when the RFC is revised.
I would prefer a non-subclassing solution. I'd rather not see one referral-type subclass for every naming and containment scenario. One idea is to allow an aux class to mark an entry as a reference, another idea is to use a DSEType attribute, a third idea is to invent an <any> name form and <any> dit structure rule.

>>P3: The ref attribute is supposed to hold a URI, and the RFC goes as
>>far as to say "If the URI component is not a LDAP URL, it should be
>>returned as is.". RFC2251 and draft-ietf-ldapbis-protocol-xx.txt says a
>>referral holds one or more URLs. How can a more generic URI be converted
>>to a more specific URL?
>
>As used in RFC 2251 and RFC 3396, the terms URI and URL are
>interchangeable.
It is not clear in my mind why you say this. I'll have to do some more reading I guess.

>>Either RFC 3296 needs to address this, or
>>draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in
>>referral values.
>
>We likely should s/URL/URI/ in RFC 2251.
Probably. I'll raise in ldapbis.

>>P4: In various places, the semantics of the ManageDsaIT control are
>>wrong. It states things like "When the control is present in the
>>request, the server SHALL NOT generate a referral or continuation
>>reference based upon information held in referral objects and instead
>>SHALL treat the referral object as a normal entry". AFAIK, during name
>>resolution, the manageDsaIT control is applied only when the last RDN of
>>the DN being evaluated is a reference.
>
>Yes. We'll need to correct this when the RFC is revised.
>
>Kurt
Regarding the answers to the other questions/issues, they all seam reasonable, but I wish most of the explanations were present in the RFC. Also, I think the issues  #2 and 3 (SHOULD NOT have LDAP URL extensions, and SHOULD NOT validate referential integrity) should be prefixed with like "in absense of further specification...". This would clarify the intent.

Thanks for the quick response.
 
Jim
--=__Part0A544673.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Oct 4 13:26:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09984 for ; Sat, 4 Oct 2003 13:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5qAL-0006FY-5T; Sat, 04 Oct 2003 13:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5q9b-0006DT-Ma for ldapext@optimus.ietf.org; Sat, 04 Oct 2003 13:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09968 for ; Sat, 4 Oct 2003 13:25:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5q9Z-0001mj-00 for ldapext@ietf.org; Sat, 04 Oct 2003 13:25:13 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A5q9Y-0001mg-00 for ldapext@ietf.org; Sat, 04 Oct 2003 13:25:12 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h94HP5lg040307; Sat, 4 Oct 2003 17:25:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031004211520.02b0fce0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 04 Oct 2003 22:24:46 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] RFC3296 review Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 09:45 PM 10/3/2003, Jim Sermersheim wrote: >>>> "Kurt D. Zeilenga" 10/4/03 9:33:56 AM >>>Kurt@OpenLDAP.org> 10/4/03 9:33:56 AM >> >>>Problems: >>>P1: The Referral object class is STRUCTURAL. This prohibits various >>>implementations from implementing the RFC. The DIT Structure Rule and >>>Name Form for this object class needs to allow it to be placed and named >>>in a variety of ways. If this was an AUXILIARY class, this problem could >>>be avoided. >> >>Such implementations likely should use subclasses of referral (as >>they do for aliases). >As we all know this underspecification of aliases has been problematic. >I assume one reason that RFC3296 was published was to promote interoperability of the management of subordinate references. >If one DSA allows "referral" and "extensableObject" to build a subordinate reference, and another requires some number of subclasses (domainContainerSubRef, organizationSubRef, localitySubRef, and on and on ad nauseum), it is an imedement to interoperability. Note that some prefer to use cnAliasObject, uidAliasObject, etc., then to use SUPs, others prefer an AUX cnObject, uidObject, etc.. Others avoid multiple classes by having one class which list all the allowed naming attributes. Others use DIT content rules. Sure, it is hard for a client to know which to use. Anyways, as this issue: How do clients determine how to augment objectclass attribute to allow the naming attribute(s) to be present? exists for alias objects and that specification is currently being revised, I suggest we take this issue to LDAPBIS. I note, at least, where one uses subclasses... the client can see determine which subclasses are available in the subschema. Likewise for DIT content rules. >If there is a better solution, the better solution should be preferred. I think there is significant contention as to what's best here. Personally, I think the server should describe in its subschema which naming attributes are allowed to be present in which referral and alias objects (just as they do for other objects). The server should be allowed to use any schema mechanism available to it. >>>P2: Referral suggests using "extensibleObject" object class to allow >>>any naming. This doesn't work for some implementations that use name >>>forms. the extensibleObject object class is more analogous to having a >>>DIT Content rule that allows [anything] in the MAY list. It has nothing >>>to do with naming. >> >>We likely should add the subclassing approach when the RFC is revised. >I would prefer a non-subclassing solution. I'd rather not see one referral-type subclass for every naming and containment scenario. One idea is to allow an aux class to mark an entry as a reference, another idea is to use a DSEType attribute, a third idea is to invent an name form and dit structure rule. I rather not re-invent referral objects (or invent new schema mechanisms). >>>P3: The ref attribute is supposed to hold a URI, and the RFC goes as >>>far as to say "If the URI component is not a LDAP URL, it should be >>>returned as is.". RFC2251 and draft-ietf-ldapbis-protocol-xx.txt says a >>>referral holds one or more URLs. How can a more generic URI be converted >>>to a more specific URL? >> >>As used in RFC 2251 and RFC 3396, the terms URI and URL are >>interchangeable. >It is not clear in my mind why you say this. I'll have to do some more reading I guess. Because to the protocol, it is irrelevant as to whether a particular URI was classified as a URL or not. What matters is whether or not the URI can be used to complete the operation. >>>Either RFC 3296 needs to address this, or >>>draft-ietf-ldapbis-protocol-xx.txt needs to allow URI to be returned in >>>referral values. >> >>We likely should s/URL/URI/ in RFC 2251. >Probably. I'll raise in ldapbis. > >>>P4: In various places, the semantics of the ManageDsaIT control are >>>wrong. It states things like "When the control is present in the >>>request, the server SHALL NOT generate a referral or continuation >>>reference based upon information held in referral objects and instead >>>SHALL treat the referral object as a normal entry". AFAIK, during name >>>resolution, the manageDsaIT control is applied only when the last RDN of >>>the DN being evaluated is a reference. >> >>Yes. We'll need to correct this when the RFC is revised. >> >>Kurt >Regarding the answers to the other questions/issues, they all seam reasonable, but I wish most of the explanations were present in the RFC. Some elaboration may be appropriate... > Also, I think the issues #2 and 3 (SHOULD NOT have LDAP URL extensions, and SHOULD NOT validate referential integrity) should be prefixed with like "in absense of further specification...". This would clarify the intent. No, that wasn't the intent. The intent was to say that implementors should not do X unless they fully understand the implications of doing X. That is, (as I attempted to clarify) the SHOULD NOT, like any other SHOULD NOT, may be ignored as discussed in RFC 2119. I don't think we should cloud the imperatives with "further specification" statements. >Thanks for the quick response. You're welcomed. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 23 21:52:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28893 for ; Thu, 23 Oct 2003 21:52:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACr7Q-0002yT-AE; Thu, 23 Oct 2003 21:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACr6h-0002tf-1e for ldapext@optimus.ietf.org; Thu, 23 Oct 2003 21:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28879 for ; Thu, 23 Oct 2003 21:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACr6e-0003mX-00 for ldapext@ietf.org; Thu, 23 Oct 2003 21:51:12 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1ACr6c-0003mB-00 for ldapext@ietf.org; Thu, 23 Oct 2003 21:51:11 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Fri, 24 Oct 2003 11:44:34 +1000 Received: (qmail 12533 invoked from network); 24 Oct 2003 01:50:33 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 24 Oct 2003 01:50:33 -0000 Reply-To: From: "Andrew Sciberras" To: , , "'Ldapext \(E-mail\)'" Date: Fri, 24 Oct 2003 11:50:32 +1000 Message-ID: <013901c399d1$36a6c6e0$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [ldapext] draft-ietf-boreham-numsubordinates-01.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Just some comments regarding draft-ietf-boreham-numsubordinates-01.txt. Firstly I'm curious as to what `numSubordinates' identifies as being a subordinate? Eg. Is a subentry counted as a subordinate? >4. Attribute Definition > > ( 1.3.6.1.4.1.453.16.2.103 NAME 'numSubordinates' > DESC 'count of immediate subordinates' > EQUALITY integerMatch ORDERING integerOrderingMatch > SYNTAX 1.3.6.1.4.1.453.16.2.103 > SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) > > numSubordinates ATTRIBUTE ::= { > WITH SYNTAX INTEGER > USAGE directoryOperation > SINGLEVALUED TRUE > NO USER MODIFICATION TRUE > ID {dod internet(1) private(4) > enterprises(1) isode-consortium(453) > ic-dsa(16) ic-dsa-at(2) 103} > } The SYNTAX is incorrect. It should be 1.3.6.1.4.1.1466.115.121.1.27 > 5. Client-Server Interaction >Servers MUST ensure that the value returned in the numSubordinates >attibute to clients is consistent with the view that client has of other >server contents. Is this suggesting that the numSubordinates value should take access control information into consideration, and only provide an indication of how many subordinate entries the user has access to? >6. Relationship to hasSubordinates > >The X.500 hasSubordinates operational attribute[ITU-X501] can be >regarded as indicating whether numSubordinates has a non-zero value for >the same entry. This leads to the potential for optimization in a server >implementation, in that it isn't necessary to store both values. This may not be exactly the case, as a TRUE value of the `hasSubordinates' attribute only indicates that subordinates _may_ exist. As stated in X501: A value of TRUE may be returned when no subordinates exist if all possible subordinates are available only through a non-specific subordinate reference (see ITU-T Rec. X.518 | ISO/IEC 9594-4) or if the only subordinates are subentries or child family members. Cheers, Andrew Sciberras Adacel Technologies Ltd _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 24 06:31:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24228 for ; Fri, 24 Oct 2003 06:31:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzDj-0005OW-1T; Fri, 24 Oct 2003 06:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzCs-0005GW-R8 for ldapext@optimus.ietf.org; Fri, 24 Oct 2003 06:30:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24076 for ; Fri, 24 Oct 2003 06:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACzCo-00013G-00 for ldapext@ietf.org; Fri, 24 Oct 2003 06:30:06 -0400 Received: from krl9-d9bb4361.pool.mediaways.net ([217.187.67.97] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1ACzCn-00012u-00 for ldapext@ietf.org; Fri, 24 Oct 2003 06:30:06 -0400 Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 60FCE1F28B; Fri, 24 Oct 2003 12:29:27 +0200 (CEST) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6E6561F25D; Fri, 24 Oct 2003 12:29:26 +0200 (CEST) Message-ID: <3F98FF06.8060000@stroeder.com> Date: Fri, 24 Oct 2003 12:29:26 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: andrews@adacel.com.au Cc: S.Kille@ISODE.COM, david@bozemanpass.com, "'Ldapext (E-mail)'" Subject: Re: [ldapext] draft-ietf-boreham-numsubordinates-01.txt References: <013901c399d1$36a6c6e0$a618200a@mtwav.adacel.com.au> In-Reply-To: <013901c399d1$36a6c6e0$a618200a@mtwav.adacel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI! I'd also like to add something from the client perspective. IMHO one of the most important use-cases for this kind of operational attributes is that it enables the client to detect leaf entries which is very useful for implementing a comfortable user interface. > 4. Attribute Definition > [..] > Every entry in the DIT MAY have a numSubordinates operational attribute > the contents of which indicate how many immediate subordinates that > entry has. For example, a leaf entry would have numSubordinates equal to > "0". Entry "ou=People, o=ace industry, c=us" in a DIT where the contents > of that container comprises 1000 leaf entries, would have > numSubordinates equal to "1000". Note that a recent version of one LDAP server implementing numSubordinates (SunOne/iPlanet DS 5.x) unfortunately does not return numSubordinates: 0 anymore (in opposite to Netscape DS 4.x). Instead no numSubordinates attribute is returned. This makes this attribute unusable to determine whether an entry is a leaf entry or not. I'd like to see a note stating 'MUST return zero integer value "0" for leaf entries'. > 6. Relationship to hasSubordinates > > The X.500 hasSubordinates operational attribute[ITU-X501] can be > regarded as indicating whether numSubordinates has a non-zero value for > the same entry. This leads to the potential for optimization in a server > implementation, in that it isn't necessary to store both values. I'd like to add a note that it's RECOMMENDED to implement hasSubordinates on the server's side if the server already implements numSubordinates. I think the "potential for optimization" justifies this. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 24 09:31:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29915 for ; Fri, 24 Oct 2003 09:31:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD21u-0001Ps-L0; Fri, 24 Oct 2003 09:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrG9-0005Vt-EH for ldapext@optimus.ietf.org; Thu, 23 Oct 2003 22:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29114 for ; Thu, 23 Oct 2003 22:00:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrG6-0003s8-00 for ldapext@ietf.org; Thu, 23 Oct 2003 22:00:58 -0400 Received: from server1.montana.boreham.org ([63.112.219.168] helo=toad.mtbrook.boreham.org) by ietf-mx with esmtp (Exim 4.12) id 1ACrG5-0003s3-00 for ldapext@ietf.org; Thu, 23 Oct 2003 22:00:58 -0400 Received: from squirrel (squirrel.mtbrook.boreham.org [63.112.219.169]) by toad.mtbrook.boreham.org (Postfix) with SMTP id 455373FA0; Thu, 23 Oct 2003 19:00:27 -0700 (PDT) Message-ID: <058601c399d2$f34a4aa0$f400fc0a@mtbrook.boreham.org> From: "David Boreham" To: , , "'Ldapext (E-mail)'" References: <013901c399d1$36a6c6e0$a618200a@mtwav.adacel.com.au> Date: Thu, 23 Oct 2003 19:03:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Firstly I'm curious as to what `numSubordinates' identifies as being a > subordinate? > Eg. Is a subentry counted as a subordinate? Good question, and I remember this coming up when I implemented the feature. My vote would be to not count subentries, but I'm interested to hear what other folks think. > The SYNTAX is incorrect. It should be 1.3.6.1.4.1.1466.115.121.1.27 Thanks. I suspect this was a typo as I had an old copy of the document with the correct syntax OID (which I un-corrected thinking that it was an error since it didn't match the 1999 version of the document). > >Servers MUST ensure that the value returned in the numSubordinates > >attibute to clients is consistent with the view that client has of other > >server contents. > > Is this suggesting that the numSubordinates value should take access control > information into consideration, and only provide an indication of how many > subordinate entries the user has access to? Yes. > >The X.500 hasSubordinates operational attribute[ITU-X501] can be > >regarded as indicating whether numSubordinates has a non-zero value for > >the same entry. This leads to the potential for optimization in a server > >implementation, in that it isn't necessary to store both values. > > This may not be exactly the case, as a TRUE value of the `hasSubordinates' > attribute only indicates that subordinates _may_ exist. > As stated in X501: > > A value of TRUE may be returned when no subordinates exist if all possible > subordinates are available only through a > non-specific subordinate reference (see ITU-T Rec. X.518 | ISO/IEC 9594-4) > or if the only subordinates are subentries or child > family members. Hmm...interesting. I'm happy to remove the paragraph referencing X.501. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 24 10:21:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02414 for ; Fri, 24 Oct 2003 10:21:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2oG-0006mu-Pk; Fri, 24 Oct 2003 10:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2nL-0006g0-8F for ldapext@optimus.ietf.org; Fri, 24 Oct 2003 10:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02328 for ; Fri, 24 Oct 2003 10:19:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD2nI-0003le-00 for ldapext@ietf.org; Fri, 24 Oct 2003 10:20:00 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1AD2nI-0003lR-00 for ldapext@ietf.org; Fri, 24 Oct 2003 10:20:00 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9OEJQoW288722; Fri, 24 Oct 2003 10:19:27 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9OEJOJY069792; Fri, 24 Oct 2003 10:19:25 -0400 Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt To: "David Boreham" Cc: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 24 Oct 2003 09:19:23 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 10/24/2003 09:19:25 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , I'd vote for including subentries. The X.501 text allows hasSubordinate to be true if the only children are subentries. It seems a bit inconsistent to return hasSubordinates=TRUE and numSubordinates=0. I would expect that there will be cases (no access, subentries, maybe other cases) where numSubordinates or hasSubordinates will indicate the presence of entries that don't seem to be there. John McMeeking "David Boreham" , , "'Ldapext s.com> (E-mail)'" Sent by: cc: ldapext-admin@iet Subject: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt f.org 10/23/2003 09:03 PM > Firstly I'm curious as to what `numSubordinates' identifies as being a > subordinate? > Eg. Is a subentry counted as a subordinate? Good question, and I remember this coming up when I implemented the feature. My vote would be to not count subentries, but I'm interested to hear what other folks think. > The SYNTAX is incorrect. It should be 1.3.6.1.4.1.1466.115.121.1.27 Thanks. I suspect this was a typo as I had an old copy of the document with the correct syntax OID (which I un-corrected thinking that it was an error since it didn't match the 1999 version of the document). > >Servers MUST ensure that the value returned in the numSubordinates > >attibute to clients is consistent with the view that client has of other > >server contents. > > Is this suggesting that the numSubordinates value should take access control > information into consideration, and only provide an indication of how many > subordinate entries the user has access to? Yes. > >The X.500 hasSubordinates operational attribute[ITU-X501] can be > >regarded as indicating whether numSubordinates has a non-zero value for > >the same entry. This leads to the potential for optimization in a server > >implementation, in that it isn't necessary to store both values. > > This may not be exactly the case, as a TRUE value of the `hasSubordinates' > attribute only indicates that subordinates _may_ exist. > As stated in X501: > > A value of TRUE may be returned when no subordinates exist if all possible > subordinates are available only through a > non-specific subordinate reference (see ITU-T Rec. X.518 | ISO/IEC 9594-4) > or if the only subordinates are subentries or child > family members. Hmm...interesting. I'm happy to remove the paragraph referencing X.501. _______________________________________________ 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-admin@ietf.org Fri Oct 24 10:42:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03934 for ; Fri, 24 Oct 2003 10:42:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD38a-0001IS-Oa; Fri, 24 Oct 2003 10:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD38P-0001H1-0B for ldapext@optimus.ietf.org; Fri, 24 Oct 2003 10:41:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03865 for ; Fri, 24 Oct 2003 10:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD38M-00045U-00 for ldapext@ietf.org; Fri, 24 Oct 2003 10:41:46 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AD38L-00045R-00 for ldapext@ietf.org; Fri, 24 Oct 2003 10:41:45 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9OEfg5u020865; Fri, 24 Oct 2003 08:41:43 -0600 (MDT) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h9OEffv13591; Fri, 24 Oct 2003 16:41:42 +0200 (MEST) Message-ID: <3F9939DB.5070305@Sun.COM> Date: Fri, 24 Oct 2003 16:40:27 +0200 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John McMeeking CC: David Boreham , ldapext@ietf.org Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'd vote for including subentries as well... You can have a numSubordinate != 0 and not being able to see children entries (due to access controls). But having numSubordinate = 0 and getting a NON_LEAF error when deleting the entry will be be perceived as more confusing. Ludovic. John McMeeking wrote: > > >I'd vote for including subentries. > >The X.501 text allows hasSubordinate to be true if the only children are >subentries. It seems a bit inconsistent to return hasSubordinates=TRUE and >numSubordinates=0. I would expect that there will be cases (no access, >subentries, maybe other cases) where numSubordinates or hasSubordinates >will indicate the presence of entries that don't seem to be there. > >John McMeeking > > > > > "David Boreham" > , , "'Ldapext > s.com> (E-mail)'" > Sent by: cc: > ldapext-admin@iet Subject: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt > f.org > > > 10/23/2003 09:03 > PM > > > > > > > > >>Firstly I'm curious as to what `numSubordinates' identifies as being a >>subordinate? >>Eg. Is a subentry counted as a subordinate? >> >> > >Good question, and I remember this coming up when I implemented the >feature. >My vote would be to not count subentries, but I'm interested to hear what >other folks think. > > > >>The SYNTAX is incorrect. It should be 1.3.6.1.4.1.1466.115.121.1.27 >> >> > >Thanks. I suspect this was a typo as I had an old copy >of the document with the correct syntax OID (which I >un-corrected thinking that it was an error since it didn't >match the 1999 version of the document). > > > >>>Servers MUST ensure that the value returned in the numSubordinates >>>attibute to clients is consistent with the view that client has of other >>>server contents. >>> >>> >>Is this suggesting that the numSubordinates value should take access >> >> >control > > >>information into consideration, and only provide an indication of how >> >> >many > > >>subordinate entries the user has access to? >> >> > >Yes. > > > >>>The X.500 hasSubordinates operational attribute[ITU-X501] can be >>>regarded as indicating whether numSubordinates has a non-zero value for >>>the same entry. This leads to the potential for optimization in a server >>>implementation, in that it isn't necessary to store both values. >>> >>> >>This may not be exactly the case, as a TRUE value of the >> >> >`hasSubordinates' > > >>attribute only indicates that subordinates _may_ exist. >>As stated in X501: >> >>A value of TRUE may be returned when no subordinates exist if all >> >> >possible > > >>subordinates are available only through a >>non-specific subordinate reference (see ITU-T Rec. X.518 | ISO/IEC >> >> >9594-4) > > >>or if the only subordinates are subentries or child >>family members. >> >> > >Hmm...interesting. I'm happy to remove the paragraph referencing X.501. > > > > >_______________________________________________ >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-admin@ietf.org Fri Oct 24 14:51:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22897 for ; Fri, 24 Oct 2003 14:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD71a-00009m-8F; Fri, 24 Oct 2003 14:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD717-0008WS-0Z for ldapext@optimus.ietf.org; Fri, 24 Oct 2003 14:50:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22850 for ; Fri, 24 Oct 2003 14:50:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD712-0002bp-00 for ldapext@ietf.org; Fri, 24 Oct 2003 14:50:28 -0400 Received: from krl9-d9bb4fe8.pool.mediaways.net ([217.187.79.232] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1AD712-0002ba-00 for ldapext@ietf.org; Fri, 24 Oct 2003 14:50:28 -0400 Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 79E2C7EDED; Fri, 24 Oct 2003 20:49:56 +0200 (CEST) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A80D722C73; Fri, 24 Oct 2003 20:49:55 +0200 (CEST) Message-ID: <3F997453.7020507@stroeder.com> Date: Fri, 24 Oct 2003 20:49:55 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Ludovic Poitou Cc: John McMeeking , David Boreham , ldapext@ietf.org Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: <3F9939DB.5070305@Sun.COM> In-Reply-To: <3F9939DB.5070305@Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ludovic Poitou wrote: > > John McMeeking wrote: >> >>> Firstly I'm curious as to what `numSubordinates' identifies as being a >>> subordinate? >>> Eg. Is a subentry counted as a subordinate? >> I'd vote for including subentries. >> > I'd vote for including subentries as well... Any use-cases for including subentries? Which are the use-cases for 'numSubordinates'? > You can have a numSubordinate != 0 and not being able to see children > entries (due to access controls). Yes. But what's the problem with that? > But having numSubordinate = 0 and getting a NON_LEAF error when deleting > the entry will be be perceived as more confusing. Does this really happen at all? Maybe I don't understand this sentence. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Oct 27 12:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25781 for ; Mon, 27 Oct 2003 12:12:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAuP-0000fA-4w; Mon, 27 Oct 2003 12:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAts-0000cd-G7 for ldapext@optimus.ietf.org; Mon, 27 Oct 2003 12:11:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25714 for ; Mon, 27 Oct 2003 12:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEAtq-0000e7-00 for ldapext@ietf.org; Mon, 27 Oct 2003 12:11:27 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AEAtq-0000e4-00 for ldapext@ietf.org; Mon, 27 Oct 2003 12:11:26 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RHBMPh008628; Mon, 27 Oct 2003 10:11:23 -0700 (MST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h9RHBLv05471; Mon, 27 Oct 2003 18:11:21 +0100 (MET) Message-ID: <3F9D516C.1090203@Sun.COM> Date: Mon, 27 Oct 2003 18:10:04 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= CC: John McMeeking , David Boreham , ldapext@ietf.org Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: <3F9939DB.5070305@Sun.COM> <3F997453.7020507@stroeder.com> In-Reply-To: <3F997453.7020507@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Michael Str=F6der wrote: > Ludovic Poitou wrote: > > > > John McMeeking wrote: > >> > >>> Firstly I'm curious as to what `numSubordinates' identifies as=20 > being a > >>> subordinate? > >>> Eg. Is a subentry counted as a subordinate? > >> I'd vote for including subentries. > >> > >> I'd vote for including subentries as well... > > > Any use-cases for including subentries? > Which are the use-cases for 'numSubordinates'? The question was whether SubEntries should be counted in the=20 numSubordinate operational attribute. My vote was yes... > >> You can have a numSubordinate !=3D 0 and not being able to see childre= n=20 >> entries (due to access controls). > > > Yes. But what's the problem with that? No problem. If subentries are counted in the numSubordinate attribute,=20 an entry that has subEntries will have a positive numSubordinate but=20 regular client applications won't see any child entries. Some apps may=20 be confused by this behavior, but this can already happen with ACI. As opposed, not counting SubEntries in the numSubordinate attribute, an=20 application can read the numSubordiante attribute, see its value is 0,=20 delete the entry and get a NON_LEAF error... and be confused.... I prefer the first scenario to the second one. > >> But having numSubordinate =3D 0 and getting a NON_LEAF error when=20 >> deleting the entry will be be perceived as more confusing. > > > Does this really happen at all? Maybe I don't understand this sentence.= > This is what would happen if Subentries are NOT counted as numSubordinate= =2E Ludovic. > Ciao, Michael. > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Oct 27 13:29:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28596 for ; Mon, 27 Oct 2003 13:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEC6v-0007hl-Pc; Mon, 27 Oct 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEC6E-0007Ys-76 for ldapext@optimus.ietf.org; Mon, 27 Oct 2003 13:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28522 for ; Mon, 27 Oct 2003 13:28:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEC6C-0001Xo-00 for ldapext@ietf.org; Mon, 27 Oct 2003 13:28:16 -0500 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AEC6B-0001Xl-00 for ldapext@ietf.org; Mon, 27 Oct 2003 13:28:15 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id h9RIS6lg066397; Mon, 27 Oct 2003 18:28:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20031027091611.02bc7c40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 27 Oct 2003 10:27:23 -0800 To: david@bozemanpass.com, S.Kille@ISODE.COM From: "Kurt D. Zeilenga" Cc: ldapext@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] Re: draft-boreham-numsubordinates-01.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , David, Steve: Technical comments: The document is not clear as to whether it is describing the well established semantics of an existing attribute or is attempting to introduce an attribute with possibly new semantics. That is, are you just documenting what is or are you engineering what will be? I'll defer making most of my comments until you clarify your objectives to the list, as they hinge on whether your engineering a new attribute type or documenting the well established semantics of an existing attribute type. A few things which don't hinge on the above question: I note that RFC 2252 and X.501 descriptions of attribute type differ in specified matching rules. DN string used in example does not strictly conform to RFC 2253 (extra spaces). I suggest the document not detail handling of NO-USER-MODIFICATION issues as such detailing is better left to base protocol specification. It is sufficient to say that the attribute is defined as not allowing user modification and then cite RFC 2251 and 2252. This avoids possible introduction of attribute type specific semantics (to what should remain attribute type neutral semantics). Security Considerations section should note that general LDAP security considerations (cite RFC 3377) apply. Editorial comments: Document missing required text/sections Does not include (precisely) one of three listed RFC 2026 statements (see ID guidelines) Does not include IANA Considerations section (to detail OID assignment and request registration of attribute type's short name). Does not include IPR statement. Does not include short copyright statement. Does not include full copyright statement. Document is not properly formatted. - Don't right justify text - Don't hyphenate words Document is garbled - hyphens replaced with spaces Document contains numerous nits - acronyms not spelled out on first use in Abstact - acronyms not spelled ont on first use in body - references not split (normative v. informative) The text "is it NOT" likely should be "it is not". (out of order, NOT isn't a keyword so shouldn't be uppercased.) Should cite RFC 3377 on first use of the term LDAP. Should cite RFC 2251 on first use of an protocol element defined in RFC 2251 (such as the Search operation). Should cite X.501 on use of term DIT. Should cite RFC 2252 when presenting LDAP attribute type descriptions. Should cite draft-zeilenga-ldap-user-schema-mr for integerOrderingMatch. -- Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Oct 27 20:23:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02596 for ; Mon, 27 Oct 2003 20:23:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEIZY-0000ck-G4; Mon, 27 Oct 2003 20:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEIZ5-0000aw-Fx for ldapext@optimus.ietf.org; Mon, 27 Oct 2003 20:22:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02551 for ; Mon, 27 Oct 2003 20:22:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEIZ3-0003Xp-00 for ldapext@ietf.org; Mon, 27 Oct 2003 20:22:29 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1AEIZ2-0003XV-00 for ldapext@ietf.org; Mon, 27 Oct 2003 20:22:28 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Oct 2003 18:21:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 27 Oct 2003 18:21:33 -0700 From: "Jim Sermersheim" To: , , Cc: Subject: [ldapext] Re: draft-boreham-numsubordinates-01.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part83DD2C8D.1__=" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part83DD2C8D.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>> "Kurt D. Zeilenga" 10/27/03 11:27:23 AM >>> >David, Steve: > >Technical comments: >The document is not clear as to whether it is describing the >well established semantics of an existing attribute or is >attempting to introduce an attribute with possibly new >semantics. That is, are you just documenting what is or are you >engineering what will be? I'll defer making most of my >comments until you clarify your objectives to the list, >as they hinge on whether your engineering a new attribute >type or documenting the well established semantics of an >existing attribute type. As I (hope to) understand it, the document is defining an attribute that has a specific purpose. It happens that the attribute is currently being used by one or more vendors, but it may be used in different ways due to the lack of this Internet-Draft being progressed. My hope is that the Internet-Draft's purpose is primarily to define this attribute in a way that leads it to be used interoperably, regardless of whether that will cause existing applications to change. In addition, if there are sufficient changes to the specification of the attribute, a new OID (and possibly short name) may be warranted so the existing applications won't automatically be broken (this makes a good case for defering OID assignment to RFC publication). Maybe this is is near the point at which you were driving. Jim --=__Part83DD2C8D.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/27/03 11:27:23 AM >>>
>David, Steve:
>
>Technical comments:
>The document is not clear as to whether it is describing the
>well established semantics of an existing attribute or is
>attempting to introduce an attribute with possibly new
>semantics. That is, are you just documenting what is or are you
>engineering what will be? I'll defer making most of my
>comments until you clarify your objectives to the list,
>as they hinge on whether your engineering a new attribute
>type or documenting the well established semantics of an
>existing attribute type.
As I (hope to) understand it, the document is defining an attribute that has a specific purpose. It happens that the attribute is currently being used by one or more vendors, but it may be used in different ways due to the lack of this Internet-Draft being progressed. My hope is that the Internet-Draft's purpose is primarily to define this attribute in a way that leads it to be used interoperably, regardless of whether that will cause existing applications to change.
 
In addition, if there are sufficient changes to the specification of the attribute, a new OID (and possibly short name) may be warranted so the existing applications won't automatically be broken (this makes a good case for defering OID assignment to RFC publication).  Maybe this is is near the point at which you were driving.
 
Jim
--=__Part83DD2C8D.1__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 28 04:18:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11206 for ; Tue, 28 Oct 2003 04:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPzJ-0001vf-5I; Tue, 28 Oct 2003 04:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPyt-0001sm-1n for ldapext@optimus.ietf.org; Tue, 28 Oct 2003 04:17:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11168 for ; Tue, 28 Oct 2003 04:17:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPyp-00064r-00 for ldapext@ietf.org; Tue, 28 Oct 2003 04:17:35 -0500 Received: from lx.yapay.inka.de ([193.197.184.188] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1AEPyn-00064V-00 for ldapext@ietf.org; Tue, 28 Oct 2003 04:17:34 -0500 Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 299D67F07E; Tue, 28 Oct 2003 09:25:03 +0100 (CET) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id EB6077F067; Tue, 28 Oct 2003 09:25:01 +0100 (CET) Message-ID: <3F9E27DD.6070403@stroeder.com> Date: Tue, 28 Oct 2003 09:25:01 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Ludovic Poitou Cc: John McMeeking , David Boreham , ldapext@ietf.org Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: <3F9939DB.5070305@Sun.COM> <3F997453.7020507@stroeder.com> <3F9D516C.1090203@Sun.COM> In-Reply-To: <3F9D516C.1090203@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ludovic Poitou wrote: >=20 > Michael Str=F6der wrote: >=20 >> Ludovic Poitou wrote: >> > >> > John McMeeking wrote: >> >> >> >>> Firstly I'm curious as to what `numSubordinates' identifies as=20 >> being a >> >>> subordinate? >> >>> Eg. Is a subentry counted as a subordinate? >> >> I'd vote for including subentries. >> >>> I'd vote for including subentries as well... >> >> Any use-cases for including subentries? >> Which are the use-cases for 'numSubordinates'? >=20 > The question was whether SubEntries should be counted in the=20 > numSubordinate operational attribute. This question simply can't be answered without looking at possible use-ca= ses=20 for this attribute. > If subentries are counted in the numSubordinate attribute,=20 > an entry that has subEntries will have a positive numSubordinate but=20 > regular client applications won't see any child entries. Some apps may = > be confused by this behavior, but this can already happen with ACI. Yes, this is the same issue like any scenario with ACI/ACLs in effect. > As opposed, not counting SubEntries in the numSubordinate attribute, an= =20 > application can read the numSubordiante attribute, see its value is 0, = > delete the entry and get a NON_LEAF error... and be confused.... IMHO entry is leaf entry <=3D> value of hasSubordinates is 'FALSE' <=3D> value of numSubordinates is '0' no matter whether you count all sub entries or just the next level. Examples (please correct me if I got it wrong): 1. Counting all sub entries in numSubordinates: dc=3Dtest,dc=3Dcom (numSubordinates: 5) | +-ou=3DTest1 (numSubordinates: 0) | +-ou=3DTest2 (numSubordinates: 3) | +-cn=3DTestperson1 (numSubordinates: 0) | +-cn=3DTestperson2 (numSubordinates: 1) | +-mail=3Dtest1@test.com (numSubordinates: 0) 2. Counting only one-level in numSubordinates (similar to what's another = vendor is doing in an attribute called 'subordinateCount'): dc=3Dtest,dc=3Dcom (numSubordinates: 2) | +-ou=3DTest1 (numSubordinates: 0) | +-ou=3DTest2 (numSubordinates: 2) | +-cn=3DTestperson1 (numSubordinates: 0) | +-cn=3DTestperson2 (numSubordinates: 1) | +-mail=3Dtest1@test.com (numSubordinates: 0) As you can see in any scenario leaf-entries have numSubordinates set to z= ero. Hmm, maybe I don't understand the word "SubEntries" correctly? Maybe you are talking about sub entries like sub schema sub entry? Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 28 10:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29285 for ; Tue, 28 Oct 2003 10:23:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVgU-0002PO-1j; Tue, 28 Oct 2003 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVfo-0002Lx-2D for ldapext@optimus.ietf.org; Tue, 28 Oct 2003 10:22:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29211 for ; Tue, 28 Oct 2003 10:22:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVfl-0005Vc-00 for ldapext@ietf.org; Tue, 28 Oct 2003 10:22:17 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1AEVfk-0005Us-00 for ldapext@ietf.org; Tue, 28 Oct 2003 10:22:16 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Oct 2003 08:21:44 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 28 Oct 2003 08:21:14 -0700 From: "Jim Sermersheim" To: , Cc: , , Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part3A64967A.1__=" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3A64967A.1__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Right, when people on this thread are talking about subentries, they are = talking about subentries in the X.500 subentry sense of the word (like = subschema subentry, prescriptiveACI subentry, etc). Jim >>> Michael Str=F6der 10/28/03 1:25:01 AM >>> Ludovic Poitou wrote: >=20 > Michael Str=F6der wrote: >=20 >> Ludovic Poitou wrote: >> > >> > John McMeeking wrote: >> >> >> >>> Firstly I'm curious as to what `numSubordinates' identifies as=20 >> being a >> >>> subordinate? >> >>> Eg. Is a subentry counted as a subordinate? >> >> I'd vote for including subentries. >> >>> I'd vote for including subentries as well... >> >> Any use-cases for including subentries? >> Which are the use-cases for 'numSubordinates'? >=20 > The question was whether SubEntries should be counted in the=20 > numSubordinate operational attribute. This question simply can't be answered without looking at possible = use-cases=20 for this attribute. > If subentries are counted in the numSubordinate attribute,=20 > an entry that has subEntries will have a positive numSubordinate but=20 > regular client applications won't see any child entries. Some apps = may=20 > be confused by this behavior, but this can already happen with ACI. Yes, this is the same issue like any scenario with ACI/ACLs in effect. > As opposed, not counting SubEntries in the numSubordinate attribute, = an=20 > application can read the numSubordiante attribute, see its value is = 0,=20 > delete the entry and get a NON_LEAF error... and be confused.... IMHO entry is leaf entry <=3D> value of hasSubordinates is 'FALSE' <=3D> value of numSubordinates is '0' no matter whether you count all sub entries or just the next level. Examples (please correct me if I got it wrong): 1. Counting all sub entries in numSubordinates: dc=3Dtest,dc=3Dcom (numSubordinates: 5) | +-ou=3DTest1 (numSubordinates: 0) | +-ou=3DTest2 (numSubordinates: 3) | +-cn=3DTestperson1 (numSubordinates: 0) | +-cn=3DTestperson2 (numSubordinates: 1) | +-mail=3Dtest1@test.com (numSubordinates: 0) 2. Counting only one-level in numSubordinates (similar to what's another=20= vendor is doing in an attribute called 'subordinateCount'): dc=3Dtest,dc=3Dcom (numSubordinates: 2) | +-ou=3DTest1 (numSubordinates: 0) | +-ou=3DTest2 (numSubordinates: 2) | +-cn=3DTestperson1 (numSubordinates: 0) | +-cn=3DTestperson2 (numSubordinates: 1) | +-mail=3Dtest1@test.com (numSubordinates: 0) As you can see in any scenario leaf-entries have numSubordinates set to = zero. Hmm, maybe I don't understand the word "SubEntries" correctly? Maybe you are talking about sub entries like sub schema sub entry? Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 --=__Part3A64967A.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Right, when people on this thread are talking about subentries, they = are talking about subentries in the X.500 subentry sense of the word (like = subschema subentry, prescriptiveACI subentry, etc).

Jim

>>> Michael Str=F6der <michael@stroeder.com> = 10/28/03 1:25:01 AM >>>
Ludovic Poitou wrote:
>
> = Michael Str=F6der wrote:
>
>> Ludovic Poitou wrote:
>= > >
>> > John McMeeking wrote:
>> >>
&g= t;> >>> Firstly I'm curious as to what `numSubordinates' = identifies as
>> being a
>> >>> subordinate?>> >>> Eg. Is a subentry counted as a subordinate?
>&= gt; >> I'd vote for including subentries.
>>
>>>= I'd vote for including subentries as well...
>>
>> Any = use-cases for including subentries?
>> Which are the use-cases = for 'numSubordinates'?
>
> The question was whether SubEntries= should be counted in the
> numSubordinate operational attribute.
This question simply can't be answered without looking at possible = use-cases
for this attribute.

> If subentries are counted in = the numSubordinate attribute,
> an entry that has subEntries will = have a positive numSubordinate but
> regular client applications = won't see any child entries. Some apps may
> be confused by this = behavior, but this can already happen with ACI.

Yes, this is the = same issue like any scenario with ACI/ACLs in effect.

> As = opposed, not counting SubEntries in the numSubordinate attribute, an =
> application can read the numSubordiante attribute, see its value = is 0,
> delete the entry and get a NON_LEAF error... and be = confused....

IMHO

entry is leaf entry
<=3D> value = of hasSubordinates is 'FALSE'
<=3D> value of numSubordinates is = '0'

no matter whether you count all sub entries or just the next = level.

Examples (please correct me if I got it wrong):

1. = Counting all sub entries in numSubordinates:

dc=3Dtest,dc=3Dcom = (numSubordinates: 5)
|
+-ou=3DTest1 (numSubordinates: 0)
|
+-ou= =3DTest2 (numSubordinates: 3)
|
+-cn=3DTestperson1 (numSubordinates: = 0)
|
+-cn=3DTestperson2 (numSubordinates: 1)
|
+-mail=3Dtest1@test.com (numSubordina= tes: 0)

2. Counting only one-level in numSubordinates (similar to = what's another
vendor is doing in an attribute called 'subordinateCount= '):

dc=3Dtest,dc=3Dcom (numSubordinates: 2)
|
+-ou=3DTest1 = (numSubordinates: 0)
|
+-ou=3DTest2 (numSubordinates: 2)
|
+-cn= =3DTestperson1 (numSubordinates: 0)
|
+-cn=3DTestperson2 (numSubordin= ates: 1)
|
+-mail=3Dtes= t1@test.com (numSubordinates: 0)

As you can see in any = scenario leaf-entries have numSubordinates set to zero.

Hmm, maybe = I don't understand the word "SubEntries" correctly?
Maybe you are = talking about sub entries like sub schema sub entry?

Ciao, = Michael.


_______________________________________________
Ldap= ext mailing list
Ldapext@ietf.org=
= https://www1.ietf.org/mailman/listinfo/ldapext
--=__Part3A64967A.1__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 28 11:41:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06751 for ; Tue, 28 Oct 2003 11:41:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWtw-0002TD-EQ; Tue, 28 Oct 2003 11:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWtM-0002Pu-Pz for ldapext@optimus.ietf.org; Tue, 28 Oct 2003 11:40:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06721 for ; Tue, 28 Oct 2003 11:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEWtL-0000Zt-00 for ldapext@ietf.org; Tue, 28 Oct 2003 11:40:23 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AEWtK-0000Zn-00 for ldapext@ietf.org; Tue, 28 Oct 2003 11:40:22 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9SGeJPh005129; Tue, 28 Oct 2003 09:40:20 -0700 (MST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h9SGeJv07707; Tue, 28 Oct 2003 17:40:19 +0100 (MET) Message-ID: <3F9E9BAA.8060006@Sun.COM> Date: Tue, 28 Oct 2003 17:39:06 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: michael@stroeder.com, david@bozemanpass.com, ldapext@ietf.org, jmcmeek@us.ibm.com Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable That was my interpretation as well... Ludovic. Jim Sermersheim wrote: > Right, when people on this thread are talking about subentries, they=20 > are talking about subentries in the X.500 subentry sense of the word=20 > (like subschema subentry, prescriptiveACI subentry, etc). > > Jim > > >>> Michael Str=F6der 10/28/03 1:25:01 AM >>> > Ludovic Poitou wrote: > > > > Michael Str=F6der wrote: > > > >> Ludovic Poitou wrote: > >> > > >> > John McMeeking wrote: > >> >> > >> >>> Firstly I'm curious as to what `numSubordinates' identifies as > >> being a > >> >>> subordinate? > >> >>> Eg. Is a subentry counted as a subordinate? > >> >> I'd vote for including subentries. > >> > >>> I'd vote for including subentries as well... > >> > >> Any use-cases for including subentries? > >> Which are the use-cases for 'numSubordinates'? > > > > The question was whether SubEntries should be counted in the > > numSubordinate operational attribute. > > This question simply can't be answered without looking at possible=20 > use-cases > for this attribute. > > > If subentries are counted in the numSubordinate attribute, > > an entry that has subEntries will have a positive numSubordinate but > > regular client applications won't see any child entries. Some apps ma= y > > be confused by this behavior, but this can already happen with ACI. > > Yes, this is the same issue like any scenario with ACI/ACLs in effect. > > > As opposed, not counting SubEntries in the numSubordinate attribute, = an > > application can read the numSubordiante attribute, see its value is 0= , > > delete the entry and get a NON_LEAF error... and be confused.... > > IMHO > > entry is leaf entry > <=3D> value of hasSubordinates is 'FALSE' > <=3D> value of numSubordinates is '0' > > no matter whether you count all sub entries or just the next level. > > Examples (please correct me if I got it wrong): > > 1. Counting all sub entries in numSubordinates: > > dc=3Dtest,dc=3Dcom (numSubordinates: 5) > | > +-ou=3DTest1 (numSubordinates: 0) > | > +-ou=3DTest2 (numSubordinates: 3) > | > +-cn=3DTestperson1 (numSubordinates: 0) > | > +-cn=3DTestperson2 (numSubordinates: 1) > | > _+-mail=3Dtest1@test.com _=20 > (numSubordinates: 0) > > 2. Counting only one-level in numSubordinates (similar to what's anothe= r > vendor is doing in an attribute called 'subordinateCount'): > > dc=3Dtest,dc=3Dcom (numSubordinates: 2) > | > +-ou=3DTest1 (numSubordinates: 0) > | > +-ou=3DTest2 (numSubordinates: 2) > | > +-cn=3DTestperson1 (numSubordinates: 0) > | > +-cn=3DTestperson2 (numSubordinates: 1) > | > _+-mail=3Dtest1@test.com _=20 > (numSubordinates: 0) > > As you can see in any scenario leaf-entries have numSubordinates set=20 > to zero. > > Hmm, maybe I don't understand the word "SubEntries" correctly? > Maybe you are talking about sub entries like sub schema sub entry? > > Ciao, Michael. > > > _______________________________________________ > 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-admin@ietf.org Thu Oct 30 15:27:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09884 for ; Thu, 30 Oct 2003 15:27:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJNk-0007Xq-QF; Thu, 30 Oct 2003 15:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJNX-0007XA-8O for ldapext@optimus.ietf.org; Thu, 30 Oct 2003 15:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09851 for ; Thu, 30 Oct 2003 15:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJNV-0001a4-00 for ldapext@ietf.org; Thu, 30 Oct 2003 15:26:45 -0500 Received: from krl9-d9bb4c01.pool.mediaways.net ([217.187.76.1] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1AFJNU-0001Zq-00 for ldapext@ietf.org; Thu, 30 Oct 2003 15:26:44 -0500 Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6AB84904F7; Thu, 30 Oct 2003 19:27:41 +0100 (CET) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 61D858BFBA; Thu, 30 Oct 2003 19:27:40 +0100 (CET) Message-ID: <3FA1581C.3050504@stroeder.com> Date: Thu, 30 Oct 2003 19:27:40 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Cc: ldapext@ietf.org Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > Right, when people on this thread are talking about subentries, they are > talking about subentries in the X.500 subentry sense of the word (like > subschema subentry, prescriptiveACI subentry, etc). Then I ask again for use-case(s) of counting these kind of subentries in `numSubordinates'. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 31 03:53:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17953 for ; Fri, 31 Oct 2003 03:53:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFV1h-0007dQ-2T; Fri, 31 Oct 2003 03:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFV1c-0007d0-BQ for ldapext@optimus.ietf.org; Fri, 31 Oct 2003 03:52:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17937 for ; Fri, 31 Oct 2003 03:52:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFV1Z-00040d-00 for ldapext@ietf.org; Fri, 31 Oct 2003 03:52:53 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AFV1Y-00040Z-00 for ldapext@ietf.org; Fri, 31 Oct 2003 03:52:52 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h9V8qqc13045; Fri, 31 Oct 2003 09:52:52 +0100 (MET) Received: from pappel.asw.mchp.siemens.de ([139.25.160.30]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h9V8qpd06980; Fri, 31 Oct 2003 09:52:51 +0100 (MET) Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 09:52:50 +0100 Message-ID: From: "Volpers, Helmut" To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= , Jim Sermersheim Cc: ldapext@ietf.org Subject: RE: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt Date: Fri, 31 Oct 2003 09:52:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think the use-case of for the "numSubordinates" is to decide whether = the entry is a leaf without making an additional search. If you don't=20 count the subentries in the "numSubordinates" your application (e.g. = your User-Administration browser" will not offer you the possibility to browse below this object. You can argue that the "hasSubordinates" can = be used=20 for this but I don't need both in reality and if I have both I don't = like that the=20 "numSubordinates" can be 0 when the "hasSubordinates" is TRUE. I vote for : count the subentries in the "numSubordinates". Helmut > -----Original Message----- > From: Michael Str=F6der [mailto:michael@stroeder.com]=20 > Sent: Thursday, October 30, 2003 7:28 PM > To: Jim Sermersheim > Cc: ldapext@ietf.org > Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt >=20 >=20 > Jim Sermersheim wrote: > > Right, when people on this thread are talking about=20 > subentries, they=20 > > are > > talking about subentries in the X.500 subentry sense of the=20 > word (like=20 > > subschema subentry, prescriptiveACI subentry, etc). >=20 > Then I ask again for use-case(s) of counting these kind of=20 > subentries in `numSubordinates'. >=20 > Ciao, Michael. >=20 >=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 From ldapext-admin@ietf.org Fri Oct 31 07:51:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26096 for ; Fri, 31 Oct 2003 07:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYk0-0008Bq-VX; Fri, 31 Oct 2003 07:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFYj4-00088S-D8 for ldapext@optimus.ietf.org; Fri, 31 Oct 2003 07:50:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25950 for ; Fri, 31 Oct 2003 07:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFYj3-0007JT-00 for ldapext@ietf.org; Fri, 31 Oct 2003 07:50:01 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx with esmtp (Exim 4.12) id 1AFYj2-0007Iy-00 for ldapext@ietf.org; Fri, 31 Oct 2003 07:50:00 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id h9VCnTRS421574 for ; Fri, 31 Oct 2003 07:49:29 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9VCnSKG042972 for ; Fri, 31 Oct 2003 07:49:28 -0500 Subject: Re: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt To: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 31 Oct 2003 06:49:27 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 10/31/2003 06:49:28 AM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I feel that numsubordinates should return 0 when hassubordinates would return FALSE=2E Since hassubordinates can include subentries, numsubordinates should also=2E John McMeeking = Michael Str=F6der = =2Ecom> cc: ldapext@ietf= =2Eorg Sent by: Subject: Re: [ldapext] = Re: ldapext-admin@iet draft-ietf-boreham-nums= ubordinates-01=2Etxt f=2Eorg = = = 10/30/2003 12:27 = PM = = = Jim Sermersheim wrote: > Right, when people on this thread are talking about subentries, they = are > talking about subentries in the X=2E500 subentry sense of the word (l= ike > subschema subentry, prescriptiveACI subentry, etc)=2E Then I ask again for use-case(s) of counting these kind of subentries i= n `numSubordinates'=2E Ciao, Michael=2E _______________________________________________ Ldapext mailing list Ldapext@ietf=2Eorg https://www1=2Eietf=2Eorg/mailman/listinfo/ldapext = _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 31 10:18:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03015 for ; Fri, 31 Oct 2003 10:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFb2H-0002Op-Td; Fri, 31 Oct 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFb1Z-0002KG-BR for ldapext@optimus.ietf.org; Fri, 31 Oct 2003 10:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02876 for ; Fri, 31 Oct 2003 10:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFb1X-0001Yv-00 for ldapext@ietf.org; Fri, 31 Oct 2003 10:17:15 -0500 Received: from krl9-d9bb4009.pool.mediaways.net ([217.187.64.9] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1AFb1W-0001Xt-00 for ldapext@ietf.org; Fri, 31 Oct 2003 10:17:14 -0500 Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 48D09A439B; Fri, 31 Oct 2003 16:16:43 +0100 (CET) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 869F67F341; Fri, 31 Oct 2003 16:16:42 +0100 (CET) Message-ID: <3FA27CDA.1060409@stroeder.com> Date: Fri, 31 Oct 2003 16:16:42 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: John McMeeking Cc: ldapext@ietf.org Subject: [ldapext] Re: draft-ietf-boreham-numsubordinates-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John McMeeking wrote: > > I feel that numsubordinates should return 0 when hassubordinates would > return FALSE. Since hassubordinates can include subentries, > numsubordinates should also. Ok, I agree with that. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext