From ldapext-bounces@ietf.org Fri Oct 06 14:41:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVucS-0002t4-Ki; Fri, 06 Oct 2006 14:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVucR-0002su-EH for ldapext@ietf.org; Fri, 06 Oct 2006 14:40:23 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVucM-0000En-3E for ldapext@ietf.org; Fri, 06 Oct 2006 14:40:23 -0400 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 k96IdRIc031833 for ; Fri, 6 Oct 2006 12:39:51 -0600 Message-ID: <4526A2DD.1070001@highlandsun.com> Date: Fri, 06 Oct 2006 11:39:25 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: ldapext-bounces@ietf.org RFC4512 and RFC4517 allow OIDs to be either numeric or short-name descriptors, but the objectIdentifierMatch and objectIdentifierFirstComponentMatch matching rules have no way to determine in what context a descriptor resides. That makes it pretty much impossible to validate these descriptors in arbitrary attributes. One possible solution would be to specify the namespace in a schema extension: attributetype ( 1.1.1.1.1.1.1.1.1 NAME 'myAttr' DESC 'The attribute to use' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE X-OID-NAME 'attribute' ) How are others handling this issue? -- -- 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 Sun Oct 08 09:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWZ1C-0000tS-7k; Sun, 08 Oct 2006 09:48:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWZ1A-0000tN-Ut for ldapext@ietf.org; Sun, 08 Oct 2006 09:48:36 -0400 Received: from [2001:4f8:3:ba:2e0:18ff:fe02:efec] (helo=boole.openldap.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWZ17-0004ov-JF for ldapext@ietf.org; Sun, 08 Oct 2006 09:48:36 -0400 Received: from gypsy.OpenLDAP.org (M739P025.adsl.highway.telekom.at [62.47.252.89]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id k98Dlt8r027385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Oct 2006 13:47:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20061008153242.03175d78@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 08 Oct 2006 15:47:36 +0200 To: Howard Chu From: "Kurt D. Zeilenga" Subject: Re: [ldapext] objectIdentifierMatch In-Reply-To: <4526A2DD.1070001@highlandsun.com> References: <4526A2DD.1070001@highlandsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 1.8 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: ldapext-bounces@ietf.org At 04:39 AM 10/7/2006, Howard Chu wrote: >RFC4512 and RFC4517 allow OIDs to be either numeric or short-name descriptors, but the objectIdentifierMatch and objectIdentifierFirstComponentMatch matching rules have no way to determine in what context a descriptor resides. For operational attributes, the context is implicit. >That makes it pretty much impossible to validate these descriptors in arbitrary attributes. For user application attributes, it is not possible for the server to know what the context is without some additional information I think it reasonable to provide this information in an attribute type description extension as you propose. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 10 02:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBPp-0008VS-T8; Tue, 10 Oct 2006 02:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBPp-0008VN-0B for ldapext@ietf.org; Tue, 10 Oct 2006 02:48:37 -0400 Received: from [72.232.34.10] (helo=host.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXBPn-0003Jd-CY for ldapext@ietf.org; Tue, 10 Oct 2006 02:48:36 -0400 Received: from [203.206.165.210] (helo=[192.168.1.156]) by host.eb2bcom.com with esmtpa (Exim 4.52) id 1GXBPh-0005wb-OL; Tue, 10 Oct 2006 16:48:30 +1000 Message-ID: <452B4238.8010200@eb2bcom.com> Date: Tue, 10 Oct 2006 16:48:24 +1000 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: <4526A2DD.1070001@highlandsun.com> In-Reply-To: <4526A2DD.1070001@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 - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: ldapext-bounces@ietf.org Howard, Howard Chu wrote: > RFC4512 and RFC4517 allow OIDs to be either numeric or short-name > descriptors, but the objectIdentifierMatch and > objectIdentifierFirstComponentMatch matching rules have no way to > determine in what context a descriptor resides. That makes it pretty > much impossible to validate these descriptors in arbitrary attributes. There's only a problem if the name is ambiguous, i.e., used in more than one context. Most descriptors I've encountered have been defined in only one context. We reject a descriptor if the context cannot be established and the name is ambiguous, accept a descriptor if it is unique regardless of context, and output a numeric OID if the context cannot be established and we can't find a unique descriptor. > > One possible solution would be to specify the namespace in a schema > extension: > > attributetype ( 1.1.1.1.1.1.1.1.1 NAME 'myAttr' > DESC 'The attribute to use' > EQUALITY objectIdentifierMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.38 > SINGLE-VALUE > X-OID-NAME 'attribute' ) > > How are others handling this issue? We use the X.500 definition of AttributeTypeDescription rather than the LDAP representation to represent schema internally. The X.500 definition differs from the LDAP representation in that it specifies the syntax using a DirectoryString containing an ASN.1 type definition, rather than as an OID. We indicate that an attribute syntax is an OID for an attribute type by defining the syntax to be "ATTRIBUTE.&id" instead of "OBJECT IDENTIFIER". The ATTRIBUTE.&id notation happens to be a reference to the OBJECT IDENTIFIER type, but carries the connotation that it is restricted to OIDs for a directory attribute type. Similarly, we use OBJECT-CLASS.&id, NAME-FORM.&id and MATCHING-RULE.&id for the other contexts. We retain "OBJECT IDENTIFIER" as the syntax when no particular context applies. We map all these alternatives into the same LDAP syntax OID, but that's not a new problem. There are other cases where a single LDAP syntax OID has been used for attributes or matching rules that have slightly different ASN.1 type definitions for their syntaxes. Where necessary, we indicate the specific X.500 syntax with an X-SYNTAX-STRING extension to the LDAP Attribute Type Description. The X-SYNTAX-STRING value is a direct copy of the DirectoryString from the X.500 AttributeTypeDescription. Adding arbitrary new fields to LDAP schema descriptions is problematic for X.500 vendors since there is no direct way to represent the new field in a BER encoding of the description. The X-SYNTAX-STRING extension is an exception because it is exposing an X.500 field that LDAP left out. Rather than defining an X-OID-NAME, I think a better solution would be to define some new LDAP syntax OIDs that have the meaning of "OBJECT IDENTIFIER for an attribute type", "OBJECT IDENTIFIER for an object class", etc. That way no schema extension is required. The definition for the objectClass attribute will be an issue though. Either the definition has to be migrated to the new LDAP syntax OID for object class OIDs, or 1.3.6.1.4.1.1466.115.121.1.38 can be reinterpreted to be the syntax for object class OIDs and a new LDAP syntax created to represent OIDs of no particular context. Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext