From ldapext-admin@ietf.org Wed May 5 03:50:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27797 for ; Wed, 5 May 2004 03:50:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLH7P-0000vy-KW; Wed, 05 May 2004 03:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLH1t-0007pL-QO for ldapext@optimus.ietf.org; Wed, 05 May 2004 03:41:21 -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 DAA27462 for ; Wed, 5 May 2004 03:41:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLH1r-0005dn-An for ldapext@ietf.org; Wed, 05 May 2004 03:41:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLH0u-0005Tt-00 for ldapext@ietf.org; Wed, 05 May 2004 03:40:20 -0400 Received: from du-006-178.access.de.clara.net ([212.82.229.178] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1BLH0P-00059k-00 for ldapext@ietf.org; Wed, 05 May 2004 03:39:50 -0400 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id ABC15AAC6F for ; Wed, 5 May 2004 09:15:52 +0200 (CEST) Message-ID: <409894A8.2070007@stroeder.com> Date: Wed, 05 May 2004 09:15:52 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ldapext@ietf.org 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 Subject: [ldapext] Attribute type ref, usage distributedOperation and Manage DSA IT mode 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! The USAGE of attribute type 'ref' is distributedOperation. From draft-ietf-ldapbis-models-10: A usage of directoryOperation, distributedOperation, or dSAOperation indicates that attributes of this type represent operational and/or administrative information. That is, they are operational attributes. So far, so good. But if a client is in Manage DSA IT mode 'ref' is not an operational attribute from the client's perspective. How should the client behave? Background: In web2ldap I solely present non-operational and user-editable attributes to the user when generating input forms. Hmm, I probably have to add special treatment for 'ref' considering the Manage DSA IT mode. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 5 09:50:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13348 for ; Wed, 5 May 2004 09:50:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMhr-0003I5-F2; Wed, 05 May 2004 09:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMgR-0002Xg-Rr for ldapext@optimus.ietf.org; Wed, 05 May 2004 09:43:35 -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 JAA12996 for ; Wed, 5 May 2004 09:43:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLMgQ-0004iz-19 for ldapext@ietf.org; Wed, 05 May 2004 09:43:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMfR-0004V9-00 for ldapext@ietf.org; Wed, 05 May 2004 09:42:33 -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 1BLMeS-0004BC-00 for ldapext@ietf.org; Wed, 05 May 2004 09:41:32 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i45DfQnC021485; Wed, 5 May 2004 13:41:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040505063727.02caa390@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 05 May 2004 06:41:27 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Attribute type ref, usage distributedOperation and Manage DSA IT mode Cc: ldapext@ietf.org In-Reply-To: <409894A8.2070007@stroeder.com> References: <409894A8.2070007@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=AWL autolearn=no version=2.60 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 At 12:15 AM 5/5/2004, Michael Str=F6der wrote: >HI! > >The USAGE of attribute type 'ref' is distributedOperation. > > From draft-ietf-ldapbis-models-10: > > A usage of directoryOperation, distributedOperation, or dSAOperation > indicates that attributes of this type represent operational and/or > administrative information. That is, they are operational attributes. > >So far, so good. > >But if a client is in Manage DSA IT mode 'ref' is not an operational= attribute from the client's perspective. Says which RFC? The Manage DSA IT control does not alter the usage of attribute types. The control just causes the operation to act in a DSA IT instead in the DIT. >How should the client behave? >Background: In web2ldap I solely present non-operational and user-editable= attributes to the user when generating input forms. Hmm, I probably have to= add special treatment for 'ref' considering the Manage DSA IT mode. > >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 Wed May 5 11:11:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19749 for ; Wed, 5 May 2004 11:11:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNvJ-0000qd-9a; Wed, 05 May 2004 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNgX-0002R5-Vi for ldapext@optimus.ietf.org; Wed, 05 May 2004 10:47:46 -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 KAA17330 for ; Wed, 5 May 2004 10:47:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNgV-0004RM-Cd for ldapext@ietf.org; Wed, 05 May 2004 10:47:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNff-0004Cm-00 for ldapext@ietf.org; Wed, 05 May 2004 10:46:51 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BLNf4-0003v1-00 for ldapext@ietf.org; Wed, 05 May 2004 10:46:14 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 05 May 2004 08:45:43 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 05 May 2004 08:45:16 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Attribute type ref, usage distributedOperation and Manage DSA ITmode Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=AWL autolearn=no version=2.60 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, are you assuming that operational attributes are always non-user-e= ditable? >>> Michael Str=F6der 5/5/04 1:15:52 AM >>> HI! The USAGE of attribute type 'ref' is distributedOperation. From draft-ietf-ldapbis-models-10: A usage of directoryOperation, distributedOperation, or dSAOperation indicates that attributes of this type represent operational and/or administrative information. That is, they are operational attributes. So far, so good. But if a client is in Manage DSA IT mode 'ref' is not an operational=20 attribute from the client's perspective. How should the client behave? Background: In web2ldap I solely present non-operational and user-editable= =20 attributes to the user when generating input forms. Hmm, I probably have = to=20 add special treatment for 'ref' considering the Manage DSA IT mode. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 5 12:05:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22824 for ; Wed, 5 May 2004 12:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOkf-0006B9-Ac; Wed, 05 May 2004 11:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLObX-0001zW-SO for ldapext@optimus.ietf.org; Wed, 05 May 2004 11:46:39 -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 LAA21914 for ; Wed, 5 May 2004 11:46:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLObW-0005IQ-P4 for ldapext@ietf.org; Wed, 05 May 2004 11:46:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOaY-00053A-00 for ldapext@ietf.org; Wed, 05 May 2004 11:45:38 -0400 Received: from [62.80.45.235] (helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1BLOZY-0004b0-00 for ldapext@ietf.org; Wed, 05 May 2004 11:44:48 -0400 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 5FED8C807C; Wed, 5 May 2004 17:43:35 +0200 (CEST) Message-ID: <40990BA7.5050604@stroeder.com> Date: Wed, 05 May 2004 17:43:35 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Cc: ldapext@ietf.org Subject: Re: [ldapext] Attribute type ref, usage distributedOperation and Manage DSA ITmode References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: 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 Jim Sermersheim wrote: > Michael, are you assuming that operational attributes are always non-us= er-editable? Yes, if I don't have any more knowledge about the operational attribute. In web2ldap I've added a special treatment for 'ref' when being in Manage= =20 DSA IT Mode today. Ciao, Michael. >>>>Michael Str=F6der 5/5/04 1:15:52 AM >>> >=20 > The USAGE of attribute type 'ref' is distributedOperation. >=20 > From draft-ietf-ldapbis-models-10: >=20 > A usage of directoryOperation, distributedOperation, or dSAOperation= > indicates that attributes of this type represent operational and/or > administrative information. That is, they are operational attribute= s. >=20 > So far, so good. >=20 > But if a client is in Manage DSA IT mode 'ref' is not an operational=20 > attribute from the client's perspective. How should the client behave? > Background: In web2ldap I solely present non-operational and user-edita= ble=20 > attributes to the user when generating input forms. Hmm, I probably hav= e to=20 > add special treatment for 'ref' considering the Manage DSA IT mode. >=20 > Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 5 12:37:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24569 for ; Wed, 5 May 2004 12:37: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 1BLPDf-0001NL-LL; Wed, 05 May 2004 12:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLP0u-0003g9-VZ for ldapext@optimus.ietf.org; Wed, 05 May 2004 12:12:52 -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 MAA23048 for ; Wed, 5 May 2004 12:12:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLP0t-0004Bk-G8 for ldapext@ietf.org; Wed, 05 May 2004 12:12:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOzo-0003wG-00 for ldapext@ietf.org; Wed, 05 May 2004 12:11:44 -0400 Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx with esmtp (Exim 4.12) id 1BLOz1-0003TJ-00 for ldapext@ietf.org; Wed, 05 May 2004 12:10:55 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Wed, 05 May 2004 10:10:24 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 05 May 2004 10:10:04 -0600 From: "Vithalprasad Gaitonde" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] cn=monitor 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 Is the cn=monitor present in some LDAP server based on a standard? If not is there a plan/interest for standardization for this. Thanks, Prasad _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 5 13:09:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26520 for ; Wed, 5 May 2004 13:09:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPmV-0005wQ-6h; Wed, 05 May 2004 13:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPXm-000155-35 for ldapext@optimus.ietf.org; Wed, 05 May 2004 12:46:50 -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 MAA25091 for ; Wed, 5 May 2004 12:46:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPXk-0005dj-Dj for ldapext@ietf.org; Wed, 05 May 2004 12:46:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPWr-0005OX-00 for ldapext@ietf.org; Wed, 05 May 2004 12:45:54 -0400 Received: from server1.montana.boreham.org ([63.112.219.168] helo=mail.montana.boreham.org) by ietf-mx with esmtp (Exim 4.12) id 1BLPWA-0004sz-00 for ldapext@ietf.org; Wed, 05 May 2004 12:45:10 -0400 Received: from squirrel (squirrel.mtbrook.boreham.org [63.112.219.169]) by mail.montana.boreham.org (Postfix) with SMTP id D64D911031D for ; Wed, 5 May 2004 09:44:32 -0700 (PDT) Message-ID: <13cf01c432c0$3e034d90$a9db703f@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] cn=monitor Date: Wed, 5 May 2004 09:44:32 -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 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 > Is the cn=monitor present in some LDAP server based on a standard? If > not is there a plan/interest for standardization for this. There's an existing SNMP MIB for Directory Servers, and I know that there's a vague similarity between that and a _subset_ of the content of cn=monitor for at least one server implementation. It might be possible to define a cannonical mapping between the MIB and the cn=monitor content. Another useful (IMHO) activity would be to work on the MIB (or the mapped LDAP equivalent) some to bring it in line with the needs of present-day deployents and implementations. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 5 13:27:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27622 for ; Wed, 5 May 2004 13:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPy5-0003MM-On; Wed, 05 May 2004 13:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPnW-0006Zt-Fy for ldapext@optimus.ietf.org; Wed, 05 May 2004 13:03:06 -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 NAA26244 for ; Wed, 5 May 2004 13:03:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPnU-0002JM-BH for ldapext@ietf.org; Wed, 05 May 2004 13:03:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPmY-00021i-00 for ldapext@ietf.org; Wed, 05 May 2004 13:02:07 -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 1BLPlp-0001jd-00 for ldapext@ietf.org; Wed, 05 May 2004 13:01:21 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i45H1HnC022809; Wed, 5 May 2004 17:01:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040505095250.04ed55a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 05 May 2004 10:01:18 -0700 To: "Vithalprasad Gaitonde" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] cn=monitor Cc: In-Reply-To: References: 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=AWL 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: , At 09:10 AM 5/5/2004, Vithalprasad Gaitonde wrote: >Is the cn=monitor present in some LDAP server based on a standard? At present, there are no standards for publishing monitoring information via LDAP. There is, of course, some standardized MIBs which one can access via SNMP. >If not is there a plan/interest for standardization for this. I'd be interested in publishing a general approach for accessing MIBs via LDAP. And them maybe design some new MIBs. I'd also be interested in an (informational?) RFC discussing some good and bad implementation practices. One thing that concerns me is that some implementations publish "cn=monitor" (and DNs of like DSA specific information trees) as values of the root DSE namingContexts attribute. That's bad as namingContexts is intended specifically for DIT naming context discovery. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 5 14:07:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01149 for ; Wed, 5 May 2004 14:07:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQam-0005lr-O0; Wed, 05 May 2004 13:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQXm-0003n4-Bu for ldapext@optimus.ietf.org; Wed, 05 May 2004 13:50:54 -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 NAA29366 for ; Wed, 5 May 2004 13:50:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLQXj-0000MA-Vj for ldapext@ietf.org; Wed, 05 May 2004 13:50:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQWh-00003L-00 for ldapext@ietf.org; Wed, 05 May 2004 13:49:48 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx with esmtp (Exim 4.12) id 1BLQVc-0007HR-00 for ldapext@ietf.org; Wed, 05 May 2004 13:48:40 -0400 Received: from [192.168.1.10] (82-43-138-40.cable.ubr01.newm.blueyonder.co.uk [82.43.138.40]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 5 May 2004 18:47:53 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 05 May 2004 18:47:49 +0100 Subject: Re: [ldapext] cn=monitor From: Chris Ridd To: "Kurt D. Zeilenga" , Vithalprasad Gaitonde CC: Message-ID: In-Reply-To: <6.0.1.1.0.20040505095250.04ed55a0@127.0.0.1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 On 5/5/04 6:01 pm, Kurt D. Zeilenga wrote: > I'd also be interested in an (informational?) RFC discussing > some good and bad implementation practices. One thing that > concerns me is that some implementations publish "cn=monitor" > (and DNs of like DSA specific information trees) as > values of the root DSE namingContexts attribute. That's > bad as namingContexts is intended specifically for DIT naming > context discovery. We avoid polluting the namingContexts attribute by using virtual attributes (one for each MIB we support) on our root DSE which are generated/returned on demand. A mechanism for reporting which attributes hold which MIB contents might be nice, as currently clients just "have to know" what attributes the server's using :-( Cheers, Chris _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 7 11:33:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01555 for ; Fri, 7 May 2004 11:33:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM77w-0001rS-2y; Fri, 07 May 2004 11:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6xJ-0004t4-6x for ldapext@optimus.ietf.org; Fri, 07 May 2004 11:08:05 -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 LAA29583 for ; Fri, 7 May 2004 11:08:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6xG-0000LI-J3 for ldapext@ietf.org; Fri, 07 May 2004 11:08:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6wE-0007ha-00 for ldapext@ietf.org; Fri, 07 May 2004 11:06:59 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BM6vf-0007Gw-00 for ldapext@ietf.org; Fri, 07 May 2004 11:06:23 -0400 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.30) id 1BM6va-0004kh-Vk for ldapext@ietf.org; Fri, 07 May 2004 17:06:18 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.30) id 1BM6u8-0006j6-CU for ldapext@ietf.org; Fri, 07 May 2004 17:04:48 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BM6u7-0005u7-00 for ldapext@ietf.org; Fri, 7 May 2004 17:04:47 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Fri, 7 May 2004 17:04:47 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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] ManageDsaIT control vs. parent referral objects 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: , RFC 3296 says: > 3. The ManageDsaIT Control > > The control causes Directory-specific > entries (DSEs), regardless of type, to be treated as normal entries > allowing clients to interrogate and update these entries using LDAP > operations. This control would make more sense to me if it did not apply to superior referral entries of the entries that are considered by the operation. For example, as far as I can tell from rfc3296, one can now use the manageDSAIT control to add subordinate entries below referral entries. I haven't got X.511(97); how does its ManageDsaIT service option work in this respect? -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 7 12:49:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04816 for ; Fri, 7 May 2004 12:49:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8OS-0004Q0-EX; Fri, 07 May 2004 12:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8FU-0000gD-NT for ldapext@optimus.ietf.org; Fri, 07 May 2004 12:30:56 -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 MAA04040 for ; Fri, 7 May 2004 12:30:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8FT-0005qd-4a for ldapext@ietf.org; Fri, 07 May 2004 12:30:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8Ea-0005PD-00 for ldapext@ietf.org; Fri, 07 May 2004 12:30:00 -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 1BM8DI-0004bi-00 for ldapext@ietf.org; Fri, 07 May 2004 12:28:40 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i47GSdnC038446; Fri, 7 May 2004 16:28:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040507091058.04d22cc0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 07 May 2004 09:28:37 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] ManageDsaIT control vs. parent referral objects Cc: ldapext@ietf.org In-Reply-To: References: 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=AWL 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: , At 08:04 AM 5/7/2004, Hallvard B Furuseth wrote: >RFC 3296 says: >> 3. The ManageDsaIT Control >> >> The control causes Directory-specific >> entries (DSEs), regardless of type, to be treated as normal entries >> allowing clients to interrogate and update these entries using LDAP >> operations. > >This control would make more sense to me if it did not apply to superior >referral entries of the entries that are considered by the operation. >For example, as far as I can tell from rfc3296, one can now use the >manageDSAIT control to add subordinate entries below referral entries. I think that reading is a bit far fetched. One of the fundamentals of the LDAP service model is that the result of any modification of the directory (whether to the DIT or a DSA IT) must result in a consistent directory state. Maybe the text would be more easily understood if s/normal entries/entries in the protocol/ The control affects the semantics of the protocol operation, it doesn't alter the underlying directory and/or DSA information models. >I haven't got X.511(97); how does its ManageDsaIT service option work >in this respect? The ManageDsaIT service option, like the ManageDsaIT, indicates that the operation acts with a Dsa IT management plane instead of DIT. RFC 3296 use of the term "normal" means only that, objects within the selected Dsa It management plane are treated in the protocol as if they were objects in the DIT. I note that once LDAPBIS wraps up its work revising the 'core' TS, I intend to undertake a major revision of this RFC. In particular, I plan to incorporate most (if not all) of Steven's Directory Admin Models I-D into the revision. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 7 13:49:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08563 for ; Fri, 7 May 2004 13:49:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9MI-0007MZ-W4; Fri, 07 May 2004 13:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9Fc-0004iV-7i for ldapext@optimus.ietf.org; Fri, 07 May 2004 13:35:08 -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 NAA07801 for ; Fri, 7 May 2004 13:35:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9FZ-0003hy-V7 for ldapext@ietf.org; Fri, 07 May 2004 13:35:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9EY-0003GK-00 for ldapext@ietf.org; Fri, 07 May 2004 13:34:02 -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 1BM9Db-0002oj-00 for ldapext@ietf.org; Fri, 07 May 2004 13:33:03 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i47HX2nC038939; Fri, 7 May 2004 17:33:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040507102652.04e5aa60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 07 May 2004 10:32:59 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] ManageDsaIT control vs. parent referral objects Cc: ldapext@ietf.org In-Reply-To: <6.0.1.1.0.20040507091058.04d22cc0@127.0.0.1> References: <6.0.1.1.0.20040507091058.04d22cc0@127.0.0.1> 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=AWL 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: , The below comment is misplaced. I intend to incorporate the admin models stuff into a subsequent revision of the subentries specification [RFC 3672]. At 09:28 AM 5/7/2004, Kurt D. Zeilenga wrote: >I note that once LDAPBIS wraps up its work revising the 'core' >TS, I intend to undertake a major revision of this RFC. In >particular, I plan to incorporate most (if not all) of Steven's >Directory Admin Models I-D > >into the revision. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 7 17:30:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21999 for ; Fri, 7 May 2004 17:30:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCfS-0003kT-2y; Fri, 07 May 2004 17:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCbq-0002NB-AD for ldapext@optimus.ietf.org; Fri, 07 May 2004 17:10:18 -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 RAA21033 for ; Fri, 7 May 2004 17:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMCbn-0004bC-W2 for ldapext@ietf.org; Fri, 07 May 2004 17:10:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCb6-00049V-00 for ldapext@ietf.org; Fri, 07 May 2004 17:09:32 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BMCZr-0003Ja-00 for ldapext@ietf.org; Fri, 07 May 2004 17:08:15 -0400 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.30) id 1BMCZj-0005Ou-Vb; Fri, 07 May 2004 23:08:07 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.30) id 1BMCZi-00060g-78; Fri, 07 May 2004 23:08:06 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BMCZh-0006jw-00; Fri, 7 May 2004 23:08:05 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: ldapext@ietf.org Subject: Re: [ldapext] Complex knowledge information In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 7 May 2004 23:08:05 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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: , Jim Sermersheim writes: >>>>Hallvard B Furuseth 4/21/04 3:17:17 PM >>> >>Jim Sermersheim writes: >>> 1) What is the preferred way to represent this type of auxiliary >>> knowledge information in the directory? >>> 2) What is the preferred way to represent this type of auxiliary >>> knowledge information in operations returning a referral (or >>> searchResultReference)? >> >> (...) >>> (relying on the LDAP URL extensions means a similar mechanism must be >>> defined for future URI types). >> >> Or the syntaxes of referral and continuation references in the protocol >> could be extended to e.g. 'URI [SPACE ]', if the >> client has sent an extended request which solicits this. > > I'm thinking that might cause some unwanted effects on existing clients > which only expect a valid URI. No. As I said, it would only be sent if solicited. >> Similarly, maybe the 'ref' attribute could be extended to use the label >> part of 'labeledURI'. That would probably refer to something local to >> the server, though, so I'm not sure if it would be practical to make the >> label part of the referral protocol field identical to the label part of >> the 'ref' attribute. > > Yeah, this would have to be coupled with the solution above right? Not necessarily, though it could be confusing to do it differently. The server could move the info from the attribute to a control or whatever. It solves the problem of what to do if you have two ref attributes in one entry, and they need different extra information. > What > do you mean when you say it would refer to something local to the > server? It could potentially contain anything, right (a reference to > something, raw data, a mathematical formula, a SAML assertion, etc). True. But I had the impression that you were referring to data held elsewhere in the server, which would be sent in addition to the LDAPURL. > Thanks for the feedback so far. Do you think it would help if I > illustrated some extreme examples of storing stuff on values of the ref > attribute, and contrast that with returning that same kind of stuff in a > control, and further contrast those with returning small (reference > data) which would force the client to make a subsequent read? Yes, quite useful. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu May 13 23:50:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07907 for ; Thu, 13 May 2004 23:50:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOTgz-0001BS-DE; Thu, 13 May 2004 23:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOTdx-0000Y4-UP for ldapext@optimus.ietf.org; Thu, 13 May 2004 23:45:53 -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 XAA07763 for ; Thu, 13 May 2004 23:45:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOTdv-0005D7-Q5 for ldapext@ietf.org; Thu, 13 May 2004 23:45:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOTcx-0004fz-00 for ldapext@ietf.org; Thu, 13 May 2004 23:44:51 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BOTcH-00046H-00 for ldapext@ietf.org; Thu, 13 May 2004 23:44:09 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 13 May 2004 21:43:40 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 13 May 2004 21:43:23 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] password policy: pwdAllowUserChange 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'm not sure why we need this attribute. It's there to grant a user the rights to change his own attribute. Are there implementations that need this? It seems that local access control mechanisms should suffice. I'd like to remove it unless there's a compelling reason to leave it. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 14 01:08:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12282 for ; Fri, 14 May 2004 01:08:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOUtc-00030Z-CO; Fri, 14 May 2004 01:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOUob-0001or-77 for ldapext@optimus.ietf.org; Fri, 14 May 2004 01:00:57 -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 BAA11840 for ; Fri, 14 May 2004 01:00:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOUoY-0006KT-7x for ldapext@ietf.org; Fri, 14 May 2004 01:00:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOUmY-0005Fh-00 for ldapext@ietf.org; Fri, 14 May 2004 00:58:51 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BOUkj-0003q1-00 for ldapext@ietf.org; Fri, 14 May 2004 00:56:57 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Fri, 14 May 2004 14:44:28 +1000 Received: (qmail 17937 invoked from network); 14 May 2004 04:56:04 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 14 May 2004 04:56:04 -0000 Reply-To: From: "Andrew Sciberras" To: "'Jim Sermersheim'" , Subject: RE: [ldapext] password policy: pwdAllowUserChange Date: Fri, 14 May 2004 14:56:04 +1000 Message-ID: <01ff01c4396f$c3760020$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: 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=AWL 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 Hi Jim, I tend to agree with your here. I think that this an Access Control issue and therefore should not be part of the policy. I do not have any issues with its removal. Our directory can adequately control access to attributes and their values using our local access control and X.500 Basic Access Control implementations. Removing the pwdAllowUserChange attribute may become a problem for Directory implementations whose access control scheme cannot provide this functionality. If this attribute stay's within the draft then I think that text should be added to clearly indicate that the pwdAllowUserChange attribute is intended to be used in absence of any access controls. Cheers, .......................... Andrew Sciberras http://view500.adacel.com >-----Original Message----- >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On >Behalf Of >Jim Sermersheim >Sent: Friday, 14 May 2004 13:43 >To: ldapext@ietf.org >Subject: [ldapext] password policy: pwdAllowUserChange > > > > >I'm not sure why we need this attribute. It's there to grant a user the >rights to change his own attribute. Are there implementations that need >this? It seems that local access control mechanisms should suffice. > >I'd like to remove it unless there's a compelling reason to leave it. > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 14 01:53:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14515 for ; Fri, 14 May 2004 01:53:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVa5-000577-Rt; Fri, 14 May 2004 01:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVPa-0002lH-Ij for ldapext@optimus.ietf.org; Fri, 14 May 2004 01:39:10 -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 BAA13876 for ; Fri, 14 May 2004 01:39:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOVPX-0002Z4-DO for ldapext@ietf.org; Fri, 14 May 2004 01:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOVOe-0001yh-00 for ldapext@ietf.org; Fri, 14 May 2004 01:38:12 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BOVNR-0000sF-00 for ldapext@ietf.org; Fri, 14 May 2004 01:36:57 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 13 May 2004 23:36:28 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 13 May 2004 23:36:04 -0600 From: "Jim Sermersheim" To: Subject: RE: [ldapext] password policy: pwdAllowUserChange Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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=AWL 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 Yeah, I guess I could see a point in leaving it for the reason you point out, but for the same reason, I could see adding another attribute which grants rights to some 'pwdAdministrator" to change other people's passwords (and maybe even various password policy attributes). In fact, to align more closely with some existing implementations, the pwdSafeModify would allow this pwdAdministrator to make modifications without providing the old password. Section 2.1 currently lets us sleaze out of this rathole. I hope I'm not getting myself into more trouble. Jim >>> andrews@adacel.com.au 5/13/04 10:56:04 PM >>> Hi Jim, I tend to agree with your here. I think that this an Access Control issue and therefore should not be part of the policy. I do not have any issues with its removal. Our directory can adequately control access to attributes and their values using our local access control and X.500 Basic Access Control implementations. Removing the pwdAllowUserChange attribute may become a problem for Directory implementations whose access control scheme cannot provide this functionality. If this attribute stay's within the draft then I think that text should be added to clearly indicate that the pwdAllowUserChange attribute is intended to be used in absence of any access controls. Cheers, .......................... Andrew Sciberras http://view500.adacel.com >-----Original Message----- >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On >Behalf Of >Jim Sermersheim >Sent: Friday, 14 May 2004 13:43 >To: ldapext@ietf.org >Subject: [ldapext] password policy: pwdAllowUserChange > > > > >I'm not sure why we need this attribute. It's there to grant a user the >rights to change his own attribute. Are there implementations that need >this? It seems that local access control mechanisms should suffice. > >I'd like to remove it unless there's a compelling reason to leave it. > >Jim > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 14 02:34:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29602 for ; Fri, 14 May 2004 02:34:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWEn-00065T-5N; Fri, 14 May 2004 02:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWBa-0004xf-Kc for ldapext@optimus.ietf.org; Fri, 14 May 2004 02:28:46 -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 CAA29375 for ; Fri, 14 May 2004 02:28:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOWBW-0006Tm-Qw for ldapext@ietf.org; Fri, 14 May 2004 02:28:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOWAc-0005xs-00 for ldapext@ietf.org; Fri, 14 May 2004 02:27:47 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx with esmtp (Exim 4.12) id 1BOWA4-0005Go-00 for ldapext@ietf.org; Fri, 14 May 2004 02:27:13 -0400 Received: from [192.168.1.10] (82-43-138-40.cable.ubr01.newm.blueyonder.co.uk [82.43.138.40]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 14 May 2004 07:26:29 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 14 May 2004 07:26:28 +0100 Subject: Re: [ldapext] password policy: pwdAllowUserChange From: Chris Ridd To: Jim Sermersheim , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 On 14/5/04 6:36 am, Jim Sermersheim wrote: > Yeah, I guess I could see a point in leaving it for the reason you point > out, but for the same reason, I could see adding another attribute which > grants rights to some 'pwdAdministrator" to change other people's > passwords (and maybe even various password policy attributes). In fact, > to align more closely with some existing implementations, the > pwdSafeModify would allow this pwdAdministrator to make modifications > without providing the old password. Section 2.1 currently lets us sleaze > out of this rathole. > > I hope I'm not getting myself into more trouble. We asked Ludovic about this attribute a while ago. Essentially it is intended to be used by the server *after* access control evaluation has occurred - this enables an administrator to fine tune the user's access to the attribute without having to mess around with setting entryACI or the local equivalent. Apparently the Netscape/Sun implementation automatically sets its local ACLs when the pwdAllowUserChange attribute is changed, so on that server they're always the same. Being able to tweak stuff without messing with access controls seems like a fine goal which permits password management clients with having to have knowledge of the local access control implementation. It does need clarifying in the draft though. Cheers, Chris _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 14 03:34:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03422 for ; Fri, 14 May 2004 03:34: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 1BOX7u-0007bS-AT; Fri, 14 May 2004 03:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX4f-0006pn-Bd for ldapext@optimus.ietf.org; Fri, 14 May 2004 03:25:41 -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 DAA02814 for ; Fri, 14 May 2004 03:25:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOX4d-000635-1V for ldapext@ietf.org; Fri, 14 May 2004 03:25:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX31-0005E1-00 for ldapext@ietf.org; Fri, 14 May 2004 03:24:00 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx with esmtp (Exim 4.12) id 1BOX0z-0003xy-00 for ldapext@ietf.org; Fri, 14 May 2004 03:21:53 -0400 Received: from [192.168.1.10] (82-43-138-40.cable.ubr01.newm.blueyonder.co.uk [82.43.138.40]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 14 May 2004 08:21:22 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 14 May 2004 08:21:19 +0100 Subject: Re: [ldapext] password policy: pwdAllowUserChange From: Chris Ridd To: Chris Ridd , Jim Sermersheim , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 On 14/5/04 7:26 am, Chris Ridd wrote: > Being able to tweak stuff without messing with access controls seems like a > fine goal which permits password management clients with having to have > knowledge of the local access control implementation. That makes more sense with "prevents" instead of "permits" :-) Cheers, Chris _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 14 15:43:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18222 for ; Fri, 14 May 2004 15:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOiWL-0003DD-42; Fri, 14 May 2004 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZKY-0007IZ-TL for ldapext@optimus.ietf.org; Fri, 14 May 2004 05:50:14 -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 FAA10248 for ; Fri, 14 May 2004 05:50:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZKU-0003Pa-Uu for ldapext@ietf.org; Fri, 14 May 2004 05:50:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZJi-0002uC-00 for ldapext@ietf.org; Fri, 14 May 2004 05:49:22 -0400 Received: from linagora.net2.nerim.net ([62.4.23.8] helo=sgi2.linagora.com) by ietf-mx with esmtp (Exim 4.12) id 1BOZId-0002GS-00 for ldapext@ietf.org; Fri, 14 May 2004 05:48:15 -0400 Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id C6D32198221 for ; Fri, 14 May 2004 11:47:46 +0200 (CEST) Received: from [192.168.0.185] (unknown [192.168.0.185]) by sgi2.linagora.com (Postfix) with ESMTP id 35F2A19821D for ; Fri, 14 May 2004 11:47:46 +0200 (CEST) From: Alexandre PAUZIES Organization: LINAGORA To: ldapext@ietf.org Date: Fri, 14 May 2004 11:47:40 +0200 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200405141147.41442.alexandre.pauzies@linagora.com> 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.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: quoted-printable Hi, I made a draft to propose new LDAP matching rules : http://www.ietf.org/internet-drafts/draft-pauzies-ldap-schema-nonascii-mr-0= 0.txt and I hope you could send me comments on this. I also made patchs to add thoses matching rules implementation in OpenLDAP. Alexandre =2D-=20 Alexandre Pauzi=E8s LINAGORA - Soci=E9t=E9 de services en Logiciels Libres http://www.linagora.com/ - T=E9l: 01.58.18.68.28 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri May 14 17:05:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26848 for ; Fri, 14 May 2004 17:05: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 1BOjd5-0005oT-Uu; Fri, 14 May 2004 16:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOj8Y-0000an-DB for ldapext@optimus.ietf.org; Fri, 14 May 2004 16:18:30 -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 QAA21290 for ; Fri, 14 May 2004 16:18:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOj8W-0004lg-BN for ldapext@ietf.org; Fri, 14 May 2004 16:18:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOj5c-0003UH-00 for ldapext@ietf.org; Fri, 14 May 2004 16:15:29 -0400 Received: from 1-1-2-20b.rny.sth.bostream.se ([82.182.132.65] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1BOj2q-0002XI-00 for ldapext@ietf.org; Fri, 14 May 2004 16:12:36 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id i4EKBGn03942; Fri, 14 May 2004 22:11:17 +0200 Message-ID: <40A527E4.9020903@it.su.se> Date: Fri, 14 May 2004 22:11:16 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en, en-us MIME-Version: 1.0 To: Alexandre PAUZIES CC: ldapext@ietf.org Subject: Re: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt References: <200405141147.41442.alexandre.pauzies@linagora.com> In-Reply-To: <200405141147.41442.alexandre.pauzies@linagora.com> 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 Alexandre PAUZIES wrote: > Hi, > > I made a draft to propose new LDAP matching rules : > http://www.ietf.org/internet-drafts/draft-pauzies-ldap-schema-nonascii-mr-00.txt > and I hope you could send me comments on this. > > I also made patchs to add thoses matching rules implementation in OpenLDAP. > > Alexandre > Hmm. Section 1 could do with a bit of elaboration - I don't understand the purpouse of this. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon May 17 03:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03341 for ; Mon, 17 May 2004 03:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcDI-0003VD-Mz; Mon, 17 May 2004 03:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPc7B-0002fv-JN for ldapext@optimus.ietf.org; Mon, 17 May 2004 03:00: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 DAA02988 for ; Mon, 17 May 2004 03:00:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPc77-0002EN-Es for ldapext@ietf.org; Mon, 17 May 2004 03:00:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPc64-0001uW-00 for ldapext@ietf.org; Mon, 17 May 2004 02:59:37 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1BPc57-0001Kn-00 for ldapext@ietf.org; Mon, 17 May 2004 02:58:37 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 May 2004 16:58:06 +1000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] password policy: pwdAllowUserChange X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 Date: Mon, 17 May 2004 16:58:06 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381015BFFD7@ausyms21.ca.com> Thread-Topic: [ldapext] password policy: pwdAllowUserChange Thread-Index: AcQ5hWIwlDIGohdkQLmv8f1MCSKqgQCVs1MA From: "Ramsay, Ron" To: "Chris Ridd" Cc: X-OriginalArrivalTime: 17 May 2004 06:58:06.0835 (UTC) FILETIME=[4E74FC30:01C43BDC] 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: 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 pwdDisallowUserChange? -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of Chris Ridd Sent: Friday, 14 May 2004 17:21 To: Chris Ridd; Jim Sermersheim; ldapext@ietf.org Subject: Re: [ldapext] password policy: pwdAllowUserChange On 14/5/04 7:26 am, Chris Ridd wrote: > Being able to tweak stuff without messing with access controls seems = like a > fine goal which permits password management clients with having to = have > knowledge of the local access control implementation. That makes more sense with "prevents" instead of "permits" :-) Cheers, Chris _______________________________________________ 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 Mon May 17 05:58:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10833 for ; Mon, 17 May 2004 05:58:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPens-0000YA-QA; Mon, 17 May 2004 05:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPegz-0008Ot-ED for ldapext@optimus.ietf.org; Mon, 17 May 2004 05:45:53 -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 FAA10405 for ; Mon, 17 May 2004 05:45:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPegv-0006ol-To for ldapext@ietf.org; Mon, 17 May 2004 05:45:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPefy-0006Ve-00 for ldapext@ietf.org; Mon, 17 May 2004 05:44:51 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1BPef0-0005uv-00 for ldapext@ietf.org; Mon, 17 May 2004 05:43:50 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 May 2004 19:43:20 +1000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 Subject: RE: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt Date: Mon, 17 May 2004 19:43:19 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381015C014A@ausyms21.ca.com> Thread-Topic: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt Thread-Index: AcQ561Js32VvD7WCQFyu9WK/LZPtXwCB80lw From: "Ramsay, Ron" To: "Alexandre PAUZIES" , X-OriginalArrivalTime: 17 May 2004 09:43:20.0351 (UTC) FILETIME=[635F7AF0:01C43BF3] 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: 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 Why isn't this covered by the old matching rules? The X.500 standard = caseIgnoreMatch applies to UTF-8 and matches case (though they may not = have defined the meaning of space?). Ron -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of Alexandre PAUZIES Sent: Friday, 14 May 2004 19:48 To: ldapext@ietf.org Subject: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt Hi, I made a draft to propose new LDAP matching rules : http://www.ietf.org/internet-drafts/draft-pauzies-ldap-schema-nonascii-mr= -00.txt and I hope you could send me comments on this. I also made patchs to add thoses matching rules implementation in = OpenLDAP. Alexandre --=20 Alexandre Pauzi=E8s LINAGORA - Soci=E9t=E9 de services en Logiciels Libres http://www.linagora.com/ - T=E9l: 01.58.18.68.28 _______________________________________________ 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 Tue May 18 01:34:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01395 for ; Tue, 18 May 2004 01:34:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPx8z-0002ur-Mv; Tue, 18 May 2004 01:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPx24-0001KB-Li for ldapext@optimus.ietf.org; Tue, 18 May 2004 01:20:53 -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 BAA00818 for ; Tue, 18 May 2004 01:20:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPx21-0001Tz-IB for ldapext@ietf.org; Tue, 18 May 2004 01:20:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPx1D-00017B-00 for ldapext@ietf.org; Tue, 18 May 2004 01:20:00 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPx0W-0000hg-00 for ldapext@ietf.org; Tue, 18 May 2004 01:19:17 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Tue, 18 May 2004 15:07:30 +1000 Received: (qmail 18538 invoked from network); 18 May 2004 05:18:35 -0000 Received: from unknown (HELO adacel.com.au) (10.32.24.165) by nexus.adacel.com with SMTP; 18 May 2004 05:18:35 -0000 Message-ID: <40A99CA9.8030307@adacel.com.au> Date: Tue, 18 May 2004 15:18:33 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ramsay, Ron" , Alexandre PAUZIES CC: ldapext@ietf.org Subject: Re: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt References: <1395B4B334FCC143B36AF788E68B6381015C014A@ausyms21.ca.com> In-Reply-To: <1395B4B334FCC143B36AF788E68B6381015C014A@ausyms21.ca.com> 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.1 required=5.0 tests=AWL 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 Ramsay, Ron wrote: > Why isn't this covered by the old matching rules? The X.500 standard > caseIgnoreMatch applies to UTF-8 and matches case (though they may not > have defined the meaning of space?). These matching rules strip out diacriticals before performing the case ignore match, which is something the existing case ignore matching rules don't do. The names of these matching rules are clearly causing confusion. A better name for caseIgnoreNonasciiMatch, for example, would be something like caseIgnoreCanonicalLatinMatch or caseIgnoreBasicLatinMatch. Regards, Steven > > Ron > > -----Original Message----- > From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of > Alexandre PAUZIES > Sent: Friday, 14 May 2004 19:48 > To: ldapext@ietf.org > Subject: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt > > > Hi, > > I made a draft to propose new LDAP matching rules : > http://www.ietf.org/internet-drafts/draft-pauzies-ldap-schema-nonascii-mr-00.txt > and I hope you could send me comments on this. > > I also made patchs to add thoses matching rules implementation in OpenLDAP. > > Alexandre > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 19 05:40:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24911 for ; Wed, 19 May 2004 05:40: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 1BQN7Z-0007j7-0S; Wed, 19 May 2004 05:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMKS-0001NP-TS for ldapext@optimus.ietf.org; Wed, 19 May 2004 04:21:35 -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 EAA21053 for ; Wed, 19 May 2004 04:21:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQMKQ-0000ez-3k for ldapext@ietf.org; Wed, 19 May 2004 04:21:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMJW-0000XP-00 for ldapext@ietf.org; Wed, 19 May 2004 04:20:35 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BQMId-0000Nn-00 for ldapext@ietf.org; Wed, 19 May 2004 04:19:40 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.30) id 1BQMIa-00078o-0h; Wed, 19 May 2004 10:19:36 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BQMDj-0004QH-2V; Wed, 19 May 2004 10:14:35 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BQMDU-0000bk-00; Wed, 19 May 2004 10:14:21 +0200 From: Hallvard B Furuseth Message-Id: To: Alexandre PAUZIES Cc: ldapext@ietf.org Subject: Re: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt In-Reply-To: <200405141147.41442.alexandre.pauzies@linagora.com> References: <200405141147.41442.alexandre.pauzies@linagora.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 19 May 2004 10:14:21 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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: 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 Alexandre PAUZIES writes: > http://www.ietf.org/internet-drafts/draft-pauzies-ldap-schema-nonascii-mr= -00.txt The draft says: > When using thoses rules, non-ASCII characters such as letters with > accents are converted (when UTF-8 compatibility conversion is > possible RFC 2044 [RFC2044]) to ASCII characters (same letter without > accent) before the match. First, "same letter without accent" is not a good rule, and I don't know of any standard tables one can use to implement it anyway. When I asked the Unicode mailinglist (unicode@unicode.org) about a similar problem, the recommendations were: - use the NFKD decompositions from the UCD, then see if the first character is an ASCII character, and if so, remove diacritics in the 03xx block (that have a "Mn" general category and a non-zero combining class). - or produce the NFD normalisation of the text, and remove all characters with a non-zero combining class. Unlike NFD, NFKD would for example convert the trademark symbol to "TM" and superscript 2 to "2". However, many people will find a rule like above close to what they need, but unfortunately useless or poor for their purpose. For example, an important special case I'd want in our server is to translate "=F8" to "o", both for foreigners who have been told plain-ASCII names and so that Norwegian "=F8" would match Swedish "=F6". Other examples (from D. Starner): Diagraphs can be treated as titlecase or capital or intelligently. 00FE - "th" 00DE - "TH" 00F0 - "dh" ("th"?) OOD0 - "DH" ("TH"?) 0108 - "CH" (Esperanto) 0109 - "ch" 011C, 011D - "GH", "gh" (E-o) 0124, 0125 - "HH", "hh" (") 0134, 0135 - "JH", "jh" (") 015C, 015D - "SH", "sh" (") 017F - "s" Depending on your goals, 015F & 0161 could be "sh", 0163 "ts", 017D "zh", etc. 0195 - "hw" 01A3 - "gh"(?) 01BF - "w" 01C0 - "|" ("c"?) 01C1 - "||"? ("x"?) 01C3 - "!" ("q"?) 0223 - "w" ("ou"? "8"?) I omitted most capitals and those that can be found by decomposition or name stripping, as well a bunch I don't know anything about. My impression from the Unicode mailinglist is that there are a lot of such special cases not covered by Unicode, and that the usual solution is to amend the Unicode character mappings with private mappings at need. I think no comprehensive list of such special cases exists. What such a list would consist of would in any case depend on e.g. which languages/cultures/geographical areas it applies to. Kenneth Whistler said: You could search in the Unicode email archives for "fallback". Much of that discussion will be about fallback display of glyphs, but there have also been discussions about fallback conversion of characters. There might be further examples or pointers somewhere in there. (I did that, but didn't find much which related to my purpose at the time. Don't remember if the matches would relate to your more general rules. URL . Note the user name and password at that page.) Anyway, I suggest that the draft should not specify exactly how these rules match, but just give a default rule such as suggested above and allow private amendments. How much to allow implementations to differ from the default would depend on the intended purpose of these matching rules. So what is the intended purpose of these rules? For example, - Are they only intended to be useful for Latin scripts, or could people who use other scripts add similar rules? - another suggestion at the Unicode mailinglist was: for Korean syllables (U+AC00 - U+Dxxx), you can use 'Hangul Syllable Short Names' that can be algorithmically derived with small tables. - What is the best trade-off between getting successful matches of strings intended to be equivalent, and not getting too many matches due to loss of semantics? For example, how about non-letters? Would it be useful to let some or all punctuation match each other, or to treat it all as space? That way "J. Doe" would match "J Doe". Once the intent is clarified, I suggest you take this to the Unicode mailinglist for advice. --=20 Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sun May 23 14:41:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29152 for ; Sun, 23 May 2004 14:41:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRxoK-0007nx-Ul; Sun, 23 May 2004 14:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRxl7-0007NH-N0 for ldapext@optimus.ietf.org; Sun, 23 May 2004 14:31:41 -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 OAA28815 for ; Sun, 23 May 2004 14:31:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRxl5-0005Ns-2W for ldapext@ietf.org; Sun, 23 May 2004 14:31:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRxk1-00056U-00 for ldapext@ietf.org; Sun, 23 May 2004 14:30:34 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BRxj2-0004dC-00 for ldapext@ietf.org; Sun, 23 May 2004 14:29:32 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.30) id 1BRxix-0002qZ-3c for ldapext@ietf.org; Sun, 23 May 2004 20:29:27 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BRxiv-0008Ay-V0; Sun, 23 May 2004 20:29:25 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BRxiv-00005P-00; Sun, 23 May 2004 20:29:25 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Sun, 23 May 2004 20:29:25 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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] noop control vs. non-modify 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: , draft-zeilenga-ldap-noop-04.txt says: > The control is appropriate for request messages of LDAP Add, Delete, > Modify and ModifyDN operations [RFC2251]. I don't remember if I have suggested this before, but the control could be useful with other operations too: - Bind: Verify that the credentials are correct without actually changing the session's authorization ID or SASL layer, and without abandoning outstanding operations. Probably the server SHOULD NOT wait for outstanding operations either. - Operations in general: Check if the server supports the operation (with the given parameters), or that it supports some control, or that the user has access to perform the operation. The noop control spec would have to say that the operation has no effect, not only that it has no effect _on the directory_. It should not affect SASL/TLS layers, bind DN, or anything else. The control would fail if it could not test the operation without such side effects. noOperation would be returned instead of compareTrue and compareFalse as well as instead of success. BTW, 'no effect' may not be entirely possible, with or without my suggestion. For example, in a directory where each entry is stored in a file, Add+noop might update the time of last access for the file, and the server might support a way to read that time. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu May 27 17:19:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26499 for ; Thu, 27 May 2004 17:19:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTS71-0007zO-3U; Thu, 27 May 2004 17:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTRsP-0003cq-0h for ldapext@megatron.ietf.org; Thu, 27 May 2004 16:53:21 -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 QAA24466 for ; Thu, 27 May 2004 16:53:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTRs8-00077W-Ic for ldapext@ietf.org; Thu, 27 May 2004 16:53:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTRrH-0006qQ-00 for ldapext@ietf.org; Thu, 27 May 2004 16:52:12 -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 1BTRqL-0006Xw-00 for ldapext@ietf.org; Thu, 27 May 2004 16:51:13 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i4RKpBKl086225; Thu, 27 May 2004 20:51:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040527131251.04966e70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 27 May 2004 13:51:20 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] noop control vs. non-modify operations In-Reply-To: References: 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=AWL autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 11:29 AM 5/23/2004, Hallvard B Furuseth wrote: >draft-zeilenga-ldap-noop-04.txt says: >> The control is appropriate for request messages of LDAP Add, Delete, >> Modify and ModifyDN operations [RFC2251]. I should also note that the control is appropriate for extended requests of operations which update the directory, such as the password modify extended operation [RFC3062]. >I don't remember if I have suggested this before, but the control could >be useful with other operations too: > >- Bind: Verify that the credentials are correct without actually > changing the session's authorization ID or SASL layer, and without > abandoning outstanding operations. Probably the server SHOULD NOT > wait for outstanding operations either. As engineering this functionality requires special attention to security considerations (as it would extend LDAP authentication capabilities), I believe it best that a separate control be used to provide this functionality. I note that already exists controls, so called "fast bind" or "concurrent bind" controls, which do provide this kind functionality. >- Operations in general: Check if the server supports the operation > (with the given parameters), or that it supports some control, > or that the user has access to perform the operation. While the control could, I guess, be used to discover feature support it is not intended to be used in that manner. >BTW, 'no effect' may not be entirely possible, with or without my >suggestion. For example, in a directory where each entry is stored in a >file, Add+noop might update the time of last access for the file, and >the server might support a way to read that time. I note that I-D does not use the term 'no effect'. And while any access of the directory could be viewed as having an effect upon the directory, I think the document is reasonable clear on which effects it this control impacts. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 31 12:01:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28004 for ; Mon, 31 May 2004 12:01:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUpA6-0006Jf-Sm; Mon, 31 May 2004 11:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUp07-0004lB-L8 for ldapext@megatron.ietf.org; Mon, 31 May 2004 11:46:59 -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 LAA27165 for ; Mon, 31 May 2004 11:46:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUp01-0003PU-Sv for ldapext@ietf.org; Mon, 31 May 2004 11:46:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUoz2-00031s-00 for ldapext@ietf.org; Mon, 31 May 2004 11:45:53 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BUoxz-0002QI-00 for ldapext@ietf.org; Mon, 31 May 2004 11:44:47 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.30) id 1BUoxw-0002IH-Of for ldapext@ietf.org; Mon, 31 May 2004 17:44:44 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BUoxv-0006RA-3b; Mon, 31 May 2004 17:44:43 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BUoxt-000528-00; Mon, 31 May 2004 17:44:42 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Mon, 31 May 2004 17:44:42 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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] Object class for untyped objects X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I'd like to publish an RFC for a structural object class which can be used (at least) for entries with no 'natural' choice of a structural object class, typically because the entry must exist even though its contents are uninteresting. For example, our directory ended up with entries like this, because no such object class existed: uid=,ou=people,dc=uio,dc=no cn=,ou=filegroups,dc=uio,dc=no That 'ou' (organizationalUnit) is silly, but it was the best existing object class to use. The entries can end up as useless garbage in response to searches for org.units. One might think others who want a similar structure would be less lazy and define a proper object class, but I keep seeing this mis-design in other places too. So I'm thinking of an object class like this: ( 'untypedObject' DESC 'Object of no particular type' SUP top STRUCTURAL MAY ( c $ cn $ dc $ l $ o $ ou $ st $ street $ uid # naming $ description $ owner $ seeAlso # general info $ enhancedSearchGuide $ searchGuide ) ) # subtree bases Do you think such an object class is too general, and I should rename it to something like 'subtreeBase' instead? Or is it not general enough for an object class as general as this, and should include what Luke Howard's upcoming 'namedObject' offers? "May be used when no other structural object class is available" - in the case of namedObject, the rationale is entries whose function is supplied by an auxiliary object class like posixGroup. See the expired I-D . Currently I avoided that in order to not step on Luke's toes. Notes on untypedObject's attributes: - The c through uid attributes are for naming of entries; they are not supposed to be used for anything else (unless the entry has other object classes as well). I took them from the table in rfc2253 (UTF-8 String Representation of Distinguished Names), in case the entry's RDN needs to match the RDN of something else. Though possibly only cn should be there, or cn, dc and uid. - Description, owner and seeAlso seems good to offer for 'nothing in particular'-kind of objects, since they may not contain anything else which indicates what they are for and who is responsible for them. - EnhancedSearchGuide and searchGuide are for entries used as base objects of subtrees. Finally, I'm not sure if the proper way to get an OID for such an object class is to use our own OID space or to get one from IANA. BCP64 (RFC3383) section 3.1 says For IETF developed elements, specifications SHOULD use OIDs under "Internet Directory Numbers" (1.3.6.1.1.x). but maybe that doesn't apply to an informational RFC developed on an expired IETF working group's mailing list. (Kurt, maybe you could add something to bcp64bis about that? And maybe the reply to that should go to ietf-ldapbis@openldap.org.) -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 31 12:43:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00220 for ; Mon, 31 May 2004 12:43:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUply-0005Ur-To; Mon, 31 May 2004 12:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUpfg-0004WF-Br for ldapext@megatron.ietf.org; Mon, 31 May 2004 12:29:56 -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 MAA29608 for ; Mon, 31 May 2004 12:29:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUpff-00048n-Ft for ldapext@ietf.org; Mon, 31 May 2004 12:29:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUpe2-0003Kx-00 for ldapext@ietf.org; Mon, 31 May 2004 12:28:14 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BUpcJ-0002Xd-00 for ldapext@ietf.org; Mon, 31 May 2004 12:26:27 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.30) id 1BUpcG-0007lA-25 for ldapext@ietf.org; Mon, 31 May 2004 18:26:24 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BUpY8-00065f-Tk for ldapext@ietf.org; Mon, 31 May 2004 18:22:08 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BUpY8-00056V-00 for ldapext@ietf.org; Mon, 31 May 2004 18:22:08 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Subject: Re: [ldapext] Object class for untyped objects In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 31 May 2004 18:22:08 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I wrote: > Finally, I'm not sure if the proper way to get an OID for such an object > class is to use our own OID space or to get one from IANA. BCP64 > (RFC3383) section 3.1 says > > For IETF developed elements, specifications SHOULD use OIDs under > "Internet Directory Numbers" (1.3.6.1.1.x). Um. Maybe I should add that the reason I think this might apply at all is because I'll be develop it through Internet-Drafts in order to become an RFC, not just to publish an already existing schema element. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 31 13:06:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01233 for ; Mon, 31 May 2004 13:06:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUq79-0000Uk-CM; Mon, 31 May 2004 12:58:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUq36-0008Ao-4g for ldapext@megatron.ietf.org; Mon, 31 May 2004 12:54:08 -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 MAA00770 for ; Mon, 31 May 2004 12:54:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUq35-0005xF-7d for ldapext@ietf.org; Mon, 31 May 2004 12:54:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUq2A-0005ak-00 for ldapext@ietf.org; Mon, 31 May 2004 12:53:11 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BUq1k-0005DY-00 for ldapext@ietf.org; Mon, 31 May 2004 12:52:44 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.30) id 1BUq1h-0003FK-1v; Mon, 31 May 2004 18:52:41 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BUq1e-000869-7S; Mon, 31 May 2004 18:52:38 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BUq1c-0005BZ-00; Mon, 31 May 2004 18:52:36 +0200 From: Hallvard B Furuseth Message-Id: To: "Kurt D. Zeilenga" Subject: Re: [ldapext] noop control vs. non-modify operations In-Reply-To: <6.0.1.1.0.20040527131251.04966e70@127.0.0.1> References: <6.0.1.1.0.20040527131251.04966e70@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 31 May 2004 18:52:36 +0200 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) 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 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Kurt D. Zeilenga writes: >At 11:29 AM 5/23/2004, Hallvard B Furuseth wrote: >> draft-zeilenga-ldap-noop-04.txt says: >>> The control is appropriate for request messages of LDAP Add, Delete, >>> Modify and ModifyDN operations [RFC2251]. >> (...) >> I don't remember if I have suggested this before, but the control could >> be useful with other operations too: >> >> - Bind: Verify that the credentials are correct without actually >> changing the session's authorization ID or SASL layer, and without >> abandoning outstanding operations. Probably the server SHOULD NOT >> wait for outstanding operations either. > > As engineering this functionality requires special > attention to security considerations (as it would extend > LDAP authentication capabilities), I believe it best that a > separate control be used to provide this functionality. Good point. > I note that already exists controls, so called "fast bind" > or "concurrent bind" controls, which do provide this kind > functionality. Pity they don't seem to be RFC'ed then. Do you know of some such specs or implementations that seem reasonable, and whose owners might accept to have them RFC'ed? I might find time to do that, and an OpenLDAP reference implementation, sometime this year:-) >> BTW, 'no effect' may not be entirely possible, with or without my >> suggestion. (...) > > I note that I-D does not use the term 'no effect'. No, I did. I was just noting that some wordsmithing or deeper work would be needed with my suggestions, if they were accepted. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon May 31 13:41:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02656 for ; Mon, 31 May 2004 13:41:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUqin-00052z-4h; Mon, 31 May 2004 13:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUqen-0004cD-0w for ldapext@megatron.ietf.org; Mon, 31 May 2004 13:33:05 -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 NAA02394 for ; Mon, 31 May 2004 13:33:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUqel-0004vZ-Uq for ldapext@ietf.org; Mon, 31 May 2004 13:33:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUqdp-0004Yf-00 for ldapext@ietf.org; Mon, 31 May 2004 13:32:06 -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 1BUqct-0004C4-00 for ldapext@ietf.org; Mon, 31 May 2004 13:31:07 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i4VHV6qf011925; Mon, 31 May 2004 17:31:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040531100747.04a89c40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 31 May 2004 10:31:07 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: OIDs (was: [ldapext] Object class for untyped object) In-Reply-To: References: 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=AWL autolearn=no version=2.60 Cc: ietf-ldapbis@OpenLDAP.org, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 09:22 AM 5/31/2004, Hallvard B Furuseth wrote: >I wrote: > >> Finally, I'm not sure if the proper way to get an OID for such an object >> class is to use our own OID space or to get one from IANA. BCP64 >> (RFC3383) section 3.1 says >> >> For IETF developed elements, specifications SHOULD use OIDs under >> "Internet Directory Numbers" (1.3.6.1.1.x). > >Um. Maybe I should add that the reason I think this might apply at all >is because I'll be develop it through Internet-Drafts in order to become >an RFC, not just to publish an already existing schema element. A couple of notes regarding this BCP 64 text... First note that text says "For IETF developed elements" as opposed to "elements described in IETF documents". This because IETF documents often describe elements developed by others (e.g., other SDOs, individuals). Second note that IETF work can be done by individuals as well as by working groups. That said, I don't think this sentence was intended to exclude others from requesting assignment of an Internet Directory Number for use in an LDAP specification. This is evident because the assignment practice is "Expert Review with Specification Required" and not "IETF Consensus". A simple rewording/reordering of the section would likely be more clear here. I intend to incorporate such a change in the next revision of the BCP64bis I-D. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext