From ldapext-admin@ietf.org Thu Jan 1 09:20:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08429 for ; Thu, 1 Jan 2004 09:20:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ac3gB-0007zW-5q; Thu, 01 Jan 2004 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ac3fm-0007yU-94 for ldapext@optimus.ietf.org; Thu, 01 Jan 2004 09:19:38 -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 JAA08376 for ; Thu, 1 Jan 2004 09:19:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ac3fk-0000QN-00 for ldapext@ietf.org; Thu, 01 Jan 2004 09:19:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ac3dL-0000NA-00 for ldapext@ietf.org; Thu, 01 Jan 2004 09:17:10 -0500 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1Ac3aL-0000JL-00 for ldapext@ietf.org; Thu, 01 Jan 2004 09:14:01 -0500 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.20) id 1Ac3Zs-0003GF-QO for ldapext@ietf.org; Thu, 01 Jan 2004 15:13:32 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx2.uio.no with esmtp (Exim 4.14) id 1Ac3Zl-0004PX-CT; Thu, 01 Jan 2004 15:13:25 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1Ac3Zk-00058n-00; Thu, 1 Jan 2004 15:13:24 +0100 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Thu, 1 Jan 2004 15:13:24 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required 12, BAYES_00 -4.90) Subject: [ldapext] True filter vs. (objectClass=*) 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 suggest to add this statement to draft-zeilenga-ldap-t-f: Whenever the "(objectClass=*)" filter will succeed (including reading the Root DSE), the "(&)" filter will also succeed. rfc2251 section 3.4 explicitly says the (objectClass=*) filter should be used to read the root DSE. It does _not_ say 'any filter which matches the root DSE', so as currently defined the TRUE filter might not work here. (OTOH, there is one filter which properly may succeed when TRUE fails: (objectClass=subschema) to read schema.) -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Jan 2 08:20:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07296 for ; Fri, 2 Jan 2004 08:20:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcPDp-00087I-HL; Fri, 02 Jan 2004 08:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcPDR-00083L-0o for ldapext@optimus.ietf.org; Fri, 02 Jan 2004 08:19:49 -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 IAA07155 for ; Fri, 2 Jan 2004 08:19:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcPDP-00071K-00 for ldapext@ietf.org; Fri, 02 Jan 2004 08:19:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcP4P-0006Ki-00 for ldapext@ietf.org; Fri, 02 Jan 2004 08:10:32 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1AcOy2-0005u4-00 for ldapext@ietf.org; Fri, 02 Jan 2004 08:03:54 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i02D2md6423814; Fri, 2 Jan 2004 08:02:48 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i02D2lvE214916; Fri, 2 Jan 2004 08:02:48 -0500 Subject: Re: [ldapext] True filter vs. (objectClass=*) To: Hallvard B Furuseth Cc: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 2 Jan 2004 07:02:45 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 01/02/2004 07:02:47 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 do not believe (&) or (|) are valid filters, though the ASN.1 does seem to imply they are valid. RFC 2251 and [protocol], para 4.5.1: The 'and', 'or' and 'not' choices can be used to form combinations of filters. At least one filter element MUST be present in an 'and' or 'or' choice. I interpret that as meaning you can do (&(...)) or (|(...)), where (...) is some filter element, but not (&) or (|). I don't know how to interpret the "and : {} " in X.511: SearchArgument ::= OPTIONALLY-PROTECTED { SET { [intervening components deleted] filter [2] Filter DEFAULT and : { }, John McMeeking Hallvard B Furuseth To: ldapext@ietf.org Subject: [ldapext] True filter vs. (objectClass=*) Sent by: ldapext-admin@iet f.org 01/01/2004 08:13 AM I suggest to add this statement to draft-zeilenga-ldap-t-f: Whenever the "(objectClass=*)" filter will succeed (including reading the Root DSE), the "(&)" filter will also succeed. rfc2251 section 3.4 explicitly says the (objectClass=*) filter should be used to read the root DSE. It does _not_ say 'any filter which matches the root DSE', so as currently defined the TRUE filter might not work here. (OTOH, there is one filter which properly may succeed when TRUE fails: (objectClass=subschema) to read schema.) -- Hallvard _______________________________________________ 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 Jan 2 09:10:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09929 for ; Fri, 2 Jan 2004 09:10: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 1AcQ03-00021U-5b; Fri, 02 Jan 2004 09:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcPzQ-00020p-LY for ldapext@optimus.ietf.org; Fri, 02 Jan 2004 09:09: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 JAA09901 for ; Fri, 2 Jan 2004 09:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcPzF-0002rk-00 for ldapext@ietf.org; Fri, 02 Jan 2004 09:09:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcPue-0002l6-00 for ldapext@ietf.org; Fri, 02 Jan 2004 09:04:31 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx with esmtp (Exim 4.12) id 1AcPrV-0002ds-00 for ldapext@ietf.org; Fri, 02 Jan 2004 09:01:13 -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 i02E07Kc485342; Fri, 2 Jan 2004 09:00:07 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i02E0634062418; Fri, 2 Jan 2004 09:00:07 -0500 Subject: Re: [ldapext] True filter vs. (objectClass=*) To: Hallvard B Furuseth , ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 2 Jan 2004 08:00:04 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 01/02/2004 08:00:06 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: , Disregard my last post. I hadn't had my morning coffee yet. I was reading this with respect to the wrong I-D (ldapbis-protocol, not draft-zeilenga-ldap-t-f). And the DEFAULT of "and : {}" is the LDAP (&). John McMeeking John McMeeking/Rocheste To: Hallvard B Furuseth r/IBM@IBMUS cc: ldapext@ietf.org Sent by: Subject: Re: [ldapext] True filter vs. (objectClass=*) ldapext-admin@ietf .org 01/02/2004 07:02 AM I do not believe (&) or (|) are valid filters, though the ASN.1 does seem to imply they are valid. RFC 2251 and [protocol], para 4.5.1: The 'and', 'or' and 'not' choices can be used to form combinations of filters. At least one filter element MUST be present in an 'and' or 'or' choice. I interpret that as meaning you can do (&(...)) or (|(...)), where (...) is some filter element, but not (&) or (|). I don't know how to interpret the "and : {} " in X.511: SearchArgument ::= OPTIONALLY-PROTECTED { SET { [intervening components deleted] filter [2] Filter DEFAULT and : { }, John McMeeking Hallvard B Furuseth To: ldapext@ietf.org Subject: [ldapext] True filter vs. (objectClass=*) Sent by: ldapext-admin@iet f.org 01/01/2004 08:13 AM I suggest to add this statement to draft-zeilenga-ldap-t-f: Whenever the "(objectClass=*)" filter will succeed (including reading the Root DSE), the "(&)" filter will also succeed. rfc2251 section 3.4 explicitly says the (objectClass=*) filter should be used to read the root DSE. It does _not_ say 'any filter which matches the root DSE', so as currently defined the TRUE filter might not work here. (OTOH, there is one filter which properly may succeed when TRUE fails: (objectClass=subschema) to read schema.) -- Hallvard _______________________________________________ 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 Jan 2 12:59:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16967 for ; Fri, 2 Jan 2004 12:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcTZc-00015W-TU; Fri, 02 Jan 2004 12:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcTZI-00014n-Ch for ldapext@optimus.ietf.org; Fri, 02 Jan 2004 12:58:40 -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 MAA16959 for ; Fri, 2 Jan 2004 12:58:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcTZG-0003hd-00 for ldapext@ietf.org; Fri, 02 Jan 2004 12:58:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcTXM-0003dL-00 for ldapext@ietf.org; Fri, 02 Jan 2004 12:56:43 -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 1AcTWG-0003ZU-00 for ldapext@ietf.org; Fri, 02 Jan 2004 12:55:32 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.9) with ESMTP id i02HtVu0020441; Fri, 2 Jan 2004 17:55:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.0.22.0.20040102091400.0279f060@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 02 Jan 2004 09:55:17 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] True filter vs. (objectClass=*) Cc: ldapext@ietf.org 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 06:13 AM 1/1/2004, Hallvard B Furuseth wrote: >I suggest to add this statement to draft-zeilenga-ldap-t-f: > > Whenever the "(objectClass=*)" filter will succeed (including > reading the Root DSE), the "(&)" filter will also succeed. Succeed? As it match the DSE? or returned by the search operation? I've written this I-D to limit its scope to the evaluation of Filters. It has no impact beyond that. >rfc2251 section 3.4 explicitly says the (objectClass=*) filter >should be used to read the root DSE. It does _not_ say 'any filter >which matches the root DSE', so as currently defined the TRUE filter >might not work here. This I-D does not alter any TS, including RFC 2251, which mandates a particular filter in a specific cases. That is, this I-D only extends the general filter capabilities. It does not alter when and where those general filter capabilities may be used. Hence, I suggest adding: It is noted that certain search operations, such as those used to retrieve information from subschema subentries [RFC2251], require use of particular filters. This document does not change these requirements. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Jan 3 09:26:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02267 for ; Sat, 3 Jan 2004 09:26:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acmj3-00049E-8B; Sat, 03 Jan 2004 09:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acmi4-00048H-UZ for ldapext@optimus.ietf.org; Sat, 03 Jan 2004 09:25:06 -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 JAA02227 for ; Sat, 3 Jan 2004 09:24:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acmht-0006xX-00 for ldapext@ietf.org; Sat, 03 Jan 2004 09:24:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acmdb-0006jQ-00 for ldapext@ietf.org; Sat, 03 Jan 2004 09:20:24 -0500 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1AcmYq-0006Sq-00 for ldapext@ietf.org; Sat, 03 Jan 2004 09:15:28 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AcmYN-0003pL-VY; Sat, 03 Jan 2004 15:14:59 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AcmYM-0005T0-3u; Sat, 03 Jan 2004 15:14:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1AcmYI-00048D-00; Sat, 3 Jan 2004 15:14:54 +0100 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org Subject: Re: [ldapext] True filter vs. (objectClass=*) In-Reply-To: <6.0.0.22.0.20040102091400.0279f060@127.0.0.1> References: <6.0.0.22.0.20040102091400.0279f060@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 3 Jan 2004 15:14:54 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required 12, BAYES_00 -4.90) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Kurt D. Zeilenga writes: >At 06:13 AM 1/1/2004, Hallvard B Furuseth wrote: >>I suggest to add this statement to draft-zeilenga-ldap-t-f: >> >> Whenever the "(objectClass=*)" filter will succeed (including >> reading the Root DSE), the "(&)" filter will also succeed. > > Succeed? As it match the DSE? or returned by the search operation? s/succeed/match/. >> rfc2251 section 3.4 explicitly says the (objectClass=*) filter >> should be used to read the root DSE. It does _not_ say 'any filter >> which matches the root DSE', so as currently defined the TRUE filter >> might not work here. > > This I-D does not alter any TS, including RFC 2251, which mandates a > particular filter in a specific cases. I didn't mean to. Perhaps I should have put "If a server supports True/False filters," in front of the statement. > That is, this I-D only extends > the general filter capabilities. It does not alter when and where > those general filter capabilities may be used. I don't see why my suggestion (as clarified above) does that either. > Hence, I suggest adding: > It is noted that certain search operations, such as those used to > retrieve information from subschema subentries [RFC2251], require use > of particular filters. This document does not change these requirements. I'm fine with that too, if you also include this modification: These filters are commonly used when requesting DSA- specific Entries (DSEs) ..."except the root DSE"... which do not necessarily have 'objectClass' attributes. That was the statement I was thinking of in my original message. I thought you meant it should be possible to read all DSEs with the "(&)" filter. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Jan 16 12:24:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22108 for ; Fri, 16 Jan 2004 12:24:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXhQ-00065R-GH; Fri, 16 Jan 2004 12:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXgq-000622-N1 for ldapext@optimus.ietf.org; Fri, 16 Jan 2004 12:23: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 MAA21979 for ; Fri, 16 Jan 2004 12:23:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXgp-0001WR-00 for ldapext@ietf.org; Fri, 16 Jan 2004 12:23:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXdv-0001Mg-00 for ldapext@ietf.org; Fri, 16 Jan 2004 12:20:24 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx with esmtp (Exim 4.12) id 1AhXbZ-0001D2-00 for ldapext@ietf.org; Fri, 16 Jan 2004 12:17:58 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GHGqIh704010 for ; Fri, 16 Jan 2004 12:16:52 -0500 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GHGpXX222948 for ; Fri, 16 Jan 2004 12:16:51 -0500 To: ldapext@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Fri, 16 Jan 2004 11:16:48 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5|September 18, 2003) at 01/16/2004 11:16:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ldapext] password policy administrative operations 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: , There are some administrative operations that are not addressed by the password policy draft. - Can an account be unlocked after being locked due to failed requests? If so, is this done by having the administrator reset the password? Or should there be another way to unlock the account without changing the password? Perhaps an extended request? Modify requrest to delete the pwdaccountlockedtime attribute? - Is there a way to prevent passwords from expiring on specific accounts? One obvious way is to place these accounts where the password policy doesn't apply, but I think a more appropriate approach would be a property of the account -- some combination of operational attributes (pwdneverexpires=TRUE?) and / or extended operations (some sort of "set pwd attributes" extended operation?). There's probably others, but these are items I have encountered as folks look at implementing pwd policy in their organizations. John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Jan 16 13:28:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24196 for ; Fri, 16 Jan 2004 13:28:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhYhM-0002NW-Uf; Fri, 16 Jan 2004 13:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhYgo-0002Kw-6m for ldapext@optimus.ietf.org; Fri, 16 Jan 2004 13:27:26 -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 NAA24156 for ; Fri, 16 Jan 2004 13:27:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhYgm-0005DB-00 for ldapext@ietf.org; Fri, 16 Jan 2004 13:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhYfq-0005A3-00 for ldapext@ietf.org; Fri, 16 Jan 2004 13:26:26 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AhYf0-00053z-00 for ldapext@ietf.org; Fri, 16 Jan 2004 13:25:34 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0GIP2j4012582; Fri, 16 Jan 2004 10:25:03 -0800 (PST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i0GIP1P14477; Fri, 16 Jan 2004 19:25:01 +0100 (MET) Message-ID: <40082C41.9000007@Sun.COM> Date: Fri, 16 Jan 2004 19:24:01 +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: John McMeeking CC: ldapext@ietf.org Subject: Re: [ldapext] password policy administrative operations References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: > > >There are some administrative operations that are not addressed by the >password policy draft. > > > I agree... I think that the draft is already too complex and too long and if we are starting to add all the administrative operations that can be done on the password policy, we will end up with a book. :-) We tried to describe a schema for defining a policy and a schema (operational attributes) for enforcing the policy. We tried to describe what the server should do with these attributes to have consistent behavior and security between level between hetereogenous servers. I'm not sure we really want to describe administrative operations. If we were to define all administrative operations, i would do it with extended operations and would certainly remove all the operational attributes and related description to let implementors choose their own design. This would certainly bring interoperability from a client application point of view but will prevent replication / synchronization between different vendors. >- Can an account be unlocked after being locked due to failed requests? If >so, is this done by having the administrator reset the password? Or should >there be another way to unlock the account without changing the password? >Perhaps an extended request? Modify requrest to delete the >pwdaccountlockedtime attribute? > > This may be a choice of the user of the password policy. Some customers may request to have the password changed after it's been locked due to failures. Some other customers may just want to be able to remove the lock and don't change the password. Should we really mandate all Administrative operations ? >- Is there a way to prevent passwords from expiring on specific accounts? > > How about defining a specific password policy for those account with no expiration of the password ? Not all entries have to obey the same policy. Ludovic. >One obvious way is to place these accounts where the password policy >doesn't apply, but I think a more appropriate approach would be a property >of the account -- some combination of operational attributes >(pwdneverexpires=TRUE?) and / or extended operations (some sort of "set pwd >attributes" extended operation?). > >There's probably others, but these are items I have encountered as folks >look at implementing pwd policy in their organizations. > > >John McMeeking > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Jan 29 13:38:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07149 for ; Thu, 29 Jan 2004 13:38:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmH3B-0004Gy-02; Thu, 29 Jan 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmEzn-0002f7-SS for ldapext@optimus.ietf.org; Thu, 29 Jan 2004 11:26:23 -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 LAA29644 for ; Thu, 29 Jan 2004 11:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmEzm-0004Wv-00 for ldapext@ietf.org; Thu, 29 Jan 2004 11:26:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmEyt-0004Rg-00 for ldapext@ietf.org; Thu, 29 Jan 2004 11:25:28 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 1AmEyc-0004M7-00 for ldapext@ietf.org; Thu, 29 Jan 2004 11:25:11 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 29 Jan 2004 09:24:40 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 29 Jan 2004 09:24:24 -0700 From: "Bruce Bergeson" To: Cc: "Kent Boogert" , "Vijay KN" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartAA8BFEA8.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [ldapext] draft-bergeson-uddi-ldap-schema-02.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: , 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. --=__PartAA8BFEA8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit All, We have updated the draft http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-schema-02.txt based on a round of initial reviews and we want to progress it to RFC status. Before requesting the Area Director to initiate a last call, we wanted to see if anyone has any further feedback. We'll approach the AD in a week if there seems to be no issues. Bruce, Kent, and Vijay. Bruce Bergeson Sr. Software Engineer (801) 861-3854 Novell, Inc., a leading provider of Net business solutions www.novell.com --=__PartAA8BFEA8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

We have updated the draft http://www.ietf.o= rg/internet-drafts/draft-bergeson-uddi-ldap-schema-02.txt based on = a round of initial reviews and we want to progress it to RFC status. = Before requesting the Area Director to initiate a last call, we wanted to = see if anyone has any further feedback.

We'll approach the AD in a = week if there seems to be no issues.

Bruce, Kent, and = Vijay.
 
Bruce Bergeson
Sr. Software Engineer
(801) 861-3854
Novell= , Inc., a leading provider of Net business solutions
www.novell.com
--=__PartAA8BFEA8.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext