From ldapext-bounces@ietf.org Wed Feb 15 06:23:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Kkl-0004oX-R4; Wed, 15 Feb 2006 06:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Kkk-0004n6-JM for ldapext@megatron.ietf.org; Wed, 15 Feb 2006 06:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00075 for ; Wed, 15 Feb 2006 06:21:36 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Kyc-0005bH-Te for ldapext@ietf.org; Wed, 15 Feb 2006 06:37:51 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k1FBMqN0031734 for ; Wed, 15 Feb 2006 05:22:53 -0600 Message-ID: <43F30F1B.9060700@highlandsun.com> Date: Wed, 15 Feb 2006 03:23:07 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060209 SeaMonkey/1.5a Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [ldapext] objectIdentifierMatch X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org It seems this matching rule is rather difficult to use in practice, given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.) I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 15 14:09:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9S1j-00081R-9x; Wed, 15 Feb 2006 14:09:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9S1h-0007yq-3W for ldapext@megatron.ietf.org; Wed, 15 Feb 2006 14:09:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23908 for ; Wed, 15 Feb 2006 14:07:34 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9SFl-0004dI-OC for ldapext@ietf.org; Wed, 15 Feb 2006 14:23:54 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k1FJ9EMJ086665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 19:09:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060215105339.0223cd88@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 15 Feb 2006 11:08:53 -0800 To: Howard Chu From: "Kurt D. Zeilenga" Subject: Re: [ldapext] objectIdentifierMatch In-Reply-To: <43F30F1B.9060700@highlandsun.com> References: <43F30F1B.9060700@highlandsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 2.1 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 03:23 AM 2/15/2006, Howard Chu wrote: >It seems this matching rule is rather difficult to use in practice, with descriptor support, yes. >given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.) It's difficult to know whether a particular descriptor unambiguously refers to a particular OID. LDAP has always allowed an OID to refer to different OIDs in different contexts. >I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions? I'd prefer something like X-OID-CONTEXT than X-NAMESPACE as the latter is not OID-specific. And as values, I would spell them out for clarity. That is, X-OID-CONTEXT 'attributeTypes' Of course, even descriptors naming a particular kind of object may be ambiguous, like 'x-foo'. This is why I suggested 'X-OID-CONTEXT' instead of 'X-OID-KIND'. The term context implies which kind of object is being named, but the source of the names (for 'attributeTypes', the controlling schema). Kurt >-- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 15 14:48:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Sdl-0001vx-V0; Wed, 15 Feb 2006 14:48:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Sdj-0001t7-R7 for ldapext@megatron.ietf.org; Wed, 15 Feb 2006 14:48:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26290 for ; Wed, 15 Feb 2006 14:46:52 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Srn-0005wd-RB for ldapext@ietf.org; Wed, 15 Feb 2006 15:03:13 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k1FJmYjE088862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 19:48:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060215113928.0229cc58@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 15 Feb 2006 11:48:12 -0800 To: Howard Chu From: "Kurt D. Zeilenga" Subject: Re: [ldapext] objectIdentifierMatch In-Reply-To: <7.0.1.0.0.20060215105339.0223cd88@OpenLDAP.org> References: <43F30F1B.9060700@highlandsun.com> <7.0.1.0.0.20060215105339.0223cd88@OpenLDAP.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 2.1 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I note that in some cases OID and objectIdentifierMatch are used where it would be more appropriate for the syntax/matching rules for attribute descriptions to be used. Attribute descriptions allow language and other tags to be specified. Unforunately, matching rules commonly used for attribute descriptions do not deal with ambiguity in naming of attribute types (cn v commonName v 2.5.4.3) as well as ambiguity caused by ordering of attribute options. So, we might consider designing robust 'attribute description' syntax and matching rules (instead of or in addition to an attribute type schema description extension). Kurt At 11:08 AM 2/15/2006, Kurt D. Zeilenga wrote: >At 03:23 AM 2/15/2006, Howard Chu wrote: >>It seems this matching rule is rather difficult to use in practice, > >with descriptor support, yes. > >>given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.) > >It's difficult to know whether a particular descriptor >unambiguously refers to a particular OID. LDAP has always >allowed an OID to refer to different OIDs in different contexts. > >>I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions? > >I'd prefer something like X-OID-CONTEXT than >X-NAMESPACE as the latter is not OID-specific. And as values, >I would spell them out for clarity. That is, > X-OID-CONTEXT 'attributeTypes' > >Of course, even descriptors naming a particular kind of object >may be ambiguous, like 'x-foo'. This is why I suggested >'X-OID-CONTEXT' instead of 'X-OID-KIND'. The term context >implies which kind of object is being named, but the source >of the names (for 'attributeTypes', the controlling schema). > >Kurt > >>-- >> -- Howard Chu >> Chief Architect, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc >> OpenLDAP Core Team http://www.openldap.org/project/ >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 15 15:04:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9StQ-0004P3-7w; Wed, 15 Feb 2006 15:04:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9StO-0004Nj-4p for ldapext@megatron.ietf.org; Wed, 15 Feb 2006 15:04:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26950 for ; Wed, 15 Feb 2006 15:03:02 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9T7P-0006L6-AP for ldapext@ietf.org; Wed, 15 Feb 2006 15:19:23 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k1FK4PIY009219; Wed, 15 Feb 2006 14:04:27 -0600 Message-ID: <43F38959.5050809@highlandsun.com> Date: Wed, 15 Feb 2006 12:04:41 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060209 SeaMonkey/1.5a Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] objectIdentifierMatch References: <43F30F1B.9060700@highlandsun.com> <7.0.1.0.0.20060215105339.0223cd88@OpenLDAP.org> <7.0.1.0.0.20060215113928.0229cc58@OpenLDAP.org> In-Reply-To: <7.0.1.0.0.20060215113928.0229cc58@OpenLDAP.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Kurt D. Zeilenga wrote: > I note that in some cases OID and objectIdentifierMatch are > used where it would be more appropriate for the syntax/matching > rules for attribute descriptions to be used. Attribute > descriptions allow language and other tags to be specified. > > Unforunately, matching rules commonly used for attribute > descriptions do not deal with ambiguity in naming of attribute > types (cn v commonName v 2.5.4.3) as well as ambiguity > caused by ordering of attribute options. > > So, we might consider designing robust 'attribute description' > syntax and matching rules (instead of or in addition to > an attribute type schema description extension). That makes a lot more sense. We probably still need the schema extension to address the other uses. > > Kurt > > At 11:08 AM 2/15/2006, Kurt D. Zeilenga wrote: >> At 03:23 AM 2/15/2006, Howard Chu wrote: >>> It seems this matching rule is rather difficult to use in practice, >> with descriptor support, yes. >> >>> given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.) >> It's difficult to know whether a particular descriptor >> unambiguously refers to a particular OID. LDAP has always >> allowed an OID to refer to different OIDs in different contexts. >> >>> I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions? >> I'd prefer something like X-OID-CONTEXT than >> X-NAMESPACE as the latter is not OID-specific. And as values, >> I would spell them out for clarity. That is, >> X-OID-CONTEXT 'attributeTypes' >> >> Of course, even descriptors naming a particular kind of object >> may be ambiguous, like 'x-foo'. This is why I suggested >> 'X-OID-CONTEXT' instead of 'X-OID-KIND'. The term context >> implies which kind of object is being named, but the source >> of the names (for 'attributeTypes', the controlling schema). >> >> Kurt >> >>> -- >>> -- Howard Chu >>> Chief Architect, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc >>> OpenLDAP Core Team http://www.openldap.org/project/ -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 15 19:07:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WgI-0007Ic-Jd; Wed, 15 Feb 2006 19:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WgG-0007HO-GE for ldapext@megatron.ietf.org; Wed, 15 Feb 2006 19:07:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23253 for ; Wed, 15 Feb 2006 19:05:45 -0500 (EST) Received: from eagle.unknowndns.net ([221.133.206.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9WuA-0000hz-Gi for ldapext@ietf.org; Wed, 15 Feb 2006 19:22:08 -0500 Received: from [203.206.165.210] (helo=[192.168.1.156]) by eagle.unknowndns.net with esmtpa (Exim 4.52) id 1F9Wfv-0006g8-8e; Thu, 16 Feb 2006 10:07:11 +1000 Message-ID: <43F3C22D.1030500@eb2bcom.com> Date: Thu, 16 Feb 2006 11:07:09 +1100 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] objectIdentifierMatch References: <43F30F1B.9060700@highlandsun.com> In-Reply-To: <43F30F1B.9060700@highlandsun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - eagle.unknowndns.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Spam-Score: 4.2 (++++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Howard, Howard Chu wrote: > It seems this matching rule is rather difficult to use in practice, > given that it's supposed to accept textual descriptors in addition to > numeric OIDs, but there's no way for apps to know in what context the > valid descriptors reside. (See > http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an > example of how this affected our password policy implementation, > ITS#4402 for another user tripping over it in an arbitrary schema.) > > I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' > to attribute definitions with this matching rule might help make things > less ambiguous. Suggestions? The problem is wider than just attributes with the OID syntax. OIDs can be embedded in more complex syntaxes. When GSER encoding or decoding values of these syntaxes the context of an OID descriptor becomes an issue. In our implementation we exploit a feature of ASN.1 to determine the appropriate context. The X.500 ASN.1 definitions typically refer to an OBJECT IDENTIFIER for an attribute type with the notation ATTRIBUTE.&id, which means the id field of the ATTRIBUTE information object class (not to be confused with entry object classes). The type of that id field is OBJECT IDENTIFIER, so as far as most encoding rules are concerned, OBJECT IDENTIFIER and ATTRIBUTE.&id are equivalent. However for GSER we use ATTRIBUTE.&id as an indication that the context for any OID descriptors is attribute types. Similarly, X.500 typically uses OBJECT-CLASS.&id to refer to the OID for an entry object class, MATCHING-RULE.&id to refer to the OID for a matching rule and NAME-FORM.&id to refer to the OID for a name form. X.500 isn't entirely consistent in using the appropriate referencing notation, so we replace some of the OBJECT IDENTIFIER references in our ASN.1 sources with the more specific reference. In particular, we change the X.500 syntax of the objectClass attribute from OBJECT IDENTIFIER to OBJECT-CLASS.&id. We haven't changed the LDAP syntax OID of the objectClass attribute, instead treating this as just another one of those annoying cases where a single LDAP syntax OID corresponds to a number of slightly different ASN.1 type definitions. >From my perspective the "correct" solution is to define additional syntax OIDs to represent the different contexts of OIDs in LDAP. That is, a separate LDAP syntax for attribute type OIDs which has the underlying notional ASN.1 type of ATTRIBUTE.&id, a separate LDAP syntax for object class OIDs which has the underlying notional ASN.1 type of OBJECT-CLASS.&id, and so on. The LDAP-specific encoding for each of these new syntaxes would be exactly the same as the LDAP-specific encoding of the current LDAP OID Syntax. Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 15 19:30:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9X2L-00013g-S6; Wed, 15 Feb 2006 19:30:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9X2K-00010s-3J for ldapext@megatron.ietf.org; Wed, 15 Feb 2006 19:30:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29020 for ; Wed, 15 Feb 2006 19:28:33 -0500 (EST) Received: from eagle.unknowndns.net ([221.133.206.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9XGQ-0002xb-2Z for ldapext@ietf.org; Wed, 15 Feb 2006 19:44:56 -0500 Received: from [203.206.165.210] (helo=[192.168.1.156]) by eagle.unknowndns.net with esmtpa (Exim 4.52) id 1F9X29-0007ZW-HM; Thu, 16 Feb 2006 10:30:09 +1000 Message-ID: <43F3C78F.3070701@eb2bcom.com> Date: Thu, 16 Feb 2006 11:30:07 +1100 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] objectIdentifierMatch References: <43F30F1B.9060700@highlandsun.com> <7.0.1.0.0.20060215105339.0223cd88@OpenLDAP.org> <7.0.1.0.0.20060215113928.0229cc58@OpenLDAP.org> In-Reply-To: <7.0.1.0.0.20060215113928.0229cc58@OpenLDAP.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - eagle.unknowndns.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Kurt, Kurt D. Zeilenga wrote: > I note that in some cases OID and objectIdentifierMatch are > used where it would be more appropriate for the syntax/matching > rules for attribute descriptions to be used. Attribute > descriptions allow language and other tags to be specified. > > Unforunately, matching rules commonly used for attribute > descriptions do not deal with ambiguity in naming of attribute > types (cn v commonName v 2.5.4.3) as well as ambiguity > caused by ordering of attribute options. > > So, we might consider designing robust 'attribute description' > syntax and matching rules I support this. I can't stuff an LDAP attribute description into an OBJECT IDENTIFIER in X.500, so "attribute description" needs to be a distinct syntax for LDAP/X.500 alignment. My preference would be for the underlying ASN.1 type of such a syntax to be the same as the AttributeDescription type I have defined for XLDAP, i.e. AttributeDescription ::= SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL } even if the LDAP-specific encoding is defined to be the ABNF for AttributeDescription from RFC 2251. Regards, Steven > (instead of or in addition to > an attribute type schema description extension). > > Kurt > > At 11:08 AM 2/15/2006, Kurt D. Zeilenga wrote: > >>At 03:23 AM 2/15/2006, Howard Chu wrote: >> >>>It seems this matching rule is rather difficult to use in practice, >> >>with descriptor support, yes. >> >> >>>given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.) >> >>It's difficult to know whether a particular descriptor >>unambiguously refers to a particular OID. LDAP has always >>allowed an OID to refer to different OIDs in different contexts. >> >> >>>I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions? >> >>I'd prefer something like X-OID-CONTEXT than >>X-NAMESPACE as the latter is not OID-specific. And as values, >>I would spell them out for clarity. That is, >> X-OID-CONTEXT 'attributeTypes' >> >>Of course, even descriptors naming a particular kind of object >>may be ambiguous, like 'x-foo'. This is why I suggested >>'X-OID-CONTEXT' instead of 'X-OID-KIND'. The term context >>implies which kind of object is being named, but the source >>of the names (for 'attributeTypes', the controlling schema). >> >>Kurt >> >> >>>-- >>> -- Howard Chu >>> Chief Architect, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc >>> OpenLDAP Core Team http://www.openldap.org/project/ >>> >>>_______________________________________________ >>>Ldapext mailing list >>>Ldapext@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ldapext >> >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Feb 27 10:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkaR-0004w8-2E; Mon, 27 Feb 2006 10:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkaP-0004u6-KD for ldapext@ietf.org; Mon, 27 Feb 2006 10:46:57 -0500 Received: from boole.openldap.org ([204.152.186.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkaP-0007CG-88 for ldapext@ietf.org; Mon, 27 Feb 2006 10:46:57 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k1RFkrNA023578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 15:46:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060227073515.03881468@OpenLDAP.org> Message-Id: <7.0.0.16.0.20060123115156.0226d6d0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Feb 2006 07:46:26 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: directory@apps.ietf.org Subject: [ldapext] Open meeting of the Directory Directory X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org A session slot at IETF#65 to hold an open meeting of the Directory Directorate as been approved. Presently, the session is scheduled for 1740-1840 on Monday, 20 March 2006. Of course, the schedule is not final yet. Regards, Kurt ==== Open Meeting of the IETF Directory Directorate Session Chair: Kurt Zeilenga Purpose: Discuss on-going and future directory standardization work, namely LDAP extension work. This session is considered an open meeting of the Directory Directorate, also known as the LDAP Directorate: http://www.apps.ietf.org/ldap-directorate.html Open discussion regarding this session will take place on the LDAPEXT mailing list, archived at . Members of the directorate may, of course, discuss this session on the directorate's mailing list. 0) Preliminaries 1) Introduction 2) Discussion of on-going directory standardization efforts a) Distributed Operations (Chaining) b) LDAP Transactions c) Password Policies 3) Discussion of future directory standardization efforts 4) Open Mic _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Feb 27 19:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsV2-0006ZV-R0; Mon, 27 Feb 2006 19:13:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsUy-0006R8-TH for ldapext@ietf.org; Mon, 27 Feb 2006 19:13:52 -0500 Received: from mail17.ca.com ([155.35.248.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsS7-0001Uk-5R for ldapext@ietf.org; Mon, 27 Feb 2006 19:10:56 -0500 Received: from ausyms11.ca.com ([155.35.201.2]) by mail17.ca.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 11:10:54 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Open meeting of the Directory Directory Date: Tue, 28 Feb 2006 11:10:50 +1100 Message-ID: <52681ACFF63C114F8A3C3651FC9D301F15D34F@AUSYMS11.ca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ldapext] Open meeting of the Directory Directory Thread-Index: AcY7tTKHucvDhwkgTj20BCohIwItDgARf+NQ From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 28 Feb 2006 00:10:54.0224 (UTC) FILETIME=[70D16900:01C63BFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: directory@apps.ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Should the page at http://www.apps.ietf.org/ldap-directorate.html be updated? It makes a reference to LDUP so it must be quite old and therefore the addresses on that page are likely to be incorrect (but I don't know the people referred to). Ron=20 -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]=20 Sent: Tuesday, 28 February 2006 2:46 AM To: ldapext@ietf.org Cc: directory@apps.ietf.org Subject: [ldapext] Open meeting of the Directory Directory A session slot at IETF#65 to hold an open meeting of the Directory Directorate as been approved. Presently, the session is scheduled for 1740-1840 on Monday, 20 March 2006. Of course, the schedule is not final yet. Regards, Kurt =3D=3D=3D=3D Open Meeting of the IETF Directory Directorate Session Chair: Kurt Zeilenga Purpose: Discuss on-going and future directory standardization work, namely LDAP extension work. This session is considered an open meeting of the Directory Directorate, also known as the LDAP Directorate: http://www.apps.ietf.org/ldap-directorate.html Open discussion regarding this session will take place on the LDAPEXT mailing list, archived at . Members of the directorate may, of course, discuss this session on the directorate's mailing list. 0) Preliminaries 1) Introduction 2) Discussion of on-going directory standardization efforts a) Distributed Operations (Chaining) b) LDAP Transactions c) Password Policies 3) Discussion of future directory standardization efforts 4) Open Mic _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 28 16:30:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FECQi-0005ul-VH; Tue, 28 Feb 2006 16:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FECQi-0005uK-7T for ldapext@ietf.org; Tue, 28 Feb 2006 16:30:48 -0500 Received: from boole.openldap.org ([204.152.186.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FECQf-0007Jc-Op for ldapext@ietf.org; Tue, 28 Feb 2006 16:30:48 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k1SLUiKK011738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Feb 2006 21:30:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060228132901.03d38568@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 28 Feb 2006 13:30:13 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-managedit-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Enjoy! -- Kurt >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Date: Tue, 28 Feb 2006 15:50:01 -0500 >Subject: I-D ACTION:draft-zeilenga-ldap-managedit-00.txt >Reply-To: internet-drafts@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The LDAP Manage Directory Information Tree Control > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldap-managedit-00.txt > Pages : 12 > Date : 2006-2-28 > >This document defines the Lightweight Directory Access Protocol (LDAP) >Manage Directory Information Tree (DIT) Control which allows a >directory user agent (a client) to request the directory service >temporarily relax enforcement of constraints of the X.500 models. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-managedit-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-zeilenga-ldap-managedit-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-zeilenga-ldap-managedit-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2006-2-28130944.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-zeilenga-ldap-managedit-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext